Architectuur zonder Architectuur!

De afgelopen tijd is het onderwerp architectuur echt een hype geworden en het einde is nog lang niet inzicht: nooit eerder werden er zoveel seminars over dit onderwerp gehouden. Nooit eerder werden er meer boeken en artikelen over dit onderwerp gepubliceerd.

Maar waarom eigenlijk?
Is architectuur nieuw? Dat toch zeker niet.
Is architectuur een doel? Ook dat toch niet.

De belangrijkste reden voor al deze aandacht voor dit onderwerp heeft te maken met het feit dat iedereen dagelijks geconfronteerd wordt met de gevolgen van slechte en toevallig tot stand gekomen structuren. Denk bijvoorbeeld aan eilandautomatisering en het ratjetoe aan verschillende technologieën die van project tot project gebruikt zijn. Om nog maar niet te spreken van de totaal verschillende bouwstijlen die gehanteerd zijn van ontwikkelaar tot ontwikkelaar en van project tot project.

Logisch dus dat er totaal geen sprake is van synergie tussen de verschillende projecten. Dat het beheer op langere termijn een onmogelijke taak is. Dat inwerktijden de spuigaten uitlopen en dat het maken van aanpassingen zolang duurt dat niemand het meer wil en durft uit te leggen. Dat dus de ICT een blok aan het been is van menige organisatie en dus niet de bedrijfsstrategie ondersteund laat staan aanvult is logisch.

Aan de ontwikkelaars lag het zeker niet. De zeer goed opgeleide en ervaren ingenieurs die doorgaans de projecten realiseren begrijpen maar al te goed welke keuzes er moeten worden gemaakt en wat de consequenties daarvan zijn. Ze doen dat alleen steeds vanuit hun eigen projectdoelstellingen en vanuit hun eigen ervaringen.

Aan de acceptatietesters lag het ook niet: zij controleerden keurig of de applicatie werkt zoals het moet als het wordt opgeleverd. Wat er op de achtergrond gebeurd en hoe dat is ingericht kunnen en willen zij natuurlijk niets van weten.

De oorzaak is eenvoudig: vanuit het IT Management zijn er nauwelijks inhoudelijke eisen gesteld aan de manier waarop de verschillende projecten *inhoudelijk* werden uitgevoerd en die paar eisen die wel werden gesteld kwamen vaak niet verder als het dicteren van welke versie van Visual Studio en SQL Server er gebruikt moest worden en heel af en toe zelfs een zogenaamde Coding Standard. Misschien begrijpelijk want de projecten schoten als paddenstoelen uit de grond en nieuwe technologieen boden zich sneller dan ooit aan.

Nee, bij kleinere automatiseringsafdelingen is het juist de IT Manager die de meeste kennis heeft van de organisatie als geheel en het IT landschap bovendien en daarom is juist hij bij uitstek de juiste persoon om zich hiermee bezig te houden.

IT Managers, laat de architectuurkaas niet van je brood eten!

Start vandaag met het inhoudelijk opstellen van wat tijdens de beruchte seminars populair 'beleid' wordt genoemd. Zorg dat je weet op wat voor soort veranderingen je wilt inspelen en hoe (denk aan adaptief/perfectief/proactief onderhoud) . Oja, vergeet ook niet om te testen of dergelijke veranderingen echt beter te realiseren zijn. Want als er een ding is wat we de afgelopen periode hebben geleerd dan is dat het wel.

Want architectuur is iets waar je niet al te veel over moet praten,

het is iets wat je gewoon moet doen.