How to Define Your DevOps Roadmap
How to Define Your DevOps Roadmap
An article from DZone's Research Guide to Continuous Delivery, Volume III, out now!
Join the DZone community and get the full member experience.Join For Free
When adopting DevOps across the organisation there are many different ways to set a path. You can take one application and go all the way to Continuous Delivery or you can take all your applications and just improve one area like Configuration Management. Clearly there is not just the one correct way – the silver bullet people are looking for. In this article I will explore the parameters that help you define the path for your organisation and provide some guidance.
How and Why DevOps Adoptions Fail
There is a general approach that I recommend for anyone defining a DevOps adoption strategy and roadmap which I will describe further below. What people need to keep in mind is that their delivery context is different to everyone else’s and that that the adoption of “hot” practices or the implementation of new recommended tools is no guarantee to bring you the results you are after. Far too often DevOps adoptions fall into one of two unsuccessful patterns:
Failure mode 1 — Too little in the right place: Let’s be honest to ourselves, the adoption of DevOps practices is never just an implementation project. Once you implement a specific practice like deployment automation or functional test automation, the real challenge is only just beginning. Truth be told the 80/20 rule is a real challenge for our efforts, as the last 20% of automation for deployments can be hardest and yet most benefits are depending on removing that last manual step. Too often do I see the focus move off the early adoption areas which then remain at the 80% mark and cannot reap the full benefits. This in turn can lead to deterioration of the practices while maintenance efforts are high and yet the benefits are not outweighing it.
Failure mode 2 — Local Optimization: Looking across the organizations that I have worked with, I see a disheartening pattern of local optimization. Some group goes off and implements DevOps practices (for example the testing center of excellence or the operations team) and they have great successes. Their individual results improve so that the automated regression now runs in minutes not hours and giving developers a development environment from the cloud takes hours not weeks. Yet the organization as a whole fails to see the benefits because the different practices are not compatible or too many dependencies continue to hinder real results. Different test automation is run in the application test environment versus the one that runs in pre-production test, the cloud based environment for developers are not compatible with the operations guidelines for production environments. Bringing these practices back together is costly and the associated change management is a nightmare.
How can you avoid these failure patterns? Follow the three steps below:
1. Visualize Your Delivery Process
Ask yourself, do you really understand everything that is happening in your delivery process and how long it actually takes? More likely than not, you don’t really know or are not sure. So the first order of business is to bring stakeholders from across the delivery lifecycle together and map the process out. Do this with all the stakeholders in the room. You as a process owner will be surprised what you can learn about your process from others who are exposed to your process or have to participate in it. Techniques from Value Stream mapping come in very handy here.
2. Identify Pain Points and Bottlenecks
Once you have the visualization of the process, add some quantifications on it like how often feedback loops are run through, the volume of requests, and cycle times. You will use this information to identify pain points and bottle necks. It will also help you with baselining some performance metrics that you want to improve. It is good practice to define metrics for bottlenecks so that you can see them being removed.
3. Address the Minimum Viable Cluster of Applications for DevOps Uplift
And now to the secret sauce: Go wide, but just wide enough. Identify the minimum viable cluster that you can address and which will have significant meaning if you can improve it. The minimum viable cluster can be determined from your previous analysis of the process and the analysis of your application architecture as you are now able to identify a set of application that needs to be delivered together. In most enterprise environments applications are not independent (like they could be with microservices) and hence you need to address the integrated applications that change together. The pain points and bottlenecks will give you indication which integration points are important (like those for performance testing, or application deployments or integration testing) while others with system that don’t change or have not much data flow are less important. Make sure to challenge yourself on the minimal set as casting the net too wide will hinder your progress and being too narrow will mean you are unable to demonstrate the benefit. For this minimum viable cluster you want to integrate as early in the lifecycle as possible by deploying all the required practices from the DevOps toolkit to get to short feedback cycles.
A key factor of success lies in the execution of your roadmap and the right governance. Making sure that you have tight feedback cycles and that the different groups remain aligned to the goals and the underlying technical architecture is hard work. Enlist your change agents across the organisation to help.
Adjust Your Roadmap to Bring the Organization Behind Your Efforts
Everything I wrote so far points to a preference for going wide, yet there are very good reasons to break this pattern. I want to explore two of them in more detail:
Enabling the Change: In some organizations there is skepticism that the change journey is going to be successful or in some cases there is not even sufficient knowledge to understand what good looks like. In those cases it can be beneficial to single out an application or technology as showcase. You usually choose a relatively isolated application that has a suitable technology architecture to show how good delivery in a DevOps model looks like with minimum effort. The balance to be struck here is that this is meaningful enough to not be seen as “token effort” and yet it needs to be something where progress can be shown relatively quickly. I have seen internal portal applications or employee support systems like a company mobile app as great examples of this.
Consider Your Stakeholders: As with every other project in your organisation, the support of your stakeholders is key. There will simply be no DevOps adoption program much longer if your supporters are getting fewer and fewer and the opponents are getting larger in number. When you look at your application portfolio you might have applications which are not in the “minimum viable cluster” but which are of keen interest to some of your stakeholders. It is often worthwhile investing in those to make sure that they are ahead of the curve so that your stakeholders can “show off” their pet applications to the rest of the organisation. The teams associated with those pet applications are often more open to pushing the boundaries as well.
Don’t Get Distracted By “Shiny Objects”
It feels like no week is going by without a new DevOps product or concept being introduced to the community. And as technologist myself I understand the temptation to invest in a “quick Docker proof of concept” or “a microservice assessment of your portfolio”. Yet many organizations would benefit from focusing on the more basic practices of DevOps first. Often the benefits of those new products and concepts are only enabled when a certain maturity is reached and unfortunately short cuts are not available in most cases. Make sure your efforts remain focused on the areas that will bring you benefits and don’t chase each hype until you are ready to really benefit from it.
So in summary you should go with a “Go wide, but just wide enough” approach in most cases as you want to demonstrate benefits to the organization. Those benefits will serve you during the next adoption phase and you can move ahead step by step on your adoption journey leveraging earlier benefits. The better you get at it, the wider and deeper you will be able to go.
Opinions expressed by DZone contributors are their own.