Model Driven Configuration Management

Configuration Management is a key part of IT Service Management. The major process frameworks (ITIL, COBIT, CMM) all call for it. According to ITIL, Configuration Management's goals are to “account for all the IT assets and configurations within the organisation and its services.” What’s in scope? All applications, components, databases, servers, message queues, ETL jobs, and so forth become CIs, or Configuration Items.

This essay examines the particular issue of Configuration Item identification: how is it that CIs are first identified? As an extension of the Object Management Group’s Model Driven Architecture, the concept of Model Driven Configuration Management is proposed.

To mitigate the typical last-minute “over the wall” dysfunctional handoff from development to operations, CI identification should be driven as far upstream as possible. In its section on Configuration Management, ITIL argues that

"Support tools should allow control to be maintained, for applications software, from the outset of systems analysis and design right through to live running. Ideally, organisations should use the same tool to control all stages of the life-cycle . . . the IT infrastructure Configuration Management tool should at least allow Configuration Management information to be transferred from a software development Configuration Management system into the CMDB without the need for rekeying."

However, this seems to imply some sort of interface between the source code control tool (aka software configuration management tool/repository) and the CMDB. Source code control tools such as PVCS, VSS, or CVS play an essential role in the software development lifecycle, but they are essentially just specialized file management systems with the ability to compare text files. The overall structure of an application is not represented in the source code control system, which is hierarchical and focused on the source code – basically, just a managed directory structure with some extra capability, by no means a modeling tool.

A modern distributed system’s complexity comes in the interconnections and dependencies on things like databases and middleware, which the version control system does not represent. A simple distributed system for example might have a database with stored procedures, several interlinked components on an application/web server, and dependencies on other systems via message queues. These dependencies cannot be derived directly from the software configuration management system.

A software development project of any real size should have a representation of these architectural dependencies (a problem domain recognized by software engineering theorists under the general area of “architectural description"; see this Google search). Usually, this representation is in an informal sketch maintained in a drawing tool (often Visio). Less often – and more desirably – the project will use the Object Management Group’s Unified Modeling Language, in particular the Deployment Diagram, to document the system. And the core point of this essay is that the deployment diagram can and should be a direct input into a CMDB.

Figure 1. Component CI deployed to server CI

The point of using the OMG’s modeling standards are that they are languages with a precise representation, not merely diagramming standards. The standard XML format for OMG models is called XML Metadata Interchange, or XMI. A VERY simplified pseudo-XMI fragment representing the above CI metadata, showing the server, the component, and their relationship (as an Association), would be:

Figure 2. XMI representation of deployment diagram (click to enlarge)

We have everything here we need to feed a configuration management system: objects with names and unique IDs, and a precise representation of their interconnections. Connections between servers and switches can be represented, between components and databases, and virtually anything else imaginable in the modern IT infrastructure. A competent XSLT programmer could convert this structure into whatever format a CMDB required; far preferable would be a CMDB that accepted this industry standard directly.

To think through the upstream implications on the software development lifecycle: the deployment diagram would not only be stored in the source code control repository, but it might actually define the structure of the project’s area in that repository. If the project architect defines a “Component1” on the deployment diagram, that in turn should be a major structuring element in the source control tool, under which all contributing software modules (e.g. Java classes) would be contained. There would be challenges in the case of component refactoring (if the deployment diagram is changed, does the directory structure of the source code control tool?), but these would not be impossible to handle with some thoughtful tools programming.

Model Driven Configuration Management will be an essential part of ERP for IT. It will help break down the longstanding and notoriously problematic handoff between development and operations. Since the deployment diagram would be maintained in a repository in a standard format, it should be available at all times to all interested stakeholders, making it a valuable resource for infrastructure planning, security analysis, capacity planning, and more. Additionally, it provides considerable efficiency in drawing upon the skills of the software architects for defining the CIs, rather than waiting for some downstream Configuration Item identification process to re-analyze the system from a configuration management perspective, work that is essentially non-value-add and redundant.

Acknowledgements to my colleague Chris Capadouca as a partner in the development of these concepts. You heard it here first!

Comments

[David Eddy]

At the dawn of Y2K time (e.g. early 1994 for me) I stumbled across the fact that no more than 10% of MVS sites worldwide had purchased a formal SCM (software configuration management... the then operative term) tool. The big two were Endevor (purchased by Computer Associates in 1995) and Serena's ChangeMan.

I probed multiple research & primary sources & find this 10% figure to believable. It was very easy to find companies who'd bought Endevor/Changemen (at $100,000+ these were non-trivial purchases... plus "mainframe" had recently become a very dirty word) and never adequately installed it.

So we've moved forward 10 years. The 'Net is every bit as much a production platform as mainframes.

Plus there was the Y2K push to inventory everything.

Now the question is how well used are such practices today... particularly when one SHOULD be folding websites into the equation. (Your websites **are** automagically hooked up to your mainframe systems... right?)

Last week I spoke with an academic who SWORE that use of SCM tools in Unix was very widespread & totally common. Needless to say I'm sceptical.

Inquiring minds need to know...?

[charlie]

I have not seen any distributed development project not use source control, in about 10 years of industry practice. The availability of CVS as a free and powerful solution has been a big help.

[Jorge Ubeda]

You pointed to a very interesting issue: SCM integrated into a MDA tool. Here are two sides to be considered (from my point of view): the first one, any MDA tool have a better way to try and solve it. The second one, given that with a MDA tool the application info is mantained at model level, the source code generated is apart and "irrelevant", if I need to define and preserve a release. What are your thoughts on it?
Jorge Ubeda

[Adam Sweeney]

>> I have not seen any distributed development project not use source control, in about 10 years of industry practice <<

I agree with this. It has definitely become the 'norm', as awareness has taken grip. This has not always been the case in the past of course.

By the way, some useful other references on process frameworks:

COBIT User Group: http://www.controlit.org
ITIL Open Guide: http://www.itlibrary.org

[dbai]

Do you know any XMI-based CI definition standard?