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


The five ITIL books can be obtained directly from the publisher's website:

Or as downloadable PDFs: HERE

Current Membership

Latest: deirdreqg18
New Today: 0
New Yesterday: 40
Overall: 231752

People Online:
Visitors: 146
Members: 0
Total: 146



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.

Related Resources

Service related resources
Service Level Agreement

How to set up
IT Change Management
Process Info-Graphic

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.


Select Interface Language:

Please contact us via the feedback page to discuss advertising rates.

The Itil Community Forum: Forums

ITIL :: View topic - CMDB Project : Lessons Learnt
 Forum FAQForum FAQ   SearchSearch   UsergroupsUsergroups   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CMDB Project : Lessons Learnt

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

Joined: Apr 24, 2007
Posts: 9
Location: Dubln, Ireland

PostPosted: Fri Apr 27, 2007 6:56 pm    Post subject: CMDB Project : Lessons Learnt Reply with quote


Can anyone give me any feedback on a CMDB implementation project from a lessons learnt perspective ?


Back to top
View user's profile
Senior Itiler

Joined: Sep 16, 2006
Posts: 3597
Location: London, UK

PostPosted: Fri Apr 27, 2007 8:18 pm    Post subject: Reply with quote

You sure about this... The lesssons learnt would fill 2 or 3 books

I will give a try

The first lesson to be learnt - Data Collection and data entry

When an physical inventory is taken of what servers, routers etc are in a data center floor area, there are several ways to collect the data and store the data

1 - have unique Company Asset tags which are bar coded. The information is collected during the arrival of the kit
1a - Then you can go around with a barcode reader and inventory the kit

2 - find the damn serial #on the device and enter it in a inventory sheet
2a - the serial # may be on the front back or the sides, top, bottom. The front and back are easy to get to in a rack cabinet but if the kit has been there for years, the s/n may
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter
Back to top
View user's profile
Senior Itiler

Joined: Sep 16, 2006
Posts: 3597
Location: London, UK

PostPosted: Fri Apr 27, 2007 8:54 pm    Post subject: Reply with quote


In addition,

when the data is gathered by the staff, you need to have standards for things like devices, device type etc
as well as preventing the staff from misspellling

for ex

Server - it was spelled severe, srver, srv, sevier, etc by people typing the word

A Sun e250 Server was called

manufacture sun
model sun e250 unix
device type sun

in other words, there needs to be a good process to ensure that the data entered aint specious
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter
Back to top
View user's profile

Joined: Mar 03, 2007
Posts: 33
Location: Minneapolis

PostPosted: Sun Apr 29, 2007 12:12 am    Post subject: Data control Reply with quote

Involve data professionals. The remark above about people putting in various values that mean the same thing is a data architecture question, pure and simple. Your vendor may or may not understand this - in my view, any tool that allows/encourages people to enter data in such a way is substandard, but there are far too many out there like this.

I have devoted *considerable* effort in multiple engagements to defining an official list of "applications" (as services, not software products). Such an official list has great utility across multiple ITSM processes. If you have competing/overlapping/inconsistent "application" lists, suggest you attack this hard. Doesn't necessarily cost large amounts of financial capital, but it will cost you political capital.

Charles T. Betz
Back to top
View user's profile Send e-mail
Senior Itiler

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

PostPosted: Sun Apr 29, 2007 4:38 am    Post subject: CMDB Implementation Lessons Learned Reply with quote

Hi SandraDee,

The list of lessons learned can be very large. However, here are some of the most critical things to keep in mind (in no particular order)...

  • Cost of Initial CMDB Implementation: Most enterprises that invest in CMDBs have no idea how exensive it is to implement a good CMDB. Aside from the cost to purchase and deploy the tool itself, there are all the integrations that have to get built to other systems, the work that it takes to get the data in, the work to understand how your enterprise will maximize its return on the investment, etc.
  • Cost of Maintaining a CMDB: Most enterprises that invest in CMDBs take no time to spell out the costs, in detail, of what it will take to maintain and grow the CMDB, year-over-year. The costs associated with doing so could be huge, when not done correctly.
  • Understanding the Return on Investment for Your CMDB Implementation: Most enterprises implement a CMDB without itemizing, in detail, what the return on that investment will be. Taking the time to do so and communicating that justification to get buy-in is absolutely critical. Identifying the return on investment is not always easy.
  • Complexity of Implementing and Maintaining a CMDB: Most enterprises have no clue as to what they're getting themselves into with the implementation of a CMDB. Of all operational systems, once an enterprise starts feeding data in or out of a CMDB, it becomes a critical dependency for all other systems. As a result, it will require a significant effort to grow and improve it, build and enhance integrations, implement useful datamining, implement useful reporting, etc. Many people think that implementing a CMDB is nothing more than building a data model. The reality is that the CMDB will become one of the most complex distributed applications that an IT organization will own and run for itself. Most enterprises that want a CMDB rarely have the resources necessary to care for it, over the long term.
  • Having the Wrong People Drive the Selection and Rollout of a CMDB: A CMDB is a highly distributed software application that will need some serious care and feeding to grow it and integrate it to many other systems. In most cases, CMDB implementations grow from within infrastructure teams, because of ITIL. A very big mistake is that the infrastructure teams don't hand off the effort to a firm's software architecture and process teams, who are far more experienced in such tools and technologies and who typically have responsibilities for bigger picture landscapes in IT. If your enterprise doesn't have such an enterprise architecture team, you have another problem...
  • Underestimating Integrations to and from a CMDB: Creating integrations to other systems that will help populate the CMDB or use data from it is an expensive and complicated task. The CMDB, as a stand-alone repository, is virtually useless to an enterprise. Done correctly, it will act as the IT data routing hub for all operational IT data/information.
  • Incomplete Identification and Understanding of Proper CMDB Feautures and Requirements: Unfortunately, most enterprises that implement CMDBs don't take the time to truly understand what a good CMDB is supposed to do. Instead, they only look at the requirements that fulfill what the implementation team needs. This is a sure sign of long term failure as, more often than not, the implementation team has very limted needs, when compared to the bigger picture needs of an enterprise. It is critical to understand everything a good CMDB should do, even if you don't intend to use all features, from day one, because once your CMDB is in place, it's growth will not stop there. An enterprise that is constantly maturing will want to mature and expand the functionality of their CMDB to address that enterprise maturation and expansion.
  • Oversimplification of CMDB Scope: Many enterprises try to narrow the scope of a CMDB, for initial implementation. In doing so, they have a tendency to leave out the proper room for growth that will be needed to address many other forms of Configuration Management that they may not be thinking of, day one. For example infrasructure people tend not to think of the needs of software people, or facilities people, or project managers, etc. As a result, the CMDB purchased or implemented is limited to the scope that the planners wanted to solve for, at the time of implementation, and more often than not leaves no real room for growth and maturity.
  • Poor Data Freshness/Accuracy in a CMDB: Many enterprises implement a CMDB thinking that it will become the central hub for "true" data. However, if data is being generated in other systems that feed the CMDB, the CMDB can "never" be that point of "true" data. Those systems that feed it will be (assuming that's where data is created). What this means is that the CMDB, if implemented as a stand-alone non-operational system, will always have data that is out of date, unless you can guarantee transactional synchronization between the source system and the CMDB (which is virtually impossible since most source systems are not built to facilitate transactional data pushes). This leads to the alternative, which is to select CMDBs that you work directly in, to create and manage data/information.
  • Choosing "Repository" CMDBs Over "Operational" CMDBs: The difference between a CMDB that is a data repository (the most common type) and one that is operational is that the data repository form is not the definitive true source of data (and can never be). The best it will ever be is a data hub. The operational CMDB is a place where people work, daily, and where data gets created from scratch. As a result, because data is created within it, an operational CMDB is the true source of data. This ensures that the CMDB will have a much higher value and provide a greater return, from day one. Also, an operational CMDB that has tools to address individual operational areas of your organization (such as Incident Management, Project Management, License Management, etc.) will act as a platform to allow that enterprise to decommission many other tools over the long term, in addition to the many integrations that might be necessary between those tools.
  • Inadequate Handling of the Human Factor: It's always amazing to me how many people talk about CMDBs but can't actually describe one, accurately, when pressed to do so. Too many people confuse a CMDB's features with Asset Management features, think of it as nothing more than a data model, etc. It is important to properly train people on what the tool is, how it fits into processes, how it will be integrated into other tools, why it must exist, what its impact will or won't be, etc. It becomes critical to ensure that people will know and understand how to use the CMDB and the Configuration Management processes to solve problems for themselves and others in the enterprise.
  • Not Treating the CMDB as a Service: Once a CMDB is in place, it will be a service that will need to be maintained with detailed SLAs/OLAs. Not doing so can have some severe impacts on an enterprise. To make a CMDB successful, an enterprise will need to put Product and Service Owners, Organizations, and expectations around it.
  • Not Managing the CMDB as a Product: Like any other products that an enterprise manages, the CMDB should have a clearly defined product owner and a team that will plan its upgrades through managed SW releases. This means that SW development lifecycle best practices should be applied to how it is managed, ensuring the builds, deployments, tests, etc. are all repeated "properly" in every environment (Dev, Integration, QA, Production, etc.)
  • Not Understanding the Future Criticality of a CMDB: If you take a CMDB and use it to feed data/information to downstream systems, those systems will become dependent on the CMDB. This means that the more systems that depend on it, the more critical the CMDB will become to the enterprise. This will slowly raise the CMDB from a Tier 3 application to a Tier 1 application, over time. Many enterprises fail to realize that this will happen and don't plan for it, from day one. Remember, if the CMDB becomes a dependency for many downstream applications, it will become critical for disaster recovery, as it will need to be one of your first systems to be recovered in IT.
  • Over-Glorification of the CMDB: Many people implementing a CMDB think that doing so will have a huge positive impact on their enterprise. The truth is that, while valuable, unless you're using your CMDB as an operational system that facilitates your "tool take-out" strategy, which will allow you to decommission other operational tools and directly impact your P&L, your CMDB may not have nearly the impact on your enterprise that you think it will. Also, because it takes such a long time to properly integrate it to all your systems, unless you're strategically managing a big picture plan, you may find it very difficult to gain the impact that you thought you might, at the beginning of your initiative.

Anyhow, again, please understand that there are many other valuable lessons learned. However, these are usually the most obvious and the type that most leaders will want to know about. I certainly hope they help you in your efforts.

My Best,

Frank Guerino, CEO
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

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.