Avoiding Pyrrhic DevOps
Below we'll discuss some ways to model and approach DevOps setup so that automation advantage does not cost you more than what you gain in efficiencies and savings.
Join the DZone community and get the full member experience.Join For Free
As an architect firmly grounded and comfortable in the technical aspects of DevOps delivery, I have found myself greatly uncomfortable with some of the more sales and cost-related issues of delivering DevOps solutions, lately. Now more than ever, I have come to appreciate the "known" vs the "unknown" when it comes to DevOps delivery. There is nothing like an "unknown" factor(s) that can turn your "slam dunk" DevOps gig, into a Pyrrhic win of stack automation at crippling costs. Here are some ways to model and approach DevOps setup so that automation advantage does not cost you more than what you gain in efficiencies and savings.
1. Handle the "Known" With Fixed Guaranteed Outcomes
DevOps is often about matching enterprise needs with automation tools that are congruent with enterprise strategy direction and policy. I hold the view that "Technology is the easy part to implement; it's changing hearts and minds that is the messy business of DevOps." Setting up a pipeline of automation tools is a relatively "easy" thing to do, based on collective knowledge and the maturity of tools, architectures, and integrations that exist. This is why I often give direction to my team to estimate work items related to DevOps pipeline setup as fixed cost/price. We have even built out assets (templates, images, Docker containers, and so on) that contain base configurations and topologies of automation pipelines. I work for an IT service provider, so DevOps for one client is never the same as the next, so our pipeline solutions are never the same snowflake twice. But we adhere to the 80/20 rule when it comes to setting up automation tools like IBM UrbanCode Deploy (UCD), Jenkins, Selenium, and so on. Sometimes we use a Docker image for a base setup of UCD that we have reused countless times, and the same principle can be extended to other automation tools. This allows for a "prix fixe" approach to standing up a delivery pipeline, with a "menu" of automation tools.
When describing the deliverables of fixed outcomes, the effort becomes relatively easy to articulate. You have a set goal/outcome, it's either there or it isn't... it's a binary operation.
Clients and project teams love fixed price solution components because they are easy for budget and planning... there is little to no variability. What is known is a set fixed cost/price (and often a fixed schedule accompanied with a concrete goal and deliverables).
2. Handle the "Unknown" With Time-Boxed Outcome
Don’t you just love Agile? (Say, "YES!") DevOps automation is scary from a service provider point of view. We know about the 287 different proprietary and open source DevOps automation tools that are there today (this adorable "Periodic Table of DevOps Tools" by XebiaLabs offers a plethora of choices to start a do-it-yourself DevOps pipeline construction). The part that keeps me up at night is the thought that, as a DevOps service provider that sells custom automation services... I have *no* idea of the true complexity of an application's unique deployment to the extent that I can estimate it. I get heartburn over it... every.single.time. So the question becomes, how can I provide cost estimations on something that I do not have tribal knowledge on?
It's all about taking the "time box" approach to custom automation work and defining concrete deliverables. This is a balanced approached that tells a DevOps consumer: I am here to help with your automation work, I am not sure how *much* I will get done, but here are the documented automation runbooks I will attempt to create for you. I hope to get 100% of them completed, but I can't guarantee completeness because I don't know exactly how complex the application deployment is. When describing the deliverables of time-boxed outcomes, documentation templates, automation asset specifications, and others you may think of are setting an expectation that automation work will yield something of an outcome.
Client and project teams need to have the expectation that they will have a heavy stake in time-boxed delivery activities. Typically, accessibility to subject matter experts (who have tribal knowledge of deployments) and executive commitment and buy-in are critical to the extent of completeness in time-boxed outcomes.
DevOps transformations include a healthy mix of behavioral consulting, educational training, delivery of IT automation tools, and construction of automation assets that result in significant value added benefits. Building a "continuous delivery" pipeline is the IT foundation for DevOps transformation, but not all aspects of pipeline build out should be planned with the same approach. Leverage a healthy mix of Fixed Price and Time & Materials instruments into an iterative execution model. For those activities that are relatively constant, a Fixed Price model should be used to factor out variability. For example, provisioning machines and installing pipeline tools (Jenkins, Git, Selenium, and so on), should be relatively straightforward to estimate, based on situational requirements. Clearly, a small pilot pipeline has a relatively simple topology than a highly available enterprise pipeline, but a Fixed Price approach to the pipeline tool build out should be relatively constant. My last blog talked about the transformation of IT operations to an automation asset management model, which is a great way to estimate those "fixed price situations" as you build up assets in your automation library.
For the consulting, education, and automation of custom applications in the pipeline, it might be best to have a time-boxed, "time & materials" approach, especially if the DevOps delivery team does not have intimate tribal knowledge of the applications that are being automated. How *do* you estimate the time it will take to automate the build, test, deploy of an application you don't have intimate knowledge of? Care to play craps, anyone?
Failing to consider the use of "time-boxed" efforts in your DevOps cost model could quickly lead into a DevOps pipeline implementation with increased quality, optimization, and responsiveness at the crushing expense of runaway costs due to lack of tribal knowledge, accessibility to technical subject matter experts, and commitment to automation. Having been a Pyrrhic winner, first hand, be wise and consider both "fixed price" and "time boxed" efforts in your DevOps cost model!
Take a quick self-assessment to know where are you on your DevOps journey.
Opinions expressed by DZone contributors are their own.