SlideShare ist ein Scribd-Unternehmen logo
Restrukturierung einer industriellen Großapplikation
18 Monate und kein Ende in Sicht
Hendrik Lösch
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
Basierend auf einem echten Projekt
Das Szenario
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!
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
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
Klären wie es um die Software steht
Voranalyse
Voranalyse
Interne Einschätzung
5. April 2022
ZEISS Seite 8
„An einem Neubau führt kein Weg vorbei!“
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
Wissen was wirklich gebraucht wird
Detailanalyse
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
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
Detailanalyse
Issue-Analyse
5. April 2022
ZEISS Seite 13
Detailanalyse
Ursprungsziele
5. April 2022
ZEISS Seite 14
Verbesserung der Laufzeitstabilität
Flexibilisierung der Softwarestrukturen
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)
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
Lösungen definieren
Konzeption
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
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
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
?
?
?
?
?
?
?
?
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
Konzeption
5. April 2022
ZEISS Seite 22
Eventstorming – Theorie
https://www.eventstorming.com/
Konzeption
5. April 2022
ZEISS Seite 23
Eventstorming – Praxis
Fachliches
Modul
Fachliches
Modul
Fachliches
Modul Fachliches
Modul
Gesamtaufwand: ca. 8 PT
Konzeption
5. April 2022
ZEISS Seite 24
Modulschnitt
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.
Den Monolithen aufbrechen
Modularisierung
Modularisierung
5. April 2022
ZEISS Seite 27
Change by Abstraction
Software System
mgl.
Modul
Modularisierung
5. April 2022
ZEISS Seite 28
Change by Abstraction
Software System
mgl.
Modul
Trennschicht /
Abstraktionsschicht
Modularisierung
5. April 2022
ZEISS Seite 29
Change by Abstraction
Software System
Modul
Modularisierung
5. April 2022
ZEISS Seite 30
Change by Abstraction
Software System
Modul
Modularisierung
5. April 2022
ZEISS Seite 31
Gefahr der „Shotgun Surgery“!
Software System
mgl.
Modul
Software System
Strukturierte Modularisierung Unstrukturierte Modularisierung
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
Transition (weiterer) Entwicklungsteams und Softwarebestandteile
Ramp-Up & Skalierung
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
Ramp-Up & Skalierung
Team Setup – Analysephase
5. April 2022
ZEISS Seite 35
Intern
Extern
Analyse Team
Architekt Architekt Architekt
Projektleiter Stakeholder
Stakeholder
Stakeholder
Stakeholder
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.
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
Ramp-Up & Skalierung
Organisatorischer Ablauf
5. April 2022
ZEISS Seite 38
Health
Check
What
we‘ve
learned.
What
we‘ve
created.
Ramp-Up & Skalierung
Verlauf
5. April 2022
ZEISS Seite 39
Health
Check
Startup
December 2020
May 2020
Start
Incubation
Team
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
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
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
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
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
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
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
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
Restrukturierung einer industriellen Großapplikation

Weitere ähnliche Inhalte

Ähnlich wie Restrukturierung einer industriellen Großapplikation

Agile BI in der Praxis - Agiles Testen
Agile BI in der Praxis - Agiles TestenAgile BI in der Praxis - Agiles Testen
Agile BI in der Praxis - Agiles Testen
OPITZ CONSULTING Deutschland
 
Wie erstelle ich ein Datenmodell in einem agilen Projekt?
Wie erstelle ich ein Datenmodell in einem agilen Projekt? Wie erstelle ich ein Datenmodell in einem agilen Projekt?
Wie erstelle ich ein Datenmodell in einem agilen Projekt?
OPITZ CONSULTING Deutschland
 
Der digitale Zwilling als Reisebegleiter in die agile Hardware Entwicklung
Der digitale Zwilling als Reisebegleiter in die agile Hardware EntwicklungDer digitale Zwilling als Reisebegleiter in die agile Hardware Entwicklung
Der digitale Zwilling als Reisebegleiter in die agile Hardware Entwicklung
Agile Austria Conference
 
Continuous Delivery - Nett oder nötig? Erfahrungsbericht der FriendScout24 - ...
Continuous Delivery - Nett oder nötig? Erfahrungsbericht der FriendScout24 - ...Continuous Delivery - Nett oder nötig? Erfahrungsbericht der FriendScout24 - ...
Continuous Delivery - Nett oder nötig? Erfahrungsbericht der FriendScout24 - ...
Michael Maretzke
 
130605 buildfrei skalieren_fuer_bigdata
130605 buildfrei skalieren_fuer_bigdata130605 buildfrei skalieren_fuer_bigdata
130605 buildfrei skalieren_fuer_bigdata
Henning Blohm
 
Alles im Griff: welche Plattform unterstützt den Social Workplace?
Alles im Griff: welche Plattform unterstützt den Social Workplace?Alles im Griff: welche Plattform unterstützt den Social Workplace?
Alles im Griff: welche Plattform unterstützt den Social Workplace?
netmedianer GmbH
 
Jens Bleiholder und Rico Grossmann Unterstützung agiler Vorgehensmodelle du...
Jens Bleiholder und Rico Grossmann   Unterstützung agiler Vorgehensmodelle du...Jens Bleiholder und Rico Grossmann   Unterstützung agiler Vorgehensmodelle du...
Jens Bleiholder und Rico Grossmann Unterstützung agiler Vorgehensmodelle du...
Stephan Trahasch
 
Vortragsreihe Dortmund: Unified Development Environments
Vortragsreihe Dortmund: Unified Development EnvironmentsVortragsreihe Dortmund: Unified Development Environments
Vortragsreihe Dortmund: Unified Development Environments
Thorsten Kamann
 
Die Macht der Daten - CeBIT 2017
Die Macht der Daten - CeBIT 2017Die Macht der Daten - CeBIT 2017
Die Macht der Daten - CeBIT 2017
Detlev Sandel
 
VMware Site Recovery Manager
VMware Site Recovery ManagerVMware Site Recovery Manager
VMware Site Recovery Manager
inoX-tech GmbH
 
Migration von Aftersales Systemen auf eine Cloud Plattform
Migration von Aftersales Systemen auf eine Cloud PlattformMigration von Aftersales Systemen auf eine Cloud Plattform
Migration von Aftersales Systemen auf eine Cloud Plattform
QAware GmbH
 
.NET Core Architecture (UI)
.NET Core Architecture (UI).NET Core Architecture (UI)
.NET Core Architecture (UI)
Robin Sedlaczek
 
Modulare Enterprise Systeme - Eine Einführung
Modulare Enterprise Systeme - Eine EinführungModulare Enterprise Systeme - Eine Einführung
Modulare Enterprise Systeme - Eine Einführung
Andreas Weidinger
 
Cloud Native Migration: Wie IT-Landschaften ihren Weg auf eine Cloud-Native-P...
Cloud Native Migration: Wie IT-Landschaften ihren Weg auf eine Cloud-Native-P...Cloud Native Migration: Wie IT-Landschaften ihren Weg auf eine Cloud-Native-P...
Cloud Native Migration: Wie IT-Landschaften ihren Weg auf eine Cloud-Native-P...
QAware GmbH
 
Interview - Data Migration AG - Peter R. Schönenberger - smart con SAP 2013
Interview - Data Migration AG - Peter R. Schönenberger - smart con SAP 2013Interview - Data Migration AG - Peter R. Schönenberger - smart con SAP 2013
Interview - Data Migration AG - Peter R. Schönenberger - smart con SAP 2013Maria Willamowius
 
Low-Code- und No-Code-Apps im PLM: Einordnung, Nutzen, Risiken, Chancen
Low-Code- und No-Code-Apps im PLM: Einordnung, Nutzen, Risiken, ChancenLow-Code- und No-Code-Apps im PLM: Einordnung, Nutzen, Risiken, Chancen
Low-Code- und No-Code-Apps im PLM: Einordnung, Nutzen, Risiken, Chancen
Intelliact AG
 
Artikel Netzguide: SOA als Grundlage für "Composite Applications"​
Artikel Netzguide: SOA als Grundlage für "Composite Applications"​Artikel Netzguide: SOA als Grundlage für "Composite Applications"​
Artikel Netzguide: SOA als Grundlage für "Composite Applications"​
Peter Affolter
 
Advanced Continuous Integration
Advanced Continuous IntegrationAdvanced Continuous Integration
Advanced Continuous Integration
OPITZ CONSULTING Deutschland
 
Architectures for .Net Core Applications
Architectures for .Net Core ApplicationsArchitectures for .Net Core Applications
Architectures for .Net Core Applications
Robin Sedlaczek
 
Produktdatenmanagement mit Neo4j - Andreas Weber, semantic pdm
Produktdatenmanagement mit Neo4j - Andreas Weber, semantic pdmProduktdatenmanagement mit Neo4j - Andreas Weber, semantic pdm
Produktdatenmanagement mit Neo4j - Andreas Weber, semantic pdm
Neo4j
 

Ähnlich wie Restrukturierung einer industriellen Großapplikation (20)

Agile BI in der Praxis - Agiles Testen
Agile BI in der Praxis - Agiles TestenAgile BI in der Praxis - Agiles Testen
Agile BI in der Praxis - Agiles Testen
 
Wie erstelle ich ein Datenmodell in einem agilen Projekt?
Wie erstelle ich ein Datenmodell in einem agilen Projekt? Wie erstelle ich ein Datenmodell in einem agilen Projekt?
Wie erstelle ich ein Datenmodell in einem agilen Projekt?
 
Der digitale Zwilling als Reisebegleiter in die agile Hardware Entwicklung
Der digitale Zwilling als Reisebegleiter in die agile Hardware EntwicklungDer digitale Zwilling als Reisebegleiter in die agile Hardware Entwicklung
Der digitale Zwilling als Reisebegleiter in die agile Hardware Entwicklung
 
Continuous Delivery - Nett oder nötig? Erfahrungsbericht der FriendScout24 - ...
Continuous Delivery - Nett oder nötig? Erfahrungsbericht der FriendScout24 - ...Continuous Delivery - Nett oder nötig? Erfahrungsbericht der FriendScout24 - ...
Continuous Delivery - Nett oder nötig? Erfahrungsbericht der FriendScout24 - ...
 
130605 buildfrei skalieren_fuer_bigdata
130605 buildfrei skalieren_fuer_bigdata130605 buildfrei skalieren_fuer_bigdata
130605 buildfrei skalieren_fuer_bigdata
 
Alles im Griff: welche Plattform unterstützt den Social Workplace?
Alles im Griff: welche Plattform unterstützt den Social Workplace?Alles im Griff: welche Plattform unterstützt den Social Workplace?
Alles im Griff: welche Plattform unterstützt den Social Workplace?
 
Jens Bleiholder und Rico Grossmann Unterstützung agiler Vorgehensmodelle du...
Jens Bleiholder und Rico Grossmann   Unterstützung agiler Vorgehensmodelle du...Jens Bleiholder und Rico Grossmann   Unterstützung agiler Vorgehensmodelle du...
Jens Bleiholder und Rico Grossmann Unterstützung agiler Vorgehensmodelle du...
 
Vortragsreihe Dortmund: Unified Development Environments
Vortragsreihe Dortmund: Unified Development EnvironmentsVortragsreihe Dortmund: Unified Development Environments
Vortragsreihe Dortmund: Unified Development Environments
 
Die Macht der Daten - CeBIT 2017
Die Macht der Daten - CeBIT 2017Die Macht der Daten - CeBIT 2017
Die Macht der Daten - CeBIT 2017
 
VMware Site Recovery Manager
VMware Site Recovery ManagerVMware Site Recovery Manager
VMware Site Recovery Manager
 
Migration von Aftersales Systemen auf eine Cloud Plattform
Migration von Aftersales Systemen auf eine Cloud PlattformMigration von Aftersales Systemen auf eine Cloud Plattform
Migration von Aftersales Systemen auf eine Cloud Plattform
 
.NET Core Architecture (UI)
.NET Core Architecture (UI).NET Core Architecture (UI)
.NET Core Architecture (UI)
 
Modulare Enterprise Systeme - Eine Einführung
Modulare Enterprise Systeme - Eine EinführungModulare Enterprise Systeme - Eine Einführung
Modulare Enterprise Systeme - Eine Einführung
 
Cloud Native Migration: Wie IT-Landschaften ihren Weg auf eine Cloud-Native-P...
Cloud Native Migration: Wie IT-Landschaften ihren Weg auf eine Cloud-Native-P...Cloud Native Migration: Wie IT-Landschaften ihren Weg auf eine Cloud-Native-P...
Cloud Native Migration: Wie IT-Landschaften ihren Weg auf eine Cloud-Native-P...
 
Interview - Data Migration AG - Peter R. Schönenberger - smart con SAP 2013
Interview - Data Migration AG - Peter R. Schönenberger - smart con SAP 2013Interview - Data Migration AG - Peter R. Schönenberger - smart con SAP 2013
Interview - Data Migration AG - Peter R. Schönenberger - smart con SAP 2013
 
Low-Code- und No-Code-Apps im PLM: Einordnung, Nutzen, Risiken, Chancen
Low-Code- und No-Code-Apps im PLM: Einordnung, Nutzen, Risiken, ChancenLow-Code- und No-Code-Apps im PLM: Einordnung, Nutzen, Risiken, Chancen
Low-Code- und No-Code-Apps im PLM: Einordnung, Nutzen, Risiken, Chancen
 
Artikel Netzguide: SOA als Grundlage für "Composite Applications"​
Artikel Netzguide: SOA als Grundlage für "Composite Applications"​Artikel Netzguide: SOA als Grundlage für "Composite Applications"​
Artikel Netzguide: SOA als Grundlage für "Composite Applications"​
 
Advanced Continuous Integration
Advanced Continuous IntegrationAdvanced Continuous Integration
Advanced Continuous Integration
 
Architectures for .Net Core Applications
Architectures for .Net Core ApplicationsArchitectures for .Net Core Applications
Architectures for .Net Core Applications
 
Produktdatenmanagement mit Neo4j - Andreas Weber, semantic pdm
Produktdatenmanagement mit Neo4j - Andreas Weber, semantic pdmProduktdatenmanagement mit Neo4j - Andreas Weber, semantic pdm
Produktdatenmanagement mit Neo4j - Andreas Weber, semantic pdm
 

Mehr von Hendrik Lösch

Why (most) softwareprojects fail silently
Why (most) softwareprojects fail silentlyWhy (most) softwareprojects fail silently
Why (most) softwareprojects fail silently
Hendrik Lösch
 
We (don't) need a software architect!?!
We (don't) need a software architect!?!We (don't) need a software architect!?!
We (don't) need a software architect!?!
Hendrik Lösch
 
Software ist was du draus machst!
Software ist was du draus machst!Software ist was du draus machst!
Software ist was du draus machst!
Hendrik Lösch
 
.NET zu .NET Core
.NET zu .NET Core.NET zu .NET Core
.NET zu .NET Core
Hendrik Lösch
 
Workshop Vue js
Workshop Vue jsWorkshop Vue js
Workshop Vue js
Hendrik Lösch
 
Migrationsstrategien
MigrationsstrategienMigrationsstrategien
Migrationsstrategien
Hendrik Lösch
 
Einstieg in das Vueniverse
Einstieg in das VueniverseEinstieg in das Vueniverse
Einstieg in das Vueniverse
Hendrik Lösch
 
Survivalkit für Codehausmeister
Survivalkit für CodehausmeisterSurvivalkit für Codehausmeister
Survivalkit für Codehausmeister
Hendrik Lösch
 
Confessions of a Codehausmeister
Confessions of a CodehausmeisterConfessions of a Codehausmeister
Confessions of a Codehausmeister
Hendrik Lösch
 
WPF Dos n Don'ts - der WPF Rundumschlag
WPF Dos n Don'ts - der WPF RundumschlagWPF Dos n Don'ts - der WPF Rundumschlag
WPF Dos n Don'ts - der WPF Rundumschlag
Hendrik Lösch
 
Clean mit visual studio
Clean mit visual studioClean mit visual studio
Clean mit visual studio
Hendrik Lösch
 
Advanced Refactoring Patterns
Advanced Refactoring PatternsAdvanced Refactoring Patterns
Advanced Refactoring Patterns
Hendrik Lösch
 
Codesmells
CodesmellsCodesmells
Codesmells
Hendrik Lösch
 
Advanced Refactoring Patterns - Dev Day 2018
Advanced Refactoring Patterns - Dev Day 2018Advanced Refactoring Patterns - Dev Day 2018
Advanced Refactoring Patterns - Dev Day 2018
Hendrik Lösch
 
Der Healthcheck für Softwareprojekte
Der Healthcheck für SoftwareprojekteDer Healthcheck für Softwareprojekte
Der Healthcheck für Softwareprojekte
Hendrik Lösch
 
MVVM mit WPF
MVVM mit WPFMVVM mit WPF
MVVM mit WPF
Hendrik Lösch
 
Ionic 3
Ionic 3Ionic 3
Legacy Code refaktorisieren
Legacy Code refaktorisierenLegacy Code refaktorisieren
Legacy Code refaktorisieren
Hendrik Lösch
 
TDD für Testmuffel
TDD für TestmuffelTDD für Testmuffel
TDD für Testmuffel
Hendrik Lösch
 
Ionic 2 - Hybridapps auf Steroiden
Ionic 2 - Hybridapps auf SteroidenIonic 2 - Hybridapps auf Steroiden
Ionic 2 - Hybridapps auf Steroiden
Hendrik Lösch
 

Mehr von Hendrik Lösch (20)

Why (most) softwareprojects fail silently
Why (most) softwareprojects fail silentlyWhy (most) softwareprojects fail silently
Why (most) softwareprojects fail silently
 
We (don't) need a software architect!?!
We (don't) need a software architect!?!We (don't) need a software architect!?!
We (don't) need a software architect!?!
 
Software ist was du draus machst!
Software ist was du draus machst!Software ist was du draus machst!
Software ist was du draus machst!
 
.NET zu .NET Core
.NET zu .NET Core.NET zu .NET Core
.NET zu .NET Core
 
Workshop Vue js
Workshop Vue jsWorkshop Vue js
Workshop Vue js
 
Migrationsstrategien
MigrationsstrategienMigrationsstrategien
Migrationsstrategien
 
Einstieg in das Vueniverse
Einstieg in das VueniverseEinstieg in das Vueniverse
Einstieg in das Vueniverse
 
Survivalkit für Codehausmeister
Survivalkit für CodehausmeisterSurvivalkit für Codehausmeister
Survivalkit für Codehausmeister
 
Confessions of a Codehausmeister
Confessions of a CodehausmeisterConfessions of a Codehausmeister
Confessions of a Codehausmeister
 
WPF Dos n Don'ts - der WPF Rundumschlag
WPF Dos n Don'ts - der WPF RundumschlagWPF Dos n Don'ts - der WPF Rundumschlag
WPF Dos n Don'ts - der WPF Rundumschlag
 
Clean mit visual studio
Clean mit visual studioClean mit visual studio
Clean mit visual studio
 
Advanced Refactoring Patterns
Advanced Refactoring PatternsAdvanced Refactoring Patterns
Advanced Refactoring Patterns
 
Codesmells
CodesmellsCodesmells
Codesmells
 
Advanced Refactoring Patterns - Dev Day 2018
Advanced Refactoring Patterns - Dev Day 2018Advanced Refactoring Patterns - Dev Day 2018
Advanced Refactoring Patterns - Dev Day 2018
 
Der Healthcheck für Softwareprojekte
Der Healthcheck für SoftwareprojekteDer Healthcheck für Softwareprojekte
Der Healthcheck für Softwareprojekte
 
MVVM mit WPF
MVVM mit WPFMVVM mit WPF
MVVM mit WPF
 
Ionic 3
Ionic 3Ionic 3
Ionic 3
 
Legacy Code refaktorisieren
Legacy Code refaktorisierenLegacy Code refaktorisieren
Legacy Code refaktorisieren
 
TDD für Testmuffel
TDD für TestmuffelTDD für Testmuffel
TDD für Testmuffel
 
Ionic 2 - Hybridapps auf Steroiden
Ionic 2 - Hybridapps auf SteroidenIonic 2 - Hybridapps auf Steroiden
Ionic 2 - Hybridapps auf Steroiden
 

Restrukturierung einer industriellen Großapplikation

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