This content is provided by Red Hat

When an organization makes the change to DevOps, it can be easy to get caught up by the promise of shiny new technological solutions, by buzzwords like automation and cloud. But while these are integral parts of the practice, and rightfully exciting to an organization used to slower, more traditional forms of software development and infrastructure management, it’s important not to let them overshadow the most important parts of DevOps: the people and the processes.

“The technology is kind of the sideshow; this whole DevOps thing is really a cultural evolution,” said Ian Tewksbury, senior architect at Red Hat. “And the hard part is the people and process transformation. And, yeah, sure, we can help you with your technology, and that’s fun and all. But the thing that is really going to give you the value is that we bring our culture with us, not just our technology, and teach you how to do DevOps by operating how we operate when we’re at home, and showing you how it works on a day to day basis. It’s embedding you in the culture, by bringing it with us.”

Traditional software development happens in silos. When you start you may have an application development team, a security team, an operations team. Sometimes these teams aren’t communicating enough with the others, and that causes friction. Developers get frustrated because operations doesn’t have the infrastructure spun up, operations is getting adversarial with the security team because they’re making it hard to automate the infrastructure, and everyone loses sight of the common goal, the organization delivering value.
“So Red Hat can come in as that third party and realize we’re all trying to bring this value to your organization,” Tewksbury said. “And then start being the glue between those organizations to bring everyone to the same table, create those shared goals, that shared team meaning, and break down those barriers.”

They do this by getting everyone on board with the goals and the process, from the C-level executives down to the “hands-on-keyboards,” Tewksbury said. Red Hat’s consultants operate as a bridge between these tiers, ensuring the operators understand the vision of the executives, while the CIO or the CTO is hearing the pain points from the technical people.

Many times, Tewksbury said, the operations lead, the development lead and the continuous integrations lead have never even been in the same room together. So that’s often the first step, getting these people together to share their goals.

“But what’s getting in their way is ingrained organizational process,” Tewksbury said. “So especially in the government space, you can end up with a great group of people where you got a government CIO or CTO who really wants to do this transformation. Maybe they’ve even got all their middle managers on board, and even got a majority of their hands-on-keyboard people on board with changing the way they do things. Buy they’ve got policies on the books, and they might even have congressional oversight that says, ‘well, here is the way thou shalt do this.’ And they’ve gotten stuck on ‘well, how do we actually do this transformation, if all of this existing procedure and policy says we have to do it the current way?’”

That’s where Red Hat’s architects spend most of their time, Tewksbury said. There’s always some kind of process or procedure to change these policy hang ups. But it takes time, with the various groups sitting down and talking with one another, to find out what those are and to hash out how to move forward with them. What allows the previous silos to come together to work through those tough problems is the shared meaning.

The other major challenge is training. DevOps requires employees to learn entirely new skill sets from what they may have learned in school or on the job.

“From a technical and tactical standpoint, the biggest thing we run into is your traditional Ops Linux administrator was not trained in the software development lifecycle skillset,” Tewksbury said. “So whatever they went to school for, or however they learned on the job did not include source control, documentation, and moving from ‘I wrote this awesome Python or bash script’ to ‘Well, how do you source control that script and share it with others,’ let alone turning it into something fancy, like an Ansible script? How do you make these things reusable, so it’s not just sitting on Sally’s Unix machine? It’s sitting in a source controlled space that goes to peer review.”

Half the job, Tewksbury said, is helping traditional Linux administrators understand that he’s not turning them into software developers; they’ve always been software developers, and just didn’t know it. And the reverse is true: Developers have to learn the operations side of the house, and understand their concerns. Once they understand that, they’re not only ready to start taking on the culture of DevOps, they find they are already in the middle of doing it. It’s a continuous journey, not a destination.

“The key to anything in this realm is the technology is cool and nifty and shiny and fun, and it can help solve problems, but technology by itself does not solve problems. People using policy and procedure effectively along with technology solve problems,” Tewksbury said. “You need to put your people at the forefront of any conversation to have success with any of these initiatives.”

Copyright © 2024 Federal News Network. All rights reserved. This website is not intended for users located within the European Economic Area.