DevOps: Get Everyone in the Same Boat

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

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.