A Year of Workshops: What We've Learned From Automation Envisioning
The Infrastructure Automation Envisioning Workshop allows WWT to work interactively with our customers to help prioritize, explore and set a vision for infrastructure automation within Information Technology (IT) organizations. In this workshop, we explore the reasons a given organization wants to adopt automation or further their automation strategy. We explore the challenges that a team has already encountered. We also help IT teams prioritize the focus of their automation development efforts in order to best support the goals for a business or organization. 
Over the past year of facilitating these workshops, we've seen some common themes emerge, such as lack of time or resources for training and conflict between departments within an organization. We've also seen some common goals such as automated compliance and reduction of toil.
The first goal of this workshop is to expose challenges that emerge either from a lack of automation or a lack of effective, scalable automation. The second goal is to help set courses of action that will allow IT teams to demonstrate high-value, high-impact results from automation in the quickest manner possible. The third goal is to outline a strategy that helps organizations create an automation architecture that is flexible scalable, and supports a community of automation development throughout an IT organization.
What is driving the need for automation?
Increasing speed of delivery and reducing friction when work passes between different teams are the most common drivers amongst our workshop participants. These two drivers are interconnected, and one of the powers of automation is that can reduce the number of common requests that are passed between groups. For example, think of a network operations team that needs to pass a ticket to the network services team that manages an IP address management (IPAM) tool such as Infoblox. An automated workflow could reserve that IP address without the need to have manual intervention from different approvers. This inherently increases speed of delivery for that service. Not only is it the speed of delivery, but it is the confidence that those items are configured properly and the same way each and every time.
Toil, in the DevOps context, is defined as manual, repetitive work that diminishes in value as the work increases. Think of our previous example of reserving an IP address in an IPAM system. The work is the same every time, and while important to document and track those operations, clicking around a GUI and copy-pasting a value between screens is repetitive and subject to error the more it is done because, honestly, it is boring. Automation can reduce the time and increase the accuracy of that operation by reducing the toil, which allows talented engineering teams to to focus on higher-value work.
Automation priorities
When asked about priorities, our workshop participants had varied answers, some specific to organizational goals and/or directives. Some had more industry-standard answers such as wanting to keep up with the current trends and keeping their skillsets up to date with training. Any modern IT system should have an interface that lends itself programmatic access, typically referred to as an Application Programming Interface (API). Automation is not a corner case anymore. It is, as we say, "table stakes" to have the ability to automate tasks within a system, whether that system is a storage array, a compute platform, or a network device.
One of the priorities our customers often cite is standardization. The ability to know that a device is configured a standard way each and every time is important to organizations for two reasons. One, we know that any change made to a device or a fleet of devices will have that common configuration, and that configuration is prescribed in code. We know that defining configuration "as code" prevents accidental device misconfiguration, and the "as code" methodology protects against the dreaded compliance and troubleshooting headaches that result from configuration "drift." Imagine you have 100 routers across your organization running BGP. Because all those configurations have been manually typed in by different engineers over time, there may be subtle differences that don't affect the operation today. However, there may be a need to update a prefix list in the future and it is possible that N percent of those routers have unexpected behavior because they are not starting from the same base configuration, that is the danger in configuration drift. Having a standardized data model that implements these changes through an automation workflow gives a team the confidence that each device is configured according to design.
The other priority that is often cited is service delivery. Going back to the drivers of increased speed, the idea that we can decrease the time to delivery of a service to its requestor is a high-profile way to show the value of automation. For example, when a developer needs a way to publish an application or service, they likely need to request an IP address. If that developer is accustomed to a waiting on IT for three-days before their request is complete and you automate this workflow such that it completes within five minutes, there is immediate value from automation to the developer, IT engineers, and the larger organization. When you demonstrate the sort of value that people can "feel," because you gave them the precious gift of time, you don't have to explain how you automated the process (perhaps by integrating a ServiceNow workflow with a Job in Ansible Tower that configures a Virtual IP (VIP) on an F5 Device, etc.) in order to secure investment in to automate more workflows. The value feels so obvious to people because IT operations no longer has the appearance of being a blocker for development cycles that are critical to advancing organizational goals. 
Common challenges when implementing automation
Understanding an organization's priorities for automation and their main impetus for implementing automation is important to help understand where the journey of automation may begin. Before a team can start implementing those practices, they must acknowledge that there are some challenges. Otherwise, that team would already be executing on these desires.
The most common challenge we've heard, by far, is in the realm of training and skills development. The IT industry is changing and engineers who have spent a career learning the intricacies of data center network design are being asked to learn new skills, and this can be a challenge. It can be daunting to look at everything in the universe of programmability and automation and figure out where to begin. The most common starting points that we've seen in our customer base has been Red Hat Ansible and Python. For on premises infrastructure, this is the de facto standard that is common across our customer base. The flipside of where to start is finding time to learn. The other challenge that we've seen in these workshops is prioritizing learning these new skills amongst the day-to-day challenges that an IT engineer faces. Unfortunately, a lot of organizations haven't prioritized learning new skills and veteran engineers are forced to spend off hours coming up to speed on these new technologies.
The other common challenge we've heard over the past year is organizational. The problem of "islands of automation" is a real one in most enterprises. The virtualization team, the storage team, and the network team may all have different priorities and roadmaps for their automation. How can an organization embrace an automation program that can benefit the entire organization? One of the fortunate outcomes of these workshops is that when we get representation from different teams, those conversations can be started. In somewhat of a predictable phenomenon, giving a mix of IT engineers problems to solve inspires them to work together. Ideas start to emerge and maybe the tools would be different, but could the organization benefit from things such as a common version control strategy? Could one team's experience with building pipelines benefit another team that is just beginning? We hope that these workshops begin these conversations between those silos.
How we help clients achieve their automation goals
WWT has experience in helping our customers navigate these complex topics. We have world-class automation engineers who can work with customer automation engineers to deploy solutions to solve complex problems.
We can also help in the training and skills development. We can perform skills assessments of organizations to help set that skills development strategy. We can do automation mentoring, which helps teams navigate getting their automation development projects off the ground. We also have many opportunities on our digital platform for IT engineers to get hands-on experience with automation topics. We do periodic webinars showcasing approaches to automation, with lessons learned from our development and delivery experience. We present at industry events. And we host our own automation and programmability meetup that contributes to the global community of automation learners. WWT possesses the skills and thought leadership to help organizations of all sizes adapt and grow into the automation engineering mindset.