De Enterprise Architect mag niet mislukken

De Enterprise Architect werd zo’n 30 jaar geleden geïntroduceerd om problemen met de toenemende complexiteit van IT-systemen en hun slechte afstemming met de bedrijfsdoelstellingen op te lossen. Deze problemen bestaan ​​nog steeds, nu versterkt door een steeds hoger tempo van technologische veranderingen.

Waarom zal een Enterprise Architect eerder falen dan slagen? Hier volgen acht redenen, gevolgd door aanbevelingen om ze te vermijden.

1. Gebrek aan ondersteuning

Een Enterprise Architect heeft drie hulpmiddelen nodig om zijn werk goed te kunnen doen: toegang, leverage en goodies.

Toegang betekent de mogelijkheid om te communiceren met de juiste managers, vaak op C-level.

Leverage gaat over:

• De juiste plaats in de rapportageketen.
• Commitment van het bestuur.
• Het vermogen om het technologiebudget te beïnvloeden.
• De bevoegdheid om ongepaste technologie-implementaties te stoppen.

Soms kan zelfs een schijnbaar kleine verandering van de titel van technisch architect naar hoofdinvesteerder het verschil maken.

Goodies omvatten:

• De mogelijkheid om nieuwe technologieën in te kunnen zetten voor het testen.
• Technische experts uit te lenen aan slepende projecten.
• Toegang te krijgen tot exclusieve informatie.

Deze goodies kunnen tegen andere gunsten worden geruild.

Een goed ondersteunde Enterprise Architect kan vertrouwen opbouwen door consequent zinvolle resultaten te leveren. Gebrek aan ondersteuning zal zelfs de beste architecten laten falen.

2. Het inhuren van de verkeerde Enterprise Architect

De vaardigheden die iemand nodig heeft om Enterprise Architect te worden, maken die persoon niet noodzakelijkerwijs een goede Enterprise Architect. Vaak worden de meest technische mensen gepromoveerd terwijl ze andere belangrijke vaardigheden missen. Belangrijke vaardigheden zijn:

• Interesse in het bedrijf.
• Het vermogen om technologie te vertalen in eenvoudige bedrijfsresultaten
• Het vermogen om met een aanstekelijk enthousiasme nieuwe technologieën te implementeren.

3. Een Ivoren Toren bouwen

Sommige bedrijven huren een aantal schitterende architecten in die zich lang terugtrekken en terugkeren met geavanceerde frameworks. Deze presenteren ze vervolgens aan de belangrijkste managers van de organisatie. Die hebben geen idee waar de architecten het over hebben, zodat hun complexe referentiearchitecturen genegeerd worden.

Ivoortorens hebben de neiging om de complexiteit te vergroten en de echte belanghebbenden te negeren. Een nieuwe CIO krijgt onmiddellijk erkenning van zijn medewerkers als hij de Enterprise Achitect ontslaat. Gevolg is dat enterprise architectuur een gevreesd woord wordt dat diep in het bedrijfsgeheugen herinnert wordt.

4. Politie en ongevoeligheid voor cultuur

In dat specifieke geval leidt het veranderen van de Enterprise Architecture tot een politietaak met mislukking tot gevolg. Het kost veel moeite om je bedrijf en IT-ers regelmatig opnieuw te overtuigen van de waarde van enterprise-architectuur. Een zachte benadering maakt de kans groter dat de functie slaagt. De beste Enterprise architecten spreken zachtjes en dragen een pot honing met zich mee.

5. Onderhoud van de EA documentatie

Soms blijft een Enterprise Architect druk bezig met het documenteren van de as-is-toestand. Hij heeft een ongelooflijke reeks diagrammen tot zijn beschikking om de verschillende aspecten van alles weer te geven. De wereld van diagrammen is verslavend en perfectie is de vijand van goed genoeg.

In plaats daarvan moet deze architect zich concentreren op het produceren van frequente, zinvolle en meetbare bedrijfsresultaten.

Het is niet eenvoudig om goede KPI’s te bedenken om enterprise-architectuur te meten.

6. Star vasthouden aan een framework of tool

Er zijn meer dan 80 Enterprise Architectuur-frameworks en je zult de perfecte niet vinden. Je kunt het beste kennis nemen van alle belangrijke frameworks, het grootste deel daarvan negeren en de resterende 10% vermengen op een manier die past bij de cultuur, volwassenheid en doelstellingen van de organisatie. Beperk de tijd die je besteedt aan het selecteren van tools en frameworks en richt je in plaats daarvan op het gebruik ervan.

7. Denken dat Enterprise-architectuur hetzelfde is als technische infrastructuur

De meeste Enterprise Architectuur programma’s worden geïnitieerd door IT en komen nooit buiten het technologiedomein. Hoewel technologiestandaarden, technologische road maps en solide technische methoden eenvoudigere, goedkopere, overdraagbare, herbruikbare en beter onderhoudbare oplossingen opleveren, stemmen ze de IT-investeringen niet af op bedrijfsdoelstellingen en leveren ze geen technologische innovatie op.

8. Het woord “Enterprise” letterlijk nemen

“Enterprise” betekent niet noodzakelijkerwijs de hele onderneming. Het betekent veel meer het bekijken vanuit een hogere context alvorens een beslissing te nemen. Architectuur verplaatsen naar het echte bedrijfsniveau vereist een volwassen en toegewijde organisatie. Als je het bedrijfsaspect te vroeg probeert te pushen leidt dat tot mislukking. 

Voor de ondersteuner van de Enterprise Architect

Zorg ervoor dat de organisatie klaar is voor een architectuurgestuurde aanpak en dat de Enterprise Architect goed wordt ondersteund. Als je EA-kandidaten interviewt, vraag dan naar de 8 faalredenen van de functie.

Voor de Enterprise Architect

Bereid je goed voor als je de Enterprise Architectuur van de organisatie wil bespreken. Houd rekening met je eigen capaciteiten, de bedrijfscultuur, het volwassenheidsniveau van de organisatie en het niveau van ondersteuning. Stap op als je niet zeker bent over een van de 8 faalredenen. Blijf niet hangen op een plek waar je het verschil niet kan maken.

Discussieer mee op LinkedIn.