Het applicatielandschap: het bos én de bomen zien!

Bedrijven hebben grote hoeveelheden IT-applicaties. Die variëren van klein tot groot, van onbelangrijk tot bedrijfskritisch en van applicaties in eigen beheer tot services in de cloud. Het is essentieel om het hele applicatielandschap te overzien, maar ook de relevante eigenschappen van de individuele applicaties. Hoe houdt een bedrijf grip op dit alles?

IT-applicaties zijn vanuit diverse perspectieven interessant. Iemand met een financiële achtergrond wil weten wat een applicatie kost en hoe voorspelbaar deze kosten zich ontwikkelen in de loop van de jaren. Iemand met een securityachtergrond vraagt zich af hoe veilig een applicatie is en hoe vertrouwelijk een applicatie de data verwerkt. Kijk je vanuit de business, dan wil je misschien weten hoe effectief de businessprocessen ondersteund worden. Een auditor let op de risico’s van een applicatie of applicatielandschap en de bijbehorende beheersmaatregelen. En een enterprisearchitect wil vooral dat de applicatie past in een architectuurplan, hoe een keten van applicaties een end-to-endbedrijfsproces ondersteund en hoe toekomstbestendig en onderhoudbaar de applicaties zijn.

Inzicht en overzicht in het applicatielandschap

Of je nu tientallen, honderden of duizenden applicaties gebruikt, het wordt al snel lastig om het overzicht te behouden en te bepalen welke actie waar nodig is. Zeker in een situatie met beperkte capaciteit en beperkt budget. Bij Rabobank gebruiken we al een aantal jaren de application value analysis-methode (AVA) van Gartner (zie kader). Dit geeft ons tegelijkertijd inzicht en overzicht. Hierna lichten we toe welke waarde AVA ook voor een auditor kan hebben, uitgeschreven in de stappen die de AVA logischerwijze doorloopt.

Stap 1 – Bepaal de bron

Als startpunt is een betrouwbare bron (golden source) nodig van alle applicaties. Voor kleine organisaties zal dit beginnen met een spreadsheet, maar grotere bedrijven zullen al snel een configuration managementdatabase (CMDB) gaan gebruiken: een gestructureerde bron met alle IT hard- en software. Een dergelijk bron is zeer wenselijk want vanuit IT-governance frameworks zoals COBIT wordt deze namelijk ook geadviseerd. Maar de definitie en scope van een applicatie kan echter veel discussie opleveren.

Een zelfbouwsysteem of een systeem in de cloud (SaaS) is vanzelfsprekend een applicatie. Maar wat te doen met IT-diensten zoals een website waar je, met een contract, op mag inloggen om data op te halen, maar waar je geen bedrijfsgegevens achterlaat? En wat te denken van een noodzakelijke website waarmee je data aanlevert voor regelgeving- of belastingdoeleinden?

Application value analysis

Application value analysis (AVA, ook bekend als de TIME-methode) is een methodiek van technologieonderzoeksorganisatie Gartner. Met deze methode wordt een score bepaald voor de IT-fitheid (zie stap 2) van een applicatie en de businessfitheid. Op basis van deze scores landt een applicatie in een van de volgende vier kwadranten:

1. tolerate – IT goed maar sluit onvoldoende aan bij de business;

2. invest – IT en business beide goed;

3. migrate – business fit goed maar IT verouderd;

4. eliminate – verouderde IT en voldoet ook niet meer aan businesseisen en -wensen.

Afhankelijk van de totale jaarlijkse onderhoudskosten wordt een applicatie groter of kleiner weergegeven in de grafiek. Het eindresultaat geeft in een beeld zowel een goed overzicht als een detailinzicht (zie figuur 1). Het bos en de bomen gevangen in één foto!

Figuur 1. Standaard 2 x 2 matrix voor AVA

Stap 2 – Data verzamelen

Aan de hand van de lijst van applicaties bepalen we vervolgens de rest van de informatie (zie tabel 1):

1. algemene gegevens over de applicatie;
2. IT-aspecten van de applicatie;
3. businesseigenschappen.

Veel informatie of eigenschappen zullen al bekend zijn. Al is dit waarschijnlijk kennis die verspreid is over verschillende specialisten.

Algemene applicatie-informatie betreft vooral zaken die nuttig zijn voor rapportage en analyse na afloop:

• Wat is de omschrijving van de applicatie?
• Welke afdeling gebruikt haar?
• Voor welk doel (businessfunctie)?
• Wie is de softwareleverancier?
• Is er een softwareonderdeel waarvan het contract binnenkort afloopt?
• Wat zijn de jaarlijkse kosten?

Vanuit een IT-perspectief kijken we naar aspecten als:

• Hoe afhankelijk zijn we van schaarse IT-specialisten?
• Hoe betrouwbaar is de leverancier?
• Hoe eenvoudig is het onderhoud?
• Hoe zit het met de beveiliging en de stabiliteit?
• Hoeveel andere applicaties zijn afhankelijk van de werking?

Vanuit een businessperspectief kijken we naar aspecten zoals:

• Hoe goed sluit de applicatie aan bij de businesswensen?
• Hoe bedrijfskritisch is de applicatie?
• Hoe kijken we naar de toekomstige inzet van de applicatie?
• Gaat de applicatie goed om met de kwaliteit van de data die ze verwerkt?

Dit zijn veel gegevens die verzameld en ingeschat moeten worden. Maar dit zijn allemaal zaken zijn die we sowieso al moeten weten om in control te zijn. Door de definities en criteria vast te leggen, kun je borgen dat potentieel subjectieve meningen (of verschillen veroorzaakt door cultuurverschillen tussen landen of bedrijfsonderdelen) toch goed meetbaar, vergelijkbaar en verifieerbaar worden.

Stap 3 – Analyseren en overzicht krijgen

Na het verzamelen van de data kan de analyse beginnen. De applicaties zullen als een zwerm vogels verspreid zijn over de grafiek. Is dit beeld herkenbaar voor onszelf en onze stakeholders? Zien we applicaties landen in de kwadranten waar we ze verwachten? Waar willen of moeten we actie op ondernemen? In de regel zullen de applicaties langs de diagonaal liggen: tussen linksonder waar de IT- en businessfit slecht is (meestal rond de 20% van alle applicaties) en rechtsboven waar zowel de business als de ontwikkelaars blij zijn (tussen de 40-60%).

Wat we soms zien, is dat een applicatie niet terechtkomt waar we deze verwachten of willen hebben. Bijvoorbeeld een applicatie op moderne technologie waar de eindgebruikers heel bij mee zijn (invest volgens het model). Dan blijken echter de kosten onacceptabel hoog (eliminate als gewenste uitkomst). De verleiding is dan groot om net zo lang aan de knoppen te draaien tot deze applicatie wel op de gewenste plaats terechtkomt. Dit is onwenselijk. Dus naast de ‘AVA-uitkomst’ hebben wij een bedrijfsstrategie toegevoegd. Dat is een manier om met goede argumenten – in uitzonderingsgevallen – af te kunnen wijken van het model.

Vanuit een architectuur- en auditperspectief zijn we vooral geïnteresseerd in de onderste helft van het kwadrant: de applicaties waar de IT verouderd is (zogenaamde ‘technical debt’) en/of waar er security- of stabiliteitszorgen zijn. Hier verwachten we een concreet plan van de betrokken business- en IT-eigenaar van het systeem (geholpen door de architect). Wat gaan we doen om deze applicatie te vervangen, upgraden of consolideren om weer volledig aan de IT- en businesswensen van vandaag en morgen te kunnen voldoen? Soms is dit een eenvoudige upgrade die enkele weken kost, maar er kunnen ook complexe programma’s van jaren voor nodig zijn. Onderlinge afhankelijkheden tussen applicaties maakt zo’n verbetering extra lastig.

Zichtbaarheid en support van senior management

Alle data worden bottom-up verzameld. Maar het is essentieel dat de belangrijkste bevindingen goed zichtbaar zijn en ondersteund worden door het senior management aan de business- en IT-kant. Dit doen we op twee manieren:

1. Als eerste beschrijven we jaarlijks een ‘(de)commisioning roadmap’ voor de komende jaren. Wat plannen we de komende jaren aan nieuwe applicaties voor de verschillende afdelingen en landen? En welke verouderde systemen gaan we wanneer uitzetten? Het is vrij eenvoudig om nieuwe applicaties aan te schaffen of te bouwen. Maar het is veel lastiger om oude systemen uit te zetten die vaak al diepgeworteld zitten in het applicatie- en datalandschap en de IT-infrastructuur. Te weinig applicaties uitzetten of het niet ‘onder architectuur’ aanzetten van nieuwe applicaties resulteert dan snel in een complexer applicatielandschap. Terwijl reductie van complexiteit bij veel organisaties juist een langdurig en belangrijk streven is.
2. We rapporteren vervolgens de ‘tech renewal priorities’, een beperkt overzicht van systemen die qua beveiliging of stabiliteit door de ondergrens (dreigen te) zakken. Die situatie willen we koste wat kost vermijden. Dus daar moet top-down aandacht, prioriteit en budget voor komen.

Zo! Daarmee is de vinger in de dijk gestopt. We hebben de belangrijkste acties op individueel applicatieniveau in gang gezet en kunnen naar achteren stappen om wat meer overzicht te krijgen over ons applicatielandschap.

Wat kan de AVA voor een architect betekenen?

Wij gebruiken deze ‘gouden’ bron aan AVA-data om vanuit alle nodige gezichtspunten naar ons applicatielandschap te kijken. Omdat we per afdeling of per land kunnen zien hoe de applicaties verdeeld zijn, kunnen we direct zien waar er relatief veel in de kwadranten eliminate of migrate zitten. Zo kunnen we kijken of daar extra investeringen of aandacht nodig zijn.

Door de bomen het bos blijven zien!

We kunnen ook heel specifiek op een aspect inzoomen. Welke applicaties zijn bijvoorbeeld erg afhankelijk van specialisten en zijn dus een potentieel key-(wo)man risk? Hoe zijn de applicatiekosten verdeeld over ons landschap? We zien in de praktijk dat dit niet een mooie normaalverdeling is (Gauss-curve). Eerder dat het een poissonverdeling is: heel veel kleine, goedkope systemen, maar ook een (gelukkig) klein aantal hele grote systemen. Dit vraagt dan om een moeilijke keuze: richten we ons op de kleine systemen die door het hoge aantal een significant beveiligingsrisico vormen? Of richten we ons op het aanpakken van grote systemen – mogelijk gevolgd door een ruimer IT-budget? Zien we een groter deel van ons applicatielandschap door de jaren heen minder toekomstbestendig worden voor de businesswensen? Neemt het aantal applicaties dat niet in lijn is met de architectuurvisie toe of af?

Ondersteuning van de bedrijfsstrategie

Doordat we alle applicaties gekoppeld hebben aan ons bedrijfsfunctiemodel kunnen we ook inzoomen op functionele deelgebieden. Staan onze product-administratiesystemen er over alle bedrijfsonderdelen heen goed voor? Zien we onze bedrijfsstrategie gefocust op excellent customer focus terug in de scores voor de systemen in de specifieke bedrijfsfuncties die gerelateerd zijn aan onze klantbediening?

De AVA is op zich al input voor een audit, juist vanwege de vele complexiteiten en aspecten ervan

Het hebben van inzicht en overzicht betekent nog niet dat de oplossingsrichting eenvoudig is. Wat doe je met een applicatie die niet meer aansluit bij businesseisen en regelgeving en waarvan de technologie grenzeloos verouderd is? Er zijn in hoofdlijnen drie oplossingsrichtingen:

• Vervang de applicatie in haar geheel met dezelfde functionele scope door een moderne applicatie (bijvoorbeeld cloud native) die gekozen is volgens de huidige businesseisen.
• Vervang de applicatie door een aantal kleinere applicaties die samen dezelfde functionaliteit bieden, maar individueel beter onderhouden en aangepast kunnen worden (kreten als ‘ontkoppelen’ en ‘microservices’ komen nu direct in gedachten).
• Vervang de applicatie samen met een aantal andere kleine applicaties juist door een grotere die beter aansluit bij industry best practices, beter het end-to-endproces ondersteunt en goedkoper kan zijn dan alle losse/ad hoc ontstane applicaties bij elkaar.

De architect als boswachter!

Voor deze strategische adviezen is de kennis, kunde en jarenlange ervaring nodig van een enterprise- of businessarchitect mét doorzettingsvermogen! De rechterbovenhoek waarbij een applicatie volledig voldoet aan de businesswensen en waarvan de technologie draait als een zonnetje heet niet voor niets invest. Ook deze applicaties hebben constant aandacht nodig door nieuwe regelgeving, nieuwe gebruikerswensen en urgente security updates. De applicaties hebben dus allemaal de neiging om weer naar linksonder af te glijden. Zodra de ene applicatie aandacht heeft gehad, moet je alweer naar de volgende rennen om die weer naar rechtsboven te tillen.

Wat kan de AVA voor de auditor betekenen?

Ook voor een auditor zijn deze applicatie-inzichten heel behulpzaam. In een oogopslag zie je voor een organisatieonderdeel (gebaseerd op informatie van subonderdelen) de belangrijkste applicaties en in welke categorie ze vallen. Dat helpt enorm voor het inzicht en als input voor accountmanagementmeetings. Er is zo gesprekstof over belangrijke ontwikkelingen, veranderrisico’s, welke applicaties op de tech-priolijst staan, et cetera. Daarnaast is de AVA op zich al input voor een audit, juist vanwege de vele complexiteiten en aspecten ervan.

Ook kun je hiermee vragen naar de plannen rondom applicaties in de eliminatie/migreerkwadranten om diepgaandere inzichten te krijgen. Deze informatie is ook interessant voor het auditplan. Zo kun je belangrijke veranderingen meenemen in de IT-portfolio van een onderdeel. Bijvoorbeeld een designaudit van een nieuwe applicatie. Ten slotte kan het inzicht natuurlijk gebruikt worden om aan te tonen wat binnen een bepaald organisatieonderdeel de (IT-)auditdekking is.

Dieper inzicht krijg je in de detaildata van de AVA. Hierin kun je per applicatie de businessfit en IT-fitscores per criterium zien. Daarvan kun je bekijken of die scores passen bij de risico’s die aan de orde komen in andere (in-control)rapporten en processen.

Uit de data kan de auditor specifieke risico’s bepalen binnen de scope van de audit, zoals slechte ondersteuning van leveranciers of lage beveiligingsscores (technical debt). Ook kun je bij een belangrijk verschil tussen de uitkomst van de AVA en de bedrijfsstrategie gerichte vragen stellen, want ook dit kan leiden tot extra risico’s.

Conclusies en aanbevelingen

We hebben nu een aantal jaren ervaring met het AVA-proces en het gaat ieder jaar beter. De data zijn ieder jaar beter, het kost steeds minder tijd om het proces uit te voeren en de zichtbaarheid en impact zijn steeds groter. Zowel business- als IT-stakeholders kennen de scores en positionering van hun systemen in de kwadranten. Zij willen dat hun investeringen bijdragen aan een effectiever en efficiënter applicatielandschap.

Wat begon als een leuke vingeroefening om wat inzicht te krijgen, is uitgegroeid tot een belangrijk stuurinstrument voor onze business en IT-afdelingen. Het geeft nieuwe medewerkers, auditors en toezichthouders ook veel inzicht. Kortom, het gebruik van AVA is goed te vergelijken met de taken van Staatsbosbeheer. Vanaf grote hoogte tussen de wolken het overzicht houden over de diverse bossen en landschappen, maar tegelijkertijd vanaf de grond zorgen dat alle individuele bomen en soorten floreren en geen bedreigingen kennen.

Met dank aan Gartner (www.gartner.com/) voor hun AVA/TIME-methode in het bijzonder en IT-research in het algemeen.