Begin je CMDB eens niet bij de CMDB

Als we een CMDB gaan inrichten of verbeteren, beginnen we vaak direct met wat erin moet komen.

· Welke CI-classes hebben we?

· Welke attributen willen we vastleggen?

· Welke relaties hebben we nodig?

· Wat kan Discovery voor ons vinden?

Dat zijn uiteraard vragen die moeten worden beantwoord. Maar is het echt handig om daarmee te starten?

Want waarom willen we die informatie eigenlijk vastleggen?

Een CMDB neerzetten om een CMDB te hebben is een slechte reden. Waarom zou je zoveel tijd steken in het vastleggen en onderhouden van informatie als je niet weet of die informatie wel nodig is? Zeker in een tijd waarin een overvloed aan informatie vaak een groter probleem is dan een tekort eraan, lijkt het verstandig om eerst naar nut en noodzaak te kijken.

De CMDB moet de organisatie antwoorden geven. Maar op welke vragen?

· Een incidentmanager wil weten welke gebruikers en services geraakt zijn bij uitval van een systeem.

· Een change manager wil kunnen bepalen wat de impact van een wijziging is.

· Security wil weten welke kwetsbare componenten onderdeel zijn van een kritieke service.

· Een service owner wil weten waar zijn service van afhankelijk is.

· Finance kijkt weer naar assets, kosten en contracten.

· En een beheerder wil simpelweg weten: voor welke systemen ben ik eigenlijk verantwoordelijk?

Dat zijn heel verschillende vragen.

En ze bepalen uiteindelijk welke informatie je nodig hebt.

Misschien moet je daarom niet beginnen met wat je in je CMDB kunt registreren.

Begin met de vragen die je organisatie ermee moet kunnen beantwoorden.

· Wie stelt die vraag?

· Welke beslissing wordt ermee genomen?

· Welke informatie is daarvoor nodig?

· Hoe betrouwbaar moet die informatie zijn?

· En wie is ervoor verantwoordelijk dat die informatie ook betrouwbaar blijft?

Pas daarna wordt het interessant om te bepalen welke CI's, attributen en relaties daarvoor nodig zijn.

Dat klinkt misschien als een klein verschil, maar het verandert de CMDB van een database die we zo compleet mogelijk proberen te vullen in een informatievoorziening met een doel.

En het helpt ook bij een vraag waar veel organisaties mee worstelen:

Wat moeten we eigenlijk allemaal in onze CMDB vastleggen?

Misschien is het antwoord wel: Niet alles wat je kunt vinden.

Maar precies genoeg om de vragen te kunnen beantwoorden waarvoor je de CMDB nodig hebt.

Dan wordt ook de vraag of je CMDB goed is een stuk interessanter.

Niet: Hoeveel CI's hebben we geregistreerd?

Maar: Kunnen we erop vertrouwen als we er een belangrijke vraag aan stellen?