There are many different approaches to Software Modernisation. The right approach will depend on many factors such as the business goals you have for the modernisation program, the current state of your systems and organisation, prevailing business pressures, the resources available to the program and the structures of resource allocation within your business.
In this article I’m going to outline some different ways of leading a Software Modernisation program with their pros and cons. The goal is to help the reader to understand which approach might be suitable for their organisation, the current state of its systems and the business value that it wants to unlock through software modernisation.
The people that regularly work with the technology of your organisation, such as software developers, infrastructure teams (if you have them), QA groups, DBAs, Infosec or Appsec groups are likely to be the people that understand best the problems that exist within your organisation. It seems logical, even obvious perhaps, to trust such groups to understand the problem, secure budget and execute on a software modernisation program.
With technology led change there will typically be a backlog of technology focussed deliverables such as “migrate our database to the cloud”, “upgrade our core e-Commerce platform to the latest version” or “rewrite our monolithic application into Microservices”. The group responsible for delivering the modernisation will create the backlogs for the deliverables and find a way to deliver on the improvements without impacting on the critical business deliverables that must continue in parallel.
The project will be led by the people that have the best understanding of how to modernise the technology estate.
As the deliverables will generally be contained within a single system it is likely that each deliverable will be contained within a single value stream owned by a single group. This ought to ensure that change can be driven quickly.
The business value may not be obvious outside of the group executing on the program. This can lead to a lack of support from higher level stakeholders.
As the stakeholders of the program are technology focused there is a risk that modernisation, whilst improving the technology, may not deliver real business benefits.
Any technology led change risks being siloed within a single group and will do nothing to address holistically any organisational problems.
Development teams may be tempted to overdesign systems and introduce new “cool” technologies because they can without considering the full benefits and costs.
A bottom up approach to Software Modernisation places the ownership of the modernisation goals at the level of the existing product teams. The organisation will understand that Software Modernisation is necessary as the current state of systems is making it hard to deliver on its business objectives. Each product team is empowered to create backlog items that deliver Software Modernisation goals and add them to its backlog. Typically the leadership of the organisation will mandate that a certain proportion of each team's resources should be allocated to modernisation items with the rest of the available resources assigned to feature work.
Each existing product team is empowered to choose the modernisation backlog items that fix their own pain points which should lead to good motivation and buy-in.
Feature work should continue throughout the modernisation program.
The lack of any implementation team tasked specifically with Software Modernisation items could mean that specific software modernisation goals, deliverables and metrics are hard to articulate.
In an organisation where the current state of systems is causing large amounts of unplanned work it is likely that the business could bring pressure to bear on product owners to de-prioritise Software Modernisation items in favour of feature work.
Many of the symptoms of positive change delivered by a Software Modernisation program will be visible in improvements to the organisation’s approach to DevOps practices. The DevOps transformation team will be tasked with improving the tools and practices around all of the technology value streams with a clear goal of enabling each product team to be self-sufficient.
It needs to be understood that this team should not be seeking to be gatekeepers in the sense of a traditional ops or production services team but rather they should be creating tools and practices to enable every product team to be its own gatekeeper of production quality. In order to take advantage of the new ways of working provided by the DevOps team each product team will have to necessarily modernise parts of the systems that they own.
No product team should get left behind by this approach as the new tools will be available to all.
Product teams should be able to continue working on their own backlogs with priorities set by their product owners.
Each product team can set its own agenda for improvement and therefore find suitable times to work on software modernisation alongside its ongoing feature work.
For this approach to be successful there needs to be widespread buy in from the whole organisation and not just those directly involved in the program.
Product owners need to have a level of understanding over how software modernisation work will improve their feature flow over time in order to be able to make informed decisions on priority.
There is a danger that the goals of product teams could be perceived to be misaligned with those of the DevOps transformation team.
The idea with product lead change is that Software Modernisation is driven by reorganising the software teams around product verticals with close business involvement. In order to ensure that each new product vertical has the ability to autonomously deliver on its outcome, it is inevitable that the software modernisation will have to take place. Software Modernisation goals are thus immediately linked to obvious business value first through decoupling efforts to facilitate autonomous teams then through constantly iterating on the tools to support the value streams.
The ultimate goal in this type of modernisation program will see the whole organisation realigned around customer facing outcomes being served by autonomous cross functional teams. Owing to business continuity concerns it is unlikely to be possible to execute some kind of “big bang” organisational transformation. Short term business disruption will be kept to a minimum if the new product focused teams are created iteratively.
A good way to start is to identify the easiest outcome to isolate from the rest of the systems, create a team to deliver that outcome, empower them to do what modernisation is necessary on the existing systems to isolate their value stream before delivering their solution. If the high level stakeholders are nervous about risk to ongoing business then consider selecting a low risk product or outcome, or perhaps a greenfield opportunity, for the new team.
When your first product team is delivering regular value, confidence and enthusiasm for the new model should be building throughout the organisation. At this point you can consider the next team or teams to create based on which will deliver the most impact, either in terms of immediate customer facing value, business agility or a combination of both.
This approach demonstrates the value of breaking silos down by creating product based verticals instead of technology based horizontal silos.
There is obvious deliverable business value through the product chosen as the focus for software modernisation.
If the business consists of a lot of technology siloes the early stages of the modernisation program can be very frustrating as the new product team attempts to understand not only what various systems do but why they do it.
There may be internal resistance to this type of change because the reorganisation of the teams that should eventually result will be perceived as a threat to some personal interests.
In some organisations, particularly larger organisations, it may make sense to use a combination of one or more of the above approaches. One combination that can work very well is to combine the DevOps Transformation Team Approach with the Product Led Approach. This approach can reduce the potential friction between the newly created product teams and the existing infrastructure (or production systems or ops) team because the latter groups will form the core of the new DevOps team which will be aligned with the new product teams since they will all be focusing on Software Modernisation goals.
A hybrid approach involving more people within technology should ensure better alignment across the group leading to better outcomes.
Any type of hybrid approach can be designed to balance more visibly tactical concerns with strategic objectives.
A hybrid approach, particularly one that involves development teams, a product group and ops focused development teams may cross existing business verticals and thus cut across some high level budget holders. It will thus be necessary to get a high level of alignment and cooperation for such an approach to be successful.
A hybrid approach will necessarily be a larger program involving more people and can therefore be expensive.
Ultimately, every organisation is different. There are different reasons why software might need to be modernised, different budgetary structures within the organisation and different external pressures that need to be balanced against each other. It is also very likely that an ambitious Software Modernisation program will cross existing organisational boundaries and may ultimately result in a painful realignment of those boundaries which could be perceived by many as a threat.
Consider carefully how you can deliver on the goals of the business while keeping your stakeholders, and especially your budget holder, happy throughout. Showing value early and often will be key to building momentum and support within the wider organisation, ensuring your budget will not be questioned and giving you the best chance of long term success.
Software Modernisation can be a long and sometimes frustrating journey. As long as you and your stakeholders understand this and as long as you follow some of these principles to help you in choosing the methodology that gives you the best chance of long term success, then the journey should ultimately prove extremely rewarding.
According to a report by Deloitte, the cost of technical debt in the United States alone was estimated at $1.5 trillion in 2022. Despite this..
Is it possible to modernise critical legacy systems whilst maintaining business as usual? This was the theme of a recent techUK panel event where..
In January 2022, the last version of AngularJS left support. There will be no official updates or security patches for AngularJS ever again.
Join our newsletter for expert tips and inspirational case studies
Join our newsletter for expert tips and inspirational case studies
