DevOps - Part I 

We have seen organizations use agile methodologies to speed up their software delivery by blurring the lines between business and IT development. While this has brought immense improvements to IT teams in particular, other departments are still arguing that software development takes too much time and barely moves the needle. As ironic as it sounds: both are right – depending, of course, on your point of view. But how is this possible? In this and the following article, we look forward to addressing these issues by focusing on DevOps, its overall impact and its conceptual background.

One of the most challenging things about this topic is acknowledging that we have improved the process of creating value, but not the process of delivering it. In other words, while we can design and develop software much faster than before, it still takes a lot of time to deliver the right quality to the client.

That is why DevOps takes a big-picture view of the entire life cycle of software development as one system from start to finish. It starts with an idea that is born as a business hypothesis, then turned into software by a development team and finally rolled out to deliver value to the customer. A piece of software cannot generate meaningful value until it runs in a productive state and can be accessed by the customer. The way to achieve this is to combine the capabilities of IT development and IT operations into a single organizational entity that will ideate, develop, test, deploy and operate software for their client.

In order to improve the value delivery chain, here at Deloitte we encourage a holistic approach that encompasses the four areas "Culture & People", "Technology", "Processes" and "Governance". It is certainly still possible to produce positive results if you only consider a subset of the implications in a DevOps implementation. To fully leverage the potential of DevOps, however, it is essential to include all of the four areas. This article takes a closer look at "Governance" and "Processes", with the areas "Culture & People" and "Technology" addressed in the second installment.

Governance

At Deloitte, we recommend organizations start by investigating how well their operating model reflects their value delivery chain and to what extent they have key DevOps capabilities. Another central question is whether the operating model is keeping the organization from moving forward in a more agile direction? Defining key design principles to act as the north star throughout the transformational journey is therefore strongly advised. These design principles should include, but are not limited to, the following aspects:

• End-to-end responsibilities 
• Product-centricity 
• Customer orientation 
• Co-location (within the teams as well as with the customer, where possible) 
• Automate everything you can 

Besides establishing design principles, DevOps governance is focused on continuous improvement of the organization and their products. That is why Deloitte recommends starting small and defining a functionality that you can release nearly on demand. This helps the team become more accountable, moving seamlessly into end-to-end responsibility and increasing buy-in for the change within the team.

From a micro-perspective of the Governance area, this is the point at which the requirements towards team structure start to change. Moving from a silo mentality to cross-functional development and then on to agile development, DevOps will need a range of skills and capabilities in IT operations. To fully leverage the potential of DevOps, in other words, we advise building teams that include at least the following roles:

• Product Owner – assumes responsibility for the team’s works by prioritizing the most important features to develop or operate 
• Solution Architect – mainly responsible for the solution architecture as well as ensuring the solution architecture fits into the overall enterprise architecture 
• Developer / Tester – mainly responsible for the development and quality assurance of the solution 
• Operations Specialist – mainly responsible for non-functional requirements and the operation of the software 
• Additional Expert – depending on your organization, you might need additional experts on your team to achieve your objectives – this could be UI designers, legal experts, mathematicians, etc. 

The goal is clear: organizations should aim for a setup where responsibilities are shared across the team, enabling them to not only build a solution, but also run it. This makes light work of handovers and shortens lead times and feedback cycles, because the team responsible for a software operation will receive direct feedback.

When it comes to transforming your company into a DevOps-ready organization, it is good practice to start small, restructuring one or a few teams first and then scaling up. This allows you to incorporate organization-specific insights gained in the initial team transformation(s) into your overall target organization.

You build it. You run it.

Processes

The goal of DevOps is to identify and remove obstacles in the value delivery chain by realigning processes and operations that have traditionally been assigned to separate stakeholders. This realignment aims to increase the overall flow through the software development lifecycle and to enhance the quality of results achieved in the system:

• Continuous Integration – By integrating every code change (new features, bug fixes and configuration changes) into the working solution automatically, you can obtain instant feedback about the change. This allows you to better understand whether the code is still working as expected and how the change has affected the work of others. 
• Continuous Delivery and Continuous Deployment – To respond quickly to changes and market needs, it is essential to have a fast, secure and reliable way to deploy your changes in production. Continuous Delivery is a concept that allows you to deploy any successfully tested build of your application on demand by automating your entire deployment process. Continuous Deployment takes this one step further and automatically releases any successfully tested build to production without any manual intervention. 
• Continuous Testing – By automating the integration and deployment of software changes, the process of manually testing those changes can become a new bottleneck and potentially take weeks to complete. That is why it is so crucial to automate testing and integrate it into the delivery pipeline. When you shorten the feedback loop, developers receive instant feedback on their changes and gain confidence that they did not introduce any bugs that could potentially disrupt the service. We recommend balancing effort and reward using a testing pyramid with a large base of automated unit tests at the bottom and a slightly smaller test on higher abstraction levels, culminating in manual tests at the top of the pyramid only where necessary. 
• Proactive Monitoring – In order to enforce a stable system, you will need to subject all phases of your development process to a rigorous monitoring system, starting with the first line of code in your development and not ending until your system goes live. Developers rely on live telemetry from the software running in production to shorten feedback loops once again and identify incidents as they occur, improving the overall quality of the system. It is important to carefully consider the metrics that are most relevant to the software package’s goal in terms of business, application and infrastructure; too many metrics will drown out the important information. Incorporating advanced statistical analysis and machine learning applications will help gain more valuable insights into the monitoring data. When a production incident occurs, a blameless post mortem will enable the team to learn from the experience and adjust the monitoring system accordingly. 
• Built-in Security – In an effort to build secure and reliable software, the team must ensure that security controls are integrated in the software development life cycle and not added on top of a finished software product as an afterthought. Right from the start, security should be seen as an integral element to build into the software; development and security teams should be engaged as early in the life cycle as possible. It is also key to include as much security testing as possible in the delivery pipeline to provide developers more feedback on the behavior of their software. 

In addition to these key processes that will be affected by a DevOps implementation, other areas will come into focus as bottlenecks in the software development life cycle, e.g., Release and Change Management as an approval and review process for deployed changes. That is why it is so important to see DevOps not as a goal, but as a journey throughout you will encounter – and remove – bottlenecks in the software development life cycle.

This article makes clear that there is much more to DevOps than just technology in terms of Governance and Processes. In the second part of this article, we will take a closer look at “Culture & People” as well as “Technology” issues in DevOps transformation to sum up our perspective and show that DevOps is about more than just technology.