Ontwikkelen zonder Architectuur

«Ontwikkelen onder architectuur» is een mooie, beeldende, typisch Nederlandse uitdrukking die zich jammer genoeg moeilijk in het Engels laat vertalen. Het appelleert aan een gevoel van doordachte, kwalitatief hoogwaardige resultaten. Het wordt geassocieerd met een architect die, als rechterhand van de opdrachtgever, een ingewikkeld bouwproces in goede banen weet te leiden. Een architect met verstand van zaken, die weet wat er op de markt te koop is, en die dat kan vertalen naar de dromen en verlangens van de opdrachtgever. Iemand die niet alleen maar praatjes verkoopt, maar ook verantwoordelijkheid neemt voor een succesvolle realisatie. Prachtig, toch?

Voor zover ik heb kunnen nagaan is het begrip «Ontwikkelen zonder Architectuur» voor het eerst geïntroduceerd in het alleszins lezenswaardige boekje van Sogeti, getiteld: “DYA – Snelheid en samen­hang in business- en ICT-architectuur”. Maar als het begrip «Ontwikkelen onder Architectuur» zulke warme gevoelens oproept, wat is dan «Ontwikkelen zonder Architectuur», in welke situatie zou je dat dan willen praktiseren en waarom is het eigenlijk überhaupt nodig?

Het genoemde boekje stelt dat er gegronde redenen kunnen zijn om zonder architectuur te willen ontwikkelen; bijvoorbeeld als je een oplossing heel snel moet realiseren – een korte time-to-market – of als je innovatieve technologie wilt toepassen. Het lijkt bedoeld als een soort ingebouwde escape in het architectuurproces, een escape die dient om managers die bang zijn voor een papieren tijger hun belangrijkste argumenten tegen «Ontwikkelen onder Architectuur» bij voorbaat uit handen te slaan.

Op het eerste gezicht lijken dit allemaal zeer valide argumenten. Waarom is het bij nader inzien dan toch je reinste

Flauwekul?

Het zou flauw zijn om er alleen maar op te wijzen dat het per definitie onmogelijk is om een systeem te ontwikkelen dat geen architectuur heeft. Immers, ieder systeem van enige complexiteit is opgebouwd uit onderdelen met onderlinge interacties, heeft wel enige interactie met de buitenwereld, en is conform bepaalde ontwerpprincipes gebouwd. Zelfs spaghetti heeft een bepaalde architectuur. Maar dat is ongetwijfeld niet wat de auteurs bedoeld hebben met hun, eh, woordgrapje. Ze hebben vermoedelijk bedoeld dat een bedrijf binnen haar enterprise architectuur bewust gekozen heeft voor het toepassen van bepaalde principes en standaarden, maar dat het desondanks soms toch wenselijk kan zijn om – al is het maar tijdelijk – systemen te accepteren die niet aan die zelfgekozen principes en standaarden voldoen.

Evengoed is de woordkeus op z'n minst ongelukkig te noemen. Het suggereert immers dat je maar twee mogelijkheden hebt: je ontwikkelt ofwel onder, ofwel zonder architectuur. Er lijkt geen tussenweg mogelijk te zijn. En dát is precies wat er zo wringt aan het begrip «Ontwikkelen zonder Architectuur». Het creëert een tegenstelling die er niet zou mogen zijn. Denk even mee.

Een uitgewerkt stelsel van principes en standaarden is zonder twijfel hartstikke nuttig. Tegelijkertijd is het in niemands belang dat zoiets een keurslijf wordt. Met andere woorden: in de praktijk heb je als architect soms behoefte om een afweging te maken van het belang van het toepassen van een specifiek principe of een standaard tegenover het toestaan van een afwijking. En als de nadelen van het toepassen van een standaard – in termen van ontwikkelkosten, exploitatiekosten en ontwikkeltijd – overduidelijk niet opwegen tegen de voordelen van een alternatief, dan valt het toch moeilijk te verkopen dat de enterprise architectuur principes onder alle omstandigheden onverkort moeten worden toegepast? Ontwikkelen onder architectuur zou toch juist moeten draaien om het maken van een evenwichtige afweging tussen alle concerns van alle stakeholders?

Dan nog iets. In de pure vorm van ontwikkelen zonder architectuur zou er sprake zijn van een architectuur die op geen enkele manier past in de bestaande enterprise architectuur. Dat houdt dus in dat de bedrijfsprocessen op een volstrekt andere leest zijn geschoeid dan de rest van de processen binnen de organisatie; dat een informatiesysteem op geen enkele manier past in de bestaande informatiearchitectuur en dat er van compleet andere technologiestack gebruik wordt gemaakt. Er zijn vast tal van praktijkvoorbeelden te bedenken waar zo'n totale breuk met de bestaande situatie heeft plaatsgevonden. Een aparte organisatie, met een aparte boekhouding, eigen gebouwen, een eigen manier van werken, een eigen website, een apart data warehouse en eigen informatiesystemen. Maar wacht even. Dan hebben we het in dat geval eigenlijk over een apart bedrijf, met een aparte identiteit, dat over de hele linie zelf zijn eigen keuzes maakt en ook zelf beslist over de inrichting van zijn eigen enterprise architectuur. Een nieuwe enterprise architectuur, naast een bestaande. Ook dat kun je toch heus niet betitelen als «Ontwikkelen zonder Architectuur»?

Dan was er ook nog het sympathieke argument dat het toepassen van nieuwe technologie in het algemeen nieuwe ontwerpprincipes en standaarden vereist. Principes en standaarden die je niet vooraf kunt vaststellen, althans als je niet helderziende bent. Het toepassen van nieuwe technologie vraagt typisch om een experiment, met als doel om in de praktijk te onderzoeken welke nieuwe principes en standaarden zinvol zouden zijn. Op zichzelf is dat toch geen flauwekul? En toch is er met dit argument iets raars aan de hand. Om te beginnen geldt ook hier dat het niet zonder meer logisch is dat een technologische vernieuwing een enterprise over de hele linie op z'n kop zet. Werkelijk alles tegelijkertijd proberen te veranderen is immers een riskante strategie die je in de praktijk gelukkig niet zo vaak tegenkomt. Maar stel je even voor dat er een project loopt dat erop gericht is om een nieuwe architectuur in te voeren. Een project dat begint met het opstellen van eisen en wensen, op basis daarvan een leverancier selecteert, een proof-of-concept met de technologie uitvoert om te bewijzen dat de goede richting gekozen is, vervolgens een pilot uitvoert om te bewijzen dat het ook in de praktijk gebracht kan worden en dan de lessen trekt voor vervolgprojecten. Een project dat de fundamenten legt voor de nieuwe architectuur. Zou je niet bij uitstek in zo'n innovatief project een prominente inbreng van architecten verwachten? Zou je dan werkelijk een project, dat een nieuwe architectuur als de belangrijkste deliverable heeft, willen uitvoeren onder het label «Ontwikkelen zonder Architectuur»?

De architectuuragenda

Ontwikkelen onder architectuur is een balanceeract. Er zijn doorgaans een heleboel stakeholders bij een ontwikkeling betrokken. Niet zelden hebben deze stakeholders op onderdelen tegenstrijdige belangen. Als architect moet je daarvoor gevoelig zijn en je moet in staat zijn om tussen dergelijke klippen door te laveren. In de praktijk werkt het vaak erg goed om de discussie over het toepassen van principes en standaarden tegelijkertijd te voeren met de discussie over de eisen en wensen van de stakeholders in een scenario workshop. In zo'n workshop worden de voor- en nadelen van de verschillende oplossingsscenario's op een rijtje gezet. Het gaat dan om realistische oplossingsscenario's die door de betrokken architect zorgvuldig zijn gekozen. Zulke oplossingsscenario's kunnen in principe het hele kleurenspectrum tussen wit – geheel conform de geldende architectuur – en zwart – geheel afwijkend van de geldende architectuur – afdekken. Een dergelijke integrale belangenafweging aan de hand van concrete scenario's werkt vaak veel effectiever dan een geisoleerde discussie over het honoreren van een specifiek requirement, principe of standaard.

Als enterprise architect zou je na moeten denken over een formele procedure voor het accepteren van afwijkingen van de geldende principes en standaarden. Dan houd je tenminste grip op de projecten. Het is uiteraard zaak dat beslissingen over het al of niet toestaan van uitzonderingen op het juiste niveau worden genomen. Je kunt je daarvoor eens laten inspireren door de vrijstellings­procedure die bij de regelgeving in bestemmingsplannen gebruikelijk is. Het meest bekend is de zogenaamde artikel-19 procedure, die het afhandelen van aanvragen voor vrijstellingen regelt. Minder bekend is de artikel-17 procedure, die voor tijdelijke vrijstellingen gebruikt kan worden. Denk in elk geval ook na over de rol die een orgaan als de architectuurraad bij het al dan niet verlenen van vrijstellingen zou kunnen spelen.

«Ontwikkelen zonder Architectuur» is onmiskenbaar een flauwekulbegrip. Als je «Ontwikkelen onder Architectuur» op een professionele manier praktiseert, dan is «Ontwikkelen zonder Architectuur» volstrekt nutteloos en overbodig. Het wordt de hoogste tijd dat we als architecten stoppen met ons vakgebied te diskwalificeren met dit soort verwarrende begrippen. Wij staan er immers voor om in het complexe krachtenveld van alle stakeholders, evenwichtige ontwerpkeuzes maken die rekening houden met het hele spektrum aan belangen. De enterprise architectuur is best belangrijk, maar als het puntje bij paaltje komt, dan staat het belang van de business toch voorop. Een enterprise architect moet sowieso oppassen voor het stigma van de principeneuker. Het onverzettelijk vasthouden aan principes schiet uiteindelijk altijd zijn doel voorbij. Het is veel effectiever om constructief mee te werken aan just-enough en just-in-time architectuur. Dat is overigens ook veel uitdagender. Er zijn immers nog zoveel andere kleuren behalve zwart en wit.

Deze flauwekul ontzenuwt een actueel architectuurdebat op een pittige en soms zelfs controversiële manier. Het is de 2^de in een reeks flauwekul die op dit weblog gepubliceerd zal worden.