Your solution should work in the non-profit sector (provided the egos of NHS Trust or University leadership allow it)
Competitors in the private sector co-operating on this scale would probably run foul of anti-collusion legislation?
We have seen new entrants in banking (Revolut, Wise) and energy (Octopus) build new systems and out-compete legacy players locked into the tech debt spiral you describe so clearly
How do EDF, British Gas etc collaborate on their IT needs?
Octopus has spun off its software as a separate business and is selling that to other energy providers (no doubt carefully selected not to easily compete with Octopus)
Interestingly a lot of the banking innovation has arisen from standards like Open Banking https://www.openbanking.org.uk/ Open standards for industry supports innovation but the way ahead is customers and suppliers working together to enable innovation.
Back in the day, having this piece to hand would have really helped counter the "it'll all be fine" overconfidence of those buying (and selling!) discrete systems that it was obvious would eventually need to be made to integrate with each other.
I also recognise this from HE. I recall a VAT 'special' implementation that meant upgrades to the rest of the finance system were next to impossible.
Systems tend to have a pecking order, too: payroll, purchase ledger and sales ledger tend to get priority. And in a students system, UG gets more attention that PGT than PGR, driven by the numbers for most institutions (people and associated income).
Wearing my work hat, we are still pursuing, perhaps quixotically, the goal of empowering learners to control their own qualification (and micro-credential) data, using a digital wallet chosen from a suitably managed market. But the new infrastructure will only be possible if learning providers have modern, standards-compliant, student record systems. Few do.
So we have realised that – as you say - the need is for an ecosystem-wide change throughout HE, and indeed the education sector generally.
We are experimenting to see whether it is possible to recruit sufficient HEIs to make progress. Generally, the student experience folk in each HEI are keen; the information systems directors less so. But there is now some potential for support from Skills England, and the beginnings of interest from data taxonomy bodies, such as the EDM Association. Both may help.
Your comparison with Open Banking, made in a response to a comment, is interesting. There action was required by the CMA, and funded by fines on the 9 largest banks. They succeeded in defining and implementing certain open standards for data exchange, but avoided the case for the fundamental changes to organisational and business models needed to accommodate wallets as agents of the individual. These issues still cause trouble, and – if ever solved – may have a beneficial effect on other sectors, such as education and health.
This matches what I saw first-hand, trying to help a large software provider break out of the trap you describe of having drifted from product company to customisation-service business. We failed. The company was acquired ~15,000 jobs gone. The extinction risks for vendors are real.
One thing I'd add to the "conditions" side: worldview and culture also matter. A small minority of large commercial organisations have genuinely generative cultures. They are unusually alert to these traps, know which applications actually matter to the business, and protect investment in those even when budgets get cut everywhere else (they don't let the critical few get starved during a downturn the way most do). That same culture makes them braver about switching, so they end up as the early adopters who make new entrants viable in the first place.
So the fix isn't only collective standards and reference architectures, it's also a critical mass of early adopters, customers with the culture that empowers leaders to act.
A brilliantly informative analysis. I was closely involved in the introduction of a new student records system in the mid-2000s and even then remember it being referred to by one of the provider’s developers as ‘a beast’. The proposed strategy looks very difficult to implement though unless there is some system-wide guidance, or perhaps self-organised collaboration, that doesn’t conflict with competition law.
I saw this exact scenario several times while consulting in the FE and HE sectors.
One involved a major examination body running a large SAP ERP implementation surrounded by numerous bespoke integrations. Another was a university attempting to replace an unsupported student record system that had accumulated years of custom interfaces and local business logic.
In both cases I described the projects as "slow-burn disasters" because the technical challenge wasn't replacing the software—it was untangling years of embedded business processes. The vendors had newer products available, but there was no credible migration path.
The same pattern exists in financial services, where COBOL systems often embody decades of regulatory change, product evolution and hard-won edge cases. Much of the institutional knowledge now exists only in the code itself.
One point I'd add is that end-of-life planning, upgrade paths and maintainability should be treated as critical non-functional requirements from the outset codified in the contract rather than added as appendix or ommitted all together They're frequently overlooked in favour of delivering today's functionality, even though they're often the difference between a platform that evolves and one that eventually traps both customer and supplier.
Your solution should work in the non-profit sector (provided the egos of NHS Trust or University leadership allow it)
Competitors in the private sector co-operating on this scale would probably run foul of anti-collusion legislation?
We have seen new entrants in banking (Revolut, Wise) and energy (Octopus) build new systems and out-compete legacy players locked into the tech debt spiral you describe so clearly
How do EDF, British Gas etc collaborate on their IT needs?
Octopus has spun off its software as a separate business and is selling that to other energy providers (no doubt carefully selected not to easily compete with Octopus)
Interestingly a lot of the banking innovation has arisen from standards like Open Banking https://www.openbanking.org.uk/ Open standards for industry supports innovation but the way ahead is customers and suppliers working together to enable innovation.
Back in the day, having this piece to hand would have really helped counter the "it'll all be fine" overconfidence of those buying (and selling!) discrete systems that it was obvious would eventually need to be made to integrate with each other.
I also recognise this from HE. I recall a VAT 'special' implementation that meant upgrades to the rest of the finance system were next to impossible.
Systems tend to have a pecking order, too: payroll, purchase ledger and sales ledger tend to get priority. And in a students system, UG gets more attention that PGT than PGR, driven by the numbers for most institutions (people and associated income).
Good article. You are right.
Wearing my work hat, we are still pursuing, perhaps quixotically, the goal of empowering learners to control their own qualification (and micro-credential) data, using a digital wallet chosen from a suitably managed market. But the new infrastructure will only be possible if learning providers have modern, standards-compliant, student record systems. Few do.
So we have realised that – as you say - the need is for an ecosystem-wide change throughout HE, and indeed the education sector generally.
We are experimenting to see whether it is possible to recruit sufficient HEIs to make progress. Generally, the student experience folk in each HEI are keen; the information systems directors less so. But there is now some potential for support from Skills England, and the beginnings of interest from data taxonomy bodies, such as the EDM Association. Both may help.
Your comparison with Open Banking, made in a response to a comment, is interesting. There action was required by the CMA, and funded by fines on the 9 largest banks. They succeeded in defining and implementing certain open standards for data exchange, but avoided the case for the fundamental changes to organisational and business models needed to accommodate wallets as agents of the individual. These issues still cause trouble, and – if ever solved – may have a beneficial effect on other sectors, such as education and health.
This matches what I saw first-hand, trying to help a large software provider break out of the trap you describe of having drifted from product company to customisation-service business. We failed. The company was acquired ~15,000 jobs gone. The extinction risks for vendors are real.
One thing I'd add to the "conditions" side: worldview and culture also matter. A small minority of large commercial organisations have genuinely generative cultures. They are unusually alert to these traps, know which applications actually matter to the business, and protect investment in those even when budgets get cut everywhere else (they don't let the critical few get starved during a downturn the way most do). That same culture makes them braver about switching, so they end up as the early adopters who make new entrants viable in the first place.
So the fix isn't only collective standards and reference architectures, it's also a critical mass of early adopters, customers with the culture that empowers leaders to act.
This is an insightful observation. I concur.
A brilliantly informative analysis. I was closely involved in the introduction of a new student records system in the mid-2000s and even then remember it being referred to by one of the provider’s developers as ‘a beast’. The proposed strategy looks very difficult to implement though unless there is some system-wide guidance, or perhaps self-organised collaboration, that doesn’t conflict with competition law.
I saw this exact scenario several times while consulting in the FE and HE sectors.
One involved a major examination body running a large SAP ERP implementation surrounded by numerous bespoke integrations. Another was a university attempting to replace an unsupported student record system that had accumulated years of custom interfaces and local business logic.
In both cases I described the projects as "slow-burn disasters" because the technical challenge wasn't replacing the software—it was untangling years of embedded business processes. The vendors had newer products available, but there was no credible migration path.
The same pattern exists in financial services, where COBOL systems often embody decades of regulatory change, product evolution and hard-won edge cases. Much of the institutional knowledge now exists only in the code itself.
One point I'd add is that end-of-life planning, upgrade paths and maintainability should be treated as critical non-functional requirements from the outset codified in the contract rather than added as appendix or ommitted all together They're frequently overlooked in favour of delivering today's functionality, even though they're often the difference between a platform that evolves and one that eventually traps both customer and supplier.