DevOps from A to Z
Enterprises should look at DevOps as a company-wide transformation, rather than just a means for facilitating digital transformation. In this article, Anders Wallgren, CTO at Electric Cloud, gives an overview of how to implement DevOps the right way.
More than a fad: DevOps drives business transformation
Organizations all over the world are making a big bet on DevOps as a foundational aspect of their goals to create a high-performance business through digital transformation. Themes like “architecture,” “business buy-in” and “the focus on people and leadership” are now heavy on the docket for technology leaders.
Some of the largest enterprise organizations in the world, like Disney, Starbucks, Nike, and Amazon are demonstrating that DevOps practices can be extremely effective as a driver of end-to-end business transformation. As we look at what’s to come, one thing becomes abundantly clear – we must disrupt ourselves before our competition does.
Different drivers for DevOps, and cloud
As more organizations move towards the cloud, DevOps initiatives are often not far behind. Cloud migrations generally start with operational and financial motivators. For example, organizations may want to leverage cloud services to eliminate the cost of a traditional data center, reduce the need to hire system admininstrators, and streamline software delivery processes.
When an organization attempts to move to a more modern architecture like the public cloud, or from mainframes to microservices, it is crucial that every team in the organization is aligned with the same goals, that they collaborate often and that they automate as much of their processes as possible. A successful digital transformation not only focuses on modernizing tools or architecture, but modernizing practices as well – and this is where DevOps comes in.
Enterprises should look at DevOps as a company-wide transformation, rather than just a means for facilitating digital transformation. The desire to get better at delivering high-quality software, and to deliver that software “on business demand” are key reasons that enterprises are moving to DevOps.
Re-engineering business processes
“We don’t like to use the word ‘transformation,’ because transformation happens to you, and no one likes that feeling,” is one of my favorite quotes from Jonathan Smart, head of development services at Barclays, taken from his talk at DevOps Enterprise Summit 2017.
The quote resonates with the collaborative nature of DevOps. When an enterprise moves from waterfall development to Agile, it undeniably leads to some sort of business process re-engineering. Tooling, process and culture all need to be reviewed to address the multi-disciplinary nature of cross-team software delivery. Businesses should approach this transformation in an agile manner, and expect setbacks. The difficulty of the journey also depends on the starting point. For example, a bank beholden to a mainframe application with a lot of red tape required to make changes to it is going to require much more effort to affect a change. However, any organization in any industry may pick the wrong goals while facing politics, people, feelings and changing skill sets. It’s how an organization handles these setbacks that determines their success.
Remove the bottlenecks first
Defining “current state” and understanding existing boundaries is essential at the initiation of a DevOps transformation – businesses have to know where they stand today, in order to make the transformation happen. The Theory of Constraints aligns with this thinking: improvements won’t have much impact unless you remove your biggest constraint first.
It’s crucial to know what that constraint is and tackle it, versus trying to overcome small constraints that will yield little value in terms of cost or time savings. Value stream mapping is a growing discipline for defining these constraints and costs. Value stream mapping really provides a “code’s-eye-view” of the software delivery lifecycle which allows you to see how the code (“value”) moves from inception to production. A challenge commonly heard is that most organizations are so siloed that it’s hard to have anyone identify and agree on what their value stream looks like, and where its constraints are until the organization determines that things need to be changed.
Re-engineering and re-architecting
From the technical perspective, there is also the question of whether DevOps pipelines and practices can absorb new tools while also coexisting alongside legacy tools, processes, and release cycles. It’s important for organizations to easily adapt, and incrementally improve, their delivery capabilities for both new and legacy architecture and applications. For them, it is not an option to shut down the application to experiment with new architectures and technologies (like microservices/containers) in the hopes of improving the application, because the customer can’t be impacted by even the most significant re-architecture. Because of this, organizations will need to operate in a hybrid model where new technology is on-boarded safely in a way that allows it co-exist with the systems that are already in place.
As we look at both the business and technical sides of DevOps and the challenges that have been revealed over time, we realize that this re-engineering process is going to require a cultural shift.
Creating a culture of transformation and adaptability
If DevOps is to become more focused on business transformation, the business culture will play a defining role in whether or not it succeeds. Adaptability is key to a successful transformation, and you may need to face the hard facts that some people may not be open to things like automation, or may resist the urge to move away from the mainframe.
For example, to keep up with the pace of delivery, QA teams who are used to “executing tests” may need to transform into “test engineers;” writing tests and automating the work they used to perform manually. Similarly, enterprises will want to include other teams in the transformation as well, seeking representation from finance, legal, HR, accounting, etc. Why? The new cadence of value delivery offered by DevOps will change job roles and requirements far beyond Dev and Ops – for example, how can a CFO hope to define a quarterly budget for some large list of value (“features”) when you are defining new features and delivering a new application value via a 4 week sprint.
SEE ALSO: “You cannot buy DevOps in a box”
Create a learning culture and become an adaptive organization
The success of these transformation efforts will vary. One key way to determine how likely you are to succeed with your transformation is to leverage a framework based on Ron Westrum’s 1993 Theory of Organizational Safety. To get started, one must honestly answer the following question:
“How does my organization handle someone coming forward with a mistake or problem?”
- If the messenger is punished, it’s a punitive organization.
- If messengers are ignored, it’s a bureaucratic organization.
- If messengers are listened to, it’s a learning culture.
Businesses will not be able to leverage DevOps unless they lean more towards the side of a learning organization because visibility and blameless cultures are key to DevOps success. A lot of large organizations leverage third-party components. Understanding the software supply chain and where risks exist from third-party or open source components is becoming more and more critical to DevOps success.
What’s most clear to me is that DevOps is not going to be written off as a fad or trend in software development and delivery – instead, it’s going to have a permanent effect. More companies are going to approach it as a means to transform the enterprise into a digital organization – and it’s going to require an all-hands approach.