English | EN 
A famous quote by Heraclitus goes roughly along to lines of: “The only constant in life is change”. This is especially true in the digital world where change is considered infinite. If we are looking at the ISO25010 standard, changeability is not a specific mentioned quality attribute.
Changeability would partially fit in with Maintainability and Portability. It does not encompass both categories, but aspects of both can be considered as part of changeability.
Change is infinite
So why do I consider changeability of software its most powerful aspect? As mentioned before, change is infinite and often unpredictable. Many things we can plan for, but far more often things happen that are totally unexpected. How we deal with that as humans and crafters of quality software determines our ability to cope with those unexpected crises.
The reason why I consider changeability more important and powerful than all the other attributes is that if something is lacking in one of the categories it can be quickly remedied if the ability to change is part of the design. A system that is a big ball of mud or a spaghetti system can not be so easily fixed as a changeable system.
Some examples
Imagine the following scenario. Last year log4shell was a large security crisis in the Java ecosystem. A system that was using the right abstractions and dependency management was quickly remedied. A system that was not using proper dependency management and the right abstractions would have had the definitions all over the codebase. This would have made the problem far harder to solve.
Another scenario is where a system has to migrate to a different persistence store. For example an application that uses an AS400/DB2 database and wants to migrate to Postgresql. Again a system that uses the right abstractions has a far easier time of doing this than a system that directly uses the AS400 API.
And last but not least, imagine that your team needs to add features to your system in time for the busy holiday system. Can you guess what kind of system is more able to adapt to the demands of the business?
Make your systems changeable
So how can we ensure that our systems are able to deal with infinite change? There are a few things that are important. First of and in the broadest sense of the word: keep technical debt low. Technical debt comes in many forms, but their outcome is almost always that it becomes way harder to adapt to change.
Next to keeping technical debt low, it is imperative that you use the proper abstractions between parts of your system. At a single codebase level we often say: “toss in an interface in there. While reality is not as crude, in essence that is often what is required. In between applications something similar is available. The internals of a single application are abstracted away behind an interface: a rest API, a message format or another well defined contract.
Another important part is modularity, which interestingly enough is its own quality aspect. Modularity is in part accomplished by well defined interfaces, however there is more to good modularity than that. Modularity groups those things together that belong together and change together. Good modularity makes it easy to extract modules from a single system into a whole new service.
The infinite balancing act
“Tossing in an interface” is not a silver bullet. Like any tactic or strategy it has a tradeoff. Using more abstractions and interfaces can increase your application’s complexity to the point that it is hard to grasp and maintain. The effect is actually counter to what you wanted to achieve in the first place and is thus slowing down change.
Using any pattern, tactic and strategy is, again, an infinite balancing act between pros and cons. What might have worked for today’s world, might not in that of tomorrow. Like our systems, our architecture should be constantly evolving to meet the infinite stream of change.
