Longacre Deployment Management for Enterprise Configuration Management


cannot answer the questions your team asks. While simplifying is important, maintaining useful details is crucial. The balance requires cooperation and input from all participants during requirements gathering. (You can't afford to alienate anyone until after you pick their brain.)

When you abstract the process model, automation is absolutely crucial. Regardless of the underlying technology, regardless of the physical location of the repository or the target server environments, regardless of the political boundaries being crossed: the abstracted operations have to have the same interface, the same behavior, and the same results. Being able to automate the procedures is essential to being able to develop the abstractions required for LDM. If you can't automate the underlying methods, because you don't have the time or the knowledge or the authority, you won't be able to get LDM working. Get help.

The automation issue is almost certainly deeper than it looks. If the enterprise uses several different technologies, then automation has to support those different technologies. It isn't enough to have some VB skills. You'll need skills appropriate to all the technologies. Do you have JCL skills? ObjectRexx? Perl? JavaScript? VB.net? Make sure that you either have the skills, know how to get the skills, or have the budget to buy or rent the skills.

Data vs. Metadata
Traditional software CM techniques define a change order work flow using states. The states typically represent the "wait intervals" in the software development process: "the order has been submitted by a user and is waiting to be approved by management," or "the order has been worked by the developer and is waiting to undergo formal testing." This set of states is defined to apply to each change order. In this model, the change orders are data, and the set of states are metadata that remain constant during routine operations.


Most shops define their change order work flow with states that correspond exactly to their testing environment. If the shop performs two kinds of testing, change orders will have two states reflecting those test steps. This is an intuitive breakdown, albeit specific to the process followed within the shop. The fact that the development and testing teams use two testing phases is not always useful or relevant to anyone not part of those two teams. After breaking down the process and encoding the process states into the change order work flow, it is common to see one or more translating metadata fields created that simplify the technical work flow to something usable in metrics or in reports to upper management. (Consider the classic "Open/Closed Report.")

It is obvious from this translation that not every part of the organization shares the same view of the software change life cycle. LDM encourages adopting a simpler life cycle-not quite as simple as Open/Closed but less elaborately detailed than most. Part of this simplification comes from the observation that many of the states in a traditional work flow correspond to locations-server targets where code can be installed for work or testing . By encoding locations as data-separate records in the system-instead of metadata, LDM encourages change order states to correspond to the purpose rather than the implementation of the work flow.


This may not be as simple as the Open/Closed report, but it is generally more comprehensible to upper management. It is also much easier for a non-specific lifecycle to be adopted as a corporate or enterprise standard. By removing artifacts that are specific to a particular toolset or technology, the abstracted work flow can be standardized across all toolsets and technologies.

Similarly, when two historically separate teams start

About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.