What is CM Architecture Anyway?

twenty years ago during the development of Neuma’s own CM+ tool (Full disclosure: author works for Neuma) we saw the need for dynamically configured user interfaces and created a GUI definition language for rapid specification of dialog panels. Over time, we simply expanded the language so that we can now put a script line together that specifies a full interactive dashboard using the same language architecture but with new capabilities.

Similarly, we saw the need for a process engine, an object-based hybrid repository, a high-level scripting capability, dynamically changing data and object dependencies, rapid traceability navigation, and interactive reports. How did we see these needs? From experience in previous large software projects which had limitations in these areas. To address these needs, we focused on the architectural requirements that apply not only to CM but to most management tools. By focusing on these, the CM tool architecture was established by Neuma's core development team. A rich set of CM-specific capabilities, as opposed to features, and a focus on easy end-user configuration allowed us to support quite a wide range of CM solutions, for both traditional and agile shops, for both SW and SW/HW teams, for both CMMI and CMII certifications, all from a single software base.

And there net benefits to sound architecture. In the case of a good “solution architecture” that outlasts the life of the project, you won’t have to swap out solutions part way through the project. You can remain productive and maintain and improve your CM process over time. You don’t have to pay twice for tools, training, customization, and configuration. You avoid data and code migration costs, the lost productivity during conversion, the subtle (and not-so-subtle) changes to process, the evaluation project for selecting a new solution, and so on. And all of these problems are avoided when the project is in full swing! So you avoid risking delivery schedules and costs by having good CM solution architecture.

In the case of good CM tool architecture, a vendor can instil confidence into its customers. The good architecture helps avoid complex or costly upgrade procedures. It allows the CM process to evolve without undue restrictions, and it means the CM tool will have a longer life span, not cut short by technological or philosophical pressures. A strong CM tool architecture increases the likelihood that the CM tool can be easily adopted throughout the organization.

It doesn’t really matter what you’re building, just get the architecture right if it has to last. Architecture adds longevity, and that’s beautiful in its own way.