Is Enterprise Automation Next Generation Architecture?

Setting the Stage

Automation is an initiative on all IT Leaders “to do” lists. But the definition of automation is not consistent across all leaders. Much of the ambiguity in the definition has to do with scope. Enterprise Automation is intentional about looking at automation from a business perspective. IT Automation on the other hand is more focused on eliminating humans from repetitive tasks.

One could think of enterprise automation as a consolidation of many IT automation projects across the enterprise. However, the only way true value can be realized from Automation is if these tactical projects were coordinated and integrated to deliver a strategic goal. Otherwise, these IT automation projects are just independent initiatives that may or may not be able to work together at key intersection points.

Thinking of automation as a strategic initiative is not something I see a lot of organizations truly contemplating.

Consider that some automation initiatives may focus on an organization’s hybrid cloud infrastructure while another initiative within the same enterprise may be driving towards automating security remediations. Other projects could have a goal of ensuring systems remain in compliance with security standards.

Each of these initiatives may require touching infrastructure components such as networking, and servers as well as reacting to changes provided by an application’s API. Thinking carefully about this, one can see how complexity is inherent to an enterprise automation initiative.

My goal with this post is to identify the points that an organization should consider when embarking on an Enterprise Automation strategy.

What is the value of Automation?

When thinking of next generation architecture, organizations should consider automation from an enterprise/strategic perspective. To accomplish this, IT Leaders need to be able to present a business case on the value of such an initiative. But how does one define the value of automation? Is cost savings compared to the cost of the product a sufficient metric? If an organization is looking only at short term tactical projects then focusing on cost may be a valid approach. However, implementing short term tactical automation projects may create longer term technical debt if not addressed as part of a broader strategy.

Enterprise Automation is a strategic, business level project where strategic value outweighs cost in the long term.

A strategic enterprise automation strategy, must look at the business value an organization can achieve. An increase in quality is a great strategic value, as is agility and speed of execution. What about increased efficiency that allows staff to focus on growth initiatives? Compliance is another factor that is a costly exercise for many organizations. An organization also has existing assets that must be leveraged. Using automation to streamline those processes is also something that should be considered.

All of these factors have a place in a business case for enterprise-wide Automation, but what this approach really requires is that an organization look at automation as a strategic initiative, not merely a technical one.

An Enterprise Framework is Key

How does one approach an automation strategy at an enterprise level? Today’s enterprises are highly complex, interdependent ecosystems. They consist of infrastructures that span on-premise, public cloud, and increasingly multiple public clouds. Automation needs of these infrastructures span provisioning, patching, and incident response. Infrastructure as code is a promising technique to address these needs, but how does one address networking components and applications as well as compute and storage components?

Security footprints are often made up of a combination of event producing pieces of software that must be correlated, oftentimes manually. In larger organizations, these processes may be disparate depending on the team responsible for that part of security. What happens when something suspicious happens and deeper investigation is required to prevent a breach?

Secrets management is another example of complexity within the enterprise. Applications, infrastructure and databases may legitimately need elevated privileges. Creating a standard codified process that allows these credentials to be extracted from a secrets management repository and securely be used across multiple automation runs is a highly desired integration point.

Most mature automation processes are implemented in code. Considering how to manage an automation code repository is another important consideration. Factors such as structure, access and code quality should be considered.

Creating a framework, that addresses people, process and technology that will in essence govern what gets automated, is a critical step in evolving an organization’s architecture. Once an organization understands that an Enterprise Automation Framework is required is when one should look for the right tooling to accomplish its goals.

Enter Ansible Automation Platform

Ansible Automation Platform is the technology part of an enterprise framework for automation, a platform that can easily integrate with other product-centric tools across infrastructure (public and on-premise, network, compute and storage), be able to interface with applications through their API’s, coordinate security incident response, support secrets management among other capabilities.

While there are combinations of other tools that can support this enterprise framework, Red Hat’s Ansible Automation Platform 2 is a single, unifying platform that should be on any IT Leaders short list in enabling organizations to achieve this goal.

As an API-first platform, all of its capabilities are exposed through its REST API. This provides the platform the capability to integrate with other application APIs to either enable some function within that application or accept a call from that application and execute some codified activity.

As the rising de facto language of IT automation, Ansible collections, roles and playbooks proliferate the Internet. Many of them are available through community sites such as galaxy.ansible.com. But how well are these community-developed playbooks managed? Is there a potential for some bad actor to poison a collection thereby potentially compromising one’s enterprise automation strategy or worse? As an organization that thrives on community, Red Hat understands how to secure the software supply chain.

We have taken our expertise in how we productize open source projects to Ansible content in the form of Certified Content Collections. Within the Red Hat Automation Hub, that can be consumed either as a service or on-premise, we have certified 114 collections across 56 partners including AWS, Microsoft, Cisco, Cyberark and ServiceNOW.

Red Hat has approached AAP’s Role-based Access Control with organizational delegation in mind. We have an organization and team structure that allows subject matter experts (SME) to have the access they need to codify their processes in Ansible playbooks and distribute them to the enterprise as Job Templates. These templates are distributed using a security approach that will allow the elevated credentials to be used during the execution of a playbook run, but never exposed to anyone. This approach frees up the SMEs to move on to higher value work while providing the teams that need these processes to get their jobs done more efficiently.

An Automation Architect is then able to use the Job Templates provided by the SME’s from different teams in an Ansible Workflow to create an overall codified service that can then be exposed to and consumed by the automation consumers. This service can be constructed in such a way as to include any appropriate approvals and published either on the Red Hat Hybrid Cloud under your organization’s account or built on a private service (tech preview) provided by Red Hat.

Automation Metrics

Through most of this blog I have talked about the harder-to-quantify parts of automation such as ensuring quality by codifying processes, and increasing efficiency allowing staff to free up time and work on growth initiatives. However, while quality, growth, and compliance should be a key part of any enterprise automation strategy, clearly cost must still be considered.

A feature of Ansible Automation Platform that is often overlooked is Red Hat Insights for Ansible. This service provides a couple of capabilities for customers: 1) Projecting automation cost savings using Saving Planner and 2) Determining savings being realized from implemented automation using the Automation Calculator.

We provide these services to aid organizations in calculating the potential cost savings of an Ansible Automation Platform Investment.

Closing

One of my goals with this post is to address the point that automation should be treated as a strategic initiative. Further as Enterprise Architects build a business case for enterprise automation it should include other factors such as increasing quality, providing opportunities for growth, maintaining compliance, and maximizing existing assets in addition to cost. Any solution for an Enterprise Automation strategy should consist of creating a framework that would allow appropriate tools to integrate and work together cohesively. Integration points and a diverse ecosystem are critical to the success of a project of this scale.

Finally, I wanted to make the case that Ansible Automation Platform 2 should be on any IT Leaders short list of products to evaluate for this type of initiative.

Is Enterprise Automation a Next Generation Architecture? Should factors other than cost be considered? Is Ansible Automation Platform 2 a viable solution for an Enterprise Automation initiative?

What do you think? I read and respond to all comments.