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.

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 saa2023@ewolff.com
    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