CMDB implementation approach - best practice

[Suggy]

One of my architect says, as part of CMDB implementation project, 1st step to populate only those CI's which are part of your business applications. Finish populating CIs comprising of all your Services

As a second step, populate all other CI's.

What are your thoughts or views on this? How are you doing your CMDB implementations.

[dpacheco]

The answer, as all good answers are, is: "It depends".

What are the purposes of your CMDB?  Why are you implementing a CMDB in this first place? Is it to allow for users to create incidents and change requests against servers and understand their impact?  Or is it to perform an inventory of network gear for financial reporting?  Or do you want to document responsibility and ownership against the services provided to the end users to enable demand and request management against those services?  Will you have a clear, well-defined process to associate servers and infrastructure components to the Business Application CIs?  Will you be able to see where data is missing, where you have orphaned objects, and will you have a process to address that orphan data?  What is the priority?

Generally speaking, I don't like doing a CMDB in a CI class-centric approach. For one, a "good" CMDB is more useful when it shows relationships between CIs than data about the CIs themselves.  The question to ask is really "What am I planning to use the CMDB for?", and the answer to where you should start, should flow from that.

I would reach very different conclusions on where to start if my primary motivation for implementing a CMDB is to conduct financial asset inventory on my servers, versus if it's to perform application portfolio analysis to find duplication and gaps in my business capabilities, versus if I'm trying to understand the ownership of my capability portfolio.  There are multiple use cases and associated business requirements, and each present a different set of priorities on where to start, especially when you matrix them against how much time, money and resources you have to throw at them.

Once you answer the question of what you are planning to use the CMDB for, and you understand how much time and resources you can apply, there will be some CI classes (and more importantly, relationships) that become more clearly foundational to accomplishing that use case. Could be servers, could be services, could be business applications, could be databases.

It depends.

[Kostya]

Agree @dpacheco 

Consider current CSDM framework on the early stage so your CMDB fits in the service and application models later.

Establish a good governance model around your platform and especially CMDB incl. service owners, application owners, platform and cmdb architects.

As part of the previous, communicate the value of the CMDB for each stakeholder and user of the platform (what are the benefits for financial, security, shopfloor guys folks etc).

A CMDB (and discovery) implementation is less technical and more an organisational initiative. So find a buy-in of upper management, who should support your implementation on early stage.

Beside of this, please taker a look on various best practice articles and white papers of ServiceNow and partners, e.g. Configuration Management, CMDB for dummies, CMDB design guide and the community posts.

Good luck, @Suggy .

[Lowell Coleman]

CMDB for dummies, CMDB design guide These two links are the same.

[Rahul Priyadars]

CMDB has >800 Classes with many attributes. Why we do not have data for all Classes in Our environment or we do not need those data.

What data should go in CMDB classes - Purely Depends on Your Use cases you want to Address from CMDB data example 

Drive Your Patching of servers from CMDB data

Change Management Impact Analysis from CMDB

Billing Metering from CMDB etc etc 

So if you have list of use cases or Problem statement which CMDB data will address then you will be in a Good Position to identify what to Populate and why.

Regards

RP