Informatiearchitectuurzorg

De titel doet wellicht vermoeden dat dit artikel gaat over zorgen die ik mij maak om mijn functie, maar nee. Alhoewel ik wel bezorgd ben over de hoeveelheid “architectuurvragen” die ik op de hooivork heb, en de hoeveelheid aandacht die ik effectief aan ieder van die vragen geven kan. Maar daar wil ik het alleen indirect over hebben. In dit artikel wil ik het vooral hebben over “zorg” als in verzorging.

Met “informatiearchitectuurzorg” trek ik dan een directe parallel met “gezondheidszorg”. Op wikipedia vind ik de volgende definitie van gezondheidszorg:

De gezondheidszorg in een bepaald land is het geheel aan activiteiten dat gericht is op de verbetering van de gezondheid van de mensen in dat land. Onder de gezondheidszorg wordt niet alleen het onderzoek en de kennis van gezondheid begrepen, maar ook de toepassing van deze kennis om de gezondheid van mensen te verhogen, ziekten te voorkomen (preventieve gezondheidszorg) of te genezen, en het lichamelijk en psychisch functioneren te verbeteren.

Het leuke is dat die definitie nagenoeg 1-op-1 kan worden overgenomen voor de definitie van informatiearchitectuurzorg:

De informatiearchitectuurzorg in een bepaalde organisatie is het geheel aan activiteiten dat gericht is op de verbetering van de gezondheid van de architectuur van de bedrijfsinformatie, en -informatievoorzieningen. Onder de informatiearchitectuurzorg wordt niet alleen het onderzoek en de kennis van informatiearchitectuurgezondheid begrepen, maar ook de toepassing van deze kennis om de gezondheid (duurzaamheid, toekomstvastheid) van de informatiearchitectuur te verhogen, verzwakkingen te voorkomen (preventieve architectuurzorg) of te herstellen, en het functioneren van bedrijfsinformatievoorzieningen te verbeteren.

Het klopt als een bus, en mijn hierboven genoemde zorgen over de aandacht die ik effectief kan besteden aan de veelheid aan architectuurwerk die ik op mijn hooivork heb, kan ik met behulp van deze parallelle definitie heel mooi oplossen. In de gezondheidszorg zijn (in Nederland althans) namelijk niveau’s aangebracht: een eerste, tweede en derde lijn. Op de eerste lijn bevindt zich de rechtstreeks toegankelijke hulp zoals huisartsen, apothekers, psychologen, fysiotherapeuten, et cetera. Op de tweede lijn bevinden zich de specialistische zorgverleners die alleen na doorverwijzing geconsulteerd kunnen worden. En op de derde lijn bevinden zich tenslotte expertisecentra waarop tweedelijns-specialisten een beroep kunnen doen.

Een mooi systeem. De verlichting van mijn persoonlijke architectuurzorgen ligt mijns inziens dan ook in het aanbrengen van vergelijkbare niveaus in de informatiearchitectuurzorg (en waarschijnlijk gebeurt dat vaak al heel vanzelfsprekend, maar noemen we het niet zo).

De eerstelijns informatiearchitectuurzorg bestaat dan uit informatieanalisten. Zij vormen het eerste contact met de business rondom ICT-gerelateerde vragen en zorgen (issues), of issues met een ICT-component. Hoewel de diversiteit kleiner is dan in de gezondheidszorg hebben de informatie-analisten evengoed ook verschillende specialiteiten. Zo zijn er bijvoorbeeld ERP-informatieanalisten, GIS-informatieanalisten en BI-informatieanalisten. Allemaal proberen ze hun “patienten” eerst te bedienen vanuit hun specialisme en binnen afgesproken beleidskaders en conform architectuurprincipes die op hun specialisme van toepassing zijn.

Op de tweede lijn van de informatiearchitectuurzorg plaats ik de solutions architecten en informatiearchitecten. Zij komen in beeld wanneer de issues en de impact daarvan op de gezondheid van de informatiearchitectuur de kaders van de informatieanalist ontstijgen. Soms is de ingeschatte overschrijding van een zekere budgetgrens daarin bepalend, maar vaak ook de complexiteit van de benodigde oplossing (meerdere systemen vanuit verschillende disciplines worden geraakt).

Tenslotte bevinden zich op de derde lijn, in mijn beleving, de architectuurbeleidsmakers, domeinarchitecten, security-architecten en enterprise-architecten. Maar ik ervaar zelf de scheidslijn tussen lijn 2 en 3 als onscherp. Met name het terrein van de domeinarchitect vind ik onscherp. Eigenlijk staat deze met één been in de tweede lijn en met één been in de derde lijn. Vanuit zijn domeinexpertise wordt hij/zij regelmatig geconsulteerd door informatiearchitecten, maar binnen zijn/haar domein opereert de domeinarchitect op de tweede lijn.

Zoals ik al aangaf, helpt het aanbrengen van deze zorgniveau’s mij bij het vergroten van mijn eigen effectiviteit (als GEO-informatiearchitect). Ik moet er daarbij goed voor zorgen dat de informatie-analisten met wie ik nauw samenwerk, goed op de hoogte zijn van de toepasselijke beleidskaders en architectuurprincipes. Tegelijkertijd voeden zij mij weer met de toepasbaarheid van dat beleid en die principes in de dagelijkse praktijk, en met informatie over voorgenomen verbeteringen (TO-BE Architectuur).

Op die manier kan ik mijn aandacht beter verdelen over de diverse projecten en complexere business-vragen, en hou ik tijd over voor architectuurbeschrijving en -vastlegging (mijn monnikentaak) en het maken van architectuurvisie.

Eigenlijk komt het erop neer dat informatiearchitectuur een capaciteit is van de organisatie. Die capaciteit zit niet op competenties van enkele individuen, maar op samengestelde competenties verspreid over verschillende mensen. Een goede indicatie voor volwassenheid van iedere organisatie-capaciteit is de (snelle) reproduceerbaarheid ervan door “nog-niet-ingewijden” (nieuwe teamleden of teamleden met nieuwe taken).

Met het aanbrengen van zorgniveau’s zou de volwassenheid van de informatiearchitectuur-capaciteit dus groter moeten worden. Ik heb het  niet gemeten, en ik ga dat ook niet doen, maar ik zie dat het werkt.

Ontvlechting en sanering

Ontvlechting en sanering, twee ICT-vaktermen. Het zijn eigenlijk “gewone” Nederlandse woorden die door de ICT-wereld zijn geadopteerd. Blijkbaar was dat nodig. Neem bijvoorbeeld “ontvlechting”. Ontvlechten is alleen nodig als er sprake is van onwenselijke vervlechting. In de ICT raken zaken inderdaad nogal eens teveel met elkaar vervlochten doordat die zaken over de tijd, te haastig en op diverse manieren aan elkaar werden geknoopt. En dat gebeurt dan ook vaak herhaaldelijk en jaren achtereen, zodat de ongezonde situatie ontstaat waarin van delen van het geheel niemand helemaal begrijpt waarom het werkt zoals het werkt.

Het werkwoord “saneren” heeft louter betekenissen die nuttig zijn voor de ICT, zoals: opruimen, weer gezond maken, zuiveren en verbeteren. Maar we denken meestal aan deze betekenis: afbreken en vervangen. Natuurlijk zou je liever willen voorkomen dan saneren, maar dat is moeilijk. De druk vanuit de business is vaak te hoog waardoor toch concessies worden gedaan aan kwaliteit en zonder architectuur wordt gewerkt. En zonder overkoepelend toezicht op en zonder overkoepelende besturing van – ofwel, zonder architectuur governance van – ICT-ontwikkelingen komen de haastig neergezette oplossingen meestal niet weer onder architectuur.

Dus als een ICT-landschap over de jaren door vele uitbouwprojecten is verworden tot een complex, instabiel, onvoorspelbaar, moeilijk beheerbaar en lastig uitbreidbaar geheel, waarvan niemand meer helemaal overziet en begrijpt hoe het werkt en waarom, dan wordt het tijd voor ontvlechting en sanering. Dit zijn doorgaans grote uitdagingen.

Ontvlechten is het proces van het in kaart brengen van de complexiteit en het weer terugwinnen van het overzicht en het inzicht. Door ontvlechting komen we weer “in control” van het beheer en de ontwikkeling, zodat met vertrouwen kan worden besloten tot het opruimen van overtollige constructies en het weer beter maken van ongezonde constructies: ofwel sanering .

En als ontvlechting echt een heilloze zaak is, dan rest eigenlijk nog maar één ding: volledige sanering. Dat houdt dus in dat je een compleet ICT-landschap vervangt. Wanneer is ontvlechting heilloos? Dat is niet eenvoudig te beantwoorden, maar levensvatbaarheid en toekomstvastheid zijn belangrijke factoren.

Uiteindelijk hoop je met ontvlechting en sanering te bereiken dat we weer “in control” geraken over het betroffen ICT-landschap, en dat we deze weer voldoende gevitaliseerd hebben zodat het weer een tijd mee kan. Ook doet uw organisatie er verstandig aan haar ICT-processen te ontvlechten en saneren en te zorgen dat aan- en verbouw in het ICT-landschap voortaan onder architectuur gebeurt.