A perennial question in the configuration management field is how to control databases. Databases are too big and too complex to be managed as simple objects. They have a very expressive language—SQL—for describing their structure, content, and changes. Database CM is important when either the structure or the content of a critical database is being managed. And it is essential for the growing number of business systems driven by metadata^[1]. Despite this need, there have been no general solutions available. Commercial vendors have not taken the obvious step of providing generalized configuration and/or change management support, and CM solutions for databases have focused on the structure only, treating content and other attributes, including triggers and stored procedures, as an installation problem rather than a development problem.

A newer issue is how to do Enterprise^[2] CM. Some CM tool vendors have attempted to provide support for large-scale systems (e.g., Component Based Development). And vendors have been attempting to support geographically distributed development for some time. Full support for complex enterprise systems is still lacking, however. Supporting complex systems, like supporting complex organizations, is a hard problem.

A recent project needed both functions. A multi-technology system demanded tracking of changes from requirements through retirement. The system included Cobol, Java, and .NET components, but the key component was a metadata tool for application development. The metadata tool was built on an Oracle database, where business logic and business variables were defined and maintained. Software development in this environment centered around changes to the database made with the metadata tool, and involved managing change across the full set of different technologies, across different organizations, in offices that were widely separated. In short, we needed to provide both Enterprise CM and Database CM.

We realized that we were facing two problems with one solution: the diversity of the enterprise forced us to abandon the traditional “software release” approach to CM in favor of a higher level, more abstract solution. Taking an abstract view let us redesign the develop, test, and deploy work flow so that we could manage source code and database content updates interchangeably. We call this technique Longacre Deployment Management™ (LDM), and use it to track the progression of all types of intellectual property (IP)—program logic, hardware and software configuration, database structure or content—through a single, abstract life cycle.

We believe that LDM is essential to successfully implementing CM in a database-heavy enterprise, and that it provides significant advantages over other software release–based techniques where divergent technologies are involved. The novelty of the LDM technique inspired the writing of this case study, along with an accompanying article^[3] describing the technical details of implementing LDM. We have endeavored to separate the two. This case study presents the situation faced by our client, and the solutions we devised. The details of LDM provided here are only those relevant to discussing the CM system we implemented. Likewise, the client details in the LDM article are confined to those relevant to providing implementation hints for LDM.

[1]:   ‘Metadata’ is data about data. A data dictionary or an XML schema, for example. A more basic example is a screen definition language, specifying the position and title of fields to be displayed, but leaving the field values themselves to be extracted from another data source.

[2]:     Enterprise is defined first as “a project or undertaking that is especially difficult, complicated, or risky.” Later comes “a business organization.” We mean the first sense of the word.

[3]:     Austin Hastings, “Technical Introduction to Longacre Deployment Management™,” CM Journal, 15 April, 2007, URL: http://www.cmcrossroads.com/content/view/7910/240 (accessed 15 April, 2007).