Teamstrukturen für SOftwaremodernisierung
Legacy-Monolith-Team
Core Team
SRE-Team
Platform Team
Service 1 Team
Legacy-Monolith-Team
Core Team
SRE-Team
Platform Team
Service 1 Team
Chief Tailwind Officer • Founder
Agile Coach • Scrum Master • Product Owner
15 Jahre Projektmanagementerfahrung und seit 2015 als Agile Coach in Projekten tätig. Seine Leidenschaft ist es, Menschen & Teams zu inspirieren und für ihre Aufgabe zu begeistern, damit sie fokussierter und motivierter wertschöpfende Produkte erzeugen können.
Programmiert seit 1984 und verdient seit 1992 sein Geld mit Software. Ein Hacker gone Management mit viel Erfahrung als CTO, Founder, Advisor und Investor, mit Spaß an Architektur, Leadership, Agile, DevOps und natürlich Security.
Warum überhaupt
Modernisieren?
Abhängigkeiten
Externe Faktoren
Google ... Chrome Apps
... AngularJS
... Fabric
... Plus
Compliance & Security
Externe Faktoren
Geänderte Aufgabenstellungen
Externe Faktoren
Software Aging
Innere Faktoren
Wartbarkeit &
Erlernbarkeit
Innere Faktoren
Bugs und Features
Dauern lange
Innere Faktoren
Fluktuation &
Brain Drain
Innere Faktoren
Also: Modernisieren!
Schlechtes Timing:
Modernisierungen
vs Cloud Native
Refactoring
statt
REENGINEERING
Gescheiterte Modernisierungsansätze
Featurefreeze & Zeitbudget für Modernisierung
Gescheiterte Modernisierungsansätze
Alles NEU!
Ein neues Team erstellt eine neue Software.
Während das alte Team neue Features in die alte baut.
Gescheiterte Modernisierungsansätze
74% of organisations have started a modernisation program but failed to complete it.
2020 Mainframe Modernisation Business Barometer
Success Rate for Replacements: 26%"
2020 Standish Group Endless Modernisation
Gescheiterte Modernisierungsansätze
Projekt "Phönix 7"
Gescheiterte Modernisierungsansätze
Wir kennen alle Features,
Wir können Greenfield mit
neuen Technoligien Anfangen und Scheitern trotzdeM??
Wie wird Software
mit teams entwickelt?
Cross-functional First Try
DevbizUXsecops
Conways LAW
"Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure"
Inverse/Reverse Conway Maneuvre
Micorservices/You build it, you run it!
Mental Load bei Microservices
Intrinsisch
Dinge, die ich für meine aktuelle Aufgabe einfach brauche.
Wie viele Dinge muss ich berücksichtigen?
Wie interagieren die Dinge miteinander?
EXTRINSISCH
Was muss ich dazu noch beachten? Welche äusseren Anforderungen gibt es noch?
Lernbezogen
Kognitive Belastung um das benötigte Wissen zu lernen, das ich dann als intrinische oder extrinische kognitive Belastung jonglieren muss.
SUM(INTRINSISCH
+EXTRINSISCH
+LERNBEZOGEN)
<= CONST
Team-archetypen nach Team topologies
Complicated-subsystem team
Enabling team
Stream-aligned team
Platform team
Stream aligned Teams
Platform Teams
Enabling Teams (technical Consulting)
COMPLICATED SUBSYSTEMS
Team Interaction Modes
(Kommunikationsmuster)
Collaboration
Enge zusammenarbeit zwischen zwei Teams
X-as-a-Service
Klare Verantwortungen mit vorhersagbarer Delivery und gutem Product Management
Facilitating
Erkennen und Reduzieren von fehlenden Fähigkeiten
Lern Loops
Warum Modernisierungen noch schlimmer sind
Die gealterte Software
IST BEREITS zu KOMPLEX
Extrinsische und intrinisische
Kognitive Last / Technisch
HÖHERE QUALITÄT BRAUCHT
METHODE - CrafterShip
lernbezogene Kognitive Last / Methodisch
Empirisch gesehen produziert das existierende Setup genau die Art von Software, die man jetzt ablösen will.
DIE NEUE PLATFORM MUSS
ERST ERLERNT WERDEN
lernbezogene kognitive Last / Technisch
NEVER TRUST YOUR FIRST TRY.
lernbezogene Kognitive Last / Technisch
Shu Ha Ri gilt auch bei neuen Plattformen
Neuen Plattformen brauchen
Anderes Knowhow
von AWS zu KUBECTL
Kognitive Last / Technisch
Cloud-Native Arbeitsweisen brauchen Observability -
und ARCHITEKTURKNOWHOW
Kognitive Last / Technisch
Built-Run-Teams braucht
neue Arbeitsweisen
Von On-Call-Duty über Incident Management bis Post Mortem-Kultur
lernbezogene kognitive Last / Methodisch
Neue Rollen, Ansprechpartner und Kooperationen
Kognitive Last/ Organisation und Kooperation
Genau deshalb kommen die Team Topologies als explizites Werkzeug aus der DevOps-Bewegung.
Storming, Norming &
Politik
Kognitive Last/ Organisation und Kooperation
einer WELT mit ÜBERLAST lade ich noch deutlich mehr auf.
74%
Ansätze zum Umgang
DAMIT
Fokus:
Dämpfung von
Mentaler LAST
Alte Software
Neue Platform
Methoden & Struktur
MAX
-
Software
-
Teamstruktur
-
Knowhowaufbau
gemeinsam behandeln
-
Self-Service
-
Reproduzierbare (DEv-) Environments
Stream Aligned Team
X-AS-A-Service
Blue prints
Referenzarchitekturen
Golden Paths
Bootcamps
Stream Aligned Team
X-AS-A-Service
lernbezogene kognitive Last / Technisch
Developer Portals
https://backstage.spotify.com/
Developer Experience wird ZUR Organisationsaufgabe
- Die Pioniere für die neue Plattform
- erste Version der
- neuen Platform
- eines neuen Service
- des neuen Toolings
- des Onboardings
- Experimente, PoCs
https://www.cnpatterns.org/organization-culture/core-team
Core team
Core-Team
MVP Platform
- Sobald es von anderen nutzbar ist können auch andere Teams darauf aufsetzen
- nach ca 2 Monaten vorhanden
- 20%-40% der finalen Plattformfeatures
Basis-Infrastruktur für die ersten Siedler
https://www.cnpatterns.org/organization-culture/mvp-platform
Graduelles Onboarding
https://www.cnpatterns.org/organization-culture/gradual-onboarding
- Team für Team wird in Kollaboration
auf die neue Plattform gehoben
- Knowhowaufbau beginnt
vor tatsächlichem Einsatz
- das Core-Team supported und
trainiert aktiv
Graduelles Onboarding
https://www.cnpatterns.org/organization-culture/gradual-onboarding
Legacy-Monolith-Team
Core Team
Enabling
Core-Team
Service 2 Team
Service 1 Team
Die ALT-Software
ist ein Complicated Subsystem
Legacy-Monolith-Team
Core Team
Enabling
Core-Team
Service 2 Team
Service 1 Team
Extraktion/Integration
VON APIs
Legacy-Monolith-Team
Service 2 Team
API-Definition & Integration: Kollaboration
Legacy-Monolith-Team
Service 2 Team
Nach Fertigstellung: NIL / X-As-A-Service
Divide & Conquer
Legacy-Monolith-Team
Extraction-Team
Service-Extraktion: Kollaboration
Legacy-Monolith-Team
Extracted-Service-Team
Nach Extraktion: NIL / X-As-A-Service
Enabling
Core-Team
Temporäre
Kollaboration
für Komplexe
Aufgabenstellungen
Legacy-Monolith-Team
Extracted-Service-Team
EnablingCore-Team
Beratung,
Event storming oder Wardley Maps
Service 1 Team
Service 2 Team
Enabling
Core-Team
Legacy-Monolith-Team
Facilitating
PLATFORM-Team
https://www.cnpatterns.org/organization-culture/platform-team
- Übernimmt die Platform vom
Core-Team
- Ist selbst ein Product-Team
- die Stream-aligned Teams
sind der Kunde
Strangler-Fig-
Pattern
https://cmfirstgroup.com/modernize-with-the-strangler-application-pattern-and-microservices/
Strangle Monolithic Organization
https://www.cnpatterns.org/organization-culture/strangle-monolithic-organization
SRE ERSETZT Core-Team
https://www.cnpatterns.org/organization-culture/sre-team
Stream-Aligned Team 1
SRE-Team
Platform Team
Stream-Aligned Team 2
SRE-
Team
Platform Team as a Service
EVOLUTION über
Learning-Loops & SENSING
https://teamtopologies.com/book
Spotify? LESS?
Safe 5.1: Evolution != Design
https://teamtopologies.com/book
Ziel:
Evolutionäre Organisation mit evolutionärer Architektur
3 Phasen:
-
Bootstrap: Core, Platform-MVP
-
Modernisierung: onboarding & Strangling
-
evolution
Woran wir schon scheiterten
Zu wenig zeit, zu wenig Leute:
Mehr Mental Load bedeutet
mehr Aufwand und mehr Kalenderzeit
Balance zwischen
Cost of Delay
Und Zeit zum
Lernen
Organisations- und
Personalkarussel ist zusätzliche Mental Load
Politik und intransparenz verhindert lernen und adaption.
Empfehlungen
Cloud Native Transformation Patterns
Tools for creating effective Cloud Native architecture—and remaking the way we work
Team Topologies
Team Topologies
Organizing business and technology teams for fast flow
Viel Glück!😀
… und vielen Dank für eure Aufmerksamkeit🙇🏼
Landsberger Straße 314
80687 München
fon(089) 242054 - 11 77
fax(089) 242054 - 29
Teamstrukturen für Softwaremodernsierung
By Johann-Peter Hartmann
