A lot of business software has a short life. It's bought or built, it does its job for a few years, and then it slowly becomes the thing everyone works around, until someone decides it has to be replaced.
It doesn't have to go that way. The clinical registry we built for a Royal College has been running for nearly fifteen years. The system that runs an engineering company we work with has been in daily use for eight, and it's still growing. Neither is a museum piece: both are still being improved. Here's what we think makes the difference.
Build around the work, not the fashion
Technology changes every few years. The way a team does its work changes much more slowly. A system modelled closely on the real process, with its own terms, its own rules and its own exceptions, stays useful for as long as the process does. One modelled on whatever was fashionable at the time ages with the fashion.
Look after the data above all
Screens can be redesigned and code can be rewritten, but the data is the part that accumulates value year after year. Clear structure, rules that keep it consistent, and a record of who changed what are what make ten years of history trustworthy rather than a liability.
It also means the rest can change around it. The engineering system was given a completely new interface a few years ago, without changing the data underneath: the people using it got a modern tool, and nobody lost a single record.
Interfaces come and go. The data is what you're really building.
Test everything, automatically
The thing that stops old systems changing is fear: nobody's sure what a change might break. The answer is automated tests, small programs that check the system still behaves correctly, run every time anything changes. The engineering system now has over four thousand of them. That's what makes it safe to keep improving something that a whole company depends on.
Upgrade little and often
Every system sits on layers of technology, such as programming frameworks, databases and hosting, and all of them keep moving. Left alone for too long, the gap becomes a cliff, and the only way forward looks like starting again. Kept up to date in small, regular steps, it never becomes a project in its own right.
Even big moves can be made this way. The engineering system is moving to a new database platform now, with those tests confirming that every result comes out the same before and after.
Change when the world does
Long-lived systems have to absorb change from outside: new regulations, new reporting requirements, new ways of working. When recorded consent became a requirement before any patient could be added to the registry, it became a rule in the system. When the sensitivity of the data called for it, the database moved to a server the College controls. A system that can't adapt to that kind of change gets replaced. One that can just keeps going.
Keep the same people
The most valuable thing a long-running system has is people who understand it: why that rule exists, what that report is really for, which odd case caused which fix. Our longest-running systems are still looked after by the people who built them, which is why a change that would take a newcomer weeks to understand can be made in an afternoon.
And know when it's time
Not everything should last forever. Sometimes a system really has reached its limits, and replacing it is the right call. When that happens, it's worth doing carefully, and we've written about what that takes.
If you have a system that's been good to you and is starting to show its age, talk to us. Often it needs looking after, not replacing.