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, then leave. The greater part of the journey involves mentoring employees so that they understand not only how to use automation, but when. It requires buy-in and collaboration across the enterprise, from employees who may fear being automated out of a job. The organization has to learn to own it in order to begin streamlining its processes.
That’s the journey a law enforcement organization recently went through 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 basically just completely changed the way that they do business, changing turnarounds from two weeks on a particular test that they had to do regularly, for an example, to a matter of hours.”
Before Red Hat got involved, there were two organizations under the same umbrella, but they couldn’t have operated more differently. The first group was constantly looking to build and deploy next generation technologies, while the second group was maintaining legacy servers and was much more deliberate about their pacing. It created an “us vs. them” environment, and as is often the case in situations like this, 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.
Prior to Red Hat arriving, they would deploy a large platform by hand every couple of weeks. They would build the virtual machine, then connect the third-party software repositories.
“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 is with the automation adoption journey, what we did 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, we’re 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 early on to reveal the fullest 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’re 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 it falls apart. They had taken over by the time we were gone.”
That took buy-in from everyone involved. Bontreger said it was an important step forward when Red Hat managed to convert its biggest naysayer. This person had essentially cornered the market within the organization on Perl scripts. On the one hand, he’d guaranteed himself job security because he was the only one doing this, but on the other hand, he was always swamped, and never got the chance to do anything else. He was concerned at first about automation taking that security away from him, but the scalability, flexibility and freedom to branch out into new territories eventually won him over.
“I’d even say that he’s one of our biggest supporters now 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 small little 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 buy-in and ownership of the processes that Red Hat is trying to foster in its automation journeys. Because ultimately, Red Hat is just the guide on these journeys.
“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.”