Phase II of the Core Transformation Journey - Getting There
1 like270 views
The document discusses the challenges and best practices of data migration during the core transformation journey in banking, emphasizing the importance of thorough testing and risk management strategies. It outlines the technical intricacies involved, such as ensuring data quality and proper mapping, as well as the need for robust disaster recovery plans to maintain business continuity. Recommendations include the use of phased implementation, regular audits, and proactive monitoring to mitigate risks associated with migration and system failures.
Phase II of the Core Transformation Journey - Getting There
- 1. Phase II of the Core Transformation Journey: Getting There Universal Banking Solution System Integration Consulting Business Process Outsourcing
- 2. An earlier paper discussed ways to secure the is advisable to cleanse it prior to migration in order buy-in of top management and key stakeholders to avoid the same flaws being carried over to the for a core transformation decision. In this, we new system. Corrective options include data touch upon some of the IT challenges during and quality tools, simple manual effort or assumption after transformation. of default values until the right ones become available. Typically, banks have built layers of IT infrastructure, from mainframe and client server Incomplete migration of existing data: To prevent applications to ERP systems and custom partial data migration, a complete data dictionary applications, creating an IT snarl beset with of the existing system is needed to match all data problems of cost, rigidity and lethargy. Ensuring elements with the corresponding ones in the new the peaceful co-existence of new applications with system. Auditing and testing with migrated data the old is one of the challenges of core through one or more simulation runs prior to going transformation. Another is the minimization of live is highly recommended. Reverse mapping of risks during data migration. All this while, the bank data from the new system to the existing one has to ensure that business is disrupted as little as works as a secondary check. possible, preferably not at all. Quality issues in migrated data not seen in old Getting Applications to Co-Exist data: Quality issues cropping up in the new system on account of the following reasons are The way to get new and legacy applications to trickier to handle: communicate is by defining the right enterprise architecture, which ironically involves adding a a. A bug in the new system layer of Service Oriented Architecture (SOA) on b. Incorrect translation of old data into a new top of the others. format for the new system c. Incorrect mapping of migrated data to data The success of SOA adoption hinges on the elements of the new system – for example, a robustness of the bank’s IT policy and process mismatch between the totals on the internal framework. Putting check points where necessary counters of the two systems and automating at least some part of enforcement improves the framework’s effectiveness. These d. Wrong assumption of default values for policies determine how applications must interact, additional data elements required in the new share functionalities and generally behave with system one another. Yet again, technology provides the e. New system highlighting errors that were tools to define these policies, and once the rules masked by the old one are established within the interfacing infrastructure, all systems automatically comply. Again, there is no magic bullet for any of the above; mitigation is possible only through That apart, middleware technology can enable painstaking review, audit and testing of migrated existing applications to fit into the revised data. Also, the efficacy of data migration improves enterprise architecture by giving them a “facade” by having multiple iterations of data migration to communicate with new applications. Thus, even during the testing phase and using specialized non-standard legacy applications can interact with migration tools rather than relying on manual new systems in a standardized manner. processes. Mitigating Risks of Data Migration Different results reported by the new system despite data being correct: Sometimes, the new The risks of data migration manifest in several system throws up different results from the old forms, as described below: one, in spite of there being no variation in the migrated data. This is likely due to a difference in Quality issues with existing data: When the quality the way data is processed by the two systems or of existing data is suspect on account of the existence of a bug. Thorough testing with duplication, inaccuracy or incompleteness, it migrated data is the best preventive action. Phase II of the Core Transformation Journey: Getting There
- 3. Lack of proper control over migration scripts and the running of operations. Unfortunately, this is a programs: Often, migration scripts, programs and less than ideal world in which problems creep up tools are not subject to the same stringent controls from time to time. That being said, the risks that ensure correctness of version, patches, associated with banking transformation can be upgrades etc., as the main system. This slackness mitigated to a great extent by following these best is because of the wrong assumption that these practices: tools which are meant for one time use do not need rigorous control like the main system which Taking a phased risk-managed approach: By will be used repeatedly. Often, testing may be opting for phased implementation instead of done with one version of a migration script and big-bang transformation, banks give up quicker actual migration with another, without anyone and larger financial benefits in return for less risk detecting the discrepancy. Clearly, data migration and lower overall gains accrued gradually over the tools, scripts and programs demand the same implementation lifecycle. controls and checks as any other software. Having a risk mitigation plan: Whereas risks are Adopting data migration best practices is usually identified at the outset of any recommended for the reasons described below: transformation, mitigating actions rarely are, leaving banks floundering in the wake of disaster. • Although technical implementation can be Therefore, it is crucial to have a mitigation plan handled by the IT department, business users laid out for every significant risk. must participate in review and testing, since they are the actual owners of the data and Testing thoroughly: Likewise, a testing plan must therefore understand it best be drawn up right at the beginning and executed preferably with migrated data. Conducting multiple • Data migration should be treated not like a simulation runs across various lifecycle events parallel activity, but as an integral part of the further reduces the risk. main transformation program. The data migration strategy and plan must be decided Right-sizing infrastructure: Over-sizing may entail upfront. Any modifications to be made during additional expenditure, but under-sizing is a recipe implementation should be subject to stringent for disaster. While transforming their core change control, like any other aspect of the systems, banks need to ensure adequate program infrastructure to support the intended scale of business. • There must be a clear cutover strategy for migration, with the approach and limitations - Performance and stress testing: Performance and such as the cutover window, reconciliation stress testing, especially under peak load approach / window, fallback strategy and utilization helps banks to assess the readiness channel cutover strategy - highlighted in order to and stability of their infrastructure. prevent business disruption Monitoring proactively: Banks must establish alert Ensuring Business Continuity and monitoring mechanisms to detect impending problems well in time during the core systems Besides data migration, there are several sources implementation lifecycle. of risk to business continuity - unexpected events, systemic failure or a failed core transformation - Auditing regularly: While pre-implementation audit each of which must be managed. is necessary to highlight issues that might crop up on going live, post-implementation audit could In theory, a perfectly planned and executed core send out an early warning signal of impending systems transformation should pose no threat to problems after switchover. Phase II of the Core Transformation Journey: Getting There
- 4. Conducting preventive maintenance and Of course, the best safeguard for the bank is to be upgrades: This improves reliability and minimizes able to switch over to a completely manual mode chances of failure. and still provide essential banking services when all systems fail, much like the airline industry Having a rollback plan: In the extreme case of total which issues manual boarding passes if computer failure after switchover, it may be necessary to systems fail, so that customers may still fly. revert to the old systems. Hence, a rollback plan is essential. Last but not least, banks must routinely test their disaster preparedness plans even when it is not Transformation risks apart, business may be mandatory to do so. disrupted on account of natural calamity or hardware / software failure. The way to defend against this is through effective disaster recovery Author planning and execution. Balwant C Surti Ideally, banks must have an “active-active” Head - Solutions Architecture and disaster recovery infrastructure plan, which Design Group, Finacle enables automatic switchover to backup systems Infosys Technologies Limited configured to deliver a predetermined level of service; however, the financial and technological requirements may render this infeasible. In the absence of such an arrangement, manual intervention will be required to restore normalcy. While this implies a break in service, the extent of disruption can be minimized with advance planning. The risk of hardware or software failure can be mitigated by installing alternative resources which take over when the main instances go down – for example, having an additional web server helps maintain continuity when there’s an outage of the primary server. Although this creates hardware redundancy, it also imparts scalability over the longer term. Similarly, software redundancy can be built through applications that clone themselves, so that when one instance fails, another takes its place. Such practices eradicate single point sources of failure in both hardware and software to ensure business continuity. 24x7 solutions with the in-built capability to switch to a stand-in application / offer a graded level of fallback in the event of failure provide additional defence against business disruption. Ideally, all business critical applications must have this feature. When applications are not 24x7 enabled, it is possible to compensate that through third party solutions – for example, when the functioning of a web server is interrupted, a third party solution could redirect web traffic seamlessly to alternative servers. Phase II of the Core Transformation Journey: Getting There
- 5. Join us on Twitter, LinkedIn and Finacle Whiteboard at www.infosys.com/finacle/networking.asp