Refactor, Rearchitect, Rebuild - Was macht man wann? (v1) 🇩🇪 @DevLand 2026

Präsentiert auf der DevLand 2026

---

Viele Wege führen zur Modernisierung von Software – doch welche Strategie ist wann sinnvoll? "Refactor, Rearchitect, Rebuild" und ihre Verwandten sind Schlagworte, aber hinter jedem Ansatz stehen unterschiedliche Voraussetzungen und Ziele. In diesem Vortrag beleuchten wir, wie man den richtigen Zeitpunkt für die Erneuerung erkennt und mit welchen Methoden sich der aktuelle Zustand des Systems präzise erfassen lässt. Erst auf dieser Basis kann beurteilt werden, welche Modernisierungsstrategie – von gezielten Refactorings bis zum vollständigen Rebuild – am besten zum individuellen System und den zukünftigen Anforderungen passt.

Wir diskutieren praxisnah:

* Woran wir sehen, dass Technik und Fachlichkeit sich nicht gleichmäßig entwickelt haben und wir modernisieren müssen
* Wie wir den Fortschritt und Erfolg der Modernisierung messen
* Welche Praktiken wir einsetzen für eine nachhaltige Modernisierung - und noch mehr - welche Prinzipien wir im Team etablieren damit wir Erfolg haben

Transcript

1. 13.03.26 Richard Gross (er/ihm) Refactor, Rearchitect, Rebuild Was macht man wann? Archäologie Modernisierung Hypermedia richargh.de/ richargh.de in/richargh
2. Refactor, Rearchitect, Rebuild, … Typisches Cloud Begriffe Slide 3 CC BY-SA richargh.de
3. Bei den R’s exisitiert ein gewisser Konsens Slide 4 CC BY-SA richargh.de Rebuild Rehost Replatform Refactor / Rearchitect Rebuild 6 Optionen Retire Retain Repurchase 8 Optionen Retire Retain Replace Rehost Replatform Refactor Rearchitect Rehost Replatform Refactor Re-architect 6 Optionen Repurchase Wegwerfen, Unverändert behalten, Ersetzen durch Produkt Kaum, wenig, viel, alles verändern
4. Refactor oder Rearchitect? Ein Versuch der Begriffsdefinition Slide 5 CC BY-SA richargh.de
5. Refactoring Struktur verändern ohne Verhalten zu ändern1 Slide 6 CC BY-SA richargh.de 1 https://martinfowler.com/books/refactoring.html
6. Es geht hier um Qualitätskriterien1 Slide 7 CC BY-SA richargh.de 1 https://quality.arc42.org/ Efficient Flexible Usable Suitable Secure Safe Reliable Operable Maintainable Refactoring Rearchitecting (mit Verhaltensänderung)
7. Refactoring: Klare Microstrukturen Slide 8 CC BY-SA richargh.de Mikro-Architektur: Eintscheidungen die individuell pro Modul treffbar sind https://isa-principles.org/ Presentation Infrastructure Domain Presentation Infrastructure Domain PreDoInf Refactoring
8. Rearchitecting: Veränderung der Makrocharakteristika Slide 9 CC BY-SA richargh.de Makro-Architektur: Entscheidungen die Modulübergreifend sind https://isa-principles.org/ Blocking Presentation (Json, Html, …) Database Domain Rearchitecting Database Domain Blocking Presentation (Json, Html, …) Messages Non-Blocking Presentation (MQTT, Atom, …) 3rd Party Clients
9. Refactor, Rearchitect, Rebuild, … Nicht nur relevant für die Cloud Slide 10 CC BY-SA richargh.de
10. Modernisierung, (a) entweder für weniger Total Cost of Ownership Slide 11 CC BY-SA richargh.de * Relativ zu z.B. Anzahl Anwender/Tag oder Anfragen/Tag Betrieb (u.a. Ressourcen, Skalierungskosten, Ausfallzeiten) Wartung (u.a. Sicherheit, Bugs, Updates) Zeitaum: 5-10 Jahre Modernisierung € Betrieb + Wartung (Relativ*) € € Betrieb + Wartung (Relativ*)
11. Oder (b) für Optionen, wo vorher keine waren Slide 12 CC BY-SA richargh.de Modernisierung € Frage: Gibt es einen Weg das ins System einzubauen? Egal wie, Nein So, So, Oder so
12. Die R’s geben eine grobe Kosten-Nutzen- Indikation Slide 14 CC BY-SA richargh.de Zeit & Aufwand Rehost Relative Kosten Betrieb + Wartung Replatform Refactor Rearchitect Rebuild Anzahl Optionen
13. Was macht man jetzt wann? Wie bekommen wir unsere Handlungsempfehlungen? Slide 15 CC BY-SA richargh.de
14. Zuerst mappen1 wir unser System Slide 16 CC BY-SA richargh.de 1 Aus der Sicht des Anwenders https://www.swardleymaps.com/ Evolution Genesis Custom Product Commodity (+utility) Wertschöpfungs- kette Sichtbar Unsichtbar Neue Konzepte Wenig Wissen Sehr Viel Veränderung Competitive Adv.: Neuheit Für bestimmte Kunden gebaut Etwas mehr Wissen Viel Veränderung Competitive Adv.: Umsetzung Standardisiert Gut Verstanden Stabilisiert langsam Comp. Adv.: Features/Brand Komplett Standardisiert Sehr gut Verstanden Stabilisiert Comp. Adv.: Cost/Effiency Pay-per-use Kühlschrank E-Mails Strom
15. Wir mappen System und Abhängigkeiten Slide 17 CC BY-SA richargh.de Evolution Genesis Custom Product Commodity (+utility) Wertschöpfungs- kette Sichtbar Unsichtbar Kunde Hauptsystem Anwendungsfall Datenspeichersystem* Suchsystem System 3 System 2 System4 Selbstgebautes System
16. Wir mappen die Core Domains Slide 18 CC BY-SA richargh.de Siehe auch https://github.com/ddd-crew/core-domain-charts Evolution Genesis Custom Product Commodity (+utility) Wertschöpfungs- kette Sichtbar Unsichtbar Kunde Hauptsystem Anwendungsfall Datenspeichersystem* Suchsystem System 3 System 2 System4 Selbstgebautes System Core Domain Supporting Domain Generic Domain
17. Core Domains können auch in (sichtbarer) Commodity liegen Slide 19 CC BY-SA richargh.de Evolution Genesis Custom Product Commodity (+utility) Wertschöpfungs- kette Sichtbar Unsichtbar Kühlschrank, Spülmaschine, … Selbstgebautes Product Core Domain E-Mails Proton Mail Hey …
18. Aus der Map ergibt sich dann Slide 20 CC BY-SA richargh.de Die Sicht des Kunden einnehmen. Wie sichtbar seid ihr aus Sicht eurer Kunden? Evolution Genesis Custom Product Commodity (+utility) Wertschöpfungs- kette Sichtbar Unsichtbar Schnelle Innovation, Braucht viele Optionen Kosten reduzieren
19. Wir mappen System und Abhängigkeiten Slide 21 CC BY-SA richargh.de Eine Wardley Map https://www.swardleymaps.com/ Evolution Genesis Custom Product Commodity (+utility) Wertschöpfungs- kette Sichtbar Unsichtbar Kunde Hauptsystem Anwendungsfall Datenspeichersystem* Suchsystem* System 3 System 2 System4 MAKE BUY COTS* Outsource zum Supplier Selbstgebaute Systeme
20. Daraus ergibt sich was grob zu tun ist Slide 22 CC BY-SA richargh.de Eine Wardley Map https://www.swardleymaps.com/ Evolution Genesis Custom Product Commodity (+utility) Wertschöpfungs- kette Sichtbar Unsichtbar Kunde Hauptsystem Anwendungsfall Datenspeichersystem Suchsystem System 3 System 2 System4 Refactor, Rearch, Rebuild Verändern Retire, Repurchase Wegwerfen/ Ersetzen Selbstgebaute Systeme
21. Doch wie verändern wir jetzt diese Systeme? Slide 23 CC BY-SA richargh.de Eine Wardley Map https://www.swardleymaps.com/ Evolution Genesis Custom Product Commodity (+utility) Wertschöpfungs- kette Sichtbar Unsichtbar Hauptsystem System 3 System 2 Refactor, Rearch, Rebuild Selbstgebaute Systeme Verändern
22. Dazu müssen wir wissen wie es um das System steht Slide 24 CC BY-SA richargh.de Basierend auf Quasar Enterprise, 2008 Technik, Architektur und Systemhygiene Business value / Fachlichkeit Wartungshölle Eingeschränkte Wartbarkeit Idealer Korridor für Weiterentwicklung Over-engineering ? ? ? ?
23. Software Health Check durch 5 Sichten Slide 25 CC BY-SA richargh.de Software Anforderungen Fachlichkeit Entwicklungsprozess Technik/Architektur Betrieb/DevOps Team
24. U.a. hat das Team genug Wissen, um 80% des Systems neuzubauen, falls nötig? Slide 26 CC BY-SA richargh.de Software Fachlichkeit Team
25. Wie steht es um das eigentliche System? Slide 27 CC BY-SA richargh.de Software Technik/Architektur Team
26. Wir visualisieren das System als Stadt Slide 28 CC BY-SA richargh.de Mit https://codecharta.com/ SomeService.java z.B. Häufigkeit der Änderung [Täglich, Wöchentlich, Monatlich] Zykl. Komplexität Lines of Code
27. Wo ist die meiste Komplexität? Lines of Code Zykl. Komplexität Änderungshäufigkeit (Täglich, Wöchentlich, Monatlich) Visualisiert mit https://codecharta.com/ Component3 Component2 Component1 Component4 Component5 Slide 29 CC BY-SA richargh.de
28. Gibt es Wissenssilos? Visualisiert mit https://codecharta.com/ Lines of Code Zykl. Komplexität Anzahl Autoren [1, 2, 3+] Slide 30 CC BY-SA richargh.de
29. U.v.m. Slide 31 CC BY-SA richargh.de Temporale Kopplung Veränderungen Coverage Verwobenheit
30. Damit kennen wir den Zustand von Komponenten Slide 32 CC BY-SA richargh.de Online-push ordering
31. Software is Fraktal Slide 33 CC BY-SA richargh.de Landschaft System System System SubSystem SubSystem SubSystem SubSystem Komponente SubSystem Komponente Komponente Komponente Komponente Komponente Komponente
32. Die einzelnen Komponenten können wir auch mappen Differenziert entscheiden, nicht alles gleich behandeln Slide 34 CC BY-SA richargh.de
33. Mappen der Core Domain Components mit fachlichem Wissen des Teams Slide 35 CC BY-SA richargh.de * Statt Werstchöpfungskette. Evolution Genesis Custom Product Commodity (+utility) Fachliches Wissen*, Größe, Verwobenheit der Core Component Hoch Gering
34. Mögliches Vorgehen an Wissen ausrichten (Core Domain Components) Slide 36 CC BY-SA richargh.de * Statt Werstchöpfungskette. Evolution Genesis Custom Product Commodity (+utility) Hoch Gering Refactor nötig zum lernen Manchmal rearchitecture zum Vertrauen aufbauen Rebuild möglich Änderungen oft nötig Änderungen seltener nötig Umfang des Vorgehens an erwarteter Änderungs- häufigkeit ausrichten Fachliches Wissen*, Größe, Verwobenheit der Core Component
35. Vorgehen mit Component Health abgleichen Slide 37 CC BY-SA richargh.de * Statt Werstchöpfungskette. Neben dem fachlichen Wissen gibt es natürlich noch den Business-Wert/USP, Komplexität, Risiko und Kosten der Komponente. Diese bespricht man am besten im Dialog. Evolution Genesis Custom Product Commodity (+utility) Hoch Gering Core Component à Refactor to Rearchitect Sup. Component à Refactor Sup. Component à Rebuild Komponente: - Wartungshölle - Eingeschränkt - Idealer Korridor Selbstgebaute Systeme Rehost, …, Rebuild Core Domain Supporting Domain Generic Domain Core Component à Retain ist auch möglich Fachliches Wissen*, Größe, Verwobenheit der Core Component
36. Von Unten nach oben Feedback einarbeiten Slide 38 CC BY-SA richargh.de Landschaft Core System Sup. System Sup. System SubSystem SubSystem SubSystem SubSystem Komponente SubSystem Komponente Komponente Komponente Komponente Komponente Komponente Check health
37. Daraus ergibt sich ob und wie wir die Systeme verändern. Slide 39 CC BY-SA richargh.de Eine Wardley Map https://www.swardleymaps.com/ Evolution Genesis Custom Product Commodity (+utility) Wertschöpfungs- kette Sichtbar Unsichtbar Hauptsystem System 3 System 2 Refactor, Rearch, Rebuild Selbstgebaute Systeme Verändern à C.1 Rearchitect à C.2 Rebuild à C.3 Refactor à C.4 Retain à C.1 Rearchitect à Sys. Rebuild C. = Component Sys = System
38. Refactor, Rearchitect, Rebuild Durch mappen zu einer strategisch begründbaren Entscheidung Slide 40 CC BY-SA richargh.de
39. Slide 41 CC BY-SA richargh.de Mehr übers Code Mappen https://javapro.io/2025/10/21/map-your-code-master-your-architecture/
40. Slide 42 CC BY-SA richargh.de Fragen? richargh.de Richard Gross (he/him) Software Archaeology Hypermedia Modernisation Works for maibornwolff.de/ richargh.de richargh https://content.maibornwolff.de/meetings/richard-gross Trink ein (virtuelles) Heißgetränk mit mir.
41. Appendix Great that you are still reading J Slide 43 by richargh.de from
42. The True Cost of Feature-based Rewrites Original Article by Doug Bradbury The True Cost of Rewrites Features Releases over time Catch Up Missing Features Sub-Par Parity Enhancements Planned Rewrite Actual Features Undiscovered Scope Old App Adoption Slide 44 CC BY-SA richargh.de
43. Slide 45 CC BY-SA richargh.de G e n e r i c High High Model Complexity Low Business Differentiation Low Supporting Core Make Buy
44. Slide 46 CC BY-SA richargh.de Architect Build Map Adjust
45. A certain consensus exists Slide 47 CC BY-SA richargh.de Gartner (2011) https://www.gartner.com/en/documents/1485116 AWS (2016) https://aws.amazon.com/blogs/enterprise-strategy/6-strategies-for-migrating-applications-to-the-cloud/ Azure https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/plan/select-cloud-migration-strategy GCP https://cloud.google.com/architecture/migration-to-gcp-getting-started 8 choices Retire Retain Replace Rehost Replatform Refactor Rearchitect Rebuild 6 choices Retire Retain Repurchase Rehost Replatform Refactor / Rearchitect 6 choices Repurchase Rehost Replatform Refactor Re-architect Rebuild Turn off what is no longer useful (10%) Do nothing for now Use a different product (Saas) VMs: Move to cloud without optimization Managed Services and/or containers Optimize: Take advantage of cloud Split: Also turn monolith to microservices As a fully cloud-optimized app