Top Ten Requirements for Your CM and ALM Strategy

In my article, "Building a CM and ALM Strategy," I took a high-level look at the requirements needed for a successful next-generation configuration management (CM) and application lifecycle management (ALM) solution strategy. In this article, I’m taking those same requirements and looking deeper into them.

1.  Low Total Cost of Ownership (TCO): Obviously, open source; it's free—well, except for the training. OK, upgrades too. Some administration, but that's to be expected. And we'll worry about the rest of the team later—when we buy more tools—hopefully they will integrate nicely without too much effort. The tool has all sorts of ways to customize it; all we have to do is provide the staff. Oh, and I'm sure there are some open source user interfaces that can go on top of the command line.

Get the picture? Open source may very well mean free, but it doesn't mean low cost. Yes, it is preferable to spending several thousand dollars licensing per user for a commercial solution, especially one that's even got higher training, consulting, and administrative costs. So it certainly looks a lot better. The problem is, you haven't looked enough.

What about a tool that costs a few hundred dollars per user, requires minimal training, has virtually no administration, and does not require a bunch of add-on tools or a separate database product in order to complete the solution?  Have you found one yet? Look harder.

2. The Best Technology: Get smart! Don't use vendors to show you how their solution is best. Do some homework and pick out the best features of various solutions. Then bring the vendors in and ask how they support these features. We're talking CM and ALM features; the requirements are well known. If vendors can't meet the feature requirements, cross them off your list—DON'T LOWER YOUR REQUIREMENTS.  Use the vendors to learn all the best features and then look for a tool that provides all of these features. Realistically, you may not find 100 percent coverage in one tool, but if you look hard enough, you will come very, very close.

3. A Team Tool: Developers don't like overhead. They want a tool that has little overhead or one that they are familiar with. The same goes for the rest of the team: testers, project managers, CM managers, development managers, executives, technical writers, marketing team, and product management. Don't provide each group its own tool—you'll NEVER get them to work together. 

First of all, raise the bar. Don't get a tool that minimizes developer overhead. Get one that gives them a lot more than they could have hoped for and that makes them more productive. Give them something that does things for them that they'll go "wow" at; things that they haven't considered. Developers are familiar with low-level CM tools for the most part. Show them a way to navigate the riches of the CM repository to help them do their work more productively. Don't minimize their interaction with the information.

Then move on to each and every role on the team. If you could have the best tool for a given role, what would it do? What would make it be so easy to use that training is minimal? How does it increase the user’s knowledge in his role so that others consider him an expert?

This is the type of team tool you need.

4. Product Quality and Product Requirements: These sort of go hand in hand, as they focus on the customer. Agile works well in many scenarios, but whatever the scenario, clear communication of requirements, including the fact that a customer seldom knows exactly what he wants, and the ability to change requirements incrementally is important. Maybe in a launch vehicle the requirements change less, but change is still inevitable and the better it's supported, the happier your customer will be.

Yes, it's important to trace test cases to requirements and do functional audits, etc. Good tools can do these. But great tools go beyond and answer questions such as: When did this requirement last fail to be met? What requirements have changed between these two builds? What's the status of each customer issue? What's the status of each customer?

Great design can result in a great product. But take away the proper ALM functions, and your great design will not result in a successful product. Delivery issues, customer feedback, quality assurance issues—these will all haunt you if they are not dealt will properly.5. CM Tool Reliability and Availability: Want to turn someone off using the tools? Make them unreliable. Maybe they crash too often. Maybe they don't quite enforce the process properly. Maybe there are too many cases where the baseline just wasn't recorded properly (and once is usually enough!). If you can't trust your CM repository, you're in trouble.

But even if you can, it's got to be there when you need it. And that doesn't just mean at critical times. If your server goes down and it means all users can't get information—big loss. If your upgrade puts the tool offline for half a day—big loss. If it doesn't recover automatically from a power outage—potential loss.

Your CM tools should be more robust than your operating system—at least from a server perspective. If you're "rebooting" your CM tools more often than you're rebooting your OS, you've got problems.

What kind of recovery tools does your solution provide for data corruption? Ideally, there is NEVER any data corruption. The tool I use I thought fit that category—until the day we found out that the faulty hard drive was spraying random errors across the repository. Fortunately, we had a "warm-standby" recovery capability and were back up in a few minutes. Or there's the one where the defense department came in and said, "We're going to wipe your drive clean to see how well you recover." Guess what? The backups weren't doing their job properly. Fortunately, they did have all of their transactions from day one and they simply reran them and in a few hours their CM database was back up and running. Not so for some other apps.

What are the odds that a hurricane takes out the entire building or that a tsunami strikes? You have to cover all the bases, and few, though some, tools do. Insurance might cover your assets, but it won't cover your customers, so make sure disaster recovery is addressed.

6. Longevity: OK, ten years is one thing, but thirty? If that's a requirement for your project, what do you do? You get a tool with a track record and one that you can have confidence that it will remain available and sufficiently current to support you. I've built in-house tools that have lasted more than a quarter century. Tools like ClearCase, Synergy, and CM+ have been around for darn near that long, even though the former two have gone through some ownership changes. It would be interesting to look at these three tools, and perhaps one or two others, and identify a few things:

• How much have they progressed, feature-wise, each release?
• How difficult would it have been to transition a CM repository through all of the releases?
• What has administration requirements been like for each of them?
• How current is the newest release, in terms of what today's user expects?
• What would be the cumulative cost of CM (licenses and admin/support) for fifty users over the past twenty years?

Speaking from experience, the CM database I'm currently using is almost twenty-five years old. There was a major (full day) upgrade back in the 1990s. Apart from that, just a few minutes per upgrade. It's an extremely different product from when it first came out, but the repository is still plenty robust and far more advanced than a RDBMS, and even after nearly twenty-five years, we're still not close to tapping its potential capabilities. That's longevity. And it gives me confidence that, even if the technology development stopped, there's plenty of existing technology to tap to keep evolving capabilities in house for the next ten years. In fact, I know of a few companies that acquired the technology before annual fees were mandatory, and they're still using versions that are more than a dozen years old for current projects—with zero upgrades!

7. Corporate Culture and Process Constantly Changing: This requirement is all about customization. I don't want to change a screen from blue to green. I want to redefine a dashboard based on the changing role definitions our management has decided upon. And I might only have a day or two notice. Or, perhaps we want to move from a central development team to a globally distributed team but continue to work as if we were a central team. 

Here, when we look at the technology, we look not so much at "features" but at "capabilities." Technology should be viewed in (at least) two components: The architecture and the end-user functionality. Take a CM tool that doesn't support change packages and add change packages to it. Now compare it to a CM tool that has supported change packages for twenty years. Do you think you'd see a difference? The latter will have evolved with change packages as part of its soul, its architecture. The former will probably have a database feature that aggregates files and perhaps a UI that lets you do some basic operations on change packages.

Now apply that to customization. Take a CM tool or an ALM tool that was built as a specific tool with a cool feature, say the ability to link file changes to problem reports and features. It may have many UI capabilities that allow you to do some traceability, reporting, etc. Great. Now take a second CM tool that allows you to create any object type (problems, changes, test runs, customers, companies, etc.) that you want, and that lets you create traceability links of various kinds between any two objects. Add in the capability to automatically generate graphs, displays, etc., that allow point-and-click traversal of these links, or reports based on arbitrary consideration of the data linked together, and what you have is not just the ability to link file changes to problem reports and features but a capability to create a structure that meets your requirements, in this case traceability and the related data navigation.

Apply this to an example: Maybe you want customer requests to be transformed to engineering problem reports or engineering features, the latter being linked to new revisions of requirements. Perhaps you want change packages that can be linked to the engineering problems or features and to internal refactoring activities. Maybe your culture also says each problem report must link to a test case to verify it, and each feature must have a set of test cases for it. Now, with the first tool, the "cool feature" one, you'd just say, we can do some of that and perhaps use a database and spreadsheets for the rest. In the second tool, the one with capabilities, you'd implement the exact process you want.But I can't stress enough that it must be nearly child's play to do these things. Don't hand me a compiler or scripting language and say "Yes, you can do it." Instead, in the five minutes I give you, show me how it is done, right in front of my eyes. That's a capability. That's what you need to support corporate culture and process.

Yes, there are other things: role definition, dashboard generation, custom forms and dialogs, dynamic schema definitions, state-flow definitions, with roles guarding transitions and a decent, configurable "portal" or main screen that has my to-do lists, quick links, frequent reports, etc. Give me these things, and I can customize the tool to do what our project wants.

Let me do it in hours instead of days, weeks, or months, and you've got a winner. Look for this technology if this requirement is important to you. You'll find it.

8.  Global Operation: If you are currently a multiple site organization, or see your organization growing into one, recognize that from the start. Don't pick up a technology that's not going to let you deal with multiple sites. And don't yield to the temptation that says, "We'll wait until the need arises." 

Do you really want to cause major upheaval of your development shop just as you're moving to a multiple site solution? Wouldn't you rather see a solution that looks the same for multiple sites as for a single site? We have long passed the point where technology and bandwidth allow such an operation.

Global operation solutions need to take into account the fact that there may be extended network outages between sites or intermittent outages as the world changes. They need to acknowledge that you may want all your assets available at all sites or that you may want to restrict some assets from some sites because, for example, the government is not stable.

Some people are of the mind that global operation is a license for hiring additional administrators. I ask, why should you need additional administrators? Doesn't the technology do all the work? Is it not reliable? I want global operation to reduce my administration! After all, with multiple sites, I should have an automatic disaster recovery capability. And, I should be able to reduce my "backups" because I have live sites that are live backups of one another.

9. Low Training Costs: Too many organizations forget this as a strategic requirement. It's no good paying only a few hundred dollars per user for licenses, when I have to pay a couple of thousand for training! Do you want a training package that is two-weeks long or one that is two-days long? You'll pay more for two weeks, and the product’s complexity will be significantly more. But that does not mean the functionality will be greater.

Look at developer training. Yes, it might be fun to be on a week-long training course, but you've just consumed 2 percent of your developer resources for the current year. And for that privilege, you've probably had to pay 2 percent additional salary. When's the last time you sent your developer on a course to learn how to use a text editor or spreadsheet? Why not? Because they are easy to use.

If your solution means you have to teach developers a whole new set of commands, what their options are, and how they all fit together, maybe your solution is not as modern as you thought. It's one thing to teach concepts and perhaps a bit of tool-specific terminology. But developers know most of the process. They should be able to sit down with the tool after a couple hours of training and run with it.

If you're addressing the full lifecycle, you'll have fewer technical users, too. The tools have to be even easier to use, but not just to do the same old task. The ease-of-use for new functionality is critical. That's where dashboard customization is critical. That's where concepts like active workspace displays, custom in-tool process guidance, handy links and to-do lists, and intuitive queries and traceability navigation become important. Don't make me learn a dozen commands. Don't make me search through pull-down menus. Let me point-and-click. Put the information up that I'll need. Fill in the default values based on my context and on what I'm doing. Minimize my training.

10. Mature CM: Some organizations like to force exclusive checkouts; others want only parallel checkouts. Some use agile methods; others use traditional methods. Some want fixes automatically propagated from one development stream (i.e., release trunk) to another; others never want that done automatically. Some want to allow a workspace to be used for multiple concurrent changes; others want a separate workspace per change. Some want all files in the workspace R/W; others want only checked out files to be R/W. Some want files to be checked out before they’re modified; others want to make changes to the workspace and then let the tool figure out what was done.There are dozens of different preferences. Some are just bad (e.g., not using change packages for software). What's important is that the capabilities of your CM/ALM environment can cater to these. And can streamline operation based on your preferences. If you're using an agile method, your CM/ALM tool should, in a single click, show you what's on your plate for the next iteration. You shouldn't need to go running to the product owner to find this out. And though verbal discussion is good, the assignments, priorities, and objectives or stories behind each activity should be clear from your tools.

A lot of projects start up as if there will only ever be one release of the software, only to find that as time goes on they are supporting multiple releases and perhaps more than one variant within each release. You need the capabilities in your tools and processes to handle this.

If your tools have the capability to understand your processes, they can help you. If your branching strategy is customized within your tool, your tool can tell your developers when they need to branch, rather than vice versa. It can also tell you when a change you make may need to be applied to other development streams; that's mature CM. If your tool allows you to customize dependency relationships (e.g., this change before that one), and understands these relationships, it can tell the developer or the builds/CM manager when promoting a change package will cause dependency violations, and specifically what those violations are.

On the other hand, if you sort of have change packages (e.g., everything that you commit in a single transaction), then when you find that you've forgotten a file or need to correct a typo, requiring another transaction, your "change package" integrity is broken. If you're using file-based rather than change-based CM, and you don't promote all of your files, the CM tool can't tell you you've made a mistake, or that only an arbitrary portion of your change went into the build.

Don't Give In
I've gone on way too long here, but hopefully the message is clear. Identify next-generation requirements. Look around at the tools that support the capabilities that will let you meet these requirements, then formulate your CM/ALM strategy.

Don't compromise your strategy because your CM manager is only used to tool ABC. Don't compromise, because with tool XYZ supporting process QUP, you know how much support, administration, and training costs you had to absorb to get a partial solution.

Identify your requirements, and find the solution that meets or exceeds these requirements. Aim high. You don't want to go through this process again in three to five years. It's costly. Get all parties in your product team involved. Put a next-generation CM/ALM strategy in place for the whole organization based on your needed capabilities.

If you can't find good tools, call me or drop me an email with your requirements. I'll help you—no charge!  Don't give up and compromise.