Enterprise Architekturen müssen agile Prozesse befördern, indem sie kurze Rückkopplungszyklen ermöglichen und das Vorgehensmodell unterstützen. Dafür betrachte ich Enterprise Architekturen aus dem Blickwinkel der agilen Software-Entwicklung. Im Vortrag identifiziere ich Architektur-Muster auf der Makro-Ebene, die Verantwortung dezentralisieren, Abhängigkeiten auflösen und Rückkopplung beschleunigen.

2. Anpacken.

3. Begeistern.

4. Entkoppelt, schnell, flexibel:
Agile Enterprise Architektur
Dr. Wolf-Gideon Bleek

5. Wider der Zentralisierung

6. Wir sind it-agile
• ca. 40 Mitarbeiter
• Erfahrung mit agilen
Methoden seit 2001
• Hamburg & München
• Zahlreiche
Publikationen
• Organisation,
Prozesse, Technik

7. Ich bin Wolf-Gideon Bleek
• Studium Informatik
• Promotion in Softwaretechnik
• 30 Jahre Beratungserfahrung
• Spaß an der Technik
• Agiler Engineering Evangelist
wgb@it-agile.de @VonWiedegong

8. www.menti.com
55 71 85
Zuerst eine kurze Umfrage

9. Motivation

10. “I call it the endgame fallacy.“
https://unsplash.com/

11. – Dr Donald Ferguson, CTO of CA Technologies
What's the biggest technology mistake you ever made -
either at work or in your own life?
„When I was at IBM, I started a product called Websphere [which helps companies to
operate and integrate business applications across multiple computing platforms].
Because I had come from working on big mission-critical systems,
I thought it needs to be scalable, reliable, have a single point of control ...
I tried to build something like a mainframe,
a system that was capable of doing anything,
that would be able to do what might be needed in five years.
I call it the endgame fallacy. It was too complex for people to master. I overdesigned it.
Because we were IBM, we survived it, but if we'd been a start-up, we'd have gone to the
wall.“
http://www.bbc.com/news/business-11944966

12. Systeme werden größer
• Weil mehr Standard-Funktionen
erwartet werden (Kundenkonto,
Lieferanschriften, Rabattcodes
Artikelbewertungen etc.)
• Weil sie heute mehr können müssen
(multi channel, multi language etc.)
• Weil immer mehr integriert wird
(Versender, Bezahlsysteme, Social
Media etc.)

13. Komplex
EnterpriseArchitekturensind
•groß,
•habenvielezentraleElemente,
•etabliereninterneStandards

14. Klassische Enterprise Architektur
Quelle: IBM RedPaper „SOA Banking Business Pattern“
• Zentrale Komponenten
• Zentrale Kommunikation
• Redundanzfrei

15. Gleich-
förmigkeit
TechnologienwerdenamAnfang
ausgewählt.
NichtalleProblemesindschonbei
Projektbeginnbekannt.

16. Langsam
Abstimmungenbrauchenlange
ProzessemüssenüberTeams
koordiniertwerden

17. FeedbackFeedbackkannselteneingeholt
werdenoderfindetnichtstatt

18. Viele sind
unglücklich
Anforderungenstauensich
EntwicklersehenihreArbeitspätin
Produktion.
NutzersehenspätErgebnisseimSystem

19. Warum schränken wir uns unnötig ein?
• wir verzichten auf mögliche Environments
• wir verzichten auf mögliche Releases
• wir verzichten damit auf frühzeitiges Feedback

20. Was nützt mir eine saubere Architektur …
… wenn die darin implementierte Lösung
nicht zum Problem passt?

21. Agile Zielsetzung

22. Wird die Software den Geschäftszielen gerecht?

23. Wird die Software den Geschäftszielen gerecht?

24. Rückkopplung beschleunigen
https://unsplash.com/

25. Abhängigkeiten auflösen
https://unsplash.com/

26. Abhängigkeiten auflösen
https://unsplash.com/

27. Verantwortung dezentralisieren
https://unsplash.com/

28. Ziel: Langfristig dauerhaftes
und schnelles Feedback

29. Was tat uns weh?
und wie hat es gewirkt?

30. Maschinen
eigeneMaschinensindteuer
Aber:MaschineninderCloud/on
demandwerdenimmerbilliger
https://unsplash.com/

31. Lizenzen
Lizenzkostenverhindernmehrere
ExemplaredesSystemzuerstellen.
FürvieleAnwendungsfällegibtes
kostenloseLizenzen
https://unsplash.com/

32. Kommuni-
kation
ImTeam:einfach,schnell,
kostengünstig
Team-übergreifend:aufwendig,
langsam,kostenintensiv
https://unsplash.com/

33. Kommunikation mit mehreren Teams ist
schrecklich aufwendig

34. Replikation /
Redundanz
Früher:Vermeiden,Teufelszeug
Heute:Handhabbar

35. WartenLangsame(manuelle)Prozesse
verzögernFeedback
https://unsplash.com/

36. Redundanzkosten vs. Kommunikationskosten
Kosten
Isolierungsgrad der Teams
Kosten durch Redundanz

37. Redundanzkosten vs. Kommunikationskosten
Kosten
Isolierungsgrad der Teams
Kosten durch Redundanz
Abstimmungskosten

38. Redundanzkosten vs. Kommunikationskosten
Kosten
Isolierungsgrad der Teams
Kosten durch Redundanz
Abstimmungskosten
Gesamtkosten

39. Redundanzkosten vs. Kommunikationskosten
Kosten
Isolierungsgrad der Teams
Kosten durch Redundanz
Abstimmungskosten
Gesamtkosten

40. Redundanzkosten vs. Kommunikationskosten
Kosten
Isolierungsgrad der Teams
Kosten durch Redundanz
Abstimmungskosten
Gesamtkosten
Ein Team

41. Redundanzkosten vs. Kommunikationskosten
Kosten
Isolierungsgrad der Teams
Kosten durch Redundanz
Abstimmungskosten
Gesamtkosten
Zwei Teams

42. Redundanzkosten vs. Kommunikationskosten
Kosten
Isolierungsgrad der Teams
Kosten durch Redundanz
Abstimmungskosten
Gesamtkosten
Viele Teams

43. Schlagt die Software klein

44. Unab-
hängigkeit
herstellen
WirbefreienunsvonRestriktionen
WirakzeptierenkeinWarten
WirnutzenRedundanzbewusst

45. Hin zu kleinen Einheiten

46. Hin zu frei duplizierbarer Software

47. Kommunikation in kleinen Gruppen

48. Kein Warten

49. Jedem seine Kopie

50. Wie machen wir das?

51. Wie machen wir das?
Alle notwendigen
Komponenten sind dabei

52. Wie machen wir das?
Alle notwendigen
Komponenten sind dabei
Umfang auf Minimum
reduzieren

53. Wie machen wir das?
Alle notwendigen
Komponenten sind dabei
Umfang auf Minimum
reduzieren
Unabhängige Einheiten
nutzen

54. Wie machen wir das?
Alle notwendigen
Komponenten sind dabei
Umfang auf Minimum
reduzieren
Unabhängige Einheiten
nutzen
Self-contained system micro services container

55. So könnte ein Einheit aussehen
Microservice
Kundendaten
http(s)
Microservice
E-Mail Versandt

56. Für jedes Environment ein Exemplar
h
Development
h
Build h
Testing
h
Staging
h
Production

57. Für jede Aufgabe ein separates System
h
Landing Pages
h
Shoph
Tracking
h
Accounting

58. Finish

59. Freiheit
TeamskönnenTechnologieselber
wählen
NurwenigeEntscheidungenmüssen
mitanderenabgestimmtwerden

60. WET
statt
DRY.
WriteEverythingTwice

61. Kontra-
intuitiv:
Redundanz
Aber:Esgibtdanntrotzdem
einenFail!

62. Kontra-
intuitiv:
Redundanz
Aber:Esgibtdanntrotzdem
einenFail!

63. Kontra-
intuitiv:
Redundanz
Aber:Esgibtdanntrotzdem
einenFail!

64. Chance 1NiewiedereinkompletterRe-Write

65. Dritter Anlauf Nudeln richtig hinzubekommen
Spaghetti Lasagne Ravioli

66. MigrationIchkannauchschonallesNeueauf
dieseArtmachen(Migrationspfad)

68. Wolf-Gideon Bleek
Anpacken.
Begeistern.

70. Hier wird ähnlich gedacht
• Self-Contained-Systems - Assembling Software from Independent Systems, http://scs-architecture.org
• Von Monolithen und Microservices, Guido Steinacker, 6/2015, https://www.informatik-aktuell.de/
entwicklung/methoden/von-monolithen-und-microservices.html
• Systainable Architecture, Stefan Tilkov, 8/2014, https://speakerdeck.com/stilkov/sustainable-
architecture
• InfoQ„Self Contained Systems (SCS): Microservices Done Right“, Eberhard Wolff https://
www.infoq.com/articles/scs-microservices-done-right.
• Sven Günter, Andreas Havenstein: Prinzipien für skalierbare Architekturen, Developer Week 2014
• Agile Review 2017/01„Self-Contained-Systems mit Containern und Micro-Services für einen agilen
Entwicklungsprozess“, Dr. Wolf-Gideon Bleek, it-agile GmbH.

71. Danke
AnHolgerBohlmann,Henning
Wolf,AndreasHavensteinundSven
GünterfürihreBeiträgezudiesem
Vortrag.