Posted: Thu Nov 29, 2007 1:02 pm Post subject: Is It A CMDB I Need?
Being new to ITIL in general, I'm slowing working my way through the materials (paper and electronic), and reading the various forum posts. A lot of good information about a lot of things.
However, my focus at the moment is a CMDB to support Change and Release Management. I think.
Let me put it this way - When the dev department receives an RFC for a new function to be put into one of our apps, there is no real understanding of the impact that change will cause. This is a problem.
So what I'm thinking, based on my limited knowledge of what a CMDB is, is to create CI's for each of the assemblies, the projects they belong to, and the solutions those projects are part of, and the systems that run the built solutions, to end up with the services that use those systems.
This way, if Joe Bloggs changes Assembly A, I can follow the path all the way up to Service A, and to a bunch of change/release management info like stakeholders, maintenance schedules, other pending changes, etc.
I'd also like to tie the CI's with the application Use Cases and Automated Testing Scripts, but that would require knowing which CI's are responsible for each function. For example, changing the format of a report wouldn't affect the logon function, whereas adding a field to a table would affect any function that involves that table (even if it doesn't use the new field), as determined by the CI relationships.
So. Is it a CMDB I am looking for, or something else?
This is a great question and though there is no straight answer to it, I can certainly give you pieces of the puzzle for you to put the picture together.
Not having a CMDB to evaluate the impact of a change is not a problem. It is a risk. It may sound like semantics, but it is actually just a very different approach. In principle, if you have a problem, you are going to try to solve it. If you have a risk, you are going to try to evaluate it. It is very different, and evaluation is the key.
Evaluate the risk and suppose that:
The app you want to change supports a business process that generates $5,000 per hour.
Changes of this nature occur 4 times per year.
If an upgrade fails, you are taking the risk of going down for about an hour before you can fail over to the older version of the app.
Each failure costs about $1,000 in overhead to produce a fix.
Failures can occur every time.
Your conclusion is that the risk of not producing an impact assessment, provided that you can demonstrate that an impact assessment effectively mitigates that risk, can cost the company about $24,000 per year. Blow this out over the useful life of a CMDB: say 8 years, and that is just about $200,000.
Now compare that number to the TCO of a CMDB over its useful life, factor in growth, etc, and you will know whether the risk is acceptable or not. Maybe that is part of the cost of doing business. Maybe whoever requests those changes just needs to understand that upfront.
The key to Service Management is not so much how you organize your process but how you think about your impact on the overall business. It is about business alignment of IT and it is about making business decisions while driving business results...
Just a different angle... _________________ BR,
Technology Consulting | Service Excellence
Red Badge Certified
Thank you for the reply Fabien. I had figured in some aspects of risk, but hadn't expressed it in my post. What you said though has given me a different view on it. I'll do some sums and see what I come up with.
Of course, mitigating risk when making changes to production systems is only part of the story (we've been doing very well without any CMDB for quite some time). The biggest factor is that more and more of our customers are requiring stronger controls, greater accountability and assurances of information security/integrity - "Do you have an ISMS?", "Do you follow ITIL best practices?", "How do you handle incidents?", etc.
It's like they've been reading management newsletters and suddenly decided "We need our vendors to have ISO 27000 accredition!" or some such pie-in-the-sky statement.
All in all, it's a bit of a headache. Too much, too soon. And it doesn't help that the area of IT service management seems to be in flux, with several competing ideas - some proprietory, others less so - most of which are aimed at medium/large enterprises, not small operations with 30 staff and 120 customers.
Whoops. Bit of a rant there. My apologies.
Anyhow, your comments are appreciated and I'll add them to the mix.
a CMDB can take a good bit of time to get right, to populate and to make relationships between CI's. Then there is the admin which, depending on what level you want to go to record CI's, can require dedicted people.
However the benefit is that it is at the core of the ITIL processes and is the common link between them (especially the Service Support processes).
You can function without one but how effectively?
At this point do you know what CI's you have?
Do you have spreadsheets or databases with the information
Do you have some form of asset register that can e used to get started
Do you have aset discovery tools
Will the scope of your CMDB need to have a dedicated Config Manager?
Will you need help in designing the CMDB and expertise in getting the right way to make relationships.
My advise is get the people you need in early on if you are serious about building a CMDB. Get good people that can demomstrate previous success.
I have had to reengineer a number fo CMDBs for companies who either tried to do it themselves or who didn't invest enough at the time.
If you want to do ITIL processes you will need a CMDB to do it correctly but you can function without one. _________________ Mark O'Loughlin
ITSM / ITIL Consultant
Thanks for the reply Mark. At this point I'm not even sure I need a CMDB, although pretty much everything is pointing towards one. And yes, I've toyed around with creating one, primarily to get a feel of how the CI's would relate.
As a former DBA, I find db schemas are a good way to see if I've got the entities all sorted out. If I miss something I end up with a lot of duplication. It's also easier for me to think of how a "Server" CI relates to an "Infrastructure" CI.
One thought did cross my mind... If I were to include business productivity software in the CMDB (so I know, for example, which PC's still need updates), I would have to have one CI for each installed copy, even if the majority are identical.
Wouldn't that be a bit too much duplicated data?
I guess determining the level of granuality would resolve that, but for me, I really need to know which services, or service functions, would be affected by changes to the production environment, at both the code level and the infrastructure level.
Questions like -
"When can I reboot this server after the patch is installed?"
"What testing do I need to do if I change XYZ function in this app?"
"What's affected if that managed switch fails?"
From what I understand, this is where the CMDB excels.
And yes, we have a bunch of spreadsheets with limited asset data, and heaps of Use Cases and test scripts for the apps, but no discovery tools that I'm aware of.
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum