The IT Skeptic - Comments for "Some ITSM technologies are a no-brainer"

Some of the tool-enabled

Tom 1972 — Tue, 28 Sep 2010 07:08:52 +0000

Some of the tool-enabled things are less glamourous Ops things but valid nevertheless.

Security & Access Mgt. I'm no security guru but tools can help prevent SPAM, viruses and manage access.
Service Request & Access Mgt. Many companies spend too much money resetting passwords so a self-help tool might help.
Request Fulfilment. SW distribution hasn't been done with men in vans and disks for 10+ years.
Release Mgt. SW distribution & patch mgt tools should help.
Knowledge Mgt. Some sort of shared, searchable Kbase is helpful too. Maybe.

Lastly, some companies waste money buying software they don't need so some sort of SW inventory mgt tooling can help.

the 5% Club

skeptic — Sun, 26 Sep 2010 21:15:00 +0000

We are as usual debating terminology :)

Many tools provide some relationships, i.e. subsets of what ITIL defines as CMDB.
SDLC tools link the CIs of an app down to a very fine granularity - the Build, and link versions to environments.
Network managers auto-discover all sorts of linkages of network CIs.
Inventory tools auto-discover the contents of server hard-drives.
Procurement tools link assets to owners, suppiers etc
Operational monitoring tools manually (or sometimes automagically) link services to apps, apps to servers, apps to databases etc

None of these is a CMDB. According to ITIL, CMDB is the uber-repository of all information, exactly as Repository was supposed to be, or in the new CMS vision it is the uber-federator of all information, exactly as X500 was supposed to be. If you have one of that list of CMDB subsets above, or its ilk, you are in the 100% Club. If you can justify the costs of all the coded integration and feeds - and all the manual discovery and maintenance - to get everything in one place, then you have a CMDB and you are in the 5% Club.

Just to clarify some CMDB questions

Charles T. Betz — Sat, 25 Sep 2010 13:48:40 +0000

So, you are saying that only 5% of organizations would see ROI in the basic mapping of applications (not even going to a "service" concept) to servers.

Let's consider the likely cost of this. First you would need, not a general purpose CMDB, but at least three tables in a database. You've already said that the Asset table is OK. I myself have seen many organizations of many sizes also have an "Application" list. Relating servers (between one to ten in smaller shops) to a given application takes (in my experience) on average an hour of SME work to baseline (perhaps with support from an analyst, so 2 hours total) , and perhaps an hour a year (combined) to maintain. These are conservative, by the way; most can be done more quickly.

You also have some marginally increased costs on the Asset tool but I think these are negligible.

These 3 hours a year need then to be balanced against

1) the requests that the SMEs would receive in the absence of this data being collected and maintained,
2) the risk that is run in NOT understanding application dependencies in the event of Incident or Change (remember, without doing this you only understand that you are changing or troubleshooting a server, not even the application running on it)
3) the value that might be lost from not tracking this data over time and using it as an accurate input into IT Portfolio decisions

Of course, if you have an Asset tool that is integrated with your Incident and Change systems, it likely is more robust than just a list. "Related Asset" was a Remedy construct before the CMDB concept came into the picture. I think I have seen it in pretty much all the related tools.

Now, terminology may be hanging us up here. I thought you have also said that it is essential to see what Assets support a given a Service. Humor me by substituting "Service" for "Application" in the above arguments. Do we not need to know what Service is affected by a Change? And is not the relationship between a Service and an Asset, a "Dependency"?

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

if there is ROI

skeptic — Sat, 25 Sep 2010 08:47:28 +0000

An asset tool is just a list. The relationships are the hard expensive bit. If there is ROI, go for it. And if there is ROI, welcome to the 5% Club.

Trying to figure out when CMDB crosses the line

Charles T. Betz — Sat, 25 Sep 2010 06:19:43 +0000

Rob,

You are ok with an integrated Asset tool to which Problems and Changes can be linked...

Are you OK with that Asset tool containing Applications as well as Servers? For example? (Considering Applications as a sort of logical Asset)

Would you be OK with those Applications being mapped to the Servers? (Many to many relationship)

If all of that is OK, I think you do support at least minimal CMDB. And it's not that hard or expensive to get to.

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