The CMDB dream team

One of the issues dogging the CMDB hype cycle is the steep requirements for architecting and implementing such systems, even when based on vendor products. Expertise from a wide variety of domains is called for. What would a qualifed CMDB dream team look like? 

(Be warned this is a bit of a rant)

First, what do I mean by qualified?

I mean in the professional sense. A heart surgeon is not qualified to have an opinion on brain surgery. An accountant is not qualified to render a legal opinion. I am not qualified to have an opinion about supply chain optimization, operating system kernel architecture, or ultra-high-volume OS/390 transaction processing. That's life; we all specialize. But it's important to know what we don't know.

The CMDB (or the CM system) is, first and foremost, an application system. It is not an infrastructure service (like networking), nor is it a core operating system, nor is it middleware. It is an application to be used in the fulfillment of use cases that add value to the efforts of stakeholders.

Those stakeholders are often infrastructure engineering personnel, with backgrounds in networking or server engineering; or ITSM staff concerned with processes such as change and incident management. It is much less often the case that the CMDB stakeholders have backgrounds in application requirements, design, construction, or management.

(This narrowness of experience, unfortunately, extends to many of the consultants and pundits pontificating about the CMDB.)

There is often an assumption among such stakeholders that they are also qualified to install and manage an enterprise class application. "How difficult can it be? We have a few people who've hacked some code, among our server engineers. We install and support our server management consoles. How is this different?"

It is different, trust me. Installing a middleware management console for the use of 5 infrastructure engineers focused on specific and detailed configuration problems, is a completely different problem from installing an ITSM suite, or a CMDB. You don't want infrastructure engineers implementing a large, shared, multi-user, multi-use case application, any more than you want application developers mucking around with OS kernel parameters. 

So, what do you need on your CMDB team to help ensure success?

- Project management experience. PMBOK, PMI, Prince2, etc., etc. And if your CMDB is the foundation for a variety of ITSM efforts (improving Incident, Problem, and Change for example) you need program management experience.

- Experience in requirements engineering. Do you have someone who has built out requirements, at a detailed level, for multiple complex systems involving multiple distinct stakeholder groups? Understands the distinction between functional and non-functional requirements? Between use cases and "shall" format? Pros and cons of each? In use cases, between essential and detailed? If the "vendor is going to do this," do you have someone in-house who can validate what they are capturing? Requirements are the most common cause of large systems failure, by far.

- Architecture and systems integration experience. Do you have someone familiar with design patterns? Not just the Gang of Four, but the Martin Fowler/Gregor Hohpe work is especially relevant, for when you need to think through how that CMDB is going to exchange all that high complexity data in a federated model. The vendor is going to do that for you? What if they need to exchange data with one of their worst competitors' products? Feel confident they'll do right by you if you don't have any undestanding of what they are proposing?

- Experience in real software development. Not just shell scripting. No, we're not going to build a CMDB from scratch in C++, but they are all frameworks requiring care and feeding by engineers with strong backgrounds in application management. (One of the most popular CMDBs has a core engine that looks much like PeopleTools. See also 4GL) Oh, your vendor hadn't told you that? Their professional services folks will be taking home nice Christmas bonuses at your expense... Unfortunately, this is not something you can just take anyone from the help desk and train them in, no matter how motivated they may be.

- Data/OO competence, up through metamodeling. What is your conceptual model, the major concepts you are going store in this database? YOU have to specify those - they are your requirements, and industry standards are of minimal help. How does your conceptual model translate to logical and physical realizations? Which of the many alternative choices of CI types available in the modern CMDB are you going to use to represent your concept X? Sometimes they will map - and sometimes, they may not.

On a more advanced level, if you want to negotiate some of the coming trends strategically, you need someone able to read the likes of OMG platform specs and the DMTF models and understand and critique them; understand the religious wars among the relational, object-oriented, and XML camps, with Semantic Web emerging as well. Can you mediate such a debate between your data and application architects? Do you understand the difficulties of deep inheritance and recursion? What about SML (CMDBf) on the horizon?

Or is this all more professional services $ to your friendly vendor?

- Data quality management. Data quality is the Achilles' heel of the CMDB. This seems to come as surprise to some, who then assume that "CMDB can't be done." I beg to differ. Data quality is an issue that will always be with us. It has been solved in many large scale systems, through a combination of

• Master Data Management principles
• correct, self-reinforcing process design
• process quality assurance
• data quality metrics and sampling

all implemented as an interlocking whole. Have you participated in any such efforts? (See Larry English, David Loshin, and DAMA.) Don't look to your vendor here; they won't have a clue about data quality. There are consultant$, of course. How do you know if they are any good?

- Process design, implementation, and improvement. I'll give ITIL/ITSM practitioners credit in that this usually is a stronger suit. But way too often, the assumption is that "process is everything, and data and system are nothing, or can be left up to the vendor." Dangerous thinking. If you don't have a logical data and systems architecture to complement your process architecture, you have a stool with one leg.

And finally, you do need your infrastructure engineers and managers. But in this case, they are the customer - the source of many of your most important requirements. This may be an unfamiliar role for them...

All of this expertise must be combined to plan and execute on CMDB implementation and integration. If you're missing any of it on your team, your CMDB is at risk.

Resist the temptation to say the vendor will do it all for you. This didn't work with ERP systems, and it will not work with CMDB.

(Rant off.)

-Charlie 

Comments

[alex]

Hi Charlie,
You list a good mix of skills that represents the kind of expertise one would want in a team that maintains and evolves a CM repository. Actually, I would say, that the same mix of qualifications would be useful for many development projects, not only a project that resulted in a successful CMDB implementation.

Rather than contemplating a "CMDB dream team", I would instead like to take a step back and ask two questions that I believe have lead to issues that dog "the CMDB hype cycle" and represent bigger risks to CMDB adoption.

1) Where, organizationally, does the CMDB fit?
IT likes to structure itself into a development group and an operations group. Given that structure, which group is best suited for developing and administrating the CMDB? A comprehensive CM model will describe entities spanning both development and operations worlds (e.g., application components vs. physical infrastructure). Of course, all these CM entities are inter-related so a change in one place, impacts other parts of the model. Assuming both development and operations can agree on collaborating via a CMDB (which would be a huge landmark decision), there are still practical problems around who ultimately controls the CMDB. This leads to another practical question:

2) What is the role of a CMDB with respect to other tools?
A CMDB in isolation is just a data model that amounts to documentation. A CMDB only has practical value if its data and artifacts are leveraged by tools - tools that drive the day-to-day IT processes such as application releases, operating system upgrades, network configurations, etc.

Both questions really can boil down to this: How do development and operations groups collaborate using the CMDB paradigm? Does anyone have real life experiences they can share?

Alex
---
dev2ops: Driving change from dev to ops in a software as a service world. A view from the trenches.

[alphasong]

re 1) The CMDB as an application should be owned by the same group that supports your HR and Finance systems - it is a corporate back end system. The business process owner should be an IT Service Management organization that is neither development nor operations, but a referee between the two.

2) For one vision, see http://erp4it.typepad.com/erp4it/2005/06/a_success_story.html. I have a lot on this in my book.

[Jiri Ludvik]

Charles,

Why are you calling your post a rant? I think it is rather justified. Even though I have not seen the full CMDB, I have been pretty close to two asset / inventory management implementations from which I can say draw some lessons. I'd say that in terms of skills, ideal team is pretty much closer to an ERP than a technology project. I would probably combine several skills you mentione into fewer roles:
- project manager
- CMDB tools expert - data structures, cmbd tools
- requirements, process & business change specialist - use cases, requirements, business process engineering
- architect - overall concetp, data sources, integration.
- ops process specialist - ITIL, day to day operations
- data acquisition
- data cleansing
- training

This is pretty similar to the roles on an ERP project. The only problem there is that because business benefit of CMDB is much smaller than that of ERP, it is difficult to justify the funding for experienced and full time staff for these roles. So you probably end up with fewer part time people who are not clued up, which will evenetually result in lower quality and/or longer timescales.

Following Alex's example and taking a step back, I think the key to successful implementation is in the balance of costs & benefits. I had a discussion about this yesterday with one of our CMDB /asset management specialists and we pretty much agreed that for the time beeing the balance of costs & benefits for CMDB is still too heavy on the cost side, which makes successful implementation rare / painful.

I'd guess the key is looking at what can be done now (in terms of CMDB products, ops process design & enterprise infrastructure design) that will enable easier future adoption of CMDB.

[Larry]

We have used a remarkably similar structure for our project team that is implementing a CMDB.

I would also add that this approach applies to any service management systems or tool implementation and yes it is very similar to any other IT project for the business.

The one difference? We don't have to train the finance people in generally accepted accounting practices if we are implementing a financial management system for them. But...we do have to train IT staff and managers in ITIL and Service Management... :)