Search
Topics
  Create an account Home  ·  Topics  ·  Downloads  ·  Your Account  ·  Submit News  ·  Top 10  
Modules
· Home
· Content
· FAQ
· Feedback
· Forums
· Search
· Statistics
· Surveys
· Top
· Topics
· Web Links
· Your_Account

Current Membership

Latest: DLefroy
New Today: 5
New Yesterday: 72
Overall: 139695

People Online:
Visitors: 77
Members: 4
Total: 81 .

Languages
Select Interface Language:


Major ITIL Portals
For general information and resources, ITIL and ITSM World is the most well known for both ITIL and ITIL Books. A shorter snapshot approach can be found at ITIL Zone

Related Resources
Service related resources
Service Level Agreement
Outsourcing

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.


The Itil Community Forum: Forums

ITIL :: View topic - General Guidelines for CMDB Implementation
 Forum FAQForum FAQ   SearchSearch   UsergroupsUsergroups   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

General Guidelines for CMDB Implementation

 
Post new topic   Reply to topic    ITIL Forum Index -> Configuration Management
View previous topic :: View next topic  
Author Message
zajonc
Newbie
Newbie


Joined: Nov 30, 2006
Posts: 6

PostPosted: Thu Nov 30, 2006 10:50 pm    Post subject: General Guidelines for CMDB Implementation Reply with quote

Where do you start with implementing a CMDB? Have you seen any non vendor-specific best practises for implementing a CMDB?
Back to top
View user's profile
raroa
Senior Itiler


Joined: Dec 05, 2006
Posts: 54

PostPosted: Tue Dec 05, 2006 6:11 pm    Post subject: Reply with quote

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.
Back to top
View user's profile
Guerino1
Senior Itiler


Joined: Jan 01, 2006
Posts: 500
Location: New Jersey

PostPosted: Wed Dec 06, 2006 2:21 am    Post subject: Reply with quote

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]
Back to top
View user's profile Send e-mail Visit poster's website
zajonc
Newbie
Newbie


Joined: Nov 30, 2006
Posts: 6

PostPosted: Thu Dec 07, 2006 10:38 pm    Post subject: Determining if you need a CMDB Reply with quote

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?
Back to top
View user's profile
Guerino1
Senior Itiler


Joined: Jan 01, 2006
Posts: 500
Location: New Jersey

PostPosted: Sun Dec 10, 2006 5:53 am    Post subject: Re: Determining if you need a CMDB Reply with quote

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]
Back to top
View user's profile Send e-mail Visit poster's website
matterw
Newbie
Newbie


Joined: Jan 17, 2007
Posts: 2

PostPosted: Thu Jan 18, 2007 6:13 am    Post subject: Re: Determining if you need a CMDB Reply with quote

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]
Back to top
View user's profile
m_croon
Senior Itiler


Joined: Aug 11, 2006
Posts: 262
Location: Netherlands

PostPosted: Thu Jan 18, 2007 4:33 pm    Post subject: Re: Determining if you need a CMDB Reply with quote

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"
Back to top
View user's profile Visit poster's website
ThePatriot
Newbie
Newbie


Joined: Jul 13, 2007
Posts: 1

PostPosted: Fri Jul 13, 2007 9:49 pm    Post subject: Re: General Guidelines for CMDB Implementation Reply with quote

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.


Good Luck!

Cool


[Note: Edited by Admin to remove external links]
Back to top
View user's profile
Guerino1
Senior Itiler


Joined: Jan 01, 2006
Posts: 500
Location: New Jersey

PostPosted: Sat Jul 14, 2007 3:57 am    Post subject: Re: Determining if you need a CMDB Reply with quote

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.

Anyhow, I certainly hope this helps.

My Best,

Frank Guerino, CEO
TraverseIT
On-Demand ITIL
Back to top
View user's profile Send e-mail Visit poster's website
Display posts from previous:   
Post new topic   Reply to topic    ITIL Forum Index -> Configuration Management All times are GMT + 10 Hours
Page 1 of 1

 
Jump to:  
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

Powered by phpBB 2.0.8 © 2001 phpBB Group
phpBB port v2.1 based on Tom Nitzschner's phpbb2.0.6 upgraded to phpBB 2.0.4 standalone was developed and tested by:
ArtificialIntel, ChatServ, mikem,
sixonetonoffun and Paul Laudanski (aka Zhen-Xjell).

Version 2.1 by Nuke Cops 2003 http://www.nukecops.com

Forums ©

 

Logos/trademarks property of respective owner. Comments property of poster. Rest 2004 Itil Community for Service Management & Foundation Certification. SV
Site source copyright (c)2003, and is Free Software under the GNU / GPL licence. All Rights Are Reserved.