The business case for collaborative DevOps

Invisible Thread — Wed, 11 Jul 2012 22:18:57 GMT

The business case for collaborative DevOps

by ErikaHorrocks

There’s a lot of talk these days about DevOps, designing processes for coordinating software development teams with IT operations teams. The talk is being driven by companies challenged by a fast-moving market, an ever changing regulatory landscape, and transformational change. All companies today require agility in their business processes. While many companies limit the scope of DevOps to deployment automation, IBM takes a much broader view. DevOps is really about improved automation, integration, collaboration, and optimization of development and operations, the ultimate goal being improved business outcomes.

Startups vs. the established enterprise

Let’s begin by looking at DevOps in the different contexts of a small startup and an established enterprise. In a startup, the primary focus is on developing a new offering. Constant and small refinements of key business processes are the norm. The goal of developing the core business offering takes precedence over many operational activities. This is as it should be. The risk to the business is not in alienating established customers or compromising revenue streams; rather it is about defining a product and creating or validating a business model. The potential for failure during the development of new offerings forces startups to work quickly to achieve value.

By contrast, unless an established enterprise is going through a major business re-alignment, the company’s need to retain market share and protect revenue streams creates a different set of priorities. No doubt, the greatest threat to an established business is an inability or unwillingness to change. Introducing change to either technologies or practices poses risk. Though it is important to innovate regarding new product and service offerings, many enterprises have back office systems that are highly dependent on known inputs and outputs to pro-vide a smooth flow of financial and customer information. Even small changes can introduce potentially devastating impacts to revenue. This is why—along with regulatory requirements that impact large, established, businesses and markets—enterprise architecture and change control boards are prevalent in large established companies.

The hidden costs of competing interests

Some refer to DevOps as simply “bridging the gap” between development and operations. While at a very high level this is true, the real gaps that need to be bridged are the various disconnects between processes, measurements, technologies, and data. If we look at traditional organizational structure, we see that the VP of IT Operations and the VP of Development both typically report to the CIO. If the two teams are not talking to each other, then there is a problem.

While tension between two groups can be a good thing—and it is used extensively in research and development to help innovate faster—by providing your development and operations teams with incompatible metrics and different incentives, you are building a system designed to fail.

From a business perspective, the conflict in priorities and focus between development and operations can be thought of in terms of differing types of cost. For both teams, the cost is associated with a loss that is to be avoided. Development is focused on delivering new application code quickly; operations is focused on getting things right, and avoiding the costs (both direct and indirect) associated with failures. Balancing these two types of cost can be a problem, because the usually simple, bifurcated analysis fails to see a linkage between the two.

The concept of technical debt

This is where the concept of technical debt can be useful, because it offers a way for both sides to see a common, holistic cost structure. Technical debt essentially refers to the costs imposed on one organization by the actions of another. For example, if a development organization, in the interest of time, does not ensure the performance of a new or updated application, the costs of dealing with a performance problem at a later stage will primarily be carried by the operations organization. In an accounting sense, development has moved the cost of non-scalability off its own books and placed the cost of failure on the ledger of the operations group. Technical debt, therefore, isn’t just a question of organizational cost tracking, but an issue that impacts the business’s bottom line.

To adopt a unified approach to cost reduction, both organizations can use the notion of technical debt to develop a more mature approach to setting priorities. As partners, both the development and operations organizations must plan how to reduce costs both to the business—their original priority—and to their partner organization. For development, this means that as they deploy people, processes, and tools to reduce the cost associated with adopting business agility, they must minimize technical debt that would otherwise be passed to the operations group. In taking this approach to realizing business benefits, organizations can engage in a mature, business-focused collaboration that takes the DevOps discussion beyond simply a technology focus.

The long view on Collaborative DevOps: Three areas of benefit

We are witnessing this trend with many automation tool providers who focus on a single function that is 100 percent buzzword-compatible and will try to position their product as the full definition of the concept. In their mind, DevOps is only about deployment automation. While deployment automation is a key component of DevOps, it is not the entirety of DevOps.

IBM sees at least three key areas that need to be addressed for an enterprise to execute successfully in a Collaborative DevOps manner.

Build applications using collaborative incident management

Collaborative incident management aligns with agile development processes that are proven within the enterprise. When development and operations can both provide data to the right parties without the need for ad hoc reporting and meetings, then they can better focus on their specific roles and responsibilities.

Deploy and run applications collaboratively with enterprise architecture alignment

Enterprise architecture is about defining that path your business is taking, and understanding how the systems need to change in order to get you farther along that path. Enterprise architecture alignment, through repository linkage, addresses the operations team’s need to reduce risk associated with a production change.

Manage applications collaboratively through deployment planning and automation

As we’ve seen in the two prior areas of DevOps focus, we can significantly reduce risk while providing the business with needed changes if we can increase the collaboration between development and operations. Getting a common lexicon, common data, and improved access to information empowers both development and operations to better address the needs of the business while implementing change with a higher level of efficiency and effectiveness.

The growing interest in DevOps

Our customers have begun to show more interest in the idea of DevOps. Why? New methods for deploying software have enabled businesses to dynamically provision environments. We also see an increasing number of our customers leveraging the principles of agile development and starting to understand that their operational metrics are, at times, at odds with these practices. The clear value in reducing the cost and delays in development has caused the business to desire this same capability for production environments. Market forces are causing companies to increase the rate of change to their production environments. This increases risk for those who are not able to handle the necessary governance, discipline, and automation. Collaborative DevOps is one a powerful solution that can help address these concerns.

Read the full whitepaper here: http://ibm.co/OvkXdB

About the authors

Michael Rowe is a Business Strategist for IBM Rational where he has spent the last 4 years working across IBM helping define our DevOps strategy. In his 28 years in the IT industry he has worked across the full life cycle of application development, support, and operations across multiple industries.

Pete Marshall is a Business Strategist for IBM Tivoli Software and has recently been focused on working with Rational to jointly deliver DevOps solutions. Pete is just about to complete his 30th year in the IT