Don't fall for the demo: an asset database with bells and whistles is not a CMDB
This article has been podcast
Don't fall for the demo: anyone can set up an asset database with enough relationship bells and whistles on it to fool themselves and others that they have a CMDB. People set up a CMDB and either grossly overspend beyond any reasonable ROI to complete it, or settle for the delusion that an asset database is a CMDB. The vendors of service desks sell an asset database that looks a bit like a CMDB then claim all the benefits of a CMDB.
Antonio and Frank commented on my last blog post. I decided to move my response up here to the main blog rather than post a reply comment.
They both defended auto-discovery as a useful tool for CMDB. We aren't agreeing or disagreeing because we are talking at slightly crossed purposes.
Yes auto-discovery is a useful aid. Frank you sum up nicely the two scenarios where it is useful. I like the concept of Reactive and Proactive ConfigM. I've used the same model for Problem for a while but not thought to apply it to Config. I'm sure I'll remember to attribute it to you :-)
But we all agree that auto-discovery only does some of it. So I have two main points that I think you guys are not addressing:
The REST of the CMDB is the hard bit. Auto-discovery automates the easy bit. If I don't have an auto-discovery tool, I can take any geek and get him/her to map my network for me manually. But I need a higher-value person to work out my logical processes, services, stakeholders and SLAs and interconnect them all and connect them with the easy bit, and I need that person(s) on staff because I need to keep that data current. I just don't think that is do-able within any sensible ROI contstraints, sorry.
So instead most organisations (those that don't grossly overspend to do the whole thing) end up with an asset database with enough relationship bells and whistles on it to fool themselves and others that they have a CMDB.
My second point is that the vendors of service desks pull the same trick. They sell an asset database that looks a bit like a CMDB then claim all the benefits of a CMDB.
Don't fall for the demo: anyone can set up one server linked to one process linked to one service, so the service comes up on impact assessment of a change or outage (I've been there - I was a vendor).
Work out how many of these you will need to set up in your business. Scope the effort required to manually discover and populate the details of all your processes, services, stakeholders and SLAs, and then all the inter-relationships between them. Then figure out how you are going to deal with the bits that don't play nicely:
- itinerant devices (portable and wireless devices)
- load-balanced Citrix or web-server farms
- Web Services and other loosely-coupled dynamic relationships
- All the new on-demand computing where you don't even know what device a process will run on
Then scope maintaining that data current as services come and go, people come and go, the company reorgs and outsources and....
It just doesn't add up, sorry. It is another of these techno-geek fantasies to fix everything that looks good in concept and wildly impractical in practice.
Made in New Zealand 
Comments
Absolutely...
I have been floating around the IT industry for a while now and I've yet to see a good application for a CMDB. You are right, of all the CMDB software I've seen, they are nothing more that glorified asset management databases. But this criticism is not just aimed at CMDBs. The number of Service Desk applications that are now calling themselves "ITIL compliant" is huge, and all many of them have done is rebadged their product offering (sometimes with even just a version number change) and changed a few labels to make it look like it conforms to ITIL. But of course they can do that, quite justifiably, and get away with it, because ITIL is not a standard... it is only a framework.
By the way I have an idea for a proper CMDB... but no money or skills to develop it!
the world does not need another CMDB technology
Save your money: the world does not need another CMDB technology. Technology is not the solution to a process problem.
Hmm...
I don't have any money to save!! :) Anyway, I'm not sure the problem with Configuration Management is a process problem. I have a question as to whether Configuration Management is actually a "process" in it's own right, like Change Management or Incident Management.
It's a question of ownership.
It's a question of ownership. ITIL says the ownership of the data, and the processes that check and maintain the data, is theoretically a distinct role from the ownership of the change process, presumably because the data serves more masters than just change.
Ever tried validating a CMDB?
A project just completed was to take a service desk CMDB that had been forced upon many of the technical teams, and visualise the CIs and dependencies. Why? there were over 2500 servers linked to appps, services etc. and no one trusted the data. The service owners who were meant to keep their own bits up to date were not experts in software, the service desk and so on, but they tried and got it wrong occasionally. When we drew pictures using the data it suddenly became clear that people had been inputing it wrongly ever since it was commissioned. Wrong relationships, orphaned servers with no known function, decommisioned servers linked to live apps.
A lot of effort went into gathering and creating the data (all manual), but it was let down by the fact that everything was basically textual. The service mappings were created by drawing them on whiteboards, then manually inputting them into the system. No one can get the orignal pictures out of the system so we were I suppose, recreating the whiteboard. Haven't we always used pictures to understand complexity? Anyway, the moral of my piece is maybe it is easier for service owners to validate a picture, than relationships in a database. So a CMDB that doesn't enable you to get different types of reports, especially graphical is not only of limited value, you can't easily check it.
We all use roadmaps to plan, check progress and react to unknowns. It consists of text in a structured form (index), high level and low level physical maps, logical maps of train or metro stations, key services, and so on. Its just as well we have CM for our road infrastructure as we need the knowledge presented in different ways, to suit the different needs. It sounds like maybe... some of our taxes are well spent....
CMDB, where does it add value
Hi,
from my own experience i can say that a CMDB adds value, BUT:
We need to make sure we do it at the right level.
We decided to register PCs, Servers, main infrastructure components but not pheripherals such as mice, racks, server componenents, etc.
This gave us a possibility to link problems to part of our infrastructure and found out that certain types of assets created more issues than others.
So to me the configuration management process adds value if done at the right level,
Eduard
The only way a CMDB will actually work for you...
Hello Skeptic,
Again, you make some great points. To sum up the two critical points that I want to address:
1) IT Resources and enterprises will bend themselves into believing that they do have a CMDB when they really don't, and
2) Sales people will tell you that they're selling a CMDB when they're really not, such as in the case of an Asset Register.
Let's face it. If you're building your own CMDB, in this day and age, and you're not in the business of selling CMDBs you're in over your head. The requirements for a solid CMDB are huge, complex, and expensive. Think of what it takes to build a stand-alone, multi-tier, distributed application, let alone what it costs to integrate it to endless other systems. So, if you're building one yourself, you're probably not doing it with a real ROI in place because if an enterprise brings someone like me or my staff in we can "always" prove to it that the up-front implementation and the year-over-year maintenance costs are far beyond anything most enterprises or IT resources will ever want to admit to and are far beyond a reasonable ROI. This translates into a very simple statement that you, as the "Skeptic" will love... "Implementing ITIL tools yourself is extremely expensive and not cost prohibitive if you really take the time to look at the details."
There are a lot of reasons that enterprises try to make themselves believe they should build their own solutions but the reason that seems to come up the most is that many IT resources "want" build and and manage their own tools. They "want" to believe they are "technology developers" and that they're good at it. They "want" to be challenged. They "want" to have an important place in their enterprise. They "want" to impress people. In reality, if you bring a competent C-Level executive into the room and let me at them, I will always prove, with facts, that you can "never" justify the cost of building and maintaining your own "horizontal" tools unless you are specifically in the business of selling them (i.e. it's your vertical market and you intend to make profit off of them).
Let me clarify this. Your Vertical IT is aligned with the industry you sell to and represents your specialization and/or expertise. This is "value-add" IT and represents where you do want to spend your IT budget. Your Horizontal or Operational IT is what is common across any and all vertical industries. For example, anything that is ITIL. Unless you are explicitly in the business of "selling" ITIL solutions, the business case for not building your own ITIL solutions is very easy to show.
Does this mean you shouldn't have ITIL tools? No. Depending on your scale and geographic distribution, you can range from being very successful with paper and spreadsheets, if you're small, all the way through to where vendor supplied tools actually can make your enterprise better, if you're big. Two ends of the spectrum. In all cases, regardless of where your enterprise sits in the spectrum, you can never really justify the cost of building and maintaining your own horizontal tools, in this day and age.
Aside from the fact that it's not your core business and conflicts directly with your vertical goals, here are the technical requirements that act as reasons as to why not:
Necessary Costs:
- Cost of Domain Design Expertise (i.e. The business problem at hand, such as CMDB)
- Cost of Domain Implementation Expertise
- Cost of Application Architecture/Design Expertise for large scale distributed systems
- Cost of UI Design & Implementation Expertise
- Cost of Business Engine & Business Rules Design Expertise
- Cost of Business Engine & Business Rules Implementation Expertise
- Cost of Data Modeling Design Expertise
- Cost of Data Modeling Implementation Expertise
- Cost of API Design Expertise
- Cost of API Implementation Expertise
- Cost of Business Intelligence & Reporting Design Expertise
- Cost of Business Intelligence & Reporting Implementation Expertise
- Cost of Infrastructure Engineering Design Expertise
- Cost of Infrastructure Engineering Implementation Expertise
- Cost of Hardware Servers (for each application tier and multiplied by each environment)
- Cost of Storage (for each environment)
- Cost of racks, cabling, power, cooling, data center real estate costs, bandwidth, etc.
- Cost of documentation development
- Cost of associated training
- Cost of regression test framework design expertise
- Cost of regression test framework implementation expertise
- Cost of year-over-year associated Incident Management/Support
- Cost of Integration Design expertise
- Cost of Integration Implementation expertise
- ETC.
I'm only getting started. But to make the matter worse, all of the above is required for each tool you build. Now, if you sum all of the above costs for any one application and multiply that by the number of tools you build for each domain (Incident, Problem, Configuration, etc.), it gets very ugly very quickly. One for Problem Mgmt. One for Incident Mgmt. One for CMDB. Etc. The costs become huge. What's worse is that these are the "up-front" entry costs. I haven't even gotten into the year-over-year maintenance costs to keep those resources on hand and refresh the infrastructure as needed. Not to mention that by having so much infrastructure (SW & HW) in place, you're raising your probability of Incidents to "1", meaning that you now have to have on-sight support expertise for all of it. Needless to say this gets completely out of hand as an enterprise tries to implement more and more of it and drives the cost of ownership for ITIL through the roof.
So, if building such solutions, yourself, isn't the right answer, then what is? Let me stress that living without best practices, standards, and structure is not the answer. Enterprises always need to strive toward understanding them and improving them. The answers live in two areas:
1) You live without the tools and use paper, spreadsheets, etc. This works for a while but will not scale if you grow and spread across multiple buildings and regions.
2) You let vendors solve the problems for you.
#1 is straightforward and doesn't really need to be addressed. However, #2 need to be broken down into two categories: A) Vendors that sell you point solution tools and B) Vendors that sell you business platforms that represent whole product solutions.
In the former case, "A", a vendor that sells you a point solution leaves you to figure out how to provision for it, implement it, maintain it, upgrade it, integrate it, etc., all yourself. In other words, they leave you to deal with the complexities of their tools. Such solutions force you to divert money, energy, time, and resources away from your vertical industry problems and require you to have dedicated resources, budget, and infrastructure for things that don't help your top or bottom lines. In such a solution you quickly start to lose track of your costs and your environment gets extremely complex to manage, with far too many moving and highly incompatible parts.
In the latter case, "B", a vendor that sells you a business platform sells you a whole product solution that allows them to solve the business problem (in this case ITIL tools) for you so that you don't have to. They do this in a way where you simply connect to them or their solution and pay for the connection. Behind the connection they are constantly improving the service, allowing you to not worry about it and go back to focusing on your vertical problem spaces, with little investment in managing their implementations. They also ensure you understand your cost down to the dollar.
Examples of vendors that provide business platforms or whole product solutions include but are not limited to:
- Salesforce.com for CRM
- CollabNet for development
- Business Engine for Program Management
- BlackRock's Aladdin for Investment Management
- TraverseIT's KnowIT for ITIL and horizontal IT
The world is moving toward managed horizontal services. The reason is simple. By doing so, an enterprise can leverage economies of scale. They buy from a specialized service provider because the service provider has the best available resources to put on the problem, has the most expertise in solving the problem, can deliver the best solution in the shortest amount of time, and can do it for the best price. It's a country club model. You join a country club to have ongoing access to a golf course so that you don't have to build and maintain your own. It's not that you can't but why would you go through the cost and complexity of doing so if it's not your core/vertical business to do so? Salesforce is the country club of CRM, CollabNet is the country club of Development, etc.
Now, to get back to the topic of CMDB... Implementing a CMDB is not something an enterprise should ever be doing, themselves (again, unless they intend to sell it for profit). It's far too complicated and expensive for them to do so. However, buying a stand-alone CMDB puts you in a position of having to provision for it, package it, deploy it, install it, test it, maintain it, integrate it, provision for it, etc. etc. etc. Your costs just skyrocketted, again. This leaves us with: If you're going to implement a CMDB because you've outgrown paper & spreadsheets and can justify the investment, what's the right way to implement one?
So, to finally answer the the topic assigned to this post: "The only way a CMDB will actually work for you..." is to not do it yourself and let someone else give you one that works and is constantly growing and improving at no extra charge to you, as part of one constant and controlled service. In other words, the only way it will actually work for you is to let a Utility vendor provide it to you as part of a business platform that acts as a whole product solution. This way, you're not worried about a CMDB. You just get one. It comes as part of a package with everything else you get. Period.
Anyhow, I thank you for the opportunity to allow me to post and I hope the information adds value to you and your community.
Regards,
Frank Guerino
CEO & Founder
TraverseIT
On-Demand ITIL
Frank.Guerino@TraverseIT.com
http://www.TraverseIT.com
Where is the line between commentary and commercial?
Where is the line between commentary and commercial? The answer is never clear, but I do think you are exploring that line, Frank. I have shamelessly promoted this blog elsewhere so I can hardly throw stones, and you do provide interesting content. But all readers should note that content promoting a product rather than a point of view will be edited or deleted. In order to not set a precedent for others I have edited your post somewhat.
But that's not what teh Demo did
Skeptic, you hit it it right.
Any CMDB tool needs to be looks at first as a neat dog and pony show. Make sure the demo is done remotely and where the food and drinks sre paid for is the best.
The main problem is that when a company - even the one I am still whoring for - buys software packages. It does not ask the people (minions) who will use it. It basically gets bought because the sales teams smoozed the right senior management weenies with out getting Operational savvy people involved who have used similar tools.
But the hardest part for any organization which has more than 3 employees is determining what information they need to support the services they provide. That should be the key to what the applications they buy
Demo hustle
I agree with your point regarding demos and a strong and sharp dose of common sense is required to outmaneuver the plucky IT sales guys before they get you signing on the dotted line - don't forget, this is the century of the 'show-me' economy / 'make/DIY' generation :-)
If you're going to spend more than $10,000 it would be rather obvious to trial and test the software over a reasonable period (1-3 months) before committing to the service/product. If you've kept it for 3 months its more liely you'll be buying it and costing much less in customer support so this IS a benefit to vendors.
If you're thinking of spending more than $100k and less than $500k then I really think you'd do better studying the market and hiring a couple of people to implement the tools you've selected.
Under $10,000 the software should be easy to install and give you the results you expect during the trial without the added expense of external consultants getting in the way of you running your business. This choice is for 2 types - those that don't and those that do. Those that do are successful, those that don't don't know they're unsuccessful .
On your overall views recently and especially today I keep wondering if you're not 'daring' someone to actually tell you how to achieve the coveted CMDB nirvana - maybe we'll hear you doing podcast interviews with the likes of nLayers or Heroix challenging them with your views on the citizen airwaves - either way someone somewhere must be reading these posts and thinking what if... what if me, my business, my geek mate could do this for me and the rest of the world ;-)
Lets take stock - software is getting cheaper - oops, excuse me ... it's free: www.zenoss.org so, lets have faith in evolution of IT at an accelerated rate faster than any other business due to the concept and embrace of community values then ponder 'when' would this be possible - at what stage and with what vapour-tools could this actually happen - to manage a CMDB architecture that is self-cognizant.
Acknowledging all those 'singlularity' enthusiasts I'd not doubt the technology so much as the desire to architect the solution that meets the strict requirements of configuration items and their relationships to each other.
However, human input is unlikely to dissappear - it's an essential factor and holds a child-relationship to the parent CMDB - probably via an HR adapter thingy :->
As more processes automate will it become impossible to manage? I think not - I have faith in humanity to tame complexity at each and every hurdle with more sophisticated versions of wannabe-CMDB - it's early days and CMDB is but an infant in the messy world of SOA and IT.
Keep blogging, I'm enjoying the read!
sooner or later CMDB tools will get smart enough
Hi Ed and welcome.
Thanks for the zenoss link - it is new to me. I looked at open source tools early this year and didn't find them.
I'll address your "dare" question in a new blog entry.
I am sure you are right: sooner or later CMDB tools will get smart enough that CMDB will become realistically achievable. But I think "later". They have terrific hurdles to overcome yet. And faster than the tools catch up, the more we move the bar. With Web Services, you don't know which Web Service will get picked from the UDDI until runtime. With the vision of Grid Computing, you won't even know if the server running the app belongs to you or to EDS.
Even in more conventional environments, how do you auto-discover that this logical database on this database instance is accessed by this Java code which is is part of this logical transaction which supports this conceptual business process which provides part of this Service to this Business Unit whose service owner is Fred and it is delivered under this SLA. So when we close that logical database we impact Fred's SLA. Sorry but that is a long way from a few pretty network diagrams and a report on how much memory is in the CPU.
ITIL is about process not technology. CMDB is the only exception. It should never have got in there, and we can leave it out.