SlideShare ist ein Scribd-Unternehmen logo
E-Commerce vs
Architektur!
Hallo! Und willkommen zu E-Commerce vs Architektur!
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.
@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.
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üfft, 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 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.
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 ,
Modifizierbarkeit, 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 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.
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, offensichtlich ist da keine Silver Bullet, keine Universallösung, auf die wir uns fix 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öffentlicht 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 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.
Essential Complexity
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.
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.
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.
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.
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.
Accidental 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.
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.
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.
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.
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.
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 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.
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
Accidental Complexity
Marktfeedback/Innovation
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
Accidental Complexity
Marktfeedback/Innovation
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
Accidental Complexity
Marktfeedback/Innovation
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
Accidental Complexity
Marktfeedback/Innovation
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
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
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 finden.
„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 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.
Off the Shelf-Shop

PIM, Plugins etc
Off the Shelf-Shop

PIM, Plugins etc
Betrieb
Konfiguration
Accidental Shop
Essential Shop
Bei Standardaufgaben
wenig Aufwand,
meist nur
Konfiguration 

und Betrieb …
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.
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
Off the Shelf-Shop

PIM, Plugins etc
Skalieren
Flexibilität
neue Clients
Wenn der Standard nicht reicht …
…steigt
Knowhow-Bedarf
Accidental Complexity
deutlich
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.
Off the Shelf-/Proprietary Shop

0
35
70
105
140
Jahr 1 Jahr 2 Jahr 3 Jahr 4
Essential Complexity Accidental Complexity
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
Off the Shelf-Shop

Ohne Refactoring
0
35
70
105
140
Jahr 1 Jahr 2 Jahr 3 Jahr 4
Essential Complexity Accidental Complexity
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
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
E-Commerce Platform/ 

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
E-Commerce Platform/ 

Modularer/DDD-Monolith

Frontend-Layer
Other
Clients
REST/Events
Context
API
Context
API
Context
API
Context
API
Über mehrere
Teams
skalierbar.
E-Commerce Platform/ 

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 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!
Team Team Team
Context
API
Context
API
Context
API
Context
API
Context
API
Context
API
Context
API
Essential 

Complexity
Code
Accidental Complexity
Marktfeedback/Innovation
Essential 

Complexity
Code
Accidental Complexity
Marktfeedback/Innovation
Essential 

Complexity
Code
Accidental Complexity
Marktfeedback/Innovation
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 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,
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,
Automatisierung?
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 Langzeiteffekte 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
Jahr 1 Jahr 2 Jahr 3 Jahr 4
Essential Complexity
Accidental Complexity
Ok, und was mache ich jetzt?

… mit der Organisationsform,
die den Lern-Zyklus am besten
abbilden kann.
Essential 

Complexity
Code
Accidental Complexity
Marktfeedback/Innovation
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 findet man praktisch immer eine Abart der folgenden:
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.
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.
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.
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.
E-Commerce vs Architecture
Und Übergangsformen …
Aber nicht nur diese Formen gibt, es viele Formen in der Mitte, Kompromisse und Anleihen bei anderen Architekturen.
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.
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?
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)
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.
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?
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.
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 .“
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
…
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.
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.
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?
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.“
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.
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.
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.
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:
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.
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.
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 findet 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 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 findet 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 fixen 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 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.

Weitere ähnliche Inhalte

Was ist angesagt?

DevOps und ITIL: Waffenbrüder oder Feinde?
DevOps und ITIL: Waffenbrüder oder Feinde?DevOps und ITIL: Waffenbrüder oder Feinde?
DevOps und ITIL: Waffenbrüder oder Feinde?
OPITZ CONSULTING Deutschland
 
BizDevOps - Die prozessorientierte IT-Organisation
BizDevOps - Die prozessorientierte IT-OrganisationBizDevOps - Die prozessorientierte IT-Organisation
BizDevOps - Die prozessorientierte IT-Organisation
Uwe Weng
 
Quo vadis DevOps
Quo vadis DevOpsQuo vadis DevOps
Quo vadis DevOps
cusy GmbH
 
Agil in der Normativen Welt
Agil in der Normativen WeltAgil in der Normativen Welt
Agil in der Normativen Welt
Thomas Arends
 
OOP2015 agile im konzern gloger ewe
OOP2015 agile im konzern gloger eweOOP2015 agile im konzern gloger ewe
OOP2015 agile im konzern gloger ewe
Markus Theilen
 
Advanced Continuous Integration
Advanced Continuous IntegrationAdvanced Continuous Integration
Advanced Continuous Integration
OPITZ CONSULTING Deutschland
 
VSHN DevOps Workshop at topsoft 2019
VSHN DevOps Workshop at topsoft 2019VSHN DevOps Workshop at topsoft 2019
VSHN DevOps Workshop at topsoft 2019
Markus Speth
 
DevOps Meetup Freiburg - DevOps in Practice
DevOps Meetup Freiburg - DevOps in PracticeDevOps Meetup Freiburg - DevOps in Practice
DevOps Meetup Freiburg - DevOps in Practice
Haufe-Lexware GmbH & Co KG
 
ConSol Unternehmenspräsentation 2019
ConSol Unternehmenspräsentation 2019ConSol Unternehmenspräsentation 2019
ConSol Unternehmenspräsentation 2019
ConSol Consulting & Solutions Software GmbH
 
Bessere Software schneller liefern
Bessere Software schneller liefernBessere Software schneller liefern
Bessere Software schneller liefern
Mayflower GmbH
 
Agile Anti-Patterns
Agile Anti-PatternsAgile Anti-Patterns
Agile Anti-Patterns
Mayflower GmbH
 
Das Ganze ist mehr als seine Teile: Die moderne Continuous-Delivery-Umgebung
Das Ganze ist mehr als seine Teile: Die moderne Continuous-Delivery-UmgebungDas Ganze ist mehr als seine Teile: Die moderne Continuous-Delivery-Umgebung
Das Ganze ist mehr als seine Teile: Die moderne Continuous-Delivery-Umgebung
OPITZ CONSULTING Deutschland
 
Organisation 4.0
Organisation 4.0Organisation 4.0
Organisation 4.0
Uwe Weng
 
Extreme Manufacturing in der Medizintechnik
Extreme Manufacturing in der MedizintechnikExtreme Manufacturing in der Medizintechnik
Extreme Manufacturing in der Medizintechnik
Frank Lange
 
Highspeed-Projekte für die Medizintechnik
Highspeed-Projekte für die MedizintechnikHighspeed-Projekte für die Medizintechnik
Highspeed-Projekte für die Medizintechnik
Frank Lange
 
Ketzerischer Vortrag zur Agilen Entwicklung
Ketzerischer Vortrag zur Agilen Entwicklung Ketzerischer Vortrag zur Agilen Entwicklung
Ketzerischer Vortrag zur Agilen Entwicklung
Thomas Arends
 
Definition of Ready
Definition of ReadyDefinition of Ready
Definition of Ready
Markus Unterauer
 
Migration von Applikationen in die Cloud
Migration von Applikationen in die CloudMigration von Applikationen in die Cloud
Migration von Applikationen in die Cloud
Aarno Aukia
 
Der Enterprise-Java-Architekt – eine aussterbende Gattung!?
Der Enterprise-Java-Architekt – eine aussterbende Gattung!?Der Enterprise-Java-Architekt – eine aussterbende Gattung!?
Der Enterprise-Java-Architekt – eine aussterbende Gattung!?
OPEN KNOWLEDGE GmbH
 

Was ist angesagt? (20)

DevOps und ITIL: Waffenbrüder oder Feinde?
DevOps und ITIL: Waffenbrüder oder Feinde?DevOps und ITIL: Waffenbrüder oder Feinde?
DevOps und ITIL: Waffenbrüder oder Feinde?
 
BizDevOps - Die prozessorientierte IT-Organisation
BizDevOps - Die prozessorientierte IT-OrganisationBizDevOps - Die prozessorientierte IT-Organisation
BizDevOps - Die prozessorientierte IT-Organisation
 
Quo vadis DevOps
Quo vadis DevOpsQuo vadis DevOps
Quo vadis DevOps
 
Agil in der Normativen Welt
Agil in der Normativen WeltAgil in der Normativen Welt
Agil in der Normativen Welt
 
OOP2015 agile im konzern gloger ewe
OOP2015 agile im konzern gloger eweOOP2015 agile im konzern gloger ewe
OOP2015 agile im konzern gloger ewe
 
Agile Business Software mit der Enterprise Cloud
Agile Business Software mit der Enterprise CloudAgile Business Software mit der Enterprise Cloud
Agile Business Software mit der Enterprise Cloud
 
Advanced Continuous Integration
Advanced Continuous IntegrationAdvanced Continuous Integration
Advanced Continuous Integration
 
VSHN DevOps Workshop at topsoft 2019
VSHN DevOps Workshop at topsoft 2019VSHN DevOps Workshop at topsoft 2019
VSHN DevOps Workshop at topsoft 2019
 
DevOps Meetup Freiburg - DevOps in Practice
DevOps Meetup Freiburg - DevOps in PracticeDevOps Meetup Freiburg - DevOps in Practice
DevOps Meetup Freiburg - DevOps in Practice
 
ConSol Unternehmenspräsentation 2019
ConSol Unternehmenspräsentation 2019ConSol Unternehmenspräsentation 2019
ConSol Unternehmenspräsentation 2019
 
Bessere Software schneller liefern
Bessere Software schneller liefernBessere Software schneller liefern
Bessere Software schneller liefern
 
Agile Anti-Patterns
Agile Anti-PatternsAgile Anti-Patterns
Agile Anti-Patterns
 
Das Ganze ist mehr als seine Teile: Die moderne Continuous-Delivery-Umgebung
Das Ganze ist mehr als seine Teile: Die moderne Continuous-Delivery-UmgebungDas Ganze ist mehr als seine Teile: Die moderne Continuous-Delivery-Umgebung
Das Ganze ist mehr als seine Teile: Die moderne Continuous-Delivery-Umgebung
 
Organisation 4.0
Organisation 4.0Organisation 4.0
Organisation 4.0
 
Extreme Manufacturing in der Medizintechnik
Extreme Manufacturing in der MedizintechnikExtreme Manufacturing in der Medizintechnik
Extreme Manufacturing in der Medizintechnik
 
Highspeed-Projekte für die Medizintechnik
Highspeed-Projekte für die MedizintechnikHighspeed-Projekte für die Medizintechnik
Highspeed-Projekte für die Medizintechnik
 
Ketzerischer Vortrag zur Agilen Entwicklung
Ketzerischer Vortrag zur Agilen Entwicklung Ketzerischer Vortrag zur Agilen Entwicklung
Ketzerischer Vortrag zur Agilen Entwicklung
 
Definition of Ready
Definition of ReadyDefinition of Ready
Definition of Ready
 
Migration von Applikationen in die Cloud
Migration von Applikationen in die CloudMigration von Applikationen in die Cloud
Migration von Applikationen in die Cloud
 
Der Enterprise-Java-Architekt – eine aussterbende Gattung!?
Der Enterprise-Java-Architekt – eine aussterbende Gattung!?Der Enterprise-Java-Architekt – eine aussterbende Gattung!?
Der Enterprise-Java-Architekt – eine aussterbende Gattung!?
 

Ähnlich wie E-Commerce vs Architektur CodeTalks.Commerce_2018

Modernisierung in Zeiten wie diesen
Modernisierung in Zeiten wie diesenModernisierung in Zeiten wie diesen
Modernisierung in Zeiten wie diesen
enpit GmbH & Co. KG
 
eparo – Online-Konzeption (Vortrag ADC Young Masters 2012 – Rolf Schulte Stra...
eparo – Online-Konzeption (Vortrag ADC Young Masters 2012 – Rolf Schulte Stra...eparo – Online-Konzeption (Vortrag ADC Young Masters 2012 – Rolf Schulte Stra...
eparo – Online-Konzeption (Vortrag ADC Young Masters 2012 – Rolf Schulte Stra...
eparo GmbH
 
Rethink! ITEM 2016 - Post Event Report
Rethink! ITEM 2016 - Post Event ReportRethink! ITEM 2016 - Post Event Report
Rethink! ITEM 2016 - Post Event Report
Ramona Kohrs
 
K5 Konferenz 2015 - Intro zur Marketing Session - Florian Heinemann
K5 Konferenz 2015 - Intro zur Marketing Session - Florian HeinemannK5 Konferenz 2015 - Intro zur Marketing Session - Florian Heinemann
K5 Konferenz 2015 - Intro zur Marketing Session - Florian Heinemann
Florian Heinemann
 
Von Kutschern, Managern und Systemadministratoren
Von Kutschern, Managern und SystemadministratorenVon Kutschern, Managern und Systemadministratoren
Von Kutschern, Managern und Systemadministratoren
Johann-Peter Hartmann
 
Namics & Adobe Industrie-Workshop "Be smart" vom 23.05.2017
Namics & Adobe Industrie-Workshop "Be smart" vom 23.05.2017Namics & Adobe Industrie-Workshop "Be smart" vom 23.05.2017
Namics & Adobe Industrie-Workshop "Be smart" vom 23.05.2017
Namics – A Merkle Company
 
BASTA Spring 2018: User Interface, quo vadis? Überlebensstrategien eines Soft...
BASTA Spring 2018: User Interface, quo vadis? Überlebensstrategien eines Soft...BASTA Spring 2018: User Interface, quo vadis? Überlebensstrategien eines Soft...
BASTA Spring 2018: User Interface, quo vadis? Überlebensstrategien eines Soft...
Rainer Stropek
 
E-Commerce Organisationsstrukturen
E-Commerce OrganisationsstrukturenE-Commerce Organisationsstrukturen
E-Commerce Organisationsstrukturen
Björn Schotte
 
"Failure is not an options" Slides from our IBM Connections Webinar Series. F...
"Failure is not an options" Slides from our IBM Connections Webinar Series. F..."Failure is not an options" Slides from our IBM Connections Webinar Series. F...
"Failure is not an options" Slides from our IBM Connections Webinar Series. F...
Beck et al. GmbH
 
2009 - Basta!: Agiles requirements engineering
2009 - Basta!: Agiles requirements engineering2009 - Basta!: Agiles requirements engineering
2009 - Basta!: Agiles requirements engineering
Daniel Fisher
 
Datenanalysen in der Softwareentwicklung mit Software Analytics
Datenanalysen in der Softwareentwicklung mit Software AnalyticsDatenanalysen in der Softwareentwicklung mit Software Analytics
Datenanalysen in der Softwareentwicklung mit Software Analytics
Markus Harrer
 
[ecspw2013] Session Executive 01: ecspand 3.0 - Vorgangsbearbeitung für den S...
[ecspw2013] Session Executive 01: ecspand 3.0 - Vorgangsbearbeitung für den S...[ecspw2013] Session Executive 01: ecspand 3.0 - Vorgangsbearbeitung für den S...
[ecspw2013] Session Executive 01: ecspand 3.0 - Vorgangsbearbeitung für den S...
d.velop international
 
Plone im Kontext des WCMS Marktes
Plone im Kontext des WCMS MarktesPlone im Kontext des WCMS Marktes
Plone im Kontext des WCMS Marktes
Alexander Loechel
 
Die Architektur, die man kann
Die Architektur, die man kannDie Architektur, die man kann
Die Architektur, die man kann
Johann-Peter Hartmann
 
Thementag 2023 06 Dieses Mal machen wir alles richtig - 9 Hacks für wandelbar...
Thementag 2023 06 Dieses Mal machen wir alles richtig - 9 Hacks für wandelbar...Thementag 2023 06 Dieses Mal machen wir alles richtig - 9 Hacks für wandelbar...
Thementag 2023 06 Dieses Mal machen wir alles richtig - 9 Hacks für wandelbar...
IKS Gesellschaft für Informations- und Kommunikationssysteme mbH
 
Enable Mobility and Improve Cost Efficiency within a Secure Ecosystem - Futur...
Enable Mobility and Improve Cost Efficiency within a Secure Ecosystem - Futur...Enable Mobility and Improve Cost Efficiency within a Secure Ecosystem - Futur...
Enable Mobility and Improve Cost Efficiency within a Secure Ecosystem - Futur...
Microsoft Österreich
 
To Be or Not to Be - Die Digitalisierung und ihre Folgen
To Be or Not to Be - Die Digitalisierung und ihre FolgenTo Be or Not to Be - Die Digitalisierung und ihre Folgen
To Be or Not to Be - Die Digitalisierung und ihre Folgen
Martin Runde
 

Ähnlich wie E-Commerce vs Architektur CodeTalks.Commerce_2018 (20)

Modernisierung in Zeiten wie diesen
Modernisierung in Zeiten wie diesenModernisierung in Zeiten wie diesen
Modernisierung in Zeiten wie diesen
 
eparo – Online-Konzeption (Vortrag ADC Young Masters 2012 – Rolf Schulte Stra...
eparo – Online-Konzeption (Vortrag ADC Young Masters 2012 – Rolf Schulte Stra...eparo – Online-Konzeption (Vortrag ADC Young Masters 2012 – Rolf Schulte Stra...
eparo – Online-Konzeption (Vortrag ADC Young Masters 2012 – Rolf Schulte Stra...
 
20110406 activiti april
20110406 activiti april20110406 activiti april
20110406 activiti april
 
Rethink! ITEM 2016 - Post Event Report
Rethink! ITEM 2016 - Post Event ReportRethink! ITEM 2016 - Post Event Report
Rethink! ITEM 2016 - Post Event Report
 
K5 Konferenz 2015 - Intro zur Marketing Session - Florian Heinemann
K5 Konferenz 2015 - Intro zur Marketing Session - Florian HeinemannK5 Konferenz 2015 - Intro zur Marketing Session - Florian Heinemann
K5 Konferenz 2015 - Intro zur Marketing Session - Florian Heinemann
 
20110321 activiti märz
20110321 activiti märz20110321 activiti märz
20110321 activiti märz
 
Von Kutschern, Managern und Systemadministratoren
Von Kutschern, Managern und SystemadministratorenVon Kutschern, Managern und Systemadministratoren
Von Kutschern, Managern und Systemadministratoren
 
Namics & Adobe Industrie-Workshop "Be smart" vom 23.05.2017
Namics & Adobe Industrie-Workshop "Be smart" vom 23.05.2017Namics & Adobe Industrie-Workshop "Be smart" vom 23.05.2017
Namics & Adobe Industrie-Workshop "Be smart" vom 23.05.2017
 
BASTA Spring 2018: User Interface, quo vadis? Überlebensstrategien eines Soft...
BASTA Spring 2018: User Interface, quo vadis? Überlebensstrategien eines Soft...BASTA Spring 2018: User Interface, quo vadis? Überlebensstrategien eines Soft...
BASTA Spring 2018: User Interface, quo vadis? Überlebensstrategien eines Soft...
 
E-Commerce Organisationsstrukturen
E-Commerce OrganisationsstrukturenE-Commerce Organisationsstrukturen
E-Commerce Organisationsstrukturen
 
"Failure is not an options" Slides from our IBM Connections Webinar Series. F...
"Failure is not an options" Slides from our IBM Connections Webinar Series. F..."Failure is not an options" Slides from our IBM Connections Webinar Series. F...
"Failure is not an options" Slides from our IBM Connections Webinar Series. F...
 
2009 - Basta!: Agiles requirements engineering
2009 - Basta!: Agiles requirements engineering2009 - Basta!: Agiles requirements engineering
2009 - Basta!: Agiles requirements engineering
 
Datenanalysen in der Softwareentwicklung mit Software Analytics
Datenanalysen in der Softwareentwicklung mit Software AnalyticsDatenanalysen in der Softwareentwicklung mit Software Analytics
Datenanalysen in der Softwareentwicklung mit Software Analytics
 
20110223 activiti
20110223 activiti20110223 activiti
20110223 activiti
 
[ecspw2013] Session Executive 01: ecspand 3.0 - Vorgangsbearbeitung für den S...
[ecspw2013] Session Executive 01: ecspand 3.0 - Vorgangsbearbeitung für den S...[ecspw2013] Session Executive 01: ecspand 3.0 - Vorgangsbearbeitung für den S...
[ecspw2013] Session Executive 01: ecspand 3.0 - Vorgangsbearbeitung für den S...
 
Plone im Kontext des WCMS Marktes
Plone im Kontext des WCMS MarktesPlone im Kontext des WCMS Marktes
Plone im Kontext des WCMS Marktes
 
Die Architektur, die man kann
Die Architektur, die man kannDie Architektur, die man kann
Die Architektur, die man kann
 
Thementag 2023 06 Dieses Mal machen wir alles richtig - 9 Hacks für wandelbar...
Thementag 2023 06 Dieses Mal machen wir alles richtig - 9 Hacks für wandelbar...Thementag 2023 06 Dieses Mal machen wir alles richtig - 9 Hacks für wandelbar...
Thementag 2023 06 Dieses Mal machen wir alles richtig - 9 Hacks für wandelbar...
 
Enable Mobility and Improve Cost Efficiency within a Secure Ecosystem - Futur...
Enable Mobility and Improve Cost Efficiency within a Secure Ecosystem - Futur...Enable Mobility and Improve Cost Efficiency within a Secure Ecosystem - Futur...
Enable Mobility and Improve Cost Efficiency within a Secure Ecosystem - Futur...
 
To Be or Not to Be - Die Digitalisierung und ihre Folgen
To Be or Not to Be - Die Digitalisierung und ihre FolgenTo Be or Not to Be - Die Digitalisierung und ihre Folgen
To Be or Not to Be - Die Digitalisierung und ihre Folgen
 

Mehr von Johann-Peter Hartmann

The End of my Career
The End of my CareerThe End of my Career
The End of my Career
Johann-Peter Hartmann
 
DevOps beyond the Tools
DevOps beyond the ToolsDevOps beyond the Tools
DevOps beyond the Tools
Johann-Peter Hartmann
 
Warum die it nicht um new work herumkommt
Warum die it nicht um new work herumkommtWarum die it nicht um new work herumkommt
Warum die it nicht um new work herumkommt
Johann-Peter Hartmann
 
Legacy php - Sanieren oder Ablösen?
Legacy php  - Sanieren oder Ablösen?Legacy php  - Sanieren oder Ablösen?
Legacy php - Sanieren oder Ablösen?
Johann-Peter Hartmann
 
RoofTop Brains & BBQ: Ein Gästbuch für China
RoofTop Brains & BBQ: Ein Gästbuch für ChinaRoofTop Brains & BBQ: Ein Gästbuch für China
RoofTop Brains & BBQ: Ein Gästbuch für China
Johann-Peter Hartmann
 
NewWork in der Praxis
NewWork in der PraxisNewWork in der Praxis
NewWork in der Praxis
Johann-Peter Hartmann
 
Das Ende der Karriere
Das Ende der KarriereDas Ende der Karriere
Das Ende der Karriere
Johann-Peter Hartmann
 
Reparier Deine Unternehmenskultur!
Reparier Deine Unternehmenskultur!Reparier Deine Unternehmenskultur!
Reparier Deine Unternehmenskultur!
Johann-Peter Hartmann
 
Lügen, schlimme Lügen und IT-Verträge
Lügen, schlimme Lügen und IT-VerträgeLügen, schlimme Lügen und IT-Verträge
Lügen, schlimme Lügen und IT-Verträge
Johann-Peter Hartmann
 
How not to screw the operating system of your startup
How not to screw the operating system of your startupHow not to screw the operating system of your startup
How not to screw the operating system of your startup
Johann-Peter Hartmann
 
Einfangen eines technisch kaputten projektes
Einfangen eines technisch kaputten projektesEinfangen eines technisch kaputten projektes
Einfangen eines technisch kaputten projektes
Johann-Peter Hartmann
 
Agile versus Management WJAX 2014
Agile versus Management WJAX 2014Agile versus Management WJAX 2014
Agile versus Management WJAX 2014
Johann-Peter Hartmann
 
Leadership in der IT
Leadership in der ITLeadership in der IT
Leadership in der IT
Johann-Peter Hartmann
 
Vom Entwickler zur Führungskraft
Vom Entwickler zur FührungskraftVom Entwickler zur Führungskraft
Vom Entwickler zur Führungskraft
Johann-Peter Hartmann
 
Erfolgreiche rewrites
Erfolgreiche rewritesErfolgreiche rewrites
Erfolgreiche rewrites
Johann-Peter Hartmann
 
Surviving Complexity
Surviving ComplexitySurviving Complexity
Surviving Complexity
Johann-Peter Hartmann
 
Java script security for java developers
Java script security for java developersJava script security for java developers
Java script security for java developers
Johann-Peter Hartmann
 
Rewrites überleben
Rewrites überlebenRewrites überleben
Rewrites überleben
Johann-Peter Hartmann
 
JavaScript Security
JavaScript SecurityJavaScript Security
JavaScript Security
Johann-Peter Hartmann
 
Serverside Cryptoparty
Serverside CryptopartyServerside Cryptoparty
Serverside Cryptoparty
Johann-Peter Hartmann
 

Mehr von Johann-Peter Hartmann (20)

The End of my Career
The End of my CareerThe End of my Career
The End of my Career
 
DevOps beyond the Tools
DevOps beyond the ToolsDevOps beyond the Tools
DevOps beyond the Tools
 
Warum die it nicht um new work herumkommt
Warum die it nicht um new work herumkommtWarum die it nicht um new work herumkommt
Warum die it nicht um new work herumkommt
 
Legacy php - Sanieren oder Ablösen?
Legacy php  - Sanieren oder Ablösen?Legacy php  - Sanieren oder Ablösen?
Legacy php - Sanieren oder Ablösen?
 
RoofTop Brains & BBQ: Ein Gästbuch für China
RoofTop Brains & BBQ: Ein Gästbuch für ChinaRoofTop Brains & BBQ: Ein Gästbuch für China
RoofTop Brains & BBQ: Ein Gästbuch für China
 
NewWork in der Praxis
NewWork in der PraxisNewWork in der Praxis
NewWork in der Praxis
 
Das Ende der Karriere
Das Ende der KarriereDas Ende der Karriere
Das Ende der Karriere
 
Reparier Deine Unternehmenskultur!
Reparier Deine Unternehmenskultur!Reparier Deine Unternehmenskultur!
Reparier Deine Unternehmenskultur!
 
Lügen, schlimme Lügen und IT-Verträge
Lügen, schlimme Lügen und IT-VerträgeLügen, schlimme Lügen und IT-Verträge
Lügen, schlimme Lügen und IT-Verträge
 
How not to screw the operating system of your startup
How not to screw the operating system of your startupHow not to screw the operating system of your startup
How not to screw the operating system of your startup
 
Einfangen eines technisch kaputten projektes
Einfangen eines technisch kaputten projektesEinfangen eines technisch kaputten projektes
Einfangen eines technisch kaputten projektes
 
Agile versus Management WJAX 2014
Agile versus Management WJAX 2014Agile versus Management WJAX 2014
Agile versus Management WJAX 2014
 
Leadership in der IT
Leadership in der ITLeadership in der IT
Leadership in der IT
 
Vom Entwickler zur Führungskraft
Vom Entwickler zur FührungskraftVom Entwickler zur Führungskraft
Vom Entwickler zur Führungskraft
 
Erfolgreiche rewrites
Erfolgreiche rewritesErfolgreiche rewrites
Erfolgreiche rewrites
 
Surviving Complexity
Surviving ComplexitySurviving Complexity
Surviving Complexity
 
Java script security for java developers
Java script security for java developersJava script security for java developers
Java script security for java developers
 
Rewrites überleben
Rewrites überlebenRewrites überleben
Rewrites überleben
 
JavaScript Security
JavaScript SecurityJavaScript Security
JavaScript Security
 
Serverside Cryptoparty
Serverside CryptopartyServerside Cryptoparty
Serverside Cryptoparty
 

E-Commerce vs Architektur CodeTalks.Commerce_2018

  • 1. E-Commerce vs Architektur! Hallo! Und willkommen zu E-Commerce vs Architektur!
  • 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.
  • 9. Volatility++ Uncertainty++ Complexity++ Ambiguity++ Und im Moment haben wir IT-Unternehmen mit einer Welt zu tun, in der alle 4 Faktoren zunehmen.
  • 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.
  • 15. Und ich dachte so … ok, das wird nicht einfach.
  • 16. 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 , Modifizierbarkeit, Stabilität Architektur-Strategie Da hilft mir meine Lehrbuch-Strategie mit Arc42, ATAM, Architectural Runway und so weiter ja nur so mittel.
  • 17. Ok … Hmpf. Ok, wie sollten wir denn dann vorgehen?
  • 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?
  • 21. Ok, das ist ja mal gerade sehr uneindeutig.
  • 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?
  • 23. 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 …
  • 24. 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.
  • 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.
  • 36. Accidental Complexity Auf der anderen Seite gibt's Accidental Complexity.
  • 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.
  • 38. Accidental 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.
  • 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.
  • 43. 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.
  • 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.
  • 46. Shared Mental Models Essential 
 Complexity Code Accidental Complexity Marktfeedback/Innovation 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.
  • 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.
  • 48. 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.
  • 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.
  • 50. Die schlechte Nachricht: Software ist deutlich grösser. Mental Models Der Nachteil ist nur: unsere Software ist deutlich größer.
  • 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.
  • 52. Essential 
 Complexity Code Accidental Complexity Marktfeedback/Innovation Essential / Accidental Complexity und mentale Modelle - das ist unsere Arbeit. Hier ein paar Begriffe, die wir dazu nutzen.
  • 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.
  • 76. Domain Driven Design: Minimierung der Accidental Complexity
  • 78. E-Commerce Platform/ 
 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.
  • 79. 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)
  • 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!
  • 81. Team Team Team Context API Context API Context API Context API Context API Context API Context API Essential 
 Complexity Code Accidental Complexity Marktfeedback/Innovation Essential 
 Complexity Code Accidental Complexity Marktfeedback/Innovation Essential 
 Complexity Code Accidental Complexity Marktfeedback/Innovation
  • 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.
  • 84. Aber die Accidental Complexity haben wir mit MicroServices gelöst!
  • 85. https://www.slideshare.net/adriancockcroft/goto-berlin 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,
  • 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
  • 91. https://martinfowler.com/articles/serverless.html Und wir kennen die Langzeiteffekte von den neuen Architekturen noch nicht. Es kann sein, dass wir ähnliche Antipattern erzeugen, wie wir sie aus der Vergangenheit schon kennen.
  • 92. 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.
  • 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.
  • 120. 2. Migrationsstrategie Komplett- Rewrite! Big Bang! Was wir aber schon wissen ist wie wir dort nicht hinkommen - nämlich über einen grossen Rewrite.
  • 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.