CMDB vs. Application Portfolio Management: wat is het verschil?

Veel organisaties steken jaren werk in hun Configuration Management Database (CMDB). Maar zodra een enterprise architect, application portfolio manager of CIO een strategische vraag stelt over het softwarelandschap, blijkt het antwoord verrassend lastig te vinden. Vragen als deze:

Een CMDB alleen beantwoordt ze zelden. Dat roept een belangrijke vraag op:

Als we al een CMDB hebben, hebben we dan nog Application Portfolio Management (APM) nodig?

Het korte antwoord is ja. Een CMDB en APM hebben verschillende, maar elkaar aanvullende doelen. Wie het verschil begrijpt, kan de governance verbeteren, complexiteit verminderen en goed onderbouwde beslissingen nemen over het softwareportfolio.

Wat is een CMDB?

Een Configuration Management Database (CMDB) is het centrale register van je IT-assets, de zogenoemde configuratie-items, en de relaties daartussen: applicaties, servers, databases, infrastructuurcomponenten en bedrijfsservices.

Het doel is operationeel. Een CMDB helpt IT-teams te zien wat er bestaat, hoe systemen met elkaar verbonden zijn, wat een wijziging kan raken en hoe incidenten samenhangen met configuratie-items. Voor IT-beheer, servicemanagement en changemanagement is dat enorm waardevol.

Waar een CMDB niet voor ontworpen is: strategische portfoliovragen beantwoorden.

Wat is Application Portfolio Management (APM)?

Application Portfolio Management (APM), in het Nederlands ook wel applicatieportfoliomanagement, beheert applicaties als bedrijfsmiddelen in plaats van als technische configuratie-items. Het stelt andere vragen:

• Waarom hebben we deze applicatie, en welke business capability ondersteunt ze?
• Doen andere applicaties al hetzelfde?
• Wat kost ze, en welke risico’s brengt ze mee?
• Moeten we haar behouden, vervangen, consolideren of uitfaseren?

Het doel van APM is geen nettere inventaris. Het doel is betere portfoliobeslissingen: minder wildgroei aan applicaties, minder overbodige tools, applicaties die aansluiten op de bedrijfsstrategie, sterkere technologiegovernance en een duidelijk pad voor modernisering.

CMDB vs. APM: de belangrijkste verschillen

Naast elkaar gezet is het verschil het duidelijkst:

In één zin: een CMDB vertelt je dat een applicatie bestaat, APM vertelt je of die applicatie nog een plek in je portfolio verdient.

Vier gaten die een CMDB openlaat

Veel organisaties ontdekken dat hun CMDB honderden of zelfs duizenden applicatierecords bevat. Maar zodra ze beginnen aan een Application Rationalization-traject, duiken steeds dezelfde vier gaten op.

1. Zakelijke context ontbreekt

Een CMDB kent de naam en de eigenaar van een applicatie. Zelden kent ze de business capabilities, de functionele overlap met andere tools, het strategisch belang, de tevredenheid van gebruikers of hoe goed de applicatie in het portfolio past. Zonder die context worden portfoliobeslissingen giswerk.

2. Dubbele applicaties blijven verborgen

Stel dat je organisatie al deze tools gebruikt:

Elke tool kan keurig geregistreerd staan in de CMDB. Wat de CMDB je niet vertelt, is dat alle vier dezelfde projectmanagement-capability ondersteunen. De dubbele investering in licenties, contracten en support blijft zo onopgemerkt.

3. Beperkt zicht op de cloud

Wie werkt aan cloudtransformatie, begint meestal met dezelfde vraag: hoeveel van ons softwarelandschap draait in de cloud, en hoeveel nog on-premise? Sommige CMDB’s bevatten hostinginformatie, maar weinig bieden het portfoliobrede inzicht en de rapportages die strategische planning nodig heeft.

4. Geen zicht op digitale soevereiniteit

Digitale soevereiniteit wordt steeds belangrijker, zeker voor Europese organisaties. Hoe afhankelijk zijn we van niet-Europese leveranciers? Hoeveel van ons portfolio is in handen van Amerikaanse aanbieders? Welke applicaties passen bij onze soevereiniteitsdoelen? Met alleen CMDB-data zijn die vragen meestal niet te beantwoorden.

Waarom CMDB en APM samen het beste werken

CMDB en APM zijn geen concurrerende benaderingen. De CMDB levert de basisinventaris. Application Portfolio Management bouwt daarop voort met zakelijke context, portfolioanalyses, inzichten voor rationalisatie, analyse van de cloudstrategie, leveranciersinformatie en beoordelingen van digitale soevereiniteit.

De rol van dataverrijking

Een van de grootste uitdagingen in Application Portfolio Management is datakwaliteit. Applicatierecords zijn vaak onvolledig, verouderd of inconsistent, en de gaten met de hand vullen kan maanden duren.

Precies daar wordt verrijking waardevol. Door bestaande CMDB-records aan te vullen met externe marktinformatie krijgt elke applicatie:

• haar softwarecategorie en de business capabilities die ze ondersteunt
• haar deploymentmodel: cloud of on-premise
• leveranciersinformatie, inclusief de herkomst van de leverancier
• technologietrends en kansen voor rationalisatie

Het resultaat is een veel bruikbaarder en strategischer beeld van het applicatieportfolio.

Verder dan inventaris: wat moderne APM-teams vragen

De meest succesvolle teams voor enterprise architectuur en portfoliomanagement gaan verder dan het bijhouden van statische inventarissen. Ze richten zich op inzichten die besluitvorming ondersteunen, zoals:

• Welke applicaties kunnen we consolideren?
• Welke applicaties ondersteunen dezelfde business capability?
• Welke leveranciers vormen een strategisch risico?
• Hoe soeverein is ons applicatielandschap?
• Hoeveel van het portfolio draait nog on-premise?

Om die vragen te beantwoorden is meer nodig dan een inventaris. Daar is intelligentie voor nodig.

De belangrijkste inzichten

Veelgestelde vragen