Koen Vincent Studentnummer: Scriptienummer 1049

Welke risico’s moet een organisatie beheersen met betrekking tot haar legacy-systemen bij het realiseren van haar systeemintegratie (vernieuwings-)doelstellingen? Koen Vincent Studentnummer: 1689843 Scriptienummer 1049

Risicobeheersing bij legacy-systeemintegratie

1. Voorwoord Dit document is het resultaat van mijn scriptie ten behoeve van de postdoctorale opleiding EDP auditing aan de Vrije Universiteit Amsterdam. Deze scriptie is het resultaat van onderzoek, interviews, workshops en praktische toetsing. Resulterend tot een framework voor het beheersen van risico’s tijdens legacysysteemintegratie. Graag wil ik mijn begeleider aan de Vrije Universiteit Amsterdam, Paul Harmzen, bedanken voor zijn hulp en flexibiliteit bij het realiseren van deze scriptie. Daarnaast wil ik mijn vrouw bedanken voor alle goede zorgen tijdens de uitvoering van het onderzoek en het schrijven van deze scriptie. Ook gaat mijn dank uit naar alle geïnterviewden zowel van de interne organisatie als ook externe organisaties die in hun drukke schema’s tijd hebben gevonden om bij te dragen aan het onderzoek.

-2-


2. Samenvatting In mijn werkomgeving is sprake van een grote hoeveelheid legacy-systemen. Jarenlang zag de organisatie geen noodzaak om het systeemlandschap te vernieuwen en te vervangen. De winsten waren goed, de marges op veel producten, waren hoog. Daarnaast was sprake van een economisch goede tijd. Dit had tot gevolg dat zij minder kritisch ging kijken naar haar eigen verdienmodel, maar ook naar de inrichting van de operationele processen en ondersteunende systemen. Hierdoor is jarenlang doorgewerkt met hoge operationele kosten. De gemaakte winsten verborgen de noodzaak voor de integratie van bestaande systemen. In de laatste jaren is hier verandering in gekomen en staat men voor een nieuwe uitdaging, waarbij een veelvoud aan systemen geïntegreerd moet worden in een nieuwe doelarchitectuur. Vanuit een Audit perspectief werd ik gegrepen door de vraag welke risico’s zich voordoen bij het integreren van legacy-systemen. Om deze vraag te beantwoorden heb ik eerst vastgesteld wat een legacy-systeem is. Vanuit de literatuur is hiervoor geen eenduidige definitie beschikbaar. Vaak wordt bij legacy-systemen gedacht aan verouderde systemen, waarvoor geen ondersteuning op de hardware of software meer gegeven wordt door de leverancier. In het onderzoek is de definitie met betrekking tot legacy-systemen breder geformuleerd. De definitie is als volgt: Legacy-systemen zijn die systemen, die niet binnen de nieuw ingerichte of in te richten doelarchitectuur passen en vervangen zullen worden bij het realiseren van systeemintegratie en rationalisatie. Deze definitie is de basis waarop gekeken wordt naar legacy-systeemintegratie. Legacy-systeemintegratie is het proces waarbij het oude systeem gemigreerd gaat worden naar de doelarchitectuur. Het startpunt hierbij is de beslissing tot het uitfaseren van het legacy-systeem. Het eindpunt betreft het daadwerkelijk uitzetten en verwijderen van het legacy-systeem. Onderzoek in bestaande literatuur gaf weinig houvast met betrekking tot risico’s in samenhang met legacysysteemintegratie. De aanwezige informatie was vaak niet specifiek gericht op legacy-systeemintegratie. Daarnaast was de beschikbare informatie erg versnipperd. Dit onderzoek heeft wel geleid tot het onderkennen van een aantal stappen in de legacy-systeemintegratie: huidige situatie, geplande uitfasering, in transitie en uitgefaseerd. Per fase is uitgewerkt wat in de literatuur terug te vinden was met betrekking tot het beheersen van risico’s en bijvoorbeeld eisen die worden gesteld vanuit weten regelgeving. Dit onderzoek was de basis voor het opstellen van een risicobeheersingsframework. Om de risico’s in kaart te brengen en uit te gaan van een marktstandaard is ervoor gekozen de risico’s met betrekking tot legacy-systeemintegratie te plotten op Cobit control objectives. Hierdoor is het voor organisaties relatief eenvoudig aanvullende maatregelen in te richten naast eventueel bestaande Cobit implementaties. Vanuit deze risico-inventarisatie is een framework opgesteld met aanvullende maatregelen, om de legacy-systeemintegratie te beheersen. De risicomapping en het normenkader zijn getoetst in de praktijk met behulp van workshops en interviews. Deze workshops en interviews hebben geleid tot aanvullingen en aanscherpingen van de risico’s evenals de verwachte beheersmaatregelen. De risicomapping is opgenomen in bijlage 1. Het uiteindelijke resultaat, het framework, is opgenomen in bijlage 2. De belangrijkste risico’s die naar voren kwamen tijdens de praktische toetsing van het framework zijn onder andere de tijdigheid bij uitvoering van beheersmaatregelen en de periodiciteit waarmee dit plaatsvindt gedurende de integratie. Daarnaast is de IT-governance en planning bij het maken van de juiste keuze met betrekking tot legacy-systeemintegratie een van de te beheersen risico’s. Vaak wordt niet bewust gekozen voor een strategie die past bij de kenmerken van het te integreren legacy-systeem. Het toekennen van voldoende prioriteit en budget voor onderhoud en ontwikkeling van de legacy-systemen is ook een aspect dat beheerst moet worden. Het is dus de vraag of de toegekende budgetten en prioriteitstellingen nog in lijn zijn met het belang van het legacy-systeem voor de operationele processen. Het niet meer aansluiten van de legacy-systemen bij de klant- en de marktvraag is eveneens een van de te beheersen risico’s. Voor (IT-) Auditors is het beoordelen van legacy-systeemintegratie interessant. Tijdens systeemintegratietrajecten is vaak veel aandacht voor de nieuwe doelarchitectuur en slechts beperkt voor de legacysystemen. Beslissingen voor legacy-systeemintegratie worden vaak genomen vanuit politieke overwegingen of opgelegd middels financiële targets. Door objectief beoordelingen uit te voeren kan het management ondersteund worden in het maken van de juiste beslissingen ten aanzien van legacy-systeemintegratie. Gedurende de transitiefase is sprake van verschuivingen in het risicoprofiel. Deze verschuivingen moeten -3-

Risicobeheersing bij legacy-systeemintegratie ook beheerst worden. Het verschaffen van zekerheid over deze transitie is eveneens waardevol voor het management, omdat men zekerheid verkrijgt over de integriteit en continuïteit van de dienstverlening. Daarnaast is de aandacht voor het uitfaseren van systemen zeer beperkt. Bij het daadwerkelijk uitschakelen van systemen komt meer kijken dan men in eerste instantie denkt. Het framework biedt een handvat om ook deze processen beheerst te laten verlopen.

-4-


3. Inhoudsopgave 1. 2. 3. 4.

Voorwoord ...............................................................................................................................................................2 Samenvatting ...........................................................................................................................................................3 Inhoudsopgave.........................................................................................................................................................5 Inleiding en onderzoeksopzet ..................................................................................................................................6 4.1. Aanleiding .....................................................................................................................................................6 4.2. Doelstelling onderzoek .................................................................................................................................6 4.3. Onderzoeksvragen ........................................................................................................................................7 4.4. Resultaat van het onderzoek ........................................................................................................................7 4.5. Aanpak ..........................................................................................................................................................7 4.6. Leeswijzer .....................................................................................................................................................7 5. Theoretisch kader ....................................................................................................................................................8 5.1. Inleiding ........................................................................................................................................................8 5.2. Wat zijn legacy-systemen?............................................................................................................................8 5.3. Welke fasen zijn er bij systeemintegratie? ...................................................................................................8 5.4. Verschillende faseringen.............................................................................................................................10 5.4.1. Huidige situatie ..........................................................................................................................11 5.4.1.1. Application Portfolio Management ................................................................................11 5.4.1.2. Val-IT ...............................................................................................................................13 5.4.2. Geplande uitfasering..................................................................................................................13 5.4.2.1. System development lifecycle ........................................................................................13 5.4.2.2. Enterprise Architecture...................................................................................................14 5.4.2.3. SRAH ...............................................................................................................................15 5.4.3. In transitie ..................................................................................................................................16 5.4.3.1. Conversies.......................................................................................................................16 5.4.3.2. Legacy migratie strategieën............................................................................................16 5.4.3.3. Chicken Little Strategie ...................................................................................................16 5.4.3.4. Butterfly methode ..........................................................................................................18 5.4.3.5. Big bang theorie..............................................................................................................18 5.4.4. Uitfaseren...................................................................................................................................19 5.4.4.1. Compliancy .....................................................................................................................19 5.4.4.2. Fiscale wetgeving ............................................................................................................20 5.4.4.3. Wet bescherming persoonsgegevens .............................................................................20 5.4.5. Cobit...........................................................................................................................................21 6. Opbouw van het framework ..................................................................................................................................23 6.1. Opstellen risicoprofiel.................................................................................................................................23 6.2. Opstellen normen .......................................................................................................................................25 7. Conclusie ................................................................................................................................................................29 8. Persoonlijke reflectie .............................................................................................................................................30 Bijlage 1 Legacy Integratie Risico Framework ...................................................................................................................31 Bijlage 2 Normenkader ......................................................................................................................................................38 Bijlage 3 SRAH readiness checklist ....................................................................................................................................47 Bijlage 4 Geïnterviewde functionarissen...........................................................................................................................49 Bijlage 5 Literatuurlijst.......................................................................................................................................................50

-5-


4. Inleiding en onderzoeksopzet 4.1. Aanleiding In mijn werkomgeving is sprake van een grote hoeveelheid van legacy-systemen. De organisatie heeft jaren geen noodzaak gezien om haar systeemlandschap te vernieuwen en te vervangen. De resultaten waren goed, de marges op veel producten waren afdoende. Daarnaast was sprake van een economisch goede tijd en waren de rendementen uit beleggingen gunstig. Voor de organisatie had dit het gevolg dat zij minder kritisch heeft gekeken naar haar eigen verdienmodel, maar ook naar de inrichting van de operationele processen en ondersteunende systemen. In het verleden heeft de organisatie, een fusiebedrijf, andere bedrijven opgekocht en ‘as is’ in de organisatie geplaatst. De daadwerkelijke integratie van deze organisaties heeft echter slechts beperkt plaatsgevonden. Dit betekent een grote diversiteit in het systeemlandschap, maar ook dat de processen jaren naast elkaar hebben gefunctioneerd en niet uniform zijn ingericht. Systeemintegratie om te komen tot een uniforme backoffice werd niet in gang gezet. Hierdoor is jarenlang doorgewerkt met hoge operationele kosten. De gemaakte winsten verborgen de noodzaak voor de integratie van de organisaties. De laatste jaren is hier verandering in gekomen. De marges zijn geslonken, de winsten zijn gedaald en de huidige economie zit in een recessie. Hierdoor is het noodzakelijk kostenbesparingen door te voeren. Een sterke IT-Business alignement is hierbij noodzakelijk. Men moet investeren in een vernieuwde dienstverlening waarbij de IT aansluit op de huidige business doelstellingen, om uiteindelijk kostenbesparingen te realiseren en nieuwe/andere klantbehoefte te kunnen bedienen. De systeemontwikkeling heeft zich in het verleden lange tijd gericht op het doorontwikkelen van duurzame, maar vaak complexe, verouderde systemen op de zeer betrouwbare legacy-omgevingen. De angst voor vernieuwing kwam vaak voort uit onzekerheid over het onbekende. Vooral over het risico dat de nieuw te ontwikkelen systemen de betrouwbaarheid van de legacy-systemen niet kunnen evenaren. Door de (bedrijfs)economische verandering is de organisatie overgegaan tot het rationaliseren van haar systeemlandschap. Legacy-systeemintegratie is het proces waarbij het oude systeem over gaat tot integratie/vernieuwing van het systeem in de doelarchitectuur. Het startpunt hierbij is de beslissing tot integratie van het legacy-systeem. Het eindpunt betreft het daadwerkelijk uitzetten en verwijderen van het legacy-systeem. In de praktijk constateer ik een aantal oorzaken voor de noodzaak tot legacy-systeemintegratie. Onder andere door het verlies van kennis over deze legacy-systemen, de dalende performance, schaalbaarheid en het verliezen van support op software en hardware ontstaat deze noodzaak. Voor een aantal van de systemen geldt dat de ontwikkelaars met kritieke kennis, die inmiddels al jaren verbonden waren aan de organisatie, de pensioengerechtigde leeftijd hebben bereikt. Daarnaast zijn er in het verleden voor hetzelfde doel vaak meerdere applicaties ontwikkeld (fusiebedrijf) die allemaal onderhouden moeten worden en bijvoorbeeld aangepast bij wettelijke veranderingen. De bovenstaande redenen leiden ertoe dat een enorme aandacht bestaat voor het integreren van systemen en processen. Dit leidt tot rationalisatie van het systeemlandschap, kostenbesparingen en efficiëntieverbeteringen. Zowel binnen de auditafdeling als binnen de businessafdelingen zelf is voldoende aandacht voor de ontwikkeling van deze nieuwe systemen aanwezig. De aandacht voor de uit te faseren systemen en de risico’s die de transitie met zich meebrengt voor de bestaande organisatie, processen en systemen is vaak beperkt.

4.2. Doelstelling onderzoek Bij het realiseren van de integratiedoelstellingen ligt vaak de focus op de ontwikkeling van het nieuwe systeem. In de literatuur is veel informatie beschikbaar over het ontwikkelen van nieuwe doelsystemen en ook over projectaanpakken om de ontwikkeling van de nieuwe doelsystemen te realiseren. De andere kant van systeemintegratie is het blijven beheersen van de oude omgeving. Door de veranderende doelstellingen van het bedrijf en het investeren in de nieuwe omgeving, wordt in mijn werkomgeving, op de oude omgeving vaak direct bezuinigd. De veranderingen brengen risico’s met zich mee die beheerst moeten worden. De doelstelling van mijn onderzoek is om in kaart te brengen welke risico’s het realiseren van de integratiedoelstellingen met zich mee brengen voor de legacy-systemen. De inventarisatie heeft geleid tot een overzicht van maatregelen om het risico te beheersen. Mijn onderzoek heeft zich niet gericht op de risico’s met betrekking tot de doelsystemen en de systeemontwikkeling van de doelarchitectuur. De -6-

Risicobeheersing bij legacy-systeemintegratie doelstelling heeft geleid tot de volgende hoofdvraag: •

Welke risico’s moet een organisatie beheersen met betrekking tot haar legacy-systemen bij het realiseren van haar systemeemintegratie (vernieuwings-)doelstellingen?

4.3. Onderzoeksvragen De volgende deelvragen moeten gezamenlijk antwoord geven op de hoofdvraag van het onderzoek: 1. 2. 3. 4. 5.

Wat zijn legacy-systemen? Welke fasen bestaan bij systeemintegratie en welke specifieke aspecten bevatten deze fasen? Welke veranderingen ontstaan ten aanzien van de beheersing? Welke risico´s moeten worden beheerst bij het uitfaseren van een (legacy)systeem? Hoe kan een auditor toegevoegde waarde leveren?

4.4. Resultaat van het onderzoek Het resultaat van het onderzoek is een praktisch getoetst framework dat weergeeft welke risico’s een organisatie moet beheersen bij het realiseren van haar systeemintegratiedoelstellingen van legacysystemen.

4.5. Aanpak Het onderzoek bestaat uit een literatuuronderzoek en een uitwerking van het literatuuronderzoek tot een bruikbaar framework. Bij het literatuuronderzoek gaat het voornamelijk om begripsbepaling en (theoretische) modelvorming op basis van academische literatuur en artikelen uit het werkveld. In het literatuuronderzoek is de basis gelegd voor het framework. In aansluiting op het literatuuronderzoek is een framework ontwikkeld. Doelstelling was om uit de modellen in de literatuur risico’s en maatregelen te extraheren en deze specifiek te maken voor het onderwerp. Om de werkbaarheid van het framework vast te stellen is deze getoetst in de praktijk. Deze toetsing is uitgevoerd door verschillende kennisexperts in het vakgebied. Dit is vormgegeven door interviews en workshops. Het bijgestelde framework is opgenomen in bijlage 2. Een toelichting van de gewijzigde elementen in het theoretisch gevormde framework als resultaat van de praktische toetsing is onderdeel van de scriptie.

4.6. Leeswijzer In dit hoofdstuk zijn de aanleiding en doelstelling van het onderzoek beschreven. Tevens is aangegeven op welke onderzoeksvragen antwoord wordt gegeven in dit referaat. Daarnaast is het verwachte resultaat van het onderzoek en de aanpak van het onderzoek beschreven. De deelvragen zijn de uiteindelijke basis voor beantwoording van de hoofdvraag. Het theoretisch kader wordt geschetst in hoofdstuk 5. Dit hoofdstuk geeft antwoord op deelvragen 1, 2 en 3. In hoofdstuk 6 wordt antwoord gegeven op deelvraag 4. Een deelresultaat van de scriptie (legacy integratie risico framework) is opgenomen in bijlage 1. Deze risico-inventarisatie is de basis voor het vervolg van hoofdstuk 6. Hierin wordt de totstandkoming van het framework beschreven. Het framework beantwoordt de hoofdvraag en is opgenomen in bijlage 2. In de conclusie wordt aandacht besteed aan de toegevoegde waarde,die een(IT) auditor kan leveren bij legacy-systeemintegraties.

-7-


5. Theoretisch kader 5.1. Inleiding In mijn werkomgeving, is het IT-landschap grotendeels traditioneel. Voor de transactie verwerkende systemen wordt veelal nog gebruik gemaakt van legacy-systemen. Voorbeelden hiervan zijn Mainframes en/of AS/400 systemen met bijbehorende database management systemen en applicaties. In de huidige tijd en economische situatie is de focus op de kosten zichtbaar toegenomen. Een voorbeeld hiervan is dat programma’s ten behoeve van het versnellen van de IT-vernieuwing zijn opgezet. Een start met het realiseren van systeemrationalisatie is gemaakt. Hiervoor is een Enterprise Architectuur opgesteld en is voorzichtig begonnen aan application portfolio management, die verderop worden toegelicht. Door de veranderingen in de markt wordt scherper aan de wind gezeild en heeft dit ook zijn effect op de versnelde doorvoering van IT Rationalisatie. Bij de integratie van legacy-systemen gaat de aandacht veelal uit naar de nieuw in te richten omgeving. Ook in de theorievorming is dit zichtbaar, dit blijkt uit het feit dat nauwelijks literatuur en normenkaders beschikbaar zijn voor het integreren van legacy-systemen in een nieuwe doelarchitectuur. In dit hoofdstuk wordt uiteengezet wat legacy-systemen zijn, uit welke fasen legacysysteemintegratie bestaat, welke risico’s en beheersmaatregelen in de literatuur zijn aangetroffen ten aanzien van legacy-systeemintegratie. De in de literatuur aangetroffen risico’s en beheersmaatregelen hebben de basis gevormd voor het opgestelde framework in bijlage 2 voor het beheersen van de risico’s bij legacy-systeemintegratie.

5.2. Wat zijn legacy-systemen? Om te bepalen wanneer sprake is van legacy-systemen is een aantal definities beschikbaar in de literatuur. Een uniforme terminologie bestaat nog niet voor legacy-systemen. Een voorbeeld: “Een legacy-systeem kan worden gedefinieerd als een informatiesysteem dat zich verzet tegen noodzakelijke wijzigingen en evolutie.” [Brodie 1995]. Dit is veelal een eenzijdige blik op de ontwikkeling en toekomstvastheid van legacy-systemen. Een meer algemene definitie van legacy-systemen is de volgende: ”Het gaat om systemen waarmee de bedrijfskritische informatie van een organisatie wordt verwerkt en geconsolideerd. Als deze systemen falen heeft dat een serieuze impact op essentiële processen. Dergelijke systemen kunnen diverse problemen veroorzaken voor een organisatie. Ze draaien veelal op exotische en/of verouderde hardware en zijn daardoor traag en duur in het onderhoud. Ook het softwareonderhoud kan duur zijn: omdat vaak weinig of sterk verouderde documentatie beschikbaar is. Hierdoor is het begrijpen van het systeem en het opsporen van fouten vaak duur en tijdrovend. Legacy-systemen zijn soms geschreven in een programmeertaal die niet meer gangbaar is en die nog maar weinig ontwikkelaars beheersen. Het gebrek aan eenduidige software-interfaces maakt integratie van legacy-systemen met andere systemen moeilijk. De systemen zijn vaak moeilijk of helemaal niet uitbreidbaar. Legacy-systemen zijn niet noodzakelijkerwijs oud. Merk ook op dat het woord ‘Legacy’ vaak een negatieve lading heeft. Dit is veelal onterecht, aangezien dergelijke systemen vaak wel de kritieke systemen van een bedrijf vormen” [Wu et al 1997], [Maat&Vogt, 1998], [Bisbal et al 1999] en [Bisbal 1997]. Zoals blijkt uit de vorige alinea bestaan meerdere definities voor legacy-systemen binnen de literatuur. Legacy-systemen zoals benoemd in de literatuur zijn voor het doel en de begripsvorming in het kader van dit onderzoek te eng. In mijn werkomgeving is sprake van een fusiebedrijf, waarbij in het verleden veel bedrijven opgekocht zijn en met andere bedrijven is gefuseerd, maar de IT-integratie niet of nauwelijks heeft plaatsgevonden. Hierdoor is een gediversifieerd landschap ontstaan. Deze ontwikkeling is zichtbaar bij meerdere grote organisaties. Het betreft niet altijd systemen die op basis van “leeftijd” als legacy benoemd worden en hiermee dus aan het einde van hun systeemlifecycle zijn. Voor andere systemen die als legacysystemen bestempeld worden kan het zijn dat deze aan het einde van haar economische lifecycle zijn of dat de strategische doelstellingen niet in voldoende mate ondersteund worden. Hiermee passen deze systemen niet meer in het gerationaliseerde applicatielandschap. Op basis van het bovenstaande wil ik legacysystemen ook als volgt definiëren: Legacy-systemen zijn die systemen, die niet binnen de nieuw ingerichte of in te richten doelarchitectuur passen en vervangen worden bij het realiseren van systeemintegratie en rationalisatie.

5.3. Welke fasen zijn er bij systeemintegratie? Wanneer sprake is van een gediversifieerd systeemlandschap, is het realiseren van uniformiteit in processen en procedures niet eenvoudig. De financiële crisis creëert druk op het resultaat van organisaties. De -8-

Risicobeheersing bij legacy-systeemintegratie beheersing van de kosten wordt hierdoor onder een vergrootglas gelegd. De keuze wordt gemaakt om het IT-landschap te rationaliseren en de legacy-systemen te integreren in de doelarchitectuur. De verandering vanuit deze legacy-systemen naar nieuwe systemen kan op meerdere manieren. Voorbeelden hiervoor zijn nieuwbouw, migratie, re-engineering of softwarerenovatie. Voor allen geldt dat uiteindelijk een overgang plaats zal vinden vanuit de legacy-systemen naar de doelarchitectuur. Wanneer de keuze wordt gemaakt om het IT landschap te gaan rationaliseren heeft dit flinke gevolgen voor een organisatie. Rationalisatie heeft een enorme impact op de omvang van het personeelsbestand. Dit wordt mede veroorzaakt doordat door rationalisatie processen, systemen en beheersing hiervan geüniformeerd kunnen worden en uiteindelijk minder redundantie in werkzaamheden aanwezig is. Deze besparingen worden eveneens inzichtelijk in een artikel van IBM over Empowering the CIO: Enabling smarter decisions with Application Portfolio Management[IBM 2011]. Figuur 1 uit dit artikel geeft dit grafisch weer.

Figuur 1: Enabling smarter decisions

Het proces van de systeemintegratie start op het moment dat het management heeft besloten over te gaan tot het uitfaseren/integreren van legacy-systemen. De impact op het systeem, de processen en organisatie begint vaak al wanneer de keuze voor overgang naar een nieuwe doelarchitectuur wordt gemaakt. Het overzicht van IBM toont dat de kosten van operations, onderhoud en systeemontwikkeling dalen gedurende het integratietraject naar de doelarchitectuur. Dit betreft echter enkel de doelstellingen, die middels rationalisatie en integratie gerealiseerd moeten worden. De huidige situatie van het systeemlandschap, operationele kosten en ontwikkelingskosten zijn inzichtelijk te maken. De projectie van de verwachte kosten voor het doelsysteem is ook redelijk te prognosticeren. Het verloop van de integratieperiode is minder rechtlijnig. De timing en inrichting van deze fase zijn zeer divers. Oorzaken hiervoor liggen onder andere in de gekozen aanpak. Hierdoor valt te stellen dat de dalende lijn zoals geschetst in Figuur 1 niet altijd dalend lineair verloopt. Of een besparing op cost of operations plaatsvindt tijdens de integratiefase is sterk afhankelijk van de legacy-systeemintegratie strategie. Een eventuele besparing moet in lijn zijn met het belang van het legacy-systeem voor de organisatie. Figuur 1 schetst dat in de integratiefase nog wordt geïnvesteerd in aanpassingen van de legacy-systemen. In de praktijk blijkt vaak dat slechts een beperkt budget beschikbaar is voor het onderhouden van de legacysystemen. Ontwikkeling wordt beperkt tot het voldoen aan weten regelgeving en het oplossen van productieverstoringen. Naast de financiële beschouwing kan vanuit andere perspectieven naar de legacy-systeemintegratie worden gekeken. Voorbeelden zijn het beheersen van de continuïteit van de core-business of een risicobeheersingsperspectief, waar IT een onderdeel van is. Risico’s die zich voor kunnen doen zijn bijvoorbeeld het beheersen van de integriteit van systemen bij parallelle omgevingen. Problemen met de beschikbaarheid en kwaliteit van resources. Niet voldoen aan weten regelgeving, omdat zich wijzigingen -9-

Risicobeheersing bij legacy-systeemintegratie voordoen die niet worden verwerkt in legacy-systemen. Security risico’s omdat support ontbreekt op verouderde systemen. Figuur 1 geeft wel een heldere basis om te concluderen dat het systeemintegratieproces van de legacysystemen uit meerdere fasen is opgebouwd. Passende maatregelen voor het beheersen van de risico’s aangaande de legacy-systemen gedurende het integratietraject en de specifieke fasen zijn zoals eerder aangegeven nauwelijks beschreven en uitgewerkt in literatuur. Uit mijn waarnemingen over hoe een dergelijke overgang tot stand komt, concludeer ik dat 4 fases te onderkennen zijn rondom legacysysteemintegratie doelstellingen. Deze fasen zijn te benoemen als huidige situatie, geplande uitfasering, in transitie en uitgefaseerd. Wanneer vanuit het oogpunt van beheersing naar deze fases wordt gekeken hebben deze een specifiek risicoprofiel. Onderstaand worden per fase mogelijke beheersmaatregelen behandeld passend bij het risicoprofiel. Dit is tevens de basis voor het opstellen van een specifiek risicoprofiel.

5.4. Verschillende faseringen In dit hoofdstuk wordt per fase toegelicht voor welke risico’s in de literatuur aanknopingspunten zijn aangetroffen in het kader van risicobeheersing. Het is van belang inzicht te hebben in het verloop van het legacy-systeemintegratieproces vanuit een risicoperspectief om deze beheersmaatregelen te kunnen plaatsen in het proces. Wanneer de keuze is gemaakt dat een systeem vervangen gaat worden of dat integratie gaat plaatsvinden, dan wijzigt mogelijk een aantal zaken in de beheersing. De transitie van huidige situatie naar geplande uitfasering betekent dat zowel het financiële belang als het business belang van de applicatie in eerste instantie gelijk blijft. Een verschuiving van effort en budget voor het legacy-systeem en de processen hier omheen gaat plaatsvinden. Onderzoek naar de veranderende situatie voor een aantal applicaties in mijn werkomgeving wijst uit dat de aandacht verschuift naar het nieuwe systeem. Het budget voor beheer en ontwikkeling op het legacy-systeem is gedaald. Bezuinigingen vinden plaats op het proces. Hierdoor neemt mogelijk het aantal beheersmaatregelen af, waardoor het risico toeneemt. Een schematische weergave van het resultaat van deze analyse is opgenomen in Figuur 2.

Situatieverloop

Beheersing

Budgetten

Impact

Risico

Huidige situatie

Geplande uitfasering

In transitie

Uitgefaseerd

Fasen Figuur 2: situatieverloop

Besparingen op IT-beheersmaatregelen en het korten van beschikbare budgetten, worden mogelijk direct doorgevoerd. Hierdoor is een verschil te zien in de beheersing tussen een systeem in de “huidige situatie” en de verandering naar geplande uitfasering. Voorbeelden zijn aanpassingen van service levels en afname van - 10 -

Risicobeheersing bij legacy-systeemintegratie beschikbare resources, omdat externe inhuur wordt beëindigd of resources op het ontwikkelen van de doelarchitectuur worden ingezet. Bij de overgang van geplande uitfasering naar in transitie betreft het voornamelijk een afname van investeringen. Daarnaast wordt vaak verder bezuinigd op het uitvoeren van IT-beheersmaatregelen en gaat de beschikbaarheid en inzet van resources verder dalen. Hierdoor kunnen de risico’s op de bestaande omgeving toenemen. De gekozen legacy-systeemintegratie is ook van invloed op de toename van de risico’s, naarmate de ontwikkeling van het nieuwe systeem vordert. Een van de strategieën kan zijn dat parallel wordt gedraaid met twee omgevingen, met alle bijbehorende processen en beheersomgevingen die van toepassing zijn. Een andere strategie kan het gelijktijdig functioneren van de systemen op één infrastructuur zijn, waardoor risico’s met betrekking tot juiste verwerking en integriteit van de data zullen toenemen. Bij een overgang van in transitie naar uitgefaseerd is het belang van het systeem gedaald. Hierdoor nemen ook de risico’s af. De risico’s verdwijnen nog niet, omdat het verwijderen van systemen en data ook beheerst moet plaatsvinden. Daarnaast zijn er nog risico’s met betrekking tot weten regelgeving.

5.4.1.Huidige situatie Om te komen tot het besluit van legacy-systeemintegratie dient een analyse te worden uitgevoerd op het bestaande systeemlandschap. Hierbij moet worden geïnventariseerd welke systemen niet passen binnen de doelarchitectuur. Daarna dient objectief bepaald te worden of een legacy-systeem in aanmerking komt voor systeemintegratie. Een logisch startpunt hierbij is het constateren in welke fase van haar life cycle een applicatie zich bevindt. Daarna moet een analyse uitgevoerd worden waarin wordt bepaald welke oplossing het best gekozen kan worden voor het integreren van het legacy-systeem. Hiervoor zijn verschillende scenario’s denkbaar. Het Amerikaanse ministerie van defensie heeft hiervoor het Software Re-engineering Assessment Handbook ontwikkeld. Dit handboek biedt richtlijnen voor het kiezen van de beste oplossingsrichting voor het uitfaseren en integreren van legacy-systemen. 5.4.1.1. Application Portfolio Management Omdat legacy-systemen niet generiek zijn, is de route om te komen tot uitfasering eveneens niet generiek. De trigger om te komen voor geplande uitfasering zou onderdeel moeten zijn van gedegen IT-portfolio management. [Maat&Vogt 1998] toont in figuur 3 welke aspecten er bijdragen aan de keuze om legacysystemen te rationaliseren.

Figuur 3: aspecten rationalisering legacy-systemen

Te zien is dat portfolio management de basis kan vormen voor de start van de verandering. Uit een portfolioassesment kan blijken dat een systeem in aanmerking komt voor verandering. In de ring om portfoliomanagement heen staan verschillende strategieën die de basis zijn voor de verandering. - 11 -

Risicobeheersing bij legacy-systeemintegratie Softwarerenovatie is een samenspel van strategieën en is daarom als een basis onder deze strategieën weergegeven. Bedrijfsprocesrenovatie is tevens als aparte balk benoemd omdat dit eveneens een aanleiding kan zijn voor uitfasering. Application portfolio management draagt zorg voor het geordend en gestructureerd omgaan met de applicaties waar een organisatie gebruik van maakt. In portfolio management worden de financiële baten afgewogen tegen de operationele- en onderhoudskosten van de applicaties [IBM 2011]. Aspecten waarop applicaties gemeten kunnen worden zijn Return on Investment, Total Cost of Ownership, Total Economic Impact Business Value of IT. De uitkomsten van dergelijke metingen bepalen mede of systemen in aanmerking komen voor uitfasering en de passende strategie. Het beoordelen van de portefeuille is een continu proces.

Figuur 4: [IT investment management]

Door op een gestructureerde wijze het applicatielandschap vanuit onder andere financieel perspectief te beheersen, ontstaat ruimte om op een beheerste wijze de transitie vorm te geven. Dit betekent dat een integratie/transitie roadmap opgesteld kan worden. Hierbij is het van belang dat deze roadmap niet enkel de investeringen in de nieuwe systemen bevatten, maar ook de investeringen die benodigd zijn voor het realiseren van de integratie en het beheersen van de oude legacy-systemen. Figuur 4 geeft weer dat op basis van gemaakte keuzes, de investeringen in de integratie eveneens moeten worden bestuurd in investment- en project portfolio management.

- 12 -

Risicobeheersing bij legacy-systeemintegratie 5.4.1.2. Val-IT Het sturen op IT-investeringen, voor zowel de ontwikkeling van de doelarchitectuur als de ontwikkelingen in de legacy-systemen, is van belang tijdens de legacy-systeemintegratie. Hier is het Val-IT framework[ISACA VAL-IT] voor ontwikkeld. Val-IT is een governance framework wat algemeen aanvaarde richtlijnen en process ondersteuning biedt bij de evaluatie en selectie van It-enabled business investeringen. Daarnaast biedt het ondersteuning om beter te sturen op de realisatie van baten en het leveren van waarde vanuit deze investeringen. Het Val IT framework is gebaseerd op het COBIT framework. Om return on investment te realiseren worden de Val IT principes toegepast op management processen inclusief value governance, portfolio management, and investment management. Het doel van Val IT is: • Het definiëren van de relatie tussen IT, business en andere organisatieonderdelen met governance verantwoordelijkheden; • Het managen van het portfolio IT-enabled business investeringen; • Verhogen van de kwaliteit van business cases voor IT-ondersteunde business investeringen, waarbij de nadruk wordt gelegd op het definiëren van key financial indicatoren, het kwantificeren van indirecte baten en een uitgebreide bepaling van het downside risk Het is van belang kosten, risico’s en uitkomsten te relateren aan een gebalanceerd portfolio van IT-enabled business investeringen. Ook is het van belang investeringen te beoordelen over de gehele looptijd. In figuur 5 is wordt het kritieke pad van de IT-enabled investeringen opgenomen. Dit ook van toepassing bij legacy-systeemintegratie. Hierin wordt getoond dat IT solution delivery en IT operational implementation eerst moeten plaatsvinden alvorens overgegaan kan worden tot Business integration. Verder wordt inzichtelijk gemaakt dat het realiseren van de baten plaatsvindt na uiteindelijke realisatie. Het eerder inboeken van nog niet gerealiseerde baten is een van de grote risico’s in deze fase, omdat het invloed heeft op de inrichting van de bestaande business operation.

Figuur 5: [ISACA VAL-IT]

5.4.2.Geplande uitfasering Wanneer is bepaald dat een systeem in aanmerking komt voor integratie, dan zal dit proces gepland moeten worden. Wanneer het vernieuwen van het applicatielandschap onderdeel is van een continu proces, dan zal het startpunt voor legacy-systeemintegratie ook voortkomen uit bijvoorbeeld application lifecycle management. Om vervolgens op een beheerste en gestructureerde wijze om te gaan met het plannen van de migratie, is te verwachten dat in de literatuur informatie beschikbaar is over deze periode in life cycle management. Dit is echter zeer beperkt het geval. Daarnaast heeft legacy-systeemintegratie zeker raakvlakken met systeemontwikkeling en kwaliteitsbewaking van systeemontwikkeling. Deze onderdelen sluiten echter niet aan op het specifieke risicoprofiel voor legacy-systeemintegratie, omdat deze zich voornamelijk richten op de doelarchitectuur. Voor het plannen van een integratie is dan ook niet veel literatuur beschikbaar. 5.4.2.1. System development lifecycle Een kwaliteitsbeheersingsframework om te bepalen of een legacy-systeem in aanmerking komt voor systeemintegratie verwacht je aan te treffen in de methodieken die de levensfase van systemen bepalen en controleren. Het blijkt echter dat hierin de aandacht zich vooral richt op de ontwikkeling van het nieuwe systeem. De ontwikkeling van software vindt al tijden plaats. Het samenspel van hardware, platform en database bepaalt mede of er sprake is van een gemoderniseerd systeem. Door het ministerie van justitie in de Verenigde Staten is de levensloop van een informatiesysteem vastgelegd.

- 13 -


Figuur 6: [US DOJ 2003]

Volgens de ontwikkelmethodiek van het Amerikaanse ministerie van justitie bestaat de levensloop van een systeem uit 10 fases. Waarbij uitfasering de laatste fase van de Systems Development Life Cycle is. In de meeste omgevingen is de focus vaak gelegd op de eerste 9 stappen uit de levenscyclus. Literatuur over de te nemen stappen bij de zogenoemde “disposition” van een systeem is zeer beperkt. Volgens de SDLC cycle omvat de laatste stap een aantal aspecten. Deze fase draagt zorg voor de geordende uitfasering van het systeem. Daarnaast dient zorg gedragen te worden voor het veiligstellen van de cruciale informatie over het systeem. Op deze wijze kan indien nodig het systeem in de toekomst weer hergebruikt worden. Als belangrijkste onderdeel van deze fase wordt het veiligstellen van de data uit het systeem benoemd, zodat deze op een beheerste wijze beschikbaar gesteld kan worden aan het nieuwe informatiesysteem. Verder dient de data uit het systeem gearchiveerd te worden om te kunnen voldoen aan weten regelgeving en voor beschikbaarheid van de gegevens in de toekomst. Voor het inventariseren van de risico’s geeft dit een aardige eerste aanzet, maar het helpt onvoldoende bij het inventariseren van de risico’s tijdens de verschillende fasen.

5.4.2.2. Enterprise Architecture Voor het integreren en migreren van de legacy-systemen bestaat een relatie met de nieuw in te richten omgevingen. Een van de methodieken die ontwikkeld is, is het Deloitte Enterprise Architecture Framework [Deloitte]. Dit framework moet bijdragen aan de ontwikkeling van de nieuwe doelarchitectuur. Dit proces is weergegeven in figuur 7.

- 14 -


Figuur 7: [Deloitte]

Het model geeft weer dat de toekomstige omgeving moet aansluiten op de businesstransformatie, moet zorgen voor kostenbesparingen, procesoptimalisatie en rationalisatie. Ook in dit model is relatief weinig aandacht voor de legacy-systemen en de integratiestrategieën. Het model is voornamelijk gericht op de transformatie die de doelarchitectuur moet opleveren.

5.4.2.3. SRAH Wanneer de keuze voor uitfasering en/of integratie is gemaakt is het van belang op een juiste en eenduidige manier vast te stellen welke strategie hiervoor het best gebruikt kan worden. Het eerder genoemde Software Re-engineering Assessment Handbook (SRAH) van het Amerikaanse ministerie van defensie biedt hiervoor een drietal assessments. Dit zijn assessments op het gebied van techniek, economisch perspectief en een management guidance bij het nemen van een beslissing op basis van het technische assessment gecombineerd met het economische assessment. Deze assessments besteden aandacht aan een risico dat wordt gelopen bij het maken van keuzes met betrekking tot de systeemintegratie van legacy-systemen. Een van deze risico’s is het maken van een onjuiste keuze voor het te integreren legacy-systeem. Want welk systeem is de beste keuze om in aanmerking te komen voor systeemintegratie? Het SRAH geeft middels een onderbouwde analyse een goed handvat voor het vaststellen van de volgordelijkheid, daarnaast ondersteunt het de uitvoering van deze analyse. Wat in het assessment niet wordt meegenomen is de operationele noodzaak en efficiency van de systemen. Wel geeft het een gedegen representatief oordeel over mogelijk beste volgorde legacysysteemintegratie. Een belangrijk risico volgens het SRAH betreft het feit dat de organisatie niet klaar is voor de verandering. Hiervoor hebben ze een assessment opgesteld. De vragenlijst om te toetsen of een bedrijf klaar is voor reengineering is opgenomen in bijlage 3. De belangrijkste thema’s waar op getoetst wordt zijn: • Organisatorische aspecten • Inrichting van het re-engineering team • Tool analyse • Training • Inrichting van nieuwe beheerprocessen • Ontwikkelstandaarden Uitgangspunt hierbij is dat wanneer de score vanuit de vragenlijst te laag uitpakt op deze specifieke aspecten eerst maatregelen getroffen moeten worden om het juiste volwassenheidsniveau te bereiken. - 15 -

Risicobeheersing bij legacy-systeemintegratie Alvorens over te gaan om de juiste technische oplossing vast te stellen. Het technisch assessment bevat een drietal vaste oplossingsstrategieën. Deze strategieën zijn re-engineer, Reverse-engineer en status quo. De re-engineering kent een verzameling van vijf deelstrategieën. Het betreft hier de deelaspecten: • Herdocumenteren • Vertalen van broncode • Data reengineering • Retarget • Restructure De beste strategie wordt bepaald op basis van vragenlijsten, het is aan te bevelen deze uit te zetten bij meerdere kennisexperts om bepaalde vooroordelen zo veel mogelijk uit te sluiten en een objectieve analyse na te streven.

5.4.3.In transitie Voorgaande fasen waren vooral gericht op het bepalen of systemen in aanmerking komen voor systeemintegratie en de hierbij te volgen aanpak. De fase die volgt is de transitiefase. In deze fase moet onder andere het migratieverloop worden bepaald. Dit kan plaatsvinden met behulp van migratiestrategieën, daarnaast moet een beheerste conversie van data plaatsvinden. De reguliere IT-beheersmaatregelen voor de legacy-systemen moeten eveneens op pijl blijven. 5.4.3.1. Conversies In frameworks die conversie ondersteunen lijkt het logisch meer kaders te vinden hoe te handelen bij de integratie van systemen. Nader onderzoek wijst uit dat ook deze frameworks zich over het algemeen richten op de daadwerkelijke conversie en de overgang naar het nieuwe systeem. De aandacht voor het latende systeem is dan ook zeer beperkt. Zo blijkt ook uit het IT Control framework voor dataconversies [Korff en Verberne 2010]. De normen waarmee rekening gehouden dient te worden beperken zich tot de rechten in het latende systeem en het beschikbaar blijven van historische data. Ook in [Maat et al 2008] is weinig tot geen aandacht voor de latende systemen met betrekking tot migraties. De aandacht gaat vooral uit naar de juistheid en volledigheid van de conversie.

5.4.3.2. Legacy migratie strategieën Voor het juist kunnen uitvoeren van migraties van legacy omgevingen naar nieuwe omgevingen wordt doorgaans gebruik gemaakt van legacy migratiestrategieën. In deze strategieën is de aandacht vooral gericht op de transformatie vanuit het nieuwe systeem. Echter bevinden zich in de aandachtpunten voor de transformatie belangrijke aspecten waar rekening mee gehouden dient te worden op de oude omgeving. Legacy-systeemintegratie is een fenomeen wat al lang speelt. In [Bisbal et al 1999] is beschreven dat legacy-systemen een enorme, langdurige zakelijke investering vertegenwoordigen. Helaas zijn deze systemen vaak langzaam en onvoldoende schaalbaar. Het vastleggen van gegevens uit een legacy-systeem op een manier die organisaties kan ondersteunen in de toekomst, is belangrijk. In 1999 was dit nog een relatief nieuw onderzoeksgebied. Deze migratiestrategieën zijn tot op heden nog steeds onderbelicht. Twee methoden zijn bedacht voor de migratie van Legacy. Deze twee benaderingen zijn de " Chicken Little Strategie " [Brodie 1995] en de "Butterfly methode"[Brodie 1995] en [Aebi 1994]. Naast deze twee theorieën bestaat nog de veel gebruikte Big Bang theorie[Eason 1988]. Genoemde strategieën zijn in de hierop volgende paragrafen nader uitgelegd. 5.4.3.3. Chicken Little Strategie De eerste strategie " Chicken Little Strategy ", laat het legacy-systeem en doelarchitectuur samenwerken tijdens de migratie met behulp van een bemiddelende module. Deze strategie herbouwt de legacy-systemen geleidelijk op het doelsysteem. De doelarchitectuur is in eerste instantie vrij klein, maar groeit als de migratie vordert. Deze werkwijze begint met de analyse van het legacy-systeem gevolgd door het ontwerpen van de doel-interface, database en applicatie. Vervolgens wordt de oude database stapsgewijs gemigreerd en vindt uiteindelijk een overgang naar de doelarchitectuur plaats. De strategie om hiertoe te komen bevat 11 stappen. Te weten: 1: 2: 3:

Incrementeel analyseren van het legacy-systeem; Incrementeel ontleden van het legacy-systeem; Incrementeel ontwerpen van de doelinterfaces; - 16 -

Risicobeheersing bij legacy-systeemintegratie 4: 5: 6: 7: 8: 9: 10: 11:

Incrementeel ontwerpen van de doelapplicaties; Het stapsgewijs ontwerpen van de doeldatabase; Het in etappes installeren van de doelomgeving; Ontwikkelen van de per deel benodigde gateways en installeren; Getrapt migreren van de legacy databases; Stapsgewijs migreren de legacy-applicaties Incrementeel migreren van de legacy interfaces In etappes overbrengen naar het doel informatiesysteem.

Met de interoperabiliteit van beide systemen ontstaat het risico dat het proces complex en traag wordt Brodie en Stonebraker hebben de Chicken Little Strategie uitgewerkt voor kritieke systemen binnen organisaties. Hierbij hebben ze een methodiek bedacht, waarbij de business impact op de reguliere processen zo laag mogelijk dient te zijn. Dit heeft echter wel impact op de complexiteit van het IT-landschap, omdat systemen gelijktijdig gebruikt moeten kunnen worden. Om dit te kunnen realiseren wordt gebruik gemaakt van een zogenaamde gateway. Deze gateway treedt dan op als een tussenlaag voor de communicatie tussen het legacy-systeem en het doelsysteem [Brodie 1995]. Onderstaand is het landschap zoals bedacht door Brodie en Stonebraker weergegeven.

Figuur 8: Chicken Little Strategie

Door het kiezen van deze migratiestrategie wordt het landschap complexer en foutgevoeliger. In figuur 8 is te zien dat er een Forward Gateway,ingericht is die de brug vormt tussen de nieuwe interface en de nieuwe database. Deze wordt gebruikt om transacties te verwerken in de doelarchitectuur. Voor de legacy-systemen is er een reverse gateway om de connectie te maken met de oude omgeving. Een van de nadelen is dat de structuren van de verschillende databases niet altijd overeen komen. Legacy systemen gebruiken bijvoorbeeld niet altijd een relationele database. Een mapping tussen het oude en het nieuwe systeem wordt hierdoor complex en brengt integriteits- en volledigheidsrisico’s met zich mee. Daarnaast ontstaat een risico op ongewenste redundantie. Om de data consistent te verwerken in de juiste database is er een tussenlaag bedacht. Deze zogenoemde coördinator controleert naar welke database de data getransporteerd moet worden. Gezien de complexiteit van het ontwikkelen van een nieuw doelsysteem lijkt het erg ambitieus om gelijktijdig een compleet vertaalportaal in te richten en de integriteit en volledigheid van de gegevensverwerking te waarborgen. Daarnaast ontstaan risico’s voor koppelingen met andere systemen in de keten, zoals de verwerking van de gegevens in de financiële systemen. Daarnaast heeft deze migratiestrategie impact op de te beheersen omgevingen die toeneemt in het gewijzigde landschap. Aanvullende maatregelen moeten getroffen worden, omdat er sprake is van uitbreiding voor de bestaande kritieke systemen.

- 17 -

Risicobeheersing bij legacy-systeemintegratie 5.4.3.4. Butterfly methode De ‘Butterfly Methode’, veronderstelt dat de legacy-systemen de gehele migratie werkzaam moet blijven en dat het legacy-systeem en doelarchitectuur niet samenwerken tijdens het migratieproces. Hierbij blijven in principe zowel het legacy-systeem als de doelarchitectuur parallel aan elkaar in gebruik en worden gedurende het migratietraject de legacydatabases overdragen naar de doeldatabase. Echter tijdens de parallelle run worden er geen transacties opgeslagen in de oorspronkelijke tabellen, maar worden deze vastgelegd in tijdelijke tabellen. Deze tabel wordt later overgebracht naar de doeldatabase. Tijdens de overdracht van de tijdelijke tabellen worden verdere transacties van de gegevens in andere tijdelijke tabellen opgeslagen. Dit levert een iteratief proces op. Dit proces gaat door tot de migratie van de laatste tabellen geen ernstige overlast voor de core business meer veroorzaken. Ook hier is de koppeling van de systemen in de keten, waaronder de doorkoppeling naar de financiële systemen, een verhoogd risico. In [Brodie 1995] en [Aebi 1994] wordt aangegeven, dat het migreren van de data management service de belangrijkste stap is voor een succesvolle migratie van legacy-sysytemen. Dit vanwege het feit dat hierin vaak de meeste problemen optreden. De Butterfly methode richt dan ook zijn aandacht op het migreren van deze stappen. Hoe men dit oplost is grafisch weergegeven in Figuur 9:

Figuur 9: Butterfly methode

De ontwikkeling van het doelsysteem vindt zoals te zien onafhankelijk plaats van het legacy-systeem. Wanneer gestart wordt met de migratie vindt er een freeze plaats van de legacy data store zoals weergegeven in Figuur 9. Hierin geldt de Data-Access-Allocator als een middelware component die de Legacy-systemen naar de juiste datastore geleidt. Dit kan de Legacy Datastore betreffen, maar ook de Temporary Store (TSn). Tevens wordt er een conversiestraat gebouwd, de zogenaamde Chrysaliser. Deze draagt zorg voor het migreren van de tijdelijke datastores naar de doelarchitectuur. Door deze methodiek is het dus eenvoudig meerdere omgevingen naast elkaar te laten functioneren.

5.4.3.5. Big bang theorie Daarnaast is het mogelijk gebruik te maken van de big bang theory, waarbij het nieuwe systeem geheel separaat wordt ontwikkeld naast de bestaande variant. [Eason 1988] beschrijft Big bang als volgt:”Wanneer iedereen die betrokken is bij het nieuwe systeem gelijktijdig over gaat tot het gebruiken van dit volledig - 18 -

Risicobeheersing bij legacy-systeemintegratie werkende nieuwe systeem op een specifieke datum”. Het realiseren van een juiste en uitgebreide planning is hierbij van cruciaal belang. Omdat er een specifieke datum voor go live is vastgesteld. Op deze datum moet alle functionaliteit beschikbaar zijn, tests zijn uitgevoerd, de data moet zijn geconverteerd, getest en gevalideerd. Daarnaast moeten alle nieuwe werkprocedures beschikbaar zijn en de medewerkers getraind. Dit alles in een gezamenlijk traject tot de specifieke datum. Planning en realisatie zijn vaak complex en deadlines worden vaak overschreden. Door de grote verandering in systemen en processen is het niet waarschijnlijk dat alles vanaf dag één vlekkeloos verloopt. Op basis van onderzoek is gebleken dat de performance van de organisatie een dip krijgt na de implementatie van een wijziging. Figuur 10 uit [Eason 1988] visualiseert deze dip:

Figuur 10: Initial dip phenomenon

De dip in performance wordt mede veroorzaakt doordat men nog moet wennen aan het nieuwe systeem en de vernieuwde processen. Na een periode van weken en of maanden normaliseert de performance en stijgt zelfs mogelijk. Wetende dat deze dip ontstaat, is het voor een organisatie dan ook van belang maatregelen te treffen. Enerzijds helpt het weten van het bestaan van deze dip het management om actief te sturen op performance en eventueel tijdelijk de capaciteit te verhogen. Anderzijds is het van belang risico’s in het aanloopproces van implementatie zo veel mogelijk te minimaliseren. Dit kan worden gerealiseerd door medewerkers offline te trainen, proefimplementaties te organiseren en het beschikbaar hebben van actieve coaches gedurende de implementatieperiode.

5.4.4.Uitfaseren De status uitgefaseerd kan op meerdere wijzen ingevuld worden. Echter het voornaamste is dat bestaande systeemfunctionaliteit en infrastructuur, uitgezet wordt en niet meer in gebruik is. Vanwege wettelijke eisen kan het voorkomen dat gegevens nog bewaard moeten worden. Hierdoor is het mogelijk dat een gegevensverzameling nog steeds beschikbaar moet zijn. Om dit te realiseren zijn meerdere mogelijkheden denkbaar. Bijvoorbeeld een Offline-back-up van de gehele gegevensverzameling of het gebruiken van geminimaliseerde database. Hierbij is het van belang de data goed te kwalificeren en te classificeren. Wanneer deze gegevensverzamelingen worden afgevoerd is hierop weten regelgeving van toepassing. Literatuur waar het uitfaseren van systemen in verwacht mag worden is IT-outsourcing. Vooral bij het overdragen van de huidige systemen, is te verwachten dat aandacht wordt besteed aan de systemen die uitgezet worden. Het blijkt echter dat bij de meeste exit strategieën er relatief geen tot weinig aandacht is voor het daadwerkelijk uitzetten van bestaande systemen. Veelal omdat deze worden overgedragen aan de nieuwe organisatie. 5.4.4.1. Compliancy Tijdens de uitfasering van een legacy-systeem zijn compliance aspecten een belangrijk aandachtspunt. In - 19 -

Risicobeheersing bij legacy-systeemintegratie eerste instantie is sprake van fiscale aspecten. Daarnaast zijn er nog eisen met betrekking tot de privacywetgeving. Wanneer sprake is van eventuele productrationalisaties of commerciële conversies van producten is het van belang juridische aspecten af te wegen. Bijvoorbeeld of de voorgenomen wijziging impact heeft op het afgesloten contract en geen negatieve gevolgen heeft voor de dienstverlening.

5.4.4.2. Fiscale wetgeving Vanuit de fiscale plicht geldt, dat een administratie minimaal 7 jaar moet worden bewaard, deze wetgeving is opgenomen in artikel 52 van de Algemene Wet inzake Rijksbelastingen (AWR). De zogenaamde administratieplichtigen zijn krachtens het eerste lid van dat artikel gehouden op zodanige wijze een administratie te voeren dat te allen tijde hun rechten en verplichtingen hieruit duidelijk blijken. Ook alle gegevens die van belang zijn voor de heffing van de belasting moeten inzichtelijk kunnen worden gemaakt. Een andere belangrijke bewaarplicht is de administratieplicht voor het bestuur van rechtspersonen. Krachtens artikel 2:10 BW is dat bestuur verplicht “om van de vermogenstoestand van de rechtspersoon en van alles betreffende de werkzaamheden van de rechtspersoon, naar de eisen die voortvloeien uit deze werkzaamheden, op zodanige wijze een administratie te voeren en de daartoe behorende boeken, bescheiden en andere gegevensdragers op zodanige wijze te bewaren, dat te allen tijde de rechten en verplichtingen van de rechtspersoon kunnen worden gekend”. Wanneer systemen gemigreerd worden, moeten keuzes gemaakt worden hoe om te gaan met historische data. Deze historische gegevens moeten worden bewaard. Mogelijkheden hiervoor zijn conversie van historische data naar een nieuw opslagmedium, beschikbaar houden van een oude omgeving of historische data mee migreren naar het nieuwe systeem. Conversie is op grond van artikel 52 lid 5 AWR onder de volgende voorwaarden toegestaan: • Volledigheid van de conversie van oude gegevens is gegarandeerd; • Juistheid van de uitvoering van de conversie is noodzakelijk; • Beschikbaarheid moet gedurende de volledige bewaarplicht geborgd zijn; • De geconverteerde gegevens moeten binnen redelijke tijd reproduceerbaar en leesbaar zijn; • De controle van de geconverteerde gegevens moet binnen redelijke termijn kunnen worden uitgevoerd; • De uitkomsten van de interne controle (onder andere de analyse van de verschillen tussen de originele en de overgezette bestanden) van de conversie dienen ook bewaard te blijven; • Authenticiteit en integriteit van gegevens moet gewaarborgd zijn. Voor de bewaarplicht van gegevens zijn richtlijnen meegegeven hoe om te gaan met het bewaren van gegevens. Hiervoor zijn een aantal NEN ISO normen als voorbeeld benoemd, deze zijn de standaard NEN ISO 15489: 2001 'Informatie- en archiefmanagement', de standaard NEN ISO 23081: 2006 'Processen voor informatie- en archiefmanagement - Meta-gegevens voor archiefbescheiden' en de standaard NEN 2082: ‘Eisen voor functionaliteit van informatie- en archiefmanagement in programmatuur'. 5.4.4.3. Wet bescherming persoonsgegevens Vanuit Artikel 10 van de Wet Bescherming Persoonsgegevens(Hierna WBP) [CBP artikelen]: geldt dat er een omgekeerde bewaarplicht is. Het betreft hier een vernietigingsplicht. Wanneer gegevens niet meer relevant zijn, dan dienen deze verwijderd te worden. Dit is terug te vinden in de WBP: 1. Persoonsgegevens worden niet langer bewaard in een vorm die het mogelijk maakt de betrokkene te identificeren, dan noodzakelijk is voor de verwerkelijking van de doeleinden waarvoor zij worden verzameld of vervolgens worden verwerkt. 2. Persoonsgegevens mogen langer worden bewaard dan bepaald in het eerste lid voor zover ze voor historische, statistische of wetenschappelijke doeleinden worden bewaard, en de verantwoordelijke de nodige voorzieningen heeft getroffen ten einde te verzekeren dat de desbetreffende gegevens uitsluitend voor deze specifieke doeleinden worden gebruikt. Om te voldoen aan bovenstaande regelgevingen moeten maatregelen getroffen worden. Tevens is in de WBP sprake van registratie van gegevensverzamelingen en bewerkingen. Hiervoor is het Wbpmeldingenregister [CBP artikelen] opgericht. Dit register bevat de verwerkingen van persoonsgegevens die bij het College bescherming persoonsgegevens zijn aangemeld. Het CBP heeft de plicht een openbaar register van deze meldingen bij te houden (art. 27 Wbp). Opname in het register is geen verklaring van het CBP dat de verwerking rechtmatig is. De verwerking is door het CBP niet inhoudelijk getoetst. Het blijft de verantwoordelijkheid van degene die meldt om de - 20 -

Risicobeheersing bij legacy-systeemintegratie verwerking op een juiste en volledige wijze te doen en om zich te houden aan de overige bepalingen van de Wet bescherming persoonsgegevens. Niet alle verwerkingen van persoonsgegevens zijn in dit openbare Wbp-meldingenregister terug te vinden. Verwerkingen kunnen ook gemeld worden bij een zogenaamde functionaris voor de gegevensbescherming (FG). Het CBP houdt een Register van Functionarissen voor de gegevensbescherming bij. De FG heeft eveneens de wettelijke plicht (art. 30 Wbp) een openbaar en kosteloos te raadplegen register bij te houden van de verwerkingen die bij deze functionaris zijn aangemeld. Verwerkingen kunnen ook zijn vrijgesteld van melding. Naast de wat meer algemene risico’s die voor de meeste systemen gelden, kan er natuurlijk sprake zijn van specifieke wetgevingsaspecten van verzekeringsproducten waar rekening mee gehouden moet worden. Bijvoorbeeld wetgeving ten aanzien van pensioenproducten, maar ook levensverzekering.

5.4.5.Cobit Bovenstaande literatuur heeft deelaspecten behandeld die de basis zijn voor het opstellen van een framework met risico’s en beheersmaatregelen. Standaarden voor het beheren van de applicatie lifecycle en software ontwikkelmethodieken bieden geen compleet beeld voor het uitvoeren van legacysysteemintegratie. Het uitvoeren van legacy-systeemintegratie toont echter de meeste gelijkenissen met een systeemontwikkelingtraject. Om de aangetroffen literatuur te clusteren en structureren naar risico’s en maatregelen is het raadzaam een basissituatie te hanteren. Het Cobit framework is een basissituatie, die in de markt als standaard is geaccepteerd en deze standaard is inmiddels ver doorontwikkeld. Cobit is een framework voor het gestructureerd inrichten en beoordelen van een IT-beheeromgeving [ISACA Cobit]. Cobit 4.1 kent 318 beheersdoelstellingen, die zijn gerangschikt naar vier beheerdomeinen: • Planning and Organization • Acquisition and Implementation • Delivery and Support • Monitoring De inhoud van deze onderwerpen is weergegeven Figuur 10:

- 21 -


Figuur 10: Cobit overview]

Doordat Cobit een uitgebreid framework is en de verschillende deelaspecten een groot aantal control objectives bevatten is het goed te gebruiken als een volledigheidscontrole op het beheersen van legacysysteemintegratie. Belangrijke onderwerpen die legacy-systeemintegratie risico’s afdekken zijn onderdeel van Cobit. Het raakt de inrichting van de governance. Aandacht voor strategie is aanwezig in Plan and Organise. Ook voor Delivery and Support, als ook de ontwikkeling van software in de Acquire and Implement fase zijn beheersmaatregelen aanwezig. Te concluderen valt dat het een goede basis om te starten met het specifiek maken van het risicoprofiel voor legacy-systeemintegratie.

- 22 -


6. Opbouw van het framework Zoals in het vorige hoofdstuk is beschreven biedt Cobit een algemeen framework voor de inrichting en beheersing van de enterprise IT. Het is een in de markt breed geaccepteerd framework, wat inmiddels door veel bedrijven is geïmplementeerd. Tijdens de literatuurstudie is vastgesteld dat de informatie, wanneer het legacy-systeemintegratie betreft, niet specifiek is op dit onderwerp is toegesneden. Wel is er op deelaspecten literatuur beschikbaar. Om te komen tot een framework is Cobit een goede basis, omdat het veel van de aspecten van legacysysteemintegratie raakt, wel blijkt dat de beheersdoelstellingen van Cobit niet altijd specifiek genoeg zijn. Dit betekent dat een aanpassing nodig is van zowel de risico’s uit het framework, als de maatregelen.

6.1. Opstellen risicoprofiel De beheersdoelstellingen, zoals deze in Cobit terug te vinden zijn, sluiten niet volledig aan bij het risicoprofiel van legacy-systeemintegratie. Op elementen in de control objectives is extra aandacht nodig voor het uitvoeren van deze specifiek benoemde control objectives. Daarnaast zijn beheersdoelstellingen in Cobit niet altijd specifiek genoeg, deze moeten gespecificeerd worden in kader van legacysysteemintegratie. Hier valt bijvoorbeeld te denken aan specifieke aandacht voor legacy-systemen in de control objectives of extra nadruk op de tijdigheid in de uitvoering van de control objectives. Vanuit dit oogpunt is een mapping opgesteld tussen de legacy-systeemintegratie risico’s en de beheersmaatregelen uit Cobit. Deze mapping is opgenomen in Bijlage 1. Het doel van deze mapping is om een basis te creëren voor het opstellen van beheersmaatregelen bij het specifieke risicoprofiel wat van toepassing is op het realiseren van legacy-systeemintegratie doelstellingen. Om vast te stellen of de onderkende risico’s aansluiten bij de praktijk heb ik workshops gehouden met vertegenwoordiging van interne en externe IT-auditors, functioneel- en applicatie beheerders, en key users business(een volledig overzicht van de functies van deelnemers aan de interviews en workshops is opgenomen in bijlage 4). In deze workshops is het risicoprofiel voor legacy-systeemintegratie op basis van Cobit beheersdoelstellingen getoetst. De uitkomsten van deze workshops zijn verwerkt in de in Bijlage 1 opgenomen mapping. De voornaamste aanpassingen en aanscherpingen zijn onderstaand nader uitgewerkt. De belangrijkste aanvullingen en aanscherpingen vanuit deze workshops op de mapping in Bijlage 1 hadden betrekking op het blijven voldoen aan de klantbehoefte (klant belang centraal) en het blijven voldoen aan de vraag vanuit de markt. Het risico hierbij is dat de legacy-systemen niet meer voldoen aan verwachtingen in de markt. Hiermee lopen organisaties het risico onvoldoende in te kunnen inspelen op veranderingen in de markt voor de legacy-omgevingen, wanneer deze in transitie zijn. Dit is terug te vinden in onderstaand risico: Cobit Omschrijving control objective

Risico

PO1.2

Aandacht voor alignement is enkel aanwezig voor de doelsystemen. Hierdoor is alignement van de huidige operationele processen geen onderdeel meer van de huidige IT planning. Hierdoor ontstaat een groter verschil tussen de huidige omgeving en de doelarchitectuur, wat integratie complexer maakt. Daarnaast ontstaat het risico dat Business-IT alignement verslechtert, door onvoldoende slagkracht in het realiseren van de doelarchitectuur, omdat de legacy-omgeving niet meer aansluit bij klant- en marktwensen. Afstemming met stakeholders (business) vindt onvoldoende plaats, waardoor IT-oplossingen en prioriteitstellingen niet overeenkomen met eisen van de business.

Business-IT Alignment Establish processes of bi-directional education and reciprocal involvement in strategic planning to achieve business and IT alignment and integration. Mediate between business and IT imperatives so priorities can be mutually agreed.

Vanuit de businessvertegenwoordiging werd de voornaamste zorg geuit over de beschikbaarheid van het budget voor verandering. Hierin merkte men dat de impact in hun situatie onder andere invloed had op de beschikbaarheid van systemen en oplostijden van incidenten en problemen, omdat service levels werden teruggezet, terwijl het belang van het systeem voor de organisatie niet was gewijzigd. Dit heeft geleid tot aanscherping van een viertal risico’s:

- 23 -

Risicobeheersing bij legacy-systeemintegratie Cobit Omschrijving control objective

Risico

PO1.1

Risico ontstaat dat besparingen meteen worden ingeboekt, terwijl hiervoor geen gedegen business case aanwezig is. Investeringen in legacy-systemen blijven uit, terwijl deze nog operationeel zijn en waarschijnlijk enige tijd blijven. Tevens ontstaat het risico dat er tijdens de integratiefase niet wordt geïnvesteerd en de aanpassingen die noodzakelijk zijn in de legacyomgeving niet zijn begroot. Specifieke aandacht voor legacy-systemen opnemen in het beoordelen en managen van de operationele systemen op basis van value management.

AI2.6

AI2.10

DS1.6

PO1.1 IT Value Management Work with the business to ensure that the enterprise portfolio of IT-enabled investments contains programmes that have solid business cases. Recognise that there are mandatory, sustaining and discretionary investments that differ in complexity and degree of freedom in allocating funds. IT processes should provide effective and efficient delivery of the IT components of programmes and early warning of any deviations from plan, including cost, schedule or functionality, that might impact the expected outcomes of the programmes. IT services should be executed against equitable and enforceable service level agreements (SLAs). Accountability for achieving the benefits and controlling the costs should be clearly assigned and monitored. Establish fair, transparent, repeatable and comparable evaluation of business cases, including financial worth, the risk of not delivering a capability and the risk of not realising the expected benefits. AI2.6 Major Upgrades to Existing Systems In the event of major changes to existing systems that result in significant change in current designs and/or functionality, follow a similar development process as that used for the development of new systems. AI2.10 Application Software Maintenance Develop a strategy and plan for the maintenance of software applications. DS1.6 Review of Service Level Agreements and Contracts Regularly review SLAs and underpinning contracts (UCs) with internal and external service providers to ensure that they are effective and up to date and that changes in requirements have been taken into account.

Legacy-systemen worden uitgesloten voor grote wijzigingen, ongeacht het feit of deze wijzigingen benodigd zijn voor het continueren van de operations of een positieve businesscase hebben.

In de onderhoudsplannen wordt geen aandacht besteed aan het omgaan met legacy-systemen en legacy-systemen die deel uit maken van een integratietraject. Service levels worden niet tijdig of onterecht aangepast, wanneer er veranderingen optreden in de legacy-omgeving.

Daarnaast werden de grootste risico’s gezien in de beschikbaarheid van resources. Dit komt deels doordat kennis voor oudere systemen al schaars is. Door de financiële crisis en bezuinigingen die doorgevoerd moeten worden, wordt externe inhuur bemoeilijkt. Ook de balans tussen het inzetten van mensen met kritieke kennis inzetten voor legacy-systemen en voor de IT-vernieuwing speelt hierbij een rol. De risico’s uit de mapping werden niet specifiek aangepast, maar er werd wel extra attentie gevraagd voor deze risico’s. In de mapping is het risicoprofiel voor legacy-systeemintegratie gevormd. Vanuit deze basis zijn de te verwachten normen ten behoeve van de beheersing opgesteld. Het resultaat van de mapping en de praktische toetsing van de theoretische risico’s is opgenomen in Bijlage 1.

- 24 -


6.2. Opstellen normen Om te komen tot het normenkader heeft de mapping van de Cobit control objectives met de specifieke risico’s voor legacy-systeemintegratie als basis gediend. Dit risicoprofiel is gehouden tegen de uitkomsten van de uitgevoerde literatuurstudie, die een basis moet vormen voor het opstellen van normen ten aanzien van de beheersing. Door het kiezen van Cobit control objectives is er een vrij volledige basisset van beheersmaatregelen aanwezig in het framework. Doordat het risicoprofiel specifiek is en er vanuit de literatuur slechts op beperkte aspecten informatie te vinden is over te treffen beheersmaatregelen zijn specifieke maatregelen toegevoegd. Ook is er een set van maatregelen, waarvoor geldt dat de reguliere invulling van de Cobit control objectives een redelijk invulling geven, echter vanuit het risicoprofiel wordt aanvullende aandacht gevraagd bij specifieke kwaliteitsaspecten. Bijvoorbeeld de tijdigheid bij het uitvoeren van de control objectives. Het normenkader is opgenomen in Bijlage 2. Ook voor dit normenkader heeft wederom een praktische toets plaatsgevonden. Hiervoor zijn eveneens sessies gehouden, waarbij interne- en externe auditors, IT-ers en business vertegenwoordigers aanwezig waren. Hier hebben een aantal aanvullingen en aanscherpingen van de maatregelen plaatsgevonden. Deze zijn verwerkt in het in Bijlage 2 opgenomen normenkader. Deze aanpassingen zijn onderstaand nader uitgewerkt. De belangrijkste conclusies waren dat de maatregelen goed aansluiten bij het feit dat er vanuit een strategie een duidelijke lijn en bijbehorende beheersing moeten zijn, wanneer er sprake is van legacy-integratie. Vanuit verzekeraars gezien moet tegenwoordig echt de slag gemaakt worden naar het verder digitaliseren van de dienstverlening en wordt legacy-systeemintegratie niet per systeem uitgevoerd. Integraties worden simultaan uitgevoerd, wat het geheel nog complexer maakt. Het belang van de maatregelen ten aanzien van de governance op de integratie werden als zeer groot onderkend.

Cobit Risico control objective PO1.1 Risico dat de business case te positief is begroot, omdat besparingen meteen worden ingeboekt en investeringen in legacysystemen niet zijn opgenomen, terwijl deze nog operationeel zijn en waarschijnlijk enige tijd blijven. Hierdoor ontstaat het risico dat aanpassingen die noodzakelijk zijn in de legacyomgeving niet zijn voorzien.

PO1.4

Aanvullende maatregelen

Een framework wordt gehanteerd voor het opstellen van een gedegen business case, zoals Val-IT. Kosten en investeringen in de legacy-omgeving zijn opgenomen in de business-case voor het ontwikkelen van een doelsysteem. Deze kosten en investeringen omvatten minimaal: minste: - Beschikbaarheid van resources - Aanpassingen in legacy-systemen, waaronder weten regelgeving - Business-IT-alignment aanpassingen - Budgettering voor het behouden van een kwalitatief voldoende beheersing binnen de runomgeving In de businesscase zijn meerdere scenario's (best case, worst case) uitgewerkt ten aanzien van de realisatie van de nieuwe doelomgeving en de variabele kosten voor de legacyomgeving zijn hiervoor meegenomen. De business case omvat uitwerkingen omtrent de gekozen legacy-integratiestrategie, de benodigde kosten in tijd, middelen en geld zijn hierin voldoende vertegenwoordigd. Kosten en Servicelevels voor legacy-systemen zijn opgenomen in de business-case, waarbij de risico's en het belang van de systemen voor de organisatie op juiste wijze zijn opgenomen. De Integratiestrategie is geen onderdeel van het De organisatie beschikt over een legacystrategische plan, de aandacht voor methodieken integratie strategie en/of deze maakt onderdeel en omgang met migratie is zeer beperkt. Hierdoor uit van het strategisch plan. Hierin zijn op zijn ontstaat een risico voor de beheerste integratie, minst verschillende in de markt bekende - 25 -

Risicobeheersing bij legacy-systeemintegratie omdat deze onvoldoende management attention verkrijgt.

PO1.5

PO4.3

migratiestrategieën opgenomen zoals Chickenlittle, Butterfly en Big bang. Het strategisch plan biedt richtlijnen om vast te stellen hoe bepaald wordt welke systemen in aanmerking komen voor legacy-integratie. Daarnaast biedt het richtlijnen om de prioritering van de systemen te bepalen. Beschikbare methodieken hiervoor zijn Application Portfolio Management en het Software Reengineering Assessment Handbook. De juiste stakeholders zijn betrokken bij het opstellen van de legacy-integratie strategie. Legacy-systemen en vooral de integratie van In de tactische IT-planning is voldoende deze systemen zijn geen onderdeel van de aandacht voor legacy-systemen. Deze tactische IT planning. Hierdoor kunnen problemen aandacht is in lijn met het belang van deze ontstaan ten aanzien van de benodigde IT systemen voor de organisatie, risk appetite ten initiatieven, beschikbaarheid van resources en het aanzien van deze systemen, vereisten vanuit gebruik van resources. weten regelgeving. In het tactisch IT-plan wordt aandacht besteed aan de verdeling van kritieke kennis over legacy-systemen en doelsystemen. Een stuurgroep met voldoende mandaat, met Een stuurgroep met de juiste vertegenwoordiging van de juiste stakeholders is vertegenwoordigers (Business, IT, Project) is niet aanwezig, waardoor de sturing op ingericht die zicht houdt op de beheersing van prioriteitstelling, het -beleid en de totale integratie, waarbij de risico's, integratiestrategieën ontbreekt. voortgang en problemen voor zowel de nieuwe omgeving als de legacy-systemen worden gemonitord

Daarnaast werd eveneens het belang onderschreven van de maatregelen met betrekking tot het daadwerkelijk uitzetten van een systeem. Vaak beperkt dit zich tot een vrij simpel verzoek. Hier ontstond een interessante discussie tussen IT en business vertegenwoordiging, waarbij de IT-afdeling aangaf netjes te waarschuwen het verzoek tot beëindiging door te voeren zonder bijvoorbeeld het maken van een laatste back-up (en overige mogelijk te verwachten maatregelen bij het uitvoeren van een dergelijk proces). Vanuit de business werd hierop gereageerd dat er verwachtingen waren dat er vanuit IT meer gestuurd werd op het beheerst uitzetten van een systeem. Uiteindelijk resulteerde het in een discussie over eigenaarschap versus goed huisvaderschap/professioneel IT beheer. De generieke consensus was echter wel dat een overzicht met te treffen maatregelen en het beleggen van taken, bevoegdheden en verantwoordelijkheden in het proces tot uitschakelen van een systeem, vervelende consequenties van het uitschakelen kan voorkomen. Op dit punt is een aantal maatregelen in het framework toegevoegd en aangescherpt. Voor een communicatieplan en communicatie over daadwerkelijke uitfasering werd aandacht gevraagd, deze zijn opgenomen bij de maatregelen: Cobit Risico control objective DS11.4 Bij het uitfaseren van systemen ontstaat een verhoogd risico dat data en hardware verwijderd/verkocht/vernietigd worden, waarbij in het uitvoeren van deze acties niet wordt voldaan aan weten regelgeving.


Een impactanalyse is uitgevoerd voor het uitzetten van legacy-systemen. Waarbij minimaal de volgende gegevens zijn vastgelegd: - Operating System - Database en instantie - Servernaam - IP adres - CMDB nummer - Overzicht van systeemkoppelingen - Overzicht van Batchjobs - Eigenaar van het systeem. - Analyse of er nog actieve applicaties zijn op de onderliggende hardware en software - 26 -

Risicobeheersing bij legacy-systeemintegratie (platform en database) - Analyse of er nog delen van de applicatie in gebruik zijn.

Een proces is ingericht voor het uitzetten van systemen. Dit proces bevat tenminste de volgende stappen alvorens deze daadwerkelijk wordt uitgeschakeld: - Stel vast dat een recente back-up beschikbaar en leesbaar is (bijvoorbeeld in de vorm van platgeslagen databases, zodat de oude infrastructuur niet meer noodzakelijk is bij het benaderen van historische gegevens). - Stel vast dat een akkoord aanwezig is van de systeemeigenaar. - Stel vast dat de software en systeeminstellingen van de legacy-omgeving zijn veilig gesteld. Voor eventuele fallback of toekomstig gebruik. - Een impactanalyse is uitgevoerd voor het uitzetten van het legacy-systeem. - Een communicatieplan over het uitzetten van een systeem is aanwezig. Een proces is ingericht waarbij data wordt gewist(en overschreven) van hardware, voordat deze wordt verkocht / afgevoerd. Een ander punt wat nadrukkelijk werd besproken waren de eisen ten aanzien van weten regelgeving. Hiervan werd duidelijk dat de ketenverantwoordelijkheid voor het voldoen aan deze eisen niet in voldoende mate werd gevoeld. Deelaspecten van de verantwoordelijken waren slechts bekend. Dit resulteerde niet in aanpassingen in het framework, maar men gaf aan dat het hielp bij de awareness inzake eisen vanuit weten regelgeving. Cobit Risico control objective DS11.3 De herkomst van opgeslagen data en media is niet terug te leiden naar de oorspronkelijke bron. Daarnaast is de bruikbaarheid en integriteit niet voldoende gewaarborgd.


Processen zijn ingericht om te waarborgen dat de data uit de legacy-systemen conform wet en regelgeving wordt gearchiveerd, waaronder: - Beschikbaarheid onder redelijke termijn - Bewaarduur conform wetgevingseisen - Authenticiteit en Integriteit zijn gewaarborgd. - Gegevens in het archief zijn geïndexeerd en herleidbaar naar systemen / processen.

Voor de controls uit het Cobit kwadrant monitor and evaluate bleek dat voor de relevante controls uit dit kwadrant sprake was van een gemene deler. De Cobit beheersdoelstellingen voldoen voor het beheersen van de risico’s, maar het is van belang deze frequent uit te voeren gedurende het legacy-systeemintegratie proces. Na de workshops en interviews ten aanzien van de toetsing van maatregelen heb ik het framework nog getoetst bij een tweetal ervaren projectleiders, die verantwoordelijk zijn voor integratieprojecten bij mijn werkgever. Deze gaven aan dat ze het belang van de aandacht voor legacy-systemen tijdens de integratie - 27 -

Risicobeheersing bij legacy-systeemintegratie wel onderkenden. Maar de praktijk wijst uit dat de blijvende beheersing van de legacy-systemen geen onderdeel is van het systeemontwikkelingsproject. Hierdoor draagt dit niet bij aan de doelstellingen en KPI’s die het project meekrijgt bij de realisatie van het project. Vanuit de ontwikkeling van het nieuwe systeem wordt het enkel als een belasting gezien, omdat aandacht wordt gevraagd voor het behoud van kennis en resources voor de legacy-systemen, dit is tegenstrijdig met de projectdoelstellingen. Daarnaast geven ze aan dat het daadwerkelijk uitfaseren van systemen vaak geen onderdeel is van het project. Dit geldt voor zowel conversieprojecten als systeemontwikkelingprojecten. De conclusie was dat het niet raadzaam is om dit te betrekken in de conversie- of systeemontwikkelingprojecten, omdat het anders enorme impact heeft op de doorlooptijd van deze projecten. Dit komt mede doordat de oude systemen nog deels beschikbaar moeten blijven als een fall-back scenario, maar ook omdat deze systemen soms nog in gebruik zijn door andere afdelingen binnen het bedrijf. Uiteindelijk zal het systeem door de organisatie wel een keer uitgezet moeten worden. Hiervoor werd aanbevolen, wanneer dit omvangrijk genoeg is, een project op te zetten voor het daadwerkelijk uitzetten van systemen. Omdat er toch veel specifieke aspecten bij komen kijken, zoals het beschikbaar houden van de oude data vanuit wetgeving en het daadwerkelijk uitzetten van systemen en verwijderen van data, hardware en software. Wanneer een apart project wordt opgestart voor het uitfaseren van systemen, dan bieden de maatregelen uit het hier ontwikkelde framework een goed handvat om dit project beheerst uit te voeren. Dit alles is verwerkt in het getoetste normenkader dat is opgenomen in bijlage 2.

- 28 -


7. Conclusie Een eenduidige definitie van legacy-systemen is niet beschikbaar. In de literatuur wordt vaak een traditionele visie gehanteerd. Het gaat dan over oude, logge en lang doorontwikkelde systemen, die uiterst stabiel zijn. In de modernere perceptie zijn het systemen die niet passen binnen de doelarchitectuur. Door de noodzaak om kosten van de operationele budgetten naar beneden te krijgen, is het integreren van legacy-systemen naar een lean ingerichte doelarchitectuur steeds belangrijker. De mate van integratie komt hiermee in een stroomversnelling. Vanuit de strategische-, tactische- en operationele sturing is de focus vooral gericht op het realiseren van de nieuwe doelarchitectuur. Besparingen dienen zo spoedig mogelijk te worden gerealiseerd. Dit heeft vaak zijn weerslag op de legacy-omgevingen. Mogelijke gebieden waarop dit zijn weerslag kan hebben zijn, beschikbaarheid van resources, stopzetten van het ontwikkelbudget voor legacy-systemen, afbouwen van beschikbaarheidseisen van de applicaties of het versoberen van de procesinrichting rondom deze applicaties. Doordat deze maatregelen vaak al worden getroffen terwijl het legacy-systeem nog operationeel is ontstaat een interessant speelveld rondom de risicobeheersing. In dit speelveld kan een (IT) auditor toegevoegde waarde leveren. Door toetsing, op objectieve wijze, van de risicobeheersing van deze legacysystemen kan de aandacht worden gevraagd voor de blijvende beheersing van de operationele- en ITrisico’s. Veel van deze risico’s hebben dan ook te maken met de inrichting van de IT-governance. In de Cobit methodiek komen deze voornamelijk terug in de planning & organisation fase. Hier zijn veel maatregelen voor beschikbaar. Een specificatie van maatregelen met betrekking tot deze risico’s is opgenomen in het framework in bijlage 2. Voor het maken van de juiste keuzes in de volgorde van te integreren systemen, het bepalen van de juiste integratiestrategie en om te toetsen of de organisatie wel klaar is voor het uitvoeren van een dergelijke integratiestrategie zijn goede hulpmiddelen beschikbaar. Deze hebben dan ook hun weerslag gevonden in het normenkader en gaan vooral in op economische, organisatorische en IT gerelateerde perspectieven. Natuurlijk bestaan andere aspecten die een rol kunnen spelen zoals interne politieke beslissingen (tegenstrijdige belangen tussen verschillende afdelingen) en het ontbreken van voldoende IT-business alignement, waardoor de slag op de markt wordt gemist of het vertrouwen van de klant wordt geschaad. Ook in deze situaties kunnen auditors toegevoegde waarde leveren. Dit kan door objectief de feiten vast te stellen, zodat het management op basis van de juiste, onafhankelijk vastgestelde feiten een weloverwogen beslissing kan nemen in de volgordelijkheid van legacy-systeemintegratie en de bijpassende legacymigratiestrategie. Gedurende het integratietraject zijn zowel de doelarchitectuur als de legacy-systeem aan verandering onderhevig. Tijdig inspelen op de veranderingen is voor de beschikbaarheid en integriteit van systemen en data van groot belang. Een auditor kan hier zowel preventief in de adviserende rol, als detectief door middel van het verschaffen van Assurance zekerheid bieden voor een beheerste integratie en overgang tussen twee systemen. Hierbij moet de focus niet enkel liggen op het doelsysteem, maar ook de beheersing van de risico’s met betrekking tot het legacy-systeem moet aandacht krijgen. Uitfasering van systemen zou moeten volgen na voltooiing van het system development project voor de doelarchitectuur. Hier zijn specifieke risico’s aan verbonden. Het beheerst uitzetten van het systeem is over het algemeen niet een van de doelstellingen van het ontwikkelproject en/of het conversieproject. Hierdoor is de aandacht voor het uitfaseren van systemen beperkt. Bij het uitzetten van systemen komt een flink aantal aspecten kijken, zoals het voldoen aan de bewaarplicht uit weten regelgeving, maar ook het veiligstellen van data, software en configuratie instellingen, zodat een fall-back scenario beschikbaar is voor het legacysysteem. Daarnaast moet ook data, hardware en software op een veilige wijze verwijderd worden. Vanwege het belang van weten regelgeving ten aanzien van bijvoorbeeld de bewaarplicht kan een (IT-)Auditor zekerheid bieden over de beheersing van deze risico’s. Dit levert toegevoegde waarde op, omdat verantwoordelijkheden voor dergelijke eisen vaak verknipt zijn over de business en IT-ketens. Door toetsing vanuit Audit ontstaat inzicht in de beheersing van de hele keten. Door de grote veranderingen gedurende het legacy-systeemintegratie proces is het geven van Assurance of het adviseren over de te treffen beheersmaatregelen tijdens deze veranderingen, zowel voor de (IT-) auditor als het management een interessant, belangrijk maar ook noodzakelijk onderwerp. Daarnaast is het een onderwerp wat vaak onderbelicht is, terwijl zich hier wel specifieke risico’s voor doen. Het uitvoeren van een Audit op de beheersing van systeemintegratie van legacy-systemen, draagt dan ook bij aan de zekerheid die het management krijgt over de uitvoering van de op dat moment nog steeds actieve en van belang zijnde productieomgevingen. - 29 -


8. Persoonlijke reflectie Discussies met collega’s over risico’s die wij zagen bij een organisatie die haar legacy-systemen integreert, zoals dat in mijn werkomgeving al geruime tijd het geval is, waren het startpunt voor het onderwerp van de scriptie. Bij aanvang van de scriptie had ik de verwachting dat informatie met betrekking tot legacysysteemintegratie breder beschikbaar was. Dit bleek niet het geval. Ook in de bestaande literatuur bleek op een zeer beperkt aantal deelaspecten informatie beschikbaar. Hierdoor ontstond een uitdaging om hiervoor een framework op te stellen uit de gefragmenteerde informatie. In de workshops die ik heb georganiseerd om het risicoprofiel en het framework te toetsen werden een aantal van mijn persoonlijke inzichten onderschreven. Het verschil van benadering en risicoperspectief van de verschillende deelnemers verbreedt je inzicht in de daadwerkelijke risico’s die zich voordoen. Deze workshops benadrukten voor mij eens te meer dat multidisciplinair samenwerking een van de belangrijkste aspecten is tijdens het realiseren van de legacy-systeemintegratiedoelstellingen. Daarnaast blijkt dat de organisatie-inrichting eveneens een cruciale rol speelt. Wanneer de organisatie gefragmenteerd is ingericht, vergroot dat de afstand tussen de verschillende disciplines en verhoogt de bureaucratie. Gevolg is dat mensen niet verder kijken dan de standaard paden en zich strikt beperken tot hun eigen verantwoordelijkheidsgebied, terwijl de risico’s vaak overstijgend zijn. Voor mijn persoonlijke werk als IT-auditor vind ik het van belang aandacht te vragen voor de continue beheersing van de legacy-systemen op een niveau dat representatief is voor het belang van deze systemen. Het is verleidelijk om voornamelijk stil te staan bij nieuwe ontwikkelingen, omdat dit vernieuwend en uitdagend is. Maar vergeet niet je huidige bezit te koesteren. Het verhogen van de awareness over de risico’s en beheersing van legacy-systeemintegratie is dus van belang. Het beschikbaar stellen van objectieve beelden over de risico’s en de impact van de gemaakte keuzes op de legacy-systemente maken keuze bij het management moeten dan ook bijdragen aan het verhogen van de awareness. In mijn toekomstige auditwerkzaamheden zal het vergroten van deze awareness dan ook aandacht krijgen.

- 30 -


Bijlage 1 Legacy Integratie Risico Framework Cobit control objective Planning & Organisation PO1.1

PO1.2

Detail control objective

Specifiek risico

PO1.1 IT Value Management Work with the business to ensure that the enterprise portfolio of IT-enabled investments contains programmes that have solid business cases. Recognise that there are mandatory, sustaining and discretionary investments that differ in complexity and degree of freedom in allocating funds. IT processes should provide effective and efficient delivery of the IT components of programmes and early warning of any deviations from plan, including cost, schedule or functionality, that might impact the expected outcomes of the programmes. IT services should be executed against equitable and enforceable service level agreements (SLAs). Accountability for achieving the benefits and controlling the costs should be clearly assigned and monitored. Establish fair, transparent, repeatable and comparable evaluation of business cases, including financial worth, the risk of not delivering a capability and the risk of not realising the expected benefits. Business-IT Alignment Establish processes of bi-directional education and reciprocal involvement in strategic planning to achieve business and IT alignment and integration. Mediate between business and IT imperatives so priorities can be mutually agreed.

Risico dat de business case te positief is begroot, omdat besparingen meteen worden ingeboekt en investeringen in legacy-systemen niet zijn opgenomen, terwijl deze nog operationeel zijn en waarschijnlijk enige tijd blijven. Hierdoor ontstaat het risico dat aanpassingen die noodzakelijk zijn in de legacy-omgeving niet zijn voorzien.

Aandacht voor alignement is enkel aanwezig voor de doelsystemen. Hierdoor is alignement van de huidige operationele processen geen onderdeel meer van de huidige IT planning. Hierdoor ontstaat een groter verschil tussen de huidige omgeving en de doelomgeving, wat integratie complexer maakt. Daarnaast ontstaat het risico dat Business-IT alignment verslechtert, door onvoldoende slagkracht in het realiseren van de doelomgeving, omdat de legacy-omgeving niet meer aansluit bij klant- en marktwensen. Afstemming met stakeholders (business) vindt onvoldoende plaats, waardoor IT-oplossingen en prioriteitstellingen niet overeenkomen met eisen van de business.

- 31 -

Risicobeheersing bij legacy-systeemintegratie PO1.4

IT Strategic Plan Create a strategic plan that defines, in co-operation with relevant stakeholders, how IT goals will contribute to the enterprise’s strategic objectives and related costs and risks. It should include how IT will support IT-enabled investment programmes, IT services and IT assets. IT should define how the objectives will be met, the measurements to be used and the procedures to obtain formal sign-off from the stakeholders. The IT strategic plan should cover investment/operational budget, funding sources, sourcing strategy, acquisition strategy, and legal and regulatory requirements. The strategic plan should be sufficiently detailed to allow for the definition of tactical IT plans. IT Tactical Plans Create a portfolio of tactical IT plans that are derived from the IT strategic plan. The tactical plans should address IT-enabled programme investments, IT services and IT assets. The tactical plans should describe required IT initiatives, resource requirements, and how the use of resources and achievement of benefits will be monitored and managed. The tactical plans should be sufficiently detailed to allow the definition of project plans. Actively manage the set of tactical IT plans and initiatives through analysis of project and service portfolios. PO2.2 Enterprise Data Dictionary and Data Syntax Rules Maintain an enterprise data dictionary that incorporates the organisation’s data syntax rules. This dictionary should enable the sharing of data elements amongst applications and systems, promote a common understanding of data amongst IT and business users, and prevent incompatible data elements from being created.

De Integratiestrategie is geen onderdeel van het strategische plan, de aandacht voor methodieken en omgang met migratie is zeer beperkt. Hierdoor ontstaat een risico voor de beheerste integratie, omdat deze onvoldoende management attention verkrijgt.

PO2.3

PO2.3 Data Classification SchemeEstablish a classification scheme that applies throughout the enterprise, based on the criticality and sensitivity (e.g., public, confidential, top secret) of enterprise data. This scheme should include details about data ownership; definition of appropriate security levels and protection controls; and a brief description of data retention and destruction requirements, criticality and sensitivity. It should be used as the basis for applying controls such as access controls, archiving or encryption.

Data classificatie en eigenaarschap zijn niet goed belegd binnen de organisatie, waardoor verwarring gaat ontstaan over taken, bevoegdheden en verantwoordelijkheden omtrent de data. Gedurende de integratie is hier eventueel sprake van overdrachtsmomenten en zijn aanvullende risico's aanwezig. Daarnaast verandert die systeemomgeving en ontstaat het risico dat controls en security niet voldoen aan de daar aan te verwachten eisen op basis van de dataclassificatie.

PO2.4

PO2.4 Integrity Management Define and implement procedures to ensure the integrity and consistency of all data stored in electronic form, such as databases,data warehouses and data archives.

Het risico bij integratie ontstaat dat de integriteit en consistentie van data onvoldoende is gewaarborgd.

PO1.5

PO2.2

Legacy-systemen en vooral de integratie van deze systemen zijn geen onderdeel van de tactische IT planning. Hierdoor kunnen problemen ontstaan ten aanzien van de benodigde IT initiatieven, beschikbaarheid van resources en het gebruik van resources.

Door het ontbreken van centraal inzicht in onderlinge relaties tussen systemen, data en datadefinities is de integriteit van data en systemen bij het uitfaseren of integreren van systemen niet gewaarborgd.

- 32 -


PO4.3

PO4.5

PO4.8

PO4.9

PO4.11

PO3.1 Technological Direction Planning Analyse existing and emerging technologies, and plan which technological direction is appropriate to realise the IT strategy and the business systems architecture. Also identify in the plan which technologies have the potential to create business opportunities. The plan should address systems architecture, technological direction, migration strategies and contingency aspects of infrastructure components. PO4.3 IT Steering Committee Establish an IT steering committee (or equivalent) composed of executive, business and IT management to: • Determine prioritisation of IT-enabled investment programmes in line with the enterprise’s business strategy and priorities • Track status of projects and resolve resource conflict • Monitor service levels and service improvements

Systeemintegratie vindt op een onbeheerste wijze plaats en is niet in lijn met het vigerende beleid binnen de organisatie ten aanzien van migratiestrategieën.

PO4.5 IT Organisational Structure Establish an internal and external IT organisational structure that reflects business needs. In addition, put a process in place for periodically reviewing the IT organisational structure to adjust staffing requirements and sourcing strategies to meet expected business objectives and changing circumstances. PO4.8 Responsibility for Risk, Security and Compliance Embed ownership and responsibility for IT-related risks within the business at an appropriate senior level. Define and assign roles critical for managing IT risks, including the specific responsibility for information security, physical security and compliance. Establish risk and security management responsibility at the enterprise level to deal with organisationwide issues. Additional security management responsibilities may need to be assigned at a system-specific level to deal with related security issues. Obtain direction from senior management on the appetite for IT risk and approval of any residual IT risks. PO4.9 Data and System Ownership Provide the business with procedures and tools, enabling it to address its responsibilities for ownership of data and information systems. Owners should make decisions about classifying information and systems and protecting them in line with this classification.

De organisatiestructuur past door de integratie niet meer bij de veranderende IT-omgeving. Resourcing sluit niet aan op de behoefte voor het in bedrijf houden van de reguliere business processen of sluit niet meer aan omdat men twee systemen en processen moet faciliteren. Risico's op de legacy-omgevingen worden onvoldoende en/of met onvoldoende aandacht beheerst. Risico's nemen toe ten tijde van integratie in een voortdurend veranderende omgeving. Risico bestaat dat risicobeheersing, security en compliance niet op het gewenste niveau zijn.

PO4.11 Segregation of Duties Implement a division of roles and responsibilities that reduces the possibility for a single individual to compromise a critical process. Make sure that personnel are performing only authorised duties relevant to their respective jobs and positions

Over systemen heen of binnen systemen ontstaan conflicterende functies/autorisaties, als gevolg van veranderende systeemomgeving. Het beleid ten aanzien van het voorkomen functiescheidingsconflicten is niet tijdig aangepast.

Een stuurgroep met voldoende mandaat, met vertegenwoordiging van de juiste stakeholders is niet aanwezig, waardoor de sturing op prioriteitstelling, het -beleid en integratiestrategiën ontbreekt.

Afspraken rondom data- en systeemverantwoordelijkheden tijdens het integratieproces zijn onduidelijk in een veranderende omgeving.

- 33 -


PO4.12 IT StaffingEvaluate staffing requirements on a regular basis or upon major changes to the business, operational or IT environments to ensure that the IT function has sufficient resources to adequately and appropriately support the business goals and objectives.

IT-resources sluiten niet aan bij de benodigde capaciteit gedurende de migratie, omdat geen rekening is gehouden met een eventuele parallelle run.

PO4.13

PO4.13 Key IT Personnel Define and identify key IT personnel (e.g., replacements/backup personnel), and minimise reliance on a single individual performing a critical job function.

Kritieke kennis is niet in kaart gebracht en gedocumenteerd, waardoor gedurende het integratietraject onvoldoende kritieke kennis aanwezig is en/of onvoldoende verdeeld onder de beschikbare resources.

PO5.2

PO5.2 Prioritisation Within IT Budget Implement a decision-making process to prioritise the allocation of IT resources for operations, projects and maintenance to maximise IT’s contribution to optimising the return on the enterprise’s portfolio of IT-enabled investment programmes and other IT services and assets.

In de veranderagenda is de balans en prioritering voor legacy- en nieuwe systemen scheef. Hierdoor ontstaat het risico dat de IT onvoldoende aansluit bij de business eisen en onvoldoende voldoet om in de klant en marktbehoefte te voorzien. Integreren betekent ook een investering in legacy-systemen en pas inboeken van winsten en verdiensten wanneer deze daadwerkelijk gerealiseerd kunnen worden.

PO5.3

PO5.3 IT Budgeting Establish and implement practices to prepare a budget reflecting the priorities established by the enterprise’s portfolio of IT-enabled investment programmes, and including the ongoing costs of operating and maintaining the current infrastructure. The practices should support development of an overall IT budget as well as development of budgets for individual programmes, with specific emphasis on the IT components of those programmes. The practices should allow for ongoing review, refinement and approval of the overall budget and the budgets for individual programmes. PO7.1 Personnel Recruitment and Retention Maintain IT personnel recruitment processes in line with the overall organisation’s personnel policies and procedures (e.g., hiring, positive work environment, orienting). Implement processes to ensure that the organisation has an appropriately deployed IT workforce with the skills necessary to achieve organisational goals.

De budgetten ten aanzien van de legacy-omgevingen zijn geen representatieve afspiegeling van het belang dat zij vertegenwoordigen voor de organisatie, waardoor kwaliteit en beheersbaarheid van de dienstverlenging onvoldoende kan worden gegarandeerd.

PO7.5 Dependence Upon Individuals Minimise the exposure to critical dependency on key individuals through knowledge capture (documentation), knowledge sharing, succession planning and staff backup.

Kritieke kennis met betrekking tot legacy-systemen is onvoldoende verspreid en beschikbaar bij een beperkt aantal personen binnen de organisatie.

PO7.1

PO7.5

Het personeelsbestand, met bijbehorende mensen en competenties sluit niet aan bij de behoefte vanuit de organisatie, door bezuinigingen op de budgetten voor legacy-systemen. Tweede risico is dat door het niet voeren van een juist personeelsbeleid kritieke kennis ontbreekt en deze op korte termijn tegen veel geld extern geworven moet worden en deze kennis niet behouden blijft binnen de organisatie

- 34 -


PO9.4 Risk Assessment Assess on a recurrent basis the likelihood and impact of all identified risks, using qualitative and quantitative methods. The likelihood and impact associated with inherent and residual risk should be determined individually, by category and on a portfolio basis. PO9.5 Risk Response Develop and maintain a risk response process designed to ensure that cost-effective controls mitigate exposure to risks on a continuing basis. The risk response process should identify risk strategies such as avoidance, reduction, sharing or acceptance; determine associated responsibilities; and consider risk tolerance levels.

Risicoanalyses worden niet periodiek uitgevoerd op de omgeving in transitie, niet enkel op de doelomgeving, zoals dit vaak gebeurt, maar ook op de legacy-omgeving, deze is namelijk ook ernstig aan verandering onderhevig.

AI1.2 Risk Analysis Report Identify, document and analyse risks associated with the business requirements and solution design as part of the organisation’s process for the development of requirements. AI2.3 Application Control and Auditability Implement business controls, where appropriate, into automated application controls such that processing is accurate, complete, timely, authorised and auditable.

Risico's van integratie zijn niet / onvoldoende onderkend in de Risico analyse rapporten bij het ontwerp van de transitie van de legacy-omgeving naar het doelsysteem.

AI2.4

AI2.4 Application Security and Availability Address application security and availability requirements in response to identified risks and in line with the organisation’s data classification, information architecture, information security architecture and risk tolerance.

Maatregelen ten aanzien van data classificatie, informatie architectuur, information security en risico tolerantie zijn niet juist en volledig door veranderingen, als gevolg van het uitvoeren van de integratiestrategie.

AI2.6

AI2.6 Major Upgrades to Existing SystemsIn the event of major changes to existing systems that result in significant change in current designs and/or functionality, follow a similar development process as that used for the development of new systems.

Legacy-systemen worden uitgesloten voor grote wijzigingen, ongeacht het feit of deze wijzigingen benodigd zijn voor het continueren van de operations of een positieve businesscase hebben.

AI2.10

AI2.10 Application Software Maintenance Develop a strategy and plan for the maintenance of software applications.

In de onderhoudsplannen is geen aandacht besteed aan het omgaan met legacy-systemen en legacy-systemen die deel uit maken van een integratietraject.

AI7.5

AI7.5 System and Data Conversion Plan data conversion and infrastructure migration as part of the organisation’s development methods, including audit trails, rollbacks and fallbacks.

Maatregelen ten aanzien van data conversie sluiten niet aan bij de gekozen integratiestrategie.

PO9.5

Acquire and Implement AI1.2

AI2.3

Het ingerichte controlestelsel is onvoldoende in balans met het belang van het systeem en processen binnen de organisatie toetsing tijdens de integratiefase, om te voorkomen dat deze in onbalans raakt met het belang van de legacy-systemen voor de organisatie.

Bezuinigingen op beheersdoelstellingen en controlemechanismen worden doorgevoerd op legacy-systemen, terwijl dit niet in lijn is met het belang van de systemen voor de organisatie.

Deliver and Support

- 35 -

Risicobeheersing bij legacy-systeemintegratie DS1.6

DS1.6 Review of Service Level Agreements and Contracts Regularly review SLAs and underpinning contracts (UCs) with internal and external service providers to ensure that they are effective and up to date and that changes in requirements have been taken into account.

Service levels worden niet tijdig of onterecht aangepast, wanneer er veranderingen optreden in de legacy-omgeving.

DS5.3

DS5.3 Identity Management Ensure that all users (internal, external and temporary) and their activity on IT systems (business application, IT environment, system operations, development and maintenance) are uniquely identifiable. Enable user identities via authentication mechanisms. Confirm that user access rights to systems and data are in line with defined and documented business needs and that job requirements are attached to user identities. Ensure that user access rights are requested by user management, approved by system owners and implemented by the security-responsible person. Maintain user identities and access rights in a central repository. Deploy cost-effective technical and procedural measures, and keep them current to establish user identification, implement authentication and enforce access rights. DS9.1 Configuration Repository and Baseline Establish a supporting tool and a central repository to contain all relevant information on configuration items. Monitor and record vall assets and changes to assets. Maintain a baseline of configuration items for every system and service as a checkpoint to which to return after changes.. DS11.1 Business Requirements for Data Management Verify that all data expected for processing are received and processed completely, accurately and in a timely manner, and all output is delivered in accordance with business requirements. Support restart and reprocessing needs.

Toegang tot systemen en data is onvoldoende beheerst, omdat de beheersomgeving is aangepast vinden niet tijdig plaats.

DS11.2 Storage and Retention Arrangements Define and implement procedures for effective and efficient data storage, retention and archiving to meet business objectives, the organisation’s security policy and regulatory requirements. DS11.3 Media Library Management System Define and implement procedures to maintain an inventory of stored and archived media to ensure their usability and integrity.

Data-opslag, retentie en archivering en backup en restores, van uitgefaseerde systemen, zijn niet in lijn met de daaraan gestelde eisen vanuit weten regelgeving.

DS11.4 Disposal Define and implement procedures to ensure that business requirements for protection of sensitive data and software are met when data and hardware are disposed or transferred.

Bij het uitfaseren van systemen ontstaat een verhoogd risico dat data en hardware verwijderd/verkocht/vernietigd worden, waarbij in het uitvoeren van deze acties niet wordt voldaan aan weten regelgeving.

DS9.1

DS11.1

DS11.2

DS11.3

DS11.4

De CMDB is niet tijdig en juist bijgewerkt bij wijzigingen van systemen of het daadwerkelijk uitfaseren van systemen.

Door integratie ontstaat een verhoogd risico dat data onjuist, onvolledig , niet tijdig en redundant worden verwerkt, omdat eisen en business requirements ten aanzien van datamanagement onvoldoende zijn gevalideerd.

De herkomst van opgeslagen data en media is niet terug te leiden naar de oorspronkelijke bron. Daarnaast is de bruikbaarheid en integriteit niet voldoende gewaarborgd.

- 36 -

Risicobeheersing bij legacy-systeemintegratie Een proces is ingericht op meldingen van verwerkingen tijdig te verwijderen of aan te passen in het meldingenregister van het CBP. Batch-jobs, interfaces en koppelingen met aanpalende systemen zijn niet verwijderd en/of aangepast bij het uitfaseren van legacysystemen.

DS13.2

DS13.2 Job Scheduling Organise the scheduling of jobs, processes and tasks into the most efficient sequence, maximising throughput and utilisation to meet business requirements.

DS13.3

DS13.3 IT Infrastructure Monitoring Define and implement procedures to monitor the IT infrastructure and related events. Ensure that sufficient chronological information is being stored in operations logs to enable the reconstruction, review and examination of the time sequences of operations and the other activities surrounding or supporting operations.

Fall-back voor legacy-systemen bij een mislukte conversie of integratie is niet mogelijk omdat de infrastructuur niet te reproduceren is.

ME2.4 Control Self-assessmentEvaluate the completeness and effectiveness of management’s control over IT processes, policies and contracts through a continuing programme of self-assessment.

Selfsassesments op de beheersing en sturing van het integratieproces vinden niet plaats.

ME3.1 Identification of External Legal, Regulatory and Contractual Compliance Requirements Identify, on a continuous basis, local and international laws, regulations, and other external requirements that must be complied with for incorporation into the organisation’s IT policies, standards, procedures and methodologies.

Gegevensverzamelingen van uitgefaseerde systemen voldoen niet aan de daaraan gestelde eisen vanuit weten regelgeving.

Monitor and Evaluate ME2.4

ME3.1

- 37 -


Bijlage 2 Normenkader Cobit control objective Planning & Organisation

Specifiek risico

Specifieke aanvullende maatregelen

PO1.1

Risico dat de business case te positief is begroot, omdat besparingen meteen worden ingeboekt en investeringen in legacy-systemen niet zijn opgenomen, terwijl deze nog operationeel zijn en waarschijnlijk enige tijd blijven. Hierdoor ontstaat het risico dat aanpassingen die noodzakelijk zijn in de legacyomgeving niet zijn voorzien.

Een framework wordt gehanteerd voor het opstellen van een gedegen business case, zoals Val-IT. Kosten en investeringen in de legacy-omgeving zijn opgenomen in de businesscase voor het ontwikkelen van een doelsysteem. Deze kosten en investeringen omvatten minimaal: - Beschikbaarheid van resources - Aanpassingen in legacy-systemen, waaronder weten regelgeving - Business-IT-alignment aanpassingen - Budgettering voor het behouden van een kwalitatief voldoende beheersing binnen de runomgeving

In de businesscase zijn meerdere scenario's (best case, worst case) uitgewerkt ten aanzien van de realisatie van de nieuwe doelomgeving en de variabele kosten voor de legacyomgeving zijn hiervoor meegenomen. De business case omvat uitwerkingen omtrent de gekozen legacy-integratiestrategie, de benodigde kosten in tijd, middelen en geld zijn hierin voldoende vertegenwoordigd. Kosten en Servicelevels voor legacy-systemen zijn opgenomen in de business-case, waarbij de risico's en het belang van de systemen voor de organisatie op juiste wijze zijn opgenomen.

- 38 -


Aandacht voor alignement is enkel aanwezig voor de doelsystemen. Hierdoor is alignment van de huidige operationele processen geen onderdeel meer van de huidige IT planning. Hierdoor ontstaat een groter verschil tussen de huidige omgeving en de doelomgeving, wat integratie complexer maakt. Daarnaast ontstaat het risico dat Business-IT alignment verslechtert, door onvoldoende slagkracht in het realiseren van de doelomgeving, omdat de legacyomgeving niet meer aansluit bij klant- en marktwensen. Afstemming met stakeholders (business) vindt onvoldoende plaats, waardoor IT-oplossingen en prioriteitstellingen niet overeenkomen met eisen van de business.

Een proces is ingericht wat zorgdraagt voor het opnemen van business requirements in het Strategische IT-plan voor de legacy-omgevingen gedurende legacy-systeemintegratie. Ontwikkelingen in de markt en klantbehoefte worden periodiek bijgewerkt, gedurende de duur van het integratieproces.

PO1.4

De Integratiestrategie is geen onderdeel van het strategische plan, de aandacht voor methodieken en omgang met migratie is zeer beperkt. Hierdoor ontstaat een risico voor de beheerste integratie, omdat deze onvoldoende management attention verkrijgt.

De organisatie beschikt over een legacy-integratie strategie en/of deze maakt onderdeel uit van het strategisch plan. Hierin zijn op zijn minst verschillende in de markt bekende migratiestrategieën opgenomen zoals Chicken-little, Butterfly en Big bang.

PO1.5

PO2.2

PO2.3

Legacy-systemen en metname de integratie van deze systemen zijn geen onderdeel van de tactische IT planning. Hierdoor kunnen problemen ontstaan ten aanzien van de benodigde IT initiatieven, beschikbaarheid van resources en het gebruik van resources. Door het ontbreken van centraal inzicht in onderlinge relaties tussen systemen, data en datadefinities is de integriteit van data en systemen bij het uitfaseren of integreren van systemen niet gewaarborgd. Data classificatie en eigenaarschap zijn niet goed belegd binnen de organisatie, waardoor

Het strategisch plan biedt richtlijnen om vast te stellen hoe bepaald wordt welke systemen in aanmerking komen voor legacy-integratie. Daarnaast biedt het richtlijnen om de prioritering van de systemen te bepalen. Beschikbare methodieken hiervoor zijn Application Portfolio Management en het Software Reengineering Assessment Handbook. De juiste stakeholders zijn betrokken bij het opstellen van de legacy-integratie strategie. In de tactische IT-planning is voldoende aandacht voor legacy-systemen. Deze aandacht is in lijn met het belang van deze systemen voor de organisatie, risk appetite ten aanzien van deze systemen, vereisten vanuit weten regelgeving. In het tactisch IT-plan wordt aandacht besteed aan de verdeling van kritieke kennis over legacy-systemen en doelsystemen. Wijzigingen in de Enterprise Data Dictionary en Data Syntax Rules vinden tijdig plaats, door In de planning van het integratieprogramma de verwerking van de mutaties in de Enterprise Data dictionary en de Data Syntax rules op te nemen, om de integriteit van de data te waarborgen Controles vinden plaats of milestones uit het integratieprogramma tijdig zijn verwerkt in de Enterprise Data dictionary. Overdrachtsmomenten zijn formeel opgenomen in de planning van het project/programma. Overdrachtsmomenten in data- en systeemeigenaarschap worden aantoonbaar vastgelegd.

- 39 -


PO2.4

verwarring gaat ontstaan over taken, bevoegdheden en verantwoordelijkheden omtrent de data. Gedurende de integratie is hier eventueel sprake van overdrachtsmomenten en zijn aanvullende risico's aanwezig. Daarnaast verandert die systeemomgeving en ontstaat het risico dat controls en security niet voldoen aan de daar aan te verwachten eisen op basis van de dataclassificatie. Het risico bij integratie ontstaat dat de integriteit en consistentie van data onvoldoende is gewaarborgd.

Bij overdracht vindt een toetsing plaats dat de ontvangende omgeving voldoet aan de eisen (maatregelen voor vertrouwelijkheid, beschikbaarheid en integriteit), die gesteld worden op basis van de data classificatie.

Processen zijn ingericht waarbij is vastgelegd waar data geregistreerd wordt. Tijdens het integratieproces wordt een mapping table bijgehouden om zorg te dragen voor integriteit bij parallelle run, chicken little of butterfly methodiek. Een proces is ingericht waarbij wijzigingen in de database inrichting tijdig worden verwerkt in de enterprise data dictionary om zorg te dragen voor consistentie in de gegevensopslag in databases, data warehouses en archief.

PO3.1

PO4.3

PO4.5

Systeemintegratie vindt op een onbeheerste wijze plaats en is niet in lijn met het vigerende beleid binnen de organisatie ten aanzien van migratiestrategieën.

Een detailplan wordt opgesteld ten behoeve van het integratie en migratietraject. Waarin minimaal beheersingsaspecten zijn opgenomen ten aanzien van de migratiestrategie. Hierin staan maatregelen in beschreven die zorgdragen voor beschikbaarheid, integriteit en vertrouwelijkheid van de data en systemen tijdens het integratie en migratieproject.

Periodiek vindt een herijking plaats of de migratie- en integratiestrategie aansluit op de nieuwe en opkomende technologieën. Indien nodig wordt het detailplan aangepast. Een stuurgroep met voldoende mandaat, met Een stuurgroep met de juiste vertegenwoordigers (Business, IT, Project) is ingericht die zich vertegenwoordiging van de juiste stakeholders is focust op de beheersing van de totale integratie, waarbij de risico's, voortgang en problemen niet aanwezig, waardoor de sturing op voor zowel de nieuwe omgeving als de legacy-systemen worden gemonitord prioriteitstelling, het -beleid en integratiestrategiën ontbreekt.

De organisatiestructuur past door de integratie niet meer bij de veranderende IT-omgeving. Resourcing sluit niet aan op de behoefte voor het in bedrijf houden van de reguliere business processen of sluit niet meer aan omdat men twee systemen en processen moet faciliteren.

Een proces in ingericht waarin de beschikbaarheid van resources, inrichting van de organisatie en verdeling van resources over de legacy-systemen en doelomgeving wordt bepaald. De periodiciteit van dit proces sluit aan bij de mijlpalen in de integratie zoals deze zijn opgenomen in de integratieplanning.

- 40 -


PO4.9

PO4.11

Risico's op de legacy-omgevingen worden onvoldoende en/of met onvoldoende aandacht beheerst. Risico's nemen toe ten tijde van integratie in een voortdurend veranderende omgeving. Risico bestaat dat risicobeheersing, security en compliance niet op het gewenste niveau zijn. Afspraken rondom data- en systeemverantwoordelijkheden tijdens het integratieproces zijn onduidelijk in een veranderende omgeving.

Een risk management afdeling is ingericht in de organisatie, waarbij controle op de beheersing van IT-risks ten tijde van integratie onderdeel uitmaakt van de jaarplanning. Tevens wordt gerapporteerd over de informatiebeveiliging en compliance. In de business en IT afdelingen zijn risk dashboards aanwezig die worden gebruikt om te sturen op kritieke IT-risico's, waaronder information security, fysieke beveiliging en compliance. Hierbij is voldoende aandacht voor de beheersing van de legacy-systemen. Een proces is ingericht waarbij wijzigingen in dataclassificaties,bijvoorbeeld van actief gebruikte data naar gearchiveerde data, tijdig worden verwerkt. Periodiek vindt een toetsing plaats of systeem en data-eigenaarschap juist zijn belegd en verwerkt in de CMDB. Tijdens de integratiefase, wordt de periodiciteit van deze toetsing in lijn gebracht met de realisatiesnelheid van het programma/project.

BIV classificaties zijn opgesteld voor de betrokken systemen. Periodiek wordt vastgesteld of de vastgelegde BIV classificaties nog representatief zijn voor het systeem. Periodiek vindt een toetsing plaats of de informatiebeveiligingsmaatregelen in lijn zijn met de BIV-classificatie (SOLL-IST). Over systemen heen of binnen systemen Gewenste functiescheidingen zijn vastgelegd, waarbij het risico wordt verminderd dat één ontstaan conflicterende functies/autorisaties, als enkele persoon het gehele proces kan compromitteren. gevolg van veranderende systeemomgeving. Het Periodiek wordt getoetst of autorisaties geen functiescheidingsconflicten bevatten. beleid ten aanzien van het voorkomen Een proces is ingericht wat bij veranderingen in systemen tijdens de legacy-systeemintegratie functiescheidingsconflicten is niet tijdig tijdig aanpassingen verwerkt in de functiescheidingsconflict documentatie. Deze wijzigingen aangepast. worden tevens tijdig doorvertaald naar de inrichting van de organisatie.

PO4.12

IT-resources sluiten niet aan bij de benodigde capaciteit gedurende de migratie, omdat geen rekening is gehouden met een eventuele parallelle run.

Een proces is ingericht waarin gedurende de legacy-systeemintegratie periode periodiek wordt bepaald of de resource beschikbaarheid volstaat en in lijn is met de programma/projectplanning.

PO4.13

Kritieke kennis is niet in kaart gebracht en gedocumenteerd, waardoor gedurende het integratietraject onvoldoende kritieke kennis aanwezig is en/of onvoldoende verdeeld onder de beschikbare resources.

Kritieke kennis is in kaart gebracht. Aan de hand van de inventarisatie wordt een plan opgesteld waarin beschreven staat hoe kennis gedeeld/gedocumenteerd wordt. Waar vervanging en backup beschikbaar is en waar aanvullende maatregelen nodig zijn om te voorkomen dat kritieke kennis onvoldoende is verdeeld onder de beschikbare resources. Dit behoeft extra aandacht omdat door de vraag naar kennis vanuit de nieuwe omgeving, de beschikbare kennis met betrekking tot de legacy-systemen schaarser wordt.

- 41 -


In de veranderagenda is de balans en prioritering voor legacy- en nieuwe systemen scheef. Hierdoor ontstaat het risico dat de IT onvoldoende aansluit bij de business eisen en onvoldoende voldoet om in de klant en marktbehoefte te voorzien. Integreren betekent ook een investering in legacy-systemen en pas inboeken van winsten en verdiensten wanneer deze daadwerkelijk gerealiseerd kunnen worden.

In het besluitvormingsproces is voldoende aandacht voor benodigde investeringen in de legacy-systemen, die bijdragen aan het realiseren van een beheerste integratie. Daarnaast dient in het besluitvormingsproces afgewogen te worden wat de impact van de beslissingen is op de legacy-systemen, wanneer het resources betreft.

PO5.3

De budgetten ten aanzien van de legacyomgevingen zijn geen representatieve afspiegeling van het belang dat zij vertegenwoordigen voor de organisatie, waardoor kwaliteit en beheersbaarheid van de dienstverlenging onvoldoende kan worden gegarandeerd.

Een budgetteringsproces is ingericht, waarbij bij het vaststellen van het budget rekening wordt gehouden met de gehele IT-portfolio. Waarbij de lopende operationele kosten een representatieve afspiegeling zijn van het belang van de systemen voor de huidige organisatie. Periodieke review, bijstelling en goedkeuring zijn onderdeel van het budgetteringsproces.

PO7.1

Het personeelsbestand, met bijbehorende mensen en competenties sluit niet aan bij de behoefte vanuit de organisatie, door bezuinigingen op de budgetten voor legacysystemen. Tweede risico is dat door het niet voeren van een juist personeelsbeleid kritieke kennis ontbreekt en deze op korte termijn tegen veel geld extern geworven moet worden en deze kennis niet behouden blijft binnen de organisatie

Een plan is opgesteld om op de beschikbaarheid van kritieke resources te sturen. Hierin wordt onder andere aandacht besteedt aan het behouden van personeel met kritieke kennis., het verwerven van mensen met specialistische kennis. Daarnaast dient beleid aanwezig te zijn voor het behoud van medewerkers tijdens de integratieperiode, omdat mensen in zien dat hun functie overbodig zou kunnen worden. Hierbij valt te denken aan omscholen en opleiden.

PO7.5

Kritieke kennis met betrekking tot legacysystemen is onvoldoende verspreid en beschikbaar bij een beperkt aantal personen binnen de organisatie.

PO9.4

Risicoanalyses worden niet periodiek uitgevoerd op de omgeving in transitie, niet enkel op de doelomgeving, zoals dit vaak gebeurt, maar ook op de legacyomgeving, deze is namelijk ook ernstig aan verandering onderhevig.

Kritieke kennis voor legacysystemen is vastgelegd in de systeemdocumentatie. Een kennisbank met kritieke kennis met betrekking tot de legacy-systemen is ingericht. Kennisoverdrachtsessies onder betrokken personeel vinden periodiek plaats, om continuïteit in het kennisniveau te waarborgen. Periodiek wordt een riskassesment uitgevoerd, met betrekking tot de risico's die gemoeid zijn met de legacy-systeemintegratie. De periodiciteit van de risk assesments is in lijn met het risicoprofiel van de legacy-systeemintegratie. In de risk assesments is ook aandacht voor de beheersing van legacy-systemen bij integratie.

- 42 -


Acquire and Implement AI1.2

Het ingerichte controlestelsel is onvoldoende in balans met het belang van het systeem en processen binnen de organisatie toetsing tijdens de integratiefase, om te voorkomen dat deze in onbalans raakt met het belang van de legacysystemen voor de organisatie.

Een risico response proces is ingericht voor het ontwikkelen, beheren van cost-effectieve controls, die representatief zijn voor het belang van de legacy-systemen in de huidige organisatie.

Risico's van integratie zijn niet / onvoldoende onderkend in de Risico analyse rapporten bij het ontwerp van de transitie van de legacy-omgeving naar het doelsysteem.

In de requirements van systeemontwikkeling zijn ook eisen ten aanzien van de beschikbaarheid, integriteit en vertrouwelijkheid van de legacy-systemen tijdens de integratie opgenomen. Een risico analyse rapportage is opgesteld voor de risico's die van toepassing zijn op de legacy-systemen tijdens het integratieproces. Procedures zijn ingericht om vast te stellen dat de application controls in de legacy-systemen nog accuraat, volledig, tijdig en geautoriseerd worden uitgevoerd.

AI2.3

Bezuinigingen op beheersdoelstellingen en controlemechanismen worden doorgevoerd op legacy-systemen, terwijl dit niet in lijn is met het belang van de systemen voor de organisatie.

AI2.4

Maatregelen ten aanzien van data classificatie, informatie architectuur, information security en risico tolerantie zijn niet juist en volledig door veranderingen, als gevolg van het uitvoeren van de integratiestrategie.

AI2.6

Legacy-systemen worden uitgesloten voor grote Een beheerst changemanagement proces is ingericht en wordt gevolgd voor het ontwikkelen, wijzigingen, ongeacht het feit of deze wijzigingen en implementeren van grote wijzigingen in de legacy-systemen. benodigd zijn voor het continueren van de operations of een positieve businesscase hebben.

AI2.10

In de onderhoudsplannen is geen aandacht besteed aan het omgaan met legacy-systemen en legacy-systemen die deel uit maken van een integratietraject.

Een onderhoudsplan voor het onderhouden van legacy-systemen is opgesteld en wordt gemonitord. In het onderhoudsplan is tevens rekening gehouden met het blijven uitvoeren van onderhoud, bij vertraagde systeemoplevering van het nieuwe doelsysteem.

AI7.5

Maatregelen ten aanzien van data conversie sluiten niet aan bij de gekozen integratiestrategie.

Een framework is opgesteld voor het uitvoeren van systeem- en data-conversies. Waarbij rekening wordt gehouden met audit trails, controle tellingen, rollbacks, fall back-scenario's.

Applicatie security en beschikbaarheidseisen zijn opgesteld voor de applicatie. Voor de integratieperiode zijn de specifieke risico's, met bijbehorende security en beschikbaarheidsrequirements in kaart gebracht.

Deliver and Support

- 43 -


Service levels worden niet tijdig aangepast, wanneer er veranderingen optreden in de legacy-omgeving.

Een proces is ingericht om met een frequentie, die overeenkomstig is met de verandersnelheid van de integratie, een review uitvoert, om vast te stellen of de SLA vereisten nog up to date zijn.

DS5.3

Toegang tot systemen en data is onvoldoende beheerst, omdat de beheersomgeving is aangepast vinden niet tijdig plaats.

Een proces is ingericht om veranderingen in de toegangsrechten, door wijzigingen in legacysystemen (beschikbaarheid van functionaliteit en gewenste scheiding van autorisaties voor gegevens en toegang tot data), tijdig te verwerken tijdens legacy-integratie.

DS9.1

De CMDB is niet tijdig en juist bijgewerkt bij wijzigingen van systemen of het daadwerkelijk uitfaseren van systemen.

Wijzigingen in de CMDB worden tijdig doorgevoerd. Een proces is ingeregeld bij een Chicken Little of Butterfly integratie strategie, dat zorg draagt voor tijdige verwerking van de wijzigingen in de CMDB, om de integriteit en continuïteit van de gegevensverwerking te waarborgen.

DS11.1

DS11.2

Door integratie ontstaat een verhoogd risico dat data onjuist, onvolledig , niet tijdig en redundant worden verwerkt, omdat eisen en business requirements ten aanzien van datamanagement onvoldoende zijn gevalideerd. Data-opslag, retentie en archivering en backup en restores, van uitgefaseerde systemen, zijn niet in lijn met de daaraan gestelde eisen vanuit weten regelgeving.

Een proces is ingericht om bij het uitfaseren van een systeem tijdig de wijziging in de CMDB te verwerken. Business Requirements voor Data Management tijdens de integratie zijn in kaart gebracht. Specifieke eisen ten aanzien van continuïteit en beschikbaarheid in de transitie fasen zijn onderkend en vastgelegd. Periodieke toetsing wordt uitgevoerd op juiste, volledige en tijdige verwerking van gegevens tijdens de integratie. De periodiciteit van de toetsing is in lijn met de legacysysteemintegratieplanning Bij het uitfaseren van het systeem is geïnventariseerd welke data uit het systeem beschikbaar moet blijven op basis van door weten regelgeving daaraan gestelde eisen. Tevens is vastgesteld wat de requirements zijn ten aanzien van de bewaartermijnen vanuit wet en regelgeving. Een proces is ingericht om te toetsen of de eisen ten aanzien van archivering in lijn zijn met de daaraan gestelde eisen van weten regelgeving. Een framework van maatregelen is ingericht voor informatie en archief management (NEN ISO 15489: 2001 , NEN ISO 23081: 2006, NEN 2082) Toetsing vindt plaats of data bij uitfasering binnen redelijke tijd reproduceerbaar zijn (Algemene Wet inzake Rijksbelastingen). Maatregelen zijn ingericht om voor gearchiveerde gegevens de authenticiteit en integriteit te waarborgen

- 44 -


De herkomst van opgeslagen data en media is niet terug te leiden naar de oorspronkelijke bron. Daarnaast is de bruikbaarheid en integriteit niet voldoende gewaarborgd.

Processen zijn ingericht om te waarborgen dat de data uit de legacy-systemen conform wet en regelgeving wordt gearchiveerd, waaronder: - Beschikbaarheid onder redelijke termijn - Bewaarduur conform wetgevingseisen - Authenticiteit en Integriteit zijn gewaarborgd. - Gegevens in het archief zijn geïndexeerd en herleidbaar naar systemen / processen.

DS11.4

Bij het uitfaseren van systemen ontstaat een verhoogd risico dat data en hardware verwijderd/verkocht/vernietigd worden, waarbij in het uitvoeren van deze acties niet wordt voldaan aan weten regelgeving.

Een impactanalyse is uitgevoerd voor het uitzetten van legacy-systemen. Waarbij minimaal de volgende gegevens zijn vastgelegd: - Operating System - Database en instantie - Servernaam - IP adres - CMDB nummer - Overzicht van systeemkoppelingen - Overzicht van Batchjobs - Eigenaar van het systeem. - Analyse of er nog actieve applicaties zijn op de onderliggende hardware en software (platform en database) - Analyse of er nog delen van de applicatie in gebruik zijn.

DS13.3

Fall-back voor legacy-systemen bij een mislukte conversie of integratie is niet mogelijk omdat de infrastructuur niet te reproduceren is.

Een proces is ingericht voor het uitzetten van systemen. Dit proces bevat tenminste de volgende stappen alvorens deze daadwerkelijk wordt uitgeschakeld: - Stel vast dat een recente back-up beschikbaar en leesbaar is (bijvoorbeeld in de vorm van platgeslagen databases, zodat de oude infrastructuur niet meer noodzakelijk is bij het benaderen van historische gegevens). - Stel vast dat een akkoord aanwezig is van de systeemeigenaar. - Stel vast dat de software en systeeminstellingen van de legacy-omgeving zijn veilig gesteld. Voor eventuele fallback of toekomstig gebruik. - Een impactanalyse is uitgevoerd voor het uitzetten van het legacy-systeem. - Een communicatieplan over het uitzetten van een systeem is aanwezig. Een proces is ingericht waarbij data wordt gewist(en overschreven) van hardware, voordat deze wordt verkocht / afgevoerd. Een proces is ingericht, dat zorg draagt voor het beschikbaar zijn van de meest recente IT infrastructuur instellingen, zodat een reproductie van de omgeving kan worden gemaakt, wanneer dit noodzakelijk is tijdens de integratie en/of uitfaseren. Bij wijzigingen in de infrastructuur tijdens de legacy-systeemintegratie, wordt deze tijdig verwerkt in operation logs.

Monitor and Evaluate - 45 -

Risicobeheersing bij legacy-systeemintegratie ME2.4

Selfsassesments op de beheersing en sturing van het integratieproces vinden niet plaats.

Selfassessments voor op de beheersing en aansturing van het integratieproces worden periodiek uitgevoerd.

ME3.1

Gegevensverzamelingen van uitgefaseerde systemen voldoen niet aan de daaraan gestelde eisen vanuit weten regelgeving.

Toetsing of historische gegevensverzamelingen nog voldoen aan de daaraan gestelde eisen voor weten regelgeving vindt periodiek plaats.

- 46 -


Bijlage 3 SRAH readiness checklist REENGINEERING PREPARATION Organizational Needs 1. Have the purposes/goals of reengineering been defined for this reengineering project? 1 - No 2 - Yes but they're unclear to me or don't know them 3 – Yes 2. Does management support this reengineering effort? 1 - No 2 - Yes but with reservations or management perceives that reengineering will solve all their maintenance problems 3 – Yes 3. How important is this reengineering project to the organization (managers, users, etc.)? 1 - Not important 2 - Average importance 3 – Critical 4. Is there financial support for this reengineering effort? 1 - Expect little or no financial support 2 - Expect some funding but not sufficiently funded 3 - Expect project will be fully funded 5. Is the reengineering effort consistent with overall corporate strategy? 1 - Not aware of a corporate strategy 2 - Mostly 3 – Yes Reengineering Team 6. Has a reengineering team been chosen? (Picked from the users, maintenance personnel and management) 1 - No or not representative of all key groups 2 - Yes but not dedicated full time 3 – Yes New Maintenance Process Defined 7. Has a new maintenance process environment been clearly documented? 1 - No 2 - Yes but only in broad, general terms 3 – Yes 8. Has an organizational CMM software assessment been done? 1 - No 2 - Yes but unknown 3 – Yes 9. The organization's CMM level is: 1 - One 2 - Two 3 - Three or above 10. Has a tactical plan been defined and implemented to improve the CMM level of the maintenance organization? 1 - No tactical plan to improve maintenance 2 - Yes, the tactical plan has been defined 3 - Yes, the tactical plan is being implemented Metrics 11. Have development/maintenance software metrics been defined for the organization? 1 - No 2 - Yes but the metrics are not basedo n process improvement or related to corporate - 47 -

Risicobeheersing bij legacy-systeemintegratie goals 3 - Yes 12. Are software metrics being used regularly? 1 - No 2 - Unsure how metric information is being applied 3 - Metrics play a key role in shaping maintenance decisions 13. How will metrics be used on the reengineering project? 1 - Will not be used 2 - Metrics still being defined or unsure of metrics usage 3 - Metrics will determine whether the reengineering project was successful 21. How will the reengineered software be valid ated? 1 - Not considered this 2 - Will use current validation test suite 3 - Detailed test plan, including functional traceability 22. Does the new maintenance environment include testing? 1 - No 2 - Testing is included but is mostly ad hoc or blackbox 3 - Testing is an integral part of the new maintenance environment Tools Analysis 23. Are tools available (to automate the various reengineering strategies) for the target hardware platform and source code language? 1 - No, or don't know 2 - Yes, but would require extensive customization 3 – Yes Training 24. How much current training/understanding of reengineering is there within the maintenance organization? 1 - Few, if any, of the reengineering team have been trained 2 - Some of the reengineering team have been trained 3 - Most of the key reengineering team have been trained in reengineering, tools, and the target maintenance environment 25. Who is to be trained and in what area? 1 - Training has not been considered 2 - Training is part of this reengineering project but not in detail 3 - People have been designated and specific classes identified 26. Is there a funded plan to train the reengineering staff in any new tools or techniques which will be used? 1 - No 2 - Yes, but less than 10% of reengineering budget 3 - Training represents 10% or more of the entire reengineering budget

- 48 -


Bijlage 4 Geïnterviewde functionarissen Onderstaand is een overzicht opgenomen van de functies van de geïnterviewde personen en personen die de workshops hebben bijgewoond: •

Functioneel applicatie beheerders

•

Technisch applicatie beheerders

•

Database beheerders

•

Platform beheerders

•

IT keten managers

•

IT delivery managers

•

Informatie manager

•

Manager functioneel beheer

•

Key users uit de business

•

Business managers

•

Projectleiders

•

Internal auditors

•

Externe auditors

- 49 -


Bijlage 5 Literatuurlijst Geraadpleegde literatuur met verwijzing: [Aebi 1994] D. Aebi, R. Largo, ’Methods and Tools for Data Value Re-Engineering’, Proceedings International Conference on Applications of Databases. Lecture Notes in Computer Science 819, SpringerVerlag 1994, pp. 499-411. [Brodie 1995] M. Brodie, M. Stonebraker, ’Migrating Legacy Systems: Gateways, Interfaces and the Incremental Approach’, Morgan Kaufmann Publishers, Inc. USA, 1995 [Wu et al 1997] ‘Migrating Legacy Systems : From a Caterpillar to a Butterfly’, Trinity College Technical Report, January 1997. [Maat&Vogt, 1998] Een methodische aanpak voor legacy. [Bisbal et al 1997] An overview on legacy system migration. [Bisbal et al 1999] Legacy InformationSystems: Issues and Directions. [Korff en verberne 2010] IT Control framework voor dataconversies. [Maat et al 2008] Samenwerking tussen business, project en auditors, sleutel tot succesvolle conversies, Margarethe van der Maat, Luc van Peer, Eric Bijlsma en Ivo Brand, de EDP-Auditor nummer 1, 2008 [US DOJ 2003] Information resources management (US Department of Justice) SDLC. http://www.justice.gov/jmd/irm/lifecycle/ch1.htm [Eason 1988] Information technology and organizational change, Taylor & Francis, [CBP artikelen] http://www.cbpweb.nl/wbpnaslag/2/Paginas/wbp-artikel-10-1.aspx [IT investment management] http://pramodrrao.files.wordpress.com/2011/06/it-investment-management.jpg [IBM 2011] Empowering the CIO: Enabling smarter decisions with Application Portfolio Management [ISACA VAL-IT] http://www.isaca.org/Knowledge-Center/Research/ResearchDeliverables/Pages/Val-ITFramework-2.0.aspx [ISACA Cobit] http://www.isaca.org/COBIT/Pages/default.aspx?cid=1003566&Appeal=PR [Deloitte]: Deloitte Enterprise Architecture Framework (http://www.deloitte.com/assets/DcomNetherlands/Local%20Assets/Documents/EN/Services/Consulting/nl_en_consulting_brochure_enterprise_ar chitecture.pdf) [Cobit overview] http://www.qualified-audit-partners.be/user_images/Articles/CobiT_Framework.jpg Geraadpleegde literatuur: Van Grembergen, IT Governance mechanismen (Cobit en de balance scorecard), 2004) De Haes, Van Grembergen: Analysing the Relationship between IT Governance and Business/IT Alignment Maturity, 2008 Steven De Haes & Wim Van Grembergen: IT Governance: theorie vs praktijk in IT professional; 18, 2007 Peter Weill, Jeanne W. Ross: Linking Strategy, IT Governance, and Performance, 2004 IT Governance institute: Cobit 4.1, 2007 The systems Development Audit, Chris Nelms, Computer Audit Update, Jun2 1996, Elsecier Science Ltd.

- 50 -

Risicobeheersing bij legacy-systeemintegratie Client X Conversion Strategy, strategy and approach document. Data Migration Concepts and Challenges, Gershon Pick, March 2001. Beheersbaarheid van Dataconversies, deel 1, de zeven valkuilen van conversie, ir. M.C.L.P. Pleumeekers RE. A plan for succesful Legacy Data Conversion, Derek Wilson, Infomanagement Direct, September 2004, http://www.information-anagement.com/infodirect/20040917/1010466-html Best Practices Mitigate Data Migration Risks and Challenges, Ted Friedman, May 15th, 2009, Gartner, ID: G00167994 Risk and Challenges in Data Migrations and conversions, Ted Friedman, February 2009, Gartner, ID: G00165710 ASL: een framework voor applicatiebeheer, Remco van der Pols, 2006, Academic Services; Beheer van Informatiesystemen, M. Looijen,1998, Kluwer Bedrijfsinformatie; BiSl: een framework voor Functioneel Beheer en Informatiemanagement, Remco van der Pols, 2005, van Haren Publishing; Sturing en organisatie van ICT-voorzieningen, Theo Thiadens, 2008, van Haren Publishing; Wet bescherming persoonsgegevens, H. H. de Vries, D.J Rutgers, 2001, Kluwer.

- 51 -

Koen Vincent Studentnummer: Scriptienummer 1049

Recommend Documents