OpenMake, Builds and Change and Release Management

(I had the briefing below sometime ago, on 13 Feb 2007, but the CMDB angle was NDA until earlier this week when OpenMake demonstrated the Meister-CA CMDB integration. –Coté)

This morning I talked with the OpenMake folks, which was nice after a long game of meeting scheduling. Tracy Ragan was kind enough to comment at length on a recent BuildForge briefing note, so it was a nice blog-to-briefing loop.

Like other “full plate” build management systems, OpenMake does a lot: it’s a build framework for all sorts of builds from x86 to z/OS with, of course, Visual Studio and Eclipse plugins and integration (I neglected to ask about NetBeans, but there was no mention). There’s the “basics” of build automation, building up audit trails, and remote building.

While there’s clearly a larger ALM story here, one of smaller points that intrigued me was OpenMake’s integration with a CMDB. The idea here — primarily for in-house development and customization of packaged applications — is that your build tool should be updating (and using?) the configuration items in a CMDB.

As the press release says:

CMDB release-management integration works by extending Meister’s approach to deep component-dependency scanning. As each version of an application is constructed, Meister manages and documents the hierarchal relationships among versions of applications, supporting components, middleware, subsystems and operating platforms. These dependencies may exist between multiple source files within an application, associated application components and among application and infrastructure elements. Meister’s dependency mining provides an XML-based self-documenting roadmap to these relationships at both a macro and micro level.

Meister discovers dependency-mining information about every version of each application component potentially deployed to a target platform. Since the CMDB retains details about components available on each platform throughout an enterprise’s infrastructure, this information can be used to predict the success or failure of releasing and deploying new and updated software. Analysis of Meister forensic data could identify an application’s dependency on incompatible sub-components or a specific target workstation’s need to upgrade an application, component or subsystem.

This, of course, makes sense. The current ITIL/CMDB focus is squarely on help desks (incident and problem management). My theory of why is that a help desk is the easiest to implement (or, you might already have one that can be retro-fitted to be ITIL-y) and sell.

I was reminded of this angle by a recent article by Brian Johnson which suggests an ITIL implementation re-focus on change management: that story fits well with OpenMake’s CMDB integration and their overall story.

Naturally, the next logical questions are: (a.) will it work with BMC, IBM, HP, and other CMDBs? which just begs the question (b.) when are these CMDB’s going to be compatible? Good luck standardizing that cash-cow in the short term. Tragically, tools vendors like OpenMake have to either place bets on who the “winners” are and/or spend lots of time and money on integrating with each.

The annoyances of a non-standard world aside, it’s all an interesting data-point on CMDB’s being used more widely. It’ll be fun to see how widely and how Meister-CA CMDB integration works.

Technorati Tags: builds, changemgmt, cmdb, itil, meister, openmake, releasemgmt