On demand CMDB

As promised in a comment recently, I have published an article on ITSM Watch about "on-demand CMDB". The idea is that we only need to keep a minimum of data in the CMDB and we assemble the rest as needed. [Updated: the article is now included and revised on this blog]

We [already] create data ad-hoc anyway when we have to. If the data is not there or not right and management wants the report, we gather it up and clean it up and present it just in time, trying not to look hot and bothered in the process.
How much better would it be if we had a team, expert in producing on-demand configuration information? They would have formal written procedures for accessing, compiling, cleaning and verifying data, which they would practice and test. They would have tools on the ready and be trained in using them. Most of all they would “have the CMDB in their heads”, e.g., they would know where to go and who to ask to find the answers. They would have prior experience in how to do that and what to watch out for.
So instead of ad-hoc amateurs responding to a crisis, experts would assemble on-demand data as a business-as-usual process.

What do you think? Could it work? If so, wouldn't it be much cheaper and more responsive to a changing environment?

Comments

Interesting idea????

I worked with a company a few years ago that did something similar for IT operations analysis. Instead of running large data warehouse jobs every night and never having the expertise to read and report the data, they had 4 real-time analysts that looked at 15min/1hour ETL output.

John
johnmwillis.com

the world is flat and wetware is cheaper

We geeks want to automate everything but reality is the only time where it is cost effecitve to automate is for tasks that are
a) repetitive and
b) STABLE. in a constantly changing world the cost of changing software usually outweighs the benefits it returns

So why do we delude ourselves that a CMS will be stable? All this geekbuzz about federation scares me. If we are constantly integrating and de-integrating operational tools and chasing new technolgoies like your buddy The Cloud and virtual this and that, then the already bnutty cost of a CMDB goes up another order of magnitude.

Learn to love people.. Hunmans are infinitely adaptable and self correcting and autonomous.

And in the new flat world, they are cheaper too. Maybe we only need one on-demand-cmdb team member onsite and much of the data crunchin can be outsourced to India or China or Egypt or Romania or Kenya.

Trip to the looney bin required

Common sense and simplicity are one thing, but - wow - you need to get in touch with the trenches again. Automation, federation, and central repositories and clearinghouses provide repeatability, scalability and reliability. People - don't. Especially those offshorers. Nice dream, but please, pass me what you are smoking.

examples

I've often called for some concrete examples of CMDB fully implemented and working, especially those where the organisation feels it has received a justidfiable business return on the investment. I'd be especially interested in any examples NOT in the world's biggest or most complex sites. if u have some examples please share them with us.

And if you have an example of federated CMDBs working then I'll be a bit shocked.

If you don't have any examples, then I suggest you avoid the blue pills before evaluating the CMDB concept - they make you far too optimistic.

Syndicate content