CM: THE NEXT GENERATION: From Version Control to Product Management

collection of products. This perspective should include all of the data and processes necessary to successfully manage the product. The scope of management may start with the development team and over time grow to the entire product team. So the next thing to look at is how does the solution expand over time to meet the widening scope. There are some solutions out there that are barely tapping their technology's potential, while others have been maxed out for years. It makes sense to look at the history of the solution to understand not only how it has grown, but how it can grow. Then remember that the road from Version Control to Configuration Management is complex, but it doesn't help to take short cuts. So here are a few other guidelines.

• Make sure that your data is centralized. What I mean by this is that it's not distributed across files, such as in your version control files. It's fine to have data there, but it's not going to be of much use if I have to open and query 20,000 files to perform a simple query. Your CM data must reside in some central database.
• Version control systems are limited to performing change control at the file level. This is very unnatural. Change control needs to be done at the change level. Otherwise I have to implement a way of linking all of my file revisions to a common cause so that I can perform change-based operations such as ensuring that the entire change is checked in, creating a delta/difference report for the change, and ensuring that all revisions get promoted for a change. Make sure that the "change package" technology is central to the CM solution. Adding change packages into a file-based solution doesn't cut it. An automatic baseline generation tool that works for file revisions will not adjust easily to one that works on changes. A file promotion solution has numerous problems that cry out for a change-based promotion solution. Change packages should be the central point of traceability.
• Change management involves Change Requests (CRs) as well as Changes. These are not the same. A CR is basically a Problem Report or a Feature Request. It is requesting a change to the product. However, development teams need the flexibility of implementing CRs in the most beneficial fashion. For a complex CR, typically an initial change will be made to allow easier transition to the new functionality, at either or both of the Product and Design levels. Perhaps an initial change goes in to ensure that previously unused data fields are initialized. Or perhaps existing APIs are modified so that the development may proceed more easily. CRs will often involve a series of Changes. And sometimes a Change may address more than one CR. If you don't treat these separately, you'll find that you'll be shoe-horning your process into an inadequate model.
• Workflow management must be central to the CM solution. It's not sufficient to have a nice modeling tool if the CM solution has to be retrofitted to support the model. It's perhaps even worse to have one type of workflow management for problem/issue tracking, another for change management and another for build management.
• Look for a seamlessly integrated set of applications. You want to avoid the costs of training on different tools, of having vendors point fingers at one another, of coordinating upgrades across vendors. You want to avoid having to do the integration glue yourself. You don't want to have to deal with multiple repositories for different parts of your solution - it will inevitably lead