A recent CM discussion on LinkedIn asks what is CM architecture? We all know there are CM plans, process guidelines, handbooks, and other tools, but how exactly can we define CM architecture? Well, there are two sides to answering that question with one dealing with your CM solution’s architecture and the other, which may be closely related, dealing with the architecture of your tools.
Remember that a good CM architecture can be built upon for years and even decades while a poor one can be patched up for a few years until it outgrows its usefulness.
Also remember that a solution may have to meet certain requirements, including the following: a low administrational cost of tools, a small learning curve—both for process and tools, for all team members—full ALM support so that the entire product team benefits from the solution, near zero-downtime, parallel development support, and end-to-end traceability. The list goes on.
If you find a ready-made solution that meets all of your requirements, eureka! If don’t find that solution, however, you will probably compromise some of your requirements. But if your solution architecture, wherever it ends up, is to succeed long term, it needs to be adaptable to global development, increases in the number of users and total content, changes to process, new platform support, and so forth.
So how much do you want to assess your CM architecture? To answer this, you need to look at how your architecture holds up during these adaptations, meaning these changes in process and environment. Additionally, you might be asking yourself how much time and effort do you have to put into modifying your solution in order to help it adapt? You also might wonder how much scripting you might need? A typical shop will spend a great deal of resources over time tinkering with a solution that has outgrown its usefulness.
A good CM architecture will last for decades, not just years. I know of a few CM solutions consisting of both process and tools that have been around for decades. These solutions have improved over time, but they are basically the same tools and core processes. Time is a good measure of architecture. If you start with a sound architecture, you'll find that you won't have to swap tools and revamp processes five years into the project. Instead, one solution will last the entire lifetime of the product.
So let’s look at CM tool architecture and try to figure out what it is. A good CM tool architecture can be measured by the longevity of its effectiveness, but it’s not good enough to measure longevity in a single project to judge a tool's architecture. A good tool architecture will last across a wide range of solutions or organizations. The tool must be adequate in that it must be able to meet a wide range of requirements. However, it must also be able to adapt well, and not just bit by bit over time in a particular situation. It must be able to adapt to a host of differing CM requirements and evolving CM requirements.
Yes, CM is CM, but the requirements are continually changing in the following ways: increased global software development, more frequent release cycles in which you might be forced to release every three months instead of every three years, and the emergence of interactive dashboards that run meetings. So how is a CM tool supposed to adapt when these requirements that barely existed twenty years ago? The answer is that although good architecture can’t foresee the requirements, it can easily grow into them. For example, fifteen or 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.
