Accelerating Software Delivery

Why is there a divide between Dev and Ops?

This is part two of a five part series where we will look at DevOps and the solutions that can be gained by its implementation. 

For decades, Development and Operations organizations have been divided. This gulf exists for one key reason: Development’s mission and focus is creating value by producing change in response to customer and market requirements., yet Operation’s mission and focus is creating value by keeping applications and services running reliably so that customers can depend on them. Unfortunately, with traditional software development and delivery methods, a higher change frequency often directly correlates to a higher risk to application reliability.

Cultural differences regarding change

While it’s dangerous to engage in broad stereotypes, it’s fair to say that Dev tends to be more risk-taking while Ops is more risk-averse. After all, the Dev team is paid to create change and the Ops team is paid to keep the enterprise running.

Through the development of Agile and lean software development techniques, Dev has discovered that smaller and more frequent releases are better for producing higher quality software which is more likely to meet customer expectations and needs. Dev has proven that higher frequency releases leads to meeting their goal of creating customer value.

Meanwhile, experiences in software delivery have made Ops teams all too aware that the majority of downtime happens as an unintended side effect of making changes to software. In response, Ops has developed many mechanisms to guard the gates to software changes, such as heavy change management and encouraging fewer releases.

The technology divide – process and tools

Driven by the desire for heightened business dexterity, many Dev organizations have either already made the transition to Agile practices, or are seriously considering this type of conversion. Agile’s primary goals include smaller releases, more frequent delivery of working software, and a dramatically shorter time to market. In order to attain these ambitions, Dev tools have been growing more sophisticated, with heavy emphasis on boosting development and testing speed as well as improving collaboration among teams. The evolution of Dev tools is enabling software to be produced and delivered at an ever increasing pace.

On the Ops side, Dev’s augmented delivery pace has led to an increased demand for system resources. Ops tools have also grown in their sophistication to meet these needs. By automating system configuration, virtualizing entire software stacks, and enabling resources on demand via the cloud, Ops has evolved their tools and processes to assist the delivery of resources faster and more consistently. Yet despite all the enhanced efficiencies supplied by modern Dev and Ops tools, it’s still difficult to deploy software in a consistent, repeatable, and reliable manner. To bridge this chasm, the Dev and Ops teams must collaborate much more than before. This newfound emphasis on coordination is driving the move towards DevOps.

Come back next week for the third installment of the 5 week series entitled Why is the Migration to DevOps Happening Now.

 

1 Comment

  1. Panama says:

    Now let me give you another reason why Developers should take responsibility for the application in production. Who is better able to find the root cause of performance problems than the team that wrote the code? Let’s say the Operations team is alerted, either by a performance monitoring tool or by the inevitable angry phone call from the business people, that an application’s performance is lagging. What can the typical operations staffer do with that information? If they are extremely lucky they will be able to isolate the cause of the problem to some piece of failing infrastructure. Frankly that is relatively rare. Usually the various infrastructure monitoring tools Ops uses are showing all “green lights.” More often than not, the problem lies inside the application. Who knows more about what is happening inside that VM than the development team? Most ops people are not developers, cannot read code and would not be able to track down a problem whose root cause was buried within the application layer. Why have a middle man in operations get alerted simply so he can turn the problem over to the dev team anyway? Just have the developers get the alerts and jump on the problem sooner! If it’s their code that is the problem they should be the ones remediating the problem. The secondary consequence of this system is that developers become a bit more diligent about the code they push into production, knowing they have to live with the results.

Leave a comment