On the value of an automation platform

 March 31, 2026

Over the last 20+ years in IT, I’ve seen automation evolve from a nice-to-have to a non-negotiable part of how organizations operate. Every company I’ve worked with has some form of automation. The problem is that, in many cases, what they have is not an automation strategy but rather a collection of individual scripts, cron jobs, and one-off solutions that were built to solve immediate problems. This is what I usually call ad-hoc automation or point automation, and while it works in the short term, it creates significant issues over time. This does not happen only in small or particularly tech-adverse companies; it is a very common situation across sectors and sizes.

The reason the majority of companies start introducing automation in an ad hoc fashion is fairly easy to guess: it solves immediate problems with minimal friction. Automation is natural, to the point that we could even argue it is an emerging human behavior: when someone needs to perform an action repeatedly, they often try to automate it. To do so, they will probably write a script or a short program. If they need to integrate it in a more complex workflow or allow untrusted (or semi-trusted) people to run it, they will also create a UI or an API.

Each of these automations, taken individually, makes perfect sense. The person who wrote it understands it, it solves their problem, and it gets the job done. The issue is that no one is looking at the bigger picture.

Over time, though, the organization ends up with dozens or hundreds of these small automation artifacts scattered across the estate. They live in different repositories, use different languages, follow different conventions, and have wildly different levels of documentation and error handling. Some are version-controlled, some are not. Some have been tested, most have not.

This is the automation equivalent of technical debt, and like all technical debt, it compounds.

When I talk about an automation platform, I’m not talking about a fancier way to run scripts. I’m talking about a fundamentally different approach to how automation is created, managed, executed, and maintained across an organization.

I want to be clear about one thing, immediately: this is not about any specific product. Whether you choose Ansible, Terraform, or any other solution, the principles remain the same.

Just in the last couple of weeks, I’ve been asked three times by large corporations what an automation platform is and how it differs from their solution. A good automation platform needs, first of all, to be the materialization of an enterprise-wide automation strategy, which mandates automation to be developed by teams, on which language it needs to be written, which platform it needs to be run on, what the automation code structure is, how credentials are managed, etc. Looking at the platform from a practical standpoint, it is a tool that a designed team stands up and maintains, applying updates, bug fixes, etc., and provides to the rest of the business. On top of this platform, the other teams create their own automations.

This is not a new concept in enterprises. It is very common to find virtualization and application platforms in businesses that work exactly the same way. Though, for some reason, the people have a lot of resistance to applying the same model to automation.

There are several benefits to a platform approach to automation.

The first is the result of the centralization itself: governance, security, and auditability are easier to achieve. Since all automation happens in a single place, it is easy to gather all logs, set up enterprise-grade authentication, ensure the platform is always up to date, and keep it secure, as with any other software officially deployed in the organization. Further, having a dedicated team to maintain the platform makes all platform lifecycle aspects easier to schedule and more predictable. Automation code should not contain credentials. Credentials should be injected by the platform at execution time. This allows automation developers to write automation code without accessing secrets, making the whole organization much safer.

The second benefit of the automation platform is about reusability and inner-sourcing. A critical aspect of a well-designed automation platform is that the automation code is not written in a way that ties it to a specific machine. It should be the platform itself that associates the execution of a specific automation code with the automation target. The code itself should be managed as any other piece of code: it should be versioned, documented, tested, and have a clearly defined lifecycle. Thanks to this aspect, as well as the use of a single automation language across all automation on the platform and, hopefully, the same best practices across the organization, it is possible to share and reuse code across different teams. In theory, if all good coding and security practices have been adopted, there is no reason why the automation code should not be shared across the organization to all automation developers. This sharing allows the creation of Communities of Practices where practitioners share their knowledge and provide feedback to the platform team to continuously improve the platform.

The third benefit of an automation platform is that automation execution occurs in a trusted environment. This might seem a trivial aspect, but it becomes critical in enabling end-to-end automation. Usually, users do not want to create a VM, open a firewall port, or provision disk space. What they really want is to provision a full environment to deploy their artifacts. Deploying a full environment might involve deploying tens, if not hundreds, of components.

Having the ability to provision components quickly through automation is good, but if they have to provision components individually and potentially obtain approvals for each component, it will still be a very painful experience. The solution is to leverage the presence of all automations on a single platform to create higher levels of abstraction, allowing the user to run full environments in a single run and ensuring that all approvals and checks are completed immediately after the request, before provisioning any item on the systems. This provides a significantly improved user experience, drastically reduces the number of approvals, and minimizes the time users have to wait to access their new environments.

In my experience, creating an automation strategy and an automation platform is the only way for organizations to get real value from automation, allowing them to reduce the time to achieve business value by orders of magnitude while simultaneously improving consistency and security posture.

Does your automation have an automation strategy and platform, or is it drowning in ad hoc automation?