I think a competition is a great idea in theory, but in practice is unlikely given procurement regulations, cultural issues, bureaucratic fears, etc
The part that still relies on the mainframe is the entitlement calculation - all the very complex rules which determine what payments each claimant is entitled to. Other aspects have already been moved to (or at least duplicated in) non-mainframe systems, e.g. SAP CRM. Those entitlement rules are written in SOUL, Model 204’s 4GL; a team of programmers in Canberra are kept busy constantly translating legislative updates into SOUL (the government can’t resist the urge to constantly tinker with the details of social security law, so almost every year brings at least a few minor changes, and every few years major ones).
Since this is basically business rules, they decided to use a Java-based low-code/no-code business rules automation platform as a replacement, and tirelessly translated all the business rules encoded in the SOUL code into it. And they succeeded functionally - the new system produced the same results as the old one - but the performance was worse by orders of magnitude, and since it was fundamentally single-threaded (time to process a single record - maybe in theory you could parallelize aspects of it but I doubt either old or new system were) - it wasn’t a problem you could solve just by throwing more hardware at it.
Idea I have: keep the SOUL code as-is, and build a SOUL compiler for Linux (e.g. using LLVM). Or even just transpile the SOUL code into C. Totally doable, likely to give similar performance to the original mainframe system… Of course, that wouldn’t solve the problem of “system written in obscure language almost nobody knows any more”, but at least could get it on to a mainstream platform
but… people with the skill set to do this are unlikely to be interested in a government job with a rather limited salary…
And, in most countries, government agencies are strangled by procurement rules which attract firms which are adept at negotiating those rules, even if not always so adept at successfully solving the underlying problem… meanwhile, other firms which might be highly adept at the underlying problem take one look at those rules and think “this isn’t worth it”
The part that still relies on the mainframe is the entitlement calculation - all the very complex rules which determine what payments each claimant is entitled to. Other aspects have already been moved to (or at least duplicated in) non-mainframe systems, e.g. SAP CRM. Those entitlement rules are written in SOUL, Model 204’s 4GL; a team of programmers in Canberra are kept busy constantly translating legislative updates into SOUL (the government can’t resist the urge to constantly tinker with the details of social security law, so almost every year brings at least a few minor changes, and every few years major ones).
Since this is basically business rules, they decided to use a Java-based low-code/no-code business rules automation platform as a replacement, and tirelessly translated all the business rules encoded in the SOUL code into it. And they succeeded functionally - the new system produced the same results as the old one - but the performance was worse by orders of magnitude, and since it was fundamentally single-threaded (time to process a single record - maybe in theory you could parallelize aspects of it but I doubt either old or new system were) - it wasn’t a problem you could solve just by throwing more hardware at it.
Idea I have: keep the SOUL code as-is, and build a SOUL compiler for Linux (e.g. using LLVM). Or even just transpile the SOUL code into C. Totally doable, likely to give similar performance to the original mainframe system… Of course, that wouldn’t solve the problem of “system written in obscure language almost nobody knows any more”, but at least could get it on to a mainstream platform
but… people with the skill set to do this are unlikely to be interested in a government job with a rather limited salary…
And, in most countries, government agencies are strangled by procurement rules which attract firms which are adept at negotiating those rules, even if not always so adept at successfully solving the underlying problem… meanwhile, other firms which might be highly adept at the underlying problem take one look at those rules and think “this isn’t worth it”