Migration of legacy systems
Upcoming SlideShare
Loading in...5
×
 

Migration of legacy systems

on

  • 1,337 views

 

Statistics

Views

Total Views
1,337
Views on SlideShare
1,337
Embed Views
0

Actions

Likes
1
Downloads
54
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • Gartner , Inc. ( NYSE :  IT ) is an information technology research and advisory firm headquartered in Stamford , Connecticut
  • Well-defined SOA framework: Infrastructure development and deployment will become more consistent across all the different enterprise applications
  • One of the IT challenges that could be noticed from the diagram above is that most of the applications communicate directly to each other. Such dependency may become a real problem when an application needs to be modified or phased out. Any modification may lead to updating each unique communication line in its own way. Therefore, such changes may become a costly endeavor. This situation is called tight coupling between applications and is becoming a real head-ache for some enterprises.
  • DMS – Data Management System
  • DDL – Data Description Language
  • DML – Data Manipulation Language
  • SPS – Source Physical Schema
  • Take advantage of the new data system features

Migration of legacy systems Migration of legacy systems Presentation Transcript

  • Capita Selecta Software Engineering and Technology Migration of Legacy Systems ( Adapted from chapters 6 & 7 – Software Evolution ) Hong-Phu Nguyen ( [email_address] ) April 1, 2009
  • 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
    • 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
  • 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
      • Architecture Recovery
      • Architecture
      • Transformation
      • Architecture-based
      • development
    www.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
    • 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
  • 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!