Legacy Transformation

Legacy Applications:

Valuable Assets or Decrepit Liabilities?

7 February 2003

Legacy Transformation

Scale of the opportunity

   There were 6,267,000,000 people on our planet in late 2002 ...Driving 722,000,000 cars (average age 6.8 years in the UK) ….And living in 1,645,000,000 households  They had ‘invested’ $5,000,000,000,000 in software (according to Information Week and IBM)  ...And by 1998 had developed an estimated 7,000,000,000 function points   ...Of which 30% were COBOL These function points were equivalent to about 640,000,000,000 lines of COBOL

Legacy Transformation

Questions

   What to do with those ‘legacy’ applications? Do we keep them running as long as possible and replace them when they are past their sell-by date?

…or is there an alternative, such as re-hosting, renovation, re-use or recycling?    If yes, how to decide which way to go?

What’s involved?

Where to go for help?

Are legacy applications like cars, to be replaced on a regular basis by newer, more fashionable and/or economic models, …. or more like houses, to be maintained long-term, and extended or modified to meet our changing needs, and perhaps completely renovated once in a while?

Legacy Transformation

A couple of definitions

 A

legacy application

is any application based on older technologies and hardware, such as mainframes, that continues to provide core services to an organisation. 

Legacy transformation

is about retaining and extending the value of the legacy investment through migration to new platforms.

Transformation can involve any combination of translation, migration, recycling, and re-use

Legacy Transformation

Why transform?

1. It retains/enhances the value of the application in the business 2. Because it’s better economics

Higher

Transform Do nothing

Application Value

Initial maintenance phase Enhancement phase(s)

Lower

Initial implementation

Time

Replace

Legacy Transformation

What’s inside the ‘black box’?

Legacy Application

???????

Transformed Application

Legacy Transformation

Inside the black box - the process

Test Translate Analyse and assess the legacy systems Migrate data Compon entise Add function ality Integrate Re-use Set transformation goals & success measures Administer and control transformation activities

Legacy Transformation

Challenges

  Preserve the business rules. Keep the migration timeframe short enough to avoid retrofit issues.

  Retain the functionality of the application through any migration process.

Retain ‘know-how’ in the organisation to support on-going maintenance.

Automating the transformation process is central to addressing these challenges

Legacy Transformation

A snapshot of available solutions

ArtinSoft Freedom, Relativity Rescueware Legacy to J2EE, .NET, others Netron HotRod, Semantic Designs, McCabe Concerto2, CAST - code mapping and pattern detection SWS DASE, Relativity Rescueware, Intercomp eMaker - hierarchical & relational to relational Test Translate Analyse and assess the legacy systems Migrate data Compon entise Add function -ality Integrate Re-use McCabe Audit - assess metrics ArtinSoft Analyzers diagnostic assessment Cyrano Wincap - retro documentation ASG Rochade administration, versioning Set transformation goals & success measures Administer and control transformation activities SWS Software, Prince COBOL dialect revision ASG Encore - extract COBOL code segments Merant NetExpress - wrap COBOL in Java Sapiens eMerge, Prolifics middleware HostBridge, Jacada, DataDirect - Web-enabling

Legacy Transformation

Example 1: GYSSA transformed an ERP product

 GYSSA is based in Guatemala, with regional offices in all the Central American countries. and business intelligence.

GYSSA’s ERP product

(called SPC) took 48 programmer-years to develop and has 7 sub-systems aimed at Central American market needs for B2B, CRM, ERP, information portal  

Architecture was Client/Server

, mostly written in earlier versions of Visual Basic.

Two choices:

build new system from scratch (estimate was three years based on previous experience) or migrate and re-architect.   

Upgrading SPC to .NET

was decided on as the best way to remain competitive in the Central American market and to stay in the forefront as a supplier of ERP solutions in the area.

Diagnostic analysis revealed that transformation could be completed in eight months,

with an equally sized development team at one quarter the cost.

Automatic translation tools

for Visual Basic 6.0 to .NET. were based on ArtinSoft’s upgrade wizard

Legacy Transformation

Example 2: Owens & Minor transformed contracts and pricing applications - and avoided ERP package implementation

 

Owens & Minor are a leading US distributor of medical/surgical supplies.

Existing contracts and pricing applications

were 15 years old - heavily customised, written in OS/2

. Complex rules for pricing with unique prices for each customer and product.   Original software vendor

Future requirement

over the Web

out of business

.

for such capabilities as multicurrency transactions    Relativity Technologies provided

tools to analyse business rules and translate

the COBOL and CICS into Java.

Tool tested on three master files

containing EDI maps and customer information. The test project was complete within six months. “It easily would have cost us tens of millions of dollars to go with SAP or Oracle. So far we've spent about $1 million on this project…we should complete the whole thing within 18 months and for less than $5 million” CIO David Guzman

Legacy Transformation

Example 3: Tharco extended package application through Web front-end



THARCO designs and manufactures corrugated boxes, and foam cushioning plastics.

THARCO carries an inventory of 1,600+ sizes of stock corrugated boxes and packaging materials.



Requirement: To enable customers to go online

to place or check the status of their orders - the company also saves money and increases efficiency by streamlining the front portions of its business process.



THARCO was an all-SAP shop

cost led , so mySAP was the obvious choice however, complexity, licensing and transaction-fee issues - and overall

THARCO chose an alternative middleware option

which exposed the required parts of SAP to the Web.

Web browser Standard Web server HAHT Commerce Suite application code HAHT deployment pack Application server (eg IBM Websphere) SAP R/3

Illustrative example

Legacy Transformation

Example 4: How Anglo-Irish Bank upgraded COBOL-based back-office applications

Used Intercomp AnalyzeIT to analyse code and structure ACUCOBOL ISAM Distributed data Scalability limits Record locking problems Problems in maintenance Used Intercomp MineIT to discover business rules, regenerate COBOL

Test Translate Analyse and assess the legacy systems Migrate data Compon entise Add function -ality Integrate Re-use Set transformation goals & success measures Administer and control transformation activities

2.5 million lines of code Contractors migrated data Micro Focus COBOL DB2 Consolidated data Bank leveraging DB2 for extracts, reporting Improved code semantics, readability Scalable

Legacy Transformation

Example 5: ALLTEL transformed data resource

 ALLTEL Information Services provides banking and mortgage software to financial organisations in the U.S.

  ALLTEL is developing new real-time/DB2 products to complement existing financial software suite. Components of this software suite are used by four of the top ten banks in the U.S. One of the major challenges of the initial project is moving from a VSAM to a DB2 data model. ALLTEL used Netron’s DMS product and associated services based on an iterative, rules-based approach to data migration.

 ALLTEL also use this as the standard method for helping its customers move their data models to DB2 as they upgrade to new releases of ALLTEL’s software products.

Legacy Transformation

What strategy?

 Choice driven by business needs to meet market requirements.

‘push’ to save money, or ‘pull’  Mix and match 4 options to transform the applications - replace, re-use, transform, rewrite.

  Consider the future of the overall application portfolio.

Choose the target platform based on general strategic considerations.

Migrations due to mergers and acquisitions can fit more than one category

Legacy Transformation

Business benefits and drivers

Legacy Transformation - Business Value Model Business Driver

Internal focus

Deteriorating system Economy eBusiness

External focus

Get ready for change Key business objective Value dimensions Survival, operational continuity

•Improved maintainability (documentation, easier to fix) •Access to support •Lower operating costs •Access to new customers (package supplier) •More adaptable system

Reduce operating costs Extend reach inside business and/or external to business Position business for the future

•Reduced operating costs, licence costs, back-up/disaster recovery costs •Opportunity to outsource •Reduced complexity •More adaptable system •Increased revenues •New customers/users •Better service to existing, new customers/users •Reduced customer acquisition costs •Brand enhancement •Adaptable system •Closer integration with business partners •Extended services to customers •Web Services option •Re-use of components •Future-proofing

Legacy Transformation

Key factors are quality of the legacy and availability of standard packages

Unique, non standard Type of Application Standard, packages available REWRITE REPLACE TRANSFORM RE-USE (or RE-CYCLE) Low High Quality of Legacy Application Adapted from Erlich

Legacy Transformation

Steps to a decision

Drivers Deteriorating system Looking for economies Adding eBusiness functionality Getting ready for change

Legacy portfolio Overview of Decision Process

Screen for continuing business value Assess Individual Legacy Applications

Applications: A B C D E ...

Map portfolio against drivers Selected applications • Quality • Cost • Business fit • Level of business change • Resourcing • Affordability Input to business case Outcome Transform Rewrite Replace Re-use Do nothing

Legacy Transformation

Which target platform?

 .NET and J2EE - most automatic translation products target these platforms  Re-use, scalability, and wide access to related products and services.  Integrated Development Environments (IDEs) make the development and maintenance task easier.  Application containers (runtime environments) provide the qualities of service necessary for enterprise applications such as transaction handling, security and persistence services.  Growing skill base.

 Suitable for Web Services.  Willingness to accept commitment to one strategic supplier a factor to consider in choosing .NET.

Choice between .NET and J2EE best made on broader strategic grounds

Legacy Transformation

Making it happen

Project set-up Acquire transformation technologies Proof of Concept Additional functionality definition Test Analyse and assess the legacy systems Set transformation goals & success measures Translate Migrate data Re-use Compon entise Add function ality Integrate Administer and control transformation activities Build know-how

Legacy Transformation

Example 6: Building know-how at North Carolina Department of Justice

 DOJ is migrating an application from an existing Unisys COBOL/MASM/MAPPER mainframe legacy application environment to a Java-based application. The migration was a pilot for the transformation of mainframe legacy code in other applications. Test Translate Analyse and assess the legacy systems Migrate data Compon entise Add function ality Integrate Re-use Set transformation goals & success measures Administer and control transformation activities Build know-how DOJ staff with little or no knowledge of the existing business rules contained in the existing code reviewed and comprehended the COBOL application's architecture, organisation and processes Established training material and conducting training class for DOJ's IT staff.

Worked with consultants to validate the JAVA programming standards, the XML messaging standards and the state service broker architecture to be utilised for the project.

Legacy Transformation

Selling the transformation project - what makes it so difficult?



If it ain’t broke, don’t fix it -

Managers like to get something new for their money - transforming a legacy application looks like a project to ‘fix’ something that already works. 

Jam tomorrow -

Transformation makes it easier to maintain and enhance the application in the future - to address things that happen. This is always worth less than immediate benefits.

might



Apples and Oranges -

Are you comparing like with like? The costs of the transformation project have to be spelled out, while the true cost of today’s legacy (disruptions, maintenance issues, costly operations, and so on) is often hidden in other budgets. These must be spelled out if the transformation project is to be compared with the cost of doing nothing.

Legacy Transformation

Choosing a business partner - Follow the money

‘Infrastructure’ suppliers Transformation Project Operations

Base Platfo rm Provi der Ena bling Tech nolo gy Minin g Tools Con versi on Tool s Syste m Integr ator Outs ourc er IS Dep artm ent Cust ome r

Licence-driven revenues Project-driven revenues Operations driven revenues

Legacy Transformation

In summary Transformation works

It’s feasible to extend the business value of core legacy applications by migration to new platforms.

Real savings are possible

Transformation is probably cheaper than rewriting or replacing a legacy application.

Horses for courses Alliances are key to success

Choose suppliers, tools and mix of transformation approaches based on future business needs and realities of the legacy portfolio. A first transformation project has a steep learning curve. It’s advisable to work closely with the experts to ensure success.

Legacy Transformation

Thank you

Declan Good [email protected]