In my previous blog, CMDB System Use Cases - Part One, I discussed use cases such as Change Impact Management and Change Automation, and Asset Management and Financial Optimization. In this follow-up blog I cover two more CMDB use cases.
3. Service Impact, Performance and Capacity Optimization
While historically, CMDBs grew up with a focus more on process control than on performance management. Both technology advances in CMDB System design and pressures from new trends, like cloud computing, are changing that dramatically. Operational professionals with concerns such as Mean-Time-to-Repair (MTTR) and Mean-Time-Between-Failure (MTBF) can benefit greatly from a "reconciled view of truth" including the impacts of change on performance, both of which are ultimately dependent on a dynamic CMDB System foundation.
I am including "Capacity Optimization" as part of the use case here, although it might also fit with change management or asset management. Capacity optimization draws from a convergence of performance, change, configuration and usage insights, and as such it could in theory belong to any of the three major use cases indicated here. However, given the increasingly dynamic tradeoffs between performance impacts and capacity-related choices, the linkages have become strongest in the service impact arena.
Some of the subsidiary use cases here include:
- A reconciled view of truth across many multiple sources (or when siloed monitoring tools are allowed to collide no more and both operations and the service desk have a single, common set of insights).
- Reflexive insights into change and configuration — a two-way street that can both validate changes, and support triage and diagnostics via change histories.
- Incident and problem management automation and governance — as more cohesive insights enable higher levels of automation and IT efficiency.
- Finding the owner of the problem far faster, with less phone time and less downtime.
- Linking capacity and performance for diagnostics via a clear understanding of service interdependencies.
- Optimizing capacity for more effective service delivery through what/if analytics informed by clearly modeled service interdependencies.
- Business process and service-specific benefits — by joining business service and business process model attributes to the application infrastructure.
A surprising number of CMS-driven deployments are beginning to extend the CMDB System to support development and test environments. While these are still among the more progressive and even so often not yet fully realized. The emerging pattern I'm seeing looks something like this:
1. Automate the provisioning of new systems, storage and infrastructure in response to development requests through the CMS and its modeling.
2. Model the new applications or application enhancements as they evolve through development into test. Doing this may range from manual to more automated capabilities.
3. Apply production-level performance analysis into the new capabilities which are already modeled as an extension of the CMDB System.
4. When ready, integrate those capabilities into the large system.
This of course depends on having a "pre-deployment" or "planned" state supported in the CMS. But the power and value of doing this for major application initiatives is significant. To be clear, this doesn't replace unique development tools, but provides a much more realistic and consistent set of values to work from.
As broad as this list is, it's still far from complete. Moreover, not every use case here is likely to work as a First Phase deployment. Some, like the DevOps sequence described above, require higher levels of maturity than others. But hopefully these options provide at least a useful Rorschach inkblot for stimulating your imagination in decided what you want to do, and where you want to go with your CMS plan.
Some of the added advantages of the CMDB System will get addressed in my next blog on: First Phase Assessment — Separating Truth from Fiction.