Auteur: Willem Janssen

Waarom Enterprise Architectuur haar beloftes niet inlost

Het komt regelmatig voor dat een Enterprise Architectuur (EA) met veel enthousiasme en goodwill in een organisatie is geïmplementeerd, en is mislukt. Waarom is dat en hoe is dit te voorkomen?

In organisaties wordt vaak aan de slag gegaan met het uitdenken van de manier van toepassen van EA frameworks zoals bijvoorbeeld TOGAF waarna een set aan vaak complexe diagrammen uitgedacht wordt. Met deze template diagrammen in de hand worden o.a. processen, actoren, functies, applicaties en data in kaart gebracht en in een centrale repository opgeslagen. Een paar jaar later zie je vaak dat deze diagrammen niet meer actueel zijn en is niet duidelijk wie in de business eigenaar is van wat.

Het gevolg is dat het wiel vaak opnieuw uitgevonden moet worden als een deel van de organisatie geanalyseerd wordt, bijvoorbeeld voor de implementatie van een nieuwe applicatie. Er worden bijvoorbeeld processen gemodelleerd en data-analyses gedaan. Binnen elk project waar dit soort informatie vastgelegd wordt, wordt het vaak op een andere manier gedaan en de informatie niet op zo’n manier opgeslagen dat een volgend project, of de operatie, hier gebruik van kan maken.

De potentiële waarde van het toepassen van EA is groot. Oliver IT ziet EA dan ook als het hebben van een bouwtekening van een huis. Als deze actueel en betrouwbaar is, is het makkelijker te bepalen waar we moeten verbouwen om de veranderende markt goed te kunnen blijven bedienen, welke vakmensen we moeten betrekken in een verbouwing en of we een deel van het huis gaan raken waar al een verbouwing voor gepland staat. De redenen voor het toepassen van EA zijn solide, maar EA kan vaak niet voldoen aan de verwachtingen.

Waar gaat het mis?

1.De afstand tussen de operatie en enterprise architecten is te groot
2.De taal (diagrammen) waarin enterprise architecten communiceren wordt niet goed begrepen.
3.Enterprise architecten kunnen in veel gevallen niet snel genoeg mee bewegen met de operatie
4.Eigenaarschap is niet goed belegd

De belofte is dat architecten de organisatie helpen in het maken van gefundeerde beslissingen over strategie, mogelijk door te voeren veranderingen en (toekomstige) technologische toepassingen. Om deze belofte in te kunnen lossen is een actuele bouwtekening nodig. De focus ligt vaak op hoe deze bouwtekening eruit moet zien en moet passen op hoe de organisatie er in de ideale wereld uit zou moeten zien, in plaats van hoe deze werkelijk functioneert. Er is te weinig zicht op de dagelijkse werkelijkheid waardoor onvoldoende bijgedragen kan worden aan oplossingen op uitdagingen die de business daadwerkelijk ervaart.

De realiteit is dat de meeste mensen diagrammen niet makkelijk kunnen lezen. De architectuur diagrammen zijn vaak complex en vergen veel aandacht van de lezer om echt te begrijpen wat er staat. De lezer haakt af, terwijl er vaak hele waardevolle informatie in zo’n diagram beschreven staat. Enterprise Architecten zijn vaak erg sterk in abstract denken en veronderstellen dat andere mensen daar net zo goed in zijn. Anderzijds, en dat is niet alleen in het EA vakgebied, is er de valkuil van het gebruiken van te veel jargon. Vaak sluit zowel de mondelinge als de schriftelijke taal van architecten niet aan bij de taal die andere collega’s spreken.

Dit is vaak ook een capaciteitsprobleem. Het is niet ongebruikelijk dat een handjevol architecten de EA documentatie up to date moeten houden voor organisaties waar duizenden mensen werken. Men loopt simpelweg achter de feiten aan waardoor informatie die onder EA vastgelegd wordt niet actueel te houden is. Hierdoor neemt de waarde van deze informatie aanzienlijk af. De business merkt en voelt dit en gaat eigen manieren toepassen om toch de (korte termijn) doelen te kunnen bereiken. Een andere oorzaak is dat de neiging bestaat te veel informatie vast te willen leggen, wat de hoeveelheid werk om dit actueel te houden niet ten goede komt.

Een voorbeeld is dat wanneer een procesdiagram bekeken wordt, daar een eigenaar bij staat die al 2 jaar uit dienst is. Of waar de naam van de collega zou moeten staan, staat niets ingevuld. Het beleggen van data-eigenaarschap is vaak nog uitdagender én wordt steeds urgenter vanwege de steeds grotere rol die data speelt binnen en buiten de organisatie.

Hoe dan wel?

1.Decentraliseer en democratiseer het opstellen van benodigde diagrammen.
2.Leg alleen het noodzakelijke vast in deze diagrammen en houd ze simpel.
3.Werk iteratief. Begin klein en laat EA groeien in een tempo dat de organisatie aankan.
4.Borg eigenaarschap.

Het actueel houden van diagrammen is vele malen uitdagender dan ze voor de eerste keer op te stellen. Projecten waarin een legertje mensen de organisatie in kaart brengen lukken meestal prima. Het bijhouden is waar het vaak moeilijk wordt en strandt. Dit kan voorkomen worden door mensen die direct bij de veranderingen betrokken zijn, deze veranderingen bij te laten werken in de bouwtekening. Een goed begin is de IT professionals. Daar waar software aangepast wordt, worden vaak de processen geraakt, de data, de actoren, de technologie, de capabilities, etc. Maak de bouwtekening en het aanpassen daarvan onderdeel van het ontwerpproces waardoor deze professionals direct baat hebben bij de nieuwe methodiek. Voorkom dat diagrammen bijwerken een corvee taak wordt die uitgevoerd moet worden nadat men eigenlijk al klaar is. Hiervoor is gebruiksvriendelijke en toegankelijke tooling nodig. Een mooi voorbeeld is Value Blue.De rol van een architect zal meer verschuiven naar het begeleiden en ondersteunen van collega’s.

“Perfection is the enemy of good”. Zoek aansluiting bij de collega’s ‘die het gaan doen’. Leg concepten uit zonder jargon te gebruiken en zoek aansluiting bij het abstracte denkniveau van de modelleurs. Laat hen alleen informatie vastleggen waar zij zelf het nut van zien of overtuig ze dat additionele zaken ook echt nut hebben. Het hoeft niet meteen perfect, bepaalde concepten kunnen ook later geïntroduceerd worden. Geef het model, maar vooral ook de mensen de kans te groeien.

Maak ruimte om te experimenteren. Begin met een beperkte basis die minimaal nodig is. Daarmee ontstaat ruimte voor de modelleurs om zelf met ideeën te komen, die onder begeleiding van de ervaren architect waar nodig bijgestuurd kunnen worden. Architecten zullen in een meer dienende rol zullen moeten acteren dan een eisende rol. Dat wil niet zeggen dat architecten iedereen maar hun gang moeten laten gaan. Er is een model waaraan voldaan moet worden, er zijn conventies waar niet vanaf mag worden geweken. Leg vooral uit waarom en beweeg als architect mee wanneer de modelleurs of de organisatie aanpassingen wil in de manier van vastlegging.

Beleg het eigenaarschap van processen, data en applicaties op eenduidige wijze. Zorg ervoor dat modelleurs en eigenaren samen een verantwoordelijkheid voelen voor het correct beschrijven en actueel houden van de betreffende diagrammen. Zorg voor borging door het hebben van actuele platen op te nemen in bijvoorbeeld Definitions of Ready en Done en eigenaren op regelmatige basis formeel te laten bevestigen dat hun diagrammen actueel zijn.

In dit artikel hebben wij een aantal concrete tips aan willen leveren die de kansen kunnen vergroten dat de investeringen in EA zich terug betalen en EA haar beloftes inlost. Het is zonde om de enorme hoeveelheden werk van architecten uiteindelijk te laten leiden tot prachtig uitziende resultaten die helaas weinig meerwaarde voor de organisatie bieden. Op dezelfde wijze doorgaan als voorheen gaat niet ineens wel werken, dus durf te experimenteren en durf in te grijpen wanneer de traditionele valkuilen niet vermeden worden.

Specifiekere vragen?

Vul uw e-mailadres in en Oliver IT neemt zo spoedig mogelijk contact met u op!

Gelukt! We nemen spoedig contact met u op!
Gerben Moerland Partner
Gerben Moerland