Open First

This content is provided by Red Hat.

Automation adoptions are a journey. It’s not just a matter of hiring a vendor to come in, install the technologies, and then leave. The greater part of the journey involves mentoring employees so that they understand not only how to use automation, but when to use it. It requires acceptance and collaboration across the enterprise and understanding from employees who might fear being automated out of a job. The organization has to learn to own its automation processes in order to even begin.

A law enforcement organization recently went through that kind of journey with Red Hat.

“We were able to come into their organization and partner with them in adopting automation technologies,” said Ryan Bontreger, senior consultant at Red Hat, “We … completely changed the way that they do business, changing turnarounds from two weeks on a particular task that they had to do regularly … to a matter of hours.”

Before Red Hat got involved, there were two groups working in the same area, but they couldn’t have operated more differently. The first group was constantly looking to build and deploy modern technologies, while the second group was maintaining legacy servers and was more deliberate about their pacing. It created an us-versus-them environment, and the two groups had rarely, if ever, even been in the same room.

“It’s a typical battle you see in a lot of organizations where you have one side that’s moving extremely fast and then one side that’s not used to moving so fast. And so it’s always ‘well, if they do this, it’s going to hurt us, or if we do this, it’s going to hurt them,” Bontreger said, “We got them in the same room, talking it out, just getting that communication flow going. And it was really just getting those groups together and letting them earn trust between each other. It was key to them being successful with automation.”

That was the first phase of the journey: discovering the problem and getting on the same page. Then came the technologies.

Before Red Hat arrived, they would manually deploy a large platform every few weeks. They would build the virtual machine, connect the third-party software repositories, and deploy their applications.

“Essentially a new requirement would come in and they would go through the same manual process over and over and over again. So what we’ve done with the automation adoption journey, is essentially teach them how to fish,” said Jonny Rickard, an architect at Red Hat, “So we’d go in, and in the first couple of applications, we sit down with them, and we’re really kind of driving. And then you graduate to this next phase, where they’re driving and we’re sitting shotgun, and debugging together. And then really, towards the end, it’s them writing all the Ansible or writing all the automation themselves.”

This phased approach also helped to quickly reveal the full extent of the problem, as well as the depths of the communication gaps between the two teams. It also helped those teams learn to collaborate in order to build the foundations of their own success.

“By the end of it, we’re being surprised by the automation that they were doing,” Rickard said. “They can start doing things without even telling us and it’s theirs. We didn’t make something for us, leave and then it falls apart. They had taken over by the time we were gone.”  These efforts extended far beyond the initial project scope.  What was intended initially, was automation to support the next-generation infrastructure.  However, within a few months, the team maintaining legacy infrastructure joined in, as well as several different application, network, and security groups, all creating their own automation to reduce their turnaround time for everyday tasks.  “No one likes to be the team everyone’s waiting on”, Bontreger states. “When one team speeds up, others will follow suit.”

The effort took commitment from everyone involved. Bontreger said, it was an important step forward when the Red Hat team managed to engage the most skeptical person.This person had developed his own type of automation via perl scripts, but it didn’t scale well. Being the creator and owner, he was subject to a constant barrage of requests, leaving him swamped with work that prevented him from doing the work that he wanted to do; like adding additional features or upgrades to the infrastructure, or improving processes.  At first, he was concerned about automation affecting his performance because he was having to learn something new. As he started picking it up, the scalability, flexibility and freedom to branch out into new territories eventually won him over.

“I’d even say that he’s now one of our biggest supporters of using Ansible. Just because it gave him the opportunity to be a leader in a new area,” Bontreger said. “Bringing in automation, he could either hold on to his smaller kingdom or he could advance and move up and be a leader in this new area. And I think he saw it that way.”

That’s exactly the kind of commitment and ownership of the processes that Red Hat is trying to foster in its automation journeys. Because ultimately, Red Hat is just the guide.

“We can’t make the trip for you. We can bring you along,” Bontreger said, “We can show you the way but it requires the customer to be part of it. We can’t sit in a corner and make it happen without your help.”

For more information on Red Hat’s Automation adoption journey, view a Red Hat Summit virtual event on Adventures with Ansible: The Automation Journey.