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).