developed and deployed on several different platforms and technologies: Cobol, PL/SQL, Java/WSAD and .NET running on iSeries, Linux, and Windows. The high level of abstraction lets a single unified work flow control development across the board, because the gritty details of software development are encapsulated in the change, bundle, and deploy model.
LDM also supports multiple, diverse teams. Because LDM is disconnected from the particular details of development, build, test, and release for a team, it can support different teams working separately or together. LDM moves management of the flow of changes to a higher level. This permits different teams using different work flows to use the same underlying investment in tools and scripting. It also lets separate teams quickly agree on a shared high-level work flow without the need to radically change the teams' internal development processes.
Teams that share a common LDM foundation can combine and divide again with very little stress. LDM enables organizations to treat their development teams and sub-teams as building blocks, so as to quickly react, at the organizational level, to development challenges.
Finally, LDM works regardless of geographic location. While the system assumes a single repository for storing workflow objects like bundles, change orders, etc., it also assumes that the key question in the CM process regards the location of changes. In a geographically diverse development environment, LDM requires that the abstract deployment method be capable of operating across the network, and requires that the Location records be capable of explicitly identifying a location. Beyond those requirements, LDM handles geographic complexity just as well as technological or organizational complexity.
Drawbacks & Constraints
LDM requires the abstraction of the basic CM and build operations. There is no way to implement LDM without a solid understanding of the individual steps in the software change flow, or without the ability to script those changes. A scripting or automation specialist is essential.
There is an absolute technical minimum: LDM requires tightly integrated tools. If you cannot or will not provide this level of integration, LDM will be difficult or impossible to implement. (You will wind up coding and supporting the tight integration yourself. This is a waste of money and time: you should buy this, not build it.)
Another requirement is a complex enterprise. While it is possible to implement LDM for a simple development environment, it probably isn't worth it. LDM excels at supporting database development, and at abstracting the complex details of a multi-technology or multi-team environment. Simpler environments can use simpler solutions.
The hardware environment needs to roughly correspond with the development life cycle. A change order life cycle that features nine different states with four test phases is unlikely to map cleanly to a development environment that has only two server locations. It may be that the process can be redesigned or it may be that some compromise between a ‘pure' LDM implementation and a ‘qualitative' approach can be reached. This is an area that needs exploration.
Details Abstraction & Automation
LDM works by abstracting build and release management operations to a high level, and expressing all CM operations for all components at the same level. Doing so requires a clearly understood model of the development process shared across the enterprise. Everyone involved has to understand and agree to the abstract model. Since that model will be simpler than the models used in the various teams throughout the enterprise, it should be fairly straightforward to get general agreement to a simplified schema.
At the same time, the model has to be sufficiently expressive and powerful to serve. A model is worthless if it