The IT Skeptic - Comments for "Top 10 reasons NOT to implement CMDB"

enhancing my cahoonas

skeptic — Wed, 18 Jan 2012 08:59:44 +0000

You haven't said anything to enhance my cahoonas.

I'm well aware of IT is a service to the business - you might like to read my book Basic Service Management if you doubt I have grasped the concept.
And I'm well aware of the importance of relationship information. My challenge is around how one manages the relationship data and in particular how much one invests/wastes on automating that management.

I don't doubt that GE, Boeing and the UK Police can cost justify a CMDB. I'm quite sure the complexity of their environment makes some automation essential. I'm sure GE and Boeing have the cash for one too. The UK Police less so. I've worked for NZ Police - I know the complexity of their environment and the paucity of their funding. Despite British imperialism I doubt your coppers are any better off proportionally. But no doubt they are big enough to find a few million in a drawer somewhere. I call such organisations the Five Percent Club. It is very impressive that you work with them but I don't think that has much relevance to the other 95% of us who

don't have enough money for a CMDB
even if we did have the dosh, the cost of a CMDB far exceeds our cost of the errors and delays in managing the relationship data manually in human repositories: there is no ROI
even if we can raise a decent business case for automating relationship tracking, there are more pressing demands on our limited funds
even if we are awash with money, we don't believe CMDB automation works well enough to solve the problem.

One day CMDB will be an affordable product that comes out-of-the-box, that doesn't require integration, reconciliation, and manual linking of logical concepts. [If you are a vendor who wants to claim you have that now, don't do it here - I'll be very very rude.] I look forward to that far-off day.

In the meantime, you 5-percenters and you poorly-supervised geeks who get to play with this stuff can continue to shovel money at the problem until you learn the answer. But please leave the rest of us - the huge silent majority rest of us - alone to manage relationships exactly the way we do now, and cut this macho my-CMDB-is-bigger-than-yours crap. Yes very impressive toy, now go away.

Stop thinking in just IT terms

Visitor — Wed, 18 Jan 2012 06:42:41 +0000

You want a real CMDB, Real Knowledge Mgt, etc. Have the cahoonas to start with the real issue. Document strategy, capability, process, information and technology as a service and your IT relationships must come out because you actually start to measure how strategy drives projects, capabilities, processes, etc as KPI's. i.e. IT is a service to the business NOT a business in itself. GE has them, Boeing has them and here is a Police enterprise model including links down the applications. http://pra.npia.police.uk/

Troy DuMoulin said

skeptic — Fri, 03 Aug 2007 08:59:08 +0000

Troy DuMoulin said

I continually see claims on the internet about the CMDB such as:
It would cost way too much money and we could never justify the business case
It would be far too difficult
It would be much to complex
It could never be in one single database (who said it should be)
We would never have the political ability to achieve it

I'm egotistical enough to think he is refering to me, among others but not many. Unlike Troy I'll give you a link so you can read both sides of the argument and draw your own conclusions.

All I'll say in addition to the original post is that "You Cannot Manage What You Do Not Understand" is such a fundamental assumtion behind lots of methodologies, and like all axioms it is open to challenge. I'll do an article on this some time soon. For now let me just say You Cannot Manage What You Do Not Understand? Try managing people. We achieve this all the time but things staff think or do often remain a mystery.

I don't think Troy has answered the fundamental challenge. He agrees that CMDB is difficult. He avoids the question of how often the significant investment in overcoming that difficulty is (a) cost justified and (b) the best use of scarce resources.

Service

Visitor — Sun, 29 Jul 2007 14:56:13 +0000

There are far more than four definitions for Service. A google search, for example, easily turns up more than fifty. The problem is that most are, at best, Class-B definitions. They are easily understood and are somewhat useful in a general context. But while the layman may walk away with a general understanding of the topic, a serious practitioner attempting to apply the definition would have trouble doing so properly or with rigour. They risk undermining the process of derivative works and likely introduce downstream errors.

The v2 definitions (and most of the others in the IT industry) fall under this category. They are easy to digest but make for a flawed foundation when deriving a service catalogue, service portfolio or fully articulating value creation.

The v3 definition, while certainly a mouthful, is intended for serious practitioners, researchers, theorists and students of service management. It isn't a definition for the whole service sector (hairdressers, waiters, etc.), only those in a business and IT context. There does not exist, by the way, a pithy definition of Service for the whole service sector. There are good reasons for this, reasons which explain some of the problems of IT.

As a side note, I can't help but notice some of the difficulties with which SOA struggles can be attributed to Class-B definitions.

Service catalog? What is a service?

avallesalas — Sun, 29 Jul 2007 00:29:27 +0000

Charlie, Skeptic...

first we should agree on what is a service. I've seen at least 4 different definitions about what a service is. The most impressive and vague is that extracted from the ITIL V3 books, where a service is anything we provide to a customer and for what that customer does not assume risk and costs...

then we have a definition of service in ITIL V2, something like one or more IT Systems that enable a business process, then we have the CMMI-SVC definition, and lastly, I think that ISO 20k or BS15k have a service definition.

So, if we don't agree on what a service if, how can we agree on what a service catalog is? (for example, consultancy or training is not allowed in an ITIL V.2 definition-based service catalog, but it is fully allowed in a CMMI-SVC definition-based Service catalog)

Regards!
Antonio

Application info is generally useful

skeptic — Sat, 28 Jul 2007 20:26:18 +0000

Yes. I forget the terminology but V3 has adopted the concept of the two layer Catalogue: one to sell* to customers and one to guide IT staff. Application info is generally useful in a brochure so people can relate it to their own perspective of IT which is via the Apps. It is useful in a technical catalogue because Apps are almost always key CIs for a Service.

* though as I said in a recent article, Service Transition is much too light on the concept of selling

Agreed

Charles T. Betz — Sat, 28 Jul 2007 18:45:55 +0000

This is the kind of poorly considered marketing hype that is rapidly giving CMDB a bad name. There are a multitude of distinct systems required here, which for good reasons of cohesion and coupling should *not* be considered as a monolithic whole. Drift control as Skeptic correctly notes is intrinsic to the class of element being managed.

Skeptic, in your evolving concept of "Service Catalog," would you agree that minimally it should include Applications (as a subtype of Service) and their dependencies upon servers, databases, and each other?

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

Ten reasons not to implement a CMDB

Visitor — Sat, 28 Jul 2007 12:38:05 +0000

Skeptic, you are correct this article smells of a vendor who cannot get a CMDB together...

The IT Skeptic - Comments for "Top 10 reasons NOT to implement CMDB"

enhancing my cahoonas

Stop thinking in just IT terms

Troy DuMoulin said

Service

*Service* catalog? What is a service?

Application info is generally useful

Agreed

Ten reasons not to implement a CMDB

Service catalog? What is a service?