TSB testing inadequate ahead of IT migration - IBM report

TSB testing inadequate ahead of IT migration - IBM report

TSB may not have carried out enough testing ahead of its notoriously botched migration to a new IT system in April, according to an early report from a team of IBM specialists brought in by the bank.

With customers locked out of accounts for days on end thanks to its disastrous switch to a new platform provided by Spanish parent Banco Sabadell, TSB brought in IBM to help it work out what went wrong.

In an initial report written as the problems still raged on 29 April, but only just released by the Treasury Select committee of MPs investigating the issue, IBM noted the complexity of the migration.

Yet, says the report: "Performance testing did not provide the required evidence of capacity and the lack of active-active test environments have materialised risk".

It continues: "IBM has not seen evidence of the application of a rigorous set of go-live criteria to prove production readiness."

Three days after the report was written, TSB chief Paul Pester told the Treasury Select Committee that the migration was not rushed through to meet bonus targets.

The newly released report includes a note from TSB stating: "It contains a preliminary work plan with very early hypotheses, produced after just three days of engagement with TSB.

"These hypotheses were not final nor were they a validated view of what went wrong or of the actions that may or may not subsequently have been taken."

Another report into the meltdown, from law firm Slaughter & May, is currently being written.

Read the IBM report:

Download the document now 723 kb (Chrome HTML Document)

Comments: (2)

A Finextra member
A Finextra member 22 June, 2018, 17:442 likes 2 likes

I wonder how much IBM charged for stating the obvious?

A Finextra member
A Finextra member 06 July, 2018, 03:23Be the first to give this comment the thumbs up 0 likes

For concrete actions, the last page of the report is the best. Missing 2 things:

1. Which layer has the problem? For example, Microservices can end up with multiple calls to the database layer, or they can take too much processing time on the application server.

2. Take off some of the load by "manual"-ising the operations, ie: sending the traffic normally going through the internet to a (human) service center - after sorting out the routing issues to the call center and increasing people.