SOFTWARE-MODERNISIERUNG

Mehr als nur "Endlich die neue Plattform".

Wir sind nicht so gut
in Modernisierungen.

Aber deutlich schlechter
in Replacements.

Modernisierungen
früher ... 

• neue, bessere Technologien stehen zur Verfügung

• Kompatibilität zur IT-Landschaft muss bereitgestellt werden
• Verfügbarkeit von Fachkräften wird problematisch

"Four Key Metrics"

auf "adopt"

Modernisierung im Jahr 2022

Deployment Frequency

• Low: einmal pro 6 Monate 
• Medium: monatliche oder alle 2-3 Monate
• High: mehrfach pro Monat oder Woche
• Top: on-demand, auch mehrfach pro Tag 

Modernisierung
2022

Lead time
for changes

• Low: mehr als 6 Monate  
• Medium: zwischen 1 und 6 Monaten
• High: zwischen einem Tag und einer Woche
• Top: weniger als eine Stunde

Modernisierung
2022

Time to
restore service

• Low: mehr als 6 Monate  
• Medium: zwischen einem Tag und einer Woche
• High: weniger als ein Tag
• Top: weniger als eine Stunde

Modernisierung
2022

Change failure rate

• Low: 16-30%
• Medium: 16-30%
• High: 16-30%
• Top: 0-15%

Modernisierung
2022

https://services.google.com/fh/files/misc/state-of-devops-2021.pdf

Cloud Native

Up to 10 times
faster development.

Cloud Native

Up to 100 times less
infrastructure costs

Wer glaubt das?

Faktor 10?!
Faktor 100 ... ?!

Faktor 100 preiswerter
in Operations?!

"Wir gehen in die Cloud."

Rehosting

A.k.a. "Lift and Shift"

software behalten, hardware wechseln
 

• Extern:AWS, Azure, Google, Hetzner, Ionos

• Intern: OpenStack, Vmware, ...

30% billiger als
on-premise!

(sagt Amazon)

Für 85% der Anwendungen teurer als  on-premise!

(sagt Dell)

Replatforming

A.k.a. "Lift, Tinker and Shift"

Scale 2 Zero

Reduktion des effektiven
Hardware-Bedarfs 50-90%

Reduktion des effektiven
Hardware-Bedarfs 50-90%

Container & Lambda

• Klein genug um es nicht genehmigen zu müssen
• Standardisiert genug um es verlässlich automatisch behandeln zu können

Self Service & Automation
vs Tickets

Was bleibt bei Self-Service übrig?

Faktor 10 schneller

im Development?!

Der Trick 10 mal schneller zu arbeiten ...

... ist
90% der Arbeit

wegzulassen.

Uncle Bob

“reading versus writing is
well over 10 to 1.
We are constantly reading old code as part of the effort to write new code. ...[Therefore,] making it easy to read makes it easier to write.”

98% der Zeit wird mit Verstehen von existierendem Code verbracht.

Aufgabe:
Lesen & Recherche reduzieren

MicroServices

Microservices: Software that fits in your Head

Dan North

Microservices architecture allows us moving complexity into the area where we know how to automate things.

O'Reilly

Serverless

Nur noch die echte Funktionalität wird implementiert.

• sollte eigentlich "service-full" sein
  • Function as a Service / Lambda /λ
  • Serverless databases / Aurora etc
  • SQS, SNS, ELB, Route53,
• Funktion als Deploymentebene
• Pay-as-you-go
• Skalieren - von 0 bis Milllionen - geht

Faktor 10?
Ok. Kauf ich. 

Aber meine Realität sieht anders aus.

Damals, der erste
Prototyp

Grossartige Software!

Aber wir brauchen mehr Features.
Und die bestehenden müssen geändert werden.
Und ein paar Kundenanpassungen.

Um so agiler ich auf Kunden und Markt reagiere, um so schneller altert meine Software

Agiles Paradox

"Big Ball of Mud"

• Hohe Einarbeitungsaufwände
• Verschiedene Leute mit verschiedenen Ansätzen
• Fehlender Gesamtüberblick
• Ungenutzte Features, toter Code
• Buffer everywhere: Zeitschätzungen sind unzuverlässig

"Wir würden es am liebsten komplett neu schreiben..."

Also Moderniserung ...

Aber wie gehe ich dabei vor? 

Architektur

"Stuff that is hard to change"

Welches Schweinderl hätten's denn gern 2022

• Modulare/Moderne/DDD Monolithen
• MiniService/MacroService/SCS
• Cloud Native 
• MicroServices 

• Keine Layered Monolithen
• Keine SOA/ESB-Architekturen               

Everything in software architecture is a trade-off

First Law of Software Architecture

ATAM 1: Businesstreiber

Business-Treiber ....

• NFRs: Wartbarkeit, Erlernbarkeit,
  Verlässlichkeit, Security ...
• Ressourcen: Zeit & Geld
• Capabilities: 
  • Flexibilität
  • Austauschbarkeit von Teilen
  • Integrierbarkeit

... als messbare Szenarien.

ATAM 2: Lösungsarchitekturen
als Architectural Kata

ATAM 3: TradeOff-Bewertung
auf Basis der Architekturoptionen

Empfehlung: Microservics + Frontend-Monolith

Trade-Offs:

• mehr Zeitbedarf
• mehr Ressourcenbedarf
• längerer Doppel-Betrieb
• Keine Unabhängigkeit bei der Frontend-Arbeit

ARC41 1: Detailsicht auf die Lösung

DDD: Big Picture Event Storming

Bounded Contexts für den Service-Schnitt, Aggregates & ACLs für API-Design

ARC41 2: Cross-Cutting-Concepts

ARC41 3: Deployment Diagram

Das war der ein

Modernisierung & Migration

Die Strangler Fig

Das Strangler Fig Pattern in Front Controller / API Gateway / Fassade

Das Strangler Fig Pattern bei
einer Divide & Conquer Strategie aussen

Das Strangler Fig Pattern mit
API für Zugriff auf interne Funktionalität

Extraction mit Feature Toggle

Parallel Run als Kompabilitätscheck

Und viele mehr ... 

(Ausschnitt aus unserem Miro-Workshop-Board)

Ok, aber wie komme ich von Alt nach Neu?

(Architectural) Enablers

• Modernisierungsaufgaben sind oft zu groß für User-Stories
• Architectural / Infrastructure Enablers aus SAFe 
• Epics, die für zukünftige Business-Anforderungen benötigt werden.

Enabler im Architectural Runway

• Schrittwiese Implementierung der Zielarchitektur
   
• Implementierung der Migrationsdienste - etwa der Strangler-Proxy.
   
• Aufräumarbeiten - Abbau von alter und temporärer Infrastruktur.

Opportunistische Roadmap

• Enabler werden unmittelbar nach der Implementierung genutzt
• Erlaubt parallele Bereitstellung von Business-Requirements
• Verringert Doppel-
  implementierungen

Tracking & Prediction

• Die alte Software ist alt und unvorhersehbar
• die neue Platform ist noch unbekannt 
• Wie teuer wird es und wann wird es fertig?
• Nur die Volatität ist verlässlich :-/

Organisation

Die Organisation bis hier erzeugt die Architektur, die jetzt da ist. Also drehen wir das ganze um?

Das Modernisierungs-
Dilemma

• Die Plattform existiert noch nicht
  • es fehlt die neue Infrastruktur
  • es fehlen Services und Beispiele, die sie nutzen
• Die alte Plattform muss auch weiterbetrieben werden
• Die Kollegen kennen die neuen Technologien noch nicht

Ok, und was machen wir da? 

Team Topologies for the Rescue!

Build-run-Teams

• Sowohl Feature als auch Component-Teams
• Volle Verantwortung für alle Features von einer Komponente
• Nur auf Basis von Micro/Mini-Service-Architekturen machbar
• Kann weitgehend autark agieren - von GUI zu Deploy
• Mit den anderen Komponenten
  wird über APIs geredet.

Platform Team

• Eigenständiges Team, das sich um Auswahl, Aufbau und Konfiguration des Basissets von Werkzeugen und Praktiken, die von allen Teams genutzt werden, kümmert.
• Selbst ein Built-Run-Team für die Platform.
• Fokus ist sowohl Stabilität der Platform als auch Performance und Arbeitserleichterung für die anderen Teams

Service Delivery

Technical Consulting /
ENABLING Teams

• Cross-Cutting zu stream aligned teams
• bandwidth to research
• develop tools, methodologies etc

Enabling Teams

• sind in kontinuierlichem, regelmäßigem Kontakt zu Teams
• bei Bedarf auch Teil der Teams
• sorgen dafür, dass zukünftige Probleme rechtzeitig mit Tooling, Methoden und Ansätzen gelöst werden können 
• stützen den Technology Lifecycle im Teams
• erlaubt es, neue und komplexe Technologien zu verstehen und einzusetzen
  • Training, Workshops, HandsOn-Kooperation

COMPLICATED SUBSYSTEMS

COMPLICATED SUBSYSTEMS

• Legacy-Systeme sind komplexe Subsysteme!
   
• Verteilen über mehrere Teams?
• Als Teilaufgabe in einem Team?
• Als Feature-Thema in einem Feature-Team?

Schritt 1: Core Team

• Das erste Team für die neue Platform
• Drei Deliveries: 
  • die neue Platform
  • Architektur und Beispiele 
  • Bootcamp, Onboarding & Schulung
• HandsOn-Aufbau der neuen Plattform
• Geht später in Platform-Team und BR-Teams auf.

Platform- und Built-Run-Team integriert.

Artefakt 1: MVP Platform

• Wird vom Core Team gebaut
• Sobald es von anderen nutzbar ist können auch andere Teams darauf aufsetzen
• nach ca 2 Monaten vorhanden
• 20%-40% der finalen Plattformfeatures
• Experimente und PoC gehören dazu.

Start

Legacy Software

Core-Team

Monolith

Platform-
MVP

Erster Service

Ramp-Up

Core-Team

Platform Team

Stream Aligned
Built & Run-Team

Stream Aligned
Built & Run-Team

Stream Aligned
Built & Run-Team

Platform-
MVP

Erster
Service

Zweiter
Service

Platform Team

Stream Aligned
Built & Run-Team

Stream Aligned
Built & Run-Team

Stream Aligned
Built & Run-Team

Platform-
MVP

Erster
Service

Zweiter
Service

Platform Team

Stream Aligned
Built & Run-Team

Stream Aligned
Built & Run-Team

Stream Aligned
Built & Run-Team

Platform-
MVP

Erster
Service

Zweiter
Service

Legacy Software

Monolith

Platform Team

Stream Aligned
Built & Run-Team

Stream Aligned
Built & Run-Team

Stream Aligned
Built & Run-Team

Platform-
MVP

Erster
Service

Zweiter
Service

Legacy Software

Monolith

Migrate

Strangle

Aufgaben 

• Basisknowhow bereitstellen ( gerne extern ;-) )
   
• Training jeweils direkt vor der Anwendung
   
• Fokus auf Developer Experience - Golden Paths mit Tutorials etc
   
• Perspektive und Plan für die Legacy-Teams bereitstellen

Antipattern

• Modernisierungs-Almosen statt Modernisierung
   
• Death by Feature Freeze
   
• Death by Business Value
   
• Opportunistischer Dauerläufer

Noch Fragen?

Wir haben zumindest schon vieles falsch gemacht und daraus gelernt :-)