A reference architecture is a hypothesis library

A reference architecture makes it easy to produce a tidy diagram. Match the local boxes to the reference boxes, borrow its names, calculate an alignment percentage, and the work looks finished.

The diagram may also be wrong for the system being designed.

A reference architecture is better used as a set of ideas to test. It can suggest functions the system may need, common separations of responsibility, information that has to move, useful controls, and failures other designers have already met. Local goals and constraints decide which suggestions belong in the design.

What the reference can and cannot know

ISO/IEC/IEEE 42010 distinguishes a system’s architecture from the description used to represent it. The OASIS SOA Reference Model is deliberately abstract and independent of a concrete implementation. The TOGAF Standard and industry models such as the BIAN Service Landscape offer reusable material at different scales.

None of them knows:

what this organization is trying to improve;
which functions distinguish it from competitors;
which old systems, contracts, and skills constrain the change;
how much interruption or recovery time is acceptable;
which untidy local arrangement is preventing a real failure; or
what has deliberately been left out of scope.

Broad coverage is useful for finding omissions. It is not evidence that every box deserves local investment.

Start with the result, not the reference

The useful chain runs in this direction:

problem to solve
    ↓
result wanted, including deliberate exclusions
    ↓
things the system must be able to do
    ↓
small reference slice worth consulting
    ↓
local decision and migration
    ↓
test that the result occurred

This order matters. Michael Porter’s distinction between operational effectiveness and strategy is relevant here: a common good practice may improve operations without being a strategic priority. Henry Mintzberg’s critique of strategic planning makes a related point. Analysis can expose options and implications; it does not choose what is worth doing.

The starting position matters too. Work on dynamic capabilities shows why two organizations can accept the same general idea and still need different paths. Discovery-driven planning provides the practical response: test the assumptions that carry the most risk before committing the whole roadmap.

Use capabilities carefully

A capability asks what must be possible without assuming which current system, team, or process will provide it. This makes capabilities useful for comparing a local estate with a reference model. The Open Group’s Business Capabilities guidance uses them to connect strategy to architecture without starting from an application inventory.

Before adopting a reference capability, classify its local role:

Local role	Practical response
Differentiating	Preserve the local advantage; use the reference to check omissions and interoperability.
Necessary	Standardize where useful and fund enough reliability to operate it.
Commodity	Prefer adoption and reuse over local invention.
Transitional	Keep it working long enough to remove it; do not polish it into permanence.

The classification is local. A capability may be ordinary in the reference model and differentiating here. The reverse is equally common.

Capability language also has a limit: it can hide the person or system that actually does the work. Once a capability matters to the design, name who owns it, where its data lives, how it is reached, and what happens when it fails.

Record a decision, not an alignment score

For each relevant proposition, record one of four decisions:

Adopt: use it without a material local change.
Specialise: keep the idea but alter it for a named constraint.
Map: retain a different local design and document the relationship.
Reject: do not use it, and record why.

“Aligned” is not a fifth decision. It does not say whether the names match, the function exists, an interface conforms, or the design has merely been redrawn.

A compact record is enough:

source: conventional segmented-network design
proposal: isolate infrastructure management from ordinary client traffic
wanted_result: client-network failure does not remove administrative access

local_fact: >-
  The network controller runs inside the Kubernetes cluster whose switching
  fabric it manages.

decision: specialise
reason: >-
  Segmentation is useful, but the controller needs a bootstrap and recovery path
  that does not depend on the network it is repairing.

tests:
  - remove ordinary client reachability
  - reach the controller from the recovery workstation
  - verify switches and access points retain or regain controller contact

review_when:
  - the controller moves outside the cluster
  - out-of-band management is added

The record names the source, desired result, conflicting local fact, decision, tests, and reason to reconsider it. That is more useful than “82% aligned.”

A worked case: network segmentation

A common network design separates client, server, management, and untrusted device traffic. The proposal is sensible: one compromised or broken client network should not remove the ability to administer infrastructure.

In this homelab, the network controller runs inside Kubernetes, and Kubernetes depends on the switches managed by that controller. Copying the reference boundary directly can make the controller unreachable during the change meant to protect it.

The reference still improves the design. It prompts five checks:

keep management traffic separate from ordinary clients;
preserve an administrative route;
keep the controller reachable;
recover without depending on the failed path; and
migrate devices without dropping both old and new control paths together.

The local answer is to specialise the segmentation pattern with a separate bootstrap and recovery route. The result is less visually pure and safer to operate.

What to challenge in a reference

The mismatches are usually the useful output:

a function has no local owner;
one component performs several functions that should fail independently;
the local design needs a distinction the reference does not make;
a proposed boundary would break recovery;
a supposedly standard function is locally differentiating;
a low-priority box is receiving investment because it appears in the model; or
a workaround is being normalized even though it should be removed.

Also resist one-to-one mappings. A reference capability is not automatically one service, team, repository, or data product. Its maturity sequence may not be a safe migration order. Its terminology does not change who decides, which database owns a record, or what fails together.

Minimum workflow

For one architecture decision:

State the result that should become possible or safer.
Name the inherited systems, skills, costs, risks, and recovery requirements.
Select only the relevant part of the reference.
Turn each useful proposal into a small decision record.
Classify the local role of the affected capability.
Adopt, specialise, map, or reject the proposal.
Test the weakest assumption first with a reversible experiment.
Put only the surviving choices into the target and migration plan.

The reference has done its job when it helps produce a better local decision. Conformity is neither required nor, by itself, informative.