Don't have an account yet? You can create one. As a registered user you have some advantages like theme manager, comments configuration and post comments with your name.
NOTE: ® ITIL is a registered trademark of OGC. This portal is totally independent and is in no way related to them. See our Feedback Page for more information.
Search
Languages
Select Interface Language:
Advertising
Please contact us via the feedback page to discuss advertising rates.
The Itil Community Forum: Forums
ITIL :: View topic - General Guidelines for CMDB Implementation
Start with what you have to get out and work backwards: what reports or queries do you need to support?
Be brutally pragmatic: note I said "have to" and "need'. CMDB projects are no place for nice-to-haves and idealism. Scope can rapidly balloon out to be unachievable: see the IT Skeptic.
And if you don't know the answer to "what reports or queries do you need to support?" then you don't need a CMDB. The surveys I have seen on how many organisations have impemented CMDB are in the 10-15% range, i.e. the majority of organisations do business without one.
Joined: Jan 01, 2006 Posts: 500 Location: New Jersey
Posted: Wed Dec 06, 2006 2:21 am Post subject:
Hello Zajonc,
I recommend that you start by not confusing an Asset Register with a CMDB. Most enterprise "do" need an Asset Register. Very few need a CMDB. You might be able to get away with an Asset Register/Inventory, to start. In a case like that, start with a spreadsheet until your scale outgrows it. You can then worry about multi-tier distributed applications to meet your needs.
Recommendation: Don't build your won CMDB. You will go down an expensive, complicated, and time consuming path that will make it very difficult for your enterprise to get off of, when the time and need show themselves.
Best Regards,
Frank _________________ [Edited by Admin to remove link]
Posted: Thu Dec 07, 2006 10:38 pm Post subject: Determining if you need a CMDB
Thanks for your replies.
Both mention something like: don't do it unless you have to, then only put into what you must have, and start with CMDB-liek source that already exist.
What crieteria have you all used to determine if you "have to have" a CMDB? For our organizatioin (global, with thousands of IT employees), I think the biggest benefit would be in processes like Change Management. Lots of the different areas we have have there own system for tracking things. Till now it hassn't been much of a problem, but as the applications get more complicated dependnacies, it's pretty difficult to keep track of who is talking about what, and to keep everybody up to date.
The first goal I see is to integrate/federate/syncrhonize all of these various sources. Do anybody have similar experience? What would be a good plan of attack for meeting that goal?
Joined: Jan 01, 2006 Posts: 500 Location: New Jersey
Posted: Sun Dec 10, 2006 5:53 am Post subject: Re: Determining if you need a CMDB
Hello Zajonc,
Please see my responses, embedded below...
zajonc wrote:
What crieteria have you all used to determine if you "have to have" a CMDB? For our organizatioin (global, with thousands of IT employees), I think the biggest benefit would be in processes like Change Management. Lots of the different areas we have have there own system for tracking things. Till now it hassn't been much of a problem, but as the applications get more complicated dependnacies, it's pretty difficult to keep track of who is talking about what, and to keep everybody up to date.
If you have thousands of IT employees, distributed globally, then you have much bigger problems than just a CMDB. I'll venture to say that you tons of different tools that don't talk to each other. However, in for an enterprise of this size, you will almost definitely need one master CMDB that ties all your global information together.
In an enterprise like this, the first thing I recommend is that you not "build" anything. You will not have the in-house expertise to build anything that will be even remotely adequate for an enterprise of this size. Whatever you do build will be a tiny, non-scalable, and highly limited point solution. You're better off getting a higher level architecture group to buy Commercial Off The Shelf (COTS) solutions that will help solve the problems, globally. They should be looking for a single tool that will do the following:
Provide solutions for "many" independent operational disciplines from one tool, as opposed to buying one tool for each discipline
Eliminate the need for many other tools and all their associated infrastructure (SW, HW, STOR, etc.)
Collapse all critical operational data into one master repository that people can work in, directly
Tie all stakeholders and organizations together, regardless of their roles and responsibilities
For an enterprise of your size, I wouldn't go any other way.
Quote:
The first goal I see is to integrate/federate/syncrhonize all of these various sources. Do anybody have similar experience? What would be a good plan of attack for meeting that goal?
In my opinion, this is a bad goal. This is what traditionally breaks an enterprise up, causes extremely high ownership costs, fragments and makes data redundant, causes many different data/information silos that won't share across each other, and ultimatley builds kingdoms that will make it difficult to get work done. In this day and age, I recommend your plan of attack revolve around looking for one master solution that solves many problems at once, not fifty independent solutions that claim to solve one problem each and will cause you to have an exponentially new set of problems, once you own them all, have to provision for all of them, have to maintain them all, and have to try to figure out how to integrate them all together. In this day and age, you should be looking for one tool and vendor that has already done all that work for you and will continue to do so, after you've purchased from them.
I hope this helps.
Best regards,
Frank _________________ [Edited by Admin to remove link]
Posted: Thu Jan 18, 2007 6:13 am Post subject: Re: Determining if you need a CMDB
zajonc wrote:
What crieteria have you all used to determine if you "have to have" a CMDB? For our organizatioin (global, with thousands of IT employees), I think the biggest benefit would be in processes like Change Management.
This is a great question to ask! With one of my customers we started with the goal to provide transparency around the CIs that are most close the business and can't be auto discvoered, applications. In this case the applications are the life blood of the company. This gave the IT department the ability to speak the language of the business right off the bat. The infrastructure/data center CIs where brought in next to provide Change Management and Incident Managment functions. For example, when server 'xyz' was being rebooted they were able to automatically get sign off from the business to approve the RFC.
So, while a lot of people have said let me start by bringing in auto discovery data or something like that I would ask what is the business problem that you are trying to solve -- don't just do it because... That is a recipe for failure.
I'm not sure if you read this quote or not, but Gartner estimates that 75% of CMDB implementations will fail over the next three years with a .8 probability -- I'm counting on this as well due to a poor if any business driver.
Matt
________________________________________
Business Transparency, Inc.
President
(201) 248-0438
[No URLs Please]
Joined: Aug 11, 2006 Posts: 262 Location: Netherlands
Posted: Thu Jan 18, 2007 4:33 pm Post subject: Re: Determining if you need a CMDB
zajonc wrote:
The first goal I see is to integrate/federate/syncrhonize all of these various sources. Do anybody have similar experience? What would be a good plan of attack for meeting that goal?
Hi,
In my opinion, this is not a goal. It can merely be a (one) step in order to achieve an organizational goal/improvement (buss. driver as Matt said).
Also, I often find that billing is a good driver for config. management. Something like "I have a customer who is not happy with me since I cannot legitimize the billing of the workstations. The # of workstations I put on the bill is not correct, and the customer has plenty of examples to prove it"
Posted: Fri Jul 13, 2007 9:49 pm Post subject: Re: General Guidelines for CMDB Implementation
zajonc wrote:
Where do you start with implementing a CMDB? Have you seen any non vendor-specific best practises for implementing a CMDB?
Sir,
We're currently amidst a CMDB/CMIS Project ourselves; we too have a global organization of enormous proportion. Given the complexity of the initiative and the fact that not all are ITIL v2 or v3 savvy; we began by ensuring our community, be it stakeholder, project team, or just sponsors, were working from the same level of understanding. The first thing we did was poll our community to determine what if any expectations were already present; we were surprised to find out just how many didn't really understand what the solution was, more so, the number of people believing they were simply going to be choosing a COTS and move on.
We took the results of our survey and used it as a feeder to one of our meetings. As we analyzed the results we also began establishing a common language by defining some of the basic concepts of ITIL and SOA; then we addressed acronyms, and finally, known state of the industry. It was interesting to see just how many people didn't know there was a difference between a CMDB and an Inventory Management System; let alone Asset Management, Definitive Software Library, Hardware Store, etc.
Once we felt everyone was educated to the same level we began the project management processes--such as identifying requirements and migrating these into goals and objectives; eventually a scope statement.
Joined: Jan 01, 2006 Posts: 500 Location: New Jersey
Posted: Sat Jul 14, 2007 3:57 am Post subject: Re: Determining if you need a CMDB
Hello Matt,
matterw wrote:
...Gartner estimates that 75% of CMDB implementations will fail over the next three years with a .8 probability -- I'm counting on this as well due to a poor if any business driver.
I can't say that I have seen this exact quote but I can say that I have seen others that are in the same range and support it. I can also tell you, from real experience, that the biggest reasons for CMDB failures revolve around "understanding" and "expectations".
Most people that undetake a CMDB effort haven't really taken the proper time that's necessary to understand what their CMDB is or is supposed to do. They haven't spent the time to truly understand the requirements. They haven't spent the time to understand what it will take to implement one (time, money, energy, distraction to their business), etc. They haven't taken the time to understand what it will mean to "keep" a CMDB in their enterprise, failing to understand that a CMDB is a constantly evolving concept that will drain a lot of time, money, and energy every year that you own it.
In the end, because they don't understand what they're getting themselves into, they almost always (almost unanimously) underestimate the complexity of a real CMDB. The CMDB is, by far, one of the most complicated "application concepts" that an IT organization will ever implement for itself. Just from a headcount perspective, to do it right, requires dedicated application designers/architects, dedicated data modelers, dedicated User Interface experts, dedicated coders, dedicated integration specialists, dedicated specialists for Reporting, Business Analysis, Enterprise Search, Web 2.0, Semantic Web, etc. etc. etc. Then, to allow all these people to be effective, it will require all forms of design, development, verification, and runtime software.
The reality is the list goes on and on and on. Most people choose to close their eyes to the real complexities associated with a CMDB, and as a result they shoot themselves in the foot and instantly cripple their chances of success.
For those that don't wish to admit it, a CMDB, in this day and age, is the Command, Control, and Communication platform for "an entire enterprise", not just the infrastructure, engineering, and operations teams. If you scope it to be less than a CCC platform, you will lose the battle before you even get started. CIOs, CTOs, CFOs, COOs, CEOs, your customers/clients, etc., don't care about the details unless they have to. They want the high level dashboard view that helps them run their business. The ITIL CMDB is all about the minutia. Based on our experiences, I can honestly say that this is the first step to failing with your CMDB.
If you and your enterprise are smart enough to scope it to be a true CCC platform, then you're probably also smart enough to understand that building and managing such a complex CMDB is "not" your core business and you won't try and convince yourselves that it's an undertaking that you can effectively, do yourself. A CMDB that is a real CCC platform is as complicated as a Trade Processing System for a financial firm, or a Flight Reservation System for an airline, or an Account Management System for a bank, or a Reservation Booking System for a global travel agency, or a Medical Informatics Platform for a hospital. A real CMDB is the "backbone" and "dashboard" to the entire enterprise. It is the "center" of how IT works. Sadly, very few people that try implement a CMDB get this. They think it's as simple as an Asset Register, or a data model, or an auto-discovery solution. They think they can create one with nothing more than an Access database or some simple web forms over a data model in MySQL/Oracle/Sybase/etc.
Also, another driver to failure is the fact that the majority of the CMDBs undertaken are not formally sponsored and budgeted by the business(es) IT serves. I can't tell you how many CMDB attempts we find that were built under the radar. There is nothing that non-IT leaders (CEOs/COOs/CFOs/etc.) more than seeing their IT organization making decisions to roll things out under the radar that don't have any real business value. Trust me, if you can show how a CMDB will drive real business value, a smart leader (any smart leader) can get it and will look for ways to support it, assuming it fits into their priority list. More often that not, a CMDB is something that is built and rolled out by an IT infrastructure person, who has very little experience in Distributed SW Application Design, Analysis, Implementation, Deployment and Support. The end result: failure.
We find that most times, the reason why a CMDB was built the way it was, was because the person/people building it "wanted" to build it themselves. They wanted the experience of something "fun" and/or "challenging" to do at work. They wanted to build and roll out something that they felt they owned and had control over, something that gave them a sense of security and job stability. Guess what. These are all wrong reasons for rolling out a CMDB and trying to do it, yourself.
There are only three reasons to implement any software system in your enterprise:
1) It saves your real and tangible money, reducing your Total Cost of Ownership (TCO)
2) It makes you money by helping sales and grow Revenue
3) It does both of the above
If you can't prove that what you're rolling out does any one of the above, chances are that you shouldn't be rolling it out. Too many people roll out solutions without understanding, "IN DETAIL", how that solution fits into one of those 3 drivers. Understanding, in detail, means breaking your costs into extreme detail, where you have a roll up of what it takes to get in (i.e. initial investment to deploy) and what it costs to stay in, year-over-year (YOY), after it's been deployed. We find that most implementations of a CMDB do not include such detailed analysis. Results: Failure.
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
Forum FAQ
Search
Usergroups
Profile
Log in to check your private messages
Log in
