DESIGN AND EVALUATION OF A MODEL FOR

MULTISTAGE LEGACY-CRISIS DETECTION IN

IT-SOLUTIONS OF ENTERPRISES

A thesis submitted in fulfillment of the requirements for

the award of the degree of

DOCTOR OF PHILOSOPHY
in
COMPUTER SCIENCE AND ENGINEERING

By
Amit Mishra

Under the Supervision of

Dr. Anurag Singh Baghel

DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING

SCHOOL OF INFORMATION AND COMMUNICATION TECHNOLOGY
GAUTAM BUDDHA UNIVERSITY
GREATER NOIDA 201310
INDIA
2017
 SELF-DECLARATION

I hereby declare that work contained in this thesis titled “DESIGN AND
EVALUATION OF A MODEL FOR MULTISTAGE LEGACY-CRISIS
DETECTION IN IT-SOLUTIONS OF ENTERPRISES” is original. I
have followed the standards of research ethics to best of my abilities. I have
acknowledged all the sources of information which I have used in the
thesis. I have completed all the pre-submission requirements as mentioned
in the UGC mandate and GBU Ph.D. ordinance.

Amit Mishra
Enrolment No.: PHD/ICT/1303
Department of Computer Science and Engineering
School of Information and Communication Technology
Gautam Buddha University, Greater Noida, 201310
Gautam Buddha Nagar, Uttar Pradesh, India

(I)
 CERTIFICATE

This is to certify that Mr. Amit Mishra has worked on the research work
entitled “Design and Evaluation of a Model for Multistage Legacy-Crisis
Detection in It-Solutions of Enterprises”, under my supervision and
guidance. The content of thesis being submitted to the Department of
Computer Science and Engineering, School of Information and
Communication Technology, Gautam Buddha University for the award of
degree of Doctor of Philosophy in Computer Science and Engineering,
are original and have been carried out by the candidate himself. This thesis
has not been submitted in full or part for the award of any other degree or
diploma to this or any other university.

(Dr. Anurag Singh Baghel)

Thesis Supervisor
Assistant Professor
Computer Science and Engineering
School of Information and Communication Technology
Gautam Buddha University

Countersigned by

(Dr. AK Gautam)
Dean of School
School of Information and Communication Technology
Gautam Buddha University, Greater Noida.

(II)
 ACKNOWLEDGEMENTS

This is the grace of GOD, who provided me the courage, family, friends, teachers and
colleagues motivating and supporting me to accomplish this work. First of all I express
my gratitude to my father, who still keeps interacting with me and taking status of my
studies as he used to do during my childhood. This reminded me every day to keep
focus on the research work. This was a necessary fuel to accomplish the research
journey along with my tedious job profile being a working professional. Blessings of
my mother always helped me to keep me oriented towards my work balancing with
professional work.
ICIAICT-2012, 1st international conference on innovations and advancements in GBU
was trigger point when Mr. Nripendra Mishra, motivated me to present two papers in
the conference. This gave me opportunity to interact with Dr. Anurag Singh Baghel, Dr.
Pradeep Tomar and Dr. Gurjit Kaur to present two papers as industry representative.
This encouraged me to initiate the conceptualization for this research work.
I express my special gratitude to my research supervisor Dr. Anurag Singh Baghel, who
consistently guided to follow the right path and methodology for this research work.
Even being almost equal in age he was never hesitant asking me to work hard. He
cooperated with me to make himself available as per my needs, requirements and
schedule. Without this kind of unconditional support this work would have been
impossible for me to accomplish being a working professional.
Dr. Pradeep Tomar, coached me for good paper writing, he made himself available for
discussion and drafting research papers giving his experience in Software Engineering,
together during Saturday‟s to get desired direction and results of this work. Express my
gratitude to Prof. Anil Kumar Gautam and Dr. Rajesh Mishra for giving valuable
feedback during review presentations, helping to attain comprehensiveness in this work.
My brother Dr. Anurag Mishra and his wife Dr. Namita Mishra shared their experiences
of research and those were key inputs to my work. Brother Anoop, supported me in
discussing software re-engineering topics and many times countering my arguments and
being critic he helped to get the work in final shape.

(III)
Very-very deep sense of gratitude to my wife Mrs. Rekha Mishra, who is supportive
throughout my work. Sacrificing countless week-ends and vacations, she gave me
encouragement to devote my free time to research work. My daughters Apoorva,
Ayushi and son Abhyuday teased me for still studying like student but supported to
concentrate on my work.
Special thanks to ST-Microelectronics, management team, process working group and
my colleagues who provided me the real environment and data to accomplish the work.
I can‟t forget the contribution of Mr. Sanjay Davar for giving key inputs to this work on
the architectural analysis part. Mr. Vipul Goyal, Mr. Rishi Agarwal and my team
supported me via backing up whenever I needed off days to dedicate to this work.
Special thanks to Dr. Manad Lal Verma „Krant‟, who guided me towards writing and
publishing work and Dr. Vivek Agnihotri, who reviewed my publishing draft work from
technical and grammatical perspectives to improve the quality of research and
publishing work.
I would also like to express my sincere thanks to all faculty members and research
scholars of Gautam Buddha University, who helped me to have academic view to my
work. Special thanks to Mr. Ankur Chaudhary, Mr. Sonu Lal Gupta and Miss Priyanka
Goyal for providing me the study materials and peer reviewing the work. Also thanks to
Dr. Kapil Sharma, who motivated me to attend good conferences and guided for writing
impactful research papers. Dr. Sandeep Sharma assisted me in thesis drafting, his
suggestions were real help for me. Last but not the least, I thank all my friends in
Greater Noida who appreciated my excuses and un-availabilities on several other
occasions to devote my time to this work. Mr. Ashish Gangwar executed several of my
personal duties during this tenure to facilitate me bandwidth for this work.

With the countless helps, blessings and grace of God, this work has been concluded
smoothly.

“सकल , सक लक ”|

May, 2017 (Amit Mishra)

(IV)
 ABSTRACT

Name of the Student: Amit Mishra Enrolment No.: PHD/ICT/1303

Degree of which Submitted: Doctor of Philosophy
Department/School: Computer Science and Engineering
School of Information and Communication Technology
Gautam Buddha University, Greater Noida-201312, (U.P.)
Thesis Title: “Design and Evaluation of a Model for Multistage Legacy-Crisis
Detection in It-Solutions of Enterprises”
Thesis Supervisor: Dr. Anurag Singh Baghel
Month and Year of Thesis Submission: May, 2017

This thesis deals with the legacy transformation and related issues. Primarily the
work focuses on the detection of crisis situation in maintaining the legacy software
applications. This point is clear indication to start thinking for transforming or phasing
out of legacy application. This research work has a peculiarity in terms of industrial
aspects into academics. Study has included all real data and applications of real world
with big size applications having big user-base in software industry. Academic research
approach of study helped to have quality outcome. Industrial view has highlighted the
importance of softer issues in legacy transformation.

Practical approaches to cope the softer issues are also result of industry experience into
study. All practical approaches described were used to define the checklist and tools to
handle issues in legacy transformation. Literature review and study have been
performed in two perspectives to define the problem area. One perspective is industrial
perspective and other one is academic perspective. “Legacy attributes and their
weights”, is a specific chapter in this thesis which describes the situations of entering a
legacy into crisis. It also determines the impact of each attribute contributing to legacy
crisis. It talks about the symptomatic parameters, which indicate the degree of legacy
crisis.

(V)
Further a model is developed for “Multistage Legacy Software Crisis Detection
Matrix”, where stage-1 for Legacy Crisis Symptom Score (LCSS) computation is based
on monthly Key Performance Indicators (KPIs) while stage-2 is more at the design
entropy level. In second stage the architectural analysis is made with respect to SOA
and CLOUD industry standard architecture paradigms. Threshold values are determined
empirically for both the stages to decide the degree of legacy crisis. The model
developed here is unique improvement over the existing models and methods in the
determination of legacy crisis situation. Peculiarity of this model is it‟s correctness to
practical results, ease of implementation, objectivity and first attempt to develop a
standardized and proven approach. This work contributes in saving cost by giving a tool
to determine legacy crisis situation and taking proactive measures to deal with it.
Organizations may save cost on consultancy by applying the model themselves.
Application of the model on legacy software gives a recommendation to go for
transformation or not. Validation of model is done through the application of model on
already transformed applications and the results were validated with old gut-feel model.
Gut-feel model is based on decisions by expert teams and people having deep domain
knowledge and experience. For the validation and threshold value determination it has
been applied on 204 applications representing 7 business solution groups across the
globe.

Another important aspect of this work is identification of “Soft Issues” in legacy

transformation based on the post mortem workshop of execution of two big programs.
Correlation analyses among these soft issues were performed to determine the
interdependencies among soft issues. Outcome of this work in summary is decision
support tool for legacy transformation, cost saving with ease of implementation and
saving cost on consultancy, revealing the operational and architectural weaknesses of
applications, understanding and coping the soft issues in legacy transformation.

Models developed in this work are useful for industry in practical sense. It is more
suitable for organizations where legacy applications are being used. Models can be
automated further by researchers to make the application simpler for LCSS and Soft
Architectural Distance (SAD) computation.

(VI)
 List of Publications
This section provides a list of publications that has been derived from the work
presented in this thesis.

Published and Accepted

[1] Amit Mishra, Pradeep Tomar and Anurag Singh Baghel, “Multistage Legacy
Software Crisis Detection Matrix,” IJCTA Journal, International Science Press,
vol. 9(10), pp. 453-461, 2016.

[2] Amit Mishra, Pradeep Tomar and Anurag Singh Baghel, “Transforming from
Legacy to Packaged/Standard S/W Solutions: For Big Enterprises,” Journal of
Software Engineering Tools and Technology Trends, vol.3(1), pp.5-11, 2016.
[3] Amit Mishra, Pradeep Tomar and Anurag Singh Baghel, “Soft Architectural
Distance (SAD): How Far is the Legacy Architecture from SOA Architecture
Principle?,” IOSR Journal of Computer Engineering(IOSR-JCE), vol. 1(1), pp. 7-
12, 2016
[4] Amit Mishra, Pradeep Tomar and Anurag Singh Baghel, “Softer Impediments in
Legacy Software Transformation: Challenges and Lessons Learnt,” International
journal of control theory and applications, 3rd International Conference on
Computing Sciences, April, 2016 . (Accepted: Scopus indexed Journal)
[5] Amit Mishra, Pradeep Tomar and Anurag Singh Baghel, “Technological Advances
in Computing and it is Coherence with Functional and Business Needs,”
Communication and Computing Systems - CRC Press, ICCCS-16, pp. 197-200,
2016.
[6] Amit Mishra, Pradeep Tomar and Anurag Singh Baghel, “Improvement and
Evaluation of Software Development Process through Contextualization for
Maintenance of Legacy Systems,” Elsevier, Materials Today Proceedings,
International Conference on Recent Trends in Engineering and Materials Science
(ICEMS-2016), 2016 (Accepted)

(VII)
Communicated
[7] Amit Mishra, Pradeep Tomar and Anurag Singh Baghel, “Coping with Soft Issues
in Legacy Software Transformation,” Communicated to: Indian Journal of Science
and Technology. (SCOPUS Indexed)
[8] Amit Mishra, “A Technical Report on Software Maintenance, Key Performance
Indicators: Legacy Software Health Report,” Communicated to: ACM Transactions
on Software Engineering and Methodology (TOSEM).

(VIII)
 CONTENTS
Self-Declaration I
Certificate II
Acknowledgement III
Abstract V
List of Publication VII
List of Figures XI
List of Tables XII
List of Abbreviations XV

Chapter 1: Introduction 01
1.1. Software Re-engineering …..………………………………………... 04
1.2. Problem Identification .…………..……………………………………….. 08
1.3 Legacy Case Study: 4th Decimal Place in Unit Price.........………………. 09
1.4. Legacy crisis attributes …………………………………………………... 13
1.5. Research Objectives …..………………………………………………….. 15
1.6. Research Methodologies and Validation Model………………………… 16
1.7 Detailed Approach ……………………………………………………… 19
1.8. Thesis Organization …………………………………………..………… 21

Chapter 2: Literature Review 23

2.1. Literature Review …………….…………………….…………………..... 23
2.2. Legacy Transformation Studies from Industrial Perspective….…............. 24
2.3. Legacy Transformation Studies from Academic Perspective...….…...….. 27
2.4. Literature Review Conclusion……………………………………………. 33

Chapter 3: Legacy Attributes and Their Weights 34

3.1. Attributes and Weights ……...………………….……….............……….. 35
3.2. Determining Legacy Attributes (Operational Perspective)………..........… 36
3.3. Weights of Operational Legacy Attributes...……………………………… 38
3.4. Determining Legacy Attributes (Architectural Perspective)....................... 39
3.5. Weights of Architectural Legacy Attributes …………............................... 44

Chapter 4: Multistage Legacy Software Crisis Detection 49

4.1. Introduction.................................................................................................. 49

(IX)
4.2. Multi-Stage: Legacy Crisis Detection Model………….………………… 50
4.3. STAGE-I: Legacy crisis detection via operational matrices…...………… 51
4.4. Determination of Threshold Value for LCSS.............................................. 55
4.5. STAGE-II: Legacy Crisis Detection via Architectural Analysis................. 61
4.6. Legacy Architecture Questionnaire Determination...................................... 63
4.7. Applying the SAD computation w.r.t. CLOUD Architecture Principle….. 67

Chapter 5: Soft Issues Identification and Coping 72

5.1. Softer Challenges and Coping with Them …………………………….…. 73
5.2. Determining Soft Issues ………………….…..……………………........... 73
5.3. Interdependencies: Softer impediments………………………………….. 76
5.4. Coping with Soft Issues ……….…………………………………………. 87

Chapter 6: Results Discussion and Future Directions 99

6.1. Legacy Crisis Operational Attributes……................................................... 99
6.2. Validation of Stage-I : Legacy crisis detection via LCSS model................. 102
6.3. LCSS Results Summary and Discussion...................................................... 111
6.4. Validation of Stage-II: Architectural Analysis …………………………… 112
6.5. Conclusions.................................................................................................. 132
6.6. Research Contribution.................................................................................. 134
6.7. Future Directions ………............................................................................. 135

References…......................................................................................................... 137
Appendix-A: Appendix-A: Data-sources, Techniques and Models…………….. 148
Appendix-B: A Technical Report on Software Maintenance, Key Performance
Indicators: Legacy Software Health Report ……..…………………………………. 152

(X)
 List of Figures
Fig. No. Description Page No.
1.1. Horseshoe model of reengineering………………..…………………........ 04
1.2. Service Oriented Architecture …………………………………………… 07
1.3. „n-why‟ Analysis for Root Cause Identification ……..………………....... 11
1.4. Legacy Crisis Attributes ..…..…….…………………………………….... 14
1.5. Outline of Research Work …....….……………………………………..... 17
1.6. Validation Model ……………………….......………….….…............…... 18
2.1. Legacy Transformation Strategy ……………..…..…...................... 21
2.2. Legacy Transformation Approaches vs. Effort Dimensions …………….. 27
4.1. Flowchart for LCSS Computation ……………………….........…………. 53
4.2. Delphi Technique for Questionnaire Determination .……..............……... 63
5.1. Flow Chart-Softer Challenges Determination ...………………................. 74
5.2. Program Board Structure with IT and Business Accountable..................... 94
6.1. Figure 6.1: Incident Arrival Trend (Legacy - SO and Recent – DRP)….……... 100
6.2. Monthly Question Trend (Legacy - SO and Recent – DRP)………………..…... 100
6.3. Monthly SLO/SLA Compliance Trend for Application SO…............................ 101
6.4. Monthly Reported Problems Trend For Legacy and Recent Application ……... 101

(XI)
 List of Tables

Table No. Description Page No

1.1. Main Set of Problems Highlighted After Go-Live …..………………….. 10

1.2. Preventive Action (PA) Summary ……….…………………………….... 12

2.1. Legacy Software Definition Summary …………………………………….…. 23

3.1. Top Page KPIs and Legacy Attributes ..……………................................ 37

3.2. Top Page KPI (Legacy Attribute) Weight Computation............................ 39

3.3. Inputs Received in Archo-2015 (S&M + GLWO)…................................. 40

3.4. Inputs Received in Archo-2015 (Finance + Purchase)…........................... 40

3.5. Inputs Received in Archo-2015 (ICT Manufacturing + HR + BI)..…….. 41

3.6. BSG Input Consolidation Delphi Round1..............……………………… 42

3.7. BSG Input Consolidation- Delphi Round2………………………….….. 43

3.8. SOA Attribute Weights………………………………………………… 44

4.1. Legacy Crisis Symptom Score Matrix…………………………………... 55

4.2. Legacy Crisis Symptom Score Percentile Matrix………………………. 56

4.3. Legacy Architecture Evaluation Questionnaire…………………………. 64

4.4. SOA Architecture Weight Matrix for Sales Order Application…………. 65

4.5. Computation for Degree of SADness – SOA………………….………… 67

4.6. CLOUD Architecture Weight Matrix for Sales Order Application…….. 68

4.7. Computation for Degree of SADness - CLOUD…………………….….. 69

5.1. Lessons Learnt Workshop Responses - DAMLOG and DAMBILL …... 75

(XII)
5.2. Soft Issues Classification (Organizational and Individual)……………. 76

5.3 Responses to Questionnaire (Individual Soft Issues)…..………………... 78

5.4. Correlation Analysis: Individual Soft Issues ……………………………. 81

5.5. Responses - Questionnaire (Organizational Soft Issues)…...…………… 83

5.6. Correlation Analysis (Organizational Soft Issues)……………………… 86

5.7. A Sample Legacy Transformation Readiness Assessment Sheet ………. 93

6.1. User Counts and Normalization Factors for Applications ...……..……... 104

6.2. LCSS Computation for Sales Order (SO).................................................. 105

6.3. LCSS Computation for VLOG…………................................................... 106

6.4. LCSS Computation for Business Partner (BP)…………………………. 107

6.5. LCSS Computation for Backlog Management (BM)…………………… 108

6.6. LCSS Computation for Sales General Agreement (SGA)..……………... 109

6.7. LCSS Computation for Order Scheduling (AS, MS, SWAP)…………… 110

6.8. LCSS computation for five applications ………………………..………. 111

6.9. Answer Architecture Questionnaire for Legacy – SO: SOA …………… 113

6.10. SAD Computation for SO: SOA ………………………...……................ 115

6.11. Answer Architecture Questionnaire for Legacy – SO: CLOUD …..……. 116

6.12. SAD Computation for SO: CLOUD ……………………………………. 118

6.13. Answer Architecture Questionnaire for Legacy – BM: SOA ……..……. 119

6.14. SAD computation for BM: SOA ...……………………………………… 121

6.15. Answer architecture questionnaire for legacy – BM: CLOUD………... 122

6.16. SAD computation for BM: CLOUD ……………………………………. 124

6.17. Answer Architecture Questionnaire – Order Scheduling: SOA…………. 125

(XIII)
6.18. SAD computation for Order Scheduling: SOA ………………………… 127

6.19. Answer Architecture Questionnaire – Order Scheduling: CLOUD …….. 128

6.20. SAD computation for Order Scheduling: CLOUD …………………..…. 130

6.21. Validation through SAD Score …………………………………………. 131

(XIV)
 List of Abbreviations

ADM Architecture Driven Modernization

AS Automatic Scheduling
BITA Business IT Alignment
BM Backlog Management
BP Blue Print
BSG Business Solution Group
CEM Corrective Evolution Model
CMMI Capability Maturity Model Integration
CORE Component Oriented Reverse Engineering
CR Change Request
DAMBILL Changed name of billing project
DAMLOG Changed name of logistics project
DD Detailed Design
DO Divisional Order
DOC Degree Of Coherence
DRP Distribution Resource Planning
EAI Enterprise Application Integration
EDI Electronic Data Interchange
EPM Enterprise Project Management
ERP Enterprise Resource Planning
FGD Functional General Design
FP Function Points
GTS Global Trade Systems
ICT Information and Communication Technologies
IR Issue Root
IT Information Technologies
ITP Interrupts to Production
KLO Keep Lights ON

(XV)
KPI Key Performance Indictors
LCSS Legacy Crisis Symptom Score
LES Logistics Execution System
LSHR Legacy Software Health Report
MS Manual Scheduling
NF Normalization Factor
NFS Normalization Factor on Size
NFU Normalization Factor on User-base
NOAC No Action
OR Operations Reviews
PEM Proactive Evolution Model
REM Reactive Evolution Model
ROI Return on Investment
SAD Soft Architectural Distance
SDLC Software Development Lifecycle
SDP Software Development Process
SEPG Software Engineering Practice Group
SGA Sales General Agreement
SLA Service Level Agreement
SLO Service Level Objectives
SnM Sales and Marketing
SO Sales Order
SOA Service Oriented Architecture
SPI Software Process Improvement
TGD Technical General Design
WM Warehouse Management

(XVI)
 1. Introduction

With technological developments in the field of computers and software,

automation through computerization has entered widely and deeply in almost every field.
It has become very common to run an enterprise through sophisticated computer
software. It is a well-accepted fact that technology is changing rapidly, hence the need to
keep upgraded with latest trends is the key to success. This is especially true for big
enterprises where the challenge is not only to keep the enterprise running but also to
collaborate with other enterprises doing similar business. Many enterprises started to use
the software systems initially with the objective to ease some of the activities but later
they were converted to semi-automated systems. Finally, over the time, they evolved as a
back-bone of the organization. However, as the time passes, the requirements from the
software change. Additional functionalities need to be incorporated; performance matrix
also change over the time. Finally it needs to be compatible with latest upgrades in
platform it is residing on and also with the latest upgrades in the systems of collaborating
companies and other systems it interact with. To enhance the capabilities of the systems
to achieve this iterative changes are done in the system time to time. These changes,
sometimes in arbitrary manner and in arbitrary (as need be) components, successively
reduce the performance of the system; enhancing capabilities becomes difficult and more
importantly these systems slowly becomes rather incompatible with the other systems
they are interacting with and with latest technology as well. Such a set of software are
called legacy.

Technology evolution reshapes the way to do IT, offering a wide variety of development
technologies/languages, packaged solutions, cloud solutions, infrastructure options,
hosting options with a high speed of implementation at acceptable costs. This evolution is
also resulting in a high speed of redundancy of existing IT solutions of enterprises, as
support and availability of experienced staff tends to dwindle, forcing them to evolve and
keep abreast with the evolution.

Page |1
Organizations always intend to acquire and implement best-in-class solution approaches
and architectural designs for their IT solutions. But as the time passes by, requirements
change, new technologies emerge, customer base becomes broadened and the
compatibility with old systems becomes a challenge. To cope up the increased
requirements from the software and to cope up the changed environment (users, clients,
interfacing, platform etc.) maintenance becomes increasingly tedious - monetarily and
effort wise too. At some point, this maintenance effort (time and cost) increases so much
that they start to eat most of the IT budget and resources. This is the point at which
legacy system starts into entering crisis situation.

From industrial perspective, business requirements are also evolving and they need more
flexible, robust and agile systems. In this situation, companies cannot rely on their legacy
systems further. It becomes difficult to maintain legacy and the knowledge around it
starts diminishing. In most of the cases, either there is no documentation or it is
insufficient and unauthentic. But when enterprises define a legacy transformation and its
roadmap, often the core issue comes to identify the state when one can say that now it is
the time to start the legacy transformation. At this stage the maintenance of the software
becomes very costly. Increased number of regression bugs, even small change deters
developers from touching the code. In general, legacy software usually suffer from : lack
of packaging, redundancy in software components leading discrepancies, out of support
or warranty, issues in collaborating with partners who are already advanced, scarcity of
skilled resources on old technologies, software distribution & WEB support, increasing
maintenance and support cost. In a nutshell, at the crisis point called as „legacy crisis‟
maintenance start to eat most of ICT budget and resources leaving no room for
innovation [1], [2].

Against this backdrop, big organizations are often facing a challenge to transform their
systems to modern day packaged / standard solutions. The broad area of this work is
software re-engineering, which is the process of analyzing an existing software system
and re-implementing it for specific objective [1], [3]. Most of the work in this area
already done is for the legacy transformation, approaches to the legacy transformation
and challenges with their solutions [1], [2], [3], [4]. But this work is one step back at the
level of decision to determine if the situation has arisen when the legacy should be
Chapter 1. Introduction Page |2
transformed. Maintaining legacy at this point is no more economically and technically
viable. This work develops a model for legacy crisis detection.

In fact this work identifies legacy as a multistage phenomenon. After this analysis, the
work is focused to develop a multistage „Legacy Crisis Detection Matrix‟, which in the
first stage gives symptom based detection for the management to initiate the
transformation process. Then the next level of detection goes more at architectural and
code level to do the assessment of the legacy software crisis stage. Both, when combined,
give the elements to take right decision about the legacy transformation.

The study in this thesis reveals that the legacy systems are not only about IT, but also
involve business and organization aspects. Apart from technical challenges, soft issues
have much deep rooted impact [5]. Soft issues are non-technical problems related to
behavioral, psychological, environmental, and managerial issues. They are often hidden
but still they may have deep rooted effect on quality and output [6]. Academia
perspective is more towards the technical aspects of the legacy systems while industry‟s
aspect is more about the business value of the system. At the same time, business world
does not bother till legacy starts impacting and disturbing business processes [7]. This is
the reason why ICT proposes proactively to modernize legacy systems, but business does
not show interest to sponsor the transformation. Without having approval, sponsorship
and ownership from business such initiatives can‟t be launched. Even if they are
launched, they are set to fail [8]. Failures are not only because of technical reasons but
organizational aspects also play big role [9], [10].

This thesis covers these aspects and more importantly it tries to answer following
questions - When to go for legacy transformation? Is it the situation where maintaining
legacy is not economically viable? Has the legacy crisis arrived or is about to arrive? All
these important questions are at the center of this work.

Following section discusses the key concepts and definitions used in this research work.

1.1 Software Re-engineering

Software re-engineering, is the process of analyzing an existing software system and re-
implementing it for specific objective. Software Evolution is mandatory to keep the
solutions viable for the organization [1], [2], [3], [4].

Chapter 1. Introduction Page |3

Lehman‟s three laws make it very evident [3]:

1- A software product must change continually or becomes progressively less useful.

2- The structure of a program tends to degrade as more and more maintenance is
carried out on it.
3- Over a software lifetime, the rate of development is approximately constant (i.e.
almost same in development and maintenance phase).

R. Kazman et al. gave another definition of re-engineering in 1998 [6]. As per these
authors software reengineering is- the process of re-implementing the system in a new
form. It could be new technology, new platform, and new languages used. Reusing of
components need to be judiciously decided in reengineering [11]. Generally,
reengineering is a two-step process. In first step a reverse engineering is applied to have
an abstract description of the system and then forward engineering is applied to create the
reengineered system [12]. So, reengineering can be represented by Equation (1.1) as
culmination of both reverse and forward engineering in sequence. In current scenarios
SOA principles are put in focus to achieve sustainable reengineering [13].

Reengineering = Reverse Engineering + Forward Engineering (1.1)

1.1.1 Reverse Engineering

In reverse engineering process, the existing software is analyzed from code to identify all
its components, their interdependencies and document them. It is basically the step of
reconstructing the design and requirement documents. Reconstruction of documentation
is done from target system implementation perspective.

1.1.2 Forward Engineering

It is the usual method of engineering which follows the conventional flows to implement
the system. It starts with the requirement, goes through modeling, design and coding
phases.

Reengineering is explained via the horseshoe model [3], [14] shown in Fig. 1.1. It has
three broad steps -

1- Analysis of existing system and preparation of a description document starting

from the legacy software code.

Chapter 1. Introduction Page |4

 2- Transforming the old description to the new target requirements.
3- Implementing the restructuring.

Figure 1.1: Horseshoe Model of Reengineering

Re-engineering can be achieved via either re-structuring or complete rewrite of the

software. Restructuring is a representation of one system into other, keeping core of the
system as it is. It remains same at the conceptual level and externally the system behavior
also remains the same. It is mainly some code level reorganization, while rewriting is
fresh implementation of design retrieved from the reverse engineering method.
Depending on the need and conditions, organizations may decide to go for restructuring
or rewriting of the software.

Need of reverse engineering and reengineering is generally result of bad software

reliability. This stage comes after software has spent its life with continuous changes over
it. Generally the issues of reliability in software come in two stages. One is primitive
stage in early life of the software and the next stage of issues in software reliability are
towards the end of software life. This is well represented by bathtub model of software
reliability [10].

Chapter 1. Introduction Page |5

1.1.3 Bathtub Model of Software Reliability
It is a generic reliability model, which states three phases of failure trends. First is high
failure rate in early life of software which decreases with stabilization. Second phase is a
constant failure rate (with random failures), while the third phase is again increasing rate
of failure depicting the wear-out condition. Mostly this stage arrives in legacy systems at
certain stage and finally it enters into crisis [15].

If applications do not evolve and do not respond to changing technology and business,
they becomes legacy. Legacy software are old software which are outdated
technologically, normally it is not known how to cope with them but they are still useful
for the organization. Legacy software had been written years ago using outdated
techniques, yet it continues to do useful work [5].To harness the methodological
framework with proactive capabilities, its roadmap is suggested to be defined with a
highly iterative process model. Each iteration forces the process and system architects to
reestablish alignment between new business process requirements that emerge from new
strategic directions causing the birth of new legacy enterprise systems [4][16].

While legacy becoming outdated, new concepts continually emerge. Applications may
become outdated with respect to current trends in architecture as well [4]. To confirm the
point of legacy crisis, the evaluation of state of architecture plays a key role. In the
present work, Service Oriented Architecture (SOA) and CLOUD architecture are taken as
reference or benchmark for the study. Legacy architecture is compared with each
attribute of SOA and evaluated on SOA architecture principles.

1.1.4 Service Oriented Architecture (SOA)

SOA is a software architecture concept based on the notion of services, and service
repositories facilitated by service bus. A service comprises of a contract, set of interfaces
and methods to call a service. The SOA is shown in Fig. 1.2.

The SOA implementation is focused on a front end application that uses one or more
services. These services are published in service registers. Service bus is arranged to
communicate with services [13]. While from the business perspective [14], [16], SOA is
a concept of business architecture. In this architecture business functionalities and
application logic are made available to SOA consumers. These services are published and

Chapter 1. Introduction Page |6

shared to be reused over the network [17][18]. Existing architecture weaknesses can be
handled via transforming to SOA architecture [19]. Interfaces are medium to expose
these reusable services.

Service contract
Service
Business logic
Interface 1
Implementation
Interface 2 Data

Figure 1.2: Service Oriented Architecture

1.1.5 Principles of Service Oriented Architecture

„Service Oriented Architecture‟ (SOA) principles are stated below in the following
paragraphs [20], [21] and [22].

The Separation of Business from Presentation Logic

In the context of legacy applications, architecture weaknesses are very common. The
code becomes fragmented and misaligned among different layers namely the database
layer, the business logic layer, and the presentation layer. As all these layers are mixed-
up it is not possible to transform them as services. Therefore, there is a need to
appropriately decompose the code from business functions.

The Loosely Coupled Relationship between Services

SOA architecture principle focuses to have independent services. They are free from
cross service dependencies and interactions are defined loosely. It reduces the complexity
in consuming these services. A degree of independence is achieved through
decomposition of different functionalities.

Chapter 1. Introduction Page |7

The Coarse-Grained Nature of Services
Legacy applications comprise of fine grained elements and units. They are implemented
through very small units or operations but not possible to represent as in sizeable chunk
of functional units. SOA services are logical groupings of these small fine grained units.

1.2 Problem Identification

Big enterprises have been using software systems since long to run their enterprise
operations and over time they have evolved as a back-bone of the organization‟s IT
operations. Such legacy software becomes a big challenge for organizations. Sometimes
the huge maintenance cost is not realized as many organizations don‟t benchmark their
existing solutions with the latest solutions available in market. But it is also true that no
organization can run their software in isolation. Big organizations have to deal with
customers having world-wide presence. Such customers do business with several
companies to have solutions to their requirements. If one is able to provide a solution,
competition has to provide the same or better. The problem identification of this work has
been triggered from one of such problems in industry. One classic case of legacy crisis
was experienced by ST-Microelectronics business to negotiate prices with their
customers towards year 2005 – 2006 [7]. Competition in electronics business is tough.
There is always a pressure to have optimum cost. Due to legacy software, the systems
were not able to allow pricing up to the 4th decimal place. Traditionally it was supported
up to maximum of 3 digits after decimal point. But as the competitions adopted new
pricing solutions to go up to 4th digit, company started to lose either business or profit.

Having multiple applications and modules un-packaged in legacy make the issues
manifold. In this referred case also, organization has taken a big hit on business.
Enablement of 4th digit pricing was required to be implemented in all applications
impacted in whole landscape. But, as different applications in legacy are tightly coupled,
one application specific evolution causes impact on others and make it more complex.
Even after implementation goes live, it is not smooth. It is very relevant to put this case
study here to realize the legacy crisis. Following section will discuss about a real case of
industry where a small change caused huge impacts and disruptions to the running
applications.

Chapter 1. Introduction Page |8

1.3 Legacy Case Study: Tragedy of 4th Decimal Place in Unit Price
As discussed in [7], it is very evident that even one simple change for business need may
result into big tragedy for legacy software landscape. Scenario covered in this case study
is repercussions of increasing price field precision from 3 decimal places to 4th decimal
place. In the microelectronics business, volumes are huge with low unit prices. In the
tough competition, quoting the price up to third decimal place was either losing profit for
company or losing business to the competition. Business was requesting enablement
since year 2006 but ICT was not able to fulfil the request because of multiple legacy
applications in full ecosystem starting from quotation till invoicing. More than 500 man
days of effort was initially estimated with huge risk to operations and potential legal
issues in case of discrepancies. Finally the implementation was limited to one key
customer enablement for using 4th decimal place in unit price with more than 700 man
days of effort in implementation and support. This realization was achieved in 2011-
2012. Business had to wait for 6 years for simple implementation which was finally done
with limitations and reduced scope. Post deployment issues were enormous, multiple
interrupts to production took place, business and ICT had to spend days and nights to
come back to normal situation.
This all had resulted in learnings about the ways to manage legacy. Origin of this
research work is one of the learnings identified during the 8-D analysis and 5-why
analysis of the post go-live issues (see Appendix A). It is worth mentioning summary of
these findings. All the problems faced were analysed from root to get the real cause
behind. This analysis is helpful in defining the corrective and preventive actions.

1.3.1 Problem Description & Containment Actions: (Event occurred: 3rd June 2012)
Problem summary is stated in Table 1.1. These problems were quantified by concerned
departments and reported in remedy tool. Remedy tool is used to report the issues faced
by users of all software systems in ST-Microelectronics. This Table 1.1 itself is result of
8-D analysis tool under D-2 section (see Appendix A). HP3K and E1 or Esicom1 in this
case study is the legacy machine which is managed with COBOL application. These
problems caused huge discrepancies in invoices to end customers and intercompany
customers. Recovering back the normal situation and confidence of users and customers

Chapter 1. Introduction Page |9

to the ICT applications required marathon efforts. As listed in Table 1.1, more than 400M
dollar discrepancies were introduced [7].

Table-1.1: Main Set of Problems Highlighted After Go-Live

Reported
Problem Summary Impact Summary Containment Actions
Date
-HP-3K(E1) Software corrected
-Detected by internal customer
P1: Customer wrong on Jun 11th
service for very few customers
Invoice : Invoiced -Magnitude for data
03-Jun-12/ -IT detected 51 customer‟s
on old customer discrepancies June 12th and
05-Jun-12 invoices impacted
backlog price (price backlog price corrected
-Aggregate value (+/-) : around
change not reflected) -Dispatch reports to each regions
70K USD
for credit/debit notes
-E1 Software Corrected June
18th for 1st event and on 23rd
- 40% Interco invoice value
for 2nd
impacted
-Intercompany invoice
-Approximately 340M dollars
P2: Interco wrong discrepancies report sent to CFC
03-Jun-12 discrepancy reported on June
Invoice ( Invoiced on on Jun 18th& 23rd
13-Jun-12 13th
price multiplied by -Recovery actions defined with
20-Jun-12 -On 20th June , other 100 M
10) CFC
dollars discrepancy identified
-Massive intercompany sanity
due to cases not covered by
check program developed and
issue above
installed on June 24th to monitor
if new cases raising
P3: Local SI value in -Software correction done June
Loyang and other Asia sites.
report ( Value in 03-Jun-12/ 18th
Unit price values were
report was multiplied 13-Jun-12 -Customer documents Re-print
multiplied 10 times
by 10) done afterwards

Under the D-4 of 8-D analysis, the root cause is identified for 4th decimal problem. This
is done using 5-why method to reach up to lowest level (leaf node) as shown in Fig. 1.3.

Preventive actions are aimed to never repeat similar problem in any area under the
domain. For this case study, Table 1.2 enlists the identified preventive actions.

Chapter 1. Introduction Page |10

 4th Decimal Problem

Why the Final Why intercompany Why wrong value on

Customer Invoice price invoice was wrong? SI document in
was wrong?E2 Invoice unit price Loyang? Value
Backlog price change multiplied by 10 was multiplied by 10.
did not flow correctly
price was wrong ?
Why E2 backlog
E2 Backlog price
price
change Why invoice price was Why value multiplied
change did notnot
event did
multiplied by 10? E1
flow by 10? E1 SI
flow correctly
correctly to to E1
field changed from 3 to
E1? E1 programs program was not
did not handle well the 4 digit tuned for 4th decimal
price change event.

E1
Whyprograms did did
E1 programs Why E1 field changed
not handle well
not handle well thethe from 3 to 4 digit? Was Why SI local
price change
price change event an un-intentional change programs was not
event? E1 program was not detected. tuned for 4th
logic
change wasevent
incorrect.
did decimal? Not in
not flow correctly the impact analysis
to E1E1 ? program
E1 Why un-intentional component
Why
programs did not change was not detected repository
Why E1 SI local
logic incorrect?
handle well
It‟s complex tothe in tests? Test coverage program was not in
price change
manage Esicom1 event was limited repository?  Was
changes in COBOL. not in ICT portfolio.

Why test coverage was

Why it's complex to limited? Users were Why it was not in the
manage Esicom1 not involved for inv. ICT portfolio?
changes? UAT biz tests Developed locally
case was not tested by Loyang people,
Why users were not
never repatriated to
involved for invoice tests
design? No adequate ICT portfolio
Why UAT Biz case user test environment
Why developed
was not tested?
locally by Loyang -
Never experienced
Why no adequate user test team, never
in past (PA2)
environment? Complete repatriated to ICT
end-to-end (E2E) portfolio? Was not
environment not present included in
governance (PA1,
Why Complete E2E PA7)
environment not present?
HP3K limited hardware
availability and not people
knowing it (PA1, PA3,
PA4)

Figure 1.3: „n-why‟ Analysis for Root Cause Identification

Chapter 1. Introduction Page |11

 Table-1.2: Preventive Actions (PA)
Preventive Target Closure
Action Summary Owner Status Summary
Action(PA) Date

No more modifications Stephane D. Guidelines issued to BSG

PA1 31-Jul-2012
in E1 (CIO) directors

Intense test & validation

Scenarios being added in
PA2 of (E1) scenarios for Annamaria Villa 15-Jul-2012
validation
backlog

Interco invoice test case

PA3 to be added in use cases Jean Haibe 15-July-2012 Added to E1 use cases
of E1

Two E1 knowledge temp.

Esicom1 additional
Sergio ( for one year – phase out
PA4 people just to support 31-Jul-2012
Brambillasca timeline for E1 ) resources
operations
will be engaged

Review change request

Proposal approved , white
process governance
paper on this under service
PA5 (communication plan Antoine Keller 15-Jul-2012
management will be
among all business
issued by OOCIO
groups impacted )

Ensure CFC involvement

Systematically done from
PA6 on project trigger by Marco Moltrasio 06-jul-2012
now on
S&M community

Consider critical local

applications (category Sergio is preparing
„A‟ & „B‟) for ICT Sergio communication with
PA7 31-Jul-2012
portfolio , and follow Brambillasca Claudio and then
change request validation with finance
governance

1.3.2 Lessons Learnt:

The case study derived to following lessons learnt by the organization to manage legacy
applications -
• Changes to be forbidden in Esicom1 (HP-3K) components (very old machine, with
COBOL software). It was a decision taken not to repeat similar crisis.

Chapter 1. Introduction Page |12

• Even after the decision to have no changes in COBOL based system; it may still need
to have minimum critical resource mass to support operations till COBOL is phased
out. This also is a cost of carrying legacy.
• Handle clashing priorities for key resources to focus on comprehensive & timely
closure of post go-live issues.
• Focus on legacy transformation, execute transformation before they enter in crisis.
• Device a mechanism to detect the applications which are entering into legacy crisis
situation.
• Change request governance improvement to be implemented so that not all change
requests are catered without filter. Following controls are necessary to approve a CR
for implementation-
o Organize business project board for approving cross functional Change
Requests (CRs) impacting multiple domains.
o Reinforce communication among all business stake holders to approve CRs
carefully.

This case study shows the severity of the legacy management and transformation.
Organizations intending to replace their legacy systems by the new sustainable solutions,
generally apply best-in-class solution approaches and architectural designs but still face
lot of challenges. Target of this research work is to prevent organizations from facing
such legacy crisis by detecting the crisis point scientifically and not after facing issues.

1.4 Legacy Crisis Attributes

Till date, there is no scientific model to evaluate the state of legacy software and to tell if
it is reaching to the crisis. No clear model is available highlighting the parameters
attributing to legacy crisis and also not known to which extent each parameter contributes
to this crisis. However, only risks and challenges are highlighted in [23], [24], [25].

Broadly these attributes may be evaluated in two stages:

1- Operational attributes; and

2- Software architecture, design and coding level attributes.

Chapter 1. Introduction Page |13

Architecture, design and code level attributes will cover mainly the state of situation for
the architecture and design principles, modularity, reusability, abstraction levels,
interdependencies, object orientation etc. These attributes contributing to legacy crisis are
depicted in Fig. 1.4. On the other hand, the operational attributes cover the operation
issues, vendor support, size/effort ratio of developing a change request, regression
defects, and user interface issues. Above parameters will be evaluated and weighted
factor will be assigned to each parameter and based on these weighted parameters, a
multistage legacy crisis detection model will be developed.

Figure 1.4: Legacy Crisis Attributes

This work is targeted to develop a multistage „Legacy Crisis Detection Matrix‟. Which in
the first stage gives symptom based detection for the management to initiate the

Chapter 1. Introduction Page |14

transformation process. Then the next level of detection goes more at architectural and
code level to do the assessment of the legacy software crisis stage.

This thesis, further, explores and develops overall practical approach for helping the
legacy transformation according to the industry needs. Special focus on the dimensions
which are least talked or explored till now in legacy transformation. Considerations are
not only to be made for technical issues but also the business matters of continuity and
softer issues including people issues and organizational issues too. Some of
organizational issues are discussed in [26], [27], [28]. The thesis also proposes a model
which can be used to analyze the current architecture and code to give legacy crisis
levels. Apart from technical issues, the thesis also presents the issues related to behaviors
[9], [29], highlighted empirical studies of software engineering, and the way they might
be combined with quantitative methods. Finally, the softer issues of legacy
transformation are explored with industry validated ways to address them.

1.5 Research Objectives

Several studies and researches already carried out in the area of legacy modernization by
academia. However, their prime focus was to address issues with legacy systems and
coping with them. However, the industrial aspect is rather untouched. Moreover, efforts
establish that legacy crisis detection model may be framed as a two stage model. This
model may use the operational matrices of organization in first stage to have the legacy
crisis symptoms. In stage-II architectural aspects may be considered. Combining both, the
model may determine the legacy crisis point. While deciding for transformation of this
legacy, certain soft issues come into picture. These soft issues are more linked to
behavioral and organizational aspects which are less visible but more dangerous. As the
literature survey suggests, there is no model prior to this work to assess the legacy crisis
nor there exist any concrete effort to identify the factors responsible for and contributing
to legacy crisis. Literature is also not specific and exclusive about soft issues of legacy
transformation. Considering this, the objectives of the present work are framed as
follows-
 To do the identification and analysis of parameters and their weights attributing to
legacy crisis.

Chapter 1. Introduction Page |15

 To design and develop a model using above parameters for – „Multistage Legacy
Crisis Detection Matrix‟ and derive the weighted factor of transformation matrix
giving a notional value for degree of legacy crisis.
 To develop a model and concept, which can represent the current state of architecture
and design w.r.t. industry standard architecture and design, e.g. SOA (service oriented
architecture) and CLOUD.
 To study the „softer (non-technical) issues in legacy transformation‟ faced by big
enterprises.
 To propose a model to determine the impact of different soft issues, their
interdependencies and determine ways to cope with these issues.

1.6 Research Methodologies and Validation Model

To achieve the above objectives, this work has utilized vast industry experience of a
group of technical experts. Primarily the experts belonging to seven business solution
groups (BSG) of ST-Microelectronics that is a top multinational organization spreading
across 35 countries. These 7 BSG representatives from different countries have
participated in brain storming sessions to contribute in legacy attribute determination and
their weights determination. In these brainstorming exercises a mix population of
engineers and architects were included. Participants to exercise were from different
business solutions groups, ranging their experience from 3 years to more than 20 years
with their roles ranging from coding, design, architects, business analyst and people
managers of ICT and business.
In both the stages of the legacy crisis detection process, it uses previous and current data
sets related to incidents faced, problems identified and defects encountered. Reports
generated from corporate remedy tool used worldwide to analyze issues related to
production systems. To determine threshold values for stage-I crisis determination,
statistical methods were applied. 80 percentile method was used to screen 204
applications to give the threshold value. LCSS computation for all 204 applications were
done and arranged in decreasing LCSS order. LCSS index at 80% from bottom is chosen
as threshold for qualifying to next stage evaluation. Qualitative research methodology
will be used to derive the outcomes on the study of various legacy transformation

Chapter 1. Introduction Page |16

programs executed and revealing the attributes contributing most to the crisis [30][31].
Validation of findings were done via statistical methods, and applying the model on
already transformed applications to deduce that the hypothesis is correct.

The data from qualitative research methodology is applied to incorporate empirical data
and results, description of situation, results and different views etc. [32]. Softer issues
determination and coping with them were studied using post-mortem analysis of legacy
software releases. Post deployment screening helped in identification of these attributes.
Flow chart in Fig. 1.5, defines various stages of this research work.

Study and analysis of issues faced in industry

Literature survey in industry and academia

Problem/gap identification

Study of various approaches and techniques

Development/modification of models

Implementation of models

Result validation/verification of models

Documentation of research work

Figure 1.5: Outline of Research Work

The validation of the developed model and the legacy transformation matrix is done in
following manner as depicted in Fig. 1.6 -
1- The model for detection of legacy crisis was applied in different application domains
of some organizations and compared the results with today‟s gut-feel model and
Delphi decision support model (see Appendix-A).

Chapter 1. Introduction Page |17

2- The model was applied on non-transformed version of applications already
transformed and validated that the model was able to detect the level of crisis
appropriately.
3- Remedy tool used to have operational data of real production systems to see the
history and current operational performance trend of legacy software.
4- Key Performance Indicators (KPI) dashboard: monthly and quarterly used for health
of applications.
5- Remedy reports and business object reports on base data are used to analyze and
validate results.

Monthly/Quarterl Live Remedy Business Object

y KPI dashboards data Reports

Apply
Model
Validate with
already
transformed
Validate Intermediate application results
Results

Final Results Rely on Empirical Validations

Figure 1.6: Validation Model

1.7 Detailed Approach

This section elaborates the detailed steps followed to accomplish the work in this thesis.
Background of the work started from industry issues faced in legacy maintenance at ST-
Microelectronics. Approach for developing the model and implementing it were
individual efforts whereas for enriching it with broader perspective, specific group
contributions were instrumental. A process working group (PWG) ( Constituted of 30

Chapter 1. Introduction Page |18

people; 4 persons from each of the 7 different business solution groups representing
world-wide IT organization and 2 persons from Software Engineering Practice Group
(SEPG)) facilitated the present work with relevant inputs and expert opinion. Every
representative had more than fifteen years of experience of dealing legacy and associated
software engineering. 3 workshops around legacy maintenance and one post-mortem
workshop around soft issues were also used to produce relevant inputs for this work.
Workshops relevant to this work were-

1- Application portfolio assessment exercise and recommendations with Cap-Gemini at

ST-Microelectronics in 2013 [33].
2- Softer issues determination and coping were facilitated by the post-mortem exercise
of SAP-migration program at ST-Microelectronics India in 2013 [34].
3- PWG‟s inputs were sought in „Legacy Architecture Workshop: Archo-2015‟ [35] in
April, 2015 for legacy attributes identification started in this workshop.
4- PWG workshop in Rousset (France) in May 2015 was used to summarize the
software development and evolution processes and determining legacy attributes
contribution [36].
5- PWG workshop in Rousset (France) in Mar 2016 was used to approve various
outcomes of PWG and subgroups of different streams. Aim was also to evaluate the
effectiveness of work being done since 2015 [36].

Following were the main steps followed to define the model-

1- Real issues faced by industry in terms of poor health of legacy applications, eating
lot of resources in legacy maintenance and issue of 4th decimal crisis (section 1.3)
were the trigger point and motivation of the research.
2- First stage of legacy crisis detection is based on the operational attributes of legacy
crisis that were taken from ICT top-page document (see Appendix-A). Seven purely
operational attributes were taken directly from top-page.
3- Gaps were identified while working with only above 7 operational attributes.
Therefore 3 more attributes were added concerning maintenance releases over legacy
and using the performance attributes from release database. Delphi method (see

Chapter 1. Introduction Page |19

 Appendix-A) of group decision making was used to finalize these 3 additional
attributes with the help of PWG in „Archo-2015‟
4- Weights for each 10 attributes were derived by running a rank exercise to rank-1 to 3
each attribute by each participant. Finally giving highest priority to rank-1 and lowest
to rank-3, a total gravity of each attribute was determined. Thereafter, a normalization
factor was applied to make the total 100. Hence found the weights of 10 attributes.
5- Taking the basic outcome from step-3, the model for stage-I has been developed. This
model gives the formula for Legacy Crisis Symptom Score (LCSS) computation.
6- For qualification criteria to enter to stage-II of legacy crisis, threshold determination
was done. Threshold was defined using LCSS computation on 204 applications and
taking a point of 80 percentile.
7- For stage-II the architectural evaluation, again, the legacy issues were gathered.
Asked to provide 10-15 legacy architectural attributes from all 7 BSGs.
8- In next round consolidated distinct 43 attributes were determined.
9- 3rd round of Delphi method was used to rate top 10 issues out of 43 issues, attributes
were ranked on their top-10 scores given by 30 experts. 10 attributes with highest
ranks were chosen.
10- A questionnaire with 25 questions, addressing 10 architectural attributes determined
during step-9 was prepared with the consent of enterprise architects.
11- Along with 25 questions, one architectural matrix was prepared for 10 SOA attributes
and another matrix for 5 CLOUD attributes was also prepared. These questions are
answered in the second stage evaluation and used by the model to determine
architectural health of legacy application under evaluation.
12- A model was developed to compute the Soft Architectural Distance (SAD)
normalized to value 1. SAD for SOA and CLOUD closer to 1 shows poor legacy
architecture while SAD value closer to ZERO shows legacy architecture aligned with
respective standard architecture.
13- Validation of stage-I and stage-II models were done applying on legacy perceived
performing poor in ICT and also on four already transformed applications.

Chapter 1. Introduction Page |20

14- Conclusions derived and validated with PWG for the cases where applications
qualified only stage-I but not in stage-II, and also where model qualified the
applications in both the stages.
15- Outcome of post mortem exercise of DAMLOG and DAMBILL were used to
highlight soft issues faced during legacy transformations and ways to cope with them.

1.8 Thesis Organization

The thesis is further structured as follows to manage the logical flow of study:

Chapter 2 covers the literature review done around legacy transformation, issues with
legacy systems, software reliability factors, managing issues in legacy transformation.
Literature study is divided in 2 broad categories- industrial perspective and academic
perspective. Industrial perspective is covered by white papers published by some top
Information Technology (IT) companies and consulting organizations from internet
sources. Academic perspective is addressed through publications in reputed journals and
proceedings of conference papers. Chapter also discusses about the various international
standards of IT, for software product evaluation and quality attributes of software.
Adopted strategies of legacy modernization, their pros and cons are also discussed.

Chapter 3 describes „Legacy Crisis‟ situation. It discusses the different reasons behind
applications becoming legacy. This chapter explores different attributes of legacy and
their magnitude of effects i.e. determination of weights of each attribute. Symptomatic
parameters, which indicate the degree of legacy crisis are discussed in this chapter.

Chapter 4 describes two stages of legacy crisis detection. Stage-I for LCSS computation
which is based on monthly Key Performance Indictors (KPIs) and second stage
determines if the legacy is in the state of crisis. This model gives flexibility to the
organizations to define their respective threshold points to declare a legacy crisis situation
during SAD computation. A derivation of the weighted factor of transformation matrix
giving a notional value for degree of legacy crisis is also presented in this chapter.

Chapter 5 discusses identification of soft issues and correlation among them. This
chapter also discusses practical approaches to cope with the soft issues. It also deals with
different such soft issues and ways to handle them.

Chapter 1. Introduction Page |21

Chapter 6 presents and discusses all the results and the ways they are validated. All the
data and derivation details are described under this chapter. Finally, conclusions and
future directions are presented.

Two appendices are also attached. Appendix-A introduces different theories used in the
thesis, e.g. Delphi Technique for group decision making. 8-D tool and Eshikawa
(Fishbone) analysis used to determine legacy crisis attributes as a derivation from real
industry problems. All data sources and tools used in the research work, has been
explained in this appendix.

Appendix-B is a technical report on software maintenance, Key Performance Indicators

(KPI) and Legacy Software Health Report (LSHR). LSHR describes compilation of
operational data of legacy software operations and support.

Chapter 1. Introduction Page |22

 2. Literature Review

This chapter summarizes the literature and the work already done around the field
of legacy transformation and software re-engineering. Besides literature from academia,
white papers from companies, published results and indicators from industry are also
used as an important source of information. Particularly, the production data of legacy
applications being used in several wings of ST-Microelectronics, a Hi-tech company with
world-wide presence in all continents is used. 8-D tool and Eshikawa (Fishbone) analysis,
from real industry problems are used to determine legacy crisis attributes (See Appendix
A). Author participated to several industry workshops dealing different aspects of legacy
applications and software engineering practices through software engineering database
[37]. Proceedings and findings of these workshops and special task forces/workgroups
added further to the study.

2.1 Literature Review

Different authors and practitioners defined the legacy systems in their own ways.
Different definitions referred for legacy software are summarized in Table 2.1 [3], [5],
[38].

Table 2.1. Legacy Software Definition Summary

Authors Definition

Legacy software are the software which have grown large, written years
Bennett (1995) ago, use outdated technology, organizations don‟t know how to cope
with them but they are vital for organization function.
Wu et al. (1997) Large and complex software as a result of continuous evolution but no
more modification or evolution is easy.

Weiderman (1997) Legacy software are result of continuous patchwork on mainframe or

desktop computers suffering from several incompatibilities.
Legacy software are systems with-
Rahgozar & Oroumchian  Very old applications running from 20 to 30 years.
 Monolithic big program less integrated.
(2002)
 Very primitive data exchange through files.
 Legacy data handling is navigational or hierarchical
Sneed (2006) Poor user interface with outdated technology.

Page |23
 Authors Definition

Legacy software are the software written in legacy languages e.g.

Colosimo et al. (2007) COBOL, PASCAL etc. with low or no interaction possibilities with
other applications.
Defined primarily old aged systems as legacy software, which are
Stehle et al. (2008) important for organization function but face maintenance issues due to
old age.
Legacy software is not only the old aged but carrying vulnerability in
NASCIO (2008) terms of supportability, maintainability, high availability, robustness
and software or hardware support.
Legacy software are applications, on which development is
Nowakowski (2012) continuously carried over to evolve them matching changing business
needs of market and changing technology.
Legacy applications that have been developed and maintenance carried
Khadka et al. (2013)
over last 30 years or so.

2.2 Legacy Transformation Studies from Industrial Perspective

Legacy transformation is a very wide topic and very relevant for the industry these days.
Though, an extensive literature explaining the legacy transformation approaches exists,
but the careful study reveals several gaps to be addressed.

The „Business Value of Legacy Modernization (Microsoft)‟ [39], a white paper from
Microsoft-supported programs in 2007, highlighted a review of different programs that
can help us to find the best partner(s) and guidance for modernizing legacy systems. This
white paper examines the issue of legacy modernization from a business standpoint [39].
It is designed for top management and executives, which concludes with guidance on
how to create a successful strategy for legacy modernization. This legacy transformation
strategy is depicted in Fig. 2.1. Depending on the application features, business
requirements and cost pressure determines the transformation strategy. For example, if
applications do not meet current business needs, and type of changes are with business
differential then strategy is to go for redevelopment of application.

There are essentially three steps in determining the right approach for any organization,
looking for legacy transformation [39]: These steps are followed by most of the
organizations going for transformation. They are as follows-

Chapter 2. Literature Review Page |24

 Figure 2.1: Legacy Transformation Strategy

1. Application portfolio analysis (APA), to review full landscape of application and

determine if they can be rationalized to reduce the set of application via legacy
transformation.
2. Partner selection, to identify the competent vendors who may help the organization to
execute the legacy transformation program.
3. Validation implementation, to validate that transformed application behavior matches
with the scope stated in AS-IS model.
In 2008, Infosys-corporation has also published a white paper [40], which enlightens
„Legacy Modernization‟ as a viable and safe solution through the various insights. It
covers various risk mitigation techniques along with their pros and cons. It also highlights
the fact that organizations should prefer a suite of modernization techniques over a single
technique. In 2013, comprehensive exercise of application portfolio analysis was
performed at ST-Microelectronics ICT solutions [33]. This exercise was done with the
help of a selected vendor, Capgemini. Capgemini is a famous consultancy organization
with specialized teams working in the area of legacy transformation. Company is a global
leader in consulting, technology and outsourcing. It is with around 200K employees
offices located in more than 40 countries. This APA exercise, revealed the mechanism to
identify the applications for phase-out from portfolio rationalization perspective.

Chapter 2. Literature Review Page |25

Capgemini, used a process to fill the set of questionnaire and give the conclusion report
about the state of legacy.
Capgemini exercise is based on a set of questionnaire in 8 sections. These sections are
namely- general information, technical information, business information, life cycle
management including support, application criticality parameters, internal resources,
external resources and other cost parameters including recurring cost. Detailed questions
under these sections can be referred in [33]. Out of these details, the technical
questionnaires are related to: programming languages, niche programming languages,
application types (SAP, other packages or legacy). For non-legacy applications, the
degree of customization was asked. Information regarding technical obsolescence, code
maintainability, source code availability and documentation were also collected. Business
and user information gathering enquired regarding business sponsors, value for business,
end user rating, number of active users and regulatory requirements in existing solutions.
Although, a systematic study of application portfolio analysis was done but the method
was barely a scientific method. This analysis was simply on some technical elements,
business angles, life cycle, criticality and resources working since past twelve months.
Results derived from such a questionnaire were not giving the real picture of the state of
legacy systems.
This shows that there is a need to study these critical aspects of legacy transformation and
also a need to propose a suitable model to synthesize the industry experience in a
scientific methodology. TCS presented a white paper in 2012 [40] to highlight the
different approaches for modernization, where they have broadly classified it into six
main approaches as depicted in Fig. 2.2. As per the study, the modernization approach for
an organization depends on its current state of business alignment, technology used, and
architecture fitment. Thus, the first step involves the evaluation of modernization
requirements, followed by a recommendation of the right approach, (such as Factory
based business led approach for product rationalization, rules extraction and migration).
Finally, it is evident that the fact that often it is not a single approach, but a blend of
approaches that meets the need. In order to facilitate this blend, evaluation is done in
specific scenario and the effort needed in different dimensions for each approach. These

Chapter 2. Literature Review Page |26

dimensions are business alignment, technology alignment, and architecture alignment
[40].
Business
Alignment
10
9
8
7
Effort Scale
6
5
4
3
2
1 Business Alignment Effort
0
Technology Effort
Architecture Effort

Approach

Figure 2.2: Legacy Transformation Approaches vs. Effort Dimensions

2.3 Legacy Transformation Studies from Academic Perspective

Study of industrial perspective refined our scope of study. It helped to understand the
current gaps in industry for legacy transformation. Based on these, a selective study has
been done from academic perspective also. In 1995, Hafedh Mili et al. [41] have
highlighted that the legacy crisis is attributed by some fundamental design weaknesses.
Lesser reusable components are contributors to such weaknesses. Identifying these and
similar other attributes will help to detect the legacy crisis. They discussed about two
main categories of reuse, namely the black box reuse and white box reuse. In black-box
reuse, the component is integrated in its host environment as-it-is, i.e. without
modifications, while in white box reuse they are used and integrated into their host
environment with some modifications.

According to this work, the average cost of attempting reuse can be formulated as:

Average Sc = [Sc + (1-p).Dc] …(2.1)

Chapter 2. Literature Review Page |27

Where, „Sc’ is cost of searching desired components through databases, ‘Dc’ is the cost
of fresh development; and „p‟: is the probability of finding component in the database.

Reuse is viable only when the following condition is satisfied:

[Sc + (1-p).Dc] < Dc, OR Sc < p.Dc …(2.2)

To favour reuse, it must have an adequate coverage of the library (large p) and make sure
that developers can, quickly, either find the component they need or be fairly confident
that it does not exist.

In the context of white box reuse, the developers must compare the costs of fresh
development vs. effort of searching and reusing existing component. Reuse must consider
any modification if required. The average cost of development with the intent to reuse
can be formulated through Equation (2.3).

(Dev Cost)avg =[Sc + (1-p).(SCapprox + q.Adaptation +(1-q).Dc)] …(2.3)

Here, ‘p’ is the probability finding the component in the database, ‘q’ is the probability of
finding a component with satisfactory approximation, and „SCapprox’ is the approximate
searching cost. Similar to Equation (2.2), the Equation (2.4) is derived to determine if
reuse is viable.

Sc + (1-p) . SCapprox + (1-p) q Adaption cost <= (p + (1-p) q).Dc …(2.4)

Core logic used to determine if reuse or redevelopment is better, is based on cost factor.
This determination in the study was applied on approximation, given by Equation (2.5).

Sc + (1-p).SCapprox < p.Dc …(2.5)

This model talks only about one factor i.e. software component reuse, similar model can
be developed to all the variables attributing to legacy crisis. This is cost based and
approximation formula on the probability of component search hit ratio.

SK Mishra et al. presented their work in 2012 [42], focusing reverse engineering and
legacy transformation to SOA architecture. The detail for creating reusable software
component from object-oriented legacy system through reverse engineering is discussed
here. The authors have developed a model named Component Oriented Reverse
Engineering (CORE) for identification and creation of reusable components. Reverse

Chapter 2. Literature Review Page |28

engineering methodology is adopted to derive components from object oriented legacy
software. Tested independent components are stored and published in a repository.
Further, they are restructured to build the new system which is developed integrating
reusable components into the new system.

The components, which are platform independent and language-interoperable, are

potentially suitable for reuse. Such identified components may not be originally designed
as per modern programming paradigms and hence were not suitable for component based
programming. But with little changes, they are adopted to reuse. Normally, the legacy
components are not compatible with other components. Hence to allow re-use, a wrapper
service would be needed. This is called a component wrapping. Wrapper services allow
programmers not to worry about internal logic of the components. Some additional
features can also be added in identified components. Component wrapping is also used to
eliminate architectural mismatches. SOA studies, challenges, architecture strengthening
is discussed in papers [43] – [50], ranging the time horizon 2006 to 2013. In 2009, Carlos
Matos and Reiko Heckel presented their work on legacy transformation on Service
Oriented Architecture (SOA) [46]. This paper presents legacy system migration towards
SOA architecture. Code fragments are identified as architectural elements and graph
transformation is applied to get the architectural transformation to SOA. This achieved a
high level of automation. Papers [47], [48] use two dimensions, technical and functional
to transform existing application architectures into SOA.

Oladipo et al. [51] presented a model in 2011, based on code pattern matching in both the
dimensions, technical and functional. Legacy modernization approach discussed here is a
reverse engineering methodology on a transformation paradigm. It is aimed for
preserving capital investments and saving production and maintenance costs. The
transformation approach involved retaining and extending the value of the investments on
the legacy system through migration and modernization of the subject system.
Modernization generally transforms a legacy system in three phases: Initialization,
Extraction, and Modernization [52], [53]. The authors in this work presented a multi-
level legacy modernization roadmap that involves information extraction, artifacts
gathering from many sources, knowledge organization, analysis, and information
abstraction. Aggregation of components is done in such a way that redefining the
Chapter 2. Literature Review Page |29
relationships, abstractions, and hierarchical mental models does not alter the original
system [54]. Using the mental models, additional knowledge about the system is
produced. It is normally used because of lack of documentation about legacy systems
[55]. This paper also mentions that the legacy application is already part of today‟s
business operations, a smooth transition is vital, but there is no indication to how the
smooth transition will take place.

Ricardo Perez-Castillo et al. [56] in 2012, demonstrated the ways to improve return on
investment out of legacy by extending it‟s lifespan with smooth functioning. This is
achieved by reducing the development effort via reuse of components as much possible.
It helps to get two main advantages. First, with reuse, development cost is lower
compared to the fresh development without reuse. The second advantage is increase in
lifespan of the legacy systems resulting into improved return on investment (ROI). The
main concept demonstrated in this study is to expose data stored in legacy databases via
web services. The advantage of this approach is to expose common components and data
using web services which is prime focus of SOA approach [48], [49]. This is facilitating
legacy modernization into SOA architecture. This paper also explores the „Architecture
Driven Modernization (ADM)‟. In this paper authors explored the approach based on all
the aspects of current system architecture. A target architecture is defined first and then
the current architecture is transformed into target architecture. Under the ADM
modernization approach discussed in [57], all software assets and application are restored
in current architecture form and transformation is done considering a to-be architecture.
ADM approach has following advantages-

 Making legacy systems more agile and interoperable;

 Maintenance and development cost reduction;

 Increasing legacy life-span, while also improving ROI; and

 Easy integration with other systems and other environments like SOA.

Paper [58] discusses about a tool PRECISO that follows a model driven approach. It is a
semi-automated tool which facilitates the publication, search, and deployment of web
services from legacy relational databases. Still, some manual steps are involved.

Chapter 2. Literature Review Page |30

Belfrit Victor [38] in year 2013, explored the perception of industry professionals about
the legacy systems and their transformation. Also this work analyzes the relationship
between industry and academia. The study elaborates discrepancies in detail about legacy
transformations and how the practitioners perceive them. The main topic of this study is
addressing the gap in the perception of legacy systems between experts from industry and
from academia. Actually, most of the academia researches are too much technology
centric, and do not talk much about business aspects. However, industry is more
interested in business aspects of legacy applications. Industry also focus on business
impacts of doing legacy modernization or not doing it. Therefore, most of the times
industry does not see the benefit from pure academic resources as their references.

B. Schmerl et al. [59] have presented an interesting approach, which uses pattern
matching algorithms to detect the architecture of a running system. The key concept used
here is to explore implementation regularities and knowledge of the architectural styles.
These architectural styles are being used to create a mapping which can be applied to any
system that conforms to the implementation conventions. This mapping is useful to
aggregate the low level behavior specifications to architecturally significant modules.
This approach can be applied to any system that can be monitored at runtime [60], [61].

Literature about the behavioral aspects in legacy transformation were also explored
through available publications. Carolyn B. Seaman, touched upon this topic in 1999 [62],
where impact of non-technical issues were studied. Shikun Zhou et al. [63] in 1999
discussed about softer challenges indirectly in reverse engineering or legacy
transformation. The study was around the reverse engineering software metrics and
problems concerning these metrics. A systematic research approach has been introduced
to develop software metrics for reverse engineering [64]. Core of the work was to
develop a classification of software metrics for reverse engineering. They classified these
metrics of reverse engineering measures into five categories. These five categories
include abstractness indicators, complexity indicators, economic indicators, object-
orientation indicators, and reusability indicators. However, the real application of this
approach will not be seen until the tool of reverse engineering has industrial-strength and
substantial industrial experiments have been carried out. Hence, in this thesis, similar

Chapter 2. Literature Review Page |31

approach was adopted to detect operational and architectural crisis point of legacy in
extensive practical approach.

In 2008, a case study [65] was presented proving the fact that- so often the
implementation problems are not only the complex technical implications but also
involve behavioral aspects, organizational aspects and internal conflicts. So, the softer
aspects of issues also need to be understood and addressed. Indirectly papers [66] – [72]
touch upon non-technical challenges. However, paper does not talk about comprehensive
behavioral and other aspects. These papers do not propose solutions to these softer
aspects. This is very significant in legacy transformation projects which can be further
extended to complete the study to benefit the enterprises.

Legacy transformation to SOA and CLOUD is discussed in [43] – [50], [73] - [76] where
aim was to systematically present the existing researches around SOA and CLOUD
migrations, classify these studies, and compare them. It reveals that cloud migration
research, despite being in early stages of maturity, provides clues around architectural
aspects. Many of these papers suggested the need of a migration framework to help
improving the maturity levels and trust into SOA & CLOUD migration approaches.
Oracle Corporation published a white paper on CLOUD architecture in 2012 [73]. This
Oracle white paper highlighted the enterprise ecosystem for cloud solutions. It also talks
about broad portfolio of complete and integrated products to build Software as a Service
(SaaS), Platform as a Service (PaaS), and Infrastructure as a Service (IaaS) and elaborates
the cloud architecture elements. But it does not highlight architectural gaps with respect
to legacy transformation. Pooyan Jamshidi et al. [74] have elaborated apprehensions
about cloud architecture. The work suggests a lack of tool support to automate migration
tasks along with the need for architectural adaptations to implement a self-adaptive
cloud-enabled systems. In [75] authors also referred to several reference white papers
published by National Institute of Standards and Technology (NIST), around “Cloud
Computing Reference Architecture- 2014”. Focus was on cloud architecture, standards
and implementation. The activities of two optional cloud players, cloud broker and cloud
auditor, were reviewed as their services are necessary in some business circumstances for
the delivery of cloud services. Authors discussed about the fact that softer issues are
much more important than technical aspects. However, it does not elaborate about tool
Chapter 2. Literature Review Page |32
support to automate migration tasks. Overall there is a lack of architectural adaptation
and self-adaptive cloud-enabled systems in existing solutions and were not considered by
the authors for legacy transformation.

Study explored the existing work around softer challenges and referred to published case
studies, challenges, non-technical issues, empirical models and qualitative analyses
during legacy transformation [76] – [90]. Where [76], [77] focus more on defining
strategy, while Richards et al. [78] and Pfleeger S. L et al. [79], [80] focus on empirical
models in their study. Papers, [81] and [[82] touch upon some softer challenges but to
only a particular phase of development. Papers [83] to [85] focus on planning and
management aspects in legacy transformation. [86]-[90] highlight on challenges faced in
transformation. Business rules based approaches are discussed by Len Erlikh et al. in [90]
and [91]. [92] focused on future vision and Simone Kaplan presented financial
considerations in [93].

2.5 Literature Review Conclusion

Available literature around legacy transformation is in abundance for ways of running

legacy transformation, but no literature focuses on models to determine the legacy crisis
situation. A little literature is available on softer challenges in legacy transformation
which does not elaborate on behavioural aspects. Further, no defined approach available
to deal with softer challenges faced in legacy transformation program execution. The
work proposed in this thesis will address these identified gaps to develop a model around
legacy crisis detection as well as exploring all significant softer challenges with ways to
cope with them.

Chapter 2. Literature Review Page |33

 3. Legacy Attributes and their Weights

This chapter deals with identification of legacy attributes and their weights from
operational and industrial perspective. Weights of attributes help organizations to define
their strategy to cope with them. Weights also help in identification of legacy crisis point;
higher the weight - higher the impact on crisis situation.

Following sections describe the situation when the „Legacy Crisis‟ arrives, how it arrives,
factors attributing to legacy crisis situation, and their impacts contributing to legacy crisis
situation. Further, the symptomatic parameters which indicate the degree of legacy crisis
through application health data reported in Key Performance Indicators (KPIs) are also
described. [94] Suggested to migrate the legacy applications before the crisis becomes
unmanageable. The need is due to numerous reasons e.g. solutions using software which
are no more supported, difficult to handle new business concepts, collaboration with
other enterprises for the integrations and exchange of information, consolidation of
functions and data, understanding the precise key functions of software and their impact
on data, challenges in merger and acquisitions due to heterogeneous systems etc. When
mergers and acquisitions among two or more companies happen, IT has big role to play
in adopting data, systems, and processes integrated. If all participating organizations are
not using standard software solutions and one or many are still operating with legacy
systems it causes difficulty to integrate [95], [96].

The legacy software reaches to a level when it starts costing high for their maintenance
and also becomes difficult to find expert resources to maintain them due to technology
obsolescence [97]. Engineers and programmers working on the legacy become almost
irreplaceable due to non-availability of new resources with these skills [98]. This poses a
bigger challenge of handling softer issues with human resources. The work in this thesis
attempts to provide structured approach with practical industry experiences to manage
legacy transformation. The work incorporates learning from industry experience of
managing legacy software solutions for about 20 years in ST-Microelectronics and in
doing so, it uses applications and their release data of seven globally distributed Business
Solution Groups (BSGs) of the organization. These seven groups own applications of
Page |34
their respective business domain. For example Sales and Marketing (S&M) BSG owns
applications used by company‟s sales and marketing department users, such that
applications for customer services for quotation desks, managing contracts, taking
customer orders, confirming the orders and responding back to customers etc. While
finance BSG deals with all invoice and debit/credit related applications.

It is natural that with different communities requesting for the changes in application and
different people working to develop the same may go with different approaches [99].
After certain level of stabilization in solution and resources, engineers move to other
projects. Lack of design and other documents make the situation more complex [100].
Next change requests (CRs) for further maintenance of legacy software are carried out by
people who do not understand the functionality in totality and attributing to make the
systems difficult to maintain. Different modules of the software talk less to each other.
Only minimal level of integration remains, no standard ways like SOA for lose coupling
is used. Finally, to reach a breakeven, the management has to take decision of replacing
the legacy.

3.1 Attributes and Weights

There are several legacy crisis contributing attributes having different level of impacts.
Some of them have higher impact while some others have lower impact. Delphi-
Technique [110] is used to determine list of attributes significantly contributing to the
legacy crisis situation (see Appendix-A). Final outcome was determination attributes to
put in top page KPIs monitored monthly in the organization. Top page is used during ICT
monthly operations review in ST-Microelectronics as a quick glance to overall ICT
operations. It is a summary table and chart of key performance indicators (KPIs) which
give a glance to the application health in one page. It consists of KPIs linked to
operations, new projects, and ICT software releases. Legacy attributes determination
exercise was done in „Legacy Architecture Workshop: Archo-2015‟ [35] with 30 people
workgroup. The work group was constituted by including 4 persons from each of the 7
business solution groups representing world-wide IT organization and 2 persons from
Software Engineering Practice Group (SEPG). Every representative had more than fifteen
years of experience of dealing legacy and associated software engineering.

Chapter 3. Legacy Attributes and their Weights Page |35

Outcome of „Archo-2015‟was weights determination of operational attributes and
architectural attributes of legacy software systems. Questionnaire was defined with
attributing factors against SOA and CLOUD architecture points.

3.2 Determining Legacy Attributes (Operational Perspective)

For stage-I evaluation, i.e. operational impacts based on the operational health of
applications. These attributes are tracked for applications under maintenance and based
on trend of these attribute values. The organizations know the strengths and weaknesses
of applications running in production. These attributes are taken directly from
organization‟s operational matrices. These legacy attributes are also called symptomatic
attributes. ICT Top-page had already 7 attributes reported as KPI. PWG approved that 7
attributes already under Top-page are still relevant. During determination of relevant
legacy attributes, PWG found that apart from reported 7 KPI attributes from operational
perspective, there are some more attributes which are significant. Such attributes are
related to evolution of legacy. Carrying software development over legacy may also lead
to crisis situation. Same has been highlighted in case study presented in section 1.3. So,
some additional attributes from release database were also derived. It was decided to
adopt 3 more attributes (see italic attributes in Table 3.1) and limiting the model up to 10
attributes only. These 3 additional attributes are-

 Effort vs. CR size (man days / function points) last release: Legacy in poor state
takes more effort to develop even a simple change.
 Number of defects in 1st month of new version deployment: Any new release of
legacy usually follows with lot of problems and requires a stabilization period.
 Regression Defects reported in the 1st month after new version: New releases of
legacy results into defects even in the previously working functionality where the
changes were not intended.

This addition was based on group consensus in PWG. Group opinion was based on the
attributes that are derived from organization specific measures being monitored quarterly
and monthly. The attributes determined by the Delphi technique are listed in Table 3.1.
This Table 3.1 also lists the relationship between KPIs with respective attributes and
source of data, where they are reported.

Chapter 3. Legacy Attributes and their Weights Page |36

 Table 3.1: Top Page KPIs and Legacy Attributes

ICT TOP-Page KPI Legacy Attributes Data Source

Number of Interrupts to Production issues ICT Service
Production (ITPs) in a quarter (incidents reported) dashboard1
Number of incidents reported Production issues ICT Service
(per month) (incidents reported) dashboard
Number of questions asked by
User Interface(UI) not in-line ICT Service
users on application behavior
with technological evolution dashboard
(per month)
Number of incident ticket
Reduced vendor support/out of ICT Service
violated Service Level
warranty dashboard
Agreement(SLA)
Number of problem tickets Design Entropy ICT Service
created (per month) (No-Object orientation) dashboard
Number of average man days Time Logging
required in Keep Lights On Skill scarcity System (TLS)
(KLO) support (per month) reports2
Effort vs. CR size (man
Effort vs. CR size Release DB3
days/function points) last release
Number of defects in 1st month of Issues in Integration with
Release DB
new version deployment partners
Regression Defects reported in Regression Defects/Component
Release DB
the 1st month after new version proliferation
Annual attrition rate of engineers
Skill scarcity HR DB4
working in legacy

1. ICT Service dashboard- consists of all issues reported in live applications from remedy tool.
2. Time Logging System (TLS) reports- to report efforts on different ICT activities including KLO.
3. Release DB- Master Release (quarterly) data of ICT applications: past 5 years.
4. HR DB- Human Resource DB, having data of all recruits and resignations
Data 1 and 3 are published ST-Intranet sites, while sources 2 & 4 are accessible to managers of their perimeter. But
reports and outcomes of HR-DB on resignations and TLS are shared among teams (See Appendix-A).

These are symptomatic attributes only, which are used only as qualifying criteria to enter
into architectural evaluation. Hence in this work, these attributes have been picked
directly from organization‟s top page. Several type of issues and attributes in [102], [103]
and [104] making legacy unmanageable.

Chapter 3. Legacy Attributes and their Weights Page |37

3.3 Weights of Operational Legacy Attributes
After finalizing symptomatic legacy attributes for an organization, weights are assigned
to each attribute. Weights are in accordance to their impact on legacy crisis. In „Archo-
2015‟ [35] workgroup has determined the weights to these attributes according to
mechanism described below -

• Workgroup members were asked to rank-1 to rank-3 on paper slip among these 10
attributes. Each 30 participants of workgroup gave rank-1 to 3.

• Paper slips consolidated to put number of ranks received.

• Rank based weights are determined using Equation (3.1), which has rationale to
assign highest weights to attributes ranked 1 by participants, and lowest to the rank-3
attributes. As the same attribute may be ranked 1, 2 or 3 by different group members
hence a notional weight formula used to assign weights as below-

Attribute Weight Wi = ⌈ (3.ρ1 + 2.ρ2 + ρ3). Fn ⌉ …(3.1)

Where ρ1, ρ2 and ρ3 are count of rank-1, rank-2, and rank-3 respectively,

Fn is normalization factor to normalize the weights totaling 100. In this case it was
100/180 i.e. 5/9. Truncation towards infinity is applied to avoid having decimal values to
the attribute weights. The computation is presented in Table-3.2.

These computed weights are base to the Legacy Crisis Symptom Score (LCSS)
computation. LCSS is the stage-I of multistage legacy crisis detection matrix. Stage-I,
considers only the operational matrices hence here only the ICT top page KPIs are used.
Concept developed for LCSS computation is presented in Chapter-4 of this thesis, where
a threshold value for LCSS is also determined. If this threshold value is crossed by a
legacy application, it enters for the 2nd stage of evaluation of crisis based on architectural
aspects.

Determining Legacy Attributes (Architectural Perspective)

For stage-II evaluation, i.e. architectural analysis with respect to industry standard SOA
or CLOUD are based on architectural legacy attributes. They are also determined using

Chapter 3. Legacy Attributes and their Weights Page |38

Delphi technique (see Appendix-A). Again the exercise for determining architectural
attributes was part of „Archo-2015‟ [35].

Table 3.2: Top Page KPI (Legacy Attribute) Weight Computation

(Normalized)
Rank 2 * 2

Rank 3 * 1
Rank 1 * 3

Weight
Rank 1

Rank 2

Rank 3
ICT Top Page KPI

Number of interrupts to production (ITPs) in a 1 3 2 4 2 2 5

quarter
Number of incidents reported (per month) 5 15 4 8 4 4 15
Number of questions asked by users on 2 6 5 10 2 2 10
application behavior (per month)
Number of incident ticket violated Service 5 15 4 8 4 4 15
Level Agreement(SLA)
Number of problem tickets created 3 9 3 6 3 3 10
(per month)
Number of average man days required in „Keep 7 21 2 4 5 5 17
Lights On‟(KLO) support (per month)
Effort vs. CR size (man days/function points) 2 6 4 8 4 4 10
for last release
Number of defects in the 1st month of new 3 9 2 4 2 2 8
version deployment
Regression defects reported in the 1st month 1 3 2 4 2 2 5
after new version
Attrition rate of engineers working in legacy 1 3 2 4 2 2 5
area (per annum)
90 60 30 100
TOTAL
180

Delphi Round-1: In this round each BSG had to provide 10 to 15 attributes contributing
to legacy crisis based on their experience in legacy releases in past five years. Attributes
to be mentioned here are not to be the ones belonging to the symptomatic or operational
attributes. These attributes should primarily consider architecture, design, coding,
programing language, technologies used and other implementation challenges faced.

Raw inputs collected from 7 BSGs namely, Sales and Marketing (S&M), Global
Logistics and Warehousing (GLWO), Finance, Purchasing, Manufacturing, Human
Resources (HR) and Business Intelligence (BI). For the convenience of presentation these
inputs are listed in Table 3.3, Table 3.4 and Table 3.5.

Chapter 3. Legacy Attributes and their Weights Page |39

 Table 3.3: Inputs Received in Archo-2015 (S&M + GLWO)
SN Sales and Marketing- BSG SN GLWO- BSG
1 GUI or batch mode 1 SAP or Not
2 Technology used 2 Package or not
3 Age of application 3 Language specific
4 Interfaces technology 4 Barcode reader enabled
5 Database used 5 Application linked with h/w device
6 Central or local application 6 COBOL in use
7 Logic complexity 7 n-Tier architecture
8 Object orientation 8 Follows SOA principles of architecture
9 Shared library usage 9 CLOUD solution?
10 Documentation state 10 Object orientation
Home grown application or
11 purchased
12 Hand held device enabled
13 User base
14 EDI / Rosetta-Net /B2b/ EAI
15 Authentication LDAP or
application specific

Table 3.4: Inputs Received in Archo-2015 (Finance + Purchase)

SN Finance BSG SN Purchasing BSG
1 How old is application 1 Follows MVC
Common application for all regions
2 or not 2 Application age
3 Security features 3 Documents available
4 Web enabled 4 JAVA or technology used
5 Portable application 5 3-tier architecture
6 Monolithic or modular 6 Database in use.
Component-based software engineering
7 Reliability matters 7 (CBSE)
8 Encrypted data exchange 8 Reuse of components in place
9 Availability ensured 9 Response time
10 Algorithm available and extendable 10 Multisite application
11 Functions used by different domain

These inputs from 7 BSGs are consolidated and resulted in 43 distinct attributes.
Attributes with same name or meaning has been considered only once. For example
GLWO gave “n-Tier architecture” and Manufacturing BSG gave “3-Tier architecture”.
Both have been consolidated to a single attribute “n-Tier architecture”.

Chapter 3. Legacy Attributes and their Weights Page |40

 Table 3.5: Inputs Received in Archo-2015 (ICT Manufacturing + HR + BI)
SN Manufacturing BSG SN HR BSG SN BI BSG
1 CAD/CAM software 1 ERP 1 3-Tier architecture
Design documents :
Concurrency /
2 2 Mode: Online/offline 2 FGD/DD and TGD
multithreading
available
3 Response time issues 3 Age of application 3 Package
Enterprise
Application Integration with ERP
4 4 Monolithic or modular
Integration (EAI) (SAP)
based communication 4
5 Local/central 5 Logic complexity 5 Scheduling a job
6 Portability 6 Package
7 3-Tier architecture 7 Smart card integration
8 Technology used 8 Availability
9 Interface with h/w 9 Secure application
10 Base language
11 Authentication
12 Scheduler in use

BI BSGs did not give sufficient list of attributes, they gave only 5 attributes vs. 10 to 15
as required by each BSG. But work group considered it reasonable as landscape of
solutions in general is isolated for BSG from application context. Only data part is used
by BI as their portfolio contains only reporting applications. Manufacturing BSG gave
very specific issues to their particular experience. All those attributes were potential
targets for filtering in round-2 as they were not common issues for other BSGs.

Once these 43 distinct issues have been consolidated, they all were presented to the full
group for next round of determination for further filtering. These attributes are listed in
Table 3.6. Similar to this exercise, C. P. Holland and B. Light [105] tried to elaborate
critical success attributes during legacy transformation program execution. In paper [106]
issues highlighted in SAP ERP package were highlighted. Few of the reported issues
above and in [107] are commonly reported in this thesis under Table 3.6.

These are attributes covering architecture, platform, implementation details, design

patterns, coding styles, ways of communication interfaces, standard or packaged
solutions etc.

Chapter 3. Legacy Attributes and their Weights Page |41

 Table 3.6: BSG Input Consolidation Delphi Round1
Consolidated BSG Inputs

SN Attributes SN Attributes
1 GUI or batch mode 23 Human Language specific display
2 Technology used 24 Application linked with h/w device
Regional flavour in application
3 Age of application 25
implementation
4 Interfaces technology 26 Algorithm available and extendable
5 Database used 27 Monolithic or modular
6 Central or local application 28 Reliability matters
7 Logic complexity 29 Encrypted data exchange
8 Object orientation 30 Availability ensured
9 Shared library usage 31 Security features
Design documents : FGD/DD and TGD
10 32 Web enabled
available
Home grown application or purchased
11 33 Portable application
package
Component-based software
12 Hand held device enabled 34
engineering (CBSE)
13 User base 35 Reuse of components in place
14 EDI / Rosetta Net /B2b/ EAI 36 CAD/CAM software
Authentication LDAP or application
15 37 Concurrency / multithreading
specific
16 SAP or Not 38 EAI based communication
17 Package or not 39 Authentication
18 CLOUD solution? 40 Scheduler in use
19 Follows SOA principles of architecture 41 Integration with ERP (SAP)
20 Language used 42 Mode: Online/offline
21 Platform used 43 Monolithic or modular
22 n-Tier architecture

Delphi Round-2: As observed in round-1 that out of these 43 attributes many were very
specific to a particular BSG. These particular attributes were not significant in general at
ICT level. Also, defining model with 43 parameters would have been complex to deal
with. This needed to further narrow down the list of attributes for the model by
eliminating some attributes. Target for the elimination was not to lose any attribute which
may impact significantly the determination of legacy crisis situation. With these
considerations and constraints, model has been developed to work with ten most
significant attributes. Each BSG was then asked to mark top-10 attributes out of 43
attributes. After the rating from all BSGs for top-10, a table was built with consolidated
input. Top-10 score against each attribute is counted in last column of the table. Finally,
the attributes were arranged according to their rank of top-10 count and 10 most

Chapter 3. Legacy Attributes and their Weights Page |42

significant attributes were selected being most significant to legacy crisis. Full exercise of
attribute elimination is explained in architecture compendium document [35]. However a
subset is presented in Table 3.7 to show count of top-10 responses against chosen overall
top-10.

Table 3.7: BSG Input Consolidation- Delphi Round2

Purchas
Finance

Manufa
GLWO

cturing
SnM
Overall

HR

BI
TOP-10 (Workshop inputs)

e
top 10

Age of application 1 1 1 1 4
Shared library usage 1 1 1 1 4
Design documents: FGD,DD 1 1 1 1 4
Home grown application or
1 1 1 1 1 5
purchased
EDI / Rosetta Net /B2b/ EAI 1 1 1 1 4
Package or not 1 1 1 1 1 1 6
Follows SOA principles of
1 1 1 1 4
architecture
Platform/Language used 1 1 1 1 1 5
n-Tier architecture 1 1 1 1 1 5
Monolithic or modular 1 1 1 1 1 1 6

3.5 Weights of Architectural Legacy Attributes

Weights of legacy attributes on architecture perspective are based on SOA and CLOUD
principles. These weights are referred from LEGACY_Architecture_compendium_V1.0
document, which is outcome of “Archo-2015” workshop.

3.5.1 SOA and CLOUD Attributes

Following SOA attributes are finalized to be considered- Abstraction, Coarse Grained

Nature of Services, Loose Coupling, Compliance, Interoperability, Search-ability,
Replace-ability, Encapsulation, Law of Composition, and Service Autonomy.

First three are “Fundamental” in nature and others are derived from these fundamental
attributes. As summarized in Table 3.8, weights of 3 fundamental attributes are assigned
20, while most of derived attributes have value 5 and Encapsulation have value 10.

Chapter 3. Legacy Attributes and their Weights Page |43

 Table 3.8: SOA Attribute Weights

Weight Score
SOA Attributes
(Wi)
Abstraction 20
Coarse Grained Nature Of
20
Services
Loose Coupling 20
Compliance 5
Interoperability 5
Search-ability 5
Replace-ability 5
Encapsulation 10
Law Of Composition 5
Service Autonomy 5

Similarly, workshop identified 4 CLOUD design principle attributes. All 5 architecture

attributes are with equal weights i.e. 20. These 5 attributes are- on-demand self-service,
broad network access, resource pooling, scalable/elasticity and measured service.

Based on above two set of legacy attributes determinations legacy crisis issues can be
categorized as described in Table 3.1.

 Effort vs. CR size

 Issues in Integration with partners
 Design Entropy (No-Object orientation);
 Regression Defects;
 User Interface not in-line with technology evolution;
 Component proliferation;
 Production issues (incidents, ITPs and Problems);
 Skill scarcity; and
 Reduced vendor support/out of warranty.

3.5.2 Effort vs. CR size: Carrying out development on legacy systems is costly. New
software development has different benchmarks than the modification to very old legacy.
New development or Change Request (CR) to recent applications (non-legacy) is very

Chapter 3. Legacy Attributes and their Weights Page |44

less compared to implementation effort required to carry out similar level of complexity
CRs in legacy software. Effort and size ratio for legacy is much higher than new
software. For example, from release DB [123] it can be found that for a complex CR,
average implementation effort for Sales Order application (legacy) is approximately 16
days while for recent application Distribution Resource Planning (DRP) application it is
5.6 man days. If this ratio shows a higher trend then it contributes symptomatically to
mark an application as legacy. Actually it‟s repercussion of several deficiencies in legacy.
For example non-robust design will cause more time to carry a change and test, tightly
integrated implementations will impact more modules while implementing a CR.

3.5.3 Component Proliferation (Redundancy): Very often it happens that different

modules maintained by different teams and primarily used by different set of business
users but still they need the cross info for effectiveness. For example the sales users need
to show the logistics information for their orders and customers. In this case Sales Order
application need to interact with VLOG application to display for example shipment
dates and location, carrier information etc.

In case of legacy applications, different modules don‟t talk each other so easily and hence
one module needs to replicate a functionality of other modules causing the redundancy
and then finally resulting into overall less robust solution. This also attributes post go-live
failures where on change is implemented in one module but has been left for one or more
others impacted.

3.5.4 Issues in Integration/Collaboration with Partners: Today the automation is not

only the need inside the enterprise but also in collaboration with other enterprises which
are doing business together. For example supply chain integration is one example of such
collaboration. Where customer sends their demand projections based on their fab outs
and supplier uses the same to feed their production plans and shipments are made
accordingly. This can‟t be implemented without evolving our systems from legacy to
standard software. Similar issues are faced with mergers and acquisitions while adopting
the data and processes of acquired companies.

3.5.5 Design Entropy (No-Object Orientation): Legacy software are the result of
continuous development over old software. This results into poor design and finally bad

Chapter 3. Legacy Attributes and their Weights Page |45

architecture condition. Such design is not object oriented or not following the modern
architecture paradigms. This also results in high maintenance effort of legacy, manifold
complex to do code changes.

3.5.6 Regression Defects: In and out of legacy is not known to anyone and no
documentation exist in most of the cases. Hence any development and changes in legacy
result into regression defects. Even if what is implemented is correct but something else
start misbehaving because it has got impacted without intentional changes. Service
management dashboards clearly show increase of incidents and defects with every SO
release. Increase of average number of issues goes up to 50% to 60% for big release of
efforts more than 100 man-days.

3.5.7 User Interface not In-line with Technology Evolution: Legacy software use old
Graphical User Interface (GUI) which are outdated with respect to current technologies.
Still COBOL and VB6 user interfaces make the applications less intuitive. Applications
go towards natural death. This is a key factor in legacy crisis. Applications with such an
interface cause issues with integration with upstream and downstream process
applications. Also non uniformity is evident to end users. Different functions requiring
multiple application usage with possibly different logons to loose productivity.

3.5.8 Production Issues (incidents, ITPs and Problems): Legacy is well known for it‟s
production issues and unavailability in case of any changes applied in the ecosystem.
High number of incidents reported by users in production environment is one factor.
Unforeseen unavailability is another example of production issue and is used to reported
as Interrupts to Production (ITP). Recurrent incidents cause due to inherent problems in
application.

3.5.9 Scarcity of skilled resources: With time it is becoming difficult to find the skilled
resources on old obsolete technologies used by legacy applications. Engineers are not
interested to learn and work on those technologies due to lesser job opportunities.

3.5.10 Reduced Vendor Support/out of Warranty: Most of the legacy systems are now
in a technology which is outdated and out of support. So it is risky to remain in such a
solution. COBOL based systems on HP3K machines are one such example.

Chapter 3. Legacy Attributes and their Weights Page |46

Big enterprises have most of their key business functionalities running over legacy
software which are now no more a viable solution in today‟s scenario. Most of the
enterprises spend a significant portion of their IT budget to support legacy and to „Keep
Light ON‟ (KLO) on their legacy applications. At the same time IT-need to support
business is becoming more competitive and are required to be less costly. Increasing
expectations from businesses puts pressure on IT to work as business enabler. Legacy
transformation thus becomes key to supporting new business initiatives, linking IT
strategies to business goals, responding to market changes and optimizing the Return on
Investment (ROI). This is why Business IT Alignment (BITA) is another key point in the
journey of transformation. This all pushes us to think for transforming the legacy to the
standard package solution like Enterprise Resource Planning (ERP). Legacy software
have taken this shape in gradual manner and every component developed independently.
They talk less to each other and have lot of redundancy in components from referential,
to Sales Order confirmation and Supply chain, Billing and Invoicing. Systems are hard to
understand. It is difficult to identify precise functionalities, data model and how they are
linked with other applications. Changes to adopt new business scenarios start resulting in
regression errors; however, skilled resources become almost un-available and also it is
hard to manage collaboration with business partners, web enablement, support mergers
and acquisitions. This all result into waste of money, effort, resources etc.

The transformation of systems is more appropriate when an enterprise finds itself

overcrowded with applications and functions resulted from local software adoptions,
mergers and acquisitions, or when various business units have a tradition of operating
independently since old times with home grown or locally purchased solutions. Land up
in a situation where different versions of the same software are deployed with different
systems. They will perform the same functions with desynch and outdated code. Process,
data and services become fragmented, redundant, inefficient, expensive and error prone.
Precautions and steps of migration or transformation are also highlighted here.

The transformation conditions need to be determined before to carry out the

transformation program. Two important aspects need to be ensured. First one is to
identify the situation or critical point when legacy transformation to start and can‟t wait
further. Second is to ensure the conditions of transformation. Potential technical and non-
Chapter 3. Legacy Attributes and their Weights Page |47
technical issues need to be handled before starting the transformation program. In both
these determinations, identification of legacy attributes and their weights is the key.
Attributes and their weights determined in this chapter of thesis will be the base for the
next chapters to define model for LCSS and architectural evaluation. Combination of
these two will finally give the resultant recommendation if legacy application is entering
to crisis situation.

Chapter 3. Legacy Attributes and their Weights Page |48

 4. Multistage Legacy Software Crisis Detection

A two stage legacy crisis detection model is proposed in this chapter. The model
developed here is the only model till date available for legacy crisis detection. The first
stage is based on monthly Key Performance Indictors (KPIs) and the second stage is
rather technical and architectural evaluation of the legacy application code. First stage
evaluation is symptomatic assessment and second stage validates fully if the legacy is in
the state of crisis. This model gives flexibility to the organizations to define their
threshold values for declaring a legacy crisis situation. In summary, the chapter deals
with the design and development of the „Multistage Legacy Crisis Detection Matrix‟
model, using legacy attributes. It also derives the weight factors of the transformation
matrix giving a notional value to represent a degree of legacy crisis.

4.1 Introduction
Legacy software are not easy to replace while being used in production due to their heavy
dependency and tight coupling among different applications. They require a lot of manual
support and interventions to keep the systems running. It increases cost of KLO.
Gradually the situation worsens and it reaches to a point when, direct and indirect cost
becomes as high as unaffordable. When viability of maintenance vanishes, it reaches to
crisis point. Proactive measures to avoid this legacy crisis is the key objective of this
thesis.
The study by Anthony Lauder et al. [94] and by Amey Stone [96] paved the way for
determination of the issues in legacy and coping with them. They provided two choices -
either to maintain legacy or to transform it. But none of them addressed the dilemma of
maintaining or transforming legacy. There may be two main bases of the legacy
transformation decision. The first basis being strategic decision when enterprise goes for
phasing out all old and legacy software and deploy new suit of applications or packages.
In strategic decisions, the maintenance cost and operational issues don‟t play big role in
decision making. It is based on the poor symptoms of legacy application, hence also
referred as symptomatic analysis. The second basis for legacy transformation decision is

Chapter 4. Multistage Legacy Software Crisis Detection Page |49

legacy crisis situation when organization is forced to think for legacy transformation to
remain viable.
In summary, legacy transformation is never a straight forward initiative for many reasons.
Beyond the traditional fears of management about operational risks associated with the
transformation and the challenge with correct technology and solution selection, it is
important to detect if legacy crisis already occurred or is going to occur soon; and
therefore it is the time to start transformation. A scientific approach here is presented in
this thesis to detect the legacy crisis point and help organizations to define legacy
transformation strategy and roadmap with increased confidence.
In this chapter, „Multistage Legacy Crisis Detection Matrix‟ is proposed as
comprehensive mechanism for determining point of legacy crisis. The chapter elaborates
this matrix implementation and usage. In this mechanism the first stage gives symptom
based detection for the management to initiate the transformation assessment. The next
level of detection is architectural level and code level assessment of the legacy software
crisis stage. Approach of assessment in two stages gives flexibility and optimization of
effort in crisis detection. The model and its constituents are described in following
sections.

4.2 Multi-Stage: Legacy Crisis Detection Model

Multistage legacy crisis detection model gives the crisis detection result in two stages.
Stage-I focuses on the economic viability attributes via operational matrices. This is
primarily at the management level on the recommendation of enterprise architects. The
stage-II considers the software architecture, design and coding level attributes. Both the
stages together determine the legacy crisis point for the legacy software under question.
In stage-I, the economic viability attributes cover the operational issues which were
determined in chapter-3 with their weights. As shown in Table 3.1, 8 legacy symptoms
are associated with 10 symptomatic attributes -
 Number of interrupts reported per month in production environment.
 Number of incidents reported per month.
 Number of queries asked by users per month.
 Number of tickets crossing agreed time limit to solve the issue.

Chapter 4. Multistage Legacy Software Crisis Detection Page |50

  Number of inherent application problems reported per month.
 Size and effort ratio for developing a Change Request (CR).
 Regression defects at the early days of new software version deployment.
 Employee attrition rate (per annum) of engineers working in legacy area.

These matrices are usually operational in nature and are periodically being monitored by
management in Operations Reviews (ORs) every month. When the organization‟s
technology roadmap is superimposed with operational reports, it gives the Legacy Crisis
Symptom Score (LCSS).

LCSS threshold limit is determined based on 80 percentile of 204 applications (legacy &
non-legacy). When LCSS score of a particular legacy application crosses this threshold
limit, crisis detection enters into stage-II. Stage - II uses existing technical architecture,
programming languages, platform integrations, and software source code etc. At this
stage the model will again give a numeric notional value to indicate the degree of crisis in
legacy software. This notional value of architectural evaluation is named as Soft
Architectural Distance (SAD) [108]. Degree of SADness is key parameter of stage-II in
legacy crisis detection matrix.

4.3 STAGE-I: Legacy Crisis Detection via Operational Matrices

Stage-I of legacy crisis detection uses operational matrices as parameters and outcome of
this exercise is the LCSS score. It works on the weighted factor method for different
attributes contributing to legacy crisis. Determination of these attributes and their weights
has been done taking inputs from organization‟s way of working, operational matrices in
use, and legacy stakeholders of the organization. As detailed in chapter-3, these have
been determined via taking inputs from software engineers, architects, business analysts,
service managers, solution managers, and solution directors followed by their
consolidation in „Archo-2015‟ through Delphi technique. Even if these attributes are
generic in nature still they need to be revalidated in context to specific organization. To
incorporate this specificity in proposed model, the LCSS computation uses method of
benchmarking to compare the matrices of legacy system vs. average matrices of three
most recent (non-legacy) applications in the organization.

Chapter 4. Multistage Legacy Software Crisis Detection Page |51

Symptoms of legacy crisis become evident when the attributing indicators of legacy
application under question are relatively worse than the average of selected set of non-
legacy applications. These non-legacy applications have to be chosen in such a way that
these domain of application spans, in general, all the applications of the organization in
terms of size, functionality and user base. These non-legacy applications are termed as
“Benchmarked Applications (BAPs)” of the organization. Formula to determine the
LCSS need to be based on the comparison of legacy crisis attributes among legacy
application vs. average attribute values of benchmarked applications. Comparison of
attribute values can be represented in terms of ratio of these values for legacy
applications vs. BAPs. Higher the value of this ratio, poorer is the state of legacy. This
ratio would be termed as legacy ratio. For legacy under crisis, legacy ratio may go up to
the range of 3 to 6 or even higher. This ratio is then multiplied with respective weights of
legacy attribute to determine contributing factor due to one specific legacy attribute.
Applying the weights for each attribute, the score would be normalized to 100. Therefore,
one hundred score is the ideal score with respect to BAPs, while for legacy this score
would be 100 times of the legacy ratio. Overall LCSS is then computed by summing up
these contributing factors for each attribute. A normalization factor NF, Equation (4.4) is
applied while comparing the attributes with respect to BAPs to consider the function
point size and number of users using the legacy application. If legacy is bigger in size and
number of users are more than BAPs‟ average, NF is higher. NF is smaller, if the legacy
is smaller vs. BAPs‟ average. Hence, LCSS has to be normalized inversely for this
normalization factor.
Let Li, denote the value of ith legacy attribute;
BPij denotes the ith attribute of jth BAP application
Number of BAPs chosen for the model= m
1 j m
The average value ith BAP attribute (BPi) =  BPij
m j 1
in
Li
Hence, the aggregate LCSS for all n attributes α  1  j m

   BP
i 1
ij
mj 1

Chapter 4. Multistage Legacy Software Crisis Detection Page |52

Finally, the weights and a normalization factor (NF) is applied to have LCSS after
considering the function point size and user base.
Let Wi denotes the weight of ith attribute.
i n
1 Li
LCSS= . Wi . j m
…(4.1)
1
   BPij
NF i 1

 m  j 1

The value of NF is calculated with the help of Equations (4.2), (4.3) and (4.4).
The outcome of threshold determination [35] suggests that any LCSS score above 300
(empirical) is good enough to mark legacy application for stage-II evaluation of legacy
crisis detection (i.e. architectural analysis).
Score 300, in fact, indicates that legacy performance is 3 times worse compared to non-
legacy benchmarked applications.
For ST-Microelectronics, 3 benchmarked applications were used with 10 legacy crisis
attributes in the proposed model. Algorithm to compute LCSS in this specific case is
explained through Fig. 4.1 below.

LCSS Computation

Take 10 KPI dashboard attributes

Determine weight of each

attribute Chose 3 BAPs to compute NF

Fill matrix: taking operational figures

from service dashboard and release
DB

Compute LCSS using Eq. 4.1

Figure 4.1: Flowchart for LCSS Computation

Chapter 4. Multistage Legacy Software Crisis Detection Page |53

The steps involved are elaborated further-
Step-I: Determination of attributes and their weights contributing to legacy crisis –
operationally. As computed in Table 3.2.
Step-II: Chose 3 non-legacy most recent applications in organization as benchmarked
applications (BAPs) to be used for comparison to determine LCSS.
Step-III: Calculate normalization factor (NF) for legacy application in comparison to 3
Benchmarked Applications (BAPs). This normalization factor comprises two factors; one
is based on number of users and other is based on application size in terms of function
points (FPs).

Let NFU denotes normalization factor on user base; and

NFS denotes normalization factor on size base (function points)
3*( Number of activeusers of the legacy system)
NFU  ( 4.2)
 Number of active users of BAPi
i

3*( Number of function points ( FPs) of the legacy system)

NFS  (4.3)
 Number of FPs for BAPi
i

Finally, the normalization factor for legacy system 

( NFU  NFS )
NF  (4.4)
2
Step-IV: Matrix computation with weight factor based on 10 attributes is finalized.
Computation is shown in Table 4.1. Attributes and their weights in this table are taken
from Table 3.2.
Step-V: Compute final LCSS score using Equation (4.1).
Step-VI: Decision to enter into second stage of computation after crossing the limit of
threshold value of LCSS. (The threshold value is organization specific. However, a score
more than 300 (empirical) is high enough to go for stage-II.

Chapter 4. Multistage Legacy Software Crisis Detection Page |54

 Table 4.1: Legacy Crisis Symptom Score Matrix

legacy score
Factor %
Weight
BAP1 BAP2 BAP3 Legacy Weighted
BAP Avg.

(W)

(L)
Attribute Score Score Score Factor Factor
(Y)
(M) (N) (O) (Z=L/Y) (W*Z/NF)

Number of Interrupts to
Production (ITPs) in a 5 L1 M1 N1 O1 (M1+N1+O1)/3 L1/Y1 W1*Z/NF
quarter
Number of incidents
15 L2 M2 N2 O2 (M2+N2+O2)/3 L2/Y2 W2*Z2/NF
reported (per month)

Number of questions asked

by users on application 10 L3 M3 N3 O3 (M3+N3+O3)/3 L3/Y3 W3*Z3/NF
behavior (per month)
Number of incident ticket
violated Service Level 15 L4 M4 N4 O4 (M4+N4+O4)/3 L4/Y4 W4*Z4/NF
Agreement(SLA)
Number of problem tickets
10 L5 M5 N5 O5 (M5+N5+O5)/3 L5/Y5 W5*Z5/NF
created (per month)
Number of average man
days required in Keep
17 L6 M6 N6 O6 (M6+N6+O6)/3 L6/Y6 W6*Z6/NF
Lights On (KLO) support
(per month)
Effort vs. CR size 10 L7 M7 N7 O7 (M7+N7+O7)/3 L7/Y7 W7*Z7/NF
st
Number of defects in the 1
month of new version 8 L8 M8 N8 O8 (M8+N8+O8)/3 L8/Y8 W8*Z8/NF
deployment
Regression Defects reported
in the 1st month after new 5 L9 M9 N9 O9 (M9+N9+O9)/3 L9/Y9 W9*Z9/NF
version
Attrition rate(per annum) of
L1 (M10+N10+O1
engineers working in legacy 5 M10 N10 O10 L10/Y10 W10*Z10/NF
0 0)/3
area
NF= Normalization
Sum (Weights) 100 factor (FP size and User LCSS using Equation (4.1)
base)

4.4 Determination of Threshold Value for LCSS

LCSS threshold value is determined empirically. In the present case, the threshold
determination was based on 80 percentile value in a set of applications as shown in Table
4.2. Empirical data of software maintenance is used from weekly published operations
and support dashboard data (See Appendix-A). It has used 204 applications of 7 BSGs
and 3 years of data [95]. The method is summarized as follows -
Steps to determine LCSS threshold in the present case:
Step-1: Run LCSS computation on all 204 applications of 7 BSGs.
Step-2: Apply the statistical data-analysis - „rank & percentile‟ on LCSS column.

Chapter 4. Multistage Legacy Software Crisis Detection Page |55

Step-3: Chose threshold based on 80 percentile value (as guidelines from process work
group members in „Archo-2015).
Based on Table 4.2, the 80 percentile analysis gives the LCSS threshold value as 300.
This table is taken from [35].

Table 4.2: Legacy Crisis Symptom Score Percentile Matrix

Application
Application Name LCSS Rank Percentile
ID
155 E-SAMPLE 721.2 1 100.00%
172 PRICE LIST (DCPL,LB,MPP,ER) 476.3 2 99.50%
S2S PLANNING SCHEDULE ( DELFOR
191 461.7 3 99.00%
LOADER, RESPONSE )
22 CLS - MANUFACTURING INTEGRATION 459.3 4 97.00%
23 CLS – PICKING 459.3 4 97.00%
24 CLS - WORLDWIDE SHIPMENT 459.3 4 97.00%
25 CLS (GLOBAL STOCK MGMNT) 459.3 4 97.00%
161 I2 SCHEDULING 451.2 8 96.00%
171 ORDER SCHEDULING (AS,MS,SWAP) 451.2 8 96.00%
83 DM (DEMAND MANAGEMENT IN I2) 432.6 10 94.00%
90 MFS 432.6 10 94.00%
92 MPS 432.6 10 94.00%
131 BACKLOG ENGINE 432.6 10 94.00%
187 RMS (RETURN MANAGEMENT SYSTEM) 421 14 93.50%
193 SGA (SALES GENERAL AGREEMENT) 408.2 15 91.60%
194 SGA AUTHORIZATION 408.2 15 91.60%
SGA KEY CUSTOMER CONTRACT (FOR
195 408.2 15 91.60%
SGA06)
196 SGA PRICE CONTRACT (FOR SGA01) 408.2 15 91.60%
198 SHIP AND DEBIT/CLAIM(CL) 407.4 19 91.10%
199 SO (SALES ORDER) 392.5 20 90.60%
186 PRMIS 389.2 21 90.10%
145 DESIGN WIN 378.2 22 89.60%
201 SO-BATCH (SALES ORDER) 376.4 23 89.10%
192 S2S PO CHANGE 372.1 24 88.60%
S2S ORDERS (INCLUDING
190 369.3 25 88.10%
SBI,CONSUMPTION)

Chapter 4. Multistage Legacy Software Crisis Detection Page |56

Application
Application Name LCSS Rank Percentile
ID
96 PRIS-MANUFACTURING 368.2 26 87.60%
133 BM (BACKLOG MANAGEMENT) 365.2 27 87.10%
165 LEGACY ASIA (POSNEW/MRS/REPORTS) 361.2 28 86.20%
LEGACY USA
166 361.2 28 86.20%
(DISTUS/ICM/INFOBURST/ISO/RSAN)
200 SO KEEP 351.3 30 85.70%
97 PRIS-MARKING 351.2 31 84.70%
146 DISTRI (CLAIMS/STOCK/RESALES) 351.2 31 84.70%
142 CP (CUSTOMER PROFILE) 349.3 33 84.20%
137 BUY ON-LINE (BOL) 348.1 34 83.70%
71 ASSY-BOSCH APPLICATION 342 35 83.20%
156 E-SAMPLE/E-STORE 341.4 36 82.70%
147 DIVISIONAL ORDER 341.2 37 81.70%
189 S2S ORDER RESPONSE 341.2 37 81.70%
126 B2B/EDI - EDI/RN/EDIINT/XML 321.6 39 81.20%
127 B2B/EDI - TLE EDI 311.2 40 80.70%
128 B2B/EDI - WEBMETHODS B2B 301.2 41 80.20%
98 PRIS-PLANNING 300.2 42 79.80%
152 EDI LOADER 281.8 43 79.30%
119 SMI 281.2 44 78.30%
E-ID (ELECTRONIC IMMEDIATE
154 281.2 44 78.30%
DELIVERY)
122 S2S 280 46 77.80%
20 TRAVEL AND EXPENSES 279 47 77.30%
124 B2B/EDI - 2STARWAY 276.7 48 76.80%
111 YCTR (YIELD AND CYCLE TIME REVIEW) 273.6 49 76.30%
85 DMT 272.8 50 75.80%
132 BATCH RESCHEDULING 271.2 51 74.80%
EDI INCOMING (ORDERS,DELFOR,PO
151 271.2 51 74.80%
CHANGE)
EDI OUTGOING (ORDER
153 261.5 53 74.30%
RESPONSE,INVRPT,SENDER)
94 PRIS-API (FLEXIBLE MODEL) 261.2 54 73.80%
134 BM-MACRO 256.9 55 73.30%
69 ADHERENCE AND CONFORMITY 256 56 72.90%

Chapter 4. Multistage Legacy Software Crisis Detection Page |57

Application
Application Name LCSS Rank Percentile
ID
136 BUSINESS PARTNER 252.1 57 72.40%
123 SPEND ANALYSIS 251.3 58 71.90%
130 BACKLOG DISCREPANCY 248.9 59 71.40%
117 BCI 247.8 60 70.90%
84 DMBI (DEMAND MANAGEMENT BI) 246.7 61 70.40%
73 BI@ST 242.2 62 69.90%
30 FLOW LOGISTICS 241.2 63 69.40%
135 BRAND PORTAL STE 237.1 64 68.90%
21 WALL STREET SYSTEMS 235.2 65 68.40%
104 SVI DATA VALIDATION UNIVERSE 234.8 66 67.90%
72 AUTO-ITO 234.2 67 67.40%
61 REPORTING 234 68 66.00%
66 SUPPORT TOOL 234 68 66.00%
160 FOLLUPA 234 68 66.00%
129 BACKCS (BACKLOG CUSTOMER SERVICE) 231.2 71 65.50%
95 PRIS-INTERFACE 219.6 72 65.00%
91 MMDPS 218.6 73 64.50%
164 IRDP 218.4 74 64.00%
180 PRISMA OPPORTUNITY/REGISTRATION 218.2 75 63.50%
110 WIM 214.4 76 63.00%
183 PRISMA PROFILING 213.7 77 62.50%
178 PRISMA INTERACTIVE QUOTING 210.2 78 62.00%
DSSK (DEMAND AND SUPPLY SENSORS
87 210 79 61.00%
AND KPIS)
202 ST E2E COMMUNITIES 210 79 61.00%
197 SGA PRINT (SPECIFIC PRINTING FOR SGA) 204 81 60.50%
182 PRISMA PRODUCT SELECTOR 200.6 82 60.00%
179 PRISMA MPP/MQ QUOTES (SGA04/05) 200.2 83 59.60%
100 R4DA 189.2 84 59.10%
78 CAPACITY DEMAND ANALYZER 184.2 85 57.10%
79 CCAR/DMM/WPP/RFC 184.2 85 57.10%
80 CONSOLIDATED AVAILABILITY 184.2 85 57.10%
81 DATA QUALITY MANAGEMENT – DQMS 184.2 85 57.10%
113 SAP-MM (RAW MATERIAL MGMNT) 182.2 89 56.60%

Chapter 4. Multistage Legacy Software Crisis Detection Page |58

Application
Application Name LCSS Rank Percentile
ID
184 PRISMA QUOTE FOR CONTRACT (SGA01) 181.2 90 56.10%
150 EAI – WEBMETHODS 179.3 91 55.60%
121 POS CYCLE TIME 178.9 92 55.10%
173 PRISMA ALERT/NOTIFICATION 178.2 93 54.60%
93 MTRP 176.9 94 54.10%
32 LABELING 176.2 95 53.20%
39 TCDR 176.2 95 53.20%
11 DSR (DAILY STATIC REPORT) 175 97 51.70%
51 PEOPLEFIRST INTERFACES 175 97 51.70%
52 PEOPLESOFT PAYROLL US 175 97 51.70%
14 MINI DSR 174.3 100 50.70%
50 HR REPORTING(BI) 174.3 100 50.70%
74 BO PRIS-M UNIVERSE 174.2 102 48.70%
75 BO PRIS-P UNIVERSE 174.2 102 48.70%
76 BO SUPPORT 174.2 102 48.70%
77 BORNEO 174.2 102 48.70%
149 DVM (DEMAND VARIATION MONITORING) 172.8 106 48.20%
PRISMA DISTRIBUTOR QUOTE
176 171.2 107 47.70%
(SADA/SGA03)
170 ONLINE SUPPORT 169.7 108 47.20%
107 TCDM 168 109 46.30%
108 TS (TABLE SYSTEM) 168 109 46.30%
163 INDIVIDUAL PASSPORT 165.2 111 45.80%
99 QLIKVIEW 163.4 112 45.30%
89 IPDS 162.2 113 44.30%
CHANNEL DWH (CHANNEL
138 162.2 113 44.30%
DATAWAREHOUSE)
144 DELFOR (DELIVERY FORECAST) 156.4 115 43.80%
86 DQMS 154.2 116 42.30%
174 PRISMA BUDGETARY QUOTE 154.2 116 42.30%
175 PRISMA CUSTOMERS 154.2 116 42.30%
70 AGRATE DATA WAREHOUSE 154 119 41.80%
185 PRISMA REPORTS (QUOTE,OPP, ETC) 149.4 120 41.30%
162 INCENTIVES AND COMMISSIONS 149.2 121 40.80%
1 BIBA (BILLING/BACKLOG) UNIVERSE 145.5 122 40.30%

Chapter 4. Multistage Legacy Software Crisis Detection Page |59

Application
Application Name LCSS Rank Percentile
ID
29 EAI – WEBMETHODS 145.2 123 39.40%
46 ELEAVE 145.2 123 39.40%
41 CABBIE 145 125 38.90%
105 SVI METRICS UNIVERSE 135.3 126 37.90%
106 SVI WEB APPLICATION 135.3 126 37.90%
19 STPARC 134.4 128 37.40%
5 STMR (STMICROELECTRONICS REPORTS) 134.2 129 35.40%
15 ATEB 134.2 129 35.40%
17 SAP-FI 134.2 129 35.40%
18 SAP-TIMESHEET 134.2 129 35.40%
47 EMPLOYEE/MANAGER SELF SERVICE 131.2 133 34.90%
31 INTRASTAT ITALY 131 134 33.90%
38 SAP-LES 131 134 33.90%
118 SAP/MM RAW MATERIALS MRP 129.2 136 33.00%
177 PRISMA GENERIC MODULE 129.2 136 33.00%
204 TERRITORY MANAGEMENT 128.2 138 32.50%
112 SAP/MM 126.2 139 32.00%
67 VIRTUAL LEARNING ENVIRONMENT 125 140 31.00%
68 VIRTUAL LIBRARY 125 140 31.00%
82 DBS 124 142 30.50%
141 COREKEYACCOUNT3YRPLAN 123.3 143 30.00%
2 FLOW FRAMEWORK 123.2 144 21.60%
COLLABORATIVE SOLUTION –
26 123.2 144 21.60%
DASHBOARD
35 SAP GTS TRADE COMPLIANCE 123.2 144 21.60%
43 ECAFE 123.2 144 21.60%
45 E-LEARNING – SABA 123.2 144 21.60%
53 PF - ENTERPRISE LEARNING 123.2 144 21.60%
54 PF-COMPENSATION AND BENEFITS 123.2 144 21.60%
55 PF-EPA 123.2 144 21.60%
56 PF-PEOPLE REVIEW 123.2 144 21.60%
57 PF-RECRUITING 123.2 144 21.60%
58 PF-WORKFORCE ADMINISTRATION 123.2 144 21.60%
59 PF-WORKFORCE DEVELOPMENT 123.2 144 21.60%

Chapter 4. Multistage Legacy Software Crisis Detection Page |60

Application
Application Name LCSS Rank Percentile
ID
60 PS - PAYROLL INTERFACES 123.2 144 21.60%
62 SAP PAYROLL - CHINA BE 123.2 144 21.60%
63 SAP PAYROLL – INDIA 123.2 144 21.60%
64 SAP PAYROLL – PHL 123.2 144 21.60%
65 SAP PAYROLL – SINGAPORE 123.2 144 21.60%
NSA (NEW SERVICE APPLICATION) –
10 123 161 18.70%
STATIC
33 LOGISTICS CYCLE TIME - BO UNIVERSE 123 161 18.70%
34 LOGISTICS DATA MART - BO UNIVERSE 123 161 18.70%
40 ARCOLE 123 161 18.70%
CIA (CUSTOMER INFORMATION
139 123 161 18.70%
AUTOMATION)
203 STANDARD REPORTS (CONTROLLED) 123 161 18.70%
URP (USER REPORTING PROFILE)
8 121 167 16.70%
UNIVERSE
9 MRS (MANAGEMENT REPORTING SYSTEM) 121 167 16.70%
42 DATAFIN 121 167 16.70%
88 EAI – WEBMETHODS 121 167 16.70%
3 MARS UNIVERSE 114 171 15.20%
4 BEST INTRANET 114 171 15.20%
7 BEST DOCSHARE 114 171 15.20%
12 BEST OTHER SOLUTIONS 112 174 14.20%
49 HR ORGANIZATION CHARTING 112 174 14.20%
6 JIT PROCESS 110.2 176 13.70%
116 SRM CATALOG MANAGEMENT 104.8 177 13.30%
114 SAP/SUS 104.2 178 12.30%
143 CRM-SALESFORCE 104.2 178 12.30%
13 GOOGLE SEARCH 104 180 11.30%
48 GESTOR 104 180 11.30%
115 SAP/SRM 103.6 182 10.80%
120 SAP/PP ROUTING AND WORK-CENTER 103.4 183 10.30%
181 PRISMA PRICE TABLES 103.2 184 9.80%
16 BILLING 102.6 185 8.30%
STOCK EVOLUTION FOLLOW-UP
103 102.6 185 8.30%
EVOLUTION

Chapter 4. Multistage Legacy Software Crisis Detection Page |61

Application
Application Name LCSS Rank Percentile
ID
148 DRP 102.6 185 8.30%
140 CMDM 102.2 188 7.80%
101 SAP-PLM (MATERIAL MASTER) 102.1 189 6.80%
102 SAP-PLM (PRIS-P) 102.1 189 6.80%
109 UNCOMMITTED RISK ANALYSIS 101.2 191 5.90%
157 EXTRANET PORTAL 101.2 191 5.90%
44 EEXIT 101.1 193 5.40%
27 CONEX 101 194 3.40%
28 DOCUMENT PRINTING 101 194 3.40%
36 SAP WAREHOUSE MANAGEMENT SYSTEM 101 194 3.40%
37 SAP_GESTOCK 101 194 3.40%
159 FBAV AND RESCHED 87.2 198 2.90%
NON STANDARD REPORTS
169 78 199 2.40%
(ADHOC/ORGZN)
125 B2B/EDI - EDI EXCEL MACRO 56.3 200 1.90%
188 ROMCODE 49 201 1.40%
158 FAQ 45.6 202 0.90%
168 MYTEAMSPACE_STE 37.4 203 0.40%
167 MYTEAMSPACE_ST 36.2 204 0.00%

4.5 STAGE-II: Legacy Crisis Detection via Architectural Analysis

Stage-II of legacy crisis detection is more on the technology front [112]. It is on the
aspects of current architecture of legacy. At this stage, architectural evaluation is done
with respect to Service Oriented Architecture (SOA) principles. The degree of deviation
from SOA standard architecture is used to detect the legacy crisis point. Notion of Soft
Architectural Distance (SAD) [92] represents the state of architecture of legacy vs. SOA.
It uses SOA attributes and answer to 25 architecture questions in context to legacy system
under consideration.
Following considerations were made while defining the notion of soft architectural
distance-
 SAD computation is based on the closeness of attributes computed using
principles of SOA architecture.

Chapter 4. Multistage Legacy Software Crisis Detection Page |62

  Weights are applied while considering standard architecture. For SOA, primary or
fundamental attributes will have higher weightage in evaluating any existing
application‟s architecture, while the derived attributes play minor role in
evaluation.
 Person knowing the application implementation need to respond against twenty
five questions in the prepared questionnaire, around the landscape and
architecture of concerned application.
 If the answer to a particular question is YES, from the SOA Architecture Weight
Matrix the weight corresponding to a particular attribute may be read. If answer is
NO, the weight will be taken as zero, these weights summed for all the questions,
give the observed attribute weight score (Oi) for that particular attribute.
 Standard weights (Wi) of each attribute may be read from header of the SOA
Architecture Weight Matrix. Weights (Wi) are defined by the architects
community of organization against each Service Oriented Architecture (SOA)
attribute.
 Wi – Oi gives the distance in the direction of ith attribute.
 The distance in the attribute space may be determined by summing the difference
multiplied by the weight (standard) of corresponding dimension (attribute).
 This distance is then mapped in the range [0, 1] dividing it by ∑ .
The relation thus can be written as -
∑
Soft Architectural Distance (SAD) degree = (4.5)
∑

The degree of SADness may be calculated for CLOUD architecture also, using the same
equation and method but the CLOUD architecture weight matrix.
A high SAD score represents poor state of architecture. Organization specific threshold
for this score may be derived to take the decision of legacy crisis point. This value
closure to 1 represents bad architecture while lower values represent standard industry
architecture. Algorithm established in this thesis for SAD computation is represented in
flowchart given in Fig. 4.2.Figure 4.2: Flowchart for SAD Computation

Chapter 4. Multistage Legacy Software Crisis Detection Page |63

Application of above approach will be clear with the illustrations further with real
examples. SAD formula is applicable on both SOA and CLOUD. Only the attribute and
weight matrix differs.

4.6 Legacy Architecture Questionnaire Determination

Summary of determination of attributes and corresponding questionnaire for legacy
architecture is depicted in Fig. 4.3. Against each of 10 attributes, relevant questions were
determined and approved by taking opinion of enterprise architects to form the
questionnaire as given in Table 4.3.

•Raw data collection from 7 BSGs

Round-1 •S&M, GLWO, FIN, PUR, MFG, HR, BI: Gave 10 to 15 attributes

•BSG data consolidation

Round-2 •Distinct 43 attributes selected

•All 43 attributes ranked top-10 by each BSG

Round-3 •Top-10 of all attributes selected based on rank of aggregate top-10 count

•Based on Top-10, Organization specific questions formed

Round-4 •PWG + Enterprise architects approved 25 questions as given in table 4.3

Figure 4.2: Delphi Technique for Questionnaire Determination

For each answer „YES‟ in Table 4.4, fill 1 in weight matrix and for „NO‟, put 0. All other
weights are standard from the legacy design compendium document [35]. Bottom row is
sum of all these weights where answer is „YES‟. These aggregates are the observed
values of variable (Oi) in the equation.

Chapter 4. Multistage Legacy Software Crisis Detection Page |64

 Table 4.3: Legacy Architecture Evaluation Questionnaire

Architecture Evaluating Questionnaire

S.NO. TOP-10 Attributes
(Legacy Systems)
1 Package or not Packaged solution?
Home grown application or
2 Home grown applications?
purchased
Home grown application or
3 Development is done using framework?
purchased
4 Platform/Language used Batch Programs in 3 GL?
Ecosystem is heterogeneous (e.g. C, JAVA, SAP, DB
5 EDI / RosettaNet /B2b/ EAI
etc.)?
6 Platform used Nature of services is database centric?
3-Tier architecture to keep
7 n-Tier architecture
presentation and biz layer separated?
8 n-Tier architecture Nature of services is functionality/logic centric?
9 Age of application Age of legacy in range of 20 years?
10 Age of application Age of legacy in range of 10 years not older?
11 Age of application Age of legacy in range of 5 years not older?
12 Shared library usage Services used by SELF/mother application only?
13 Shared library usage Services published and used by self and others?
Services / functions follow international level
14 Follows SOA/CLOUD principles
standards?
Services do not follow international standards but
15 Follows SOA/CLOUD principles
follow at organization level standards?
Application/service design is in the form of functions
16 Monolithic or modular
for one logical set of actions?
17 Monolithic or modular Monolithic structure?
18 Monolithic or modular Functions and Services: signatures clearly defined?
19 Monolithic or modular Functions do not use global or static variables?
Functions/Services signatures are published at
20 Monolithic or modular
common place?
Service names represent the purpose correctly (brief
21 Monolithic or modular
description compliments it)?
User Requirements Document (URD) exists at product
22 Design documents : FGD,DD,TGD
level?
Functional General Design (FGD) exists at product
23 Design documents : FGD,DD,TGD
level?
Detailed Design document (DD) exists at product
24 Design documents : FGD,DD,TGD
level?
Technical General Design document (TGD) exists at
25 Design documents : FGD,DD,TGD
product level?

Chapter 4. Multistage Legacy Software Crisis Detection Page |65

 Table 4.4: SOA Architecture Weight Matrix for Sales Order Application

LAW OF COMPOSITION

SERVICE AUTONOMY
INTEROPERABILITY
COARSE GRAINED
analysis Questions

LOOSE COUPLING

REPLACEABILITY
AS-IS architecture

ENCAPSULATION
Q. Sr. No.

SEARCHABLITY
ABSTRACTION

COMPLIANCE
Answer: Y/N?

(W=20)

(W=20)

(W=20)

(W=10)
(W=5)

(W=5)

(W=5)

(W=5)

(W=5)

(W=5)
1 Packaged solution? 0 0.8 0.5 0.5 0.2 0.2 0 0 0.5 0.1 0.1
2 Home grown applications? 1 0.3 0.1 0.1 0.1 0.1 0 0 0.1 0.1 0.1
3 Development is done using framework? 0 0.5 0.2 0.2 0.2 0.2 0.2 0.2 0.5 0.4 0.1
4 Batch Programs in 3 GL? 1 0.3 0.2 0.1 0.1 0 0.1 0.1 0.2 0.1 0.1
3-Tier architecture to keep
5 1 0.6 0.3 0.3 0.3 0.2 0.2 0.2 0.2 0.4 0.3
presentation and biz layer separated?
6 Monolithic structure? 1 0.1 0.1 0.1 0.1 0.1 0 0 0.1 0.1 0.1
Ecosystem is heterogeneous (e.g. C, JAVA, SAP,
7 0 0.4 0.4 0.3 0.2 0.5 0.6 0.6 0.2 0.2 0.2
DB scripts etc.)?
8 Nature of services is database centric? 1 0.5 0.5 0.4 0.3 0.2 0.2 0.2 0.2 0.4 0.3
9 Nature of services is functionality/logic centric? 0 0.7 0.5 0.3 0.3 0.3 0.2 0.2 0.2 0.2 0.4
Age of LEGACY in range of
10 1 0.1 0.1 0.1 0.1 0.1 0 0 0.1 0.1 0.1
20 years?
Age of LEGACY in range of
11 0 0.3 0.2 0.1 0.1 0 0.1 0.1 0.2 0.1 0.1
10 years not older?
Age of LEGACY in range of
12 0 0.6 0.4 0.3 0.3 0.3 0.4 0.6 0.5 0.5 0.6
5 years not older?
13 Services used by SELF/mother application only? 1 0.3 0.3 0.4 0.6 0.5 0.5 0.6 0.4 0.4 0.4
14 Services published and used by self and others? 1 0.8 0.7 0.7 0.3 0.4 0.4 0.6 0.5 0.5 0.6
Application/service design is in the form of
15 1 0.8 0.6 0.5 0.4 0.5 0.5 0.6 0.4 0.4 0.4
functions for one logical set of actions?
Services / functions follow international level
16 0 1 1 1 0.8 0.8 0.6 0.8 0.8 0.8 0.8
standards?
Services do not follow international standards but
17 1 0.8 0.6 0.5 0.7 0.6 0.6 0.6 0.7 0.4 0.6
follow at organization level standards?
18 Functions and Services: signatures clearly defined? 1 0.6 0.5 0.5 0.7 0.6 0.9 0.9 0.5 0.4 0.6

Chapter 4. Multistage Legacy Software Crisis Detection Page |66

 LAW OF COMPOSITION

SERVICE AUTONOMY
INTEROPERABILITY
COARSE GRAINED
analysis Questions

LOOSE COUPLING

REPLACEABILITY
AS-IS architecture

ENCAPSULATION
Q. Sr. No.

SEARCHABLITY
ABSTRACTION

COMPLIANCE
Answer: Y/N?

(W=20)

(W=20)

(W=20)

(W=10)
(W=5)

(W=5)

(W=5)

(W=5)

(W=5)

(W=5)
19 Functions do not use global or static variables? 0 0.5 0.5 0.5 0.4 0.6 0.6 0.9 0.5 0.4 0.6
Functions/Services signatures are published at
20 0 0.6 0.5 0.5 0.7 0.6 0.9 0.9 0.5 0.4 0.6
common place?
User Requirements Document (URD) exists at
21 0 0.3 0.4 0.4 0.1 0 0.1 0.1 0.2 0.1 0.1
product level?
User Requirements Document (FGD) exists at
22 1 0.6 0.5 0.5 0.2 0.2 0.9 0.3 0.3 0.2 0.3
product level?
User Requirements Document (DD) exists at
23 0 0.3 0.4 0.4 0.1 0.2 0.1 0.1 0.2 0.1 0.1
product level?
User Requirements Document (TGD) exists at
24 1 0.3 0.4 0.4 0.1 0.2 0.1 0.1 0.2 0.1 0.1
product level?
Service names represent the purpose correctly
25 0 0.3 0.4 0.4 0.1 0.1 0.1 0.1 0.2 0.1 0.1
(brief description compliments it)?

Chapter 4. Multistage Legacy Software Crisis Detection Page |67

 Table 4.5 Computation for Degree of SADness - SOA

Observed
Weight
Analysis wi
SOA Attributes Score Wi*Wi
Score (Wi -Oi) (wi-Oi)
(Wi)
(Oi)
Abstraction 20 3.9 16.1 322 400
Coarse Grained Nature
20 3.1 16.9 338 400
Of Services
Loose Coupling 20 2.9 17.1 342 400
Compliance 5 3.1 1.9 9.5 25
Interoperability 5 2.6 2.4 12 25
Search-ability 5 2.6 2.4 12 25
Replace-ability 5 2.7 2.3 11.5 25
Encapsulation 10 2.7 7.3 73 100
Law Of Composition 5 2.5 2.5 12.5 25
Service Autonomy 5 2.7 2.3 11.5 25
100 Sum Wi*(Wi -Oi) 1144 1450
Soft Architectural Distance (SAD) score using Equation (4.5) 0.789

As illustrated in Table 4.5, for Sales Order application, Equation (4.5) gives SAD score =
0.789 on SOA architecture benchmark. This score is close to 1 depicting the application
being architecturally poor in condition.

4.7 SAD computation with CLOUD Architecture Principle

Model developed for SOA is also applicable to CLOUD architecture. CLOUD
architecture principle is based on 5 attributes. Table 4.6 represents weights against each 5
attributes and Table 4.7 represents the computations. All these are with equal weights.
Model proposed here helps in detecting the legacy crisis point in 2 stages. In first stage,
the symptom is indicated in LCSS score, which provides a systematic basis for
management to decide whether the situation needs to be analysed further or not. In the
IInd stage, degree of SADness is computed. More this score is close to 1, more severe is
the legacy crisis. This helps the management to take the decision whether legacy
transformation program to be started now or organization can wait further by extending
the life-span of legacy.

Chapter 4. Multistage Legacy Software Crisis Detection Page |68

 Table 4.6: CLOUD Architecture Weight Matrix for Sales Order Application

Answer : YES=1/NO=0 For

AS-IS architecture analysis

On-demand self-service

Scalable and Elasticity

Broad network access

Resource pooling

Measured service
Q. Sr. No.

Questions

(W=20)

(W=20)

(W=20)

(W=20)

(W=20)
SO
1 Packaged solution 0 1 0.8 0.8 1 1
2 Home grown applications? 1 0.3 0.3 0.3 0.2 0.3
3 Development is done using framework? 0 0.5 0.4 0.5 0.6 0.4
4 Batch Programs in 3 GL? 1 0.3 0.2 0.2 0.2 0.6
3-Tier architecture to keep
5 1 0.6 0.3 0.6 0.3 0.2
presentation and biz layer separated?
6 Monolithic structure? 1 0.2 0.2 0.1 0.3 0.2
Ecosystem is heterogeneous (e.g. C,
7 0 0.4 0.4 0.3 0.7 0.5
JAVA, SAP, DB scripts etc.)?
8 Nature of services is database centric? 1 0.5 0.5 0.4 0.3 0.2
Nature of services is functionality/logic
9 0 0.4 0.5 0.6 0.5 0.5
centric?
Age of LEGACY in range of
10 1 0.1 0.1 0.1 0.1 0.2
20 years?
Age of LEGACY in range of
11 0 0.3 0.3 0.3 0.3 0.2
10 years not older?
Age of LEGACY in range of
12 0 0.6 0.4 0.6 0.6 0.3
5 years not older?
Services used by SELF/mother
13 1 0.3 0.3 0.4 0.6 0.5
application only?
Services published and used by self and
14 0 0.8 0.7 0.7 0.7 0.8
others?
Application/service design is in the form
15 0 0.8 0.6 0.5 0.4 0.5
of functions for one logical set of actions?
Services / functions follow international
16 0 1 1 1 0.8 0.8
level standards?
Services do not follow international
17 standards but follow at organization level 1 0.5 0.6 0.5 0.7 0.6
standards?
Functions and Services: signatures clearly
18 1 0.6 0.5 0.5 0.7 0.6
defined?
Functions do not use global or static
19 0 0.5 0.5 0.5 0.4 0.6
variables?
Functions/Services signatures are
20 0 0.7 0.5 0.5 0.7 0.6
published at common place?
User Requirements Document (URD)
21 0 0.3 0.4 0.4 0.1 0
exists at product level?
User Requirements Document (FGD)
22 0 0.4 0.5 0.5 0.2 0.2
exists at product level?
User Requirements Document (DD)
23 0 0.3 0.4 0.4 0.1 0.2
exists at product level?
User Requirements Document (TGD)
24 1 0.3 0.4 0.4 0.1 0.2
exists at product level?
Service names represent the purpose
25 correctly (brief description compliments 0 0.7 0.6 0.6 0.5 0.6
it)?

Chapter 4. Multistage Legacy Software Crisis Detection Page |69

 Table 4.7: Computation for Degree of SADness - CLOUD
Weight Observed
Cloud Attributes Score Analysis Score (Wi -Oi) Wi(Wi-Oi) (Wi)2
(Wi) (Oi)
On-demand self-
20 3.7 16.3 326 400
service
Broad network
20 3.4 16.6 332 400
access
Resource pooling 20 3.5 16.5 330 400
Scalable and
20 3.5 16.5 330 400
Elasticity
Measured service 20 3.6 16.4 328 400
100 Sum Wi*(Wi -Oi) 1646 2000
SAD Using Equation (4.5) 0.823

This model was applied to detect the legacy crisis symptom indicated in matrices using
Remedy tool reports for the ST-Microelectronics legacy applications in ICT. LCSS score
for Sales Order application was computed to be more than threshold value 300, which is
then submitted to stage-II for SAD score computation.
Similarly, the threshold value for degree of SADness based on SOA and CLOUD, is
empirically determined and consented by „Archo-2015‟ [35] as follows. As stage-II is the
final evaluation and not only the indicator hence it is not purely a single numerical
threshold value. Any SAD score less than 0.6 is clear indicator of sustainable
architecture, while when it is more than 0.8 is clear indication bad architecture. However,
values in the range of 0.6 to 0.8 requires human intelligence and in this case, other softer
factors may play role in decision making. Stage-II‟s is a manual decision having inputs of
SAD computation. Degree of SADness for Sales Order come out to be 0.789 with respect
to SOA architecture, while 0.823 with respect to CLOUD architecture. Both the stages
qualify it perfectly for legacy crisis. LCSS score correctly gave the indication that most
of the IT budget was eaten up by KLO activities leaving no room to think for
transformation. Results of stage-I were supported with stage-II results and management
took decision to include the Sales Order, legacy application in transformation roadmap.
LCSS model is implemented with monthly dashboard reports, which do systematic LCSS
computation for each application presented (legacy or non-legacy). As it is generated

Chapter 4. Multistage Legacy Software Crisis Detection Page |70

monthly, there is also a trend available to indicate if the situation is deteriorating.
Detailed results and discussions are presented further in Chapter-6. While this model
helps in detecting the legacy crisis point of legacy applications, it also indicates even for
new application that while carrying over the changes, whether the state of architecture
and application robustness are compromised.
Technical approaches to address the legacy transformation has already been worked by
several authors in legacy transformation. However, this transformation is not only the
technical subject. There are several softer challenges which need to be addressed in
legacy modernization journey. Typical softer challenges are: natural inertia, fears of
losing jobs, indispensability syndrome, legacy knowledge only remains in minds not
digitized, week business case, not freezing the evolution of legacy while transforming it,
not setting right expectations with stakeholders about the results of transformation etc.
Solution to these issues are also under the scope of this work, presented in next chapter.

Chapter 4. Multistage Legacy Software Crisis Detection Page |71

 5. Soft Issues: Identification and Coping

The term “Soft Issues” is introduced in Chapter-1 under introduction. Current chapter
details the identification of soft issues in legacy transformation programs which are less
visible upfront but most impacting in the success of the transformation program. This
chapter also establishes the interdependencies or correlation among these soft issues and
also presents the measures to be taken to cope with these soft issues. This study based on
post-mortem analysis of real programs is unique to reveal soft issues experienced through
legacy transformation programs [34]. Similar attempt on smaller scale was made by Kim
Man Lui in [107].

Legacy software applications are well known for their importance to the organization but
less maintainable due to huge incremental changes over years. A situation comes when
managing legacy becomes a crisis, costing adversely to the organization. This forces
organizations to go for legacy modernization. In the journey of this transformation, often
it is seen that the focus remains around the technical solutions and challenges. Still
several programs fail miserably because of ignorance in handling the softer issues with
the stakeholders of the program [107], [109]. This work focuses on coping up with such
softer issues, human psychology, organizational challenges, management role,
stakeholder‟s confidence and contribution.

There are several studies done via post mortem analysis of legacy transformation
programs. Runeson et al. in 2012 [65], presented a case study to deal empirically the
issues in software engineering. Here, authors presented how a program which was going
to failure was converted to success. In [102], Herman Tromp and Ghislain Hoffman have
suggested a methodology to follow certain steps to make the transformation successful.
Authors suggested to have a correct and agreed „as-is‟ situation in current environment
and architecture in the form of standard document. AS-IS document describes the current
implementation while TO-BE document elaborates blue-print of future implementation.
Hence, the work also suggested to have separately determined „to-be‟ technical and
deployment architecture. A critical evaluation was then suggested between „as-is‟ and
„to-be‟ situations. While doing this, authors also touched the softer issues and risks in

Page |72
study and hinted to have management perspective. However, the work mentioned nothing
about coping with the softer challenges. Studies presented in [31] and [103] focus on
lessons learnt from programs which were failed. These are also helpful to avoid similar
mistakes while running the transformation programs. Few studies were performed based
on post-mortem of successfully executed programs [53], [55]. In [107] Kim Man Lui and
Keith C. C. Chan, have focused on the team structure and team composition to bring the
effectiveness in the program execution.

All above studies were with the intention to find the shortcomings or areas of
improvement in technical and behavioural aspects.

5.1 Softer Challenges and Coping with Them

The inputs in this section are based on the legacy transformation programs executed at
ST-Microelectronics; primarily based on the post-mortem analysis of company‟s Global
Logistics and Warehousing (GLWO) applications. Coping with these issues are well
proven in Hi-tech industry domain legacy software transformations. Findings in this
study are based on hypothesis, which is proven true when applied in execution. Base data
to validate the hypothesis is used from Enterprise Project Management (EPM) tool and
Remedy tool for tickets being generated in production environment. Projects post-
mortem exercise is another key input to this study. Fig. 5.1 is high level flow chart to
show the method of determining the softer challenges with the help of 55 technical,
managerial and analyst experts. Compilation of the lessons learnt exercise of DAMLOG
and DAMBILL transformation programs also helped in determining the softer
challenges[34].

5.2 Determining Soft Issues

DAMLOG and DAMBILL post-mortem analysis is used for identification of soft issues.
DAMLOG application handles company‟s logistics operations, while DAMBILL is
application for handling company‟s billing procedures. However the execution of these
programs were successful, but they were delayed by more than 300%, even with resource
persons inducted more than double compared to what was estimated [35].

Chapter 5. Soft Issues Identification and Coping Page | 73

 START

Lessons learnt All 55 experts to Prepare

exercise with 55 provide the TOP- Questionnaire and
experts to determine 10 list of soft consolidate
soft issues issues responses

Classify issues in:

organizational and
individual level

Interdependency determination
using correlation analysis

Figure 5.1: Flow Chart-Softer Challenges Determination

Apart from the vendors and consultants, more than 100 resource persons worked on these
transformation programs spending on an average more than 12 hours a day with lot of
continuous stress. Study utilized the experience and feedback on execution of these two
transformation programs [35] with the motive to find solution avoiding such situations in
future.
Measures were taken to mitigate the major risks to make the program successful which
gave lot of learnings. The post-mortem analysis was done to derive the conclusions out of
these learnings. Inputs from 55 people including software engineers, business analysts,
project-mangers, program-managers, consultants, and senior management teams (across
34 different countries with varied cultures) are utilized for the analysis presented. Experts
had to give TOP-10 contributing factors which created hurdles during the lifecycle of the
project execution of DAMLOG and DAMBILL. Finally this list of issues was classified
by clubbing similar issues giving a common name. All TOP-10 issues with frequency
more or equal to 20 (around 40% of participating population) are presented in following
Table 5.1. These are the significant soft issues which affect the execution and result of
the legacy transformation programs. Following sections will discuss these issues and
ways to cope with them.

Chapter 5. Soft Issues Identification and Coping Page | 74

 Table 5.1: Lessons Learnt Workshop Responses - DAMLOG and DAMBILL
Factors Identified as
TOP-10 by more than 20
S. No. Cumulative Frequency of TOP-10 issues (Left to Right)
persons(AROUND 40%
of population)
1 Natural inertia* 12 4 7 3 5 3 3 4 2 1 44
2 Fear of losing jobs* 2 4 3 2 2 3 2 2 3 2 25
Indispensability
3 6 6 4 4 1 3 3 6 1 34
Syndrome*
Legacy knowledge resides
4 3 2 1 4 1 4 1 3 2 4 25
in minds*
5 Weak leadership 2 4 3 4 2 3 1 1 20
Insufficient
6 1 2 1 5 2 2 2 2 3 20
communication
1
7 Lack of clarity in vision 1 1 2 2 5 2 2 4 20

8 Weak business case* 2 2 2 4 2 3 4 1 1 4 25

Lack in management
9 2 4 3 2 1 3 3 2 20
commitment
Organization structure
10 1 4 2 1 7 4 6 1 1 27
/program governance *
Not freezing evolution in
11 2 4 1 2 1 5 4 2 2 2 25
legacy systems*
12 Incorrect prioritization 2 3 4 6 4 1 20
Treating as only ICT
13 1 1 4 2 2 2 4 4 20
program
Not addressing business
14 2 2 1 3 1 6 4 6 25
change mgmt *
Not setting right
15 5 3 4 2 2 5 5 26
expectations *
16 Bad system architecture* 3 3 1 2 3 7 7 1 27
No effective tools of
17 1 4 1 8 6 20
estimation
18 Bad technical choice 1 6 3 2 2 1 4 5 2 26
19 Low technical know how 1 1 4 3 1 5 5 1 3 24
TOTAL 50 50 49 48 46 47 51 47 43 42 473

Note: Table 5.1 is a partial presentation of data. Total people responded 55, many people did not list all 10
factors. All attributes which got twenty or more score in TOP-10 count are put in this table. The complete
data can be referred to [116].

‘*’: indicates all issues rated in TOP-10 by 25 or more people in workshop.

Chapter 5. Soft Issues Identification and Coping Page | 75

The above data underlines the following facts:
 Nineteen classes of attributes rated by twenty or more people under TOP10.
 Fifteen identified attributes are non-technical issues/softer challenges.
 „Natural inertia‟ is rated as top-most issue by maximum 12 people, 44 rated in
TOP10.
 Technical issues are perceived lesser impacting compared to softer issues.
 Softer impediments and challenges were perceived significantly impacting the
program execution.
Result of this analysis was the identification of most significant soft issues which were
rated in top-10, by 25 or more experts in their responses. A total of 9 such soft issues are
listed in Table 5.2. These soft issues are further classified as individual and
organizational issues.

Table 5.2: Soft Issues Classification (Organizational and Individual)

S. No. Soft Issue Issue level

1 Natural inertia Individual
2 Fear of losing jobs Individual
3 Legacy expert‟s – „Indispensability Syndrome‟ Individual
Legacy knowledge resides in minds rather than being
4 Individual
digital
5 Organization structure program governance Organization
6 Weak business case Organization
Not setting right expectations of legacy transformation
7 Organization
results
Not freezing evolution in legacy systems and insisting
8 Organization
legacy function in new solution scope
9 Not addressing business change management Organization

5.3 Interdependencies: Softer impediments

Typically non-technical issues are related to human behaviour, organization behaviour,
person‟s psychology and organization structure.

Chapter 5. Soft Issues Identification and Coping Page | 76

Each soft issue was evaluated against two related questions and answers from all 55
experts as described in section 5.2. Therefore, total responses in Table 5.3 were 110. The
responses were collected from 1 to 5 as described below.

1- Strongly Disagree
2- Disagree
3- Somewhat agree
4- Agree
5- Strongly Agree

5.3.1 Issues and Evaluating Questions: Individual

Soft issues and their respective questions are summarized below [35], [110], [111] -

Natural Inertia:
a- Switching my profile from one role to other is a value add for me?
b- Switching one s/w language, package or platform to other is good for my carrier?

Fear of losing jobs:

a- Bringing packages instead of legacy would give me opportunities?
b- By replacing the legacy, company wants to reduce ICT workforce?

Legacy expert’s Indispensability Syndrome:

a- It is easy to move people from one role to other?
b- It is not easy to simply fire experienced people, as they have great knowledge?

Legacy knowledge resides in minds rather than being digital:

a- Adequate documents are available on legacy?
b- Center of Excellence (COE), have sufficient knowledge about IN & OUT of legacy?

Following sections will determine the correlation among the soft issues. They elaborate
the meaning of interdependencies experienced among the various soft issues under
consideration.

Chapter 5. Soft Issues Identification and Coping Page | 77

 Table 5.3: Responses to Questionnaire (Individual Soft Issues)
Individual Soft Issues
S.NO. Natural Legacy expert‟s: Fear of Legacy knowledge resides in
inertia „Indispensability Syndrome‟ Losing Jobs minds rather than being digital
1 5 1 5 1
2 5 1 3 1
3 2 2 2 2
4 2 2 2 2
5 5 2 5 2
6 4 2 2 1
7 5 2 5 2
8 5 2 5 2
9 4 2 4 2
10 4 2 4 4
11 4 2 3 2
12 4 2 4 2
13 4 4 4 4
14 1 3 5 3
15 1 2 1 2
16 1 2 1 2
17 5 2 5 2
18 5 2 5 2
19 5 2 4 2
20 5 4 5 4
21 5 2 5 5
22 5 3 5 3
23 3 4 3 4
24 4 2 4 2
25 5 3 5 3
26 5 4 5 4
27 4 5 4 5
28 4 2 4 2
29 3 5 2 4
30 5 5 5 5
31 5 5 3 2
32 5 3 5 3
33 5 2 5 2

Chapter 5. Soft Issues Identification and Coping Page | 78

 Individual Soft Issues
S.NO. Natural Legacy expert‟s: Fear of Legacy knowledge resides in
inertia „Indispensability Syndrome‟ Losing Jobs minds rather than being digital
34 5 1 3 1
35 5 4 5 1
36 5 1 4 1
37 5 1 5 1
38 5 1 5 1
39 5 1 2 1
40 5 1 3 2
41 5 1 5 1
42 5 1 4 1
43 4 1 4 1
44 5 5 5 3
45 5 2 2 2
46 3 3 3 3
47 5 5 5 5
48 5 4 5 2
49 4 4 4 4
50 3 5 3 5
51 5 2 5 2
52 1 2 3 2
53 2 1 2 1
54 5 2 5 2
55 2 2 2 2
56 5 1 5 1
57 5 2 4 2
58 2 2 2 2
59 3 1 3 1
60 5 1 4 1
61 5 2 5 2
62 2 3 2 3
63 3 1 4 1
64 2 3 2 2
65 4 1 4 1
66 5 1 5 1
67 3 3 3 3
68 3 2 2 2

Chapter 5. Soft Issues Identification and Coping Page | 79

 Individual Soft Issues
S.NO. Natural Legacy expert‟s: Fear of Legacy knowledge resides in
inertia „Indispensability Syndrome‟ Losing Jobs minds rather than being digital
69 3 2 3 2
70 3 2 3 2
71 5 2 4 2
72 5 2 5 2
73 5 1 4 4
74 5 3 5 3
75 2 2 2 2
76 3 2 3 2
77 5 3 3 3
78 3 1 3 1
79 3 1 3 1
80 5 1 5 1
81 2 1 3 1
82 3 1 3 2
83 2 1 2 1
84 5 2 4 2
85 5 2 5 2
86 5 2 3 2
87 2 2 2 2
88 3 2 3 2
89 3 2 3 1
90 5 2 3 2
91 4 2 4 2
92 5 2 5 2
93 3 2 3 2
94 5 2 2 2
95 4 2 4 3
96 5 2 4 2
97 5 2 5 2
98 2 2 2 2
99 1 2 1 2
100 5 2 2 2
101 5 2 1 2
102 5 2 5 2
103 5 2 4 2

Chapter 5. Soft Issues Identification and Coping Page | 80

 Individual Soft Issues
S.NO. Natural Legacy expert‟s: Fear of Legacy knowledge resides in
inertia „Indispensability Syndrome‟ Losing Jobs minds rather than being digital
104 5 2 5 2
105 5 4 3 3
106 2 3 5 3
107 3 2 3 2
108 2 2 3 2
109 2 3 2 3
110 2 4 5 1

Response of all 55 experts were captured in Table 5.4. To find the interdependency
among these issues, correlation analysis was applied. The correlation analysis applied
here is Pierson‟s correlation (‘R’) between two variables [113], Equation (5.1).
N . ( X ..Y )   X . Y
R …(5.1)
[ N . X 2  ( X ) 2 ][ N . Y 2  ( Y ) 2 ]

Where, N is the number of pairs of data. X and Y are two variables where correlation is
being calculated.
Correlation analysis was done applying computation on the 110 responses recorded in
Table 5.3. Result of such computation is given in Table 5.4.

Table 5.4: Correlation Analysis: Individual Soft Issues

Legacy
Legacy
expert‟s – Fear of
Soft Issues row/column combination Natural knowledge resides
„Indispensa losing
for correlation inertia in minds rather
bility jobs
than being digital
Syndrome‟
Natural inertia 1
Legacy expert‟s – „Indispensability
-0.0007 1
Syndrome‟
Fear of losing jobs 0.6164 0.1136 1
Legacy knowledge resides in minds
0.0303 0.7365 0.1174 1
rather than being digital

Looking the rows and columns of correlation results it is evident that there are strong
dependencies between:
a) Coefficient = 0.6164, for „Natural Inertia‟ and „Fear of Losing Jobs‟; and

Chapter 5. Soft Issues Identification and Coping Page | 81

 b) „Legacy knowledge resides in minds rather than being digital‟ and „Legacy
expert‟s – Indispensability Syndrome‟, correlation coefficient computed 0.7365.

5.3.2 Issues and Evaluating Questions: Organizational

Response to the questionnaire related to organizational soft issues is collated in Table 5.5.
Question details are enlisted below –

Organization structure program governance:

a- Do you believe specific organization structure needed for legacy transformation?

b- Was the current ICT organization structure suitable to run a transformation program?

Weak business case:

a- Do you believe specific organization structure needed for legacy transformation?

b- Was the current ICT organization structure suitable to run a transformation program?

Not setting right expectations of legacy transformation results:

a- You were made aware by program structure about the outcomes before?

b- You were correctly told what you see today after transformation?

Not freezing evolution in legacy and insisting legacy function:

a- You received continuously change requests on legacy, while transformation program

was in execution?

b- You were requested to customize the packaged solution by adding many functions of
legacy?

Not addressing business change management:

a- Business users were adequately sensitized about new solution?

b- Business was taking ownership in transformation program for decisions?

Chapter 5. Soft Issues Identification and Coping Page | 82

 Table 5.5: Responses - Questionnaire (Organizational Soft Issues)
Organizational Soft Issues
Not Not freezing Not setting right
Organization
addressing evolution in legacy expectations of Weak
S. structure
business systems and insisting legacy business
NO. program
change legacy function in transformation case
governance
management new solution scope results
1 4 4 5 3 2
2 4 1 1 4 4
3 4 5 5 4 4
4 4 1 1 4 4
5 4 4 4 4 4
6 3 2 2 2 3
7 3 3 3 3 4
8 3 1 1 3 3
9 2 3 3 2 2
10 2 5 5 2 2
11 2 3 3 2 2
12 2 3 3 2 2
13 3 3 3 3 3
14 3 3 3 3 3
15 2 1 1 4 2
16 1 4 4 1 1
17 5 2 2 5 5
18 3 3 3 3 3
19 3 1 1 3 3
20 3 3 3 3 3
21 3 5 5 3 2
22 4 3 3 4 4
23 5 3 3 2 3
24 4 4 4 4 4
25 3 1 1 3 3
26 4 3 3 4 4
27 2 5 5 2 2
28 1 3 3 1 1
29 2 1 3 1 4
30 3 3 3 3 3
31 4 3 3 4 4

Chapter 5. Soft Issues Identification and Coping Page | 83

 Organizational Soft Issues
Not Not freezing Not setting right
Organization
addressing evolution in legacy expectations of Weak
S. structure
business systems and insisting legacy business
NO. program
change legacy function in transformation case
governance
management new solution scope results
32 5 2 2 5 5
33 3 2 2 3 3
34 2 5 5 3 2
35 5 1 1 5 3
36 2 5 5 2 2
37 3 1 1 3 3
38 5 4 4 5 5
39 5 2 2 2 5
40 3 3 3 3 3
41 2 2 2 2 2
42 2 3 3 2 2
43 2 1 1 1 2
44 3 3 3 3 3
45 3 5 5 3 3
46 3 3 3 3 3
47 3 3 3 3 3
48 4 3 3 4 4
49 4 3 3 4 4
50 4 2 2 4 4
51 5 3 3 5 5
52 5 2 2 2 3
53 5 1 1 5 3
54 2 3 3 2 3
55 2 5 5 2 4
56 2 4 3 5 2
57 2 3 3 2 2
58 3 3 3 3 3
59 3 3 3 3 4
60 3 2 2 3 3
61 4 3 3 2 4
62 4 3 3 4 4
63 3 5 2 3 5

Chapter 5. Soft Issues Identification and Coping Page | 84

 Organizational Soft Issues
Not Not freezing Not setting right
Organization
addressing evolution in legacy expectations of Weak
S. structure
business systems and insisting legacy business
NO. program
change legacy function in transformation case
governance
management new solution scope results
64 2 1 1 2 2
65 3 3 3 1 3
66 3 5 5 3 3
67 4 3 3 4 2
68 4 3 3 3 4
69 3 3 3 3 3
70 3 3 3 3 3
71 4 2 3 4 1
72 4 5 5 4 4
73 5 2 1 5 5
74 5 5 5 5 3
75 2 1 1 2 2
76 2 4 4 2 2
77 1 2 2 1 1
78 2 1 3 2 2
79 3 1 1 3 4
80 5 3 3 5 5
81 2 5 5 2 3
82 3 3 3 3 3
83 3 3 3 4 2
84 4 2 3 4 4
85 5 3 3 5 5
86 2 3 2 2 2
87 2 5 5 2 2
88 3 1 1 3 3
89 3 5 5 3 3
90 2 1 1 2 2
91 4 4 4 4 4
92 2 4 2 2 2
93 3 3 3 3 3
94 2 1 1 2 2
95 2 5 3 2 2

Chapter 5. Soft Issues Identification and Coping Page | 85

 Organizational Soft Issues
Not Not freezing Not setting right
Organization
addressing evolution in legacy expectations of Weak
S. structure
business systems and insisting legacy business
NO. program
change legacy function in transformation case
governance
management new solution scope results
96 2 5 5 2 2
97 3 3 3 3 1
98 3 3 3 3 3
99 1 3 3 1 2
100 3 3 3 3 2
101 2 3 4 2 3
102 3 5 5 3 3
103 2 5 5 2 4
104 2 1 1 2 2
105 2 5 5 3 2
106 2 1 1 2 2
107 2 4 4 2 3
108 3 2 2 3 2
109 4 3 3 4 4
110 3 3 3 3 3

Similar correlation analysis is performed for organizational soft issues:

Table 5.6: Correlation Analysis (Organizational Soft Issues)

Not
Not freezing setting
Not
evolution in right
Organizatio addressing Weak
Soft Issues row/column legacy systems expectati
n structure business busine
and insisting ons of
combination for correlation program change ss
legacy function legacy
governance manageme case
in new solution transform
nt
scope ation
results
Organization structure program
1
governance
Not addressing business change
-0.0997 1
management
Not freezing evolution in legacy
systems and insisting legacy -0.0947 0.9136 1
function in new solution scope
Not setting right expectations of
0.77747 0.0149 -0.0500 1
legacy transformation results
Weak business case 0.7109 -0.0211 -0.0361 0.5694 1

Chapter 5. Soft Issues Identification and Coping Page | 86

This correlation analysis in Table 5.6 clearly defines following interdependencies among
organizational attributes based on very high correlation coefficient value:

a) „Organization structure program governance‟ and „Not setting right expectations

of legacy transformation results‟; and
b) „Weak business case‟ and „Organisation structure program gouvernance‟.
c) „Not addressing business change management‟ and „Not freezing evolution in
legacy systems‟.

5.4 Coping with Soft Issues

Based on the post-mortem analysis and correlation analysis, following are the empirical
ways to cope with the softer challenges faced during legacy transformation programs.

5.4.1 Natural Inertia:

It is human nature to resist change, especially when people are comfortable and more
importantly habitual of using existing tools and procedures/practices. Ironically, in spite
of people being critical to a legacy technology, the replacement of old application by new
application is never welcomed by the people on ground [114].

This is true for ICT resources, who manage and maintain the legacy as they are
comfortable knowing all in-and-out of applications. Same is also true for business users
who are used to with the legacy software [114].

Coping with Natural Inertia:

Individuals resist change when they feel not involved and are not part of the change. Due
to lack of involvement many of them go into DON‟T CARE approach which is
detrimental to the transformation program. With increased level of involvement, the
sense of ownership increases and breaks the inertia with internal dynamism. Engagement
of key legacy experts and specific role assignment to them within the transformation
program ensures their involvement and commitment. Giving due value to them in blue
printing and training to new target technology helps breaking inertia.

5.4.2 Fear of Being Outdated and Losing Jobs:

People running legacy software have sometimes spent a prime of their work life to use
and grow the legacy system and are quite resistant to migrate to new solutions fearing

Chapter 5. Soft Issues Identification and Coping Page | 87

their jobs may become redundant either due to lack of knowledge and fluency they have
on the new technology or sometimes an assessment that the new solution is intended to
reduce the existing workforce and optimize operational costs.

Coping with Fear of Being Outdated and Losing Jobs: Following are the ways to cope
with this factor:

Up-skilling: Appropriate up-skilling and „change management‟ of such resources in

the new technology/solution context should be well planned during the transformation
program. Adequate time and cost should be assigned and budgeted to such up-skilling
initiatives. This helps to reduce the fear and negativity. Enhanced skills with rich
experience is definitely a value add which is good for employee and company both.
The subject of up-skilling can be target technology /package or the methodologies for
reconstructing the design and reverse engineering tools.

Alternate Job Opportunities and Increased Engagement: In case of workforce

reduction linked to the transformation program, exploring alternate job options for
employees that are foreseen to be released with the new solution deployment could
win their confidence and commitment. Giving important roles to some key end-users
in the transformation program helps ensure their involvement. This builds their
motivation and commitment which often becomes a key factor of success of the
transformation. For example, HR forces a rule, not to open any job requests from
market until the available profiles getting freed from outgoing legacy are absorbed or
proven unsuitable completely.

Fitment in New Context: Finding and committing job profile fitment for specific
experts in the new context ensures their support upfront. It is much more relevant for
the applications which are more with business bend. Change in job profile should be
well communicated as ultimately a good mix of previous experience and change in
profile returns most of the time good energy and motivation in employees. It
generates the new synergy contributing to the success of transformation.

Severance Package: As a last option, there may be certain unavoidable

circumstances when people working on the legacy can‟t be adjusted and organization
wants to reduce the size with more automation and with newer technology. Then

Chapter 5. Soft Issues Identification and Coping Page | 88

 considering the long term benefit for the organization handsome severance package
can be declared and let the people opt it voluntarily. This should be the last option if
all other options mentioned before does not suit. This helps to stop the negativity
spreading in the organization.

5.4.3 ‘Indispensability Syndrome’:

Legacy experts tend to feel as an indispensable lot having worked upon for years on the
legacy system and also with an ever increasing scarcity of the legacy workforce. Forced
by employee mobility to newer avenues, legacy experts are usually carried away by
indispensability syndrome. For example, a couple of employees working since more than
25 years in billing applications (written in COBOL) at ST-Microelectronic, ICT
department, were so crucial for the company that they were almost irreplaceable. Only
they could solve the problems faced in production. Till the transformations were initiated
such resources were feeling themselves most important up to the level of arrogance [115].
However, after the transformation those resources became almost redundant, ultimately
demotivated, and non-productive for the organization.

Coping with ‘Indispensability Syndrome’: Some recommendations to address such

cases are as below:

 Backup Planning: Associating additional resources with such profiles in order to

create backup options and reduce dependency. This could still be a challenge for the
associated resources but positioning smart resources that have strong technological
and functional background and ability to ramp-up quickly in the legacy solution could
act as a backup plan reducing the dependence on such resources.
 Engagement: Assignment of such resources upfront in key roles in the
transformation could help allay some fears of such resources who are sometimes
critical to the success of the transformation. An appropriate job assurance to such
resources in the form of an important fitment in the new context could be a motivator
to ensure alignment of such human resources. This will ensure commitment of legacy
expert towards the program otherwise he would fear that after new transformed
solution, he will no longer remain in control of things.

Chapter 5. Soft Issues Identification and Coping Page | 89

 Engage Technical Consultant of Legacy Domain: Companies face scarcity of
resources working in legacy technology and most of the times people are not
interested in growing their carrier in such old technologies, so the alternate option
could be to look for partners / service providers who can supply resources on
contract, who can help in various reverse engineering steps and also can reduce the
indispensability of internal experts.

5.4.4 Legacy Knowledge Resides in Minds Rather than Being Digital:

Most of the legacy systems are running on the basis of individual expertise and lack
proper documentation on implemented solutions. With multiple change requests and bug
fixes done over the years and having crossed many hands, documentation, if at all it
exists, is generally equally obsolete and does not correspond to the current state of the
solution [115].

Although several practices like reverse engineering of legacy systems are generally used,
it still needs commitment and time of IT legacy experts and key business users running
day to day operations on the legacy. Engaging existing legacy experts and end users
becomes key in such circumstances and managing their motivation is equally important.
Key Legacy experts and end users need to be relieved from their operational work and
assigned to the transformation. Although various reverse engineering practices and
automation tools could help to extract partial specifications from the legacy code itself,
manual efforts are still heavily needed to reconstruct and complete the „as-is‟ state and
specifications. Together with Legacy experts and end users, transformation teams need to
resurrect and complete the „as-is‟ state from available content (like help documents,
change request tickets, release documentation, incident tickets etc.) complementing the
content extracted by tools.

Coping with legacy documentation: Some recommendations to address the

documentation issue are mentioned below:

 Train the legacy experts with reverse engineering tools: This will help in not
only generating the base of the documentation work by listing the
services/function/classes or components but also to increase the motivation of
legacy experts.

Chapter 5. Soft Issues Identification and Coping Page | 90

  Reconstruction of design and architecture with human intervention: A
process to extract original architecture from a legacy system was developed in
[106]. The methodology was a perceptive design recovery process which tells
how to utilize various sources of domain knowledge to obtain relevant
information about the application and get into the minds of the earlier developers
with the aim of reconstructing the design and architecture. The re-constructed
architecture is further compared with the original architecture to obtain the level
of conformance.
 Use ‘RIGI’ system for legacy re-documentation: Paper [105] claims that views
that are compatible with the mental models used by the then software engineers.
Rigi system helps to generate views on the logical software structure previously
held only in their minds. Also the highlighted critical areas of software structure,
that needed more attention, having high dependencies.

5.4.5 Weak Business Case:

The business case identifies concrete benefits (revenues or savings) that the organization
is intending with the transformation. Return on Investment (ROI) should be forecasted
and viability of the cost and effort analyzed. If business case itself is weak, there is no
hope of success.

Business Case Analysis:

Before starting the transformation program, some questions need to be answered. What is
the compelling need to execute the transformation? Did it already reach to legacy crisis?
Are the solutions working well and not causing the huge maintenance cost or not
suffering with regression errors with every change implementation? Assessment must be
performed to see if business case is strong enough to start transformation program [46],
[117], [119].

The presence of a desire to achieve the results, willingness to accept the impact of doing
the work, and the resolve to follow through and complete the endeavor are the ingredients
to make the transformation successful. This is evaluated through and assessment matrix,
Table 5.7. Active discussions and brainstorming sessions are required to fill this
assessment matrix. A well determined organization is better able to execute the

Chapter 5. Soft Issues Identification and Coping Page | 91

transformation with clear indication of the intent to accept the impacts. Key resources
(e.g., financial, human, infrastructure etc.) are allocated for the endeavor; and top
executives project the clear message that the organization will follow through a message
that identifies the effort as well as the benefits. Legacy transformation readiness
assessment sheet assesses the transformation program on three parameters. These
readiness factors are illustrated in Table 5.7 as a sample sheet.

Readiness factors significant for the transformation are determined via brainstorming
sessions with experts of different domains. Then these factors are evaluated on three
dimensions, urgency, readiness status and degree of difficulty to fix an issue. Combining
these three dimensions degree of favor is being defined as follows-

1- „Urgency‟ of a factor means that action is needed before a transformation

initiative can begin, it may have values (low=1, medium=2, high=3). In case some
readiness factor is to be assured before start of transformation, it is set with
value=3.

2- „Readiness Status‟ is assessment of a factor stating how much the organization is

ready to execute the program. Assessment values could be (low=1: i.e. needs
substantial work before proceeding, fair=2: i.e. needs some work before
proceeding, acceptable=3: i.e. some readiness issues exist and there exists no
showstopper, good=4: i.e. relatively minor issues exist, or high=5: i.e.no readiness
issues).

3- „Degree of Difficulty to Fix‟ is and assessment of effort and resources required if

any issues are identified. This factor can be rated as (no action=1: NO action
needed, easy=2, moderate=3 or difficult =4).

It can be intuitively argued (also have general consent of group of 55 experts) that the
degree of urgency directly and positively affects the business return value of
transformation program, which may be represented on some scale calling it degree of
favor (Df). Further the readiness status also affects it the same way. However, the degree
of difficulty to fix affects it adversely, that is if difficulty is more then it will attract less
favor.

Chapter 5. Soft Issues Identification and Coping Page | 92

The degree of favor, therefore, may be measured on a scale that can be calculated by the
Equation (5.2).

Let X be degree of urgency, Y be the readiness status, and Z be the degree of difficulty –

X .Y
Then, Degree of favor Df = …(5.2)
15.Z

Where division by 15 is done to map the maximum degree to 1 and keeping all other
values non-negative.

It is a bit subjective which may vary with specificities and can be fixed by management
and architects. Df is a good representation of assessment of legacy transformation
readiness. This assessment gives a systematic way of evaluation of the organization‟s
confidence on ability to run the transformation programs. This exercise should also be
done with business representatives inside the assessment team.

Table 5.7: A Sample Legacy Transformation Readiness Assessment Sheet

Transformation Readiness Assessment Summary
Degree in
Degree of
Readiness favor as
S. No. Readiness factor Urgency(X) difficulty to
status(Y) Equation
fix(Z)
(5.2)
1 Transformation vision
Desire, Willingness,
2
Resolve
3 Need of transformation
4 Business case
5 Partner integrations
6 Other attributes

5.4.6 Organization Structure and Program Governance:

Most organizations have a pretty strict and project-based organization which is adding
considerably to their latency and inability to adapt. It is clear that in such an environment
there will be a lot of resistance towards new developments.

Organizing Program Structure for Legacy:

The team organization for legacy transformation should have a central authority to
control major revitalization efforts in transformation execution to enforce architectural

Chapter 5. Soft Issues Identification and Coping Page | 93

consistency and to provide a deployment policy. Having business stakeholders in
program organization is also a must for success [49][51].

If the program comprises multiple projects, they too must have a business project
manager and an IT project manager. Project managers in IT are the persons who maintain
the project plans at their track levels who share the same to consolidate to the global plan
at program management level. The same is typically represented in Fig. 5.2.

Program
management
office

Figure 5.2: Program Board Structure with IT and Business Accountable

5.4.7 Not Freezing Evolution in Legacy Systems:

Sometimes it has been seen that business users insist to keep asking change requests to
legacy system even when transformation program is ongoing. All such changes must be
discarded.

 The legacy code should be frozen and only minimal changes needed for business
continuity or production bugs would be allowed in the legacy software which should
be otherwise declared frozen.

 If migrating to a new package, educate and insist business users to go for standard
solutions offered by the new package and not bringing fancy features of old
applications which may be costly in maintenance later.

Chapter 5. Soft Issues Identification and Coping Page | 94

 Put in place the strict exception approval process to carry out a new version on legacy
software.

5.4.8 Not Addressing Business Change Management:

Business change management is integral part of the transformation program. Ultimately

they are the real sponsors of the legacy transformation. Even if the top managers in
business are aware yet if the business change management is not cascaded well, this may
cause a setback to the program. Proper cascade of business change management is
required in each phase of transformation program starting from definition till the
deployment of new solution.

Coping with Business Change Management: Various considerations needed are as

below-

 Awareness and trainings on new solution should be arranged for all stakeholders.

 Engaging Business: The acceptability of the new solution cannot be granted unless
end users who will switchover from operating the legacy solution to the new one are
adequately engaged, informed, and trained at relevant stages in the transformation
program. Apart from keeping those in the program-board and project management
organization, business organization must be equally made aware of features,
possibilities, way to use, and high level trainings on new solution.

 End user engagement: Selected end user representatives from various sites and
local/regional offices must be engaged during the solution selection, architecture and
roadmap definition stages and assigned key roles as part of the business team in the
transformation project. They should have the responsibility to define business
requirements and functional specifications and should be the ones to approve/sign-off
the new solution.

 Change agents and spreading the knowledge in business: Selected end users
should also be groomed to lead the end user trainings and act as change catalysts in
the business organizations. The role of change catalyst is very important as they work
as bridge between IT and business organizations.IT organization neither needs to

Chapter 5. Soft Issues Identification and Coping Page | 95

 bother about the complexities in the business organizations nor to have contacts with
everyone in the business organization.

Change agents cascade the philosophy of transformation, benefits, expectations and

roadmap inside business to set the right expectation out of the transformation
program. Additional end users can be engaged during the software acceptance testing
stages to further expand/increase the awareness of the new solution.

 Regular communication and learning culture: As the program evolves, various

communication channels like newsletters or other published content can be utilized to
ensure periodic and continuous communication to all end users. This helps to keep
people informed and interested in the new solution. As new processes are put into
place, the company will need to institute effective learning and support strategies for
IT practitioners and end-users.

5.4.9 Not Setting Right Expectations of Legacy Transformation Results:

It often happens that various stakeholders make very high expectations out of
transformation results and modernization. There is a need to be careful and realistic while
making commitments and presenting the transformation program [74][77]. On one hand
business users may be dreaming for having full automation, no old pains, being bug-free
software from day one, and magical response time etc. On the other hand, IT
management may be dreaming of excellent customer satisfaction after deploying new
solution [99]. Their expectations may be very high, but they may get disappointed after
the realization of the transformation.

Setting right expectations out of legacy transformation: Following are the key
considerations used to overcome this problem:

Honest communication about expected results: Business community, IT management,

IT support teams, and other stakeholders must be made upfront aware of the clear
outcomes of the transformation program. Marketing stunts and generating false
expectations must be avoided. If the implementer is an external service provider then
internal management must be careful to have it controlled, checked and then uniformly
understood.

Chapter 5. Soft Issues Identification and Coping Page | 96

Prototypes: Graphical User Interface (GUI) and block diagrams shared at intermediate
stages to review and have feedback is necessary. This helps giving very fare idea about
the future application behaviors and helps building the mind maps. It is suggested to
share prototypes with users to give real feel and not only limiting to the power point
presentations.

Setting up the ‘goal models’ with stakeholders: Here a kind of modeling is done to
represent the stakeholder goals in the form of graphical representation along with their
inter-dependencies. Goals are decomposed into sub goals and their synthesis. In [99], soft
goals are analyzed as qualitative objectives such as „improve profits‟ or „keep customers
happy‟. Subsequently, goal model goes through refinements. Root goal is represented as
collection of leaf goals. To achieve the system level root goals, work and controls are
applied on the individual leaf goals.

Beta validation with right participants: Key users with real practitioners in business
must be involved in Business IT Alignment (BITA) validation and sign off. Combined
validation cycle with IT analysts and business will help to arrive at a final version faster.
This step should be marked as important milestone and a key achievement as pre go-live.
It is suggested that all the documentation and release notes must be published and shared
by this milestone. Clear tracking and addressing of the questions, bugs highlighted
during BITA, is a key to have smooth go-live. BITA results must be formally recorded
and reviewed. Appropriate time must be spent in BITA. While doing the validation,
regular image of LIVE data must be reflected in beta environment.

Legacy functions with target evolution: Reverse engineered specifications merged with
new adaptations are discussed, agreed, and signed off. Being realistic here and an
authority to awake people from dreams will help. „To–be‟ picture should be made black
and white clear. Suggested to discuss the crazy change requests when they are raised
instead of leaving them in grey zone. ICT should not do any verbal or false commitment.
However, be sensitive to capture and integrate the sincere evolutions to make maximum
out of the transformation programs. Try to address as much the pains of users possible.

Choosing right authorities from each stake holder community: This helps to enforce
the well thought decisions even if it may have certain drawbacks. Here again,

Chapter 5. Soft Issues Identification and Coping Page | 97

management commitments matter to take this transformation seriously on priority and
assign right resources to it. It is well known that democratic approach can‟t work always.
Keeping business and IT organizations in the program board is good but there must be
one authority who can take the decision in case of conflict.

Highlight the legacy functionality getting compromised in new system: Any

functionality which is getting compromised in the new solution must be highlighted and
well communicated in advance to set the right expectations. This will help to anticipate if
any address to this is required. It will not come to users as surprise - when to go live. If
the functionality is nice to have, users can mentally be prepared to live without it but in
case it is a key function then it warrants for the solution.

Forecast stabilization timeframe: Make an assessment for the duration of stabilization

period, share and agree with business and other stakeholders.

Soft issues are often ignored during the legacy transformation. It is experienced that they
are crucial and impact considerably the transformation program. Hence appropriate
handing is mandatory. Ways to cope with them described in this chapter are tried in real
scenarios and found to be working.

Chapter 5. Soft Issues Identification and Coping Page | 98

 6. Results, Discussion and Future Directions

This chapter discusses the data details, result summary, and any deviation of
hypothesis with proven results. The chapter also highlights the scope of contribution of
this research work to the society, research community and software industry. Specially, to
the organizations and people dealing with legacy software.

6.1 Legacy Crisis Operational Attributes

Section 3.2 identifies legacy crisis operational attributes and section 3.3 fixes their
weights used in the model proposed for legacy crisis detection. The present section
provides further discussion on these attributes.
6.1.1 Number of Interrupts to Production (ITPs) in a Quarter
ITPs are unwanted events in production when single application or set of applications
stop functioning and business activities are interrupted in production environment. Such
events are very difficult events in production. Having a website not available for few
minutes may cause huge losses to the organization. ITPs are rare but they are more likely
to take place in case of legacy software. So, it was certainly an attribute of legacy crisis.
Quarterly score is tracked for all applications. Weight factor for this attribute fixed by
this work is 5%, representing the level of uncertainty of production system availability.
6.1.2 Number of Incidents Reported (per month)
This indicator is much closure to operational issues of a system. Users log tickets in
application and their monthly count represents the condition of legacy system. As it is
direct feedback and experience of application to end users. This work has fixed the higher
weightage 15% to this attribute. It is very evident from Fig. 6.1 that legacy application
SO has very high incident monthly rate compared to benchmarked application DRP. Also
legacy application has potential uncertainty of getting high peaks especially after new
releases as in case of SO release in October 2015.
6.1.3 Number of Questions Asked By Users on Application Behaviour (Per Month)
One major drawback of legacy applications is missing documentation or documented
help. It mostly goes with individual heads. Legacy knowledge resides mostly in mind of
people, causing more questions from users.

Page |99
 Ticket Count

Month (YYYY-MM)

Figure 6.1: Incident Arrival Trend (Legacy - SO and Recent – DRP)

Higher the number of questions asked lower the clarity in users. This costs support effort
and disturbs the solution team and support teams. It has also pretty good weightage 10%
set by this work. Fig. 6.2 depicts such a comparison with respect to questions being asked
to the support team by users. SO is getting consistently twice or thrice the questions in
comparison to DRP on an average.

20 19
17 18 17
16 16
Ticket Count

15
11 12
10 10 10 10 10 10
7 6 6 6 7
5 5 DRP
4 4 3 3
1 SO (SALES ORDER)
0

Month (YYYY-mm)

Figure 6.2: Monthly Question Trend (Legacy - SO and Recent – DRP)

6.1.4 Number of Incident Tickets Violating Service Level Objectives (SLO)

SLO is the target time limit under which ICT organizations to solve a particular issue
after reported. Legacy issues take longer to get resolved. They are also good indicator for
legacy crisis. Present work has fixed higher weightage 15% to SLO attribute, in
determination of legacy crisis. Fig. 6.3 shows SLO target line at 90% and it is very
evident that achieving the SLO targets for legacy application are difficult. Even if major
changes in SO are blocked and application is stable, resolving live issues take higher time
to resolve.

Chapter 6. Results, Discussion and Future Directions Page | 100

 120.00%
Target 90%
100.00%
96.43%
85.29%
80.00% 81.13% 78.72%
73.33% 73.26%

60.00% SLO % Resolution SLO Compliance

Target
40.00%

20.00%
Month (YYYY-mm)

0.00%
2016-01 2016-02 2016-03 2016-04 2016-05 2016-06

Figure 6.3: Monthly SLO/SLA Compliance Trend for Application SO

6.1.5 Number of Problem Tickets Created (Per Month)

Legacy applications are more prone to have problems. Specially, just after a new release
installations. Peaks around deployment dates indicate the same. It has been assigned a
weight of 10% in terms of contribution to legacy crisis. Fig. 6.4 shows that in general
legacy applications receive more problem tickets. Non-legacy application DRP had low
number of problems except on couple of months when infrastructure related issues
caused several response time specific problems in March-April 2016 in DRP.

35
30 29
25
Ticket Count

20 20
18
15 14 14
12 DRP
10 9 8 7 8 SO (SALES ORDER)
5 6 6 6 6 5
3 4 4 3
2 2
0

Month (YYYY-MM)

Figure 6.4: Monthly Reported Problems Trend For Legacy and Recent Application.

Chapter 6. Results, Discussion and Future Directions Page | 101

6.1.6 Average Man Days Required To Keep-Lights-On (KLO) support (Per Month)
KLO includes all sort of support activities around an application. Effort in supporting
users to solve issues, answer queries, give trainings. Legacy has higher KLO cost. It is up
to the level when KLO eats lot of resources. Earlier in chapter-3, it has been assigned
highest weightage, 17% in legacy crisis contribution.
6.1.7 Effort vs. CR size
As legacy lacks in documentation, skilled resources and modularity etc. it is difficult to
carry out changes over legacy. It is computed in terms of average man days required to
develop for each function point. It also contributes significantly into legacy crisis. As
determined in chapter-3, weightage of legacy crisis is 10% for this attribute.
6.1.8 Number of Defects in The 1st Month of New Version Deployment
Most number of defects are reported in the first month after live deployment. Although,
non-legacy applications also attribute higher number of defects but, it is much more
relevant for legacy application. Weight for this attribute in legacy crisis is being assigned
to 8%.
6.1.9 Regression defects reported in the 1st month after new version
Legacy is prone to regression errors. Most number of defects are reported in the first
month after live deployment of a release. Recent applications (non-legacy) also have
higher number of reported defects, closure to the release date, but it is much more
relevant for legacy application. This is the reason why it is suggested in [115] to keep
evolving the application suit and business with their ecosystem. This attribute is assigned
a 5% pie in legacy crisis operationally.
6.1.10 Attrition Rate (per annum) of Engineers Working in Legacy Area
This is a non-technical reason and attribute. Keeping a resource engaged in legacy is a
big challenge. Resources get bored and switch their job. This count is also a minor factor
(under TOP-10). Weight fixed for this attribute in section 3.3 is 5%.
These attributes and their weights are used to detect the legacy crisis. LCSS score is
computed at two stages. 1st stage is completely based on above 10 attributes and their
weights.

Chapter 6. Results, Discussion and Future Directions Page | 102

6.2 Validation of Stage-I : Legacy Crisis Detection via LCSS Model
For validation purpose the model is applied on six different organizationally known,
poor-state legacy applications. One of them - the Sales Order (SO) application has been
chosen as representative poor legacy application. SO application was developed in VB
front end-Tuxedo middleware-Oracle back end. It was developed around 25 years ago
and is used world-wide for placing company orders manually. Other one is Order
Scheduling application, which is also almost equally old as SO.
The model is also applied on old application health data of four other applications which
were already transformed. These four applications were, VLOG (for logistics), BP
(customer referential application named Business Partner), BM (backlog management)
and SGA (pricing and quantity contract application). It has been proven through
validation that LCSS conform to the state of legacy. LCSS score computed for already
transformed applications were found to be poorer and above the derived threshold value.
Below sections show these computations for each application chosen to validate the
model. LCSS are computed using Equation (4.1). For the normalization factors Equation
(4.2), Equation (4.3) and Equation (4.4) are used.
Section 4.4 of the thesis established empirically the threshold value specific to ST-
Microelectronics applications. It is fixed through 80 percentile method applied on 204
applications LCSS. By this method the threshold value is derived 300. It is observed that
any score more than 300 is high enough to go for stage-II.
Computation about normalization factor (NF) and LCSS for above said six applications
are provided in Table 6.1 to Table 6.7 and summary result is presented in Table 6.8.
Method proposed in section 4.3 is used for these LCSS computations. Tables 6.2 – 6.7
provide the computations SO application, VLOG application, BP application, BM
application, SGA application and of Order Scheduling applications (Automatic
Scheduling (AS), Manual Scheduling (MS) and SWAP) respectively. 3 set of
applications are used in ST-Microelectronics for order scheduling and their data is
analysed together.
Application authentication database SQL used for counting active application users:
Below query is used to fetch user‟s profiling data from ORGSEC application, which
keeps record of all configured users with their authentication.

Chapter 6. Results, Discussion and Future Directions Page | 103

 Select count(distinct sufo.sw_user__id)
FROM user_function uf,
sw_user_x_func_x_org sufo,
sw_user su
where uf.SW_APPLICATION__ACRONYM=’Application Name’
and sufo.function__code=uf.code
and su.id = sufo.sw_user__id
and su.activity_status__code='30'; -- Status:30 (ACTIVE)

In this query, the term „application initials‟ is replaced by initials of respective

applications viz. „SO‟, „VL‟, „BM, „SG‟ and „SC‟ respectively. Same is used to calculate
number of users of benchmarked applications as well. While for „BP‟ application the user
count is derived from SAP-CRM using SU01 transaction. User count for different
applications and NF computations are mentioned in Table 6.1. Sizes of applications are
based on standard function points and taken from application teams. This user count is
used to calculate normalization factor (NF). NF calculations are done applying Equation
(4.2), Equation (4.3) and Equation (4.4).

Table 6.1: User Counts and Normalization Factors for Applications

Applications No. of Users Size (FP) Normalization Factor

(NF)
BAP1 DRP 1850 240 NA
BAP2 S2S PO Change 1730 400 NA
BAP3 eID 2008 320 NA
Legacy SO 2264 368 1.2
Legacy Order Scheduling 2180 524 1.4
Transformed Legacy VLOG 4368 558 2.0
Transformed Legacy BM 1466 225 0.75
Transformed Legacy SGA 3121 150 1.1
Transformed Legacy BP 2486 245 1.05

Chapter 6. Results, Discussion and Future Directions Page | 104

 Table 6.2: LCSS Computation for Sales Order (SO)

Weight LEGACY BAP1 BAP2 BAP3 BAP Legacy Weighted

Source
Attribute Factor % score Score Score Score Avg. Factor Factor
(W) (L) (M) (N) (O) (Yi) (Zi=L/Y) (W*Z/NF)

Operation & Support

Number of Interrupts to Production (ITPs) in a quarter 5 1 1 0 0 0.3 3.3 13.8
dashboard
Operation & Support
Number of incidents reported (per month) 15 48 7 4 6 5.7 8.4 105
dashboard
Number of questions asked by users on application Operation & Support
10 9 3 1 2 2 4.5 37.5
behavior (per month) dashboard
Number of incident ticket violated Service Level Operation & Support
15 8 4 2 2 2.7 3 37.5
Agreement(SLA) dashboard
Operation & Support
Number of problem tickets created (per month) 10 9 2 0.25 1 1.1 8.2 68.3
dashboard
Number of average man days required in Keep Lights On Yearly BITA
17 8 3 2 2 2.3 3.5 49.6
(KLO) support (per month) dashboard
Effort vs. CR size (man days/function points)
Release DB 10 4.6 1.2 2.3 1.7 1.7 2.7 22.5
For last release
Number of defects in the 1st month of new version
Release DB 8 5 1 1 1 1 5 33.3
deployment
Regression Defects reported in the 1st month after new
Release DB 5 2 0 1 2 1 2 8.3
version

Attrition rate(per annum) of engineers working in legacy

area
ICT Top page 5 4 1 1 1 1 4 16.7

NF= Normalization factor to FP size and User

Sum (Weights) 100 LCSS 392.5
base (1.2)

Chapter 6. Results, Discussion and Future Directions Page |105

 Table 6.3: LCSS Computation for VLOG
Weight LEGACY BAP1 BAP2 BAP3 Legacy Weighted
Source BAP Avg.
Attribute Factor % score Score Score Score Factor Factor
(W) (L) (M) (N) (O) (Yi) (Zi=L/Y) (W*Z/NF)
Operation & Support
Number of Interrupts to Production (ITPs) in a quarter 5 2 1 0 0 0.3 6.7 16.8
dashboard
Operation & Support
Number of incidents reported (per month) 15 91 7 4 6 5.7 16 120
dashboard
Number of questions asked by users on application Operation & Support
10 21 3 1 2 2 10.5 52.5
behavior (per month) dashboard
Number of incident ticket violated Service Level Operation & Support
15 17 4 2 2 2.7 6.3 47.3
Agreement(SLA) dashboard
Operation & Support
Number of problem tickets created (per month) 10 9 2 0.25 1 1.1 8.2 41
dashboard
Number of average man days required in Keep Lights On Yearly BITA
17 35 3 2 2 2.3 15.2 129.2
(KLO) support (per month) dashboard
Effort vs. CR size (man days/function points)
Release DB 10 3.2 1.2 2.3 1.7 1.7 1.9 9.5
For last release
Number of defects in the 1st month of new version
Release DB 8 7 1 1 1 1 7 28
deployment
Regression Defects reported in the 1st month after new
Release DB 5 4 0 1 2 1 4 10
version
Attrition rate(per annum) of engineers working in legacy
ICT Top page 5 2 1 1 1 1 2 5
area
Sum (Weights) 100 NF (FP size , User base) = 2.0 LCSS 459.3

Chapter 6. Results, Discussion and Future Directions Page | 106

 Table 6.4: LCSS Computation for Business Partner (BP)
Weight LEGACY BAP1 BAP2 BAP3 BAP Legacy Weighted
Source
Attribute Factor % score Score Score Score Avg. Factor Factor
(W) (L) (M) (N) (O) (Yi) (Zi=L/Y) (W*Z/NF)
Operation & Support
Number of Interrupts to Production (ITPs) in a quarter 5 0 1 0 0 0.3 0 0
dashboard
Operation & Support
Number of incidents reported (per month) 15 20 7 4 6 5.7 3.5 50
dashboard
Number of questions asked by users on application Operation & Support
10 4 3 1 2 2 2 19
behavior (per month) dashboard
Number of incident ticket violated Service Level Operation & Support
15 6 4 2 2 2.7 2.2 31.4
Agreement(SLA) dashboard
Operation & Support
Number of problem tickets created (per month) 10 4 2 0.25 1 1.1 3.6 34.3
dashboard
Number of average man days required in Keep Lights On Yearly BITA
17 6 3 2 2 2.3 2.6 42.1
(KLO) support (per month) dashboard
Effort vs. CR size (man days/function points)
Release DB 10 5.9 1.2 2.3 1.7 1.7 3.5 33.3
For last release
Number of defects in the 1st month of new version
Release DB 8 3 1 1 1 1 3 22.9
deployment
Regression Defects reported in the 1st month after new
Release DB 5 3 0 1 2 1 3 14.3
version
Attrition rate(per annum) of engineers working in legacy
ICT Top page 5 1 1 1 1 1 1 4.8
area
Sum (Weights) 100 NF (FP size, User base) =1.05 LCSS 252.1

Chapter 6. Results, Discussion and Future Directions Page | 107

 Table 6.5: LCSS Computation for Backlog Management (BM)
Weight LEGACY BAP1 BAP2 BAP3 Legacy Weighted
Source BAP Avg.
Attribute Factor % score Score Score Score Factor Factor
(W) (L) (M) (N) (O) (Yi) (Zi=L/Y) (W*Z/NF)
Operation & Support
Number of Interrupts to Production (ITPs) in a quarter 5 0 1 0 0 0.3 0 0
dashboard
Operation & Support
Number of incidents reported (per month) 15 34 7 4 6 5.7 6 120
dashboard
Number of questions asked by users on application Operation & Support
10 6 3 1 2 2 3 40
behavior (per month) dashboard
Number of incident ticket violated Service Level Operation & Support
15 6 4 2 2 2.7 2.2 44
Agreement(SLA) dashboard
Operation & Support
Number of problem tickets created (per month) 10 4 2 0.25 1 1.1 3.6 48
dashboard
Number of average man days required in Keep Lights On Yearly BITA
17 6 3 2 2 2.3 2.6 58.9
(KLO) support (per month) dashboard
Effort vs. CR size (man days/function points)
Release DB 10 6.7 1.2 2.3 1.7 1.7 3.9 52
For last release
Number of defects in the 1st month of new version
Release DB 8 8 1 1 1 1 8 85.3
deployment
Regression Defects reported in the 1st month after new
Release DB 5 4 0 1 2 1 4 26.7
version

Attrition rate(per annum) of engineers working in legacy 1

ICT Top page 5 5 1 1 1 5 33.3
area

Sum (Weights) 100 NF (FP, User Base) = 0.75 LCSS 508.2

Chapter 6. Results, Discussion and Future Directions Page | 108

 Table 6.6: LCSS Computation for Sales General Agreement (SGA)
LEGACY BAP1 BAP2 BAP3 BAP Legacy Weighted
Source Weight Factor
Attribute score Score Score Score Avg. Factor Factor
% (W)
(L) (M) (N) (O) (Yi) (Zi=L/Y) (W*Z/NF)
Number of Interrupts to Production (ITPs) in a Operation & Support
5 3 1 0 0 0.3 10 45.5
quarter dashboard
Operation & Support
Number of incidents reported (per month) 15 23 7 4 6 5.7 4 54.5
dashboard
Number of questions asked by users on application Operation & Support
10 5 3 1 2 2 2.5 22.7
behavior (per month) dashboard
Number of incident ticket violated Service Level Operation & Support
15 6 4 2 2 2.7 2.2 30
Agreement(SLA) dashboard
Operation & Support
Number of problem tickets created (per month) 10 4 2 0.25 1 1.1 3.6 32.7
dashboard
Number of average man days required in Keep Lights Yearly BITA
17 7.5 3 2 2 2.3 3.3 51
On (KLO) support (per month) dashboard
Effort vs. CR size (man days/function points)
Release DB 10 6.4 1.2 2.3 1.7 1.7 3.8 34.5
For last release
Number of defects in the 1st month of new version
Release DB 8 12 1 1 1 1 12 87.3
deployment
Regression Defects reported in the 1st month after
Release DB 5 6 0 1 2 1 6 27.3
new version
Attrition rate(per annum) of engineers working in
ICT Top page 5 5 1 1 1 1 5 22.7
legacy area
Sum (Weights) 100 NF (FP, User Base) = 1.1 LCSS 408.2

Chapter 6. Results, Discussion and Future Directions Page | 109

 Table 6.7: LCSS Computation for Order Scheduling (AS, MS, SWAP)

Weight LEGACY BAP1 BAP2 BAP3 BAP Legacy Weighted

Attribute Source Factor % score Score Score Score Avg. Factor Factor
(W) (L) (M) (N) (O) (Yi) (Zi=L/Y) (W*Z/NF)

Number of Interrupts to Production (ITPs) in Operation &

5 0 1 0 0 0.3 0 0
a quarter Support dashboard
Operation &
Number of incidents reported (per month) 15 46 7 4 6 5.7 8.1 86.8
Support dashboard
Number of questions asked by users on Operation &
10 12 3 1 2 2 6 42.9
application behavior (per month) Support dashboard
Number of incident ticket violated Service Operation &
15 12 4 2 2 2.7 4.4 47.1
Level Agreement(SLA) Support dashboard
Number of problem tickets created (per Operation &
10 12 2 0.25 1 1.1 10.9 77.9
month) Support dashboard
Number of average man days required in Yearly BITA
17 9 3 2 2 2.3 3.9 47.4
Keep Lights On (KLO) support (per month) dashboard
Effort vs. CR size (man days/function points)
Release DB 10 8.3 1.2 2.3 1.7 1.7 4.9 35
For last release
Number of defects in the 1st month of new
Release DB 8 10 1 1 1 1 10 57.1
version deployment
Regression Defects reported in the 1st month
Release DB 5 12 0 1 2 1 12 42.9
after new version
Attrition rate(per annum) of engineers
ICT Top page 5 4 1 1 1 1 4 14.3
working in legacy area
Sum (Weights) 100 NF (FP, User Base) = 1.4 LCSS 451.4

Chapter 6. Results, Discussion and Future Directions Page | 110

6.3 LCSS Results Summary and Discussion
LCSS computation for five applications is summarized below in Table 6.8.

Table 6.8: LCSS computation for five applications

Legacy Normalization
S. No. LCSS Remarks
Application Factor (NF)
Applied the developed model and result
1 SO 1.2 392.5 qualified stage-I for legacy
transformation.
Already transformed, model applied on
2 VLOG 2 459.3 old data (2013-14), result qualified
stage-I for transformation.
In case of BP application, Model did not
qualify stage-I for transformation but
actually it was transformed. Decision of
BP transformation was not because of
3 BP 1.05 252.1
legacy crisis but to adopt to a new
futuristic solution Customer Master Data
Management (CMDM ) mandated by
ICT architecture roadmap.
Already transformed, model applied on
4 BM 0.75 508.2 old data (2013-14), result qualified
stage-I for transformation.
Already transformed, model applied on
5 SGA (Price) 1.1 408.2 old data (2011-12), result qualified
stage-I for transformation.

Qualified for transformation in Stage-I

6 Order Scheduling 1.4 451.4
but later in stage-II it was rejected.

Organization threshold for ST-Microelectronics is decided to be 300 (See section 4.4) or

above. This threshold value of 300 is 80 percentile score applied on 204 applications.
When LCSS applied on all 204 applications, 161 applications had score lower than 300
and working group evaluated these applications to be relatively better from application
health perspective. Remaining 43 applications were mostly found in poor state. Finally,
close observation was done for 3 legacy applications namely VLOG, BM and SGA where
transformation is already done but used here to validate the model. Then the model is
applied on 3 other applications SO, BP and Order Scheduling, which were among the
main concerned Legacy Applications. As summarized in Table 6.8, LCSS score for SO

Chapter 6. Results, Discussion and Future Directions Page | 111

was 392.5, VLOG score was 459.3, BP score was 252.1, BM score was 508.2, Order
Scheduling LCSS was 451.4 and SGA score was 408.2. The above computations qualify
SO application for stage-II evaluations. For already transformed applications VLOG, BM
and SGA the LCSS score was found to be much above than threshold value hence it is
proven to be in-line with past gutfeel model. Except for the case of BP application was
migrated but the score on old data was less than threshold value. However, migration of
customer referential application Business Partner (BP) was not because of legacy crisis
but it was because of the fact that ICT architecture roadmap mandated to go for a new
customer referential package chosen for better integration. So, it can be deduced to the
conclusion that LCSS computation model works fairly good to predict the legacy crisis
point for stage-I. Order Scheduling application was qualified for stage-II evaluation but
in next section it is shown that it did not qualify for transformation after applying stage-II
of the model.
While applying this model, benchmarked applications need to be chosen very carefully.
As they are used to derive normalization factors, any errors committed in choosing the
BAP applications may lead to give erroneous results.

6.4 Validation of Stage-II : Architectural Analysis

Stage-II of legacy crisis detection is more on the technology front. It is on the aspects of
current architecture of legacy. In this section architectural evaluation is done with respect
to Service Oriented Architecture (SOA) and CLOUD principles. Depending on the
degree of deviation from these architecture principles point of legacy crisis is confirmed.
Notion of SAD [111] represents the state of architecture of the legacy with respect to
SOA and CLOUD. Degree of SADness is computed using Equation (4.5).
For stage-II legacy crisis also the same legacy applications are used which were used for
stage -I. Weights on architectural attributes of legacy are derived in section 3.5.

Chapter 6. Results, Discussion and Future Directions Page | 112

Table 6.9 - 6.20 describe the SAD computation with respect to SOA and CLOUD architectures for these application.
Table 6.9: Answer Architecture Questionnaire for Legacy – SO: SOA

SERVICE AUTONOMY
INTEROPERABILITY
COARSE GRAINED
analysis Questions

LOOSE COUPLING

REPLACEABILITY
AS-IS architecture

ENCAPSULATION
SEARCHABLITY
Q. Sr. No.

ABSTRACTION

COMPOSITION
COMPLIANCE
Answer: Y/N?

LAW OF
(W=20)

(W=20)

(W=20)

(W=10)
(W=5)

(W=5)

(W=5)

(W=5)

(W=5)

(W=5)
1 Packaged solution? 0 0.8 0.5 0.5 0.2 0.2 0 0 0.5 0.1 0.1
2 Home grown applications? 1 0.3 0.1 0.1 0.1 0.1 0 0 0.1 0.1 0.1
3 Development is done using framework? 0 0.5 0.2 0.2 0.2 0.2 0.2 0.2 0.5 0.4 0.1
4 Batch Programs in 3 GL? 1 0.3 0.2 0.1 0.1 0 0.1 0.1 0.2 0.1 0.1
3-Tier architecture to keep
5 1 0.6 0.3 0.3 0.3 0.2 0.2 0.2 0.2 0.4 0.3
presentation and biz layer separated?
6 Monolithic structure? 1 0.1 0.1 0.1 0.1 0.1 0 0 0.1 0.1 0.1
Ecosystem is heterogeneous (e.g. C, JAVA, SAP, DB scripts
7 0 0.4 0.4 0.3 0.2 0.5 0.6 0.6 0.2 0.2 0.2
etc.)?
8 Nature of services is database centric? 1 0.5 0.5 0.4 0.3 0.2 0.2 0.2 0.2 0.4 0.3

9 Nature of services is functionality/logic centric? 0 0.7 0.5 0.3 0.3 0.3 0.2 0.2 0.2 0.2 0.4
Age of LEGACY in range of
10 1 0.1 0.1 0.1 0.1 0.1 0 0 0.1 0.1 0.1
20 years?
Age of LEGACY in range of
11 0 0.3 0.2 0.1 0.1 0 0.1 0.1 0.2 0.1 0.1
10 years not older?
Age of LEGACY in range of
12 0 0.6 0.4 0.3 0.3 0.3 0.4 0.6 0.5 0.5 0.6
5 years not older?
13 Services used by SELF/mother application only? 1 0.3 0.3 0.4 0.6 0.5 0.5 0.6 0.4 0.4 0.4

14 Services published and used by self and others? 0 0.8 0.7 0.7 0.3 0.4 0.4 0.6 0.5 0.5 0.6

Chapter 6. Results, Discussion and Future Directions Page | 113

 SERVICE AUTONOMY
INTEROPERABILITY
COARSE GRAINED
analysis Questions

LOOSE COUPLING

REPLACEABILITY
AS-IS architecture

ENCAPSULATION
SEARCHABLITY
Q. Sr. No.

ABSTRACTION

COMPOSITION
COMPLIANCE
Answer: Y/N?

LAW OF
(W=20)

(W=20)

(W=20)

(W=10)
(W=5)

(W=5)

(W=5)

(W=5)

(W=5)

(W=5)
Application/service design is in the form of functions for one
15 0 0.8 0.6 0.5 0.4 0.5 0.5 0.6 0.4 0.4 0.4
logical set of actions?
16 Services / functions follow international level standards? 0 1 1 1 0.8 0.8 0.6 0.8 0.8 0.8 0.8

Services do not follow international standards but follow at

17 1 0.8 0.6 0.5 0.7 0.6 0.6 0.6 0.7 0.4 0.6
organization level standards?

18 Functions and Services: signatures clearly defined? 1 0.6 0.5 0.5 0.7 0.6 0.9 0.9 0.5 0.4 0.6

19 Functions do not use global or static variables? 0 0.5 0.5 0.5 0.4 0.6 0.6 0.9 0.5 0.4 0.6
Functions/Services signatures are published at common
20 0 0.6 0.5 0.5 0.7 0.6 0.9 0.9 0.5 0.4 0.6
place?
21 User Requirements Document (URD) exists at product level? 0 0.3 0.4 0.4 0.1 0 0.1 0.1 0.2 0.1 0.1

22 User Requirements Document (FGD) exists at product level? 0 0.6 0.5 0.5 0.2 0.2 0.9 0.3 0.3 0.2 0.3

23 User Requirements Document (DD) exists at product level? 0 0.3 0.4 0.4 0.1 0.2 0.1 0.1 0.2 0.1 0.1

24 User Requirements Document (TGD) exists at product level? 1 0.3 0.4 0.4 0.1 0.2 0.1 0.1 0.2 0.1 0.1
Service names represent the purpose correctly (brief
25 0 0.3 0.4 0.4 0.1 0.1 0.1 0.1 0.2 0.1 0.1
description compliments)?

Chapter 6. Results, Discussion and Future Directions Page | 114

 Table 6.10: SAD Computation for SO: SOA

Weight Score Observed Analysis

SOA Attributes (Wi -Oi) Wi(Wi-Oi) Wi*Wi
(Wi) Score (Oi)
Abstraction 20 3.9 16.1 322 400
Coarse Grained Nature Of Services 20 3.1 16.9 338 400
Loose Coupling 20 2.9 17.1 342 400
Compliance 5 3.1 1.9 9.5 25
Interoperability 5 2.6 2.4 12 25
Search-ability 5 2.6 2.4 12 25
Replace-ability 5 2.7 2.3 11.5 25
Encapsulation 10 2.7 7.3 73 100
Law Of Composition 5 2.5 2.5 12.5 25
Service Autonomy 5 2.7 2.3 11.5 25
100 Sum Wi.(Wi -Oi) 1144 1450
Soft Architectural Distance (SAD) score applying Equation (4.5) 0.789

Chapter 6. Results, Discussion and Future Directions Page | 115

 Table 6.11: Answer Architecture Questionnaire for Legacy – SO: CLOUD

Answer: Broad
Resource Scalable and Measured
Q. Sr. YES=1 On-demand self- network
AS-IS architecture analysis Questions pooling Elasticity service
No. service (W=20) access
NO=0? (W=20) (W=20) (W=20)
(W=20)
1 Packaged solution 0 1 0.8 0.8 1 1
2 Home grown applications? 1 0.3 0.3 0.3 0.2 0.3
3 Development is done using framework? 0 0.5 0.4 0.5 0.6 0.4
4 Batch Programs in 3 GL? 1 0.3 0.2 0.2 0.2 0.6
3-Tier architecture to keep
5 1 0.6 0.3 0.6 0.3 0.2
presentation and biz layer separated?
6 Monolithic structure? 1 0.2 0.2 0.1 0.3 0.2
Ecosystem is heterogeneous (e.g. C, JAVA, SAP,
7 0 0.4 0.4 0.3 0.7 0.5
DB scripts etc.)?
8 Nature of services is database centric? 1 0.5 0.5 0.4 0.3 0.2
9 Nature of services is functionality/logic centric? 0 0.4 0.5 0.6 0.5 0.5
Age of LEGACY in range of
10 1 0.1 0.1 0.1 0.1 0.2
20 years?
Age of LEGACY in range of
11 0 0.3 0.3 0.3 0.3 0.2
10 years not older?
Age of LEGACY in range of
12 0 0.6 0.4 0.6 0.6 0.3
5 years not older?
13 Services used by SELF/mother application only? 1 0.3 0.3 0.4 0.6 0.5
14 Services published and used by self and others? 0 0.8 0.7 0.7 0.7 0.8

Chapter 6. Results, Discussion and Future Directions Page | 116

 Answer: Broad
Resource Scalable and Measured
Q. Sr. YES=1 On-demand self- network
AS-IS architecture analysis Questions pooling Elasticity service
No. service (W=20) access
NO=0? (W=20) (W=20) (W=20)
(W=20)
Application/service design is in the form of
15 0 0.8 0.6 0.5 0.4 0.5
functions for one logical set of actions?
Services / functions follow international level
16 0 1 1 1 0.8 0.8
standards?
Services do not follow international standards but
17 1 0.5 0.6 0.5 0.7 0.6
follow at organization level standards?
Functions and Services: signatures clearly
18 1 0.6 0.5 0.5 0.7 0.6
defined?
19 Functions do not use global or static variables? 0 0.5 0.5 0.5 0.4 0.6
Functions/Services signatures are published at
20 0 0.7 0.5 0.5 0.7 0.6
common place?
User Requirements Document (URD) exists at
21 0 0.3 0.4 0.4 0.1 0
product level?
User Requirements Document (FGD) exists at
22 0 0.4 0.5 0.5 0.2 0.2
product level?
User Requirements Document (DD) exists at
23 0 0.3 0.4 0.4 0.1 0.2
product level?
User Requirements Document (TGD) exists at
24 1 0.3 0.4 0.4 0.1 0.2
product level?
Service names represent the purpose correctly
25 0 0.7 0.6 0.6 0.5 0.6
(brief description compliments it)?

Chapter 6. Results, Discussion and Future Directions Page | 117

 Table 6.12: SAD Computation for SO: CLOUD

Weight Score Observed Analysis Score (Wi -Oi) Wi.(Wi-Oi) Wi. Wi

Cloud Attributes
(Wi) (Oi)

On-demand self-service 20 3.7 16.3 326 400

Broad network access 20 3.4 16.6 332 400
Resource pooling 20 3.5 16.5 330 400
Scalable and Elasticity 20 3.5 16.5 330 400
Measured service 20 3.6 16.4 328 400
Total 100 Sum Wi(Wi -Oi) 1646 2000

Applying Equation (4.5), SAD on CLOUD = 0.823.

Chapter 6. Results, Discussion and Future Directions Page | 118

 Table 6.13: Answer Architecture Questionnaire for Legacy – BM: SOA

LAW OF COMPOSITION
AS-IS architecture analysis

SERVICE AUTONOMY
Answer: YES=1/NO=0?

INTEROPERABILITY
COARSE GRAINED
NATURE of services

LOOSE COUPLING

REPLACEABILITY

ENCAPSULATION
SEARCHABLITY
ABSTRACTION

COMPLIANCE
Q. Sr. No.

(W=20)

(W=20)

(W=20)

(W=10)
(W=5)

(W=5)

(W=5)

(W=5)

(W=5)

(W=5)
Questions

1 Packaged solution? 0 0.8 0.5 0.5 0.2 0.2 0 0 0.5 0.1 0.1
2 Home grown applications? 1 0.3 0.1 0.1 0.1 0.1 0 0 0.1 0.1 0.1
3 Development is done using framework? 0 0.5 0.2 0.2 0.2 0.2 0.2 0.2 0.5 0.4 0.1
4 Batch Programs in 3 GL? 1 0.3 0.2 0.1 0.1 0 0.1 0.1 0.2 0.1 0.1
3-Tier architecture to keep
5 1 0.6 0.3 0.3 0.3 0.2 0.2 0.2 0.2 0.4 0.3
presentation and biz layer separated?
6 Monolithic structure? 1 0.1 0.1 0.1 0.1 0.1 0 0 0.1 0.1 0.1
Ecosystem is heterogeneous (e.g. C,JAVA, SAP, DB scripts
7 0 0.4 0.4 0.3 0.2 0.5 0.6 0.6 0.2 0.2 0.2
etc.) ?
8 Nature of services is database centric? 1 0.5 0.5 0.4 0.3 0.2 0.2 0.2 0.2 0.4 0.3
9 Nature of services is functionality/logic centric? 0 0.7 0.5 0.3 0.3 0.3 0.2 0.2 0.2 0.2 0.4
Age of LEGACY in range of
10 1 0.1 0.1 0.1 0.1 0.1 0 0 0.1 0.1 0.1
20 years?
Age of LEGACY in range of
11 0 0.3 0.2 0.1 0.1 0 0.1 0.1 0.2 0.1 0.1
10 years not older?
Age of LEGACY in range of
12 0 0.6 0.4 0.3 0.3 0.3 0.4 0.6 0.5 0.5 0.6
5 years not older?
13 Services used by SELF/mother application only? 1 0.3 0.3 0.4 0.6 0.5 0.5 0.6 0.4 0.4 0.4

Chapter 6. Results, Discussion and Future Directions Page | 119

 LAW OF COMPOSITION
AS-IS architecture analysis

SERVICE AUTONOMY
Answer: YES=1/NO=0?

INTEROPERABILITY
COARSE GRAINED
NATURE of services

LOOSE COUPLING

REPLACEABILITY

ENCAPSULATION
SEARCHABLITY
ABSTRACTION

COMPLIANCE
Q. Sr. No.

(W=20)

(W=20)

(W=20)

(W=10)
(W=5)

(W=5)

(W=5)

(W=5)

(W=5)

(W=5)
Questions
14 Services published and used by self and others? 1 0.8 0.7 0.7 0.3 0.4 0.4 0.6 0.5 0.5 0.6
Application/service design is in the form of functions for one
15 1 0.8 0.6 0.5 0.4 0.5 0.5 0.6 0.4 0.4 0.4
logical set of actions?
16 Services / functions follow international level standards? 0 1 1 1 0.8 0.8 0.6 0.8 0.8 0.8 0.8
Services do not follow international standards but follow at
17 1 0.8 0.6 0.5 0.7 0.6 0.6 0.6 0.7 0.4 0.6
organization level standards?
18 Functions and Services: signatures clearly defined? 1 0.6 0.5 0.5 0.7 0.6 0.9 0.9 0.5 0.4 0.6
19 Functions do not use global or static variables? 0 0.5 0.5 0.5 0.4 0.6 0.6 0.9 0.5 0.4 0.6
Functions/Services signatures are published at common
20 0 0.6 0.5 0.5 0.7 0.6 0.9 0.9 0.5 0.4 0.6
place?
User Requirements Document (URD) exists at product
21 0 0.3 0.4 0.4 0.1 0 0.1 0.1 0.2 0.1 0.1
level?
22 User Requirements Document (FGD) exists at product level? 1 0.6 0.5 0.5 0.2 0.2 0.9 0.3 0.3 0.2 0.3
23 User Requirements Document (DD) exists at product level? 0 0.3 0.4 0.4 0.1 0.2 0.1 0.1 0.2 0.1 0.1
User Requirements Document (TGD) exists at product
24 1 0.3 0.4 0.4 0.1 0.2 0.1 0.1 0.2 0.1 0.1
level?
Service names represent the purpose correctly (brief
25 0 0.3 0.4 0.4 0.1 0.1 0.1 0.1 0.2 0.1 0.1
description compliments it)?

Chapter 6. Results, Discussion and Future Directions Page | 120

 Table 6.14: SAD computation for BM: SOA

Weight Score Observed Analysis Score

SOA Attributes (Wi -Oi) Wi. (Wi -Oi) Wi.Wi
(Wi) (Oi)
ABSTRACTION 20 6.1 13.9 278 400
COARSE GRAINED NATURE of services 20 4.9 15.1 302 400
LOOSE COUPLING 20 4.6 15.4 308 400
COMPLIANCE 5 4 1 5 25
INTEROPERABILITY 5 3.7 1.3 6.5 25
SEARCHABLITY 5 4.4 0.6 3 25
REPLACEABILITY 5 4.2 0.8 4 25
ENCAPSULATION 10 3.9 6.1 61 100
LAW OF COMPOSITION 5 3.6 1.4 7 25
SERVICE AUTONOMY 5 4 1 5 25
100 Sum Wi*(Wi -Oi) 979.5 1450
Soft Architectural Distance (SAD) score using Equation (4.5) 0.676

Chapter 6. Results, Discussion and Future Directions Page | 121

 Table 6.15: Answer architecture questionnaire for legacy – BM: CLOUD
Broad
Ans.: On-demand Resource Scalable and Measured
Q. Sr. network
AS-IS architecture analysis Questions YES=1/ self-service pooling Elasticity service
No. access
NO=0? (W=20) (W=20) (W=20) (W=20)
(W=20)
1 0 1 0.8 0.8 1 1
Packaged solution?
2 1 0.3 0.3 0.3 0.2 0.3
Home grown applications?
3 0 0.5 0.4 0.5 0.6 0.4
Development is done using framework?
4 1 0.3 0.2 0.2 0.2 0.6
Batch Programs in 3 GL?
5 3-Tier architecture- 1 0.6 0.3 0.6 0.3 0.2
presentation and biz layer separated?
6 1 0.2 0.2 0.1 0.3 0.2
Monolithic structure?
7 Ecosystem is heterogeneous (e.g. C,JAVA, SAP, 0 0.4 0.4 0.3 0.7 0.5
DB scripts etc.)?
8 1 0.5 0.5 0.4 0.3 0.2
Nature of services is database centric?
9 0 0.4 0.5 0.6 0.5 0.5
Nature of services is functionality/logic centric?
10 Age of LEGACY in range of 1 0.1 0.1 0.1 0.1 0.2
20 years?
11 Age of LEGACY in range of 0 0.3 0.3 0.3 0.3 0.2
10 years not older?
12 Age of LEGACY in range of 0 0.6 0.4 0.6 0.6 0.3
5 years not older?
13 1 0.3 0.3 0.4 0.6 0.5
Services used by SELF/mother application only?
14 1 0.8 0.7 0.7 0.7 0.8
Services published and used by self and others?

Chapter 6. Results, Discussion and Future Directions Page | 122

 Broad
Ans.: On-demand Resource Scalable and Measured
Q. Sr. network
AS-IS architecture analysis Questions YES=1/ self-service pooling Elasticity service
No. access
NO=0? (W=20) (W=20) (W=20) (W=20)
(W=20)
15 Application/service design is in the form of 1 0.8 0.6 0.5 0.4 0.5
functions for one logical set of actions?
16 Services / functions follow international level 0 1 1 1 0.8 0.8
standards?
17 Services do not follow international standards but 1 0.5 0.6 0.5 0.7 0.6
follow at organization level standards?
18 1 0.6 0.5 0.5 0.7 0.6
Functions and Services: signatures clearly defined?
19 0 0.5 0.5 0.5 0.4 0.6
Functions do not use global or static VAR?
20 Functions/Services signatures are published at 0 0.7 0.5 0.5 0.7 0.6
common place?
21 User Requirements Document (URD) exists at 0 0.3 0.4 0.4 0.1 0
product level?
22 User Requirements Document (FGD) exists at 1 0.4 0.5 0.5 0.2 0.2
product level?
23 User Requirements Document (DD) exists at 0 0.3 0.4 0.4 0.1 0.2
product level?
24 User Requirements Document (TGD) exists at 1 0.3 0.4 0.4 0.1 0.2
product level?
25 Service names represent the purpose correctly 0 0.7 0.6 0.6 0.5 0.6
(brief description compliments it)?
Observed Score of as total (Oi) 5.7 5.2 5.2 4.8 5.1

Chapter 6. Results, Discussion and Future Directions Page | 123

 Table 6.16: SAD computation for BM: CLOUD

Weight Score Observed Score

Cloud Attributes (Wi -Oi) Wi.(Wi-Oi) Wi*Wi
(Wi) (Oi)

On-demand self-service 20 5.7 14.3 286 400

Broad network access 20 5.2 14.8 296 400
Resource pooling 20 5.2 14.8 296 400
Scalable and Elasticity 20 4.8 15.2 304 400

Measured service 20 5.1 14.9 298 400

Total 100 Sum Wi*(Wi -Oi) 1480 2000

Soft Architectural Distance (SAD) score using Equation (4.5) 0.74

Chapter 6. Results, Discussion and Future Directions Page | 124

 Table 6.17: Answer Architecture Questionnaire – Order Scheduling: SOA

LAW OF COMPOSITION

SERVICE AUTONOMY
INTEROPERABILITY
COARSE GRAINED
analysis Questions

LOOSE COUPLING

REPLACEABILITY
AS-IS architecture

ENCAPSULATION
Q. Sr. No.

SEARCHABLITY
ABSTRACTION

COMPLIANCE
Answer: Y/N?

(W=20)

(W=20)

(W=20)

(W=10)
(W=5)

(W=5)

(W=5)

(W=5)

(W=5)

(W=5)
1 Packaged solution? 0 0.8 0.5 0.5 0.2 0.2 0 0 0.5 0.1 0.1

2 Home grown applications? 1 0.3 0.1 0.1 0.1 0.1 0 0 0.1 0.1 0.1

3 Development is done using framework? 0 0.5 0.2 0.2 0.2 0.2 0.2 0.2 0.5 0.4 0.1

4 Batch Programs in 3 GL? 1 0.3 0.2 0.1 0.1 0 0.1 0.1 0.2 0.1 0.1

3-Tier architecture to keep

5 1 0.6 0.3 0.3 0.3 0.2 0.2 0.2 0.2 0.4 0.3
presentation and biz layer separated?

6 Monolithic structure? 1 0.1 0.1 0.1 0.1 0.1 0 0 0.1 0.1 0.1

7 Ecosystem is heterogeneous (e.g. C, JAVA, SAP, DB scripts etc.)? 0 0.4 0.4 0.3 0.2 0.5 0.6 0.6 0.2 0.2 0.2

8 Services are database centric? 1 0.5 0.5 0.4 0.3 0.2 0.2 0.2 0.2 0.4 0.3

9 Services is functionality centric? 0 0.7 0.5 0.3 0.3 0.3 0.2 0.2 0.2 0.2 0.4

Age of LEGACY in range of

10 1 0.1 0.1 0.1 0.1 0.1 0 0 0.1 0.1 0.1
20 years?
Age of LEGACY in range of
11 0 0.3 0.2 0.1 0.1 0 0.1 0.1 0.2 0.1 0.1
10 years not older?
Age of LEGACY in range of
12 0 0.6 0.4 0.3 0.3 0.3 0.4 0.6 0.5 0.5 0.6
5 years not older?

Chapter 6. Results, Discussion and Future Directions Page | 125

 LAW OF COMPOSITION

SERVICE AUTONOMY
INTEROPERABILITY
COARSE GRAINED
analysis Questions

LOOSE COUPLING

REPLACEABILITY
AS-IS architecture

ENCAPSULATION
Q. Sr. No.

SEARCHABLITY
ABSTRACTION

COMPLIANCE
Answer: Y/N?

(W=20)

(W=20)

(W=20)

(W=10)
(W=5)

(W=5)

(W=5)

(W=5)

(W=5)

(W=5)
13 Services used by SELF/mother application only? 1 0.3 0.3 0.4 0.6 0.5 0.5 0.6 0.4 0.4 0.4

14 Services published and used by self and others? 1 0.8 0.7 0.7 0.3 0.4 0.4 0.6 0.5 0.5 0.6

Application/service design is in the form of functions for one logical set of

15 1 0.8 0.6 0.5 0.4 0.5 0.5 0.6 0.4 0.4 0.4
actions?

16 Services / functions follow international level standards? 0 1 1 1 0.8 0.8 0.6 0.8 0.8 0.8 0.8

Services do not follow international standards but follow at organization level

17 1 0.8 0.6 0.5 0.7 0.6 0.6 0.6 0.7 0.4 0.6
standards?

18 Functions and Services: signatures clearly defined? 1 0.6 0.5 0.5 0.7 0.6 0.9 0.9 0.5 0.4 0.6

19 Functions do not use global or static variables? 0 0.5 0.5 0.5 0.4 0.6 0.6 0.9 0.5 0.4 0.6

20 Functions/Services signatures are published at common place? 0 0.6 0.5 0.5 0.7 0.6 0.9 0.9 0.5 0.4 0.6

21 User Requirements Document (URD) exists at product level? 0 0.3 0.4 0.4 0.1 0 0.1 0.1 0.2 0.1 0.1

22 User Requirements Document (FGD) exists at product level? 1 0.6 0.5 0.5 0.2 0.2 0.9 0.3 0.3 0.2 0.3

23 User Requirements Document (DD) exists at product level? 0 0.3 0.4 0.4 0.1 0.2 0.1 0.1 0.2 0.1 0.1

24 User Requirements Document (TGD) exists at product level? 1 0.3 0.4 0.4 0.1 0.2 0.1 0.1 0.2 0.1 0.1

25 Service names represent the purpose correctly? 0 0.3 0.4 0.4 0.1 0.1 0.1 0.1 0.2 0.1 0.1

Chapter 6. Results, Discussion and Future Directions Page | 126

 Table 6.18: SAD computation for Order Scheduling: SOA

Weight Score Observed Analysis Score

SOA Attributes (Wi -Oi) Wi. (Wi-Oi) Wi. Wi
(Wi) (Oi)
ABSTRACTION 20 7 13 260 400
COARSE GRAINED NATURE of services 20 5.3 14.7 294 400
LOOSE COUPLING 20 4.7 15.3 306 400
COMPLIANCE 5 4.4 0.6 3 25
INTEROPERABILITY 5 4.3 0.7 3.5 25
SEARCHABLITY 5 4.6 0.4 2 25
REPLACEABILITY 5 4.9 0.1 0.5 25
ENCAPSULATION 10 4.6 5.4 54 100
LAW OF COMPOSITION 5 3.7 1.3 6.5 25
SERVICE AUTONOMY 5 4.2 0.8 4 25
Total 100 Sum Wi*(Wi -Oi) 933.5 1450
Soft Architectural Distance (SAD) score using Equation (4.5) 0.644

Chapter 6. Results, Discussion and Future Directions Page | 127

 Table 6.19: Answer Architecture Questionnaire – Order Scheduling: CLOUD
Broad network Resource Scalable and Measured
Answer: On-demand self-
Sr. No AS-IS architecture analysis Questions access pooling Elasticity service
YES=1/NO=0? service (W=20)
(W=20) (W=20) (W=20) (W=20)
1 Packaged solution 0 1 0.8 0.8 1 1
2 Home grown applications? 1 0.3 0.3 0.3 0.2 0.3
3 Development is done using framework? 0 0.5 0.4 0.5 0.6 0.4
4 Batch Programs in 3 GL? 1 0.3 0.2 0.2 0.2 0.6
3-Tier architecture to keep
5 1 0.6 0.3 0.6 0.3 0.2
presentation and biz layer separated?
6 Monolithic structure? 1 0.2 0.2 0.1 0.3 0.2
Ecosystem is heterogeneous (e.g. C, JAVA,
7 0 0.4 0.4 0.3 0.7 0.5
SAP, DB scripts etc.)?
8 Nature of services is database centric? 1 0.5 0.5 0.4 0.3 0.2
9 Nature of services is functionality/logic centric? 0 0.4 0.5 0.6 0.5 0.5
Age of LEGACY in range of
10 1 0.1 0.1 0.1 0.1 0.2
20 years?
Age of LEGACY in range of
11 0 0.3 0.3 0.3 0.3 0.2
10 years not older?
Age of LEGACY in range of
12 1 0.6 0.4 0.6 0.6 0.3
5 years not older?
13 Services used by SELF/mother application only? 1 0.3 0.3 0.4 0.6 0.5
14 Services published and used by self and others? 1 0.8 0.7 0.7 0.7 0.8
Application/service design is in the form of
15 1 0.8 0.6 0.5 0.4 0.5
functions for one logical set of actions?
Services / functions follow international level
16 1 1 1 1 0.8 0.8
standards?
Services do not follow international standards
17 1 0.5 0.6 0.5 0.7 0.6
but follow at organization level standards?

Chapter 6. Results, Discussion and Future Directions Page | 128

 Broad network Resource Scalable and Measured
Answer: On-demand self-
Sr. No AS-IS architecture analysis Questions access pooling Elasticity service
YES=1/NO=0? service (W=20)
(W=20) (W=20) (W=20) (W=20)
Functions and Services: signatures clearly
18 1 0.6 0.5 0.5 0.7 0.6
defined?
19 Functions do not use global or static variables? 0 0.5 0.5 0.5 0.4 0.6
Functions/Services signatures are published at
20 1 0.7 0.5 0.5 0.7 0.6
common place?
User Requirements Document (URD) exists at
21 0 0.3 0.4 0.4 0.1 0
product level?
User Requirements Document (FGD) exists at
22 1 0.4 0.5 0.5 0.2 0.2
product level?
User Requirements Document (DD) exists at
23 1 0.3 0.4 0.4 0.1 0.2
product level?
User Requirements Document (TGD) exists at
24 1 0.3 0.4 0.4 0.1 0.2
product level?
Service names represent the purpose correctly
25 1 0.7 0.6 0.6 0.5 0.6
(brief description compliments it)?
Observed Score of as total (Oi) 9 8.1 8.3 7.5 7.6

Chapter 6. Results, Discussion and Future Directions Page | 129

 Table 6.20: SAD computation for Order Scheduling: CLOUD

Weight Observed
Cloud Attributes
Score Score (Wi -Oi) Wi(Wi-Oi) Wi .Wi
(Wi) (Oi)
On-demand self-
service 20 9 11 220 400
Broad network
access 20 8.1 11.9 238 400
Resource pooling 20 8.3 11.7 234 400
Scalable and
Elasticity 20 7.5 12.5 250 400
Measured service 20 7.6 12.4 248 400
Totals 100 Sum Wi.(Wi -Oi) 1190 2000
Soft Architectural Distance (SAD) score using Equation (4.5) 0.595

Chapter 6. Results, Discussion and Future Directions Page | 130

Similar, computations have been done to validate notion of SAD. When applied on one of
benchmarked applications DRP, SAD score was 0.30 and 0.24 for SOA and CLOUD
respectively. SGA had 0.72 and 0.66, and VLOG as 0.86 and 0.79 scores for SOA &
CLOUD.
As can be read from the respective tables, SAD scores both for SO & BM are close to
one depicting poor state of legacy architecture. While Order Scheduling application was
qualified in stage-I but architecturally found to be good, hence decision was not to go for
transformation. This indicates that there is a scope to tune the management of application
to bring legacy crisis under control. Organizations may choose their decision looking the
SAD score. There is no single threshold determined for this, as stage-II is the final
evaluation and not only the indicator hence it‟s not purely mechanical. Value of SAD less
than 0.6 or more than 0.8 is clear indication good or bad architecture, however, values in
the range of 0.6 to 0.8 requires human intelligence and other softer factors may play role
in decision making.
Table 6.21: Validation through SAD Score
S. SAD
Application SAD (SOA) (CLOUD) Remarks
No.
Score very close to 0.8 and clear
1 SO 0.789 0.823
decision to go for transformation.
Undoubtedly it had to go for
transformation, however it was
2 VLOG 0.86 0.79
transformed before the model
developed.
Being non-legacy application
3 DRP 0.3 0.24 SAD score very low, close to 0, no
transformation to be done.
Already transformed, model
applied on old data (2013-14),
4 BM 0.676 0.74
result qualified stage-I for
transformation.
Already transformed, model
5 SGA (Price) 0.72 0.66 applied on old data (2011-12),
SAD score, favors the decision.
Order Management decision was not to
6 0.644 0.595
Scheduling go for transformation

Chapter 6. Results, Discussion and Future Directions Page | 131

SAD computations for SOA & CLOUD executed on different legacy applications few
already transformed and few under consideration are summarized in Table 6.21.
Outcome of the study is concluded with key findings described ahead. Prime objective of
the work has been to make the life better for the organizations and people managing or
dealing day to day with legacy systems. Alerting the organizations at right time to take
step forward for legacy transformation is key. One simple practical example of legacy
crisis situation is implementation of pricing up to 4th decimal place from existing 3
decimal places caused more than 1000 man days of effort including considerable effort
from top management and business people (case study described in section 1.3). This is
really a legacy crisis situation.

6.5 Conclusions
The findings of this work are summarized below:

 A model was developed to detect legacy crisis point, which has two stages. First
stage is operational symptom based and the second stage is based on architectural
issues.
 Developed methodology was applied on 204 applications belonging to 7 BSGs.
These 204 applications include 4 applications which were already transformed.
All these 4 applications are recommended by the methodology when applied on
pre-transformation production data and old architecture.
 Out of 204 applications, LCSS 80 percentile give 42 applications and these 42
applications are confirmed with poor rating and identified as target for next set of
applications under transformation.
 Legacy software after certain stage enters into crisis situation this situation
depends on the attributing factors identified in this study. Legacy crisis attributes
are almost similar for all sort of legacy but their weightage may differ specific to
the organization. Model developed in the study helps to decide weight factor for
each attribute. Legacy crisis symptom can be determined by LCSS score as per
the model developed. This LCSS is totally on the operational matrices. It is the 1st
stage of legacy crisis determination process.

Chapter 6. Results, Discussion and Future Directions Page | 132

  Second stage for legacy crisis detection goes with architectural and design aspect.
SAD degree indicates the design entropy of the application and confirms the
symptom of stage-I. SAD score less than 0.6 is sustainable architecture and
clearly the transformation can be delayed, score more than 0.8 forces the
organization to think immediately for transformation. SAD score ranging 0.6 to
0.8 however is much subjective and softer aspects play larger role in decision.
 In case stage-II detection with design entropy does not conform to the LCSS
findings in stage one. This meant that stage-I confirms the legacy crisis on high
node but SAD score contradicts the same. In this case legacy transformation
approach may vary. This indicates that full system replacement is not required
immediately and approach could be to handle the situation with evolution or
correction in same system. It may require handling of some softer challenges. As
it is done in case of Order Scheduling application.
 Softer challenges in legacy software management are much more important than
the technical ones. Study determined the softer issues and their weights impacting
the legacy transformation program. Study also suggested the ways to cope with
the softer challenges in legacy transformation. It covers personal and
organizational aspects. Choosing the right people and right organization to do the
right task or job is the key factor for success of legacy transformation. Involving
all stakeholders at right time is must.
 Right leadership with good project management along with support from
stakeholder is key. Project managers for big programs to have ICT and business
project managers, so that they can take care of ICT and business management
both.
 People engagement in the program and managing expectations of legacy
resources is important for transformation success.
 This research work has a peculiarity in terms of industrial aspects into academia.
Study has included all real data and applications of real world with big size
applications having big user-base. Academic research approach of study helped to
have quality outcome. It is only the industrial view which has highlighted the
weights of softer issues in legacy transformation.

Chapter 6. Results, Discussion and Future Directions Page | 133

  This work has determined softer issues which generally are faced during legacy
transformation programs.
 Practical approaches to cope the softer issues are also result of industry
experience into study. All practical approaches described were used to define the
checklist and tool to handle issues in legacy transformation.

6.6 Research Contributions

This research work has a peculiarity of incorporating enormous effort and experience to
the field of legacy maintenance. Research work is the compilation of more than 20 years
of real industry experience of individual and derivation of contributions of much
experienced team to this field. This work is unique formalization of empirical knowledge
for the benefit and reuse of wider community of engineers, researchers and organizations.
Access to the huge meaningful maintenance data and reports made this work most
practical. Contribution of the work can be categorized as:
6.6.1 Contribution to Society: This research work contributes in giving proactive
approach to cope with issues. Timely alert and actions to phase out legacy application
saves the effort and resources being wasted to non-value added activities.
6.6.2 Contribution to Engineers and Organizations: Organizations still working with
legacy face real challenge to decide when to phase-out the legacy software. If timely
replacement is not done it costs to the company and full ecosystem. One simple real
example of legacy limitation was managing pricing of components up to fourth decimal
places. In the microelectronic business volumes are huge with low unit prices. In the
tough competition quoting the price up to third decimal place was either losing profit for
company or losing business to the competition. Business was requesting enablement
since year 2006 but ICT was not able to fulfil the request because of multiple legacy
applications in full ecosystem starting from quotation till invoicing. More than 500 man
days of effort was initially estimated with huge risk to operations and potential legal
issues in case of discrepancies. Finally the implementation was limited to one key
customer enablement for using 4th decimal place in unit price with more than 700 man
days of effort in implementation and support. This realization was achieved in 2011-
2012. Business had to wait for 6 years for simple implementation which was finally done

Chapter 6. Results, Discussion and Future Directions Page | 134

with limitations and reduced scope. Post deployment issues were enormous, ITPs took
place business and ICT management made upset. But this all had resulted in learnings
about the ways to manage legacy. This research work contributes in giving proactive
approach to cope with such issues. Here also organizations can save huge effort and
resources.
6.6.3 Contribution to Researchers: The results and data provided in this research work
contribute in giving access to rich software legacy data and attributes. Academia can take
benefit to define the research directions to contribute further in the field of legacy
software management.

6.7 Future Directions

In general the academic researchers focus more on the technology aspect, making them
less value for the industry. Presented research work has extensive industry blend to make
it useful for practical purposes in industry. Similar thought process need to be encouraged
for future studies in the field of legacy transformation.

 Next researches are expected to be focused more on how to automate LCSS value
computation. A plug-in need to be developed which can interface with any
support tool like REMEDY to apply the LCSS algorithm of applications with
benchmarked recent applications.
 Code scan tool can be developed which uses all the architectural aspects to
automatically determine the SAD score with basic answer to questions and
organization specific parameter matrix as inputs.
 A fuzzy model can be developed to interpret the results of SAD computations,
especially when the SAD score has no extreme values, i.e. not clearly saying good
or bad architecture.
 In this study the methodology applied is generic but determination of factor sis
organization specific. Adding on to this methodology, future work could be to
release the factor/weight matrix generic to the industry. Organizations always
have time constraints in every project they do. So, the best solution for them is
ready-to-use matrix which is generic. Also if methodology is not correctly used
they may arrive to wrong factors.

Chapter 6. Results, Discussion and Future Directions Page | 135

  Generalization of matrices and weight factor needs extensive survey and
interview processes with right set of questions to get flavor of all segments of
software industry with aspects from different set of stake holders starting with
users, ICT management and project managers up to the designer, coder and
support engineers.
 Determination of architecture base matrix to made adaptive in nature. Initial
values of matrix elements are determined by experts but with usage of the model
the weight matrices must evolve through a learning system integration on real
data.
 This two stage model can be enhanced to three stage model by introducing this
automated technical architecture assessment. Where, the first stage remains with
LCSS computation on operational matrices, second stage is automated SAD
computation, and new third stage would be refinement of stage two via human
intervention to cover the historical aspects like age of legacy, reusability of
components and it‟s extent.
Legacy will never die, what is recent today will become legacy tomorrow. So the
research must go on to help industry and people dealing with legacy applications.

Chapter 6. Results, Discussion and Future Directions Page | 136

 References

[1] Seacord, Robert C., et al.: “Legacy modernization strategies. Technical Report
CMUSEI-2001-TR-025,” Carnegie Mellon University, Pittsburgh, 2001.
[2] Seacord, Robert C., Plakosh,D., Lewis,G.A.: “Modernizing Legacy Systems.
Carnegie Mellon,” SEI. Addison-Wesley, Reading, 2003.
[3] Bergey J., Smith D., Weiderman N., Wood S.,“Option Analysis for
Reengineering (OAR): Issues and Conceptual Approach, Software Engineering
Institute,” Carnegie Mellon University, Tech. Note CMU/SEI-99-TN-014, 1999.
[4] Van den Heuvel,Willem-Jan., “Integrating Modern Business Applications with
Legacy Systems: A Software Component Perspective,” MIT Press, Cambridge,
2007.
[5] Bennett, K., “Legacy systems: coping with stress. Software”, IEEE Transactions,
vol. 12(1), pp. 19-23, 1995.
[6] R. Kazman, S. G. Woods, and S. J. Carriere, “Requirements for Integrating
Software Architecture and Reengineering Models: CORUM II,” IEEE, In
Proceedings of WCRE-98, Honolulu, pp. 154-163, 1998.
[7] Amit Mishra, “Legacy Software Tragedy: with 4th Decimal Pricing, a Case
Study,” ST-Microelectronics, 2012
[8] Runeson, P., & Host, M., “Guidelines for conducting and reporting case study
research in software engineering.” Empirical Software Engineering, vol. 14(2),
pp. 131-164, 2008.
[9] Seaman, C. B., “Qualitative methods in empirical studies of software
engineering. Software Engineering”, IEEE Transactions on, vol. 25(4), pp. 557-
572, 1999.
[10] Seacord, R. C., Comella-Dorda, S., Lewis, G., Place, P., & Plakosh, D., “Legacy
System Modernization Strategies (No. CMU/SEI-2001-TR-025).”, Carnegie-
Mellon University Pittsburgh Pa Software Engineering Inst., 2001
[11] Sneed, H. M., “Encapsulation of legacy software: A technique for reusing legacy
software components,” Annals of Software Engineering, vol. 9(1-2), pp. 293-313,
2001.

References Page | 137

[12] Stehle, E., Piles, B., Max-Sohmer, J., & Lynch, K., “Migration of Legacy
Software to Service Oriented Architecture,” Department of Computer Science
Drexel University, Philadelphia, PA, 2014.
[13] Krafzig, D., Banke, K., Slama, D., “Enterprise SOA: Service Oriented
Architecture Best Practices”, Prentice Hall. pp. 75-83, 2004.
[14] Maamar, Z., Benslimane, D., Thiran, P., Ghedira, C.,Dustdar, S., Sattanathan, S.,
“Towards a context-based multi-type policy approach for Web services
composition,” Data & Knowledge Engineering., vol. 23(2), pp. 329-334. 2006.
[15] P. Zave and M. Jackson, “Conjunction as composition,” ACM Transactions on
Software Engineering and Methodology, vol. 2(4), pp. 379-411. 1993.
[16] Ravi Khadka, Amir S, Slinger Jansen, Jurriaan H., Geer P. Haas, “Migrating a
Large Scale Legacy Application to SOA: Challenges and Lessons Learned,”
IEEE, 20th Working Conference on Reverse Engineering (WCRE), pp. 425-432,
2013.
[17] Brooks Jr, F. P., “No Silver Bullet-Essence and Accidents of Software
Engineering,” IEEE Computer, Volume 20(4), pp. 10-19, 1987.
[18] Seaman, C. B., “Qualitative methods in empirical studies of software
engineering,” IEEE Transactions on, Vol. 25(4), pp. 557-572, 1999.
[19] Joseph F. Maranzano, Sandra A. Rozsypal and Gus H.Zimmerman, Guy W.
Warnken and Patricia E. Wirth, “Architecture Reviews: Practice and
Experience,” IEEE Software, vol. 22(2), pp. 34-43, 2005.
[20] Zhang, Z., Liu, R., & Yang, H., “Service Identification and Packaging in Service
Oriented Reengineering,” Software Engineering and Knowledge Engineering,
vol.5(1), pp. 620-625, 2005.
[21] P Fleeger S. L., “Software Engineering: Theory and Practices,” Pearson
Education, Second Edition, 2007.
[22] Bisbal, J., Lawless, D., Bing, W., & Grimson, J., “Legacy information systems:
issues and directions,” IEEE Software, vol. 16(5), pp. 103-111, 1999.
[23] J. J. Jiang, G. Klein, and R. Discenza, “Information system success as impacted
by risks and development strategies,” IEEE Transactions on Eng. Manage., vol.
48(1), pp. 46–55, 2001.

References Page | 138

[24] A. P. Snow and M. Keil, “The challenge of accurate software project status
reporting: a two-stage model incorporating status errors,” IEEE Transactions on
Eng. Manage., vol. 49(4), pp. 491–504, 2002.
[25] K. K. Hong and Y. G. Kim, “The critical success factors for ERP
implementation: An organizational fit perspective,” Information & Management,
vol. 40(1), pp. 25–40, 2002.
[26] J. S. K. Ang, C. C. Sum, and L. N. Yeo, “A multiple-case design methodology
for studying MRP success and CSFs,” Information & Management, vol. 39(1),
pp. 271– 281, 2002.
[27] M. Al-Mashari, A. Al-Mudimigh, and M. Zairi, “Enterprise Resource Planning:
A Taxonomy of Critical Factors,” European Journal of Operational Research,
vol. 146(2), pp. 352–364, 2003.
[28] V. A. Malbert, A. Soni, and M. A. Venkataramanan, “Enterprise resource
planning: Managing the implementation process,” European Journal of
Operational Research, vol. 146(2), pp. 302–314, 2003.
[29] B. C. Y. Tan, H. Jeff, H. J. Smith,M. Keil, and R.Montealegre, “Reporting bad
news about software projects: Impact of organizational climate and information
asymmetry in an individualistic and a collectivistic culture,” IEEE Transactions
on Eng. Manage., vol. 50(1), pp. 64–77, 2003.
[30] Aversano, L., & Tortorella, M., “An assessment strategy for identifying legacy
system evolution requirements in eBusiness context,” Journal of Software
Maintenance and Evolution: Research and Practice, vol. 16(4-5), pp. 255-276,
2004.
[31] Y. Xue, H. Liang, W. Boulton, and C. A. Snyder, “ERP implementation failures
in China: Case studies with implications for ERP vendors,” International Journal
of Production Economics, vol. 97, pp. 279–295, 2005.
[32] Roger S. Pressman, “Software Engineering: A Practitioner's Approach”, Mc-
Grawhil, Sixth Edition, 2005.
[33] Cap-Gemini, “Application Portfolio Analysis (APA),” Technical APA Report of
ST-Microelectronics, ICT solutions, 2013.

References Page | 139

[34] Amit Mishra, “Lessons Learnt from DAMLOG and DAMBILL,” Post-mortem
reports of SAP-migration projects of big Enterprise, 2013.
[35] Amit Mishra, “Legacy Architecture Principle Compendium,” Proceedings of
workshop, Archo-2015, Greater Noida, India, 2015.
[36] Bendix Cecilia, Amit Mishra et al., “Process Simplification Contextualization,”
Workshop, ST- Microelectronics, Rousset, France, 2015.
[37] Software Engineering Release Database, http://best-collab.st.com
/ws/Service_Management/SitePages/Home.aspx , ST-Microelectronics, 2013
[38] Belfrit Victor Batlajery, “Revisiting legacy systems and legacy modernization
from the industrial perspective”, Ph.D. Thesis, University of Utrecht, Utrecht, the
Netherlands, 2013.
[39] Microsoft Corporation, “The Business Value of Legacy Modernization”,
http://www.microsoft.com, 2007.
[40] Anupam Karar and Ramesh Kumar (TCS), “Transform Legacy Systems for
Improved Customer Experience,” http://feeds2.feedburner.com/tcswhitepapers,
2012.
[41] Hafedh Mili, Fatma Mili, and Ali Mili, “Reusing Software: Issues and Research
Directions,” IEEE Transactions on Software Engineering, vol. 21(6), 1995.
[42] Mr. SK Mishra and Prof. AK Mishra, “Creating Reusable Software Component
from Object-Oriented Legacy System through Reverse Engineering,” Journal of
Object Technology, vol. 8(5), pp. 133-152, 2009.
[43] Sneed, H.M., “Wrapping Legacy Software for Reuse in a SOA,” Multi Konferenz
Wirtschafts Informatik, vol. 2(1), pp. 345-360. 2006.
[44] Saunders, Shelly, Margaret Ross, Goeff Staples and Sean Wellington, "The
software quality challenges of service oriented architectures in ecommerce",
Software Quality Journal, vol. 14(1), pp. 65-75, 2006.
[45] Maurizio, A., Sager, J., Corbitt, G., & Girolami, L., “Service oriented
architecture: challenges for business and academia,” IEEE Conference in Hawaii
International Conference on System Sciences, Proceedings of the 41st Annual.
pp. 315-315, 2008.

References Page | 140

[46] Carlos Matos, Reiko Heckel, “Migrating Legacy Systems to Service-Oriented
Arch.,” Electronic Communications of the EASST, vol. 16(1), pp. 1-16, 2009.
[47] Zhang, Z., Yang, H., Zhou, D., & Zhong, S., “A SOA Based Approach to User-
Oriented System Migration,” Proceedings of the 2010 10th IEEE International
Conference on Computer and Information Technology, Washington, USA, pp.
1486-1491, 2010.
[48] Ravi Khadka, Amir Saeidi, Slinger Jansen, Jurriaan Hage, “A Method
Engineering Based Legacy to SOA,” IEEE International Conference on Software
Maintenance (ICSM), pp. 163-172, 2011.
[49] Ravi Khadka, Amir Saeidi, Slinger Jansen, Jurriaan Hage, “A Structured Legacy
to SOA Migration Process and its Evaluation in Practice,” 7th IEEE International
Symposium on the Maintenance and Evolution of Service-Oriented and Cloud-
Based Systems (MESOCA), pp. 2-11, 2013
[50] Khadka, R., Saeidi, A., Jansen, S., Hage, J., & Haas, G. P., “Migrating a Large
Scale Legacy Application to SOA: Challenges and Lessons Learned,” IEEE
conf. Proceedings of the 20th WCRE, Koblenz, Germany, pp. 425-432 , 2013
[51] Oladipo Onaolapo Francisca1 and Anigbogu Sylvanus Okwudili, “A Software
Reverse Engineering Methodology for Legacy Modernization”, International
Journal of Advances in Engineering & Technology, vol. 1(4), pp. 244-248, 2011.
[52] K. M. Lui and K. C. C. Chan, “Capability maturity model and SAP: Toward a
universal ERP implementation model,” International Journal of Enterprise Inf.
Syst., vol. 1(3), pp. 69–95, 2005.
[53] J. Verner and W. Evanco, “In house software development: What software
management practices are needed for project success,” IEEE Software, vol.
22(1), pp. 86–93. 2005.
[54] Y. J. Yeh and H. W. Chou, “Team composition and learning behaviors in cross
functional teams,” Social Behaviors and Personality, vol. 33(4), pp. 391–402,
2005.
[55] Z. Zhang, M. K. O. Lee, P. Huang, L. Zhang, and X. Huang, “A framework of
ERP systems implementation success in China: An empirical study,”
International Journal of Production Economics, vol. 98(1), pp. 56–80, 2005.

References Page | 141

[56] Ricardo Perez-Castillo, Ignacio Garcia-Rodriguez de Guzman, Ismael Caballero
and Mario Piattini, “Software Modernization By Recovering Web Services From
Legacy Databases,” Journal of Software Maintenance and Evolution: Research
and Practice, volume 25(5), pp. 507-533, 2012.
[57] J. Preston and N. Epley,“Explanations versus applications: The explanatory
power of valuable beliefs,” Psychology Sciences, vol. 16(10), pp. 826–832, 2005.
[58] Ricardo Perez-Castillo, Ignacio Garcia-Rodriguez de Guzman and Ismael
Caballero, “PRECISO: A Reverse Engineering Tool to Discover Web Services
from Relational Databases,” IEEE 16th Working Conference on Reverse
Engineering, pp. 309-310, 2009.
[59] B. Schmerl, J. Aldrich, D. Garlan, R. Kazman, and H. Yan., “Discovering
Architectures from Running Systems,” IEEE Transactions on Software
Engineering, vol. 32(7), pp. 454–466, 2006.
[60] Joseph F. Maranzano, Sandra A. Rozsypal and Gus H. Zimmerman, Guy W.
Warnken and Patricia E. Wirth, “Architecture Reviews: Practice and
Experience,” IEEE Software, vol. 22(2), pp. 34-43, 2005.
[61] Sascha Hunold , Matthias Korch , Bjorn Krellner, Thomas Rauber , Thomas
Reichel, Gudula Runger, “Transformation of Legacy Software into Client/ Server
Applications through Pattern-based Re-architecturing,” Annual IEEE
International Computer Software and Applications Conference, pp. 303-310,
2008.
[62] Carolyn B. Seaman, “Qualitative Methods in Empirical Studies of Software
Engineering. Software Engineering,” IEEE Transactions on, Software
Engineering, vol. 25(4), pp. 557-572, 1999.
[63] Shikun Zhou, Hongji Yang, Paul Luker and Xudong He, “A Useful Approach to
Developing Reverse Engineering Metrics,” IEEE, 23rd annual ICSAC, pp. 320-
322, 1999.
[64] Colosimo, M., De Lucia, A., Francese, R., Scanniello, G., & Tortora, G.,
“Introducing Legacy System Migration Technologies in a Software Company: a
Controlled Experiment,” 2007.

References Page | 142

[65] Runeson P, Martin Host, Austen Rainer, Bjorn Regnell, "Case Study Research In
Software Engineering, Guidelines And Examples", John Wiley & Sons, Inc.,
eBook, 2012
[66] Ardhendu Mandal, “BRIDGE: A Model for Modern Software Development
Process to Cater the Present Software Crisis,” IEEE International Advance
Computing Conference, pp. 1617-1623, 2009.
[67] Torchiano, M., Di Penta, M., Ricca, F., De Lucia, A., & Lanubile, F., “Migration
of Information Systems in the Italian Industry: A State of the Practice Survey,”
Information and Software Technology, vol. 53(1), pp. 71-86, 2011.
[68] Tomassetti, F., Torchiano, M., Tiso, A., Ricca, F., & Reggio, G., “Maturity of
Software Modelling and Model Driven Engineering: A Survey in the Italian
Industry,” Evaluation & Assessment in Software Engineering (EASE 2012), 16th
International Conference on IET, pp. 91-100, 2012.
[69] Geetha, S., “Possible Challenges of Developing Migration Projects,”
International Journal of Computers & Technology, Volume 3(3), pp. 463-465,
2012.
[70] Mohapatra, S., “Business Process Reengineering: Automation Decision Points in
Process Reengineering,” Springer, Science & Business Media, 2012.
[71] Gartner, Inc., “The Quest for Talent: You Are Not Seen Nothing Yet. Gartner
Research., from http://www.gartner.com/DisplayDocument?id=569115,” 2013.
[72] Pedram Bahramnejad, Seyyed Mehran Sharafi, Akbar Nabiollahi,“A Method for
Business Process Reengineering Based on Enterprise Ontology,” International
Journal of Software Engineering & Applications (IJSEA), vol.6(1), pp. 25-39,
2015.
[73] Oracle Corporation, “Cloud Reference Architecture”, White Paper, 2012.
[74] Pooyan Jamshidi, Aakash Ahmad, and Claus Pahl,“Cloud Migration Research: A
Systematic Review,” IEEE Transactions on Cloud Computing, vol.1(2), pp. 1-15,
2013.
[75] Papazoglou, M., & Van Den Heuvel, W. J., “Service-Oriented Design and
Development Methodology,” International Journal of Web Engineering and
Technology, vol. 2(4), pp. 412-442, 2006

References Page | 143

[76] Lin, C. Y., “Migrating to Relational Systems: Problems, Methods, and
Strategies,” Contemporary Management Research, vol. 4(4), pp. 369-380, 2008.
[77] Meng, F., Qu, Z., & Guo, X., “Refactoring Model of Legacy Software in Smart
Grid based on Cloned Codes Detection,” International Journal of Computer
Science Issues (IJCSI), vol. 10(1), pp. 296-303, 2013.
[78] Richards, L., & Morse, J.M., “Users guide for qualitative methods,” California:
Publications Inc., 2007.
[79] G. Canfora, M. Di Penta, and L. Cerulo, “Achievements and challenges in
software reverse engineering,” Communications of the ACM, vol. 54(4), pp. 142–
151, 2011.
[80] Tonella, P., Torchiano, M., Du Bois, B., & Systa, T., “Empirical studies in
reverse engineering: state of the art and future trends,” Empirical Software
Engineering, vol. 12(5), pp. 551-571, 2007.
[81] Jesus Bisbal, Deirdre Lawless, Bing Wu, and Jane Grimson, “Legacy
Information Systems: Issues and Directions,” IEEE Software, vol. 16(5), pp. 103-
111, 1999.
[82] Hugo Bruneliere, Jordi Cabot, Gregoire Dupe, Frederic Madiot, "MoDisco: A
model driven reverse engineering framework", Information and Software
Technology, vol. 56(1), pp. 1012, 2014.
[83] Venkatraghavan N Iyer-Infosys, “Legacy Modernization: Modernize and scale,”
http://www.infosys.com, 2008.
[84] Sven Burmester, Holger Giese, Jorg Niere, Matthias Tichy, Jorg P. Wadsack,
Robert Wagner, Lothar Wendehals, Albert Zondorf, "Tool integration at the
meta-model level: the Fujaba approach", International Journal on Software Tools
for Technology Transfer, vol. 6(1), pp. 203-209, 2004
[85] Bergey J, Liam O‟Brien, Dennis Smith DoD, “Software Migration Planning”,
Technical Note CMU/SEI-2001-TN-012 Carnegie Mellon University, 2001.
[86] Brodie ML, Michael Stone braker DARWIN, “On the incremental migration of
legacy information systems,” Technical memorandum TR-0222-10-92-165
Electronics Research Laboratory, College of Engineering, University of
California, Berkeley, March 1993.

References Page | 144

[87] Onaiza Maqbool, Haroon Babri, "Hierarchical Clustering for Software
Architecture Recovery", IEEE Transactions on Software Engineering, vol.
33(11), pp. 759-780, 2007.
[88] A. Marburger, B. Westfechtel, "Tools for understanding the behavior of
telecommunication systems", Software Engineering 2003. Proceedings. 25th
International Conference on, pp. 430-441, 2003.
[89] Duggan Jin, “Graceful Retirement: Your Applications,” Not You AV-15-4789
Gartner Group, http://www.gartner.com, 2002.
[90] Len Erlikh Unlock, “The power of your legacy systems Relativity Technologies
Inc,” http://www.relativity.com, 2000.
[91] J.H. Jahnke, A. Walenstein, "Reverse engineering tools as media for imperfect
knowledge", Reverse Engineering 2000. Proceedings, Seventh Working
Conference on, pp. 22-31, 2000.
[92] Onaiza Maqbool, Haroon Babri, "Hierarchical Clustering for Software
Architecture Recovery", IEEE Transactions on Software Engineering, vol.
33(11), pp. 759-780, 2007
[93] Simone Kaplan, “Despite the sluggish economy and uncertain business climate,
right now is the perfect time to tear down your legacy applications and start
over,” http://www.cio.com/archive/031502/ infrastructure_content.html, CIO
Magazine, 2002.
[94] S. Muhammad; O. Maqbool; A. Q. Abbasi , "Evaluating relationship
categories for clustering object-oriented software systems," IET Software, vol.
6(3), pp. 260-274, 2012.

[95] Gabriele Bavota, Rocco Oliveto, Malcom Gethers, Denys Poshyvanyk, Andrea
De Lucia, "Methodbook: Recommending Move Method Refactorings via
Relational Topic Models", IEEE Transactions on Software Engineering, vol.
40(7), pp. 671-694, 2014
[96] K. Bennett, “Legacy Systems, Coping with Success,” IEEE Software, vol. 12(1),
pp.19–73.1995.

References Page | 145

[97] Bisbal, J., Lawless, D., Bing, W., & Grimson, J. “Legacy information systems:
Issues and Directions,” IEEE Software, vol. 16(5), pp. 103-111. 1999.
[98] Chang-Yang Lin, “Migrating to Relational Systems: Problems, Methods, and
Strategies,” Contemporary Management Research, vol. 4(4), pp. 369-380, 2008.
[99] Oladipo Onaolapo Francisca1 and Anigbogu Sylvanus Okwudili, “A Software
Reverse Engineering Methodology for Legacy Modernization,” International
Journal of Advances in Engineering & Technology, vol. 1(4), pp. 244-248, 2011.
[100] Arash Habibi,Azam Sarafrazi, Sedigheh Izadyar,"Delphi Technique Theoretical
Framework in Qualitative Research," The International Journal of Engineering
And Science (IJES),vol. 3(4), pp. 08-13, 2014.
[101] H. Tromp and G. Hoffman, “Evolution of Legacy Systems, Strategic and
Technological Issues, Based on a Case Study,” Workshop on Evolution of Large-
Scale Industrial Software Applications (ELISA), 23 September 2003, ICSM
2003.
[102] K. Ewusi-Mensah, “Software Development Failures: Anatomy of Abandoned
Projects,” MIT Press, Cambridge, 2003.
[103] M. Jorgensen and D. Sjoberg, “The importance of not learning from experience,”
in Proceedings of European Software Process Improvements, Copenhagen,
Denmark, pp. 2.2–2.8, 2000.
[104] C. P. Holland and B. Light, “A critical success factors model for ERP
implementation,” IEEE Software, vol. 16(3), pp. 30–36, 1999.
[105] N. Welti, “Successful SAP R/3 Implementation: Practical Management of ERP
Projects. Reading,” MA: Addison-Wesley, 1999.
[106] Z. Zhang, M. K. O. Lee, P. Huang, L. Zhang, and X. Huang, “A framework of
ERP systems implementation success in China: An empirical study,”
International Journal of Production Economy, vol. 98(1), pp. 56–80, 2005.
[107] Kim Man Lui and Keith C. C. Chan, “Rescuing Troubled Software Projects by
Team Transformation: A Case Study With an ERP Project,” IEEE Transaction
on Engineering Management, vol. 55(1), pp. 171-184, 2008.

References Page | 146

[108] Carolyn B. Seaman, “Qualitative methods in empirical studies of software
engineering. Software Engineering,” IEEE Transactions on Software
Engineering, vol. 25(4), pp. 557-572, 1999.
[109] Ashwin Tomar & VM Thakre, “A Customized Model on Software Quality
Assurance & Reuse,” International Journal of Internet Computing, vol. 6(2), pp.
279-284, 2013.
[110] Chia-Chien Hsu, Brian A. Sandford, “The Delphi Technique: Making Sense of
Consensus,” Practical Assessment Research & Evaluation. vol. 12(10), pp. 1-8,
2007.
[111] Amit Mishra, Pradeep Tomar and Anurag Singh Baghel, “Soft Architectural
Distance (SAD): How Far is the Legacy Architecture from SOA Architecture
Principle?,” IOSR Journal of Computer Engineering(IOSR-JCE), vol. 1(1), pp. 7-
12, 2016.
[112] L. Lyons, “A Practical Guide to Data Analysis for Physical Science Students,”
Cambridge University Press, 1998
[113] Amit Mishra, Pradeep Tomar and Anurag Singh Baghel, “Transforming from
Legacy to Packaged/Standard S/W Solutions: For Big Enterprises,” Journal of
Software Engineering Tools and Technology Trends, vol. 3(1), pp.5-11, 2016.
[114] Amit Mishra, Pradeep Tomar and Anurag Singh Baghel, “Multistage Legacy
Software Crisis Detection Matrix,” IJCTA Journal, International Science Press,
vol. 9(10), pp. 453-461, 2016.
[115] Amit Mishra, Pradeep Tomar and Anurag Singh Baghel, “Technological
Advances in Computing and it is Coherence with Functional and Business
Needs,” Communication and Computing Systems - CRC Press, ICCCS-16, pp.
197-200, 2016.

References Page | 147

 Appendix-A: Data-sources, Techniques and
Models

This Appendix is aimed to present references and required details to all the data sources,
techniques and methods used in this thesis.

Data Sources

In the present work ST-Microelectronics Pvt. Ltd., Software Engineering data of all
seven BSGs were used largely. These 7 BSGs are namely-

• Sales and Marketing

• Global Logistics and Warehousing (GLWO)

• Finance

• Purchasing

• Manufacturing

• Human Resource (HR)

• Business Intelligence (BI)

The document mentioned below can be accessed on ST-Microelectronics Pvt. Ltd.

Intranet site as specified below for all seven BSGs.

[1] ST-Microelectronics PVT. LTD., ICT – BSGs Quarterly Master Releases KPI data,
http://best-collab.st.com/ws/SQA_SCC_Quality_Assurance/Measurement%20
and%20 Analysis/Forms/AllItems.aspx from year 2011 till 2015.
[2] ST-Microelectronics PVT. LTD., ICT-BSGs Operation and Support Service
Dashboard, http://best-collab.st.com/ws/Service_Management/SitePages/Home.
aspx and http://best.st.com/docshare/ict/ict-dashboard/Forms/AllItems.aspx,with
rolling 1 year data from year 2011 till 2015
[3] ST-Microelectronics PVT. LTD., ICT-TOP Page data for all seven BSGs,
http://best.st.com/Corporate/ICT/Documents/ICT-Top-Page-2015-V18.pdf from
year 2011 till 2015.

Page | 148
[4] ST-Microelectronics PVT. LTD., ICT-Remedy Database (Change Requests,
Incidents, Questions, Requests and Problems) for all seven BSGs,
ICT_Health_Evolution Business Object (BO) Universe, past 5 years, from 2011 till
2015.
[5] ST-Microelectronics PVT. LTD., ICT8D repository and fishbone / Eshikawa
diagram analysis reports covering critical Interrupts to production (ITPs),
http://8d.sgp.st.com/past 5 years, from 2011 till 2015.
[6] ST-Microelectronics PVT. LTD., ICT Applications Portfolio Analysis (APA) by
Cap-Gemini as benchmarking exercise on legacy transformation, http://best-
collab.st.com/ws/ICT/Reporting%20and%20Dashboards/Forms/AllItems.aspx?Roo
tFolder=%2Fws%2FICT%2FReporting%20and%20Dashboards%2FSnM%5FSPS
G%5FServiceManagement, 2013.
[7] ST-Microelectronics PVT. LTD., ICT, Time Logging System (TLS),
http://tls.sgp.st.com/ to report efforts on different ICT activities including KLO:
past 5 years, from 2011 till 2015.
[8] ST-Microelectronics PVT. LTD., ICT, Human Resources Data (limited access),
http://ehr.st.com/for employee attrition rate working in legacy area.

Delphi Technique
The Delphi technique [101] is used in this work for deriving parameter values and
sometimes weights of these parameters applicable for one organization. It is a well-
accepted method for gathering data from respondents within their domain of expertise.
The technique is designed as a group communication process which aims to achieve a
convergence of opinion on a specific real-world issue. Fig, A-1 describes the iterations in
Delphi Technique. ST-Microelectronics process working group (PWG) was instrumental
in determination of final set of attributes on legacy crisis contribution from operational
and architectural perspective. PWG is constituted with one senior representative from
each BSG and 3 members of S/W Engineering Practice Group (SEPG).

Appendix-A Page | 149

 Top-n Issues Ranking &
from 7 BSGs Prioritization

PWG PWG
Brainstorming Brainstorming

Identify PWG
Common Issues Approval

PWG Management
Brainstorming Agreement

Figure A.1: Delphi Technique Iterations

8D Problem Solving Technique:

8D (8 Disciplines) is Ford Motor Company's problem-solving method. It is a team

oriented problem solving approach. It is used to:

- protect the customer (external or internal) by implementing quickly interim

containment actions

- identify the technical and system root cause(s) of a sporadic problem

- implement relevant permanent corrective actions to eliminate technical root causes

- implement relevant preventive actions related to system root causes to avoid re-
occurrence.

Summary of all 8 dimensions is as follows:

D1: Forming the team, setting accountabilities.

D2: Explore all dimensions to detail the problem and gravity of problem.

Appendix-A Page | 150

D3: Apply immediately the containment actions

D4: Focus on n-why analysis, Eshikawa analysis to determine root cause.

D5/D6: In D5 the team lists the corrective actions linked to the technical root causes
(occurrence and escape). These actions must be verified to be sure they are effective and
that they do not cause other undesired effects for the customer (risk assessment). In D6
the permanent and selected corrective actions are implemented.

D7: The D7 objective is to prevent any recurrence. The team lists and implements all the
preventive actions linked to the potential, the system root causes (occurrence and escape)
and the cross-fertilization to avoid the same issue to happen again.

These actions must be verified to be sure they are effective and they don‟t cause other
undesired effects for the customer (risk assessment).

D8: This part is dedicated to the lessons learned, the assessment of the 8D and the closure
of the 8D. The „Lessons Learned‟ and the assessment are performed by the management
during the 8D board or the 8D closure meeting.

It concerns not only the lessons learned about the issue it-self but also about the way to
manage and solve it. What worked well? What did not work so well? Etc. are reviewed.

Appendix-A Page | 151

 Appendix-B: A Technical Report on Software
Maintenance, Key Performance Indicators:
Legacy Software Health Report

This Appendix is aimed to present a real industry data on software maintenance and
software engineering to compliment the work presented in this thesis. Based on this real
software data a technical report writing is presented to extract meaningful information.
Software maintenance data is taken from ST-Microelectronics operational dashboards.
Here the information processing is based on different flavors of software application
support. Data reported in this section belongs to seven Business Solution Groups (BSGs)
involving 204 applications running in live. Horizon of data is past three years, typically
from year 2012 to 2015. Software maintenance data is taken from corporate tools (e.g.
Remedy), reports and dashboards based on these tools etc. (See Appendix-A). A
systematic study is applied on the incidents, problems, service requests, change requests,
questions asked by users about application behavior, interrupts to production faced during
execution etc. Framework used for operations and support (OnS) processes here are
based on IT Infrastructure Library (ITIL). Suitable Key Performance Indicators (KPIs)
for software maintenance are discussed to emphasize on importance of management by
measurements. KPIs help to make the performance measurable and comparable. Trend
analysis of KPIs and their meaning is also elaborated which indicates about the actions to
take for quality improvement. Software Performance Indicators (SPI) are derived by
combining the KPIs from Information and Communication Technologies (ICT) service
dashboards. This information is supposed to be helpful for the software industry catering
mainly the software maintenance and support on legacy or old software. Study presented
here is also a good insight for the researchers contributing to software engineering and
software maintenance.
Software applications developed and deployed has regular maintenance and definite life
cycle like other operational things. Although there is no natural wear and tear effect on
software code like regular working machines, yet they start performing poorly due to
regular maintenance over the existing code. This all makes the software less robust in

Appendix-B Page | 152

their maintenance lifecycle. Big companies are very sensitive to control the software
robustness and quality. For this kind of control a measurement and benchmarking is
necessary. KPIs are such measuring indicators which help the organization to smell about
the health of application. It is much more necessary for software under maintenance for
longer period of time or software which are legacy today.
Overall health indicator for an application is represented in the form of SPI with visual
index on Red, Yellow and Green colors from bad to good. SPI is culmination of several
KPIs attributing with different weights. These weights are organization specific focus.
For example, some organizations may focus on timely closure and some may give more
focus to overall reduction in incident arrival trends. Drill down to the relevant factors
affecting SPI is made simple, which helps to investigate the root cause behind.
Compilation of this technical report has been done with ample of real industry data to
make it most practical. The study presented here will help the industry as well as
researchers working with legacy software and maintaining the home grown or purchased
old software packages. Following the recommendations made here, organizations attain
the faster maturity in their processes and practices resulting improved software quality
and reliability.
Data Dimensions and KPIs Used
This technical report presented here consists of varied data of software maintenance.
Even if it is based on single company data yet it has favors of seven BSGs operating in
different countries e.g. India, France, Italy, Singapore and Switzerland. These seven
business solution groups cover 204 applications running in live. Time range used to
present this report is 3 years, 2012 to 2015. Seven Business Solution Groups-
1- Business Intelligence(BI)
2- Finance
3- Global Logistics and Warehousing(GLWO)
4- Human Resources (HR)
5- Manufacturing
6- Purchasing
7- Sales and Marketing (SnM)

Appendix-B Page | 153

Following 7 KPIs are reported monthly in ICT top page to indicate health of applications.
Names are self-explanatory to describe the KPIs presented in Table B.1. Apart from these
there are architectural aspects but the main focus here to present only operational
perspective. Some effort was made to apply the practical software engineering approach
in but it was only for development stage, requirement engineering phase and not the
maintenance phase.
Table B.1: Seven KPIs of ICT Top Page
ICT TOP-Page KPI Indicating Factor Data Source
Number of Interrupts to Production issues(incidents ICT Service
Production (ITPs) in a quarter reported) dashboard
Number of incidents reported Production issues(incidents ICT Service
(per month) reported) dashboard
Number of questions asked by User Interface(UI) not in-
ICT Service
users on application behavior line with technological
dashboard
(per month) evolution
Number of incident ticket
Reduced vendor support/out ICT Service
violated Service Level
of warranty dashboard
Agreement (SLA)
Number of problem tickets Design Entropy (No-Object ICT Service
created (per month) orientation) dashboard
Number of average man days Time Logging
required in Keep Lights On Skill scarcity System (TLS)
(KLO) support (per month) reports
Attrition rate (per annum) of
Skill scarcity HR DB
engineers working in legacy area

Operations and Support Dashboard Summary

Operations and support dashboard is an instrument which gives service manager and ICT
management a way to have quick look of all KPIs and trend. This dashboard is derived
out of remedy database which is unique repository of all ITPs, incidents, problems and
changes. Dashboard is a synthesized excel based report. Links are on the home page to go
to detail of each KPI. O&S dashboard front page is shown in Fig. B.1.

Appendix-B Page | 154

 Figure B.1: Operations and Support dashboard of Sales Process applications
(Under SnM BSG)

Some of the KPI figures for a subset of Sales and Marketing BSG applications are shared
below and represented in graphs Fig. B.2 – Fig. B.9 -
Number of Incidents Reported (Per Month): Is record of any misbehavior of
application faced by users. Full detail of tickets are available in dashboard but summary
chart is shared in one sheet to have quick view of the trend. Any abnormal increase trend
gives the signal of unusual event. This need to be explained else a deeper analysis and
solution to the issue is initiated.
Number of Problems Reported (Per Month): Is record of consistent misbehavior of
any application function. Each problem may have multiple linked reported incidents.

Appendix-B Page | 155

 Incident Trend
450

400 390

350
# of Incidents

300

250
206 190
184 203
180 194
200 151 171
155 171 160156 156
150 137
115 120
105 97 100
100
65
38
50 24
21
Months
0
07- 08- 09- 10- 11- 12- 01- 02- 03- 04- 05- 06-
2015 2015 2015 2015 2015 2015 2016 2016 2016 2016 2016 2016
Total # of Incidents Arrived 105 97 100 390 206 180 151 184 203 190 160 65
No of Open Incidents 21 24 38 115 120 137 171 194 155 171 156 156

Figure B.2: Monthly incident trend for sales process applications (under SnM BSG)

Problem Trend
300

250
240
250 239 235
# of Problems

200 181
165
162
149 144
146
150

104
95
100

54 43
50 36
30 29
27 17 18
12 14 19 15

0
Months 07-2015 08-2015 09-2015 10-2015 11-2015 12-2015 01-2016 02-2016 03-2016 04-2016 05-2016 06-2016
Total # of Problem
12 14 19 54 27 36 17 30 43 29 18 15
Arrived
No of Open Problem 146 95 104 149 165 144 162 181 240 239 235 250

Figure B.3: Monthly Problem Trend for Sales Process Applications (Under SnM BSG)

Appendix-B Page | 156

Number of service requests and questions reported (per month): Is record of queries
asked by users while using application or certain functionalities which are not available
in applications are logged as service request by users to have back end support.

Service Request & Question Trend

200 173
176
180 157
159
160
# of Service Requests

142 136 140

140
120 112 107 103
94
100 84 79
85 81
80 63
53 57
60
40 42
25 38
40
12 16
20
0
Months
07-2015 08-2015 09-2015 10-2015 11-2015 12-2015 01-2016 02-2016 03-2016 04-2016 05-2016 06-2016
Total # of Service Request & Question 112 107 94 176 142 136 157 173 159 140 103 81
No of Open Service Request & Question 12 16 25 40 38 42 53 57 63 85 84 79

Figure B.4: Monthly service request and question trend for sales process applications

Number of change requests reported (per month): Change requested for application
evolution.

Change Trend

140
122
120
# of Total Changes

104
81 97
100
78 76 86
77 69
80 65
56 59
60
31 34
40 23 27
16 25
18 16 14
20 13 10 9
0

07- 08- 09- 10- 11- 12- 01- 02- 03- 04- 05- 06-
2015 Months 2015 2015 2015 2015 2015 2016 2016 2016 2016 2016 2016
Total # of Changes Arrived 18 13 16 16 10 23 14 25 31 34 27 9
No of Open Changes 77 78 69 76 65 56 59 81 122 86 97 104

Figure B.5: Monthly change request trend for sales process applications
Appendix-B Page | 157
Service Level Objectives and Service Level Agreement (SLA):
It is the measurement of the percentage of tickets meeting the agreed time to resolve the
ticket. Acknowledgement is first response to requester, while resolution is the completing
the request with appropriate solution. Target for organization under study is 87% for
acknowledgement and 90% for resolution.

100.00%
90.00% 92.86%
86.15%
80.00% 82.28%
77.97% 77.01% Target 87%
70.00% 70.93%
SLO %

60.00% Acknowledge SLO

50.00% Compliance
40.00% Target
30.00%
20.00%
10.00%
Month (YYYY-MM)
0.00%
2016-01 2016-02 2016-03 2016-04 2016-05 2016-06

Figure B.6: Monthly SLO acknowledgement trend for sales applications

120.00%
Target 90%
100.00%
96.43%
85.29%
80.00% 81.13% 78.72%
73.33% 73.26%
Resolution SLO
60.00% Compliance
SLO %

Target
40.00%

20.00%
MONTH (YYYY-MM)
0.00%
2016-01 2016-02 2016-03 2016-04 2016-05 2016-06

Figure B.7: Monthly SLO resolution trend for sales applications

Appendix-B Page | 158

A service management dashboard on top of this is there to depict at a glance view of
health. SPI is computed as weighted average of above 10 KPIs. First glance having a red
attracts the attention to focus. Drill down to specific issue and KPI is a feature of this
dashboard.

Figure B.8: Service dashboard at ICT level

Figure B.9: Service dashboard at Sales and Marketing level

Appendix-B Page | 159

Report Findings
This section shares summary data on 7 KPIs relevant for old applications. It gives insight
on support and maintenance effort required in keep running the old application. Important
findings of this technical report are as follows:
1- Abnormal growth in incidents even for a month affects the moving open incident
count at a moment for months.
2- High incident counts for few months lowers the SLA for coming many months
even if the ticket count is controlled.
3- Increase in the number of problem tickets in a month increases manifold in the
number of incidents.
4- Legacy applications face huge number of questions and service requests, draining
the ICT capability to do value added tasks.
5- Bad operational KPIs cost high value for keeping lights on (KLO), reducing to do
change request. This is reflected in unaddressed increasing trend of CRs from
business.

Acknowledgments
Special thanks to ST-Microelectronics for providing the opportunity to author to work as
process working group member and participating to various workshops and initiatives.
World-wide exposure to work with software engineering data made this technical report
more meaningful and practical. Thanks also to our management permitting to use non-
sensitive data for this report in view to give benefits to industry and researchers.

Appendix-B Page | 160