Ever since Microsoft’s Satya Nadella declared that all companies are software companies, we’ve seen a big shift in how businesses are using software to compete. As a result, companies are placing greater emphasis on delivering software faster to drive transformation. This emphasis places DevOps at center stage, with a growing need to incorporate DevOps into company culture and companies’ digital transformation efforts.
When people think about DevOps transformations, for many, the first thing that comes to mind is a technology overhaul. They think of IT teams, development tools, software automation, and rapidly flowing software deployment. But successful DevOps transformations involve a much broader scope of people, processes, and tools. As companies start putting their DevOps digital transformation strategies into full gear, here are eight elements critical to success.
1. Understand That You’re Building a Service
Your developers can tell you a version of the following story:
Back in the day, we would set up a Jenkins server under someone’s desk and then we’d start to use that server to build our software. More and more developers would start to use it. The problem was, when issues came up, like the server would get powered off, no one knew where it was running. That’s when Jenkins became a Production-level service.
Think of your DevOps transformation as introducing a new service to all of the people who are responsible for delivering software. You need a service that is available 24/7, since delivering software requires robust, sustainable delivery from developer through Production. Successful organizations think of this “DevOps as a Service” approach as a way to ensure that everyone has what they need to do their job in delivering high-quality software.
2. Establish a Clear Focus
The next step in any DevOps transformation is simple: don’t “do DevOps” just for the sake of saying that your company “does DevOps.” You need to become an organization that maintains focus on the entire delivery pipeline, from developer to Production. Start with a clear, honest assessment about the way you currently deliver software. Here are some things to think about:
What are the different release processes you leverage today? How are changes to most applications delivered from developer to Production? How many applications do you currently have? How many active releases are associated with an app at any given time?
How do you define releases at your organization? Is it a per-app event, or is it an outage for one night with all apps included? Try to think about everyone who has a role in getting your application running in Production — Dev, QA, InfoSec, OPS, DBAs, etc.
What is your overall goal with this launch? Be specific. “I want to do triple the amount of releases next year” is good, but it isn’t enough. What does this mean for your organization? Do you want to triple the number of all releases, or just one? Are you trying to increase the average time per release post build?
Finally, think about how you want to track progress toward your already established goals. What KPIs will you use?
3. Get Executive Buy in
In many enterprises, we find the DevOps transformation grows organically starting with the front-line developers and then to the rest of the organization. To make the transformation successful, it’s important that executive leadership be involved every step of the way. Leadership must have a total commitment to the transformation, including committing time, resources, and budget. Otherwise the transformation efforts will become fractured or even abandoned.
Communication is crucial. This communication includes regularly sharing wins and their impact with the entire company, however large or small those wins may be. Share early and share often — and speak in business terms that everyone can understand.
For example: What will this DevOps success enable customers to do that they couldn’t do before? Did it allow the company to enter into a new market or line of business? Will the software help employees or partners become more efficient?
Find ways to tell the whole organization the story about the relevance of the transformation and about all the people who made it possible. A successful DevOps transformation involves much more than getting a few small teams on board. It’s about moving the entire organization forward, and that requires that everyone, including executive management, buy into the transformation.
4. Build Your Minimum Viable Products (MVPs)
You’re going to have to sell this DevOps transformation to constituents across your organization. To make your changes credible, you’ll need to achieve success in Production. The reality is that it’s easy to automate in Development. It’s really hard to automate in Production.
Here’s the one simple rule for success: 1–3 applications, implemented from Development through Production. By picking a small set of applications and working through a DEV to PROD implementation, you’ll achieve three things. First, you’ll have implemented the service platform, by working through any/all organizational boundaries. Second, you’ll have real success that you can measure for your entire pipeline. And third, by picking applications that have a variety of technologies and a regular release process, you’ll have credibility across multiple teams in your organization.
5. Increase Collaboration
At its core, DevOps is all about collaboration. Ensuring everyone involved in software delivery knows what everyone else is doing creates the social cohesion that drives DevOps forward. There’s no way to implement DevOps overnight, but any step towards greater collaboration delivers real benefits.
For example, follow a scrum model by holding daily team meetings where people review their progress by addressing three simple questions: What did I do yesterday? What will I do today? What might block me from achieving my goals? These meetings should be short and sweet — about 15 minutes — and include the whole team. The difference here is that instead of just focusing on technical application changes, you’ll discuss non-code topics as well. These non-code topics are critical for shining the light on all the organizational boundaries (think “people” and “process”) that deter so many DevOps transformations.
I also like the practice of what I call “dad” meetings — bringing everyone involved with delivery of an application to the table, from Dev, QA, DBAs, and Ops managers to Production staff and even the CIO, for a 2-to-3-hour mandatory meeting. During these meetings, each team reviews exactly what every member of that team needs and what is blocking them from getting it. A meeting like this works because, I can guarantee you, that at least one person in the room has never been asked the question, “what do you need”? Getting answers to that question forces the conversations necessary for figuring out how standardize the way you get your software into Production.
It’s critical that every team in the release delivery process is invested in the success of the project. If you haven’t taken the time to build collaboration and trust with all the teams responsible for delivering change, go back to that step before trying to actually implement changes. It’s easy to say, “communicate more.” What you really need to ensure is that people who are taking the risk to make these changes know that they are both encouraged and supported.
6. Let the Service Provide the Solution (or, Stop People from Writing Their Own Scripts)
A 2017 report by the International Data Corporation (IDC) predicted that organizations around the world will spend around $1.7 trillion USD on their digital transformations by the end of 2019. That’s a lot of money being invested to reap the benefits of a digital transformation — happier customers, increased innovation, higher employee satisfaction, and faster time to value of products and services. But for many organizations those benefits have not yet been realized.
Scripting may be the culprit. Specifically, scripting how software is delivered throughout your DevOps toolchain, from code integration to testing to configuration management to deployment of every application to all sorts of environments, from Development to Production.
If you’re like most organizations, highly paid developers end up writing scripts — by hand — to deliver instructions for every activity required to release software. Each time anything changes, they have to make edits, so in essence, they end up scripting the entire DevOps tool chain and software delivery pipeline over and over again, instead of writing code for business applications. Developers don’t like doing this kind of maintenance work because it keeps them from creating great features at high velocity.
A more modern and scalable approach is based on the DevOps as a Service model. A DevOps service provides teams the functionality they need to build and execute their own functionality, for example, blueprints for transforming legacy applications onto new cloud architecture, or automated release plans that include your provisioning, so that tasks comply with your organization’s security requirements. And when your organization decides to implement a new technology? The solution is implemented via the service, so your teams can all take advantage of the solution.
7. Manage Your Pipeline as Code
Your entire delivery pipeline needs to be managed as code. This means that deployments, releases, infrastructure, and configurations need to be versioned and certified. Your DevOps service will both demand and enforce this, since delivery of changes won’t be possible by someone “logging into a server and running their custom script.” In that example, the person would check their script into a source code repository, and the running of the script would be executed at the appropriate time by the release orchestration engine (which, by the way, would also be running versioned definitions of release modules).
8. Standardize for Scale
I can’t stress enough the importance of standardizing your software delivery process, particularly if you, like many large companies, are looking to shift applications to the cloud. By bringing everyone together, defining your releases, and establishing goals, you’ll move away from a trial and error approach to a more repeatable, scientific one. Standardization not only allows you to deliver software more quickly and efficiently, it positions you to set goals and then collect and analyze data that allows you to see if you’re meeting them.
The important step here is to assign metrics/KPIs to those goals and track them over time to see how successful you are or where you need to improve. That information will arm you with hard data and intelligence that will solidify support for DevOps and help you make the best decisions that will continue to improve your processes. Collecting and reporting on a standardized process also sets you up for more advanced analytics approaches, such as predictive DevOps and AI, which will rise in use over the coming years,
When it comes to a successful DevOps transformation, much is at stake. Organizations that learn how to master efficient and effective software delivery will succeed. Software delivery is first and foremost a business endeavor — all the people, tools, tasks, and processes exist to drive business value. Harmonizing all these pieces requires expanding your approach from development-centered to business-value-stream centered. Keeping these eight elements in mind as you kick off your DevOps transformation will get you on the fast track to realizing this business value.
