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: Really a Problem? Eberhard Wolff Head of Architecture https://swaglab.rocks/ https://ewolff.com/
2. Legacy is a Challenge
3. Congrats on Working on a Legacy System!
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 your job is important! •And an interesting challenge!
5. Why Legacy Software Is Great! •Legacy has a positive connotation (outside IT)
6. The Advantage of Working with Legacy Systems
7. What is Software Development About? •Code?
8. https://github.com/scala/scala/
9. https://github.com/scala/scala/
10. https://www.heise.de/blog/KI-in-der-Softwareentwicklung-Ueberschaetzt-9336902.html
11. Software Development = Learning •How to do things better. •Domain •Business case •Architecture •Technologies
12. Legacy = Knowing • An approach to solve the domain problem has been implemented. • Known: Domain Business case Architecture Technologies Domain-experts! Users!
13. Advantage: Knowing the Weaknesses
14. Knowing the Weaknesses Outdated Technology Need to improve legacy system New requirements Hard to change
15. Outdated Technology •Really? •Software development: costly and high risk. •Sticking with old technology might be less risk and cheaper.
16. Outdated Technology •Educate developers in the old system! •Might take time. •But cost-efficient and low risk.
17. Security and Outdated Technology •Technology might not get any security updates. •Migrations probably inevitable then.
18. 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
19. 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!
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 driver
21. 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
22. Recommendation: Provide business value – even in a technology migration!
23. Advantage: Knowing the Business Case and Domain Experts
24. 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”
25. 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
26. 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
27. 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.
28. Big Bang? Stepwise
29. Big Bang? Stepwise
30. Why Stepwise? •Less risk •Can provide value while migrating •Consider big bang for really small, simple systems
31. 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
32. Advantage: Knowing an Implementation of the Business Logic
33. Implement the Same Logic Anew? •Fallacy: Should be easy! •Slow development •Frustrating •Often IT as driver •Result: A very complex system •New Legacy
34. 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
35. Advantage: Knowing the Business Case, Domain Experts, and Users
36. 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?
37. 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
38. 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
39. https://software-architektur.tv/2023/01/27/folge149.html
40. Domain-driven Design •Let the domain drive the design! •Let the domain drive the migration! •Where is the business value?
41. Benefits •More motivation •More support by business experts and users
42. 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?
43. 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.
44. Business -> Migration •Nick Tune considers a strategic approach. •Business model canvas to capture changes to the business model. •Drives the migration.
45. https://software-architektur.tv/2020/08/07/folge011.html
46. https://www.manning.com/books/architecture-modernization
47. Legacy Migration Should not Create New Legacy!
48. 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
49. 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
50. Advantage: Knowing the Existing Architecture
51. Software Development = Learning •Does the Migration Actually Improve the Architecture? •Let’s do a fresh start!
52. 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
53. 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
54. 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
55. Requirements Piggyback Migration Requirement Migration Requirement Migration Requirement Migration
56. Migration Invoicing & Order Process Shipping Product Information System Customer Information System
57. Migration Invoicing & Order Process Shipping Product Information System Customer Information System Reporting (new) Order Process Replica of some data Replica of some data
58. Architecture: Better or Worse?
59. Architecture: Better or Worse Obviously better! Solves my business problem!
60. Architecture: Better or Worse •Reporting: New, additional part •More dependencies to legacy •Worse •Order process: Probably better structure •…but old order process still around
61. 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.
62. Building in Schleswig 1234 monastery 1530 home for the poor 1975 town hall
63. Goal: Peak Project Goal Migration Successful migration to a great, all modularized system.
64. 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.
65. Reality Architecture Too often: Magic In particular for migrations. What value will you generate in the next months?
66. 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
67. https://software-architektur.tv/2023/03/31/folge159.html
68. Compromise •Probably need to compromise during migration •Might need some migration that cannot be motivated by business value.
69. Can’t Always Piggyback Requirement Migration Migration Requirement Migration
70. Compromise •Is migration the only option to improve?
71. Advantage: Knowing the Existing System and Its Environment
72. Options •Lots of challenges = many options to improve the situation. •So lots of choice!
73. Options •Migrate to microservices! •Decouple teams! •Lots of effort •Problem: continuous delivery pipeline contention •Alternative: Speed up pipeline
74. Conclusion
75. Conclusion •Legacy means we know a lot. •Use it to your advantage! •Provide business value! •I.e. let the domain drive the design!
77. Send email to jax2024@ewolff.com 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