Reference Model Tailoring

A team of 40 engineers running three products adopts a cloud vendor's landing-zone reference architecture whole: hub-and-spoke networking, three subscription tiers, a central firewall appliance. Four years later the appliance adds a hop to every internal call and has caused two of the last five incidents. The auditors were told the architecture "conforms to the vendor reference", so every simplification now reads as a control deviation rather than as a design decision.

Reference models are written for the largest plausible adopter, because that is the only way one document serves an industry. The adopter is expected to delete what does not apply, and the deletion is the part nobody records. Tailoring is doing it on purpose and writing it down: one row per element, stating whether it was kept, replaced or dropped, which concern it addressed, and how that concern is met in your design. The Open Group's TOGAF has carried the idea since the version 9 line first published in 2009: its Preliminary Phase includes an explicit step to tailor the framework and any other selected frameworks before applying them.

Why it matters

An unrecorded deletion is indistinguishable from an oversight, and that is the whole cost. An auditor, a new architect and the vendor's own consultant all ask the same question later, and without a record the answer is reconstructed from memory by whoever is still there.

Adopting the model as a design rather than as a questionnaire also produces a topology sized for an estate you do not have, and the surplus is not free.

Worst, conformance quietly becomes the control. Once "we follow the vendor reference" is the stated basis of assurance, the architecture cannot be improved without appearing to weaken a control. A tailoring record prevents that by making the concern the control and the reference model one way of meeting it.

Implementation patterns

• One row per element, written at adoption time: element, decision, the concern it addresses, how it is met, and the date. Forty elements is an afternoon.
• Name the concern, not the component. "East-west inspection and egress control" is a concern; a firewall appliance is one implementation. Auditors accept a different implementation of a named concern far more readily than an absent component.
• State conformance as a level, not a boolean. "We conform to sections 3 to 5 and have tailored section 6, recorded here." A boolean invites a finding; a level invites a conversation.
• Attach a revisit trigger to every drop: "dropped hub-and-spoke at 3 products; revisit above 10." Without a trigger a drop becomes permanent by accident.

Industry example

Cloud vendors' landing-zone reference architectures are the most widely adopted reference models in current practice, and they are written for a large enterprise with many business units, separate audit and security functions, and a network team. A three-product company applying one unmodified inherits a topology designed for coordination problems it does not have.

Industry models repeat the pattern: a retail or banking reference model offers hundreds of capabilities, and a company using 30 of them has done the right thing. The model's value is a checklist of concerns somebody else learned the hard way, and the tailoring record converts a checklist into an architecture.

Failure scenarios

• Wholesale adoption. Every element implemented, none questioned, and the cost surfaces in year two when the estate is too dependent on the topology to change cheaply.
• Silent subsetting. Half the model implemented, nothing recorded, and a later audit reads the gaps as findings.
• Drops with no trigger. A deletion correct at 3 products is still in force at 30, and the concern it addressed is now real.

Trade-offs

What it buys: the right to have a smaller architecture and still answer questions about it, with the argument front-loaded to where it is cheapest.

What it pays: the afternoon of writing, a quarterly revisit, and a real loss of cover. "We followed the vendor reference" is a comfortable answer when something goes wrong, and the record replaces it with named decisions and named owners. Some organisations do not want that, and there the practice fails politically rather than technically.

When not to use it

Skip it when the model is contractual. If a regulator, a customer agreement or a certification scheme names the reference architecture as a requirement, tailoring is not available and the correct response is to implement the element and make it highly available.

Skip it too when the organisation will reach the scale the model assumes within a year: a topology adopted early is early rather than wrong, and migrating away and back costs more than carrying the surplus.

Interview question

Q: Your predecessor adopted a vendor landing zone whole and told the auditors the architecture conforms to it. You want to remove a central appliance that costs a hop on every internal call. What do you produce before touching anything, and in what order do you change it?

What a strong answer covers: the tailoring record first, because the blocker is evidentiary rather than technical, with the appliance's row naming the concern and its replacement. Then the sequence: stand up the replacement path carrying no traffic and confirm the logs match, generate both rule sets from one source so they cannot drift, move one product at a time by route change, leave the old path with zero flows for 30 days as the rollback window, then decommission. The real point of no return is the identity and subscription change rather than the routing.

Quick check

Quiz: Why is "our architecture conforms to the vendor reference" a costly thing to tell an auditor? It makes conformance the control, so every later simplification reads as a control deviation rather than a design decision.

Flashcard: What does a tailoring record hold per element? The element, whether it was kept, replaced or dropped, the concern it addressed, how that concern is met now, and the trigger to revisit.