Modernizing Legacy Systems

Lucy Watts, PMPRKV Technologies Inc.

About RKV

• Premier Provider of IT Services & Solutions• 14 Years Experience with the State of Missouri– Completed Over 500 PAQs in 16 Agencies– Delivered Business Cases for over 10 Modernization Efforts

• Currently Implementing UI Modernization Solutions For Indiana and Louisiana

• Over 115 Consultants Completing Modernization Efforts • Management Team – Average Over 25 Years IT

Experience

Why Modernize?

• Complete Portfolio Analysis to Establish Technical Quality & Business Value of Systems

• Determine Criteria for Assessment & Prioritize• Technical Quality Criteria

– Frequency of New Releases– Maintenance Ease– HW/SW Reliability or Obsolescent– Organization Infrastructure– System Performance– Accuracy– Operational Ease

• Business Value Criteria– Contribution to Profit/Providing Services– User Satisfaction– Ease of Integration with Other Systems/Technology– Value

What Do I Modernize?

1

2 3

4

No reengineering

Low –priority reengineering

Replace with commercial package

Good reengineering candidates

Business valueI. Warren 1999. The Renaissance of Legacy Systems. Method Support for Software Evolution

Tech

nica

l qua

lity

Interpreting Assessment

•Need to Be Improved are Replaced, Consider Replacement With COTS, Transfer Solutions, Frameworks

Low Business Value, Low Technical Quality

•No Modernization Effort RequiredLow Business Value, High Technical Quality

•Actively EvolveHigh Business Value, High Technical Quality

•Modernize or ReplaceHigh Business Value, Low Technical Quality

Preparing For The Business Case

Identify Executive Sponsors & Management

Determine High Level Business Requirements

Determine Goals & Objectives

Identify Other Stakeholders

THE BUSINESS CASE

Problem Statement

Business Needs

Citizen Self Service

Supplier Stability – HW, SW, Vendor,

Staff

Failure RateAge Support Requirements

Maintenance Costs

Interoperability

Goals & Objectives

• Measurable Results• Eliminates Problems• Includes Benefit• Includes Timeframe

Stakeholders

Sponsors

End Users

Constituents (Business, Citizen, Other Agencies,

Federal Government)

Developers, Testers, Maintainers, System

Administrators, Architects, Business

Analyst

Legal

Legislature

Interfacing Systems

Federal Government

Requirements

User•Processes •Activities•Rules•Information Requirements

System

• Architecture• User Interface• SOA• Data

Warehouse• Web Enabled

• Database

Constraints

•Interfaces•Development Standards•Enterprise Architecture Standards•Existing Infrastructure

Nonfunctional

•Performance •Availability •Usability •Security•Flexibility

Constraints

• Due Dates Imposed by Statues• Budget• Processes/Business Rules Required by Law• Technical Architecture• Available Resources with Business & Technical

Skills & Knowledge• Tolerance for Risk

Architecture

Software Implementa

tion

Interim Legacy

Maintenance

Cost

Solution

Implementation Plan

• Must Reflect Approach/Methodology• Gap Analysis

– Business Requirements, Legacy System, COTS or Transfer Solution• Prototyping• Iterations – Avoid Big Bang Approach• Architecture Changes• Staff Training• Bridging with Legacy/Turning Off Legacy• Procurement• Resources

Risks

Identification

EvaluationMitigation

Benefits

Cost Reduction Or Avoidance

Faster Response Time to

Constituents

Easier Interaction Between Citizen & Government

Enabler for Information/Dat

a Sharing

Resolution for Data Integrity

Issues

Compliance to Governor &

Legislative Mandates

Dispelling Some MythsCOBOL applications process 85% of all global business data

Myth #1 – Legacy

applications

provide little or limited

business value

1998 – 20 Billion CICS Transactions, 2000 – 30 Billion

1993 – 30,000 CICS Systems, 1999 – 50,000Myth #2 – Web-based

systems are

rapidly displacing

legacy systems

200 Billion Lines of Code, 60% of World’s Software

Over the next 5 years, 15% of all new application functionality will be developed using COBOL

It is being web-enabled

Myth #3 – COBOL is a

dead language & is no longer being

enhanced or

upgraded

More MythsData is typically redundant & inconsistently defined, hard to integrate & lacks integrity

Legacy systems have built in safeguards to deal with these issues, while many new web based systems do not

Myth #4 – Legacy data

stores can be left intact &

made accessible to Web-based applications

May be hard to decipher, hard to invoke, redundantly defined, but is very reliable

Business logic is accurate & reliant, but not conducive to dynamic business requirements

Sometimes is the only place business rules are documented or known

Myth #5 – Legacy system functionality is no longer valid

More MythsFunctional fragmentation, caused by hierarchical or stovepipe evolution, have created a situation where systems fulfill tasks in a piecemeal fashion.

Direct conflict with e-business systems to trigger rules and access data on demand

Will fulfill some requirements but will not Web-enable key business functions

Myth #6 – Web-enabling legacy

systems will satisfy new

business requirements

Studies have shown 80% of business rules and functionality in legacy system is retained

Sometimes is the only place business logic and rules in documented or known Myth #7 –

Organizations developing new

systems can ignore legacy

systems

Source: Modernizing Legacy Systems, Seacord, Plakosh, Lewis - 2003