The Silo Problem: Three Teams, Three Truths

Ask an infrastructure engineer, a security engineer, and a compliance officer to describe the state of your production environment.

You will get three different answers. Not because any of them is wrong. Because each of them is looking through a different tool, with a different data model, in a different language, updated on a different schedule.

This is the silo problem. And it is not a people problem. It is an architecture problem.

Three Teams. Three Tools. Three Truths.

Modern infrastructure management has quietly fractured into three separate disciplines, each with its own toolchain.

Configuration is owned by infrastructure engineers (as defined in Part 2: the SREs, DevOps engineers, Platform engineers, and others in the trenches). They write Terraform, Ansible, Pulumi, shell glue, and platform-specific templates. Their source of truth is a repository and, often, a last-run artifact.

Policy is owned by security or platform governance teams. They write policy in a separate language, in a separate repository, often evaluated at a separate moment.

Evidence is owned by compliance and audit functions. They gather proof after the fact, usually through scans, reports, benchmarks, spreadsheets, or external control mappings.

Three teams. Three tools. Three truths. And somewhere in the middle, a production environment all three are supposedly describing.

The Gap Is Where Things Go Wrong

In a perfect world, these three views would stay synchronized. What the infrastructure team deploys would satisfy the policy team's constraints, and the evidence the compliance team gathers would reflect both. In practice, the gaps between them are where most infrastructure failures originate.

A configuration change ships because it passed the pipeline. The policy check ran against the plan, not the outcome. The compliance scan runs later. By the time anyone notices the gap, it has been open for weeks.

This is not a failure of process. Teams respond by adding more gates, more reviews, more approvals, more tickets, more meetings, more control points.

The overhead grows. The gaps remain. Because you cannot close an architectural gap with workflow alone.

The Translation Tax

There is another cost that gets discussed far less often: the translation tax.

A security engineer expresses a constraint in one language. An infrastructure engineer has to interpret it in another. A compliance team speaks in controls and benchmarks. The platform team speaks in resources, providers, modules, and runtime behavior.

The mapping between these models ends up living in a spreadsheet, a wiki, a point-in-time audit package, or someone's head.

That translation is expensive. It introduces ambiguity. It makes collaboration slower than it needs to be. It creates situations where two teams believe they agree while actually operating on different models of the same environment. The language barrier is not incidental. It is load-bearing.

Policy as an Afterthought

The usual infrastructure workflow looks something like this: write configuration, open a pull request, run a policy check as a gate, apply if it passes, produce compliance evidence later.

Policy appears in the middle. Compliance appears at the end. Both are downstream of configuration. That means both are reactive. They are checking intent after intent has already been formed, rather than shaping intent from the beginning and continuously validating it against reality.

This is why teams end up with the familiar pattern: the pipeline was green, the deployment succeeded, and the environment still drifted into a policy or compliance problem later. The fix is not a better gate. The fix is eliminating the separation in the first place.

Same Room. Same Language. Same Loop.

What would it look like if configuration, policy, and evidence were not separate disciplines with separate toolchains, but different expressions of the same infrastructure truth? An infrastructure engineer writes what the system should be. A security engineer writes what the system is allowed to be. A compliance team defines what evidence the system must continuously produce.

All three live in the same language family. All three are evaluated in the same loop. All three operate on the same model of the environment. The security engineer does not need a separate policy universe. The compliance team does not need a separate evidence universe. The infrastructure engineer does not need to guess whether their configuration satisfies constraints defined somewhere else.

When the walls come down, the gaps start closing. Not because of better process. Because the architecture no longer creates the separation in the first place.

The Silo Is a Design Choice

The uncomfortable truth is that the silos between configuration, policy, and compliance exist because we designed them in. We built separate tools for separate concerns and then wondered why the teams using those tools ended up operating on separate truths. That separation made sense when each concern was young and tooling was immature. It makes less sense now. What remains is the accumulated cost of treating three views of the same infrastructure reality as three separate systems.

That cost shows up every time:

• a security rule exists but is not visible to the people writing config,
• a compliance finding surprises the infrastructure team,
• an incident reveals that the platform team and the policy team believed different things about the same environment.

The silo is a design choice. It can be unmade.

---

What's Next

The next post looks at what happens when a broken execution model meets a new force multiplier: AI-generated infrastructure intent.