Evaluating and Evolving Architecture

A quality attribute scenario is a concrete, testable sentence: some source sends a stimulus to the system in a given environment, and the system responds with a measurable result. "Scalable" has no measure, so nobody can agree whether a design meets it.

A fitness function is an automated, objective check that the system still meets a required architectural quality — response time, allowed dependencies, security rules. A unit test checks business behaviour; a fitness function guards a structural or quality property.

Technical debt is a shortcut in design or code that makes today faster but future changes slower. The principal is the work needed to fix the shortcut; the interest is the extra effort every change costs while it stays unfixed.

It means improving one desirable property usually costs another. Example: caching copies of data makes reads fast but copies can be stale; adding redundant servers raises availability but raises cost and operational complexity.

A = abstract types / total types in a component (0 = all concrete, 1 = all interfaces). The main sequence is the line A + I = 1: stable components should be abstract, unstable ones concrete. D = |A + I - 1| is how far you sit from that line — smaller is better.

ATAM is a structured workshop where stakeholders write measurable quality scenarios, the architect explains how the design handles the top ones, and the group records risks, non-risks, sensitivity points and trade-off points — not a pass/fail score.

Atomic checks one characteristic in isolation (a layering rule); holistic checks several interacting at once (security plus performance under load). Triggered runs on demand — a build or deploy; continuous runs constantly against the live system, e.g. monitoring latency.

Add a test that reads the code's dependency graph — from source, bytecode, or import statements — and asserts rules like 'domain must not reference persistence' and 'no cycles'. Run it in the build so violations fail like any other test.

CAP says that when the network splits (a partition), a distributed store must choose: keep answering with possibly-stale or conflicting data (availability), or refuse some requests to stay correct (consistency). PACELC adds: even with no partition, you still trade latency against consistency.

Only review decisions that are expensive to reverse. Use a written proposal template (context, options, trade-offs, chosen option), require the author to consult affected experts, timebox feedback, record the outcome as a decision record, and automate recurring checks instead of re-reviewing them.

Make small reversible changes behind a deployment pipeline that runs fitness functions on every commit; change contracts additively (add new, migrate, remove old); replace systems piece by piece rather than all at once; and use feature flags so releasing is separate from deploying.

Erosion is when code violates the intended architecture — for example a layer calling something it is not allowed to call. Drift is when things are added that the architecture never covered, so the design loses coherence without any explicit rule being broken. Both, left unchecked, end in a structureless "big ball of mud".

Prioritise by how much the debt actually costs: fix the places you change often and that hurt every time, not the ugliest code. Estimate the fix cost and the ongoing cost of leaving it, tie remediation to upcoming features, and put it on the same backlog as features so it is compared, not deferred.

First-order effects are the intended ones; second-order are what those effects then cause — often later and elsewhere. Splitting a service speeds deploys (first order) but creates distributed transactions, on-call load and cross-team coordination (second order).

Connascence (Meilir Page-Jones) means two pieces of code are 'born together': if one changes, the other must change too, or the system breaks. Static forms are visible by reading the code (names, types, order of parameters); dynamic forms only appear at run time (call order, timing, values, object identity).

LCOM looks at which methods of a class touch which fields. If methods share fields, the class is cohesive; if they form separate groups touching disjoint fields, the class is really several classes glued together. High LCOM = low cohesion, a hint to split.

A risk is a decision that may stop a goal being met; a non-risk is a decision that's fine given stated assumptions; a sensitivity point is a decision that strongly swings one quality attribute; a trade-off point swings two the opposite way. Non-risks record the assumptions that could later expire.

Fowler classifies debt on two axes: was it taken on purpose (deliberate) or by accident (inadvertent), and was the decision sensible (prudent) or careless (reckless). The four combinations call for different responses — from scheduled repayment to coaching or changing how the team works.

Risk-storming is a group technique where people mark risks directly on the architecture diagrams. Everyone first writes risks alone and silently, then all notes are placed on the diagram, discussed, and ranked by probability and impact so the riskiest spots are visible and get mitigation owners.

List the options as columns and the criteria (quality attributes) as rows, give each criterion a weight agreed with stakeholders, score every option per criterion, then sum weight × score. Its value is the discussion it forces, not the number it prints.

Strength = how hard the coupling is to detect and change (name is weak, timing/identity strong). Locality = how far apart the coupled parts are (same function vs different services). Degree = how many places share it. Rules: reduce strength, keep strong forms local, and shrink degree.

Group related risks into a few themes, tie each theme to the business goal it endangers, estimate the value of fixing it and the cost, and present ranked themes with expected loss and cost — not a list of thirty technical items.

Pick the few characteristics that really drive the design, make each measurable with a threshold, and automate it in the pipeline. Review the suite as business needs change. When two conflict, make the trade-off explicit and decide by business priority — do not silently weaken one.

Architecture smells are structural warning signs above the code level: dependency cycles between modules, a god component everything depends on, a shared 'utils' hub, and features scattered across many modules. Metrics such as coupling counts, instability and change coupling help spot them, but they are indicators, not verdicts.

Tie every design choice to a measured or agreed requirement. Ask what evidence says this attribute matters at this scale, what it costs the other attributes, and whether the decision is easy to reverse later. Optimise last-responsibly, not first.

SAAM came first and is simpler: stakeholders write change scenarios, you check which components each one touches, and compare candidate designs — mainly for modifiability. ATAM extends it to many quality attributes at once and adds explicit trade-off and sensitivity analysis.

A sensitivity point is a design choice where one quality attribute changes sharply if you tweak it. A trade-off point is a choice that is a sensitivity point for two or more attributes at once, so tuning it helps one and hurts another.

Static metrics only see code references. They miss coupling through shared databases, shared message schemas, implicit data meanings, required call ordering, timing assumptions, and shared libraries. Measure it instead by what actually co-changes and co-deploys, and guard boundaries with automated contract tests and fitness functions.