The LEAP Process

Taking the Risk Out of Innovation

LEAP minimizes the risks associated with any technology transformation by executing a number of manageable projects in advance that provide immediate benefits, ultimately preparing the legacy technology for eventual replacement.

How LEAP Works

Legacy Encapsulation Abstraction Process (LEAP) is a combination of technology along with a sequence of projects
that de-risk the transformation of core systems and flips the dismal conversion failure rate into a high success rate.

PHASE 01
Create a Roadmap
PHASE 02
Building the Blueprint
PHASE 03
Wrap and Orchestrate
PHASE 04
Upgrade Ecosystem
PHASE 05
Unify Multi-Cores
PHASE 06
New Core Setup
PHASE 07
Replace the Core
Phase 1: Planning

Create a Roadmap

Requirements, budgets, timelines, program governance, and expected business outcomes are documented.  Detailed plans can be developed over time for each phase.  It is important to identify dependencies between the different phases and any undertakings requiring extended periods.  These “long poles” can include internal development activities or identifying and acquiring third-party solutions to replace existing components of the legacy ecosystem.

Phase 2: Documenting Existing Conditions and Future State

Building the Blueprint

Document the data elements, process flows, business rules, product features and integration points of the existing core and supporting systems. This is mapped to the same information for the desired future state including new third party applications. Where new components have not yet been selected, place holders are inserted until the information is collected. Before beginning this step, identify the tools that you will use to document and maintain the data model, process model, product features and integration requirements.

Phase 3: Create New Service Layer

Wrap and Orchestrate

The next step in the LEAP is to wrap the existing core and related servicing component and create a new servicing layer, making the core “headless” in the process. In this phase, the BPM connects and orchestrates all the dis-jointed systems and human tasks to unify and automate the servicing process.The automation of all servicing tasks provides tangible cost savings by decreasing average handling times and automating post call activities. It also provides a better client experience through faster service execution and process transparency. For LEAP, the process of abstracting and putting a standardized wrapper around the core and its ecosystem sets the stage for low risk migration or consolidation of the core and other legacy components.

Phase 4: Replace or Retire

Upgrade Ecosystem

The next step in the LEAP is to replace or retire selected legacy applications in the core ecosystem that are now being orchestrated by the new servicing layer. Some legacy applications may become redundant since their functions can be easily replaced by modeling them in the BPM, content management and UI tools that were deployed in the previous core wrapping phase. New 3rd party applications that were selected to replace legacy components are also introduced in this step by creating data adaptors and APIs from the new applications to the servicing platform. The new unified desktop around the legacy core provides direct benefits for the bank and its customers while staging for a low risk core transformation.

Phase 5: Unified Desktop

Unify Multi-Cores

Connecting multiple cores with a common servicing tool combines information and servicing logic across them seamlessly.  This allows business processes to be standardized and operationally combined across multiple cores.  The multi-core unified desktop enables centers-of-excellence to be established across multiple product lines for functions like regulatory compliance, audit, fraud detection, customer complaints and the like.

Phase 6: Preparing for Conversion

New Core Setup

With the core encapsulated and the ecosystem upgraded to its future state, the majority of the bank operational staff will not be affected by the core conversion.  The remaining tasks have been reduced to preparing for the conversion of data and interfaces for those systems that will remain after the transition. The new core will have a native data schema that needs to be translated into the DDM used in the previous phases.  Once the data adaptors are verified and APIs are tested the new core can be connected to a copy of the servicing layer and ecosystem to verify functionality.

Phase 7: Replace the Core

Replace the Core

The last step is the actual conversion to the new core using live cut-over data, pre-tested data adaptors, payment system interfaces, and APIs.  A go/no-go checklist covering all relevant areas is used to manage all the tasks and get the appropriate sign-offs required to perform the conversion. It is important to resist the temptation to enable new core capabilities or introduce other systems at the same time as the core conversion.  It is also not necessary since the LEAP technology that was put in place earlier can quickly expose advanced capabilities of the core and its ecosystem after the core is replaced.