Het falen van enterprise architectuur

Verschenen als ‘Agile development helpt enterprise architect’ in de Automatiseringgids van 22 oktober 2013 (PDF.)

Enterprise-architectuur wil maar niet volwassen worden. Bijna twintig jaar nadat TOGAF op de markt verscheen, maakt enterprise-architectuur de grote beloften van weleer nog altijd niet waar. In de praktijk zijn de succesvolle enterprise-architecten, de mensen die een verschil maken in hun organisaties, op de vingers van een hand te tellen. Dat is jammer, want de problemen die enterprise-architectuur wil aanpakken, blijven relevant. Informatiesystemen die slecht aansluiten op bedrijfsprocessen, IT-systemen die aan elkaar kleven als drop in een broekzak, hoge beheerkosten, trage veranderprojecten: in veel organisaties is het dagelijkse kost. Wat gaat er mis? En hoe kunnen enterprise-architecten effectiever worden? Architectuur bedrijven gaat grofweg in drie stappen. Stap 1 is het verzamelen van eisen en beperkingen. Waar wil de organisatie naartoe? Wat weerhoudt ons daarvan? Wat is onze uitgangspositie? De architect vangt deze eisen en beperkingen in tekst, platen en modellen die een beeld geven van de huidige situatie, de uitdagingen en de kansen die er liggen. De tweede stap is het ontwerpen van een doelarchitectuur. Hoe kan de informatievoorziening de bedrijfsstrategie ondersteunen? Hoe verlagen we de beheerslasten zodat er tijd en energie vrijkomt voor vernieuwing? De derde stap is veruit de moeilijkste. Tot nu toe is de architect louter op papier bezig geweest. Nu is het zaak om door te zetten en te voorkomen dat zijn prachtige plannen in een bureaula verdwijnen. Voor veel enterprise-architecten is de stap naar realisatie een brug te ver. Ze blijven in hun denken en doen steken op het abstracte niveau van modellen en platen. Sommigen hechten zich zozeer aan een model dat ze er niet los van komen. Anderen hollen van project naar project, overal schetsen van oplossingen achterlatend zonder dat er ooit iets gerealiseerd wordt. In beide gevallen voegt de architect geen enkele waarde toe. Sterker, dit gedrag kost de organisatie alleen maar tijd en geld. Om werkelijk iets te bereiken, moet een architect zich niet alleen verantwoordelijk voelen voor het maken van plannen, maar ook voor de uitvoering ervan in de praktijk. Hij moet de bouwplaats op om zijn ideeën toe te lichten en om toezicht te houden. Maar ook om vragen te stellen en actief kritiek op te halen zodat hij zijn plannen verder kan verbeteren. Op papier is ieder probleem oplosbaar, in de praktijk worden de onvermijdelijke denkfouten rücksichtlos zichtbaar. En misschien is dat nu juist wat veel architecten afschrikt. Veel enterprise-architecten zijn gewend om het slimste jongetje van de klas te zijn. Dan is het niet prettig om met je fouten geconfronteerd te worden.

Taboe

Enterprise-architectuur omvat de structuur van de gehele onderneming, inclusief bedrijfsprocessen, producten, organigram, gegevensstromen, IT-systemen. Zelfs wie zich beperkt tot de informatievoorziening op enterpriseniveau kan zich jarenlang uitleven op het beschrijven van de huidige architectuur en het verfijnen van blauwdrukken voor de toekomst. En dat is precies wat veel enterprise-architecten doen. De derde stap, het realiseren van hun plannen in de praktijk, laten ze achterwege waardoor hun invloed nihil is.

Het is niet verwonderlijk dat het geduld met enterprise-architectuur zo zoetjesaan opraakt. In sommige organisaties is het ‘a-woord’ zelfs taboe verklaard. Dat is in de architectengemeenschap niet onopgemerkt gebleven en er zijn twee grotere bewegingen in het veld te signaleren. De eerste is een vlucht naar voren: nog uitgebreidere raamwerken, nog betere modellen, modernere tools. Vooral meer van hetzelfde dus. Gelukkig is er ook een tegentrend zichtbaar die zich juist richt op het verwezenlijken van architectuur in de praktijk. Een term die in dit verband vaak opduikt, is agile architectuur.

Agile softwaredevelopment is aan het begin van de eeuw ontstaan als reactie op de klassieke watervalmethode. Projecten volgens die methode duurden te lang, kosten te veel of mislukten simpelweg. In gunstige gevallen werd er iets gebouwd dat net niet deed waar de klant lang geleden om gevraagd had. Zelden loste het systeem de actuele problemen op. Die pijnlijke situatie zette een aantal software professionals aan het denken en dat leidde tot een familie van ontwikkelprocessen, waarvan Scrum en eXtreme Programming de bekendste zijn. Sindsdien is agile development steeds belangrijker geworden.

Inspiratiebron

De problemen die agile development oplost, zijn deels vergelijkbaar met die waar enterprise-architectuur nu mee kampt: te lang blijven hangen in de probleemanalyse en ontwerpfase en een gebrekkige feedbackloop van realisatie terug naar analyse. De vraag is dus: kunnen we de lessen van agile development toepassen om enterprise-architectuur uit het slop te trekken?

Agile teams leveren werkende software op in korte iteraties, waarbij de klant aan het stuur zit. Dat vereist intensieve samenwerking tussen business en techneuten, zodat elke iteratie een werkend systeem oplevert met dat deel van de oplossing waar de klant het meest behoefte aan heeft. Dat is een recept dat elke enterprise-architect zich eigen zou moeten maken.

Aan de andere kant is schaalbaarheid nog altijd de achilleshiel van agile development, dat van nature gericht is op projecten, kleine teams en de korte termijn. Enterprise-architectuur gaat juist over projecten heen en bewijst zijn waarde pas op de langere termijn. Een agile enterprise-architect weet dat zijn scope enorm is, op het megalomane af. Hier geldt de vuistregel: hoe groter het gebied, hoe minder gedetailleerd de kaart. Een agile enterprise-architect stelt prioriteiten in samenwerking met al zijn stakeholders. Hij helpt ze hun problemen te verwoorden en bevordert het begrip voor de problematiek van hun tegenvoeters: om samen te werken zullen techneuten de business behoorlijk moeten begrijpen en andersom. Modellen kunnen daarbij een hulpmiddel zijn, maar alleen als ze passen bij de gesprekspartners en hun belangen. Met een financieel directeur (CFO) voer je een heel ander gesprek dan met een Oracle database-administrator.

Bovenal zoekt een enterprise-architect de praktijk op. Om te begrijpen evenzeer als om uit te leggen. Omdat hij weet dat het venijn in de details schuilt en dat de wereld is veranderd sinds hij zijn laatste ontwerp maakte. En omdat hij weet dat hier, op de bouwplaats, de echte waarde wordt opgeleverd. En daar wil hij aan meewerken.

Natuurlijk is dit alles makkelijker opgeschreven dan gedaan. Agile is geen wondermiddel dat enterprise-architecten in een klap effectief maakt. Het is geen kwestie van simpelweg principes kopiëren. Enterprise- architecten hebben hun eigen ontdekkingstocht te gaan. De lessen van agile development kunnen dienen als inspiratiebron, maar zijn zeker geen blauwdruk.