Devops is all the rage. If you believe what you read in the tech press, devops could even be IT's saving grace. And predictably, as with most hot IT buzzwords, devops is now being used to sell everything from consulting services to cloud services to software.
But devops is not for sale. In fact, it can't be sold, because it's not a product or a service. It's a leadership thing.
[ Learn how to work smarter, not harder with InfoWorld's roundup of all the tips and trends programmers need to know in the Developers' Survival Guide. Download the PDF today! | Sign up for InfoWorld TechBrief, the best way to get the latest tech news and analysis every morning. | Don't want another newsletter? Then go to infoworld.com/techbrief, where you'll always find the most recent edition. Be sure to bookmark it. ]
Devops started as a bottom-up initiative to get development and operations personnel to work closer together in support of a more agile delivery cycle. Agile development yields better outcomes, but it also increases the burden on operations, which must keep pace with the increased volume of change agility brings. The devops approach pushes development and operations teams to collaborate and fix the organizational issues that were forcing them apart.
The devops challenge can only be addressed by aligning an IT organization's culture and performance incentives around end-to-end quality, agility, and time to market. Ultimately, the organizational issues raised by devops go beyond simply bridging the gap between development and operations.
Getting past the conflict
There's a long history of IT contentiousness between development and operations organizations. Development sees operations as an impediment to getting projects out the door quickly. Operations sees development as not being attuned to its needs for quality, availability, and ease of operations.
To bridge the divide, devops proposes roles that span both sides, such as the release manager, along with general blandishments about greater communication and collaboration. Those approaches may work well in smaller or less complex organizations, but in IT organizations that must serve the global enterprise, they often fall short. Most large companies are built on legacy technology that tends to be fragile -- and agile and fragile mix about as well as oil and water.
The devops leadership issue can only be addressed by changing the culture from a siloed mindset to a quality and time-to-market mindset across all the functions that make up IT. This must be driven through strong CIO leadership. The CIO needs to align functional leaders' goals to reduce time to market, improve quality, and break down the siloed functional incentives of the past. A decade ago these functional silos clarified accountability and had their place in the slower-paced, waterfall world of IT. Today, thanks to the consumerization of IT and today's warp speed of change, these silos now stand squarely in the way of progress.
For example, delivery leaders need to be measured by production quality, whether that's code related or system related. They need a seat at the table when quality issues are at hand, and they need to be locked at the hip with the operations' functional owner. Quality cannot be an operations issue alone. Similarly, the operations leader needs to understand the business drivers and must be incented to support the delivery of business value quickly and cost-effectively. This cannot be solely a delivery issue. If these functional leaders' compensation hinges on end-to-end value and quality delivery, then their organizations will also feel the need to align with their functional partners.