An enterprise's technology architecture standards assume commodity compute. A new workload requires specialised hardware, specific interconnect and a different operational model. How should standards handle this?
Show the full answer Hide the answer
The tension
Standards exist to limit variety, because variety is what makes an estate expensive to operate. A workload that genuinely does not fit is either forced onto an unsuitable standard — producing a system that works badly and expensively — or granted an exception that, repeated enough times, dissolves the standard.
How to handle it
1. Standards state the property, not the implementation. "Compute is provisioned through the platform, is observable through the standard telemetry, and is patched on this cadence" is a standard a specialised workload can meet. "All compute runs on this instance family" is not, and it will be broken by the first legitimate exception.
The distinction matters generally: a standard expressed as a mechanism will be violated by every case its author did not foresee; a standard expressed as a property survives.
2. Explicit variation points. The standard names where instances are allowed to differ and where they are not. Without this, the standard is either ignored or applied absurdly.
3. An exception path with an owner, a scope and an expiry. Not a permanent carve-out. Exceptions with no expiry become the architecture.
4. Extend the standard where the exception recurs. If specialised compute becomes a recurring need, the answer is a second sanctioned pattern with its own paved road — not an indefinite series of exceptions. Two supported patterns are far cheaper than one standard and twenty exceptions.
What the specialised workload must still meet
The properties the standard exists to protect, even if the mechanism differs:
- Identity and access through the enterprise model.
- Observability in the common telemetry, so it is operable by the same on-call.
- Network policy and segmentation consistent with the estate.
- Cost attribution, so its spend is owned.
- Patch and vulnerability management, however the mechanism differs.
The failure to avoid
Standards defended as ends in themselves. A standard exists to reduce operational cost and risk. A workload meeting those objectives by a different mechanism has not violated the intent, and refusing it drives the team outside the governed estate — producing a shadow environment with none of the controls the standard existed to provide.
The governed exception is always better than the ungoverned workaround, which is the practical argument for making the exception path fast and visible.