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. 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 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 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.
We'll call our client “Really Big Financial,” or RBF, and hope they don't sue us. RBF is an American company providing insurance to a niche market. That niche has experienced sustained, profitable growth. As usual, market growth means buyouts and mergers—RBF has development and production facilities spread across North America, and suffers from the usual confusion caused by trying to combine separate organizations.
RBF does software development as an IT function, not as an R&D function: the primary purpose of software development is to support their own business, and RBF's software “customers” are other RBF divisions or business partners. There is a smörgåsbord of different technologies at play: there are COBOL applications doing back office functions and supporting thin-client systems. There are Java and .NET middle-tier and thick-client applications. And there is a new but substantial metadata-based application development environment supporting a web interface.
RBF's legacy software