Overslaan en naar de inhoud gaan

APM zonder Enterprise Architectuur is als spelen met vuur

APM 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 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. 

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 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 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.

Automatisch up-to-date
Wat nu als informatie over het applicatieportfolio 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 basis gelegd voor applicatie rationalisatie, licentiebeheer en het beheer van onderhoudscontracten. 

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. 

Auteur: Tom de Ridder, XR-Magazine

  •  

Copyright © 2019 Mavim B.V.