Make mine red

I have been dining out on the stories of COBOL engineers dying out for a while now.

Does your technology need to be totally fried with smoke coming out of it to be considered ‘defunct’?

They die of ripe old age, in case you were concerned, and I take no joy from the recounting.

Nor do I take any joy from the predictability of the predicament faced by organisations who are heavily dependent on said engineers to maintain their ageing COBOL codebase with its esoteric quirks and natural language components in not widely spoken vernaculars.

I have been talking about the lunacy of it all for a while.

I have been talking about the operational complexity and risk this practice introduces.

All because people are terrified of migration conversations… or they have other, shinier things to spend their budgets on… or they have real fires to fight and this ain’t broke, so we ain’t fixin’.

Only, how do you define ‘broke’?

Does something need to be totally fried with smoke coming out of its motherboard to be considered ‘defunct’?

You wouldn’t turn up to compete at motocross with a BMX Freecoaster no matter how cool it looks and how much you love it, so why are you doing it with your operating infrastructure?

Don’t answer that.

I know why.

We all know why, and I get it. The natural antibodies of your organisation fight you every step of the way. Your career is on the line.

And every day that passes the complexity is compounded by good people trying to do the right thing incrementally.

That word, once a banner of reasonableness, has become the ultimate albatross.

About a year ago, I facilitated a closed-door roundtable on the theme of AI adoption and specifically how to avoid making all the same mistakes the FS industry had made in the adoption of almost every other new technology to date.

During the course of the conversation, a university professor put to the table a programme his team was developing, using AI tools to migrate COBOL code to Python. Of course, the conversation threatened to fall into a delightful rabbit hole of why Python and not Java, but I ruled with an iron fist and brought them back.

There were regulators in the room, so the first question was to them: what would they need to see for something like that to be palatable? It was an interesting debate, and although it was not conclusive, you could see the regulators (a diverse mix from very different geographies) were willing and able to face into the complexity of the conversation.

So, I turned to the bankers in the room and said, “Assuming all this is sorted and a path forward is cleared, what would it take for you to jump in?”

They all looked at each other and chuckled. And after a little pause, one held three fingers up and said, to general applause, “We would go third.”

Meanwhile, some companies are reputed to be pointing AI tools at their mainframes to replace the need for the COBOL engineers with their scarce skills and ailing health. And good for them. They’re doing what they need to here. But are our organisations, the ones who are going to go third if they go at all, doing what they need to?

Band-aids upon band-aids to keep things limping along while we deal with things that are on fire.

So let’s unpack this: first the fires, then the band-aids.

What would it take for something to be deemed on fire inside big organisations, when evidently having technology from the 50s processing 90% of all retail card transactions in ‘real time’ (ahem) and hoping for the best when it comes to exposure, liquidity management, AML and fincrime… isn’t… on fire?

If that is not on fire, what is?

Seriously: what is? What does it take for something to be deemed on fire?

It’s not a rhetorical question. It has a very specific answer. And the answer is that ‘one of the following three things needs to be true’:

• It’s something the regulator says won’t do.
• It’s something an important client (think material share of wallet) says won’t do.
• It’s an event like an outage or a competitor winning a big deal or gaining a strategic advantage.

End of list.

These three things are how you get to the top of the ‘attention span and budget’ list.

Now, increasingly, system resilience, responsiveness and capability management are making all three of those rubrics, but not yet in a holistic way.

So, to add to my roundtable friends’ answer.

What would it take for one of them to move on system modernisation across the board? They would need the industry to be well and truly on the road to doing it wholesale and/or one of the above to apply simultaneously.

If you are thinking ‘I may have retired by then’, then join the club. We have t-shirts.

The t-shirts come in all sizes but only two colours:

Blue for the ‘I hope I have retired by then’ camp and fire-engine, apoplectic red for the rest of us who think we are already late with this.

But honestly, where does all this leave us? Other than in two camps, the blues and the reds.

And we all know, both the blues and the reds know, the operational challenges of trying to do 2024 things with 1954 tech.

In fact, the business of balancing ‘wrappers’ and extensions and shadow ledgers and ‘brown field’ initiatives is thriving and, arguably, bigger now than the problem it tried to contain. Because now the solution (read: band-aid) is a problem in itself.

The band-aids that were meant to help us focus on the fires have become a blazing inferno of complexity themselves.

So even if you mustered the courage to deal with the antiquities… what do you do with 70 years of accumulated… band-aid-shaped stuff… all around your creaking legacy?

The answer is always ‘you do what you do with the elephant’.

Don’t look at me like that. ‘How do you eat an elephant? One bite at a time.’

There is no other way. One step at a time is how you get anywhere, with working out teleportation being on the to-do list, straight after ‘switch off ancient systems’.

I joke. But I don’t.

I have spent my entire career trying to persuade organisations to make material, deep changes to their tech estates before there was a fire to put out. It has been exhausting work, but it has its moments.

And yet the moment is past.

In a world of deepfakes, real-time connectivity and regulatory scrutiny over resilience, responsiveness and supply chain ‘trailing risks’ (a wonderfully cute name for a very scary set of implications), I say that not knowing in real time whether your organisation is whole… is a very dangerous place to be.

I would call that level of danger definitively: on fire.

What we could have done in our own time and with the benefit of optionality now has to be done under duress.

But no matter.

Help is at hand. There are tools to risk-manage the process. There are partners who have done this before, in other industries as well as ours. Plus, we like putting out fires, right? It’s what careers are made of in FS. That is a pattern we understand.

So.

Sadly, it’s bad news for the crew that picked the blue t-shirt, the ‘I hope I have retired by the time we need to do the hard work of modernising our critical technology’ crew.

For the rest of us: pick your t-shirts and get to work.

I’ll have red.

#LedaWrites

Leda Glyptis is FinTech Futures’ resident thought provocateur – she leads, writes on, lives and breathes transformation and digital disruption.

She is a recovering banker, lapsed academic and long-term resident of the banking ecosystem. 

Leda is also a published author – her first book, Bankers Like Us: Dispatches from an Industry in Transition, is available to order here.

All opinions are her own. You can’t have them – but you are welcome to debate and comment!

Follow Leda on X @LedaGlyptis and LinkedIn.