 |
|
| Recent
Articles |
The Evolving Domain Language Of IT
One of the hallmarks of mature professions is that they have a clear and detailed language - a domain (or universe) of discourse or an ontology. In the...
Souce Code's Value
In the past week I heard about two fairly large companies who are in a bit of a jam. Back in the days of the Internet Boom, they purchased an "E-commerce server" from...
What You Need To Know About The New Version Of...
The Information Technology Infrastructure Library (ITIL) v3 was released in June 2007, seven years after the last critical ITIL methodology update. With this new...
Where IT Is Going
Over the last couple of days, I have been at a security conference in NY City, and it has proven to be very interesting in the end not just to hear about what pain people have, but in general, where major industry...
SOA, BPM (& EDM) For Enterprise Applications
Bill Swanton and Ian Finley at AMR Research recently published "SOA and BPM for Enterprise Applications: A Dose of Reality" (subscription required).
Federal Litigation Rule Changes And IT/Data "Maps"
In 2004, I noted the idea of the "Data Map," proactive documentation of IT assets undertaken in the interest of litigation preparedness.
With recent changes to the Federal Rules of Civil Procedure, the concept is...
|
|
08.30.07
CMDB Dream Team
 By
Charles Betz
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.
Continue reading this article.
About
the Author:
Charles Betz is a Senior Enterprise Architect, and chief architect for IT
Service Management strategy for a US-based Fortune 50 enterprise. He is author of the forthcoming Architecture and Patterns for IT Service
Management, Resource Planning, and Governance: Making Shoes for the Cobbler's Children (Morgan Kaufman/Elsevier, 2006, ISBN 0123705932). He is the sole author of the popular www.erp4it.com weblog.
|
|
