7 years, 1 month ago

CMDB Deployment: Where to start? – Part 1

Your company has finally come to the conclusion that Configuration Management is critical to effective service based operations. You’ve now been tasked with finding and deploying a Configuration Management Database solution. The question now is, where do you start and how do you get things rolling with maximum benefit and minimal tears.

These are the steps I normally recommend customers to follow:

  1. Select a CMDB and discovery product
  2. Identify the ITIL process to focus on first
  3. Plan the deployment
  4. Define the scope, breadth and depth of discovery
  5. Implement in phases

Let’s discuss the first two steps.

1. Select a CMDB and discovery product

The first step is selecting a CMDB vendor and product. Now, some may argue that I have left out the option of developing the CMDB in house. While this is definitely an option, it is my firm belief that it isn’t a viable one. The main reason is that there is a staggering amount of CI types, required attributes and relationship details needed to support most ITIL processes. In addition, developing and maintaining a CMDB in house is not cost effective or very practical. Today, with all of the CMDB products on the market, their advanced features, their capabilities and the support and continuous improvement provided by the vendors, outsourcing seems to be the best option.

When choosing a CMDB vendor, there are several things that one should consider.

  • The vendor should be viable and reputable to ensure they will be around to support and improve the product for the long term.
  • A CMDB should be able store and present the relationships between infrastructure elements and business applications and services. Without this capability, the CMDB is merely an inventory tool.
  • The breadth, depth and method of discovery offered for populating the CMDB should be robust enough to meet ITIL processes and objectives.
  • The discovery process shouldn’t put undue stress on the discovered infrastructure.
  • The product should have a published API and support seamless integration with currently available ITSM and monitoring solutions.
  • The product should be able to seamlessly integrate or federate with other data sources to enrich the CI details and attributes.
  • The modeling of applications and business services should be easy to wrap a repeatable process around.
  • Application models should update dynamically and not require significant process to keep them current.
  • The solution should provide meaningful reporting such as CI comparisons, application snapshots, changes over time and configurable inventory reports.

I would also recommend that you chose a product that has a broad current install base. It isn’t that newer products aren’t worthy or viable options. I have just found it much easier for customers to manage and maintain solutions that have widely published information on the internet, large available talent pool in the market place and developed user communities and support groups.

2. Identify the ITIL process to focus on first

The next step is to identify which business processes the CMDB will support out of the gate. This step takes some thought and planning as it is frequently here where the overly lofty goals and unrealistic expectations that can derail a CMDB deployment manifest. In my opinion, it is wise to select a single business process that is experiencing significant pain. This will allow you to target very specific goals and objectives and quickly show value.

For many companies, the biggest “bang for the buck” (and probably my favorite) is the Change Management process. The reason is that the change process is an easy target and from my observations, a significant cause of angst and pain for most organizations. Most researchers agree that lack of visibility into and poorly planned changes are the most significant cause of IT outages.

CMDB Deployment - Gary Passaglia - Intact TechnologyWhy is change such a problem? I firmly believe that all change management processes suffer from the same inherent flaw. Namely, relying on the person who is entering the request for change to identify the potential risk and impact that change poses to the organization. The issue is that this is a self-defeating proposition as the more risk and potential impact you identify for your change, the more scrutiny and potential work you bring upon yourself. In addition, modern computing environments are now strewn with shared resources, virtualization and complexity to the point that you may not really know what the risk actually is. For sure CAB boards can try to deduce this by getting 50 people in a room and doing what I call “you cool” change due diligence (the change manager goes around the room going you cool with this, you cool with this, how about you), but without the true configuration data is anyone really making an informed decision?

There’s also a condition that I like to call “operational change”. Is the following scenario familiar to you? A critical application worked fine yesterday but fell on its face today. An emergency call is coordinated with all of the lead technology teams and the first question being asked is… you guessed it, “what changed!?” The answer you usually get is between baby gibberish and the sound baseball cards used to make against the spokes of my bike tires (yes I’m severely dating myself here). A CMDB can provide instant change reports that answer the “what changed” question down to the patch level or even lines within application configuration files (at least the one we sell does…<grin>).

If change isn’t favorable in your organization there are other solid targets; my second favorite is Incident Management. The CMDB is the mechanism that can bridge the gap between user experience and the infrastructure elements that are potentially contributing to the problem. In its simplest form it can greatly enhance the capability of standard element management by providing the insight into the affected applications and business services from individual events. Administrators can also leverage the topology within the CMDB to quickly get to the root cause of event storms or major outages. I’m still blown away by the number of organizations that have to rely on manual processes to try to figure out the impacted application or user base from a simple server down event.

No matter what process you decide to tackle first (Change Management, Incident Management, Asset Management) I strongly recommend you pick one to start with. Even if the CMDB solution you pick is integrated with or a part of your ITSM system, there are processes and adoption issues that can’t be overlooked. It has been my experience that focusing initially on a single process allows companies to quickly develop a strong foothold with the CMDB providing quantifiable business value. Having a significant win with the initial deployment will also drive adoption for the onboarding of additional processes and integration points. Trust me, get one win and the CMDB will take off like wild fire in your organization. Try to bite off too much out of the gate and you’ll run the risk of the CMDB being viewed as something that was too big to tackle and not worth the effort.

Thanks for taking the time to read this and as always, please feel free to share your comments and thoughts. In part 2 of this blog, I’ll discuss deployment and discovery strategies that provide rapid time to value with minimal pain and effort.









The post CMDB Deployment: Where to start? – Part 1 appeared first on Intact Technology Blog | HP Elite Software Partner | IT Consulting.