$30 off During Our Annual Pro Sale. View Details »

Legacy Software: Not Really a Problem!

Eberhard Wolff
September 27, 2023

Legacy Software: Not Really a Problem!

Legacy software makes even experienced developers shudder. But the word "legacy" actually has a negative connotation only in IT. And legacy software practically always solves a business problem successfully, while a newly developed software must first find its niche. This presentation shows how to use these and other insights to come up with strategies for dealing more productively and successfully with legacy software. And that's how to turn the "problem" of legacy into an opportunity.

Eberhard Wolff

September 27, 2023
Tweet

More Decks by Eberhard Wolff

Other Decks in Technology

Transcript

  1. Legacy Software:
    Not Really a Problem!
    Eberhard Wolff
    Head of Architecture
    https://swaglab.rocks/
    https://ewolff.com/

    View Slide

  2. Legacy is a Challenge

    View Slide

  3. Congrats on Working
    on a Legacy System!

    View Slide

  4. 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 the job is important!
    •And an interesting challenge!

    View Slide

  5. Why Legacy Software Is Great!
    •Legacy has a positive connotation
    (outside IT)

    View Slide

  6. The Advantage of Working
    with Legacy Systems

    View Slide

  7. What is Software Development About?
    •Code?

    View Slide

  8. https://github.com/scala/scala/

    View Slide

  9. https://github.com/scala/scala/

    View Slide

  10. Software Development = Learning
    •How to do things better.
    •Domain
    •Business case
    •Architecture
    •Technologies

    View Slide

  11. Legacy = Knowing
    • An approach to solve the domain problem has been
    implemented.
    • Known:
    • Domain
    • Business case
    • Architecture
    • Technologies
    • Domain-experts!

    View Slide

  12. Advantage:
    Knowing the Weaknesses

    View Slide

  13. Knowing the Weaknesses
    Outdated
    Technology
    Need to improve
    legacy system
    New requirements
    Hard to change

    View Slide

  14. Outdated Technology
    •Really?
    •Software development: costly and high risk.
    •Sticking with old technology might be cheaper.

    View Slide

  15. Outdated Technology
    •Educate developers in the old system!
    •Might take time.
    •But cost-efficient and low risk.

    View Slide

  16. Security and Outdated Technology
    •Technology might not get any security updates.
    •Migrations probably inevitable then.

    View Slide

  17. Technology
    Why don‘t you use a cross-
    compiler or emulator?
    Low risk!
    Cost efficient!
    Are you nuts?
    The software must be
    changeable!
    So it is not just about
    outdated technology

    View Slide

  18. UI
    Old, complex Architecture
    Same UI
    Clean Architecture
    Why would users /
    business experts
    support this
    migration?
    You need their
    expertise!
    You need their
    political support!

    View Slide

  19. 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

    View Slide

  20. 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 drive

    View Slide

  21. Recommendation:
    Provide business value – even
    in a technology migration!

    View Slide

  22. Advantage:
    Knowing the Business Case
    and Domain Experts

    View Slide

  23. Legacy System: Advantage
    •There is already a system.
    •This systems is useful.
    •We “only” need to optimize.
    •Existing system can give us some freedom to do so.
    •But something has to change.
    •“Migration”

    View Slide

  24. 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

    View Slide

  25. 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

    View Slide

  26. 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.

    View Slide

  27. Big Bang? Stepwise

    View Slide

  28. Big Bang? Stepwise

    View Slide

  29. Why Stepwise?
    •Less risk
    •Can provide value while migrating
    •Consider big bang for really small, simple systems

    View Slide

  30. 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

    View Slide

  31. Advantage:
    Knowing an Implementation
    of the Business Logic

    View Slide

  32. Implement the Same Logic Anew?
    •Slow development
    •Frustrating
    •Often IT as driver
    •Result: A very complex system
    •New Legacy

    View Slide

  33. UI
    Old, complex Architecture
    Same UI
    Clean Architecture
    Why would users /
    business experts
    support this
    migration?
    You need their
    expertise!
    You need their
    political support!

    View Slide

  34. Advantage:
    Knowing the Business Case
    and Domain Experts

    View Slide

  35. 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?

    View Slide

  36. 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

    View Slide

  37. 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

    View Slide

  38. https://software-architektur.tv/2023/01/27/folge149.html

    View Slide

  39. Domain-driven Design
    •Let the domain drive the design!
    •Let the domain drive the migration!
    •Where is the business value?

    View Slide

  40. Benefits
    •More motivation
    •More support by business experts and users

    View Slide

  41. 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?

    View Slide

  42. Business -> Migration
    •Migrating a system might be an effect of a business
    strategy.
    •Might need to understand it fully.
    •But: I consider myself an architecture consultant, not
    a business consultant.

    View Slide

  43. Business -> Migration
    •Nick Tune considers a strategic approach.
    •Business model canvas to capture changes to the
    business model.
    •Drives the migration.

    View Slide

  44. View Slide

  45. Legacy Migration Should
    not Create New Legacy!

    View Slide

  46. 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

    View Slide

  47. 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

    View Slide

  48. Advantage:
    Knowing the Existing
    Architecture

    View Slide

  49. Advantage:
    Knowing the Existing
    Architecture

    View Slide

  50. Software Development = Learning
    •Does the Migration Actually Improve the
    Architecture?
    •Let’s do a fresh start!

    View Slide

  51. 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

    View Slide

  52. 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

    View Slide

  53. 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

    View Slide

  54. Requirements Piggyback Migration
    Requirement
    Migration
    Requirement
    Migration
    Requirement
    Migration

    View Slide

  55. Reality
    Invoicing &
    Order
    Process
    Shipping
    Product Information System
    Customer Information System

    View Slide

  56. Migration
    Invoicing &
    Order
    Process
    Shipping
    Product Information System
    Customer Information System
    Reporting
    (new)
    Order
    Process

    View Slide

  57. Architecture:
    Better or Worse?

    View Slide

  58. Architecture: Better or Worse
    •Reporting: New, additional part
    •More dependencies to legacy
    •Worse
    •Order process: Probably better structure
    •…but old order process still around

    View Slide

  59. 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?

    View Slide

  60. View Slide

  61. Goal: Peak
    Project Goal
    Migration
    Successful migration
    to a great,
    all modularized system.

    View Slide

  62. 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.

    View Slide

  63. Reality
    Architecture
    Too often:
    Magic
    In particular for migrations.
    What value will you generate in the next months?

    View Slide

  64. 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

    View Slide

  65. https://software-architektur.tv/2023/03/31/folge159.html

    View Slide

  66. Compromise
    •Probably need to compromise during migration
    •Might need some migration that cannot be motivated
    by business value.

    View Slide

  67. Can’t Always Piggyback
    Requirement
    Migration Migration
    Requirement
    Migration

    View Slide

  68. Compromise
    •Is migration the only option to improve?

    View Slide

  69. Advantage:
    Knowing the Existing System
    and Its Environment

    View Slide

  70. Options
    •Lots of challenges
    = many options to improve the situation.
    •That has some benefits

    View Slide

  71. Options
    •Migrate to microservices!
    •Decouple teams!
    •Lots of effort
    •Problem: continuous delivery pipeline contention
    •Alternative: Speed up pipeline

    View Slide

  72. Conclusion

    View Slide

  73. Conclusion
    •Legacy means we know a lot.
    •Use it to your advantage!
    •Provide business value!
    •I.e. let the domain drive the design!

    View Slide

  74. https://www.socreatory.com/de/trainers/eberhard-wolff

    View Slide

  75. 60-Minuten-Consulting
    •Online
    •Inkl. Bericht
    •99€
    https://swaglab.rocks/60-min-consulting/

    View Slide

  76. Send email to [email protected]
    Slides
    + 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

    View Slide