Who Should Own the CMDB?

[gmcgee]

Hi All,
I have recently been hired to help my company setup an IT Services Catalogue. I have ITIL Foundations training and certification. While I am not new to ITIL concepts, this will be my first Services Catalogue implementation.

I realize that one of the keys to a successful implementation is to have a working CMDB that helps us understand all the relationships of CIs behind or supporting the service. Tracking the components as well as end to end is crucuial to our success in service delivery.

Currently the company does not have a CMDB. I'm working with a fellow employee on that initiative as well. While discussing strategies, we came across the question, who should own the CMDB? (Incident Manager, Problem Manager, Asset Manager, Service Level Manager etc). I was interested in hearing others perspectives on this topic and how they addressed it at their company.

Right now I'm leaning towards assigning ownership of the CMDB to the Service Level Manager, in this case myself, as it helps us align with what we want to deliver for our clients.

Regards,
Greg

[mnsmith]

ITIL states that the CMDB is the responsibility of the configuration manager but as you've not got a CMDB at the moment, I doubt you'll have a config manager. The next best person would be the change manager, as they are closely related to the config manager and in my case are performed by the same person.

Hope that helps
_________________
Mick Smith
Change, Configuration and Release Manager

[Diarmid]

Hi Greg,

I think you have to look at practical issues. How big a workload will it be short term and longer? Which managers have the best aptitudes for that role? Is it okay to mix strategic roles (CMDB) with tactical roles (like, say, Incident Management); I hesitate to line up all the ITIL roles in this way because it is all relative to how your organization tackles this.

There is no hard and fast answer. Who ever takes on the CMDB has to be careful not to develop it from their own perspective. They have to step back and look at how it will work effectively throughout the service.

Since Mick got in before me, I'll add that the Change Manager is a good fit for the wider perspective.
_________________
"Method goes far to prevent trouble in business: for it makes the task easy, hinders confusion, saves abundance of time, and instructs those that have business depending, both what to do and what to hope."
William Penn 1644-1718

[UrgentJensen]

Good question Greg,

I agree with the guys above but would like to expand (though not literally, that would be painful):

You don't want to create a conflict of interests. The CMDB will hold the truth about what CIs have changed from one day to the next and therefore if you are trying to enforce Change Management then you need to have someone in control who can report impartially on what's been done right and what's be tampered with 'under the radar'. Giving it to an operational manager can be an issue, though not always and I have no reason to doubt you or anyone else.

Secondly scaling. The breadth and depth of data you wish to capture and maintain will have a direct correlation to who can practically take this on. If you're literally just counting pc's, servers and network devices then sure, give it to the Change Manager. Otherwise...

Cheers,

UJ
_________________
Did I just say that out loud?

(Beige badge)

[gmcgee]

Thanks for sharing with me your perspectives and advice.

Greg

[Fabien]

so, for the monkey wrench...

Many service management tools today offer a wide range of functionality, including a CMDB. The discussions then become very interesting. In V3, the entire CMS (the ensemble of repositories & tools holding and managing configuration data) should be the responsibility of the configuration manager. But it's really not that easy.
_________________
BR,
Fabien Papleux

Accenture
Technology Consulting | Service Excellence
Red Badge Certified

Twitter @itilgeek

[Pathak]

Hello Greg,

An input to service catalogue is never from CMDB in real sense. It is laways otherwise. SO u may go ahead and get your servcie catalogue ready/implemented as soon as possible.

Let me put it like this. By having your service catalogue prepared you then in right earnest start looking for what component makes difference or impacts the service and start steadily identifying them as CI. This way you would steadily build your CMDB in some time

Regards,