The art of not dying

My cousin has been in hospital for the past few weeks.

Maintaining your tech estate is not an exercise in bravery, but rather an exercise in risk management

I know. It’s not the most cheerful of openers. But stay with me here.

He needed emergency surgery over a complication that all his doctors told us they had never encountered outside a medical textbook.

Trailblazing in all the wrong ways.

He was rushed into surgery… and when he came to and we were allowed to see him, he beamed at me despite the tubes and cables and exhaustion and shouted, “Babe, I did not die!”

Now.

My first reaction was relief, because, why yes… he did not.

My second reaction was you absolute, majestic clown. Not losing your sense of humour. Even here. Even in this.

My third reaction was… man, we are setting the bar a little low aren’t we?

And yet it’s fundamental. It’s sort of the baseline of everything else working out… this not dying thing.

And you will be pleased to hear that I didn’t think about how this story applies to tech transformation at work immediately. I did not think about it while there with my cousin. But I thought about it soon after, because that is who I am as a person. And because ‘not dying’ is often the performance benchmark we set for a number of our systems, particularly the legacy ‘core’ ones.

The idea is either that… for a system dating back to the 1960s… every day it runs is a miracle of engineering, ingenuity, persistence and luck.

Or that for systems that are so fundamental and foundational, not falling over is all they need to do.

It does not matter if they run efficiently.

If 90% of credit card transactions globally run on them, success is literally them not dying. Imagine the alternative, right?

But also, not falling over is their superpower.

Built-in redundancy and resilience.

Not dying is what they are designed for. And they do it well, frankly, or they wouldn’t still be standing, several decades on.

The problem is… that is pretty much all they do well.

And with good reason.

Systems designed in the 60s had no way of imagining the world as it would be today. They could not possibly cater to what did not yet exist.

That is not a failure or a shortcoming.

But it is a fact.

While our government is discussing the boundaries of AI ethics in law, every CIO I know… behind closed doors… is under pressure to generate GenAI use cases for their organisation, wondering: “What on earth am I going to train the algo on when we struggled with API wrappers last time round?”

“What do you want me to do with the metaverse when I am batch processing transactions like I did in the 70s?”

“Do you really want me to go down the path of making the requisite changes?”

This last question is notionally posed to an imaginary CEO.

And this imaginary CEO is most likely going to say, “Why yes, we want to be and to be seen to be leaders in our field. Of course I want us to show an ability to engage with the topics of the time. So go forth and engage with (insert topic of the day here).”

And we do. With varying degrees of reluctance.

And we hope that whatever the topic is stays top of mind for the CEO and doesn’t get superseded by a different urgency, emergency or fad…

That the CEO stays in position and a leadership change doesn’t challenge the strategy.

And that the ‘we didn’t die’ rubric of the equation continues to run.

Because all the shiny new stuff is great, but not dying is more important.

Or so we thought for a very long time.

And although some of the fads will pass without leaving a trace – you cannot get me excited about the metaverse, do not even try – some changes are profound and lasting. Our world is real time and the expectation of what that means keeps evolving.

Whether you want your organisation to actively participate in the AI era that is dawning around us or not, it will happen around you.

The way API-first architectures did.

The way cloud adoption did.

And of course, there is no easy button. And of course, you want to risk-manage whatever you do. And of course, I at least would want to make the smallest possible number of risky decisions during my tenure.

So the option is to manage the risk or reduce the number of decisions.

And as regulators, competitors and customers raise the bar of what they expect our systems to be able to do, that balancing act is ever-present.

So let me tell you another story.

In this one, someone does actually die, I’m afraid.

Let’s call him Bruce. Not to protect his identity, but because I cannot for the life of me remember his actual name. So, if it is actually Bruce, please forgive me.

Bruce worked for a mid-sized American bank, but America being what it is, a mid-sized bank is bigger than Barclays.

I exaggerate. But not by much.

This bank was on an old core banking system. It doesn’t matter which.

It didn’t do much. But it didn’t die.

But in a changing world, that stability was not enough. It was necessary, but not sufficient.

As regulators pushed for real-time fraud monitoring and real-time liquidity management… and competitors started touting personalisation in their backyard… the need to change the system became pressing.

And yet the leadership prevaricated, for all the reasons we all know and understand.

And then someone spotted that, because the system had been in place for ages and a lot of customisation had taken place over the years, the only person who really knew how everything worked – the person who needed to be there to help with any outage, issue, patch or extension – was Bruce.

And Bruce was about seven years from retirement.

So, the leadership decided they had to bite the bullet.

They thought, we have seven years to come up with a strategy that allows us a risk-managed transition away from this system towards something that won’t die but also will allow us to be relevant and for the first time in years… strategic.

Back slaps all around.

The plan is devised… reviewed… amended… agonised over… and then approved.

And then Bruce dies.

Without warning or permission.

And what happened next was the oldest story in the book. The only people who could reverse-engineer the jungle of customisations were the providers’ own engineers, who were happy to oblige, but the cost was considerable, and it came with a contract extension of 30 years.

Yes, 30. You read that right. Three, zero.

Yes, yes, there were break clauses, but we all know what going to the OpCo to break a contract like that looks like. So, 30 years it was.

This is what being had over a barrel looks like, by the way. And of course, had the decision-makers known this might happen, they wouldn’t have made those decisions, in that way or in that order.

Only they do… we all know this might happen.

Because I have sat in risk committees who track the death rate among COBOL engineers who also speak the local language for the natural language component. And if those engineers are, say, five in your last count… how is just tracking their not dying a good way of managing risk?

Obviously I believe there is an alternative to this.

And I also believe that maintaining your tech estate is not an exercise in bravery, but rather an exercise in risk management. Because we want the aspiration to be considerably higher than not dying, but of course to get there… not dying is key. Not stumbling is key.

But it is not enough.

#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.