Doing architectural design, and assessing the alternatives

Move 1 — represent the system in context

Architectural design starts outside the system. Before you can say what is inside, you describe the external entities that interact with the software and the nature of each interaction, which the requirements model already largely gives you. An architectural context diagram places the target system in the middle and everything else around it in one of four positions: superordinate systems that use it, peer systems it exchanges information with, subordinate systems it uses, and actors — people and devices that produce or consume its information. The details of every interface shown must eventually be specified; all data crossing the boundary is identified now, not later.

Move 2 — define archetypes

An archetype is a class or pattern representing a core abstraction critical to the architecture — a small set of them is enough even for a complicated system. Archetypes are the stable elements: they may be instantiated many different ways as behaviour changes, but they themselves persist. You derive them mostly by looking at the analysis classes already in the requirements model and asking which of them name something the architecture must have regardless of how the requirements evolve.

Move 3 — refine archetypes into components

Now the structure appears. Components come from two sources, and forgetting the second is the classic omission. The application domain supplies components derived from the analysis classes — the business entities the system is about. The infrastructure domain supplies components with no business meaning at all but without which nothing runs: memory and task management, communication, database access, scheduling.

Move 4 — describe an instantiation

The architecture so far is still abstract. An instantiation applies it to a specific problem to demonstrate that the structure and the components really do work — you elaborate the components against a concrete scenario and see whether the collaboration is natural or whether the system has to twist itself into knots to get the job done. If it twists, you have learned something cheaply.

Assessing the alternatives

Architectural design should produce more than one candidate. Choosing between them is a defined activity, not a preference. The architecture trade-off analysis method (ATAM) runs iteratively: collect scenarios as use cases; elicit the requirements, constraints and environment; describe the candidate styles and patterns using module, process and data-flow views; evaluate each quality attribute in isolation (reliability, performance, security, maintainability, testability, portability); then find the sensitivity points — architectural attributes where a small change moves a quality attribute a lot — and from those the trade-off points, the elements to which several quality attributes are sensitive at once. Trade-off points are where the real decisions live.

Alongside that sit three lighter instruments. An architectural review is a specialised technical review aimed at whether the architecture can meet the system's quality requirements, usually staffed by engineers plus an independent expert rather than by all stakeholders. Pattern-based architecture review (PBAR) is the small-team version: a short face-to-face audit held after the first walking skeleton, which walks the important quality attributes through the relevant use cases, matches the system's structure to the patterns it claims to use, and asks what each pattern does to each quality attribute. And architecture conformance checking runs continuously afterwards, because deadline pressure and technical difficulty cause deviations, and unchecked deviation is how architecture erodes.

Worked example — two candidate architectures for BorrowBox

Candidate A: synchronous. The app asks the lending service to open a door; the service calls the locker gateway; the gateway calls the controller and waits; the answer travels back. Simple, one code path, trivially auditable.

Candidate B: token plus events. The service issues a signed short-lived token; the phone presents it to the controller, which validates offline; the controller later publishes DoorOpened to an event channel that the lending service consumes.

Run the scenarios. Quality attribute availability: the street cabinet's uplink is down for minutes at a time each week, and A fails completely in that window while B degrades to a delayed audit record. Performance: A's three-second budget must cover two network hops plus a controller round trip; B's covers a local signature check. Security: A keeps the decision on the server, which is easier to reason about; B has to solve token replay and clock skew, which A does not. Testability: A can be tested end to end from a single test harness; B needs a controller simulator.

The uplink is the sensitivity point — availability and performance both move sharply with it. Token lifetime is the trade-off point: shorten it and replay risk falls but clock-skew failures rise; lengthen it and the reverse. That is the decision the architecture actually turns on, and naming it is worth more than the choice itself.