The Next Generation: 10 Requirements for Your CM/ALM Strategy

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.