The IT Skeptic - Comments for "CMDB is crazy talk"

While we're on the topic of "land grabs"

Charles T. Betz — Sat, 19 Feb 2011 15:57:29 +0000

Here it is from the other side:

http://www.redmonk.com/cote/2011/02/16/the-developer-landgrab-another-wa...

My money is on the development community.

Cloud has no impact on ITIL

ianclayton — Wed, 05 Jan 2011 09:39:26 +0000

Cloud computing has no DIRECT impact on whether ITIL lives or dies beyond reminding us all of what the business and end user customers have required of IT for a long, long time. Cloud computing is a valid option for any IT organization - in fact most run some form of hybrid cloud computing environment today! Just step back for a moment - if you have your corporate email with Google - its been clouded...

ITIL is there to be leveraged - IMHO its the professional who is unable or unwilling to recognize where ITIL is strong and weak and plug gaps with other references and their experience, or who allows a customer to or organization to misunderstand what ITIL is and can do to help an ITSM initiative, that will be its downfall.

Cloud is not a fad - its a viable option and the term is being marketed daily into every living room by companies such as Microsoft and IBM, the former wrapped around their latest gaming systems. ITSMers need to get ahead of this as Cloud reflects a burning desire by customers to punt on the risk and costs, and get to the nirvana of utility computing where you pay for what you use and can shop around. Security issues will get resolved because the community demands it and it will lead to revenue for those who truly offer a risk free cloud option.

Given ITIL's gestation cycle its unreasonable for any professional to think it will contain the entire answer at any moment in time. Its a valid contribution. So it will survive, but become less strategic over time as an increasing number of sources are available and trusted.

Another old blog article here from me on this that lists many of the 'benefits' the business expected of ITSM, ITIL and now Cloud... A href="http://ianmclayton.com/?p=601">Every Cloud has a Silver Lining

A matter of degree

aroos — Wed, 05 Jan 2011 08:13:17 +0000

I suppose this is how we look at it. Yes, it is useful but...

I'm have been an ITIL trainer and consultant and nearly all my customers are in an outsourcing situation so yes; parts of ITIL can be used succesfully in that situation. On the other hand, a lot of ITIL guidance is less useful. Changing ITIL has become hard as a result of its success. It has been translated to several languages and there is this enormous certification training industry which resists all change which endangers their investment in training materials etc.

I'm not really not so interested in what happens to ITIL but I'm more interested in finding useful guidance for ITSM which is not based on 80's mainframe service context. This is how I see a typical current ITSM situation. Application, IT infra and network come from different sources and there is no single provider who has complete control. There are several players in the game and all of them need to manage their IT services. Cloud will bring new elements to the game.

Aale

cultural chasm

skeptic — Tue, 04 Jan 2011 19:21:00 +0000

Your ideas are always interesting Tim - I jumped on one phrase there. I'm always interested to thrash ideas - there are many more folk out there where I'm one of the people they'd like to thrash.

You need to talk to Charles Betz too - we've debated the idea that app owner owns the service. Breaking down the development/operations cultural barrier is a good idea, but it is a genuine barrier. Hence your use of the term "landgrab" showing which side of that fence you are on :) Until we find a way to break that down, we must work within its constraints.

P.S. My organisation has a staff of one - me. I work for multiple clients with their IT staff varying from 0.5 to 500.

ITIL should change to deal with Cloud

skeptic — Tue, 04 Jan 2011 19:10:55 +0000

I completely agree that ITIL should change to deal with Cloud situations. But I disagree about how much change is required - or more precisely that ITIL cannot change enough and is therefore dead. ITIL is used successfully in many outsourcing contexts already.

ITIL has a momentum. perhaps something new will take its place but not necessarily. Way back when the IT Swami made seven predictions about the future of ITIL, one option was synthesis with something else, and another option was a long life in slow decline.

a less exagerated perspective

Tim — Tue, 04 Jan 2011 11:51:33 +0000

I was overstating the point for effect :-) Actually, since I stumbled across your blog a few years ago, I think that you're one of the people that I'd like to thrash through my thoughts with.

Of course your examples continue to be important. My point is more that consideration of these elements need to be owned by the applications people (who should understand the wider context of how the apps are used - by app, I mean things like whatever's meaningful to a business user). My experience is that the separation between building apps and running them is counter-productive and, I believe, a major source of additional costs in operating the IT function.

Although ITIL's made a land grab for IT governance, I'm not convinced that it's actually a useful direction to come from. This point of view may come from my background, but I don't think so. My background is in large scale architecture, and our biggest challenge in transformations or putting in place actionable governance was getting a view of how the IT systems hang together on a continuing basis with a view to any form of improvement.

Let me try to restate my pov, better:

I've seen ITIL used as an approach to get control of infrastructure, production set up of applications and how the whole supports the business. A significant emphasis is on reducing operating costs (75% of the IT budget). I don't think that the common approach of a 'bottom up' approach to trying to understand the IT landscape is tractable. The opacity of how IT supports the business and poor alignment of incentives across the IT function with business objectives makes it all but impossible to get effective control (eg you cannot have effective vendor management unless you understand the costs and benefits of what each vendor delivers to the organisation; much of the IT budget is wasted on products and services that actually destroy value - and I've got lots of examples of that).

My contention is that (IT) application owners should be given lifetime responsibility for the applications. The model that I encounter, those responsible for building enterprise apps usually quickly scope out the main issues relevant to the operation of the system as they strive to meet project deadlines and costs. In the worst examples, they ignore non-functional requirements for business processes and apps altogether (eg RTO, RPT, expected rate of change). What they build is then not what is implemented in production, and much effort and cash is wasted post implementation trying to meet non-functional expectations from the business, based on a poor understanding of how the application should or does consume resources. I've measured 98% capex wastage on such efforts. Eventually, some underlying component falls out of support and a major re-implementation must be undertaken.

I believe that the lessons from internet scale apps of ensuring that the app can be deployed automatically, and that automated test coverage is sufficient does enable a new way of working.

I completely agree with your point about understanding what you've got before outsourcing - I've got several very expensive counter examples - but, I also think that it's more productive to get control of apps from the development end and throw out the rest as fast as possible. This is not simple, nor cheap (the original development phase - 30% of an app build cost - is likely to increase by 30%, but all subsequent refactorings are simple and cheap, which is crucial as requirements change (including the changing requirements of the underlying infrastructure like COTS components going out of support.)

Based on my measurements and some collaboration from major systems integrators and benchmarkers, I believe that the change in emphasis should save 50% of the 75% of IT costs spent on keeping the lights on, and be self financing.

If you're interested, I'm keen to discuss this offline, as I value your pov. It may just be that your organisation is already more sensibly set up than those that I've encountered.

Tim

Don't confuse need for management with a method

aroos — Tue, 04 Jan 2011 11:03:59 +0000

IT services must be managed with inhouse, shared, outsourced or cloud solutions, need for management does not evaporate but it changes. Do not confuse ITSM with ITIL. ITIL has been written mainly for inhouse and shared service centers. There is an underlying assumption of central control over things. The concept of Business is confusing in ITIL, you have written an excellent post about that earlier http://www.itskeptic.org/node/1826. It is possible to use some concepts of ITIL in any situation but the simple fact is that ITIL does not describe or apply for a complex IT service model.

There is a need for ITSM model which covers multiple outsourcing and cloud. Somebody should write it.

Aale

ITIL doesn't disappear in a puff of cloud.

skeptic — Tue, 04 Jan 2011 10:01:00 +0000

"much of the need for ITIL evaporates" - I must disagree.

BCP *NEVER * goes away. Someone is murdered in the lobby of the building and nobody can get in for three days. Hurricane Katrina hits. etc... Oh I know the Cloud magically makes our systems accessible anywhere you can run a browser, but that isn't all there is to continuity. Some stuff is still on paper, filed. people need to talk. In many businesses - I know this comes as a shock - we still have to touch real people.

Likewise Change is about more than managing build and release. Many users don't like the interface altering without warning. There may need to be training, or even changes to work procedures. What if a SaaS vendor's new version has an impact on accounting procedures?

Or incident. Many organisations find they want to keep service desk level 1 support in-house because they need staff who understand their business.

You can't outsource Risk management. or governance.

Availability is more important than ever, to match up changing demands with available suppliers.

And clearly Supplier Management becomes pivotal. Information Security becomes paramount (architecting, confirming, auditing, testing...)

And so on. ITIL isn't so much about operating systems. It is more about managing and governing them. the Cloud doesn't remove any of that, it only skews it a little. None of the need for ITIL evaporates. there is an old principle that you better have your act together before you outsource it. I'd add that it better stay that way after you do. You need to closely manage and govern external suppliers or else you are not looking after the interests and assets of your employers.

if you mean that the SCALE of ITIL is reduced, then I'd say perhaps it is theoretically possible but history shows that many supposed simplifications generate nearly as much work elsewhere to run them. usually the throughput or reliability is increased, more than reducing the workload to run it.

Outsource your CMDB problem to the Cloud

ianclayton — Mon, 03 Jan 2011 23:20:08 +0000

This CMDB discussion has a huge carbon footprint!. As I have blogged numerous times, the concept of a CMDB - is laudable. We all know it has benefit but comparable challenges. May I suggest you outsource the need to any vendor who has both a history of recommending your IT organization do this - and who offers some form of outsourcing services.

I'll not mention any names but a few years ago when this was a hot topic, a major vendor was asking a Fortune 100 company to invest in a CMDB solution - there's in fact. What had slipped by the vendor was that they already had the contract to manage all IT devices and desktops. This begged the question - as a customer - why do I need a CMDB - when its you the vendor that needs one? And - given you have been running our It for 4-5 years - I presume you have one in place and can show us it in operation if we ask?

Classic.... there is a simple test as well - grab a set of keys - different ones on multiple fobs - car, house, garden shed - and ask the vendor sales rep/engineer if they could explain how they would approach developing a CMDB to contain the information for your keys.... there are classic signs they should give as to whether they are competent or not....

CMDB vendors selling snake oil

Tim — Mon, 03 Jan 2011 22:57:22 +0000

Greg
I think that Rob's points are pretty good: if you look at how ITIL evolved, the CMDB was a concept comparable to a DB that has all of the records for running a business, but no one would consider that such a beast exists. The CMDB product vendors don't seem to understand this, but their customers don't seem to get it either.

I've seen CMDB projects that would require more people managing the data and the data model in the CMDB than running the systems. There are all sorts of philosophical problems with trying to produce a bottom up view of what the vendors identify as CIs (see how LMAX works uses Continuous Delivery). For the most part a more tractable approach is to automate the building of the apps from the ground up, so that you can at least reliably build your production systems.

A sensible CI for 2011 would be, say, 'Cloud Infrastructure', RTO would be driven by an application redeployment and failover model, rather than relying on a BCP/DR process that's only tested when it's needed, capacity planning becomes a budgeting exercise that business can actually engage in, etc.

In fact, if the capex costs of infrastructure are removed, and the gaps (eg for billing) are filled, much of the need for ITIL evaporates. The focus on service levels is still crucial, but a simpler IT organisation and fewer separations of concern make it easier to engage the business in meaningful discussions, where the app owners can demonstrate what's possible and the business does not feel like it's dealing with an group that's hiding behind jargon.

Tim

hard-nosed pragmatist

skeptic — Sat, 01 Jan 2011 20:38:24 +0000

There's a deep psychological effect at work here. tech people are as blinded by their love of technology and their quest for perfect information as any smitten youth is by the charms of his g/f. I'm sure that even amongst the small number of sites that supposedly have a working CMDB providing real value, many of those conceal one or two passionate people furiously peddling behind the scenes to keep it clean and working. I believe many CMDBs would not bear close scrutiny from a hard-nosed pragmatist manager or auditor.

CMDBs are a way for companies to bleed money.

So Greg, don't dream of still more and better technology to fix the problem - you're only digging yourself deeper. Step back and ask yourself what the real business problem is that is supposedly being solved here and then look for the real solution using a cost-effective combination of people, practices, technology and partners.

I thought it was just me

ITSMinfo — Sat, 01 Jan 2011 15:27:04 +0000

Tim,

That's funny--I thought the limitations were just the tool I was building as the engagement consultant. To be truthful, the tool did have its limitations. After inputting the CI's and relationships, the CMDB is unable to report on attributes of related CI's. (It could search attributes of related CI's, but couldn't include those attributes in the output report). Nor could it report on attributes of linked contacts sourced in LDAP (typically AD). When importing CI's and relationships, CI's will get updated, but old relationships will not get expired, for example when a device changes switch ports. Automated imports from multiple data sources, as important as they are, still have the tendency to contain stale data of various sorts that require manual intervention.

I always suspected that we were not the only tool to experience limitations. I believe most tools contain more hype than capability, and more limitations than the sales staff lead the prospects to believe. In fact, I think most sales staff are not even aware of the limitations.

It will only get harder as more servers and services move to the cloud--and only more important. I hope 2011 is the year the management tools start to catch on and catch up. Migrating this configuration data into the One True View of the CMDB may have to wait for 2012 (or never).

CMDB is broken because there is no clear 'Service' separation

Tim — Fri, 31 Dec 2010 16:09:23 +0000

I agree with you general point about the implausibility of CMDB/CMS to support ITSM. I came to the same conclusion as one of the founders of a discovery tool company.

The core issue seemed to me to be the complexity of the dependency graph for any given 'service' and its rate of change. I've concluded that the lines of communication from IT infrastructure (down to the data center) to the business owners of business processes are just too long to be useable. The huge capex costs of infrastructure with corresponding cost recovery, which is what drives much of ITSM, coupled with the incentives for vendors, individuals and groups to build play pens of various types just make the whole IT value chain too hard to manage.

IT's hard because it's too flexible and the divide between those that build applications and those that run them makes matters worse.

So why not just eliminate the concept of infrastructure (ie sharing of anything concrete) and put the emphasis of IT more on the Information and less on the Technology? How? Move towards the s/w engineering use of the term Config. Management and automate the build/test/deploy cycle on assets, not services: the application owners, designers and builders should know, control and be accountable for service levels (and take on ITSM discipline/staff). This is how large scale internet apps are now being built.

Would you expect the installation of a new socket for a sewing machine in a factory to require the electrician to know the structure of her local nuclear power plant, even though she doesn't know how/when the sewing machine will be used? That's the complexity jump that we're expecting ITSM to handle.

MCCMDBDB

skeptic — Thu, 30 Dec 2010 08:11:02 +0000

I like MCCMDBDB.

I was about to create a checklist over at BSM Basic Service Management but I pulled up for two reasons: (a) I'm trying to keep BSM non-IT-specific and (b) some folk would interpret a checklist as "you have to do all these things" or "your life is not complete until you have all these" - a checklist always implies finishing it.
[As an aside, i do think that many IT techs subscribe to the "He who dies with the most toys, wins" philosophy of cool-tech-acquisition. I think it explains many bad software buying decisions and i also think it explains the passion for CMDB].

Maturity Levels of CMDB

ITSMinfo — Thu, 30 Dec 2010 07:14:45 +0000

Skep,

As usual you are right, especially when you are making sense. :-0

Maybe the ITSM community needs to stop thinking about the CMS / CMDB as a process (which has defined inputs and outputs) or a thing or a database. Instead we can think about it as a broad collection of activities that help maintain information and documentation on the configuration of assets and software inside an organization. This isn't a black or white implementation where you do it all or you don't do any--most organizations span the spectrum of gray.

The trouble with ITIL (as if there were only one) is the concept of a CMS is so abstract that most people have trouble understanding it. This is by design--it saves the authors the trouble of actually doing anything. I still have trouble describing ITIL's take on the CMS, and I have done practical implementations in a dozen organizations.

Let's start helping practitioners in a practical way by listing and describing the various CM activities that take may take place and the benefits and costs associated with each.

For example:
- Automated discovery of hardware assets
- Automated discovery of installed software assets
- Automated discovery of network assets
- Automated linking of software and hardware assets
- Automated linking of hardware and network assets
- Automatic reporting on software compliance and unused licenses
- Linking Incidents to CI's
- Linking Changes to CI's
- Linking Problems to CI's
- Linking CI's to end-users
- Linking CI's to end-user organizations

This list is VERY incomplete, and there is no out of the box solution for any of the above. There is a wide variety of expression of CI names, CI types, attributes, and statuses of the above items. Each can be automated to different levels.

By making a checklist we can help practitioners and organizations understand what they can do, what other organizations do, and what they should consider in the future. It would be a list of available options, rather than a document of the One True Way dictated high from above. We can expand on Skep's checklist concept.

A list or checklist of practical activities could also feed into a maturity assessment.

We can call it the Management of the Configuration of the Configuration Management Database Database. Or we can call it WikiCMDB for short. :-)

The CMDB Imperative

skeptic — Wed, 29 Dec 2010 20:19:23 +0000

So does the "bible of CMDB". If ever one book popped the vendors' CMDB bubbles it's that one

This part...

CraigWilkey — Wed, 29 Dec 2010 11:37:51 +0000

"Anyone who believes they can buy a plug-and-play CMDB from a vendor gets what they deserve."

I agree with this 100%

plug-and-play CMDB

skeptic — Mon, 20 Dec 2010 20:40:47 +0000

Anyone who believes they can buy a plug-and-play CMDB from a vendor gets what they deserve. Investigate the development and ongoing maintenance overheads of integration, federation and reconciliation of data sources.