In this case, the entire data set of the existing IT systems must be "transferred" to the new one, system migration will take place.
However, it is important what quality of IT system migration we perform. Indeed, an incomplete or flawed system migration could cause group-wide, costly and long-term damage, as was a particular example of British TSB Bank in 2018, when it detached from the Lloyds Banking Group (LBG) system to switch to the Spanish company Banco Sabadell applied software.
What was wrong? In this article, we briefly present the mistake that fit into bankers’ nightmares, analyze the wrong decisions, and provide an overview of how banking IT systems could have been correctly migrated and avoid CEO resignation.
TSB Bank's migration project has been struggling from the beginning and has not been properly prepared. It was a redesign of a complex legacy system with only a narrow 18-month timeframe, which of course exceeded the planned deadline - at an additional cost of almost £ 70 million, as LBG still had to pay for the old system. Another fundamental flaw in the project was that responsibilities were not clearly defined and experts in the new system were not given access to the old one.
However, the real trouble came from system arming, almost immediately after departure an error occurred in (1) the transfer of bank transactions, (2) customers could not access their account, (3) many customer had access to other customer’s account details, (4) irrational amounts appeared in the accounts and other similar faults.
The complaints flooded in, after a while the customer service couldn’t even handle it; Twitter was also loud from dissatisfied customers, and the press also began to write about the incident - which is not surprising given the size and severity of the case. To top it all off, British Financial Ombudsman and Financial Conduct Authority (FCA) have also launched proceedings against TSB Bank.
When it became clear that the chaotic situation would not be resolved in-house, management turned to an IBM team of experts for help. Their report shows that the size and complexity of the banking IT system migration project posed a high risk, therefore “world-class organized planning and systematic testing” would have been expected.
However, IBM did not find a trace of everything or the strict requirements for live deployment. According to some theories, the reason for the system collapse may have been that the testing of the test plants was not complete, yet the management still decided on a sharp commissioning: risky and lost.
As a result of the incident, the bank’s CEO, Paul Pester, was forced to resign.
The case of TBS Bank is a very instructive example of the importance of proper testing and the catastrophic consequences of failing to do so. As IBM found, the bank should have applied more comprehensive testing processes that could improve a wide range of situations.
With test automation, all this could have been avoided, because tested software is much more reliable at identify possible errors and is much more likely to migrate IT systems without a problem. Manual testing also has its place and function, but it also has its shortcomings.
For a project of this size, such as the migration of TBS Bank’s system, manual testing works with too large a margin of error. On the one hand, repeated manual execution of tests quickly becomes monotonous, which increases the chance of the error due to the human factor. In addition, time-consuming and resource-intensive, test automation can perform a larger number of test runs in the same amount of time compared to manual testing.
Overall, automated testing results in a better tested application, which is essential to prevent TSB-like situations. Therefore, the Bulgarian DSK Bank commissioned KPMG and ProofIT specialists to design and conduct automated performance testing when migrating its systems.
If an IT system is better tested, the potential risks can be recognized in greater depth. Perhaps if TSB leaders had been aware of the risk they were taking with the sharpening, they would have preferred to wait with it or opt for a partial introduction.
Certain test automation tools can help in a deeper understanding of a software - such as the product of ProofIT Ltd., the domestically developed ACE (Automated Conformance Evaluation). With these tools, test runs are evaluated immediately and automatically, so we can get continuous feedback on the status of the tested application.
Thanks to this feedback, it is possible to make more informed decisions, as a result of which the errors that go into sharp operation will already be known and a strategy has been developed to deal with them. This avoids a situation where the involvement of an external expert is already required.
However, with test automation, it can be expected that similar, drastic errors will be less, as potential anomalies can be detected at an early stage of development, making them easier and less costly to repair. This makes operations more predictable, which also contributes greatly to assessing future risk.
If your company is about to introduce a new system, the history of TSB can be an instructive example for it. The risks associated with switching can never be completely eliminated, but they can be controlled by properly designed and executed testing. ProofIT Ltd. has created the ACE test automation product and service package to reliably and easily facilitate the transition during such complex processes.
Forrás:
