Skip to main content

What we can learn from TSB's IT issues

(Image credit: Image Credit: TSB)

The IT breakdown at TSB continues. Following a disastrous back-end system upgrade earlier this year, the bank hit the headlines again last month after the latest in a string of technical failures saw millions locked out of their accounts. 

Back in April, TSB’s back-end processes were catapulted into the limelight for all the wrong reasons after the failed implementation and migration of data to a new system left 1.9 million customers unable to access their digital and mobile accounts for several weeks. 

After spending recent months reassuring customers that services would be restored and improved, the IT system built by TSB’s Spanish parent company, Banco de Sabadell, crumbled yet again. This has cost the bank in both customer confidence and an exodus of senior figures including chief executive Paul Pester, who resigned in September.

So, what went wrong at TSB? And, more importantly, what can CIOs and CEOs learn from it to avoid the same IT systems nightmare?

No TLC for TSB

These failures are not about bad luck, they’re about poor measurement and management of the risks when adapting legacy systems. 

It is important to remember that this is ultimately an in-house bespoke failure. With Proteo4UK being a further version of Sabadell’s platform, Proteo, which in itself descends from a retail banking system supplied by Accenture. Sabadell and TSB’s biggest mistake was to ignore the risks associated with integrating the business into an existing platform.

The warning signs were there. Back in 2015, when Sabadell completed the takeover of TSB and confirmed its intention to migrate the UK business to a Proteo platform, experts warned that it was “high risk”. Sabadell knew that the platform would need to be adapted to comply with UK regulations and systems, a process which experts had warned could prove extremely costly. 

Whilst Sabadell had successfully completed the same migration with a number of small Spanish banks in the past, there were concerns over the complexity and ownership of TSB’s legacy system, which it has since been confirmed was still owned and controlled by Lloyds Banking Group. The success of banking organisations integrating new businesses of this size into their existing IT platforms can be described as patchy at best. 

TSB’s shares dropped as a result and Morgan Stanley analyst Huw van Steenis even commented in the FT at the time that Sabadell may have to implement a new IT platform ‘from scratch’ due to the complexities of adapting and integrating to an existing platform. Yet they still went ahead with Proteo4UK. 

This leads into another related issue, which was that TSB rushed the system live to save it from the embarrassment of an even later project release. With the lack of even a prototype or proof of concept by May and the project still not being ready by the following autumn, Sabadell decided to push back the switchover to April; an expensive delay due to the fees attached to using the old IT system in the wake. A delayed date that was met, but that still resulted in systems crumbling a matter of hours after the system went live.

Although the system may have met go-live criteria, it was proven against inadequate test plans. This can often be the case when too much of a focus is placed on positive testing, rather than negative, alongside lapses in factors such as regression testing. Not having the correct checks in place was a basic error, and one exacerbated by tight roll-out deadlines.

Lessons learned

When it comes to large-scale business critical projects such as TSB’s software upgrade, it is important to identify and closely manage risks, ensuring that the end solution is completely fit-for-purpose with an appropriate timescale for delivery and robust testing. 

We’ve all seen the images from social media of TSB and Sabadell staff celebrating what they thought had been a “flawless” execution of one of the most complex IT migrations ever undertaken. This is what makes the whole debacle even more ridiculous.  

Even for those with the internal resources like Sabadell, building a bespoke system might seem prohibitive at first, but any business must look way beyond shoehorning in an existing solution and launching it as fast as possible, particularly if that isn’t quite fit for purpose. 

TSB’s cautionary tale of failure when migrating a new business onto a legacy IT system should make others think twice before taking shortcuts. 

How to ensure a successful integration project

Stick to these best system integration practices and ensure you maximise the potential of your existing software infrastructure without any hiccups. 

1. Avoid database level integration 

For a successful integration project, amalgamate your systems using services and programming interfaces where possible. Choosing to integrate at a database level can potentially bypass a significant amount of business logic and data validation, which could have a detrimental impact upon the systems integration.

2. Research off-the-shelf product APIs

With integrating off-the-shelf products comes the issue of the considerable differences within the pre-sales and post-sales integration options, and the interfaces. The contrast in these options, partnered with poor interfaces, will turn your successfully integrated project into an isolated suite of stand-alone products. Make sure you understand the APIs restrictions of each product involved in your software integration project. 

3. Understand integration

Analysis is a key aspect of a successful integration project. With this analysis, you can gain a greater understanding of what integration is and the impact it will have on your systems, which is crucial when deciding whether your integration project will involve the replication of any data or cause any crossovers in your operating systems. 

4. Minimise data duplication

The overarching aim of your systems integration project is to eliminate complexities and ensure a more efficient and effective working process. You need your integrated systems to hold data individually, and avoid having data residing on various systems. If you do require data duplication, only enable updates on one of your systems, then simply roll out the changes – rather than having the laborious job of individual updates. Keep it separate to keep it simple. 

5. Modular releases

When you’re looking to roll out the releases of your project, the best systems integration practice is to take an often and early approach. This way, you can begin to build a working concept and model with some of or parts of your systems, rather than opting for one large release at the end of the system integration. 

Delivering the work in stages may not always be a feasible option, but opting for this methodology, alongside using proof of concepts, prototypes, minimum viable products, and beta releases can help introduce functionality to the end users as soon as possible. 

Adam Stirk, Operations Director at Audacia (opens in new tab) 

Image Credit: TSB

Adam Stirk is Operations Director at the software developer Audacia.