The Legacy Challenge

What’s a legacy system? Some would say that it’s a system running on no longer supported components – old versions of software, impossible to upgrade databases, operating systems that were released before the Internet was a thing, or servers that still have Pentiums inside. Another way of looking at it would be when the number of people who know how the system works is fewer than the fingers on one hand and you are concerned that if anyone else retires, you will no longer be able to make any changes to the system.

Those are all true. There are plenty of corporations and government entities running systems that have some or all of those. Much of the backbone of UK government’s technology is based on systems built in the 70s, 80s and 90s. Our tax is collected, our benefits paid and our customs transactions policed by such systems.

There is, though, more to a legacy system than that. It could even be said that a legacy system is one that went live yesterday – because unless you have a plan to invest in your shiny new IT asset, all it will do by itself is decay and rust.

As systems get bigger and more complicated, whole areas of code will be looked at less and less frequently; familiarity with how that code works decreases. Personnel churn, whether in house developers or supplier staff, means that new people have less experience with the code than those who went before. Wholesale code reviews are rare. Code optimisation – revisiting already working code to re-factor it- as a way of teaching new staff how the whole thing works seems a forgotten discipline.

We talk now of technical debt – code that was fine when it was launched but is really holding back development of new capability now. It’s too complicated. It’s hard coded. It has dead ends. It doesn’t interface to new tools. This code can be a day old too.

IT systems are strategic assets, like bridges, tunnels, dams and roads. The internals need to be inspected, cleaned, operated and polished. Sure you can stand back and look at them and say how nice they are and how impressive the construction is. But the day you slow down on your maintenance is the day they become part of your legacy estate.

Put another way, it takes a project to get your system live. But if you think that’s the end of the story, you’ll find that it’s only the beginning. Too many projects move on to the next thing, leaving others to pick up what they’ve left behind … with no budget, no support and no chance.

You can pay now, or you can pay later, but you’re going to pay.

Computer Says No

The FT has a front page story today saying that Ulster Bank is absorbing the cost of negative interest rates (on money it has deposited at the ECB) because its systems can’t handle a minus sign. Doubtless whoever wrote the code, maybe in the 80s, never thought rates would fall below zero.

We had a similar problem at a bank in the 90s when our COBOL based general ledger couldn’t handle the number of zeros in the Turkish lita; we wrote to their central bank and PM to see if they wouldn’t mind looping a couple off so that we could continue to process transactions. History does not record the answer, but I suspect there came none.

Legacy systems were in the news in government IT this week as it was stated that there was no central register of such systems, that they are blocking data sharing and that there’s no plan to move off them. GDS, says Alison Pritchard, the interim leader, will be looking for money in the next spending review to deal with the problem.

This is, of course, an admirable aim. The trouble is, departments have been trying to deal with these systems for two decades – borders, immigration, farm payments, student loans, benefits, PAYE, customs etc all sit on systems coded in the 70s, 80s and early 90s. Legacy aka stuff that works. Just not the way we need it to work now.

Every department can point at one, and sometimes several, attempts to get off these systems … and yet the success rate is poor. Otherwise why would they still be around?

The agile world does not lend itself well to legacy replacement. Few businesses would accept the idea that their fully functional system would be replaced in a year or two with a less functional MVP. What would make the grade? How would everything else be handled? Could you run both in sync?

In the early 2000s a few of us tried to convince departments to adopt an “Egg” model and build a new business inside the existing business – one that was purely internet facing and that would have less capability than the existing systems but that would grow fast. Once someone (business or person) was inside the system, we would support them in that new system, whatever it took – but it would be a one way ticket. We would gradually migrate everyone into that system, adding functionality and moving ever more complicated customers as the capability grew.

It’s a challenging strategy. It would have been easier in the 2000s. Harder now. Much harder. But possible. With commitment. And a lot of planning.

All Numbers Are Made Up

Anyone who has worked with me for even a short while will recall a time when I have prefixed or suffixed a number with “this is made up” and usually followed up with “all numbers are made up.”

This is usually in one of two contexts:

  1. “This project will cost £50m (made up number), what does that mean for us, where will the costs fall, what should we worry about in terms of over-runs, where are our risks?” – the aim is to stimulate debate about the project as a whole and give everyone a number to play around with to help get to a (much) better number later.
  2. “I’ve heard that the consequences of this going wrong could be (made up number) £100m.” In this context I have no idea what the right number is but I want to know what other people think, so I throw a number out and see what other people think on the basis that we need to start somewhere.

My general theory is that all numbers you hear quoted are made up – sometimes with a bit of science, but sometimes they’re purely Wild Assed Guesses. The problem is that few admit to the numbers being made up, and so there’s somehow a belief that the fact that someone has stated a nunber must mean it’s true.

Only a few days ago, there was speculation that the cost of repatriating the Thomas Cook passengers (and, at that, just the UK citizens – no one talks about those from other countries who have to find ways home) would be £600m. It was unsourced and plainly completely made up, but very few dared admit that it was nonsense.

Which brings me to today’s story on Government Notify saving £175m in the next five years (my italics).

We don’t, therefore, know how much it has saved in the last 4 years, though we do know that it has been used to send “more than 500 million messages.”

We do know that it’s supposed to save £35m a year for each of the next five years, so 5 * 35 gives us £175m.

There are essentially three ways to get to that number, and it could be a combination or sum of all of them:

  1. Assume that everyone would have to spend some money to build or buy the equivalent capability to Notify. There are commercial equivalents of course. There are costs to integrate to either solution which, one could argue, are the same and therefore they are left out; but there are also operating costs (the commercial services are often SaaS based so there would be no build costs). That might be (Wild Assed Guess) £25,000 per service and we know that there are 1,200 services using it, so that would be £30m for the services to date (who would, of course, not save further money from here because they are already inside the Notify world, unless there is a cost of operation that they need to pay; we don’t know either way)
  2. There’s an arbitrage cost between low scale users and high scale users where message costs are cheaper for the latter and so bundling together lots of government (to get to 500m messages over 4 years for instance) would result in a unit cost save per message, provided you hit the volumes you specify. That might save (made up number) 4p per text message and so we would get £20m savings for all of the messages sent to date.
  3. There’s a business cost save if, for instance, you implement text message reminders for, say, Doctor’s appointments and you track the before and after attendance rates and see that 25% more people attend at the right time when they’re reminded. That might save (made up number) £250/appointment … and multiply that by the 25% extra and you have a savings figure. In the world of truly Wild Assed Guesses, this could be tens or hundreds of millions, depending on how many GPs, Hospitals and others use the services. But the organisatons with the highest number of users are Cabinet Office, Ministry of Justice and Home Office, followed, oddly by MoD, DfE, DWP and HMCTS. No NHS. So we don’t know.

What’s perhaps odd about the £175m savings is that it is quoted as £35m/year for the next 5 years. That is, it doesn’t increase (or decrease). That suggests that there will be no more users, no more services and no more messages sent (which, at least, is better than reducing any of those). That would be a shame – it’s a well used service, filling a clear need and one would imagine that, given that many services are still not online, and of those that are, may don’t use Notify, that there is a market opportunity.

All told, it means we have no idea what to think about the savings and whether they are real, or entirely made up (note: all numbers are made up).

This is an interesting topic, because using my patented eDt Time Machine (TM), I can go back to 2002/3 and look at the case we put together for why we should build a notification engine (we called it “Notifications” – clever, hey?) and we looked at (1) and (2) for our own case and (3) to help the services who might adopt it figure out what the benefits for them would be. We worked with a partner to do the heavy lifting and integrated it with our existing capabilities – HMRC were amongst the first users (sending text messages to say that your tax return had been received for instance).

The outloud thinking about this led to articles, such as one by Charles Arthur in May 2002, that speculated about exam results being sent by text, and another by John Lettice, and the Guardian also picked it up (it may well have been a slow news week). For the record, it came true in 2009, as I noted right here on this blog. And now, it appears that it’s even more true, although we may never know what the real numbers are.

If it’s a made up number, just say what the assumptions were when you came up with it. Transparency and all that.

10 year iterations

Opportunities for the transformation of government come along roughly once every 10 years it seems. There have been two significant efforts to drive real transformation in UK government in last two decades:

  • The early 2000s several waves of major IT change initiatives, including NHS IT, border technology, ID cards etc. Electronic government was also targetted, building on the previous administration’s “Government Direct” paper. The original 1997 pronouncement said:
    • “by 2002, 25% of dealings with Government should be capable of being done by the public electronically, that 50% of dealings should be capable of electronic delivery by 2005 and 100% by 2008”
  • 2010 brought the the creation of GDS, a big focus on agile and digital exemaplers along with spend controls. Key pronouncements there included:
    • “Government ICT is vital for the delivery of efficient, cost-effective public services which are responsive to the needs of citizens and businesses.
    • Digitising transactional services will save people and businesses time and money; by making transactions faster, reducing the number of failed transactions and simplifying the end-to-end process.

Now, it could be that big waves of change come with changes of Administration – the Blair government in 1997 and the Coalition in 2010.

Or it could be that large organisations, such as the civil service, can only handle significant change on a decade long cycle – it takes time to define goals, communicate, shed previous work, mobilise new teams, align funding and get into delivery.

At the beginning of the change cycle, there is enthusiasm and excitement, occasionally more heat than light perhaps, but nonetheless, a desire to get things done. As the decade draws to a close, everyone is tired, change is harder and less and less is done. You can perhaps see some of that tiredness in Gerry Gavigan’s “short history of government digital strategies” published in 2012.

As this decade draws t0 a close and the new one begins, we might be ready for a new approach.

One that brings a clear strategy and plan but that also recognises the need to work out how to keep momementum going over a 10 year cycle, avoiding the big bang start and the drawn out slowdown.

One that mobilises teams across government and its industry and third sector partners and that allows for inevitable fatigure, rotation of staff and the funding cycle.

One that sets long term goals, but also makes clear the steps along the way that will be required to meet those goals and that, in so doing, will demonstrate the progress that is being made on a monthly, quarterly and annual cycle.

Hockey Sticks Abound

We love our targets. By 2040 we will no longer allow diesel and petrol cars to be sold in the UK. By 2050 we will be a net zero economy. By 2030 government will be joined up and trusted (as I wrote about yesterday).

Ever since 2000 when the goal was to get “100% of government online by 2005” these hockey stick goals (I’m quite sure I didn’t coin the term, but someone in the Office of the e-Envoy likely did) have become prevalent. They’re called hockey stick because the implementation plan looks – for all of them – like this:

The current set of goals are no different. Such long term goals are loved, mostly by those pronouncing them, because they’re thought to be visionary and inspiring. Send a man to the moon, bring him back alive, do it by the end of the decade and all that.

The trouble is they’re not inspiring and they’re not visionary. Not unless they come with a plan and some actions that will take place week to week, month to month and year to year to make them so. I don’t mind if the target is missed – anything far enough away has significant uncertainties in both the dimension of the goal and the timing – but I do mind when the goal is just thrown out there as a sound bite without any thinking about what it will take to achieve it and certainly when there’s no plan.

Stairway To Nowhere

By nature I’m an optimist. I expect people to be good and to do the right thing, I expect that tomorrow will be better than today and next year better than this year. I expect that we will make progress. I expect that we will learn from what has gone before and do our best to make fewer of those same mistakes.

That said, as the header of the blog says, I am “largely disappointed by digital transformation” … and pessimistic about how we make real, positive change happen. We seem to be in a loop, doing much of what has been done before, making some localised improvements but nothing on a macro scale.

I’m adding a tag to my blog “stairway to nowhere” to give me a place to look at why this is so and what we might do about it and how we might start.