INTEC Department of Information Technology Evolution of Legacy Systems Strategic and managerial issues based on a case Herman

INTECDepartment of Information Technologyhttp://www.intec.rug.ac.be

Evolution ofEvolution of Legacy Systems Legacy Systems

Strategic and Strategic and managerialmanagerialissues based on a caseissues based on a case

Herman Tromp, Herman Tromp, Ghislain HoffmanGhislain Hoffman

ELISA workshop, Amsterdam, Sep. 23, 2003ELISA workshop, Amsterdam, Sep. 23, 2003

INTEC - Department of Information Technology

What is legacy What is legacy

Legacy : Money, etc. (to be) received by a person by the will of

and at the death of another person Something handed down from ancestors or

predecessors

(source : dictionary)

Legacy has a Positive connotation : value Negative connotation : old, out-of-date, inappropriate

for current use


What is a legacy system?What is a legacy system?

A legacy system is an operational system that has been designed, implemented and installed in a radically different environment than imposed by the current ICT strategy. It is also a system that still contains considerable business value and is critical for operations.

(Note : other definitions are available)


ContextContext

The ARRIBA project (see companion paper) Migration at LCM (this paper)

Largest organisation in Belgium, responsible for health care allowances (interfaces with government agencies, hospitals and indivual citizens in a variety of ways)

Large scale systems, parts of it about 30 years old “home developed” (no commercial software was

available then) Urgent need to migrate (hardware is becoming

obsolete) Objective of this paper : to discuss the strategic

and managerial issues of legacy migration


A few position statements ...A few position statements ...

... from the lessons learned Large scale systems can only be succesfully

migrated through evolution Evolution implies more than code refactoring (it

can hardly be refactored) Evolution must also consider architecture,

information models, persistency techniques, business culture, ...

... and thus has severe implications on strategy and management ...

... and is seriously impacted by these.


As is – What is “large scale”As is – What is “large scale”

0

100.000

200.000

300.000

400.000

500.000

600.000

700.000

1995 1996 1997 1998 1999 2000 2001

Average number of BS2000 transactions by day


As is – Numbers, numbers, numbersAs is – Numbers, numbers, numbers

0

50

100

150

200

250

300

1996 1997 1998 1999 2000 2001

Sequential passes per month.


As is – Numbers, numbers, numbersAs is – Numbers, numbers, numbers

System Subsystem Code # prog. # lines

Assurabilité Audit AA 5 8.321Assurabilité CRM AC 8 16.710Assurabilité AS 1094 1.213.254Assurabilité Divers AX 44 60.455Assurabilité Banque Carrefour CB 162 146.678Indemnités Audit UA 8 6.441Indemnités UK 450 473.835Intersoc PI 118 151.572Service social CS 196 248.740Soins de santé Fanchise CF 52 47.483Soins de santé ALC CR 71 96.036Soins de santé Audit GA 5 19.658Soins de santé Correcttion Val. GC 57 187.976Soins de santé Adm. Hospital. GH 243 360.862Soins de santé Accident GO 96 109.675Soins de santé Divers GX 157 191.815Soins de santé GZ 470 419.867Soins de santé Prestations à terme PT 230 244.307VHS PE 107 138.667Total 19 3573 4.142.352


Technical view on “as is”Technical view on “as is”

Four distinct types of processing:

1. Transactional, under control of a transaction monitor Many concurrent access points – ACID requirements imposed

by the transaction monitor 2. Batch or volume transactions

Single point of access – ACID requirements met by JCL scripts (experience based)

3. Sequential transactions The whole database is scanned - ACID requirements met by

running programs (experience based) 4. Journaling operations

Sequential copy of medical acts – no database involved All those manually scheduled depending on the time of

the day


Drivers for legacy evolutionDrivers for legacy evolution Redefinition of corporate strategy, e.g. from a data

processing model to a multichannel service oriented model

Business process redefinition and reorganisation, due to rapidly changing legal requirements

Cost of ownership of the current system (diversity of systems, corporate take-overs, software maintenance costs)

Lack of existence of a corporate information model Lack of a well defined architecture Outright end of life situation (no proper database system,

phasing out of a line of hardware and system software, etc…)


Specific drivers in the present caseSpecific drivers in the present case Predominance of COBOL code Business logic is hidden in JCL and in the heads

of the operators No database : data is stored in a flat file system... ... Which is a home-brewn version of an IDMS

database Data is stored in a single file and accessed

through a wrapper (its usage is obscured by the presence of multiple entry points)

The wrapper performs logical to physical mapping down to the disk block level, and is also responsible for hashing, garbage collection, etc.


Specific drivers in the present caseSpecific drivers in the present case Knowledge of business logic is present, but the

expertise on how to translate it into an implementation is getting lost (people are leaving)

“New” technologies are not very well understood, but experiments and POC’s are ongoing (but not in core operations) ERP EAI and message brokers Data warehousing J2EE based application servers RDBMS

(This seems to be a typical situation)


Evolving legacy systemsEvolving legacy systems

First option: rewrite from scratch (Big Bang) Second option: refactor (rewrite in new context) Third option: migrate (geriatric operation) Fourth option: reuse by trying to define

components Fifth option: a mix of the first four options

Evolution is the way to go ...


A management viewA management view

Motivation (why ?) Objectives (where ?) Basic postulates and constraints (environment) Critical success factors (how to measure

success) Risk assessment Methodology (how)


MotivationMotivation

LCM needs to make sure that it develops and maintains a strategic technology direction, keeps current with industry development, and employs the selected technologies appropriateto reach its long-term objectives: to be the leader in the healthcare and related social services.The strategic decision to start the REFAC project (Reorganisation of the Financial, Administrative and Control circuits) implies a complete revision of the “Health Care” information system. This revision is minimally based on the installation of a relational database. The IT Management considers this project to be an excellent opportunity to carry out the firststeps in leaving the current platform BS2000. However involving some risks, this migration operation appears to be essential andinevitable for the future. Movement to a new environment will reduce support requirements, enable faster responses to development needs, and permit staff to be reassigned to support emerging newtechnologies. Viewing data as an institutional asset will improve the quality of reports,allow LCM staff to respond easily to rapidly expanding requests for information, and provide a service oriented users environment.


ObjectivesObjectives

Set up a evolution plan from the BS2000 towards a new platform

Define a new technical infrastructure to be developed and installed

Create an efficient and flexible application and data architecture.

Accompany this with a budgetary, HRM and business reengineering plan.

Make the necessary budgets available


Postulates and constraintsPostulates and constraints

Migration by stages (no big bang) evolution Stage by stage synchronisation of data Definition of a corporate information model

accessible through a relational data base (Oracle 9x) Business Process Reengineering Real time system with availability 24x7 J2EE based thin client architecture via portal and

application servers No data replication (?) Interface with existing CRM and financial systems


Critical success factorsCritical success factors

Affordable but significant proof of concept Quick win definitions Succesful implementation of a strategic application

suite within 2 years Management and stakeholder support Support of users (business and regular)


Risk assesmentRisk assesment

Unfeasibility (technology mix, integration of COBOL/Java)

Complexity Performance (is already a problem) Obsolescence of techniques Lack of pragmatism Unmanageable systems (related to complexity) Cost control (hard ...) Lack of (human) resources


Methodolody and planningMethodolody and planning

Evaluation of the “as-is” situation (investigation of COBOL code, underlying data structures, ...)

Determine a “to-be” business and application architecture

Determine a “to-be” technical and deployment architecture

Evaluate evolution scenario’s between the “as-is” and “to-be” situation

Any methodology should reflect the structure of the organisation.


Conclusion ? Some empirical lawsConclusion ? Some empirical laws

“A system that is used will be changed “ (Lehman)

“An evolving system increases its complexity, unless work is done to reduce it” (Lehman)

“A system reflects the organisational structure that built it” (Conway)

“What applies to small systems does not apply to large ones” (DeRemer)

“Architecture wins over technology” (Morris-Ferguson)


Appendix – accessing informationAppendix – accessing information

Some extra information ...


Access Access

Actual access to applications

applications

MUT

LEASY

terminalsOpen

UTM


Future AccessFuture Access

Future access to applications

ApplicationsData interface

RDBMS

Terminals

Connector

Browser

Application Server

http-Server

PC

Browser

PC

InternetIntranet

JDBC


Handling data in COBOLHandling data in COBOLMONITOR

UserProgramma

SUB-Programma

FILE-HANDLER

M UT

FILE-HANDLER

LEASY

MUx

MUx

M08

POT

UID

VCS

VAKA

OONS

GIFT

- openen Leasy cata loog- openen files- openen transactie- in itia lisatie- oproepen FH L- oproepen user-program m a- s lu iten files

- business log ica- oproepen FH L- oproepen sub-program m a

- business log ica- oproepen FH L- oproepen sub-program m a

- lezen leden- om zetting fys-log - log-fys- wegschrijven leden


Data streamsData streams

Sequential Batch

Updates

Logging

- PPR --> BTM- USER --> BC- PRINT --> REMOTE

Read

OpenUtm

MUT

1200 seq

500 trx

300 BC160 BTM

5.700.000 leden

externe dataperformatie


Physical data organisationPhysical data organisation

RNR2r 1

RNM1x 2

RNR

20 %

Begin Vrije Ruim te

E inde fichier

E inde DATA

x RNM1 RNR1 2

s RNM RNR 4

r RNR2 1

RNR1RNM1

IND

DAT1 9...9

2 z

3 9...9

299 9...9

FSP

300 9...9

301 free end

15.000.000 recordsvan 1K (D AM -rcords)

13.125 records van 1 PP(PAM -pages = 2k )

13.125 records van 1 PP(PAM -pages = 2k )

y RNM RNR 2 HV 9...9

z RNM RNR 2 HV y

x

r

z

y

s

free

end


Example of a data structureExample of a data structure

ADM 01

BYD 03

ATT 04 DEL

BYD 05

MUT 02

E11 06

E11 09 E11 08 E11 07 PDL

XXX

INFO LID

- F IC N R- AD R ES- H V + FR EE Adres- LN G- R N R

- R N M- SW -SKIP- SEQ N R- U N IEK (adm _id)- D AT U M W ijzig

00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000

00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000

00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000

00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000

0000000000000000

0000000000000000

0000000000000000

0000000000000000- LN G- N R- BAT C H -D AT- BAT C H - PR O G ID

- O N L-D AT- O N L-PR O G ID- O N L-PER SN R- D EL-PD L- SEQ N R

Record

1

Record

2

Documents

INTEC Department of Information Technology Evolution of Legacy Systems Strategic and managerial issues based on a case Herman