Legacy Software:
Really a Problem?
Eberhard Wolff
Head of Architecture
https://swaglab.rocks/
https://ewolff.com/
Slide 2
Slide 2 text
Legacy is a Challenge
Slide 3
Slide 3 text
Congrats on Working
on a Legacy System!
Slide 4
Slide 4 text
Why Legacy Software Is Great!
•Legacy software has business value!
•Otherwise, you wouldn’t be working on it.
•The organization would just get rid of it.
•So your job is important!
•And an interesting challenge!
Slide 5
Slide 5 text
Why Legacy Software Is Great!
•Legacy has a positive connotation
(outside IT)
Software Development = Learning
•How to do things better.
•Domain
•Business case
•Architecture
•Technologies
Slide 12
Slide 12 text
Legacy = Knowing
• An approach to solve the domain problem has been implemented.
• Known:
Domain
Business case
Architecture
Technologies
Domain-experts!
Users!
Slide 13
Slide 13 text
Advantage:
Knowing the Weaknesses
Slide 14
Slide 14 text
Knowing the Weaknesses
Outdated
Technology
Need to improve
legacy system
New requirements
Hard to change
Slide 15
Slide 15 text
Outdated Technology
•Really?
•Software development: costly and high risk.
•Sticking with old technology might be less risk and
cheaper.
Slide 16
Slide 16 text
Outdated Technology
•Educate developers in the old system!
•Might take time.
•But cost-efficient and low risk.
Slide 17
Slide 17 text
Security and Outdated Technology
•Technology might not get any security updates.
•Migrations probably inevitable then.
Slide 18
Slide 18 text
Technology
Why don‘t you use a cross-
compiler / emulator /
automated translation?
Low risk!
Cost efficient!
Are you nuts?
The software must be
changeable!
So it is not just about
outdated technology
Slide 19
Slide 19 text
UI / API
Old, complex Architecture
Same UI / API
Clean Architecture
Why would users /
business experts
support this
migration?
You need their
expertise!
You need their
political support!
Slide 20
Slide 20 text
New Requirements Are Important!
Outdated
Technology
Need to improve
legacy system
New requirements
Hard to change
Only valuable to
implement new
requirements
Usually not the
only driver
Slide 21
Slide 21 text
New Requirements Are Important!
Outdated
Technology
Need to improve
legacy system
New
requirements
Hard to change
Only valuable to
implement new
requirements
Usually not the
only driver
Slide 22
Slide 22 text
Recommendation:
Provide business value – even
in a technology migration!
Slide 23
Slide 23 text
Advantage:
Knowing the Business Case
and Domain Experts
Slide 24
Slide 24 text
Legacy System: Advantage
•There is already a system.
•This systems is useful.
•We “just” need to optimize.
•Existing system can give us some freedom to do so.
•But something has to change.
•“Migration”
Slide 25
Slide 25 text
How Long Will the Migration Take?
•How long did the development of the original system
take?
•If the new system will be done much quicker: Why?
•Let people estimate the time
Slide 26
Slide 26 text
How Long Will the Migration Take?
•Let people estimate the time.
•In months
•Fibonacci numbers:
1 month, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144
•Result: 89 months
Slide 27
Slide 27 text
Example
•Everyone agreed: 89 months
•You cannot run such a project and generate business
value only at the very end.
•So: Stepwise
•So: Provide business value while the project runs.
Slide 28
Slide 28 text
Big Bang? Stepwise
Slide 29
Slide 29 text
Big Bang? Stepwise
Slide 30
Slide 30 text
Why Stepwise?
•Less risk
•Can provide value while migrating
•Consider big bang for really small, simple systems
Slide 31
Slide 31 text
Why Stepwise?
A complex system that works is invariably
found to have evolved from a simple
system that worked.
John Gall: Systemantics: How Systems Really Work and
How They Fail
Slide 32
Slide 32 text
Advantage:
Knowing an Implementation
of the Business Logic
Slide 33
Slide 33 text
Implement the Same Logic Anew?
•Fallacy: Should be easy!
•Slow development
•Frustrating
•Often IT as driver
•Result: A very complex system
•New Legacy
Slide 34
Slide 34 text
Old, complex Architecture Clean Architecture
Why would users /
business experts
support this
migration?
You need their
expertise!
You need their
political support!
UI / API Same UI / API
Slide 35
Slide 35 text
Advantage:
Knowing the Business Case,
Domain Experts, and Users
Slide 36
Slide 36 text
Explore the Domain!
•Implement new and useful business logic
•What do users like?
•What is the value of the system?
•How can you improve the value?
Slide 37
Slide 37 text
Example 1
•Stepwise migration to microservices by the book
•But: What is the value to the customer / user?
•New strategy: implement new features
•Result: more value, more motivation
Slide 38
Slide 38 text
Example 2
•Stepwise migration to microservices by the book
•Plan: provide no business value
•Frustrating
•User struggle with reporting.
•So: implement new reporting
•Would otherwise have never been done.
•High motivation for team and business experts
Domain-driven Design
•Let the domain drive the design!
•Let the domain drive the migration!
•Where is the business value?
Slide 41
Slide 41 text
Benefits
•More motivation
•More support by business experts and users
Slide 42
Slide 42 text
Questions to Understand Business Value
•Why are we migrating the system?
•Why are we migrating now?
Why not in a year?
Why not a year ago?
Slide 43
Slide 43 text
Business -> Migration
•Migrating a system: effect of a business strategy.
•Migration is costly.
•Spending lots of money without a business need: unlikely
•Need understand business reaons fully.
•But: I consider myself an architecture consultant, not a
business consultant.
Slide 44
Slide 44 text
Business -> Migration
•Nick Tune considers a strategic approach.
•Business model canvas to capture changes to the
business model.
•Drives the migration.
Strangler Fig
•Starts to grow somewhere
•Grows upwards for light
•Takes energy from the tree
•The intend is not to kill the tree!
Vinayara
https://creativecommons.org/licenses/by-sa/3.0/deed.en
Slide 49
Slide 49 text
Strangler Fig Pattern
•Starts migration somewhere
•Take stuff from the original
system
–Event capture
–Asset capture
•Grow
•The intend is not to kill the
legacy application!
Vinayara
https://creativecommons.org/licenses/by-sa/3.0/deed.en
Slide 50
Slide 50 text
Advantage:
Knowing the Existing
Architecture
Slide 51
Slide 51 text
Software Development = Learning
•Does the Migration Actually Improve the
Architecture?
•Let’s do a fresh start!
Slide 52
Slide 52 text
Order Process
Invoicing
Process
Ecommerce: Define BCs
Accept order
Delivery
Tracking
Invoicing
Taxes
Shopping Cart
Invoicing
Taxes
Shipping
Tracking
Delivery
Accept order
Functionality
Shopping Cart
Slide 53
Slide 53 text
Order Process
Invoicing
Process
Ecommerce: Define BCs
Invoicing
Taxes
Shipping
Tracking
Shopping Cart
Delivery
Accept order
Request / change
local to one bounded
context
Relatively small
models
Slide 54
Slide 54 text
Order Process
Invoicing
Process
Ecommerce: Define BCs
Product: price
Customer: billing
address
Shipping
Product:
description
Customer:
shipping address
Customer:
recommend-
dations
Each model will
include a product
and a customer
Product: size /
weight
Migration
Invoicing &
Order
Process
Shipping
Product Information System
Customer Information System
Slide 57
Slide 57 text
Migration
Invoicing &
Order
Process
Shipping
Product Information System
Customer Information System
Reporting
(new)
Order
Process
Replica
of some
data
Replica
of some
data
Slide 58
Slide 58 text
Architecture:
Better or Worse?
Slide 59
Slide 59 text
Architecture: Better or Worse
Obviously better!
Solves my business
problem!
Slide 60
Slide 60 text
Architecture: Better or Worse
•Reporting: New, additional part
•More dependencies to legacy
•Worse
•Order process: Probably better structure
•…but old order process still around
Slide 61
Slide 61 text
Architecture: Goal?
•How important is the goal really?
•We did not really manage to get near it.
•Why is the final architecture so important for people?
•What matters: what you can achieve.
•What matters: business features delivered.
Slide 62
Slide 62 text
Building in Schleswig
1234 monastery
1530 home for the
poor
1975 town hall
Slide 63
Slide 63 text
Goal: Peak
Project Goal
Migration
Successful migration
to a great,
all modularized system.
Slide 64
Slide 64 text
Migration IMHO
What is the next step?
How can we implement the
current requirements and
approach the goal e.g. a better
modularization?
How do we overcome
the next obstacles?
Current requirements
Don’t
ignore
Focus
Goal: Peak
Project Goal
Successful migration
to a great,
all modularized system.
Slide 65
Slide 65 text
Reality
Architecture
Too often:
Magic
In particular for migrations.
What value will you generate in the next months?
Slide 66
Slide 66 text
Isolation and Big Ball of Mud
•Some parts of the systems might be beyond repair.
•Some parts might not be worth any investment.
•Isolate them!
•Let them be!
•Big Ball of Mud / Sweeping it under the Rug
Compromise
•Is migration the only option to improve?
Slide 71
Slide 71 text
Advantage:
Knowing the Existing System
and Its Environment
Slide 72
Slide 72 text
Options
•Lots of challenges
= many options to improve the situation.
•So lots of choice!
Slide 73
Slide 73 text
Options
•Migrate to microservices!
•Decouple teams!
•Lots of effort
•Problem: continuous delivery pipeline contention
•Alternative: Speed up pipeline
Slide 74
Slide 74 text
Conclusion
Slide 75
Slide 75 text
Conclusion
•Legacy means we know a lot.
•Use it to your advantage!
•Provide business value!
•I.e. let the domain drive the design!
Slide 76
Slide 76 text
No content
Slide 77
Slide 77 text
Send email to [email protected]
Slides
+ Service Mesh Primer EN
+ Microservices Primer DE / EN
+ Microservices Recipes DE / EN
+ Sample Microservices Book DE / EN
+ Sample Practical Microservices DE/EN
+ Sample of Continuous Delivery Book DE
Powered by Amazon Lambda
& Microservices
EMail address logged for 14 days,
wrong addressed emails handled manually