Voor de uitvoering van een architectuurreview zijn inmiddels

Het toetsen van architectuur bij de Rabobank Ervaringen en aanbevelingen vanuit de praktijk Hans Bielok en Arjan Uittenbogerd Bij veel bedrijven is het belang dat wordt gehecht aan de architectuur van de informatievoorziening de afgelopen jaren sterk toegenomen. Dit komt omdat bedrijven voor de ondersteuning van hun bedrijfsprocessen te maken hebben met een complex ICT-landschap, waarvan het beheer lastig is en dat vaak ook hoge kosten met zich meebrengt. Een goed doordachte architectuur met duidelijke regelgeving die in de praktijk strak wordt nageleefd is één van de hulpmiddelen om de complexiteit binnen de perken te houden. Maar dat niet alleen. De architectuur wordt ook gezien als een goed hulpmiddel voor de afstemming van businessen ICT-doelstellingen op langere termijn. Beide auteurs zijn werkzaam binnen het directoraat Groep ICT van Rabobank Nederland. J.C.H. (Hans) Bielok RE (l) is Control & Compliance Officer bij de afdeling ICT Beleid en Architectuur. A.C.A. (Arjan) Uittenbogerd EMITA (r) is informatiemanager bij de afdeling Programmaen Informatiemanagement. Hij is onlangs afgestudeerd aan de postdoctorale opleiding EDP-auditing van de Erasmus Universiteit Rotterdam (EURAC). Ter afsluiting van deze opleiding heeft hij een referaat vervaardigd met de titel Het toetsen van informatiearchitectuur: een praktijkvoorbeeld. Voor de uitvoering van een architectuurreview zijn inmiddels al verschillende benaderingen beschreven [Smil05]. Toch lijkt in de praktijk de architectuur nog niet vaak getoetst te worden door IT-auditors. Door de toenemende aandacht voor en belang van architectuur is de kans groot dat een IT-auditor hier mee te maken gaat krijgen, als object van toetsing of als norm in het geval dat architectuur randvoorwaarden geeft voor het ontwikkelen en beheren van systemen. Binnen de Rabobank wordt architectuur gezien als belangrijk hulpmiddel bij het ontwikkelen en beheren van informatiesystemen. Sinds eind jaren 80 wordt gewerkt onder architectuur en architectuurprocessen en -producten zijn in samenhang met andere ICT-processen en -producten beschreven. In 2004 is voor het eerst een meting uitgevoerd naar de volwassenheid van de architectuurprocessen. Hierbij werd gebruik gemaakt van het Architecture Maturity Model (AMM). In 2006 is een vervolg-assessment uitgevoerd. Dit keer werd het AMM-assessment uitgebreid met een inhoudelijke toets van de architectuurproducten. Met name deze laatste toets wordt in dit artikel toegelicht. We beschrijven hoe dit onderzoek is uitgevoerd, de resultaten ervan en wat de toegevoegde waarde was voor de Rabobank. Ten slotte geven we een aantal algemene aanbevelingen voor het toetsen van architectuurproducten. De structuur van het artikel is als volgt: In deel I beschrijven we het begrip architectuur en introduceren we een globaal model met aspecten die voor architectuur van belang zijn. Op basis van dit model wordt een aantal architectuurproducten van de Rabobank beschreven die voor de toets van belang waren. In deel II zijn de opzet en uitvoering van de toets beschreven. Deel III bevat de resultaten van de toets en algemene aanbevelingen voor het toetsen van architectuur. Architectuur (deel I) Om de resultaten van de toets te kunnen plaatsen is het van belang om een beeld te hebben van het begrip architectuur en hoe hier binnen de Rabobank mee omgegaan wordt. Begripsomschrijving van architectuur Er zijn verschillende en uiteenlopende definities van het 17 de EDP-Auditor nummer 2 2007

begrip architectuur. Dit is niet vreemd omdat het architectuurdenken nog relatief jong is en de doelstellingen die ermee nagestreefd worden zeer divers zijn. In de literatuur kom je nieuwe begrippen tegen zoals informatiearchitectuur, ICT-architectuur, digitale architectuur en beveiligingsarchitectuur. In het onderzoek en dit artikel zijn we uitgegaan van de definitie zoals deze binnen de Rabobank gehanteerd wordt. Daarnaast hebben we in dit artikel ook een aantal aspecten uit een aantal andere definities in een eenvoudig model gezet om een meer algemeen beeld van architectuur te geven. Een aantal architectuurproducten van de Rabobank wordt aan de hand van dit model toegelicht. De inrichting van architectuur binnen de Rabobank is gebaseerd op Dynamische Architectuur (DYA) van Sogeti [Berg04], waarvan in een vorig nummer van de EDP-Auditor een boek beschrijving is gepubliceerd, en Tapscott [Taps93]. De volgende definitie wordt gehanteerd: Een consistent geheel van principes en modellen dat richting geeft aan ontwerp en realisatie van de processen, organisatorische inrichting, informatievoorziening en technische infrastructuur van een organisatie. [Wagt02] De doelstelling ervan is als volgt geformuleerd: De architectuur kan gezien worden als het geheel van afspraken dat ervoor zorgt dat individuele ontwikkelingen aansluiten op elkaar en op het overkoepelende bedrijfsbelang. Door het stellen van concrete kaders, is duidelijk waar individuele projecten zich aan te houden hebben en waar ze vrijheid in hebben. De producten van de projecten die zich aan de architectuur houden passen in het groter geheel. [Fort04] De definitie onderkent verschillende views (processen, organisatorische inrichting, informatievoorziening en technische infrastructuur) en verschillende manieren van uitwerken (principes en modellen). Hiernaast wordt binnen de Rabobank ook onderscheid gemaakt in het niveau binnen de organisatie (Rabobankgroep, Rabobanklabel en domeinen binnen het Rabobanklabel). Bij de doelstelling wordt onderscheid gemaakt tussen het aansluiten van ontwikkelingen op elkaar en op het bedrijfsbelang. Tevens worden er vanuit de samenhang kaders gesteld voor individuele projecten. Zonder al te veel in te gaan op andere definities van architectuur hebben we getracht om op basis van een aantal daarvan een model te maken om zo het begrip architectuur vanuit een breder perspectief (dan uitsluitend dat van de Rabobank) te bezien. Op basis van de definities hebben we de volgende aspecten onderkend: Niveau in de organisatie: Is de scope van de architectuur de hele organisatie of een specifiek onderdeel? Manier van uitwerken: Wordt architectuur beschreven in de vorm van principes, modellen, componenten, regels? Views: Vanuit welke gezichtspunten wordt de architectuur uitgewerkt? Veel voorkomende gezichtspunten zijn business, proces, informatie, applicatie en technologie. Tijdshorizon: Beschrijft de architectuur een bepaald moment in de toekomst en, zo ja, welk moment of de huidige situatie? Gartner heeft hiervoor de begrippen tomorrow architecture (3-5 jaar), next-minute architecture (volgend jaar) en today architecture (huidige situatie) geïntroduceerd. [Ross99] Overig: Naast bovenstaande aspecten zijn er nog enkele andere die we voor de eenvoud van het model onder het kopje overig geschaard hebben, hoewel ze zeer divers zijn. Dit betreft planning, kosten, ethische aspecten, gevoelswaarde. et cetera. In onderstaande figuur is dit schematisch weergegeven: Architectuur binnen de Rabobank Om de resultaten van de uitgevoerde toets te kunnen plaatsen is het van belang om een beeld te hebben van de Rabobank en de manier waarop binnen de Rabobank wordt omgegaan met architectuur. Hiervoor beschrijven we de architectuurproducten die voor de toets van belang waren aan de hand van het voorgaande model. Dit geeft een beeld van hoe we intern tegen architectuur aankijken. Om ook een extern beeld te krijgen zijn tevens de resultaten van een begin 2006 uitgevoerd AMM-assessment beschreven. Dit assessment was gericht op architectuurprocessen en had dus een andere invalshoek. De Rabobankgroep omvat naast de Aangesloten Banken en Rabobank Nederland ook gelieerde instellingen, zoals Robeco en De Lage Landen. Rabobank Nederland is onder andere onderverdeeld in een wholesale- en internationaal retailbedrijf en een binnenlands retailbedrijf. De ICT-functie is voor een belangrijk deel gecentraliseerd onder de naam Groep ICT. De rol en toepassing van architectuur is voor de verschillende businesseenheden wisselend en divers. Voor het binnenlands retailbedrijf bijvoorbeeld wordt de architectuur in 18 de EDP-Auditor nummer 2 2007

aparte projecten over de volle breedte vooraf uitgewerkt; voor het wholesale- en internationaal retailbedrijf gebeurt dit op het moment dat er ontwikkelingen zijn waarvoor het noodzakelijk is dat er ook een architectuurvisie is. Op dat moment wordt de architectuur voor het specifieke onderdeel binnen het project uitgewerkt. De architectuurtoets is uitgevoerd voor het binnenlands retailbedrijf. Dit is het onderdeel van waaruit de massamarkt wordt bediend. De architectuurfunctie is binnen Groep ICT verder uitgewerkt dan bij de businesseenheden. Dit uit zich in het aantal personen dat hieraan werkt, binnen Groep ICT meer dan honderd en bij de businesseenheden een tiental, en ook in de mate waarin processen en producten gedefinieerd en gestandaardiseerd zijn. De businesseenheden hebben soms zelf architecten in dienst, maar maken meestal gebruik van diensten van Groep ICT. Er zijn binnen Groep ICT aparte afdelingen met een eigen verantwoordelijkheid voor architectuur: ICT Beleid en Architectuur (IBA) voor de overall architectuur. Programma- en Informatiemanagement (PIM) voor de domeinarchitecturen. Systeemrealisatie is gericht op constructieprincipes. Beheer & Exploitatie op inrichting van de fysieke infrastructuur. Voor de architectuurtoets was het Handboek Architectuur van belang, evenals de volgende architectuurproducten: ICT-strategie Rabobank. Architectuur Rabobank. Procesarchitectuur Rabobank. Domeinarchitecturen. Project Start Architecturen (PSA s). ICT-strategie Rabobank De ICT-strategie Rabobank 2004-2008 bevat de doelstellingen en strategische afspraken 1 op ICT-gebied voor het merk Rabobank en sluit aan op de ICT-strategie van de Rabobankgroep. De businessview van architectuur maakt deel uit van de ICT-strategie. Dit onderdeel is beperkt uitgewerkt. De afspraken zijn de basis geweest voor het toetsingskader dat voor de inhoudelijke toets van de Architectuur Rabobank is opgesteld. Architectuur Rabobank Het doel van de Architectuur Rabobank is het afbakenen van applicatieve domeinen en (verander)programma s en het beschrijven van afspraken voor de uitwerking van domeinen, PSA s, overall constructieprincipes, technische applicatiemodellen, het inrichten van de technische infrastructuur, beveiligingmechanismen en beheerprocessen en hulpmiddelen. De Architectuur Rabobank verdiept de afspraken uit de ICT-strategie Rabobank en bevat een nadere uitwerking van de Groepsarchitectuur voor het Rabobanklabel. De afspraken in de Architectuur Rabobank zijn grotendeels overgenomen in het toetsingskader dat voor de inhoudelijke toets van de domeinarchitecturen en de PSA s is opgesteld. Voor de afbakening en inrichting van applicatieve domeinen is een lagenmodel uitgewerkt. Dit bevat een aantal logische lagen en per laag een aantal logische domeinen. Deze domeinen zijn verder uitgewerkt in domeinarchitecturen. Binnen de domeinen worden onder andere ICT-componenten uitgewerkt. Zie Figuur achitectuur Rabobank. Procesarchitectuur Rabobank De Procesarchitectuur Rabobank beschrijft de bedrijfsprocessen en hun onderlinge samenhang. De processen zijn op een generiek niveau beschreven en uitgewerkt in een procesmodel. De Procesarchitectuur vormt een kader voor de ontwikkeling en het gebruik van processen binnen de Rabobank. Ten tijde van het onderzoek werd de Procesarchitectuur herzien. Toch zijn een aantal belangrijke afspraken in de Procesarchitectuur, waarvan duidelijk was dat ze nog steeds actueel waren, opgenomen in het toetsingskader voor de domeinarchitecturen en de PSA s. Domeinarchitectuur De domeinarchitectuur beschrijft hoe de domeinoverstijgende architectuurafspraken binnen het domein toegepast moeten worden. Hierbij wordt beschreven welke componenten ontwikkeld worden en hoe dit ontwikkelen gebeurt. Dit gebeurt op basis van afspraken over functionele ordening, technische constructieprincipes, informatiebeveiligingsvoorschriften, afspraken over procesinrichting, etc. De migratieparagraaf in de domeinarchitectuur is mede input voor programma s en projecten waarin deze componenten ontwikkeld worden. De uitwerking van een domeinarchitectuur verschilt per domein. Er is wel een sjabloon dat gericht is op de uitwerking van de onderdelen business, proces, informatie, 19 de EDP-Auditor nummer 2 2007

applicatie en technologie, maar de manier waarop dit gebeurt, de diepgang en de tijdshorizon zijn per domein verschillend. Project Start Architectuur (PSA) Een PSA is nodig omdat er vele architectuurdocumenten en -afspraken zijn en het voor veel projectmedewerkers niet te overzien is wat en op welke manier ze dit moeten toepassen. Voor ieder project moet een PSA gemaakt worden. De aspecten en diepgang van uitwerking zijn afhankelijk van het project, de diepgang van uitwerking van de domeinarchitectuur en de impact op de architectuur van de wijziging die het project beoogt te realiseren. Een PSA bevat een selectie van verschillende onderdelen uit andere architectuurdocumenten en een beschrijving van de manier waarop dit binnen het project toegepast moet worden. De uitwerking ervan is divers. Ook voor de PSA bestaat een sjabloon met de onderdelen business, proces, informatie, applicatie, technologie en migratie, maar de manier waarop PSA s uitgewerkt worden, de diepgang en de tijdshorizon zijn verschillend. Handboek Architectuur Het Handboek ICT-architectuur is geen architectuurproduct, maar is van belang voor de toets omdat het de beschrijving bevat van het architectuurproces binnen de Rabobank. Ook wordt de samenhang beschreven van de architectuurproducten, zoals de Groepsarchitectuur, de Architectuur Rabobank, de domeinarchitecturen en de PSA s. Daarnaast zijn architectuurdisciplines en -rollen en, onder het kopje Architectuur Governance, de besluitvorming en de afwijkingsprocedure uitgewerkt. Relatie tussen deze architectuurproducten In bovenstaande paragrafen is een aantal architectuurdocumenten beschreven en gerelateerd aan de eerder beschreven algemene aspecten van architectuur. In de tabel Scope Architectuurproducten van de Rabobank worden de relaties samengevat. AMM-assessment De ervaringen binnen de Rabobank met betrekking tot het toetsen van architectuur hebben vooral betrekking op de procesmatige kant. Hiervoor zijn de afgelopen jaren voor verschillende onderdelen van de Rabobank Groep AMMmetingen uitgevoerd. AMM is ontwikkeld door Sogeti in samenwerking met onder meer de Rabobank. AMM onderzoekt de kwaliteit van de architectuurprocessen en onderkent vergelijkbaar met CMMI en ITSCMM 2 vijf volwassenheidsniveaus (levels). Bij het assessment dat begin 2006 is uitgevoerd zijn in samenwerking met Sogeti de levels van AMM in overeenstemming gebracht met CMMI en ITSCMM om zo in de rapportage naar het management een beeld te kunnen geven dat aansluit op de vaker toegepaste en daardoor meer bekende CMMI-volwassenheidsniveaus. Het AMM-ambitieniveau van de Rabobank is voor de periode tot 2008 gericht op het tweede ( repeatable ) en derde level ( defined ). Voor de uitvoering van het assessment werden de architectuurprocessen onderzocht binnen drie geselecteerde domeinen: Verkoop, Sparen en Besturing. Bij deze keuze is rekening gehouden met spreiding over de lagen uit de architectuur, verschillen in aansturing van programma s binnen de domeinen en verschillen in de inzet van pakketten versus maatwerk. Het resultaat van het AMM-assessment was, dat level-2 nog niet volledig is bereikt. De belangrijkste aanbevelingen komen er op neer dat gezorgd dient te worden voor: transparantie en borging van de architectuurprocessen, met expliciete structuren, checklists en sjablonen; meer betrokkenheid van de business. De toets (deel II) In het eerste deel is het begrip architectuur beschreven en hebben we hier een model voor geschetst. Daarnaast is een aantal producten beschreven waarin architectuur binnen de Rabobank is uitgewerkt. In dit tweede deel beschrijven we de opdracht en aanpak van de inhoudelijke toets die begin 2006 uitgevoerd is en waarbij de beschreven architectuurproducten als norm en object van toetsing gebruikt zijn. De opdracht Voor het opstellen van de opdrachtformulering is uitgegaan van de architectuurprocessen en -producten die daarbij opgeleverd worden. Binnen de Rabobank wordt de volgende keten gehanteerd: 1. Voeren strategische dialoog. Dit betreft het afstemmen van businessdoelstellingen tussen verschillende businesseenheden en het afstemmen van de ICT-doelstellingen op de business doelstellingen. Resultaten hiervan worden o.a. vastgelegd in de vorm van afspraken in de ICT-strategie en de definities van programma s. 20 de EDP-Auditor nummer 2 2007

2. Opstellen/actualiseren architectuur. Dit betreft het uitwerken van de afspraken uit de ICT-strategie in de architectuur Rabobank en domeinarchitecturen als architectuurkader voor programma s. Voor de uitwerking van domeinarchitecturen kan hierbij nog een verdieping van de business doelstellingen plaatsvinden. 3. Opstellen PSA. De bovenstaande processen hebben betrekking op het opstellen en inhoudelijk uitwerken van architectuur. Het proces opstellen PSA heeft betrekking op het toepassen van architectuur binnen projecten. In dit architectuurproces worden aan het begin van een project architecturale kaders voor het project opgesteld. Hierbij wordt de architectuur niet verder uitgewerkt maar wordt voor een concreet project beschreven welke architectuur van toepassing is en hoe deze toegepast moet worden. 4. Informatiseren onder architectuur. Dit is eigenlijk meer een verzamelbegrip dan een proces en betreft het ontwikkelen, implementeren en beheren van ICT-toepassingen (pakketten en zelfbouw) onder architectuur. Waar het opstellen van de PSA in de opstartfase van het project zit, wordt als onderdeel van dit proces getoetst op naleving van de architectuur tijdens de uitvoering van het project. Om de omvang van de toets te beperken is als uitgangspunt gehanteerd dat de ICT-strategie invulling geeft aan de ICTbehoeften van de Rabobank, zoals beschreven in de diverse businessplannen. Deze relatie is niet getoetst. Bij de keuze hiervoor speelde mee dat dit de eerste keer is dat we een dergelijke toets uitvoeren en we hierbij ook eerst ervaring op willen doen met de inrichting van dergelijke inhoudelijke architectuurtoetsen. De opdracht is als volgt geformuleerd: Toets binnen Groep ICT met betrekking tot het Architectuurproces of de opgeleverde producten actueel zijn, of de inhoud voldoet aan de vastgelegde afspraken en of de onderdelen consistent zijn en onderling op elkaar aansluiten. [Biel06] Aanvullend hierop is gevraagd om: Een overzicht van de beschikbare domeinarchitecturen en hun actualiteit op te stellen. Te toetsen of voldaan wordt aan de eis of voor ieder project een PSA gemaakt wordt. Aanbevelingen te doen voor verbetering van eventuele gebreken. Vanuit het oogpunt van haalbaarheid is ervoor gekozen om niet alle domeinen en PSA s te toetsen maar hierin een keuze te maken. In ons streven naar aansluiting op het AMMassessment zijn bij beide onderzoeken dezelfde drie domeinen getoetst. De aanpak De architectuurtoets is tussen januari en april 2006 in zes fasen uitgevoerd. Fase 1: Voorbereiden onderzoek. Deze fase was gericht op het opstellen en afbakenen van de opdrachtformulering. Dit is gedaan op basis van gesprekken met opdrachtgevers en andere betrokkenen en onderzoek van documentatie. Omdat in de periode dat de toets uitgevoerd is ook het AMM-assessment uitgevoerd werd en het voor de opdrachtgevers van belang was om inzicht te krijgen in samenhang tussen beide onderzoeken, is ook een aantal AMM-interviews met architecten bijgewoond. Hiernaast zijn de uitvoerders van de architectuurtoets ook betrokken bij opdrachtformulering van het AMM-assessment. In deze fase is ook het Plan van Aanpak voor de uitvoering van de toets opgesteld. Fase 2: Opstellen toetsingskader. Tijdens deze fase zijn twee verschillende toetsingskaders opgesteld. Het toetsingskader voor de Architectuur Rabobank is gebaseerd op de ICT-strategie Rabobank (1) en het Handboek ICT-architectuur (2). Het toetsingskader voor de domeinarchitecturen en de PSA s is gebaseerd op de Architectuur Rabobank (3) en eveneens het Handboek ICTarchitectuur (4). Ook is in beperkte mate de aansluiting van de domeinarchitecturen en de PSA s op de Procesarchitectuur (5) onderzocht. De PSA s en de domeinarchitecturen zijn in samenhang met elkaar getoetst vanwege de complementariteit. Ook kan het voorkomen dat in een domeinarchitectuur afspraken zijn vastgelegd voor PSA s binnen dat domein (6). De basis voor de twee toetsingskaders is in de figuur Basis voor toetsingskaders schematisch weergegeven. Fase 3: Vaststellen huidige situatie. Tijdens deze fase is de betreffende documentatie bestudeerd (Architectuur Rabobank of een domeinarchitectuur met bijbehorende PSA s). Vervolgens zijn voor verificatie hiervan interviews gehouden met de architecten die vanuit Groep ICT verantwoordelijk zijn voor het betreffende domein. Voor elke norm uit de toetsingskaders zijn de bevindingen vastgelegd. Openstaande vragen en onduidelijkheden zijn tijdelijk vastgelegd om deze separaat te kunnen navragen of verifiëren. 21 de EDP-Auditor nummer 2 2007

Fase 4: Evaluatie en formuleren conclusie. In deze fase is het beeld getoetst aan de toetsingskaders, zijn conclusies getrokken en aanbevelingen voor verbeterpunten uitgewerkt. Tijdens deze fase zijn de volgende producten opgeleverd: - toetsingskaders, met daarin vastgelegd alle bevindingen; - een overzicht van de beschikbare domeinarchitecturen en hun actualiteit en - voor het domein Sparen, als steekproef, een overzicht van de in 2005 opgeleverde PSA s in relatie tot de in die periode uitgevoerde projecten. Fase 5: Rapportage aan opdrachtgevers. Dit betrof het presenteren van het eindrapport van de toets en het bespreken van conclusie en aanbevelingen met opdrachtgevers. Tijdens deze bespreking zijn ook afspraken gemaakt over het oppakken van de verbeterpunten door de opdrachtgevers. Op verzoek van de opdrachtgevers zijn de resultaten ook gepresenteerd binnen de architectengemeenschap. Fase 6: Implementatie van verbetervoorstellen. Tijdens deze fase zijn de verbeterpunten door medewerkers van de opdrachtgevers uitgewerkt in verbeterplannen en vervolgens gerealiseerd en ingevoerd. Deze fase loopt nog en wordt gemonitord door de afdeling Control & Compliance binnen Groep ICT. Resultaten van de toets en algemene aanbevelingen voor de auditor (deel III) In dit deel beschrijven we de resultaten van de uitgevoerde toets, die specifiek zijn voor de Rabobank. Aansluitend hierop doen we een aantal algemene aanbevelingen voor het toetsen van architectuur. Resultaten van de toets Hieronder de meest in het oog springende resultaten van de toets. Ook wordt vermeld welke maatregelen het verantwoordelijke management heeft genomen in reactie op de conclusies en aanbevelingen van het eindrapport. Business-ICT alignment De gehanteerde methode binnen de Rabobank vraagt nadrukkelijk aandacht voor de koppeling van de architectuur met de business. Dit belang wordt ook onderkend door de architecten zelf. Desondanks blijkt uit de toets dat in de architectuurproducten de businessaspecten onderbelicht zijn. Zo komen in de ICT-strategie de businessaspecten summier aan bod en dan vooral gericht op het retailbedrijf. En ook is geconstateerd dat de architectuurproducten niet expliciet door de business zijn geaccordeerd of onvoldoende draagvlak binnen de business kennen. Als oorzaak hiervan wordt door geïnterviewden aangegeven dat de businessaspecten moeilijk zijn te achterhalen doordat businessplannen en dergelijke vaak ontbreken. Verder is tijdens de toets geconstateerd dat de neiging aanwezig is om (te) veel vanuit de ICT-oplossing te redeneren. Voor de Rabobank is de alignment van de architectuur met de business van groot belang. Er zijn dan ook maatregelen genomen om die aansluiting op het gewenste niveau te brengen. Zo hebben architecten en informatiemanagers de opdracht gekregen nadrukkelijk te redeneren vanuit Business, Omgeving (markt en regelgeving), Proces en daarna pas vanuit de (ICT-)oplossing. Architectuurproducten worden hier nu op getoetst. Ook wordt bij het bepalen van de ICT-strategie de business intensief betrokken via interviews en terugkoppelsessies. Architectuurproducten worden voortaan door de business gelezen en becommentarieerd. Vertegenwoordigers vanuit de business worden uitgenodigd voor de bijeenkomsten waar belangrijke architectuurontwikkelingen worden besproken of gepresenteerd. Veelheid aan afhankelijkheden De toets heeft duidelijk gemaakt dat binnen de Rabobank een groot aantal beleidsdocumenten van invloed is op de architectuur en de genoemde architectuurproducten. Het gaat hier om losse beleidsdocumenten zoals een servicearchitectuur, masterplan connectiviteit, handboek beheer, storage-architectuur, informatiebeveiligingsarchitectuur, beleid ICT-infrastructuur, etc. Het gevolg van deze veelheid aan beleidsdocumenten en onderlinge relaties is: dat het bijzonder lastig is om een volledig en actueel beeld te krijgen van de van toepassing zijnde architectuurafspraken; dat het haast ondoenlijk is om de architectuurproducten actueel te houden en de verschillende architectuuraspecten (scope, tijdshorizon, etc.) van de architectuurproducten goed op elkaar af te stemmen. Het voorgaande heeft mede bijgedragen tot het besluit van de afdeling IBA om het aantal beleidsdocumenten aanzienlijk terug te brengen en de documenten onderling beter op elkaar aan te sluiten. Zo wordt de Architectuur Rabobank voortaan voor de relevante onderdelen (informatie, applicaties, technische infrastructuur, informatiebeveiliging en ICT-beheer) als één geheel vastgelegd. Hier is een beknopte set met relevante architectuurafspraken aan gekoppeld. Niet-actuele domeinarchitecturen Binnen de Rabobank geldt de afspraak dat de Architectuur Rabobank en de domeinarchitecturen jaarlijks worden geactualiseerd. De gedachte hierachter is, dat op deze wijze steeds een solide en actuele architecturale basis aanwezig is om nieuwe projecten in goede banen te leiden. Voor de Architectuur Rabobank werkt deze aanpak, omdat deze architectuur onder de verantwoordelijkheid valt van de afdeling IBA en daar jaarlijks budget en tijd beschikbaar wordt gesteld om deze architectuur te actualiseren. Maar voor de domeinarchitecturen blijkt deze werkwijze niet haalbaar te zijn. Ondanks alle goede intenties bleek een aantal domeinarchitecturen niet actueel te zijn en van een aantal domeinen ontbrak de domeinarchitectuur. Opvallend was dat zelfs de meest recente van de aangetroffen domeinarchitecturen 22 de EDP-Auditor nummer 2 2007

toch al op onderdelen was achterhaald. Als oorzaken werden genoemd: Het vervaardigen van een volledige domeinarchitectuur blijkt veel meer capaciteit te vergen dan geschat. Een domeinarchitectuur valt onder verantwoordelijkheid van de afdeling PIM die in opdracht van de business programma's uitvoert. De business is lang niet altijd bereid het noodzakelijke budget beschikbaar te stellen. Men ziet vaak de noodzaak niet in en mist de relatie met de actuele businesswensen. De inhoud van een domeinarchitectuur wordt niet alleen bepaald door de Architectuur Rabobank, maar ook door een groot aantal andere beleidsdocumenten. Het actueel houden van een domeinarchitectuur blijkt door de vele onderlinge verbanden een lastige taak. Op basis van deze bevindingen heeft het verantwoordelijke management besloten om de onderlinge samenhang van de domeinen per laag op te nemen in de Architectuur Rabobank. Detaillering van de architectuur wordt voortaan vraaggedreven. Dit houdt in dat in plaats van domeinarchitecturen nu voor de programma s (clusters van projecten op basis van businessdoelstellingen) een programma-architectuur wordt gerealiseerd. De planningshorizon komt overeen met de looptijd van het programma. De PSA blijft bestaan. Verschillen in PSA s Geconstateerd is dat de afspraak om voorafgaand aan de start van een project een PSA te vervaardigen in het algemeen goed wordt nageleefd. Voor de meeste projecten was een PSA vervaardigd. Het voor de start van een project vastleggen van de architecturale kaders in een PSA blijkt in een behoefte te voorzien. Aangegeven werd dat ook de afdeling Systeemrealisatie grote waarde hecht aan dit document. Wel is geconstateerd dat de inhoudelijke verschillen tussen de PSA s onderling groot zijn. Ondanks het feit dat er een standaard sjabloon voor een PSA is beschreven, blijkt de manier van uitwerken, de diepgang en de tijdshorizon verschillend te zijn. Gevolg is dat ook de omvang van de PSA s fors verschillen. Een PSA moet maximaal verwijzen naar een domeinarchitectuur en moet zich beperken tot architectuuraspecten op hoofdlijnen. Als indicatie is een PSA maximaal 15 pagina s groot, maar in de praktijk zijn PSA s soms tientallen pagina s groot. Hiervoor zijn twee redenen te noemen: Een oorzaak is dat de domeinarchitectuur onvoldoende als basis voor de PSA kon dienen. In een aantal situaties had dit spontaan geleid tot een nieuw type architectuurdocument, namelijk de architectuurverkenning. Dit product moest de tekortkomingen van de domeinarchitectuur opvangen en werd formeel bestempeld als een bijlage bij de domeinarchitectuur. Er zijn veel partijen die belang hebben bij een project. De PSA wordt als het ideale document gezien om dit in vast te leggen. Daar is de PSA echter niet voor bedoeld. Op deze wijze is overlap ontstaan met andere documenten zoals de businessanalyse. De nieuwe werkwijze met programma-architecturen zou bovengenoemd probleem moeten ondervangen. Architectuurverkenningen worden verwerkt in de programma-architectuur. De scope van de PSA is nadrukkelijk beperkt tot de architectuurrelevante zaken voor het project. De indicatieve omvang blijft 15 pagina s, de planningshorizon is gelijk aan het project. Kosten In de architectuur worden strategische beslissingen genomen met verregaande consequenties. De kostenonderbouwing van dit soort beslissingen blijkt meestal te ontbreken. Dat is onterecht, omdat we geconstateerd hebben dat kosten vaak een grote rol spelen als van de architectuurafspraken wordt afgeweken. De aanbeveling luidde dan ook om het kostenaspect meer aandacht te geven bij architectuurbeslissingen, zeker op onderdelen waar structureel zaken geregeld dienen te worden voor meer domeinen. Standaardpakketten Een van de belangrijkste architectuurafspraken binnen de Rabobank is de regel dat bij voorkeur standaardpakketten worden ingezet om de gewenste functionaliteit in te vullen. Ook dienen de pakketten zo weinig mogelijk aangepast te worden (pakket-as-is). De aanschaf van een pakket brengt echter ook een aantal standaards met zich mee die soms tegenstrijdig zijn met de vigerende architectuurafspraken. Een voorbeeld hiervan is het gebruik van een pakketeigen datadictionary die afwijkt van de Rabo-standaard. Dergelijke consequenties bleken nog niet uitgewerkt te zijn. Gegeven het toenemende belang is de aanbeveling gedaan om de consequenties verder uit te werken en in architectuurafspraken vast te leggen. Meer met minder Als ondertitel kreeg het eindrapport mee meer met minder. Dit advies is op verschillende manieren van toepassing voor het onderzoeksresultaat: 1. Meer sturen op kernafspraken minder beleid en architectuurafspraken. 2. Meer overzicht en samenhang minder (losse) beleidsdocumenten. 3. Meer vanuit vraag (beleids)documentatie en architectuur opstellen minder vanuit aanbod. 4. In analogie met bovenstaande uitspraken werd door het management tijdens de rapportbespreking de boodschap van het eindrapport samengevat met: meer business minder papier. Algemene aanbevelingen voor de auditor In deze paragraaf doen we een aantal aanbevelingen, waarmee auditors hun voordeel kunnen doen als zij te maken krijgen met het toetsen van architectuur. 23 de EDP-Auditor nummer 2 2007

De overall conclusie van de toets is dat het inhoudelijk toetsen van informatiearchitectuur mogelijk en nuttig is. Zeker als je de eerste keer een dergelijke toets uitvoert, loop je tegen een aantal vragen aan. De volgende aanbevelingen bieden hierbij mogelijk ondersteuning: 1. Het is noodzakelijk om eerst een helder beeld te krijgen van wat onder het begrip architectuur verstaan wordt. Met het model in het eerste deel hebben we getracht een beeld te geven van de diversiteit. Dit of een ander model kan als hulpmiddel dienen bij de definitie zoals die binnen het bedrijf gehanteerd wordt. 2. Bekijk in welke documenten welk deel van de architectuur uitgewerkt is en of de samenhang duidelijk is. Indien de samenhang onduidelijk is moet deze eerst in kaart gebracht worden. Volgende stappen hebben pas zin als dit gebeurd is. 3. Indien de beoogde samenhang duidelijk is en beschreven is, kan deze getoetst worden. Daarnaast kunnen op basis hiervan inhoudelijke aspecten getoetst worden. De structuur kan als hulpmiddel dienen bij de keuze van de te hanteren norm en het object van toetsing. Tevens kunnen verschillende doelstellingen van architectuur ook onafhankelijk van elkaar worden getoetst. 4. Voor de inhoudelijke toetsing is een bedrijfseigen normenkader nodig. Dit geldt met name voor de toetsing op de aansluiting tussen de architectuur en het overkoepelende bedrijfsbelang, omdat dit bedrijfsbelang per bedrijf verschilt. 5. Doordat het begrip architectuur zo veelomvattend is, kunnen ook specifieke onderdelen ervan inhoudelijk getoetst worden. Een voorbeeld hiervan is de manier waarop Service Oriënted Architecture (SOA) toegepast wordt. Hiervoor is het noodzakelijk dat er voor het specifieke aspect normen voldoende smart 3 beschikbaar zijn. Het is belangrijk dat dit in de opdrachtformulering en rapportage over de resultaten duidelijk wordt gemaakt. 6. Het is van belang om bij de keuze van de scope van de toets rekening te houden met verschillen in de manier waarop bedrijfsonderdelen omgaan met architectuur. Het wholesale- en internationaal retailbedrijf met een just in time architectuur vereist een andere benadering dan het binnenlands retailbedrijf. 7. Neem alle belangrijke nieuwe ontwikkelingen (het gebruik van pakketten, outsourcing, etc.) mee bij de uitwerking van architectuur en toets deze ook. 8. Think big, act small. Begin met een beperkte maar wel duidelijke scope en ambitie en pas eventueel time-boxing toe. Binnen het onderzoek hebben we dit gedaan door architectuurprocessen en -producten binnen de Rabobank en hun onderlinge samenhang volledig in kaart te brengen. Maar vervolgens hebben we ons voor de uitvoering van de toets beperkt tot naleving van architectuur binnen de ICT-keten en, in beperkte mate, de aansluiting tussen business en ICT. Binnen de ICT-keten hebben we ons voor domeinen en PSA s beperkt tot steekproeven. Literatuurverwijzingen: [Berg04] M. van den Berg en M. Steenbergen: DYA: Stap voor stap naar een professionele enterprise-architectuur, Ten Hagen & Stam, 2004. [Biel06] J.C.H. Bielok en A.C.A. Uittenbogerd: Rapport Architectuurtoets, Rabobank, april 2006. [Fort05] J.P. Fortuin e.a.: Architectuur Rabobank, versie 2.1, Rabobank, september 2005. [Ross99] B. Rosser: IT-Architecture by Time: Today, Tomorrow or Next Minute, Gartner Research Note, december 1999. [Smil05] R. Smildiger: Een audit op informatiearchitectuur: waar te beginnen? De EDP-Auditor nummer 3, 2005 [Taps93] Don Tapscott en Art Caston, Paradigm Shift, the new promise of Information Technology, 1993, McGraw-Hill inc., New York USA. [Uitt06] A.C.A. Uittenbogerd: Het toetsen van informatiearchitectuur: een praktijkvoorbeeld, referaat voor opleiding EDP-auditing Erasmus Universiteit Rotterdam, augustus 2006. [Wagt02] R. Wagter e.a.: DYA: Snelheid en samenhang in business- en informatiearchitectuur, Tutein Nolthenius, augustus 2002. Noten 1 Afspraken zijn onderverdeeld in wetten, standaards en richtlijnen. Van wetten mag niet worden afgeweken, voor standaards bestaat de mogelijkheid een afwijkingsverzoek in te dienen bij de afdeling IBA. Richtlijnen zijn best practices. 2 Het bij views weergeven model betreft het framework van Tapscott. Dit framework geeft de samenhang weer tussen de architectuurviews Informatie (1), Applicatie (A), Tachnologie (T), Business (B) en Proces (P) 2 CMMI staat voor Capability Maturity Model Integration en ITSCMM voor IT-Service Capability Maturity Model. 3 Smart staat voor Specifiek, Meetbaar, Acceptabel, Realistisch en Tijdsgebonden. 24 de EDP-Auditor nummer 2 2007