Het begrip informatievoorzienings-architectuur (iv-architectuur) is geen trend meer die wel zal overwaaien. Het is inmiddels een serieus instrument om na menige groeistuip en fusie de informatievoorziening weer op één lijn te brengen met de organisatiedoelen. Menige organisatie investeert dan ook aanzienlijke bedragen in het in kaart brengen van haar huidige én (voorspellenderwijs) toekomstige iv-architectuur.
De vraag is of het nu wel zo nodig is om de informatievoorziening op orde te brengen met behulp van een iv-architectuur. Zo ja, kan een organisatie dit dan zelf doen of is het beter om het te laten doen? De praktijk laat zien dat het opstellen van een iv-architectuur veelal uitsluitend een aangelegenheid is voor externe dienstverleners. Voor een in-house informatiearchitect zijn namelijk nauwelijks praktische en snel toepasbare methoden gepubliceerd. Allereerst: is het überhaupt wel nodig om stevige bedragen te investeren in het opstellen van een iv-architectuur? Een ultrasnelle architectuurscan maakt deze noodzaak helder. Vergelijk onderstaande standaard structuren van de informatievoorziening:
Stovepipe-architectuur. Eén van de meest voorkomende bestaande structuren is die, waarbij een onderneming beschikt over meerdere, functioneel identieke informatie systemen. Deze architectuur ontstaat vaak door fusies, waarbij de totale informatievoorziening van de voormalige fusiepartners blijft voortbestaan. Ook kan deze architectuur het gevolg zijn van het welbegrepen eigenbelang van zelfstandige business units, die voor hun informatiefuncties niet afhankelijk willen worden van andere units binnen de onderneming. Elke unit ondersteunt zijn waardeketen daarom het liefst geheel zelfstandig met eigen informatiesystemen waardoor het nauwelijks mogelijk is om, bijvoorbeeld, een eenduidig klantbeeld op te bouwen.
Ravioli-architectuur. Gebruikers hebben vaak uit arren moede zelf honderden noodoplossingen in elkaar geknutseld. Al deze systeempjes zijn eens gestart als een ‘tijdelijke’ ondersteuning, bedoeld om de tijd te overbruggen waarin ict de gewenste functies in de basisinformatiesystemen zou onderbrengen. Inmiddels is dit uitgangspunt lang vergeten en zijn de systeempjes in de bedrijfsvoering onmisbaar geworden. Om alles nog gecompliceerder te maken, wisselen de maaksels op ontelbare manieren informatie met elkaar uit. Deze interfaces zijn bij voorkeur nooit gedocumenteerd.
Puist-architectuur. De ict-afdeling heeft gedurende decennia elk probleem opgelost door er een ad-hoc uitbreiding op het bestaande systeem voor te bouwen. Het oorspronkelijke informatiesysteem, vaak zonder twijfel van huis uit een ‘work of art’, is geheel verdwenen onder een dikke laag aanpassingen en uitbreidingen. Een Puist-architectuur is een meesterlijk instrument om beheerkosten te verhogen, werkgelegenheid te garanderen en elke mogelijkheid tot verandering effectief te torpederen.
Caterpillar processing-architectuur. Sinds vele decennia is de verwerking van gegevens in de onderneming gestoeld op een complex samenspel van batch-processen, die gegevens van het ene systeem naar het volgende overhevelen. Onderweg worden gegevens aangepast, samengevoegd en ontrafeld totdat slechts een handvol bevoorrechten nog weet wat er gaande is. Het primaire bedrijfsproces van de onderneming kan slechts met de grootste moeite aangepast worden. Als gevolg van kostbare aanpassingen in het verleden zijn deze processen bovendien voorzien van diverse mysterieuze zijpaden waar informatie spoorloos weet te verdwijnen en klanten dagenlang aan de lijn worden gehouden: ‘uw aanvraag heeft onze volle aandacht’.
Infrastructure dynamics-architectuur. De onderneming heeft in de loop van jaren een scala aan systemen op steeds weer een ander computerplatform ontwikkeld, of pakketten aangeschaft die door specifieke wensenpakketten een pluriformiteit in de onderliggende infrastructuur veroorzaakten. De oorzaak is vaak dat een opeenvolgende reeks managers vanuit uitgesproken voorkeuren bij elke nieuwe ontwikkeling een nieuwe inrichting heeft doorgedrukt. Het resultaat is een gedurende jaren opgebouwde bonte verzameling van infrastructuren, die bij voorkeur zo min mogelijk ‘compatibel’ zijn. Een eldorado voor leveranciers, die bij de voortdurende stroom van storingen de oorzaak steeds bij de concurrent weten te leggen.
Indien een informatievoorziening zich laat vergelijken met één van deze vijf ‘standaard structuren’ of een mix hiervan, dan is daarmee het licht voor een architectuurtraject op donkergroen gezet.
Zelf doen of laten doen?
Op dit moment zijn veel organisaties bezig met het opstellen van een iv-architectuur waarbij meestal externe expertise wordt ingehuurd. Het resultaat is zéker een degelijke iv-architectuur. Echter, het risico bestaat de invoering te zien als een project. Een eenmalige exercitie die moet leiden tot de implementatie van de plannen. Deze route gaat niet over rozen. Hoge ambities, te kleine budgetten en een tekort tijdsbestek voor de implementatie belemmeren in grote mate het boogde succes. Zo is iv-architectuur niet bedoeld!
Het nadenken over een iv-architectuur moet structureel als proces in de organisatie zijn ingebed, wil het succesvol zijn. Een probleemsituatie die in de loop van jaren is ontstaan, kan niet met één architectuur-project worden opgelost. Een succesvolle implementatie verloopt via meerdere stappen, waarbij het ook nog eens mogelijk moet zijn te kunnen anticiperen op de telkens weer veranderende wereld die weer nieuwe eisen aan de informatievoorziening stelt. Binnen de organisatie is daarom een informatiearchitect nodig, die op procesmatige wijze de iv-architectuur structureel inbedt, zodat ict zijn belofte als strategisch middel voor de bedrijfsvoering daadwerkelijk kan inlossen.
Hoe nu verder als men zelfstandig via een doe-het-zelf-exercitie het opstellen en implementeren van de iv-architectuur als proces structureel in de organisatie wil inbedden? De informatiearchitect moet dan kunnen beschikken over een methode die direct toepasbaar is en die voldoende handvatten biedt om tot een gedegen resultaat te komen. Als de methode beschikbaar en herhaalbaar is kan de informatiearchitect de focus verleggen naar het resultaat en hoeft zich niet te bekommeren over de aanpak.
‘Openbare’ methode
Sinds mei 2005 is een nieuwe ‘openbare’, voor iedere toepasbare methode beschikbaar: Scorpio. Scorpio beschouwt iv-architectuur als de pen van een scharnier die de bedrijfsvoering en de informatievoorziening op flexibele wijze verbindt (zie figuur 1).
Deze methode kent op hoofdlijnen twee processtappen. De verbinding naar de bedrijfsvoering wordt gelegd door het alignmentproces en vormt de verankering van de toekomstige iv-architectuur met de strategie en processen van de organisatie. De verbinding met de huidige informatievoorziening wordt gelegd via de migratieplanning. De migratieplanning is daarmee het verbindende proces tussen heden en toekomst (zie figuur 2).
Hiermee anticipeert de methode op het langcyclische organisatie-strategieproces en anderzijds op de kortcyclisch veranderende wereld van de ict. Bepalend voor het inzetten van de verandering is de huidige situatie (de operationele architectuur) die in elk plateau weer als vertrekpunt wordt genomen voor het te bereiken volgende plateau. De plateau-gewijze implementatie geeft de organisatie de ruimte te anticiperen op voortschrijdend inzicht.
Frank Boterenbrood, Jeroen Kurk en Jan Wijnand Hoek
Scorpio
Scorpio wordt beschreven in het boek ‘De informatievoorzienings-architectuur als scharnier – van strategie naar informatievoorziening’ (ISBN 9039523363). Het beschrijft de route die leidt van de strategie van de organisatie naar de informatie-voorzieningsarchitectuur aan de hand van een gedetailleerd stappenplan, modellen, technieken en basisformulieren. Verder zijn best practices opgenomen en aanbevelingen voor het toepassen van de methode. Kortom: de methode voor de echt zelfstandige informatiearchitect.
