A travel platform is building its third availability-and-pricing integration in two years, each with a different internal shape. An architect proposes a reference model. What should it contain to be useful, and what makes reference models fail in practice?

What a useful reference model contains

Not a diagram of one system. A reference model is a vocabulary plus a set of decided questions that every instance must answer the same way:

• Canonical concepts. What "availability" means (is a held inventory unit available?), what "price" includes (taxes, fees, currency, validity window), what a "rate plan" is. Most integration pain is vocabulary pain wearing a technical costume.
• Decided questions with rationale. Is availability cached, and for how long? Is price re-validated at booking? Who owns the reservation timeout? Each answered once, with the reasoning, so the fourth integration does not re-litigate.
• Required interfaces. Every supplier integration must expose the same reliability profile (timeout, retry budget, circuit state), the same freshness metadata, the same error taxonomy.
• Explicit variation points. Where instances are allowed to differ, and where they are not. A model without this is either ignored or applied absurdly.

What makes reference models fail

They describe rather than decide. A model that says "integrations typically cache availability" is an observation. One that says "availability is cached with a maximum TTL of N seconds and always re-validated at booking, because overselling costs more than a slow booking step" is a decision that saves the next team a month.

They are aspirational rather than instantiated. If no existing integration conforms, the model is a wish, and teams learn to route around it. Retrofit at least one real integration before publishing.

They are enforced by review rather than by tooling. A model expressed as a shared library, a service template and a conformance test survives. One expressed as a document survives until the first deadline.

They have no owner and no expiry. Reference models rot faster than code because nothing breaks when they become wrong. Name an owner and a review cadence, or do not write one.

The judgement being tested

Whether you understand that standardisation is only worth it when the variation is accidental. If these three integrations differ because suppliers genuinely differ in ways that matter, a reference model that flattens them will produce silent incorrectness. Standardise the vocabulary and the reliability contract; leave the genuine domain differences visible.