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
