The oldest system in the building has run without interruption for 30 years. Four people understand it. None of them wrote anything down. Only one of those three facts is reassuring.
The system works. It has processed policies, claims, accounts, tax records or payments every working day for 30 years. It has survived every reorganisation, every budget cycle, every strategy that was going to replace it. It may well be the most reliable asset in the business – and it is not the risk. The risk is everything around it.
That status is the result of care: access was restricted, changes required approval and nothing was touched without reason. Yet the knowledge remained in a few heads, the documentation was never written, vendors changed and people retired. The less often the system is changed, the more frightening each change becomes, and the fewer people remain who have done one. Twenty years of prudent decisions produce a system nobody is willing to touch.
Five questions to understand legacy options
How should decision-makers deal with this situation? The experts at middleware technologies (mWtech) engage with such scenarios frequently, and have five questions one should ask:
- If the people who understand this system were gone tomorrow, what stops, and how fast?
- Which rules exist nowhere except in the code?
- When did we last change it – and did we decide not to, or were we afraid to?
- If the supplier doubles the price or drops the product, what are our options?
- Whose job is it to know all of this?
Four answers and one silence show where to look. Five silences say something more useful – and say it in a meeting rather than during an outage. The questions also provide choices: too often, a core system stays around as a default, not a decision.
Replacement starts from the wrong place
Replacement is expensive, slow and uncertain. The business case has been rejected before, and it was probably rejected correctly. Rewrites also start from the wrong place: a replacement cannot be specified for rules nobody has written down. Such programmes spend their first year discovering what the current system already does, and most are stopped before they finish.
The work is smaller than that.
Answers lead to action
Instead of treating replacement, refactoring or any other direction as an inevitability, ask the five questions, then do the following:
Write down what you depend on. Consider which parts of the business stop without this system, where the rules actually live, and who understands them today.
Open the important rules up. Pick those rules the business relies on most, and give each one a clear, documented way to be called from outside the old system. Other applications then rely on that description rather than on the system itself, or on one person. Each step becomes small enough to fund without a board paper.
Give it an owner. A position, not a person, and a date. The question comes back on a schedule, not when somebody resigns.
None of this is a programme. It is three pieces of ordinary management applied to something that has never had them.
Timing is the only variable
Every organisation running an old core system has this conversation eventually. The only question still open is whether it happens when you choose, or when something chooses for you – a resignation, a price increase, an audit, a failure. The work does not change. The cost, the time it takes, and the number of options left to you do.
Keeping the old system another 10 years may well be the right outcome – the questions and steps above make that a decision rather than a default. You can react when a supplier changes direction, and lose an experienced person without losing the work they did.
Many enterprises run long-standing core business systems they do not want to disrupt. mWtech works with many of them, and timing is the only variable. Asking the five questions is the difference between being reactive and being ready.
Share
Editorial contacts