I developed a series of five articles on CMDB/CMS solutions and deployments for this issue of BSMdigest from research conducted with eleven vendors during the first half of 2011. This work was initially done for a technology assessment report -- EMA Radar for CMDB/CMS Use Cases: Innovation through Diversity
As the title suggests, I evaluated vendor solutions based on use cases -- and in fact there were three:
- Asset Management and Financial Optimization
- Change Management and Change Impact Analysis
For both me and the vendors involved, it was an admittedly non-trivial effort. The 11 evaluations included vendor participation in a lengthy questionnaire, hours of follow-on discussions, and in-depth dialogs with more than 20 different CMDB/CMS deployments.
The goal of this series of five articles is to share the highlights of what I personally learned during these evaluations regarding CMDB/CMS design overall -- and about each of the eleven vendors more specifically. But given the difference between these brief articles (which might tally six or seven Word pages) and the full report (102 pages in PDF) I have decided to focus more on the first objective – with some very short but hopefully insightful observations about each vendor’s position.
Right away I should tell you that the 11 vendors did not include platform vendors -- BMC, CA, HP, IBM. These will be the center of attention in a second CMDB/CMS radar due out in Q4. The reason for this was the nature of the radars themselves, which tend to crowd platforms in those markets where their solutions tend to be exceedingly rich in function and typically high in cost. So I wanted to give everyone -- both the unique vendors here, and the platform vendors -- the breathing space each group deserved. For continuity, I expect several of the more platform-like vendors to participate in the second session for points of comparison.
Having said that, the vendors referenced here are:
AccelOps
ASG Software
Axios Systems
FireScope
iET Solutions
Interlink Software
LANDesk
n(i)2 Network Infrastructure Inventory
Numara Software
ServiceNow
SunView Software
I’d like to put in a couple of observations about these vendors right now -- just for starters -- so maybe you can get a better sense of why I was excited about what I found out:
- All of them target mid-tier but many also support enterprises and service providers.
- Five out of the eleven currently offer SaaS options and several others are actively planning or considering a SaaS deployment.
- Time for initial deployments (based on customer discussions as well as vendor claims) ranged from three months to a single week.
- Product packaging didn’t always use the term “CMDB” – largely because the CMDB was in most cases bundled with some other set of solutions. To be honest, some customers, and vendors, showed more than a little squeamishness over the term “CMDB” (I can’t personally blame them) even if they realized that from a functionality perspective, that’s what they were looking for.
- While many of these vendors are growing quickly, and some very quickly (e.g. 2000% CAGR over the last four years), only one had more than 500 employees, and most were still under the 250 employee size.
The Changing Shape of the CMDB/CMS: Where It’s Going and Why
Doing this research confirmed my view that CMDB/CMS capabilities are at a turning point. After a rather bad time of it in the last few years, requirements for a CMDB System appears to be taking on new life. This is true just as the ascendance of cloud, Web 2.0 and business service ecosystems are forcing new demands for more real-time awareness, much improved ease of use, adaptability and flexibility.
To some degree this parallels ITIL’s progression in V3 from the database-centric “Configuration Management Database” (CMDB) to the more systemic and diverse “Configuration Management System” (CMS) to the complete “Service Knowledge Management System” that includes the CMS, as well as what ITIL calls “knowledge management” but what I would call “much enriched analytics”. Figure 1 provides a simplified sketch of what an SKMS might look like in the future. And, I should point out, most of the pieces of this already exist in quite a few deployments already -- with some deployments focused more on operations, some more on asset, some more on change automation, etc.
Figure 1: This graphic provides a logical representation of how a CMS -- including a core process-centric CMDB and a fully reconciled real-time system -- is gradually emerging to provide a more cohesive and reconciled context for leveraging different sources of information across the full service infrastructure.
Another way of looking at the relationships implicit in this drawing might be more like Russian dolls, with the “classic” CMDB contained within the larger CMS. And in fact, through federation in mature organizations with the discipline to manage the process, multiple reconciled physical CMDBs might exist within the larger CMS. The logic behind the idea might be something like combining a data-centric system focused on capturing physical and logical service interdependencies in one place for the purpose of analysis, combined with a broader, fully reconciled modeling system. This system would extend well beyond the former and indeed could include multiple CMDB deployments within itself. Here the idea of establishing and linking “trusted sources” to physical and logical CI attributes becomes in many respects analogous to an Active Directory for reconciling and consolidating multi-brand management investments.
However I should offer a word of caution about this evolving “nirvana.” The technologies to do all this are finally beginning to take shape -- and they include Web Service-driven integrations, Mashups, and more effective visualization and analytics for administration, analysis and reporting. But they are still largely in their infancy. We are still standing at the threshold of the “CMDB/CMS Revolution.”
Secondly -- no matter how good CMDB/CMS technology gets -- the challenging politics of asking people to learn to leverage new sources of information, dispense with siloed or redundant tools, and share more fluidly in cross-domain processes don’t go away. They can be made easier with good technology, but leadership, process definition, expectation setting, and above all good communication will always be core to any CMDB/CMS initiative.
Click here to read: 16 Questions to Get You Started on CMDB/CMS
