Artikel

Applicatie Portfolio Management zonder Enterprise Architectuur is als spelen met vuur

Enterprise architectuur omvat per definitie het applicatielandschap. Werken onder architectuur impliceert dus ook het managen van de levenscyclus van dat landschap. Althans, als je architectuur ziet als een praktisch dagelijks gereedschap in plaats van een papieren tijger. De realiteit laat veelal een ander beeld zien: de (applicatie)architectuur wordt eenmalig vastgesteld, en vervolgens verdwijnt de documentatie in de kast. Om als het nodig is eruit te worden gehaald, waarbij de eerste conclusie is dat de informatie achterhaald is en er dan, op dat moment, een flinke inhaalslag gepleegd moet worden. Het automatisch up-to-date houden van de architectuurdocumentatie voor wat betreft het applicatielandschap zorgt voor integratie tussen het dagelijkse beheer van het applicatieportfolio en het operationaliseren van architectuur. En zorgt daarmee voor “grip op ICT”.

Een enterprise architectuur (EA) is een bouwtekening die de structuur en het functioneren van een organisatie beschrijft. De bedoeling van een EA is om te bepalen hoe een organisatie het meest effectief zijn huidige en toekomstige doelen kan bereiken. Enterprise architectuur kent veelal vier invalshoeken: business, applicatie, informatie en technologie. Het vastleggen, bijhouden, gebruiken en verbeteren van informatie over deze vier invalshoeken noemen we het werken met, of onder, enterprise architectuur.

Applicatie Portfolio Management (APM) is een raamwerk voor het managen van software applicaties en services. Er wordt een inventaris bijgehouden van applicaties waarbij een waarde aan de applicaties wordt toegekend op basis van factoren zoals de levensfase waarin de applicatie zich bevindt (lifecycle), hoe vaak de applicatie gebruikt wordt (metering), de kosten die zijn gemoeid met het in de lucht houden van de applicatie (maintenance) en de relaties die de applicatie heeft met andere applicaties (dependencies). Op basis van deze waarden kan een gerichte keuze worden gemaakt of de applicatie in stand moet worden gehouden, of moet worden uitgefaseerd of moet worden vervangen.

Een voorbeeld: applicatierationalisatie

Laten we als voorbeeld een applicatierationalisatie project nemen. Doelstelling van dit project is om het aantal applicaties te verlagen van 900 naar maximaal 450, om hiermee te besparen op licentie- en beheerkosten. Als onderdeel van applicatie portfolio management (APM) dus een zeer belangrijk project. Om de juiste keuzes te maken, is het van belang dat de relaties tussen applicaties, bedrijfsprocessen, informatiestromen en infrastructuurcomponenten inzichtelijk zijn. Het zo maar “uit” zetten van een applicatie waar een informatiestroom en dus een bedrijfsproces vanaf hangt, is als spelen met vuur. En besluiten om een server uit te zetten omdat het project denkt dat er geen applicaties meer op draaien, terwijl nou juist die ene bedrijfskritische applicatie gebruik maakt van een softwarecomponent die toch nog op die server draait… levert je als ICT afdeling niet meteen de populariteitsprijs op. Dat is wellicht ook niet het doel, maar wat boven kijf staat is dat er verbouwd moet worden terwijl de verkoop doorgaat!

Zijn de relaties in beeld?

Bovenstaande komt vaker voor dan je denkt, simpelweg omdat de relaties niet in kaart zijn gebracht, en veelal impliciet danwel expliciet wordt vergeten om dit in kaart te brengen. Er wordt gefocust op het technisch werkend krijgen van een applicatie op een nieuw platform (m.a.w. operating systeem), bijvoorbeeld bij de migratie van Windows werkplekken. En hoewel het natuurlijk van groot belang is dat de applicatie op het nieuwe Windows operating systeem werkt, dient er vooral ook stilgestaan te worden bij de functionaliteit van die applicatie en de relaties met andere applicaties in het ICT landschap, zoals bijvoorbeeld het aanroepen van een e-mail client vanuit het SAP systeem dat er voor zorgt dat facturen naar klanten kunnen worden verstuurd. Al dat soort afhankelijkheden zullen moeten worden meegenomen in het keuzeproces en in de resulterende migratieplanning, zowel vanuit technisch perspectief (“SAP moet dan ook de nieuwe e-mail client kunnen aanroepen”) als vanuit service management oogpunt (“er kunnen even geen facturen uit SAP worden gemaild”).

De juiste informatie boven tafel krijgen

Als de inventarisatiefase, bij aanvang van een dergelijk migratietraject, goed wordt uitgevoerd, komt veel nuttige informatie boven tafel. Bijvoorbeeld informatie over de relaties tussen applicaties, hoe vaak deze applicaties gebruikt worden en door hoeveel gebruikers. Deze informatie kan als input dienen voor het verbeteren van de Configuration Management DataBase (CMDB). De lifecycle van applicaties en infrastructuurcomponenten dient tenslotte (volgens goed service management gebruik, en overigens ook al jaren volgens ITIL) in de CMDB bijgehouden te worden, zodat deze gebruikt kan worden voor het maken van impactanalyses op changes. En voor gecontroleerde implementatie van die changes.

CMBD versus architectuur repository

Welke informatie gaat in de CMDB en welke in de architectuur repository?

In een CMDB staan applicaties, clients, servers, netwerken, VLANs, gebruikers, groepen, locaties, printers etc. Deze zaken noemen we “assets” of “configuration items (CIs).” Hiervan wordt over het algemeen semi-statische informatie vastgelegd zoals naam, locatie, ID-nummer, asset tag, kostenplaats, gebruikers etc. In sommige CMDBs is ook de relatie van een asset met andere assets vastgelegd, zoals een applicatie die op een server draait.

In een architectuur repository zijn entiteiten als applicaties, processen, functies, actoren, bedrijfsonderdelen, applicatiecomponenten, interfaces, logische infrastructuurcomponenten etc. te vinden. Deze entiteiten zijn vaak tot op zekere hoogte terug te leiden naar de assets in een CMDB. De repository bevat informatie over de aard van een entiteit, uit welke andere entiteiten deze is opgebouwd, welke relaties er zijn met andere entiteiten en wat de aard is van die relaties.

In een architectuur repository staat veelal informatie over de omgeving van een entiteit en minder over de entiteit zelf. En in een CMDB staat veelal juist informatie over de entiteiten zelf, over de assets dus. Maar in feite is het onderscheid kunstmatig! Grip op de ICT omgeving betekent grip op entiteiten en grip op hun samenhang! En dus dient, populair gezegd, de CMDB gekoppeld te zijn aan de architectuur repository. Of, minder populair gezegd maar wel beter: het is onzin om twee databases te hebben!

Het enige argument wat nog zou pleiten voor een separate architectuur repository is het feit dat deze ook informatie bevat omtrent niet-ICT entiteiten, zoals bedrijfsprocessen en producten & diensten. Maar ja, is het onderscheid tussen “business”en “ICT” niet inmiddels heel erg achterhaald?

Met de informatie die op deze manier, als onderdeel van een applicatierationalisatie project, verzameld wordt, kan “van onderen af” een aanzet gegeven worden voor werken op basis van architectuur. Een hiervoor geschikte modelleertaal is Archimate, een modelleertechniek die in Nederland is ontstaan en die al enkele jaren aan een (internationale) opmars bezig is, mede door de adoptie van Archimate door The Open Group (welke ook TOGAF heeft gepopulariseerd). In Archimate kan op drie lagen gekeken worden naar een organisatie. De bovenste laag is de bedrijfslaag, waarin het draait om de manier waarop de strategie van een organisatie vertaald is in structuren, producten & diensten en bedrijfsprocessen. Deze processen worden mogelijk gemaakt door een samenspel van applicaties, applicatiecomponenten, interfaces en logische informatiestromen. En dit alles dient fysiek te “draaien” op de technologielaag, waarbij we de infrastructuur, bestaande uit netwerken, servers, systeemsoftware, storage back-up, firewalls, routers, switches etc. beschrijven.

Inzicht in samenhang

Vanuit APM is inzicht vereist in de samenhang tussen applicaties, applicatiecomponenten en interfaces, alsmede de relaties met zowel de bedrijfsprocessen als met de infrastructuur. Met deze informatie, beschreven in een Archimate model, kan het functioneren van de applicatie en het belang van de applicatie binnen het portfolio worden bepaald. Zo kunnen bijvoorbeeld impactanalyses die nodig zijn voor het migreren van applicaties naar de cloud beter gedaan worden. Of kunnen betere beslissingen over technische implementatieaspecten van een Service Oriented Architecture worden genomen. Ook kunnen ketenafhankelijkheden van een organisatie in kaart gebracht worden, waarmee het inrichten van ketenmonitoring veel effectiever kan worden gedaan. Tevens kan het aantal te beheren objecten worden teruggedrongen: indien duidelijk wordt dat applicaties qua functionaliteit overlap hebben, kunnen reële beslissingen worden genomen over het uitfaseren van applicaties. Dit bespaart direct op de beheerkosten.

Visualiseren

Via visualisaties zoals weergegeven in figuur 1 kan gemakkelijker gecommuniceerd worden met een breed scala aan stakeholders. Per doelgroep kan met de informatie in het model een “view” gemaakt worden die alleen die informatie bevat die relevant is voor de doelgroep. Dit maakt het nemen van beslissingen alsook het uitleggen van aankomende veranderingen een stuk eenvoudiger. Beslissingen worden genomen op basis van actuele informatie in plaats van op gevoel en op basis van foutieve veronderstellingen, zoals nu vaak het geval is voor APM.

Figuur 1: Archimate model

Automatisch up-to-date

Wat nu als informatie over het applica-tieportfolio automatisch up-to-date zou worden gehouden, en gekoppeld zou zijn aan de architectuurmodellen? Dan zou een aanzienlijk deel van de inspanning die nu nodig is om applicatie portfolio management te doen, en een aanzienlijk deel van de inspanning die nodig is om de architectuur up-to-date te houden, kunnen worden verminderd. Architecten kunnen zich richten op analyse van de beschikbare informatie, in plaats van op “data gathering”. En op business en/of technologie gedreven innovaties, ten faveure van de missie van de organisatie.

Wat nodig is, is “business intelligence in ICT beheer”, oftewel “ICT intelligence”. Op basis van een integraal beeld van het ICT landschap zoals het werkelijk bestaat, heeft een ieder die daar behoefte aan heeft c.q. toe geautoriseerd is inzicht in ICT componenten en de relaties daartussen. Informatie over beheerde objecten en de relaties hiertussen wordt uit verschillende databronnen gehaald, en verzameld in de “ICT intelligence” omgeving. Relaties tussen objecten worden geanalyseerd. Ontbrekende relaties worden voorgesteld op basis van data mining. Deze informatie kan gebruikt worden voor incident management, problem management, change management, configuration management maar ook voor transitie- en migratieprojecten. Tevens is het mogelijk een “technology roadmap” te maken. Het actuele inzicht in het applicatieportfolio wordt gecombineerd met ervaringcijfers, end-of-support data, informatie over fixes, patches, security packs, etc. Hiermee wordt de de basis gelegd voor applicatie rationalisatie, licentiebeheer en het beheer van onderhoudscontracten. En als klap op de vuurpijl wordt de verzamelde en verrijkte informatie omgezet in het Archimate format waardoor automatisch (onderdelen van) architectuurmodellen worden gegenereerd. Dit scheelt invoertijd en geeft de mogelijkheid om op ieder ogenblik een actueel architectuuroverzicht te genereren danwel een vergelijk te doen met (onderdelen) van een reeds bestaande architectuur.

Het ultieme doel

Het ultieme doel is om “op ieder moment” inzicht te hebben in de actuele situatie van de te beheren objecten (bedrijfsprocessen, afdelingen, producten/diensten, services, applicaties, infrastructuur). In de komende jaren gaat deze “grip op ICT” een hoofdrol spelen in de verlaging van beheerkosten en de verbetering van de dienstenniveaus voor beheer. Deze grip gaat een voorwaarde zijn voor de rol van ICT, waarbij de constante paradox tussen flexibiliteit en standaardisatie gemanaged dient te worden. Inzicht in het applicatieportfolio en werken onder architectuur zijn noodzakelijk om deze slag te maken.

Categorie:   
Auteur(s)
afbeelding van tomderidder
Tom de Ridder
ValueBlue - Principal Consultant

Tom de Ridder is principal consultant bij ValueBlue. Hij kan bereikt worden op tom.de.ridder@valueblue.nl.

Nieuwe reactie inzenden

De inhoud van dit veld is privé en zal niet openbaar worden gemaakt.
Indien het niet lukt om een reactie te plaatsen, stuur dan uw reactie naar redactie@xr-magazine.nl.
Alle inzendingen dienen correct, professioneel en beschaafd te zijn. IP-adressen worden gelogd, maar niet gepubliceerd. De redactie van XR Magazine behoudt zich het recht voor om anonieme reacties (niet op naam) of zonder geldig e-mailadres, te verwijderen zonder kennisgeving. Ook reacties waarin commerciële uitingen worden gedaan en/of commerciële producten en diensten worden aangeboden worden door de redactie verwijderd of ontdaan van commerciële uitingen zonder kennisgeving.