Legacy-Monolith-Team

Core Team

SRE-Team

Platform Team

Service 1 Team

Legacy-Monolith-Team

Core Team

SRE-Team

Platform Team

Service 1 Team

Software Craftsman • Architect

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.

Seit über 25 Jahren in der IT: angefangen bei HTML, CSS, PHP, Perl, Ruby, Java, Kotlin bis zu TypeScript, Golang, Ansible und Terraform. Inzwischen freiberuflich als Full-stack Developer, Software Architect, DevOps Engineer und Trainer unterwegs.

Warum überhaupt
Modernisieren?

IN ALTER SOFTWARE

STECKEN Abhängigkeiten

Externe Faktoren

... Google
... AngularJS
... Fabric
... NPM Libs

Compliance & Security

NEUE ANFORDERUNGEN

Externe Faktoren

Geänderte Aufgabenstellungen

erfordern

ANDERE KONZEPTE

Externe Faktoren

Software Aging

DEAD CODE

COMPLEXITY

DEPRECATED CODE

ENTROPY

Innere Faktoren

Wartbarkeit &
Erlernbarkeit

ZU GROSSER SCOPE

KEINE DOKUMENTATION

WIE WAR DAS NOCHMAL?! UND WARUM!??

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 Technologien Anfangen und Scheitern trotzdem?

Wie wird Software

mit teams entwickelt?

Cross-functional First Try

DevbizUXsecops

Inverse/Reverse Conway Maneuvre

Micorservices/You build it, you run it!

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"

Team-archetypen nach Team topologies

Stream aligned Teams

Platform Teams

Enabling Teams (technical Consulting)

COMPLICATED SUBSYSTEMS

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

Lern Loops

Warum Modernisierungen noch schlimmer sind

Die gealterte Software
IST BEREITS zu KOMPLEX

 Extrinsische und intrinsische 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

• Kommunikationsstruktur

• Know-how aufbau

gemeinsam behandeln

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

• 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

Core-Team ➔ Enabling team

https://www.cnpatterns.org/organization-culture/sre-team

Stream-Aligned Team 1

SRE-Team

Platform Team

Stream-Aligned Team 2

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:

1. Bootstrap: Core, Platform-MVP

2. Modernisierung: onboarding & Strangling

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