in your CEM tool which would in turn create the SCM release or package as an empty shell in your SCM tool. Through sound project management requirement gathering you identify the components that will make up your functionality changes to be placed into the package. Make the changes needed to support your new functionality and wrap all those changes and cast your package for release. The change record within the CEM tool can now be promoted with the proper approvals by those responsible business managers and environment owners through each stage of the life cycle.
Along with the CEM change record the package/release within the SCM tool is promoted and automatically installed with the proper trigger, into each environment as it goes through the stages of the life cycle. Eventually an approval for a production change control occurs within the CEM tool generating an install from SCM of the package to production and if no failures are experienced your life cycle ends for that package/release. Many packages/releases could be occurring at any given time which SCM tools can handle but you still have the environmental concerns between each stage of the life cycle and that is another management aspect which process, asset tracking, cross functional impacts and proper SCM tools or processes can assist in identifying to ensure a smooth transition of any change.
In a previous life I have combined the different but critical functions of a CEM tool and SCM tool to automate the entire life cycle in as close to a “Perfect World” as one could hope to come too. It was specific to a proprietary platform but the entire process was “almost” flawless. I loved being able to help in the design, implementation and support of such a beautiful process. All of us in technology know very well that change is inevitable and constant. Too often vendors of change products of any kind miss the mark when it comes to total change harmony but without the tools working together you can define procedures and processes and document them for all to see and use to make technology changes your ally and not your enemy.
So that leaves us with a state of change which has too many tools that do not communicate with each other. We as experts of configuration and change have to design processes and procedures that mimic as close to possible a complete and bullet proof life cycle process. I have designed and seen many others create ingenious methods to make tools work together as best as possible but the industry tool makers have to stop thinking about each part of change as a separate entity and to build and all encompassing product which can handle the full configuration and change processes harmoniously and seamlessly. That has yet to happen and while some tool vendors provide the various bits and pieces a disconnect between each of those tools still exists.
There also needs to be a move away from project managers as those in corporations who drive IT change as they are working on any number of specific efforts at a time and their focus is to complete projects and move on to the next set of requirements which is not a bad thing. It is just that they are not immersed in all the areas of technology change. But there are many pragmatic SCM and CEM people who can work all sides of the change equation. We as change experts are waiting for the lights to come on and for the tools to catch up with our experiences and of course for