Anyone who has ventured down the path of aggregating and rationalizing the contents of disparate data stores knows firsthand that, as difficult as the challenge will be to assemble the data into actionable information, it sometimes pales in comparison with the effort it will take to maintain the desired level of quality
The CMS is not a luxury and is quickly becoming essential to your survival. Doing nothing is no longer an option. You must carefully document and then communicate the “Confidence Level” you have of the Configuration Item (CI) data you are sharing. You must also provide a vehicle for the consumers of the CI data to validate, research, improve and report anomalies. You need an anomaly or “Data Discrepancy” process for them to use.
For the complete story, please follow the link below to the itSMF USA website
http://newsmanager.commpartners.com/itsmf/issues/2009-12-21/5.html
The excerpt below is from an article I wrote for the itSM Solutions DITY periodical. A link is provided below which will take you to the full article.
ITIL V3 incorporates emerging best practices for a Configuration Management System (CMS) modeled upon a federated set of Configuration Management Databases (CMDB). For most IT shops that may seem a very daunting obstacle to surmount. But, by looking beyond the task at hand, we can find guidance in several places – including architectural systems, automotive designers, and even mountain-climbing expeditions.
Whether you are constructing a high-rise building, an automobile, or planning to climb a mountain, they all require a solid foundation upon which to build, and, in all three cases, the capability of the framework determines the success you will achieve in your effort.
The framework needs to be strong, but yet flexible enough to handle the environment in which it operates. A high-rise must handle high winds without crumbling or letting its inhabitants feel the sway, and an automobile frame needs to absorb potholes while still providing a smooth ride to its passengers. The framework for a mountain climbing journey is an intangible one that leads the climber through the necessary support camps where he or she makes adjustments on the ascent to the summit.
The full article posted on the itSM Solutions website can be found here:
http://www.itsmsolutions.com/newsletters/DITYvol5iss46.htm
There are various topics for which this discussion regularly comes up, however the arguments for and against do not drastically change. In regards to the Configuration Management System (CMS) or CMDB, the topics tend to be with respect to;
- Initial Population
- Regular Updates
- Verification of updates
- Periodic Audit of system
Read more…
My first venture into implementing a CMDB was nearly five years for a very large multi-national firm and before the term ITIL was barely even spoken in North America. I was challenged by the Chief Technology Officer to look into Configuration Management and come up with a strategy for addressing it. It did not take long for me to identify my first batch of major obstacles;
- Volume of data
- Quality of data
- Constant Changes
I found that in my particular situation my problem was centered not on creating more data but instead, deciphering the volumes that already existed in the environment and determining what was accurate and at what point in time was it accurate. Accuracy and timeliness of the data in an MDR is vital and a manually populated CMS is wrought with pitfalls. There is some manual data which is unavoidable but it needs to be kept to a minimum and validated far more often than its discovered counterpart.
Read more…
In the 5 part series of posts to come, I will use the term CMS versus CMDB when describing what needs to be done. Where I use CMDB, it will typically be when describing previous efforts I have been directly involved in or to maintain a historical context. The fundamental and architectural approach which Glenn O’Donnell and I recommend in our book “The CMDB Imperative” is that of a Configuration Management System (CMS) not a Configuration Management Database (CMDB). So, you may be asking yourself, as someone recently asked me, Why is it that you called your book ‘The CMDB Imperative’ instead of ‘The CMS Imperative’ when you and Glenn are such strong proponents of a CMS?
The best way to answer this question is by quoting our book:
“We must be clear about one important detail regarding the CMDB phenomenon. ITIL practitioners hate the term CMDB. We hate it because it connotes an incorrect perception about how the CMDB should be built and used. Of course, this begs the question of why we chose to write a book about something we hate. We love the concept, we just hate the name. The concept is profound and is central to any IT organization striving for operational discipline. Every IT organization needs a CMDB, and most have probably built several in the past under different names, but there is enormous confusion around the concept and much of this confusion stems from the name itself. We wrote a “CMDB Book” to help clarify this confusion and in future editions, hope to reference CMDB only in a historical context.”
‘The CMDB Imperative: How to realize the dream and avoid the nightmares’ Page 21
Read more…