The IT Skeptic - Comments for "CMDB and CMS – the industry-created myth"

Mea culpa

JamesFinister — Tue, 26 Jan 2010 16:31:25 +0000

It took ages to get the ink out of my shirt. I also had to stand there so they could copy what they could recover from it, which of course was in reverse.

Being a good auditor I lambasted them for not having a back up copy of it on paper at the DR site.

It was a very very long time ago.

James

Who?

aroos — Tue, 26 Jan 2010 16:10:54 +0000

James

Was it you, the auditor I mean ;-)

Aale

Hmmmmm

supportthought — Tue, 26 Jan 2010 16:00:11 +0000

Rob, I would disagree with your comment about whiteboards.

I have seen some amazing CMSs in powerpoint.

Truly seamless integration.

Alex

Old fashioned

JamesFinister — Mon, 25 Jan 2010 21:37:29 +0000

Rob,

Configuration isn't solved by technology, but technology can be an enabler or a barrier.

We often forget the role of architectural design - we can purposefully make a configuration easy to manage, at multiple levels.

The issues that make configuration management difficult across technologies and suppliers make the management of other processes difficult as well.

For me my big concern is not fixing the issues with configuration management, it is that having fixed those issue we will still have other critical issues to contend with, and we kid ourselves if a CMS, or a service catalog, is going to solve those other issues.

best platform

skeptic — Mon, 25 Jan 2010 20:47:00 +0000

We must implement and manage processes and tools to have access to the critical data. That does not necessarily imply a database. Configuration is not solved by technology.

on the other hand I must disagree: many of the barriers to the tech database dream are indeed technological.

The whiteboard is of course the platform on which CMDB and CMS run best.

The good old bad old days

JamesFinister — Mon, 25 Jan 2010 20:19:23 +0000

Let us not forget that back in v1 days the CMDB could be a reality, at least in the mainframe world. What was not real world was the ability to track every incident, change and cost back to a specific CI.

I'm afraid there was one unfortunate incident where the CMDB was drawn up on a giant whiteboard that a careless IT auditor leant against and walked off with a key part of the diagram transferred on to his shirt. No names, no pack drill.

We know as well that other industries do, and must, maintain something analogous to at least a CMDB if not a CMS. I do not believe the barriers are technological, I believe it is about trying to implement a CMS or CMDB without any reference to context or purpose. We probably cannot realistically implement and manage a database to meet all requirements, but we can, and must implement and manage one that meets the critical requirements.

A Bad Thing

skeptic — Mon, 25 Jan 2010 19:32:37 +0000

I like the concept too.

The point of my post is that vendors ares selling it as a concrete deliverable that everyone needs, with proven ROI case studies, and they are doing that leveraged off ITIL. That's a bad thing no?

I like the concept of CMS

Cary King — Mon, 25 Jan 2010 17:28:46 +0000

It's clear from the comments here that my thinking is off from the groups'.

Since we're all very aware that very few organizations have even the start of a complete CMDB, I never took it as real the CMS as a currently feasible idea - rather I took CMS as a concept.

I've not yet seen a feasibility study that demonstrates that the cost of a fully federated CMS has a payoff. I've always just thought of it as a vendor sales concept that leaked in to ITIL from the dominant vendors that wrote it.

As a concept, CMS seems to work. CMS supports the ideals of Enterprise Architecture. It helps customers to focus on the idea of data from one process supporting other processes.

We use it as a means of reminding customers to gather all the appropriate data to support the other processes when they have a single opportunity. And, to make that data available for others.

For a small example, we recommend that customers gather all the data about a CI - manuals, specs, etc. - when they put the model of that CI in the catalog of CIs that are approved by Enterprise Technology Architecture, available for purchase through the controlled asset management lifecycle. In that way those documents become stored and available for everyones' use. This is a small thing. But, the concept of CMS is useful to help the various silos give consideration to the other silos. Of what other use is the concept?

Cary King
Minerva Enterprises
CEO - Managing Partner
www.MinervaE.com

What's in a name...

kengon — Sat, 28 Nov 2009 19:11:09 +0000

The only thing I'd change is to ask "What Questions Should Your Configuration Management Function Answer For You?"

OK. I can accept that.
The primary reason I went with that title is that it was a "CMDB Summit"
Tried to stay within the lanes for the title and then push the edges with the content! :-)

Good to be back...

kengon

simply isn't

skeptic — Sat, 28 Nov 2009 07:31:09 +0000

I'm sure your client made a valid business decision. The point I want to get out to the other 31999 readers is that not everyone needs one. When i see guys from 20-person IT shops asking which CMDB tool is best I cringe because I know the odds are good they have thought about nothing but technology and they don't need one anyway. the initial message of this thread was not that NOBODY should have a CMDB, it was that the "drummers" talk about it as a given, an essential core, and it simply isn't.

How often did they make changes

DavidM — Sat, 28 Nov 2009 05:03:34 +0000

One of the major problems these folks have is change-related incidents. They currently roll a change package every couple of months with too many problems because they don't have full relationship information regarding the changes and existing services. They can't easily identify the services that flow through a particular CI or all of the CIs used end-to-end to support a given service.

I have no idea the nature of the business of your 300K client or how many changes they put into production. I do know these folks have to get to change packages per month to support dynamic nature of their Web-based business.

Which means... it's not the number of employees, nor the number of CIs. It IS the complexity of the way services are used, updated & changed. This means raw numbers are potentially not a measure of anything, the key is understanding relationships and complexity.

David

Simple answer: yes :-)

DavidM — Sat, 28 Nov 2009 04:53:48 +0000

They're building a Service Catalog on top of the CMS, so yes. Automated discovery, manual relationships.

David

Configuration Management Function

skeptic — Fri, 27 Nov 2009 19:57:00 +0000

Great point Ken (we missed you)

The only thing I'd change is to ask "What Questions Should Your Configuration Management Function Answer For You?"

(yes it's a function: staff, policy, procedures, tools, metrics...)

The function comes first. Once it has - as you point out - a reason for existence, then a later step is to work out if we need tools and if so what.

If we start with a ~~process~~ activity and get people doing it and we measure it then we will find the points in the ~~process~~ activity where it is not efficient or effective enough (they are too slow to produce the required outputs; they make errors; it requires too many people to manage the data...) and THEN we work out what tools we want, with very specific requirements specified already. that might even mean a CMDB occasionally

Back To Basics...

kengon — Fri, 27 Nov 2009 18:14:53 +0000

Skep,

I like this thread, as I think it's covered a lot of important ground. However, I still think we can go back even farther. How about to the beginning? Addressing the requirements. I recently gave a presentation on BrightTALK entitled "What Questions Should Your CMDB Answer For You?".

I will not even attempt to summarize almost an hour of slides in two sentences, but I think the whole CMDB conversation has de-evolved over time and it warrants our revisiting what we're out to accomplish. I believe that if you're not clear about the questions you're trying to find answers to, then the value of any CMDB/CMS initiative is sufficiently questionable to warrant deferring until the economy recovers and you have "money to burn".

Until that time, organizations can focus on gaining clarity about and designing/implementing relevant structures to get what they really need. BTW, it doesn't need to be complicated, expensive or packaged as a "product".

kengon

Interpretation of automated results

Charles T. Betz — Fri, 27 Nov 2009 14:14:53 +0000

Is part of their responsibility to interpret and translate the automated results into business-meaningful services & components? I've seen a need for that on the software discovery side in particular (ongoing fingerprinting). Also when confronted with an impossibly complex dependency map generated by some tool.

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

Homemade tools not a good idea

aroos — Fri, 27 Nov 2009 09:52:58 +0000

The problem is not the building but the maintenace part. It is not a one time project but a continuous effort to keep the system up and running. In a home-made solution, there is only one customer to pay the development. It will not make sense in the long run.

Aale

most of the essential impact analysis most of the time

skeptic — Fri, 27 Nov 2009 08:13:00 +0000

One client I recall had - i think - 300,000 CIs. They had two configuration people, and tracked only the key relationships and only for the top 12 services. They had all the network/hardware (discovered) and some of the apps and databases and not much else. They did it manually, in CA Unicenter NSM. (the world is awash in tools to relate services to CIs, you don't need to build one). It was enough to do most of the essential impact analysis most of the time. 80/20 rule, business expediency rules. That was a pretty big site, tens of thousands of employees.

We started there, but...

DavidM — Fri, 27 Nov 2009 05:02:12 +0000

We started there, but the problem is getting the compliance without the cultural readiness. Part of the reason for the 40 people (about 28 tasked with managing the CIs the rest with building success teams and working on the cultural, compliance, and organizational issues.

The manual plan was to start with the success teams, first, then add the CI people over time.

Instead, they just going with the success team and an automated system. As the CMS gets up and running, part of the success team responsibility will include audting and verification.

Part of what they discovered, is that the complexity of the configuration items and services. The problem is understanding the relationships between the CIs and services as a part of doing a risk analysis for change management. Very often the people doing the development work don't full appreciate the live environment. What they discovered is that even with the 40 pepple they'd eventually get to a point that they have to develop a CMS, anyway. So the issue was... well if that's the case, then why not start there.

David

Company stats

DavidM — Fri, 27 Nov 2009 04:52:16 +0000

The company has something between 400 & 500 employees in the US (which is also where all of their IT lives) and another 200ish outside of the US.

The problem isn't the size of the company, it's the number of configuration items they need to track (lumping hardware, software, services, and in some cases people with specific certifications like Cisco in what constitutes a configuration item). Lots of hardware and software (in the 7K area, closer to 8.5K if you include licensed software and over 1100 services). It's the complexity of dealing with reasonable change management, catalog management, portfolio management, identifying relationships, making sure everyone has the information needed.

They're not sure that 40 people will be enough. They have to partition the CI space into what they hope will be manageable chunks -- but this is all the business side would authorize. Basically the biz side was shell shocked at the staffing increase. It took a week of meetings with the Executive Management team and another 3 days with the board. It was the inherent risk in the manual solution that helped justify the expense for the CMS.

David

Invite available if you want it

DavidM — Fri, 27 Nov 2009 04:39:50 +0000

Rob,

Tagging on to Aale's comment. I have invites available for Google Wave and will be happy to send one your way, if you'll use it.

David