E-Commerce vs Architektur CodeTalks.Commerce_2018

E-Commerce vs
Architektur!
Hallo! Und willkommen zu E-Commerce vs Architektur!

Johann Hartmann 
Founder/CTO @ http://mayﬂower.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 Mayﬂower 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.

@johannhartmann
http://blog.mayﬂower.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.

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.

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üﬀt, weil für mich als aussenstehenden war E-Commerce ein gelöstes Problem.

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.

Und ich dachte nur: seit wann machen die denn auch so schlimm Buzzword Bingo? War das nicht bisher der Job von uns Consultancies?

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.

Volatility++
Uncertainty++
Complexity++
Ambiguity++
Und im Moment haben wir IT-Unternehmen mit einer Welt zu tun, in der alle 4 Faktoren zunehmen.

Wer kennt dieses Logo? Genau, jeder der hinreichend freie Zeit auf seinem Handy verbringt.

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 oﬃzielle 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.

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.

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.

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.

Und ich dachte so … ok, das wird nicht einfach.

Aufgabenstellung
Randbedingungen
Kontext
Qualitätskriterien
Angemessenheit, Richtigkeit, Interoperabilität, Sicherheit, Ordnungsmäßigkeit,
Zuverlässigkeit , Reife, Fehlertoleranz, Wiederherstellbarkeit , Benutzbarkeit,
Verständlichkeit, Erlernbarkeit, Bedienbarkeit, Attraktivität , Zeitverhalten,
Verbrauchsverhalten, (Aufwand & Kosten), Analysierbarkeit ,
Modiﬁzierbarkeit, Stabilität
Architektur-Strategie
Da hilft mir meine Lehrbuch-Strategie mit Arc42, ATAM, Architectural Runway und so weiter ja nur so mittel.

Ok …
Hmpf. Ok, wie sollten wir denn dann vorgehen?

… 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

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.

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?

Ok, das ist ja mal gerade sehr uneindeutig.

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?

Polyglott ist schnell…
„MicroServices“
gemeinsame DB
> 30 Komponenten
7 Sprachen
> 20 APIs 
 
 
6 Entwickler
Da hat man es auf einmal mit polyglotten Ansätzen überall zu tun …

Enterprise MicroServices
UX-Team 
(andere Abteilung)
„Cross-Funktionale“
MicroService-Teams,
SAFe
1 Person
Andere Teams 
(andere Abteilung)
Security + Ops
Oder auch MicroServices im Konzern, und zwar in einem dünnen Layer in der Mitte.

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.

Technologiewahl
Wir machen X weil… 
(Rust, Elixir, Haskell, Clojure, ReasonML, Luna)  
… wir da mehr Leute ﬁnden
… sonst der Kollege geht
… bei MicroServices jeder das  
selbst entscheidet
Und, auch gerne gesehen, einen bunten Technologiezoo, weil die Architektur vollständig dezentralisiert wurde.

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!

There is no silver bullet.
Ok, oﬀensichtlich ist da keine Silver Bullet, keine Universallösung, auf die wir uns ﬁx verlassen können.

"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öﬀentlicht hat. Der hiess „No Silver Bullet - Essence
and Accident in Software engineering“

"No Silver Bullet – Essence and
Accident in Software
Engineering"
Wichtig sind dabei vor allem die Begriﬀe 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.

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 Begriﬀ schon für Ablaufkomplexität nutzt - kennt jemand zyklomatische Komplexität? Ja, genau, das ist auch essential
complexity, aber die andere.

User Experience / Journeys
Workﬂows
Eingaben, Ausgaben
Externe Schnittstellen
Externe Constraints
Konkret stehen dahinter Themen wie User Experience, Workﬂows, Eingaben und Ausgaben, Externe Schnittstellen und Constraints.

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.

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.

Accidental Complexity
Auf der anderen Seite gibt's 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.

Programmiersprache
Architektur
Plattform
Betrieb
Wartung
Komponenten
von Development-Environment bis zur
Decommissioning-Strategie
Da gehört praktisch alles dazu, was wir technisch machen, um die Essential Complexity zu lösen.

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.

Unser Job in einem Diagramm
Essential  
Complexity
Code
Marktfeedback/Innovation
In einem Diagramm: wir haben eine Vermutung über die Essential Complexity, setzen die um - und dabei entsteht Code und damit zwangsläuﬁg Accidental Complexity,
und mit dem Code bekommen wir Feedback - in Form einer Validierung, einer Invalidierung oder neuer Ideen.

Essential  
Complexity
Code
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.

Damit der Loop funktioniert
brauche ich dieses Wissen geteilt.
Essential  
Complexity
Code
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.

Shared
Mental
Models
Equipment
Model
Task Model
Team Model
Team
Interaction
Model
Sie nennen das Shared Mental Models, also geteilte mentale Modell. Wie die genau aussehen wissen sie auch nicht - aber es ist nicht sprachlich, eher das, was man sich
unter einer Mindmaps vorstellen würde.

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 Konﬁguration, die wir auf dem Weg zur Lösung des Problems einsetzen.

Es deckt sich also weitgehend mit dem, was Fred Brooks „Accidental Complexity“ nennt.

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.

Shared
Mental
Models
Essential  
Complexity
Code
Team Interaction Model:
Wie kooperieren wir? Wer hat
welche Aufgabe? Welche
Normen haben wir?
=> Wissensaustausch
Irgendwie müssen Shared Mental Models zustande kommen, und das passiert über die Kommunikation der Humanoiden. Das Team Interaction Model klärt, wie das
passiert.

Shared
Mental
Models
Team Model:
Welche Fähigkeiten, Stärken,
Schwächen haben Kollegen?
=> Wissensverteilung
Essential  
Complexity
Code
Und nicht zuletzt gibt es noch das Team Model, mein wissen, das ich über die anderen habe.

Shared
Mental
Models
Die Tuckman-Kurve beschreibt
Entstehen und Wirkung vom
Team & Team Interaction Model
Wer von Euch kennt die Tuckman-Team-Kurve?

Das ist quasi genau das, was passiert, wenn die beiden Team mental Models entstehen.

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.

Die schlechte Nachricht:
Software ist deutlich grösser.
Mental
Models
Der Nachteil ist nur: unsere Software ist deutlich größer.

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.

Essential  
Complexity
Code
Essential / Accidental Complexity und
mentale Modelle - das ist unsere Arbeit.
Hier ein paar Begriffe, die wir dazu nutzen.

Die Vorhersage unseres mentalen Modells
und das tatsächliche Verhalten der  
Accidental Complexity stimmen nicht überein.
 
„Bug“
Essential  
Complexity
Code

Die Accidental Complexity ist der  
Essential Complexity nicht angemessen und
braucht damit unnötig viel mentales Modell.
„Technical Debt“
Essential  
Complexity
Code

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

Wir reduzieren die Accidental Complexity bei
gleicher Essential Complexity, damit wir
weniger mentales Modell brauchen.
„Refactoring“
Mental
Models

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

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

Wir organisieren uns so, dass Essential und
Accidental Complexity sich in einem Shared
Mental Model ﬁnden.
„Cross-Funkionale Teams“
Mental
Models

Die Accidental Complexity entsteht aus dem
Shared Mental Model, und das entsteht durch
die Interaktion.
„Conways Law“ 
(Die Organisation bestimmt die Architektur)
Mental
Models

Ok, Johann.
Schön, dass Du soviel Freude an Theorie hast.
Was ist jetzt mit Architektur  
und E-Commerce?!
Mental
Models

Accidental Complexity:
wo Architektur stattﬁndet
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.

Off the Shelf-Shop 
PIM, Plugins etc

PIM, Plugins etc
Betrieb
Konﬁguration
Accidental Shop
Essential Shop
Bei Standardaufgaben
wenig Aufwand,
meist nur
Konﬁguration  
und Betrieb …

PIM, Plugins etc
Interne Komplexität:  
Essential & Accidental
API
Konﬁguration
… weil mir die APIs und
die Konﬁguration viel
abnehmen.

PIM, Plugins etc
API
Konﬁguration
Wenn der Standard nicht reicht …
…steigt
Knowhow-Bedarf
deutlich

PIM, Plugins etc
Skalieren
Flexibilität
neue Clients
Wenn der Standard nicht reicht …
…steigt
Knowhow-Bedarf
deutlich

Proprietäre Lösung
mehr Flexibilität mit  
„Not invented here“
für meinen Business
Nur die  
Accidental Complexity,
die ich selbst brauche.

Off the Shelf-/Proprietary Shop 
0
35
70
105
140
Jahr 1 Jahr 2 Jahr 3 Jahr 4
Essential Complexity Accidental Complexity

Mit kontinuierlichem Refactoring
0
35
70
105
140

Ohne Refactoring
0
35
70
105
140

Mit kontinuierlichem Refactoring
0
35
70
105
140
1 Team

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.

E-Commerce Platform/  
Modularer Monolith 
Frontend-Layer
Backend-Layer
Other
Clients
Skalieren
Flexibilität
neue Clients
REST

Modularer Monolith 
Frontend-Layer
Other
Clients
REST
Modul
API
Modul
API
Modul
API
Modul
API
Reduktion der
Accidental
Complexity.

Domain Driven Design:
Minimierung der Accidental Complexity

Modularer/DDD-Monolith 
Frontend-Layer
Other
Clients
REST/Events
Context
API
Context
API
Context
API
Context
API
Über mehrere
Teams
skalierbar.

Modularer/DDD-Monolith 
Context
API
Context
API
Context
API
Context
API
Context
API
Context
API
Context
API
Mit der Zahl der Features steigt die
Essential Complexity.
Das Aufbauen der mentalen Modelle wird
damit teurer.

Context
API
Context
API
Context
API
Context
API
Context
API
Context
API
Context
API
Dann begrenzen wir die Essential
Complexity doch einfach.
Und deployen sie jeweils einzeln.
Weil wir es können.
(Also Rest, Events, DDD und Infrastructure as Code)

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 Deﬁnition, 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!

Team Team Team
Context
API
Context
API
Context
API
Context
API
Context
API
Context
API
Context
API
Essential  
Complexity
Code
Essential  
Complexity
Code
Essential  
Complexity
Code

Die Dienste sind klein, weitgehend
entkoppelt und erledigen eine
kleine Aufgabe.
Dann habe ich doch gar kein
Problem mehr mit zu grosser
Complexity, oder?

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.

Aber die Accidental Complexity
haben wir mit MicroServices gelöst!

https://www.slideshare.net/adriancockcroft/goto-berlin
Die Accidental Complexity sind wir nicht los, sie ﬁndet 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,

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 ﬁndet 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,

Hold my beer.
https://www.slideshare.net/AmazonWebServices/digital-transformation-aws-webinar
Serverless!

Serverless / FAAS
Outsourcen der Accidental Complexity! 
Innerhalb der Funktion habe ich  
wenig Accidental Complexity.
Resultat:
Schnelle Entwicklung
Preiswerte Wartung

Serverless: der Powerbuilder der Neuzeit?
ähnliche Strategien kennen wir schon:
Powerbuilder
Excel, Access
SAP 
Resultat:
Vendor Lock-in
viel Flexibilität erzeugt viel
Basisknowhow

https://martinfowler.com/articles/serverless.html
Und wir kennen die Langzeiteﬀekte von den neuen Architekturen noch nicht. Es kann sein, dass wir ähnliche Antipattern erzeugen, wie wir sie aus der Vergangenheit
schon kennen.

https://www.slideshare.net/nfrankel/the-dark-side-of-microservices
Die Architektur schützt
nicht vor Komplexität
Und auch sonst helfen die neuen Methoden nicht vor alten Fehlern. Die Architektur schützt mich nicht vor schlechtem Design, sie macht es nur aufwändiger.

Ok, und was mache ich jetzt? 
Die Architekturstrategie, mit der
ich die Gesamtkomplexität  
am besten im Griff habe.
0
35
70
105
140

Ok, und was mache ich jetzt? 
… mit der Organisationsform,
die den Lern-Zyklus am besten
abbilden kann.
Essential  
Complexity
Code

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:

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 ﬁndet man praktisch immer eine Abart der folgenden:

Off-The-Shelf-Framework/Shop
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 oﬀ-The-Shelf-Framework, irgendwo zwischen Shopware und Spryker.

Moderner Monolith
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.

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

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

Und Übergangsformen …
Aber nicht nur diese Formen gibt, es viele Formen in der Mitte, Kompromisse und Anleihen bei anderen Architekturen.

MiniServices (Gartner-Trend)
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.

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)
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?

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.

Die Lösungsstrategie hängt an den
Geschäftsanforderungen 
der nächsten 5-10 Jahre.
(den bekannten und den unbekannten)
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.

Vorbereitung
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?

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 TradeOﬀ 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.

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.

1.
Das können alle Systeme,  
die Turing-Vollständig sind.
„Kann chinesisch und Stripe Payment .“
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
…

1.
„Was das Business wirklich will.“
„Wenn die neue Architektur umgesetzt ist
kann eine neue Sprache mit 2 Wochen
Entwicklungsaufwand umgesetzt werden.“
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 Eﬀekten.

1.
„Wenn die neue Architektur umgesetzt ist
gibt es in den ersten 5 Jahren keine kritischen
Sicherheitslücken mehr.““
Andere typische Themen sind Security, aber auch die Medium Time to Recovery und vieles anderes.

1.
„Wenn wir den 1.1.2019 haben ist kein Teil der
alten Architektur mehr im Einsatz.“
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?

1. Architekturanforderungen
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.“

„Was das Business bekommen kann.“
Deshalb: TradeOff. Es gibt nicht alles.
Konkret: klare Priorisierung durch die
Unternehmensleitung.
Deshalb wird das ganze im Rahmen einer TradeOﬀ-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.

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 ﬁnden.

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
TradeOﬀ-Analyse für alle sichtbar und transparent, und jeder weiß, warum ich manche Architekturen besser- oder eben weniger gut - eignen.

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 triﬀt 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.

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:

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 geschaﬀen, auf der wir gut arbeiten können.

2. Migrationsstrategie
Ok, jetzt weiß ich, wo ich hin will.  
Aber wie komme ich dahin?
Aber damit ist nicht alles geschaﬀen, was ich für Architektur brauche - da fehlt mir noch der Weg, wie ich zu dieser neuen Architektur komme.

2. Migrationsstrategie
Komplett-
Rewrite!
Big Bang!
Was wir aber schon wissen ist wie wir dort nicht hinkommen - nämlich über einen grossen Rewrite.

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 ﬁndet es auch in der Praxis defakto nicht mehr oft statt.

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:

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 ﬁndet 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 ﬁndet in Produktion statt.

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.

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.

Cost-Beneﬁt Matrix
Auf dieser Basis entsteht dann ein Portfolio von Möglichkeiten, und es wird das konkrete Portfolio auf dieser Basis ausgewählt.

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 geschaﬀen, 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.

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.

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.

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.

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

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.

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.

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.

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.

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 ﬁndet die CI statt, wie das Deployment? Wo laufen welche Dienste?

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.

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.

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.

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

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.

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.

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.

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 ﬁxen Arbeitskraft-Budget bearbeitet.

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.

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.

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.

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

Muss ich das so machen?
Nein, aber diese Inhalte sind Pﬂicht:
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 ﬁnden

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

E-Commerce vs Architektur CodeTalks.Commerce_2018

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a E-Commerce vs Architektur CodeTalks.Commerce_2018

Similar a E-Commerce vs Architektur CodeTalks.Commerce_2018 (20)

Más de Johann-Peter Hartmann

Más de Johann-Peter Hartmann (20)

E-Commerce vs Architektur CodeTalks.Commerce_2018