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