Maart
2001: Takenpakket van de informatiearchitect en de IT-er
Deze maand een zeer
veel gehoorde misvatting rond de taken de informatie architect en IT-ers:
---
“Het is niet te bepalen waar de taak van de informatie architect
ophoudt en waar de taak van de IT-er begint.“
---
Fout. Onjuist. Als
je verder doordenkt is dit juist erg simpel! En er is verder doorgedacht.
Dit is typisch een
stelling voor een IT-er. Hij komt voort uit de angst dat hij of zij
het “leuke werk” kwijt zou raken als de stelling waar zou
zijn. Het is immers best leuk om met een toekomstige gebruikers te praten
over wat ze willen en wat je allemaal voor ze kan doen.
Het is ook heel
gevaarlijk. Want als een Java programmeur gaat praten met een gebruiker,
dan zal hij proberen het met internet en Java op te lossen. En een Cool:Gen
gebruiker zal het met Cool:Gen proberen, een Rational Unified Process
specialist met RUP, een Dynamic Systems Development Method specialist
met DSDM en ga zo maar door. Soms kan dat ook wel, maar vaker zijn het
gemiste kansen. Want wie zegt nu dat deze IT methoden en hulpmiddelen
de beste oplossing bieden? Erger, wie weet nu vooraf of deze IT aansluit
bij andere oplossing binnen de informatie infrastructuur? Dat zijn grote
risico’s die tot hoge beheerkosten en tot legacy problemen gaan
leiden.
Het meest simpele
voorbeeld van een goede scheiding in de taken van de informatie architect
en de IT-er is rond informatie modellering en databases. In een informatie
model is de structuur van de in-formatie in kaart gebracht in termen
van entiteittypen, feittypen en constrainttypen (in lijn met de
ISO standaards[1] rond Conceptual Schemas). Een (conceptueel) informatiemodel
brengt met de structuur van feittypen en hun beperkingen de gegevens
in kaart die informatie zijn voor de omgeving waar we in werken. Als
die structuur goed opgezet wordt dan wordt vrijwel automatisch tot in
de 5e of een nog hogere vorm genormaliseerd.
Een informatiemodel
heeft weinig of niets te maken met IT. De laatste 20 jaar is steeds
weer en steeds beter bewezen, dat, indien het informatiemodel goed opgezet
is, er een optimaal voorstel voor de inrichting van een database gegenereerd
kan worden. Met een goed informatiemodel is gegevensmodellering dan
ook volledig overbodig: het uitgenormaliseerde entiteit-relatie (ER)
model of entiteit/attribuut relatie (EAR) model wordt immers gegenereerd!
Wat vaak (nog) niet of niet volledig au-tomatisch kan is het optimaal
inrichten van de database. Oracle heeft nu eenmaal een andere opzet
dan Sybase, Access en andere DBMS-en en elk zal op een andere manier
geoptimaliseerd moeten worden.
Als de informatie
architect een goed informatiemodel opgezet heeft is de inrichting van
de IT ook puur de inrichting van de IT. Je weet immers wat je hebben
wilt en de IT zal er voor moeten zorgen dat het dat ook biedt. Bovendien
zal de informatie architect zijn conceptuele informatiemodel zo opzetten
dat zij/hij dat makkelijk kan uitbreiden. Hij zal immers precies weten
wat bijvoorbeeld de overeenkomsten en verschillen zijn tussen prospects,
klanten, afnemers, debiteuren, crediteuren en medewerkers (het zijn
immers allemaal (rechts- of natuurlijke) personen). De IT-er, in dit
geval de database specialist, hoeft die kennis alleen maar over te nemen
en de in te zetten IT goed in te richten.
Eenzelfde verhaal
kan verteld worden rond functies en applicaties. We weten al sinds jaar
en dag dat we functionaliteit in termen van functies uit kunnen schrijven.
Ed Yourdon cs., Mats Lundeberg (IS-AC), IBM e.v.a. hebben jaren geleden
al technieken als resp. DFD’s, I-schema’s en (H)IPO’s
voorge-steld om dit te doen. Mits goed gebruikt kun je daarmee de door
een organisatie gewenste functiona-liteit in stukjes opknippen en per
stukje aangeven welke eisen, wensen, randvoorwaarden en uit-gangspunten
men wenst. Zoals gezegd: als je deze technieken goed toepast. Er zijn
ook mensen die deze technieken als een soort programmeertechnieken inzetten
en dat is eigenlijk niet de bedoeling.
Applicaties zijn
afgeronde hoeveelheden IT die een bepaalde functionaliteit aan gebruikers
bieden. Je zou ERP-software of HRM-software als twee applicaties kunnen
zien. Deze applicaties zijn echter zo complex dat ze uiteenvallen in
vele kleinere applicaties die elk wel een afgeronde hoeveelheid functi-onaliteit
aan gebruikers bieden, zoals het doorvoeren van bepaalde mutaties of
het aanmaken van een rapport. De functionaliteit die applicaties bieden
is vaak uit te drukken in één of meer functies. En dat
is waar de informatie architect en de IT-er elkaar tegenkomen. De informatie
architect zal met de organisatie spreken over de informatiebehoefte
en de daaruit af te leiden functionaliteit terwijl de IT-er één
of meer van de functies omzet naar applicaties die gebruikt kunnen worden.
Het aardige daarbij is dat als je goed in de gaten houdt welke applicaties
welke functies bieden je ook kan zien waar overlap in functionaliteit
zit. Hoeveel organisaties hebben immers niet op 20 plaatsen tegelijk
functio-naliteit om informatie over klanten bij te houden? Het zou fijn
zijn als je weet waar dat gebeurt zodat het eerstvolgende IT-project
rond datawarehousing niet weer voor verrassingen komt te staan.
We hebben in 2000
eens echt goed uitgezocht wat bij de taken van de informatie architect
hoort. Gaandeweg dat onderzoek werd het vermoeden steeds meer waarheid
dat er wel degelijk een hele duidelijke scheiding in taken te maken
is. Er werden zelfs aspecten duidelijk waarvan je misschien helemaal
niet verwacht dat ze duidelijk worden. Zo bleek functioneel beheer een
plaats te hebben binnen het, veel bredere, beheer van de informatie
architectuur. We kunnen precies aanwijzen waar functionele uitspraken
rond beveiliging thuishoren. Informatieplanning als een echt plan kreeg
een hele logische plaats, evenals visie en beleid op informatie en op
ICT. En zo kan ik nog wel even doorgaan.
Daarom is een zeer
goede scheiding aan te brengen tussen de taken van de informatie architect
en de IT-ers. Als je er goed en structureel over nadenkt blijken de
punten van zorg van voorheen alle-maal op hun plaats te vallen. Tenminste,
wij zien geen punten meer die niet op zijn plaats vallen (maar dat kan
natuurlijk onze beperking zijn en wij dagen u natuurlijk graag uit om
ons ongelijk aan te tonen).
Resultaat is wel dat de taak van de IT-er zich gaat specialiseren op
de inzet van IT. Projectmatig zal de IT-er aan veranderingen werken,
te beginnen bij het functioneel ontwerp van de IT binnen het door de
informatie architect opgezette kader en te eindigen bij de invoering
en acceptatie van de IT-oplossing. Programmamatig zal de IT-er aan applicatie
en technische beheer werken. De informatie architect sluit daar op een
programmamatige basis op aan als intermediair tussen de organisatie
en de IT-ers.
Zoals eerder besproken
in de stellingen 3 en 9 zou de verhouding tussen informatie architect
en IT-er tussen de 1 op 20 en 1 op 50 liggen. Voldoende informatie architecten
zouden dan de inzet van tus-sen de 50.000 en 100.000 IT-ers bij dezelfde
werklast overbodig maken. Jammer dat er in Nederland maar enkele 10-tallen
informatie architecten zijn.
Voetnoot:
[1] ISO
technisch rapport TR9007 rond conceptual schemas en de nieuw verwachte
ISO/IEC standaard
FCD 14481 t.a.v. Conceptual Schema Modeling Facilities (CSMF).