![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](https://image.slidesharecdn.com/oop2022hlkeinendeinsichtv2-220203084239/85/Restrukturierung-einer-industriellen-Grossapplikation-34-320.jpg)
Hochgeladen vonHendrik Lösch
Restrukturierung einer industriellen Großapplikation
Die Dokumentation beschreibt die Herausforderungen und Strategien einer Restrukturierung einer industriellen Großapplikation im Bereich Halbleiterfertigung, die von über 30 Entwicklern mit mehr als 20 Jahren Erfahrung bearbeitet wird. Der Prozess umfasst eine Grundlagenanalyse, Modularisierung, Konzeption und Ramp-Up für ein nachhaltiges Entwicklungsvorgehen, um die Software stabiler und flexibler zu gestalten. Missverständnisse unter den Stakeholdern sollten vermieden werden, indem eine klare Kommunikation und die Einbindung aller Beteiligten sichergestellt werden.
Restrukturierung einer industriellen Großapplikation
- 1. Restrukturierung einer industriellenGroßapplikation 18 Monate und kein Ende in Sicht Hendrik Lösch
- 2. Sprecher 5. April 2022 ZEISSSeite 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 einemechten Projekt Das Szenario
- 4. Szenario 5. April 2022 ZEISSSeite 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. April2022 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 esum die Software steht Voranalyse
- 8. Voranalyse Interne Einschätzung 5. April2022 ZEISS Seite 8 „An einem Neubau führt kein Weg vorbei!“
- 9. Voranalyse Warum kein BigBang? 5. April 2022 ZEISS Seite 9 Alt Kick-Off Neues Produkt Mögliche Ablösung altes Produkt Funktionsumfang t Neu
- 10. Wissen was wirklichgebraucht wird Detailanalyse
- 11. Detailanalyse Nichtfunktionale Anforderungen 5. April2022 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.
- 14. Detailanalyse Ursprungsziele 5. April 2022 ZEISSSeite 14 Verbesserung der Laufzeitstabilität Flexibilisierung der Softwarestrukturen
- 15. Detailanalyse Tatsächliche Projektziele 5. April2022 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 ZEISSSeite 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.
- 18. Konzeption Zielsetzung 5. April 2022 ZEISSSeite 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 ZEISSSeite 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 ZEISSSeite 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 ZEISSSeite 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 ZEISSSeite 22 Eventstorming – Theorie https://www.eventstorming.com/
- 23. Konzeption 5. April 2022 ZEISSSeite 23 Eventstorming – Praxis Fachliches Modul Fachliches Modul Fachliches Modul Fachliches Modul Gesamtaufwand: ca. 8 PT
- 24. Konzeption 5. April 2022 ZEISSSeite 24 Modulschnitt
- 25. Konzeption Erkenntnisse 5. April 2022 ZEISSSeite 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.
- 27. Modularisierung 5. April 2022 ZEISSSeite 27 Change by Abstraction Software System mgl. Modul
- 28. Modularisierung 5. April 2022 ZEISSSeite 28 Change by Abstraction Software System mgl. Modul Trennschicht / Abstraktionsschicht
- 29. Modularisierung 5. April 2022 ZEISSSeite 29 Change by Abstraction Software System Modul
- 30. Modularisierung 5. April 2022 ZEISSSeite 30 Change by Abstraction Software System Modul
- 31. Modularisierung 5. April 2022 ZEISSSeite 31 Gefahr der „Shotgun Surgery“! Software System mgl. Modul Software System Strukturierte Modularisierung Unstrukturierte Modularisierung
- 32. Modularisierung Erkenntnisse 5. April 2022 ZEISSSeite 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) Entwicklungsteamsund Softwarebestandteile Ramp-Up & Skalierung
- 34. Ramp-Up & Skalierung Conway‘sLaw 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 TeamSetup – Analysephase 5. April 2022 ZEISS Seite 35 Intern Extern Analyse Team Architekt Architekt Architekt Projektleiter Stakeholder Stakeholder Stakeholder Stakeholder
- 36. Ramp-Up & Skalierung TeamSetup – 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 TeamSetup – 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 OrganisatorischerAblauf 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 ZEISSSeite 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