Er is een herkenbaar patroon in configuratiebeheer: een team investeert enthousiast in het opzetten van een Configuration Management Database, vult 'm zorgvuldig met servers, applicaties en hun onderlinge afhankelijkheden — en negen maanden later blijkt de helft van de gegevens niet meer te kloppen. Nieuwe systemen zijn nooit toegevoegd, oude zijn nooit uitgeschreven, en niemand vertrouwt de data nog genoeg om 'm te gebruiken bij een impactanalyse.
Dit is niet omdat CMDB's een slecht idee zijn. Het is omdat de meeste implementaties één cruciaal element missen: een proces dat de CMDB automatisch of structureel actueel houdt, in plaats van te vertrouwen op goede bedoelingen.
Het probleem is zelden de eerste vulling
De initiële inventarisatie — alles in kaart brengen en invoeren — is meestal het makkelijkste deel. Teams zijn hier gemotiveerd voor, plannen er tijd voor in, en het resultaat is meetbaar en zichtbaar. Het probleem ontstaat daarna: bij elke wijziging, elke nieuwe server, elke uitgefaseerde applicatie moet de CMDB opnieuw worden bijgewerkt — en dat gebeurt zelden vanzelf.
Een CMDB is geen project met een einddatum. Het is een proces zonder einddatum.
Waarom bijwerken zo vaak wordt overgeslagen
De reden is bijna altijd praktisch: onder tijdsdruk wint het daadwerkelijk oplossen van een storing of het uitrollen van een wijziging het van het administratieve werk van het bijwerken van een database. Niemand laat een productieserver langer plat liggen om eerst de CMDB te updaten. Het gevolg is dat CMDB-updates stelselmatig worden uitgesteld — en uitstel wordt al snel vergeten.
Wat wél werkt: koppeling aan bestaand proces, niet een los ritueel
De meest duurzame oplossing is het CMDB-onderhoud niet als apart, geïsoleerd taakje te behandelen, maar te koppelen aan processen die toch al verplicht zijn — met name wijzigingsbeheer. Als een wijziging pas als "afgerond" telt zodra ook de CMDB is bijgewerkt, verdwijnt de mogelijkheid om dit stap simpelweg te vergeten.
Praktische maatregelen die het verschil maken
- Maak CMDB-registratie een verplicht onderdeel van de definition of done bij elke wijziging
- Plan periodieke, korte audits (bijvoorbeeld per kwartaal) specifiek om de CMDB te controleren tegen de werkelijkheid
- Waar mogelijk: gebruik geautomatiseerde discovery-tools die actief systemen scannen, in plaats van volledig te vertrouwen op handmatige invoer
- Wijs één eigenaar aan die verantwoordelijk is voor de algehele datakwaliteit, niet alleen voor losse invoer
- Meet en communiceer de datakwaliteit periodiek — zichtbaarheid houdt de discipline scherp
De prijs van een onbetrouwbare CMDB
Een CMDB die niet meer wordt vertrouwd, verliest zijn functie volledig — teams gaan 'm simpelweg negeren en vertrouwen weer op losse kennis in ieders hoofd, precies het probleem dat de CMDB zou moeten oplossen. Dat maakt datakwaliteit geen "nice to have", maar de bepalende factor of het hele initiatief zijn geld waard is geweest.
In het kort
- De eerste vulling van een CMDB is zelden het probleem; het structureel actueel houden wel
- Onder tijdsdruk verliest CMDB-onderhoud het bijna altijd van directe operationele taken
- Koppel CMDB-updates aan bestaande, verplichte processen zoals wijzigingsbeheer
- Een CMDB die niet meer wordt vertrouwd, wordt genegeerd — en verliest daarmee zijn waarde volledig
Een CMDB is uiteindelijk geen technisch probleem, maar een disciplineprobleem. De organisaties waar het wél lukt, zijn zelden degenen met de meest geavanceerde tooling — het zijn degenen die CMDB-onderhoud onlosmakelijk hebben verbonden aan het werk dat toch al moest gebeuren.