How to Build a CM and ALM Strategy

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.

And what's more, things just got worse. CM became ALM. We didn't have just one tool or vendor to deal with, there were several. And when one was upgraded to provide features we'd need, the result was that the entire solution of tools was no longer compatible and needed additional customization just to get things working properly. Upgrades became time-consuming and expensive.

The Next Generation
So how do you eliminate all these problems? What's the solution? Many will claim there is no solution; that's just the way things are. As a result, many companies defer CM until it is "absolutely necessary," as if it weren't from the start.

A successful CM/ALM strategy starts by looking at all of CM and ALM. Not just the technology. Not just the CM manager and developers. Not just the process. There are other things like: cost, vendors, product team, customers, time-to-market, product management, availability, solution longevity, ALM lifecycle, corporate culture, changing technology, global teams, training, reliability, and asset security.

Add these to the mix, and then start on your requirements. Then, and only then, work out your CM/ALM strategy.

We know the "old way" (you start with tools), and the "process is king" days (you start with process). In the next generation you start with capabilities. You want to ensure that your tools have certain capabilities and that your process can be implemented given that set of capabilities. More than that, you want to be sure that the capabilities allow your process to change as necessary, and that the capabilities presume a certain architecture within your tools.

But you have to be aggressive with your capabilities. It's not enough to be able to specify your process. You need the same process tool across the entire ALM solution. You need to share data across the solution. It's not good enough to be able to make changes. They have to be made quickly and easily, not tying up resources or causing delays. I don't want to reduce my administration team from six persons to three—I want to virtually eliminate the need for administration.

And with the ALM and CM features it’s the same. It's not good enough to improve the quality of our CM process; it needs to be fully automated so that it continues to improve in quality over time, and so that it isn't impacted by typos, vacation time, or tiredness.

The Requirements for Building a Strong CM/ALM Strategy
A good CM/ALM strategy must start with a clear understanding of your requirements. A strategy that says, we'll just worry about the next two years and get a better strategy in place then, is sort of like saying—we'll finish the house first and then worry about plumbing, heating, and electricity later. Don't waste your time. Understand your CM/ALM requirements up front.

It's not a strategy just for your project. It's a strategy for your organization and even for your customers and vendors. It's a strategy with a mission that says we won't settle for anything but the best, but we're not willing to give away the company to get it.

So what are some of the key requirements that will lead to a successful strategy? You've heard them from me before:

1. Low Total Cost of Ownership (TCO): I want tools and process that are going to give me an overall low cost.
2. The Best Technology: I'm not looking for the market leader. I want to know what all of the tools can do.
3. A Team Tool: Not what my developers say they like—what my team needs.
4. Product Quality and Product Requirements: This is not just a design issue—it's an ALM issue.
5. CM Tool Reliability and Availability: If I don't have accurate data always available, it costs a lot.
6. Longevity: I want a tool that lasts the entire product lifetime, whether one year or thirty. It's too hard and costly to change.
7. Corporate Culture and Process Constantly Changing: It's got to meet our corporate culture and process requirements—not the vendor's. And our needs will change!
8. Global Operation: My team is globally distributed and so are my customers. The solution must support this.
9. Low Training Costs: I don't have time for training the entire product team to use the tools. I'll give you a few hours, maybe more for CM staff.
10. Mature CM!

Ask for the world, and you'll never get a solution that fits. What's the point?

That's old school thinking. There's stronger technology out there than what you're familiar with. Put the requirements out there and someone will meet them. If you chase the market leader or an open source solution, you'll satisfy some of the requirements. If you go for a next-generation solution, you'll be pleasantly surprised.

Your CM/ALM strategy must include a next-generation solution. Why? Because these very requirements define the next-generation solution. you look at the a solution only for your developers or a solution that doesn't cost anything, or one that everyone seems to be using, you'll leave yourself with the same problems, only with different parameters.

In "The Next Generation: 10 Requirements for Your CM/ALM Strategy," I take these requirements and examine them more fully.