A team adopts a cloud vendor's reference architecture wholesale to run two containers and a database. The result is a hub-and-spoke network with a firewall appliance and three subscription boundaries. What went wrong?

What is being tested

Whether you can use a reference model for what it is good at — vocabulary and completeness — without inheriting a topology drawn for a different problem.

The reasoning

A reference architecture is drawn for a general case: a large enterprise, many workloads, multiple teams, strict network segmentation, a regulated environment. Every element in it is there because some organisation genuinely needed it. Published guidance of this kind is genuinely valuable — it encodes hard-won operational knowledge about identity boundaries, landing zones and what multi-region failover actually does under load, and a team adopting it inherits decisions it would otherwise get wrong.

What it cannot do is know your workload. Two containers and a database do not need a hub-and-spoke network. The result of adopting it anyway is:

• Operational cost with no benefit. Someone must now understand, patch, monitor and pay for a network virtual appliance that protects nothing of consequence.
• Slower delivery. Three subscription boundaries mean three sets of permissions, three deployment targets, and a change that used to be one step is now coordinated.
• A new failure surface. The firewall appliance is now a single point of failure for a system that did not previously have one, and it will cause an incident.
• Diffused understanding. Nobody on the team can hold the whole thing in their head, so debugging gets slower permanently.

The discipline

Go through the reference element by element and make an explicit decision on each: include, or exclude and record why. The recorded "why" is what makes the omission defensible in a later audit or review, which is usually the real reason teams over-adopt — they are afraid of being asked why something is missing.

A useful prompt for each element: what specific failure or requirement does this exist to address, and do we have it? A network appliance exists to inspect east-west traffic between many workloads. With one workload there is no east-west traffic.

What to keep even at small scale

Not everything in a reference is enterprise ceremony. Identity boundaries, secret management, encrypted transit, separate environments, logging with retention, and infrastructure defined as code are cheap at any size and expensive to retrofit. The judgement is in distinguishing those from topology that only makes sense above a certain organisational complexity.

The general failure this represents

Layer-driven and diagram-driven design: a component exists because the picture had a box, not because a requirement demanded it. Every hop, appliance and boundary that exists for that reason is pure latency and pure maintenance, and it will still be there in five years, with nobody able to explain it.