What we mean when we talk about legacy: mindset, architecture, data and Dave

Within bank walls, “legacy” is the curse of the pharaohs

“Legacy” tends to be a positive word in most environments. It denotes successful and mostly uninterrupted history. It connects present endeavours to past and future. It is considered an asset. Something to be proud of.

Then you start working in a bank and you find out that, within our walls, “legacy” is the curse of the pharaohs. The thing we accuse for most things going sour. The elusive culprit that gets blamed for slow response times, lack of agility, clunky infrastructure and global warming. Legacy is at the heart of why we can’t and won’t.

We lament it, we talk about it, we blame it. But we rarely define it because we have no intention of tackling it. Not really.

So we waste time in “wait and see” innovations and risk mitigation exercises while the world races on, leaving many of us behind.

We waste time because, really, our organisations can probably afford last minute talent substitutions to their staff and high-cost-of-ownership late-to-the-party infrastructure investments; and the individuals making the decisions have probably calibrated their pension plans; but for most of the workforce this waiting is a terrible idea that they cannot afford to pick up the tab for.

So for their sakes, here’s the truth about what we mean when we talk about legacy.

People and things

Most banks are old. And so are their systems.

Most banks have evolved and grown at different speeds across markets and geographies, they have acquired, pivoted and adjusted. So have their systems.

So when we say “legacy IT” we mean systems that span the entire life history of the organisation.

We mean that the App Store you are building will have to exist alongside systems older than you. (“I put this system in place before you were born, young lady” is an actual thing I was told in a real meeting by a real person who has since retired but his system hasn’t).

We also mean systems that do similar things in similar ways can’t be swapped out without immense effort. We mean globalisation issues and the difficulty of finding people proficient in Montran. We mean things that work well but don’t scale. Things that are effective but maybe not efficient.

Things that are familiar and reliable but as idiosyncratic as the people who built them.

We talk of spaghetti diagrams and then look at the Architects with a raised eyebrow as if untangling all this was just a matter of patience.

It is not.

There is no untangling this.

So when we talk about future-proofing an organisation’s infrastructure (ambitious) or deriving some insight from the data we hold (seemingly less ambitious) we are talking about a massive undertaking that may or may not be lunacy.

And “legacy” is not the only word that takes on a different meaning here.

“Data” is a dangerous slippery thing as well, because of “legacy”.

You see, under “legacy”, data sits, quietly minding its own business, wherever you put it. But when you put it there you didn’t know the world would change and now you want to pull it out and you can barely remember where it is. So it’s a mission to find it, and when you do, and say “right, are you ready for an outing?”, your data is all distressed and has nothing to wear so extraction becomes a military operation. You blame legacy and imagine leaky systems dating back to the war.

Yet the truth is much less dramatic.

The bigger problem is not the tech we have, it’s the tech we don’t have

Our IT “lights on” bills across banking are eye-wateringly high. And yet somehow we seem to be doing most things on spreadsheets. Either because the system doing the exact thing we want doesn’t exist, or because we still suffer palpitations since the last time we had to write a business requirements document or because it’s just faster that way. Whatever the reason, a lot of our data and processing lives on spreadsheets.

We have terms for this.

There are task forces trying to limit user defined technologies (UDT) and help standardise. UDT is an undeservedly fancy name for a spreadsheet that takes half an hour to load because “this guy Dave” has created some incredible macros that are just easier to use than the multi-million dollar system complicating your spaghetti diagram.

The problem with Dave

This guy Dave is a real person. And his mammoth spreadsheet gave me and my team our first break, over a decade ago, when this guy Dave left the bank and nobody could work out how to update his macros. So we got the gig to reverse-engineer the spreadsheet into a solution that gave people the functionality Dave had and protected the bank from future Daves.

We never met Dave, but he changed our lives. Just as he’s been changing yours.

Dave had done a good thing. He solved a problem.

Dave had done a terrible thing. He solved a problem in a way that was so local and specific that, when he left, the bank was left at a loss.

That’s the problem with Daves.

They move on, up or out.

And the real legacy you are left with are hacks and workarounds that you don’t understand.

And you are lucky if Dave’s legacy is limited to a spreadsheet that is expensive to replace but specific enough that you actually know when it has stopped working.

Because most Daves work in risk or product. And their legacy are policies nobody questions, designed on the back of now long-defunct regulatory requirements, or product  brochures and term sheets with special discounts used across an entire client segment when they were only meant as a givy-get to land an important account. The problem those Daves leave you with, is you will carry on using their legacy long after it’s stopped working and you won’t even know it.

The problem with Dave is he puts things in place “for now” and then moves on and they become “forever”. That’s what legacy truly looks like, and it’s hard to get away from.

Chin up. It ain’t all bad 

Legacy is also another word for “I’ve been around a long time”. It is shorthand for balance sheet, reserves and past success; it means you have clients, a track record, a talent pool and time to get it wrong before you get it right.

Legacy says: I’ve done this well before, don’t underestimate me.

Also legacy is super quick to acquire.

A friend working for a very successful start-up in the maker universe was complaining about their legacy infrastructure issues before their fifth birthday. They built a scrappy firm, hungry to scale and ended up with a solid business rapidly globalising. Legacy is the shorthand for: I did it well and now I get to do it again but bigger and I need to change some stuff. As problems go, it’s a good one to have. That is, if you can contain Dave.

The legacy of Dave

Dirt is “matter in the wrong place”. It’s not my line but I love it because it’s true.

Tomato sauce on your spaghetti is yum. Tomato sauce on your shirt is a stain.

Although the same applies to legacy (the things that once accelerated your business now potentially hold you back), that is not the analogy I am going for. Because systems will come and go and the next set of solutions we put in place will age and need to be rethought and replaced, no matter how good they are.

No, the problem is not IT.

The problem is Dave.

And not because he moved, but because you didn’t.

Dave is the workaround master.

He is the guy who managed to get something done.

He convinced the corporate decision makers that an exceptional circumstance existed, he managed to be granted an exemption and reprieve. He is the guy who did something different in a world of shuffling feet. And it is so unthinkable that this can actually be done, that we follow Dave’s path long after he achieved whatever he was trying to do, unable to fathom another way. Unable to remember that every solution is tied to a problem on opportunity. It is not a stand-alone universe of axiomatic value. Unable to truly follow in Dave’s footsteps and have a go at a new solution ourselves.

And we lament the spaghetti architecture and the UDT, the random policies and the seemingly randomly convoluted pricing structures. We lament the legacy we are left with by successful business growth that was right for the time and place and opportunity.

Because the time and place and opportunity changed and the legacy is not fit for purpose so that is a burden and a curse and boo to legacy and boo to Dave.

And the clock keeps ticking. And time passes.

And Dave moves on because that is the sort of person he is.

I say bring Dave back.

Keep the Daves in.

The guy who found a way and created a precedent is exactly the sort of guy you need around now, to take you into the future. Today’s workaround is tomorrow’s legacy.

Get Dave back.

And give him a team to turn his workaround into something robust. And give him an architect to minimise the worst of the spaghetti. And allow for a bit of mess, life is messy.

And when in a few years’ time you are berating Dave because your digital legacy is not right for the quantum era, you will know you did right by your workforce, and your clients and your shareholders. And you may start celebrating your legacy of successful transitions, allowing you to retain business relevance and financial viability despite the changes in the world around you.

And when that happens, and it will, you may owe Dave an apology.

By Leda Glyptis

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

Leda is a lapsed academic and long-term resident of the banking ecosystem, inhabiting both start-ups and banks over the years. She is a roaming banker and all-weather geek.

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

Follow Leda on Twitter @LedaGlyptis and LinkedIn.