The IT Skeptic - Comments for "How long can they beat the CMDB drum? What is the next fad?"

ok Charlie I bought your

moheen — Tue, 23 Oct 2007 12:28:57 +0000

ok Charlie I bought your book (been meaning to for awhile). COnfig maturity model looks good, I will expand on it for use internally, thanks alot.

excellent book btw, haven't read it all just yet, but impressed so far. Only shortcoming (and maybe I just didn't get to it yet) is coverage of the practical side of aligning time accounting with resource planning stuff

Having onboarded many

Charles T. Betz — Sun, 14 Oct 2007 14:10:50 +0000

Having on-boarded many staff from various backgrounds, I firmly believe in the value of CMDB-type tools (in their guise as Service Knowledge Management enablers) to get these people bootstrapped and productive. I'd rather not have them figure out the environment from scratch.

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

Won't drive top line, may drive bottom line

Charles T. Betz — Sun, 14 Oct 2007 13:44:41 +0000

CMDB won't drive top line revenue, but it may drive bottom line profit. IT cost avoidance is a valid business case, one that I have successfully made for CMDBs. The non-financial balanced scorecard objectives (process view, customer satisfaction, talent management) are also valid - especially with respect to service availability, which often cannot be represented as a financial goal. (And yes, I have heard that balanced scorecard is also becoming passe; let me know when something better for representing intangibles comes along.)

There is nothing fantastic or ivory tower about a CMDB. CMDB is simply a logical incremental step past an Asset system. Why are we turning it into this monster to be slain? It's just a question of properly scoping and designing some data and system architectures to support a business process (the IT service lifecycle itself, in this case).

The simple fact is that when IT operations are large enough they require their own supporting infrastructure, just like HR, Finance, Legal, Contracts, or any other back-office overhead function. I'm sure you've seen a number of vendor, contract, and asset management databases; those are the IT systems most closely associated with sourcing (along with the project management system in many cases). Are these systems mere IT playthings? What happens when you have 500 vendors selling you 4000 software products and expecting you to manage the licenses, or else you'll get a call from the BSA?

And the CMDB *is* relevant to such things. A simple Asset database tells you that you have 200 Oracle licenses. But when (e.g.) Oracle 9 goes off support, you still have to scramble and go figure out what systems are dependent on those licenses. The CMDB, if correctly implemented, tells you this with a report.

The main problem is that, even in the wake of ITIL v3's call for a "Configuration Management System," and much discussion around the concept of federation, the discussions on this board still view the CMDB as a monolithic entity. See this post, which is just a taste of chapter 4 in my book. You'll find 78 vendor-neutral pages there discussing the various types of internal IT systems supporting service strategy, design, implementation, transition, and operations, as well as how they need to be integrated in support of the IT value chain.

If IT is prioritizing its own needs as a whole at the expense of the business, a big part of this is the purchase of redundant, non-integrated technology by operations, security, portfolio management, enterprise architecture, vendor management, and other teams. See A Story of Too Many Tools. I'm much more concerned about these dynamics, which arguably a centralized CMDB can help mitigate.

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

CMDB (aka The light on the hill)

vaioboyaus — Sun, 14 Oct 2007 11:42:02 +0000

Although I believe that the implementation of a CMDB is a fantastic aspirational goal, akin to politicians wanting full employment, it is one that should be approached carefully and with an eye on the end game. That endgame should be what works best for the organisation.

Having spent almost all of my career in the IT ivory tower, I have spent the last two years in Sourcing specialising in IT & T procurement. The one fascinating thing I have seen is IT's propensity to peddle its own case at the expense of the business, spending money on things that are at best outsourced and add absolutely no benefit to the bottom line. As I become more disillusioned with the ability of IT to align itself with the Business, the business sees this as IT believing it is in some way part of the revenue gathering activities of the firm rather than a service functions that enables the revenue gathering activities.

To that end, will a CMDB when implemented in any of its guises send any money to the bottom line or enable the firm to sell a few more widgets, or acquire a few more customers to sell a few more widgets to. Any thing else fails to seed benefit or a return on money invested. To put it more simply, a TV station would rather spend $100K on a new camera than spend $30K on an IT service, when you understand that you understand the way your masters think.

VaioBoy

The IT Swami predicts an influx of Filipinos and Indians

skeptic — Sun, 14 Oct 2007 06:05:02 +0000

Good point, but a problem that applies across IT, not to CMDB alone, so however we do CMDB we will still need to address the people shortage.

The IT Swami predicts an influx of Filipinos and Indians. These English-speaking, hard working, obedient university graduates are about to give the spoilt self-indulgent Gen-X and Gen-Y brats a fright, just as soon as the Western nations buckle under and give up our racist immigration policies before our economies crumble.

In the industrial age we sucked out the third world's primary resources. In the information age we'll suck out their best and brightest.

And what was #1?

Charles T. Betz — Sat, 13 Oct 2007 14:44:42 +0000

The talent pipeline.

There is some CMDB value to be found in considering the impending mass exodus of qualified personnel from the workforce... not a panacea, but perhaps at least a framework. Those who advocate the "human CMDB" point of view - will we even be able to hire enough of them?

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

I don't see this trend

Visitor — Fri, 12 Oct 2007 11:10:37 +0000

I don't see this trend abating. Personally, I think CIOs (generally) brought this upon themselves. Particularly in the manner by which they define their roles. The list of priorities in the article was particularly telling (Biz/IT alignment, Staffing, Antivirus protection, networks, BPM, continuity planning and disaster recovery)

Notice a pattern?

Hint: I notice a resurgence in the CTO. My personal observations have them reporting increasingly more often to the CEO.

Flawed analogy

Visitor — Fri, 12 Oct 2007 10:49:06 +0000

To be a bit of a stickler ... your analogy doesn't hold. Big and centrally controlled economies can and do work. Just ask General Motors and China, for example. It was precisely this economic riddle which led Ronald Coase to the idea of transaction costs ... and the Nobel Prize.

And ITIL has distinctly evolved from Taylorism and the warmed up Scientific Management of V2. Mr. Taylor would have burst a vein at the implications of the service lifecycle: There really is no "one best way."

I also seem to recall a nice post on this board about the perils and paradox of empirical evidence...

ITIL plays to the same

Visitor — Fri, 12 Oct 2007 06:19:25 +0000

ITIL plays to the same appeal that makes communism sound so good in theory. Cenralised management of change/Centrally planned economies. You are trying to make a broken model work because your intuition and taylorist upbringing make you believe. Not because of any empirical evidence to the contrary.

Fewer CIOs are reporting to CEOs

Cary King — Thu, 11 Oct 2007 17:20:00 +0000

Fewer CIOs Are Reporting to CEOs, Survey Finds

http://www.baselinemag.com/article2/0,1540,2193506,00.asp?kc=BLBLTEMNL10...

Aligning IT and the business, which has been a major challenge for CIOs for more than a decade, was No. 2 on this year's list—as it was last year.

Not always true

Visitor — Sat, 06 Oct 2007 22:57:53 +0000

Operational and managerial discipline may seem like a truism but management thinking has come to understand this is not always the case. It may sound counterintuitive but there are even situations where it leads to failure. You can find a few of the reasons (with case examples) examined in Clay Christenson's Innovator's Dilemma.

progress of cio's as trusted businessmen

Cary King — Sat, 06 Oct 2007 22:20:00 +0000

Nick Carr disagrees:
http://www.roughtype.com/archives/2007/10/twilight_of_the.php

And, the most recent CIO mag survey reveals that only 42% of CIOs report to the CEO.

If IT wants to get respect from the rest of the business, then IT must start to run itself like a business. Businesses make an effort to know where their materials costs come from and what the cost of their products are. Those that ignore IT financial management and IT asset management (assets and their associated account for more than half the costs) do so at their own career risk.

Lots of Changes

kengon — Fri, 05 Oct 2007 17:57:39 +0000

I've seen more than a few such realignments in a number of the customers I work with.

In at least two I can think of, the departure of a CIO (immediately prior, for various reasons) was closely followed by the change in reporting structure to the CFO. In each case, I know that the CFO's were fans of the cost center approach than other alternatives.

I think the heads of IT organizations are still far from getting the point about the connection to finance and it shows. The connection to value isn't being made... and IT pays a high price for that. Until this is addressed, I believe we're going to see this trend continue.

Walking the tightrope

Paul Wallis — Fri, 05 Oct 2007 17:30:00 +0000

Gentlemen,

Rather than watching your always interesting discussions from the sidelines as I usually do I'm going to contribute to the debate.

By opting for a CMDB you opt for change. Existing processes which define the IT Service to the business will need to be changed in order to utilise the CMDB otherwise the data will become out of date, meaningless and create problems rather than solve them. Process change affects people and this takes careful planning and implementation if it is to succeed. It provides a huge opportunity for failure should it not be delivered effectively.

On that note, it is worth pointing out that a CMDB is focused firmly on IT, not business. Sure there are some business benefits to be gained, but only as a consequence of CMDB implementation forcing change on the management and delivery of IT. The great hope is that these changes will improve IT service, consequentially allowing IT delivery to become something that "just works", allowing IT to have more constructive conversations with the business.

But, you are walking a tightrope with very little in the way of a safety net. Fail and you risk heading for an expensive fall, causing the rift between business and IT to widen even further.

My blog, "Are CMDBs worth the trouble?", at www.keystonesandrivets.com discusses this in more detail. You may also be interested in my assertion that "IT exists for one reason."

IT costing

Benzo — Fri, 05 Oct 2007 10:58:41 +0000

".........that the trend to having the CIO report to the CFO continues to increase"

A little correction is in place. IT reporting into CFO stemms from early days computing where the bookkeeping -and later other accounting- functions were the first to be "automated". The CFO, no insight in computers and programming, was easily convinced that the requested budget was necessary as long as his books were in order and up to date. In those days, most senior managers would be proud to state that they "don not understand a thing about computers and programming".

I think that IT has grown up and is more cost conscious. However, in many organisations, the outdated reporting lines still exist. Many CIO's feel comfortable sitting close to the trough as a proposal approved by the CFO is most likely to make it unchallenged through the Board meeting. The CFO is happy as he is seen to control a much larger budget than he otherwise would have. Many CEO's seem not to understand the games played under their noses.

Its good to have a stretch goal

buraddo — Thu, 04 Oct 2007 18:31:01 +0000

I can see no problem in pushing the CMDB concept, and long as nobody takes it too much to heart and foolishly tries to implement the damn thing.. At least not with the current state of CMDB products.. I haven't seen many organizations implement a unified data model for across internal customer and organization data. IT Service Management data and the infrastructure supporting it is infinitely more complex as for every data field defined in a application there must be 100's of possible CI's..

My golden rule is to use the concept provided by ITIL as a template for guidance and execute based on a real problem and measured goal. Utopia views and the software vendors who tell you they can execute will soon get back to reality if you manage to do that..

As always, I discussed CMDB's in my blog a little while ago..
http://blogs.sun.com/buraddo/entry/cmdb_six_degrees_of_separation

Agreed..

Visitor — Tue, 02 Oct 2007 17:34:55 +0000

Regardless of the money spent, the consultants engaged, and the technology purchased, if an organization lacks operational and managerial discipline, they will not perform well.

know yourself 1st...

John Worthington aka MySvcMon — Tue, 02 Oct 2007 13:40:00 +0000

I've had this rant before in CMDB Kool-Aid can result in a Bad Trip so I won't spew too much more other than to say if you're not sure how effective your 'CMDB' needs to be to improve matters then look in other areas!

Personally, I agree with you that monitoring tools should be more of a focus of conversation. I'm continuing to use a tool that collects measurements from every layer of every component in an n-tier infrastructure (ERP, Citrix, VMware, whatever), learns the norms of all collected metrics, and automatically isolates which layer of which component is the source of the anomaly. It also has a unique web based architecture that provides personalized views for each domain, and can be quite effective in that nasty paradigm shift people need to make (whether they want to or not)...

The vendor really doesn't care about ITIL (they're not much into marketing), but from what I continue to see this is an area customers may want to look into. If it's not an ITIL-based 'CMDB' then maybe (horrors!) I don't need one...

Some of the big gorillas have put a big toe in these waters, but in their quest for ITSM nirvana I'm afraid that the 'integration' they seek will dilute these benefits to the point of, well, missing the point...

I feel better now.

John M. Worthington
MyServiceMonitor, LLC

Targets

Charles T. Betz — Tue, 02 Oct 2007 11:33:46 +0000

I'm a bit concerned about the way you've framed the question, which (if I can boil it down) seems to argue that CMDB is either trivial or unattainable. There is a middle ground of worthwhile work.

Spreadsheets are problematic, because they don't support many to many or recursive relationships, and usually allow unconstrained data entry rather than enforcing data domains (e.g. predefined picklists). (See pages 208-212 in my book for a very detailed case study.) You'll find that at scale many application and infrastructure teams start to build redundant little MSSQL/MySQL databases characterized by the following major entities:

Application
Database/Datastore
Server/Host
Machine
Component
Service
Cabinet/Rack
Business Function
Business Process
Queue
LPAR
Region
Subsystem

and a host of intersection entities to relate them. Such systems (of which I have easily seen a dozen across a number of large organizations with a combined total IT spend of $3 billion) are often duplicative (the server team has one, the DBAs have one, and the application engineers have one, each with slightly different focus and overlapping data). And, they are generally NOT tied to the incident or change processes. That is the opportunity for CMDB.

What are some measurable objectives?

- Reduce/eliminate unsuccessful changes where the lack of success can be attributed to poor impact analysis. This of course means you need to do some analysis of your unsuccessful changes and figure out whether a significant proportion is due to poor impact analysis. Identifying changes to chronically troubled CIs, and overlapping changes to the same or closely related CIs, are some of the benefits.
- Reduce time to recovery where the outage is prolonged by inability to identify upstream contributors to the incident, or identify needed SMEs. Again, you need a baseline to determine if there is ROI there.
- Support higher-order objectives such as capacity and financial management. This boils down to "are they using my data?" If so, you have a clear business benefit to report. The ROI can be measured by assuming that without the CMDB, they would have to maintain the data on their own, and application portfolio satisfaction measures can and should be applied ongoing to ensure the CMDB system continues to provide utility.
- Redundant re-surveying. Go and ask your application teams how many spreadsheets came across email that they were asked to fill, starting from a blank template. Then go to the project managers that drove those spreadsheets (compliance, server consolidation, data protection, etc) and estimate how much they spent on that research. Right there is a business case. At a higher level, you can do a sort of wideband Delphi: ask your senior execs to estimate how many applications there are, and for each application, how many hours per year are wasted in capturing data that was once understood - then average their estimates. If the Wisdom of Crowds thesis is correct, you've got a reasonable cost avoidance case right there.

There is also a master data management problem at issue when spreadsheets or redundant databases are allowed to proliferate, and definite benefit in solving it if you want consistent reporting across the IT organization. Talk to your local business intelligence/data warehousing professional.

Skeptic and I disagree on some issues here, but one thing we do agree on is that CMDB is probably only worthwhile for larger shops, I would say at least $50-100M IT spend a year, if not much more. Fortune 1000, at least. Smaller than that, and perhaps the spreadsheets are OK. Larger shops, highly regulated shops, or highly distributed shops need something more robust.

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

Keep going!

kengon — Tue, 02 Oct 2007 00:17:57 +0000

Visitor,

I like the direction you're going and encourage you to keep going. If the construction of your CMDB initiative doesn't clearly establish value, you're likely to be left with just another stale data source.

In your last post, you write:
"Using a CMDB which only encompasses apps/DBs/servers doesn't seem realistic. Staff won't use it because they've got more reliable excel spreadsheets. It then becomes a pretty toy. It is not enough to offer an impact analysis capability, it has to offer a capability *better* than the existing way. If my target aim falls short of that level - no matter the competency of staff or executive support - then it will be seen as a foolhardy tool. Without a target, I have no choice but to do it 100%."

In a way, it seems you're answering your own question. It very well may be that for your unique circumstances, what you have is sufficient for right now.

My two cents:
1. I'd vote for a first (next?) iteration that was tied to what's needed to "get the job done", whatever that looks like in your organization. There's some work to do on your part to get there. Based upon that work, have whatever collection of data makes sense for that.
2. How do you know if it makes sense? Well, I'd attempt to do some sort of table top simulation/exercise that will help you "smoke test" it and see if it holds together well. Does it help you answers the questions you need answers to? If not, it's likely that you've identified a significant gap to address before moving forward.

kengon