CMDB klein beginnen: een configuratiedatabase die wel bijgehouden wordt

Veel CMDB-projecten beginnen groot: alles wat ooit een asset kan zijn wordt vastgelegd, in een uitgebreid datamodel met tientallen velden en relaties. Een paar maanden later klopt de data niet meer, want niemand houdt het bij. De volgende storing wordt dus toch weer uitgezocht via mensen bellen in plaats van via de CMDB kijken. Dit artikel laat zien hoe je een CMDB opbouwt die klein begint, gericht is op wat je echt nodig hebt bij impactanalyse en storingen, en daardoor wél actueel blijft.

Waarom grote CMDB-projecten vastlopen

Een CMDB die alles wil vastleggen, wordt een project zonder einde. Elk nieuw type configuratie-item vraagt een nieuw veld, een nieuwe relatie, een nieuwe afspraak over wie het bijwerkt. Tegen de tijd dat het model compleet is, is de eerste data er alweer verouderd. En omdat niemand het onderhoud als zijn taak ziet, verzandt de CMDB in een momentopname die snel achterhaald raakt.

Het probleem zit niet in de ambitie, maar in de volgorde. Een compleet model optuigen voordat er iets werkt, betekent dat je pas laat merkt of het bijhouden praktisch haalbaar is. Beter is andersom beginnen: klein, werkend, en van daaruit groeien.

Begin met wat je echt nodig hebt

Kies configuratie-items die impact hebben

Niet elk apparaat of elke applicatie hoeft in de CMDB. Begin met de items waarvan je bij een storing wilt weten wat erdoor geraakt wordt: kritieke applicaties, de servers waarop ze draaien, en de belangrijkste koppelingen ertussen. Die informatie gebruik je direct bij impactanalyse, en dat is meteen de reden waarom mensen de CMDB gaan raadplegen.

Leg alleen relaties vast die je gebruikt

Een CMDB met honderden mogelijke relatietypen wordt nooit compleet ingevuld. Beperk je tot de relaties die je daadwerkelijk nodig hebt bij het beantwoorden van de vraag "wat gaat er mis als dit uitvalt?". Dat is meestal een handvol relatietypen, niet tientallen. Het draaiboek voor major incidents maakt duidelijk welke CI-informatie je tijdens een grote storing echt opvraagt, en dat is precies waar je je CMDB op afstemt.

Automatiseer het vullen waar het kan

Handmatige invoer is de grootste bedreiging voor een actuele CMDB. Mensen vergeten het bij te werken, vooral onder tijdsdruk. Waar mogelijk haal je gegevens automatisch op uit systemen die de waarheid al kennen: een discovery-tool, een monitoringsysteem, of een lijst uit de cloudomgeving. Handmatig werk reserveer je voor de informatie die nergens anders vandaan komt, zoals de eigenaar van een applicatie of de businessprioriteit.

In stappen naar een CMDB die blijft kloppen

Een CMDB opbouwen die standhoudt, gaat het best in een vaste volgorde:

1. Bepaal het doel. Wil je sneller impact inschatten bij storingen, of ook wijzigingen beter kunnen beoordelen? Het doel bepaalt welke items en relaties er echt toe doen. Hoe wijzigingsbeheer zonder bureaucratie werkt en welke informatie je daarvoor nodig hebt, geeft richting aan de scope van je CMDB.
2. Kies een beperkte scope. Start met de kritieke applicaties en de infrastructuur eronder, niet met elk kabeltje in het pand.
3. Automatiseer waar mogelijk. Laat discovery en monitoring het grootste deel van de data leveren, zodat mensen alleen aanvullen wat niet automatisch te achterhalen is.
4. Wijs eigenaarschap toe. Elk type configuratie-item heeft iemand nodig die verantwoordelijk is voor de juistheid ervan.
5. Breid pas uit als de basis klopt. Voeg nieuwe items pas toe als je zeker weet dat de huidige scope actueel blijft.

Wat het oplevert

Een kleine, actuele CMDB is bruikbaarder dan een grote die niemand vertrouwt. Bij een storing zie je meteen welke systemen en gebruikers geraakt worden, zonder eerst rond te bellen. Bij een wijziging weet je vooraf wat de impact is, in plaats van dat achteraf te ontdekken. Dat is precies waar het om gaat: meer bereiken met dezelfde mensen, omdat de informatie klopt op het moment dat je hem nodig hebt. Wil je eerst weten hoe volwassen je configuratiebeheer al is? Een ITSM maturity assessment brengt dat in kaart. En voor begeleiding bij de opzet: bekijk onze diensten voor servicemanagement.

Veelgestelde vragen

Hoeveel configuratie-items moeten we vastleggen om te beginnen? Begin met de items achter je kritieke applicaties, vaak niet meer dan enkele tientallen. Liever klein en actueel dan groot en verouderd.

Kunnen we een bestaande, onvolledige CMDB opnieuw gebruiken? Vaak wel. Kijk welk deel van de data nog klopt, gebruik dat als basis en bouw daaromheen verder met een beperkte scope.

Is automatisering verplicht om te starten? Nee, maar het helpt enorm. Zonder automatisering ligt het onderhoud volledig bij mensen, en dat is precies waar CMDB's vaak op vastlopen.

Wil je een CMDB die niet in een la verdwijnt maar echt gebruikt wordt bij storingen en wijzigingen? plan een gesprek en we bepalen samen welke scope voor jouw organisatie het snelste resultaat geeft.

Verder lezen

• Configuration management database (Wikipedia)
• ITIL (Wikipedia)