A next-generation CM/ALM strategy may seem aggressive, but it will help ensure that you're happy with the result. It will make sure that you deal with the entire problem domain from an organization perspective, rather than just the part your team is traditionally comfortable with.
The Old Way
Configuration management (CM) and application lifecycle management (ALM) have both been around for a while (although the ALM acronym is only a decade old). In the early days of CM it was simple—the requirement was simply to be able to reproduce what we build. That's pretty much it. If I can reproduce what I build, then when I have a success point, I can keep it—I know the configuration.
Then CM moved rapidly on to the question: How can I change my configuration from a successful state to another successful state and continue to reproduce each state? Basically, change control and change management.
So the first tools were custom built to support these basic configuration management and change control capabilities. Generally, these were home grown tools. Of course, they required staff to create and to maintain. As time went on, some components (e.g., SCCS, MAKE) appeared.
Toward the end of the 1980s and early 1990s, there came a flow of commercially supported configuration management and change control tools. All you had to do was buy the tool, then change your corporate development process to fit the tool's process, and Eureka! it did CM. No more staff to create a custom solution.
The problem was, it was the tool's process—and that process wasn't ours!
Process Is King
Through the 80s and 90s there was plenty of wisdom that said you need the right process. Get the process right. So the new approach was to get the process right, document it, then find the CM tool that best supported that process and use it.
An alternate approach was to trust the experts who got the process down right for their companies, and then built or used tools to support it. Using the same tools would give you the same process, and you wouldn't have to develop the process or the tools.
Just a couple of problems: First, the process was not really what we wanted. We needed a few things to be different. Our company culture was different. Our development and marketing were different. Yes, we had a process and a tool, but it didn't quite fit.
And even when it sort of fit, we found that as we got deeper and deeper into development, the process had to change. We discovered problems with the process that affected our quality. Technology was changing and a command-line-based tool no longer cut it with our staff. Development was using new methodologies. We understood the process better, so we could see what else was needed.
Do It Your Way
So the next step in the CM/ALM evolution cycle arose—tools and processes that could be customized. No more buying a fixed tool and living with it. I needed one with a database that could accept new data schema and with a user interface that could change. The tool also had to give me a way to implement (i.e., support) our corporate processes.
Now, I could start with a predefined process, a commercial tool, and put together a team that could customize the process and tool. But ... wait a minute ... I had just eliminated the need for a team to build processes and tools. And now these customizations were not easy, requiring a team and needing to be maintained and changed over time.
Tool vendors to the rescue: "We'll do the customization for you while you keep your staff doing what it was working on." Again, problems. We now had to pay outrageous fees to have our tools customized. Furthermore, we still had to spend significant effort both instructing the vendors or consultants on what our process was supposed to be and on verifying that their customizations were adequate.