• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Legacy Systems
 

Legacy Systems

on

  • 647 views

 

Statistics

Views

Total Views
647
Views on SlideShare
646
Embed Views
1

Actions

Likes
0
Downloads
2
Comments
0

1 Embed 1

http://www.slideshare.net 1

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

    Legacy Systems Legacy Systems Presentation Transcript

    • Legacy Systems
      • What is meant by a legacy system?
      • What it is / what it is not
      • Why is it critical to business operations?
      • Function-oriented design
      • Assessing legacy systems
        • discard it?
        • maintain it?
        • re-engineer it?
        • replace it?
    • An actual business example
      • From Fall, 1992 to Summer, 1996: Working on the TMS/AMS System for PECO Energy
      • TMS – Task Managements System
        • Tracking Labor and Materials for projects
      • AMS – Asset Management System
        • PC Based System that was re-written from a previous legacy system
          • Mainframe NOMAD Database
    • Historical Perspective (ca. 1992)
      • The only GUI environments were Windows 3.11, Macintosh OS’s, and IBM’s OS/2.
      • The only network lion-share leaders: Novell, Banyan
      • Computers of the day:
        • 20MB (up to 1GB for a server)
        • 386 or 486 processing
        • 640K Conventional memory (RAM)
    • The “legacy”
      • An IBM OS/2 platform. (still, not true GUI)
      • Used IBM’s OS/2 network solution
      • Loaded the network software high, so 604K was available for the system “in that session”
    • From Somerville p. 582:
      • Replacing a legacy system is a risky strategy for a number of reasons:
      • There is rarely a complete specification of the legacy system.
          • OJT, User testing of specific code, etc.
      • Business processes and legacy systems are often entwined
          • For PECO: It was a necessary part of operations (it tracked hours spent on a job, billing for the job, materials, miscellaneous labor, and miscellaneous overhead.)
      • Business rules may be embedded in the software of the legacy system
          • The PECO way
      • There may be unexpected problems with the new development of software to replace a legacy system
    • Implementation
      • Different parts of the system implemented by different parts of the team (Dynamic nature permitted me to add new reports to the reporting library)
      • Part or all of the system may be implemented using an obsolete programming language (Clipper 5.0)
      • System documentation is often inadequate or obsolete. (or non-existent)
      • Years of maintenance may have corrupted the system structure. (ad-hoc requests were rampant)
    • Implementation (cont.)
      • The system may have been optimized for space utilization or execution speed (as previously outlined)
      • The data processed by the system may be maintained in different files that have incompatible structures (data subsets, flat files, etc.)
      • A potential work-around as TMS/AMS got bigger: divorce the two, as two separate programs
        • The thought was that this would minimize the 604K requirements; not at all!
    • What made up the legacy?
      • As a legacy system, TMS needed to be networked, and was benchmarked at using 604K memory:
      • Written in:
        • Clipper 5.0 (95% Clipper, 5% C)
      • Database of choice:
        • dBASE
      • External Reporting:
        • Report Writer 5.0
    • Legacy System Structures (26.1)
      • System hardware (Legacy systems written for hardware systems not available anymore)
        • IBM PS/2 Series
      • Support software (Legacy systems may rely on supporting software)
        • RR and OS/2
      • Application software (The application relies on a series of interconnected programs)
        • Clipper & C, RR, dBASE
    • Legacy System Structures (26.1) (cont.)
      • Application data (The data which are processed by the application system)
        • Terminal data entry
        • Files grew quickly, and wastefully
      • Business Process (The business objective)
        • Tracking the labor, materials and assets
      • Business policies and rules (How business was done at PECO)
        • Billing codes, constraints, overrides
    • Legacy System Design (26.2)
      • Most are non- or pre-OO Development
        • (TMS tried to go OOP with class(y))
      • Conforms to a function-oriented design (broken down into reusable components)
        • this can cause problems: too many programmers dilute the code. Integrity is violated
        • it is only successful when information sharing is explicit
    • Legacy System Assessment (26.3)
      • Organizations, which depend on these systems, must decide (realistically) on the course to follow on their system
      • Assessment:
        • Scrap the system completely
        • Continue maintaining the system
        • Transform the system in some way to improve its maintainability
        • Replace the system with a new system
    • PECO’s Solution
      • Scrap the system?
        • Auditors (PECO & the subcontractors) needed the data
      • Continue maintaining the system?
        • The company was moving away from OS/2
      • Transform the system in some way to improve its maintainability?
        • Had been tried, unsuccessfully
      • Replace the system with a new system?
        • Spring 1997, a new team came in to re-write TMS using VBA (Visual Basic for Applications)