Picture a systems administrator in a traditional IT organization, with clearly delineated boundaries between their IT ops peers and the app developers. They've always viewed the "devs" as undisciplined, creative hippies who know nothing—and care little—about what it takes to keep production systems up and running.
The sysadmin and their brethren, such as network engineers and database administrators, rarely if ever communicate with the developers, let alone collaborate with or trust them. These developers are the ones who—in the view of the ops people—throw half-baked applications over the dividing wall and go on their merry way. The IT ops folks then have to methodically whip those applications into shape so they can be properly and securely deployed in their production environments.
Changing the way people think
One day, the earth shakes. The business chiefs want applications and web services to be developed, updated, and deployed in a dramatically frequent and faster manner, because that's what competitors are doing and what customers expect.
Soon, word comes down from the IT honchos that the dividing wall between operations and development must come down. As a result, the sysadmin's people and those development employees will be expected to work together in tandem at every stage of each application or web service's lifecycle, from conception and planning to production deployment.
And this plan, which our hypothetical sysadmin considers pure lunacy, even has a name—DevOps—that underscores the meshing of "development" and "operations." The horror!
So how is this sysadmin supposed to adapt to this new world order? How are they supposed to not only keep their job but also manage to thrive?
Making sense of IT ops
For starters, if the term DevOps calls up the word "devastation," the sysadmin should attempt a mindset shift and instead hear "opportunity."
That's because when an IT organization adopts DevOps in a successful manner, the value of IT operations staff can skyrocket as they move to a more prominent position where their input and work is closer and more important to the business.
And a DevOps transformation of IT can also improve job satisfaction for operations staff because DevOps requires automating many processes that have traditionally been done manually, freeing up these workers to do more valuable, strategic work.
"A lot of IT folks in the trenches see this as a challenge to their jobs, that by automating everything they're automating themselves out of a job," says Jamie Begin, CEO of RightBrain Networks, a DevOps consultancy in Michigan.
"But that's not the case at all. My counter is that this is a huge opportunity. It's a net win if you're an IT guy. Who likes getting woken up in the middle of the night to go and change a hard drive?" says Begin, who held both operations and development jobs before founding RightBrain Networks about seven years ago.
Once the DevOps mandate is issued, IT operations people who dig in their heels and flatly refuse to participate in the process will put themselves in a precarious position. They'll be seen as an impediment to DevOps success, whose key lies in the creation of a culture of constant communication, collaboration, trust, and shared responsibility for common goals.
That's why for DevOps projects, companies pick and choose people from both sides who have the attitude and aptitude to work together in an IT organization where the gates have been eliminated, says Ronni Colville, a VP and distinguished analyst at Gartner.
"When we don't see that kind of Kumbaya [disposition], ops is relegated to a very minimalist position," Colville says.
Embracing new views on DevOps
Operations people must also change their traditional mindsets in various other ways. For example, they must be more willing to try new approaches and to fail so that they can learn and improve, according to Forrester Research.
"Fear of failure is often an inhibitor of innovation. But creating an environment without blame where team members can explore ideas reduces this fear," Forrester analysts wrote in the report "Break Your Bad DevOps Habits," published in March.
Among the other recommendations in the Forrester report: operations professionals should embrace the new responsibilities presented to them by a DevOps reorganization, and they should explore new measurement and release automation tools, so there's "a single source of truth" everyone can refer to and act upon.
Another tip: proactively seek out your company's developers, get to know them, and build bridges, says Josh Johnson, a senior software engineer for Adzerk, a Durham, North Carolina maker of cloud-based ad-management software.
"The best advice I can give to operations folks is to go hang out with the developers. Be friends with them. Insert yourself into their meetings. Identify and remedy any bad blood. Be the bigger person. Teach them what you know. Foster mutual respect. Take time to learn the languages and platforms they're using," Johnson says.
That way, operations staff can also be clear about their requirements while keeping the communication channels open and positive.
Johnson, who in previous jobs suffered through several misguided DevOps implementation attempts and has written about those bad experiences on his blog, warns that above all, operations workers should avoid getting left out of the conversation. If that happens, they end up having to maintain both the general infrastructure for the organization and all the new tooling that a DevOps implementation brings in.
"Often that means stretching already thin resources further, especially if the DevOps tools are very foreign to the operations team. Or worse, it can mean supporting systems maintained by others that aren't built to operational standards, which is tedious and dangerous," Johnson says.
Managing the DevOps shift
Dan Ackerson, engineering support coach at Stylight in Munich, Germany, says that a successful DevOps implementation should result in the erasure of "devs" and "ops" descriptors for team members.
"Being an 'IT ops staffer' already indicates failure. Until the sysadmin is sitting with the 'website search' team...going out to lunch with the Ruby devs and UX designers, 'DevOps' isn't in place," Ackerson says.
Ackerson also warns that everyone involved in a DevOps transformation should be patient with themselves and others because the process takes time and isn't easy, and success is far from guaranteed.
"Team performance and output will initially drop as the new team adjusts to the input of the new colleague and helping them understand the how and why of feature development," he says. "You must be patient and give them time to learn how to work together. The boost you get in speed and quality after this is immeasurable."
While most of the DevOps emphasis has been put on the development part, operations teams are starting to proactively get more involved, says Stephen Elliot, a research VP at IDC.
"Yes, a lot of the conversation right now focuses on the app dev side, but we're seeing more ops teams get more involved and become aware of what this is all about," he says.
Starting the DevOps conversation
DevOps is prompting CIOs to question whether IT operations are what they've always been, or whether they should be conceived differently, along with the way they now drive business value, Elliot says.
"So I expect more IT ops folks to say, 'I want to have a say in how we're going to look and what we'll be doing.' They'll get more involved in this DevOps theme," Elliot explains.
Ultimately, both "devs" and "ops" need to develop mutual trust, and make that the prevailing culture of work. Without that, no amount of new tools and infrastructure will yield a true DevOps way of developing, testing, and deploying software rapidly and frequently, according to Adzerk's Johnson.
"Historically, the divisions between systems engineers and software engineers have caused some disillusionment between the groups. Developers see system admins and operations policy as barriers to getting their work done. System admins see developers as disruptive to the management of servers and infrastructure in a stable and secure way," he says.
Disillusionment creates distrust, which leads to power struggles and causes delays in code deployments.
"It comes down to fixing the cultural dichotomy that has emerged from many years of separation," Johnson says. "If you 'do DevOps' but never build trust, you can have the most sophisticated delivery pipeline ever conceived and still fail."
Keep learning
Choose the right ESM tool for your needs. Get up to speed with the our Buyer's Guide to Enterprise Service Management Tools
What will the next generation of enterprise service management tools look like? TechBeacon's Guide to Optimizing Enterprise Service Management offers the insights.
Discover more about IT Operations Monitoring with TechBeacon's Guide.
What's the best way to get your robotic process automation project off the ground? Find out how to choose the right tools—and the right project.
Ready to advance up the IT career ladder? TechBeacon's Careers Topic Center provides expert advice you need to prepare for your next move.
