As enterprises digitize in an effort to keep pace with their customers, more leaders seek the holy grail of automation. Automation can help speed time to market and breed greater efficiency. Most companies, however, aren’t naturally inclined to automate their processes, even though 71% say they’re at least kicking the tires on automation.
Red Hat’s Nick Hopman, Vice President of Global Professional Services Practices, Solutions, and Offerings, sat down with me to talk through how organizations can best implement automation rather than just aspire to it.
SEE: An IT pro’s guide to robotic process automation (free PDF) (TechRepublic)
Four keys for automation
According to Hopman, Red Hat has settled on four key principles to help companies get started with automation:
Stand up an Automation Community of Practice: Establishing strong community leaders and a regular cadence of activities and incentivizing participation through rewards and recognition.
Create a common GIT-based repository for all automation code: Allowing different teams to use the same code for their diverse purposes allows teams to get off the ground faster.
Infrastructure as Code (IaC): Gets your teams and engineers to treat every single piece of infrastructure as something that can be configured via code, while removing human error from the process.
Treat automation as a product instead of a project: Allows your team to iteratively build the automation and release it faster.
While great, it’s less clear how organizations can effectively embrace these. For example, while almost certainly useful to treat infrastructure as code, that doesn’t come naturally to most. According to Hopman, you don’t need “most” to get started: “Individuals and teams have been automating processes far longer than enterprises have. The challenge lies in applying the culture of automation that might exist on a smaller level across an organization.”
SEE: Machine automation policy guidelines (TechRepublic Premium)
Spreading the good word
To get moving, organizations need to find ways to help those pockets of automation spread. Start by laying the groundwork of why it matters, Hopman said:
There’s a strong business case to be made for automation–improving security, increasing predictability, and efficiency of repetitive tasks. If you’re doing a task 10, 100, 1000 times, then automating it will free you up to do other projects, making the organization more efficient and allowing individuals to work on other projects that might take more creativity and innovation.
Once that vision is laid out, generating “widespread awareness” of the destination, the next step involves “breaking down the barriers between various groups,” thereby allowing those small pockets of automation culture to spread. When I asked about the best people to involve in a community of practice, Hopman was quick to suggest that you don’t want only the early adopters:
A mixture of people from the organization is best. You will need some true believer/early adopter types–the community has to start somewhere and these are the folks that can help recruit and self-mobilize. You need some experts to share what they know, what they have learned–their content is bait for others to join and further their knowledge. The CoP scales and includes more and more from the organization from there.
And, importantly, it really is about culture, not technology. As Hopman pointed out, “It’s not an on prem problem. Legacy infrastructure and mainframes don’t inhibit you from driving automation forward.” Sure, automation may fit best within more modern development practices, but this shouldn’t be the excuse that holds automation back. Culture is the real key to embracing automation.
Disclosure: I work for AWS, but nothing herein directly or indirectly relates to my work.