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