Migration of legacy systems

Capita SelectaSoftware Engineering and Technology

Migration of Legacy Systems(Adapted from chapters 6 & 7 – Software Evolution)

Hong-Phu Nguyen ([email protected])

April 1, 2009

04/09/23 Migration of Legacy Systems 2

Outline

Introduction Part 1 – Architectural Transformations (Ch7)

From Legacy to Three-Tier and Services Service Oriented Architecture The Approach to Architectural Transformation

Part 2 – Data-centered Migration (Ch6) Migration Reference Model The Transformation Approach Conversions

Conclusions Q&A


Introduction

What is Migration of Legacy Information Systems? Why?

Business dimension of evolution Technological dimension of evolution

Adapting an information system to technological changes = migration

Dimensions of Migration Language User Interface Database Platform and Architecture


System Migration: State of the Art

Two migration strategies: Rewriting the legacy systems from scratch Migrating by small incremental steps

Language dimension Dialect conversion API migration Language migration

User Interface Dimension Migrating user interfaces to modern platforms


System Migration: State of the Art

Platform and Architecture Dimensions Towards distributed architectures Towards object-oriented platforms Towards aspect-orientation Towards service-oriented architectures

Database Dimension i.e. Migrating relational database to object-

oriented database technology Database reengineering


Outline




Conclusions Q&A


Part 1- Architectural Transformations

Architectural Transformations: From Legacy to Three-Tier and Services

Service Oriented Architecture (SOA) Most existing legacy systems are being

migrating to SOA Gartner: ““through 2008, at least 65 percent of

custom developed services for new SOA projects will be implemented via wrapping or reengineering of established applications (0.8 probability)”.


Why SOA?

Legacy systems must be reused rather than replaced The promise of integrating applications on disparate

heterogeneous platforms CORBA

Need of an architectural framework which allows the assembly of components and services for the rapid, and even dynamic, delivery of solutions

SOA is the best platform for carrying existing IT assets into the future?


Why SOA? (IBM)


Why SOA?

Benefits of deploying a service-oriented architecture Leverage existing assets: Legacy systems can

be encapsulated and accessed via Web service interfaces

Infrastructure, a commodity Faster time-to-market Reduced cost Risk mitigation


From Legacy to Three-Tier and Services

Migrating to a service-oriented architecture Six basic SOA principles

Well-defined interfaces Loose coupling Logical and physical separation of business

logic from presentation logic Highly reusable services Coarse-grained granularity Multi-party & business process orientation


From Legacy Systems to Three-Tier Systems and Services

Technological Decomposition Logical and physical separation of business

logic from presentation logic Reusable Services

Highly reusable services Functional Decomposition

Coarse-grained granularity Multi-party & business process orientation


Common legacy enterprise IT infrastructure (IBM)


Technological Decomposition

Legacy applications ~ “architectural spaghetti” Business process is tightly coupled with the

presentation logic. Tight coupling between applications.

Decoupling of the code is required. Reengineering towards SOA: architectural

transformation towards a multi-tiered architecture.

Business processes are formed as services


Reusable Services

Legacy systems ~ “silos”: lots of functionality is redundant or duplicated.

SOA: services should be called by more than one application.

Prior identification of reusable services across multiple functional domains.

Refactoring redundant functionality to reusable services is vital.


Functional Decomposition


The Approach to Architectural Transformation

Horseshoe Model

ArchitectureRecovery

Architecture

Transformation Architecture-based

developmentwww.sei.cmu.edu


Methodology


Code Annotation

Source code is annotated by code categories The code categories depend on the target

architecture. Technology paradigm Intended functional decomposition of target

system


Reverse Engineering

A graph model is created from the annotated source code.

R1 – the relation of source code and source graph model.

Translation: AST representation => graph-based representation.

Why graph representation? Language independence Intuitive transformation


Redesign

Source graph model is restructured to target graph model.

R2 – the relation of source code and target graph model. Support the code generation

Code category-driven transformation is specified by graph transformation rules.


Example of graph model


Forward Engineering

The target code is either generated from The target graph model and the original source

code

Or The use of refactoring at code level

The whole process can be iterated. Good for migrating to a SOA

Transformation into a three-tier architecture Decomposition into functional components


Redesign by Graph Transformation

Metamodelling with Typed Graphs Rule-Based Model Transformations Well-Defineness and Correctness of

Transformations Partial Correctness Total Correctness Uniqueness


Implementation and Example

To do


Outline




Conclusions Q&A


Part 2 – Data-centered Migration

A practical approach to data-intensive application reengineering based on The data The programs

Conversion of the database to a new data management paradigm

Adaptation of the application programs to the migrated database schema and to the target data management system


Migration Reference Model


Migration Reference Model

Schema conversion (1) Recovering the conceptual schema

expressing the semantics of the source data structure (database reverse engineering)

(2) Deriving the target physical schema from the conceptual schema

Data conversion Program conversion


Migration Strategies

The database dimension (D) Physical conversion (D1): without attempting

any semantic interpretation. Conceptual conversion (D2): more expensive

The program dimension (P) Wrappers (P1) Statement rewriting (P2) Logic rewriting (P3)


The Transformation Approach

Schema transformation Compound schema transformation Transformation history and schema mapping Program transformation


Schema Conversion

Two transformation strategies: Physical schema conversion (D1) simulates the

explicit constructs of the legacy database into the target DMS

Conceptual schema conversion (D2): the complete semantics of the legacy database is retrieved and represented to develop the new database


Physical Conversion Strategy (D1)

The DDL parsing process analyses the DDL code to retrieve the physical schema of the source database (SPS)

Schema conversion: SPS => TPS Target schema mapping


Conceptual Conversion Strategy (D2)


Data Conversion

Data migration architecture (Extract-Transform-Load ELT): converter and schema transformation Extraction of the data from the legacy database Transform these data to match the target

format Write these data in the target database


Program Conversion

Three strategies Wrapper technology (P1) maps the access

primitives onto the new database via wrapper Statement rewriting (P2) replaces each

statement with its equivalent in the new DMS Logic rewriting (P3) rewrites the access logic to

comply with the DML of the new DMS


Wrapper Strategy (P1)

A wrapper allows the data managed by a new DMS to be accessed by the legacy programs.


Statement Rewriting (P2)

Replacing legacy DMS-DML statements with native DML statements of the new DMS. Physical schema conversion (D1)

SPS-to-TPS mapping The conversion process can be easily automated

Conceptual schema conversion (D2) Flattens complex source structures in the target

relational schema Substitution process is more complex than D1 The conversion process can be fully automated


Logic Rewriting (P3)

The program is rewritten Access the new data structures

In-depth understanding of the program logic is required

Methodology (1) identifying the file access statements (2) identifying and understanding the

statements and the data objects (3) rewriting these statements as a whole and

redefining these data objects


Anything else in chapter 6?

Tool Support Industrial Application Strategies Comparison

Database Conversion Strategies: D1 vs. D2 Program Conversion Strategies: P1 vs. P2 vs.

P3 System Migration Strategies: Six Combinations


Conclusions

In theory, theory and practice are the same. In practice, they are not. – Laurence

Apply a tool to a case of migrating to SOA


Thanks for your attention!

Migration of legacy systems

Documents