Automating CM or Application Lifecycle Management

an access capability will set the tone for how critical its implementation is. When a rule is not implemented, there is typically hard data loss. When a policy is implemented, there is typically some data that can be transformed from the non-policy period, or the application can bridge across old and new policy. When an access capability for a particular function is not available, a user typically has to get implicit approval by finding a person who can sign-off on the capability by executing the desired function.

Your customization capabilities should be able to lock step with these levels. Perhaps a rule can only be implemented with special application modification permissions, or perhaps even by changing the application code itself. A policy should be more flexible and easier to implement by a person who "owns" a particular part of the process - perhaps a project manager, product manager or CM manager. Likely a policy change is implemented through scripting or by modifying some control data. It might also be implemented by adding new options, defaults or fields to data schema and to forms and dialogues. An access capability might be implemented by change role assignments, by changing the definition of a role, or by changing the GUI menu scripting such that the functionality appears for the designated person or role.

Again, if customization is difficult, process evolution will progress slowly or at a great cost. Errors in process implementation or judgement will be more difficult to role back and hence will have a greater impact.

An Example - CM+

In the CM+ architecture, we have rules and we have policy. Some of the rules are hard coded into the CM+ application, while others are scripted or configured. For example, in CM+, a baseline cannot be modified once it is permanently frozen. Our policy is that it is permanently frozen when we say "Freeze Configuration". However, the hard rule is that it can be re-opened after a "Freeze Configuration" operation as long as a subsequent candidate configuration has not yet been opened in the development stream. This allows a change of policy to allow a team to "re-freeze" baselines if necessary, so long as the next configuration has not yet been aligned. Such a change would supposedly be accompanied by an additional state for a baseline indicating when it is permanently frozen. And references to the baseline would have to be tentative until the permanently frozen designation was achieved. I don't necessarily recommend such a change in policy, and would argue that it really couldn't be called a baseline until permanently frozen, but the fact that CM+ would allow it is important for corporate processes which might require it. At the same time, the fact that CM+ will not allow a change to a permanently frozen baseline is also a very good thing. It allows the definition of true, immutable baselines.

Promotion of a problem report status to "fixed" in CM+ when the associated change is checked in is a policy decision. Some shops want an independent review of the change before giving it the designation "fixed". But the default, out-of-the-box behaviour assumes most problems are fixed by a single change, and so the designation is good. But the same default behaviour also has a verification state to which the problem is promoted after the fix has been verified. On the contrary, a feature referenced by a change is not promoted to "implemented" when the change is checked in. This is because most features, at least in an agile shop, will require more than one change for implementation.

So what's the