change management

A project baseline is the fundamental CM technique for release management. Configuration management has historically been about managing the acquisition of new products. To that end, a set of baselines is defined corresponding to various milestones in the product development cycle. These baselines reflect different expressions of the final product and include the functional, allocated, and released baselines.

We build software as part of a system or as its own entire product. The goal is to meet the requirements established by the customer, the market and/or the cost/benefits analysis. Product releases are meant to move us from some starting point to our ultimate product over a period of time: months, years or even decades. Release management starts not with the delivery of software, but with the identification of what we're planning to put into the product. The timing and content of releases helps us to manage releases so that they are not too onerous on the customer and so that we stay in a competitive position with our products. Good release management processes will ensure that you know what is going to go into your product, what actually went into the product, and what changes the customer is going to realize upon upgrading.

When it comes to IT governance, a key issue is transparency of process and data, all the way up the chain.

CM architecture has the ability to influence the market even more so than vice versa. The complexity of CM and ALM forces vendors to take the lead in market development. But the market will have its influence, and those solutions with strong architectures will be in the best position to serve that market. Last year at this time, I identified where I thought the CM solution space was heading generally. Looking back two and three years ago, I painted a bit of a picture of what defines 3rd and 4th generation CM/ALM solutions. Over the next couple of years, we should expect to see competitive and market pressures push the industry into the 3rd generation.