Building an Automation Framework

What does good look like?

What does good look like? So often over the course of the maturing automation landscape, we get asked this question.

We believe that shared frameworks provide shared curiosity and understanding, so we've pooled the lessons that we and our clients have learned over the hundreds and hundreds of automation projects we've designed and delivered for organizations across the globe to create our formal Automation Framework.

While we have espoused an architectural pattern that includes the building blocks for automation, this is the first time we are prescriptively putting product names into those functions. The Automation Framework's goal is saying to organizations still struggling with where to begin, "This is where we begin!" 

Why adopt an automation framework?

The advantage is that we get past the tools discussion and start talking about the solutions we can build and benefits those solutions can offer. We've identified the essential building blocks of an automation architecture, now we offer the best-in-industry tooling that fulfill the requirements of those blocks. A core advantage of establishing a framework is that it shifts organizational energy from toiling over potential operational challenges to creating a strategic, cross-functional vision that enables teams to solve those eventual challenges the speed, reliability and scale that automation offers.

How automation drives innovation and drives business value?

Regardless of industry, organizations invest in technology to enable and sustain their strategic goals, and ultimately their success. Financial, government, manufacturing and utility entities all measure success differently, yet they each depend on their technology investments to make daily progress toward their goals. The ability of a well-formed automation program to deploy faster and safer is a vital factor in supporting and enabling those goals. 

Building the foundation for AI-enabled operations

We couldn't call ourselves technology experts in 2026 without understanding the role of AI in automation. We feel that automation is foundational for providing data governance to AI tools that need context about technology. Automation, as we will show in this framework, provides AI tools with trusted workflows that are aware of infrastructure architecture, intended configuration and healthy operational state. This framework provides a safe and predictable outcome via automation that is potentially triggered by our AI systems. 

Of course, automation benefits from AI, too. AI coding assistants help teams develop automated workflows faster, plus they help teams build and maintain more robust testing frameworks for both automation code and infrastructure systems.

Framework components

This Validated Automation Framework at a high level has four components:

1. A way to model what our infrastructure and their relationships: As automation scales, so must the ways in which you store configuration data. Adopting a robust System or Record (SoR), sometimes called a Source of Truth (SoT), allows your visibility and management of intent data to grow alongside your automation capabilities.
2. A place to run automation jobs: Provides a focal point where automation jobs are run, tracked, maintained and shared. This provides an integration point for other systems in the environment to coordinate automated interactions and share data.
3. A way to measure results:  provide mechanisms to continuously measure your ongoing progress and inform your strategic decisions.
4. A place to store our code: A place to store, version and share codified solutions and information enables cross-functional teams to automate high-value, operationally critical sequences across technology stacks.

Now that we have those four pillars defined we will explain why we have chosen the following tools to implement those components.

1. Infrastructure Modeling: NetBox
2. Automation Platform: Red Hat Ansible Automation Platform (AAP)
3. Performance Measurement: Red Hat Automation Dashboard
4. Code Storage: A Git-based collaboration platform. Since most organizations have a Git platform already, we won't spend much time discussing this pillar.  However, it's noteworthy that a Git-based platform is no less important than the other tools.

Why NetBox?

At the heart of a robust automation, or even AI solution, data is king. The ability to model what your environment looks like in a reliable, extensible database allows you to build the data models that your automation can consume to do things like provisioning or testing of networks and systems. NetBox is the industry-leading SoR platform and thus fits into this framework as a key component providing the intent data that external systems can reference.

NetBox started out as a DCIM-focused solution, especially for networking. As it has evolved, it is now flexible enough to capture IPAM, data center, compute and security components as well as keeping its features of cabling, rack and power modeling and network source-of-truth capabilities.

NetBox also has integration capabilities to sync data with things like Infoblox, Catalyst Center, VMware and more. It also has a supported MCP server to integrate with agentic ops clients.

Why Ansible Automation Platform?

The Ansible product has evolved from a Linux sysadmin tool to a robust ecosystem of automation capabilities across many different technology stacks such as network, storage, compute and security. Because of its open-source roots and its disaggregated architecture it allows for scalability and customization. Ansible Automation Platform allows for centralized control and auditing, workflow tools, RBAC and version-control integration. AAP also has a full-featured REST API that allows for seamless northbound and southbound access. This lends itself to necessary and useful integrations as we will discuss later.

Important AAP features

AAP as a platform is continuously evolving, but at its core is a robust, scalable and secure interface for managing and launching automation jobs. One of the key features of AAP is the auditing capabilities. The platform records when a job was run, who ran it and the results of the job. These are powerful data points for governance of changes. The RBAC capabilities allows different teams within an organization manage and launch their relevant jobs, but not access to jobs that are not relevant to their job roles.

In addition to the core capabilities of AAP, there are other high-value features such as a Private Automation Hub where users of the platform can safely publish and share code specific to the organization's need in the form of Roles or Collections. Further, execution environments provide a pre-packaged container that would include all the required Ansible Collections, system requirements or python packages required for workflows. These containers are where jobs are run when they are launched. This easily allows strict control over software package versions and collection versions.

Also included in AAP is Event Driven Ansible (EDA). Ansible automation jobs require some sort of trigger to run, and that trigger is often an administrator clicking a button.  This is effective for many jobs, and EDA adds a means to trigger automation jobs based on pre-defined events.  EDA continuously listens for these events, matches them to prescribed conditions and triggers specific automation jobs. This sort of workflow is a fantastic way to automate troubleshooting, enrich incident tickets with essential information, perform validation testing and even remediate problems before human operators are aware that they exist.

Another advantage of adopting AAP is that is gives the knowledgable subject matter experts writing the Ansible code the ability to publish these automations to non-expert users. This means a repeatable process can be launched by a tier-one engineer without having to involve higher-level engineers. This produces faster outcomes and frees up time for the higher-level engineer to work on higher-level tasks.

One of highest value outcomes of automation is reducing the friction between teams. Because each team can publish its own automation for the way they want their systems interacted with, they can then share these reusable roles across teams, via git or private automation hub. For example, every time a network team needs a certificate from the security team, an automated renewal is available to attach to their workflows. This sort of cross-team collaboration saves security teams time by keeping them from managing certificate renewal tickets.  It also prevents network teams from waiting to complete their work while simplifying compliance with established security standards.

Why an Automation Dashboard?

What impact does our automation have on our teams? Our organizations? How do we justify modernizing our operations? With a tool like Ansible Automation Platform, we have key data points such as when a job ran, was it successful, who ran it, what were the results. If we can take these metrics and start aggregating them over time, we can create reports or dashboards that proves the effectiveness of automation.

We've been able to pull this sort of data from AAP and model it using different tools like Grafana, etc. for a long time, however Red Hat's built-in Automation Dashboard vastly lowers the barrier to accessing and acting on this information. This allows for custom reporting and dashboards integrated directly into the AAP ecosystem giving users and management the data they need to see the power of transformation through automation.

Integrations

Now that we have our main components of the automation framework, lets talk about what this enables us to build on top of this.

ServiceNow

Once automation capabilities are built, we can scale those to different consumers. The idea that we can push the automation closer to the requestor greatly reduces the delivery time of those resources. ServiceNow is almost ubiquitous in our customer base. If we can publish capabilities where users already know to go for requests, we can streamline those requests. Linking ServiceNow requests via the AAP API is a repeatable way for those end-users to consume the services that automation can provide.

Observability

Observability tools, at their best, allows us to understand the state of our complex systems. Through the data that the automated framework possesses, such as all the infrastructure contained in our SoR and jobs that have run in our automation platform, we have data to make sure our observability tools have the full scope of our infrastructure. Additionally, if we have robust, trustworthy observability we can integrate them with something like Event-Driven Ansible to react to events when they occur instead of waiting for a human to respond.

Agentic AI

We have the data about our systems housed in our Netbox Instance, we have ways to check real time information about our networks with AAP. This gives us the data we need to interact with our systems using an AI agent. Through use of MCP or RAG, we can answer questions about architecture, state or even capacity planning with AI. Furthermore, when we get to the point where we want agents to make changes to our systems, we can use our safe, deterministic automation systems to make sure these changes are done properly. This also gives us an opportunity to wrap policy around what AI agents can or can't do. This allows us the speed and intelligence of an AI layer with the safety of automated jobs.

Example solution

Lets review one of the more repeated architectural patterns we have seen in our customers: Software Image Management. The problem we are solving is keeping up with patching in response to bugs, CVEs or feature enhancements. Keeping up with patching schedules is often a never-ending process in large organizations.

In the context of the core components of the automation framework, a tenant of a successful and scalable SWIM workflow is the ability to use the same process for patching, regardless of which system or systems you target with the workflow. Our automation is built in a way that a common consumption model eases planning and deployment for patching cycles. The automation knows how to upgrade device A vs. device B, but the process is the same.

We have a solid source-of-truth to represent not only the configuration but the relationship between devices. This allows us to achieve velocity by automating the manual checks we would usually do before and after an upgrade. The pre- and post-checks allow us to move on to the next batch of upgrades with the knowledge that our upgraded devices are returned to service successfully. The tests are written with the knowledge contained in the source-of-truth. We can verify the intent and the architecture is still intact after a reboot of a device.

The automation dashboard allows us a quick view to the success of our patching schedule, and can alert us to failures. We can measure over a change window (or several change windows) how our maintenance events have grown from 10s of devices to 100s of devices while our infrastructure remains stable and safe.

Conclusion

What does good look like? Where do you start with automation? Our goal is to answer this question with a validated automation framework that we have seen be successful. WWT works tirelessly to enable our clients to achieve business and technical transformation with modern operations. At the same time, we want to align with the culture of our clients. If you asked us where to start, we would point to the above framework, but we know that the real world is not always that easy. We can align our skills and development to our client's environments, but still building towards the goal of modern operations that improves your business today and enables a path for building future successes.

Schedule a briefing to learn more.