An enterprise publishes reference architectures that teams do not follow. What makes a reference architecture get used?

What makes one get used

1. It decides questions rather than describing practice. "Systems typically cache availability data" is an observation. "Availability is cached with a maximum TTL of N seconds and always re-validated at commit, because overselling costs more than a slow commit" is a decision that saves the next team a month.

2. At least one real instance conforms. An aspirational reference architecture that no existing system follows is a wish, and teams learn to route around it. Retrofitting one real system before publishing is what makes it credible.

3. It is instantiated, not just documented. A shared library, a service template, a module, a conformance test. A reference architecture expressed as a document survives until the first deadline; one expressed as code that a team can start from wins by being faster than the alternative.

4. Explicit variation points. Where instances are allowed to differ, and where they are not. Without this it is either ignored or applied absurdly — and both outcomes discredit it.

5. An owner and a review cadence. Reference architectures rot faster than code because nothing breaks when they become wrong. Naming an owner and a trigger is the difference between a living artefact and a misleading one.

The judgement that decides whether it should exist at all

Standardisation pays only when the variation is accidental. If the systems it covers differ because the problems genuinely differ, a reference architecture that flattens them produces silent incorrectness — adapters defaulting missing fields, one model serving several domains badly.

The workable scope is to standardise the vocabulary (what "availability" and "price" actually mean, which is where most integration pain lives) and the reliability contract (timeouts, retry budgets, circuit state, freshness metadata), and to leave genuine domain differences visible as explicit capabilities.

The adoption question

Is following the reference architecture faster than not following it? If yes, adoption is automatic. If no, adoption requires enforcement, enforcement requires review, review becomes a queue, and the queue gets routed around.

Every successful reference architecture is, in practice, a shortcut.