De CMDB liegt in de dagelijkse praktijk
In veel IT-organisaties krijg je een CMDB voorgeschoteld als de drager van vertrouwen. Je ziet een groen dashboard en het management knikt alsof alles klopt. Maar wie heeft echt zicht op wat er in de praktijk draait, welke assets echt in gebruik zijn en welke verbindingen er nu werkelijk bestaan? De werkelijkheid is vaak anders dan het plaatje dat de CMDB geeft. Een flinke stapel shadow IT, verouderde data, en eigenaarschap dat van het een naar het ander slingert zonder dat iemand echt de verantwoordelijkheid neemt. De CMDB fungeert dan als een verzegelde doos waarin alle data zou moeten kloppen, terwijl de inhoud eigenlijk continu aan modewisselingen onderhevig is.
De centrale aantrekkingskracht van de CMDB is logisch. Je wilt governance, controle en een auditbaar spoor. Je wilt kunnen aangeven welke asset bij welke service hoort, welke changes impact hebben op de infrastructuur en waar je risico s lopen. In theorie biedt een CMDB een soelaas waar compliance en security graag op terugvallen. In praktijk werkt het anders: gegevens komen uit verschillende bronnen, zijn vaak verouderd en worden bewerkt door mensen die niet de eigenaar zijn van de data. Het resultaat is geen waarheid, maar een tijdelijke samenstelling die na een paar dagen alweer achterhaald is.
Waarom die aanname logisch of aantrekkelijk lijkt
Bedrijven willen een gereedschapskist die structuur biedt zonder elke dag weer een welkome chaos te hoeven toelichten. Een CMDB die alle onderdelen van IT, inclusief leveranciers, omgevingen en configuraties, samenbrengt klinkt als de oplossing voor complexiteit. Het imago van een gecentraliseerde waarheid roept vertrouwen op bij bestuur, auditors en security teams. Bovendien past het bij volwassenheidsmodellen: als je geen centraal register hebt, voel je je als organisatie minder controleswaardig. Het idee dat data de ruggengraat van besluitvorming vormt, is aantrekkelijk. En dan wordt de CMDB vaak ingezet alsof het de allesomvattende bron is die alle bedrijfsrisico’s kan wegnemen.
De praktijk laat vervolgens zien dat ook dit werken volgens een plan is. Het doel is nobel, maar de uitvoering zorgt voor een gespannen relatie tussen wat je registreert en wat je daadwerkelijk beheert. De data zijn zelden compleet, veel informatie ontbreekt of is niet up-to-date. Toegegeven, discovery tools doen hun best, maar shadow IT blijft bestaan en verhelpt geen hiaten in eigenaarschap. Als een asset eenmaal is aangemaakt in de CMDB, betekent dat niet dat iemand er nog steeds naar kijkt of er wijzigingen naar doorgevoerd worden. De CMDB wordt zo snel een snapshot van een momentopname in plaats van een levende, juiste kaart van de IT-realiteit.
Botsingen tussen beleid en werkvloer
De theorie predikt een clean, volledig en actueel beeld. De praktijk vertelt een heel ander verhaal. Change management vult de CMDB nauwelijks; incidenten worden opgelost zonder oorzaak structureel weg te nemen, omdat de data in de CMDB simpelweg niet consistent zijn. Leveranciers leveren bestanddelen aan die nooit door de beheerorganisatie zijn gevalideerd. Servers verdwijnen of verschijnen, zonder dat de CMDB dit bijhoudt. Data governance blijft hangen in een apart beleidsschriftje, terwijl operationele teams dagelijks beslissen op basis van wat ze zien in monitoring, logs en telemetry die geen directe link heeft met wat er in de CMDB staat. De CMDB wordt zo een zelden geraadpleegd referentiepunt, waarmee governance als een separate, technisch verlammende activiteit overleeft in plaats van een werkend onderdeel van dag-tot-dag besluiten.
De kloof is nooit slechts technisch; het gaat om eigenaarschap, budget, prioritering en cultuur. Governance lijkt vaak een stoer abstract concept op een slide, maar in de praktijk betekent het dat iemand expliciet eigenaar moet zijn van datakwaliteit en van de processen die wijzigingen in de CMDB reflecteren. Zonder die owners en zonder duidelijke budgetten voor onderhoud blijft de CMDB een instrument dat wel mooi oogt maar weinig bijdraagt aan sneller, veiliger en goedkoper beheer.
Waarom het probleem blijft bestaan
Het blijft bestaan omdat organisaties te vaak denken dat een CMDB het probleem oplost zonder dat er iets fundamenteels verandert in hoe data worden beheerd en gebruikt. Er zijn twee kernproblematiek die elkaar versterken. Enerzijds ontbreekt het aan duidelijke eigenaarschap: wie heeft er werkelijk de verantwoordelijkheid voor de data en voor het bijhouden ervan, en hoe wordt dit gemonitord? Anderzijds is er een mismatch tussen korte termijn operationele druk en lange termijn data-kwaliteit. Beleidsdocumenten worden aangehaald als bewijs van controle, terwijl in de praktijk snelle incidenten en zijwegen rondom vendor- en assetmanagement de prioriteit krijgen. Data worden bijgehouden in verschillende systemen, met conflicterende definities en weinig tot geen reconciliatie. De CMDB blijft een kunstmatig samenhangend geheel in plaats van een realistische kaart die elke dag actualiteit weerspiegelt.
Het resultaat is een gevaarlijke tolerantie: managers accepteren de afwijkingen omdat de kosten en moeite van real-time correcties te hoog lijken. En toch gebeurt er iedere dag iets in de IT-omgeving: een server wordt vervangen, een SaaS-dienst wordt aangepast, een leverancier wijzigt een licentie. Als die veranderingen niet synchroon met de CMDB lopen, ontstaat er een mismatch die security en operationele stabiliteit schaadt. In de praktijk betekent dit dat een incident vaak wordt opgelost op basis van wat iedereen nog weet of denkt te weten, en niet op basis van een betrouwbare dataverzameling. De oorzaak van problemen blijft onopgelost omdat de data waar het om draait niet betrouwbaar genoeg is om tot blijvende oplossingen te leiden.
De concrete gevolgen
Het dagelijkse risico dat organisaties lopen, is groter dan het lijkt. Security- en complianceactiviteiten worstelen met incomplete asset-informatie, waardoor kwetsbaarheden minder snel worden opgespoord en aangepakt. Patchmanagement raakt achterop wanneer de CMDB niet de realistische inventory weerspiegelt. Kosten lopen op doordat licenties en contracten dubbel lijken te bestaan: de CMDB suggereert dat alles netjes is geregistreerd, terwijl in reality assets zonder eigenaar blijven rondslingeren en extra kosten veroorzaken. De complexiteit groeit doordat men door inconsistenties meerdere data-stromen moet afwegen voordat een besluit kan worden genomen. Uiteindelijk raken mensen in de organisatie het vertrouwen kwijt in een instrument dat bedoeld is om orde te brengen, maar dat zelf voor orde zorgt in de chaos die dagelijks operationeel heerst.
De nuance
Het wel mogelijk, ja zelfs wenselijk, maken van een CMDB vraagt om een gerichte nuance. Een CMDB kan waardevol zijn als het dient als referentiekader voor kritische assets en als de basis voor governance, maar alleen als datakwaliteit en ownership expliciet worden geborgd. Dat betekent echte data-eigenaren die de kwaliteit van de data controleren en die veranderingen weten door te voeren. Het betekent dat de CMDB verbonden is met echte levenscyclussen van assets en services, waarbij wijzigingen altijd terugkoppelen naar de bron van waarheid en niet naar een handmatig aangemaakte tabel. Het betekent ook dat we afstand nemen van de illusie van een perfecte, eenmalige opzet en kiezen voor een iteratieve aanpak met duidelijke metrics voor datakwaliteit en real-time integraties met discovery, monitoring en change management. De CMDB wordt geen vervanger voor goed data management, maar een onderdeel van een samenhangend systeem waarin ownership, processen en technologie elkaar versterken in plaats van tegenwerken.
Wat organisaties daadwerkelijk anders moeten doen
Begin met duidelijk wie eigenaar is van welke data. Leg vast hoe die data worden verzameld, bijgehouden en gevalideerd. Stel minimale, noodzakelijke velden vast die de werkelijke operationele needs dekken en zet een proces in waarmee elke wijziging in de praktijk ook in de CMDB wordt doorgevoerd. Link de CMDB aan echte change- en incidentprocessen zodat data altijd doorlopend worden aangepast op basis van wat gebeurt in productie. Investeer in data governance, niet in een groter dashboardsanitair; quality moet meetbaar zijn, met concrete regels en periodieke reconciliaties. Laat leveranciers expliciet meedelen welke data zij leveren en hoe die data in de CMDB passen. En vergeet niet dat shadow IT niet weg te krijgen is door te blijven negeren; erken het bestaan en maak het deel van de realiteit die de CMDB moet ondersteunen, niet ernaast staan.
Het is geen glamoureuze verandering, maar wel noodzakelijk. Een CMDB die leeft, gekoppeld aan echte processen, eigenaren en real-time data, is geen garantie tegen fouten maar wel een garantie dat je niet langer wordt verplaatst door illusionaire waarheid. Het draait uiteindelijk om het durven toegeven dat de werkelijkheid nooit volledig in een bestand kan worden gevangen en dat governance altijd gaat over wat we wíllen controleren en wat we daadwerkelijk kunnen controleren, met welke middelen en tegen welke kosten.
De echte IT-realiteit
De CMDB liegt niet per se; de praktijk liegt eraan dat we te snel geloven dat data gelijkstaan aan werkelijkheid. De kern ligt in eigenaarschap en in het respecteren van data als een continu proces, niet als een afgewerkt product. De realiteit is dat een CMDB zelden de enige waarheid biedt, maar altijd een stuk van de waarheid. Organisaties die dit erkennen, investeren in datakwaliteit, eigenaarschap en nauwere koppelingen tussen change management, asset lifecycle en security. Pas dan ontstaat er een systeem waarin beslissingen sneller en slimmer kunnen worden genomen, zonder dat we elke dag opnieuw een nieuwe mythe over wat er in de data staat moeten lezen. De echte IT-realiteit is niet zwart-wit maar dynamisch, en dat vereist een houding die naar de praktijk luistert in plaats van naar een idealistische kaart die nooit volledig de werkelijkheid raakt. De eindige conclusie blijft: de CMDB is een hulpmiddel, geen verzekering tegen miskopen en misverstanden. De echte IT-realiteit vraagt om scherpe keuzes, durf en een cultuur die data serieus neemt als middel tot betere besluiten, niet als einddoel op zich.