Slide 1

Slide 1 text

Legacy Evolution Done Right Dr. Gernot Starke

Slide 2

Slide 2 text

Dr. Gernot Starke INNOQ Fellow üArchitecture-Improver üCoach, Trainer ü arc42, aim42 ü iSAQB

Slide 3

Slide 3 text

There should be only ONE reason to change:

Slide 4

Slide 4 text

No content

Slide 5

Slide 5 text

Change to add value...

Slide 6

Slide 6 text

• actionism • cargo cult • longing to try technology XY No:

Slide 7

Slide 7 text

Add value by removing problems

Slide 8

Slide 8 text

No content

Slide 9

Slide 9 text

Complicated systems https://flic.kr/p/7XAjXu

Slide 10

Slide 10 text

Problems in complicated system (0) • taste • price • appearance • location (of restaurant) https://flic.kr/p/6xuSMU

Slide 11

Slide 11 text

Problems in complicated system (1) • taste • temperature • consistency • popularity • purchase price

Slide 12

Slide 12 text

Problems in complicated system (2) Nutritional value: carbs, protein, fat, vitamins drugs, contamination, poison, radioactivity https://flic.kr/p/bDGDMY

Slide 13

Slide 13 text

Problems in complicated system (3) Logistics & storage of ingredients https://flic.kr/p/pnVsxu

Slide 14

Slide 14 text

Pro Beginner •overview by methodical assessment •objective priorities •balance between strategy and tactic

Slide 15

Slide 15 text

Pro •overview by methodical assessment •objective priorities •balance between strategy and tactic e valuate analyze improve

Slide 16

Slide 16 text

architecture improvement method https://aim42.org

Slide 17

Slide 17 text

Breadth-first search Stakeholder Context Quality Architecture Code Runtime Data Tests Processes Infrastructure Security ....

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

Stakeholder know many problems (+ solutions).

Slide 20

Slide 20 text

Overall structure Does component structure fit to problem? Too many dependencies?

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

Code details Hotspots and other smells...

Slide 23

Slide 23 text

Metrics • coupling / dependencies • code complexity • performance • … good

Slide 24

Slide 24 text

Metrics • coupling / dependencies • code complexity • performance • … • errors per component • Know-How per component • change frequency • … good better

Slide 25

Slide 25 text

complex code that‘s modified often. Find Hotspots

Slide 26

Slide 26 text

Context External interfaces

Slide 27

Slide 27 text

VENOM External Interface Hell „Standard“ supplier Suppler API „Custom“ supplier >200 >200 point2point interfaces „Standard“ craftsmen „Custom“ craftsmen Craftsmen API ~35

Slide 28

Slide 28 text

Cohesion (does it belong together?)

Slide 29

Slide 29 text

(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

Slide 30

Slide 30 text

Analyse application data / data structures Databases, data-structures, distribution, replication, etc

Slide 31

Slide 31 text

Clean Code + Bad Persistence ... (500) ... (300) ... (400) ... (400) ... (400) relational DB, „done wrong“

Slide 32

Slide 32 text

Technology Appropriate? Outdated? Mis-used?

Slide 33

Slide 33 text

https://www.youtube.com/watch?v=xL4 0UN5p6IY #3

Slide 34

Slide 34 text

https://www.youtube.com/watch?v=xL4 0UN5p6IY

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

breadth first search Metrics Structure Application Data Quality Security Processes Code Technology etc.

Slide 37

Slide 37 text

Pro •overview by methodical assessment •objective priorities •balance between strategy and tactic aim42

Slide 38

Slide 38 text

Our status: LARGE number of problems

Slide 39

Slide 39 text

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!

Slide 40

Slide 40 text

Pro •overview by methodical assessment •objective priorities •balance between strategy and tactic aim42

Slide 41

Slide 41 text

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!

Slide 42

Slide 42 text

Proposal: Map problems to money

Slide 43

Slide 43 text

prioritize / estimate problems roughly estimate... trivial problems

Slide 44

Slide 44 text

Issue Cost Improvement Cost > Only change something if problem is more expensive than its solution

Slide 45

Slide 45 text

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?

Slide 46

Slide 46 text

Pro •overview by methodical assessment •objective priorities •balance between strategy and tactic aim42

Slide 47

Slide 47 text

Verbesserung mit Tagesgeschäft day-to-day development Practices Practices time Approaches Practices Practices Practices Practices Scheduling Improvements

Slide 48

Slide 48 text

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

Slide 49

Slide 49 text

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“

Slide 50

Slide 50 text

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

Slide 51

Slide 51 text

Change by Switch („Strangulizer“) Original by Paul Hammant: http://paulhammant.com/2013/07/14/legacy-application-strangulation-case-studies/

Slide 52

Slide 52 text

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.

Slide 53

Slide 53 text

Beware of the database... it‘s usually harder to improve than the code

Slide 54

Slide 54 text

Summary e valuate analyze improve https://aim42.org 1. Identify problems 2. Prioritize 3. Change aim42

Slide 55

Slide 55 text

Thanx. Gernot Starke gernot.starke@innoq.com Twitter: @gernotstarke www.innoq.com