Infrastructuurarchitect is geen superman

Informatie technologie maakt onderdeel uit van zowat alle facetten van de bedrijfsvoering. Services, applicaties en systemen, al dan niet gevirtualiseerd of in de cloud zijn met elkaar verbonden in complexe serviceketens.

Een complexiteit die ervoor zorgt dat er ongewild technologie eilanden binnen een architectuur ontstaan welke rationalisatie bemoeilijken. Gebruikers en beheerders van een bepaalde oplossing zijn dan soms bijna als bewoners van een eiland met eigen overtuigingen en cultuur.

Daarmee wordt een rationele vergelijking van functionaliteiten, kosten en waarde op basis van bijvoorbeeld de MoSCoW-methode bemoeilijkt. Door niet rationele argumenten worden ‘would haves’ plots vaak ‘must haves’ in de criteria van een project. Een goed voorbeeld hiervan is de felle strijd die woedt op de virtualisatie markt. De grote spelers hebben goed op elkaar gelet en de verschillen tussen technologieën de afgelopen jaren steeds kleiner gemaakt. Desondanks blijven er wel verschillen in de oplossingsbenadering van leveranciers die vooral tot uiting komen in de ‘would haves’.

Het gaat hierbij vooral om functionaliteiten die niet aanwezig zijn binnen de traditionele infrastructuur, maar opeens een zware wegingsfactor krijgen. Deze extra’s, die soms ook met een omweg te behalen zijn, voegen vaak weinig toe aan de primaire functionaliteiten van een serviceketen maar zijn wel erg kostbaar. De leveranciers spinnen hier natuurlijk garen bij en zorgen ervoor dat beheerorganisaties hun programma van eisen inkleuren met deze niet-functionele eisen. Maar omgekeerd leiden functionele eisen vanuit de business soms tot oplossingen die slecht passen binnen een bestaande architectuur.

Veel projecten zijn onnodig duur, vaak ‘oversized’ en de nadruk ligt teveel op bijzaken. Zowel een ‘bottom-up’ benadering vanuit de techniek als ‘top-down’ benadering vanuit functionaliteit hebben hun voor- en nadelen. En zoals gewoonlijk zit ook hier de balans in het midden. Bij het vinden van deze balans, waarbij functionele noch niet-functionele eisen tekort gedaan worden, kan een infrastructuur architect een leidende rol spelen. Helaas is dit een nieuwe discipline in de it waarvoor niet direct een opleiding of carrière pad is. Deze rol wordt vooral verkregen door een combinatie van vaardigheden en ervaringen. Een ‘seen that, done that, been there’ instelling zorgt hierin voor een zekere mate van pragmatisme.

Helaas denken veel bedrijven nog dat een infrastructuurarchitect een schaap met vijf poten is dat uitblinkt in commerciële, technische, communicatieve, leidinggevende en coachende vaardigheden. Maar de meeste infrastructuur architecten wijken niet veel af van de andere schapen. Dat maakt hun wol echter niet minder waardevol. Zeker niet als er een goede samenwerking op basis van rationele argumenten is met andere specialisten. De synergie van meerdere competenties zorgt tenslotte voor een nieuwe dimensie waardoor het mogelijk wordt een brug te slaan tussen verschillende technologie-eilanden en hun bewoners. Hierbij gaat het dus meer om de oplossingsrichting en wat minder om de details. Want de details en technische verdieping komen pas als de richting en keuzes duidelijk zijn.

Nu kent deze nieuwe discipline nog weinig referenties, literatuur en modellen. Het richt zich niet op het uitvinden van het wiel, maar vooral op het aanbrengen van verbeteringen in infrastructuren. Zo voegt een infrastructuurarchitect juist bij rationalisatie van bestaande infrastructuren waarde toe door een ander patroon van denken. De ‘seen that, done that, been there’ instelling zal ervoor zorgen dat bestaande en gebruikte modellen in combinatie (her)bruikbaar zijn. Zo kan bijvoorbeeld het kwaliteitsmodel ISO/IEC 9126, dat initieel bedoeld is voor software ontwikkeling, helpen bij het definiëren van eisen voor een baseline. Maar ook referenties uit ITIL, CMM of andere methodieken zijn hierbij waardevol. En zeker bij een technologisch gedreven project als virtualisatie zijn deze essentieel.

Want hierin zijn het vaak de niet-functionele eisen die de totale kosten doen stijgen. De ‘could’ en ‘would haves’, die vaak als ’must’ en should haves’ in het eisenprogramma worden opgenomen, laten stilletjes de CAPEX naar OPEX verschuiven. Dat terwijl er feitelijk niets aan de functionaliteit van de serviceketen verandert. Hierdoor blijkt na afronding van een virtualisatieslag de nieuwe infrastructuur niet alleen duurder, maar ook nog eens moeilijker beheersbaar. Het opstellen van een goede baseline voor virtualisatie vereist een goede inzichtelijkheid, waarbij de ‘six honest serving men’ van Rudyard Kipling helpen om de juiste informatie te verkrijgen. Niet geheel toevallig komen vragen als Wat, Hoe, Waar, Wie, Wanneer en Waarom ook terug in het Zachman framewerk en TOGAF. Je kunt tenslotte niet iets verbeteren, beheren of vereenvoudigen waar je geen weet van hebt. Maar verwachtingen zijn helaas niet altijd rationeel en ook hier zijn de onuitgesproken of niet kwantificeerbare verwachtingen de struikelblokken van de infrastructuur architect.

Nu heb ik zelf, net als de meeste architecten die ik ken, een achtergrond in technisch beheer, consultancy en ontwikkeling. Met karakteristieke kenmerken als affiniteit met techniek en vaak een beta opleiding, gaat het dus vooral om het meetbaar maken en minder om het gevoel. Want net als bij Root Cause Analysis kan de basis van een klacht dan wel een gevoel zijn, maar zit de oplossing uiteindelijk in het concretiseren en aantoonbaar maken. Een infrastructuurarchitect is dus geen superheld met bovenmenselijke gaven, maar kan complexe infrastructurele problemen wel versimpelen. Dit vooral door een pragmatische houding en steeds de ‘six honest serving men’ van Rudyard Kipling in gedachte te houden.