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 develops 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 conflictThere'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.
Seeing the bigger pictureSo if devops alone cannot drive agility in a large, complex organization, what can? As with metrics -- where you must measure what matters, not simply what is measurable -- to drive agility, you need to focus your efforts on where you can get the most business value from time to market rather than where agility is easiest to create.
Start with the biggest business need for improved time to market. Think in terms of customer requirements and work backward. Get creative with technical design, process design, and organizational design.
Very likely, in order to become more agile, you will need to change your technical framework to make it flexible enough to support an agile delivery model. Agility is not just about process; it's about people and technology. Agile means getting out of the box and figuring out how to impart value to your stakeholders as quickly as possible. This requires setting aside historical software development lifecycle models where appropriate. In so doing, of course, you can't afford to neglect quality and sustainability in what is being delivered.
Devops started because operations and development staffers recognized that their organizational model was not working. The basic idea is worthy. But despite marketers' efforts to adopt the term, devops is not a magic pill to cure all of our organizational ills.
Just as with weight loss, only hard work and perseverance can win out in the end. In order to free our organizations of the extra pounds of siloed thinking, which bog them down as they attempt to be agile, we must fundamentally change the ways in which we operate and do our own hard work as leaders. We have to align our organizations around the unified purpose of quality, sustainability, and time to market.
Please join me in banishing siloed IT to the history books. Together we can create far greater value for the business much faster -- and make execution much easier and more fulfilling for our employees. The way to achieve this is by exploiting our most powerful and influential tool: our leadership
This article, "To make IT 'agile,' devops is not enough," was originally published at InfoWorld.com. Follow the latest developments in business technology news and get a digest of the key stories each day in the InfoWorld Daily newsletter. For the latest developments in business technology news, follow InfoWorld.com on Twitter.
This story, "To make IT 'agile,' devops is not enough" was originally published by InfoWorld.