ITIL’s dead elephant: CMDB can't be done
Note: this is the original "dead elephant" post from back in 2006. My thinking about CMDB has matured since then. Please see the articles (and book) in the sidebar of this article for a more complete picture of how I now see CMDB, and a much wider range of ideas why CMDB or CMS is - for most organisations - a bad idea.
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.
Get the book:The IT Skeptic Looks at CMDB
Available as a digital download for $7.95 or as a traditional book for $9.95+p&p, this book asks the hard questions about CMDB, summarises why it is generally not a good idea, and looks at the alternatives.
My thinking on this has evolved over time. Don't stop with this old post (2006).
See also numerous other posts on CMDB including:
- How to improve your service configuration data and what that means for CMDB
- The Five Percent Club who need a CMDB
- CMDB: what does it really mean
Other posts on this blog you may also be interested in:
- The value of CMDB seldom exceeds the cost of doing it
- "On Demand CMDB" - Configuration is about process not tools
- What do all the sites without a CMDB do? Fallacies behind CMDB arguments
- Live without CMDB
- Top 10 reasons NOT to implement CMDB
- The CMDB boundary problem: stop chasing this technological rainbow of a unified CMDB repository
- Get it straight: CMDB can not be auto-discovered
- Don't fall for the demo: an asset database with bells and whistles is not a CMDB
- Technology does not fix process
Read all on CMDB from this blog
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.
If you found this post useful, and you are a Facebook user, please Like the IT Skeptic on facebook
References:
- 1 An Introductory Overview of ITIL, itSMF, 2004
- 2 Demystifying The CMDB, Andrew Conry-Murray, IT Architect, 8/01/2005
- 3 CMDB or Configuration Database: Know the Difference, Gartner RAS Core Research Note G00137125, Ronni J. Colville, 13 March 2006
- 4 The jury's in on the CMDB - or is it? CMDB adoption in the real world, Network/Systems Management Newsletter, Dennis Drogseth, Network World, 05/29/06
Made in New Zealand 
Comments
CMDB Federated or non-Federated
Interesting point of view on the Remedy CMDB comparing it to how ITIL talks about it. The biggest rock in the road that I have found is; should it be federated, or not? I've always positioned myself on the federated side of the fence, and looked at various other tools instead of just depending on Auto Discovery to pull the whole picture together. However, I had a nice discussion with an old school Configuration Manager the other day that believes that the CMDB should be just a repository of data that would only change by going through the Change process. I feel that this is a dangerous position to hold since you are depending on every minor/standard change will actually be submitted into the system and update the baseline. And, it would be detrimental to the repository the moment someone goes around the system. However, I have to also ask myself should Remedy be a real time monitoring tool? I've conceded that the answer is No!, but using external interfaces into equipment to retrieve current data when needed is better than looking at the old data that is stored. The compromise is that there are a bunch of other tools available that can monitor real world changes, and some of them can actually auto generate TTs when needed. The Incident Module seems to be the primary module that kicks off a lot of our action in the back shops, but overall the inter-relationship of any of the inputs to the many different processes should affect multiple stones to roll. And, it shouldn't matter if it's an auto input, or a manual input, the more data available to the user, the better decisions can be made.
non-discoverable CMDB
Hi Lonnie (Kiwi Lonnie?)
Configuration data (let's avoid "CMDB" for now as a particular instance of Configuration data) is often updated automatically because it is integral to some underlying system, e.g network or server monitoring. That's all good.
There is a bunch of CMDB or Asset data that can't be captured by anything but the Change process because it is not technical data: who owns this? what business services are impacted? what's the SLA on this new equipment?
In theory your change process should be able to capture all configuration data. In practice as you say subversion spoils that. Auto-discovery can either capture configuration data realtime or audit the data after the fact to find inconsistencies. I think that's a design decision based on the tools.
Neither way will ever discover all CMDB data, and you are reliant on Change process to capture all the non-technical data.
And that non-discoverable data is the most important in a CMDB. Configuration data is used for all sorts of things such as asset management and lookup data for a wide range of practices and tools, but CMDB data in particular is there to do impact analysis on services of incidents and changes. CMDB is all about decomposition of services. And you don't populate that stuff anywhere but from a human filing a Change.
Change process is insufficient for CMDB maintenance.
In the CMDB implementations I've been involved with, the Change process has proved itself insufficient for CMDB maintenance. We found that we needed a dedicated Application Registration process to identify and track these important CIs, which often needed to be in the CMDB well before any formal RFC. (RFCs were seen relatively late in the game in these shops, a not uncommon approach.) Linking servers to those applications was best handled via the provisioning service request, which would be linked to a Change but was not the same as the Change.
The trouble from a pragmatic process point of view was that most Change requests did not require any CMDB changes, so you couldn't enforce a business rule requiring CMDB update, and people participating in the Change process (which had too many checkboxes as it was) would get used to just skipping that question.
Charles T. Betz
http://www.erp4it.com
http://blogs.enterprisemanagement.com/charlesbetz/
all part
Clearly you had multiple tools for the Change
processpractice, one of which was called the Application Registration tool. But I submit it was all part of the Change practice, just as i think autodiscovery tools are part of automating the Change practice too. Just because a form (or repository) has the label "Change" on it and another has "Application" doesn't mean they aren't all part of the Change practice.What will the future hold?
Many decade ago when personal computers first became available, as in Apple ][ an S-100 machines - aka before the IBM PC - I dreamt of putting my collection of books into a database: title, author, publisher, synopsis, comments. However it was a duanting task, so may books! I'd have to give up reading them to get the job done!
But now there's Amazon and databases I can refer to ... only so many of my books are from pre ISBN days ... old 'pulp' magazines and ancient first editions.
Perhaps one day all IT assets will come with RFID tags and to to build an CMDB you will just have to point your RFID scanner wand at them. Imagine that, crawling under desks and lifting ceiling tiles to get line-of-sight on some piece of equipment, consulting the old purchase records ... And of course there will be non-compliant vendors and devices that aren't in the reference database.
Do you really think that vendors and manufacturers will suddenly make life easy for us?
A list is just a list
Anton, you are falling into that same old trap! An asset database is not a CMDB. No barcode can tell you what Service this asset is going to support, or how it affects service levels. Nor can it tell you who it's business owner is or what continuity plan or availability plan it participates in. A CMDB is all about the configuration i.e. the inter-relationships between CIs. A list is just a list, no matter how high tech.
Feeling Somewhat Listless
"We hold these truths to be self-evident..."
As a mere novice with only 21 years experience working for numerous organisations - from multinationals to two-man bands - I can honestly say I have only ever seen asset registers.
I have been promised CMDB's but on closer inspection, they have invariably been asset registers.
I see (well I don't actually) Monsters
As a wise man once said to me “A CMDB is like the Lock Ness Monster……. Often spoken about but never seen….”
colossal squid
More like a colossal squid: rarely scene and a bad idea when they are
Clarification
I would like to dd one more point if you think updating CMDB is a pain then your problem is with iscovery tools and not with CMDB. I think ITILv3 separates Discovery from CMDB (I may be wrong, But I will check and confirm).
discovery
If you think discovery eases the pain of maintaining CMDB then you don't understand CMDB.
Autodiscovery doesn't tell us what we need to know. Get it straight: CMDB can not be auto-discovered
But more importantly, using discovery to update CMDB is a violation of basic change control. All changes to config data should come to us from the change management process. The whole point of change management is to know about and approve them beforehand, not to run around after the cowboys to desperately try to work out what they are doing to the environment by discovering it every day. Service Transition avoids offending powerful vendors by quietly saying this. See page 69, section 4.3.4.3 "These tools can be used to populate a CMDB, and subsequently to compare the actual live configuration with the information and records stored in the CMS" NOT to directly update the content. Or on page 195, section 7.3 "All changes should be recorded on the CMS by the time the change is implemented... Automating the initial discovery and configuration audits [not anything else]...."
Discovery is only useful on the edge of configuration. Auto-discovery is very useful where initial data is rubbish: it is good for helping get a baseline set of CIs. If your Change processes are any good then you don't need it after that, though you can use it to audit data quality and detect non-compliance. Don't fall for this vendor silver-bullet crap.
Amen
I wish I could say I have only had this conversation a few thousand times. My argument though is slightly different but augments what you say. Discovery doesn't discover some of the most important attributes in the CMS ~ namely those attributes that simply are not discoverable.. (ie. Where it is physically located, who supports it, who administers it, who can change it, etc.). While discoverable information is 'sometimes' used for incident, change, problem and other processes, these other attributes are almost always used.
JMC
Even fingerprinting doesn't work
For the past couple years I have had the following conversation with eager discovery tool vendors:
V: Our tool autopopulates your CMDB!
Me: What about our custom apps?
V: Well, you have to create fingerprints for them. Then you're golden.
Me: Tell me more.
V: Your custom app is CTBCustApp.exe; that's the name of the binary & the process in the process table. It runs on port 12784. Just configure the discovery tool and it will discover that app wherever it is running!
Me: OK. Of course, that executable is only one of a number of components of that app... we have a database too.
V: Our software discovers that
Me: Well, the software talks to 5 databases. But only one database server is "owned" by the app. We need to understand that for chargeback.
V: Hm.
Me: Also we've got a batch server, I suppose we could fingerprint those processes but they only run periodically.
V: Hm.
Me: And here's the biggie, this other business unit saw the app and loved it, but they didn't want to partner with us on the service. So we gave them the code and they have their own instance. Same file, process, and port. But different customer, SLA, & hosting infrastructure. Sounds to me like all their stuff will start showing up under my app...
V: Hm.
And so it goes. The discovery vendors pretty much leave my office with their tails between their legs. Haven't heard a compelling story yet.
Except in the case of software asset management. There, discovery is helpful. But that's asset management, not configuration management.
Charlie
Charles T. Betz
http://www.erp4it.com
not reality
Right on Charles! Discovery, BPM, CMDB, impact analysis, traffic analysis, neural networks.... they all work beautifully on Powerpoint. As I said previously "If it runs on a single PC in a vendor demo it is not reality".
How about four services delivered by load balancing across seven web servers? What constitutes "broken"?
What about Web Services deployed using UDDI, across a middleware bus?
What about Cloud storage? or cloud CPU processing?
Great post thanks! You should talk to my EA friend Alan Mayo who did exactly the same to me when I as a vendor and started this whole IT Skeptic thing (yes it's Alan's fault).
vendor spam
Dear Alex G
No you can't post a comment like that here. No matter how passionate you are about your product, dumping your sales spiel here is regarded as spam. This is not the forum for discussing the merits of specific products especially when you work for them.
If you want to discuss design principles without selling then feel free to try again
Clarification
I think there is a misunderstanding. I feel CMDB can be very useful (in monetery terms has very good ROI) if implemented properly. The only point we have to unstand is that CMDB targets at avoiding loss and not making profit and also that it does not make sense in isolation.
point of view
That's your view, I have mine: The value of CMDB seldom exceeds the cost of doing it
there is a good chance you think this because you are ascribing value to a CMDB that is not from the CMDB. See More discussion of CMDB: not the best use of funds:
Or perhaps you confuse tool with process. See Those who would promote CMDB should promote CMDB
I'm all for configuration process (in the sloppy ITIL use of the word "process") which is why I proposed On Demand CMDB - if we fix the process we probably don't need any new tool.
CMDB Succes!
Honored Skeptic,
I was blessed to be the project manager for a project at a rather large enterprise to create the first CMDB as part of their migration of ITIL processes. The project was a glowing success. I believe that the tool did all you described in your opening comments and then some. Our project architect knew exactly what it would take to make the tool robust and effective to meet the definition of what the CMDB should do by definition. Through some very ingenious and creative interface/database development, it amazingly did all that we'd planned for. The process of federating the data and implementing the interfaces was actually submitted for a patent. I always look fondly back on that project even today with excitement and amazement on what the project team actually accomplished. I knew then that the tool was a very unique event and fully appreciated how lucky I was to see something so remarkable actually come to fruition.
Cheers!
Congratulations!
Congratulations!
As project manager you must have some visibility over what such an effort cost and what were the returns on the investment?
And I'm curious as to how they maintain relationships between CIs and Services in a large organisation. Can you give us some hint as to how that works? e.g. Does a configuration manager maintain the links? Or is it required as part of an RFC for someone else to update the information?
do you stay in touch?
How is TCO?
Is the company maintaining the investment to keep all the federation interfaces working in a changing world?
Are processes functioning to maintain the validity of the data?
How reliable is impact assessment proving to be?
lots of questions sorry, but it is an old British military trick to declare victory in the face of defeat, so one must look closely at what is described as "successful". All I'm hearing from your comment is that the technology worked for its own sake.
The questions we should all ask of any project are broadly:
Was it really a CMDB or just some configuration data? (at a business level this doesn't matter but for this debate it does)
Did it work? Did it meet a need?
Did it provide ROI? Or VOI?
Was it the best use of the available funds at the time?
RE: Congratulations
The project was approx $750K USD. Very expensive, but this was a very large organization of well over 2000 servers. The intranet web-based graphical interface allowed one to drill down from the macro level of the entire network to individual server clusters to identify problems early (red symbols) and do root cause analysis on outages when they occurred.
It was a true confinguration managmenet DB as each of the CIs were tied to a business process as an attribute of the CI record. As one could drill down into the details of the network to determine a root cause of any problem, one could also be immediately aware of which business process were impacted by an outage because you could drill back up to an operational level of the business process affected. Relationships to other CIs were also identified attributes in the DB so logical and physical relationships were maintained and displayed in the graphical interface. These record attributes were initially created in the DB by the project team both in an automated fashion and manually. The data was meticulously maintained through very disciplined change management. The organization had an aggressive change managment scheme with weekly CCBs and fully documented changes. Nothing would move in the environment without being documented and then approved by the CCB. Further, every outage was investigated and reported at a daily conference call at the beginning of each business day which could mean some very serious consequences for the lackluster analyst who stepped out of process to cause the incident by an unauthorized change. Thus a very controlled environment which futher fed into discipline surrounding the CMDB content.
For ROI, I have to report sadly I left before any real ROI was measured. The final 2 sectors of the business were being migrated into the federation upon my departure. So it was a work in progress the last I was involved. However, I witnessed some remarkable funtionality in the 3 business sectors which were operational. So it did work and worked well to the specifications of what one would expect of the tool.
The tool was absolutely worth the investment as it became the bedrock for all of the ITSM processes implemented across the enterprise. It was in use daily by every service managment process owner and much of the IT staff when I departed the company. It was quite satisfying to see how quickly it was adopted into normal management practices of the infrastructure.
I offered my experience to provide an example of what is possible. Granted, from all of the other conversations I've seen on this subject most CMDB experience has been quite negative. I was very fortunate and still reflect on how unique that opportunity was in my journey through this thing called ITIL.
this rare phenomenon
I don't think your experience was utterly unique :) We get other occasional reports of this rare phenomenon called a successful full CMDB. It is out there.
but it only occurs under special circumstances:
Complex. 2000 servers isn't that huge any more (I'm assuming you mean physical servers. 2000 virtual is becoming alarmingly common). Well it is in New Zealand but i do get out occasionally. But 2000 sure isn't trivial either. A site needs to be complex enough that it warrants automation of configuration mapping.
Critical. You don't explicitly say how critical this system was but the rigorous change implies it. Even with 2000 servers, a couple of trained knowledgeable configuration staff with a normal auto-discovered and auto-inventoried network, a service catalogue, MS-Excel, and a telephone could work out the service impact of anything pretty quickly for a lot less capital invest or TCO than this thing. if "pretty quickly" isn't going to cut it then the tool becomes more atrractive
Wealthy. $750k on an internal piece of kit is hefty. To win over competing projects there needs to be a bit of spare cash in the system
I'm still a bit suspicious - sorry - of mapping to "business process". This is a slippery term sometimes used by geeks to mean an application which is as near as they get to understanding the business. An app is not a service. in fact even a correctly-defined business process is not a service, although it is getting much closer. Manually mapping up to an application CI is much much easier than manually mapping up to a busines process... or a service.
To manage 2000 servers, here must have been several hundred thousand CIs in the overall CMDB?
RE: This rare phenomenon
The mapping of CIs to business process was absolutely done right. In each case of the 3 business areas which were completed when I left, we engaged senior business analysts (business geeks) in each sector who knew their systems and could identify how these systems were supported. It was a rigorous process, but the only way to get it done right. And yes, there were several hundred thousand CIs in the federated tool.
As far as criticality? I'd say this federated database became the most critical piece of gear in the enterprise. Even the CIO would consult it on occasion to see what was "going on in the world". It quickly became the "authority source" for outage information when and if it orccurred and was frequently cited at those horrific morning calls.
It's not a big fish story, I promise you. I am as excited today as I was then just for the experience of having worked on that (what I believe) history making project.
product testimonials unwelcome
I fancy myself as a reasonably good communicator, but then folk post stuff to prove I'm not. I've just removed a comment from here.
I thought it would be abundantly clear that this blog is not the place to post plugs for specific products, whether you work for the vendor or not.
Worse though, I had hoped I had communicated that WHETHER CMDB IS A GOOD IDEA OR NOT IS NOT FIXED BY FREAKING TECHNOLOGY
Sheesh.
CMDB as ODS
This post may be of interest to those following the CMDB discussion.
Charles T. Betz
http://www.erp4it.com
It´s right, there is no
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.
You need to wander this site a bit more
You need to wander this site a bit more - I've blogged on the Federation quite a bit
P.S. After Google translating, your link looks to me to be spam and has been removed. Contact me if this was unfair. Link-droppers are getting very sophisticated. if you are the same "Opico" on twitter then you appear to be in the SEO industry. If so **** off my site please. If not, then welcome of course.
The CMDB as a dead elepthant, it cannot be done ... NOT
[This comment has been reposted as its own thread, but I think I'll leave it here too since this posting gets so much traffic and it deserves to be seen here]
It never ceases to surprises me as an IT veteran how little people change while the technology evolves around us. In part I agree with some of the statements made here, but a lot I just do not.
It was about 15 years ago when I was talking to the logistics director of a retail company in Europe about implementing the ERP system they bought. Their 6 warehouses he managed were going to be rolled out and upgraded into the system. He assured me it was impossible, and he used more or less the same arguments that are used here. They had over 100000 items (counting seasonal goods), high and low turnover, emergency orders, people already too busy (and dumb) etc etc. In short: could not be done.
Now we in IT are used to end users saying their business is unique, not like anything else, impossible to capture blah, blah, blah. We tend to learn to ignore most of the chatter because at the need of the day we are able to address almost all issues. Users lean towards the logical fallacy that is well known, The Argument from Personal Incredulity, ie I cannot explain or understand this, therefore it cannot be true, or in our cases, be done.
To cut a long story short, 2 years later the system was in, running these warehouses very efficiently, the system was ordering goods and they were saving money. O yeah, before I forget, the logistics director was replaced 6 months into the project.
Lets move it up a notch. How about a car manufacturing plant, multiple product lines, and the whole thing run in JIT logistics? For those not at home in this field, JIT stands for “just in time”, ie the car manufacturer does not have any stock, he receives daily the parts required to achieve what is planned to be produced for that day. Think about it, for example the car seat required for that day. The exact number of seats for all cars, in the correct color and upholstery option are delivered daily to the plant or even in multiple deliveries during the day. This seat is only one of maybe hundreds of thousands of items, with a production line that does NOT stop for almost anything. But yet, they manage to make it work.
Apparently we as IT have cracked some very tough nuts in the past. Through the use of a good architecture, good software and changes to the underlying business processes we are successful in supporting our IT customers.
After reading this article I could not help but think that I had taken a time machine back 20 years. A CMDB has a low number of items, low turnover and probably no transaction data attached to it .. when compared to the business we support daily. It then stuns me when people say: can't be done. My current role that has changed from 20 years managing on the business IT side to managing implementations in the IT arena, the likes of CMDB's and other tools. I am confronted daily with the arguments (fallacies) I stated previously, and I use the same examples I user here (and more) to break those doors down. Basic number comparisons tend to humble the IT department when they see what challenges the business end is faced with, and that we as IT have resolved!!
Hard to initially populate?
Once more, look at how businesses do this. In my example of the 6 warehouses they had to come in on a Sunday, count everything in one day, enter that data and have everything ready for the Monday morning business. Easy? Heck no, but doable and done hundreds of time across the globe where stock levels have to be accounted for in a new system. In IT, where large numbers of stock (configuration) items can be reached automatically, where item turnover is measured in years, where we have low numbers of items (compared to the business), no transactions and no business pressure to fit in one day (or week or month), and this is not a doable action?
Also, a typical ERP implementation needs to take on existing data, a data load of 1 million+ records from 30+ entities is not that untypical. In IT we have maybe 30k, from about 3 different entities. The effort is truly trivial. We were implementing a help desk and one of the “issues” the management raised was the difficulty of the data load, ie taking on and converting data from the existing system. We went to the business, got the numbers from a recent data load for the ERP implementation they had completed two years back. They were stunned and rather shame faced when we put those numbers up on a slide.
Hard to sync and keep up to date?
I have been asked this question by C-level types a number of times. I turn around and ask them what their (IT) supply chain looks like. The look I usually get back is once of amazement and confusion. It never dawned on them to not only document and stream line the supply chain of the business, but also their own!! Businesses manage to sync their supply chain, track every item they have to infinite detail ... and the IT department cannot? There is no fundamental difference: there is a need, a purchasing process, goods received, warehousing and life cycle management. No rocket science here, just basic process definition and alignment.
Before I go on ... yes, in this process there will be manual effort involved. For some reason IT always thinks that they can only reach maturity through automated process. Crap (if you forgive my English). If it is good enough for the business then it is good enough for us. The CI is created when ordered, not when installed, it is activated when it is received at the goods in department, not when it arrives at the desk to some technician, etc, etc. We need to stop thinking like silly techies and learn from the businesses (that use solutions we as IT provide and support, oh the irony here).
We also sell tools to support data warehouses. I have been to major international banks that run data warehouses feeding off of 15 different data marts (all with unique data sources), containing tera bytes of data. These are kept up to date daily, where data lineage, reconciliation, consolidation, data redundancy checking etc etc is all done to deliver a data warehouses that supplies data to comply with some of the most strict laws on the plant, ie reporting in the banking sector. For those not familiar in this area I suggest taking a glance at the BASEL II regulatory requirements. If banks do not comply they loose their credit ratings, and we all know what that means. They keep this all up to date using solid tools we in IT provide (ETL tools, meta data repositories etc etc ... the irony starts dripping off at this point)
Now, here we sit with our piddling little CMDB, carrying maybe 200k records, most likely no transactional data, just “is” data, with turnover measured in years ... and it we cannot keep this up to date? If we were a business we would not survive for more than a week, and to honest, I would be ashamed to even make a statement like that.
No standard model?
Show one standard ERP model, and this will make sense to me. Our IT model is infinitely simpler than what businesses have implemented thousands of times. I actually had to read that statement a number of times to grasp what was being said. Huh? I strongly suggest counting the number of entities and attributes in ORACLE's or SAP's ERP model. Then please explain why this DOES work and any model we can come up with cannot.
Does a CMDB make sense?
This is all so reminiscent of the discussion in the 1980's about ERP packages. Would they bring the benefit they projected? Were they mature enough? They we are all sooooo complicated to implement. We are now 20 years on, and you would struggle to find any business that does not have some type of ERP system implemented. Not because of the hype, but because of the solid business benefits they all have achieved, after going through the pain first of course ... and the help of some very innovative IT folks!!
Sorry about the rather long rant here, there are a lot more example of here that are sorely based on the logical fallacy I mentioned previously. My basic message to all you IT operational types out there: Do not be so parochial, step over to the business side and talk to them. Look at the issues that have faced them over the years and how the resolved them. Document what you feel is important to your CMDB implementation and then talk to the business for advice on how to proceed. If you have a logistics director or other person in the know ask him to present supply chain basics to you to understand how this works. Find a good business analyst to help you document what needs to be done. Find an architect (preferably one that helped with your data-warehouse initiatives) to help you define your infrastructure to keep your CMDB up to date and tip top. Finally, work with your supplier like your business did 20 years ago when they were starting with ERP in getting the functionality you need into your CMDB of choice. In short, step out of that damned box, stop moaning like silly end users and get the job done!!
Amen
Amen.
Mark Lutchen makes a set of similar points in his excellent book Managing IT as a Business.
I especially find it amusing when people claim that "ERP has failed, so don't try a CMDB." A look at SAP's & Oracle's financials paints a different picture.
The only quibble I would have is that the data architecture is not simple. It's actually more complex because every IT service is its own bill of materials, with dependencies on other services, making for one big hairball. Bill of materials problems can be solved, but this one is an order of magnitude larger - a BOM of BOMs, all continually changing (where product BOMS are relatively more static). I'd appreciate anyone who can contribute some pointers to the best theory/analysis for bills of materials management.
The logical/physical boundary is also tricky. We don't have good practices as an industry for understanding/representing when bits become software become applications become services supporting business processes (or is it capabilities?). Lots of debate here. Virtualization is making it even more fun.
The number of logical entities required by a comprehensive IT solution, when and if fully implemented on an ERP framework, would probably be comparable to supply chain, HR, etc, and no system yet incorporates all of them.
There is transactional data as well: events, incidents, changes, problems, releases, service requests, projects, and more, all of which can be attached to elements in the BOM. Event management in particular can present capacity challenges; it's a massive firehose.
One disservice ITIL has done (continuing into V3) is to confuse CMDB with data warehousing. The IT data warehouse is actually a separate beast from the CMDB.
Now, our friend Skeptic is doing us a service by challenging the ROI on CMDB, and this is only helping sharpen the debate. But even he has grudgingly admitted from time to time that the largest organizations (where you and I seem to be working) *may* have a case for CMDB.
The trouble of course with saying that "CMDB can't be done" categorically is that it is falsifiable. Kind of like saying "there are no black swans." Even one successful CMDB disproves the assertion.
See here for an early version of the conceptual IT data architecture in my book. Yes, it's a teaser... some key improvements in the book.
Charles T. Betz
http://www.erp4it.com
thanks
Hi Charles
Thanks for pointing out that book; I will take a look.
As for the BOM, I agree, but that is at the end of the process and long way down the road. I tend to look at the CMDB like we did the ERP systems; a CMDB is built up around a certain number of modules, which will then allow us to build up a full system. In fact, you can step off that elevator at any point and still have a ROI, something of course impossible with ERP. Discreetly building up your CMDB resolves issues slowly but surely, you are eating that elephant one bite at a time.
Each CMDB phase also requires a unique team to address that specific business layer. We were involved in a CMDB and asset discovery project at a large bank. The decision WHAT was to be discovered and populated into the CMDB was left to a techie from operations that was responsible for the installation and running the production CMDB. This as opposed to the “business” end of the CMDB making those decisions. This lead to decisions that things like firmware level of boot proms in desktops need to be detected and populated. No one questioned if they had ever needed this information before and what risk they were running if they did not have this information, the techie decided it was a “requirement” for reasons only know to him. One of the biggest mistakes made in CMDB is probably populating it with too many detailed CI's.
Services dependency mapping starts with data transactions, the applications supporting these transactions and finally the hardware supporting the user, the applications and the data (and all its middleware). Yes, you can do this but note that you need all the other bits in there first, where each CI type has its own distinct ROI, its own project approach and unique set of business users. See the forest from the trees, build up your CMDB logically involving the right people and the right time and there is then no reason why you cannot get to where you want to be.
Viewing each CMDB maturity level as a separate project also addresses (in part) your logical and physical boundary, each have their own place and follow what the end user requires at that point.
The transactions reside not in the CMDB but with the service desk systems. This is a related system but does not touch the CMDB as such (other than master data population).
As for ROI, there are lots of ways to calculate this. We strongly suggest using an incremental implementation strategy linked to measurable ROI. Projects that only promise ROI two years down the road rarely survive or even get approved nowadays. If such a project hits an over run (which never do?) then there is nothing on the balance sheets yet to move this through. If you chop up the implementation into logical business areas, using a unique project team for each and have the business define the ROI then you will go a long ways to getting a CMDB up and running successfully. There is a lot of documentation out there (white papers and such) that can help you define and calculate your ROI. I am sure your supplier can be very helpful as well.
cheers
Ben
budgies are better
I'm not saying "there are no black swans". I'm saying you can't keep one in the 'burbs. If you own a ranchero with a few hundred acres, go ahead. For the rest of us, budgies are better.
IT can be done without CMDB
Management of infrastructure can be done without a cmdb. Just refer to the General Motors presentation given at the itSMF USA 06 National Conference. They have:
7000 Servers
20,000 Engineering Workstations
140,000 PCs
2500 WAN Links
12500 LAN Switches
8200 Changes per month
17+ Service Providers
15+ Major HW providers
50+ Major SW Providers
located in a global environment.
They don't have a CMDB.
They manage the environment through various consoles, that provide the visability needed.
Also, I am not one of these people who subscribe to the ITIL text as gospel. ITIL is ment for 'fit for YOUR purpose'. Sometimes all a org needs is incident and change magement to stabilize an environment.
ITIL is a best practice - it is NOT a standard .... and furthermore, standards are still ment to be applied per organization.
Actually, GM has a CMDB
I now have it from two independent sources with firsthand knowledge that in fact GM does have an enterprise CMDB, and uses it intensely to manage their heavily outsourced IT operations. Custom built thing, relatively simple in structure, but large in scale.
Charles T. Betz
http://www.erp4it.com
Public statement about IT management controls!
Grump mode on
Saw this feedback and thought "is this presentation about the same company I know". No.. it must be another General Motors. Or maybe it exists in a different time dimension.
I don't disagree in that you can manage infrastructure without a CMDB - but it does depends on what you mean by manage. Also a bunch of infrastructure databases linked through integration could be called by some a federated CMDB. From personal experience of developing and implementing CMDB add-ons to service desks and evaluating the reality - I get really annoyed when I hear success stories that are interpretations fit for public consumption.
A few words about real life implementations of CMDBs
a. People manage despite lack of data, lack of process, lack of clear roles etc. - they still do their best with or without a CMDB. It takes a marketeer to say that grey is actually the brilliant white we have been looking for. With a reasonable CMDB implementation things are slightly whiter.
b. It is rare for public presentations to reveal the real management issues, politics, viewpoints as it is not allowed by the company lawyer, or managers who might feel exposed. The truth behind the real numbers of incidents or the root causes would never be revealed if we didn't have a service desk to count and categorise them. We still have to educate teams to actually fill in an incident report or our MI is rubbish. Likewise, communications about the true state of control is often "managed" by the managers - you need some pesky auditors or regulators to upset the status quo. If you audit CMDBs it is so easy to point out gaps and holes in change processes, that no one really knew before.
c. The CMDB concept is a good one as it is common sense to centralise knowledge of service construction and use that data by multiple teams and processes. Its just that many are badly implemented because a CMDB combines strategy, tactical, people and technical issues. Many management teams don't engage fully and many techies go off on a tangent developing a perfect concept but not delivering a tool to be used by many.
d. Even when you have a CMDB that is well thought out, implemented with supporting update processes - it doesn't mean it will be used because you still have to work at getting people to use it.
I ran an event in the UK a few days ago looking at data centre management and the areas of cross over with service management. The presentations are downloadable and include the real life experience of people who do deliver in this area. web address is www.squaremilesystems.com/n_seminars.html if anyone is interested.
Next time we have examples of why you don't need a CMDB, could they be better ones...
Grump mode off
Hi everyone, the General Motors examples shows that you can manage large environments. Hurray!
DC
the majority of the world's IT shops don't have a CMDB
Sure Dave. Given that the majority of the world's IT shops don't have a CMDB we have a plentiful supply of examples to choose better ones from.
Codswallop
OK, so I admit it is late and I also admit to having had a wee dram midweek however I’m currently resting between roles and there’s no law against it. When I read ‘Cotswold Dave’ I mistakenly saw ‘codswallop’, great nom de plume I thought until I read it correctly and as one imaginary joke evaporated the real funny side emerged. Attempting to do CMDB by the book is truly codswallop.
I admire the theory and yearn to be able to not only implement but keep going for more than a week a fully functioning CMDB. It’s almost the ‘holy grail’ of service management. I guess the ‘keep it going’ bit is the real issue, the inertia of the day to day reality kicks in and inevitably things grind to a halt. People, (expletive) people let the whole thing down. As is often said; ‘if it wasn’t for people our processes would work wonderfully’ and that for me at least, is the main issue, processes don’t fail only getting people to follow them fails.
The world of process has gone charging off on the misguided view that all that needs to happen is for people to follow process and they’ll work. Can’t argue with that other than people don’t follow process. We’re pre-programmed not to follow rules. Anyone out there who has kids will know that you don’t need to teach them to be naughty; you only need to teach them how to be good. Being naughty comes naturally to them and so must be instinctive. We all hate rules and where we can get away with not following them then we will.
OK, so I’ve drifted a little, this isn’t about CMDB it is about the basis of human nature not to want to follow rules, the dilemma is that in working in Service Management we expect that people will of their own accord follow rules and so the dichotomy is discovered. ITIL 3 has gone off into the life cycle of a service and along with most things has not paid sufficient attention to people, if we got the psychology correct then the need for process and rules would diminish and perhaps then we’d get a CMDB to work.
Why does the World Wide Web work?
If it is the basis of human nature not to want to follow rules, why does the Web work? This incredibly rich collaborative environment?
I'd suggest it is because of a minimal number of non-optional constraints, coupled with an obvious value proposition.
I'd also suggest that a CMDB capability can succeed using the same design philosophy.
It's not about the process. It's about the benefits that become obvious through following the process, and the pain of not doing so - not in terms of process police, but in terms of real consequences like outages being laid at your door due to you not updating your CMDB records.
See http://erp4it.typepad.com/erp4it/2005/06/a_success_story.html for a discussion of applying psychological principles to CMDB maintenance.
Charles T. Betz
http://www.erp4it.com
Amen brother!
Amen brother!
Look at any survey on the uptake of ITIL: lots of sites haven't done Config Management. CMDB is nice to have but business goes on without it.
P.S. I can't find that presentation on the web. Is it published?
You guys have all been fooled
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
Thankyou Master (with distinction). May your aim be true and your holidays sabai
The Human Element
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
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
"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??
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...
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
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 get the milk for the cafeteria. Just because a mega-gazillion software behemoth works for the ERP of a total organisation does not mean that something like it is a sensible use of funds just to manage the objects in the IT environment.
So what happens is ITIL convinces people they need a jumbo but they only have budget for a billy-cart. Then they get up on the roof and ....
I'm not a Chief Architect in a Fortune 50. I'm just a solutions architect who talked to and crawled over hundreds of organisations in banking, insurance, telecoms, airlines, government, retail, manufacturing and more, looking at their requirements and what was a justifiable solution for them.
Any project needs a business justification
I love ITIL as it keeps me in a fairly well paid job. The opportunity to pontificate the finer points doesn't massage my ego, but it is certainly relatively straight forward and makes for good fun. However, what I do find is business taking it very seriously and getting very wound up about not implementing it in its entirity. It's as though everyone is aware of, but conveniently forgets, the "adopt and adapt" mantra. As the band the Smal Faces sang "it's all or nothing."
Bottom line for me is that ITIL is like Communicsm/Socialism - it is the greatest thing on the planet on paper and makes perfect sense. BUT!!! As Liteheaded has stated, start involving people in it and the whole thing inevitably becomes corrupt - because people are corrupt, want power and influence, and don't want a service to work as basking in reflected glory isn't half as fun as, or full of kudos as, being Red Adair.
Tablets of Stone
So, what have we learnt from this blog? Some say that CMDB is easy whilst some say it is impossible. Some say that the toolsets of the world can resolve every issue whilst others say that it only takes a malcontent to bugger the whole thing up. What we have truly learnt is that Karl Marx tested his ideas for service management under the code name communism before attempting world domination not by revolution but by process. In saying that there needs to be some investigation into Moses’ influence on ISO 20000, where did all that ‘thou shall’ come from?
"Thou shalt"
"Moses’ influence on ISO 20000" - very good!!
You might enjoy these:
Configuration Management is important
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.
Multiple definitions of configuration management
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
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?
Four views of change?
Charles T. Betz
http://www.erp4it.com
I guess a Skeptic's site shouldn't expect clairvoyance
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
it isn't a CMDB
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 ;-)
Silver Bullets
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
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
Over-achievers
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
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.
achieving a managable configuration
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
Not Ready for the CMDB
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
"...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.
Interesting quote from an "official" ITIL book
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:
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???
Some Flaws With ITIL That Show Up in the Definition of a CMDB
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
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
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
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.
CMDB
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
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.
The butterfly effect
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
Thanks for the link Antonio - I hadn't seen that.
I have commneted in a new blog post
Don't agree, at least 100%
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
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?
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
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
... 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
Great points.
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
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?
ITIL - IT Infrastructure Library
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.
Investment
OK... Let me check my math.
35 People in 4 Months. Let's assume a conservative US IT pay of $20/hr. Assuming no overtime, or software cost, we are looking at a $448,000 investment. (Or, $11.20 per tracked item.)
I cannot speak to the industry you are in, however in my world this is quite expensive and would take a very long time to see a solid ROI.
Hi Collin Thanks for
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
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
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.
CMDB standards
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
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
More on this topic here
Hitting strong in our face
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
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)