How long can they beat the CMDB drum? What is the next fad?
CMDB can't be done - not with a reasonable investment of resources. But not to hear the vendors (of software and consulting) tell it.
I have summarised my views on this in a recent ITSMWatch article. The pursuit of CMDB as defined by ITIL is an irresponsible use of money except in organisations that must get to Level 5 maturity in Configuration Management for competitive or risk mitigation reasons.
The vendors and analysts are very practiced now at whipping the IT industry into a frenzy over some new fad: Web 2.0, SOA, CMDB... And we keep on getting suckered that technology wil fix our people- and process-problems.
Buying a CMDB to fix Service Management makes as much sense as buying a Playstation to fix a boy's behavioural problems. Technology is not the answer
I'm wondering how long this CMDB game can be played. Pretty soon they’ll saturate the CMDB market and/or there will be a backlash as the failed projects and wasted dollars pile too high to ignore, then they’ll beat a different drum and the wild cavort starts all over again. What will be the next IT operations product du jour? The IT Swami picks Governance Dashboards or Scorecards, with the long odds on Service Level Management (realtime monitoring and alerting) and/or Service Provisioning (online Service Catalogue / SLA shopping carts). Of course we can fix governance and compliance by buying tools.
Made in New Zealand 
Comments
CMDB (aka The light on the hill)
Although I believe that the implementation of a CMDB is a fantastic aspirational goal, akin to politicians wanting full employment, it is one that should be approached carefully and with an eye on the end game. That endgame should be what works best for the organisation.
Having spent almost all of my career in the IT ivory tower, I have spent the last two years in Sourcing specialising in IT & T procurement. The one fascinating thing I have seen is IT's propensity to peddle its own case at the expense of the business, spending money on things that are at best outsourced and add absolutely no benefit to the bottom line. As I become more disillusioned with the ability of IT to align itself with the Business, the business sees this as IT believing it is in some way part of the revenue gathering activities of the firm rather than a service functions that enables the revenue gathering activities.
To that end, will a CMDB when implemented in any of its guises send any money to the bottom line or enable the firm to sell a few more widgets, or acquire a few more customers to sell a few more widgets to. Any thing else fails to seed benefit or a return on money invested. To put it more simply, a TV station would rather spend $100K on a new camera than spend $30K on an IT service, when you understand that you understand the way your masters think.
VaioBoy
Won't drive top line, may drive bottom line
CMDB won't drive top line revenue, but it may drive bottom line profit. IT cost avoidance is a valid business case, one that I have successfully made for CMDBs. The non-financial balanced scorecard objectives (process view, customer satisfaction, talent management) are also valid - especially with respect to service availability, which often cannot be represented as a financial goal. (And yes, I have heard that balanced scorecard is also becoming passe; let me know when something better for representing intangibles comes along.)
There is nothing fantastic or ivory tower about a CMDB. CMDB is simply a logical incremental step past an Asset system. Why are we turning it into this monster to be slain? It's just a question of properly scoping and designing some data and system architectures to support a business process (the IT service lifecycle itself, in this case).
The simple fact is that when IT operations are large enough they require their own supporting infrastructure, just like HR, Finance, Legal, Contracts, or any other back-office overhead function. I'm sure you've seen a number of vendor, contract, and asset management databases; those are the IT systems most closely associated with sourcing (along with the project management system in many cases). Are these systems mere IT playthings? What happens when you have 500 vendors selling you 4000 software products and expecting you to manage the licenses, or else you'll get a call from the BSA?
And the CMDB *is* relevant to such things. A simple Asset database tells you that you have 200 Oracle licenses. But when (e.g.) Oracle 9 goes off support, you still have to scramble and go figure out what systems are dependent on those licenses. The CMDB, if correctly implemented, tells you this with a report.
The main problem is that, even in the wake of ITIL v3's call for a "Configuration Management System," and much discussion around the concept of federation, the discussions on this board still view the CMDB as a monolithic entity. See this post, which is just a taste of chapter 4 in my book. You'll find 78 vendor-neutral pages there discussing the various types of internal IT systems supporting service strategy, design, implementation, transition, and operations, as well as how they need to be integrated in support of the IT value chain.
If IT is prioritizing its own needs as a whole at the expense of the business, a big part of this is the purchase of redundant, non-integrated technology by operations, security, portfolio management, enterprise architecture, vendor management, and other teams. See A Story of Too Many Tools. I'm much more concerned about these dynamics, which arguably a centralized CMDB can help mitigate.
Charles T. Betz
http://www.erp4it.com
ITIL plays to the same
ITIL plays to the same appeal that makes communism sound so good in theory. Cenralised management of change/Centrally planned economies. You are trying to make a broken model work because your intuition and taylorist upbringing make you believe. Not because of any empirical evidence to the contrary.
Flawed analogy
To be a bit of a stickler ... your analogy doesn't hold. Big and centrally controlled economies can and do work. Just ask General Motors and China, for example. It was precisely this economic riddle which led Ronald Coase to the idea of transaction costs ... and the Nobel Prize.
And ITIL has distinctly evolved from Taylorism and the warmed up Scientific Management of V2. Mr. Taylor would have burst a vein at the implications of the service lifecycle: There really is no "one best way."
I also seem to recall a nice post on this board about the perils and paradox of empirical evidence...
Its good to have a stretch goal
I can see no problem in pushing the CMDB concept, and long as nobody takes it too much to heart and foolishly tries to implement the damn thing.. At least not with the current state of CMDB products.. I haven't seen many organizations implement a unified data model for across internal customer and organization data. IT Service Management data and the infrastructure supporting it is infinitely more complex as for every data field defined in a application there must be 100's of possible CI's..
My golden rule is to use the concept provided by ITIL as a template for guidance and execute based on a real problem and measured goal. Utopia views and the software vendors who tell you they can execute will soon get back to reality if you manage to do that..
As always, I discussed CMDB's in my blog a little while ago..
http://blogs.sun.com/buraddo/entry/cmdb_six_degrees_of_separation
Walking the tightrope
Gentlemen,
Rather than watching your always interesting discussions from the sidelines as I usually do I'm going to contribute to the debate.
By opting for a CMDB you opt for change. Existing processes which define the IT Service to the business will need to be changed in order to utilise the CMDB otherwise the data will become out of date, meaningless and create problems rather than solve them. Process change affects people and this takes careful planning and implementation if it is to succeed. It provides a huge opportunity for failure should it not be delivered effectively.
On that note, it is worth pointing out that a CMDB is focused firmly on IT, not business. Sure there are some business benefits to be gained, but only as a consequence of CMDB implementation forcing change on the management and delivery of IT. The great hope is that these changes will improve IT service, consequentially allowing IT delivery to become something that "just works", allowing IT to have more constructive conversations with the business.
But, you are walking a tightrope with very little in the way of a safety net. Fail and you risk heading for an expensive fall, causing the rift between business and IT to widen even further.
My blog, "Are CMDBs worth the trouble?", at www.keystonesandrivets.com discusses this in more detail. You may also be interested in my assertion that "IT exists for one reason."
Agreed..
Regardless of the money spent, the consultants engaged, and the technology purchased, if an organization lacks operational and managerial discipline, they will not perform well.
Not always true
Operational and managerial discipline may seem like a truism but management thinking has come to understand this is not always the case. It may sound counterintuitive but there are even situations where it leads to failure. You can find a few of the reasons (with case examples) examined in Clay Christenson's Innovator's Dilemma.
Asset Management comes before Service Catalog
In your ITSMwatch article you recommend starting with a Service Catalog - before Asset Management. I disagree. It wouldn't be much of a catalog if prices aren't reasonable - sort of like a restaurant menu with prices being a surprise!
More than half of IT costs come from asset costs. And, most labor costs are associated with ongoing asset maintenance - only around 20% of labor costs are development related. It would seem that getting fundamental asset management processes and costs in line are conditions precedent to a catalog.
Of course, running the IT shop like a real business would require a detailed understanding of cost components - just as it does in any kind of business.
Service Catalogue is one of the first things you should do
There are several kinds of Service Catalogue: brochure, internal technical spec, menu.
I would guess that about one percent of sites can actually put a price on a Service (or more precisely on a Service Level): that represents the highest level of maturity of Service Delivery. Charging for/by a service requires the ability to allocate or at least estimate costs, and the ability to measure and report accurately to the mutual satisfaction of both parties. Finally you better be able to deliver to it and to knowyou can before you lead with the chin by charging by service.
Service Catalogue starts with a simple list of definitions of the Services delivered. If you can't write that down you can't do Service Management, pretty much. Once you do write it down, it focuses people's minds and gets them talking the language of service. Service Catalogue is one of the first things you should do.
I don't have strong views about which comes first, asset management or service catalogue: both are pretty important. My personal preference is to get a Catalogue out there but then I'ma top-down kinda guy. A bottom-up person might well do asset sooner.
Not really talking about charging back
Achieving an understanding of constituent costs does not mean charging back.
Actually, not understanding the basic costs of a service appears worse to those outside IT when one takes a top-down approach.
IT likes to excuse their inefficient spendthrift ways by hiding behind the studied, purposeful ignorance of cost components. IT can never get respect from the other corporate functions as long as it hides behind the "percent increase from last year" approach.
Only in IT can one produce a very expensive product and expect not to justify it. By comparison, can you imagine anyone in manufacturing not understanding the component costs of their products?
Small wonder, then, that outsourcing and SaaS will continue to increase and that the trend to having the CIO report to the CFO continues to increase.
IT costing
".........that the trend to having the CIO report to the CFO continues to increase"
A little correction is in place. IT reporting into CFO stemms from early days computing where the bookkeeping -and later other accounting- functions were the first to be "automated". The CFO, no insight in computers and programming, was easily convinced that the requested budget was necessary as long as his books were in order and up to date. In those days, most senior managers would be proud to state that they "don not understand a thing about computers and programming".
I think that IT has grown up and is more cost conscious. However, in many organisations, the outdated reporting lines still exist. Many CIO's feel comfortable sitting close to the trough as a proposal approved by the CFO is most likely to make it unchallenged through the Board meeting. The CFO is happy as he is seen to control a much larger budget than he otherwise would have. Many CEO's seem not to understand the games played under their noses.
progress of cio's as trusted businessmen
Nick Carr disagrees:
http://www.roughtype.com/archives/2007/10/twilight_of_the.php
And, the most recent CIO mag survey reveals that only 42% of CIOs report to the CEO.
If IT wants to get respect from the rest of the business, then IT must start to run itself like a business. Businesses make an effort to know where their materials costs come from and what the cost of their products are. Those that ignore IT financial management and IT asset management (assets and their associated account for more than half the costs) do so at their own career risk.
Fewer CIOs are reporting to CEOs
Fewer CIOs Are Reporting to CEOs, Survey Finds
http://www.baselinemag.com/article2/0,1540,2193506,00.asp?kc=BLBLTEMNL10...
Aligning IT and the business, which has been a major challenge for CIOs for more than a decade, was No. 2 on this year's list—as it was last year.
And what was #1?
The talent pipeline.
There is some CMDB value to be found in considering the impending mass exodus of qualified personnel from the workforce... not a panacea, but perhaps at least a framework. Those who advocate the "human CMDB" point of view - will we even be able to hire enough of them?
Charles T. Betz
http://www.erp4it.com
The IT Swami predicts an influx of Filipinos and Indians
Good point, but a problem that applies across IT, not to CMDB alone, so however we do CMDB we will still need to address the people shortage.
The IT Swami predicts an influx of Filipinos and Indians. These English-speaking, hard working, obedient university graduates are about to give the spoilt self-indulgent Gen-X and Gen-Y brats a fright, just as soon as the Western nations buckle under and give up our racist immigration policies before our economies crumble.
In the industrial age we sucked out the third world's primary resources. In the information age we'll suck out their best and brightest.
Having onboarded many
Having on-boarded many staff from various backgrounds, I firmly believe in the value of CMDB-type tools (in their guise as Service Knowledge Management enablers) to get these people bootstrapped and productive. I'd rather not have them figure out the environment from scratch.
Charles T. Betz
http://www.erp4it.com
I don't see this trend
I don't see this trend abating. Personally, I think CIOs (generally) brought this upon themselves. Particularly in the manner by which they define their roles. The list of priorities in the article was particularly telling (Biz/IT alignment, Staffing, Antivirus protection, networks, BPM, continuity planning and disaster recovery)
Notice a pattern?
Hint: I notice a resurgence in the CTO. My personal observations have them reporting increasingly more often to the CEO.
Lots of Changes
I've seen more than a few such realignments in a number of the customers I work with.
In at least two I can think of, the departure of a CIO (immediately prior, for various reasons) was closely followed by the change in reporting structure to the CFO. In each case, I know that the CFO's were fans of the cost center approach than other alternatives.
I think the heads of IT organizations are still far from getting the point about the connection to finance and it shows. The connection to value isn't being made... and IT pays a high price for that. Until this is addressed, I believe we're going to see this trend continue.
that degree of financial management
Whether it is charged back or no, that degree of financial management is not what i am talking about with an early catalogue - I meant a simple list of services. I advocate to clients that they do NOT take that list to the customer(s): it is intended as a rallying banner for IT Staff. (It should be exposed to the customers only once you have some idea what is actually deliverable and measurable in service terms. And there should not be price tags until that financial sophistication of costing - activity or component - is achieved)
CMDB maturity model
Why don't you academics do something useful and create some sort of guide or what I think as a maturity model for CMDB for us practioners trying to decide where to draw the line between what ITIL says (every CI, every relationship - the stuff that can't be done) and the real world practicalities need to support our ITSM effort?
In my book
My book analyzes the problem of configuration management in detail from the perspectives of process, data, and systems architectures. I propose a configuration management maturity model on pages 66-67. Page 196-199 propose an iterative and incremental approach to configuration management, consistent with the maturity model. Page 320-356 discuss a variety of process, data, and system techniques (framed as "design patterns") to facilitate configuration management success.
BTW, I am not an academic; I am a practitioner.
Charles T. Betz
http://www.erp4it.com
ok Charlie I bought your
ok Charlie I bought your book (been meaning to for awhile). COnfig maturity model looks good, I will expand on it for use internally, thanks alot.
excellent book btw, haven't read it all just yet, but impressed so far. Only shortcoming (and maybe I just didn't get to it yet) is coverage of the practical side of aligning time accounting with resource planning stuff
Amen.
Amen. Zero based budgeting would be a completely foreign concept to most shops. The IT portfolio management literature is starting to address some of these issues; in the vendor space I would keep an eye on Lontra and Seaquation. An academic to watch is Chris Verhoef, who recently chaired the IEEE Equity conference, perhaps the most relevant conference to enterprise IT service management to emerge from academia.
In defense of IT budgeting, I would note that achieving credible IT cost accounting is a non-trivial problem at scale. I have talked to no peer who seems at all satisfied with their IT shop's approach to cost accounting and recovery.
We don't have the tools, the practices, or even completely satisfactory theoretical frameworks; activity based costing seems to be the way to go, but has some limitations. In order to make it really work, the resource inputs (software, hardware, staff effort) would need to be more consolidated than I see practiced today, the definition of the "activities" used needs BPM-type rigor, and the IT unit needs some flexibility to truly "run as a business."
My belief is that CMDB inventories and dependencies are needed because, in addition to their operational utility, they also serve as the bill of materials for the IT services. Why would you want to maintain such allocations in multiple systems? Yet, how many readers use CMDB as a direct input to IT Finance?
Charles T. Betz
http://www.erp4it.com
It this a chicken or egg discusion
I agree that the Service Catalogue would be one of the first things to do. At least as part of the dialogue with the customer on what service he wants/expects and what is possible. In order to deliver a service I need to know more on a general level what is available (in stock), than on a detailed level. Comparing IT service delivery to a restaurant: the menu should contain dishes (Service Catalogue) and not individual ingredients (CMDB). And it would be even better when the customer can order the Chef's Suprise: a dish made out of what is available and the customer personal taste or distaste.
Of course it is a good idea to have some kind of overview on the available and used assets, but that is an internal IT issue. I can create a CMDB from a Service Catalogue, but it will not be good idea to create a Service Catalogue from a CMDB. In this case the bottom-up person will get stuck in the details and will have lost his customer before he gets out.
In the discussion what comes first, Service Catalogue or CMDB, my choice is clear. The chicken or egg discussion is also put to an end by sending a chicken and an egg from Sidney to New York. The Chicken was first.
the Catalogue describes what comes out of the pipe
Many things in ITIL bootstrap or iterate their way into existence. Change needs Config needs Change, so we do them in parallel. I don't think the same is true of CMDB and Catalogue though. A Catalogue defines the Services. The Services can and should (eventually) be defined in the CMDB and linked to some underlying components but the Catalogue exists in isolation. To use my favourite analogy, the Catalogue describes what comes out of the pipe, not what machinery was required to create it and deliver it there. I can describe what is coming out of the pipe in cheerful ignorance of how that is happening (within limits, but you get my point I hope).
CMDB is essential and isn't going away
There's plenty of business case for CMDB and it isn't going away.
Past rants:
"Why should we track all our income and expenses on some piece of papyrus? I do just fine heaping all my money in a big counting house and posting armed guards at the door! Can't be done, at least not with a reasonable investment of resources."
"Why should we track the names of all our workers in some filing system? We give them their piece of silver at the end of every day! Can't be done, at least not with a reasonable investment of resources."
"Why should we track all our deliveries and sales of goods? I do fine just keeping my eyes on the shelves. Can't be done, at least not with a reasonable investment of resources."
"Wny should we track all the parts and pieces of our manufactured goods on blueprints? I know how they fit together and so do my workers. Can't be done, at least not with a reasonable investment of resources."
I just got back from ITSMF 2007 and the leading edge discussion in CMDB is not whether or not it's needed; there was general consensus we need to manage internal IT data better. The discussion is much more nuanced, around scope, maintenance process, ROI, and data architecture.
It can be done iteratively and incrementally, and I talked to multiple folks who have come to the same conclusion as me: it starts with application to database to server dependency mapping. Getting that data collected, maintained, and tied to the Change and Incident/Problem processes is *not* that expensive and has very clear benefits in availability and cost avoidance of redundant re-surveying.
Also, the element versus enterprise configuration management distinction is becoming widely accepted; people realize that the tool managing server parameters is not the same tool managing IT interdependencies.
Charles T. Betz
http://www.erp4it.com
I've never said Configuration Management can't be done
Hey Charles, we're going full circle on this one. I've never said Configuration Management can't be done, or shouldn't be done. I'm busy doing some myself. It's important. My contention is that a CMDB as defined by ITIL books as a full record of all CIs that support all services and all their interdependencies including the logical non-discoverable relationships to SLAs, owners and services can't and shouldn't be done.
I'm not trying to talk people out of tracking assets or key dependencies. I'm trying to talk them out of
a) chasing this idealised solution that has to be complete to be correct
b) falling for the silver bullet solution that CMDB technology somehow equates to Configuration process: the "if we could just store it, all our problems would be solved" mindset
My article ends up with
Two ends
Aren't there two ends to this spectrum? The first, as you called out, is the point where the search for perfection burns more investment than is returned. The other is where the level of CMDB quality is low enough that its use does more harm than good.
The question then becomes what is the minimum level of effectiveness required in order for a CMDB to be a worthwhile pursuit. A CMDB for a CMDBs sake is certainly not an answer.
I'm also curious about the support for tying a CMDB "...to the Change and Incident/Problem processes is *not* that expensive and has very clear benefits in availability and cost avoidance of redundant re-surveying."
Not saying its not true. Though I'm not sure a CMDB eliminates re-surveying. If the level of effectiveness is not high enough, even the costs of redundant re-surveying are back in the picture.
I'd just like to see the evidence on one side or the other. Maybe then this argument would have some substance.
The law of available data
Alas. I wish I could oblige on the evidentiary front, but we run into the perennial problem of client confidentiality. You have two choices: dismiss my statements out of hand, or attempt some cautious, incremental verification of the general principles I propose.
Charles T. Betz
http://www.erp4it.com
A CMDB-tree falls in the woods...
So we are back where we started, stabbing in the dark by the light of subjective statements.
I find no comfort with the iterative approach. Like most projects, process or tool based, there is only so much runway in which to show the new way is better than the old. If the effectiveness of the CMDB does meet the right level by a certain point, it becomes yet another failed intiative. Once confidence is lost, it is about impossible to regain. And if staff shy away from using the CMDB, then it doesn't matter what my next iterations accomplish. No one will be around to pay attention.
So don't fail
How is this problem different from other systems development initiatives? Don't fail with your first iteration. Find a problem that is well-scoped and solveable. Get competent people and execute. And don't even try without solid leadership backing.
In my experience, the runway has elasticity as long as you don't crash the plane by 1) oversetting expectations or 2) failing to execute.
Charles T. Betz
http://www.erp4it.com
System development
System development initiatives usually don't get off the ground without objective goals. If the observed results meet or exceed those goals, then the project is a success.
I'm struggling to define the level of success for a CMDB. "So don't fail." I sense a Dilbert cartoon somewhere in there.
"Don't fail with your first iteration." Where should that first iteration aim?
Does a CMDB have to be 20%, 80% or 99.999% effective in order to improve matters? In the absence of such criteria the project has to shoot for perfection, a situation sure to agitate the Skeptic.
Using a CMDB which only encompasses apps/DBs/servers doesn't seem realistic. Staff won't use it because they've got more reliable excel spreadsheets. It then becomes a pretty toy. It is not enough to offer an impact analysis capability, it has to offer a capability *better* than the existing way. If my target aim falls short of that level - no matter the competency of staff or executive support - then it will be seen as a foolhardy tool. Without a target, I have no choice but to do it 100%.
I guess that's the crux of my concern. I know when my other tools improve matters (e.g. monitoring tools). How do I know, beforehand, when my CMDB is worth it?
Or am I utterly confused?
know yourself 1st...
I've had this rant before in CMDB Kool-Aid can result in a Bad Trip so I won't spew too much more other than to say if you're not sure how effective your 'CMDB' needs to be to improve matters then look in other areas!
Personally, I agree with you that monitoring tools should be more of a focus of conversation. I'm continuing to use a tool that collects measurements from every layer of every component in an n-tier infrastructure (ERP, Citrix, VMware, whatever), learns the norms of all collected metrics, and automatically isolates which layer of which component is the source of the anomaly. It also has a unique web based architecture that provides personalized views for each domain, and can be quite effective in that nasty paradigm shift people need to make (whether they want to or not)...
The vendor really doesn't care about ITIL (they're not much into marketing), but from what I continue to see this is an area customers may want to look into. If it's not an ITIL-based 'CMDB' then maybe (horrors!) I don't need one...
Some of the big gorillas have put a big toe in these waters, but in their quest for ITSM nirvana I'm afraid that the 'integration' they seek will dilute these benefits to the point of, well, missing the point...
I feel better now.
John M. Worthington
MyServiceMonitor, LLC
Targets
I'm a bit concerned about the way you've framed the question, which (if I can boil it down) seems to argue that CMDB is either trivial or unattainable. There is a middle ground of worthwhile work.
Spreadsheets are problematic, because they don't support many to many or recursive relationships, and usually allow unconstrained data entry rather than enforcing data domains (e.g. predefined picklists). (See pages 208-212 in my book for a very detailed case study.) You'll find that at scale many application and infrastructure teams start to build redundant little MSSQL/MySQL databases characterized by the following major entities:
Application
Database/Datastore
Server/Host
Machine
Component
Service
Cabinet/Rack
Business Function
Business Process
Queue
LPAR
Region
Subsystem
and a host of intersection entities to relate them. Such systems (of which I have easily seen a dozen across a number of large organizations with a combined total IT spend of $3 billion) are often duplicative (the server team has one, the DBAs have one, and the application engineers have one, each with slightly different focus and overlapping data). And, they are generally NOT tied to the incident or change processes. That is the opportunity for CMDB.
What are some measurable objectives?
- Reduce/eliminate unsuccessful changes where the lack of success can be attributed to poor impact analysis. This of course means you need to do some analysis of your unsuccessful changes and figure out whether a significant proportion is due to poor impact analysis. Identifying changes to chronically troubled CIs, and overlapping changes to the same or closely related CIs, are some of the benefits.
- Reduce time to recovery where the outage is prolonged by inability to identify upstream contributors to the incident, or identify needed SMEs. Again, you need a baseline to determine if there is ROI there.
- Support higher-order objectives such as capacity and financial management. This boils down to "are they using my data?" If so, you have a clear business benefit to report. The ROI can be measured by assuming that without the CMDB, they would have to maintain the data on their own, and application portfolio satisfaction measures can and should be applied ongoing to ensure the CMDB system continues to provide utility.
- Redundant re-surveying. Go and ask your application teams how many spreadsheets came across email that they were asked to fill, starting from a blank template. Then go to the project managers that drove those spreadsheets (compliance, server consolidation, data protection, etc) and estimate how much they spent on that research. Right there is a business case. At a higher level, you can do a sort of wideband Delphi: ask your senior execs to estimate how many applications there are, and for each application, how many hours per year are wasted in capturing data that was once understood - then average their estimates. If the Wisdom of Crowds thesis is correct, you've got a reasonable cost avoidance case right there.
There is also a master data management problem at issue when spreadsheets or redundant databases are allowed to proliferate, and definite benefit in solving it if you want consistent reporting across the IT organization. Talk to your local business intelligence/data warehousing professional.
Skeptic and I disagree on some issues here, but one thing we do agree on is that CMDB is probably only worthwhile for larger shops, I would say at least $50-100M IT spend a year, if not much more. Fortune 1000, at least. Smaller than that, and perhaps the spreadsheets are OK. Larger shops, highly regulated shops, or highly distributed shops need something more robust.
Charles T. Betz
http://www.erp4it.com
Keep going!
Visitor,
I like the direction you're going and encourage you to keep going. If the construction of your CMDB initiative doesn't clearly establish value, you're likely to be left with just another stale data source.
In your last post, you write:
"Using a CMDB which only encompasses apps/DBs/servers doesn't seem realistic. Staff won't use it because they've got more reliable excel spreadsheets. It then becomes a pretty toy. It is not enough to offer an impact analysis capability, it has to offer a capability *better* than the existing way. If my target aim falls short of that level - no matter the competency of staff or executive support - then it will be seen as a foolhardy tool. Without a target, I have no choice but to do it 100%."
In a way, it seems you're answering your own question. It very well may be that for your unique circumstances, what you have is sufficient for right now.
My two cents:
1. I'd vote for a first (next?) iteration that was tied to what's needed to "get the job done", whatever that looks like in your organization. There's some work to do on your part to get there. Based upon that work, have whatever collection of data makes sense for that.
2. How do you know if it makes sense? Well, I'd attempt to do some sort of table top simulation/exercise that will help you "smoke test" it and see if it holds together well. Does it help you answers the questions you need answers to? If not, it's likely that you've identified a significant gap to address before moving forward.
kengon
Skeptic or Cynic?
"Of course we can fix governance and compliance by buying tools." does not sound skeptic any more. You just took a door a few steps further down the corridor labled "cynic".
You can already see a few of the Swami predictions. Having a personal SLA chart in newer IT Service Management tools is already quite common. But hey, why should this stop? It is much easier to buy some new software than to start thinking for yourself, so upper management will always get the tool "solution". I mean this tool is endorsed by a large organisation, so that must be good value (I ask "for whom"?). It is much easier explained in short term project memory that we implemented a new tool, as to explain we have to change our behaviour, our way of doing things and our style (the way we agree on deals) in a long running project where there is no big company that will be taking the blame if it goes wrong?
Well, welcome to the land of the cynics!
Guilty
Guilty. I am indeed cynical about vendors' predilection for flogging technology silver bullet solutions to systemic problems, and about our weakness for falling for it.
Modelling tools for crappy systems design
Dashboards for bad decision making
Prisons for crime
Things don't fix people.