November 2000: Een E-mail gesprek over Informatiearchitecten

Tussen:

• Edwin Sierat, Projectleider / Bedrijfsanalist bij Aegon
• Steven van ’t Veld, onafhankelijk informatiearchitect bij A/I/M bv

De aanleiding van het navolgende gesprek was de inhoud van de column van Steven van ’t Veld in het vakblad Informatie. De stelling in de column luidde:

“Het is niet te bepalen waar de taak van de informatie architect ophoudt en waar de taak van de IT-er begint.“.

Steven bestrijdt deze stelling en stelt dat juist relatief simpel vast te stellen is waar de scheiding tussen de taken van de informatie architect en de IT-er ligt.

De inhoud van de betreffende column kwam op het volgende neer:

Informatie architecten zijn mensen die in staat zijn om met een organisatie na te denken over de gegevens die informatie zijn voor die organisatie. De informatie architect kan zo vaststellen wat de organisatie met die informatie wil en kan bereiken. Hij/zij is daardoor in staat om goed passende oplossingen, bijvoorbeeld door IT in te zetten, te laten realiseren. Zijn kennis stelt hem/haar in staat om bestekken samen te stellen voor veranderingen die gerealiseerd zullen moeten worden in de informatievoorziening.
IT-ers dienen zich, volgens Steven, bezig te houden met informatie technologie door projectmatig de gewenste veranderingen te realiseren en programmamatig de informatievoorziening te beheren. De veranderingstrajecten zijn vergelijkbaar met het aloude traject van ontwikkelen van applicaties en informatiesystemen. Het bestek is vergelijkbaar met wat we altijd specificaties of de resultaten van een informatie analyse genoemd hebben. IT-ers krijgen het bestek en werken dat verder uit tot een (functioneel) ontwerp van de in te zetten IT-oplossing. Zij zullen deze oplossing zodanig moeten ontwerpen dat de aansluiting met organisatie (de business alignment) en met andere oplossingen optimaal is.

Op deze stelling reageerde Edwin Sierat. Het vraag en antwoord spel dat zich toen ontspon willen wij u niet onthouden. De teksten van Edwin zijn in het navolgende rood gemaakt, de teksten van Steven blauw.

Edwin: Het is natuurlijk altijd moeilijk in een korte column teveel de diepte in te duiken, maar ik vind dat er in deze column toch wel erg sterk versimpeld wordt. Ik denk dat een belangrijk deel van de verwarring terug te voeren is op een definitiekwestie: wat is een IT’er? Zoals in de column beschreven is het een behoorlijk technisch persoon die een rol vervult vanaf het FO t/m de implementatie. Ik zie een IT’er echter als iemand met een (gedeeltelijke) IT achtergrond.
Is dit belangrijk? Ik denk het wel. Namelijk, wanneer mensen met een (gedeeltelijke) IT achtergrond worden gezien met de bril die in de column wordt gebruikt, zal er geen gebruik worden gemaakt van een groot deel van de potentie van IT’ers. Vergeet niet: er zit een énorme diversiteit in de groep IT’ers. Deze varieert van mensen die uit de bestuurlijke informatiekunde hoek komen (en bij wijze van spreken geen letter kunnen programmeren), tot mensen die uit de technische informatica komen en chips kunnen ontwerpen en maken (in principe).
Vooral mensen die uit de bedrijfskundige (of bestuurlijke) informatiekunde/informatica hoek komen zijn ervoor opgeleid om met gebruikers te spreken, in hun taal, en over hun problemen. Zij hebben een achtergrond die soms meer bedrijfskunde en/of economie bevat dan informatica; maar ze komen vaak wel terecht op een IT afdeling, en zijn dus (jouw definitie) IT’ers en dus alleen geschikt om over technische zaken te spreken. Dit is zowel voor de personen zelf, als voor de bedrijven die hen hebben ingehuurd, een slechte zaak.
Ik zou er juist voor willen kiezen om IT’ers in te zetten op die zaken waar ze goed in zijn. Dit is enorm divers, maar bevat zeker alle zaken waarbij analytische vaardigheden een rol spelen. Dus, van architectuur en bedrijfsanalyse tot hardware. Natuurlijk moet de kennis, ervaring en (communicatieve) vaardigheid van de bewuste persoon hier wel voldoende voor zijn.

Steven: Ja, je hebt natuurlijk gelijk. Ik benader dit echter van de andere kant. Wat je in de praktijk ziet is dat er een enorme, haast niet te overbruggen afstand bestaat tussen IT en business. De meeste IT-ers, en dat zijn er ruim 200.000 in Nederland, kijken naar de business in de gedachten van: we hebben een goed product, organisatie gebruik het alsjeblieft. En dat gebeurt vaak niet, of in ieder geval veel te weinig. Men roept ook steeds over een betere Business-IT alignment, waarbij Tapscott/Caston of Zachman aangeroepen worden. Logisch, want zij geven resp. 5 en 36 views op het IT-systeem. De business wordt daarbij neergezet als een "view op het IT-systeem". En dit is nu precies waarom ik een scherpe scheiding zie tussen de informatie architect en de IT-architect. Die komen we ook hard tegen in de praktijk en in de cursussen die we geven.
In ruim 20 jaar praktijk blijken IT-ers soms wel en soms niet open te staan voor niet direct aan (informatie) technologie gerelateerde zaken. Het blijkt vooral voor de harde(re) IT-ers ontzettend lastig te zijn om los van technologie over informatie te praten. Dit heeft mijn mening gevormd dat we het echt over verschillende vakgebieden hebben als we spreken over "informatie" en "IT". Zoals gezegd kent Nederland ruim 200.000 IT-ers. In de praktijk kom ik slechts enkele 10-tallen, misschien ongeveer 100 mensen tegen die zich in informatie hebben gespecialiseerd.

Het zou passen in het jarenlang gehanteerde doorgroeimodel (“je begint als programmeur en groeit via analist/programmeur naar ontwerper, informatie analist en uiteindelijk wordt je manager”) als IT-ers in de loop van de jaren doorgroeien naar informatie architecten. Het blijkt echter steeds weer dat veel mensen de technologie niet los willen of kunnen laten. Onder de bedrijfskundigen zien we dat in mindere mate. Veruit de meeste mensen blijken in eerste instantie opgeleid te worden tot informatie technoloog en het blijkt voor velen vrijwel onmogelijk om de stap van IT naar informatie te maken. Niet onlogisch, want een metselaar wordt ook niet even snel architect.
Wij zien enorme verschillen tussen IT-ers en informatiespecialisten. De informatie architect is niet een ander woord voor informatie analist. Hij/zij dient in staat te zijn een informatie architectuur voor een organisatie als geheel neer te zetten. En daarmee zitten IT-ers en informatie architecten ook gelijk in elkaars vaarwater: als de informatie architect zijn werk goed doet kan het werk van IT-ers teruggebracht worden tot een minimum. Ik heb eens voor het Ministerie van Economische Zaken berekend dat als we tussen de 4000 en 8000 informatie architecten zouden hebben we ongeveer 100.000 IT-ers minder nodig zouden hebben (bij dezelfde werklast, natuurlijk).

Informatie specialisten vinden we onder de IT-ers, maar ook onder de organisatie specialisten, andragologen, AO-ers, materiespecialisten en ga zo maar door. Je hebt gelijk als je zegt dat ze onder de noemer van IT-er gebracht zijn. Door de andere rol die ze vertolken zien we in de praktijk dat ze daar gewoon niet thuishoren.

Dat zie je ook in de diensten die informatie aannemers als softwarehuizen en systeemhuizen leveren. Die hebben een probleem met het ontstaan van het beroep van de informatie architect omdat ze daarmee zelf uitkomen op een echte aannemersrol. Een informatie architect zal immers met de organisatie naar oplossingen zoeken en die zullen ook, en vaak zelfs alleen bij andere aanbieders dan een specifiek softwarehuis gevonden kunnen worden. Daarmee dient het schrijven van een bestek, het werk van de op inhoud gerichte informatie architect, losgekoppeld te worden van de toepassing van IT. Je ziet dan een zeer nette en logische verdeling van werkzaamheden ontstaan tussen de informatie architect en de IT-er. De informatie architect staat daarbij aan de kant van de business, naast de CIO, en helpt die business aan de juiste oplossingen omdat hij/zij weet waar het over gaat in de business. En daarmee staat hij/zij dus "tegenover" de informatie aannemers.

Edwin: Voor een deel ben ik het ook zeker met je eens, voor een ander deel helaas niet. Ik zal in het navolgende geen onderscheid maken tussen een programma (een groep gerelateerde projecten) en een project.
Als ik je goed begrijp zou het bereik van de informatie architect lopen vanaf de architectuur t/m de informatie analyse. Zo snel het naar applicatie gaat neigen zou de IT-er in het spel komen. Deze tweesplitsing is ingegeven door het probleem dat IT-ers niet in staat zouden zijn (of niet geïnteresseerd zouden zijn) om de techniek en de business van elkaar te scheiden.

Steven: dit is niet helemaal de reden. Ik heb in de praktijk gemerkt dat er een enorme afstand bestaat tussen “IT-denkers” en “Businessdenkers” (mensen die alles van Banken, Verzekeringen, Logistiek enz. in organisaties afweten, de materiedeskundigen, de gebruikers). Daar zijn wat proeven mee gedaan. Daarbij zie je duidelijk dat IT-ers de business vanuit de IT benaderen (mooie voorbeelden zijn Zachman en Tapscot/Caston!). Maar de businessdenkers begrijpen die invalshoek vaak helemaal niet. Ze vinden vaak ook niet de tijd om zich voldoende in IT te verdiepen om er voldoende van te kunnen begrijpen. De logische vertaalslag blijkt hier te liggen in het vaststellen welke gegevens informatie zijn en wat een omgeving met die informatie wil. Dat begrijpen, en ik heb dat echt vele keren zien gebeuren, zowel de businessdenkers als de IT-denkers.

Een ander punt is dat ik niet één architectuur zie, maar diverse. Voor informatiekundigen en IT-ers zijn er meestal 3 echt relevant: de bedrijfsprocessen architectuur, de architectuur van de informatie infrastructuur (omvat de IT-architectuur) en de informatie architectuur in hun onderlinge samenhang en alignment. De IT-er kijkt vakmatig naar een steeds groter deel van de informatie infrastructuur en de informatie architect kijkt naar de informatie architectuur. De informatie architect vertaalt tussen business en IT. En vraag me nu niet welk van de beroepen die bij de architecturen horen moeilijker of makkelijker zijn. Volgens mij, en dat zie ik ook keer op keer in mijn praktijk, zijn ze fundamenteel anders en hebben dus elk hun eigen moeilijkheidsgraad.

Edwin: Inderdaad zijn er vele IT-ers die voornamelijk geïnteresseerd zijn in IT gerelateerde onderwerpen. Wat ik echter heel duidelijk zie is dat "IT gerelateerd" langzaam maar zeker verschuift. Tegenwoordig speelt IT een dusdanig grote rol in de bedrijfsvoering van vooral (middel)grote bedrijven dat IT al snel een rol zal spelen in veranderingen in deze bedrijfsvoering. Tevens zijn er steeds meer IT-ers die begrijpen dat niet iedere oplossing een IT oplossing hoeft te zijn, en (niet minder belangrijk) dat vele oplossingen naast een IT component een (vaak veel grotere) organisatiecomponent kennen.

Steven: Helemaal mee eens. Maar nemen ze daar de consequenties dan ook van? In mijn ogen niet. Verzekeren is mijns inziens een ander vak dan IT-specialist zijn. In een van mijn eerdere columns spreek ik over 8 soorten alignment in plaats van alleen over business alignment. Wat ik denk en vind is dat de IT-ers open moeten gaan staan voor andere specialismen en dat zij daar samen mee moeten gaan werken. Niet dat de IT-er een business view en een work view maakt die de business in kaart brengt in termen van IT, want dat werkt op de langere termijn gewoon niet.

Alignment is heel erg belangrijk. Maar juist alignment laat steeds weer 2 of zelfs meer kanten van een medaille samenwerken, waarbij synergie ontstaat. Business alignment zorgt voor de afstemming tussen business en informatie infrastructuur (vooral de IT daarbinnen). Daarmee is gelijk gezegd dat beide elkaar dienen te versterken en dan is het juist ontzettend belangrijk dat de beste IT met de beste business gecombineerd wordt. De praktijk leert echter dat een “koude” confrontatie van deze beide veel en veel te weinig tot goede resultaten leidt en een tussenstap via informatie doet echt wonderen.

Edwin: Hier spelen een aantal problemen. Vele leveranciers van IT-diensten werken met een dubbele agenda. Enerzijds willen ze de klant adviseren over een optimale oplossing, maar anderzijds willen ze hun eigen diensten verkopen. Daarom is het gevaar zeer groot dat wanneer een softwarehuis een informatie analyse of probleemdefinitie uit gaat voeren, de oplossing zal betekenen dat er IT inzet nodig is. Hetzelfde geldt overigens vaak ook voor (niet IT) organisatieadviesbureaus. Hun onderzoek zal regelmatig opleveren dat er inzet van consultants nodig zal zijn. Het klassieke probleem van het "onafhankelijke" advies. Jij refereert hier ook aan, en ik moet het roerend met je eens zijn.

Steven: dit is het toneel van de concurrentie die op dit moment gevoerd wordt. Heel simpel: als je gaat bouwen komt je architect ook niet bij je aannemer vandaan! Een hele simpele regel die in de IT vaak met voeten getreden wordt. Het kan bij aannemers zelfs regel zijn dat hun medewerkers alleen mogen adviseren wat zij zelf kunnen leveren.
Een goede architect kan, in de huidige situatie binnen de IT, aannemers echt goudgeld kosten. In de eerste helft van de jaren ‘90 heb ik eens een grote procurement begeleid. De specificaties waren geschreven door een aannemer. Op basis daarvan werd aangeboden voor een all-in bedrag van f.80 miljoen en het hele traject diende als zeer risicovol aangemerkt te worden. We hebben toen een tussenstap gemaakt. In een ½ jaar hebben we gemiddeld met 1½ mens uitgezocht wat men nu echt nodig had. Toen we daarmee offerte aangevraagd hebben was de prijs ineens gezakt tot f.13 miljoen fixed price, fixed time en we konden praten over fixed quality.
Zo maakt een architect het aannemers natuurlijk wel ontzettend moeilijk. Maar ja, als je dan ziet dat het bedrijfsleven nu gebukt gaat onder de extreem hoge kosten (zoals gezegd eind 2000 gemiddeld 78% van de totale kosten voor exploitatie en dat percentage wordt groter omdat investeringen deze last niet blijken te verlagen!) die de huidige informatievoorziening met zich brengen. Legacy problemen die voor een groot deel omzet voor de aannemers opleveren. Gelukkig zien steeds meer bedrijven de problemen hiervan in en worden wijs. Dat moet ook, want we zijn wel bezig om op dit moment de legacy problemen van morgen te creëren.

Edwin: Een aantal IT-ers blijkt tijdens de definitie fase er erg veel moeite mee te hebben niet meteen een IT oplossing aan te dragen. Dit noem je ook al.

Steven: Ja, en dit is nou zo ontzettend logisch dat het vaak aan de aandacht ontsnapt. De business wil geen gevecht over IT maar wil gewoon geholpen worden de juiste informatie op het juiste moment te hebben en te krijgen. Meer niet. En dat realiseer je niet door te beginnen met over IT te praten. Zorg nou eerst eens dat je weet wat je nou eigenlijk nodig hebt.

Edwin: Klanten vragen van IT adviseurs vaak alleen maar IT advies. Er wordt regelmatig gedacht dat een IT-er per definitie geen kennis kan hebben van de bedrijfsvoering en alleen in staat is om iets te zeggen over programmeren. Dit is natuurlijk onjuist. Zoals ik in mijn 1e reactie al aangaf zijn vele IT-ers gezien hun opleiding en ervaring vaak zeer goed in staat om (door het stellen van de goede vragen) een uitstekende analyse uit te voeren, en hier (in samenspraak) goede adviezen uit te formuleren. Juist daarom ben ik geen voorstander van de strikte tegenstelling IT niet IT.

Steven: misschien wat vreemd gezien het voorgaande, maar ik ben het op dit punt wel met je eens. Ik blijf echter toch een essentieel probleem houden in de trant van “noem alle trouwe viervoeters die blaffen Hond”. Het probleem is dan echter dat we er niet meer achter kunnen komen of we het nu over een Pekinees of over een Rottweiler hebben. De een heeft bijvoorbeeld wel heel andere voeding en verzorging nodig dan de andere. En ik kan je vertellen dat ik weet dat de hoeveelheid voeding echt anders is!
Dit is misschien een wat ruwe vergelijking, maar het is wel wat er in IT-land aan hand is. 10 jaar geleden, bijvoorbeeld, had het VRI 2.500 leden. Die leden zagen samen kans om 3.000 verschillende namen voor hun specialismen in en rond IT op te geven. Als je dan naar Europa kijkt is er een standaard (CEPIS organisatie: EISS) die 43 soorten beroepen (streams) onderkent. Die streams vormen samen weer 9 groepen van echt verschillende beroepsgroepen. We kunnen, volgens mij, niet of nauwelijks over IT-ers in het algemeen spreken, de profielen zijn daarvoor te verschillend.

Wat je volgens mij zegt is, dat onder de noemer van IT-er, mensen allerlei vakken uitoefenen. Dan zijn we het dus met elkaar eens. Als voorzitter van het GIA wil ik het beroep van informatie architect isoleren omdat deze mensen slechts zijdelings met technologie te maken hebben. Ze moeten wel het nodige van IT weten omdat ze met aannemers moeten kunnen praten, maar dat is dan ook alles. Daarom is het erg moeilijk om op die beroepsgroep het label IT te blijven plakken.

Edwin: Samenvattend: IT-ers zijn er in vele vormen, maar binnen de IT groep zijn er mensen te vinden die de diverse analyse rollen binnen programma's (of projecten) kunnen bezetten. Wat hier (zoals overal) wel geldt is natuurlijk dat niet iedereen alles kan (of wil).

Steven: Dit laatste is de belangrijkste reden om de zaken te scheiden. Daarom hebben we bijvoorbeeld ook het VRI-model opgesteld, het model dat nu L_PASO heet. De informatie architect heeft een nogal afwijkend profiel van dat van de andere IT-ers en dat zal op de een of andere manier naar voren gebracht moeten worden (waarmee ik overigens niet wil zeggen dat er geen andere IT-ers zijn met een afwijkend profiel). Het is voor mij nog steeds de vraag of je de informatie architect nu wel of niet als IT-er moet zien. Voorlopig kies ik voor een scheiding om de verschillen helder te kunnen maken.

Edwin: Ten aanzien van de scheiding tussen IT architect en informatie architect; ik zou verwachten dat de informatie architect ook in staat is een (niet-technische) IT architectuur te maken. Ik heb het dan over bijvoorbeeld een applicatie architectuur welke de gewenste bedrijfsprocessen en data mapt op de bestaande applicaties. De technische architectuur (middleware e.d.) is weer een heel ander (sterk technisch) specialisme. Maar misschien is dit alleen een begripsverwarring. Eigenaardig dat de praktijk uitwijst dat er maar weinigen zijn die in staat zijn om IT los te laten bij het kijken naar een bedrijf. Ikzelf zie toch regelmatig (weliswaar niet op architectuur vlak) mensen die ook mee willen (en kunnen) denken over niet-IT oplossingen en problemen.

Steven: De informatie architect dient met een IT architect samen te kunnen werken om een IT-architectuur als onderdeel van een architectuur van een informatie infrastructuur te kunnen maken. Hij/zij kent immers wat het bedrijf echt wil en kan die regels toetsen in de IT-architectuur. Dit is vergelijkbaar met de business specialist die kan samenwerken met een informatie architect over IC en met een IT-er/IT-architect over de inzet van IT.

Edwin: In de column wordt een voorbeeld gegeven over informatiemodellering en databases. Hierbij wordt bijvoorbeeld over de 5e normaalvorm gesproken. Dit is nu juist in mijn ogen een typisch IT begrip. De gebruikers die ik spreek (of heb gesproken) hebben over het algemeen geheel geen boodschap aan een datamodel in het algemeen, en zeker geen genormaliseerd datamodel. Een logisch datamodel gaat vaak nog nèt. Ik zou zelf verwachten (maar geef eerlijk toe dat ik geen informatiearchitect ben) dat er hooguit op logisch niveau over data wordt gesproken. Dit om de aansluiting met de niet-IT-ers te behouden.

Steven: de 5e normaalvorm is juist een heel belangrijke voor gebruikers, hoewel ze dat niet in die termen verteld kan worden. Het gaat daarbij om het elimineren van redundante informatie die alleen voor een deel van onderhanden entiteiten opgenomen dient te worden. Het is toch heel gewoon om vast te stellen dat vroeger alleen voor mannen informatie over de vervulling van hun dienstplicht opgenomen dient te worden? Ergens zal vastgesteld moeten worden dat die gegevens in de organisatie waar we werken informatie is voor de personen die man zijn. En dat is het werk van de informatie architect. Met die kennis kan de informatie architect ook bestekken schrijven.

Een goed informatie architect spreekt niet over normaalvormen, maar past de principes daar achter gewoon toe. Net als dat je bij een verbouwing ook niet over het slaan van spijkers praat, maar over de plaatsen waar deuren moeten komen. Normalisatie is dan ook belangrijke basiskennis voor een informatie architect. Kijk nu bijvoorbeeld eens naar het aanbesteden van veranderingen in de informatievoorziening (procurement). Wil je dat goed doen dan zal aangegeven moeten worden wat een organisatie wil hebben en dat doe je door een goed bestek te schrijven. Een goed uitgewerkt conceptueel informatiemodel is dan hard nodig om veel overbodige zaken te voorkomen. In de praktijk heb ik diverse keren de leveromvang kunnen beperken tot 1/5 of zelfs 1/10 (in termen van geld) op voorwaarde dat er een goed bestek voorhanden was.

De informatie architectuur omvat onder meer al datgene dat je modelmatig over informatie kunt uitwerken. Integraal voor de organisatie, dus je zult moeten oppassen dat je niet in teveel details verzeild raakt. Daarom maken we meestal ook een globaal informatiemodel voor een organisatie als geheel. Als ik me goed herinner bestaat zo'n model voor een verzekeringsmaatschappij uit 5 tot 10 entiteittypen, dus 1 plaatje en 1 of 2 velletjes beschrijving daarbij. Daarmee kun je als organisatie de ontwikkeling van de informatievoorziening in de hand houden en je beleid formuleren.

Edwin: In het begin van de column worden een aantal gevaren genoemd in de richting "voor iemand met een hamer lijkt elk probleem een spijker". De eerste 2 voorbeelden (Cool:Gen en RUP) zijn inderdaad programmeertalen (omgevingen), maar DSDM is toch meer een faseringsmethode. Ik ben het ermee eens dat voordat een bepaalde programmeeromgeving wordt gekozen er een goede afweging moet worden gemaakt (door o.a. de projectleider), en dat het dus niet zo'n goed idee is om een programmeur langs te sturen wanneer het probleem nog niet duidelijk is gedefinieerd. Echter, ik zie zelf niet hoe het hebben van DSDM kennis het definiëren van een probleem tegen kan werken. Hier gebruik je DSDM helemaal niet voor.

Steven: Klopt. Het probleem zit in de benadering van zaken: projectgericht versus programmagericht. Zoals je terecht zegt is DSDM een faseringsmethode. Waar is die fasering voor bedoeld? Het doel is oplossingen te realiseren in een IT infrastructuur (als onderdeel van de informatie infrastructuur). Je start met een probleem en eindigt met ingevoerde IT. Dit op het oog zo duidelijke proces laat juist vele zaken rond dit proces onduidelijk zijn.
Als voorbeeld: stel ik heb een probleem in de afhandeling van hypotheken en een bij de afhandeling van schades. Voor beide wil ik betere ondersteuning met IT. De organisatie geeft opdracht om die oplossingen te realiseren met DSDM of met RUP, RAD, OO enz.. Wat dan meestal gebeurt is dat elk van de problemen langs die weg opgelost wordt. Nu zijn dit problemen waarbij de kans groot is dat delen van de oplossing gelijk kunnen zijn. Of misschien dat één oplossing gemaakt kan worden voor beide problemen. We spreken immers in beide gevallen over administratieve ondersteuning. Dat gebeurt dus meestal gewoon niet. Mogelijk dat men in het begin van het traject nog met elkaar praat en onderkent dat er raakvlakken zijn. Maar als de druk op de projecten gezet wordt gaat ieder snel zijn eigen weg. Met als resultaat dat er applicaties/systemen ontstaan die op zich wel doen wat ze moeten doen maar die nauwelijks integreerbaar zijn. Waarom? Vaak door hele simpele problemen: de ene applicatie werkt met een andere veldlengte dan de andere, de een heeft voor andere IT gekozen dan de ander, de een gebruikt een andere manier van afronden van getallen dan de ander en ga zo maar door. Dit soort problemen leggen de basis die de gemiddelde kosten van de exploitatie 78% van het totale budget laten zijn. Er zullen immers allerlei conversies gemaakt moeten worden om informatie uit te kunnen wisselen. Verschillende trajecten leveren vrijwel altijd een andere alignment met de business op en die dient dan vaak bijgesteld te worden. En dan spreken we nog even niet over data warehousing, waarbij we de systemen "leeg" zullen moeten halen en de vaak onvergelijkbare inhoud bij elkaar moeten gaan optellen.

Informatie architecten weten dat er in totaal tussen de 20 en 25 onderwerpen zijn die in een specificatie cq. een bestek uitgewerkt dienen te worden. Door die onderwerpen integraal op te zetten voor een organisatie voorkomt zij/hij een grote hoeveelheid werk. Omdat er vrijwel nooit vanuit een greenfieldsituatie gewerkt kan worden zal gestart moeten worden met het inpassen van wat je hebt. En dan voorzichtig uitbreiden en verbeteren. Zo ontstaat een “kennisbank” die we informatie architectuur noemen. In deze kennisbank staat wat we nodig hebben om de bestekken te kunnen schrijven en die hoeven we dus niet steeds weer te bedenken in eerste fasen van onze projecten. We maken dan dus bestekken aan de hand van wat we al wisten en onder beheer gesteld hadden. Zo groeit onze eerste projectfase langzamerhand van een analyse fase naar een toepasbaarheidsfase. Veel goedkoper, met de garantie dat de te ontwikkelen applicaties ook inderdaad passen.
Zo komen we terug op de initiële vraag dat projectmatig werken start bij het functioneel ontwerp en daarom zie ik daar dus de start van het werk van IT-ers. Daarmee worden methoden als DSDM dus wel korter, net als het oude SDM. Daarmee zullen ook methoden als RAD gebruikt kunnen worden omdat we al weten wat we willen hebben en we daar "alleen nog" vorm aan hoeven te geven. Dit zijn de eerste besparingen, en dan spreken we nog niet over de besparingen die dit op gaat leveren in de exploitatie fase.

Kort en goed: bij een programmamatig beheerde informatie architectuur kan het projectmatig ontwikkelen van oplossingen sterk bekort en in de hand gehouden worden. Die denkwijze past bij organisaties die wat volwassener zijn en bijvoorbeeld in CMM fase 2 of 3 verkeren.

Edwin: Nog een kleinigheidje t.a.v. DSDM. DSDM kan ook worden ingezet bij bijvoorbeeld BPR trajecten. Hierbij zal regelmatig geen enkele IT oplossing nodig zijn, of anders in ieder geval zal de oplossing slechts een beperkt deel van het totaal vormen. Het is dus zeker niet zo dat DSDM per definitie betekent dat er een IT oplossing moet komen. Verder kunnen ook programma's m.b.v. DSDM worden uitgevoerd (zie de White Papers). Ik zou DSDM zeker niet als IT methode willen definiëren, maar meer als een denktrant / werkwijze welke algemeen bruikbaar is (kan zijn).

Steven: Prima. Ik zie alleen niet hoe je onder 1 bepaalde methode dit soort heel verschillende zaken zou moeten combineren. Je definieert de bedrijfsprocessen toch immers (in goede samenspraak met alle betrokkenen, dus ook de IT-ers) los van welke oplossingen dan ook. Ik zie ook veel te veel dat onder een noemer als DSDM IT-ers de bedrijfsprocessen onderhanden nemen. Vaak worden bedrijfsprocessen alleen als structuur gezien die door organisatie-ingenieurs uitgewerkt kunnen worden zonder rekening te houden met minder structurele zaken als mensen, macht, cultuur enz.. Tot nu toe hebben haast alle methoden het uiteindelijk niet of nauwelijks gered. Denk bijvoorbeeld aan het uiteindelijke fiasco van SDM. Het samenvoegen van allerlei elementen tot een methode is gevaarlijk. Zoals een goede collega van me in het begin van de jaren 80 schreef: de methode doet het niet.

Edwin: Bij RUP e.d. ligt dat alweer wat anders. De modellering waar RUP op leunt (UML) is toch voor het grootste deel een IT modelleringtechniek die slechts weinige niet-IT-ers zal aanspreken.

Steven: OK, maar pretenderen de RUP- cq. UML-specialisten dat ook? Volgens mij zien ze het als een volgende, maar dan echte common business oriented language die de muren gaat slechten. Die beweging hebben we al zo vaak gezien.

Edwin: T.a.v. het schade en hypotheekprobleem ben ik het met je eens dat het bijzonder moeilijk blijkt dergelijke zaken integraal aan te pakken. Hierbij zou een goede architect zeker een rol kunnen spelen.

Steven: toch is zo’n probleem in essentie vrij simpel. Verzekeringsbedrijven hebben maar een paar soorten informatie en als je die maar voldoende in de gaten houdt kom je een heel eind. Het gaat altijd om personen, in alle soorten en maten, die in allerlei rollen in relatie staan tot producten en overeenkomsten. Ik heb zo langzamerhand heel wat banken en verzekeringsbedrijven gezien en als je dit soort simpele uitgangspunten in de achtergrond houdt ben je in staat om goed te gaan sturen. Vereenvoudigen is het motto, met als resultaat grote besparingen.
Waarschijnlijk ben ik te lang architect om niet in dit soort instrumenten te denken. Ze werken gewoon echt als ze goed ingezet en gebruikt worden. Op die basis werk ik ook veel en graag samen met andragologen, psychologen, organisatiekundigen enz.. Het probleem verplaatst zich dan op een moment van de dingen zelf naar de wil van de organisatie om er iets mee te kunnen doen. En aan dat laatste schort het vaak.

Edwin: De tegenstelling die ik echter regelmatig heb gezien is de keuze tussen korte en lange termijn. De business wil meestal liever snel een inefficiënte oplossing, dan langzaam een architectuurtechnische lange termijn oplossing.

Steven: Ik denk niet dat je er zo over moet denken. De informatie architect is immers een adviseur van de CIO. Als de informatie architect zijn organisatie kent kan hij de CIO aangeven wat de consequenties zijn van bepaalde oplossingen. Het is dan vrij aan de CIO om te kiezen om dat soort oplossingen wel of niet te laten instromen. Hij/zij kan er dan ook randvoorwaarden aan stellen, zodat de zaak niet explodeert.
Als live voorbeeld: de hypotheekadministratie loopt de mist in omdat deze zwaar verouderd is en de mensen die er mee konden werken plotseling vertrekken. Je kunt niet zonder, dus je moet wat. Nu is er een oplossing die de hypotheekadministratie binnen korte tijd goed op poten zet. Consequentie is dat deze oplossing niet goed aansluit bij de rest van de legacy. De CIO heeft besloten om dit toch te doen onder de voorwaarde dat er geen aansluitingen gemaakt gaan worden tussen dit nieuwe en de oude systemen. Waarom: het kost teveel om ze te maken, het levert teveel onderhoud op en het maakt beslissingen om andere systemen te vervangen haast onmogelijk. Tegelijk met deze businessenabler wordt een traject opgestart om de administraties structureel onder handen te nemen. Kost wel veel meer, maar de hypotheekbusiness blijft draaien en daarmee blijft het bedrijf overeind. Zo maar een voorbeeld van wat je kunt doen als je weet wat de consequenties zijn en daar kan de informatie architect zijn werk doen. Ik geloof dan ook niet in wat een voor mij bekend bedrijf laat doen rond architecten: ze laten ze maar praten. Een architect dient te weten en te kunnen handelen. Praten alleen levert James Martin-achtige geldverslindende papierstapels op, en niet of nauwelijks voordeel.

We kunnen ervan uitgaan dat iedere organisatie een informatie architectuur heeft. Deze is vaak nauwelijks herkenbaar en dus niet hanteerbaar. Breng er orde in en je kunt gaan sturen. Bijvoorbeeld op de manier die ik net aangaf. Je ziet dan ook dat beleidsvorming, functioneel beheer, change management, informatieplanning enz. op zich simpele activiteiten worden. Zo simpel dat een aantal bedrijven op dat punt tijd vragen om na te denken omdat de veranderingen dan wel groot worden voor het personeel. Maar we zitten dan ook in CMM fase 2 of 3.

Edwin: Dit wordt denk ik helaas ook veroorzaakt door architectuur projecten die verkeerd zijn gelopen. De paar grote nieuwbouw projecten (onder architectuur) die ik heb gezien leverden uiteindelijk niets op waar het bedrijf wat aan had. Het bleef bij allerlei discussies over generieke oplossingen, maar er werd niets opgeleverd. Na een dergelijke ervaring kan ik me goed indenken dat een directie nog eens heel hard na gaat denk alvorens een 2e keer toestemming te geven voor een dergelijk project.

Steven: QED: wat te bewijzen was. Je noemt het onder architectuur ontwikkelen en tegelijk is er niets veranderd sinds SDM. Onder architectuur werken heeft weinig of niets te maken met zweverig blijven kletsen, zoals veel organisaties dat zien. Daarom hebben informatie architecten altijd een schat aan ervaring en kunnen ze daarmee waarde toevoegen. Bedrijven betalen anders voor onnutte resultaten en daar heb je inderdaad niets aan.

Edwin: Op zich natuurlijk erg zonde, want het goed toepassen van architectuur gedachten kan wel degelijk geld besparen, en zelfs niet alleen op de lange termijn. Hierbij moet echter de balans worden gevonden tussen pragmatisme en maximale (maar bijzonder lastige) oplossingen.

Steven: Ik denk dat commitment van het management en de wil om structureel anders te gaan werken nog veel belangrijker is. Het is lastig om dit in bedrijven te kunnen realiseren. Dat is trouwens ook de belangrijkste reden waarom ik samenwerk met sociaal en psychologisch geschoolden.

Edwin: T.a.v. jouw eerdere stuk over de specificatiefase; ik denk ook dat een goede architectuur zeker kan ondersteunen in de informatie analyse. Hier kan (zeker in complexe organisaties met veel processen / data / applicaties) behoorlijk bespaard worden. Ik denk echter dat het uitwerken van de informatie analyse beter gedaan kan worden door iemand die ook in het vervolgproject een rol speelt.

Steven: Ben ik gedeeltelijk met je eens. Ik zie dus 2 niveaus van informatie architect. De hoofd architect zal de algemene "kenniskast" beheren en de informatie architecten vullen voortrajecten in op basis van wat die kast bevat. Daarna zullen zij het totale traject begeleiden.
Ben je bekend met het V-model? Met die begeleiding kun je ervoor zorgen dat de uitvoering in de 2e poot steeds goed aangehouden wordt tegen wat eerst vastgesteld is door de architect. Dit voorkomt veel testen en zal de acceptatie veel hoger maken. Net als in de bouw zie ik de architect ook zeker als begeleider en auditor, anders werkt het gewoon niet. Maar die architect zal zelf ook (functioneel) gecontroleerd worden door de hoofd architect en daarmee door de CIO.

Edwin: In mijn ervaring is de meest voorkomende reden dat projecten niet in hun opzet slagen een te grote afstand tussen de klant en de IT afdeling (gegeven dat het probleem een IT oplossing heeft).

Steven: Ja, maar waarom zou je nou vooraf moeten bedenken of iets wel of niet een IT oplossing kan krijgen? En wat te doen als iets een IT oplossing heeft die omgezet moet worden naar een niet-IT oplossing? Of andersom? Mijn ervaring is simpel: weet eerst waar je het over hebt voordat je aan oplossingen gaat denken. Dat is, naar mijn ervaring, echt veel simpeler dan je zou verwachten. En met een kleine afstand naar de business/klant!

Edwin: Wat regelmatig gebeurt is dat een probleem of "over de muur (naar IT) wordt gesmeten", of "door IT over de muur wordt getrokken". In het 1e geval wil de klant er eigenlijk niet mee lastig worden gevallen, in het 2e geval weet IT "het zelf wel". Beide situaties leveren natuurlijk een verkeerd eindresultaat op, al ligt het alleen maar aan de slechte acceptatie door de klant.
Het bovenstaande is ook een risico van het aanbrengen van een soort buffer (de informatie architect) tussen de klant en IT. Wanneer IT alleen met de architect praat, maar niet met de klant bestaat verder nog het risico dat de klant de informatie architect als een deel van IT gaat zien, een positie die niet echt wenselijk is. Verder is mijns inziens een gedegen kennis van de business essentieel voor het maken van een goede IT oplossing (louter technische projecten daargelaten). Dit zou natuurlijk ook goed kunnen komen wanneer de informatie architect FO's gaat schrijven en programmeurs gaat begeleiden, maar dit lijkt me ook niet de bedoeling.

Steven: Helemaal mee eens. Dat moet dan ook absoluut niet gebeuren. Een informatie architect is dan ook geen lijn verantwoordelijkheid! Hij of zij dient, idealiter, toegevoegd te zijn aan een CIO (bij voorkeur een raad van bestuur/directielid voor Informatie en Communicatie) in de business. Zij/hij dient de business te helpen in de onderhandelingen met de oplossers, niet ertussen te gaan staan. Dat is nu juist waar het essentiële verschil ligt tussen wat de informatie architect doet en wat de IT-er uitwerkt. De informatie architect staat vooral de business terzijde. Hij/zij weet wat wel en wat niet kan en laat zich, indien nodig, ompraten. Maar voordat dat het geval is dient de grote ervaring te spreken en zullen consequenties van veranderingen in de aanpak en de visie door de business gezien en geaccordeerd moeten worden. Zo’n muur is dodelijk en niet nodig, tenminste als je de juiste aanpak hanteert.

Edwin: Ik denk eerder dat de informatie architect een belangrijke rol kan spelen in het voortraject; in de positionering van de oplossing en de besluitvorming of hier één (of meer) projecten nodig zijn om het probleem op te lossen. Hierbij bewaakt de informatie architect de architectuur aspecten terwijl de bedrijfsanalist kijkt naar bedrijfsvoeringsaspecten. De bedrijfsanalist is goed in staat om vanuit het bedrijf en de klant te redeneren en kan door de combinatie van analyse vaardigheden en bedrijfskennis hierbij goed adviseren. Eventueel kan hierbij ook een (externe) organisatieadviseur worden betrokken.

Steven: Volledig mee eens. Maar dan zie je dus ook dat de vaardigheden en kennis van de informatie architect drastisch anders zijn dan die van de IT-ers. Vorig jaar hebben we in het kader van opleidingen structureel onderzoek gedaan naar deze aspecten. Het beeld dat daarbij ontstaan is van de informatie architect is heel helder, maar ook heel anders. Zoals eerder gezegd hebben we uitgerekend dat we met voldoende architecten 50% minder IT-ers nodig zullen hebben en dat feit hebben we teruggevonden. Als de puzzelstukjes op hun plaats vallen bewijs je in feite die berekening.

Edwin: Hierbij zal de bestaande architectuur natuurlijk goed kunnen ondersteunen. Verder zal (bij de vertaling naar projecten) a.d.h.v. de architectuur moeten worden bekeken hoe de gekozen oplossing kan worden ondersteund met behulp van de architectuur. Eventueel moet de architectuur worden aangepast om de vernieuwingen in de bedrijfsvoering te reflecteren.

Steven: Je spreekt hier volgens mij over de informatie architectuur, niet over de architectuur van de informatie infrastructuur. Dan ben ik het daar mee eens. Dat zijn verschillende dingen, zelfs met een volledig verschillend ritme.

Edwin: Daarbij moet ook een grove aanzet tot een informatie analyse worden gegeven. Deze aanzet kan dan worden opgepakt door een informatie analist. Bij het uitwerken van de informatie analyse zullen dan ongetwijfeld nog architectuur punten aan de orde komen waarbij de architect uitkomst moet brengen. Verder zou de architect gedurende het gehele project (in de Stuurgroep) een vinger aan de pols moeten houden om te waarborgen dat nog steeds de goede richting wordt gevolgd.

Steven: Dit is wat we uitgevonden en ingevuld hebben. De hoofd informatie architect zal de staf zijn van de CIO terwijl de informatie analisten als informatie architect onder begeleiding van die hoofd architect zaken uitwerken, al of niet in projecten. Zo kunnen junioren doorgroeien naar senior en principal.

Edwin: Ik heb het hierbij niet over de vraag of de informatie architect en/of informatie (of bedrijfs)analist bij IT hoort. Dit is een organisatievraag die mijns inziens los staat van de achtergrond van de persoon die de rol vervult.

Steven: Deels mee eens. De organisatie moet het natuurlijk zelf weten, maar als je naar het vak kijkt is het duidelijk aan te geven. Werken met IC is kompleet anders dan het werken met ICT. Werken met IC is helder voor de business, werken met ICT kan er helder door gemaakt worden zonder dat de creativiteit van de I(C)T-er hoeft in te boeten. Nee, de creativiteit kan de hoofdlijn worden omdat men weet wat men wil. Maar dan komen we wel in CMM fase 3 of hoger terecht.

Edwin: Goed, ik denk dat dit een redelijke opsomming is van de voornaamste problemen die ik met de uitwerking van de stelling heb. Vooral de polariserende werking van het onderscheid tussen informatie architect (vaak in mijn optiek een IT-er met bedrijfskundige kennis en ervaring) en IT-er lijkt mij een slechte zaak.

Steven: Een goede zaak is dat zeker niet, dat ben ik met je eens. De praktijk laat echter een soort eenheidsworst zien, waarbij alles onder de noemer van IT-er wordt geschoven. Gezien de andere werkzaamheden en daardoor ook opleiding van IT-er en informatie architect zal toch ergens een onderscheid gemaakt moeten worden. Architecten horen met aannemers samen te werken, ze horen hun taken niet te vermengen. Enige mate van polarisatie is kennelijk nodig om dit te onderkennen. Het zij zo.