ITIL’s dead elephant: CMDB can't be done

Blog entry submitted by skeptic on Mon, 2006-06-26 22:17. [nid:25]
in

This article has been podcast

CMDB can’t be done. Not as ITIL defines it. At least not with a justifiable return on the investment of doing it - it is such an enormous undertaking that any organisation attempting it is going to burn money on an irresponsible scale. The truth about CMDB is no secret. It is a “dead elephant”: a great putrescence in the corner of the room that everyone studiously ignores, stepping around it and ignoring the stench, because life will be so much simpler if they do not acknowledge the obvious.

Let us look at what is required of a CMDB:

“Configuration Management provides the foundation for successful IT Service Management and underpins every other process. The fundamental deliverable is the Configuration Management Database (CMDB), comprising one or more integrated databases detailing all of the organisation’s IT infrastructure components and other important associated assets. It is these assets that deliver IT services and they are known as Configuration Items (CIs). What set a CMDB apart from an ordinary asset register are the relationships, or links, that define how each CI is interconnected and interdependent with its neighbours.” [Ref 1]

“Detailing all of the organisation’s IT infrastructure components and other important associated assets”. I worked with a bank whose network and systems management environment managed 70,000 objects. That figure included no software (in-house or packages, applications or operating systems) and few logical objects like processes or services or owners. And they were not that big a bank. So I would say that a large organisation could well have a hundred thousand objects in a CMDB. Any organisation that doesn’t have thousands of objects to manage isn’t trying.

We hear that it is just a matter of getting the granularity right, and not including too much. On the other hand, the best working definition of what should go in is “whatever is managed by Change Management”. So ask yourself what isn’t. Should every PC be under Change Management control? Of course. What about the operating system on those PCs? Other software? If not, then you won’t be doing Release Management. What about the peripherals (keyboard, mouse etc)? No? You aren’t subject to occupational safety and health regulations? If someone suffers RSI and needs a trackball not a mouse, where will you track that if not in the CMDB?

So we will have between 1000 and 100,000 objects in our CMDB.

How will you populate the CMDB initially? The vendors’ silver bullet solution is auto-discovery. It can find out something about many things, but not everything about all things. It won’t help with disconnected devices, or financial information, or physical location. Ask how they go with finding UPS, PABX, factory machinery, or building security and cooling systems.

I worked on a project once that built a new retail system for an oil company in a moderate sized country. They had to populate 50,000 entities (tanks, trucks, warehouses, shops…). It took a team of – as I recall – three people for two years to capture and load the data. Another rule of thumb I use in Configuration Management is that any manually collected data is out of date before it is entered.

Maybe half the objects can be auto-discovered initially, but only half the data about them will be discovered. Warranty, contractual and other data still needs to be manually loaded. So expect between a few person-months and a few person-years to load the initial data.

How will you keep it current and accurate? By good tight Change Management which ensures the CMDB is updated whenever anything changes. How will you know if an error is made or someone subverts the process? The vendors’ silver bullet solution is … auto-discovery and comparison with the CMDB. See above for the limits of scope. Most tools don’t do this out-of-the-box: you will need to develop audit jobs to scan and report on discrepancies. And some manual report and review processes to pick up stuff the automated tools miss.

So expect a significant development effort to build quality control processes and tools.

Let us turn our attention now to “the relationships, or links, that define how each CI is interconnected and interdependent with its neighbours.” A single parent child relationship isn’t going to cut it here. We have relationships such as “is physically networked to”, “is responsible for”, “depends on”, “depends on but only at the end of the month”, “depends on to meet a gold SLA but can manage without it for silver”… Not to mention dealing with redundancy. Say we have seven web servers, equipped with load balancing and automatic failover. If one fails, what will be the impact on the SLAs? How many can we take out for maintenance without degrading performance?

What are the permutations between half a dozen relationships, with embedded business rules, and thousands – or hundreds of thousands - of objects? Capture those and keep them current! Maybe double your estimates.

But we are not done yet. Let us crank up the complexity by another order of magnitude: “comprising one or more integrated databases”. The probability of it being one integrated database is virtually nil. No vendor has technology that can manage the whole environment from .NET objects to telephones, so all CMDBs will be a federation of multiple vendor repositories.

The problem is that many organizations have multiple discovery tools to glean information from the same components. A federated CMDB must prevent data duplication, as well as be able to understand that different pieces of data gathered by different tools--an IP address, patch level, a host name--all belong to the same component. This process is called reconciliation, and experts say it's critical to a successful CMDB. They also say most reconciliation engines are proprietary. [Ref 2]

There is as yet no standard for their integration so all interfaces will be custom built. [For you geeks out there: ask how many integration interfaces support two-phase commit protocol to ensure transactional integrity when changes are made].

The CMDB is in its infancy. There are no standard definitions of what information goes into a CMDB, no schema for structuring that information, and no standards for integrating data from disparate vendors…. While the CMDB promises a host of benefits for the enterprise, it's also horrendously complex, lacks implementable standards, and is rife with proprietary exploitation. At present, there's no standard schema for the data that's supposed to reside in the CMDB… any CMDB implementation that aims to import and utilize data sources from disparate vendor tools will require manual integration. [Ref 2]

Vendors have rushed to fill that definition vacuum with their own implementations. For instance, Computer Associates created a data schema that's consistent across its own product line. This data schema populates the company's version of a CMDB. HP has been shipping a CMDB with its Service Desk that uses Web services to pull application information across HP's product portfolio. BMC Software's Atrium CMDB is shipped as a component of, or can be integrated with, eight BMC applications, including the IT Discovery Suite and the Remedy IT Service Management Suite.
However, all these CMDBs are essentially proprietary extensions to the vendors' own product suites. "There's no standard in the industry for how a vendor should build the data model inside the CMDB," says Colville. "There's a huge propensity to lock into one vendor for all of this." [Ref 4]

Some organisations will further multiply complexity by implementing a stand-alone “universal” CMDB which is synchronised with the other vendor repositories.

If you want something that meets the ideal DCMDB specification you are going to have to build it:

Every vendor claims to have a configuration management database (CMDB) or a CMDB strategy. Yet they are merely playing off Information Technology Infrastructure Library (ITIL) hype in this area and don't really have all the necessary functionality required for a true CMDB: reconciliation, federation, mapping and visualization, and synchronization. Rather, many are taking their domain-specific configuration repositories (such as for desktop or server configuration management, asset management, or help desk), adding one of these functions and calling it a CMDB. [Ref 3]

While the [sic] ITIL describes the processes associated with a CMDB, it says nothing about just how a CMDB gets built, how various tools are meant to feed data into the CMDB, how data should be structured inside the CMDB, and how various applications are meant to use that data. … "Customers are just trying to get a handle on what a CMDB can do," says BMC's Emerson … Enterprises that attempt to roll out a CMDB as a silver bullet for all their network management ills are likely to be disappointed. The difficulty of interoperability and the lack of standards mean a fully realized CMDB may be years away. [Ref 2]

My concern is that the convergence of architecture and process - and frankly often inflated vendor marketing - that now seems to be driving CMDB interest is complex and confusing. And CMDB technologies and standards are also very "early in the game." I am concerned that too many IT expectations are moving towards the notion of the CMDB as something that IT can simply buy to fix its woes. And this, of course, is both dangerous and false. While I am a big CMDB believer, I view it, like ITIL, as an enabler for more efficiency, improved compliance, better governance, etc. But it is not really a "thing." It is the beginning of a journey… [Ref 4]

So stack another development effort on to your estimates, to build the integration interfaces. Since these do not support two-phase commit, transactional integrity cannot be assured, so you will also need consistency reports, and repair policy and processes (mostly manual).

And now the sting: after all that I don’t believe CMDB is going to make that much difference to your ITIL processes. You sure won’t be able to automate any but the most basic impact analysis (the sort of thing vendors demo). The most sophisticated modelling tools on the market struggle to predict performance degradations, yet most SLAs put at least as much importance on performance as availability. They even struggle to predict availability whenever IP networks are involved, especially if the internet enters the equation (though complex intranets are challenging enough).

So after all that time and money a human is still going to have to look at a proposed change and make a judgement call; better informed than before, for sure, but still operating on imperfect information. Perhaps that money would have been better spent on a few nicer reports and exploratory tools, and another change management person, and a golf course for the staff.

In the past, companies wasted fortunes and diverted key resources for years trying to have one common relational database, and/or one common enterprise data model, and/or one repository of meta-data. They are doing it again trying to have one common repository of identity, or one repository of objects or Web Services. The sooner technologists and vendors stop peddling this kind of magic-fix crud the better off we will all be.

ITIL is about fixing the people and the processes, and only then implementing pragmatic tools to help them. How such an idealistic, bloated, infeasible, technology-will-solve-all-our-problems concept as CMDB got in there is beyond me.

CMDB is the only major example of ITIL describing what-should-be rather than what-is-and-how-to-manage-it, and it fails the test of common sense.

References:

Bookmark this post with:
  • Delicious
  • Digg
  • Google
  • StumbleUpon
  • Yahoo
  • Reddit
  • folkd
  • Facebook
  • Propeller
  • Magnoliacom
  • Newsvine
  • Furl
  • Rojo
  • Technorati
  • Icerocket

Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Hitting strong in our face

Submitted by Antonio Valle (not verified) on Mon, 2006-06-26 23:36.

Wow skeptic! This time you hitted hard and it hurts!
You are right in the fact that this is really difficult to get up and running. I think that a medium CMDB is a need and it is quite feasible, but only if you forget the auto-discovery and the manual entries to the database. I always recomend to go straight to the source: ¿Where it all start? In the ordering system. Whenever you buy it, you insert it into the CMDB and by discipline (important thing here!) whenever you throw it, you deactivate it in the CMDB.

It's not an easy thing, but I'm wishing to read on how to govern it without a CMDB.

Regards,
Antonio

Yes but asset register is not a CMDB

Submitted by skeptic on Tue, 2006-06-27 01:03.

Hi Antonio

What you say is true: tighten up acquisition processes and you ought to have a good list of assets in the environment, but:

- all the stuff already out there
- in-house developed code
- database instances
- logical entities like services and owners
- configuration (in the sense of "setting") info: eg web server config, routers etc etc
- stuff that sneaks in anyway: eg rogue project servers and personal wireless hubs
- purchase clerks don't know anything about the relationshiops, which are what differentiates the CMDB from existing asset databases
- relationships and dependencies change over time

In short, an asset purchase register is not a CMDB.

A better place to tighten up the tracking is in Change Management. If every change process includes a step to update the CMDB (where has it moved to? what was installed on it? what services depend on it now? what does it relate to now? ...) then in theory every CI should be properly tracked, and Change Management and Config Management staff ought to know the relationships better than anyone, and care about getting them right. By definition, if Change doesn't control it, Config isn't interested in it.

But even then, that still doesn't address:
- all the stuff out there already
- subversion of Change process (nobody can say it doesn't happen, deliberately or inadvertently)

CMDB standards

Submitted by Holger (not verified) on Tue, 2006-06-27 05:11.

It´s right, there is no standard for a CMDB, yet. That might change in the future though, as some vendors (HP, IBM, BMC Software and Fujitsu Limited, as well as CA) seem to work together to get a standard running, see http://www.itsmwatch.com/news/article.php/3608331 for more info.

Vendor standard CMDB

Submitted by skeptic on Sat, 2006-07-01 10:38.

thanks Holger

I did mean to comment on this effort but somewhere I forgot. It will be most interesting to see where they get to and by when. CA for one have just sunk a fortune in re-engineering everything to their own CMDB structure. they won't be keen to repeat that investment. Nor will others.

The talk is of "federation"; i.e. an inter-operability standard: probably just a Web Services XML definition to share CMDB data (and about time). You won't be running Tivoli tools against an OpenView CMDB any time soon.

A federated CMDB will help a little in getting a consolidated view. You will set up One CMDB to Rule Them All, but nothing these vendors come up with will help the relationship-maintenance problem I refer to in a comment below.

More on this topic here

Submitted by skeptic on Fri, 2006-08-18 00:19.

More on this topic here

ITIL - IT Infrastructure Library

Submitted by Collin (not verified) on Tue, 2006-06-27 17:23.

Whilst I understand that compiling the CMDB is a mammoth task there are two things that this post immediately made me think of:

1. ITIL is IT Infrastructure. One of your examples mentions "(tanks, trucks, warehouses, shops…)". Where does a truck fit into IT as far as the CMDB is concerned?

2. I have only done ITIL Foundation recently (I found out today that I passed the foundation exam). One of the things that the course trainer kept mentioning is that ITIL is not mandatory. It's a set of guidelines that an organisation can "adapt and adopt" to suit their needs.

Last year, over four months or we did a complete audit of every IT asset in our organisation. We captured something like 40,000 assets and recorded all that information in our CMDB and immediately we are seeing benefits with licencing, move management, change management, and problem control to name just a few.

Yes, it took an organisation of 35 people over four sites, four months alongside "business as usual" to complete, but as far as the IT organisation is concerned it was time well spent.

Hi Collin Thanks for

Submitted by skeptic on Tue, 2006-06-27 22:35.

Hi Collin

Thanks for commenting and welcome to the ITIL community. Your comnent raises some interesting issues:

My example of the oil company with tanks, trucks etc was not an example of ITIL - I didn't make that clear. It was just an example of the complexity of doing the kind of audit that your company did.

That said, ITIL is about managing the delivery of a service, so everything that the service depends on to get delivered should be under ITIL control. That means people, power supplies, building systems etc as well as IT. If the cooling goes off and the server room melts down, that will impact SLAs :-D

Did your company's audit also record the relationships and interdependencies between the assets? If not, it isn't a CMDB in ITIL terms, it is an asset database. The main function of a CMDB is to support impact analysis: impact of a change and impact of an outage. If tyhere are no relationships to "walk" to map the objects to dependant services, there is no analysis.

Also, if the assets you audited are not under good Change Management, then the configuration information is out of dtae before the person gets back top record it in the system. That's how it was then but how is it now? If that question can't be reliably answered then it is an interesting audit for the bean counters but not for service management.

Using software discovery we

Submitted by Collin (not verified) on Wed, 2006-06-28 06:55.

Using software discovery we collected information about all the software installed over the four months of the audit.

We have hardware and software relationships for all our assets, this is our method of licence control. Unfortunately the CMDB does not yet include (as you mention) buildings or services (such AC) within the building. Our network is controlled by an outside agency so we don't have that. CMDB and the ITIL process has still helped us enormously and I believe that management are looking to adopt further after the summer. I say "management" as I am only the grunt on the ground doing the job!

As for Change Management, if it was any tighter then the users would NEVER get anything! We (the grunts) have to fight on behalf of the user to justify their requests otherwise the request is refused. That REALLY gets on my nerves to be honest, but that's a different matter entirely.

Thanks for making me welcome, I will certainly be back regularly and when I have more than five minutes to spare I will be going back to read some of the older posts.

Collin

Sounds like your

Submitted by skeptic on Sat, 2006-07-01 10:49.

Sounds like your organisation is well set up and has the chance to achieve a CMDB. Do you also relate the assets (hard and soft)to processes and services and owners and SLAs? That's the hard bit.

I do admit elsewhere that a CMDB is conceptually do-able with enough people resource to load and maintain it. My contention is that "enough" requires unjustifiable investment, bordering on silly.

re Change Management: it needs to be tight to protect the CMDB data. But that means tight in how the process is conducted and most of all ensuring that the process cannot be subverted. It doesn't mean it has to be tight in what is approved: that's nothing to do with ITIL. In other words, you can approve every single change proposed if you want to, so long as the process guarantees the change will be reflected in the CMDB data, and guarantees no changes can happen without approval or without going through the process.

Great points.

Submitted by Rodrigo Flores (not verified) on Wed, 2006-06-28 01:55.

I have had similar concerns and written about these here. It's clear there are pragmatic wins for managing change, but the one ring to rule them all hype gets in the way. Here's post on the relationship between service catalogs (my blog) and the CMDB.

The achilles heel is not just the sheer amount of stuff to be discovered but the fact that some aspect of those relationships are always changing. For example, in the U.S. SOX compliance has required that IT understand and track the relationship between application access, people's roles and financial results in a new way -- none of that is in the CMDB today and nor is it discoverable.

My blog: http://servicecatalogs.typepad.com/servicecatalogs

Thanks Rodrigo. We are on

Submitted by skeptic on Wed, 2006-06-28 04:20.

Thanks Rodrigo. We are on the same wavelength: "At best, a discovery tool will only discover 50% of what you have in your infrastructure. The rest has to come from logical definition".

I also liked what you said elsewhere in your blog: "The customer issue is not about ITIL and doing process for the sake of process. You have to find what business issues is senior management concerned with, and how implementing ITIL can help. Implementing ITIL for the sake of ITIL doesn't work. You have do the complete work of tying into a specific set of pains, issues, and value"

So when is the effort of a CMDB justified by the return, by the business issues? Can it be done? How many have you seen actually done?

Don't agree, at least 100%

Submitted by Antonio Valle (not verified) on Thu, 2006-06-29 22:30.

You know what, Mr. Skeptic? A friend of mine told me some time ago that I am a secondary person. With the term "secondary" he wanted to express that I don't use to follow primary instints and I use to think about what I want to say, so I'm not good for quick discussions.

I've been thinking, and I wanted to express my opinions about your (incomplete) posting (i mean incomplete because I'm waiting for the next one: how to survive without a CMDB) :-)

1.- About the point that it is impossible to track all the CIs: my opinion is that information starts in the beginning with that thing that you call "the asset list", when we place the order the CI appears. Then the configuration management PROCESS starts: as soon as the new object arrives to the company it is processed (and the information is modified), and as soon as the CI is installed we hace 50% chances that it will be detected by our discovery tools and updated (a very common mistake is to let those discovery tools *create* the CI, and it should be allowed for automatic creation of new CIs). This update can be, for example, add the relationships that the tool can discover.

2.- About the number of CIs: yes, we can have tons of Cis. I think that a good and strong Release Management can help us a lot.

3.- About Relationships and its need. I think that all will depend on the maturity level of the company. At least, 90% of companies where I have done ITIL work they were not mature enough to have the imperious need for Impact Analysis derived from CMDB and relations between CIs. May be this is not the final focus. You can a good maintenance contract management, good support, good "going live" preparation, etc. And, of course, you don't have to maintain the same CMDB detail level and relationship level for all the areas in your CMDB. I mean that you can have detailed relationships in those areas where the ROI is better.

4.- And lastly... a company with 100.000 objects in the CMDB is a big company... I bet that they will have 100.000.000 movements in their annual accounting system. And they *can* manage the acounting. How? With something that accountants have, but IT people use to leak: DISCIPLINE. My company is a small one, but I really flip out when I see how the girls at the accounting department work.

Of course, it is a really hard way and many times (if not used properly) it doesn't pay the money. That's why in some cases I agree with you.

Regards,
Antonio

I'm with you on all of that

Submitted by skeptic on Fri, 2006-06-30 05:59.

I'm with you on all of that Antonio. What you say is true and it works. My point is just that it is not the idealised CMDB. What you are talking about is the practical solution. What the ITIL books define as CMDB is not.

What is ITIL core?

Submitted by Antonio Valle (not verified) on Fri, 2006-06-30 06:09.

Well.. what is ITIL? A set or a compendium of Best Practices... the practical way, isn't it? so may be the problem is only in hte words, how is the book written instead of in the sense of the words.

Antonio

Best Practice is a sacred cow

Submitted by skeptic on Fri, 2006-06-30 06:42.

Agreed. Which causes two issues:

1) some people take it as literal truth instead of subject to interpretation/adoption (see "ITIL as a cult")

2) Best Practice is a sacred cow. Everyone thinks they have to do best practice all the time. SO ITIl documents best practice but people don't question whether they need it, whether it offers a competitive advantage to go to the cost and effort of adopting it, they just do it because it is [cue soaring music] Best Practice. See these guys at CoPr for a jaundiced view of best practice.

Sacred Cow

Submitted by Antonio Valle (not verified) on Fri, 2006-06-30 09:32.

... that's the problem with fundamental religions... don't interprete the words, just read and follow the Sacred Word.
I agree on this with you, and remember this thread when the first books of the refreshed set appear. The religion basis will be modified in many ways and the Internet will be full of comments on this topics.

Antonio

The butterfly effect

Submitted by Antonio Valle (not verified) on Fri, 2006-06-30 09:12.

Everything is related to everything, and in this world, made smaller by the Internet this is what you get.

Today published article:

http://en.itsmportal.net/news.php?id=2257

:-)

What a load of crap

Submitted by skeptic on Sat, 2006-07-01 11:24.

Thanks for the link Antonio - I hadn't seen that.

I have commneted in a new blog post

CMDB

Submitted by David Locke (not verified) on Sat, 2006-07-01 09:41.

The CMDB is a GIS problem not an RDBMS problem. Mapping the infrastructure, the databases, the applications, the wires, the firewalls, the routers, the switches isn't impossible. We are just forced to use the wrong tools by the vendors that lack vision.

Change mangement is a spatial-temporal problem. Where is the change going to be made? When is the change going to be made?

You would even get further than the current offerings if you used MS Project with it's predecessor-successor mechanism, which just doesn't go nicely into an RDBMS.

I've doen ITIL. Nobody liked it. Nobody noticed that they were not getting called in over the weekend. But, the oncalls were doing less work over the weekends. The changes were made over those weekends. Less outages drove down the oncall impacts. But, nobody liked it.

People would refuse to close their change logs, refuse to take responsibility for process improvement, and tell me how production was more important, which was just a way of saying I'm dealing with reactive situations so much that I'll never get proactive.

ITIL is possible. But, not with the attitudes. Doing it has nothing to do with tools or effort. It has everything to do with people's attitudes towards it. Those attitudes are even manageable, if managment tried.

ITIL is possible. CMDB isn't

Submitted by skeptic on Sat, 2006-07-01 10:20.

Hi David and welcome,
Glad you found us.

GIS is an interesting spin on CMDB, but I don't think it can be done with any technology. If the whole thing could be automated then the problem might go away with enough hardware, but we are so far away from having that kind of intelligence in the tools that I wull be happy if I see it in my lifetime. The relationships are often conceptual and sometimes subjective: only humans can infer them. And any IT shop big enough to cost-justify someone maintaining those relationships is too complex for them to maintain it. Or if they did manage, the cost would not justify the return. That resource would have been better deployed fixing problems or processing changes or answering calls or a hundred other tasks than maintaining an anal book-of-all-things.

I suggest that people's attitude to ITIL changes when:
- the results are visible
- there is glory in the results
- their KPIs reward those results
If the management and the wider organisation are not thanking and rewarding them for what ITIL achieves then ITIL represents a burden and an imposition.
And hey, guess why management and the wider organisation don't react positively in so many instances? Because ITIL did not return the business benefit they most needed.
I'll address that in a future blog.

Some Flaws With ITIL That Show Up in the Definition of a CMDB

Submitted by Frank Guerino (not verified) on Wed, 2006-07-12 22:17.

Skeptic,

I'm new to your site. First, let me say that I was pointed to this post by a colleage who spoke very highly of the content, here. I want to say that after reading many of the posts, myself, I have to agree with much of what you say.

Second, specifically to do with this thread, your post on CMDBs not being achievable (based on the constraints you mentioned) is "very" accurate. It's probably one of the most realistic looks at the implementation of a CMDB that I've seen in a long time. (If you're interested, I have a white paper I wrote last year that breaks down Configuration Management into his most primitive and common requirements, that span all areas of a business. You'll find that it matches your requirements, almost exactly.) I have shared your views on this topic for a number of reasons. I'll get to the details, down below, but first I'll say that my view comes from having managed many different organizations within small, medium, and large IT organizations in many different vertical industries. I believe that I came to the same conclusions you did, even if it was through a different path.

Before I go any further, I want to make it clear that I own and run a company that delivers ITIL related solutions and that we use "your" criteria for a CMDB as the foundation for our offering. I'm not trying to market our solution and I make no claims to our solutions being perfect (although I am biased and I do believe it's a better solution!) We do not believe in building and integrating a separate CMDB. We believe that a CMDB is a "side effect" of properly having all of your data connected, together. I stress the word "properly", as it ties back to your criteria: Reconciliation, Mapping and Visualization, and Synchronization. In short, we view a CMDB to be composed of 3 basic things: 1) An inventory of anything and everything, 2) Relevant descriptive data about each and every entry into each and every inventory, and 3) The ability to truly map and manage the details of each and every relationship. BTW, your description of the complexity of relationships was right on the money.

Anyhow, to support why the ITIL direction for a CMDB is flawed, I'd like to point out some flaws and/or limitations with ITIL, itself, that ultimately cause the definition of a CMDB to be inadequate. In other words, since ITIL has these issues, they trickle into the definition of the CMDB.

First, ITIL is only intended to cover IT Infrastructure "Support". It is weak on all the other areas of IT and general business management. Examples include but are not limited to:

- Up front design and development for Infrastructure
- Up front design and development for Software
- Non-IT Product Management and Development
- Manufacturing
- Business Finance
- Sales
- Marketing
- Etc.

Second, another "critical" flaw, in my opinion, is that ITIL only covers the Production environment and doesn't cover any of the other environments, such as Development, Systems Integration Testing, Performance & Stress Testing, User Acceptance Testing, etc. For example, if you're a QA tester and your test systems go down in your QA environment, to the point where your entire organization is down, you now have a Critical Incident and an Outage in your QA environment. ITIL does not properly address such issues. Any experienced manager will tell you that there is a huge quantity of relevant data/information that is generated and needs to be managed in each and every one of these environments before you can ever even conceive of managing your Production environment, properly. The data/information generated in any one up front environment is, itself, a dependency for the next environment in your product development and management pipeline. A good CMDB will cover each and every environment.

Third, a big issue with ITIL is that it conflicts with other so called best practice specifications, such as RUP, SDLC, AGILE, MSF, MOF, PMI, CobiT, etc. While each tries to cover different areas of IT, you'll see that they bleed across each other, many times in a conflicting manner. If you try to implement ITIL in an organization that already has one or more of these, you will instantly introduce conflict between stakeholders.

I can go into much more but these three should be enough to make the point.

As you can see from the above, ITIL's "scope" is only a very small piece of a very big picture. The bigger picture is managing the whole enterprise, itself, not just IT. Most stakeholders, especially in medium to larger companies, can't see the bigger picture unless they've been fortunate enough to move up through the ranks and manage large, multi-purpose, multi-regional organizations. This is why ITIL is instantly appealing to larger organizations than it is to smaller ones. In a small company you have a higher probability of wearing many hats/roles and, therefore, a higher probability of seeing a bigger picture and possible conflicts. Unfortunately, in a small company, you won't have access to "scale" issues that only come with bigger enterprises (Another issue, altogether).

Anyhow, a CMDB is something different to each and every stakeholder that exists in different parts of the enterprise. Think about this, if you ask a Software Engineer or Developer what their view of a CMDB is, it will be very different than the ITIL definition of it. If you ask a PMO resource what their view of a CMDB is, they will throw Project information into it. If you ask a non-IT Product Manager what a CMDB is to him/her, again, you will get a different description. If you ask a competent CIO/CTO what he/she thinks a CMDB is you'll probably get the closest thing to a realistic answer, as they are forced to deal with the bigger picture, each and every day. To these C-Level executives, an Asset is anything and everything they own and/or need to run their business.

The bigger picture issue is probably why your skeptism exists. You see a bigger picture based on experience and common sense. However, you also see the "intent" of ITIL, which is good. Its intent is to improve "IT". Not a bad premise and I think we all agree with this basic principle. But, because of its flaws and limitations, we all have room for skeptism.

Something non-IT infrastructure people should think about: "Assets" mean different things to different people. To a CxO, an Asset is anything and everything he/she owns, within the enterprise. Also an Asset does not have to be infrastructure related. If you're a financial company and you offer Mutual Funds, these are Assets you proactively manage. If you're an insurance company and you offer Term Insurance products, these are Assets you proactively manage. Non-IT Product Managers care about managing their Assests and the details around them just as much as any IT person. Now, to support your statement about large quantities of assets, if you total up anything and everything that you need to "track and manage", within your enterprise, the list is huge and your CMDB will fall short of taking all of this into account.

So, if you want to build a CMDB and you use "ITIL" as a guideline for specifying it, I agree, you will fall very short of where you need to be and do so burning a huge quantity of money, energy, and time. You will have very little to show for your efforts. However, if you use the basic principles of Knowledge Management as the requirements for your CMDB, you will at least be on the right track... until you realize what it costs to do so. These statements go back to your very first line, which states "CMDB can't be done... not with a justifiable return on investment of doing it". I believe it can be done and I'm betting my business on it. I just don't believe it can be done, properly, by an organization whose job it is to focus on a vertical industry that has nothing to do with CMDBs. It's worth my investment because I'm in the business of specializing in it. It's not worth your investment if you're in the business of anything other than providing a CMDB.

I throw this out to your community as food for thought: ITIL, by itself, is a very limited view of what is right or wrong. Its intent is correct but by itself it will conflict with best practices that come from other very solid and proven principles derived from drivers such as SDLC, RUP, MSF, MOF, PMI, CobiT, etc. You need to use your experience and common sense to come up with an answer that combines them all. Your enterprise can't exist with IT Infrastructure, by itself. You need Sales. You need Marketing. You need Development. You need Manufacturing. Etc.

It comes down to common sense, which, if you think about it, will probably tell you that there's good in all of those best practice specifications. The issue now becomes... "Who has the time to read, dissect, and understand all of them?" My poor wife and children had to deal with me taking the time to do so and I'm nowhere near being done!

Anyhow, I hope this information helps. I look forward to more of your posts.

Regards,

Frank Guerino
Chairman & CEO
TraverseIT
Frank.Guerino@TraverseIT.com
http://www.TraverseIT.com

Sigh, yet another person agreeing with the Skeptic :-D

Submitted by skeptic on Wed, 2006-07-12 23:34.

Boy it's hard work provoking disagreement on this blog!!

Thankyou Frank. We have conversed in the past on other forums with my other identities. I respect your experience and knowledge in this area so I appreciate your support. You may not agree with my upcoming "Living without CMDB" post :-)

The whole "ITIL is too narrow" theme is one I will add to my list for future exploration. I think this is highlighted by ISO20000. Have you looked at that closely and if so how does it stack up in covering dev, UA, QA and other non-prod environemnts?

ISO20000 Coverage

Submitted by Frank Guerino (not verified) on Thu, 2006-07-13 05:08.

Hello Skeptic,

I honestly haven't had the opportunity to go through ISO20000 in detail, yet, although it's been on my list of To-Dos for quite a while, now. I seem to keep creating too much higher priority work for myself.

However, what little I have been exposed to tells me that it does not cover all other environments. Everything I have been exposed to tells me that it simply mirrors ITIL to do nothing more than make ITIL an international standard, rather than just a British best practice specification. However, I could be wrong about this and recommend everyone take the time to read it for themselves.

NOTE: Something I find of interest is that ITIL is not a standard nor anything close to one. It is a series of best practices. ISO making ITIL a standard seems very weak to me, as there is nothing in ITIL that clearly defines detailed standardization. The closest I believe it can come to standardization is in its definition of terms, which are still very debatable. For example: If Asset Management is the management of your entire inventory of assets, then isn't Service Management the management of your entire inventory of services? Service Management seems to have a very weak and vague definition associated with it.

Anyhow, I look forward to your future posts.

Regards,

Frank Guerino
Chairman & CEO
TraverseIT
Frank.Guerino@TraverseIT.com
http://www.TraverseIT.com

all you itSMF folk, get reading ISO20000

Submitted by skeptic on Thu, 2006-07-13 07:00.

Thanks Frank. I'm a tiny bit further ahead with ISO20000 than you then. I haven't read or studied it yet either but I do know it (a) goes further than ITIL by covering many other disciplines (b) is NOT 100% compliant with ITIL in the disciplines they have in common. i.e. contrary to popular opinion, ISO20000 is not ITIL made into a standard - it is just the nearest thing to that.

I'll give you a prediction from my alter ego, the ITIL Swami: since itSMF failed in their bid to get deeper control of ITIL with the CAR tender, branching out into ISO20000 makes a lot of sense for them. i.e. ISO20000 will become as prominent in itSMF activities as ITIL is now. This would fit well with the original premise that itSMF is an ITSM organisation, not exclusively an ITIL one (it has never been that exactly, but sometimes one would wonder). So all you itSMF folk, get reading.

Interesting quote from an "official" ITIL book

Submitted by skeptic on Tue, 2006-07-18 10:08.

OK so it has been superceded by a new book, and it is only a Complementary guidance, not the core set, but look what I found in the previous ITIL in Small IT Units book:

In many small units, taking the full ITIL approach to configuration management will not be worthwhile – the overheads of establishing and maintaining the configuration links will be too great. However, it is still essential to record assets accurately in some way.
When change requests are received, a small unit may well be able to assess them without using a designated change manager, by setting up and documenting appropriate consultation processes instead.

Now the number of managed objects may not increase linearly with increasing company size but it must be close. All you mathematicians out there; how does the number of permutations of those objects (an approximation for the number of multiple relationships between them) increase with increasing number? By a factorial! yes very good. For you poor non-mathematicians, it looks like an exponential i.e. it rockets up.

So if the (old) ITIL guidance acknowledges that a small IT unit will struggle to maintain a CMDB, how the frederick is a big IT unit going to cope??!?!!!?

I wonder if the new book says something similar???

Not Ready for the CMDB

Submitted by Troy DuMoulin (not verified) on Fri, 2006-11-17 04:32.

In my experience most organizations are not culturally ready to tackle a CMDB even though it is in my view it is something that is inevitable.

Most IT organizations are at the very early stages of an evolution from technology-focused to service-focused. The challenge before us is how to convince both the IT techies and the business customer that IT does not simply manage hardware and software.

The evolution of a service mentality starts with the awareness that a customer facing service can not be understood to be collections of like technology segregated by domain, platform, or protocol. And that it is the rudimentary responsibility of IT to understand how any given IT component enables or disables a business process. Until this is known it is difficult to claim that IT is aligned to business goals.

The primary reason why an organization has multiple redundant solutions for managing data about their environement is a result of history, internal politics and IT procurement practices focused on the domain an not the enterprise. Based on a traditional technology management view each IT domain is managed as a unique function and procures tools for its own needs. From this perspective each group has separate data sources to manage their own CIs in protective isolation.

However what do you do when you realize that managing each domain in mythical isolation prohibits you from understanding the relationship of dependency between them? It is only when an organization begins to move to service orientation that this question becomes a burning issue.

In many IT organizations maturity around Configuration Management and Processes in general follows a similar pattern.

Level 1 – IT is Project and Portfolio Focused but Operationally Challenged.

Good processes and controls exist to evaluate, control and execute projects in order to ensure on time, on scope and on budget delivery of initiatives. However, once those projects arrive in production the controls evaporate. In this model little to no concern is given to the processes which need to receive and support the project deliverable once it is live. For this organization Configuration Management makes sense while the project is being developed but not a concern once the project is closed since the attention of management is now focused on the next big initiative.

Level 2 – IT Realizes that Availability and Reliability of Technology is Tied to Business Success

At this point focus is shared between project execution and the management of an IT operational environment. IT will begin to fund monitoring tools, develop rudimentary IT Inventory lists of assets and work on basic support processes such as a Service Desk and Change Management.

Level 3 – IT Realizes that Technology Components Don’t Live in Mythical Isolation

It is only when an IT organization realizes that availability and reliability have to be looked at from and end to end solution or in ITIL words a service view that the need for a CMDB begins to become an issue. It is also at this point that the organization is even ready to support the development and implementation of processes that are required to keep a central source of data up to date.

My Thoughts
Troy
http://blogs.pinkelephant.com/troy
Recently Posted a series on the different uses of the term "CMDB Federation"

IT procurement practices focused on the domain

Submitted by skeptic on Fri, 2006-11-17 05:59.

"...IT procurement practices focused on the domain an not the enterprise. Based on a traditional technology management view each IT domain is managed as a unique function and procures tools for its own needs". Oh yes! powerful point, thankyou.

Silver Bullets

Submitted by Mark (not verified) on Mon, 2007-02-05 19:40.

Your article makes many interesting points. My rule of thumb is that there are no silver bullets and no perfect solutions, hard as we may try. I hate to use the words "Best Practices" because it implies that better practices are not being considered. So I think it is generally good to be skeptical of "conventional wisdom", since it is most often an oxymoron.

The OGC books describe practices that were observed in successful IT organizations. The ITIL documentation reflects the fact that some organizations have been able to manage their configurations successfully with the help of a CMDB.

What an organization will need to invest in a CMDB itself is a given: the increasing need for a successful CMDB is met by the increasing effort to achieve it. The more I need it, the more difficult it becomes.

The return on investment for a CMDB is threefold: (1) as a means for impact assessment for changes and incidents, (2) as a source of lifecycle information for IT resources, and (3) as a common reference point for resources and documentation among various processes.

The situation you describe is typical of many organizations: the IT configuration is unmanageable. A manageable configuration is not achieved by a CMDB in isolation. This means that the first problem is to achieve a manageable configuration, then populate the CMDB with it.

For example, you could be offering desktop users a choice between a "standard configuration" or an "ergonomic configuration", rather than managing individual pointing devices. If a better ergonomic pointing device is found or required, a new version of the ergonomic configuration is created. Release Management rolls out the configuration in phases, or as needed, or only for new deployments.

How would we get to this point? First, the services must be identified that meet the business needs (e.g. standard, ergonomic, high-availability application service, etc.). Then the configurations are planned by the Capacity, Availability and Continuity processes. Then the requests for change are submitted, evaluated and approved. Then the Release is planned, tested and deployed. Then the new configuration and its instances are documented in the CMDB.

I would not allow unmanaged or unmanageable configurations in the CMDB, because there would be no benefit. You need a CMDB available for configuration management, but let the configurations be managed as a prerequisite. Otherwise, you're only documenting chaos without yielding sufficient benefit from Service Management in general.

This way, a Configuration Item is an Item in a Configuration. The Configuration itself becomes an organizing principle for disciplined IT practice. Anyone involved in Service Management will need to convince customers, users, and IT staff that such discipline is in their best interest in terms of timeframes, quality, and cost.

To implement Configuration Management this way, Service Level and Release Management need to be brought into the foreground more than one normally hears about. Being skeptical of conventional wisdom myself, I tend to look at Service Level, Release, and Configuration Management as the first processes to implement. Then you want to improve their support with the remaining Service Support processes. Finally, the remaining Service Delivery processes improve the service and configuration planning.

...or I could be completely off base!

Thanks for your article and the thinking it inspires.

Mark

the first problem is to achieve a manageable configuration

Submitted by skeptic on Mon, 2007-02-05 20:01.

Very intersting concept "the first problem is to achieve a manageable configuration, then populate the CMDB with it." But I suspect you are doing what everyone else does to achieve a successful CMDB: redefining what the CMDB is. And I don't allow that on this blog :-) If it is not what ITIL says a CMDB is then it is not a CMDB.

I also think your "look at Service Level, Release, and Configuration Management as the first processes to implement" is something akin to the holistic service mangement discussed in the latest blog entry; mor eof a top down start-with-the-service approach than the traditional bottom up first-start-with-the-foundations-then-work-up-to-the-service

achieving a managable configuration

Submitted by cmdbmaverick on Sat, 2007-02-17 03:37.

Achieving a standard configuration is a bit of a difficult task because the moment you get towards achieving this, as models of CI's become unavailable and you will need to change. Across a wide variety of products, it is an unenviable task. A CMDB is however an achievable target, that is if your willing to do some hard yards on the technical tools. I have built a platform utilising open source tools that provides for a huge percentage of the areas people find the most difficult, ie: Service Level and availability reporting, software compliance, Desktop Asset management, etc. Check out CMDB.info, there is also a demo and detailed build instructions. I understand from an ITIL point of view the processes of Release management and Problem resolution are still not covered but for most organisations there are existing tool sets. The primary focus has been on the principle of "Make it Open Source" and the rest can be developed.

BTW I think your BLOG is great

Over-achievers

Submitted by Realist (not verified) on Sat, 2007-03-10 01:00.

Find it hard to disagree with your CMDB points. I've worked in service and systems management positions for a number of years now and although I find ITIL to be a common sense approach, the CMDB rhetoric and "cornerstone" status of any successful implementation has and will continue to be complete bollocks.

It's more interesting to look at why anyone would want a CMDB and to see if something else with less ambition would achieve a much better bang for buck - ie something which isn't an ITIL CMDB.
So why do people hanker after the CMDB? Because they want to be less reactive usually. They recognise that they introduce problems via poorly managed changes, they recognise that a lack of information about relationships and dependencies affect their ability to improve efficiency and service performance, and they hope that if they had something which described their assets and components in more detail - not just as assets but the relationships between the assets and their parts in service delivery, that it will somehow make them into a proactive efficient unit. (I know I'm conveniently ignoring some of the other reasons why the ITIL CMDB seems like a good idea - I'm just giving my opinion on what it is I've seen people want to achieve.)
Well the tool itself isn't going to do anything. Service/Help desk tools which include CMDB type functionality don't actually make you provide better support or change management. Sure, if you get your service mappings right and assign the right components to the right services, then when your systems monitoring or whatever you have pops up and says hey I have a problem on this device, then you can say hey maybe that is impacting this service or these services - but it's still only a maybe, and I've seen plenty of times where small problems mapped to supposedly more important services that aren't actually a problem, get more resources and take time away from something which has a much greater business impactg and revenue effect, but for whatever reason wasn't given a high priority in the service mapping rules file..

The best way of achieving some of the intended benefits of a CMDB is not via the CMDB, but by effective service management, which includes as a pre-requisite accurate testing of the services you provide from a service perspective - not trying to infer status and health info of services from low-level component data. There is a particularly good product out there which has capable but not overly ambitious discovery techniques, but which still relies on knowledge to give it real value and doesn't mind saying so. That product builds a service model which describes for everyone how different services are provided, whether they use discrete or shared components, and it also actively tests both the top level services and all the components, so you see instantly not just the service perspective, but if you have risk or degradation and where exactly it is. That goes across the network and all different apps and platforms. It's a form of visual CMDB if you like, but it's not got the anal qualities of a CMDB but instead has real world value and much less overhead to administer. So from one sensible approach, you have great information to share across your different IT disciplines about how services are delivered, you have effective and intelligent service monitoring, you have capacity planning capabilities and trend analysis, you can see and assess the effects of change or analyse risk of intended change, and you have a much more proactive stance of support who do occasionally see potential problems before they impact service users.

I'm not going to name the product as it would seem a shameless plug but my final point would be that many of the problems of ITIL are people problems. The ITIL CMDB and other best practice fundamentalism has turned into a gravy train for some, allowing them to milk contracts and fleece enterprises for large amounts of money when the return on investment is so low compared against the cost of implementation. To me that is a people problem, and signifies that many of us need to look more at our business values rather than thinking what we achieve in terms of IT has some sort of intrinsic value simply because it is IT.

Glad to have found this blog, it's a little like hearing an echo.

they should have stuck to process

Submitted by skeptic on Sat, 2007-03-10 04:38.

Oh thankyou for such a sensible summation. You say in a different way what is my favourite mantra: technology doesn't fix process (or people problems). it is the only time in ITIL (I think) where they introduce a technology as a fundamental part of the definition as compared to a useful accessory. they should have stuck to process.

Configuration Management is important

Submitted by steve (not verified) on Thu, 2007-03-22 15:39.

Hi Skeptic,

I read your strong statement against configuration management, whereas I would state that configuration management is the single most important thing that any project needs, and could be almost the only process that a project needs. I have real practical experience with resurrecting huge projects that have failed, so I don't start from an academically clean slate.

I would be interested in investigating whether we actually disagree, or you're using some definition of 'configuration management' from the ITIL standards. I don't know ITIL, nor do I wish to know. I don't know about a lot of other standards too, and I'm very pleased about that. My ignorance would not be noteworthy other than my status as a professional in the field that these standards are supposed to be about.

My definition of configuration management diverges at this point: "What set a CMDB apart from an ordinary asset register are the relationships, or links, that define how each CI is interconnected and interdependent with its neighbours". I would claim that it is versioning and change management of the items in the database.

I also don't care a great deal about pre-loading the database, as it is sufficient to load data in when it is used. If it's not in CM, it can be used but needs to be registered in CM. This: “the relationships, or links, that define how each CI is interconnected and interdependent with its neighbours" is bullshit. All we want is a copy of the data, to have a time and date on it.

For me, configuration management is a capture of data to answer "how, where, what" with documents in CM answering "why". Data could be on the back of an envelope, it could be a PDF of an equipment order to know how to order another one. The intent and purpose of CM is to record how to repeat the project, so that it would be possible to say "do it again".

So if we disagree, I can only offer the reality of actual projects that recovered when all other processes were stripped and CM was applied.

Steve.

it isn't a CMDB

Submitted by skeptic on Fri, 2007-03-23 01:49.

Hi Steve, and welcome.

We disagree only because of terminology.

A big part of configuration management is versioning and change management of the items in the database. A big part of CMDB is versioning and change management of the items in the database.

If there isn't also the relationships that define how each CI is interconnected and interdependent with its neighbours, it is confirguration management but it isn't a CMDB.

P.S. if you are who I think you are then you are currently studying ITIL ;-)

Multiple definitions of configuration management

Submitted by Charles T. Betz on Fri, 2007-03-23 02:10.

There are at least three definitions of configuration management:

- project configuration management (including document management, software config, source control, and all that)
- element configuration management (the management of "configurations," baselining them, controlling drift)
- enterprise configuration management (mostly what ITIL is talking about, including management of inventories and their dependencies)

I use these definitions to set ITSM direction for my organization, a US fortune 50 firm with a $1.3 bn IT budget. Much of the pain around config relates to people confusing these three very different practices. You are pretty clearly focusing on project configuration management. Skeptic has never come out against project configuration management - what he is critiquing is the monolithic enterprise CMDB concept, an idea I also find problematic.

See

here
here

Also, see

here

Charles T. Betz
http://www.erp4it.com

mapping the models

Submitted by skeptic on Fri, 2007-03-23 05:28.

Hi Charles

can you see a mapping from the three aspects of CMDB model to the four views of change model? I'm not sure if they interconnect or not...

Four views?

Submitted by Charles T. Betz on Sat, 2007-03-24 00:17.

Four views of change?

Charles T. Betz
http://www.erp4it.com

I guess a Skeptic's site shouldn't expect clairvoyance

Submitted by skeptic on Sat, 2007-03-24 01:37.

Sorry I am developing a major new initiative for the IT Skeptic, and my brains are fried. this shows how tired i am: I am refering to the four-views model that I haven't actually posted yet :-) I guess a Skeptic's site shouldn't expect clairvoyance. It is now posted

You guys have all been fooled

Submitted by ITIL Master on Thu, 2007-05-31 04:21.

Hay Skeptic, may your clouds be long and white and your sheep bleeting.

I have stood up at many industry conferences and said that the general IT community has been fooled by the vendors and industry analysts about the CMDB. The reason I say this is that they have led everyone to believe it is all about a peice of technology. In no other part of ITIL has the race to provide a peice of technology been so bitterly fought by the vendors and ably supported by the analysts.

It is not about the technology it is about the process and most organisations just forcus on the technology, blindly discovering CI's and federating data sources until they have stuck every bit of possible information in a big stinking database and then the wonder what they should do with it.

I also think people forget the purpose of the CMDB (because thats what the vendors and analysts want so they can sell stuff). It should not be there to hold everything so resist the urge to increase its scope when you do not have a handle on the Config process itself.

Oh, and do not get me started on ISO20000 when it comes to being fooled. Ask yourself how you can distil all the requirements around Change Management into little over a page and the certify against that. Well this is what they did for AS8018 and I think it is the same for ISO20000.

Love your work,

ITIL Master
The last lesson of a Master is simplicity

Thanks

Submitted by skeptic on Thu, 2007-05-31 05:04.

Thankyou Master (with distinction). May your aim be true and your holidays sabai

The Human Element

Submitted by Lite Headed on Fri, 2007-06-29 07:26.

In building a CMDB Config Management is very much in the hands of other parts of the business when obtain the required information, for example HR for contact data. When analysing the available data to check its suitability for CMDB it is often the case that it is simply not up to it. How often do you find multiple records for the same person perhaps brought about by them changing departments, perhaps there is a record in SAP but not in Exchange. When attempting to reconcile this data which record do you take as true?

When you look beyond the data you run into process (or in many cases the lack of it). So (sorry to pick on HR but the reference just flows) HR has a record of staff but takes this information from managers who either don’t have or choose not to follow a starters and leavers process. It’s a great idea to go back to the source of the data but that in itself can be blurred. The data might be ‘owned’ by one department but subject to change by another and inevitably no one takes responsibility. What this does is to expose other departments for their ill-disciplined approach to process and data management, in short a lack of effective governance. In focusing on these areas there is the inevitable backlash in that you are seen to be bringing other people’s failings to light and guess what? they refuse to cooperate. As responsibilities often lie across multiple departments there is little or no chance of escalation to demand cooperation. It seems the larger the organisation the greater the problems.

Like most things in live success or failure is down to the human element in the process chain. CMDB is a fantastic idea that would make everyone’s working day that much simpler but it’s people who inevitably let it down. So, done ITIL, done ISO 20K, getting up to speed on V3 but haven’t seen anything yet about dealing with the nut between the chair and the screen. Short of sacking people their doesn’t seem to be much of a way round it and even if we did sack people would this be picked up by the leavers process, passed into HR then into SAP then into god knows where before finding its corrupted way into the CMDB. ‘Send three and four pence, we’re going to a dance’.

a geek's fanatasy

Submitted by skeptic on Fri, 2007-06-29 08:27.

Oh so true! Thankyou for that contribution, and welcome.

The whole idea of CMDB is a geek's fanatasy, an idealist's nonsense

There is a difference between skepticism and cynicism

Submitted by Charles T. Betz on Fri, 2007-06-29 15:25.

"The whole idea of a system as large as SAP is a geek's fantasy, an idealist's nonsense."

Oh -wait a minute - what was their stock price again?

Some of these comments are crossing the line and don't seem very well informed.

Re: http://www.itskeptic.org/node/26#comment-1252 -- It's true that the history of first generation repositories and CASE (e.g. AD/Cycle) should be considered in evaluating CMDBs, but that history was (and is) not one of unmitigated failure. Factors contributing to how it all played out included things like the emergence of distributed computing, not flaws in the inherent vision. Metadata repositories remain an active market segment.

The idea that no data repository can be up to date because it relies on people to enter the data is simply misguided. It is true that human change management is often overlooked in implementing large new systems, and is usually a major failure factor (e.g. in ERP systems). But there have been enough successes that we know how to implement large, shared-data systems:

- build out a true conceptual and logical data architecture, starting with the user's universe of discourse
- understand the relationship between process and data - what processes are producing and consuming which data
- through the discipline of usability engineering, make the data entry process as painless and intuitive as possible
- close the loop on processes so that people's operational job success depends on accurate data - see http://erp4it.typepad.com/erp4it/2005/06/a_success_story.html
- develop data quality measurements (google Larry English) and correctly structure incentives for data quality
- tie the operational data to business performance management via metrics supported by a robust BI infrastructure - when those metrics are the basis of executive bonuses, data quality becomes of interest to them.

The particular pain point with CMDBs is the horrible concept of "configuration item." It's too general to map it to a process, other than the equally horrible concept of a generalized "change management" process. Neither can be operationalized as such.

You need a much more granular, subtyped concept of CI, and much more granular workflow understanding (e.g. "provision server," "release application," "build database") before you can apply the principles above; see http://erp4it.typepad.com/erp4it/2005/08/a_data_architec.html.

The other problem is products that are muddling enterprise and element configuration management together. That is a nonstarter and I think is close to the essential point Skeptic has been trying to make. See
http://erp4it.typepad.com/erp4it/2006/09/element_versus_.html,
http://erp4it.typepad.com/erp4it/2007/02/configuration_d.html and http://erp4it.typepad.com/erp4it/2007/01/the_fundamental.html.

Enough for now, I'm going on vacation.

Charles T. Betz
http://www.erp4it.com

Misguided??

Submitted by Lite Headed on Fri, 2007-06-29 18:11.

Hi Charles,

This wasn’t a pop at SAP merely using a few names of data repositories that can be sources into CMDB. In fact this blog is specifically about CMDB and the Skeptic’s point about idealistic nonsense was aimed at CMDB not SAP (I’m sure the Skepic can and probably will respond himself but I’m guessing he’s still chewing over his cornflakes in the southern hemisphere). Personally I’ve seen some horrendous data coming out of places like SAP and Active Directory and Exchange and and and …….. Mostly when you get to look into it there is often a human element that has either mistyped or failed altogether to put data in. I myself failed to use a leaving process once and as a result the leaver not only stayed in the CMDB and SAP and AD but carried on being paid for a couple of months, so a true example of human failure. We’ve said for years that computers are only as good as the people who program them, cars only go in the right direction if someone sensible is steering them and leavers processes only work if someone actually bothers to press the right buttons. There’s nothing misguided about real life experience!

I get it...

Submitted by Charles T. Betz on Fri, 2007-06-29 19:05.

I understand exactly what's being said. I'm a chief enterprise architect for IT Service Management in a US Fortune 50 company with a $2bn IT budget; my #1 priority right now is implementing an enterprise class CMDB. I've also implemented quite a bit of ERP. The similarities are striking to say the least.

Point is that being skeptical of CMDB because it is too big, monolithic, ambitious, vulnerable to human frailty, etc. overlooks that ERP systems ten and twenty times the size and complexity *do* work. They also fail spectacularly. But there *are* successes. The CMDB problem is no different. If SAP can succeed, so can a CMDB (in fact, the next generation IT systems are going to be supersets of CMDB, integrating CMDB plus service level management plus portfolio management. With that, we truly have "ERP for IT" 1.0 at least.)

The trouble with the conversations here is that participation is primarily technical. We are not getting any input from business process and data analysts who are the keys to solving large scale systems implementation problems, whether in IT, finance, HR, supply chain, or wherever.

Charles T. Betz
http://www.erp4it.com

Any project needs a business justification

Submitted by skeptic on Fri, 2007-06-29 21:56.

Any project needs a business justification. You and I have debated this point before. I don't say CMDB can't be done in the physical sense; I say it can't be done within reasonable and justifiable expenditure of money and resources. Anything is possible. We can put a man on the moon but I wouldn't advise any company do it as an advertising stunt.

Whether SAP is a justifiable project is in itself a fascinating debate - we've all seen SAP bring companies to the brink of ruin ... or over it. I never saw an SAP project run to business case projections.
But I can accept that there are organisations big enough, diverse enough and screwed enough that SAP might just return on the investment.

But to say it justifies CMDB is like saying that because DHL own their own jumbos, Mana Transport (the ten-truck company down the road from me) should buy one too. No that's not right. It's like saying that because DHL use jumbos to move product, DHL should also use them to g