Vad består en CMDB av och är det en tillgång?

En CMDB består av en mängd Configuations Items, CIs. Det finns ett gäng definitioner av CI. Lacy & Norfolk (2010) definierar CI som alla objekt som måste hanteras för att leverera en IT-tjänst. CI är typiskt IT-tjänster, hårdvara, mjukvara, byggnad, människor och formell dokumentation som processdokumentation och tjänstenivåavtal. Information kring varje CI registreras i en konfigurationspost och underhålls sedan under hela dess livscykel av CM.

Eriksson & Öberg (2013) ger exempel på CI och nämner att det vara ett fysiskt objekt eller programvara som fyller en specifik funktion. Det kan vara en viktig säkerhetsdetalj, en färdig produkt eller en fungerande enhet. Alatalo & Vallgren (2015) menar på att ett CI kan vara allt från hårdvara till mjukvara till dokumentation. De anser att allt som kan installeras, byta ut eller ändras i en IT-miljö ska kartläggas och definieras.

ITIL (2015) anser att CI är en tillgång, komponent eller ett annat objekt som är, eller som kommer att kontrolleras av CM. Objekten kan variera brett i komplexitet, storlek och typ, som kan sträcka sig från en hel tjänst eller system inklusive all hårdvara, mjukvara, dokumentation och supportpersonal till en enda mjukvarumodell eller en mindre hårdvarukomponent. Det är möjligt att gruppera CI, för att på så vis hantera dem tillsammans. Detta kan t.ex. bli aktuellt om flera komponenter hör till samma uppsättning och kan då delas in i en release. Dock bör CI väljas utifrån fastställda urvalskriterier, grupperade, klassificerade och identifierade, på ett sätt att de blir hanterbara och spårbara under tjänstens hela livscykel.

Så hur vet du vad som ska vara en CI? Ställ dig nedanstående frågor så borde du ha en bättre uppfattning.

• Vilken information behövs för att det ska vara möjligt att registrera och underhålla varje CI?
• Varför anses denna information nödvändig att lagra?
• Vem kommer använda den lagrade informationen? Går det att lita på den data som finns lagrad eller kommer ny information behöva samlas in om det behövs?
• Hur kommer informationen användas? Är det en del av en beräkning? Stödjer det vid beslutsfattande?
• Vad är kostnaden/nyttan av att samla in och upprätthålla nivån av data?
• Hur kan uppgifterna lagras och/eller presenteras för dem som behöver informationen på ett effektivt sätt utan att negativt påverka systemanvändarna som inte behöver känns vid informationen?

Mellan alla CI finns det relationer. Relationerna ska beskriva hur CI arbetar tillsammans för att leverera en tjänst. Relationerna mellan CI är hållna på att sådant vis att de ska tillhandahålla information om beroendet som finns.

Exempel på relationer:

• Ett CI är en del av ett annat CI
• Ett CI är anslutet till ett annat CI
• Ett CI använder ett att CI
• Ett CI installeras på ett annat

Det finns ett gammalt ordspråk som säger att det går att bedöma karaktären hos en man utifrån det företag han håller. Detsamma kan sägas om en del av IT-infrastrukturen. Värdet av en CI bestäms utifrån dess interaktioner med resten av miljön och vilka roller den har. Varje CI brukar anses ha sin unika intressesfär. Inflytandet kommer sträcka sig till, och påverka, en mängd olika system och processer. Till slut kan CI ha många relationer och beroendeförhållande med andra CI inom företagsklimatet.

I nästa inlägg i denna serie kommer se över vilken nytta man kan ha av en CMDB. För mer läsning, följ denna länk.

Som IT-ansvarig på Basalt ansvarar Linn för att skapa de rätta förutsättningarna för en god IT-miljö. Hon är operativt involverad och driver IT-utvecklingen framåt samt är personalansvarig för medarbetarna vid IT-avdelningen. Linn är MCP inom Office 365 och tar externa konsultuppdrag vid behov.