In diesem Vortrag stellt Hendrik Lösch seine Erkenntnisse aus der Restrukturierung einer industriellen Großapplikation vor und zieht ein Zwischenfazit. Damit soll den Zuschauern ein Bild von den Punkten vermittelt werden, auf die bei einem solchen Vorhaben besonders zu achten ist.

1. Restrukturierung einer industriellen Großapplikation
18 Monate und kein Ende in Sicht
Hendrik Lösch

2. Sprecher
5. April 2022
ZEISS Seite 2
Hendrik Lösch
Management Consultant
@HerrLoesch
hendrik.loesch@zeiss.com
hendrik-loesch.de
slideshare.net/HendrikLsch1
https://www.linkedin.com/learning/instructors/hendrik-losch

3. Basierend auf einem echten Projekt
Das Szenario

4. Szenario
5. April 2022
ZEISS Seite 4
Rahmendaten
 Halbleiterfertigung
 >30 Entwickler
 15 bis 20 Jahre in der Entwicklung
 Ansteuerung von >200 verschiedenen
Hardwarekomponenten
 >25 verschiedene Installationen
 Fast alle Tätigkeiten remote
Bildquelle: https://www.asml.com/en/news/media-library
Beispielbild!
Dies ist nicht das betrachtete System!

5. Szenario
Gegenstand der Restrukturierung
5. April 2022
ZEISS Seite 5
Client Software
 3 Arbeitsmodi
 Manuell
 Teilautomatisiert
 Vollautomatisiert
 > eine Millionen Zeilen Code
 .NET basiert
 Umfassende Migration notwendig
(Halb)automatischer
Workflow bzw.
Prozess Parameter
Details
MenuBar
Globale
Statusinformationen Lokale Statusinformationen

6. Szenario
Bisheriger Projektablauf
5. April 2022
ZEISS Seite 6
Voranalyse Skalierung
Modularisierung
Ramp-Up
Konzeption
Detailanalyse
01 02 03 04 05 06
Voranalyse
Prüfung und
Bewertung der
Software.
Erarbeitung einer
groben
Lösungsstrategie.
Detailanalyse
Tiefgehende Analyse
und Schaffung der
Entscheidungsgrund-
lagen für die
Konzeption.
Skalierung
Übertragung der
Vorgehen und
Technologien auf die
gesamte
Softwareabteilung.
Modularisierung
Identifikation der
fachlichen Module
und Schaffung einer
modularisierten
Basisarchitektur.
Ramp-Up
Bereitstellung der
Infrastruktur und
Evaluierung der
Werkzeuge. Start der
Entwicklung.
Konzeption
Definition der
Zielstrukturen und
Technologien
basierend auf den
Analyseergebnissen.
12 Monate
6 Monate

7. Klären wie es um die Software steht
Voranalyse

8. Voranalyse
Interne Einschätzung
5. April 2022
ZEISS Seite 8
„An einem Neubau führt kein Weg vorbei!“

9. Voranalyse
Warum kein Big Bang?
5. April 2022
ZEISS Seite 9
Alt
Kick-Off Neues Produkt Mögliche Ablösung
altes Produkt
Funktionsumfang
t
Neu

10. Wissen was wirklich gebraucht wird
Detailanalyse

11. Detailanalyse
Nichtfunktionale Anforderungen
5. April 2022
ZEISS Seite 11
Maximal ein Merkmal auf höchster Ebene
Maximal zwei Merkmale auf zweithöchster Ebene
Mindestens ein Merkmal auf untererster Ebene

12. Detailanalyse
Qualitätsszenarien & Qualitätsbaum
5. April 2022
ZEISS Seite 12
ISO
25010
Security
Confidentiality
S1
Authenticity
S2
Integrity
S3
Reliability
Maturity
S4
Recoverability
S5
Fault tolerance
S6
Maintainability
Modularity
S7
Modifiability
S8
Testability
S9
Analysability
S10
Functionality
Appropriateness
S11
Completeness
S12
Compatibility
Interoperability
S13
Usability
User error
protection
S14
Portability
Installability
S15
Efficiency
Time behaviour
S16
S3 Integrity Extensions to the system, such as plugins, must be checked during startup for authenticity so that only
officially permitted extensions can be introduced into the system.
S10 Analyzability New developers can be productive within four work weeks. This includes a functioning development
environment as well as the necessary understanding of the basic software structures.
S13 Interoperability If a new hardware component must be addressed by the software, only a new software adapter needs
to be implemented as far as no further workflow changes from a business perspective are associated
with this hardware.
https://iso25000.com/index.php/en/iso-25000-standards/iso-25010

13. Detailanalyse
Issue-Analyse
5. April 2022
ZEISS Seite 13

14. Detailanalyse
Ursprungsziele
5. April 2022
ZEISS Seite 14
Verbesserung der Laufzeitstabilität
Flexibilisierung der Softwarestrukturen

15. Detailanalyse
Tatsächliche Projektziele
5. April 2022
ZEISS Seite 15
Erhöhung des Automatisierungsgrades des Gesamtproduktes
Etablierung eines nachhaltigen Entwicklungsvorgehens
Flexibilisierung der Softwarestrukturen
Wechsel des Basisframeworks (.NET 6)

16. Detailanalyse
Erkenntnisse
5. April 2022
ZEISS Seite 16
Stakeholder frühzeitig
einbinden, um eine breite
Analyse zu ermöglichen und
Bereitschaft zur Zuarbeit zu
stärken.
Stabilität ist bei einer
Restrukturierung die wichtigste,
unausgesprochene Anforderung
aller Beteiligten.
Man sollte Nichts versprechen,
was man nicht halten kann,
andernfalls stärkt man die
Antipathie gegen das Vorhaben.
Immer die Sprache derer
sprechen, von denen man
verstanden werden will. Wenn
man die Sprache nicht spricht,
dann einfache Worte wählen.
Stakeholder Stabilität Versprechen Sprache

17. Lösungen definieren
Konzeption

18. Konzeption
Zielsetzung
5. April 2022
ZEISS Seite 18
Klärung der
tatsächlichen
Arbeitsabläufe
Identifikation zentraler
Komponenten
Schaffung einer
modularen
Basisarchitektur
Restrukturierung der
Bestandsanwendung
Erhöhung des
Automatisierungs-
grades des
Gesamtproduktes

19. Konzeption
Open-Closed-Principle
5. April 2022
ZEISS Seite 19
„Module sollten sowohl offen für
Erweiterungen als auch verschlossen für
Modifikationen sein.“
Bertrand Meyer: Object Oriented Software Construction

20. Konzeption
5. April 2022
ZEISS Seite 20
Monolith vs. Modulith
Modulith Ungeplanter Monolith
vs
.
Deployment Unit Fachliche Module Interne Kommunikation Technische
Bestandteile
Sales
Consult
-ing
Invoice-
ing
?
?
?
?
?
?
?
?

21. Konzeption
5. April 2022
ZEISS Seite 21
Monolith vs. Modulith
Sales
Consult
-ing
Invoice-
ing
Modulith Microservices
vs
.
Sales
Consult
-ing
Invoice-
ing
Deployment Unit Fachliche Module Interne Kommunikation Externe
Kommunikation

22. Konzeption
5. April 2022
ZEISS Seite 22
Eventstorming – Theorie
https://www.eventstorming.com/

23. Konzeption
5. April 2022
ZEISS Seite 23
Eventstorming – Praxis
Fachliches
Modul
Fachliches
Modul
Fachliches
Modul Fachliches
Modul
Gesamtaufwand: ca. 8 PT

24. Konzeption
5. April 2022
ZEISS Seite 24
Modulschnitt

25. Konzeption
Erkenntnisse
5. April 2022
ZEISS Seite 25
DDD ist sehr abstrakt und für
viele Entwickler nur schwer
verständlich, hilft aber sehr bei
strategischen Entscheidungen.
Eventstorming ist hervorragend
geeignet um die bestehende
Software zu verstehen und
bietet einen sehr guten
Ausgangspunkt für die
Architekturdokumentation.
Entscheidungen und Entwürfe
müssen von Beginn an objektiv
begründet und dokumentiert
werden um den Mehrwert zu
verdeutlichen.
Domain Driven Design Eventstorming
Nichtfunktionale
Anforderungen Dokumentation
Hat man die nichtfunktionalen
Anforderungen ausgiebig
geklärt, lassen sich
Architekturent-scheidungen
leichter vermitteln.

26. Den Monolithen aufbrechen
Modularisierung

27. Modularisierung
5. April 2022
ZEISS Seite 27
Change by Abstraction
Software System
mgl.
Modul

28. Modularisierung
5. April 2022
ZEISS Seite 28
Change by Abstraction
Software System
mgl.
Modul
Trennschicht /
Abstraktionsschicht

29. Modularisierung
5. April 2022
ZEISS Seite 29
Change by Abstraction
Software System
Modul

30. Modularisierung
5. April 2022
ZEISS Seite 30
Change by Abstraction
Software System
Modul

31. Modularisierung
5. April 2022
ZEISS Seite 31
Gefahr der „Shotgun Surgery“!
Software System
mgl.
Modul
Software System
Strukturierte Modularisierung Unstrukturierte Modularisierung

32. Modularisierung
Erkenntnisse
5. April 2022
ZEISS Seite 32
Lieber die Konzepte im Kleinen
anhand einer realen Umgebung
erproben, bevor sie im Großen
ausgerollt werden.
Man benötigt eine klare
Strategie bei der Umsetzung:
Was, wie & in welcher
Reihenfolge soll verändert
werden? Wie können mögliche
Fehlschläge kompensiert
werden?
Die Vision muss von allen geteilt
werden, man benötigt aber auch
kleine Siege die gefeiert werden
können.
Technische Schulden müssen
von Beginn an dokumentiert und
deren Abbau fest eingeplant
werden!
Iterativ Inkrementell Strategie Vision Technische Schulden

33. Transition (weiterer) Entwicklungsteams und Softwarebestandteile
Ramp-Up & Skalierung

34. Ramp-Up & Skalierung
Conway‘s Law
5. April 2022
ZEISS Seite 34
“Organizations which design systems […]
are constrained to produce designs which
are copies of the communication structures
of these organizations.”
Melvin E. Conway

35. Ramp-Up & Skalierung
Team Setup – Analysephase
5. April 2022
ZEISS Seite 35
Intern
Extern
Analyse Team
Architekt Architekt Architekt
Projektleiter Stakeholder
Stakeholder
Stakeholder
Stakeholder

36. Ramp-Up & Skalierung
Team Setup – Konzeptphase
5. April 2022
ZEISS Seite 36
Intern
Extern
Konzept Team
aka Inkubatorteam
Architekt Architekt Architekt
Projektleiter
Scrum
Master
Entwickler Entwickler
Entwickler Tester
Product
Owner
Fach-
personal
Ziel
Erfahrungswerte
am lebenden Objekt
generieren.

37. Ramp-Up & Skalierung
Team Setup – Modularisierungsphase
5. April 2022
ZEISS Seite 37
Intern
Extern
Workflow Team
Foundation Team
Architekt
Projektleiter
Product
Owner
Architekt
Scrum
Master
Entwickler
Entwickler
Tester
Entwickler
Fach-
personal
Architekt
Scrum
Master
Entwickler
Fach-
personal
Entwickler
Tester
Entwickler

38. Ramp-Up & Skalierung
Organisatorischer Ablauf
5. April 2022
ZEISS Seite 38
Health
Check
What
we‘ve
learned.
What
we‘ve
created.

39. Ramp-Up & Skalierung
Verlauf
5. April 2022
ZEISS Seite 39
Health
Check
Startup
December 2020
May 2020
Start
Incubation
Team

40. Ramp-Up & Skalierung
Verlauf
5. April 2022
ZEISS Seite 40
Health
Check
Startup
December 2020
May 2020
What
we‘ve
learned.
What
we‘ve
created.
Issue
Analysis
Software
Modularization
Documenting
Software Architectures
Domain Driven
Design
Stakeholder
Analysis
Architecture
Analysis
Issue
Backlog
Target
Architecture
Stakeholder
Map Framework
Evaluations
Branching / Merging
Strategy
Prioritized
Roadmap
Start
Incubation
Team

41. Ramp-Up & Skalierung
Verlauf
5. April 2022
ZEISS Seite 41
Health
Check
Startup Modularization
June 20201
December 2020
May 2020
What
we‘ve
learned.
What
we‘ve
created.
Issue
Analysis
Continuous
Integration
Team
Split
Software
Modularization
Documenting
Software Architectures
Eventstorming
Refactoring
Agile / Scrum
Domain Driven
Design Clean
Code
Stakeholder
Analysis
Architecture
Analysis
Issue
Backlog
Target
Architecture
Application
Frame
Migration
Strategy
User Stories
for other teams
Stakeholder
Map Framework
Evaluations
Software
Documentation
Branching / Merging
Strategy
Domain
Model
Prioritized
Roadmap
Start
Incubation
Team
Test
Automation

42. Ramp-Up & Skalierung
Verlauf
5. April 2022
ZEISS Seite 42
Health
Check
Startup Modularization
June 20201
December 2020
May 2020
What
we‘ve
learned.
What
we‘ve
created.
Issue
Analysis
Scaling
Teams
Continuous
Integration
Team
Split
Software
Modularization
Documenting
Software Architectures
Eventstorming
Requirements
Engineering
Refactoring
Agile / Scrum
Domain Driven
Design Clean
Code
Stakeholder
Analysis
Architecture
Analysis
Issue
Backlog
Target
Architecture
Application
Frame
New Front-End
Foundation
Migration
Strategy
New
Workflow
Engine
User Stories
for other teams
Stakeholder
Map Framework
Evaluations
Software
Documentation
Branching / Merging
Strategy
Domain
Model
Prioritized
Roadmap
Team C
Team B
Team A
Start
Incubation
Team
Rollout for
all SW
Teams
Test
Automation

43. Ramp-Up & Skalierung
Verlauf
5. April 2022
ZEISS Seite 43
Health
Check
Startup Modularization Scale Up
June 2021
December 2020
May 2020
What
we‘ve
learned.
What
we‘ve
created.
Issue
Analysis
Scaling
Teams
Continuous
Integration
Team
Split
Software
Modularization
Documenting
Software Architectures
Eventstorming
Requirements
Engineering
Refactoring
Agile / Scrum
Domain Driven
Design Clean
Code
Stakeholder
Analysis
Architecture
Analysis
Issue
Backlog
Target
Architecture
Application
Frame
New Front-End
Foundation
Migration
Strategy
New
Workflow
Engine
User Stories
for other teams
Stakeholder
Map Framework
Evaluations
Software
Documentation
Branching / Merging
Strategy
Domain
Model
Prioritized
Roadmap
Team C
Team B
Team A
Start
Incubation
Team
Rollout for
all SW
Teams
Test
Automation
Team A
Team B
Team C
Team D
Team E
Team F
Team G

44. Ramp-Up & Skalierung
Verlauf
5. April 2022
ZEISS Seite 44
Health
Check
Startup Modularization Scale Up
June 2021
December 2020
May 2020
What
we‘ve
learned.
What
we‘ve
created.
Issue
Analysis
Scaling
Teams
Continuous
Integration
Team
Split
Software
Modularization
Documenting
Software Architectures
Eventstorming
Requirements
Engineering
Refactoring
Agile / Scrum
Domain Driven
Design Clean
Code
Stakeholder
Analysis
Architecture
Analysis
Issue
Backlog
Target
Architecture
Application
Frame
New Front-End
Foundation
Migration
Strategy
New
Workflow
Engine
User Stories
for other teams
Stakeholder
Map Framework
Evaluations
Software
Documentation
Branching / Merging
Strategy
Domain
Model
Prioritized
Roadmap
Team C
Team B
Team A
Start
Incubation
Team
Rollout for
all SW
Teams
Test
Automation
Team A
Team B
Team C
Team D
Team E
Team F
Team G
Tech Talks
Communities of Practice
Architecture Board

45. Ramp-Up & Skalierung
Erkenntnisse
5. April 2022
ZEISS Seite 45
Die Teamverantwortlichkeiten
müssen eindeutig benannt sein
und sich auf die Architektur
abbilden lassen, ohne deren
Schnittstellendefinitionen zu
verletzen.
Die Transition der
Softwarestrukturen und der
Teamstrukturen sollte möglichst
parallel verlaufen, da sonst die
Voraussetzung weder für das
eine noch das andere
geschaffen sind.
Inkubatorteams helfen bei der
Skalierung, da sie ein „Lernen
am lebenden Objekt“ darstellen.
Durch den Teamsplitt wird das
gelernte Wissen dann in die
Breite getragen.
Wissen von Beginn an in die
Breite tragen: Community of
Practice für spezielle
Ausarbeitungen
Tech Talks für allgemeine
Wissensvermittlung
Architecture Board damit die
gleichen Ziele und Strategien
verfolgt werden.
Verantwortlichkeiten Transition Inkubatorteams Wissenvermittlung

46. Ramp-Up & Skalierung
Erkenntnisse
5. April 2022
ZEISS Seite 46
Reden, reden und nochmals
reden!!!
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

47. Sprecher
5. April 2022
ZEISS Seite 48
Hendrik Lösch
Management Consultant
@HerrLoesch
hendrik.loesch@zeiss.com
hendrik-loesch.de
slideshare.net/HendrikLsch1
https://www.linkedin.com/learning/instructors/hendrik-losch