The Ascent

It’s been 7 days since I left Fusion 11 in Washington DC and I am nearly caught up on everything or should I say, on everything that I will catch up on. Today I posted the Incident Escalation Cost Calculator which was received by everyone in my session Wednesday morning as well as I could have hoped. I also was asked for a Change Impact Cost Calculator so…I guess I have more work to do now.  I look forward to getting feedback from everyone who uses these free utilities so they can grow and mature into vital tools for everyone. Did I mention it’s free?

The conference was once again a special event where we could spend some quality time with friends and catch up on vendor products and services. This year in particular, it was great to have the HDI crowd amongst our itSMF USA brethren. It really added a new dimension and perspective to what we do. I met some new folks that I hope to eventually call friends. They came from all over the US, United Kingdom, Australia and my newest service management friends Ariel & Gonzalo from InvGate, a service management software product company based Argentina.

One of the highlights for me was without question the #SISLunch on Tuesday. For those unfamiliar with what #SISLunch is, it is an effort I took on for the conference, as a follow-up to Glenn’s blog post, to bring together thought leaders in the Configuration Management space to discuss where we as an industry should take the future of CMDB. The reason it was the highlight of course was the simple fact that surrounding yourself with world class brain power and focusing on your area of specialty is not something that you can pull off very often. Being at the table with the likes of Gene Kim, Charles Betz, Glenn O’Donnell, Ivanka Menken was amazing and inspiring. In addition to these great individuals, others who also provided great input were Ariel Gesto, Gonzalo Sainz Trapaga, Thorsten Manthey, Wayne Hartzler and John Shireling (I apologize if I missed anyone). Thank you all for participating and helping us take the first step towards the future CMDB. Be on the lookout for #SISLunch gatherings and the vehicle that Glenn & I will make available for all of us to use as our central discussion area.

A quick recap of the lunch notes is below as well as some background information that set the basis for the #SISLunch. If you were not at the #SISLunch but would like to get involved in future discussions, please contact me and I will be sure to bring you into the discussion.

• What is #SISLunch?  #SISLunch is the Twitter hashtag used during the Fusion 11 conference to communicate with everyone interested in the lunch meeting. For now, I intend to continue to use this hashtag so as to reach out to people more broadly.
• What does SIS stand for? SIS stands for Service Information System. It is an acronym that resulted from research and feedback gathered by Glenn O’Donnell after his blog posting regarding “New CMDB”.
• Is #SISlunch vendor specific? NO, ABSOLUTELY NOT!! The intention is to be technology and vendor agnostic. Ideally, we will be able to move the vendors to adopt the vision so as to enable corporations to more easily deploy a Configuration Management solution.

#SISLunch Notes:

• Using “C” in the name representing “Configuration” is not accurate because the solution is much more than just about the “configuration” of devices and/or software.
• SKMS already has too much baggage so we can’t use that as a replacement name for CMDB.
• What are the real pain points that we are trying to solve?
• Can we really move forward with the general concept while people still have a hard time defining and can’t come to agreement on what the definition of a service is? Is it sufficient to say that a Service is simply an “arbitrary logical construct”?
• We need to design the structure in a way that it captures the “language of the community”.
• If we replace “C” with “S” should we call things “Service Items” instead of “Configuration Items”?
• While discussing what the data subjects might/should be, we began to look into the concept of using a Bill of Materials sort of parallel to help frame the ideas. Also brought up along this line was to use Bill of Resources instead. The thought behind using this “manufacturing” parallel was that IT manufactures “transactions”.

So, keep an eye out for the next #SISLunch event coming to a virtual forum near you. Follow me on Twitter @CarlosCasanova and create a Twitter stream for #SISLunch to stay up to speed on the coming events.

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;

1. Initial Population
2. Regular Updates
3. Verification of updates
4. 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…