Contact Info

Jaded Studio

Thoreau Blvd.
O'Fallon, MO 63366
phone: 618.219.5249
email: send me accolades

Find Me On...


Defining A Roadmap

26 Nov 2015

When adopting DevOps across the organization 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 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 organization and provide some guidance.


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 the adoption of “hot” practices or the implementation of new recommended tools will not guarantee 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 with 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 challenge for our efforts, as the last 20% of automation for deployments can be hardest and yet most benefits are dependent 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 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 rather than hours and giving developers a development environment from the cloud takes hours rather than 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 tests, and the cloud-based environment for developers is not compatible with the operations guidelines for production environments. Bringing these practices back together is costly and the associated change management is a nightmare.


Follow these steps:

    Ask yourself if 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 unsure. 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.
    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 bottlenecks. It will also help you with base-lining 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.
    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 applications 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 indicate which integration points are important (like those for performance testing, application deployments, or integration testing) while others with systems that don’t change or have little data f low 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—as well as verifying the underlying technical architecture—is hard work. Enlist your change agents across the organization to help.
    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 showcase a particular application or technology. You usually choose a relatively isolated application that has 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 organization, 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 organization. The teams associated with those pet applications are often more open to pushing the boundaries as well.


    Shiny objects exist, and it's very easy to get distracted by a new DevOps product or concept being introduced to the community. As a technologist myself I understand the temptation to invest in a “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 level 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 hype until you are ready to really benefit from it.

    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.