Software ArchitectureAtlas

Software Architecture Atlas

Gain an overview. Understand the connections.

Quality attributeChapter I · Requirements · Building block 6 of 6

Modifiability

Changeability assesses the effort and risk of a named change; good limits keep the number of building blocks to be adapted together small. In ISO 25010 This is called modifiability and belongs to maintainability.

By Michael Meierhoff · Meierhoff Systems

  1. ChangesA named requirement as a scale.
  2. ScopeHow many modules are changed.
  3. MeasurementNumbers instead of gut feeling.

Context

Why this is important

Changeability only becomes apparent with a concrete change: How many building blocks have to be adapted and tested? Unclear boundaries turn small desires into broad regressions. The funds for this deepen their own building blocks, such as coupling and module boundaries.

Here you set and measure how complex and risky changes are. How the architecture achieves this is shown by the tactics below; fitness functions take over the ongoing exam.

At a glance · One change, scope measured

A named change affects only the modules that share its reason; the number of affected modules determines the effort.
Shop example · Playing through scenarios

Introduce change collection

The shop introduces the pickup option. Ordering and warehouses change their behavior; payment, shipping and invoice should only be targeted via stable contracts.

This is how you read the picture

  1. Changes The “Introduce pickup” scenario describes the change in the measurement of all modules.
  2. Scope In the case of unclear boundaries, five out of seven modules are affected, in the case of clear only order and warehouse.
  3. Measurement The table lists four measured variables: affected modules, lead time, error rate and broken structural rules.
Module boundaries
  • AffectedOrderCheck shipping boxes everywhere
  • AffectedInventoryChange common table logic
  • AffectedShippingDistribute special cases in the flow
  • Co-examinationPaymentEffect unclear, co-test
  • Co-examinationInvoiceEffect unclear, co-test

5Affected modules (of 7 in the shop

Without clear contracts, the change will move through many building blocks. No one knows for sure what is affected, so it is widely tested. This is a broad regression.

Switch the module boundaries. You can see which building blocks the change needs to touch and how broadly tested.

This is how you measure changeability

This is how you measure changeability
Measurement variableWhere the data comes fromIn the shop
Affected modules per changeChange analysis in the git: which files and modules are changed togetherCollection: 2 instead of 5 Modules
Transit time of a changeDORA Lead Time for Changes (from commit to delivery)Pickup is live in a few days instead of after a regression cycle
Error rate after changesDORA Change Failure RatePercentage of shop deliveries that require rework
Infringed structural rulesFitness Functions in the BuildShipping does not read order tables
Four measurands make it visible how easily a system can be changed. The values in the shop are illustrative.

Tactics

This is how the architecture achieves the goal

This building block determines and measures how well changes can be implemented; the tactics below are separate building blocks that achieve this goal.

  1. Cutting down on coupling

    A change to the payment does not force the order and catalogue to adjust.

  2. Increasing cohesion

    Associated pricing rules are in one place, so that a change touches a few places.

  3. Keeping interfaces stable

    Contracts and versions allow the Shop and Partner to change separately from each other.

Benefits & limitations

Helps if:

  • Frequent changes to a rule repeatedly require widespread modifications or cause regressions.
  • A foreseeable technology replacement should affect only a limited number of building blocks.

Boundaries

  • Speculative flexibility has a cost: extension points for changes that never happen make the system more complex (YAGNI). Invest where changes are demonstrably frequent, using Git history as evidence.
  • Even a local code change may require several approvals or data migrations. Examine team and operational workflows alongside the structure, and add appropriate Fitness Functions.

In practice

  1. Describe a specific change. State the initial situation, desired behaviour and likely frequency. This grounds the assessment in a real modification rather than abstract flexibility.
  2. Trace affected dependencies. Identify the modules, contracts, data and approvals touched by the change. Relate the identified boundaries to Module Boundaries to check for avoidable impacts.
  3. Assess the change process and risks. Consider implementation, testing, migration and operational approval. A Fitness Function can subsequently check that a relevant structural rule is maintained over time.
Read the detailed explanation

Modifiability is assessed through specific rules, interfaces and technologies that are likely to change. Clear responsibilities and stable contracts limit the number of affected parts. Module Boundaries contains changes; Fitness Functions checks whether important structural rules remain intact.

Assess code changes, coordination, migration, testing and operational approvals together. An abstraction is worthwhile when it simplifies a real change or reduces a demonstrated risk. Recurring changes provide better guidance for structural improvements than an undefined demand for maximum extensibility.

Check your understanding

Test yourself in three stages

  1. ReadingCheck in the picture

    Which building blocks change with clear module boundaries?

    View the solution with justification

    Order (addition of delivery) and warehouse (offer collection reservation). Shipping will not receive an order upon collection.

  2. ApplyingTransferred to a new situation

    A customer chooses collection for B-1042. Should the shipping module know about it?

    View the solution with justification

    No, the shipping module does not receive an order when picked up. The order module decides on the basis of the delivery method.

  3. EvaluateWeighing an alternative

    The team waives contract tests to deliver faster. How do you rate that?

    View the solution with justification

    In the short term, it saves effort. However, the table shows that clear boundaries are associated with targeted contract and module tests; without them, the regression grows broadly again.

Explore further

These building blocks continue the thoughts of this page.

PrinciplesCouplingCoupling shows which dependencies propagate changes from one building block to others.Opening PrinciplesModule boundariesModule boundaries define which data and capabilities a module owns and which contracts others use to access them.Opening PrinciplesSeparation of responsibilitiesSeparation of responsibilities assigns tasks with different reasons for change to suitable building blocks.Opening RequirementsQuality attributesYou define measurable expectations for how well a function performs under specific conditions.Opening

References

Continue on the learning path

With that, you have Requirements & quality run through. It continues with Principles & boundaries.

6 Building blocks

Next areaPrinciples & boundaries