DonCasson posted on August 21, 2007 22:54

So you’ve thought things through now and you think you’re ready to begin working on a CMDB. Whether your motives are centralized change management control, the need for a standard set of configuration items or just improved change governance – you know the organization needs it.

The next question is where to start. As the white rabbit told Alice in ‘Alice in Wonderland’ – “I’ve always found it’s helpful to start at the beginning.”

So start at the beginning - by developing a strategy, one that surveys the industry, defines the critical elements of your CMDB and tailors the process to meet the needs and IT ‘maturity’ of your organization. Who knows, you might even want to develop a ‘model’ that could provide a roadmap towards your desired ‘end state’?

So here are a few ideas about how to ‘start at the beginning’ by developing your CMDB Strategy:

  • Review current ITIL Change and Configuration Management ‘best practice’ thinking.
  • Review ‘whitepapers’ written by some of the sectors’ leading CMDB software and solution vendors. Just remember that some of the white papers are written by vendors that may have an agenda.
  • Review the functional attributes critical to the implementation of a CMDB and evaluate them against the ‘fit’ with your business.

Attributes that you may want to consider include:

  • Reconciliation (the ability to rationalize one or more instances of a CI that is discovered and determine that they are the same item and that their relationships are identified are accurate.)
  • Federation (which enables multiple data sources to be brought together to represent a coalesced view of a defined level of data.)
  • Mapping and Visualization (which provides the ability to illustrate logically and physically the hierarchical and peer-to-peer relationships between CIs.)
  • Synchronization (which provides the ability to update the CMDB with approved changes).

Next time we’ll discuss benchmarking your organization against industry best practices. Until then, remember, start at the beginning…

Don

Also, don’t forget to register for Evergreen’s change management webinar and learn how to Take Change Management from Firefighting to Fire Prevention

Are you trying to build a business case for a CMDB? Download Evergreen’s newest white paper on the subject: “The Business Case for Change and Configuration Management and the CMDB”.

—–


Posted in: CMDB  Tags:

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Last blog I talked about CMDB and its relationship to overall Service Level Management. What about is relationship to ITAM and Asset Management?

Oftentimes enterprises believe that if they have an asset management database, they also have a CMDB database. There is a fundamental difference and an important link.

IT Asset Management is the discipline of managing finances, contracts and usage of IT assets throughout their lifecycles for the purpose of maintaining an optimal balance between business service requirements, total costs, budget predictability and contractual and regulatory compliance. ITAM activities include the management of inventory, software licenses, vendors, procurement, leases, warranties, cost accounting, retirement and disposal.

The goal of Configuration Management, on the other hand, is to provide a logical model of the IT infrastructure that is accessed by all ITIL processes, the purpose of which is to drive consistency among them. Configuration activities include identifying, controlling, maintaining and verifying the versions of configured items (CIs). CI information should be stored in a single repository, or a Configuration Management Data Base (CMDB).

So here’s the link - the only difference between a given component in an asset management database or a CMDB is whether it is considered an ‘asset’, a ‘CI’ or both. The difference is only determined by what you do or plan to do with that component.

A component should be considered an ‘asset’ if you decide it is worth managing a contract, cost or usage attribute, throughout its lifecycle. In other words, does that component have an asset that is calculated ‘on the books’, such as software licenses or hardware maintenance contracts?

A component is considered a ‘CI’ if you decide it is worth managing operationally for incidents, problems, changes, releases, capacity, etc.

So there are three points to my ramblings:

  • If the same component can classified as both an asset and a CI, it can be managed for both administrative and operational purposes.
  • An asset management database is an important underpinning to the development of CMDB database.
  • ITAM and ITIL’s best practice Configuration Management share the need for reliable data about components in the IT environment. Thus discovery tools (a scalable means of keeping accurate data on deployed components) and a CMDB (a repository for reconciling and accessing the discovered data) can serve both ITAM and Configuration Management.

ITAM and ITIL are both key IT improvement processes and all IT processes that rely on and contribute to CIs are dependent upon an accurate CMDB to provide best practice service level management.

So I’ll say it again- what is good for the CMDB is good for ITIL and overall service level management. And it starts with an asset management database.

So what do you think?

Don

Also, don’t forget to register for Evergreen’s change management webinar and learn how to Take Change Management from Firefighting to Fire Prevention

Are you trying to build a business case for a CMDB? Download Evergreen’s newest white paper on the subject: “The Business Case for Change and Configuration Management and the CMDB”.


Currently rated 5.0 by 1 people

  • Currently 5/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Search

Calendar

«  March 2010  »
MoTuWeThFrSaSu
22232425262728
1234567
891011121314
15161718192021
22232425262728
2930311234
View posts in large calendar