Informatievoorziening is snel complex en onoverzichtelijk. Zodra er meerdere systemen in beeld komen, en de gebruikersgroep te groot is om iedereen persoonlijk uit te leggen hoe alles werkt, beginnen de problemen. Gebruikers weten niet hoe ze hun werk moeten doen, koppelingen werken niet zoals het moet en systemen lopen vast. Naast het bedrijfsrisico dat dit veroorzaakt en de hogere beheerkosten om de problemen op te lossen, maakt dit ook het verder ontwikkelen van de informatievoorziening lastig, of zelfs onmogelijk.
Een dergelijke situatie is te voorkomen door met een architectuur te werken. De architectuur beschrijft waaraan de informatievoorziening moet voldoen en geeft de verschillende systemen een plek. Dit verkleint de complexiteit en maakt het ICT-landschap overzichtelijk. Om dit te bereiken met de architectuur wel voldoen aan een aantal criteria, waar in dit artikel op ingegaan wordt.
Het belangrijkste criterium voor een goede architectuur is dat het doel van de informatievoorziening helder is. De informatievoorziening is er om de organisatiedoelstellingen te bereiken, en dat moet ook uit de architectuur blijken.
Als de architectuur in een plaat is vastgelegd, moet daar ook de relatie tot de bedrijfsdoelstellingen blijken. Zo kunnen de bedrijfsfuncties die door de informatievoorziening ondersteund worden, in de plaat opgenomen worden. Vaak wordt dit uitgebreid en vormt de informatiearchitectuur onderdeel van een “enterprise” architectuur, waar ook de inrichting van de organisatie is weergegeven.
Als de architectuur in een aantal principes is vastgelegd, moeten daar ook principes in opgenomen zijn die de relatie tot de bedrijfsdoelstellingen duidelijk maken. Dit is niet altijd eenvoudig, omdat bedrijfsdoelstellingen, die vaak algemeen zijn, vertaald moeten worden naar praktische principes. Het zorgt er wel voor dat de vaak slecht tastbare bedrijfsdoelstellingen toepasbaar gemaakt worden voor de informatievoorziening.
Een bijna net zo belangrijk criterium voor een architectuur is dat deze duidelijk is. De architectuur moet de informatievoorziening overzichtelijk maken, en dat lukt alleen als alle betrokkenen moeiteloos begrijpen wat de bedoeling is.
Een goede manier om de architectuur duidelijk te maken, is door deze eenvoudig te houden. Ook (of misschien zelfs “Juist”) als er veel componenten, systemen, koppelingen, partijen, etc. in het spel zijn, is het zaak om dit te vereenvoudigen tot een duidelijk overzicht. Dit kan een plaat zijn waarin alle componenten met de onderlinge relaties geschetst zijn. Met die plaat is dan goed de impact in te schatten van een wijziging of nieuw systeem.
Maar de architectuur kan ook beperkt blijven tot een lijst van uitgangspunten of principes, waar alle componenten aan moeten voldoen. Dan is nog niet bekend welke systemen er zijn en welke relaties er liggen, maar omdat ze moeten voldoen aan de uitgangspunten kan wel ingeschat worden wat de impact is van een wijziging of nieuw systeem.
Meestal is een combinatie van een plaat, met een aantal principes de beste combinatie. Het is mogelijk om de architectuur helemaal uit te schrijven, maar let er dan op dat het detailniveau goed gekozen wordt. De architectuur mag geen keurslijf worden dat beperkend werkt, het moet een model zijn dat juist mogelijkheden creëert.
Een volgend criterium voor een succesvolle architectuur is dat deze bekend is bij alle betrokkenen. Dat zijn primair de medewerkers die over de informatievoorziening gaan: beheerders, ontwikkelaars, analisten, etc. Maar ook de medewerkers die iets van de informatievoorziening verwachten moeten de architectuur kennen. Het management dat plannen maakt, moet beseffen wat er met informatievoorziening kan, maar ook wat niet in de huidige architectuur past. Daarbij mag dit management in overleg gaan met de mensen van de informatievoorziening om het maximale te halen uit de architectuur, of deze misschien wel aan te passen. Sterker, het management moet in overleg met de informatievoorziening om dit te bereiken.
Het helpt ook om de architectuur bij leveranciers van systemen bekend te maken. Hiermee weten de leveranciers direct in welke omgeving hun systeem gebruikt gaat worden, en waar eventueel rekening mee gehouden moet worden.
Een laatste criterium dat hier genoemd wordt, is het bewaken van de architectuur. Het woord “bewaken” doet vermoeden dat het toepassen van de architectuur (ook wel “werken onder architectuur” genoemd) lastig is en men geneigd is om hiervan af te wijken. Dat hoeft niet zo te zijn, als de architectuur aan de eerste drie criteria voldoet, maar in de waan van de dag wil men toch wel eens een bocht afsnijden. En een kleine afwijking kan het begin zijn van grotere afwijkingen die leiden tot de chaos waar in de inleiding sprake van was. Om dit te voorkomen is enige vorm van controle gewenst. Denk aan een procedure voor wijzigingsvoorstellen met een korte architectuurtoets.
Het is dan belangrijk om te beseffen dat een architectuur niet heilig is: het is een hulpmiddel om de informatievoorziening overzichtelijk en doelgericht te houden, geen doel op zich! Er mogen daarom ook wel afwijkingen van de architectuur zijn, maar zorg ervoor dat deze bewust gekozen worden. Zo kan er een “gedoogregister” bijgehouden worden, waarin de afwijkingen geregistreerd staan. Door regelmatig dit register door te nemen, blijft men bewust van de keuzes, en kan men hier eventueel actie op ondernemen.
Vaak worden bij architectuur criteria genoemd als modulair, toekomstvast, gelaagd, etc. Dit zijn eigenschappen van de architectuur die kunnen helpen om de hierboven genoemde criteria te bereiken. Ze gelden echter niet voor alle architecturen, terwijl dat wel geldt voor de hierboven genoemde criteria.
Om dezelfde reden worden hier geen architectuurmodellen of –instrumenten genoemd. Die zijn er wel, en kunnen heel goed helpen om hele bruikbare architecturen op te stellen. Er bestaat echter niet één model of instrument dat het beste gebruikt kan worden. Daarbij is het model of instrument en zelfs de architect niet meer dan een hulpmiddel: uiteindelijk moet de organisatie zelf met de beste architectuur komen.