Without business input, the business benefits of DevOps are elusive

To achieve the business benefits of DevOps, organizations must mend a cultural divide deeper than the one between developers and operations staff.

Better collaboration between development and operations teams isn't easy, and despite the business benefits of DevOps, some organizations that implement it unearth deeper divisions between IT and business units.

"There's always been a communication gap -- if not a wall -- between the business and IT," said Carlie Evano, senior manager of IT operations for a large cosmetics retailer.

This cultural divide often runs deep. Traditionally, business units and IT professionals work a world apart; marketing or sales professionals dream up a new initiative or product feature and present the proposal to management, who formally request that IT work its magic. Or worse, business leaders make unrealistic promises, ignorant of technical challenges.

Soon after Evano joined his current employer, his CTO asked him to begin a new project to bring voice over IP (VoIP) services to the company's retail stores right away.

"He had promised the board he'd save them $40,000 a month on telecom bills, and [he said] that I had to get it done now," Evano said. "That was a year and a half ago, and we're still working the project."

Despite the history of conflict and finger-pointing, some IT departments find proactive ways to work with business units. Adoption of DevOps principles has helped IT operations professionals better collaborate with developers, emphasizing communication and process management.

But, despite its name, DevOps shouldn't stop at improving collaboration between developers and operations staff. Some organizations find they need to bring developers and IT operations professionals to the table with business leaders and product owners, from concept to production. This trend to focus in on the business benefits of DevOps has earned clunky names such as DevOps Plus or BizDevOps.

After the frustrating VoIP project, Evano said his organization made progress in uniting IT and business leaders to head off communication problems and set realistic expectations. When product staff wanted to introduce a new customer loyalty program, stakeholders sat down with IT representatives to scope the project.

"So far, it's been the most flawless project since I started there," Evano said.

Deep divisions

Still, many organizations looking to modernize encounter challenges, and from all sides.

"We've already expected there's going to be some resistance to change," said Rory Barrett, assistant deputy director of information services for a government agency. "One of the things we've tried to do before and failed miserably is to get our customers to the table in an Agile process. I don't think we've prepared our business lines to understand what we need from them."

A collaborative process will be a change for many business units that are used to an IT development process where they document their requirements and toss the project over the wall.

At the root of the problem are the historical divides between IT, developers and the rest of the business. Business leaders and end users often do not understand the technical challenges required to provide IT services, while many IT professionals lack business or communication skills, and are sometimes viewed as outsiders. Even IT leaders suggest some of these stereotypes ring true.

"The people typically drawn to IT over the past 15 or 20 years, the vast majority of them are geek-type personalities, introverts. They like technology for technology's sake," said David Salbego, department head for infrastructure and operations at Argonne National Laboratory in Chicago. "That was good enough for 10 or 15 years, but it's not good enough going forward. The people who are going to be successful in IT have a deep understanding and caring of where the business is going."

But if IT has a bad rap, it's hard to press the reset button and just start working together.
David SalbegoArgonne National Laboratory

In the past, IT departments were neither seen nor heard until something went wrong -- and then they were blamed for outages. Today, it's no longer about simply keeping the lights on; staff well-suited to design and maintain reliable systems may find that their technical skills fall short of business expectations.

"It sounds easy," Salbego said. "But if IT has a bad rap, it's hard to press the reset button and just start working together."

IT leaders must prepare their staff for this transition to a collaborative model and reconsider the value of communication skills of staff that will interface with product groups and business leaders. To help navigate the change, Barrett said his CIO plans to bring in an organization change management instructor.

"I don't know if we're prepared to say, 'This is what we're going to need in the future from your skill set as a programmer,'" Barrett said.

The driving force behind this cultural shift is elevated business expectations. Historically, product business teams have been largely nontechnical people, but they have become more educated. In addition, tech-savvy employees demand more high-level IT services.

"Product teams have a stronger understanding of what development and operations should be capable of," said Chris Ciborowski, CEO and principal consultant at Nebulaworks, a DevOps and cloud consulting firm.

These teams are more aware of concepts like feature flags, or might request a rollout of different production versions of an app to certain locations or demographics. These capabilities highlight the business benefits of DevOps and can give product teams great insight into what works, as well as help drive new initiatives -- but these requests can challenge IT staff.

Where to start

Technologies and tools have helped spur more widespread adoption of DevOps principles. For example, containers can smooth the process of moving applications through the development, test and production pipeline. Application performance monitoring tools can provide business-level insight into app performance and correlate that information with configuration changes, or give IT a clearer view of an end user's application experience.

At its core, though, DevOps is about people and culture. While these tools can help give IT better insight into how the systems they manage affect the business, no tool can overcome cultural barriers to collaboration. The first task for an organization adopting DevOps principles across the business is to bring all of the parties to the table to educate and understand each other.

"DevOps means something different to everyone," Ciborowski said. "The first thing is to get everyone speaking a common language."

Nick Martin is executive editor for TechTarget's Modern Infrastructure e-zine, and former senior site editor for Contact him at [email protected].

Next Steps

Make a successful transition into BizDevOps

Reach BizDevOps with a digital transformation strategy

5 nontechnical metrics to measure DevOps success

Dig Deeper on DevOps Team Organization