Legacy Evolution - Done Right

As developers and architects, we spend most of our time adding features to our products (so-called "maintenance"). We are often annoyed about the many deficits of these systems.

Even supposedly simple things are becoming incredibly difficult
with these _legacy systems_, the _time-to-market_ is getting worse and worse, as business is calling for more and more features. Rarely we find time to reduce technical debt and clean up increasingly messy dependencies.

In this talk you'll learn about possibilities to systematically escape legacy hell and reduce technical and other debt in your systems. Get to know strategical and tactical improvement approaches
you can scale to fit your actual situation.

In the first step, we will conduct a breadth-first search for existing problems, issues and risks within your system. We clearly identify technical, organizational and communicative debts and determine their severity in order to concentrate on the worst of them..

Only then we'll start improving the existing situation: I will present a number of strategic improvement approaches.

Transcript

1. Legacy Evolution Done Right Dr. Gernot Starke
2. Dr. Gernot Starke INNOQ Fellow üArchitecture-Improver üCoach, Trainer ü arc42, aim42 ü iSAQB
3. There should be only ONE reason to change:
5. Change to add value...
6. • actionism • cargo cult • longing to try technology XY No:
7. Add value by removing problems
9. Complicated systems https://flic.kr/p/7XAjXu
10. Problems in complicated system (0) • taste • price • appearance • location (of restaurant) https://flic.kr/p/6xuSMU
11. Problems in complicated system (1) • taste • temperature • consistency • popularity • purchase price
12. Problems in complicated system (2) Nutritional value: carbs, protein, fat, vitamins drugs, contamination, poison, radioactivity https://flic.kr/p/bDGDMY
13. Problems in complicated system (3) Logistics & storage of ingredients https://flic.kr/p/pnVsxu
14. Pro Beginner •overview by methodical assessment •objective priorities •balance between strategy and tactic
15. Pro •overview by methodical assessment •objective priorities •balance between strategy and tactic e valuate analyze improve
16. architecture improvement method https://aim42.org
17. Breadth-first search Stakeholder Context Quality Architecture Code Runtime Data Tests Processes Infrastructure Security ....
18. Breadth-first search 1. Stakeholder 2. (Overall) structure 3. Code details 4. Cohesion 5. Context 6. Qualities 7. Development process 8. Persistence 9. Technology 10. Infrastructure examples... examples...
19. Stakeholder know many problems (+ solutions).
20. Overall structure Does component structure fit to problem? Too many dependencies?
21. Level-1: Component Disorder Sales Frontend Private + Corporate Configurator Shell Client Contracts UDS (User Data Service) Order & Fullfillment Vouchers & Rebates eGov Shop Sales & Contracts Archive External Partners Price Management Data Warehouse Marketing & Sales Campaigns Atlas Customs & Logistics Pricing Engine Sales Backend Private+Corp Hodor Optical Archive Post-Sales Services Security Extensions Legend: Java PHP Python C/C++ Hask ell Cobol PL/ SQL Flash HTML/ JS Sales Backend eGovernment
22. Code details Hotspots and other smells...
23. Metrics • coupling / dependencies • code complexity • performance • … good
24. Metrics • coupling / dependencies • code complexity • performance • … • errors per component • Know-How per component • change frequency • … good better
25. complex code that‘s modified often. Find Hotspots
26. Context External interfaces
27. VENOM External Interface Hell „Standard“ supplier Suppler API „Custom“ supplier >200 >200 point2point interfaces „Standard“ craftsmen „Custom“ craftsmen Craftsmen API ~35
28. Cohesion (does it belong together?)
29. (bad) Cohesion UDS (User Data Service) Order & Fullfillment Vouchers & Rebates Sales & Contracts Archive Price Management Marketing & Sales Campaigns Atlas Customs & Logistics Pricing Engine Sales Backend Private+Corp Sales Backend eGovernment determines prices calculations & data ALSO relevant for pricing
30. Analyse application data / data structures Databases, data-structures, distribution, replication, etc
31. Clean Code + Bad Persistence ... (500) ... (300) ... (400) ... (400) ... (400) relational DB, „done wrong“
32. Technology Appropriate? Outdated? Mis-used?
33. https://www.youtube.com/watch?v=xL4 0UN5p6IY #3
34. https://www.youtube.com/watch?v=xL4 0UN5p6IY
35. Example: Use of Rule-Engine • Review identifies deviation from standard (concerning loading strategy of Working-Memory) • Default: few but huge data sets • Reality: many but small data sets
36. breadth first search Metrics Structure Application Data Quality Security Processes Code Technology etc.
37. Pro •overview by methodical assessment •objective priorities •balance between strategy and tactic aim42
38. Our status: LARGE number of problems
39. Breadth-first search Stakeholder Kontext Qualität Architektur Code Laufzeit Daten Tests Prozesse Infrastruktur Security .... H ? H H M M ? M H H H M ? ? ? M M M M H M M ? H H M M H H M M ? H M M M M H H Priorities needed!
40. Pro •overview by methodical assessment •objective priorities •balance between strategy and tactic aim42
41. Breadth-first search Stakeholder Kontext Qualität Architektur Code Laufzeit Daten Tests Prozesse Infrastruktur Security .... H ? H H M M ? M H H H M ? ? ? M M M M H M M ? H H M M H H M M ? H M M M M H H Priorities needed!
42. Proposal: Map problems to money
43. prioritize / estimate problems roughly estimate... trivial problems
44. Issue Cost Improvement Cost > Only change something if problem is more expensive than its solution
45. Estimation: Fundamentals... Term Description Subject What do we estimate Unit Time, money, effort, pain (cost) factor What influences the subject? Assumptions What do we estimate/guess about these factors Observation Metrics, counts etc. of single factors Probability How sure are we of these numbers?
46. Pro •overview by methodical assessment •objective priorities •balance between strategy and tactic aim42
47. Verbesserung mit Tagesgeschäft day-to-day development Practices Practices time Approaches Practices Practices Practices Practices Scheduling Improvements
48. Categories of long-term improvements... Throw away & rebuild reduce size Improve some parts improve internal structure & cohesion «category» Long-Term Improvement Approach «category» Rewrite «category» Restructure «category» Data Migration «category» Brainsize «category» Improve Modularization «category» Supporting Patterns Improve processes or technology
49. Change by Extraction 2 1 Client Flawed (incohesive) System Client „other“ other features Client Flawed System Client „other“ other features Better other features Client (reduced) Flawed System Client „other“
50. Change by Split 1 2 3 Client Type 1 Flawed System Client Type 2 Client Type 1 Flawed System Client Type 2 Flawed System Client Type 1 Reduced to Type 1 Client Type 2 Reduced to Type 2 New Type 1 System Client Type 1 Client Type 2 New Type 2 System
51. Change by Switch („Strangulizer“) Original by Paul Hammant: http://paulhammant.com/2013/07/14/legacy-application-strangulation-case-studies/
52. Decorating Collaborator Client Code Flawed Supplier «use» Client Code Flawed Supplier „Proxy“ «use» «delegate» 1. 2. New functionality Client Code Flawed Supplier „Proxy“ «use» «delegate» «decoration» 1. 2. 3.
53. Beware of the database... it‘s usually harder to improve than the code
54. Summary e valuate analyze improve https://aim42.org 1. Identify problems 2. Prioritize 3. Change aim42
55. Thanx. Gernot Starke gernot.starke@innoq.com Twitter: @gernotstarke www.innoq.com