Forget legacy systems; what about legacy vendors?

I’m always blogging about replacing core systems, open source the bank, change the leadership to one that gets it and just do it.  I’m saying it so much that I’m finding myself boring.  So let’s change tack.  Who’s the vendor?

Not gonna name names, but I’ve had a few really fun discussions with banks in the last month where they tell me that their problem isn’t their legacy; it’s their legacy vendor.  They’re stuck with ABC Software and know they need to be off it, but it’s too ingrained.  The vendor has more of a proprietary lock on the bank than anything they do internally, and trying to get the vendor to adapt their software to an open sourced API and apps world is like pulling teeth.  It hurts and it bleeds a lot.

Oh dear.

Now I’ve worked with and for a variety of software firms and yes, it’s not easy to break free of the shackles of the past.  Let’s say that I’m the CEO of ABC Software and we have 100 banking clients.  I’ll bet you that 25 of those banks are the current version of our software which, for the sake of this blog, we’ll call version 5.1.  But how many are on 4.3, 4.2, 4.1?   There’s even a group of 6 who are still on variations of version 3.  There’s even a few wee pains in the derriere who are on Version 2.9 and 2.5.  So the software firm is supporting all these different guys on their different versions, and you come to me and ask me to update the whole suite of software for the FinTech World?  Hey … give me a few million more and I might consider it but, right now, I’m more concerned about what OMG Bank is doing with version 2.5 that has been so bastardised by them that I don’t even recognise it as ABC Software anymore.

Get the picture?

Now when I hear this, I always go back to basics.  If the issue is that a core system needs replacing – whether it is a bank proprietary system or one provided by a legacy software company – then the plan must be made to change it.  How do you change a rotten core system?  Well, it’s the same as how you eat an elephant, not that I eat elephants of course but, if I did, it’s one bite at a time.

So my plan would be to look at the end point I want to get to, and then work out the bite-size steps to get there.  I want to replace a core system?  OK, first I need to get the data off the old system.  Once I’ve done that, I can replicate systems with the data feeding the old system and the desired new one.  The best way to get the data sorted out is therefore to put it into an independent engine.  That way the content is independent of the processing, so I’ll never get into this handcuffed by heritage problem again.

In other words, my data migrates into a cloud based structure where applied analytics can be brought to bear.  Add into this process a sprinkle of machine learning and artificial intelligence and boom, you’re rocking and rolling.

Meantime, ABC Software can go deal with bank 2.5 and 2.9 for as long as they want.  I’m outta here.

 

Postnote:

A great illustration of the problems in this world are illustrated by the mad map of FIX Protocol versions and users.  I thought this was a standard guys?