This is a translated presentation at Red Hat Forum Tokyo 2019. Every company are facing some problem in Application Modernization, and all of them have same issue. I told about 3 things, Application Architecture, Granularity and Development method. Here is also a message of what we have to do before containerize.

1. RED HAT FORUMS
How to tackle barriers of
Application Modernization
Masahiko Umeno
Chief Technologist
15th Nov. 2019
AP16

2. Frequent spoken subject about application renewal
2
From Business side Architecture granularity Dev.
method
Org. Motivation Estimation
method
Unusable GUI and work flow… √ √ √
Gave up new biz due to long duration of development
even if it was great idea
√ √ √
Input data many times due to different application √ √
From IT side Architecture granularity Dev.
method
Org. Motivation Estimation
method
No budget for renewal √ √ √ √
Worry about a migration due to too huge system √ √ √ √ √
Completely Black boxed √ √ √
Take a several year to clarify requirements through
source code
√ √ √
Don’t want to do it! reminds of Death March project √ √ √ √
No engineer / programmer available √ √ √
No leaders who have strong will √ √ √ √

3. Agenda
3© Red Hat K.K.
•
•
•

4. What to do in Application Modernization
4
Design
Operation
Design/Build
DB
Build Logic
Definition
Service
Define
Microservice
Branch data
for parallel
Design data
migration
Test Logic
Transfer
past data
Accept data
from new app
Design
Platform
Build Platform
Design UI
Design
Process
Design
Integration
Collect
old/new data
Build UI
Comparison
Old/New
Design
Architecture
Coordination
with Business
Coordination
with Business
Build/Test
Monitoring
Test Fault
tolerance
Test /
Progress def.
Design service
integration
Build/Test
Srvc. integration
Operation
Training
Build Process Test Process

5. Architecture

6. System is huge…
6
Application was composed by each
simple structure at first
http://combine-art.com/html/blog/matsumoto/post/blog.php?post_id=1526
Kowloon Walled City

7. System is huge…
7
Even though the floor
height is slightly
different, it is the same
building height, but the
number of floors is
different
Somehow same height on
the top floorObviously
added
Living?
http://combine-art.com/html/blog/matsumoto/post/blog.php?post_id=1526
Kowloon Walled City

8. Application Architecture
8O : I - -
M ):H C: H ::C AD D AD H H B: H H ::C AD
( C C D AD D C:: ID C : E :K C DAAD H ::C H :AA ID C : I A I C A:M A:
(A : DA:H
DA: I : K :
H: ,CI: : ,CE I / IE I ) I , : K :
D :HH I I H . C :B:CI D : H: D :HH : K :
): H DC ( : ( A A I DC ,C : :C : ): H DC : K :
) I ) I D B I D C ID H : :A I DC A / : I -: A : ) I : K :
EEA I DC ,CI: I DC : H: K :H CH I DC . C :B:CI
AAD I: B HI: H C ) C BEA:B:CI :M :EI DC C I : EE
. M: I C AD C H HE :II I B :H CD A:M A I C C :H

9. 9
Application Architecture
ESB / Application
Mobile
Application
Get
Parame
ters
Cautio
n Map
ATM
Map
Billing
Calc.
SSO API Gateway : Auth/ Policy/ Flow restriction
API A API B API C API Z
Rule
Engine
Clear the role for each components
• API Gateway: Access Control of API, Statistics Management,
Billing Management
• Fuse: Service call (API), Transaction Manager
• Rule Engine: API call pattern from Fuse, Decision of data which
need to use, Billing calculation
Rule
Engine
Service
Rule
Engine
DB
API D

10. 10
Loose coupling with Rule / Process /Data / Application
HR
Settkement
Salary
Training
StatusProcess Start
Department chk
Personnel chk
Reason chk
Position Appropriate
Training Appropriate
Saraly
Personnel
Wait for
Approval
Task List
Approval
Fetch Data
By employee
number
Feed all data
Return Result
Task Start
Fetch Data
Decision
Store Data
Task Fin
Approved
Get List
Fetch Data
App/Reject
Input
Response
Response
Status
HR
Settlement
Status
Decision Service
Data Service
Process ServiceThis architecture is being used in over
100 projects in Japan

11. Target and Granularity

12. What and how to migrate
12
Look into system attributes
Ex) change frequency and migration difficulty >> map to quadrant
Bulk migration: Too risky
One by one migration: I have no clue where to start…
Start small,
Expand successful experiences
Reduce Risk
>> Understand Iterative development is better than Waterfall development.
But we have no experience

13. Choose first implementation targets
13
High migration difficulty
Low change
frequency
Salted Best for successful experience
Re-writeTentative APIed
High change
frequency
Low migration difficulty

14. Service / Microservice
14
• What is “Service”
• One business provided by an organization such as a department, section
• Ex) All of the issuance of various certificates such as a copy of family register and
resident card by the Residents Section
• What is “Microservice”
• One serving provided by a person belonging to the organization
• Ex) Acceptance / issuance / provision of application for copying family register /
resident's card and receipt of money
• Not every single function
• Ex) Confirmation of presence / absence of address notation, conversion of Japanese
and Western calendar, calculation of number of sheets, etc.
• With a certain level of granularity where functions are integrated and
the type of input / output is not complicated >>Microservice
.

15. 15
Service : Business point of view
Design
Operation
Design/Build
DB
Build Logic
Definition
Service
Define
Microservice
Branch data
for parallel
Design data
migration
Test Logic
Transfer
past data
Accept data
from new app
Design
Platform
Build Platform
Design UI
Design
Process
Design
Integration
Collect
old/new data
Build UI
Comparison
Old/New
Design
Architecture
Coordination
with Business
Coordination
with Business
Build/Test
Monitoring
Test Fault
tolerance
Test /
Progress def.
Design service
integration
Build/Test
Srvc. integration
Operation
Training
Build Process Test Process
Service
• Contract
• Purchasing
• Delivery date
• Billing
• Production Planning
• Inventory
• …

16. 16
Service : System point of view
Design
Operation
Design/Build
DB
Build Logic
Definition
Service
Define
Microservice
Branch data
for parallel
Design data
migration
Test Logic
Transfer
past data
Accept data
from new app
Design
Platform
Build Platform
Design UI
Design
Process
Design
Integration
Collect
old/new data
Build UI
Comparison
Old/New
Design
Architecture
Coordination
with Business
Coordination
with Business
Build/Test
Monitoring
Test Fault
tolerance
Test /
Progress def.
Design service
integration
Build/Test
Srvc. integration
Operation
Training
Build Process Test Process
Integration Service
Platform Service
Data Service
Decision Service
Operation Service
User Interface Service
Decision Service
Process Service

17. Granularity of Unit
17) D
• A D C A B D
• (H K B AD AA D AE C D D
• (H E D EC C E D C
• EC CC C A D A B D (CD D D BI
-B B D N
• B C B CC H
• , C ED D B D C B CDB D I B C C
• D E D C CC BI D H CD AA D K BDE B
. B D BDE D B B D D C B C C
CCE C
• " " B D D C

18. 18
Microservice
Design
Operation
Design/Build
DB
Build Logic
Definition
Service
Define
Microservice
Branch data
for parallel
Design data
migration
Test Logic
Transfer
past data
Accept data
from new app
Design
Platform
Build Platform
Design UI
Design
Process
Design
Integration
Collect
old/new data
Build UI
Comparison
Old/New
Design
Architecture
Coordination
with Business
Coordination
with Business
Build/Test
Monitoring
Test Fault
tolerance
Test /
Progress def.
Design service
integration
Build/Test
Srvc. integration
Operation
Training
Build Process Test Process
Integration Service
Platform Service
Data Service
Decision Service
Operation Service
User Interface Service
Decision Service
Process Service
Contract Billing
Production
Planning
Inventory
…
Purchasing
Delivery
date
The cross of red and blue sell (like a yellow frame cell) are “microservice”

19. Granularity of Unit (Example of “Decision Service”)
19.
App
Order Detail
Shipping Chg
Discount
Commission
Sum
Too much fine grain
Input
Output
DB
Call Rule
Call Rule
Call Rule
Call Rule
Call Rule
Get Data
Get back to
App
Order Detail
Shipping Chg
Discount
Commission
Sum
Appropriate grain
Input
Output
DB
Call Rule
Get back to
Make all decisions
and return results
with a single rule call
Get Data
Not to use as Function Call
Not too large granularity with DB access
Unit to be processed with a certain degree of unity

20. Standardization / Individual
20
Design
Operation
Design/Build
DB
Build Logic
Definition
Service
Define
Microservice
Branch data
for parallel
Design data
migration
Test Logic
Transfer
past data
Accept data
from new app
Design
Platform
Build Platform
Design UI
Design
Process
Design
Integration
Collect
old/new data
Build UI
Comparison
Old/New
Design
Architecture
Coordination
with Business
Coordination
with Business
Build/Test
Monitoring
Test Fault
tolerance
Test /
Progress def.
Design service
integration
Build/Test
Srvc. integration
Operation
Training
Build Process Test Process
) )
( ) ) ) )

21. Development methods and
Organization

22. ”Black boxed”?
22
• No requirement documents
• Only SIer did application design and build
• Only Source Code exists
Can you make it somehow?
Oh, yes.. but if you have bottomless money and duration of a century…

23. Escape from “Black Boxed”
23
No clue even if you ask Business div. >> Stop the Application Immediately!!
Who will take a responsibility if annoying customers when someone overwrite a source?
The person who was in charge quit >> Responsibility belongs to a department, not a person
Should be clarified what kind of process is performed for what purpose as the responsibility of
the department
Nobody knows at IT >> Ask Div. who ordered application or took over
In most cases someonehas information!!

24. Escape from “Black Box”
24,
Work everyone knows >> Trunk
Work understood by the person in charge of a
project >> Twig
Work understood by the dep in charge >> Branch
Basic Rule
% 9
, . , 9 , ,
% 9 !

25. Our use case
25)(
Not used Logic
Alive Logic
The result of processing past 5 years data
Realized!!
It was complicated, costly and time
consuming because worrying about
unused logic when adding/changing
logic.
40%
60%
) ) ) ) . .

26. Visualize Data/Logic
26
CustomerCredit SKU
Dealing
Inventory
Summary
Delivery Date
Past
Transaction
Derivation for
payment terms and
tradable amount
Delivery Production Plan
Parts unit price x number
Wage, delivery fee, margin
Quotation
Inventory allocation, order
lead time, production lead
time
Order
Data & Decision & RuleCorrelation of
Decision Requirement Diagram by OMG

27. Iterative development (Rule)
27
Biz Rule
Biz Knowledge
Create rule
Input Data
(Past data)
Expectation
(Past processed data)
Executed Result
Test Result
Biz Person
Test (match Result & Expectation
at Rule Engine)
Ask

28. Development Method – Waterfall
28
Items Notes
Estimation In order to clarify the deliverables in each phase, it is easy to perform the
administrative procedures on the ordering side and the receiving side.
Overall picture It is easy to grasp the whole data design etc. used in each system.
Items Notes
Business Agility In terms of calculation of estimated man-hours, it is difficult to receive additional
requirements until completion, so business side requests are not accepted until
stable operation, and business side satisfaction is low.
Quality Since the actual definition of the requirement and design accuracy is not verified,
rework is likely to occur, and the order-receiving side takes immediate measures, so
it is easy to accelerate logic spaghetti.
Dev method Even if a better development method is discovered in the course of development,
reduction of man-hours and improvement of quality will be limited, due to fears that
control will not work and quality will deteriorate if the basics are changed.
Pros
Cons

29. Development method – Iterative
29
Items Notes
Biz Agility Necessary and unnecessary functions can be confirmed at an early stage with business
users, so that business improvement requests can be received, and business improvement
can be continued even in long-term construction projects.
Quality Problems that can be identified only after deploying and testing are not identified at the
final stage, but we must address at an early stage to minimize problems and improve
quality.
Dev method By reviewing the design, development and testing when one sprint is completed, it is easy
to make improvements and accelerate man-hour reduction and quality improvement. The
faster the failure occurs, the easier quality to improve.
Items Notes
Overall picture An organization that manages each sprint is necessary, because the overall image
tends to be difficult to grasp by minimizing the design and implementation range.

30. Development method
30
Design
Operation
Design/Build
DB
Build Logic
Definition
Service
Define
Microservice
Branch data
for parallel
Design data
migration
Test Logic
Transfer
past data
Accept data
from new app
Design
Platform
Build Platform
Design UI
Design
Process
Design
Integration
Collect
old/new data
Build UI
Comparison
Old/New
Design
Architecture
Coordination
with Business
Coordination
with Business
Build/Test
Monitoring
Test Fault
tolerance
Test /
Progress def.
Design service
integration
Build/Test
Srvc. integration
Operation
Training
Build Process Test Process

31. Coverage of Red Hat
31
Design
Operation
Design/Build
DB
Build Logic
Definition
Service
Define
Microservice
Branch data
for parallel
Design data
migration
Test Logic
Transfer
past data
Accept data
from new app
Design
Platform
Build Platform
Design UI
Design
Process
Design
Integration
Collect
old/new data
Build UI
Comparison
Old/New
Design
Architecture
Coordination
with Business
Coordination
with Business
Build/Test
Monitoring
Test Fault
tolerance
Test /
Progress def.
Design service
integration
Build/Test
Srvc. integration
Operation
Training
Build Process Test Process
/ /
/ / /
/ B / / /
/ /
/ / / /
/
/ /
/ / /
/ / / /
/
/
/
A

32. Conclusion
32© Red Hat K.K.
How to tackle barriers of Application Modernization…
• Renovate the architecture maintainability with consideration
• Determine the granularity of system migration based on business and
Application architecture considering as a ”Microservice”
• Do Not start from analysis source code
• ”Trunk” first, and then ”Branch" with test-driven Iteration dev.
• A streamlined and simplified process is absolutely necessary
, ,

33. linkedin.com/company/Red-Hat
youtube.com/user/RedHatAPAC
facebook.com/RedHatAPAC
twitter.com/Red_Hat_APAC
RED HAT FORUMS
, .
, . , ,
,