Wat moet dat fietsstuur in mijn auto?

Als ik uitleg wat ik doe als IT-architect begin ik meestal met uit te leggen dat IT-architectuur mijns inziens een technisch woord is voor IT-beleid. En als IT-architect ben ik dan eigenlijk IT-beleidsmedewerker. En zoals dat gaat met beleidsmedewerkers kan ik wel het beleid opstellen, maar er niet over beslissen. Dat hoort ook zo, want de IT-verantwoordelijke binnen de organisatie moet over zijn beleid beslissen en niet ik. Ik geef alleen advies. Voor de goede orde in mijn ogen bestaat beleid uit van te voren genomen beslissingen en IT-architectuur gaat dus over beslissingen aangaande de IT-portfolio. Die IT-beslissingen worden ook wel principes genoemd.

IT-architecten maken vaak alleen architectuurplaten en vergeten de principes (of IT-beslissingen) zelf op te schrijven. Hierdoor blijven die principes impliciet. Er zijn dus wel beslissingen genomen, maar alleen hun uitwerking is geëxpliciteerd in een plaat. Het blijven echter beslissingen die IT-architecten uiteindelijk niet zelf kunnen nemen. Ja, soms lijken ze die beslissingen wel zelf te nemen, dan tekenen ze een plaat en zeggen ze: zo moet het worden (of nog erger: zo gaat het worden), maar als het puntje bij paaltje komt blijkt iemand anders de werkelijke beslissingen te nemen. En als die beslisser het plaatje dan niet begrepen en geaccordeerd heeft, dan gaat dat plaatje geen werkelijkheid worden.

Het is gebruikelijk om het systeem dat gebruikt wordt om de business te besturen ook te gebruiken voor het besturen van de IT-portfolio. De dynamiek van de business en de IT-portfolio zijn echter dusdanig asynchroon dat het lijkt alsof je een auto wilt besturen met een fietsstuur. Om dat duidelijk te maken hebben Charles Hofman en ik de IT-governance game gemaakt die vrij beschikbaar is [1]. Deze managementgame is gebaseerd op de 'Tragedy of the commons' [2]. Keer op keer krijgen wij van spelers te horen dat dit precies hun organisatie treffend beschrijft. Dit is een heel interessant punt. De kern van de 'Tragedy of the commons' is namelijk dat er geen gemeenschappelijk belang is. Maar een organisatie heeft wel degelijk een gemeenschappelijk belang, zeker bij haar IT-portfolio. We concluderen dus dat het besturingssysteem voor organisaties vaak niet in staat is om dat gezamenlijke IT-belang te dienen.

Een voorbeeld om die verschillen in dynamiek inzichtelijk te maken is wellicht de business case van IT-architectuur. Simpel gezegd komt het erop neer (en zo hebben we ook het spel ontworpen) dat aan IT-architectuur doen betekent: van te voren rekening houden met de belangen van je collegae. Zij hebben namelijk in de toekomst profijt van jouw investering nu. Hier doemt een tweeledig probleem op: ten eerste gaat die toekomst niet meebetalen aan jouw oplossing onder architectuur nu, en ten tweede is van te voren al helemaal niet duidelijk wie eigenlijk de vruchten gaat plukken van jouw investering.

Ten slotte moet mij nog één ding van het hart: ik voel mij meer een tuinman dan een architect. Een architect bedenkt dingen die dan vervolgens conform zijn beelden worden geconstrueerd. Maar de werkelijkheid van de IT-portfolio is geheel anders. IT-portfolio’s evolueren autonoom, al wat een IT-architect kan doen is zaaien, bemesten, snoeien en oogsten. Als er één abstractieniveau is waarop een IT-architect actief moet zijn is het wel dat niveau waarop hij die autonome groei respecteert en bijstuurt. Anders wordt het al gauw vechten tegen de bierkaai.

^{[1] futurefurniture.nl/it-governance-game
[2] en.wikipedia.org/wiki/Tragedy_of_the_commons, nl.wikipedia.org/wiki/Tragedie_van_de_meent}