DevOps has always been about removing bottlenecks from the software development life cycle (SDLC). In the early days of DevOps, the biggest bottleneck that attracted the most focus was infrastructure. Developers and operators worked closely together to automate infrastructure, both on-premise and cloud, and tried to address infrastructure and operational requirements earlier in the SDLC. The early days of DevOps was strongly focused on shifting infrastructure left.
DevOps has also always been about continuous learning. As enterprises big and small matured their processes and became proficient at automating infrastructure and build processes, they started to address the next bottleneck: testing and security. Instead of handing off builds to testers or scheduling security audits that often resulted in rework, they started shifting testing and security left. Many mature enterprises have now implemented automated tests, security scanning and analysis tools in their build process. Builds are forced to fail if various performance and regression tests fail or if security and coding standards do not receive an acceptable score from the code scanning processes. These advancements can lead to faster development, fewer meetings, higher productivity, and higher morale.
Organizations that have entered years three through five of their DevOps transformation often shift their focus from IT automation to IT transformation. They begin addressing the next level of bottlenecks: process, compliance, and support.
Shifting these bottlenecks left requires strong leadership because this is where significant shocks to organizational structures and culture occur.
At virtually any major DevOps event today, the conversation focuses largely on culture and leadership. Becoming a high performing organization is not a technology project. It is an exercise in leadership, organizational change management, and culture transformation. Any organization can automate infrastructure and IT processes. Very few enterprises seem to have the chops to undertake effective transformation.
Addressing transformational bottlenecks
Changing processes can be quite a challenge in most organizations. Many legacy processes were put in place over time due to a variety of reasons such as:
· Handoffs between organizational silos
· Lack of trust between silos
· A response to a painful event that happened years before
· A set of leading practices established in the days when deployments occurred only once or twice a year.
One example of the latter are software development review processes that often exist solely to compel developers or testers to meet a standard or adhere to a policy. These reviews are often held extremely late in the SDLC where there is little or no time to take corrective action.
As things shift left, legacy processes can create bottlenecks in the flow of work. Many legacy processes can be automated, performed in a different way, or even eliminated as we move to a world of automation, small change sets, and frequent deployments. Yet doing so is hard for a number of reasons, including:
· Resistance to change because people’s jobs are impacted
· Mismatched incentives between silos
· Lack of understanding of WIIFM (what’s in it for me)
· Disruption of ownership and organizational boundaries
Value stream mapping plays a vital role in identifying process bottlenecks and revealing potential business benefits of change to all stakeholders. Often, organizations can’t describe their end to end processes until all stakeholders are brought together to map out the value stream. Once everyone sees the entire value stream and where the bottlenecks are, they can then start thinking outside of their silos and looking at the system as a whole.
Shift Process Left
Optimizing legacy processes is key to agility. Automation by itself can only go so far. Process bottlenecks should be removed to improve the flow of work in process (WIP). Many processes are designed within organizational silos and add little or no value to the broader development process. As previously mentioned, these processes are often established as ways to enforce policies – for example, to review functionally before it gets to production. The problem with this approach is that it treats every change equally, regardless of the criticality of the change. In financial institutions, for example, this means that simple web page changes often go through the same rigor as a transaction processing system change.
To get around this, some companies are asking policymakers to define and own their policies, but leave implementation to the individual product teams so it doesn’t interrupt their flow. For example, a common change process involves filling out a series of tickets and holding various review meetings with many stakeholders. This often takes more time than the actual code change. The new thought process is to define the requirements for change management and allow the product team to streamline the process.
Moreover, a number of tasks can be automated, including enforcing architecture and security standards, updating a configuration management database (CMDB), and requesting infrastructure. But doing so requires the culture to change from a “we must check everything” mindset to one of “trust in your automation”. In a model of frequent deployments, people can only hold so many review meetings. Said another way, humans don’t scale in a continuous delivery model. Instead, enterprises should consider adopting a post mortem review of change management to determine whether the automation is still complying with the policies.
Shift Compliance Left
After making progress with process improvement, many enterprises can proceed to the next biggest bottleneck, which is often compliance. Taking a page out of the “shift process left” playbook, product teams can ask compliance teams to focus on identifying applicable regulatory and audit controls and requirements. Each product team can then design solutions to meet compliance and audit requirements and yet still support efficient product and service delivery.
Too often I see policy makers forcing suboptimal technology decisions on product teams. Policy makers tend to excel at policy management, not technology decision making. Technology decisions should be more focused on customer satisfaction and technology strategy, not policy. Policies are often nothing more than requirements which should be left to technologists to implement. Policy makers can still bless the technology decisions to ensure that the solutions satisfy the requirements, but they should not dictate the how.
Shift Support Left
There is also a movement to shift tier 1 through 3 support left. Historically, tier 1 support services have often been provided from a separate silo that may know very little, if anything about the actual products that customers are calling about. Those tier 1 resources typically troubleshoot and solve basic problems by following a decision tree. They farm out anything more complex to a tier 2 support group that has more product knowledge, tools, and access to developers, or tier 3 support group, who are typically the actual product developers or operations teams.
The new mindset is to move the issues closer to the people who know the product so there is less shuffling of tickets and meetings across silo organizations. Shifting support left in this way means creating a T shaped organization where the manager owns both development and operations - no more handoffs across organizational silos. This is a swarming model in which the operations team has all the necessary knowledge and tools to solve the issues and developers are embedded within the team to assist.
The Bottom Line
DevOps transformation focuses on how to become a high performing company. High performers often rely on tactics like systems thinking, value stream mapping, and organizational change management to transform their organization to be more capable of delivering in today’s business environment. We live in an age where speed to market is the new currency. We are asked to deliver more frequently, with higher quality and reliability than ever before. Legacy methods don’t apply anymore. Focusing only on automation is not enough. We must take a step back and think of the system as a whole. A culture of continuous learning, trust, and empowerment must be instilled.
Transformation is hard. It requires more than technical skills. It requires strong leadership. To be effective, middle management should be bought in and have the necessary skills to lead change. Enterprises that view DevOps as a bunch of engineers writing scripts are likely to be left in the dust. Those that instead see DevOps as business transformation and have the chops to execute their plan are more likely to leapfrog their competition.
As used in this document, “Deloitte” means Deloitte Consulting LLP, a subsidiary of Deloitte LLP. Please see www.deloitte.com/us/about for a detailed description of our legal structure. Certain services may not be available to attest clients under the rules and regulations of public accounting.
This publication contains general information only and Deloitte is not, by means of this publication, rendering accounting, business, financial, investment, legal, tax, or other professional advice or services. This publication is not a substitute for such professional advice or services, nor should it be used as a basis for any decision or action that may affect your business. Before making any decision or taking any action that may affect your business, you should consult a qualified professional advisor. Deloitte shall not be responsible for any loss sustained by any person who relies on this publication.