Migriert man noch mit dem Spotify-Modell den Monolithen zu MicroServices oder bedient die serverlose Architektur schon das IoT? Wieviele Inverse Conway-Maneuvres braucht man eigentlich, um die papiergetriebene Marketing-Abteilung crossfunktional zum Security-neurotischen Betriebsteam zu bekommen? Gute Ratschläge für die zukünftigen Anforderungen und E-Commerce-Architekturen gibt es viele - aber welche ergibt im eigenen Fall Sinn? Ein Versuch, etwas Klarheit und Übersicht zu schaffen, die konkurrierenden Strategien und ihre Voraussetzungen und Rahmenbedingungen vorzustellen und Wege aufzuzeigen, die passende Architektur zu finden.
2. Johann Hartmann
Founder/CTO @ http://mayflower.de
Ich kann gar kein E-Commerce.
Eher Architektur, Security, Agile, DevOps und so.
Hi!
Ich bin Johann, seit 20 Jahren als Founder/CTO bei Mayflower unterwegs. Vielleicht kennen uns noch ein paar Leute aus PHP-Zeiten, da haben wir damals mit
angefangen. Wir sind immer noch sehr nerdig unterwegs, sind ziemlich gut in agilen Dingen.
Ich selbst kann gar kein E-Commerce, sondern ein klassischer CTO mit Development, Architektur, Security, Agile, Devops und co im Fokus.
3. @johannhartmann
http://blog.mayflower.de
In der Praxis bin ich trotzdem oft dabei, in Architektur
und Organisation, von PHP3-Monolithen über Scala-
Mikroservices zu Serverless in agilen Organisationen.
Trotzdem bin ich oft dabei, weil die Teams alles mögliche machen, da haben wir die volle Palette - von PHP-Monolithen, die inzwischen den Führerschein machen dürfen
über grössere Scalabasierte MicroService-Architekturen bis zu Serverless-Architekturen in Startups.
4. Architektur klassisch …
ARC42
ATAM
Agile Modelling, Event
Storming
Agile Methoden, DevOps
Agile Organisation
Meistens machen wir da Workshops, die auf den klassischen Ansätzen beruhen um zu einer guten Architektur zu kommen. Ein bisschen kooperativer, aber eigentlich
ganz normal.
Also: die typischen verdächtigen, auf die man in einem Buzzword Bingo in dem Kontext setzen würde.
5. Vor 10 Jahren:
Wieso? Ist doch gelöst?
Client
(Internet Explorer)
Server
(Apache + PHP
oder Java-Kram)
Datenbank
(MySQL oder
Oracle)
E-Commerce vs
Architektur …
Mich hat das verblüfft, weil für mich als aussenstehenden war E-Commerce ein gelöstes Problem.
6. E-Commerce heute:
ChatBots, Conversational Commerce
Personalisierung, Intent Recognition
Machine Learning, AI
MicroServices, Serverless
API-Driven, MarketPlaces
DataStreams & Lakes
Und auf einmal reden die von Chatbots, von Conversational Commerce, von echter Personalisierung mit viel Intelligenz drin, von Intent Recognition und damit
notwendigerweise auch von Machine Learning mit AI drin, von Services, Serverless, API-driven Clouds, Datastreams und -lakes.
7. Und ich dachte nur: seit wann machen die denn auch so schlimm Buzzword Bingo? War das nicht bisher der Job von uns Consultancies?
8. Volatility
Uncertainty
Complexity
Ambiguity
Und die Manager dort sagten mir dann: Ja, sorry, wollten wir auch nicht, müssen wir bloss.
Unser Business läuft immer schneller, dafür ist es aber immer unsicherer und komplexer. Hey, ich war gerade auf einer E-Commerce-Konferenz, auf der sie die ganze Zeit
über Voice-Commerce geredet haben. Und ich habe Angst, dass das genau so ein durchschlagender Erfolg wie QR-Codes oder Beacons wird.
10. Wer kennt dieses Logo? Genau, jeder der hinreichend freie Zeit auf seinem Handy verbringt.
11. November 2015 Hackathon, 48 Stunden zum Prototypen
Dezember 2015 Release im Apple AppStore
März 2016 Android-Release
März 2016 20.000.000 Installationen
März 2016 Für $$$ von Facebook gekauft
Dieses TOOL ist in einem 48-H-Hackathon Ende November 2015 entstanden. Den Prototypen fanden sie gut, deshalb ging dann die erste offizielle Version im Dezember
ins Apple Appstore. Und da fanden Millionen von Leuten gut, deshalb kam noch eine Android-Version dazu, im März. Bei der Gelegenheit haben sie dann auch gleich
20.000.000 Installation vollgemacht und das ganze für ebenfalls diverse Millionen an Facebook verkauft.
12. Zeitraum zwischen
Idee und
20.000.000 Nutzern +
Facebook-Kauf:
4 Monate.
Das muss man sich mal auf der Zunge zergehen lassen. In 4 Monaten vom Hackathon zu eine Millionenfachen Installationsbasis und zum Exit. Und das ist nur ein
Beispiel, davon gibt es sehr viele. Internet, mobile Apps und globale Vernetzung beschleunigen alles.
13. Anforderungen an
Architektur 2018:
Mehr umsetzen, dafür
aber schneller und nachhaltig.
Also habe ich sie jeweils gefragt: ok, was soll die Architektur denn können?
Und sie so: Mehr Features liefern. Und viel schneller. Und zwar beides, auf Dauer.
14. Ok, sonst noch was?
Höhere Komplexität,
die wenig kostet und sich
schneller verzinst.
Ok, dachte ich, also was in Richtung MicroServices. Bekommen wir schon hin. Was denn sonst noch?
Und sie sagten: ich brauche eine Architektur, die deutlich mehr Komplexität abkann, wenig kostet und sich schneller verzinst.
18. … und bitte dafür die
richtige Organisation
Agil! Kanban! SAFe! LESS!
Cross-Funktionale Teams
DevOps Walls & Journeys
Scrum Folklore
Product Owner und Developer
MicroService-Fähige Unternehmen
Inverse Conway Maneuvre
19. Ok, was sagen denn
Konferenzen und Blogs dazu?
MicroServices! Alle machen MicroServices!
Nein, Monolith First!
Besser MacroServices! Self Contained Systems!
Wenn schon: Reactive MicroServices!
Oder gleich Serverless gehen!
Off-The-Shelf Shop! Of-The-Shelf-Framework!
E-Commerce-Cloud!
Gucken wir doch mal, was der Rest der Welt so sagt. Martin Fowler, Sam Newman, AWS und so.
20. Inverse Conway! Komponenten-Teams nach Spotify-Modell!
Nicht das Spotify-Modell kopieren!
Feature-Teams mit LESS/SAFe/Nexus/Scrum@scale!
SAFe is Waterfall
DevOps! Die Mauer muss weg!
Scrum! Agile!
Scrum/Agile is dead!
Finde Deinen eigenen Weg mit Kanban!
Ah, und wie organisiere ich das?
Ok. und wie organisieren die das?
22. Und in der Praxis?
Die Beispiele wurden angepasst
um das Leben Unschuldiger
zu schützen
Gucken wir doch mal auf die Praxis, wie werden da diese Problemstellungen gelöst?
25. Spotify Everywhere
… bei 6 Developern
… mit einem Legacy-
Monolithen als
CodeBase
Und agile Spotify-Modelle an allen möglichen Stellen, von der Anwendung auf 6 Entwickler bis zum Versuch, dass mit zwar vielen Entwicklern, aber einer zähen,
monolithischen Legacy-Codebase zu machen.
26. Technologiewahl
Wir machen X weil…
(Rust, Elixir, Haskell, Clojure, ReasonML, Luna)
… wir da mehr Leute finden
… sonst der Kollege geht
… bei MicroServices jeder das
selbst entscheidet
Und, auch gerne gesehen, einen bunten Technologiezoo, weil die Architektur vollständig dezentralisiert wurde.
27. Ok, dann wäre also der
richtige Ansatz …
Choose Boring Technology!
PHP-Off-The-Shelf -Shop + Plugins!
Frontend/Backend-E-Commerce-OS!
SAAS-Commerce
Flexibilität durch eigenen Monolithen!
MicroServices! Und zwar Reactive!
MacroServices/SCS! Weniger Disruptiv!
Serverless!
28. There is no silver bullet.
Ok, offensichtlich ist da keine Silver Bullet, keine Universallösung, auf die wir uns fix verlassen können.
29. "No Silver Bullet – Essence and
Accident in Software
Engineering"
Wir Softwareleute kennen die Formulierung vor allem von Fred Brooks, der sie 1986 in einem sehr suprigen Essay veröffentlicht hat. Der hiess „No Silver Bullet - Essence
and Accident in Software engineering“
30. "No Silver Bullet – Essence and
Accident in Software
Engineering"
Wichtig sind dabei vor allem die Begriffe Essence und Accident, dort hat er nämlich das Konzept von Essential und Accidental Complexity eingeführt, das auch die
Domain Driven Design Jungs gerne nutzen.
32. Essential Complexity
Komplexität, die unabhängig von
der Implementierung da - und damit
unvermeidbar ist.
Bei 19% Mehrwertsteuer gibt es irgendwo eine
Multiplikation mit 0,19 oder 1,19.
Achtung: schlecht benannt :-/
Essential Complexity, das ist die Komplexittät, die schon da ist bevor wir einen Handschlag gemacht haben. Die müssen wir auf jeden Fall liefern.
Eigentlich ein Misnomer, weil McCabe den Begriff schon für Ablaufkomplexität nutzt - kennt jemand zyklomatische Komplexität? Ja, genau, das ist auch essential
complexity, aber die andere.
33. Essential Complexity
User Experience / Journeys
Workflows
Eingaben, Ausgaben
Externe Schnittstellen
Externe Constraints
Konkret stehen dahinter Themen wie User Experience, Workflows, Eingaben und Ausgaben, Externe Schnittstellen und Constraints.
34. Essential Complexity
Essential Complexity kann nur durch
Featureverzicht reduziert werden.
Da ist es klar, dass es nur eine Strategie gibt, die Essential Complexity zu reduzieren. Weniger Features.
35. Essential Complexity ist
kontinuierlich in Bewegung
Jedes Bild von Essential Complexity
ist eine Hypothese
Ob es eine gute war erfahre
ich bei der Nutzung
Innovation ist neue Essential Complexity
Und weil es sich um Features handelt, ist die Essential Complexity auch nicht verbindlich - sondern nur eine Hypothese, mit jeder Implementierung und Nutzung ändert
sie sich.
37. Accidental Complexity
Die Komplexität, die durch die
Umsetzung entsteht.
Mehrwertsteuer-Beispiel:
In Excel: ein Formelfeld
In Assembler: 10 Zeilen
Als MicroService: auch 10 Zeilen :-)
Achtung: auch schlecht benannt :-/
Das ist die Komplexität, die wir brauchen, um Software zu erzeugen.
Achtung: Accidental heisst hier nicht ausversehen, sondern eher „der Realität geschuldet.“.
Die Accidental Complexity will kein Kunde, und sie ist - je nach Architektur - unterschiedlich gross für ein bestimmtes Problem der Essential Complexity.
39. Accidental Complexity
Wir liefern Essential Complexity
durch Erzeugen von Accidental
Complexity.
Architekturen sind Sets von Strategien
wie ich Essential Complexity mittels
Accidental Complexity umsetze.
Wir wollen also die Essential Complexity bedienen, und erzeugen auf dem Weg Accidental Complexity. Das ist nicht zu vermeiden.
40. Unser Job in einem Diagramm
Essential
Complexity
Code
Accidental Complexity
Marktfeedback/Innovation
In einem Diagramm: wir haben eine Vermutung über die Essential Complexity, setzen die um - und dabei entsteht Code und damit zwangsläufig Accidental Complexity,
und mit dem Code bekommen wir Feedback - in Form einer Validierung, einer Invalidierung oder neuer Ideen.
41. Essential
Complexity
Code
Accidental Complexity
Marktfeedback/Innovation
Essential Complexity:
Der Nutzer weiß, was sein Problem ist.
Der UXler weiß, wie man das in User Journey kippt.
Der Business Analyst weiß, was die Fachdomain braucht.
Accidental Complexity:
Der Entwickler weiß, wie man das implementiert.
Der Admin weiß, wie man das zur Verfügung stellt.
Das Wissen um die Essential Complexity ist verteilt. Der Nutzer kennt sein Problem und seine Weltsicht, der UXer weiß, wie man es darstellt, der Business Analyst weiß,
was die Fachdomain braucht.
Für die Umsetzung in Code braucht es dann Entwickler, die die Essential Complexity implementieren - und dazu Accidental Complexity als notwendiges Byprodukt
erzeugen.
42. Damit der Loop funktioniert
brauche ich dieses Wissen geteilt.
Essential
Complexity
Code
Accidental Complexity
Marktfeedback/Innovation
Damit ich die notwendigen Hypothesen richtig bekomme brauche ich für diesen Loop das Wissen geteilt.
Netterweise haben die Psychologen sich die Mühe gemacht mal aufzudröseln, was geteiltes Wissen konkret ist.
44. Equipment Model:
Technologie und Ausrüstung, und
wie man damit umgeht.
=> Accidental Complexity
Shared
Mental
Models
Das erste shared mental Modell ist das Equipment Model. Das ist die Technologie und Ausrüstung und deren Nutzung - also in unserem Fall all die Werkzeuge und aller
Code und alle Konfiguration, die wir auf dem Weg zur Lösung des Problems einsetzen.
Es deckt sich also weitgehend mit dem, was Fred Brooks „Accidental Complexity“ nennt.
45. Task Model:
Was wollen wir und wie kommen
wir dahin?
=> Essential Complexity
Shared
Mental
Models
Daneben gibt es das Task Model - was will ich eigentlich erreichen, und woran merke ich, dass es funktioniert hat.
Hier sind wir fast deckungsgleich mit der Essential Complexity, die Fred Brooks beschreibt.
47. Shared
Mental
Models
Team Model:
Welche Fähigkeiten, Stärken,
Schwächen haben Kollegen?
=> Wissensverteilung
Essential
Complexity
Code
Accidental Complexity
Marktfeedback/Innovation
Und nicht zuletzt gibt es noch das Team Model, mein wissen, das ich über die anderen habe.
49. Die gute Nachricht:
Wir können mehr als 5000 Details
im Blick haben
Mental
Models
Das coole an den mentalen Modellen: da sind wir deutlich besser als das durchschnittliche neuronale Netz.
Im Equipment Model halten wir zB mehr als 5000 Details vor, die wir gleichzeitig berücksichtigen können.
51. Neuer Code
Bestehenden Code ändern
Analyse von bestehendem Code
Deshalb müssen wir die
ganze Zeit über nachschlagen.
Deshalb müssen wir auch die ganze Zeit nachschlagen, und lesen viel mehr Code als dass wir schreiben. Weil wir nicht alles, was wir bräuchten, gleichzeitig im Kopf
haben könnten.
53. Die Vorhersage unseres mentalen Modells
und das tatsächliche Verhalten der
Accidental Complexity stimmen nicht überein.
„Bug“
Essential
Complexity
Code
Accidental Complexity
Marktfeedback/Innovation
54. Die Accidental Complexity ist der
Essential Complexity nicht angemessen und
braucht damit unnötig viel mentales Modell.
„Technical Debt“
Essential
Complexity
Code
Accidental Complexity
Marktfeedback/Innovation
55. Die Accidental Complexity ist so gross, dass
seriöse Vorhersagen über die Software mit
humanoiden Hirnen nicht mehr möglich sind.
„Big Ball of Mud“, „Spaghetti Code“
Essential
Complexity
Code
Accidental Complexity
Marktfeedback/Innovation
56. Wir reduzieren die Accidental Complexity bei
gleicher Essential Complexity, damit wir
weniger mentales Modell brauchen.
„Refactoring“
Mental
Models
57. Wir zerlegen die Accidental Complexity in
Teile, deren mentales Model gut handhabbar
ist.
Wir bieten für die Kommunikation mit den
Teilen ein stark vereinfachtes Modell an.
„Modularisierung“, „APIs“
Mental
Models
58. Wir organisieren unsere Firma nach den
unterschiedlichen Typen von Accidental
Complexity, ohne die Essential Complexity
oder Shared Mental Models dabei zu
berücksichtigen.
„Funktionale Organisation“
Mental
Models
59. Wir organisieren uns so, dass Essential und
Accidental Complexity sich in einem Shared
Mental Model finden.
„Cross-Funkionale Teams“
Mental
Models
60. Die Accidental Complexity entsteht aus dem
Shared Mental Model, und das entsteht durch
die Interaktion.
„Conways Law“
(Die Organisation bestimmt die Architektur)
Mental
Models
61. Ok, Johann.
Schön, dass Du soviel Freude an Theorie hast.
Was ist jetzt mit Architektur
und E-Commerce?!
Mental
Models
62. Accidental Complexity:
wo Architektur stattfindet
Jede Architektur ist ein Set von Strategien
zur Umsetzung von Essential Complexity.
Sie kann jeweils mit einigen Arten von Essential
Complexity gut umgehen, mit anderen nicht.
Architektur und gemeinsame mentale Modelle
ergeben sich gegenseitig.
64. Off the Shelf-Shop
PIM, Plugins etc
Betrieb
Konfiguration
Accidental Shop
Essential Shop
Bei Standardaufgaben
wenig Aufwand,
meist nur
Konfiguration
und Betrieb …
65. Off the Shelf-Shop
PIM, Plugins etc
Interne Komplexität:
Essential & Accidental
API
Konfiguration
… weil mir die APIs und
die Konfiguration viel
Accidental Complexity
abnehmen.
66. Off the Shelf-Shop
PIM, Plugins etc
Interne Komplexität:
Essential & Accidental
API
Konfiguration
Wenn der Standard nicht reicht …
…steigt
Knowhow-Bedarf
Accidental Complexity
deutlich
67. Off the Shelf-Shop
PIM, Plugins etc
Skalieren
Flexibilität
neue Clients
Wenn der Standard nicht reicht …
…steigt
Knowhow-Bedarf
Accidental Complexity
deutlich
68. Proprietäre Lösung
mehr Flexibilität mit
„Not invented here“
Interne Komplexität:
Essential & Accidental
für meinen Business
Nur die
Accidental Complexity,
die ich selbst brauche.
69. Off the Shelf-/Proprietary Shop
0
35
70
105
140
Jahr 1 Jahr 2 Jahr 3 Jahr 4
Essential Complexity Accidental Complexity
70. Off the Shelf-/Proprietary Shop
Mit kontinuierlichem Refactoring
0
35
70
105
140
Jahr 1 Jahr 2 Jahr 3 Jahr 4
Essential Complexity Accidental Complexity
71. Off the Shelf-Shop
Ohne Refactoring
0
35
70
105
140
Jahr 1 Jahr 2 Jahr 3 Jahr 4
Essential Complexity Accidental Complexity
72. Off the Shelf-/Proprietary Shop
Mit kontinuierlichem Refactoring
0
35
70
105
140
Jahr 1 Jahr 2 Jahr 3 Jahr 4
Essential Complexity Accidental Complexity
1 Team
73. Scaling Fallacy:
„Large Systems are like small systems, just bigger.“
Kontinuierlich …
sinkender Featuredurchsatz
mehr Bugs oder QA-Aufwand
langsameres Einlernen
Und damit optimiere ich nicht die 2% meiner Arbeit, sondern die 80%. Ich spare mir das Recherchieren.
74. E-Commerce Platform/
Modularer Monolith
Frontend-Layer
Backend-Layer
Other
Clients
Skalieren
Flexibilität
neue Clients
REST
75. E-Commerce Platform/
Modularer Monolith
Frontend-Layer
Other
Clients
REST
Modul
API
Modul
API
Modul
API
Modul
API
Reduktion der
Accidental
Complexity.
80. MicroServices sind ein Architekturmuster
der Informationstechnik, bei dem komplexe
Anwendungssoftware aus kleinen,
unabhängigen Prozessen komponiert wird, die
untereinander mit sprachunabhängigen
Programmierschnittstellen kommunizieren.
Die Dienste sind klein, weitgehend entkoppelt
und erledigen eine kleine Aufgabe.
Context
API
Context
API
Context
API
Das ist die offizielle Definition, inzwischen - die von Herrn Bezos unterscheidet sich inzwischen deutlich. Das ist alles darauf ausgelegt, dass man es
einfach ändern kann!
Kleine, unabhängige Prozesse! Sprachunabhängige Schnittstellen! Kleine, entkoppelte Dienste! Immer nur kleine Aufgaben!
82. Die Dienste sind klein, weitgehend
entkoppelt und erledigen eine
kleine Aufgabe.
Dann habe ich doch gar kein
Problem mehr mit zu grosser
Complexity, oder?
83. Die Essential Complexity ist zwar
pro Service klein, aber verstreut.
Man muss selbst für eine
integrierte Sicht sorgen - zB
über eine gemeinsame (stream-
based) Data Architecture,
ML & co.
Big Data, Streams, Correlation IDs,
Paradoxon: ich brauche losgelöste Daten pro Service, aber gemeinsame Daten fürs lernen.
Das ist der Grund, warum man im Moment nicht um Kafka & Co herumkommt.
86. https://www.slideshare.net/adriancockcroft/goto-berlin
Wir haben sie dorthin verschoben,
wo sie besser automatisierbar ist.
DevOps, SREs, Infra-Teams sind
Strukturen zum Umgang damit.
Die Accidental Complexity sind wir nicht los, sie findet nur auf einem anderen Level statt.
Das gilt nicht nur für das Deployment, für den Application Lifecycle, sondern auch für Fail-Over, Versionierung, Security,
89. Serverless / FAAS
Outsourcen der Accidental Complexity!
Innerhalb der Funktion habe ich
wenig Accidental Complexity.
Resultat:
Schnelle Entwicklung
Preiswerte Wartung
90. Serverless: der Powerbuilder der Neuzeit?
ähnliche Strategien kennen wir schon:
Powerbuilder
Excel, Access
SAP
Resultat:
Vendor Lock-in
viel Flexibilität erzeugt viel
Basisknowhow
93. Ok, und was mache ich jetzt?
Die Architekturstrategie, mit der
ich die Gesamtkomplexität
am besten im Griff habe.
0
35
70
105
140
Jahr 1 Jahr 2 Jahr 3 Jahr 4
Essential Complexity
Accidental Complexity
94. Ok, und was mache ich jetzt?
… mit der Organisationsform,
die den Lern-Zyklus am besten
abbilden kann.
Essential
Complexity
Code
Accidental Complexity
Marktfeedback/Innovation
95. Danke!
Ich mag keine Checklisten und
„in 3 Schritten“ zum Erfolg.
Aber andere Leute. Deshalb:
Dieses Slidedeck hat noch 55 Slides mit
Standardarchitekturmustern & Bewertung,
dazu Architekturentscheidungs- und
Umsetzungsstrategien.
Slides: http://slideshare.net/johannhartmann
Kommentare und Fragen gerne an:
96. Typische Architekturen
für E-Commerce 2017ff
E-Commerce vs Architecture
Wenn man sich anschaut, welche Architekturen tatsächlich in Frage kommen bei E-Commerce in 2017, dann findet man praktisch immer eine Abart der folgenden:
97. Off-The-Shelf-Framework/Shop
E-Commerce vs Architecture
Beschreibung
Standardsoftware aus dem E-Commerce-
Bereich mit Modul-APIs
Verbreitung Standardlösung für kleine Online-Shops.
Stärken
Initiale Time2Market, existierende Plugins/
Bundles, Skalierfähigkeit, Einarbeitung
Schwächen
Maintenance proprietärer Teile hoch,Vendor-
Lockin, Mittelfristige Wartungskosten hoch
Organisation
bis zu einem Team, kleine Anforderungen an
Betriebs & Development-Infrastruktur
Prozess
Anforderungsmanagement vs. Shop-
Capabilities erfordert Shop-Knowhow
Das off-The-Shelf-Framework, irgendwo zwischen Shopware und Spryker.
98. Moderner Monolith
E-Commerce vs Architecture
Beschreibung
Eigenentwicklung auf Basis von DI-
Framework, DDD-Konzepten etc.
Verbreitung State of the Art für mittlere Shops.
Stärken
Hohe Flexibilität, hohe Integrationstiefe &
Prozessoptimierung möglich
Schwächen
Initiale Kosten hoch, zunehmend schlechte
Time2Market, Maintenance-Kosten hoch,
Einarbeitung aufwändig
Organisation
bis zu einem Team, mittlerer Ops-Support,
eigene Dev-Struktur erforderlich
Prozess
Agiler Entwicklungsprozess mit XP & Clean-
Code-Techniken
Der proprietäre, aber moderne Monolith, der gute Wartbarkeit verspricht.
99. MicroServices
E-Commerce vs Architecture
Beschreibung
Eigene und fremde MicroServices ergeben
zusammen die Applikation
Verbreitung State of the Art für grosse Shops.
Stärken
Gute Time2Market, hohe Skalierbarkeit,
hohe Wartbarkeit über Zeit.
Schwächen
Hohe Anforderungen an Ops,
Organisationsstruktur & Prozessreife
Organisation
Mehrere autarke Teams parallel, ab ca 20
Personen. Inverse Conway üblich
Prozess Agiler / DevOps-Prozess notwendig
Das Amazon-inspirierte MicroService-Konzept.
100. ServerLess
E-Commerce vs Architecture
Beschreibung
Services, Cloud-Plattformen und
FAAS(Lambda) ergeben die Applikation
Verbreitung Wenige Early Adopter.
Stärken
Sehr gute Time2Market für Shop &
Innovation, sehr kleine Ops-Kosten
Schwächen
Hohe Anforderungen an technologische
Reife, hoher Vendor-Lock-In
Organisation Mehrere Teams gut möglich,
Prozess
Hohe technische Kompetenz erforderlich,
hohe CloudOps-Kompetenz
Und der aktuelle Trend - mit sehr, sehr guten Ergebnissen, aber wenig Erfahrungswissen und vorhandenen Lösungsstrategien für E-Commerce-Aufgaben - Serverless
Architectures.
101. E-Commerce vs Architecture
Und Übergangsformen …
Aber nicht nur diese Formen gibt, es viele Formen in der Mitte, Kompromisse und Anleihen bei anderen Architekturen.
102. MiniServices (Gartner-Trend)
E-Commerce vs Architecture
Beschreibung
Adaption von MicroServices mit weniger
Disruption / Anforderungen lt. Gartner
Verbreitung Beginnender Trend im Mainstream
Stärken
Nachhaltige Time2Market, mittlere Kosten,
mittlere Anforderungen
Schwächen
Time2Marketing niedriger als bei
MicroServices, Legacy möglich
Organisation Mehrere Teams möglich
Prozess
Agiler Entwicklungsprozess mit XP & Clean-
Code-Techniken
Ein erwähnenswertes Beispiel sind die „MiniServices“ wie Gartner sie nennt, oder auch Polylithen oder MacroServices genannt. Diese Services sind deutlich näher am
ursprünglichen Konzept von Amazon orientiert und deutlich größer als das, was heute üblicherweise Mikroservices genannt wird.
Von Gartner werden sie für die Firmen empfohlen, für die ein moderner Mikroservice-Ansatz zu disruptiv ist.
103. Wie man eine Architektur
in 5 Schritten ändert.
Auf Basis von
http://www.arc42.de/,
denn wir sind in Deutschland.
(Und klar kann man das auch anders machen)
E-Commerce vs Architecture
Aber wie komme ich zu so einer Architektur? Schliesslich hat man meist schon eine, und die verdient auch schon Geld. Man kann nicht auf der grünen Wiese starten.
Und überhaupt: die bestehende Architektur funktioniert schon, die neue müsste es erst nachweisen. Wie komme ich dahin?
104. Lösungsstrategie
• Technologien
• grundlegende
Entscheidungen
• Lösungsideen
1.
Der erste Schritt ist das erkennen der geeigneten Lösungsstrategie. Mit Lösungsstrategie ist vor allem der grundlegende Ansatz für die Architektur gemeint - also zB
MicroServices vs Monolith selbst. Es sind auch bereits die Lösungsideen für diverse Fragestellungen implizit enthalten, etwa für synchrones / asynchrones Verhalten, die
verschiedenen Varianten der Storage-Strategie uvm.
105. Die Lösungsstrategie hängt an den
Geschäftsanforderungen
der nächsten 5-10 Jahre.
(den bekannten und den unbekannten)
E-Commerce vs Architecture
1.
Welche Lösungsstrategie die richtige ist hängt vor allem von den Geschäftsanforderungen der nächsten 5-10 Jahre, sprich: der Lebenszeit einer typischen Architektur -
ab. Natürlich wird sich diese Strategie mit der Zeit ändern, nicht nur das, sie muss heute in der Lage sein sich ändern zu können. Genau das selbst ist zB eine der
Geschäftsanforderungen der nächsten Jahre.
106. Vorbereitung
E-Commerce vs Architecture
1. Aufgabenstellung
Qualitätsziele
Architekturrelevante (nonfunktionale)
Anforderungen
Randbedingungen
Kontext
Um nicht nur in die Glaskugel zu schauen ist es wichtig, die vorhandenen und wahrscheinlichen Fälle sichtbar zu bekommen. Und nicht nur das - es ist auch wichtig, ein
gemeinsames Verständnis über diese Faktoren zu haben. Folgende Punkte möchte wir klar haben, um überhaupt bewerten zu können, ob eine Architektur ihren
Anforderungen gut oder schlecht genügt:
- die Aufgabenstellung der Architektur - welches Problem soll gelöst werden?
- die Qualitätsziele: welche Verlässlichkeit brauchen wir? Skalierbarkeit? Erlernbarkeit? Adaptierbarkeit? im englischen nennt man diese Fähigkeiten -ilities, im deutschen
also grob -…barkeiten
- die nonfunktionalen Anforderungen: was muss integriert werden, welche Vereinbarungen sind einzuhalten und vieles mehr
- die Randbedingungen - welche Gesetze gelten, auf welche bestehende Dinge muss aufgesetzt werden etc
- der Kontext - welchen Teil der Gesamtarchitektur wollen wir überhaupt anschaue? Wo ist die Grenze unserer Architektur?
107. Vorbereitung
1.
Im ATAM-Workshop
als Szenarien gesammelt.
Aufgabenstellung
Qualitätsziele
Architekturrelevante (nonfunktionale)
Anforderungen
Randbedingungen
Kontext
Dazu nutzen wir - und viele andere - meist einen ATAM-Workshop. ATAM - lang „Architecture TradeOff Analysis Method“.
Dieser Workshop sammelt alle relevanten Parameter und bringt sie in ein Format, das von Geschäfts- und Technikseite verstanden wird, in konkrete Szenarien für die
Zukunft, die man messen kann.
An diesen Szenarien entlang werden dann verschiedene wahrscheinliche Architekturoptionen beleuchtet und auf Eignung bewertet.
108. Architekturanforderungen
1.
Im ATAM-Workshop
als Szenarien gesammelt.
„Kann chinesisch und Stripe Payment .“
Wichtig bei diesen Szenarien ist, dass hier nicht die funktionalen Anforderungen im Vordergrund stehen. Das machen wir Entwickler viel zu gerne, weil uns dazu immer
gleich eine Lösung einfällt. Es kommt also nicht darauf an, dass man chinesisch als Sprache implementieren kann. Es kommt auch nicht darauf an, ob der Shop Stripe
Payment integrieren kann.
109. 1.
Das können alle Systeme,
die Turing-Vollständig sind.
„Kann chinesisch und Stripe Payment .“
Architekturanforderungen
Das kann, wie jeder Informatiker gelernt hat, jedes Turing-Vollständige System. Deshalb hilft mir das nicht bei der Architekturbewertung - denn jede Funktion kann von
jeder Architektur geliefert werden. Und ja, bei manchen ist ist sehr einfach möglich, und bei anderen Architekturen schwieriger. Aber da kommen wir zur richtigen Frage
…
110. 1.
„Was das Business wirklich will.“
„Wenn die neue Architektur umgesetzt ist
kann eine neue Sprache mit 2 Wochen
Entwicklungsaufwand umgesetzt werden.“
Architekturanforderungen
Nämlich der, die das Business interessiert. Es ist ganz natürlich, dass die Stakeholder vor allem zwei Qualitätsanforderungen auf dem Radar haben - Kosten und Zeit.
Und die sollte man tatsächlich explizit machen, sowohl in den kurz- als auch langfristigen Effekten.
111. 1.
„Wenn die neue Architektur umgesetzt ist
gibt es in den ersten 5 Jahren keine kritischen
Sicherheitslücken mehr.““
Architekturanforderungen
„Was das Business wirklich will.“
Andere typische Themen sind Security, aber auch die Medium Time to Recovery und vieles anderes.
112. 1.
„Wenn wir den 1.1.2019 haben ist kein Teil der
alten Architektur mehr im Einsatz.“
Architekturanforderungen
„Was das Business wirklich will.“
Und natürlich ist die Modernisierung selbst auch eine Frage, über die man mit dem Business selbst eine gemeinsame Meinung bilden möchte. Wie lange wird
modernisiert? Wieviel darf das ganze kosten? Wann wird nur noch eine Software zu warten sein?
113. 1. Architekturanforderungen
„Was das Business wirklich will.“
Wenn Entwickler diese Liste sehen werden meist ihre Grundängste getriggert .
„Jetzt wollen die wieder das eierlegende Wollmilchschwein, und ich bekomme nachher die Schuld, dass es das gar nicht geben kann.“
114. 1. Architekturanforderungen
„Was das Business bekommen kann.“
Deshalb: TradeOff. Es gibt nicht alles.
Konkret: klare Priorisierung durch die
Unternehmensleitung.
Deshalb wird das ganze im Rahmen einer TradeOff-Analyse gemacht - sprich: die Kompromisse werden explizit gemacht, und noch wichtiger: es wird auch gesagt, was
es nicht geben wird, weil es in dieser Kombination so nicht existiert.
115. 1. Architekturvarianten
Es werden mehrere typische Varianten
auf dieser Basis gegeneinander bewertet.
ARC42: Explain why you or your team took certain decisions.
The “why” is often more important than the “what” or “how”.
„Was das Business bekommen kann.“
Konkret werden die möglichen und wahrscheinlichen Architektur auf einer Decision-Matrix gegen diese Szenarien bewertet - welche Architektur ist gut geeignet, um das
Ziel zu erreichen, welche Architektur eher nicht.
Der Nutzen ist aber nicht nur die Klarheit der lieferbaren und nicht lieferbaren Erwartungen - er ist vor allem im gemeinsamen Bild, worum es bei der Architektur wirklich
geht - zu finden.
Die Autoren von ARC42 sagen explizit, dass das „Warum“ bei Architektur meist wichtiger als das „Was“ und das „Wie“ ist. Und genau das Warum wird im Rahmen dieser
TradeOff-Analyse für alle sichtbar und transparent, und jeder weiß, warum ich manche Architekturen besser- oder eben weniger gut - eignen.
116. 1. Lösungsstrategie
Ergebnis:
Eine gemeinsame Empfehlung
des Teams zur Lösungsstrategie.
zB „MiniServices“
Am Ende gibt es eine Empfehlung für eine Lösungstrategie. Diese Empfehlung wird von den Technikern ausgesprochen, aber sie kommt zum Preis der Kompromisse und
Risiken, die sich im Rahmen der Bewertung herausgestellt haben. Die endgültige Entscheidung trifft die Geschäftsseite auf dieser Basis. Sie hat dabei auch die Freiheit,
von der empfohlenen Strategie abzuweichen - dieses mal aber im vollen Bewusstsein der Konsequenzen dieser Entscheidung.
117. 1. Architekturanforderungen
Was wir dabei erlebt haben:
überraschende Business-Strategien
präferierte Lösung ist nicht machbar
meistens Machbarkeit > Ästhetik
90% einstimmige Resultate
30% nachträgliche Erweiterungen
Politische Anforderungen explizit
machen und einbeziehen.
Weil wir schon eine ganze Reihe dieser Workshops gemacht haben können wir auch deutlich sagen, was dort meistens passiert:
118. 1. Lösungsstrategie
7 aus 11 für ARC42:
Ziele, Randbedingungen, Kontext,
Lösungsstrategie, Entwurfsentscheidungen,
Qualitätsszenerien und Risiken
Und ein drittes Outcome ist erfreulich - mit dem Ergebnis des ATAM-Workshop haben wir 7 der 11 Bereiche der ARC42-Architekturdokumentation erschlagen. Wir haben
damit eine Grundlage geschaffen, auf der wir gut arbeiten können.
119. 2. Migrationsstrategie
Ok, jetzt weiß ich, wo ich hin will.
Aber wie komme ich dahin?
Aber damit ist nicht alles geschaffen, was ich für Architektur brauche - da fehlt mir noch der Weg, wie ich zu dieser neuen Architektur komme.
121. 2. Rewrites
Successful
Challenged
Failed
Die, wenn man einer Statistik der bekannten Standish-Group von 2012 trauen kann - funktionieren eher selten. Konkret sind sie nur in 4% aller Fälle in Time und Budget,
in knapp der Hälfte der Fälle zwar erfolgreich, aber ausserhalb von Time & Budget, und zu fast der Hälfte aller Fälle komplett gescheitert.
Rewrites als Big Bang ist etwas, was wir nicht gut können, deshalb findet es auch in der Praxis defakto nicht mehr oft statt.
122. 2. Rewrite-Strategien
Katalog von > 50 Pattern für
Code-Modernisierung
Datenmigration
Knowhowaufbau
Organisationsgestaltung
Agile / sanfte Modernisierungen
sind Mainstream.
Der Mainstream sind sanfte, agile, kontinuierliche oder schrittweise Migrationen. Weil inzwischen praktisch alle so vorgehen gibt es auch eine ganze Reihe von Mustern
und Methoden, an denen man sich orientieren kann. Zwei Beispiele greife ich mal heraus:
123. 2. Beispiele
Strangler Pattern
https://www.martinfowler.com/bliki/StranglerApplication.html
Ein bekanntes Pattern ist das Strangler-Pattern. Dort übernimmt die neue Applikation Stück für Stück die alt. Für den Kunden findet nur eine Applikation statt - er sieht
nicht, welche Teile von der neuen und welche Teile von der alten Software kommen. Am Ende, wenn alle Teile von der neue Applikation übernommen sind ist die
Modernisierung vollendet - und sie funktioniert garantiert, denn der ganze Prozess findet in Produktion statt.
124. 2. Beispiele
Event Interception
https://www.martinfowler.com/bliki/EventInterception.html
Ein zweites Pattern ist Event Interception. Hier werden Events - im Sinne von Geschäftsereignissen - abgefangen, bevor sie weiterverteilt werden. Konkret wird eine
Bestellung etwa zu einem Event- und kann damit parallel an die alte und die neue Applikation gegeben werden. Dies gibt deutliche Freiheitsgrade - ich kann so etwa
Daten synchron halten, auch wenn die Schemata und Storage-Strategien deutlich abweichen. Ich kann Teile eines Events in der alten, Teile in der neuen Software
bearbeiten. Ich kann Abhängigkeiten unabhängig lösen, ich muss nicht darauf warten, dass auch die anderen Teile „schon neu“ sind.
Es gibt noch eine Vielzahl mehr solcher Patterns, unser eigener Katalog enthält zur Zeit etwa 50.
125. 2. Welche Patterns brauche ich?
Business-Anforderungen für die
Modernisierung explizit machen
Pattern vorstellen und ergänzen
Cost-Benefit-Bewertung
Aber welche dieser vielen Pattern brauche ich? Welche sind für meine Praxis tatsächlich relevant, welche nicht? Welche könnten funktionieren, haben aber bessere
Alternativen?
Natürlich gibt es da die bekannten Methoden, die aber - zwangsläufig - nicht für jede Situation passen. Es empfiehlt sich deshalb, diese Strategie um eigene zu
erweitern, die den eigenen Anforderungen in Architektur, in Migration, in Daten und Organisation gerecht werden.
Diese Strategien werden von den Entwickler bewertet - auf Benefit und Kosten/Risiko.
126. 2. Welche Patterns brauche ich?
Cost-Benefit Matrix
Auf dieser Basis entsteht dann ein Portfolio von Möglichkeiten, und es wird das konkrete Portfolio auf dieser Basis ausgewählt.
127. 2. Welche Patterns brauche ich?
Zu jedem Pattern gehört:
Vorbereitung
Durchführende Tätigkeiten
Nachbereitung
Vorbereitung Event-Queue einführen mit APIs in AltApp
Durchführung Ereignis für Ereignis in Event kapseln.
Nachbereitung -
Jede der Migration-Methoden erzeugt an 2-3 Stellen Aufwand - bei der Einrichtung der Methode, sprich: die Infrastruktur wird geschaffen, umgesetzt und getestet - bei
der Durchführung - denn sie muss unter Umständen bei sehr vielen Features umgesetzt werden - und schliesslich bei der Nachbereitung - also bei dem Entfernen der
temporären Strukturen. Diese Aufgaben erzeugen Aufwand, ohne dass ein unmittelbarer Aufwand dahinter steht.
128. 2. Welche Patterns brauche ich?
Diese Aufgaben sind Epics, die man in Stories
zerlegen kann, die aber keinen User haben.
Es sind
„Architectural Enablers“
Deshalb nennt man sie „Architectural Enablers“ - sie werden für die Umsetzung der neuen Architektur benötigt, zahlen aber nicht unmittelbar auf User-Stories ein. Sie
sind aber sehr wohl Voraussetzung dafür, dass in Zukunft neue User Stories auf Ihrer Basis umgesetzt werden können.
129. 2. Welche Patterns brauche ich?
Emergent Architecture: Entsteht bei der
Arbeit.
Intentional Architecture: Entsteht nicht bei
der Arbeit, ist aber trotzdem mittelfristig
wertvoll.
Damit stehen wir etwas im Gegensatz zu der Architekturstrategie, die im agilen Umfeld empfohlen wird - nämlich emergenter Architektur, die im Rahmen der normalen
Arbeit entsteht, jeweils am aktuellen Problem lang. Dass dies nicht immer ausreicht zeigt schon die Tatsache, dass wir hier gerade über Modernisierungen sprechen.
Um hier zu einer besseren Architektur zu kommen brauchen wir mehr als das - wir brauchen intentional Architecture, sprich eine Zielarchitektur, auf die wir zuarbeiten.
130. 2. Welche Patterns brauche ich?
Intentional Architecture ist das
dokumentierte gemeinsame Bild der
Architektur in Zukunft.
Es ist ein Resultat gemeinsamer Arbeit und
ändert sich kontinuierlich.
Es wird bei der emergenten Architektur
genutzt, aber benötigt Architectural Enabler.
Auch bei dieser International Architecture brauche ich Architectural Enabler, die zur Umsetzung führen.
131. 2. Welche Patterns brauche ich?
„Architectural Enablers“
sind Teil des
DEEP Backlogs.
Diese Architectural Enabler sind Teil des Backlogs. Sie sind wichtig für die Umsetzung der Architektur oder der Migration, aber - wie schon gesagt - sie kein Bestandteil
einer User Story. Trotzdem haben sie eine Wichtigkeit und eine Größe, und deshalb sollten sie auch explizit Teil des Backlogs sein.
132. 3. Lösungsarchitektur umsetzen
Lösungsarchitektur aus ATAM:
vorhanden, aber unvollständig.
Mit den Migrationsthemen selbst haben wir aber noch nicht alle Architectural Enabler auf dem Radar.
Die Umsetzung der Solution Architecture, die man zum Beispiel mit dem Atam-Workshop gefunden hat, braucht ebenfalls noch Arbeit. Dies ist aber nicht so einfach zu
greifen - denn die Architektonischen Änderungen können sich auf alles mögliche beziehen, auf die Serverstruktur, auf die Teststrecke, auf die Frontend- oder
Datenbankarchitektur.
133. 3. Lösungsarchitektur umsetzen
4 aus 11 für ARC42:
Bausteinsicht
Deploymentsicht
Cross Cutting Concerns
Deshalb nutzen wir für die Umsetzung die übrigen Punkte aus Arc42: die Bausteinsicht, die Deploymentsicht und die Cross Cutting Concerns. Eigentlich gibt es hier noch
eine Runtime-Sicht, oft kann man auf dieser Flughöhe aber auf sie verzichten.
134. 3. Lösungsarchitektur umsetzen
Architectural Katas
1 Aufgabe
2-3 Teams
1 Merge
Wie kommt man als Architektur zu einer Architektur, die vom Team getragen wird?
Das Team macht sie. Und natürlich ist nicht jeder im Team in der Lage, jeden Aspekt von Architektur gut zu bedienen. Deshalb wird die Arbeit in Gruppenarbeit gemacht,
und jede Gruppe sollte zumindest einen erfahrenen Architekten enthalten.
135. Bausteinsicht
Module
Komponenten
Subsysteme
Layer
Partitionen
3.
Mithilfe dieser Katas wird dann die Zielarchitektur präzisiert. Konkret heisst das: Welche Technologien setze ich ein, wie strukturiere ich die Software, welche
Komponenten, Layer oder Säulen brauche ich, wie zerlege ich Daten und Struktur?
Diese Sicht wird in den Gruppen erarbeitet - und im Anschluss vorgestellt, und aus diesen Sichten ein gemeinsamer Vorschlag erzeugt.
136. Deployment view
Hardwareumgebung
Deploymenteinheiten
Deploymentziele
Dev zu SCM
zu CI/CD zu
Test zu Prod
3.
Das gleiche passiert mit dem Deployment-View. Deyployment meint hier nicht nur die produktive Umgebung - sondern auch den ganzen Weg dorthin. Wie wird die
Software vom Entwickler genutzt, wo ist sie dort installiert? Wo liegt der Sourcecode? Wie findet die CI statt, wie das Deployment? Wo laufen welche Dienste?
137. Cross Cutting Concepts
3.
Und - last but not least - die Cross Cutting Concerns, die Dinge, die die ganze Applikation durchziehen. Wie wird Code erzeugt, wie wird mit Sicherheit umgegangen,
nach welchen Standards richten sich die User Interfaces, welche Design-Patterns werden genutzt und vieles mehr - bishin zu den Konzepten, die Fail Safety, Residenz,
Asynchrone Prozesse und Reporting ermöglichen.
138. 3.
Lösungsarchitektur
umsetzen
Ergebnis der Merges:
Gemeinsames Bild
für den DEEP Backlog
Unklarheiten sind Spikes
Architectural Enabler sind
Epics
Am Ende, wenn wir diese Architekturthemen allesamt erfasst und dokumentiert haben, kennen wir nicht nur die Zielarchitektur im Detail: wir können aus ihr auch ableiten,
was zu tun ist, um sie umzusetzen. Diese Arbeiten werden als Epics gesammelt und ebenfalls als Architectural Enabler in den Architektur-Backlog genommen.
139. 4. Umsetzung
Wann möchte ich
die Migration und
Architektur machen?
Agil sagt:
emergent schlägt geplant
schnelles Feedback ++
Jetzt haben wir nicht nur die neue Architektur, sondern auch die dafür notwendigen Schritte - in Detailarchitektur wie Migration - erkannt und als geschätzte Epics zur
Verfügung.
Aber wann wollen wir diese ganzen Architekturthemen machen? Im Feature-Freeze? Das wäre quasi die Maximierung von Coat-Of-Delay.
Und hier kommen wieder die Agilisten ins Spiel. Sie sagen zwei Dinge über die Erzeugung von Software
a) es ist besser, wenn die Architektur dann entsteht, wenn sie gebraucht wird.
b) wenn ich sie habe möchte ich so schnelles Feedback wie möglich bekommen.
140. 4. Umsetzung
3 Stream-Model:
A) Roadmap-Themen
B) Migration&Modernisierung
C) Daily Business & Maintenance
33 %
33 %
33 %
Und so führe ich das ganze in die Praxis über:
Ich habe drei Streams, in denen Anforderungen auftreten:
a) die Business-Themen, die ohnehin auf der Roadmap stehen und umgesetzt werden müssen.
b) die Migrations- und Modernisierungsthemen
c) Daily Business, die Themen, die ich zusätzlich trotzdem machen muss - weil sich zB Interfaces oder Gesetze ändern
141. 4. Umsetzung
Opportunistische
Modernisierung:
Umsetzung kurz
vor Nutzung.
Mit diesen drei Streams arbeite ich opportunistisch - ich setze die Architektur- und Migrationsthemen jeweils so um, dass sie da sind, wenn sie gebraucht werden.
Architektur und Migration entstehen also nicht als Big Architecture Change Upfront, sondern kontinuierlich immer dann, wenn ich kurz danach darauf zurückgreifen
könnte bzw. sollte.
142. 4. Umsetzung
Mother of all Story-Mappings:
>= 1 Jahr im Voraus
nur Roadmap-Themen
DEEP
EPIC-Level reicht meist
Damit ich das Beurteilen kann brauche ich eine gemeinsame Prognose, wann ich welche Businessthemen brauche, etwa über ein Jahr. Diese Prognose muss nicht
stimmen - es reicht aus, wenn sie den aktuellen Stand der Erwartungen widerspiegelt.
Das kann man zum Beispiel mit der Mother of all Story-Mappings machen - einfach ein Storymapping über alle erwarteten Themen für das kommende Jahr machen. Hier
reicht meist der Epic-Level, und nur die frühen Themen müssen bearbeitbar sein - aber die tiefe muss reichen, um eine schöne Abfolge der Entwicklung zu erstellen.
143. 4. Umsetzung
Value Proposition Canvas
Priorisierte Personas
Priorisierte Goals
Priorisierte Epics
So sieht das ganze konkret aus - man beginnt mit den Kerntreibern aus dem Business, den wichtigsten Personas, deren wichtigsten Zielen und die Epics, die nötig sind,
um dorthin zu kommen. Die Zielgrösse sollten irgendwo zwischen 40 und 100 Epics liegen. Und wir brauchen nicht nur die Priorisierung auf der Zeitachse - wir brauchen
ebenfalls eine Schätzung, wie gross der dahinter stehende Aufwand etwa ist.
144. 5.DEEP Backlog ausrollen
33 %
33 %
33 %
A) Roadmap-Themen
B) Migration&Modernisierung
Auf diese Weise haben wir nach dem Storymapping eine Reihenfolge der Businessthemen, die umzusetzen sind.
Jetzt schieben wir die Migration & Architekturthemen so vor die Roadmap-Themen, dass wir sie jeweils dann umsetzen, wenn sie kurz daraufhin gebraucht werden. Am
Anfang sind das meist mehr Modernisierungsthemen, am Ende reduziert sich ihre Zahl deutlich.
Die täglichen Aufgaben passieren parallel. Im Gegensatz zu den anderen Themen werden sie nicht über Reihenfolge moderniert, sondern werden pauschalisiert mit
einem fixen Arbeitskraft-Budget bearbeitet.
145. 5.DEEP Backlog auf Zeitlinie
Sprint1
Sprint2
Sprint3
Sprint4
Sprint5
Sprint6
Sprint7
Sprint8
Sprint9
Sprint10
Estimation über Sprint-
Füllung
Diesen gemeinsamen Backlog kann man dann mit seiner Schätzung auf eine Zeitlinie legen. Verbindlich ist diese Prognose jetzt natürlich lange noch nicht, ganz im
Gegenteil - uns fehlt noch jegliche Erfahrung, welche Dinge tatsächlich wie konkret aussehen und wie lange ihre Bearbeitung dauert. Aber die Reihenfolge haben wir, und
wir kennen die groben Abhängigkeiten, in denen diese Reihenfolge umgesetzt werden könnte.
146. 5. Roadmap
Release-Planning mit
Roadmap
Und genau diese Reihenfolge ist die Basis für eine Release-Roadmap, die sowohl Geschäfts als auch Modernisierungsthemen enthält. Für die Agilisten: natürlich ist das
ein Plan, aber dieser Plan muss so nicht eingehalten werden - er dokumentiert nur den Stand der aktuellen Erwartungen. Wenn dieser Stand sich ändert, dann muss auch
der Plan angepasst werden.
147. 5. Release-Prognose
Und diese Release-Roadmap erlaubt uns dann im Projektverlauf eine Release-Prognose. Wenn ich beobachte, welche Themen ich mit welcher Zeit durchbekomme und
diese Daten über die Zeit sammle, dann kann ich prognostizieren, wann ich mit ihnen fertig bin. Und nicht nur das - ich kann auch prognostizieren, wie gross meine
Verlässlichkeit auf dem Weg ist, sprich: wann ich zu 25%, zu 50% oder zu 75% sicher fertig werde. Auf diese Weise verhindere ich, dass mein Projekt aus dem Fokus
läuft - denn ich kann kontinuierlich moderieren, wie und wo ich meine Zeit investiere, und gegebenenfalls nachjustieren.
148. 5. Ist denn das Agil?
Release Roadmap und
Storymapping sind die am
weitesten verbreiteten
Requirements-Werkzeuge
bei agilen Firmen.
Immer, wenn ich mit Talks mit Release Roadmaps und Storymappings um die Ecke komme fragen die NoEstimates, warum ich hier so viel schätze. Das hat einen
einfachen Grund: ich möchte eine Basisprognose als Ankerpunkt haben, um zu schauen, wie gut meine Vorhersagen sind - und auf dieser Basis Risikomanagement
betreiben. Und Release Roadmap und Storymapping sind - tatsächlich - die am weitesten verbreitetsten Methoden aus der agilen Welt zum Requirements Management.
Quelle: State of Agile 2017
149. Muss ich das so machen?
Nein, aber diese Inhalte sind Pflicht:
Intentional Architektur entdecken
auf Basis der Businesstreiber
gemeinsam & explizit evaluiert
Umsetzungsplan
Architectural Enabler
Migrationsaufgaben
Organisation
Balance zwischen Tech & Features
Reihenfolge & Prediction erlauben
Damit habe ich eigentlich alles, was ich zur Arbeit an einer Modernisierung als gemeinsames Bild und erste Idee brauche, und ich kann loslegen.
Muss ich das genau so machen? Natürlich nicht, aber die dahinter stehenden Aufgaben muss ich trotzdem machen:
- die Businesstreiber der Zielarchitektur ermitteln
- die Zielarchitektur auf dieser Basis finden
- die Architektur - und Migrationsthemen sammeln
- eine Organisation etablieren, die die Balance zwischen Modernisierung, Roadmap und Daily Business erlaubt, um die Modernisierung nicht zu verschleppen und
trotzdem Business zu beliefern.