What SDO XaC — Software-Defined Organisation and Everything-as-Code — actually requires, and why most implementations stall at the tool selection stage
Newsletter
Insights, research, and expert perspectives — direct to your inbox.
Digital Acceleration Tools -- DATs -- are platforms and methods specifically designed to shorten the time between having a digital capability on your roadmap and having it operating in production. They are not a single product category. DATs is the umbrella term for a set of…
Everything as Code is not a tooling decision but an organisational operating model — get ownership, review, and accountability right before the first line of infrastructure code, or the toolchain just accelerates the drift.
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.
It changes who owns infrastructure decisions, how compliance is enforced, how risk is managed, and how teams are structured.
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 appear consistently.
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.
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.
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.
Make three decisions before you write a line of infrastructure code.
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.
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.
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.
AI development tools have moved from autocomplete into the workflow itself. In 2026, context-aware AI assistants sit inside the developer environment, giving feedback at design and build time, and agentic tools increasingly draft, test, and refactor across whole tasks rather…

Digital Acceleration Tools -- DATs -- are platforms and methods specifically designed to shorten the time between having a digital capability on your roadmap and having it operating in production. They are not a single product category. DATs is the umbrella term for a set of…

AI development tools have moved from autocomplete into the workflow itself. In 2026, context-aware AI assistants sit inside the developer environment, giving feedback at design and build time, and agentic tools increasingly draft, test, and refactor across whole tasks rather…