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://mayﬂower.de   Ich kann gar kein E-Commerce. Eher Architektur, Security, Agile, DevOps und so.  Hi! Ich bin Johann, seit 20 Jahren als Founder/CTO bei Mayﬂower unterwegs. Vielleicht kennen uns noch ein paar Leute aus PHP-Zeiten, da haben wir damals mit angefangen. Wir sind immer noch sehr nerdig unterwegs, sind ziemlich gut in agilen Dingen. Ich selbst kann gar kein E-Commerce, sondern ein klassischer CTO mit Development, Architektur, Security, Agile, Devops und co im Fokus.

3. @johannhartmann http://blog.mayﬂower.de   In der Praxis bin ich trotzdem oft dabei, in Architektur und Organisation, von PHP3-Monolithen über Scala- Mikroservices zu Serverless in agilen Organisationen. Trotzdem bin ich oft dabei, weil die Teams alles mögliche machen, da haben wir die volle Palette - von PHP-Monolithen, die inzwischen den Führerschein machen dürfen über grössere Scalabasierte MicroService-Architekturen bis zu Serverless-Architekturen in Startups.

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üﬀt, 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 oﬃzielle Version im Dezember ins Apple Appstore. Und da fanden Millionen von Leuten gut, deshalb kam noch eine Android-Version dazu, im März. Bei der Gelegenheit haben sie dann auch gleich 20.000.000 Installation vollgemacht und das ganze für ebenfalls diverse Millionen an Facebook verkauft.

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 , Modiﬁzierbarkeit, 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 ﬁnden … sonst der Kollege geht … bei MicroServices jeder das   selbst entscheidet Und, auch gerne gesehen, einen bunten Technologiezoo, weil die Architektur vollständig dezentralisiert wurde.

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, oﬀensichtlich ist da keine Silver Bullet, keine Universallösung, auf die wir uns ﬁx 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öﬀentlicht 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 Begriﬀe Essence und Accident, dort hat er nämlich das Konzept von Essential und Accidental Complexity eingeführt, das auch die Domain Driven Design Jungs gerne nutzen.

31. Essential Complexity

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 Begriﬀ 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 Workﬂows Eingaben, Ausgaben Externe Schnittstellen Externe Constraints Konkret stehen dahinter Themen wie User Experience, Workﬂows, 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äuﬁg 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 Konﬁguration, die wir auf dem Weg zur Lösung des Problems einsetzen. Es deckt sich also weitgehend mit dem, was Fred Brooks „Accidental Complexity“ nennt.

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 ﬁnden. „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 stattﬁndet Jede Architektur ist ein Set von Strategien zur Umsetzung von Essential Complexity. Sie kann jeweils mit einigen Arten von Essential Complexity gut umgehen, mit anderen nicht. Architektur und gemeinsame mentale Modelle ergeben sich gegenseitig.

63. Off the Shelf-Shop  PIM, Plugins etc

64. Off the Shelf-Shop  PIM, Plugins etc Betrieb Konﬁguration Accidental Shop Essential Shop Bei Standardaufgaben wenig Aufwand, meist nur Konﬁguration   und Betrieb …

65. Off the Shelf-Shop  PIM, Plugins etc Interne Komplexität:   Essential & Accidental API Konﬁguration … weil mir die APIs und die Konﬁguration viel Accidental Complexity abnehmen.

66. Off the Shelf-Shop  PIM, Plugins etc Interne Komplexität:   Essential & Accidental API Konﬁguration 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

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

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 Deﬁnition, inzwischen - die von Herrn Bezos unterscheidet sich inzwischen deutlich. Das ist alles darauf ausgelegt, dass man es einfach ändern kann! Kleine, unabhängige Prozesse! Sprachunabhängige Schnittstellen! Kleine, entkoppelte Dienste! Immer nur kleine Aufgaben!

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 ﬁndet nur auf einem anderen Level statt. Das gilt nicht nur für das Deployment, für den Application Lifecycle, sondern auch für Fail-Over, Versionierung, Security,

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 ﬁndet nur auf einem anderen Level statt. Das gilt nicht nur für das Deployment, für den Application Lifecycle, sondern auch für Fail-Over, Versionierung, Security,

87. Automatisierung?

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

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 Langzeiteﬀekte 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 ﬁndet 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 oﬀ-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 TradeOﬀ Analysis Method“. Dieser Workshop sammelt alle relevanten Parameter und bringt sie in ein Format, das von Geschäfts- und Technikseite verstanden wird, in konkrete Szenarien für die Zukunft, die man messen kann. An diesen Szenarien entlang werden dann verschiedene wahrscheinliche Architekturoptionen beleuchtet und auf Eignung bewertet.

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 Eﬀekten.

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 TradeOﬀ-Analyse gemacht - sprich: die Kompromisse werden explizit gemacht, und noch wichtiger: es wird auch gesagt, was es nicht geben wird, weil es in dieser Kombination so nicht existiert.

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 ﬁnden. Die Autoren von ARC42 sagen explizit, dass das „Warum“ bei Architektur meist wichtiger als das „Was“ und das „Wie“ ist. Und genau das Warum wird im Rahmen dieser TradeOﬀ-Analyse für alle sichtbar und transparent, und jeder weiß, warum ich manche Architekturen besser- oder eben weniger gut - eignen.

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 triﬀt die Geschäftsseite auf dieser Basis. Sie hat dabei auch die Freiheit, von der empfohlenen Strategie abzuweichen - dieses mal aber im vollen Bewusstsein der Konsequenzen dieser Entscheidung.

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 geschaﬀen, 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 geschaﬀen, 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 ﬁndet 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 ﬁndet nur eine Applikation statt - er sieht nicht, welche Teile von der neuen und welche Teile von der alten Software kommen. Am Ende, wenn alle Teile von der neue Applikation übernommen sind ist die Modernisierung vollendet - und sie funktioniert garantiert, denn der ganze Prozess ﬁndet in Produktion statt.

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-Beneﬁt 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 geschaﬀen, umgesetzt und getestet - bei der Durchführung - denn sie muss unter Umständen bei sehr vielen Features umgesetzt werden - und schliesslich bei der Nachbereitung - also bei dem Entfernen der temporären Strukturen. Diese Aufgaben erzeugen Aufwand, ohne dass ein unmittelbarer Aufwand dahinter steht.

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 ﬁndet 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 ﬁxen 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 Pﬂicht: Intentional Architektur entdecken auf Basis der Businesstreiber gemeinsam & explizit evaluiert Umsetzungsplan Architectural Enabler Migrationsaufgaben Organisation Balance zwischen Tech & Features Reihenfolge & Prediction erlauben Damit habe ich eigentlich alles, was ich zur Arbeit an einer Modernisierung als gemeinsames Bild und erste Idee brauche, und ich kann loslegen. Muss ich das genau so machen? Natürlich nicht, aber die dahinter stehenden Aufgaben muss ich trotzdem machen: - die Businesstreiber der Zielarchitektur ermitteln - die Zielarchitektur auf dieser Basis ﬁnden - die Architektur - und Migrationsthemen sammeln - eine Organisation etablieren, die die Balance zwischen Modernisierung, Roadmap und Daily Business erlaubt, um die Modernisierung nicht zu verschleppen und trotzdem Business zu beliefern.

E-Commerce vs Architektur CodeTalks.Commerce_2018

Esté a ler uma amostra.

Confira estes a seguir

E-Commerce vs Architektur CodeTalks.Commerce_2018

Mais Conteúdo rRelacionado

Diapositivos para si (20)

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

Mais de Johann-Peter Hartmann (20)

Mais recentes (20)