Software Modernisation is not just about the software and DevOps is not just about platform engineering. The two are inextricably linked. Can you make some gains in modernising your software without DevOps? Arguably, yes but you will very soon hit a natural barrier. Similarly, without modernising software you will get stuck in the early stages of your DevOps journey.
DevOps is a way of organising that creates flow, amplifies feedback, and fosters innovation. Flow is the first objective for transforming towards a DevOps approach and it is also a key objective within your software modernisation strategy. But, before we go deeper into the relationship between DevOps and Software Modernisation we need to understand what we mean by DevOps and Software Modernisation.
This article aims to explain Software Modernisation and DevOps at a high level, the connection between the two, and shows how to use the DevOps principles to guide your Software Modernisation approach.
DevOps is not a role, a team, or a set of tools. We like to think of it as an approach to software development. The term DevOps was accidentally coined from the DevOpsDays conference which was first held in 2009 in Ghent. Patrick Debois the creator of the DevOpsDays conference and one of the writers of the DevOps Handbook was looking at adopting Agile and Kanban in Operations.
The DevOpsDays conference describes itself as, "a technical conference covering topics of software development, IT infrastructure operations, and the intersection between them". Over time the term DevOps has evolved to take a much broader remit and is often described as a continuation of the Agile journey in software development. DevOps practices and principles borrow heavily from the body of knowledge represented by Agile, Lean, Continuous Delivery, and resilience engineering.
DevOps is about bringing together various teams in the software development effort to help each other to ensure the success of the whole organisation. Its primary focus is on accelerating the delivery of work from idea through to operations and the customer, enabling tight feedback loops, and creating a culture of continuous learning and experimentation. This "accelerating the delivery of work" is described as "flow" in Lean.
The description of the DevOps by Gene Kim first appeared in a 2012 article, it is also published in The DevOps Handbook. The Three Ways embody the basic principles that DevOps patterns/practices are derived from.
The first way is concerned with optimising the process of delivering changes to the software. This process is the Technical Value Stream. It starts from the point where demand for a change or new feature is identified, through development, into operations where the value associated with the change is delivered to the customer. It takes a complex systems view and emphasises the optimisation of the whole process rather than the individual parts.
The second way is about creating feedback loops from operations back to development. It's about amplifying this feedback so the software and the process to change the software is continuously improved.
The third way is about creating a culture of experimentation and learning and ensuring that the processes for changing the software minimise the cost of failure so that failure is accepted as an integral feature of experimentation.
Software Modernisation is about making change easy. The required change may be related to new functionality or update to reduce costs and mitigate risks. Often, companies have strategic systems that become increasingly more difficult to change. We view Software Modernisation as a continuous effort that should be part of your overall software development process, however, it is often neglected and consequently, your software starts showing signs of rot. These signs include software fragility, increase in time to deliver features, increased change failure rate, strong inter-system and inter-team dependencies. These have been well covered in the article Signs Your Software is Rotting.
If you start seeing these signs then you do not have sufficient attention dedicated to keeping the rot at bay. You will find an increasing number of pains. But, how do you start on your software modernisation journey? How do you prioritise? How do you organise yourselves? This is where the principles and practices around creating flow in DevOps are strongly aligned to a Software Modernisation strategy because both relate to making change easy.
The first step is to fully understand how you currently make changes and add new features to your software. To help with that, you need to visualise the process from idea, through your product backlog, into development and operations, and ultimately in the hands of your customer. We run a series of workshops with our clients, inviting all key stakeholders, to create a common understanding of this process. We also analyse the product roadmap, software architecture, team organisation, and supporting process to understand how these are helping or hindering flow through this process.
Making change easy goes in parallel with understanding the issues with the quality of service that your software is providing to your customers because "making change easy" is only the means for delivering the improvements to that software. For that reason, we also aim to fully understand the quality of service our clients are providing their customers to create a Software Modernisation roadmap that not only improves your software but also ensures that those improvements are used as early as possible in delivering value to the customers.
Take a look at our videos about Software Modernisation
Following the first way of DevOps is a good place to start on your Software Modernisation journey. This requires us to make improvements to the flow of changes from idea/demand to production. First, we visualise this flow of work through various stages, known as the Value Stream. The idea is adopted from the Lean Manufacturing techniques. The key difference between a manufacturing Value Stream and a Technical Value Stream is that the stages in building software are often invisible. We visualise these stages by representing a task or a story as an item that progresses through a series of pre-defined stages towards completion. Value Stream Mapping (VSM) helps us visualise these stages.
When creating a VSM, gather all the steps throughout the change process, pay specific attention to communication paths and dependencies within and outside the team. Highlight key meetings and activities. You can then order them and start to understand the time each stage takes, work queuing up ahead of each stage, and inherent inefficiencies in each stage. Start to understand where the bottlenecks are and where the waste is.
A typical value stream diagram
There is a lot of material out there that describes Value Stream Mapping in detail, we recommend that you understand the details and practice before running such workshops for real. Alternatively, ask a skilled facilitator who understands it to run it for you.
The VSM output helps to understand where to focus your Software Modernisation efforts from the "making change easy" perspective. The ultimate aim is to create flow in your value stream so that workflows left to right through these stages in the most efficient way possible.
Once you understand your value stream you will also see where the inefficiencies and waste is. Do not stop everything to start improving the value stream, you may be doing that for a long time while your business stagnates. Start plotting these areas of improvement on an impact/effort chart, as shown below. You will want to consider the high-impact/low-effort areas first. This will get you into the habit of improvement works and start to establish trust with the business. Also start to identify the bottleneck that is constraining the whole value stream. Alleviating that bottleneck will likely uncover the next bottleneck.
Software Modernisation is not just about the actual software. Ultimately change is related to people, processes, as well as software. It’s important to start thinking about the harder problems from the outset. These harder problems are almost always related to improvements where people, processes, and software need to evolve together.
The people part relates to individual and team skills, organisation, paths of communication, and culture. Processes encompass the standards and the ways of working within and across the team. Software is the code that represents the product as well as the codification of processes relating to development, testing, deployment, and operations. Change in one area impacts and is constrained by other areas. More often than not you'll need to look at change from a Systems Thinking perspective where people, process, and the software are all part of that same system.
Convey's Law is often quoted in the context of the kind of structure your systems end up with.
"Any organisation that designs a system (defined broadly) will produce a design whose structure is a copy of the organisation's communication structure." — Melvin E. Conway
Misalignment between the software structure and how the business thinks about change is often a key area of waste when analysing a Technology Value Stream. This misalignment causes the need for increased coordination between the team and reduces the teams to only think of their work in terms of tasks that they complete without understanding the whole. In other words, they don't have a full view of the value stream preventing them from understanding how to continuously improve the whole value stream rather than a small part. This kind of misalignment also reduces the impact that these teams have in driving the product/service towards a better customer experience because they often do not have a clear view of the product.
To come up with the ideal team and system structure, we conduct a series of exercises that create a common understanding of the business, its processes, and how change is articulated. We use several workshops and individual interviews to gather this picture and help create a common understanding. We then use this context to propose a hypothetical team structure that will create cohesive and largely independent teams and a systems architecture that supports this team structure. We test our hypothesis using the business roadmap, proposed team structure and architecture. These tests must be relatively inexpensive experiments that help to evolve the picture. We often find that companies begin restructuring with little context or careful planning that results in chaos. This actually creates a mistrust in such efforts and companies end up with worse places than where they started from. We recommend that you do not embark on this journey without expert advice.
Even if a different team structure and systems architecture is clearly needed we don't recommend that you immediately dive into making changes towards that objective or that you immediately restructure the teams. If you take that route then you will not be able to support the current and the short-term needs of the business and you will also not be able to evolve your understanding with frequent feedback.
Improving the value stream requires several skills that may not exist because the organisation did not need or use them. This includes a deep understanding of organisational design, processes, and software architecture in order to analyse the inherent problems in the value stream from a systems perspective. At least the more senior members of the team should be able to run these workshops and help visualise and continuously improve the value stream.
Refactoring, the current software architecture, automation, and platform will also require skills that may be lacking in the organisation. Refactoring implies that the structure is changed without impacting the overall behaviour of the system. The skills relate to code at the lowest level, and platform, architecture, and organisation at the higher levels.
The second way of DevOps is about continuous feedback that informs the organisation on how the software is supporting the business both in terms of features used by the customer and the suitability of the change process. Working on improvements has no direct impact on the business therefore build trust with relatively quick wins, communicate with the business on how you are providing value in the language of cost and agility and take feedback on how these improvements are helping the business. That said, tracking cost and agility do not tell you where change should be focused to drive improvements. That is why we track lead times on parts of the process, the whole value stream, cycle-time for individual stages, and queues building up ahead of those stages.
The other valuable metrics to consider are Change Failure Rate, Deployment Frequency, and Meantime to Recover. These are from Google’s DevOps Research Group and you can find out more here. Deployment Frequency allows you to tighten the feedback loops. Highly cohesive and loosely coupled components and smaller deployments help to release often with lower change failure rates. That is due to the fact that the impact of change is much smaller and well defined components reduce the cognitive load for the team making the change.
The third way is to create a culture of experimentation and learning. Here you are striving to institutionalise the improvement work not allowing the technical debt to pile up. Software and process should be designed so that cost of failure is minimised.
As mentioned earlier, we view Software Modernisation as a continuous effort to improve that should be part of your overall software development process. The Value Stream Map that we created should not be a one-off. VSM should be part of your continuous improvement process. We recommend that you re-evaluate your value stream at regular intervals, and take the learnings into actions for improvement.
If you're using an application for managing your backlog of work then you can configure the status of your backlog items to reflect the stages in the value stream that allows you to see actual data on where your inefficiencies are. Most organisations already use such tools for backlog management and have some sort of stages associated with the backlog items. Stats related to Lead-Time, Cycle Time, and Queues are much better than Velocity and Burn Downs/Ups because they provide intelligence that can focus your improvement effort.
Lowering the cost of failure should be a key concern in organisational and system design. Techniques such as Canary Releases, A/B Testing, Immutable Infrastructure and Deployments, Trunk-Based Development all help to lower the cost of failure. When the cost of change and cost of failure is low then the culture of improvements and experiments will flourish.
The road to realigning your systems and teams to better support the business is long and needs to be approached as a gradual evolution. The environment needs to be carefully prepared to encourage this evolution. This involves a clear technical vision and strategy that is shared by the whole team, a clear understanding of the needed skills, a constant and evolving view of the value stream and where people, process, and the software contribute to the inefficiencies. DevOps provides a suitable guide to Software Modernisation efforts. Following the principles relating to the three ways helps to focus your improvement efforts and ensure that you are providing value to the business every step of the way.
