1. Modernizing Legacy Systems Lucy Watts, PMP RKV Technologies Inc.

2. 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

3. Why Modernize?

4. 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? No reengineering Low –priority reengineering Replace with commercial package Good reengineering candidates Business value I. Warren 1999. The Renaissance of Legacy Systems. Method Support for Software Evolution Technical quality

5. Interpreting Assessment Need to Be Improved are Replaced, Consider Replacement With COTS, Transfer Solutions, Frameworks Low Business Value, Low Technical Quality No Modernization Effort Required Low Business Value, High Technical Quality Actively Evolve High Business Value, High Technical Quality Modernize or Replace High Business Value, Low Technical Quality

6. Preparing For The Business Case Identify Executive Sponsors & Management Determine High Level Business Requirements Determine Goals & Objectives Identify Other Stakeholders

7. THE BUSINESS CASE

8. Problem Statement Business Needs Citizen Self Service Supplier Stability – HW, SW, Vendor, Staff Failure RateAge Support Requirements Maintenance Costs Interoperability

9. Goals & Objectives Measurable Results Eliminates Problems Includes Benefit Includes Timeframe

10. Stakeholders SponsorsEnd Users Constituents (Business, Citizen, Other Agencies, Federal Government) Developers, Testers, Maintainers, System Administrators, Architects, Business Analyst LegalLegislatureInterfacing Systems Federal Government

11. 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

12. 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

13. Architecture Software Implementation Interim Legacy Maintenance Cost Solution

14. 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

15. Risks Identification EvaluationMitigation

16. Benefits Cost Reduction Or Avoidance Faster Response Time to Constituents Easier Interaction Between Citizen & Government Enabler for Information/Data Sharing Resolution for Data Integrity Issues Compliance to Governor & Legislative Mandates

17. Dispelling Some Myths COBOL 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,000 Myth #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

18. More Myths Data 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

19. More Myths Functional 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