Facing the Dell laptop with a Sony battery recall… can a CMDB help?

So, was your laptop affected by the recent Sony battery recall? I have a Dell Latitude D600 and had to check the serial number but fortunately the battery number did not match those on the recall website that you check to see if you need to get a new one.

Now, if a CMDB had contained the serial number of my battery, could I have been saved that extra step? It’s a question of granularity for the CMDB – when would you kick yourself for not going more granular on your CMDB? And is it possible to think of all scenarios such as this, especially for all hardware parts that go into laptops and servers and desktops? I sincerely doubt it’s worth the trouble… until something like this recall comes up and then I wonder.

It seems like entering all that information into your CMDB is not worth it for these rare exceptions when you want the information. Until the information could be automatically discovered somehow, it’s just as easy to have your end-users look it up for themselves. If the serial number information was available from the manufacturers or through discovery, it could be a federated attribute in an Asset Management database rather than stored in the CMDB. But, for a level of granularity that helps you pinpoint a subset of your entire collection of hardware, you could use the CMDB to help you determine who might be affected, based on who has laptops or who has Dell laptops with the exact model numbers that are affected. This sounds like a sensible and balanced approach.

How about you? Any ideas on the practicality of granularity for these recall situations? What is the next step — Change Management for tracking all the replaced batteries?

Updated to add: Here’s a link to a relevant podcast with Tom Bishop, where he talks about the relativity of data. Thanks to Ynema’s comment I can get even more familiar with the best approaches to these types of CMDB design questions.

Subscribe to the comments for this post

Throw out ITIL, but keep the CMDB?

Just read an interesting article in Network World’s Systems Management newsletter, “The jury’s in on the CMDB, or is it?” From it, I’d like to pull out two ideas that caught my eye, one is “In fact, awareness of the term ‘CMDB’ outranked awareness of the term ‘ITIL’ by a significant percentage within the U.S. IT population. (Awareness of ITIL has been traditionally higher in Europe in particular.)” I think that the concept of a CMDB is much easier to wrap your head around than the multiple concepts pertaining to ITIL and Service Management and Service Delivery and… and… the list is a long one. But a common database that houses all your assets and connects the dots for you, well, that is somehow tangible and visible and just makes sense.

The other quote from Dennis is, “In almost all the ’successful’ CMDB implementations that I’ve personally assessed, there has been a strong commitment to process and to change management processes in particular. In most but not all instances, this attention has been ITIL-driven, while in some it’s more a mix of ITIL and other best practice initiatives (and in one instance ITIL was thrown out and the CMDB was kept).” Threw out ITIL and kept the CMDB, now that is interesting. I guess one was more useful in that environment than the other. He does make the point that you need good processes in place in order to have a successful ITIL implementation. I suppose a corporate culture that isn’t driven by process and change management would struggle with ITIL and eventually give it up.

Which is more popular in your group, ITIL or the CMDB? Or are they so interrelated you can’t imagine one without the other?

Subscribe to the comments for this post

Controversial ITIL blog asks the reality check questions

I stumbled across The ITIL Skeptic’s blog today, reading on digg.com. An entry about the seeming impossibility of creating and maintaining a useful CMDB (Configuration Management Database) as defined by ITIL was an interesting read. But I suppose one answer is, don’t make it a behemoth, keep it manageable with federation? Or perhaps the heart of the argument lies in the definition from ITIL? At any rate, I found the post to be informative and thought-provoking.

The ITIL Skeptic chooses to keep his or her identity a “secret” but is apparently not a former BMC employee. I do appreciate a skeptic’s viewpoint as I continue to learn about ITIL and the CMDB since I still feel like a newbie on the topic. Plus, as a vendor we ought to be sure we pay attention to the skeptics.

Especially valuable to me as I continue to learn is the list of links included on the site. Here are the blog titles and links. I was going to offer up an OPML file with subscriptions but it seems that some of them aren’t syndicated, so I’ll work more on that later.

• ITIL Community Forum
• Wandering through Best Practice
• Fear & Loathing on the Road to ITSM Excellence
• Doug McClure’s blog
• ERP 4 IT
• An Expert’s Guide to Network & Systems Management
• Real World ITIL

Subscribe to the comments for this post

Best practices for document management systems

I recently received a question about best practices for electronic document management systems using Word 2003. While I use Word 2003, I have only used it in combination with Sharepoint as a document management system, and the docs I write in Word are usually short, internal documents, not external technical manuals. Coincidentally, I’ve heard that IT departments are using document management systems in concert with their CMDB. Text-based documents, drawings, architecture designs, all these documents are important to an IT department and any business organization. It makes sense that the CMDB would be related to a document management system, although I won’t get into any discussion about whether each document is a Configuration Item (CI) or not.
My experience with document management is Documentum with FrameMaker, and we don’t currently do much co-authoring with people in the rest of the company. So I’ll admit first off, this request for information is outside my personal knowledge. But, I do like a good research question and I gathered together some reading items.

Here’s a summary of what’s found in this article about putting together a document management system using Microsoft tools. Your environment may vary widely from an accounting-type environment, though, but I thought these were decent overarching goals for managing documents, and I expanded on a few of them based on my experience with document management systems in general.

1. Determine what documents get the “document management treatment.” Create limits on what is stored and maintained in your system so that you know what’s in there and what’s not, and you also limit maintenance and a bulging file system. Will you scan and store images of paper copies?
2. Classify or group your documents together. Some EDMSes do this for you using document type, but you might also want other criteria for easy search and retrieval later. This approach also allows you to assign more than one classification to a document.
3. Store the files efficiently to make retrieval easy. Your EDMS might do this on its own with little input from you.
4. Retrieve as needed, using versioning if desired, which leads to the next step. Realize that indexing and keyword searching are crucial tasks for retrieval. Be sure to train users to properly tag documents for fast and efficient retrieval. You may have to create a taxonomy using standard terms for the system.
5. Managing and tracking documents allows for the type of collaboration where one person can check out a document to make revisions. Other collaborative activities might include activities such as participating in active discussion groups, tracking issues associated with customer engagements, maintaining common contact information for subject matter experts on a particular document, and even assigning tasks related to a particular document. Tracking and versioning also allows for storage and retrieval of documents from a point in time which may be helpful historically.

For research like this question, one place I like to do searches is answer.google.com. There was one relevant Answer for someone who was looking for an analysis of document management software. It’s long but comprehensive. I realize you might be well past the evaluation stage for a DMS, but you might get a look at what features are offered. You can also use blogsearch.google.com to search only for blog entries on a given topic, although that particular search method did not offer much on this particular topic.

Going beyond Google, I did a search using www.bloglines.com to search for blogs about “document management systems,” and the best I’ve found so far is www.docuvantage.com/blog. Another site that offers a wide range of case studies and white papers is The Gilbane Report at http://www.gilbane.com/.

There are also lessons learned from the doc management trenches at Hewlett-Packard. It appears the author is Susan Charles, an Information Research Analyst at Hewlett-Packard. She describes the implementation of an internal document management project at HP. She discusses the challenges of the project, and what she sees as the lessons learned.

In addition, here’s a case study from a university setting. I haven’t read through it completely but it might offer some advice.

As with many best practices in technology, you want to analyze first and implement second. Spending more of your time in the up front planning and definitions will pay off when you go to populate your system with documents.

Anyone else have some advice to offer? Feel free to post a comment, or use the trackback URL to write about it in your own blog and refer to this entry.

Subscribe to the comments for this post

What’s driving CMDB adoption?

Talking about the top three reasons people say they’re working on implementing a CMDB

According to Network World, in this CMDB adoption: What some numbers tell us and why article, they have found three top drivers or motivations for CMDB implementations:
1. Change and Configuration Management (also named Release, Change and Configuration Management)
2. Service Assurance
3. Problem and Incident Management

Interestingly, “Asset and Inventory” was fourth on one survey, but when asked if CMDB was going to be used for “Asset Management” instead, that category fell even further out of the list of reasons to implement a CMDB. Read the article for the full story and details.

In the IT Discovery Suite talk I went to at the BMC Forum, these are some of the items that we see are driving discovery tool needs. While not necessarily directly related to CMDB implementations, I see a coupling, and definitely our discovery tools can populate a CMDB. However, I wonder if asset management isn’t as much of a focus, and there are plenty of other pain points to choose from. In case you need a pain point. I’m guessing most of us don’t need more pain points, but here you go.

Common pain drivers

• Don’t know what assets are deployed or their inter-dependencies
• Over- and under-buying of assets
• Cost, risk of software license and regulatory compliance
• Change Control vs. Change Management
• No insight into the impact of IT health on business activities
• Long resolution times
• Missed SLAs

Common project drivers

• Inventory
• Software license management
• Regulatory compliance
• ITIL® best practices (e.g. configuration management)
• CMDB initiative
• Application & Patch Management
• Server consolidation
• OS Migration
• Root cause analysis
• Intelligent Trouble ticket generation

You can take the survey for Network World yourself. What projects or pain points are driving your CMDB projects?

Subscribe to the comments for this post