CMDB Lessons Learned - in Search of the Path to Value
A great deal has changed in just the two to three years since the term CMDB became a part of IT’s common vernacular. And then a great deal hasn’t. Enterprise Management Associates (EMA) research from June of this year shows that initiatives are further along, strategies are evolving, however most deployments still suffer from politics, communication issues, and confusion, and many are still struggling to demonstrate value—at least in terms that senior IT executives will appreciate.
The respondents in our June research were 90% from
Here are a few highlights:
� Most CMDB deployments are less than two years underway, and 43% are less than a year underway.
� Sixty-eight percent are not yet in full-production with their first-phase deployments.
� Executive sponsors are largely VP or C-level, where as day-to-day guidance is mostly director or manager level. Based on a number of metrics and interviews, higher level executive involvement is one of the more consistent indicators of success. Something you should keep in mind.
� As of June of 2008, both IT budgets and CMDB budgets show overall growth (59% of the CMDB budgets have grown and 13% have diminished), but 23% are being redirected. Quite often this redirection is due to a change in the CIO, when the new CIO is less CMDB-aware.
� A growing number, 33%, of CMDB budgets are becoming a part of the core IT budget (versus being undefined, defined annually, or defined in terms of specific phase objectives), and this trend is more pronounced in more mature CMDB deployments. However focal interviews reveal that in many cases CMDB budgets remain bundled in with other initiatives (e.g. ITSM, change/configuration management, etc.) versus discrete in themselves.
� The importance of automation overall, and workflow-driven process automation in particular has risen to the top of functional linkages and technical priorities. There are two overarching reasons for this. The first is that workflow and process automation are primary avenues for harvesting the value of the CMDB investment, whether for incident and problem management, or for change and release management, or for service impact, or even for compliance audits, etc. The second is that automating key processes is central to the care and feeding of CMDB Systems.
� Fewer than 50% of CMDB System initiatives currently have metrics. However, most focal interviews recognized the need. “We’re not there yet,” is probably the most common response.
� Executive commitment, budgetary commitment, good metrics and good detailed requirements topped the charts for process-and-organizational success factors.
Good “in-house software development” and good discovery software topped technical requirements. CMDB systems in 2008 definitely require in-house skills. While focal interviews reveal that many executives, in particular, are becoming concerned with too much customization of CIs, some is still required in most environments. Focal interviews reveal significant in-house efforts to complement the many holes still present in CMDB technologies. EMA anticipates that the industry is several years away from a new phase in CMDB solutions which are significantly easier to deploy and integrate across brands.
On the other hand, the number one answer to, “What would have done differently” was, “We would not have used in-house development for SW as much as we did.” In putting two and two together, CMDB deployment teams need to have a high degree of technical expertise but, at the same time, they need to pick their battles wisely and focus their efforts better.
When asked about changes made that were driven from “lessons learned,” the top were: better requirements documentation; “we are increasing commitment for our CMDB program;” and higher level executive buy-in.
Most IT organizations have already embarked on the “CMDB journey” and are looking to for some benchmarks or at least signs of value. Yet consistently with prior years, no one I have spoken to claims to regret not going forward with a CMDB system. Indeed, when asked, “What would you do differently,” a few focal interviews stated that they would have started the CMDB initiative sooner. And when probed, although it wasn’t a focus for this research specifically, most respondents indicated they either had direct plans for federation, or were in some way federating already (e.g., asset data repositories federated to the core CMDB system).
One reason for optimism in pursuing the federated vision is that there are really two “parents” for CMDBs. The first is of course ITIL itself, with its focus on process and best practices. The second is largely architectural, as management technologies evolve to become more intelligent, automated and modular requiring new types of integration across domains. After all, the need for reconciled and consistent visions of “truth” is as old as IT, but CMDB-related technologies are now allowing IT architects to approach this problem in radically different ways.
The sudden growth in CMDB system deployment represents a confluence of both of these areas: process and architecture. This is borne out in real world deployments that typically require a pairing of architectural expertise with process expertise with evolving support for unique constituencies that, over time, will invariably lead beyond an all-or-nothing single repository and towards more successful federation.
Another key point to make about this diversity is there isn’t a single generically “right” place to start. There is, by contrast, a “right place for you” and your organization to start, and you can’t find the answer for that in ITIL or from a vendor trying to sell you a CMDB solution. You need to assess your own operational and business objectives, promote dialog and communication with key stakeholders and let your team judiciously decide where to begin based on readiness, resource and impact.
Dennis Drogseth is vice president of Boulder, Colo.-based