Mei
2002: Invoeren van (Corporate) Architectuur
Deze maand de volgende
stelling:
---
“Het invoeren van architecturen of van een “corporate architectuur”
in een organisatie eist veel inspanning.”
---
Het is de vraag
of dit waar is.
Elke organisatie,
groot of klein, heeft een informatievoorziening. Organisaties weten
ook, in meer of mindere mate, hoe die informatievoorziening in elkaar
zit. Het probleem is echter vaak dat elke betrokkene een eigen beeld
van die informatievoorziening heeft. Dat is meestal slechts een (klein)
deel van het geheel en er is vaak geen algemeen beeld. Aan te nemen
is dan dat men niet onder architectuur werkt.
Mensen hebben vaak
een eigen kijk op “hun” organisatie. Wat ze zien is vooral
bepaald door hun op-leiding, functie, achtergrond, interesse enz.. Ter
vergelijking: personeelsfunctionarissen kijken naar andere dingen dan
juristen, logistiek specialisten, boekhouders en ga zo maar door. Stel
dat een organisatie 25 personeelsfunctionarissen in dienst heeft. Het
is “normaal” dat zij afspraken maken over hoe zij personeel
in die organisatie zien en benaderen. Dit beeld dat ze samen vormen
zou een architectuur genoemd kunnen worden. Bij mensen die zich met
de informatievoorziening van een organisatie bezighouden lijkt dit anders
te werken. Het is “gewoon” dat iedere betrokkene een eigen
beeld van die informatievoorziening heeft.
Het invoeren van
architecturen rond een informatievoorziening vereist dat onderling afspraken
gemaakt worden. Zo ontstaan de nodige gezamenlijke beelden, architecturen.
Rond een informatievoorziening zijn 3 architecturen relevant:
- De bedrijfsproces
architectuur (ook wel business of enterprise architectuur genoemd).
Hier wordt in beeld gebracht hoe mensen in de organisatie samen werken.
Deze architectuur heeft dus te maken met de inrichting van de bedrijfsvoering.
Het is sterk de vraag of informatiekundigen en IT-ers hier een rol
als architect dienen te vervullen.
- De architectuur
van de informatie infrastructuur. Deze architectuur omvat onder meer
de IT-architectuur, die op haar beurt weer de applicatie architectuur,
de gegevensarchitectuur, de architecturen van systeemsoftware, hardware
en (IT-)netwerk bevat. Dit is vooral de architectuur van de IT-er,
en van de IT-architect.
- De informatie
architectuur (ook wel enterprise (information) architecture). Hier
gaat het om het bedrijfsmiddel cq. de productiefactor informatie die
door specialisten als informatie architecten in beeld wordt gebracht
en gehouden. We spreken hier niet over een uit applicaties opgebouwd
informatielandschap. We spreken hier over een breed opgezette uitwerking
van wat de organisatie met haar informatie wil, kan en moet.
Als we onder architectuur
aan de informatievoorziening van de organisatie willen gaan werken,
dan zullen we dus de laatste 2 vorm moeten geven, waarbij de bedrijfsproces
architectuur een feitelijk gegeven is die de context van de informatievoorziening
weergeeft.
Tegenwoordig wordt
ook over corporate architectuur gesproken. Vanuit een bedrijfsmatig
standpunt gaat het daarbij om de architectuur van de informatievoorziening
als geheel. Vakmatig is het logisch om te spreken over de informatie
architectuur en de architectuur van de informatie infrastructuur. Je
kunt de term echter ook nog veel breder uitleggen, waarbij de (deel)architecturen
van alle aspecten samengenomen worden. Dus inclusief IT, informatie,
bedrijfsprocessen, logistiek, personeel, financien enz..
Toch, als je doorvraagt,
wordt de term corporate architectuur meestal niet zo breed bedoeld.
In de praktijk wordt de IT-architectuur bedoeld, aangevuld met de manier
waarop IT-ers naar de bedrijfs-processen kijken. Feitelijk in lijn met
gedachten die bijvoorbeeld Zachman en Tapscott/Caston geïntroduceerd
hebben en door IT-Business architecten vaak wordt aangeduid als business
alignment. Een wel erg smalle opvatting van het begrip, dus.
Als de term corporate
architectuur gebruikt wordt in het kader van de informatievoorziening
zou deze dus de informatie architectuur en de architectuur van de informatie
infrastructuur moeten omvatten. De bedrijfsproces architectuur staat
daar dan naast. Het is echter wel de vraag of de term corporate, “bedrijfsbreed”,
wel zo geschikt is om te gebruiken. Het is natuurlijk maar een naam
en als iedereen er een gelijke uitleg aan geeft zou er geen probleem
zijn. Corporate informatievoorziening architectuur of corporate architectuur
informatievoorziening zou logischer en duidelijker zijn.
Terug naar de stelling:
het zou veel werk zijn. We spreken daarbij dus over organisaties en
hun in-formatievoorziening. Bestaande organisaties hébben een
werkende informatievoorziening. Organisaties kunnen slecht of goed functioneren
en alles wat daar tussen zit en dat geldt ook voor hun infor-matievoorziening.
Een organisatie heeft altijd beelden van haar bestaande informatievoorziening.
Die zijn goed of slecht, breed of smal, afgestemd of niet. Het invoeren
van architecturen informatievoorziening vereist een afgestemde, brede
beeldvorming van een informatievoorziening als geheel. Dat betekent
in de praktijk vaak dat wat we weten vaak opnieuw gegroepeerd moet worden.
Is hergroeperen
veel werk? Soms wel en soms niet. Dat hangt af van wat er al is en hoe
toegankelijk de kennis daarvan cq. de informatie daarover is. Bovendien
is de bereidheid van de mensen die deze kennis cq. deze informatie hebben
om mee te werken van groot belang.
Het eerste probleem
is het vaststellen welke architecturen er zijn, wat ze omvatten en hoe
deze samenhangen. Nemen we de hiervoor genoemde 3-deling, dan gaat het
in feite om het “vullen” van:
- de bedrijfsproces
architectuur. Hier dient de manier waarop in de organisatie (samen)gewerkt
wordt in beeld gebracht te worden.
- de architectuur
van de informatie infrastructuur. Hier gaat het om het in beeld brengen
van oplos-singen die met of zonder IT gerealiseerd zijn, zoals applicaties,
gegevens, de infrastructuur zelf, technisch beheer en beveiliging.
- de informatie
architectuur. Onder deze noemer komen tussen de 20 en 25 onderwerpen
aan de orde, zoals informatievisie en -beleid, functioneel beheer,
functionele beveiliging, informatieplanning, normen/standaards, ICT-beleid
enz.
De hoeveelheid werk
die verzet moet worden om architecturen vorm te geven en in te voeren
is gelijk aan de tijd die nodig is om het bovenstaande in hun onderlinge
relatie afgestemd in kaart te brengen. Dat kan lang duren als je alles
eerst in detail en afgestemd in gaat passen. Dat is echter vaak niet
nodig. Als je weet wat het gaat worden en de belangrijkste delen hebt,
dan heb je in principe voldoende om te starten.
Starten met het werken onder architectuur betekent het in de juiste
structuur onder beheer stellen van de resp. architecturen. In de praktijk
blijkt dat het niet echt uitmaakt of je begint met een minimaal ingevuld
geheel of met iets dat volledig ingevuld is. Een groot verschil is wel
dat een minimale invulling vaak in weken of hoogstens enkele maanden
te realiseren is, terwijl volledig invullen vaak jaren werk met zich
brengt.
Dat compleetheid
op het moment van onder beheer brengen minder relevant is blijkt uit
wat er na het onder beheer brengen gebeurt. Beheren is de start van
een continue verbeteractiviteit. Met snel on-der beheer brengen laat
de organisatie zien en weten dat men menens maakt met werken onder architectuur.
Dat is een erg belangrijk signaal voor de governance van de informatievoorziening.
Het invoeren van
architecturen en het gaan werken onder architectuur in relatie tot de
informatievoorziening hoeft dus niet veel inspanning te kosten. Ongeacht
of een organisatie voor een lange of korte voorbereiding kiest, het
idee is dat de basis, voor én na de start, steeds beter en steviger
dient te worden. Daarbij is weten hoe het er uit gaat zien en hoe e.e.a.
ingezet gaat worden (governance) van veel groter belang dan de precieze
invulling. De stelling is daarmee in principe niet juist.