Als een organisatie ICT serieus neemt, leidt dat tot serieuze vragen. Maar als het team architecten daar niet aan toe is, ontstaan er vluchtbewegingen, zeggen Gert Florijn en Matthijs Maat. De antwoorden worden verstopt in jargon en intimiderende diagrammen. Wat te doen om te voorkomen dat architectuur een schijnverankering wordt? Ontdek de zeven angsten en verlangens die een goede architectuur in de weg staan.
ICT-architectuur op zijn best helpt organisaties om grip te krijgen op hun informatievoorziening zodat ze die kunnen vormgeven op een manier die past bij hun strategie. In de praktijk komt architectuur vaak onvoldoende van de grond (zie ‘Terug naar de kern van architectuur’, AG Connect, juni 2017). De architectuur bestaat uit abstracte modellen die niet aansluiten op de realiteit, en de denkbeelden van architecten vinden hun weg niet naar de bestuurstafel, noch naar projecten. In de praktijk zijn terugkerende situaties te herkennen die een pragmatische ICT-architectuur in de weg staan.
Het zijn niet altijd de architecten zelf die daarbij een hoofdrol spelen, juist het ecosysteem waarin ze functioneren – en de angsten en verlangens van de belanghebbenden – heeft veel invloed. Vandaar: zeven angsten en verlangens die een goede architectuur in de weg staan.
De ICT van grote organisaties is complex en zelfs voor experts lastig te overzien. Beslissingen kunnen vergaande gevolgen hebben voor bedrijfsprocessen, kosten en zelfs de continuïteit. Tegelijkertijd gaan ICT-projecten vaak fout: ze lopen uit, zijn duurder dan gedacht en leveren niet de gehoopte voordelen op. Dat maakt bestuurders schuw en voedt het wantrouwen jegens ICT. Die bestuursangst kan leiden tot een schijnverankering in architectuur. Het architectuurbeleid wordt tot op het hoogste niveau besproken zonder dat er werkelijk begrip en betrokkenheid ontstaan. Dat kan een gevoel van controle geven, maar zodra er iets dreigt mis te gaan, ontstaat een crisissfeer waarin alle beleid aan de kant wordt geschoven: nu even niet zeuren over de regeltjes, het is alle hens aan dek. Pragmatische architectuur kan deze angst wegnemen door de werkelijkheid inzichtelijk te maken en reële opties te presenteren, samen met hun consequenties. Om effectief te adviseren, moet de architect het vertrouwen van de beslissers al ver voor de crisis hebben verdiend. Van nature steken veel architecten echter meer energie in de inhoud dan in relaties met anderen.
Vaak is een grote ambitie nodig om een beweging in gang te zetten. Kleine verbeteringen spreken onvoldoende tot de verbeelding om bestuurders mee te krijgen, dus worden er grote droombeelden opgesteld en uitgedragen: dit nieuwe systeem gaat eindelijk alles oplossen! Enige realiteitszin zou helpen om iets van die ambities waar te maken, maar dat blijkt lastig: is een organisatie eenmaal in de ban van de droom, dan is realiteitszin ongewenst. Architecten die op de rem gaan staan omdat er serieuze twijfels zijn, krijgen al snel het imago van zeurpiet. Architecten die jubelen over de ongekende mogelijkheden hebben juist de wind mee, maar ze lopen het risico de kop van jut te worden als de innovatie later tegenvalt.
In sommige grote organisaties lopen er talloze mensen rond met ‘architect’ op hun visitekaartje die geen idee hebben wat hun rol is. De term is verwaterd en staat gelijk aan een functieschaal: een ICT’er die lang genoeg in dienst blijft, wordt vroeg of laat architect. Er zijn voorbeelden van reorganisaties waarbij elke senior ICT’er die niet in het nieuwe organigram paste, tot architect werd gebombardeerd. In een poging hun positie te verantwoorden, grijpen veel van deze architecten naar de pen om uitgebreide architectuurbeschrijvingen te produceren. Hoewel ze weinig effect hebben, moet al dat papier wel worden gereviewd, bediscussieerd en verbeterd. Zo ontstaat een beeld van intelligente mensen die vreselijk druk zijn. Zo’n groep architecten kan soms jarenlang zijn gang gaan zonder waarde toe te voegen.
Zeker in overheidsorganisaties is architectuur vaak een ‘ding dat ook nog moet’. In de checklist voor projecten staat dat er een xyz-architectuur moet komen, dus die komt er, vaak opgesteld door iemand die de werkelijke problematiek niet kent. Er worden modellen gemaakt volgens de vigerende standaard. Er worden lappen tekst geschreven die aantonen dat een oplossing gaat voldoen aan allerlei opgelegde principes, zonder dat iemand de vraag stelt of die standaard en principes wel relevant zijn. De checklist kan worden afgevinkt, het project kan door. Daarmee is nog niet een gedragen oplossing gemaakt die recht doet aan de eigenheid van de situatie. Niemand garandeert dat zo’n architectuur werkbaar is of dat de gerealiseerde oplossing lijkt op wat er op papier is gezet.
Als een organisatie ICT serieus neemt, leidt dat tot serieuze vragen. Welke technologie kiezen we voor de volgende implementatie? Hoe bereiden we ons voor op nieuwe wetgeving rond gegevensbescherming (AVG)? Wat betekent digitale transformatie voor ons? Een antwoord geven op zulke grote vragen, vergt vertrouwen in eigen kunnen. Als het team architecten daar niet aan toe is, ontstaan vluchtbewegingen. De antwoorden worden verstopt in jargon en intimiderende diagrammen of de angstige architect vlucht in valse bescheidenheid: ‘Ik ben slechts adviseur, jullie moeten beslissen.’ Anderen zoeken houvast in standaardmethodieken en referentiemodellen. Als de NORA het zegt, zal het toch wel waar zijn? Als ik TOGAF trouw volg, moet de oplossing toch kloppen? Dat wordt pas echt een probleem als de intelligentie en creativiteit van mensen worden uitbesteed aan de methode. Op het moment dat het volgen van de juiste stappen of het tekenen van het juiste symbooltje, belangrijker wordt dan inzicht bieden, richting geven en praktische oplossingen voorstellen, schiet de inzet van een methodiek of referentiemodel zijn doel voorbij.
Zeker onder architecten is er een oerverlangen naar die ene, generieke oplossing die alle problemen aanpakt. Dat heeft onder meer geleid tot een nog altijd groeiende familie van referentiemodellen: de NORA voor de rijksoverheid, de GEMMA voor gemeenten, de VERA, PURA, ZIRA et cetera. Het motto is elke keer: laten we stoppen met het wiel opnieuw uitvinden, laten we van elkaar leren. Met dat uitgangspunt is niets mis, maar in de praktijk werkt het niet omdat er wordt begonnen met het maken van een algemeen model. En om bijvoorbeeld een model te maken dat voor elke gemeente klopt, moeten wezenlijke details worden weggelaten. De werkelijkheid wordt beschreven in zulke abstracte termen dat ze weliswaar altijd kloppen, maar ook niets toevoegen. Zo zijn er referentiemodellen voor de zorg waarin de term ‘patiënt’ niet eens voorkomt. Zonder aansluiting bij de werkelijkheid, staan die modellen ons alleen in de weg.
Bouwkundige architecten verdiepen zich in de context waarin een nieuw object functioneert. Daarbij kijken ze vanuit allerlei perspectieven. Natuurlijk stellen ze zichzelf de harde vragen: wat kan er technisch? Maar ze verdiepen zich ook in de leefwereld van gebruikers: wat doen ze in dit gebouw en de omgeving? Wat willen we bereiken met het nieuwe object? Hoe kunnen we dat realiseren? Ze nemen de klant (opdrachtgever) mee in hun denkproces en maken hun ideeën letterlijk tastbaar in maquettes. Veel ICT-architecten lijken zich niet op eenzelfde manier te durven verdiepen in de werkelijke situatie. Meelopen met gebruikers, klanten, management en leveranciers gebeurt nauwelijks. Liever proberen ze problemen op te lossen met een ICT-ideaaltypische invulling. Daarmee doen ze de eigenheid van hun organisatie tekort en lopen ze kansen mis om samen oplossingen te vinden die recht doen aan de situatie.
De auteurs Florijn en Maat zijn tevens initiatiefnemers van Architectuur met een hoofdletter P, een site met korte observaties, ervaringen en overdenkingen die gaan over effectievere ICT-architectuur.
AGconnect - ICT-architectuur is vaak kostbare flauwekul. Architecten sluiten onvoldoende aan bij de praktijk. Dat is jammer, want een ICT-architectuur kan cruciaal zijn bij het begrijpen en veranderen van de informatievoorziening.
Lees verderIT-projecten hebben een slechte reputatie. Ze duren te lang, kosten te veel en leveren te weinig op. Welbeschouwd is het een wonder dat er nog zoveel IT-projecten slagen. Want de manier waarop grote IT-projecten worden aangestuurd moet fundamenteel anders.
Lees verder
