Successful DevOps initiatives have to include everyone, not just the Dev and Ops staffs, according to Interop ITX speakers.

James M. Connolly, Contributing Editor and Writer

May 25, 2017

4 Min Read
Rosalind Radcliffe, IBM

A few things about DevOps came into focus very quickly at last week's Interop ITX conference in Las Vegas:

  • There is plenty of interest in DevOps

  • A lot of companies are still at the "how-do-we-do-DevOps?" stage

  • Doing DevOps just in Dev and Ops teams isn't enough

Plenty of evidence of the first two points showed up in the first DevOps track session in the main Interop ITX program, when a standing-room crowd of 120 attendees listened to Rosalind Radcliffe, IBM's Chief Architect for DevOps for Enterprise Systems. Casual conversation among attendees in the room highlighted how many were just getting started with DevOps.

Then Radcliffe touched on Point Number 3, emphasizing that the DevOps team should embrace a wide range of participants: project managers, developers, enterprise architects, operations staff, product owners from business units, external vendors, auditors, domain experts, senior executives, and support staff.

I know I wasn't the only person in the room who was surprised when Radcliffe highlighted one example of how IBM itself has used DevOps internally. She described the benefits IBM has seen since it moved its CICS unit to a DevOps approach.

CICS? It's IBM's 50-year-old transaction system. I probably hadn't heard the term for several years. The CICS team adopted that DevOps approach in 2005, even before DevOps became a buzzword, and apparently it's working for them.

But I think it was Nathen Harvey of Chef Software who hammered home that DevOps has to reach far beyond Dev and Ops. "I hate the word DevOps," said Harvey during the InformationWeek IT Leadership Summit, "If you want a high velocity organization you can't just focus on two departments. It involves everyone."

As the week at Interop ITX progressed, the involvement of "everyone" was a regular theme in DevOps talks. You see, if the DevOps team does as the concept mandates, they will build a basic app that addresses the minimal needs of the business unit, test it, and move it into a production environment. Then over the course of weeks, months, or years they will continually enhance it by adding the infamous "bells and whistles" that users want and the changing nature of the business may demand. You continue the cycle of build, test, implement, and improve.

Of course, this whole DevOps process replaces the traditional "over the wall" methodology introduced back in the 1960s when the IT department was called "Data Processing." A business manager would request an application, a programmer or analyst would work out the specs, and six months or three years down the road the IT team would virtually toss the finished -- albeit flawed and outdated -- application back to the user department. Changes and improvements were possible, but probably a year away.

That old process is familiar to anyone who has wored in or with IT. DevOps promises to revolutionize product/application development.

However, having "everyone" involved means that everyone has to devote the time and attention to this cycle of continuous improvement. Business managers can't sit back for three years and complain that IT is slow or producing flawed software. Those business managers or product owners have to buy into the DevOps process and make the time to provide ongoing feedback. They have to become what amount to QA professionals, watching for bugs and business gaps. They have to be monitoring their own business needs and changing requirements, understanding how their own customers are changing the way they interact with the organization. They have to understand what technology can and can't do, and what it shouldn't do.

Those same business professionals have to be ready to apply the same characteristics of DevOps to their own business processes, reaching across department boundaries to their peers in finance, marketing, or any other group to keep processes in sync with tech changes. I'll argue that even the non-tech related processes and approaches within those business units could benefit from a DevOps-style approach.

Consider how frequently -- if ever -- marketing reassesses its best practices and assumptions, how often sales falls back on "it's the way we've always done it," or finance clings to outdated concepts and processes. Imagine how continuous improvement could help almost any department.

DevOps holds promise in how it can support a dynamic organization, but it's going to require work and adoption of new mindsets by one and all.

About the Author(s)

James M. Connolly

Contributing Editor and Writer

Jim Connolly is a versatile and experienced freelance technology journalist who has reported on IT trends for more than three decades. He was previously editorial director of InformationWeek and Network Computing, where he oversaw the day-to-day planning and editing on the sites. He has written about enterprise computing, data analytics, the PC revolution, the evolution of the Internet, networking, IT management, and the ongoing shift to cloud-based services and mobility. He has covered breaking industry news and has led teams focused on product reviews and technology trends. He has concentrated on serving the information needs of IT decision-makers in large organizations and has worked with those managers to help them learn from their peers and share their experiences in implementing leading-edge technologies through such publications as Computerworld. Jim also has helped to launch a technology-focused startup, as one of the founding editors at TechTarget, and has served as editor of an established news organization focused on technology startups at MassHighTech.

Never Miss a Beat: Get a snapshot of the issues affecting the IT industry straight to your inbox.

You May Also Like

More Insights