Modifiability, testability and deployability: designing for change

Three qualities about change

Most of the cost of a successful system is incurred after its first release, as it is changed again and again. Three related qualities describe how well an architecture supports that. Modifiability is about the cost and risk of making a change. Testability is about how easily you can show, by testing, that the system (or a part of it) behaves as intended, and how readily faults reveal themselves. Deployability is about how quickly, safely and predictably a change can be put into production, and taken back out again.

They are linked in a loop. A change is only cheap if you can make it in one place (modifiability), know quickly that you have not broken anything (testability), and ship it without ceremony (deployability). A system that is modular but has no fast tests will still change slowly, because every change needs weeks of manual regression testing. A system with good tests but a quarterly release window will still deliver value slowly.

Modifiability: four questions about any change

Bass, Clements and Kazman suggest that modifiability is meaningless until you say what is expected to change. Planning for every possible change produces an over-engineered system full of unused extension points; planning for none produces a system where every change is a rewrite. Four questions sharpen the requirement.

What can change? Functions, platforms (a new database version, a move to another cloud), the environment (a new partner API, new regulation), qualities (twice the load), or capacity. How likely is the change? Spend design effort where change is probable: payment providers, tax rules and user interfaces change often; the concept of an order rarely does. Who makes the change, and when? A developer at coding time, a release engineer at deployment, an administrator through configuration, or an end user through settings. The moment at which a decision is fixed is called its binding time. What does the change cost? The effort, elapsed time and money to make, test and deploy it, plus the number of other elements affected and the risk of introducing defects.

Answering those questions gives a scenario of the kind introduced in Section 2.3: A developer adds support for a new payment provider, changing no existing modules other than configuration, within 3 person-days including tests, with no increase in checkout errors.

Tactics for modifiability

The tactics in Software Architecture in Practice reduce the cost of change by limiting how far a change ripples. They rest on two old ideas, treated in depth in Chapter 3. Cohesion measures how strongly the responsibilities inside one module belong together; coupling measures how much one module depends on another. A change that is likely should touch one cohesive module, and that module should be loosely coupled to the rest.

Increase cohesion. Split a module that does two unrelated jobs (a CustomerService that handles both login and loyalty points), and move responsibilities to where they belong, so that a likely change lands in one place.

Reduce coupling. Encapsulate: hide a module's internals behind an explicit interface, following David Parnas's principle of information hiding (1972), so callers cannot depend on what may change. Use an intermediary: put something between two parties so neither knows the other directly: an adapter, a message broker, a publish-subscribe channel, a repository in front of a database, or an API gateway. Restrict dependencies: decide which modules may call which (layering rules, a module visible only to its own package) and enforce it with tooling. Abstract common services: provide shared behaviour once, behind an interface, rather than copying it.

Defer binding. Fix a decision as late as is useful, so that the change can be made later and by someone further from the code: configuration files, environment variables, plug-ins discovered at start-up, service discovery and feature flags. Each later binding time adds machinery (configuration to validate, flags to remove, versioned plug-in interfaces), so defer only decisions that genuinely vary.

Testability: controllability and observability

A component is testable when a test can put it into a known state, feed it chosen inputs and see what it did. Two properties capture that. Controllability is the ability to set a component's inputs and internal state from a test. Observability (in the testing sense) is the ability to see its outputs and relevant internal state. Code that reads the system clock directly, calls a real payment service, picks random numbers or writes to a shared database is hard to control; code that hides its results in private state or only in log text is hard to observe.

Architectural tactics for testability therefore aim to give tests control and visibility, and to limit complexity. Isolate dependencies behind interfaces, then use dependency injection: the component receives its collaborators (a clock, a payment gateway, a repository) from outside rather than creating them, so a test can pass in a substitute. Those substitutes are test doubles, a term popularised by Gerard Meszaros: a stub returns canned answers, a fake is a working lightweight implementation (an in-memory repository), a mock checks that expected calls were made, and a spy records calls for later assertions. Provide test interfaces: hooks to set state, record and replay traffic, or run in a sandbox environment. Limit non-determinism: avoid hidden concurrency and global state, and make time and randomness injectable. Limit structural complexity: fewer dependencies and no cycles mean smaller test set-ups.

Architecture shapes the testing strategy at higher levels too. In a system of services, each boundary needs contract tests that check both sides agree on the API, and a few end-to-end tests that exercise the real path. A design with clean boundaries lets most tests run fast and in isolation, while a tangled design forces slow, brittle end-to-end tests for everything.

class OrderService:
    def __init__(self, gateway, clock):
        self.gateway = gateway   # anything with charge(amount, card)
        self.clock = clock       # anything with now()

    def place(self, order):
        if self.clock.now().hour >= 23:
            return "kitchen closed"
        return self.gateway.charge(order.total, order.card)

# In a test: full control, no network, no waiting until 11 pm
class FakeClock:
    def __init__(self, t): self.t = t
    def now(self): return self.t

class FakeGateway:
    def __init__(self): self.calls = []
    def charge(self, amount, card):
        self.calls.append(amount)
        return "approved"

Deployability

Deployability measures how predictably and cheaply a change moves from a developer's commit into production, and how quickly it can be undone. It became a first-class quality only in the last decade, as continuous delivery showed that release frequency and stability are not opposites. The fourth edition of Software Architecture in Practice (2021) added a chapter on it.

The central idea is small batches. A release that contains one change is easy to test, easy to reason about and easy to roll back; a release of three months' work contains hundreds of interacting changes, so failures are likely and hard to diagnose. Small batches require automation: a deployment pipeline that builds, tests and deploys every change the same way, scripted infrastructure and no manual steps that someone can forget. Architectural tactics include independently deployable units (so one team's release does not wait for another's), backward-compatible interfaces and database migrations, rollback and roll-forward mechanisms, gradual rollouts (canary releases to a small share of traffic first, blue-green switching between two environments) and feature flags, which separate deploying code from releasing a feature to users. Pipelines and strategies are covered in CI/CD and deployment strategies.

The cost of ignoring deployability can be severe. In August 2012 the trading firm Knight Capital deployed new code manually to its eight order-routing servers but missed one. A reused configuration flag then activated obsolete code on that server, which flooded the market with orders, producing about 4 million executions in roughly 45 minutes, and cost the firm about 460 million US dollars. An automated, verified deployment and the removal of dead code would each have prevented it.

Measuring delivery: the DORA metrics

The DORA research programme (DevOps Research and Assessment, described in Accelerate by Nicole Forsgren, Jez Humble and Gene Kim, 2018, and continued in annual reports now run within Google Cloud) found that a small set of measures predicts software delivery performance, and that the best performers are fast and stable at the same time. The current model has five software delivery performance metrics, grouped into throughput and instability. Their names have evolved: the old mean time to restore became failed deployment recovery time in 2023, and deployment rework rate was added in 2024.

Two cautions. First, these metrics describe a team's delivery system, not individuals; using them to rank people invites gaming. Second, they are outcomes. Architecture influences them strongly: teams that can deploy their part independently, test it in isolation and roll it back quickly score better, which is one reason the DORA research links loosely coupled architecture with higher delivery performance.

Maintainability in ISO/IEC 25010

ISO/IEC 25010:2023 groups these concerns under the characteristic maintainability, with five sub-characteristics: modularity (the system is made of discrete components so that a change to one has minimal impact on others), reusability (an asset can be used in more than one system or in building other assets), analysability (how easily you can assess the impact of a change, diagnose a deficiency or find the parts to modify), modifiability (the system can be changed without introducing defects or degrading quality) and testability (test criteria can be established and tests performed to determine whether they are met). Deployability has no sub-characteristic of its own in the standard; installability and replaceability sit under flexibility. The model is a checklist, as Section 2.2 explains; scenarios are what make each item concrete.