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!
