Applicatie Portfolio Management zonder Enterprise Architectuur: Spelen met Vuur

Posted on

Applicatie Portfolio Management zonder Enterprise Architectuur: Spelen met Vuur

Enterprise Architectuur omvat per definitie het applicatielandschap. Zo impliceert werken onder architectuur het managen van de levenscyclus van dat landschap. Althans, zolang je architectuur ziet als praktisch dagelijks gereedschap in plaats van een papieren tijger. Toch laat de realiteit veelal een ander beeld zien: de (applicatie)architectuur wordt eenmalig vastgesteld en daarna verdwijnt de documentatie in de kast. Vervolgens wordt deze eruit gehaald wanneer nodig, waarbij men concludeert dat de informatie achterhaald. Op dat moment moet er een flinke inhaalslag gepleegd worden. "Zonde, het automatisch up-to-date houden van de architectuurdocumentatie voor wat betreft het applicatielandschap zorgt namelijk voor integratie tussen het dagelijkse beheer van het applicatieportfolio, ook wel Applicatie Portfolio Management genoemd, en het operationaliseren van architectuur. Dit zorgt daarmee direct voor grip op IT", aldus Tom de Ridder, Principal Consultant bij ValueBlue. Hij stond ons te woord:

Wat is Applicatie Portfolio Management volgens jou?

"Applicatie Portfolio Management, ook wel afgekort als APM, is een raamwerk om software applicaties en services te managen. Er wordt een inventaris van applicaties bijgehouden waarbij een waarde aan de applicaties wordt toegekend op basis van factoren als de levensfase waarin de applicatie zich bevindt (lifecycle), hoe vaak de applicatie gebruikt wordt (metering), de kosten die zijn gemoeid om de applicatie in de lucht te houden (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. Deze organisatie van het applicatielandschap, wordt ook wel applicatierationalisatie genoemd."

Kun je een voorbeeld geven van applicatierationalisatie?

"Stel je een applicatierationalisatie project voor waarbij het je doelstelling is om het aantal applicaties te verlagen van 900 naar 450, om te besparen op licentie- en beheerkosten. Zo vormt je applicatierationalisatie-proces een belangrijk projectonderdeel van Applicatie Portfolio Management. Om de juiste keuzes te maken, is het van belang dat de relaties tussen applicaties, bedrijfsprocessen, informatiestromen en infrastructuurcomponenten inzichtelijk zijn. Wanneer je applicaties gewoonweg “uitschakelt” speel je met vuur, gezien er informatiestromen en dus een bedrijfsproces vanaf hangen. Ook wanneer je besluit zomaar een server uit te zetten omdat het project denkt dat er geen applicaties meer op draaien loop je een risico. Stel je voor dat juist die ene bedrijfskritische applicatie gebruik maakt van een software-component dat toch nog op die server draait… dan is de populariteitsprijs voor jouw IT afdeling ver uit het zicht. Wellicht kan de populariteitsprijs je gestolen worden, maar linksom of rechtsom, jij dient te verbouwen terwijl de verkoop of business gewoon doordraait."

Staan organisaties stil bij functionaliteiten en relaties tussen applicaties?

"Het gebeurt vaker dan je denkt, het gewoonweg “uitschakelen” van applicaties terwijl je informatiestromen en bedrijfsprocessen er van afhankelijk zijn. Veelal wordt impliciet dan wel expliciet vergeten om het landschap rondom applicaties in kaart te brengen. De meeste organisaties focussen zich vooral op het technisch werkend krijgen van een applicatie op een nieuw platform/operating systeem, in plaats van stil te staan bij de functionaliteit en relaties van de betreffende applicatie. Stel je een migratie van Windows werkplekken voor. In eerste instantie lijkt de werking van de applicatie op het nieuwe Windows Operating System het grootste belang. Toch blijkt dat je, zodra je het vanuit het perspectief van Enterprise Architectuur gaat bekijken, bijdraagt aan de kracht van de totale structuur en het functioneren van ieder component binnen de organisatie architectuur. Zodra je stilstaat bij functionaliteiten en onderlinge relaties voorkom je bovendien dat er ergens iets omvalt."

Hoe krijg je de juiste informatie boven tafel?

"Zorg ervoor dat je de inventarisatiefase bij aanvang van een migratietraject goed uitvoert, dan komt veel nuttige informatie boven tafel. Deze informatie gaat onder meer over de relaties tussen applicaties, hoe vaak deze applicaties gebruikt worden en hoeveel gebruikers deze applicaties tellen. Dit inzicht kan direct bijdragen om bijvoorbeeld de Configuration Management DataBase (CMDB) te verbeteren. Wanneer je tenslotte zorgt dat de infrastructuurcomponenten in de CMDB worden bijgehouden, kan deze gebruikt worden voor het maken van impactanalyses op changes. Dat geldt ook voor gecontroleerde implementatie van die changes."

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

"In een CMDB staan zaken als applicaties, clients, servers, netwerken, VLANs, gebruikers, groepen, locaties en printers. We noemen deze zaken “assets” of “configuration items (CI’s).” Veelal wordt er semi-statische informatie zoals naam, locatie, ID-nummer, asset tag, kostenplaats en gebruikers vastgelegd. In sommige CMDB systemen 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 en logische infrastructuurcomponenten 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.

Een architectuur repository bevat voornamelijk informatie over de omgeving van een entiteit en minder informatie over de entiteit zelf. In een CMDB staat juist informatie over de entiteiten zelf, over de assets dus. Toch is het daadwerkelijke onderscheid in kunstmatig. Grip op de IT omgeving betekent grip op entiteiten en grip op de onderlinge samenhang van deze entiteiten. De positieve verwoording luidt als volgt: de CMDB dient gekoppeld te zijn aan de architectuur repository. De minder positieve verwoording? De moraal van het verhaal? Het is onzin om twee databases te hebben!"

Is er een excuus om wel twee separate architectuur repositories te gebruiken?

"Het enige excuus dat pleit voor een separate architectuur repository is het feit dat deze ook informatie bevat omtrent niet-IT entiteiten, zoals bedrijfsprocessen en producten & diensten. Maar ja, is het onderscheid tussen “business”en “IT” niet inmiddels heel erg achterhaald? Met de nuttige informatie die je boven tafel krijgt, kan “top-down” een aanzet gegeven worden voor werken op basis van architectuur. Archimate is een modelleertaal die hier goed voor ingezet kan worden. Archimate is een modelleertechniek die in Nederland is ontstaan en die al enkele jaren aan een grote (internationale) opmars bezig is, mede door de adoptie van Archimate door The Open Group (welke ook TOGAF heeft gepopulariseerd). In Archimate kijk je op drie lagen 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 vervolgens mogelijk gemaakt door een samenspel van applicaties, applicatiecomponenten, interfaces en logische informatiestromen. En dit alles dient fysiek te “draaien” op de technologie-laag, waarbij we de infrastructuur, netwerken, servers, systeemsoftware, storage back-up, firewalls, routers en switches. beschrijven."

Welke concrete resultaten levert inzicht op?

"Zodra je bij Applicatie Portfolio Management inzicht hebt in de samenhang tussen applicaties, applicatiecomponenten en interfaces, alsmede de relaties met zowel de bedrijfsprocessen als met de infrastructuur, ga je succes boeken. Met de informatie, beschreven in een Archimate model, bepaal je het functioneren van de applicatie en het belang van de applicatie binnen het portfolio. Zo ga je bijvoorbeeld betere impactanalyses maken die nodig zijn voor het migreren van applicaties naar de Cloud. Je maakt betere beslissingen over technische implementatie-aspecten van een Service Oriented Architecture. Je gaat ketenmonitoring veel effectiever inrichten, omdat keten-afhankelijkheden van je organisatie in kaart worden gebracht. Tevens kan het aantal te beheren objecten worden teruggedrongen: indien duidelijk wordt dat applicaties overlappen qua functionaliteit, kunnen reële beslissingen worden genomen over het uitfaseren van applicaties. Dit bespaart direct op de beheerkosten."

locatie, functie en overlap
Figuur 1: visualisatie van de manier waarop bedrijfsprocessen (geel) worden ondersteund door IT middelen (blauwe applicaties, informatiestromen en applicatiefuncties en groene infra).

Hoe communiceer je het verkregen inzicht met verschillende stakeholders?

"Via visualisaties kan gemakkelijker gecommuniceerd worden met uiteenlopende stakeholders. Per doelgroep kan, met de informatie in het model, een “view” worden gemaakt 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 Applicatie Portfolio Management."

Moet de informatie over het applicatieportfolio altijd up-to-date zijn?

"Ja, ik vind van wel. Ik zie dat organisaties die informatie over het applicatieportfolio automatisch up-to-date houden en koppelen aan de architectuurmodellen veel meer ruimte hebben. Daar waar men eerst veel inspanningen verrichte om applicatie portfolio management en architectuur up-to-date te houden, kunnen architecten zich nu richten op analyse van de beschikbare informatie. Continue “data gathering” is verleden tijd. Er is meer focus voor business en technologie gedreven innovaties, ten faveure van de missie van de organisatie."

Wat is daarvoor nodig?
"Business intelligence in IT beheer, ofwel IT intelligence. Op basis van een integraal beeld van het IT 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 IT 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 migratie-projecten. Tevens is het mogelijk een “technology roadmap” te maken. Het actuele inzicht in het applicatieportfolio wordt gecombineerd met zaken als ervaringscijfers, end-of-support data, informatie over fixes, patches en security packs. Hiermee wordt de de basis gelegd voor Applicatie Rationalisatie, licentiebeheer en het beheer van onderhoudscontracten. 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 architectuur-overzicht te genereren dan wel een vergelijk te doen met (onderdelen) van een reeds bestaande architectuur."

Wat volgens jou het ultieme doel?
"Dat 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 IT een hoofdrol spelen in de verlaging van beheerkosten en de verbetering van de diensten-niveaus voor beheer. Deze grip gaat een voorwaarde zijn voor de rol van IT, 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."

Meer lezen en extra visualisaties over Applicatie Portfolio Management?

Comments are closed.