1
Eindscriptie RE-studie.
Op welke manier kan COBIT5 bijdragen aan
de beheersing van de IT-architectuur bij
banken?
Versie 1.0 – 15-04-2016 Naam: Ali Alam
3
Banks need to tighten their current lending IT infrastructure to
address this fast growing market, as technology can be a crucial
differentiator that provides a competitive edge – Senthil Kumar
4
Inhoudsopgave
Voorwoord ... 7
Managementsamenvatting ... 8
Hoofdstuk 1: Op welke manier kan COBIT5 bijdragen aan de beheersing van de IT-architectuur bij banken? ... 10
1.1 Introductie ... 10
1.2 Doel- en probleemstelling ... 12
1.3 Onderzoeksmethoden ... 13
1.4 Scope van de steekproef ... 14
1.5 Structuur ... 14
Hoofdstuk 2: Wat zijn de risico’s van een onvoldoende beheerst IT-architectuur? ... 15
2.1 Introductie ... 15 2.2 Definitie en conceptualisatie ... 15 2.3 Onderzoeksmethode ... 16 2.4 Literatuuronderzoek ... 16 2.5 Resultaten en Analyse ... 20 2.6 Conclusie ... 21
Hoofdstuk 3: Welke bijdrage levert COBIT5 aan de beheersing van een IT-architectuur? ... 22
3.1 Introductie ... 22 3.2 COBIT ... 22 3.3 Onderzoeksmethode ... 24 3.4 Literatuuronderzoek ... 24 3.5 Resultaten en Analyse ... 27 3.6 Conclusie ... 27
Hoofdstuk 4: Welke handvatten biedt COBIT5 ter beheersing van de IT-architectuur? ... 28
4.1 Introductie ... 28 4.2 Onderzoeksmethode ... 28 4.4 Onderzoek ... 28 Werkwijze ... 28 4.5 Resultaten en Analyse ... 29 Marktrisico ... 29 Continuïteitsrisico ... 31
5
Compliancerisico ... 34
Conclusie ... 36
Hoofdstuk 5: Hoe geschikt vinden banken COBIT5 om hun IT-architectuur te beheersen? ... 37
5.1 Introductie ... 37 5. 2 Onderzoekmethode ... 37 Werkwijze ... 37 5.3 Resultaten en Analyse ... 38 Risicoperceptie ... 38 Beheersmaatregelen ... 44 COBIT ... 52 Conclusie ... 55 Hoofdstuk 6: Conclusie ... 57 6.1 Introductie ... 57
6.2 Discussie van resultaten ... 57
Risicoperceptie ... 57
Beheersmaatregelen ... 58
COBIT ... 59
6.3 Bijdrage aan theorie ... 60
6.4 Bijdrage aan management ... 60
6.5 Beperkingen van dit onderzoek en toekomstig onderzoek ... 61
Bijlage 1 COBIT5 Processen ... 62
Bijlage 2 Uitwerking werkwijze Compliancerisico ... 63
Bijlage 3a Vragenlijst IT-architectuur Business ... 65
Risicoperceptie ... 65 Beheersmaatregelen ... 65 COBIT ... 66 Scenario 1 ... 66 Scenario 2: ... 67 Scenario 3: ... 67
Bijlage 3b Vragenlijst IT-architectuur 2e/3e lijn ... 68
Risicoperceptie ... 68
Beheersmaatregelen ... 68
6
Scenario 1 ... 69
Scenario 2: ... 70
Scenario 3: ... 70
Bijlage 4 Resultaten Interviews onderdeel Beheersmaatregelen... 71
Bank A ... 71 Bank B ... 72 Bank C ... 75 Bank D ... 77 Bank E ... 79 Bijlage 5 Begrippenlijst ... 82 Bibliografie ... 84
7
Voorwoord
U heeft zojuist de eerste bladzijde van mijn scriptie “Op welke manier kan COBIT5 bijdragen aan de beheersing van de IT-architectuur bij banken?” omgeslagen; maar wat zegt deze titel eigenlijk? Deze scriptie is geschreven in het kader van mijn parttime postdoctorale studie “Amsterdam IT Audit Programme” aan de UvA en onderzoekt de bijdrage van COBIT5 aan de beheersing van de IT-architectuur. Deze scriptie is een weergave van de periode januari 2015 tot en met maart 2016 waarin ik onderzoek heb gedaan naar de relatie tussen COBIT5 en IT-architectuur bij banken.
Graag wil ik stilstaan bij een aantal mensen die een rol hebben gespeeld in de totstandkoming van deze scriptie.
Mijn dank aan mijn begeleider Jur Huizenga voor zijn raad, advies en feedback om deze scriptie tot een goed einde te kunnen brengen.
Eveneens wil ik mijn collega’s en de mensen in mijn netwerk bedanken die mij hebben geholpen om in contact te komen met de verschillende respondenten binnen de banken.
Een dankbetuiging voor de medewerking van alle respondenten binnen de verschillende banken. Zonder hun inzicht had ik dit onderzoek niet kunnen uitvoeren.
Ten slotte wil ik mijn vrienden en familie bedanken die mij gedurende deze periode hebben bijgestaan. Ik wens u veel leesplezier toe.
8
Managementsamenvatting
Het concept Enterprise Architecture (hierna: IT-architectuur) is ontwikkeld door J.A. Zachman in 1987 (Zachman, 1987). In het artikel “A framework for information systems architecture” definieert hij, als gevolg van toenemend gebruik van informatiesystemen, een raamwerk om de informatiesystemen door de koppelingen tussen en integratie van de systemen te structureren en beheersen. Hij stelt hierbij een drietal modellen op voor informatiesystemen. Hij concludeert dat de juiste toepassing van IT-architectuur afhankelijk is van de bedrijfsfunctie en invalshoek. Sinds 1987 is voortgebouwd op deze ideeën en zijn definities ontstaan die te herleiden zijn naar de definitie van Zachman.
In de literatuur worden IT en IT-architectuur regelmatig neergezet als bedrijfscomponenten die ondersteunend zijn aan de business doelstellingen en processen. Hierdoor wordt meestal gesproken in termen van Enterprise Architecture waar de ‘business’ centraal wordt gesteld (Jonkers, et al., 2006). Doordat de IT-architectuur als ondersteunend wordt gepositioneerd aan de strategie van het bedrijf, wordt regelmatig voorbijgegaan aan het potentieel van IT-architectuur om diezelfde strategie te realiseren (Ross, 2003; Winter & Schelp, 2008; Pereira & Sousa, 2005).
In de dagelijkse bedrijfsvoering neemt bij banken IT een belangrijke positie in omdat het zich uitstrekt over de gehele waardeketen (Commissie Structuur Nederlandse Banken; 2013). Banken verkopen ook producten die veelal virtueel van aard zijn waardoor sterk wordt geleund op de informatie in informatiesystemen. Klanten versterken dit door hun behoefte om bankzaken steeds meer over het internet te willen regelen (CBS, 2012). Hiervoor is een degelijke huishouding en een effectieve IT-architectuur essentieel. Helaas lukt het de banken maar niet om dit vorm te geven.
Banken hebben over de jaren heen veel geïnvesteerd in hun IT-architectuur, maar hebben vanuit een korte termijnperspectief steeds meer systemen toegevoegd en gekoppeld aan bestaande systemen omdat dit goed leek te werken. Vandaag de dag bestaat een gemiddelde bancaire IT-architectuur uit een verzameling van diverse legacy-systemen uit het verleden die een hoge complexiteit kennen door de verscheidenheid aan koppelingen (Commissie Structuur Nederlandse Banken, 2013). Dit resulteert in een lage aanpasbaarheid als gevolg waarvan banken onvoldoende veerkracht hebben om snel te kunnen innoveren. Ook compliance uitdagingen - gericht op het implementeren van wet- en regelgeving - bevatten steeds meer IT componenten en worden daardoor minder snel succesvol overwonnen. De nadruk ligt bij de compliance eisen sterk op security en business continuïteit. Dit resulteert in weinig aanpassingsvermogen waardoor banken onvoldoende veerkracht hebben om snel te kunnen innoveren. (De Nederlandsche Bank, 2013; De Nederlandsche Bank, 2013a). Daarnaast ontstaan ook continuïteitsrisico’s die onder andere resulteren in een groot aantal storingen bij internetbankieren (Joop, 2014; NU.nl, 2014a; NU.nl, 2014b; Elsevier, 2014). Dit brengt het voortbestaan van banken mogelijk in gevaar. Als gevolg hiervan is een gestructureerde en beheerste IT-architectuur onmisbaar. Mijn onderzoek hanteert het normenstelsel van COBIT5 om de geschiktheid voor de beheersing van de IT-architectuur in kaart te brengen. Dit is om de volgende redenen. De Nederlandsche bank heeft gekozen voor het COBIT normenstelsel. Als gevolg van deze keuze wordt van de financiële sector geëist dat ze voldoet aan de COBIT 4.1 norm. Dit onderzoek kan een bijdrage leveren aan de bestaande kennis en toepassingen van COBIT4.1 in de financiële sector en de bruikbaarheid van COBIT5 als beheersingsraamwerk. Verder is COBIT5 naar mijn oordeel een overzichtelijke, complete, praktische en
9 veelgebruikte methodologie om de beheersing in te richten voor diverse bedrijfsprocessen (Ridley et al, 2004; Lainhart IV, 2000; Hojaji & Shirazi, 2010a; Hojaji & Shirazi, 2010b).
Ten slotte is het één van de weinige raamwerken die gestoeld is op het realiseren van een alignment tussen business en IT en daarbij IT als een duidelijke enabler beschouwt (ISACA, 2012; Moeller, 2013). Het doel is om bij afronding van dit onderzoek een basis te kunnen leggen voor een beheersingsraamwerk voor IT-architecturen. De conclusies uit het theoretisch model zullen in het kader van de scriptie besproken worden met subject matter experts bij banken ter validatie van de theorie. Op basis van het vooronderzoek is de voor dit onderzoek de volgende hoofdvraag gedefinieerd: Op welke manier kan COBIT5 bijdragen aan de beheersing van de IT-architectuur bij banken?
Hiertoe is op basis van COBIT5 een theoretisch model opgesteld om de IT-architectuur in termen van marktrisico, continuïteitsrisico en compliancerisico te kunnen beheersen. Het theoretisch model is besproken met de eerste lijn (business) en tweede/derde lijn binnen een vijftal banken die variëren in grootte en leeftijd.
Na het houden van de interviews en analyse van de resultaten is vastgesteld dat COBIT5 kan bijdragen aan de beheersing van de IT-architectuur bij banken rekening houdend met een aantal voorwaarden en/of omstandigheden. Ten eerste, om COBIT5 goed in te zetten dient de beheersing plaats te vinden in een vorm waarbij de afgeleide risico’s van een onbeheerst IT-architectuur gedefinieerd zijn en beheerst worden door een combinatie van COBIT5 processen. IT-architectuur direct benaderen vanuit COBIT5 middels proces APO03 zal onvoldoende resultaat opleveren. Ten tweede is het beter om de beheersing middels COBIT5 processen te implementeren bij de tweede/derde lijn, omdat COBIT5 als raamwerk een monitorende en controlerende insteek heeft en daarmee beter aansluit is op de filosofie en raison d’etre van de tweede/derde lijn. Positionering bij de eerste lijn zal mogelijk geen optimaal resultaat tot gevolg hebben omdat de eerste lijn meer hands-on maatregelen prefereert. Daarnaast gaat COBIT5 meer over de ‘wat-vraag’, die niet aansluit op de behoeften van de eerste lijn. Ten derde kan COBIT5 het beste ingezet worden voor beheersing van de continuïteitsrisico en compliancerisico en in mindere mate voor de beheersing van de marktrisico.
Vanuit de beheersing van IT-architecturen kan toekomstig onderzoek zich richten op andere branches waar sprake is van complexe IT-architecturen zoals de overheid, Fast Moving Consumer Goods en Industrie. Daarnaast kan aan de hand van de gekozen branche ook gekeken worden naar andere risico’s die in specifieke mate van toepassing zijn op de IT-architectuur in de betreffende branche en beheerst dienen te worden. Verder kan dit vraagstuk ook onderzocht worden vanuit andere raamwerken zoals BISL en ITIL. Dit onderzoek heeft de eerste basis gelegd voor een mogelijk raamwerk ter beheersing van de IT-architectuur. Ten slotte is een volgende stap ook het specifiek vertalen van het raamwerk naar een bank en deze binnen de banken te testen en aan te vullen.
10
Hoofdstuk 1: Op welke manier kan COBIT5 bijdragen aan de beheersing
van de IT-architectuur bij banken?
1.1 Introductie
Het concept Enterprise Architecture (hierna: IT-architectuur) is ontwikkeld door J.A. Zachman (1987). In zijn artikel “A framework for information systems architecture” definieert hij als gevolg van toenemend gebruik van informatiesystemen binnen bedrijven een raamwerk om de informatiesystemen, de interfaces en de integratie tussen de systemen te structureren en beheersen. Hij stelt hierbij vanuit drie perspectieven van een informatiesysteem – materiaal (Wat), functionaliteit (Hoe) en locatie (Waar naartoe) – een drietal modellen op namelijk de data, het proces en network model. Hij geeft ook aan dat de juiste toepassing van IT-architectuur afhankelijk is van de bedrijfsfunctie en invalshoek. Over de jaren heen is op dit idee voortgebouwd en zijn definities ontstaan die in essentie te herleiden zijn naar de definitie van Zachman. Zo zijn verschillende modellen en methodieken ontstaan. De meest prevalente op dit moment is TOGAF, een open standaard beheerd door de OpenGroup. Deze methode wordt actief onderhouden. De meest recente versie is 9.1.
In de literatuur worden IT en IT-architectuur regelmatig neergezet als een bedrijfscomponenten die ondersteunend zijn aan de business doelstellingen en processen, waardoor meestal wordt gesproken in termen van Enterprise Architecture (Jonkers, et al., 2006) en de business centraal wordt gesteld. Doordat de IT-architectuur als ondersteunend wordt gepositioneerd aan de strategische doelstellingen van het bedrijf, wordt regelmatig voorbijgegaan aan het potentieel van IT-architectuur als enabler van diezelfde strategische bedrijfsdoelstellingen (Ross, 2003; Winter & Schelp, 2008; Pereira & Sousa, 2005). In deze scriptie is gekozen voor de definitie van IT-architectuur waarbij - zij fungeert als een enabler voor het behalen van de strategische doelstellingen en die luidt als volgt:
“An IT architecture is the organizing logic for applications, data and infrastructure technologies, as captured in a set of policies and technical choices, intended to enable the firm’s business strategy” (Ross, 2003).
De bovengenoemde definitie spreekt in termen van “organizing logic” en hanteert daarmee een conceptueel uitgangspunt. Deze scriptie verruimt deze definitie naar een tastbaar niveau en definieert IT-architectuur als het geheel van applicaties, infrastructuur en de daarbij horende beleid en keuzes, met als doel de strategie van het bedrijf te kunnen verwezenlijken.
Bij banken neemt IT een cruciale positie in, in de dagelijkse bedrijfsvoering doordat het zich uitstrekt over de gehele waardeketen (Commissie Structuur Nederlandse Banken; 2013). Banken verkopen ook producten die veelal virtueel van aard zijn (bijv. beleggingen en geld op spaarrekeningen) en dus wordt er sterk geleund op de informatie in informatiesystemen. Dit wordt versterkt door klanten die hun bankzaken steeds meer vanuit hun luie stoel over het internet willen regelen (CBS, 2012). Om hier op aan te kunnen sluiten is een degelijke huishouding en daarmee het effectief vormgeven van de IT-architectuur essentieel. Helaas lukt het de banken maar niet om dit vorm te geven.
Banken hebben over de jaren heen veel geïnvesteerd in hun IT-architectuur, maar hebben het langetermijnperspectief niet altijd als uitgangspunt genomen. Vanuit een kortetermijndenken zijn
11 systemen toegevoegd en gekoppeld aan bestaande systemen waardoor een gemiddeld bancair IT-architectuur vandaag de dag bestaat uit een verzameling van diverse legacy systemen uit de jaren ‘60 en ’70 met een hoge complexiteit door de verscheidenheid aan koppelingen (Commissie Structuur Nederlandse Banken, 2013). Dit heeft verschillende gevolgen voor de bank.
Ten eerste leidt het tot een lage aanpasbaarheid van banken waardoor zij onvoldoende veerkracht hebben om aan te kunnen sluiten bij nieuwe ontwikkelingen in de markt (KPMG, 2010; Banking Review.NL, 2016; Computable, 2007; Consultancy.NL, 2015).
Ten tweede creëert deze complexiteit uitdagingen voor de compliance met wet- en regelgeving die steeds een belangrijk IT component bevat waardoor het banktoezicht verruimd wordt naar de IT. Toezicht is steeds meer datagedreven en de nadruk ligt op security en business continuïteit. Voorbeelden hiervan zijn BCBS 239, (eisen gesteld aan IT-architectuur en governance van risk data), informatiebeveiliging, cybercrime (De Nederlandsche Bank, 2013) en de Asset Quality Review die plaatsvond in 2014 (De Nederlandsche Bank, 2013a).
Ten derde ontstaan risico’s voor de banken die onder andere resulteren in het hoge aantal storingen bij internetbankieren (Joop, 2014; NU.nl, 2014a; NU.nl, 2014b; Elsevier, 2014) die het -functioneren mogelijk in gevaar kunnen brengen. Als gevolg hiervan is een gestructureerde en beheerste IT-architectuur onmisbaar.
Onderzoek heeft uitgewezen dat banken zich bewust zijn van bovengenoemde uitdagingen maar onvoldoende bereid zijn om er iets aan te doen (PWC, 2014; Commissie Structuur Nederlandse Banken; 2013). Onderzoek daarentegen wijst uit dat het operationaliseren van de Enterprise Architecture functie binnen de financiële sector een positief effect heeft op de IT-flexibiliteit (Schmidt & Buxmann, 2011). De steeds complexer wordende IT-omgevingen van banken bieden potentieel om de mogelijkheden ter beheersing van de IT-architectuur verder te onderzoeken en vorm te geven. Het niet beheersen van de complexiteit kan banken blootstellen aan risico’s en schade. Als gevolg van deze complexiteit heeft De Nederlandsche Bank (hierna: DNB) het onderzoeksthema “Complexe ICT Omgevingen voor financiële Instellingen” opgezet in 2014 (DNB 2014a), waarbij ze aan de hand van een toetsingskader twaalf verschillende financiële instellingen heeft beoordeeld (De Nederlandsche Bank, 2014a, De Nederlandsche Bank, 2014b). DNB hanteert het normenstelsel van COBIT 4.1 opgesteld door ISACA (ISACA, 2012) en vereist een minimale COBIT volwassenheidsniveau 3 voor bancaire processen en voor bepaalde processen zelfs een volwassenheidsniveau 4 (De Nederlandsche Bank, 2014a, De Nederlandsche Bank, 2014b).
Deze scriptie hanteert het normenstelsel van COBIT5 om de geschiktheid hiervan voor de beheersing van de IT-architectuur in kaart te brengen. Deze keuze heeft meerdere redenen:
• DNB stelt dat het normenstelsel van COBIT 4.1 als norm geldt in de financiële sector. Zo kan deze scriptie kennis toevoegen aan de bestaande toepassingen van COBIT4.1 in de financiële sector en de bruikbaarheid van COBIT5 als beheersingsraamwerk. De scope van deze scriptie beperkt zich tot de banken.
• COBIT5 is een overzichtelijk, compleet, praktisch en veelgebruikte methodologie om beheersingsraamwerken en -doelstellingen te formuleren voor diverse bedrijfsprocessen. Dit wordt
12 bevestigd door verschillende onderzoeken (Ridley et al, 2004; Lainhart IV, 2000; Hojaji & Shirazi, 2010a; Hojaji & Shirazi, 2010b). Het geeft stap voor stap aan welke maatregelen je dient te implementeren om de gewenste situatie te kunnen bereiken en welke factoren dit proces versterken. COBIT5 is één van de weinige raamwerken die gestoeld is op het realiseren van een alignment tussen business en IT en daarbij IT als een duidelijke enabler beschouwt (ISACA, 2012; Moeller, 2013). Hiermee sluit het aan op de definitie van IT-architectuur zoals gehanteerd in deze scriptie.
1.2 Doel- en probleemstelling
Het doel is om bij afronding van deze scriptie een basis te kunnen leggen voor een raamwerk ter beheersing van IT-architecturen. De conclusies uit het theoretisch model zullen in het kader van de scriptie besproken worden met subject matter experts bij banken ter validatie van de theorie.
Op basis van vooronderzoek is de voor deze scriptie de volgende hoofdvraag gedefinieerd: Op welke manier kan COBIT5 bijdragen aan de beheersing van de IT-architectuur bij banken? Deze hoofdvraag valt uiteen in de volgende deelvragen:
1. Wat zijn de risico’s van een onvoldoende beheerst IT-architectuur? 2. Welke bijdrage levert COBIT5 aan de beheersing van een IT-architectuur? 3. Welke handvatten biedt COBIT5 ter beheersing van de IT-architectuur? 4. Hoe geschikt vinden banken COBIT5 om hun IT-architectuur te beheersen?
De beantwoording van de deelvragen leidt tot de beantwoording van de hoofdvraag in de conclusie (laatste hoofdstuk) van deze scriptie. De genoemde onderzoeksvragen resulteren in onderstaand onderzoeksmodel. Per onderdeel is aangegeven in welk(e) hoofdstuk/paragraaf de deelvraag wordt
Bijdrage COBIT5 beheersing IT-architectuur
(Deelvraag 2)
Risico’s van een onbeheerst IT-architectuur
(Deelvraag 1)
Bijdrage COBIT5 ter beheersing van
IT-architectuur
(Conclusie)
Handvatten ter beheersing van IT-architectuur (Deelvraag 3) Geschiktheid COBIT5 volgens banken (Deelvraag 4) Figuur 1 Onderzoeksmodel
13 behandeld.
1.3 Onderzoeksmethoden
Deze paragraaf behandelt de gekozen onderzoeksmethoden per deelvraag om de onderzoeksvraag te kunnen beantwoorden.
Voor deze scriptie is gekozen voor een combinatie van literatuuronderzoek en interviews met subject matter experts voor validatie van het theoretisch model opgebouwd in deelvraag 3. In opvolgende hoofdstukken wordt voor iedere deelvraag uitgelegd waarom deze is geformuleerd, welke definities worden gehanteerd voor variabelen, welke onderzoekmethode wordt toegepast en waarop deze keuze is gebaseerd.
Op welke manier kan COBIT5 bijdragen aan de beheersing van de IT-architectuur bij banken? 1. Wat zijn de risico’s van een onvoldoende beheerst IT-architectuur?
Deze deelvraag is geformuleerd omdat onvoldoende beheersing van een IT-architectuur kan leiden tot verschillende risico’s, die schade kunnen berokkenen aan de bank. Het is dus belangrijk om inzicht te krijgen in de risico’s. Deze scriptie kijkt naar drie specifieke risico’s die in verband staan met de drie ontwikkelingen genoemd in de introductie, namelijk marktrisico’s, compliancerisico’s en continuïteitsrisico’s omdat deze drie soorten risico’s mogelijk een gevolg kunnen zijn van een onbeheerste IT-architectuur en daardoor grote schade kunnen berokkenen aan een bank.
2. Welke bijdrage levert COBIT5 aan de beheersing van een IT-architectuur?
In deze deelvraag wordt onderzocht welke bijdrage COBIT5 levert ter beheersing van IT-architecturen. Hiervoor dient vastgesteld te worden welke invulling COBIT5 levert aan de beheersing van IT-architecturen binnen banken.
3. Welke handvatten biedt COBIT5 ter beheersing van de IT-architectuur?
In deze deelvraag wordt de theorievorming afgerond resulterend in een theoretisch model voor deze scriptie die getoetst zal worden in deelvraag 4 met als doel patronen te ontdekken. Door een vergelijking te maken van de antwoorden op deelvraag 1 en 2 kan vastgesteld worden of de uitspraken en bijdrage van COBIT5 uit deelvraag 2 voldoende zijn om de in deelvraag 1 geïdentificeerde risico’s te kunnen beheersen en zo nodig te mitigeren.
4. Hoe geschikt vinden banken COBIT5 om hun IT-architectuur te beheersen?
De theorie die is opgebouwd in deelvraag 1 tot en met 3 wordt getoetst bij een vijftal Nederlandse banken door interviews te houden met de eerste lijn (business) en tweede/derde lijn en het theoretisch model te toetsen met als doel patronen te ontdekken. De banken variëren qua grootte en leeftijd.
14
1.4 Scope van de steekproef
Deze scriptie focust zich op een selectie van drie Nederlandse grootbanken en twee kleinere Nederlandse banken. Deze keuze is gemaakt om een gemêleerde steekproef van kleine en grote banken te kunnen nemen, waarbij de gemeenschappelijke factor tussen de banken is dat ze allemaal sterk gedreven worden door IT. Er is gekozen voor een selectie van de vier grote banken omdat deze bijna 80% van de Nederlandse bancaire markt voor hun rekening nemen (Ministerie van Financiën, 2013). Om een oordeel te kunnen vormen over de resterende 20% is gekozen voor twee kleinere banken om de verschillen in grootte en leeftijd van de banken nader te duiden in het onderzoek. Leeftijd en grootte van de bank kunnen bijvoorbeeld impact hebben op de hoeveelheid legacy in de IT-architectuur en daarmee de beheersbaarheid van de IT-architectuur. Het incorporeren van dergelijke factoren heeft als gevolg dat de resultaten een breder toepassingsveld hebben.
1.5 Structuur
Ieder hoofdstuk behandelt een deelvraag. Het hoofdstuk start met een introductie die uitleg geeft over de scope van het hoofdstuk. Er wordt een literatuur onderzoek uitgevoerd om tot een definitie en conceptualisatie te komen van de variabelen uit de deelvragen. Vervolgens wordt de onderzoeksmethode voor de betreffende deelvraag uitgelegd en de resultaten gerapporteerd. Ten slotte wordt de conclusie van elk hoofdstuk (deelvraag) geformuleerd en de opstap gemaakt naar het volgende hoofdstuk.
De indeling van deze scriptie ziet er als volgt uit:
• Hoofdstuk 2: Wat zijn de risico’s van een onvoldoende beheerst IT-architectuur? • Hoofdstuk 3: Welke bijdrage levert COBIT5 aan de beheersing van een IT-architectuur? • Hoofdstuk 4: Welke handvatten biedt COBIT5 ter beheersing van de IT-architectuur? • Hoofdstuk 5: Hoe geschikt vinden banken COBIT5 om hun IT-architectuur te beheersen? • Hoofdstuk 6: Conclusie
15
Hoofdstuk 2: Wat zijn de risico’s van een onvoldoende beheerst
IT-architectuur?
2.1 Introductie
Dit hoofdstuk behandelt de eerste sub-vraag van deze scriptie namelijk “Wat zijn de risico’s van een onvoldoende beheerste IT-architectuur?”. Het hoofdstuk start met de definitie en conceptualisatie van diverse mogelijke risico’s van een onvoldoende beheerste IT-architectuur op basis van voorgaand onderzoek. Vervolgens wordt de onderzoekmethode voor deze deelvraag uitgelegd gevolgd door een literatuuronderzoek. Ten slotte worden de resultaten gerapporteerd.
2.2 Definitie en conceptualisatie
Bovengenoemde deelvraag wordt gevormd door twee variabelen, namelijk, 1) de risico’s die een bank ondervindt als gevolg van 2) een onbeheerste IT-architectuur. Dit onderdeel gaat in op de definities en conceptualisatie van deze twee variabelen.
Deze scriptie selecteert een drietal risico’s waar banken mee te maken hebben als gevolg van een onbeheerste IT-architectuur, namelijk marktrisico, compliancerisico en continuïteitsrisico. Deze drie risico’s kunnen een mogelijk gevolg zijn van een onbeheerste IT-architectuur gelet op de marktdynamiek waar banken momenteel mee te maken hebben. Banken moeten zowel de korte- (continuïteitsrisico) als de langetermijnvisie (marktrisico) balanceren en tevens voldoen aan de vereisten van de toezichthouders. Zowel de klant als de aard van de producten geleverd door de bank zijn in hoge mate afhankelijk van de IT-automatisering van de bank (Commissie Structuur Nederlandse Banken; 2013; CBS, 2012). Zo komen de banken terecht in een moeilijke situatie, gezien het hen niet lukt om een degelijke IT-huishouding op te zetten om aan deze klantvraag te kunnen voldoen en daardoor moeite hebben om de korte- en langetermijnvisie te balanceren. Tevens zie ik marktrisico, compliancerisico en continuïteitsrisico regelmatig in de praktijk terugkomen in mijn rol als IT-auditor. Op basis van deze factoren is gekozen voor marktrisico, compliancerisico en continuïteitsrisico. Zie hieronder de gehanteerde definities met onderbouwende bronnen.
• Marktrisico is gedefinieerd als de kans dat banken niet kunnen aansluiten bij nieuwe ontwikkelingen in de markt als gevolg van een onbeheerste IT-architectuur, die leidt tot een lage aanpasbaarheid (KPMG, 2010; Banking Review.NL, 2016; Computable, 2007; Consultancy.NL, 2015)
• Continuïteitsrisico is gedefinieerd als de kans dat banken problemen kunnen ondervinden in hun voortbestaan als gevolg van een onbeheerste IT-architectuur. Een belangrijk voorbeeld hiervan zijn het hoge aantal storingen bij internetbankieren (Joop, 2014; NU.nl, 2014a; NU.nl, 2014b; Elsevier, 2014). Bij veel van deze storingen ligt de oorzaak bij falende IT van de bank (Computerworld, 2013; Tweakers, 2015; NRCQ, 2014).
• Compliancerisico is gedefinieerd als de kans dat het niet kunnen voldoen aan wet- en regelgeving als gevolg van een onbeheerste IT-architectuur. Tegenwoordig is het toezicht op banken steeds sterker gericht op data waarbij de nadruk meer ligt op security en business continuïteit. Voorbeelden hiervan zijn BCBS 239, (eisen gesteld aan IT-architectuur en governance van risk data), informatiebeveiliging, cybercrime (De Nederlandsche Bank, 2013) en de Asset Quality Review die
16 plaatsvond in 2014 (De Nederlandsche Bank, 2013a). De bank moet alleen wel weten waar de data zit. Om dit te bewerkstelligen dienen de IT-architecturen van de bank beheerst te zijn.
Alle bovengenoemde risico’s zijn te herleiden naar de IT-architectuur van de bank. Immers, een onbeheerste IT-architectuur speelt een rol in het beperken van een bank om tijdig te reageren op marktontwikkelingen omdat de bank als gevolg van een complex en verweven IT-architectuur legacy systemen niet zomaar kan vervangen. Er dient ruim de tijd genomen te worden voor vooronderzoek, het uitvoeren van testen en veel investering in de architectuur en (nieuwe) infrastructuur alvorens de implementatie van nieuwe systemen plaats vindt (Centre for the Study of Financial Innovation, 2014). En als de bank dan gereed is om de veranderingen door te voeren is het vaak al te laat.
Daarnaast creëert een onbeheerste IT-architectuur uitdagingen om de juiste data/informatie te lokaliseren in het kader van compliance reporting door de grote hoeveelheden data die verwerkt en opgeslagen wordt in systemen (KPMG, 2014). Tevens is de data/informatie over het bedrijf heen mogelijk inconsistent doordat het geadministreerd wordt in diverse systemen met eigen data formats en regels (Centre for the Study of Financial Innovation, 2014).
Ten slotte vormt een onbeheerste IT-architectuur een bedreiging voor de continuïteit van banken die resulteert in onder andere systeemuitval (Millman, 2014; Finnegan, 2014). Andere aspecten zoals slechte uitvoering, te weinig funding, te weinig management support/commitment kunnen ook een rol spelen, maar deze staan buiten de scope van dit onderzoek.
2.3 Onderzoeksmethode
Deze deelvraag zal worden onderzocht door een literatuuronderzoek uit te voeren op de genoemde concepten en variabelen van deze deelvraag, zoals IT-architecturen, IT Governance en de genoemde risico’s hiervan voor banken. Onderzocht zal worden wat er over deze concepten en variabelen gezegd is in bestaande onderzoeken en die inzichten zullen meegenomen worden in dit onderzoek. In het kader van het literatuuronderzoek wordt er gebruik gemaakt van boeken en (wetenschappelijke) artikelen.
2.4 Literatuuronderzoek
Een van de eerste baanbrekende artikelen over IT-architectuur werd geschreven door J.A. Zachman (1987). Het toenemende gebruik van informatiesystemen binnen bedrijven triggerde Zachman om een raamwerk te definiëren om de integratie en de interfaces tussen systemen te kunnen vormgeven en te beheersen. Hij stelt hierbij vanuit drie perspectieven van een informatiesysteem vanuit de data (het eigenlijke materiaal in een informatiesysteem) (What), functionaliteit (How) in termen van hoe de data wordt gebruikt in het proces en locaties (Where) die de informatie ontvangen, drie modellen op: de data, het proces en het network model. Zijn hoofdconclusie was (gezien de tijdssfeer) dat er nog geen vaste representatie is van een IT-architectuur en dat het afhankelijk is van het perspectief van iedere functie binnen de organisatie. Zo ziet de CEO van een bedrijf de IT-architectuur als een overzicht van processen en de onderliggende IT ten opzichte van een netwerk administrator die IT-architectuur ziet als een verzameling van netwerken die met elkaar verbonden zijn. Zachman (1987) behandelde IT-architectuur in dit artikel als een concept bestaande uit diverse componenten op meerdere niveaus. In de verdere jaren hebben Zachman en andere wetenschappers op dit idee voortgebouwd en zijn er verschillende onderzoeken geweest die het concept van IT-architectuur verder hebben uitgediept. In het begin was dit beperkt tot het in kaart brengen en definiëren van de componenten waaruit een IT-architectuur bestaat en hoe deze componenten te implementeren zijn in het bedrijf. Zo hebben Sowa & Zachman (1992) het originele model van Zachman uitgewerkt tot een metamodel bestaande uit het
17 enterprise model, system model en technology model, door de concepten “tijd (When)” en “motivatie (Why)” toe te voegen. Deze twee concepten definiëren wanneer een bepaald aspect in de IT-architectuur geactiveerd wordt en waarom dit gebeurt, bijvoorbeeld een invoer in het IT-systeem als gevolg van openen van een nieuwe rekening. Hiermee maakten zij een vertaling hoe IT-architectuur geïntegreerd kan worden met de bedrijfsvoering door de diverse niveaus met elkaar te verbinden en de scope van activiteiten en benodigde IT te bepalen door de “when” en “why” concepten in de processen in te vullen. Kim & Everest (1994) ontwikkelden op basis van interviews met IT-managers een raamwerk waarin Kim & Everest stelden dat IT-architectuur uit sub-componenten bestaat zoals proces, data, control en technologie architectuur. Dit stelt het bedrijf in staat om kritieke IT resources in kaart te brengen en van daar verder te bouwen.
In de 20 jaar na de publicatie van het artikel van Zachman (1987) zijn er diverse IT-architectuur raamwerken ontwikkeld door diverse partijen. Bepaalde raamwerken uit deze groep richten zich op specifieke industrieën. Voorbeelden hiervan zijn:
• The Open Group Architecture Framework (TOGAF) dat een standaard is van The Open Group en dat uitgaat van een IT-landschap bestaande uit kritieke applicaties gebaseerd op open systemen. Daarnaast faciliteert TOGAF de ontwikkeling van principes en linkt het de enterprise architectuur met IT resource management en ontwikkeling (TOGAF, 2015; Desfray & Raymond, 2014; Urbaczewski & Mrdalj, 2006).
• De Department of Defense Architecture Framework (DoDAF). Dit raamwerk valt uiteen in drie sets van “views”, namelijk Operational, System en Technical standaarden en de “All View” om deze drie aan elkaar te linken om consistentie over de systemen te bereiken door gemeenschappelijk standaarden aan te houden (Xuemin et al, 2006; Urbaczewski & Mrdalj, 2006).
• De Federal Enterprise Architecture Framework (Urbaczewski & Mrdalj, 2006). Deze is ontstaan vanuit de Amerikaanse overheid om informatie-uitwisseling tussen de diverse overheidsinstellingen te bevorderen. Hiertoe zijn standaarden ontwikkeld waar de diverse overheidsinstellingen zich aan dienden te houden bij ontwikkeling en implementatie van hun IT-architecturen.
Gelijktijdig aan de ontwikkelingen eind jaren ‘80 en begin jaren ‘90 werd het duidelijk dat gebruik van IT binnen de bedrijfsvoering een competitief voordeel kan opleveren. Zo onderzocht Clemons (1986) de voorwaarden voor het succesvol gebruik van IT en concludeerde dat gebruik van IT de klant een voordeel moet opleveren. Daarnaast moet het gebruik van IT in lijn zijn met de bedrijfsstrategie en dienen er barrières te zijn voor concurrenten zodat zij niet zomaar toegang kunnen krijgen tot de IT resources. Dit stelt het bedrijf in staat om voor een bepaalde tijd de vruchten van de IT-investering te kunnen plukken voordat de concurrentie in staat is hetzelfde te doen. Bij ontbreken van barrières verwatert het competitief voordeel van IT omdat ieder bedrijf het direct kan inzetten. King en zijn collega’s (1989) benadrukken de waarde voor de bedrijfsstrategie van zowel informatiesystemen als de informatie in deze systemen en identificeren functionele gebieden waar informatie en informatiesystemen toegepast kunnen worden. Jackson (1989) beschrijft de veranderingen die gebruik van IT kunnen triggeren in bestaande variabelen zoals industriestructuur, macht van leveranciers en toegangsbarrières die input vormen voor de bedrijfsstrategie.
Als gevolg hiervan verplaatste het onderzoek zich naar de vraag op welke manier IT-architectuur ingezet kan worden om voordelen te bereiken en werd het in context van de bedrijfsstrategie gezet. Zo stellen bijvoorbeeld Allen & Boynton (1991) in hun onderzoek naar de invloed van IT-architectuur op flexibiliteit en efficiëntie om de IT-architectuur aan te passen op het doel dat je wilt bereiken. Flexibiliteit vereist
18 snelheid, innovatie en effectiviteit in je IT-architectuur terwijl efficiëntie de omgekeerde eigenschappen vraagt.
Al snel ontwikkelde IT zich tot een evenknie van de business in tegenstelling tot een supportfunctie die IT vroeger had. Nu diende er een wezenlijk IT-strategie te zijn die in alignment is met de bedrijfsstrategie, om als organisatie waarde toe te kunnen voegen aan de organisatie door inzet van IT. Al in 1989 concludeerde Henderson & Venkatraman (1989) dat strategische IT-management zich uit in alignment op meerdere niveaus. Zo dient er horizontale alignment te zijn tussen Business strategie en de IT-strategie (strategic integration) en daarmee ook tussen de onderliggende organisatie-infrastructuur en processen en IT-organisatie-infrastructuur en processen (functional integration). Tegelijkertijd is het van belang dat de IT en business strategieën aansluiten op de onderliggende infrastructuur en processen (Henderson & Venkatraman, 1989; Henderson & Venkatraman, 1999). Dit resulteert in vier alignment perspectieven, afhankelijk van of IT of business als uitgangspunt wordt genomen.
Dit idee van Business en IT alignment is ook verder uitgediept in andere onderzoeken. Baets (1992) propageert een alternatieve strategie om Business en IT alignment te bereiken in geval van een onduidelijke of rigide bedrijfsstrategie. De alternatieve strategie stelt om op basis van de bedrijfsstrategie informatiebehoeften te definiëren om deze vervolgens te integreren in de IT-architectuur en te vertalen naar de IT-applicatiestrategie. Venkatraman et al. (1993) onderzochten de onderliggende alignment perspectieven en mechanismen als aanvulling op hun artikel over business en IT alignment uit 1989 (Henderson & Venkatraman, 1989). Ze concluderen dat op basis van de ontwikkelingen uit de industrie waar het bedrijf in opereert, de bedrijfsstrategie of IT-strategie als primaire drijfveer wordt gezien die leidt tot de invulling van de resterende variabelen, resulterend in vier perspectieven namelijk, Strategy Execution, Technology Potential, Competitive Potential en Service Level. Om de gekozen alignment ook administratief te kunnen bewerkstelligen formuleren ze een viertal mechanismen namelijk, governance process, technological capability, human skills en value management. Dit onderzoek werd opnieuw uitgebracht in 1999 (Henderson & Venkatraman, 1999). Pereira & Sousa (2005) definieerden in hun onderzoek een drietal heuristieken om alignment tussen business en IT te bewerkstelligen op het gebied van Business, Informatie en Applicatie Architectuur. Winter & Schelp (2008) verlegden het idee van Business en IT alignment in de vorm van Enterprise Architecture Governance naar een bredere scope en verkennen de toepassingen voor ondersteunende processen zoals compliance management, business continuity management, risk management door analyses op te stellen.
Ross (2003) heeft in haar onderzoek specifiek gekeken naar de IT-architectuur waarbij ze vier fasen van volwassenheid definieert, variërend van een “application silo architecture” (beperkte waarde voor business strategie als geheel) tot een volledig “modulair architecture” (levert hoge flexibiliteit van de business).
Over de jaren heen is de IT-architectuur almaar blijven groeien op basis van een korte-termijnperspectief met als gevolg dat het op den duur een grote spaghetti is geworden bestaande uit een reeks van (oude en nieuwe) systemen met verschillende mate van technologische verfijning (Reddy & Reddy, 2002; Kelly et al, 1999). Deze systemen zijn met (handmatige) koppelingen aan elkaar verbonden en dermate met elkaar verweven zijn dat effecten van veranderingen in een bepaald systeem op de rest van de architectuur lastig te overzien zijn (Kelly et al, 1999). Deze situatie is enerzijds ontstaan door de toenemende complexiteit van IT-architectuur als gevolg van uitbreiding en interne
19 groei en anderzijds als gevolg van externe groei in de vorm van fusies en overnames (Reddy & Reddy, 2002). Dit wordt ook aangeduid als legacy systemen in het IT-landschap.
Legacy systemen zijn bedrijfskritieke systemen die als ruggengraat van de organisatie fungeren en bedrijfsinformatie consolideren. Uitval van deze systemen heeft een serieuze impact op de bedrijfsvoering (Bisbal et al, 1999). Legacy systemen hebben veelal belemmerende kenmerken voor de bedrijfsvoering (Bisbal et al, 1999). Zo zijn legacy systemen lastig om aan te passen aan nieuwe ontwikkelingen en is het lastig en kostbaar om deze systemen goed te onderhouden omdat ze op verouderde hardware draaien. Daarnaast is integratie met andere (nieuwe) systemen niet eenvoudig door gebrek aan correcte interfaces. Deze kenmerken beperken de flexibiliteit van de organisatie om te acteren op de ontwikkelingen in de externe omgeving (Reddy & Reddy, 2002; Kelly et al, 1999). Ook heeft het een invloed op de efficiëntie van de bedrijfsvoering (Kelly et al, 1999).
De bancaire industrie wordt gekenmerkt door een hoge mate van IT gebruik waaruit een groot deel van de IT uit legacy systemen bestaat (Centre for the Study of Financial Innovation, 2014). Banken zijn een van de grootste investeerders in IT om hun operationele efficiëntie en klantbeleving te verbeteren (Gupta & Collins, 1997). Banken kunnen door gebruik van IT de klant beter bedienen door onder andere elektronisch bankieren en interne processen te automatiseren en kosten te verlagen (Ghaziri, 1998). Al met al levert IT diverse voordelen voor banken op maar tegelijkertijd hebben banken te maken met legacy systemen in hun IT-architectuur belemmeren om aan te sluiten bij nieuwe ontwikkelingen (Kelly et al, 1999; Commissie Structuur Nederlandse Banken; 2013; KPMG, 2010; Centre for the Study of Financial Innovation, 2014) en zelfs een bedreiging vormen voor de continuïteit (Flinders, 2014). De allereerste core banking systemen zijn ontwikkeld en geïmplementeerd in de jaren ‘70 en ‘80 en zijn van daaruit als gevolg van verspreiding en uitbreiding van bancaire diensten en fusies en overnames uitgegroeid tot enorm grote logge, inefficiënte systeemlandschappen (Deloitte Touche Tohmatsu, 2008; Dias et al, 2012; Capgemini Consulting, 2013; Heidmann, 2010), die onbeheersbaar zijn geworden waardoor ze mogelijke competitieve voordelen uit onder andere innovatie kunnen mislopen.
Aangezien IT een kritische component is van de bedrijfsvoering van een bank, stellen onbeheersbare IT-architecturen banken bloot aan tal van risico’s. De IT-risico’s kunnen grofweg gegroepeerd worden in de volgende categorieën: beschikbaarheid, performance, beveiliging en compliance (Savic, 2008).
Beschikbaarheidsrisico wordt in de literatuur geformuleerd als niet-toegankelijke systemen als gevolg van systeem falen, netwerkuitval, data center uitval of natuurrampen (Savic, 2008). Uit nieuwsberichten van afgelopen jaren blijkt dat bij veel van de storingen bij internetbankieren (Joop, 2014; NU.nl, 2014a; NU.nl, 2014b; Elsevier, 2014) de oorzaak ligt bij falende IT van de bank (Computerworld, 2013; Tweakers, 2015; NRCQ, 2014; Osbourne, 2014). Daarmee vormt systeem falen een nog groter risico aangezien het de continuïteit van de banken in gevaar kan brengen (Flinders, 2012; Flinders, 2014; Thomalla & McCarthy, 2014; Hill, 2014; Millman, 2014; Finnegan, 2014). Dit wordt ook als reëel risico gezien door banken (Centre for the Study of Financial Innovation, 2014).
Tegelijkertijd neemt regulering vanuit toezichthouders op banken als gevolg van de economische crisis almaar toe (De Nederlandsche Bank, 2013a; De Nederlandsche Bank, 2014a; De Nederlandsche Bank, 2014b; Finnegan, 2014; Joint Committee of the European Supervisory Authorities, 2014; Joint Committee of the European Supervisory Authorities, 2015; The Boston Consulting Group, 2011) en zijn de gevolgen om niet aan deze regulering te voldoen voor banken zeer ingrijpend. Banken identificeren de non-compliance met regulering dan ook als het meest impactvolle risico omdat ze het onder andere
20 als erg complex percipiëren (Centre for the Study of Financial Innovation, 2014) en dat IT-architectuur cruciaal is om data te kunnen leveren in het door toezichthouders gewenste format en dat de huidige IT-architectuur de nodige uitdagingen levert om hieraan te kunnen voldoen (Angius & Bonomo, 2014; KPMG, 2014; The Boston Consulting Group, 2011).
2.5 Resultaten en Analyse
Uit het literatuuronderzoek komt naar voren dat IT-architectuur als concept al in de jaren 80 was onderzocht door Zachman als gevolg van toenemende gebruik van IT binnen bedrijven en de behoefte de interfaces en relaties met de business in kaart te brengen. Vervolgens hebben diverse onderzoekers hier op voortgebouwd en zijn er in de loop van de 20 jaar erna meerdere raamwerken tot stand gekomen zoals DoDAF, FEAF en TOGAF. Ook ontstond eind jaren ‘80 het bewustzijn dat gebruik van IT binnen bedrijven kan resulteren in een competitief voordeel. Veel onderzoek wees uit hoe IT kan bijdragen aan processen zoals efficiëntie of innovatie. Maar het onderzoek van Henderson & Venkatraman (1989) over business en IT alignment tilde IT naar een gelijkwaardig niveau met de business, waarbij IT als evenknie werd beschouwd in plaats van een ondersteunend component. Iedereen zette in op het gebruik van IT maar nam niet een langtermijnperspectief in. Als gevolg hiervan zijn IT-landschappen ontstaan die bestaan uit diverse soorten systemen variërend in technologische verfijning en zijn dermate met elkaar verweven door meerdere (handmatige) interfaces. Dit resulteert in een hoge mate van complexiteit als het gaat om bijvoorbeeld wijzigingsbeheer van IT systemen en applicaties.
Deze trend zette ook in bij banken. Uit bovenstaand literatuuronderzoek blijkt dat onbeheerste IT-architecturen ook bij banken het gevolg zijn van het toenemende gebruik van IT binnen banken waarbij niet naar de lange termijn is gekeken. Om deze reden zijn de IT-architecturen uitgegroeid tot onbeheersbare complexe landschappen bestaande uit veel legacy IT. Voor banken is dit probleem nog groter omdat IT een kritische component is van de bedrijfsvoering van een bank. Zonder een goedlopend IT-netwerk ligt de bank plat en kan hij zijn (kritieke) bedrijfsactiviteiten niet uitvoeren. Op basis van het literatuuronderzoek is geconcludeerd dat de belangrijkste risico’s van een onbeheerste IT-architectuur samen te vatten zijn in de volgende risico’s:
• Als gevolg van een complexe en onbeheerste IT-architectuur zijn banken niet in staat om tijdig aan te sluiten op nieuwe ontwikkelingen in de markt omdat het te lang duurt om hun huidige IT-architectuur en landschap klaar te maken voor de betreffende ontwikkeling. Hierdoor lopen ze mogelijke competitieve voordelen uit innovaties mis. Dit is gedefinieerd als marktrisico.
• Het feit dat een bank zijn (kritieke) bedrijfsactiviteiten niet kan uitvoeren als gevolg van systeemfalen, netwerkuitval, data center uitval of natuurrampen en waardoor de continuïteit in het gevaar komt. In de literatuur zijn diverse gevallen aan te wijzen waarbij onder andere de legacy systemen, IT-infrastructuur en IT-architectuur de oorzaak zijn van systeemuitval en een gevaar vormen voor de continuïteit indien hier niets aan gedaan wordt. Dit is gedefinieerd als continuïteitsrisico.
• Tegenwoordig neemt het toezicht op banken vanuit toezichthouders almaar toe. Tevens verruimt het zich naar data die in een bepaald format geleverd dient te worden. De huidige IT-architectuur is onvoldoende geëquipeerd om de juiste data snel en in één keer in het juiste format op te kunnen leveren hetgeen leidt tot de nodige risico’s. Dit is gedefinieerd als compliancerisico.
21
2.6 Conclusie
In dit hoofdstuk is in kaart gebracht wat de meest belangrijke risico’s zijn van een onbeheerste IT-architectuur. Er is gekozen om met de drie risico’s van markt-, compliance- en continuïteitsrisico verder te gaan in deze scriptie omdat uit het literatuuronderzoek blijkt dat bovengenoemde risico’s de meeste impact hebben op de bedrijfsvoering van een bank. Een onbeheerste IT-architectuur beperkt een bank om tijdig te reageren op marktontwikkelingen, creëert uitdagingen om de juiste data /informatie te lokaliseren in het kader van compliance en kan een bedreiging vormen voor de continuïteit bij bijvoorbeeld systeemuitval. Dit sluit aan bij de voorgenomen selectie van risico’s aan het begin van dit hoofdstuk.
22
Hoofdstuk 3: Welke bijdrage levert COBIT5 aan de beheersing van een
IT-architectuur?
3.1 Introductie
Dit hoofdstuk behandelt de tweede sub-vraag van deze scriptie en luidt als volgt: “Welke bijdrage levert COBIT5 aan de beheersing van een IT-architectuur?”. Het hoofdstuk start met een korte introductie van COBIT5. Vervolgens wordt het onderzoekmethode voor deze deelvraag uitgelegd gevolgd door een literatuuronderzoek over COBIT en de toepassingen ervan op het gebied van IT-architectuur. Ten slotte worden de resultaten van het literatuuronderzoek besproken en gerapporteerd.
3.2 COBIT
COBIT is een raamwerk ten behoeve van IT management en is gedefinieerd door de internationale organisatie ISACA dat zich richt op IT Governance. De acroniem COBIT staat voor Control Objectives for IT en brengt een set aan standaarden en best practices zoals COSO, ITIL, BiSL, ISO 27000, CMMI, TOGAF en PMBOK samen om een set aan beheersmaatregelen te creëren om IT-processen te kunnen beheersen en managen. Het kenmerkende van COBIT is dat het business processen en doelen linkt met IT-processen en doelen en daarmee tracht alignment te creëren tussen business en IT. COBIT verschaft ook metrieken en volwassenheidsmodellen om de niveau van IT beheersing en alignment met business meetbaar te maken. De allereerste editie van COBIT werd in 1996 gepubliceerd. Er volgden nog vier versies waarvan COBIT5 de laatste is. In praktijk worden COBIT4.1 en COBIT5 het meest gebruikt. In COBIT4.1 werd IT verdeeld in vier domeinen namelijk Plan and Organise, Acquire and Implement, Deliver and Support en Monitor and Evaluate waarin de 34 processen verdeeld zijn. Ieder domain is onderverdeeld in diverse onderwerpen. Voor ieder onderwerp worden de beheersdoelstellingen, richtlijnen, inputs en outputs behandeld om effectieve beheersing en governance te bewerkstelligen. COBIT5 is de vijfde editie van het COBIT raamwerk en werd in juni 2012 gepubliceerd. In deze editie is de scope van de IT-processen aangepast en uitgebreid en bestaat uit vijf domeinen en 37 processen (zie bijlage 1). De processen zijn verdeeld onder IT Governance en management. De vijf domeinen luiden als volgt (zie figuur 2):
• Evaluate, Direct and Monitor (EDM) – 5 processen • Align, Plan and Organise (APO) – 13 processen • Build, Acquire and Implement (BAI) – 10 processen • Deliver, Service and Support (DSS) – 6 processen • Monitor, Evaluate and Assess (MEA) – 3 processen
23 Figuur 2 COBIT5 Processen (Bron: ISACA, 2012)
COBIT5 definieert een aantal elementen die implementatie van een bepaald COBIT5 proces - en daarmee een bepaald enterprise en IT goal – ondersteunen en tastbaar maken. Deze worden door COBIT5 de enabler genoemd (ISACA, 2012). COBIT5 beschrijft zeven soorten enablers:
1. Principles, policies and frameworks: instrumenten om gewenst gedrag om te zetten in procedures en beleid. Vormt het startpunt waar andere enablers uit voortkomen.
2. Processes: set van practices en activiteiten om bepaalde doelstellingen te bereiken en bepaalde output te kunnen realiseren.
3. Organisational structures: beschrijving van de beslissende entiteiten binnen een organisatie. 4. Culture, ethics and behavior: een aspect dat veelal onderschat wordt binnen organisaties om
bepaalde doelen te bereiken.
5. Information: Informatie is nodig om de organisatie draaiende te houden en draagt bij aan het bereiken van de gedefinieerde doelstellingen.
6. Services, infrastructure and applications: de infrastructuur, technologie en applicaties die voorzien in verwerking van IT.
24 7. People, skills and competencies: het mens-aspect dat benodigd is om de doelstellingen te
kunnen bereiken.
Figuur 3 COBIT5 Enablers (ISACA, 2012)
3.3 Onderzoeksmethode
De genoemde deelvraag in paragraaf 3.1 wordt onderzocht door een literatuuronderzoek uit te voeren waarbij het COBIT5 raamwerk en onderzoeken gerelateerd aan COBIT en IT-architectuur worden onderzocht om in kaart te brengen hoe COBIT kan bijdragen aan de beheersing van IT-architecturen.
3.4 Literatuuronderzoek
COBIT5 (ISACA, 2012) staat voor de Control Objectives for IT versie 5 en bestaat uit een set van 37 processen die hun bijdrage leveren aan de IT Governance binnen een bedrijf. In de literatuur is COBIT een veelbesproken onderwerp dat door diverse onderzoekers is onderzocht. Aangezien COBIT een raamwerk is om IT te managen en besturen is er naast verkennende literatuur (Guldentop, 2002; Ridley et al, 2004; van Grembergen et al, 2005) ook veel aandacht geweest in de literatuur waarbij COBIT onderzocht wordt in relatie tot een bepaald bedrijfsaspect, -resultaat, -proces of markt en de invloed die COBIT hierop heeft. Een paar voorbeelden hiervan zijn vendor evaluation (Pederiva, 2003), service level management van service providers (Van Grembergen et al, 2003) en toepassing van COBIT bij Arabische bedrijven (Ahmad, 2009). Hierna onderzochten onderzoekers hoe diverse raamwerken als ITIL, COBIT en ISO gecombineerd konden worden om tot krachtiger raamwerk te komen (Sahibuddin et al, 2008). Een proces in COBIT5 valt uiteen in beschrijving van proces, de purpose statement gevolgd door een beschrijving van de IT en procesdoelen die dit het betreffende COBIT5 proces ondersteunen met de bijbehorende metrieken. Een proces bestaat uit meerdere management practices, zogenoemde deelprocessen om het overall proces te kunnen realiseren. Verder wordt ieder management practice beschreven aan de hand van de inhoud, de inputs en outputs die de betreffende management practice dient voort te brengen en welke activiteiten hiervoor nodig zijn. Waar COBiT4.1 nog expliciet controle doelstellingen beschreef heeft COBIT5 deze controle doelstellingen onderbracht in de management practices en ondersteunende activiteiten.
Het COBIT5 Raamwerk (ISACA, 2012) adresseert de IT-architectuur in het proces AP003 Manage Enterprise Architecture dat valt binnen het domein Align, Plan and Organise (APO). De “Process Description” van APO03 luidt als volgt:
25 “Establish a common architecture consisting of business process, information, data, application and technology architecture layers for effectively and efficiently realising enterprise and IT strategies by creating key models and practices that describe the baseline and target architectures. Define requirements for taxonomy, standards, guidelines, procedures, templates and tools, and provide a linkage for these components. Improve alignment, increase agility, improve quality of information and generate potential cost savings through initiatives such as re-use of building block components.”
Deze definitie sluit aan op de definitie zoals gehanteerd in deze scriptie en is geformuleerd door Ross (2003).
Het COBIT5 proces APO03 bestaat uit doelen om effectieve standaarden en architectuur met de daarbij behorende enterprise architectuur services op te zetten, betrouwbare architectuurinformatie te creëren en een door het bedrijf gedeelde en geïntegreerde architecture raamwerk en repository te creëren. Door deze uniformiteit in architectuur kunnen gerealiseerde voordelen binnen een bepaald bedrijfsonderdeel breder toegepast worden in andere bedrijfsonderdelen.
Het proces APO03 valt uiteen in vijf management practices die de fasen van de levenscyclus van een IT-architectuur beschrijven. Een management practice is deelproces. Binnen iedere management practice is een aantal activiteiten die doorlopen worden om de practice uit te kunnen voeren. Tevens schrijft iedere management practice een aantal inputs en outputs voor die het resultaat zijn van de uitvoer van de betreffende management practice. Vaak vormt de output van een bepaald COBIT management practice input voor een ander COBIT5 management practice.
• APO03.01 Develop the enterprise architecture vision • APO03.02 Define reference architecture
• APO03.03 Select opportunities and solutions • APO03.04 Define architecture implementation • APO03.05 Provide enterprise architecture services
De eerste management practice start bij de ontwikkeling van een visie voor de IT-architectuur (APO03.01). Dit is een high-level beschrijving van de baseline en doelarchitectuur voor de business, informatie, data, applicaties en technologieën. Hier wordt de eerste stap gezet voor de business en IT alignment door doelstellingen, prioriteiten en vereisten van onder andere het bedrijf, stakeholders en projecten in kaart te brengen en vast te stellen waar een IT-architectuur aan dient te voldoen om bovengenoemde aspecten te ondersteunen.
Dit wordt gevolgd door de definitie van een referentiearchitectuur bestaande uit de huidige en doelarchitectuur uitgewerkt in termen van de informatie, data, applicaties en technologieën (APO03.02). Na review door de stakeholders wordt er een architectuur definitie document opgesteld. Ook worden de procesdocumentatie gestandaardiseerd en de rollen en verantwoordelijkheden van process owners, users, decision makers voor de IT-architectuur gedefinieerd en toegewezen.
Vervolgens dienen de gaps, afhankelijkheden en belemmeringen vanuit de organisatie in kaart te worden gebracht en hier oplossingen voor gedefinieerd te worden om de IT-architectuur klaar te kunnen maken voor implementatie (APO03.03).
Op basis van de informatie in APO03.03 wordt een implementatie- en migratieplan opgesteld dat de verschillende fasen en benodigde resources beschrijft (APO03.04). Ook dient rekening gehouden te worden met toevoegingen aan de architectuur als gevolg van nieuwe inzichten.
26 Na implementatie dient de IT-architectuur gemanaged te worden onder andere via monitoring en formalisatie van processen en procedures om business en IT alignment te behouden (APO03.05).
Proces APO03 is ook gelinkt aan een aantal IT-gerelateerde doelen in COBIT5. Zo draagt proces APO03 bij aan de alignment tussen de IT en business strategie, aan de wendbaarheid van de IT van een bedrijf en bevordert het de optimalisatie van de IT assets, resources en capabilities (ISACA, 2012). Bij het definiëren van het proces APO03 Manage the Enterprise Architecture heeft COBIT5 zich gebaseerd op de Architecture Development Method van TOGAF (TOGAF, 2015). Zo sluiten een aantal management practices van APO03 aan op de Architecture Development Method fasen van TOGAF zoals “developing an architecture vision” (ADM Phase A), “defining reference architectures” (ADM Phases B, C, D), “selecting opportunities and solutions” (ADM Phase E), and “defining architecture implementation” (ADM Phases F, G).
Naast de reguliere COBIT5 processen met de bijbehorende management practices bevat COBIT5 ook een aantal aanvullende resources, die ondersteuning bieden bij het definiëren en vormgeven van een effectieve beheersing van de IT-architectuur.
Ten eerste beschrijft COBIT5 de mapping van de COBIT5 Enterprise Goals naar IT-related goals. Dit verbindt de organisatiedoelen met de IT-doelen om alignment tussen de Business en IT alignment te creëren. Er wordt gesproken over primaire en secundaire relaties, wat onderscheid maakt tussen IT-related goals die onmisbaar zijn en IT-IT-related goals die meer een support functie hebben om de betreffende enterprise goal te realiseren. Ook is er een mapping meegeleverd tussen de COBIT5 IT-Related Goals en de COBIT5 processen. Het onderscheid tussen primaire en secundaire relaties is ook hier van toepassing. Via deze mappings kan een enterprise goal herleidt worden naar het laagste niveau van een COBIT5 proces. Bijvoorbeeld, een risico uit hoofdstuk 2 dat te maken heeft met compliance, is gedefinieerd in enterprise goal 4: “Compliance with external laws and regulations”. Deze goal heeft een primaire relatie met IT-related Goals 2 en 10, respectievelijk “IT compliance and support for business compliance with external laws and regulations” en “Security of information, processing infrastructure and applications”. Als er wordt doorgegaan met IT-related goal 2 dan is te zien dat in de mapping tussen IT-Related goals en COBIT5 processen dat COBIT5 processen APO01, APO12, APO13, BAI10 en DSS05 (zie bijlage 1 voor definitie processen) een primaire relatie hebben met het realiseren van IT en business compliance. De genoemde processen bevatten dus aspecten die als input dienen voor vormgeving van de beheersing van compliance.
Ten tweede heeft COBIT5 een mapping gemaakt van de veel voorkomende stakeholder behoeften naar de enterprise goals. Op deze manier kan effectieve stakeholder management voor IT worden uitgevoerd.
Ten derde bevat COBIT5 een overzicht van de meest voorkomende pijnpunten binnen IT management bij organisaties die worden gemapt naar de verschillende COBIT5 processen die aspecten bevatten om dit pijnpunt op te lossen. Zo is het pijnpunt “IT limiting the enterprise’s innovation capabilities and business agility” gemapt naar COBIT5 processen EDMO4, APO02 en APO04 (zie bijlage 1 voor definitie processen).
Ten vierde heeft Cobit een dergelijke mapping ook gemaakt met bepaalde risicoscenario’s. In bijlage C van het COBIT5 implementatie raamwerk staan 36 risicoscenario’s verdeeld over de risicogroepen benefit/value enblement risk, programme/project delivery risk en service delivery/IT operations risk die gemapt worden naar specifieke aspecten van COBIT5 processen. Dit stelt organisaties in staat om COBIT5 te conceptualiseren en te implementeren via een risk based approach.
27 Ten slotte heeft COBIT5 een voorbeeld decision matrix opgesteld waarbij de voor 15 veelvoorkomende onderwerpen een RACI-lijst is beschreven die aangeeft welke verantwoordelijkheden en rollen management en committees hebben binnen ieder onderwerp.
Als er een blik geworpen wordt op wetenschappelijk onderzoek, dan kan vastgesteld worden dat er veel onderzoek is geweest op het gebied van COBIT in relatie tot IT-architectuur. Zo hebben Hojaji en Shirazi (2010a, 2010b) in kaart gebracht hoe de governance van Service Oriented IT-architectuur (SOA) verbeterd kan worden aan de hand van COBIT en ITIL. Enerzijds creëert COBIT een IT en Business Alignment en voegt het beheersdoelstellingen, metrieken en maturity concepten toe en maakt beheersing en meetbaarheid van de Service Oriented IT-architectuur (SOA) governance mogelijk. Anderzijds voegt ITIL het proces van service lifecycle management toe zodat de Service Oriented IT-architectuur in iedere fase vanaf conceptualisatie tot en met maintenance goed gemanaged wordt. Deze combinatie van COBIT en ITIL resulteert in een SOA Architectuur governance raamwerk met beheersdoelstellingen en metrieken voor iedere fase van de gehele levenscyclus.
Karoline Westerlund (2015) heeft in haar artikel als één van de eersten een voorzet gedaan om een directe vertaling te maken tussen IT-architectuur en de bijbehorende COBIT proces APO03 “Manage Enterprise Architecture” om een beheersplan op te stellen voor IT-architectuur van de universiteit waar ze werkte. Ze startte met het opstellen van vier doelen die aansluiten op de behoeften van de universiteit. Vervolgens heeft ze voor deze doelen metrieken opgesteld aan hand van de metrieken van proces APO03 en deze aangepast om te kunnen voldoen aan de behoeften van de universiteit.
3.5 Resultaten en Analyse
Uit het literatuuronderzoek blijkt dat COBIT5 een specifiek proces heeft toegewezen aan de management van IT-architectuur namelijk proces “APO03 Manage Enterprise Architecture”. Dit bestaat uit een aantal IT doelen en procesdoelen met de daarbij behorende metrieken en vijf management practices gericht op de levenscyclus van een IT-architectuur. Iedere management practice geeft een beschrijving van de practice, de onderliggende activiteiten, de inputs en outputs die het resultaat zijn van de uitvoering van de betreffende management practice. Deze management practices en activiteiten vormen de beheersdoelstellingen voor effectieve IT-architectuur governance. Deze processen zijn ook onderzocht door deze te mappen met diverse type risico’s en pijnpunten om de toepasbaarheid van de COBIT5 processen tastbaar te maken. Daarnaast is er veel onderzoek geweest over de bruikbaarheid van COBIT als concept om beheersing van processen in te richten. Bovendien wordt COBIT in diverse literatuur onderzocht in verband met een bepaald bedrijfsaspect, proces of onderwerp om het te verbeteren of voordeel uit te halen.
3.6 Conclusie
Dit hoofdstuk heeft in kaart gebracht welke bijdrage COBIT5 als governance raamwerk levert om IT-architecturen te kunnen beheersen. Binnen COBIT5 is een heel proces gedefinieerd dat uitvoerig uitlegt hoe IT-architecturen beheerst kunnen worden over hun gehele levenscyclus aan de hand van activiteiten, rollen en verantwoordelijkheden, IT en procesdoelen met bijbehorende metrieken. In het volgende hoofdstuk worden de resultaten uit hoofdstuk 2 en 3 samengevoegd en wordt in kaart gebracht welke handvatten COBIT5 biedt om de in hoofdstuk 2 gevonden risico’s te kunnen beheersen.
28
Hoofdstuk 4: Welke handvatten biedt COBIT5 ter beheersing van de
IT-architectuur?
4.1 Introductie
Dit hoofdstuk behandelt de derde sub-vraag van deze scriptie namelijk “Welke handvatten biedt COBIT5 ter beheersing van de IT-architectuur?”. Dit hoofdstuk start met uitleg van de onderzoekmethode voor deze deelvraag gevolgd door een onderzoek en vergelijking van de resultaten van de twee voorafgaande deelvragen. Ten slotte worden de resultaten gerapporteerd.
4.2 Onderzoeksmethode
Deze deelvraag zal onderzocht worden door een vergelijking te maken van de resultaten van deelvraag 1 en 2 om vast te kunnen stellen of de uitspraken en bijdrage van COBIT5 met betrekking tot de beheersing van IT-architecturen (deelvraag 2) voldoende zijn om de in deelvraag 1 geïdentificeerde risico’s te kunnen beheersen en indien mogelijk te mitigeren. Ook zullen gaps in kaart worden gebracht aan de hand waarvan de theorie wordt verfijnd.
4.4 Onderzoek
In hoofdstuk 2 werd deelvraag 1 “Wat zijn de risico’s van een onvoldoende beheerste IT-architectuur?” onderzocht en beantwoord. Hieruit kwam naar voren dat marktrisico, continuïteitsrisico en compliancerisico de belangrijkste risico’s vormen van een onbeheerste IT-architectuur bij banken. Een onbeheerste IT-architectuur belet de organisatie om zich snel aan te passen aan de veranderingen in de omgeving waardoor mogelijk competitieve voordelen misgelopen worden. Daarnaast kan als gevolg van een onbeheerste IT-architectuur, systeemfalen optreden en continuïteit in gevaar worden gebracht. Ten slotte kan door een onbeheerste IT-architectuur mogelijk niet worden voldaan aan de vereisten van toezichthouders door onjuiste informatie of informatie te laat te leveren aan de toezichthouder.
COBIT5 (hoofdstuk 3) is een overkoepeld raamwerk dat handvatten aanreikt voor effectieve management en governance van IT binnen een organisatie, waarbij ze de business en IT alignment vooropstelt. Naast een verzameling van IT-processen zijn er ook diverse soorten mappings gemaakt tussen de COBIT5 processen en zaken als risico’s en tekortkomingen in de IT organisatie die als input kunnen dienen om een COBIT5 implementatie op gang te krijgen.
Werkwijze
De Risk Scenario en Pain-point mapping naar COBIT5 processen (ISACA, 2012) worden onderzocht om een koppeling te kunnen maken tussen de genoemde risico’s in deelvraag 1 (hoofdstuk 2) en COBIT5 processen (hoofdstuk 3). Ook worden de COBIT5 enterprise goals gemapt met de onderliggende IT-related goals om de onderliggende COBIT5 processen in kaart te brengen die in verband staan met de genoemde risico’s. Van hieruit worden goals/doelstellingen gedefinieerd om deze risico’s te mitigeren. Deze goals/doelstellingen worden onderbouwd met activiteiten en de actoren in COBIT5 die de activiteiten uitvoeren om de goals/doelstellingen te realiseren. Zie bijlage 2 voor een uitwerking van de werkwijze voor definiëren van de doelstelling(en) en beheersmaatregelen zoals die zijn gedefinieerd voor compliancerisico.
29
4.5 Resultaten en Analyse
Op basis van bovengenoemde werkwijze zijn voor ieder risico de processen in kaart gebracht om vervolgens de doelstelling(en) en onderliggende beheersmaatregelen te kunnen definiëren. Hieronder is per risico weergeven welke handvatten COBIT5 biedt en hoe dat risico beheerst en indien mogelijk gemitigeerd kan worden en hoe tot deze resultaten is gekomen. Zie bijlage 2 voor een uitwerking van de werkwijze voor definiëren van de doelstelling(en) en beheersmaatregelen zoals die zijn gedefinieerd voor compliancerisico.
Marktrisico
In hoofdstuk 2 is marktrisico gedefinieerd als de kans dat banken niet kunnen aansluiten bij nieuwe ontwikkelingen in de markt als gevolg van een onbeheerste IT-architectuur en daarmee een lage aanpasbaarheid hebben. In COBIT5 (ISACA, 2012) wordt agility van de organisatie genoemd op de volgende punten:
• Risk Scenario’s: New technologies, architectural agility and flexibility • Pain Point: IT limiting innovation capabilities and business agility. • Enterprise goal 8: “Agile responses to a changing business environment” • IT-related goals:
• 7: Delivery of IT in line with business requirements • 9: IT Agility
• 17: Knowledge, expertise and initiatives for business innovation. Vervolgens is onderzocht welke COBIT5 processen hier aan zijn verbonden.
Om het risico van lage aanpasbaarheid te kunnen mitigeren wordt vanuit de Risk Scenario en Pain Point mapping verwezen naar aspecten van COBIT5 processen APO01, APO02, APO03, APO04, APO05, APO13, BAI02, BAI03 en EMD04.
Volgens de mapping tussen Enterprise en IT-Related goals heeft Enterprise goal 8: “Business Service Continuity and availability” een primaire relatie (de IT-goal is essentieel om de Enterprise goal te bereiken) met IT-related goal 7 “Delivery of IT in line with business requirements”, 9 “IT Agility” en 17 “Knowledge, expertise and initiatives for business innovation”. Een mapping van deze drie doelen naar COBIT5 processen resulteert in de volgende processen die een primaire relatie hebben met deze doelen: EDM02, EDM04, APO01, APO02, APO03, APO04, APO07, APO08, APO09, APO10, APO11, BAI02, BAI03, BAI04, BAI05, BAI06.
Door middel van analyse en adaptatie van bovengenoemde processen is het volgende raamwerk opgesteld om marktrisico als gevolg van een onbeheerste IT-architectuur te kunnen beheersen.
Doelstelling 1. IT-architectuur draagt bij aan innovatie en kapitaliseren van kansen in de externe omgeving (APO04).
Beheersmaatregel 1 Verantwoordelijkheden voor de monitoring van trends in de externe omgeving zijn belegd bij de Chief Information Officer, business executives, business process owners en de hoofden van IT Architecture Development en IT Operations (APO4.02).
Beheersmaatregel 2 Ieder kwartaal wordt door de Service Manager, Information Security Manager, business executives, business process owners en de hoofden van IT
