Keeping up with the times, or being ahead of it, is a necessity for financial institutions, banks in particular. This need to be ahead makes them act swiftly to changes, adopting best-case solutions to provide features to customers. These extensions over the years turn complex and expensive, ultimately hampering growth.
More and more banks are paying attention to these complexity costs that their legacy systems incur, and Temenos Transact offers them a great way to move forward. The tools available in Temenos Transact manage front and back end of banking operations, and their flexibility enables shorter to-the-market timelines, efficiently.
The Temenos upgrade options
When banks are aiming for an upgrade with Temenos, there are two mandatory activities that needs to be done: one is the runtime upgrade and other is the core application upgrade. There could also be other activities or migrations involved as the figure above highlights, but they may or may not be implemented based on the limitations and necessities.
A runtime upgrade is concerned with the Transact application framework be it C-based TAFC or java based TAFJ. While the C-based systems will be upgraded to TAFJ, the banks that are already on TAFJ will be upgraded to the latest framework. A database migration would be mandatory during the move from TAFC to TAFJ, while systems already on TAFJ can upgrade to a newer version of RDBMS as an optional activity. During this process, upgrading from a legacy operating system framework like HP UX, Solaris, or IBM AX to a modern Linux-based system.
This can also be used as an opportunity to move to a browser-based application server instead on a desktop-based one. Moving across browser-based options is possible too, say from Websphere or Weblogic to JBoss. Also, if the banks decide to only go with the technical upgrade to take advantage of features that are available in newer versions, moving customer decisions to the core feature will provide better results.
Challenges and the nitty-gritties
Upgrading Temenos has its own challenges, but these can differ from bank to bank. Broadly, these can be classified into two sections: Generic challenges and application specific challenges.
| Generic | Application Specific |
|
|
Among generic challenges, ensuring very little downtime is important for customer satisfaction. Conducting effort and cost versus benefit analysis before discoverization, and then an internal pre-analysis session to understand the impact on local developments help in this regard. The bank’s Temenos team should be involved from the beginning of the upgrade process too, and changes in infra hardware training or resource requirements should also be considered. Once these factors are known or in place, the implementation timeline can be created. These implementation timelines must also factor in the time required to be compliant with regulations and other necessities.
Factoring in hardware compatibility and infrastructure related changes allows for an accurate timeline, and the tech stack included in every Temenos release provides details about the current hardware being used. This information can be used to decide if hardware related upgrades are essential. If there is a substantial difference between the source and target release, banks can assess the technical capabilities of their internal teams based on changes in requirements and train relevant resources.
Changes on the technical front start with the backend core. While moving to a latest release, it is worth spending some time to understand if some of the local development done on the current release can be moved to core. this will save retrofitting related work, and help with better product architecture, streamlined processes and better functional capabilities. Moving a module to core helps in future upgrade as well.
Starting the upgrade process
Target release selection and prep-work before upgrade, puts details out in the open and helps in clearly defining goals and results that are expected from the upgrade. Based on these, the release to be upgraded can be selected. The options here are either the most recent release, or a stable but slightly older release. The points that need to be considered during both activities are listed below.
| Target release Selection | Pre-Upgrade Prep work |
|
|
After discussing these points internally, the organization should shortlist a few target releases. Upgrade is not only a technological change; it brings in a lot of functional changes in the newer release, so the internal discussion between banks, the IT team and the business team is important. This helps in understanding the pain areas of the business teams and the capabilities of the target release.
Stages of upgrade
There are different stages of upgrade, depending on the current state of the organization. Depending on the exact context, some of these stages might not be relevant for the organization too. This chart below lists all the different stages that can be a part of the upgrade process, and organizations are required to pick steps that make the most sense to them.
To simplify the stage selection process, here’s an example: An organization up for a pure technical upgrade should not consider the stage 4 of this process, which is related to functional upgrade in a typical technical upgrade scenario. An update will start with discovery and scoping, which requires the bank’s involvement, starts with hardware assessment. Also, some of these stages can and will run in parallel or one stage can end after the next stage.
Run-time upgrades depend on the current environment, and will be either a lower to higher release upgrade in terms of TAFC or TAFJ – or a migration if the move is from TAFC to TAFJ, which comes with its own additional steps. Technical upgrade stage is where core layout changes are done, and any new product to be implemented will be done in a parallel way. Code conversion of the target release changes in routine to make use and new improved functionalities, and can help to compare between the local developments and their source codes.
Mock upgrade strategy
Planning mocks and executing them in a timely manner is one of the most critical factors for success for an upgrade project. Here, the base pack practice approach is divided into different mock cycles:
The example of Mock cycle 4 shows how there can be multiple marks and/or cycles inside a cycle. Initial mock cycles don’t consider the local components yet but only checks how the core runs in the newer release. After that, core and local codes and multi-threaded local jobs can be conducted. These mock cycles will help in running upgrades smoothly and seamlessly.
Back to core
There are two scenarios possible with back to core – either by configuration, or with local development in addition to it. The local development part is important if the organization is currently using a process that might not be totally fitting with all the core capabilities, and can get a better architecture and lesser maintenance.
Some of the main activities during Back to core exercise are :
- Existing functionality mapping to new system/modules
- Impact assessment.
- Existing customization will be mapped to new core functionalities.
- Further gaps will be customized
- POC
- Product configuration document.
- FSD and TSD for any additional customization.
- Descoping of local Transact tables and data migration to core tables.
- Preparation of User guides and training documentation.
In the discovery and scoping phase, analysing the local development enables the IT team to identify the customizations done and the business flow that is being followed – and then compare it against the capabilities of the core modules.
During assessment. Quite a few factors need to be analysed –be it the extent of benefit resulting from the effort put in, changes that are future proof, scalability, impact on surrounding systems, usage, licencing costs and more. If an existing customization is known to store data in a local custom table, it has to be moved to the core. The process needs to have a proper user guide and training documentation, as employees and customers who are used to existing customized processes need to understand the same. The documentation can start during the analysis phase even, and must be continually updated until the module goes into UAT.
Migrating from Legacy T24 modules to latest Transact modules
This is relevant for a functional upgrade. However, similar situation may arrive even for a technical upgrade, e.g. moving away from Temenos webservice to IRIS.
Module migration during a functional upgrade evolves around two parts, first implement the new module and then migrate the data from legacy T24 module to the new module.
Below is an example showing the approach that we follow for LD to AA migration.
Conclusion
The latest upgrade from Temenos has several changes, on both business and framework fronts. Several new modules, including Temenos Insight for deep analysis and high quality reports and Temenos Payment to support seamless, high performance payment solutions, provide banks the kind of flexibility, safety and control they need. The new version of cloud-native and cloud-agnostic Temenos User Experience Platform (UXP) supports both mobile and Internet banking. These features are designed to improve performance and customer responsiveness while controlling costs. With Temenos, banks can smoothly digitize their core banking processes and regulations while staying agile. Get a perspective on Temenos Transact upgrade from this webinar recording. With the help of an experienced Temenos partner like Maveric, banks can accelerate their upgrade approach in a cost effective, non-disruptive and secure way.
