Okay, you've decided to take the plunge to implement a Configuration Management Data Base (CMDB). You've gone through the list to determine which issues have priority based on their business impact. You've identified the processes and people to be involved. You've met with the team to decide the data you need and how frequently it must be refreshed. You've established and measured the metrics that will allow you to document performance and operational improvements. Now, all that's left is to pick a product, implement it and you're off and running.
Oops! There's a problem – which CMDB vendor and product that will best fit your enterprise needs and operational style? Which has the solution that will quickly get you up and running while delivering the best return for your operations? An exhaustive directive is beyond this column; however, we can highlight typically neglected issues to keep in mind.
Product alone isn't the issue
The product alone isn't the issue; serious contenders can't afford to deliver anything but a robust, reliable, and well-functioning solution. It isn't even hard to find a management data base (MDB). There are plenty of them out there and more coming as a range of vendors jump on the bandwagon and claim to provide a CMDB even if all they are doing is populating a static, descriptive repository of device information. Not every enterprise needs a full-blown, fully integrated CMDB, but you need to know the difference between that and what you do need before you begin your search for a vendor partner. You need to know how what your vendor is calling a CMDB, MDB or whatever matches what you expect to need and get.
Therefore, the first thing to do is to have a rock solid understanding of what you want from the CMDB. You will need a clear understanding of what role the data in the CMDB is to play in your operations and business environments. You must have a clear idea of where the data will come from and how you will use it. You should also have thought about the future so that you understand how the use of the CMDB will evolve. Once you understand your own needs, plan and vision, then you can start the search to find a vendor with a similar vision, or design concept.
What is a design concept? These are the concepts, assumptions, and ideas behind their product's development and implementation. What is the problem the vendor is solving? How do they solve it? What are the implementation and design assumptions, and their view of how IT operations will evolve? The difficulty in implementation ties directly to how well vendor answers overlap with enterprise answers to these questions.
At a minimum, this means comparing your needs to the vendor process for:
- Data reconciliation – resolving conflicting data about the same configuration item,
- Data synchronization – presenting an up-to-date, consistent view of the state of the infrastructure that includes, and distinguishes between approved and unapproved changes,
- Data integration and access – what support exists for the federation of data bases for easy integration and data access across and including multiple data bases,
- Viewing and mapping - does the product support easy visualization of the data – i.e. easy creation and adjustment of data displays to help in analysis and interpretation.
In addition, you need to ask about the tools and functionality available for analysis, report generation, and data manipulation. Then there are the questions about design architecture which can affect long term usability and utility. Some areas to examine include:
- What is the role of the CMDB? – is it the repository of enterprise standard definitions that are then imposed on the real world?
- Will the CMDB be the repository of Truth for how IT and business assets are configured and maintained? This assumes centralized control and is aligned with IT managed as a ServiceDesk function. Operationally, this allows management processes assure updates are made in an approved manner with infrastructure configurations made to match CMDB specifications.
- Is this compatible with how your enterprise functions?
- Will this leverage your existing tool set and data collection abilities?
Alternatively, will the CMDB be a reflection of the real world, with the enterprise description adjusted to reflect the physical configuration? This assumes a de-centralized approach to management and control. In this case, it is critical that the CMDB easily accept and integrate data from a wide range of 3rd party sources and management tools. How well does this fit your operational model? What changes may this imply for your operations and existing tools?
Finally, never overlook the benefits of talking to those that have gone before you. Discussing the experiences of someone who has used and lived with the product is always an excellent and information rich process.
Success in choosing a solution will depend upon your ability to balance and evaluate your enterprise vision and operational requirements against that of the vendor. The better the match, the more likely will be a successful implementation. The process is complicated, and therefore cannot be easy. Strict attention to evaluation details, careful comparison of your needs against the reality of vendor implementation and vision will get you through the process.
Seen or heard of an interesting product? Let me know what and why it struck your interest at: rlptak@ptaknoelassociates.com
ABOUT THE AUTHOR: Richard Ptak is an analyst with Ptak, Noel & Associates. He has over 30 years experience in systems product management.
