Expert Perspective: Lessons on SDO XaC

Two XaC Implementations Led, Several More Reviewed

I have led XaC implementations in two organisations and reviewed implementations in several others. In the first, we spent five months selecting and configuring the toolchain before anyone asked the governance question: when the code runs and something breaks, who is accountable? We discovered we had no clear answer, and by then the toolchain had been built around tool assumptions rather than our own architectural decisions.

The second implementation started with that question. The outcome was different. The toolchain took four weeks to stand up. The governance model took two weeks before that. Everything that followed worked.

Everything as Code is not a tooling decision. It is an organisational operating model, one that changes who owns infrastructure decisions, how compliance is enforced, how risk is managed, and how teams are structured.

XaC Is a Digital Accelerator That Needs Ownership First

XaC (Everything as Code, the practice of managing infrastructure, policy, and configuration as version-controlled, executable code) is a digital accelerator in the precise sense: it does not create design discipline, it amplifies whatever discipline already exists in your organisation.

Digital accelerators (D6 of the 6xD framework, covering tools that compress time-to-value by encoding decisions that previously required human intervention) work by encoding decisions at machine speed. That encoding only produces acceleration when the decisions themselves are clear, owned, and consistently governed. When they are not, XaC encodes ambiguity at machine speed.

The SDO model (Software-Defined Organisation, the operating model in which infrastructure, policy, and configuration are treated as software and governed accordingly) is not a tool adoption. It is an accountability redesign. The question of who owns the code is the question of who owns the decision. Those two questions must have the same answer before the first line of infrastructure code is committed.

Three Failure Patterns, Starting With the Split Organization

Three failure patterns appear consistently.

1. The split organisation. Development teams adopt code-defined infrastructure with speed. Operations teams feel their expertise is being replaced rather than encoded. Security functions bolt controls on after the fact. Three groups write three kinds of code that do not share a common model and do not speak to each other in practice. That is not XaC. That is technical debt with a new label.
2. Governance theatre. Teams produce Infrastructure as Code repositories that are version-controlled and never reviewed. Policy as Code frameworks are deployed with no named owner. The code drifts from the actual environment as manual overrides accumulate. The repository becomes a historical record of where the architecture was twelve months ago.
3. The tool-first trap. Organisations spend six months selecting a toolchain before defining what XaC is supposed to govern. When the governance questions arrive, who reviews a pull request changing a production policy rule? who owns the golden path templates?, the toolchain does not answer them.

Named failure mode: compliance drift. A team implements Policy as Code using OPA rules to automate compliance gates. The security function signs off on the initial rule set. Six months later, regulatory requirements are updated in a policy document nobody converted to a code update. The automated gates run the old rules. The organisation passes the automated check and fails the regulatory standard.

Decide Who Owns It Before Writing Infrastructure Code

Make three decisions before you write a line of infrastructure code.

1. Who owns it. Specifically: who has authority to approve changes, deprecate configurations, and mandate updates across teams. Not in a CODEOWNERS file, in a team structure and a review process.
2. How it is reviewed. What the pull request review process looks like for infrastructure and policy code, who has authority to block a merge, what the review cadence is.
3. What accountability sits behind it. What happens when a production incident is traced back to a code change, and whether the accountability model is clear enough to survive that conversation.

If your security function is not a co-author of your Policy as Code rule set, you do not have XaC. Get those three answers right and the toolchain accelerates a sound operating model. Get them wrong and the toolchain accelerates the drift.