State of the Practice of Service Identification in Industry

1. State Of The Practices Of Service
Identification In Industry
Manel Abdella)f, Geoffrey Hecht, Hafedh Mili, Ghizlane Elboussaidi, Naouel Moha, Anas Shatnawi
Jean Privat, and Yann-Gaël Guéhéneuc
1
THE 16TH INTERNATIONAL CONFERENCE ON SERVICE ORIENTED COMPUTING
NOVEMBER 12-15, 2018, HANGZHOU, ZHEJIANG, CHINA

2. Outline
1- Introduction
2- Study design
3- State of the practice of legacy-to-SOA migration
4- State of the practice of service identification
5- Recommenda@ons
6- Conclusion
2

3. Outline
1- Introduction
2- Study design
3- State of the practice of legacy-to-SOA migration
4- State of the practice of service identification
5- Recommenda>ons
6- Conclusion
3

4. Introduction
4
Maintenance tasks become central
activities in many businesses
Legacy software systems are still
essential in many businesses
70% of today’s transactional operations
are still managed by legacy systems
Legacy systems cannot simply be removed / replaced as they execute complex business logic

5. Legacy Apps Are Cri.cal But Challenging To Maintain
5
• Legacy systems suffer from several shortcomings
• High maintenace cost
• Lack of flexibility
• Lack of scalability with the evolution of the increasing business needs and
technology in the market
• The lack of sufficient support to the old technologies and infrastructure
of legacy systems
Legacy systems modernization remains essential to ease their maintenance
and make them more flexible without loosing their business values

6. SOA migration is one avenue of legacy modernization
6

7. Service Identification
• SI is the most challenging phase of the overall
moderniza5on process
• The iden5fied services must meet a range of
expecta5ons concerning their capability, quality
of service, and efficiency of use.
• Several researches in academia about SI but li@le
is known how SI is conducted in industry.
7

8. What is the state of the
practices in industry of
legacy-to-SOA migration in
general and Service
Identification in particular?
8

9. Outline
1- Introduction
2- Study design
3- State of the practice of legacy-to-SOA migration
4- State of the prac;ce of service iden;fica;on
5- Recommenda;ons
6- Conclusion
9

10. Study Design
10

11. Collection of
potential
participants
Our target: Professionals with experience in legacy-to-
SOA migration
Companies specialized in the moderniza>on of legacy
systems
Online presenta>ons and webinars
LinkedIn, Facebook, twitter
Mailing lists
We reached a total number of 298 professionals where
45 fully completed the survey
8 interviews
11

12. Informa(on about the par(cipants
50%
23%
21%
6%
Software architect Software Engineer
Directors of technology other
(c) Profession
(a) Age
(b) Development Experience 12

13. Companies
13

14. Outline
1- Introduction
2- Study design
3- State of the practice of legacy-to-SOA migration
4- State of the practice of service identification
5- Recommenda<ons
6- Conclusion
14

15. Types of the Migrated Systems
(a) Age of the migrated systems
(b) Size of the migrated systems (c) Programming Languages of migrated systems
15
Practitioners migrate different types of old legacy systems implemented mainly in Cobol and Java.
53%
49%
33%
29%
18% 18%
13% 13%
11%
4% 4% 4%
2% 2% 2%
0%
10%
20%
30%
40%
50%
60%
C
O
B
O
L
J
a
v
a
C
I
C
S
J
a
v
a
s
c
r
i
p
t
C
C
#
C
+
+
A
s
s
e
m
b
l
e
r
P
L
/
1
R
P
G
F
o
r
t
r
a
n
O
R
A
C
L
E
f
o
r
m
s
P
H
P
P
a
s
c
a
l
S
P
L

16. Motivations for Legacy-to-SOA Migration
16
Reducing maintenance costs, improving the flexibility and interoperability of legacy systems are the
main motivations to migrate legacy systems to SOA.
82%
64% 64%
42%
38% 38% 38%
24%
0%
10%
20%
30%
40%
50%
60%
70%
80%
90%
Maintenance Interoperability Flexibility Reliability Performance Availability Testability Other

17. Migra&on Strategies
Rehosting Re-architecture
Rehosting &
re-architecture
17

18. • Rehost/move with minimal changes to a more modern platform
• The business logic and data remain unchanged on the new
platform.
• Rehosting is done when the hardware or software platforms
become too costly to support /no longer supported by the
manufacturer/vendor.
Mainframe
Open Systems z/os
Compa@bility Stack
Migra&on
Components
The system can be wrapped
within services once on the
new platform
TN3270
ECI/EP
JEE
Sockets
SOAP/XML
FTP Interfaces
HTTPS
3rd Party Infrastructure
DB2, IMS-DB, Adabas, Other
COBOL PL/I, C/C+ Java, Assembler, Other
JCL/JES
CICS, IMS-TM
z/OS
Application Logic
Batch Environment
Online Environment
Platform
3rd Party Infrastructure
RDBMS (Oracle, DB2 LUW, SQL Server), etc
COBOL PL/I, C/C+ Java, Other
Batch JCL & JES Equivalent
Transaction Monitor
Linux/UNIX/Windows
z/OS
Application
Compatibility
Middleware/VMs
3270 Access
MQ Interfaces
Review / Replace
Data Migration
Legacy Systems Rehosting

19. Legacy Systems Re-architecture
19

20. Rehosting
&
re-architecture
Minimizing disruption while ensuring business continuity
Avoiding the “big-bang” migra<on strategy
Re-hos<ng the legacy systems to modern pla>orms
to minimize hardware costs
Creating wrappers to hide the internal legacy
functionalities
Replacing progressively the legacy code
20

21. Outline
1- Introduction
2- Study design
3- State of the prac8ce of legacy-to-SOA migra8on
4- State of the prac.ce of service iden.fica.on
5- Recommendations
6- Conclusion
21

22. Do you think that service identification from legacy
systems is important for legacy-to-SOA migration?
YES (87%)
NO (13%)
Benefits of so*ware reuse
Increases so*ware produc3vity by
shortening so*ware development 3me
Reduces software development cost by
avoiding development from scratch
Reduces maintenance costs
Top-down approach
Source code not reusable
Not suitable for integration problem:
wrapping of the legacy system
22

23. What are the Inputs Used for Service
Identification ?
23
76%
71%
69%
58%
53%
49%
44%
27%
16%
9% 9%
7%
0%
10%
20%
30%
40%
50%
60%
70%
80%
Source Code Business Process Human Expertise Database Use Case User Interfaces Documentation Data Flow
diagrams
Execution traces Activity diagrams Ontology State Machines
diagrams

24. What is the Direction of Service Identification?
24
Top-Down (starting by the use of domain-specific conceptual models like
business concept and process models to identify services, which are the
specified and mapped onto a software landscape)
Bo?om-Up (starAng by analyzing the exisAng soDware landscape and
modularizing it)
Mixed (starAng by the use of both domain-specific conceptual models
and the analysis of the soDware source code to idenAfy services)
No idea

25. NTTData case
25

26. NTTData case
26

27. NTTData case
27

28. 28

29. Analyses Types for Service Identification
29
Practitioners mostly relied on static analyses of the source code of their legacy systems
for service identification.
80%
44%
40%
16%
7%
0%
10%
20%
30%
40%
50%
60%
70%
80%
90%
Source code analysis Runtime Analysis Textual Analysis Historical Analysis None of the above

30. Techniques Used for Service Identification
30
Functionality clustering and wrapping are the most used techniques of service
identification in industry
60%
47%
22%
20%
13% 13%
7%
4%
9%
0%
10%
20%
30%
40%
50%
60%
70%
Functionality
clustering
Wrapping Class clustering Formal concept
analysis
Heuristics−based Feature location Genetic algorithms Machine learning None of the above

31. Desired Service Quality Criteria
31
Only few service quality criteria are desired by practitioners in the SI process:
reusability, granularity, and loose coupling
62%
47%
44%
42%
40%
29% 29%
24%
20%
11%
0%
10%
20%
30%
40%
50%
60%
70%
Service Reuse Granularity Loose Coupling Adaptation Effort Cost Composability Number Of services High Cohesion Self−descriptiveness None of the above

32. Types of the Identified Services
32
Service identification is a business driven process that prioritize the identification of domain-
specific services rather than technical services.
73% 73%
56%
49%
38% 38%
0%
10%
20%
30%
40%
50%
60%
70%
80%
Business Application Entity Entreprise Utility Infrastructure

33. Automation of
Service Identification
• The full automation of service identification process is not the primary
focus of practitioners
• Automation in wrapping and reverse engineering techniques to
document and extract the business logic of legacy systems
• Practitioners do not take the risk to try to fully automate the SI
process
• Challenging problem
• Unpredictable results
• Time consuming
• Needs a lot of research investments
6%
50%
44%
Fully automatic
Semi-automatic
Manual
33

34. Recommenda)ons
Service identification
should be a business-
value driven process
A deep understanding of
the domain and a great
familiarity with the legacy
systems are necessary
The input must be source
code and production data
The output must be high-
value, coarse-grained
services
The process must follow a
proven methodology
34

35. Conclusion
• Importance of service iden1fica1on
• Process driven by business value rather
than quality criteria
• The full automa1on of service
iden1fica1on process is not the
primary focus of prac11oners
• Feedback loop with business analysts
and customers is essensal to decide
about the per1nence of the candidate
iden1fied services.
35

36. Conclusion
• Gap between Academia and Industry
• Poor knowledge transfer between academia
and industry in the context of legacy-to-SOA
migration
• The lack of cost-effective academic service
identification techniques
• The lack of validation on real enterprise-scale
systems
• Industry-relevant research directions:
• Automation of SI
• Legacy systems understanding without reverse-
engineering
• Efficient reverse-engineering tools that detect all
dependencies between legacy systems
components.
36

37. Future Work
• Build of an exhaustive catalogue of
best practices for SI.
• Empirically study the gap between
academia and industry in terms of SI
strategies.
• Propose an automated type-centric
identification approach of services
based on legacy software systems
analyses.
37

38. Thank you !
38