Today I’d like to talk about why we do DevOps at all. Do we have goals or outcomes we’d like to see? If not, why are we doing DevOps in the first place?
Part of this article is in response to clients who have been asking for the DevOps value proposition, as well as incremental roadmaps on how to achieve perceived benefits.
The Accenture DevOps Maturity Assessment is an excellent toolkit for baselining a client’s current behaviors against high-performing DevOps organizations, and it can be used to prioritize gap closure between today’s behavior and a desired set of behaviors. I won’t be spending a lot of time on that toolkit here, but suffice to say it’s a place I recommend for all clients to start their DevOps journey.
Clients are often looking for ways to determine the order in which a set of applications should be converted to a DevOps set of practices. That question has many answers, so I thought I’d write down a few considerations that can be used to construct such a prioritization scheme.
The 4 R’s of DevOps
This is a shorthand I’m using for what I see as the characteristics of a successful DevOps organization and its resulting behaviors and outcomes. Reliable, Repeatable, Rapid Return-on-Investment related to software developed, delivered and deployed to enable business value. Let’s look at each of these in turn:
Reliable: Every piece of developed, delivered and deployed software is of high quality, and the process for delivering and deploying it works smoothly with minimal errors.
Repeatable: The high–quality, software development, delivery and deployment processes are repeatable and objectively verifiable. We can re-execute any part of this process over and over again whenever necessary.
Rapid: Cycle time can be made as short as possible—we can go from concept to working delivered software that gets deployed into production as fast as is physically possible in the environment.
Return-on-Investment (ROI): The process of development, delivery and deployment occurs with minimal waste. The ratio of business value to software effort is as high as possible.
Many of the nascent DevOps KPIs and success metrics are related to one or more of these “R”s and can be aligned with specific DevOps behaviors and supporting capabilities. Those of you who have seen me present an overall DevOps framework for behaviors and activities know how fond I am of “continuous” behaviors including Continuous Planning, Build, Testing, Integration, Delivery, Deployment and Operations (Monitoring/Feedback). From a capabilities perspective, the Accenture DevOps Platform establishes tooling to support these activities, and it’s the alignment between these initial capabilities and behaviors that tend to guide my recommendations on application prioritization.
With the exception of Continuous Planning, which I believe can be done regardless of the agility of the software development process, other aspects of Continuous behavior tend to build on each other in a crawl-walk-run kind of way. To have Continuous Testing, you usually need the ability to do Continuous Builds; Integration requires Testing; successful Delivery requires solid Integration, and Deployment relies on capable Delivery.
It’s this requirement for mastery of a pipeline of activities that helps me provide recommendations to my clients on which applications should be candidates for initial progress towards success.
For example, if I have a client who wishes to rapidly have an application with the ability for Continuous Deployment, I advise them to take the absolute smallest application they have because it’s going to have to go through the longest and largest set of pipeline activities. For some customers, I even suggest the creation of a brand-new application called “Coming Soon”, which consists of a single, static web page that can be reliably, repeatedly and rapidly re-deployed over and over again. My point is to find out all of the new processes and procedures that need to be defined and exercised to achieve this for the simplest application—ones that need to be in place before any more complex application could have a hope of being Continuously Deployed.
Other clients might want to focus on the ability to have a complete inventory of what it takes to build all of their critical software, and so they might focus on having 90 percent of their software achieving Continuous Build capability before moving on to later stages of a DevOps pipeline. In that case, I’d prioritize applications for which I know I can do repeatable builds and expand my build capability to handle larger and more complex applications.
Many clients highlight software quality through the goal of achieving Continuous Testing. In those cases, I look at the availability of capable continuous testing tools and prioritize applications against their ability to be driven and managed by the tooling I have in my DevOps pipeline before expanding the DevOps toolchain to cover more esoteric application test requirements.
By focusing on the goals you have, you can prioritize applications that get on-boarded into your evolving DevOps processes. To sum up how to prioritize for each goal of broad adoption:
Continuous Build: Start with applications where you have good source code control and accurate information about third-party libraries and software necessary to assemble the application.
Continuous Testing: Make sure you can continuously build the code, then look at which tools you have in your DevOps toolchain and which ones you’re good at running. Start with applications that match up well with those tools.
Continuous Integration: Make sure you can do continuous build and testing on the applications, then pick the ones where you can control and easily set up (and tear down, and repeat) an integration environment that you can exercise for the application.
Continuous Delivery: Do all of the above, and pick an application that’s easiest for you to bundle up into a deliverable set of artifacts, complete with an ability to stage those artifacts for deployment.
Continuous Deployment: Pick the smallest, simplest application that can make it this far. Realize that even the simple, static web page needs to be monitored and kept up, complete with the Operations to Development feedback loop (response time, uptime, access logs, etc).
It would be nice if there was one way to prioritize application for DevOps, but in reality your ability to achieve success on your DevOps journey is related to what you want to get out of it. Lining up capabilities, behaviors and outcomes in a synchronized way can help you decide on which prioritization path to take for your applications.