software CM technique: instead of trying to separate "developing releases" and "deploying released software," LDM merges the two. Thus, some parts of LDM are focused on "software configuration management" (updates to files) and other parts focus on "server configuration management" (installation of software).
The ITIL CM approach is concerned with tracking (via CMDB) the software and hardware configuration of individual servers and workstations. This approach treats servers in much the same way that other complex hardware systems, such as aircraft or ships, are treated. There are two basic operations that can be performed against the target: incremental updates and radical changes. Generally, a radical change is anything that invalidates the tracking of incremental updates, such as reformatting a server's hard drive and installing an operating system image. (If the image installed is from a recent backup, the change may be considered the invalidation or removal of the last ‘N' updates. If the image installed is from a distribution CD, it is generally easier to mark all the updates as invalidated and start again from scratch.)
Locations, of course, correspond fairly exactly to server environments. LDM is a merger of traditional release-oriented software CM with ITIL server-oriented CM. The ITIL Service Desk model doesn't know about work items and bundling because it focuses on pre-existing software. Traditional software CM doesn't care about servers because it focuses on quality evaluations and release intervals.
It's worth repeating that every different server or target work area is potentially a location in the LDM view. If a software change is made by a developer and checked in to the repository, that is only an update to the status of the Work Item. Using the example development environment above, testing the change will require pulling the changes associated with the Work Item out of the repository into some kind of bundle, and then deploying that bundle to a particular location: the Functional Test server/workspace. If the testing organization decides that the change is acceptable, the same bundle will be associated with a new deployment record, this one linking the bundle to the Regression Test server/workspace. (The two "locations" might be different directories on the same server: LBCM understands about budget limitations.)
In this way, LDM is a "larger" CM technique than classical release-based approaches. Classical CM manages software development, extending usually to source code or binaries. If a database has to be controlled, a classical CM approach will be to manage the DDL, and possibly control execution of the DDL as a build step (which implicitly constrains the syntax of the DDL: if a "rebuild" occurs, the updates must be idempotent).
LDM exploits the similarity between updates to work area and updates to a database. This lets us manage not just structural (DDL) database changes, but content (DML) changes as well. Tracking at the "deployment" level, instead of the "development" level, takes us from build and release management up to build, install, upgrade, administration and integration management. The cost is a looser grip on the system. The benefits are well worth it.
Change Orders & Work Items: LBCM Vocabulary
The Change order and Work Item entities are a basic implementation of the Task-Level Commit pattern. Work items have a very simple life cycle that consists of two main states: working and finished. These issues can be tied to other archiving systems as appropriate: see below. Once a work item has been finished, it can be bundled and deployed (see below) to server locations. LDM assumes that there is no going back: once a work item is deployed, it cannot be undeployed. From this it follows