Core Banking System Transformation From Project to Production – Why It Is Dreaded and How to Improve the Experience

At one time or another, banks have undertaken Core Banking System (CBS) transformation. This is accomplished through an upgrade or a complete replacement. Irrespective of the method adopted, these projects are considered risky and most CIOs will avoid them if possible. The reasons for undertaking these projects vary; sometimes it is to keep pace with technology. At other times, it is to take advantage of new features, respond to market dynamics, or a combination of these reasons. Even with the best consultants and risk mitigation measures, CIOs still face these projects with a lot of trepidation knowing that failure may impair their career.

Finally the big day comes, after all of the hard work and perhaps sleepless nights. The much-anticipated new system goes into production. Calls start coming in from users and customers alike with reports about ATMs and other channels not functioning, wrong account balances, inaccurate statements, certain features unavailable, etc. This situation may remain for weeks or months until the system is eventually stabilized. In extreme cases and faced with frustration, some banks will make the decision to roll back to the previous system. By the time the dust settles, the responsible CIO’s reputation at the bank would have been thoroughly diminished.

The above scenario has happened repeatedly in banks across the globe. The question is should this be the case? Can these projects be approached differently to make the outcome more predictable?

Ineffective or inadequate testing is often at the heart of this problem: how banks think about testing, the way they test, and what they test. Until banks begin to pay proper attention to testing, the outcome of CBS transformation projects will continue to be self-defeating.

The following are reasons for my assertion:

1. Failure to plan and budget for testing as a separate project activity
In planning CBS projects, banks, especially those in the emerging markets, will allocate a budget to cover the cost of implementation consultants. However, the budget often fails to recognize that testing should be accorded equal importance through the allocation of dedicated funding. Due to this oversight, the testing strategy that will emerge will usually be insufficient, the infrastructure to support the testing will be minimal, and even the people assigned to carry out the testing will be largely underequipped. This makes testing become a sideshow rather than a key project deliverable, and results in a dreadful post go-live experience.

2. Expectations that the implementation consultants should double as the testers
Many banks expect their implementation consultants to take up the responsibility for testing the software. This is not only unsafe, but it also creates a potential conflict of interest for the implementation company. Naturally, these companies will pay more attention to their area of core competence. Testing will not be given the attention it deserves and will bring forth disruptive incidents at production. 

3. Reliance on employees for testing
For cost saving and other reasons, banks sometimes opt to use business users as testers. While this approach may have relevance when it comes to user acceptance testing (UAT), leaving testing solely to end-users results in a doubtful outcome. Technical areas such as boundary value analysis, negative tests, stress tests, and performance tests will never be scoped if tests are left to be run by business users. These oversights will cause serious performance issues and a late, damning realization that the business users have largely focused on happy-path tests. Banks that have opted to establish their own internal testing department have struggled to keep up with the constant evolving test technology, and have been unable to attract and retain experienced testers.

4. Inadequate infrastructure
Generally, banks will prioritize investment in the production and disaster recovery infrastructure. For the development and testing infrastructure, the belief is that they can get by with an older or second grade infrastructure. Whilst this may work in certain situations, it may lead to unexpected failure in others. One consequence of this is that the system that performs well on the test environment may not function well on the production environment. This has been known to result in system performance or instability issues that have caught many banks unprepared.

Some banks have been known to invest colossal sums of money in testing tools only for them to realize that the tools are too complex for noncareer testers. A vast amount of knowledge transfer is required from the supplier with no guarantee that the trained resources will be available long enough to become productive. This is where testing-as-a-service (TaaS) becomes useful.

Having identified the reasons testing stands out as a major culprit for most CBS post go-live challenges, what are the solutions?

Treat testing as a separate project to run in parallel with your CBS transformation project and allocate to it a separate budget. This budget should include what will be spent acquiring suitable testing expertise and infrastructure. Fortunately, the use of cloud will allow a bank to scale up and scale down as required without the need for huge upfront investment.

Identify an independent testing company to work alongside your implementing consultant with the specific mandate for testing the software that is being implemented. This separation of duties will provide focused attention and go a long way to improve your production quality. The entity should possess strong expertise in banking or in the underlying technology. This way your bank will be working with an entity who truly knows what to test. A group of testers with no relevant expertise will encounter a steep learning curve that may take time to overcome.

Business users are not automatically good testers. They may not have the discipline to execute all of your test cases without guidance. Use your employees wisely and only ask them to test scenarios that are related to their specific duties, and that cannot be tested by the independent testing entity.

Testing as a Service (TaaS) effectively offloads the burden of building test capacity and eliminates the costs involved. TaaS vendors will come with their own tools, and trained test engineers who will work with your business teams. They will focus on delivery so that you can focus on your core business.

Finally, consider test automation where applicable. This may be laborious and time consuming initially, but if done right with mechanisms put in place for regular updates of the automated test cases, your bank will derive the benefit during future regression runs. An expert will not only automate your test cases, but they will also ensure that it stays current even as your business changes.

CBS evolution is inevitable and bank CIOs will continue to undertake these projects. The question is whether your bank is prepared to do what is necessary to reduce the risks of the project. Eliminating the risk posed by inadequate testing is a significant way to make these projects much more predictable.

At SG NewTech, being part of Software Group, we have worked with banks and microfinance institutions across the globe as advisors, consultants and co-innovators. Our Quality Assurance and Software Testing service T’Factory ‘s main goal is to help financial institutions go live confidently and remain live confidently.

Contact us if you are interested in learning more about our offerings.