hoezo architectuur

De meeste mensen denken aan bouwkunde als zij het woord 'architectuur' horen. En dat is ook voor de hand liggend. In de IT-wereld is er echter sinds de jaren 90 een steeds sterker wordende neiging ontstaan om 'onder architectuur' te willen werken.

Hier wordt dan onder verstaan dat geleverde IT-diensten en software voldoen aan een aantal principes die vakmensen met elkaar hebben afgesproken. Op zich is het een goede zaak dat er op die manier een kwaliteitsborgingsmechanisme is ontstaan, maar ik vraag mij wel eens af of wij vakmensen niet een beetje aan het doorschieten zijn. Het lijkt wel een religie te worden vol met dogma's.

Toch ben ik er een groot voorstander van om IT-diensten volgens een aantal principes op te zetten. De praktijk leert namelijk dat de onderhoudskosten, flexibiliteit en de duurzaamheid van de functionaliteit hierdoor sterk verbeteren.

Ik wil nu graag een simpel begrippenkader voor 'architectuur' in de IT-wereld intrroduceren. Dit architectuurbegrippenkader is bedoeld om perspectief te geven aan de besluitvorming over de inrichting van de IT.

In de jaren 90 heb ik bij AT&T Network systems onderstaande modellen gebruikt om aan het seniormanagement uit te leggen waarom het introduceren van 'werken onder architectuur' nodig was.


Ik probeer hiermee de interactie tussen de Business en IT in kaart te brengen en ik gebruik daarvoor vier domeinen:
Langs de horizontale as:

• de werkelijkheid bestaande uit processen, mensen en middelen en
• abstracties van die werkelijkheid in de vorm van modellen / afbeeldingen / beschrijvingen.

Langs de vertikale as:

• het bedrijf / de organisatie en
• de IT.

Op dat moment was het bedrijf bezig aan zijn eerste stappen buiten de U.S.A. en was onze vestiging in Nederland een springplank voor geplande uitbreiding. De IT voor de bedrijfsondersteuning was echter zowel in de U.S.A. als bij ons een grote lappendeken van allerlei zelfgebouwde software. Van uitbesteding was alleen bij ons in beperkte mate sprake en dan nog alleen naar de IT-afdeling van de vroegere eigenaar van het bedrijf.

Om een dialoog over de consequenties van 'globalisering' van het bedrijf op gang te brengen, heb ik de 'AS-IS' situatie in bijgaande matrix in beeld gebracht:


Uit deze inventarisatie werd duidelijk dat er sprake was van een grote verscheidenheid aan processen en technologieën om die processen te ondersteunen.

Simplificatie en standaardisatie in het bedrijf en in de IT waren alleen management doelen, maar kwamen nog niet in de werkelijkheid terug. Besluitvorming over IT was een dagelijkse directe interactie tussen Business en IT op een te laag niveau in de organisatie.


Mijn doel was het introduceren van 'werken onder architectuur'  en ik heb dit als volgt in beeld gebracht:



De boodschap kwam aan en er kwamen een aantal programma's om de aanpak te verbeteren. Maar je komt niet zo maar tot standaardisatie van de IT. Daar is een weloverwogen groeipad voor nodig. Om dit groeipad te kunnen definiëren moeten we eerst naar 'simplificatie en standaardisatie' van de business kijken.

Voorbeeld van een toepassing van het model:
In mijn periode bij Essent is dit model verder uitgewerkt tot een 'architectuur methode' en kreeg het de naam KOMPAS, met de bedoeling om aan de hand van dit model een koers uit te kunnen zetten voor de IT op basis van een aantal besluitvormings principes.