Desolat - Nein Danke! Langfristige Software-Evolution

Evolution und Verbesserung von Software müssen neben den Code-Umbauten im Kleinen auch das Große Ganze im Fokus halten, die langfristige Strategie:

Das sollten wir unter betriebswirtschaftlichen Aspekten tun - daher zeige ich ein paar Grundlagen von IT-Budgets und erkläre den Standpunkt betriebswirtschaftlicher Stakeholder...

In diesem Vortrag möchte ich Ihnen diese und andere
Ansätze vorstellen, damit Sie für die langfristige,
systematische Verbesserung Ihrer eigenen Systeme besser planen können.

Transcript

1. Desolat? Nein Danke! Langfris)ge So.ware-Modernisierung Dr. Gernot Starke
2. Dr. Gernot Starke innoQ Fellow +49 177 – 728 2570 gs@gernotstarke.de www.arc42.de Schwerpunkte:   Softwarearchitekturen Entwurf, Entwicklung, Evolution Modernisierung, Dokumentation   Mentoring und Coaching   Analyse und Optimierung von Entwicklungsprozessen   Reviews, Audits, Retrospektiven
3. 3 h>ps://www.flickr.com/photos/aigle_dore/5951683083 IT-Ausbildung bezüglich „Modernisierung“!
4. Die Botscha2: Prak)zieren Sie „Value-based Improvement“. Inves)eren Sie langfris)g >80% des CTS-Budgets in T1- und T3-Änderungen.
5. Der Plan... •  Normalfall •  Geld (Wert, Inves))on, Ertrag) •  IT-Budgets (Run, Change/CTS) •  Qualität (von IT-Systemen) •  Modernisierung (Evolu)on)
6. „das System...: Management: Zu teuer. Zu viele Fehler. Zu hohe Aufwände. Zu lange Time-to-Market. Techniker:--- Zu hohe technische Schuld. Zu wenig Verbesserung. Technologie zu schlecht. Zu wenig Innova)on. Zu wenig Budget. Zu wenig Zeit.
7. Der Normalfall...
8. Geld & Wert
9. Wert Ihres Systems (in €) ? InvesFFons-
10. mindestens 1.250.000 € 5 Personen arbeiten 5 Jahre ca. 50%, Personalkosten 500€/Tag, h>p://www.handelsbla>.com/infografiken/rechner-gehalts-rechner/7963754.html
11. eventuell 9.800.000 € 10 Personen arbeiten 10 Jahre ca. 70%, Personalkosten 700€/Tag
12. oder auch >50.000.000 € Erfahrungswerte bei mehreren (!!) großen Unternehmen in D, CH, AT, USA
13. Business Value: •  „Leistung“ •  Gebrauchs- oder Verkaufswert •  Führt direkt/indirekt zu Ertrag
14. Inves))on und Ertrag 1 1 Während der Entwicklung, kein Release => kein Mehrwert
15. Inves))ons-Ertrags-Hysterese 1 2 1 2 Während der Entwicklung, kein Release => kein Mehrwert Nach Release, zeitverzögerte Steigerung des Ertrages
16. Invesi)ons-Ertrags-Hysterese 1 2 3 1 2 3 Während der Entwicklung, kein Release => kein Mehrwert Nach Release, zeitverzögerte Steigerung des Ertrages Externe Faktoren beeinflussen Ertrag
17. Unternehmen müssen mehr verdienen als inves)eren langfris)g
18. Unternehmen müssen mehr verdienen als inves)eren Ertragssteigerung höher als Inves))on in Entwicklung <=> Steigerung des Business-Value höher als Inves))on
19. ?How to get more BANG for the buck? heute und morgen...
20. ?How to get more BANG for the buck? Business- Value Budget
21. IT-Budgets Run-the-Shop (RTS) Budget Change-the-Shop (CTS) Budget Hardware, Betriebssysteme, Lizenzen, Hos)ng, Kommunika)onsmi>el, Administra)on, Support Bugfixes, Patches, „Reparaturen“
22. CTS/RTS Rela)on... IT-Anwender IT-Lieferanten (Vendors) Run-the-Shop (RTS) Budget Change-the-Shop (CTS) Budget Run-the-Shop (RTS) Budget Change-the-Shop (CTS) Budget
23. Kosten versus Ertrag •  RTS: verursacht Kosten •  CTS: erbringt Ertrag Run-the-Shop (RTS) Budget Change-the-Shop (CTS) Budget
24. ?How to get more Business Value out of CTS?
25. Alltag der Entwicklung...: •  Funk)onale Erweiterungen •  Verbesserung von Laufzeiteigenscha.en –  Useability –  Performance Fix Enhance •  Fehlerbehebung •  Notwendige Updates etc.
26. IT-Budgets Run / Operate Fix Enhance Run-the-Shop (RTS) Budget Change-the-Shop (CTS) Budget
27. IT-Budgets + „innere Qualität“ Run / Operate Fix Enhance Durch innere Qualität beeinflusst Run-the-Shop (RTS) Budget Change-the-Shop (CTS) Budget
28. Zwei Grundwerte... •  Agility: Wie schnell / risikoarm können fachliche Änderungen implemen)ert werden •  Business Value: Fachliche Leistung, Gebrauchs- oder Verkaufswert
29. •  Agility: Wie schnell / risikoarm können fachliche Änderungen implemen)ert werden •  Business Value: Fachliche Leistung, Gebrauchs- oder Verkaufswert innere Qualität fachliche Leistung
30. Zwei Grundwerte: Business Value: •  „Leistung“ •  Gebrauchs- oder Verkaufswert •  Führt direkt/indirekt zu Ertrag Innere Qualität: •  Business-Anforderungen schnell, risikoarm und korrekt umsetzbar •  Know-How über Architektur und Implemen)erung explizit und replizierbar
31. Auswirkung von Änderungen
32. Typen von Änderungen •  T1: Verbesserung von Business-Value UND Verbesserung der inneren Qualität •  T2: Verbesserung von Business-Value •  T3: Verbesserung der inneren Qualität
33. wenn innere Qualität sinkt, wird (neue) fachliche Leistung teurer. Agility
34. Innere Qualität erreichen: •  Einfach •  Verständlich •  Konsistent •  Modular •  Wartbar •  Erweiterbar •  Kohäsiv •  .... 1x1 des So.ware- Engineering
35. Issue (Problem) Improvement (remedy) Cost Risk Cause cost of improvement improvement has risks or consequence improvements resolve cause (root) causes of issues cost of issue (potential) cost of risk risk might result in issue solve issue with improvement(s) improvement solves issue(s) •  Mängel innerer Qualität. •  Was hindert an Wertschöpfung?
36. ? How to get more Business Value out of CTS? erhöhe Anteil von T1- und T3 Änderungen!
37. ? How to get more Business Value out of CTS? Löse DIE Probleme, die Wertschöpfung am stärksten behindern!
39. •  rich)g: – wichFge Probleme lösen •  schlechter: – einfache Probleme lösen •  ganz schlecht: – interessante Problemlösungen umsetzen – Ak)onismus €
40. Langfris)ge Ansätze... Determine Improvement Approach Strangulate Bad Parts Big Bang (Cold Turkey) Frontend Switch Keep Data, Toss Code Managed Evolution Change Via Split Data Migration Branch by Abstraction Chicken Little Butterfly Bridge To New Town Change By Extraction Change On Copy Value-based Improvement
41. Big Bang (aka Cold Turkey) Client Code Flawed System User 1 New System Client Code User Entwickle ein neues System parallel zu Betrieb und Pflege des alten.
42. Big-Bang Vorgehen 1.  Spezifiziere neues System 2.  Entwerfe und implemen)ere neues System 3.  Nach Fer)gstellung & Abnahme werden Benutzer und Clients auf neues System umgestellt Risiken •  Spezifika)on aufgrund der Komplexität des alten Systems lücken- oder fehlerha. •  Know-How-Flucht: Demo)vierte Mitarbeiter des alten Systems •  Das neue System vermeidet zwar bekannte Fehler, enthält jedoch neue •  Business erhält lange Zeit (Jahre!) keine signifikanten neuen Features •  Schwierige, aufwändige Datenmigra)on
43. Change By Split Client Type 1 Flawed System Client Type 2 Kopiere für alle Client-Typen 1 Client Type 1 Flawed System Client Type 2 Flawed System Client Type 1 Reduced to Type 1 Client Type 2 Reduced to Type 2 Commons Reduziere und extrahiere Gemeinsamkeiten 2 Client Type 1 Reduced to Type 1 Client Type 2 Reduced to Type 2 New Commons Op)miere Gemeinsamkeiten 3
44. Change By Split (2) Client Type 1 Reduced to Type 1 Client Type 2 Reduced to Type 2 New Commons Op)miere spezifische Teilsysteme („Splits“) 4 New Type 1 System Client Type 1 Client Type 2 New Commons New Type 2 System
45. Change By Split Vorgehen 1.  Iden)fiziere mehrere Benutzergruppen (BG) 2.  Klone gesamtes System für jede BG 3.  Reduziere für jede BG, extrahiere Gemeinsamkeiten (technische Basis) 4.  Op)miere für jede BG Risiken •  Gemeinsamkeiten schwer zu isolieren •  Mehrere Teams benö)gt (1 pro Klon + Basis) Voraussetzungen •  stark unterschiedliche Benutzergruppen
46. Strangulate Bad Parts (1) Ersetze einige schlechte Teile Ersetze weitere schlechte Teile Und noch mehr... 1 2 3 Client Code Flawed System User Client Code Flawed System User better Client Code Flawed System User better Better System Client Code User Flawed Parts
47. Strangulate Bad Parts Vorgehen 1.  Ersetze im bestehenden System sukzessive einzelne Komponenten Risiken •  Nebenwirkungen innerhalb des Systems schwer zu testen •  Hohe Aufwände, um übergangsweise mit „Altlasten“ zu arbeiten Voraussetzungen •  interne Schni>stellen / Modularisierung
48. Branch-By-Abstrac)on (1) Client Code Flawed Supplier Client Code Client Code Flawed Supplier Client Code Abstraction Layer Client Code Flawed Supplier Client Code Abstraction Layer Kapsele die Interak)on mit den schlechten Teilen Lasse sämtlichen Client-Code diese Kapselung nutzen Erstelle einen besseren Supplier Client Code Flawed Supplier Client Code Abstraction Layer Abstraction Layer New Supplier 1 2 3
49. Branch-By-Abstrac)on (2) Vervollständige den Supplier, ggfs. enzerne den alten. Client Code Flawed Supplier Client Code Abstraction Layer Abstraction Layer New Supplier Client Code Flawed Supplier Client Code Abstraction Layer New Supplier 4
50. Value Based Improvement Analyze: Probleme und Lösungsvorschläge analysieren 1 Flawed System (bewertete) Probleme 1 2 3 4 (bewertete) Maßnahmen 1 2 3 4 5 6 7 2 Evaluate: Deren Kosten und Nutzen (wirtscha.lich) bewerten. Konsequenzen und Nebenwirkungen beachten!
51. Value Based Improvement (2) IMPROVE: Maßnahmen umsetzen 3 Flawed System (bewertete) Probleme 1 2 3 4 (bewertete) Maßnahmen 1 2 3 4 5 6 7 Flawed System better (bewertete) Probleme 2 3 (bewertete) Maßnahmen 2 3 6 7 5
52. Value-Based Improvement (3) Steigert kon)nuierlich Business-Value UND Agilität
53. architecture improvement method aim42.org, aim42.github.io
54. Op)onen zur Verbesserung Breites Spektrum Improve Processes Improve Code Structure Improve Crosscutting Concepts Improve Technical Infrastructure Improve Analysability & Evaluability Improve Hardware Improve Logging Improve Test Automation Measure Extract Business Domain Improve Use of Technology Introduce Better Technology Quality Driven Software Architecture Improve Supporting Software Automate Release Improve Engineering Improve Delivery Improve Operations Improve Governance Improve Flow Schedule Work Refactor Code Restructure Code Enable Team Improve Test Infrastructure
55. Improve Processes Improve Code Structure Improve Crosscutting Concepts Improve Technical Infrastructure Improve Analysability & Evaluability Improve Code Structure Introduce Interfaces Refactor Code Untangle Code Remove Nested Control Structures Deprecate Obsolete Parts Improve Responsibility Improve Code Layout Move Behavior Close To Data Split Up Oversized Parts Handle If-Else Chains Interface Segregation Anticorruption Layer Hide Unmaintainable Code Extract Reusable Component Integrate Reusable Component Remove Unused Parts Eliminate Navigation Code Toggle Feature Restructure Code Isolate Parts (Modularize) Prepare Change Break Dependencies
56. Fazit (1) Beachte wirtscha2liche Auswirkungen von Maßnahmen, nicht nur deren Kosten!
57. Fazit (2) Betrachte Probleme und Lösungsvorschläge getrennt
58. Fazit (3) Vorsicht vor Big-Bang
59. Fazit (4) Prak)ziere Value-Based Improvement. Inves)ere in T1 und T3 Änderungen.
60. Dr. Gernot Starke Gernot.Starke@innoq.com h>p://gernotstarke.de h>p://innoq.com h>ps://www.flickr.com/photos/foto_db/16000636092
61. Projekt
    42
62. Prak)sch eingesetzt... ‣  2014: – Logis)k-Konzern (Audit Online-Sales System, >1MLOC) – ERP-Hersteller (Audit und Rebuild Kernsystem, 2 MLOC) – Finanzdienstleister, Modernisierung Core, 500kLOC •  Automo)ve: „Mul)media-Framework“ •  Rail-Service „Infrastruktur“ •  Mobilfunk „Billing“ •  Airport-Opera)ons „Luggage Handling“ •  Systemso.ware für Maschinenbau / Lebensmi>elindustrie
63. Website Whitepaper
64. Code: github
65. Issues: viele...
66. Contributors... Beiträge willkommen!
67. Contribu)ons welcome •  Method guide: http://aim42.github.io – Source: h>ps://github.com/aim42/aim42 •  https://github.com/aim42/aim42/ issues •  Twi>er: @arc_improve42 •  Mailing list: aim42@lists.innoq.com