Softwarearchäologie für Softwarearchitekt:innen (Software Architecture Summit 2025 München)

Legacy-Systeme sind oft schwer zu verstehen (und noch schwerer zu modernisieren). In diesem Hands-On-Workshop tauchen wir in die Welt der Softwarearchäologie ein. Gemeinsam wenden wir Werkzeuge und Techniken auf Architektur-, Design- und Code-Ebene an, um verborgenes Wissen freizulegen und uns für anstehende Modernisierungsarbeiten besser zu orientieren.

Wir beginnen mit einer Einführung in die Softwarearchäologie, um zu verstehen, warum Legacy-Code oft so undurchdringlich ist. Mithilfe kollaborativer Ansätze wie dem „Architecture Communication Canvas“, „Risk Storming“ und der „Architecture Decision Discovery“ verschaffen wir uns einen schnellen Überblick über das Terrain, auf dem wir arbeiten. Im nächsten Schritt rekonstruieren wir verlorengegangene Design-Artefakte mit Techniken wie „Concept Maps“ und „Concept Mining“. Abschließend untersuchen wir das Softwaresystem auf Code-Ebene: Mit der „Code-Hotspot-Analyse“ und der „Code-Stability-Analyse“ nutzen wir die Entwicklungshistorie, um das System abzugrenzen und erste Modernisierungsmaßnahmen zu priorisieren.

Dieser Workshop richtet sich an Softwareentwickelnde und Modernisierungsverantwortliche, die ihre Fähigkeiten im produktiven Umgang mit Legacy-Systemen erweitern möchten.

Transcript

1. Softwarearchäologie für Softwarearchitekt:innen Markus Harrer Senior Consultant S o f t w a r e A r c h i t e c t u r e S u m m i t 2 0 2 5 , M ü n c h e n
2. Abstract 2 Legacy-Systeme sind oft schwer zu verstehen (und noch schwerer zu modernisieren). In diesem Hands-On- Workshop tauchen wir in die Welt der Softwarearchäologie ein. Gemeinsam wenden wir Werkzeuge und Techniken auf Architektur-, Design- und Code-Ebene an, um verborgenes Wissen freizulegen und uns für anstehende Modernisierungsarbeiten besser zu orientieren. Wir beginnen mit einer Einführung in die Softwarearchäologie, um zu verstehen, warum Legacy-Code oft so undurchdringlich ist. Mithilfe kollaborativer Ansätze wie dem „Architecture Communication Canvas“, „Risk Storming“ und der „Architecture Decision Discovery“ verschaffen wir uns einen schnellen Überblick über das Terrain, auf dem wir arbeiten. Im nächsten Schritt rekonstruieren wir verlorengegangene Design-Artefakte mit Techniken wie „Concept Maps“ und „Concept Mining“. Abschließend untersuchen wir das Softwaresystem auf Code-Ebene: Mit der „Code-Hotspot-Analyse“ und der „Code-Stability-Analyse“ nutzen wir die Entwicklungshistorie, um das System abzugrenzen und erste Modernisierungsmaßnahmen zu priorisieren. Dieser Workshop richtet sich an Softwareentwickelnde und Modernisierungsverantwortliche, die ihre Fähigkeiten im produktiven Umgang mit Legacy-Systemen erweitern möchten. Hinweis: Es werden Übungen mit Notebooks durchgeführt. Bitte (sofern vorhanden) ein eigenes Gerät mitbringen. Eine Installation von Software ist nicht erforderlich.
3. Markus Harrer Senior Consultant / Roth (das ist bei Nürnberg), Deutschland • Softwarearchitektur-Entwicklung und -Bewertung • Software-Modernisierung und -Rightsizing • Datenanalysen in der Softwareentwicklung Foundation & IMPROVE https://softwareanalytics.de https://feststelltaste.de/ Instructor inkl. Lehrplan https://markusharrer.de/ "Weniger wahn- sinnig Software entwickeln!”
4. Die „Legacy Systems“ Welt 4 Eine kuratierte Liste mit brauchbaren Informationen https://github.com/feststelltaste/awesome-legacy-systems
5. 5 Legacy Systeme?
6. https://www.flickr.com/photos/spongebabyalwaysfull/20782138502/in/photolist-xErTJN-bhpoWe-wJgkR5 6 Täglich neue Herausforderungen
7. Wichtige Arbeit https://www.flickr.com/photos/149368236@N06/33882279845/ 7
8. Beharrlichkeit und Genauigkeit https://www.flickr.com/photos/jimoftheday/2537608919/
9. Spaß mit neuen Werkzeugen https://www.flickr.com/photos/charles_hudson/5815634885/
10. https://pixabay.com/de/photos/geld-euro-geldscheine-w%C3%A4hrung-1033647/ Bezahlt halt mein Gehalt
11. 11 Wie ist eure Einstellung zu Legacy Systemen?
12. Definition „Legacy“ 12 „Etwas, das dir vermacht wurde und für jemanden wertvoll ist.“ OORP1 1 Object-Oriented Reengineering Patterns — A pattern-based approach to re-engineer object- oriented legacy systems. Frei verfügbares Buch unter http://scg.unibe.ch/download/oorp/ .
13. 13 Softwarearchäologie Really?
14. 14 “Legacy code is code without communication artifacts.” - Andrea Goulet Portrait taken from https://andreagoulet.com/
15. Aus einem KI-generierten Podcast 15 „Bei Legacy-Systemen geht es nicht nur um den Code. Du liest den Denkprozess von jemand anderem, ihren Ansatz, ein Problem auf eine bestimmte Weise zu lösen; aus einer anderen Zeit und Epoche. Ein bisschen wie archäologische Ausgrabungen, nur ür Software.“
17. „Archäologen versuchen, die Hinterlassenschaften der Leute zu finden, die vor uns waren, und den Sinn dahinter zu verstehen.“ übersetzt aus „Archaeology at work“, English Heritage Education Service https://upload.wikimedia.org/wikipedia/commons/3/3d/Indianajones4.jpg 100% Archäologie! 17
18. Softwarearchäologie 18 “Umfasst das Reverse Engineering von Softwaremodulen sowie die Anwendung einer Vielzahl von Tools und Prozessen zur Extraktion und zum Verständnis der Programm- struktur und zur Wiederherstellung von Designinformationen.“ Frei übersetzt von Wikipedia See also http://aim42.github.io/#Software-Archeology
19. Unsere heutige Agenda 19 Effektiv herausfinden, wie ein Softwaresystem tickt, mit mehreren Rediscovery Techniken auf den Ebenen Architektur Code Design
20. 20 Architektur-Ebene
21. Wie tickt eigentlich das Umfeld? 21 Michael Keeling: Design It! Firma Spaß & Gewinn! Hardware Anwender verwenden wollen will Team hilft wählt Software entwickelt läuft auf leitet an Software lebt immer in einem Systemkontext!
22. Was gehört zur Kultur einer Firma? 22 Beispiele Werte und Normen Kommunikationskultur Fehlerkultur Entscheidungskultur Zusammenarbeit Innovationskultur Umgang mit Risiken Lern- und Weiterentwicklungskultur Anerkennung und Wertschätzung Work-Life-Balance
23. Architecture Communication Canvas https://canvas.arc42.org/architecture-communication-canvas MaMa is a multi-tenant SAAS platform to produce e-health cards for insurance companies, providing maximum flexibility with data formats and business rules. • create eHealth cards • get photo from insured person • 2nd Level support for eHealth data acquisition process Health insurance companies (mandators) Government regulation body (Gematik GmbH), Rentenversicherung Bund, Print and scan service provider, card issuer, TÜV (auditor), BSI (auditor) • The system must ensure confidentiality and integrity of tenant-specific data. #security • The system must ensure timely processing of all input data. #performance • Eclipse RCP frontend • JBoss Drools rule engine • Quartz scheduler • Oracle DB • Dedicated server • Linux KVM hypervisor • Configurator • ImportHandler • ExportHandler • ProcessControl • Reporting • OperationsMonitoring • Old-fashioned UI (with Eclipse RCP) • Batch strategy limits acceptance • No end-user self service options + operate MaMa as SAAS + domain-specific configuration + one tenant per VM - batch only data transfer MaMa CRM Risk Storming Architecture Decision Discovery Warum? Wozu? Mit Leuten quatschen (oder Doku durchstöbern)
24. Dokumentation durchstöbern 24 Mögliche Quellen • Projekt-Wiki • README & Repos • Architektur-Dokumente (insb. ADRs, Diagramme) • Anforderungsdokumente (Lasten-/Pflichtenheft) • API-Dokumentation (Swagger) • Release Notes & Change-Logs • Produktseiten / Pressemitteilungen / Flyers Einen schnellen, gezielten Überflug über vorhandene Dokumentation vornehmen für ein erstes Kennenlernen und um einzuschätzen, welche Teile für ein Reengineering-Projekt nützlich sein könnten. https://oorp.github.io/#skim-the-documentation
25. Architecture Decision Discovery 25 1. Scope festlegen • Was analysieren wir und was nicht mehr? Was war schon gesetzt? 2. Technologien und Ansätze sammeln • Welche Technologien und Lösungsstrategien gibt es? 3. Fragen und Hypothesen formulieren • Warum wurde das so gemacht? Was war die damalige Situation / Kenntnisstand? Was war bereits vorgegeben? 4. Gemeinsame Diskussion und Erarbeitung von ADRs • Niederschreiben von ADRs mit den gesammelten Informationen
26. ADD in Action Welche Ent- scheidungen seht ihr hier? package org.springframework.samples.petclinic.owner; import org.springframework.stereotype.Controller; import org.springframework.ui.ModelMap; import org.springframework.util.StringUtils; import org.springframework.validation.BindingResult; import org.springframework.web.bind.WebDataBinder; import org.springframework.web.bind.annotation.*; import javax.validation.Valid; import java.util.Collection; /** * @author Juergen Hoeller * @author Ken Krebs * @author Arjen Poutsma */ @Controller @RequestMapping("/owners/{ownerId}") class PetController { private static final String FORM = "pets/createOrUpdatePetForm"; private final PetRepository pets; private final OwnerRepository owners; public PetController(PetRepository pets, OwnerRepository owners) { this.pets = pets; this.owners = owners; ...
27. Architecture Decision Record (ADR) 27 Entwurfsentscheidungen nachvollziehbar dokumentieren • Titel: Um welche Entscheidung geht es? • Kontext: Was waren die Rahmenbedingungen? • Entscheidung: Was war die Entscheidung, was waren die Alternativen? • Status: Wie steht es um das ADR? • hier auch abgelehnte oder überholte ADRs aufführen • Konsequenzen: Mit welchen Vor- und Nachteilen wollen wir jetzt leben? Beispiele unter https://github.com/arachne-framework/architecture
28. Beispiel ADR (skizziert) 28 Titel: Einsatz von Ping-Mechanismen • Kontext: Beteiligte Systeme müssen während der Tagesend- verarbeitung der Kontotransaktionen müssen verfügbar sein. • Entscheidung: Wir setzen die Architekturtaktik „Ping“ ein, um die Bereitschaft der Systeme während der Tagesendverarbeitung vor der Nutzung zu kontrollieren. Die Alternative eines „Heartbeats“ schlossen wir aus, da wir dies derzeit für zu komplex für unsere Anwendung halten. • Status: Beschlossen • Konsequenzen: • Alle Systeme implementieren Ping-Mechanismen in den Systemen • Risiko „Ping Flooding“ durch bösartige Systeme oder Unachtsamkeit • Nachteile „Performance-Overhead“ und „weniger einfache Tests“
29. Risk Storming 29 1. Komponentenüberblic k gemeinsam zeichnen 2. Risiken in Einzelarbeit identifizieren 3. Risiken im Kompo- nentenüberblick zusammenführen 4. Diskussion und Priorisierung Format & Grafik von Simon Brown (https://c4model.com) https://riskstorming.com/
30. Hands-On 30 Architecture Communication Canvas Architecture Decision Discovery Risk Storming
31. 31 Code-Ebene
32. Schnellüberflug über den Quellcode 32 „Read all the Code in One Hour“* zum Start In einer initialen Bestandsaufnahme geht es um einen ersten Eindruck (und ob System überhaupt noch zu retten ist), daher • UI walkthrough: Fachlich wichtige Use Cases in der Applikation zeigen lassen • Code walkthrough: Haupt-Use-Cases „hinter den Kulissen“ im Code ansehen („technischer Durchstich“) • Comprehension test: Beim Durchgehen den Quellcode vor allem auf Konsistenz und Verständlichkeit prüfen *adaptiert von Object-Oriented Reengineering Patterns
33. Code-(Z|D)oom-Scrolling 33 • Sämtlichen Code in eine Datei packen* • Mit Editor grob durchscrollen ✓ Erster Überblick über besonders interessante Stellen ✓ Gibt ein generell ein Gefühl über den aktuellen Zustand der Codebasis *Beispielskript für bash (packt auch noch die Dateinamen mit rein): find . -type f -name "*.java" -exec sh -c 'echo "\n--- File: $1 ---\n" >> combined.txt; cat "$1" >> combined.txt' sh {} \;
34. Größere Codebasen erschließen 34 Tool: CodeCharta • Kommandozeilen-Tool zur Generierung von Visualisierungsdaten aus den Ausgaben von Analysetools • Visualisierung von Softwarekomponenten und Messungen als 3D-Treemaps ("Code Cities") https://maibornwolff.github.io/codecharta/
35. Priorisierung mit Softwarehistorie 35 Tool: CodeScene • Bietet historische und evolutionäre Code-Analysen unter Verwendung von Versionskontrollsystemen • Analysiert Teamstrukturen und die Arbeitsweise von Organisationen • Bietet Übersicht über die Art der vorgenommenen Arbeiten, Anzahl der Fehlerbehebungen und vieles mehr https://codescene.com/
36. Luftaufnahmen von Codebasen Hot Spot Analysis Komplexen Code erkennen, der sich häufig ändert Bild aus “Adam Tornhill: Your Code as a Crime Scene” adaptiert 36
37. Hotspot Analysis im Detail 37 „In welche Code-Teile vertiefen?“
38. Hands-On 38 Source-Code-Analyse mit CodeCharta Source-Code-Analyse mit CodeScene
39. Tiefergehende Analysen mit Software Analytics 39 „Software Analytics ist die Analyse von Softwaredaten für das Management und Softwareentwickelnde mit dem Ziel, es allen an der Softwareentwicklung beteiligten Einzelpersonen und Teams zu ermöglichen neue Erkenntnisse aus ihren Daten zu erhalten, um bessere Entscheidungen zu treffen.“ Tim Menzies und Thomas Zimmermann
40. Beispiel: Code Stability Analysis 40 „Welche Teile des Systems muss ich zuerst kennenlernen?“ #commits #commits time time Stable source ile Unstable source file
41. 41 Stable source file Unstable source file Now stable source file Now stable source file
42. Bevor wir weiterziehen … 42 Auch sinnvoll auf Code-Ebene sind etwa → Characterization Tests https://oorp.github.io/#write-tests-to-understand → Scratch Refactorings https://oorp.github.io/#refactor-to-understand → Exceptions analysieren https://oorp.github.io/#study-the-exceptional-entities
43. 43 Design-Ebene
44. Über das Design spekulieren 44 Unser Fokus - Business Objects (business concepts) - Technical Patterns (technical concepts) https://oorp.github.io/#speculate-about-design
45. DataEntryServlet (3906 SLOC) OdmExtractDAO (3218 SLOC) SpreadSheetTableRepeating (1893 SLOC) EntityDAO (1809 SLOC) DiscrepancyNoteDAO (1708 SLOC) ExtractBean (1677 SLOC) Validator (1359 SLOC) SpreadSheetTableClassic (1358 SLOC) MetaDataReportBean (1305 SLOC) Validator (1241 SLOC) ExpressionService (1207 SLOC) ListStudySubjectTableFactory (1197 SLOC) ListDiscNotesSubjectTableFactory (1061 SLOC) ListDiscNotesForCRFTableFactory (986 SLOC) StudySubjectDAO (981 SLOC) DynamicsMetadataService (920 SLOC) ListEventsForSubjectTableFactory (919 SLOC) SystemController (899 SLOC) FormBeanUtil (881 SLOC) StudyEventDAO (876 SLOC) Grundproblem 1: Masse an Code 45 Ziel: Code in handhabbare Stücke („Chunks“) überführen „Ein intelligenter Entwickler ist nach meiner Erfahrung bei einer Änderung in der Lage, ca. 30.000 Zeilen [Java-]Code zu überblicken und die Auswirkungen seiner Änderung an einer Stelle in den anderen Teilen des Codes vorauszuahnen.“ Carola Lilienthal* * in Carola Lilienthal: Langlebige Software-Architekturen Die ersten 20 Java-Dateien mit ca. 30.000 Zeilen Code des Projekts „OpenClinica“ Aber was ist mit den anderen 1323 Java-Dateien (146960 SLOC)?
46. Dreisatz der konzeptionellen Integrität 46 Stereotyp (Name(nsanteil)) Konzept (gedankliche Vorstellung) Implementierung (Code) benennen setzt um eineindeutig eineindeutig
47. Business Concept Rediscovery in Spring PetClinicmitConcept Map 47 . ├── model │ ├── Owner.java │ ├── Person.java │ ├── Pet.java │ ├── Specialty.java │ ├── Vet.java │ └── Visit.java ├── repository │ ├── OwnerRepository.java │ ├── PetRepository.java │ ├── VetRepository.java │ └── VisitRepository.java └── web ├── OwnerController.java ├── PetController.java ├── PetValidator.java ├── VetController.java └── VisitController.java
48. Technical Concept Rediscovery in Spring PetClinic 48 . ├── model │ ├── Owner.java │ ├── Person.java │ ├── Pet.java │ ├── Specialty.java │ ├── Vet.java │ └── Visit.java ├── repository │ ├── OwnerRepository.java │ ├── PetRepository.java │ ├── VetRepository.java │ └── VisitRepository.java └── web ├── OwnerController.java ├── PetController.java ├── PetValidator.java ├── VetController.java └── VisitController.java Repository repository/*Repository.java Abstracts data access by encapsulating the logic needed to retrieve, store, and query data. public interface OwnerRepository { Collection<Owner> findByLastName(String lastName) throws DataAccessException; Owner findById(int id) throws DataAccessException; ... public interface PetRepository { List<PetType> findPetTypes() throws DataAccessException; Pet findById(int id) throws DataAccessException; ... Codeteile zu bekannten Konzepten zuordnen und dokumentieren
49. Grundproblem 2: Mehrdeutigkeiten 49 Späteres Ziel: Integrität von Konzepten wiederherstellen Natural Language Code one thing many names many things one name one thing one concept synonymy polysemy / homonymy DataAccess Repository EntityHandler Client Order Entity = = ≠ ≠ ≠ integrity Customer procurement.Order data.*Entity = stored as takes
50. Hands-On 50 Concept Mas auf Basis der Fachlichkeit Concept Maps auf Basis von Code Concept Rediscovery auf Basis von Code-Strukturen
51. Mögliche Lösungen: Business 51
52. Mögliche Lösungen: Technical 52 Java Beans **/bean/**/*.java Domain objects are organized as Java beans with structured hierarchies and packages based on function (admin, core, extract, login, etc.). Data Access Object **/dao/**/*.java Data Access Objects pattern for database interaction, with XML configurations for DAO definitions and separate implementations for different databases. Audit Logging **/audit/**/*.java, **/jsp/admin/audit*.jsp Comprehensive audit trail system tracking all data changes with user, timestamp, and action information. Rules Engine **/rules/**/*.java, **/rules*.xml Framework for defining and executing validation rules on clinical data.
53. LLM-Prompt für Concept Mining 53 Create an overview of the technical concepts used in this application. To do this, look at the source code file paths for the source code files, and provide a list with the title of each concept, the pattern of similar files using the glob format, and a brief description of each concept. Identify as many technical concepts as possible based on the file names, so that I can have an inventory of the technical concepts that are part of this codebase. Do not include concepts that are related to the domain or business logic. Don’t be lazy!
54. Aktuelles Design rekonstruieren 54 Vorrausetzungen • Es gibt etwas, was man „Struktur“ nennen kann • Module, Pakete, Namespaces, Verzeichnisse, … • Es wurde sich grundsätzlich über die verwendeten Konzepte im Code Gedanken gemacht • Muster, Design-Taktiken, Ansätze, … →Vorhergehende Schritte haben uns das im besten Fall gezeigt!
55. Architekturkonformitätsanalyse 55 Zuordnung von Softwareelementen zu Konzepten im Code mit Architekturmanagementwerkzeugen • Überblick über die realen Abhängigkeitsverhältnisse innerhalb der Software schaffen • Konkrete Handlungsempfehlungen zur Wiederherstellung der IST- Architektur gemäß dem SOLL erarbeiten • Nebenbei eine Übersicht über die Bausteine und Konzepte der Software in Form von Quellcode-Inventarlisten • https://dzone.com/articles/a-code-inventory-for-legacy-systems
56. Architektur(en) rekonstruieren 56 Große Lücke zwischen aktuellen Ist und damaligen Soll Bestehende Codebasis Entwickler Architekten 2) Geht nicht, weil Probleme X,Y,Z! 1) Lösung A, B, C! Architektur- modell (Soll)
57. Aktuelle Architektur(en) rekonstruieren 57 Gemeinsame Diskussionsgrundlage ür Modernisierung schaffen Bestehende Codebasis Entwickler Architekten Architektur- modell (Soll) Gap Analyse
58. 58 Aktuelle Architektur(en) rekonstruieren Ausblick: Rearchitecting auf Basis der notwendigen Todos Bestehende Codebasis Architektur- modell (Ist) Architektur- modell (Soll) Restrukturierte Codebasis 1) Reverse Engineering 2) Restrukturierung 3) Forward Engineering analysieren abstrahieren verbessern? umstellen Vorgehen nach dem Horseshoe Process Model
59. Architekturkonformitätsanalyse 59 Beispiel Sonargraph, Bild von http://www.hello2morrow.com/products/sonargraph/architect9 Tool: Sonargraph
60. Prüfung von Konzepten im Detail 60 Exploratives Untersuchen von Bezeichnern/Stereotypen in der Codebasis mit folgenden Prüfungen: • Existenz: Wird das Mittel von Namensschemata / Stereotypen im Code verwendet? • Konsistenz: Werden die gleichen Stereotypen für gleichartige Konzepte verwendet? • Integrität: Sind gleichartige Konzepte auch gleichartig implementiert?
61. Demo 61 Architekturkonformitätsanalyse
62. 62 Unser Ergebnis (Besser) verstandene Codebasis, auf die man sich auch verlassen kann
63. 63 Mehr zum Thema Softwarearchäologie
64. Mehr zum Thema 64 Sammlung über das Thema: https://github.com/feststelltaste/awesome-software-analytics
65. Microsite über Software Analytics softwareanalytics.de 65
66. Meine Sammlung 66 Eine kuratierte Liste mit brauchbaren Informationen https://github.com/feststelltaste/awesome-legacy-systems
67. Fragen 67 Welche Fragen gibt es noch zum Training?
68. INNOQ Deutschland Gegründet Mitarbeitende Kunden Jahresumsatz 2022 1999 150+ 300+ ~22 Mio. Kunden Finance | Telko | Logistik | E-Commerce | Fortune 500 | KMU | Start-ups