The human path to legacy modernisation

‘We just need to change the funding model.’

I heard that phrase many times when leading architecture teams, and it always made my heart sink.

It was normally said with good intent by architects who were working on a problem which required long term, multi-year investment to build shared assets. Unfortunately, resources (money, people, leadership attention) were allocated to meet the focused needs of business divisions, rather than to create enterprise capabilities. Hence the lament that, if only we could change the funding model, we could give the enterprise the architecture that it really needed.

Whenever I heard that phrase, I had to remind myself and my team that ‘just’ is one of the most dangerous words in the language, especially when used in fields outside your expertise. Architects hated hearing that we should ‘just’ scale up this system to ten times its planned capacity, or ‘just’ modify that system intended for retail customers to serve corporate customers. We had to remember that the CFO and the finance team would feel the same way if we asked them to ‘just’ change the funding model.

And yet . . .

There is one situation in which I think it is worth attempting to change the way in which change is funded: legacy modernisation. And I think that is because we can show that typical funding models for change in legacy systems are one cause of the problems with those systems.

As I argued in my last article, old is not bad. Legacy systems are usually not slow, fragile, hard to understand and difficult to change because of any fundamental features of the technology they are built from: they have these characteristics because they have been changed many times, by many people, in piecemeal fashion. And these changes have usually optimized for the immediate delivery of features, rather than for agility, performance, readability or maintainability. And changes have been made this way because of how they are funded and managed.

Legacy systems aren’t just built from old technology: they are built from old management practices - the way we ran things before we embraced Agile principles or learnt about DevOps. And they are usually the last systems for which these management practices change: work and investment choices are often organised in the ways that they were decades ago.

This means a flow of decision making which runs roughly along the following lines: investment portfolios are constructed to meet business needs; investment is chopped up into projects, and the impact on IT systems is assessed and estimated; funding is funneled through projects to get the work done. Within the IT department, projects are used as the mechanism to capture time and costs and charge them back to the commissioning business units.

This does not sound irrational. But it results in a mode of operation in which the teams that work on legacy systems are fed with a flow of tasks and change requests from projects, and are not allowed to work on anything else. (If the idea of not being allowed to work on anything else sounds unlikely, go and speak to the members of a corporate IT department who have been drilled to believe that they can’t do anything without a project code to charge it to.) Sometimes they do not even have the opportunity to review all of the changes they are being asked to carry out and group them logically: they just have to take the next task off the conveyor belt.

If you’ve been part of a development team, you will recognise that this is a terrible way to work. It doesn’t give you the chance to think about the evolution of your system, which rapidly becomes a patchwork of inconsistent changes. At the interface, it may look as if you are providing the requested features; underneath, the code is a boiling mess. And you never have any time to do refactoring, because refactoring is never a priority for the people who make the investment decisions: they probably have no idea what it is, and wouldn’t know how to express its value in a business case.

The result of this is that legacy systems inevitably acquire those characteristics we dread: they become slow, fragile, hard to understand and difficult to change. Until we realise that we have to do something about them, and embark on expensive modernisation projects, replacing them with packages or top to bottom rewrites. And we know that those projects are hard, often fail, and rarely get rid of everything.

What if we invested instead in changing the way our legacy teams work? What if we put them first rather than last when adopting practices such as Agile or DevOps? There is nothing about those practices which says that they only work for new technologies. What if we gave the teams that run legacy systems the freedom and capacity to manage their pipeline of work and spend time on refactoring and reliability?

On the few occasions I have seen this done, I have seen two important results. Firstly, I have seen that, when we trust the team to organise their work, they deliver more features and improve the quality of the system. Secondly, I have seen a remarkable shift in ownership, engagement and pride. Being an empowered custodian of a critical system with a future feels very different to servicing a never ending queue of feature requests, while watching your code get worse.

Perhaps this means that, when considering our legacy modernisation strategies, we should look to the team before the systems. If we modernise the way we treat and trust them, perhaps we can avoid expensive, risky replacement projects.

Of course, this may be another dangerous ‘just’: we just need to change the way we treat teams managing legacy systems, and we just need to trust them to do the right thing when given a chance. But this feels like a just which is well within the power of most technology teams.

(Views in this article are my own.)