How to Build a CM and ALM Strategy

[article]

In his CM: the Next Generation series, Joe Farah gives us a glimpse into the trends that CM experts will need to tackle and master based upon industry trends and future technology challenges.

Summary:
Joe Farah writes that a next-generation CM and 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.

Perhaps you've just not started doing CM on your project yet. Or maybe you have, and it's not going well: CM is consuming more staff than you expected. There is still plenty of rework because the CM process is failing. Initial and annual licensing fees are affecting your company's bottom line. But worst of all, your CM solution is not providing the expected benefits. What can you do?

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.

About the author

Joe Farah's picture Joe Farah

Joe Farah is the President and CEO of Neuma Technology and is a regular contributor to the CM Journal. Prior to co-founding Neuma in 1990 and directing the development of CM+, Joe was Director of Software Architecture and Technology at Mitel, and in the 1970s a Development Manager at Nortel (Bell-Northern Research) where he developed the Program Library System (PLS) still heavily in use by Nortel's largest projects. A software developer since the late 1960s, Joe holds a B.A.Sc. degree in Engineering Science from the University of Toronto. You can contact Joe at farah@neuma.com

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!