Top five considerations during planning/executions of a progressive banking core modernisation

The what and why of a banking core modernisation

The main drivers for a banking core modernisation could be either business drivers (for, e.g. New business models, process optimisation, risk and compliance, mergers) or technical drivers viz. ( End of life of underlying tech platforms, Reduction of technical debt, digitisation, deployment changes ( say on prem to the cloud )

Broadly all large banking core modernisation programs can be executed in a big bang or a phased transformational approach.

 A big bang approach to banking core modernisation is when an institution decides to work on a large program reaching the end state architecture in one go. A big bang approach may not be suitable for the large transformation programs due to the following reasons:

1. Availability of dedicated resources and organisational aspects like change adoption, training and re-skilling, redundancy management.
2. Program complexity—many applications, migration entities, multiple program streams leading to a risk of large business disruption.
3. Critical events which mandate program phasing.

Banking core modernisations can be done progressively: 

• Business segment-wise
• Business entity wise (by bank branch, by department, region or cluster)
• Application by application

Banking core modernisations that are done as progressive transformations require a well thought out approach, balancing the need for phasing and also managing the complexity like a coexistence phase. The below are some of the key considerations to determine what to transform and in what timeframe/order.

Five key considerations for planning and execution of banking core modernisations

1. Current vs end-state architecture (products, system landscape)

As part of the transformation planning, a very key decision for success would include planning the current state, intermediate and end state of the architecture and landscape of the bank. This requires a careful study of the existing landscapes of the bank and decide the order /priorities based on goals for the transformation.

2. Service catalogue and servicing points

Another aspect of planning is for the banks to consider what services they offer to their customers and their service points (Digital/ATM/Branches). In some cases, the service points (ATM's/brick and mortar branches) maybe no more relevant considering redundancy of service based on transformation goals. This ensures a transformation having the least disruption to the end customers

3. Technical considerations (systems implementation, integrations and migrations)

Migration volumes, performance tests and service expectations

With large banking core modernisations, there is more of everything to manage - This requires planning to manage underlying tech environments, performance tests, performance dry runs and multiple mock migrations to see the platform is holding up to the required service expectations. In addition, there is a need to arrive at data migration requirements for various phases to cause the least disruption in service.

Data clean up, data retention and customer communication

Large transformations are an opportunity to perform data clean-up of each system before the migration to eliminate data duplication, irrelevant and invalid data (for, e.g. closed customers.) An aspect worth considering is an archival strategy mechanism that can be employed pre-migration of data to reduce the data taken into the new landscape into the new entity. Communication planning to customers if relevant (changing account numbers, for instance.) is crucial.

 It's usually not good practice to migrate historical data to transactional applications. However, historical data is required for servicing customers and for legal / compliance reasons which determines teh data retention policies.

Integrations and coexistence strategy

IT integrations can be quite complex and would require much preparation. The starting point to this activity could be the target architecture vs current architecture gaps. An intermediate architecture landscape will evolve in a phased transformation based on capabilities offered during the coexistence phase. The integration approach is derived using the architecture for this intermediate phase. The key aspect is to maximise the reuse of integration built during this phase into the final architecture. The banks should follow all architectural principles of the end state and minimise throwaway effort. For example, an intermediate bank-wide data consolidation across systems to cater to CRM reports may need to be planned during the coexistence phase. Data ingestion aspects have to be considered as part of the coexistence strategy.

4. Human resources (Availability and skills/ management support)

Availability and skills

A crucial aspect to consider during the planning is the availability of resources and the skills they need to complete a successful transformation. This also derives the sequencing and the number of streams of work that can be spawned in parallel. Also, the number of users trained on the newer platforms needs to be kept in mind.

Management sponsorship and vendor relations

The management must have a clear vision on the end state, each milestone and be a strong sponsor to that vision. A collaborative partnership approach with all vendors involved in the merger is key to the project's success. Turnkey project approaches  are generally recipes for failures with too many moving parts in a large modernisation

5. Sunset of certain unsuitable legacy systems

Some of the legacy systems may have to sequenced earlier in the transformation due to various reasons not limited to underlying unsupported technical stack, unable to service regulatory compliance changes and impending expiry of certain vendor contracts