The platform team owns the base image. The application team owns everything on top of it. Both have automation. Neither knows what the other ran last Tuesday.
I have seen this happen. The platform team created a hardened AMI, but the application deployment pipeline overwrote the hardening. The security control disappeared. They caught it during a routine review. If they had not, when the audit came six months later, nobody could have explained the sequence from the scattered logs without knowing which team to ask. The people involved were not incompetent. They just had no way to see each other’s work.
The Automation Success Problem
Most large organizations have not failed at automation. They have succeeded at it, team by team, with whatever tool fits the job. Chef. Puppet. Ansible. Terraform. Custom Python. A few shell scripts that should have been retired years ago.
The problem is not tool quality. It is that different teams are automating different layers of the same infrastructure or even running on top of one another, with no shared view of what happened.
That is not chaos. It is ‘automation islands’.
The Trap of Standardization
The obvious response to multi-tool sprawl is standardization. Pick one tool. Migrate everything. Retire the rest.
Do not do this.
I have worked with organizations that declared Chef as the standard and treated every other tool as non-compliant. On paper, they standardized. In practice, teams with established Ansible estates kept using Ansible and teams migrating from shell scripts or manual runbooks often just wrapped those steps in Chef with no real shift to resources or idempotent patterns.
That is the trap: you can standardize the label without standardizing the operating model. You add migration debt, create a false sense of control and still avoid the real fix: a shared execution layer.
What Actually Needs to Change
You do not need to retire your tools. You need a shared execution layer that coordinates and governs execution across them.
Think of it this way: the Ansible playbooks, Puppet manifests and Bash scripts still exist and run exactly as they do today.
What changes is how they are invoked and governed: who can trigger them, what controls apply and whether one team’s execution can collide with another’s. That gives you greater control over execution order and a unified audit trail without forcing teams to rewrite what they already use.
This is an addition, not a replacement strategy. The scripts, playbooks and manifests you already rely on can stay in place, giving you room to consolidate tooling over time where it makes sense. The change is in how execution is controlled and governed, not in the automation itself.
So, What Now?
If you work in an infrastructure organization with more than one automation tool, you are probably living this problem right now. The question is not whether you have it. The question is whether you can see it.
Start with a simple test: pull your last three months of infrastructure change logs and try to reconstruct your most recent production incident from a single system. If you cannot do that without manual log collation and cross-team backtracking, you still have automation islands, and you need a better execution model
What this test reveals is a deeper issue in how execution is structured. Moving to a single execution layer brings cohesiveness back into the chaos. By centralizing execution, improving auditability and defragmenting the system, you gain stronger control over your infrastructure.
If this resonates, download our platform governance readiness self-assessment. It is designed for teams with multi-tool environments to reflect upon their environment and tooling. This will help them determine whether an execution layer is the right move for their environment.
- Takes just five minutes
- Built for real-world, multi-tool environments
- Easy to share with your architecture and platform teams
Find out where you stand and what’s holding you back.
If you want to understand the architectural patterns that make this work in practice, the next post in this series covers the Chef 360 platform as an execution layer: what it looks like, how teams actually use it and the governance patterns that make it real.
This post is part of the Automation Without Rewrites series: on governing and scaling the automation you already have, without starting over.