Every so often I get the chance to chat with Red Hat CEO Jim Whitehurst. When we spoke earlier this month, the open source company's quarterly financial results had just come out, but one of the reasons I enjoy our conversations is that they somehow manage to focus on the big-picture trends affecting the technology industry, not the momentary forces of any particular company — including his company.
See also: Red Hat CEO addresses big data's chicken-and-egg question
This time, we delved into the increasing importance of developers in IT departments. "In Europe last week," Whitehurst told me, "I had conversations with CIOs and it was all about DevOps, agile, and continuous development like I've never heard before." For IT leaders, Whitehurst said, the key conversations are moving from infrastructure to "how do I develop apps more quickly?" That’s a huge sea change in CIO thinking.
Infrastructure = cost/development = revenue
According to Whitehurst, there's a simple reason for the shift. Infrastructure is a cost center, while the apps those developers create can actually make money. For CIOs, he explained, "Infrastructure is 100% cost-driven"; there's no real upside. But if they double the productivity of their developers, that can grow revenues and the bottom line. If you can make development 25% faster, that will more than justify cutting 50% from the infrastructure. "That's really where the value is," Whitehurst declared. "That's where CIOs SHOULD be focusing."
The question, of course, is how IT organizations can encourage and enable those productivity gains. DevOps is often held out as a solution, but how does a big IT organization go about joining the dev side with the ops side?
Should it be based around the line of business, Whitehurst wondered, or is simple co-location of the two sides enough to reap the benefits? What technology tools are required? And what about reconciling the very different processes and cultures of development and operations?
Dev don’t know ops
"CIOs don't always recognize how little dev knows ops, and how different they are," Whitehurst cautioned. For instance, when selling OpenShift, "we sometimes get dev and ops into a room and they have never met each other! It’s just amazing." And yet if you picked five random devs and five random ops workers and lined them up, he added, those CIOs said they could identify which group was which with 90% confidence. They look different, they dress different, they act different, they drink different drinks.
That’s why Whitehurst advises IT departments to "start thinking about culture now and worry about infrastructure later."
"Figure out how to connect dev to ops, and get the right operational rhythm going," he said. "The tech comes later." Whether the DevOps team chooses Maven or Jenkins is "something that gets decided later, three levels down the organization."
Oh, and one more thing. "A massive re-org is not the way to start," Whitehurst warned. "That causes more harm than good." Instead of changing the way you do development across the board, start with a few projects for one team. "Wall off this group and figure it out there." Then take the lessons learned and expand to three to four projects, then to 10 to 15 projects. Finally, Whitehurst said that there will still be some projects where DevOps is not indicated, where the six-month waterfall development approach is fine.
Does Whitehurst go far enough?
From my perspective, those waterfall projects will likely become fewer and fewer over time. The way I see it, the battle for the soul of IT is over and the developers have already won — even if not everyone knows it yet. It's not that there's no ongoing role for ops and infrastructure. They will always be essential. But more and more, it's the developers who are now driving the bus, determining where IT is headed and what constitutes success and failure. That's the real meaning of the concerns Whitehurst hears from the CIOs he talks to.
Additional resource: Whitehurst recommended The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win, by Gene Kim, Kevin Behr, and George Spafford.