Evolvability (aka. changeability, evolutionary architecture)
Evolvability is a quality attribute of a system. It refers to the ability to make changes to the design of a system without breaking existing functionality. The ultimate in evolvability is [evolutionary architecture], where the fundamental structure of the system, its data structures and the communication patterns between its components, can evolve over time.
The case for evolvability is not a matter of taste. Lehman’s laws of software evolution argue from the opposite direction that an E-type system which is not continually adapted becomes progressively less satisfactory. For software embedded in a changing world, the ability to evolve is a survival trait rather than a nice-to-have. It is also a practical response to the project paradox: since the most consequential design decisions are made when knowledge is thinnest, designing so they can be revised later is often safer than trying to make them perfectly up front.
The quality of evolvability is more important in the context of distributed software than it is in monolithic software. Distributed software is inherently complex (it has a high degree of essential complexity), and therefore the ability to evolve the system over time becomes a key design constraint.
Event-driven architecture is widely recognized as offering a high degree of evolvability in distributed software. The loosely coupled nature of event-driven systems means that you can change one part of the system without having to change other parts, and the interfaces between components (in the form of event messages) tend to be more stable than messages and direct method calls.
Evolvability is most credible when it is measurable. An architectural fitness function encodes a quality or structural constraint as an automated check, so that drift away from the intended architecture is caught as soon as it is introduced.
See also backwards compatibility, the facet of evolvability that governs whether existing consumers keep working after a change. The counterpart on the debit side is technical debt: the gap between the design as it stands and the design the team now wants is exactly what refactoring must close to keep a system evolvable.