Architecture Gathering 2016 – Das interessiert Architekten heute

Am 12. und 13. Oktober fand in München das Architecture Gathering 2016 statt. Mehr als 250 Softwarearchitekten aus unterschiedlichsten Domänen und Firmen kamen zusammen, um viele interessante Vorträge zu hören und Diskussionen zu führen.

Vom Fraunhofer IESE aus der Abteilung „Architecture-Centric Engineering“ waren wir auch gut vertreten und möchten in diesem Artikel die sehr interessante und toll organisierte Konferenz Revue passieren lassen. Den Artikel haben wir gemeinsam verfasst: Taslim Arif, Susanne Braun, Sebastian Heupts, Matthias Gerbershagen, Torsten Lenhart, Matthias Naab, Dominik Rost, Marcus Trapp und Balthasar Weitzel.

Breite Abdeckung des Themenspektrums Softwarearchitektur

Softwarearchitektur ist ein breites Themenspektrum, dem die Konferenz aus unserer Sicht sehr gut gerecht wurde. Die Vorträge griffen jeweils eines oder mehrere der folgenden Themen auf:

  • Methodik (z.B. Architekturarbeit in agilen Projekten)
  • Design (z.B. basierend auf Domain-Driven Design)
  • Technologie (z.B. Javascript, Cloud)
  • Qualitätsattribute (z.B. Resilience, User Experience)
  • Architektur & Code (z.B. Technical Debt, Architekturrekonstruktion)
  • Neue Paradigmen (z.B. Microservices)
  • Architekturpatterns (Historie auf 20 Jahre Patterns)

Übersicht

Why Architects Fail | Architektur und UX | Microservices | Architektur im Code | Javascript | Architektur in der Softwaretechnik | 20 Jahre Design Patterns | Fazit

Why Architects Fail

In seiner hochinteressanten Keynote mit dem Thema „Why Architects Fail“ widmete sich Stefan Tilkov (@stilkov), Geschäftsführer und Principal Consultant bei InnoQ, typischen, kontraproduktiven Verhaltensweisen von Software-Architekten, die letztendlich den Projekterfolg gefährden können. Als Analogie verwendete er dabei den medizinischen Krankheitsbegriff und erläuterte die wichtigsten zehn „Berufskrankheiten“ von Software-Architekten anhand ihrer Symptome und Auswirkungen. Als Zuhörer konnte man sich dabei das stetige Nicken nicht verkneifen, weil man die beschriebenen „Diseases“ nicht nur bei Anderen, sondern teilweise auch bei sich selbst schon mehr als einmal beobachtet hatte. So nannte er beispielsweise den „Over-Generalization Drive“, der sich dadurch äußert, dass man zwanghaft versucht, überall Gemeinsamkeiten zu identifizieren und darauf aufbauend, möglichst generische Lösungen aufzusetzen. Diese sind dann aber aufgrund ihrer Abstraktheit nur schwer verwendbar, erhöhen aber gleichzeitig quasi als Nebenwirkung die Komplexität, was zu vielen Folgeproblemen führen kann. Ebenfalls beschrieb er die „Analysis Paralysis“, deren Symptom es ist, länger für die Auswahl der passenden Lösung für eine Aufgabe zu benötigen als dann für die Ausführung der Aufgabe selbst. Als drittes Beispiel für eine der genannten Architekten-Krankheiten sei noch die „Asset Addiction“ genannt, die gleich in zwei Ausprägungen auftritt: In der eher konservativen Variante ist der betroffene Architekt so auf ein Tool oder Framework fixiert, dass er oder sie es als Lösung für jedes Problem ansieht, frei nach dem bekannten Spruch „If you have a hammer, everything looks like a nail“. In der anderen Form ist der „Erkrankte“ versucht, jede neue Technologie einzusetzen, die gerade hip ist, egal ob sie gut auf die konkreten Bedürfnisse und den Kontext passt oder nicht. Diese drei Beispiele sollen die Stoßrichtung des Vortrags verdeutlichen, aber auch die übrigen beschriebenen Krankheiten waren griffig beschrieben und voll aus dem Alltag gegriffen.

Zum Schluss gab Tilkov offen zu, dass es keine universelle Medizin gibt, die alle diese Leiden heilen kann. Als Prophylaxe für die Vermeidung der beschriebenen Berufskrankheiten kommt es nach seiner Meinung darauf an, dass Software-Architekten nicht nur die richtigen Eigenschaften und Einstellungen mitbringen, sondern diese auch optimal „dosiert“ sind. Besonders wichtig sind dabei Erfahrung und Pragmatismus, es werden aber auch Dogmen und Regeln, Flexibilität, Minimalismus, Kenntnis der technischen Entwicklung, Experimentierfreudigkeit und aktive Mitarbeit benötigt.

Fishbowl: Kann man jede Architekturentscheidung mit einem Geldbetrag bewerten?

dsc_1241

In einer lebhaften Fishbowl-Diskussion kamen zahlreiche Besucher und Sprecher der Konferenz zu Wort. Das zentrale Thema war die Frage, ob es möglich ist, an jede Architekturentscheidung einen Geldbetrag zu heften, sodass klare quantitative Vergleiche zwischen Alternativen möglich werden. Während sich viele Teilnehmer einig waren, dass das zwar schön wäre, gab es weitgehenden Konsens, dass dies aktuell nicht möglich ist und auch nicht möglich sein wird. Zu vielfältig sind die Konsequenzen wichtiger Architekturentscheidungen (direkte und spätere Auswirkungen, Auswirkungen auf vielfältige Qualitätsattribute, Auswirkungen auf Menschen und Organisation), als dass eine präzise Bewertung mit einem Geldbetrag möglich wäre.

Insgesamt sehen nahezu alle Diskussionsteilnehmer einen starken Bedarf an verfügbaren empirischen Erfahrungen aus Softwareprojekten, die Architekten bei der Bewertung von Entscheidungen und deren Auswirkungen helfen würden. Durch die extrem vielen Einflussfaktoren, die bei Untersuchungen berücksichtigt werden müssen, ist es extrem schwierig, die richtigen und wichtigsten Einflussfaktoren mit ihren Konsequenzen zu isolieren. Erschwert wird die Sammlung von empirischen Daten zu Architekturentscheidungen dadurch, dass sich die Architekturen von Systemen durch neue Trends und Technologien ständig weiterentwickeln.

Trotzdem ist es in der Praxis sehr hilfreich, zumindest eine Bewertung vorzunehmen, so gut es eben geht. Insbesondere in der Kommunikation mit Sponsoren und Management wird es Architekten oft abverlangt, mit wirtschaftlichen Größen zu argumentieren. Dazu sind dann eben Vereinfachungen und Annahmen nötig. Bei vielen Architekturentscheidungen muss aber eine wohlüberlegte qualitative Abwägung ausreichen und oft auch die Erfahrung und das Vertrauen in die Architekten.

Software Architektur & User Experience

2016-10-12-the-architecture-gathering-naab-trapp

In unserem eigenen Vortrag betrachteten Matthias Naab und Marcus Trapp die Beziehung der Themengebiete Software Architektur und User Experience. Zwei Software Engineering Disziplinen, die auf den ersten Blick nicht nur wenig miteinander zu tun haben, sondern auch meist von sehr unterschiedlichen Personengruppen vertreten werden. Wir stellten daher die Frage: „Wie finden Softwarearchitekten den Weg zu User Experience?“ und gaben auch sogleich die Antwort: „Mit Google Maps!“. Dabei diente uns Goolge Maps als Beispiel-Anwendung, um herauszustellen, warum beiden Disziplinen eng zusammenarbeiten müssen.

Um das Publikum auf das Themengebiet einzustimmen, stellten wir zunächst die beiden Personengruppen beabsichtigt stereotypisch vor, um die derzeit durchaus noch verbreitete Kluft zwischen Softwarearchitekten und User Experience Designern aufzuzeigen.

dsc_1223

Um jedoch ein Softwaresystem zu erschaffen, das trotz erheblicher Komplexität der Anwendung dennoch so einfach zu benutzen ist und in vielen Lebenslagen der Anwender Reisen zum Erlebnis macht, müssen „Architekten“ und „UX-ler“ zusammenarbeiten. Hierzu muss ein gegenseitiges Verständnis bezüglich der Aufgaben, Anforderungen, Ziele und auch Methoden der jeweils anderen Disziplin aufgebaut werden. Denn im engen Dialog können Missverständnissen frühzeitig erkannt werden. So stehen hinter zunächst einfach wirkenden neuen Anforderungen oft hochkomplexe technischen Änderungen, die architektonische Höchstleistungen erfordern.

Plant man beispielsweise eine Reise von Kaiserslautern nach München mit dem Auto, so schlägt Goolge Maps nicht nur eine schnelle Route vor, sondern gibt auch direkt an, wie lange man mit dem Auto für diese Strecke braucht. Sowohl die Route selbst als auch die Zeitangabe werden in weniger als 1 Sekunde angezeigt. Dies ist nur möglich, da Google diese Strecken schon vorberechnet hat und somit nach Anfrage, direkt das Ergebnis liefern kann, ohne Route und Zeit jedes Mal neu berechnen zu müssen. Als Benutzer von Google Maps sind wir an diese Schnelligkeit gewöhnt und sie ist Teil der Google User Experience. Irgendwann kam jedoch ein User Experience Designer von Goolge auf die Idee, um eine noch bessere User Experience zu erreichen, soll ab jetzt bei jeder Routenplanung die aktuelle Verkehrssituation mit einbezogen werden, sowohl bei der Streckenplanung, als auch bei der Zeitberechnung. Dies hört sich zunächst nicht nach viel Aufwand an. Denn die Straßenkarte liegt schon vor, daran ändern sich auch nichts. Nun muss der Softwarearchitekt „einfach“ die Zeitdurchschnittswerde für die Strecken durch die jeweils aktuellen Zeitwerte ersetzen. Auch diese Werte liegen Google schon vor, da sie auf Basis der Positionsdaten von unzähligen Android Geräten ermittelt wurden. Somit muss der Architekt „nur“ die einen Zahlen durch die anderen ersetzen. Dabei hat der UX-ler leider nicht beachtet, dass nun eine Vorberechnung der Daten nicht mehr so einfach wie bisher möglich ist, da sich die Datengrundlage ständig ändert. Wird die Berechnung jedoch erste dann durchgeführt, wenn ein Benutzer die Routenplanung anfordert, dann würde dies viel länger dauern, als bei der bisherigen Lösung. Dies hätte einen signifikant negativen Einfluss auf die Google User Experience. Um die User Experience beizubehalten, oder durch die neue Funktionalität sogar noch zu verbessern, erfordert es gewaltige Anstrengungen in der Systemarchitektur.

Im stetigen Dialog zwischen Softwarearchitekten und User Experience Designern kann ein solches Missverständnis jedoch aufgeklärt werden. Gemeinsam kann dann an einer Lösung gearbeitet werden.

dsc_1230

Microservices – Der Schnitt ist entscheidend

Wie auch bereits im vergangenen Jahr gab es zahlreiche Vorträge, die sich mit dem Thema Microservices beschäftigten. Die wichtigste Lessons Learned vom diesjährigen Architectrue Gathering ist, dass bei einer Mircoservice-Architetkur der Schnitt der Microservices ganz entscheidend ist. Dabei handelt es sich um keine triviale Aufgabe: „You rarely get service granularity right the first time!“ (Mark Richards, https://github.com/wmr513/microservices-antipatterns-workbook). Es gibt aber glücklicherweise eine ganze Menge Patterns aus dem Domain Driven Design (DDD) von Eric Evans, die sich so gut auf Microservice-Architekturen anwenden lassen, dass man den Eindruck gewinnen könnte, Evans hätte sie schon immer für Microservice-Architekturen entwickelt. Michael Plöd (@bitboss) hat in seinem Vortrag einen sehr guten Überblick über die für Microservice-Architekturen relevanten Patterns aus dem DDD gegeben. Dabei sind insbesondere vier Bereiche aus dem DDD hervorzuheben:

  1. Strategic Design (Microservice Context)
  2. Large Scale Structure (Evolution der Microservice-Landschaft)
  3. (Internal) Building Blocks (Internes Microservice Design)
  4. Destillation (Extraktion von Microservices aus einem Monolithen).

Dabei ist Strategic Design mit der Idee des Bounded Context der relevanteste Bereich. Im Gegensatz zu früheren Enterprise-Architecture- und Enterprise-Information-Integration-Bestrebungen wird nicht versucht ein universelles und übergreifendes Datenmodell für die gesamte fachliche Domäne zu finden. Stattdessen ist das zu einem Bounded Context gehörige Modell nur für einen bestimmten Anwendungs-Kontext gültig. Eine anspruchsvolle Domäne besteht normalerweise aus mehreren Bounded Contexts. Beispielsweise können bei einem Webshop die Vorgänge Registrierung, Bestellung und Bezahlung als drei verschiedene Bounded Contexts angesehen werden. In jedem dieser Bounded Contexts wird der Kunde als Teil des Modells repräsentiert sein. Allerdings hat jeder Bounded Context sein eigenes Modell und damit auch eine eigene Sicht auf das Entity „Kunde“. Während der Registrierung interessieren beispielsweise Name, Anschrift, Alter und E-Mail-Adresse des Kunden. Bei der Bestellung wird womöglich nur die ID und der Name des Kunden benötigt. Und bei der Bezahlung sind wiederum die ID, der Name und die Kreditkartendaten des Kunden relevant. Obwohl jeder Bounded Context eine eigene Repräsentation des Kunden in seinem Modell hat, werden deutlich weniger Daten in den verschiedenen Bounded Context redundant gehalten, als man vielleicht initial erwarten würden. Durch den Schnitt der Bounded Contexts kann man entscheidend beeinflussen, wie die Sicht auf die Daten in den jeweiligen Bounded Contexts aussieht und ob dadurch mehr oder weniger Daten-Redundanz eingeführt wird oder nicht. Eberhard Wolff (@ewolff) hat diese Erkenntnis sehr anschaulich präsentiert. In Bezug auf Microservice-Architekturen entspricht jeder Bounded Context einem Microservice und damit einer Deployment Unit bzw. einem (DevOps-) Team. Insgesamt trägt dies erheblich zur Entkopplung und Isolation von Microservices bei und ermöglicht damit erst das (weitgehend) unabhängige Weiterentwickeln von Microservices durch unterschiedliche Teams mit geringen Abstimmungsaufwänden zwischen diesen Teams. Dennoch müssen Daten und Modelle zwischen den verschiedenen Microservices propagiert werden. Hierfür gibt es auch verschiedene Patterns im DDD, die dann wiederum maßgeblichen Einfluss auf die Aufwände der verbleibenden erforderlichen Abstimmungen zwischen den verschiedenen Teams haben. Eberhard Wolff hat auch dies in seinem Vortrag sehr klar herausgearbeitet.

ddd

Neben dem Strategic Design ging Eberhard Wolff in seinem Vortrag auch auf den wichtigen Aspekt der Daten-Replikation bei Microservice-Architekturen ein. Er stellte in diesem Zusammenhang verschiedene Konzept wie Event-Replikation, Event Sourcing, Command – Query Responsibility Segregation (CQRS) und Batch-Replikation vor und zeigte die Vor-und Nachteile der jeweiligen Methoden auf. Weitere spannende Microservice-Themen auf dem Architecture Gathering waren Resilience mit Hystrix (Benjamin Wilms und Felix Braun), sowie die Überführung von Monolithen in Microservice-Architekturen (Harm Gnoyke).

Architektur muss sich im Code verständlich wiederfinden

Viele Parallelen zu unserer täglichen Arbeit in Entwicklungsprojekten konnten mit dem Vortrag „Mob-Architekturverbesserung“ von Carola Lilienthal gezogen werden. Sie stellte noch einmal die Wichtigkeit einer verständlichen implementierten Architektur dar, insbesondere vor dem Hintergrund, dass bei Wartung und Erweiterung von Softwaresystemen 70% der Zeit für das Verstehen von bestehendem Code verwendet wird. Im Gegensatz dazu ist es offensichtlich, dass die 10% für das eigentliche Schreiben des Codes nicht im Hauptfokus von Optimierungen liegen sollten. Wenn also ein Großteil der Entwicklungsarbeit aus dem Verstehen von existierendem Code besteht, wie kann dann die Verständlichkeit der Architektur verbessert werden?

Dazu ging Carola Lilienthal auf die kognitiven Mechanismen ein, die Menschen helfen, komplexe Zusammenhänge zu verarbeiten: Chunking, Bildung von Hierarchien und Aufbau von Schemata. Die Herausforderung besteht nun bei verständlicher Architektur darin, diese Mechanismen nicht zu behindern und so gut es geht eben auch zu fördern. Hierbei stellte sie den kognitiven Vorgängen architekturelle Eigenschaften gegenüber: Modularität, Hierarchisierung und Musterkonsistenz.

Gerade auch aus eigener Erfahrung mit langlebigen Entwicklungsprojekten ist die Bewahrung dieser Eigenschaften schwierig und erfordert kontinuierliche Investition. Mit dieser Erkenntnis rundete Carola Lilienthal ihren Vortrag ab und stellte ein von ihr in Projekten erprobtes Vorgehen dar: Das Entwicklungsteam wird in die Lage versetzt, solche Verletzungen der Verständlichkeit fördernden Eigenschaften zu erkennen. Dazu werden einfache Architekturregeln definiert und unter anderem auch mit Hilfe von Reverse-Engineering-Tools deren Einhaltung im Code überprüft. Verletzungen dieser Regeln werden in einer Art Backlog gesammelt. Aus diesem werden dann regelmäßig hoch priorisierte Punkte abgearbeitet. Steht genügend Zeit dafür zur Verfügung, so wird kontinuierlich gegen Erosion gearbeitet und langfristig eine effiziente Entwicklung ermöglicht.

C64 Programmierung und JavaScript Architekturen

In einem sehr unterhaltsamen und technisch ausgezeichneten Vortrag im C64-T-Shirt berichtete Oliver Zeigermann über „harte Grenzen“ von unterschiedlichen Web-Architekturen bzw. Javascript Frameworks. Der interesse-weckende Titel des Vortrags suggerierte Erkenntnisse aus der C64 Programmierung für heutige Web-Anwendungen. Leider war diese Analogie etwas dünn und diente nur zur Einleitung der Erkenntnis, dass es „harte Grenzen“ von Technologien gibt, sodass diese den Anforderungen und Anwendungsfällen nicht gerecht werden können. Als Beispiel diente die C64-Programmierung mit BASIC und der Wunsch ein grafisches Spiel auf dem C64 zu verwirklichen, was sich als unmöglich gestaltete und dann die Verwendung von Assembler notwendig machte.

Oliver Zeigermann zeigte im Folgenden die von ihm erlebten „harten Grenzen“ von Web-Architekturen und -Frameworks und zeichnete damit die Entwicklung der letzten Jahre im Bereich von Javascript-Bibliotheken und Frameworks nach. Angefangen mit den Grenzen der klassischen, serverseitig gerenderten Web-Anwendung, über die Grenzen der Kombination von einzelnen Javascript oder jQuery-Schnippseln zu dem seit inzwischen geraumer Zeit populären Single Page Application Webframework AngularJS 1. Dessen harte Grenze sei die unklare Anwendungsstruktur und das 2-Wege-Data-Binding in größeren, komplexeren Anwendungen. Die Konsequenzen dieser Erkenntnisse finden sich bereits in der zweiten, vollständig überarbeiteten Version von AngularJS wieder. Hier wurde zum Beispiel bewusst auf das 2-Wege-Data-Binding verzichtet und auf Components gesetzt. Beeinflusst wurde AngularJS 2 auch vom in der Zwischenzeit entwickelten Javascript Bibliothek React. Die „harte Grenze“ von AngularJS2 und React zeige sich laut dem Sprecher Oliver Zeigermann bei Anwendungen mit einem verteilten veränderlichen Zustand und dem Umgang mit Nebenläufigkeiten, sowie durch die Vermischung von Framework und UI-Logik. An dieser Stelle hilft die Verwendung der Flux-Architektur bzw. der Bibliotheken Redux oder @ngrx/store, in der der Zustand der Anwendung zentral gehalten wird und der Kontroll- und Datenfluss immer in eine Richtung geht. Als weitere „harte Grenze“, die der Sprecher bei der Realisierung von Web-Anwendungen mit SPA erfahren musste, stellte er die Nachteile von SPAs selbst dar und präsentierte mit dem so genannten „Universal Rendering“ die Lösung. Dabei wird für den ersten Aufruf der Inhalt auf dem Server gerendert, im Folgenden dann auf dem Client, wodurch z.B. die Suchmaschinen-Indizierung wieder funktioniert.

Ganz passend zur wahnsinnig schnellen Entwicklung im Javascript-Bereich endete Oliver Zeigermann die Aufzählung mit der Aufforderung, dass man ihn nächstes Jahr über die nächste „harte Grenze“ fragen könne. Angesichts der steigenden Verbreitung und Nutzung der aktuell vorhandenen Lösungen und dem einhergehenden Lern-Effekt innerhalb der Community, wird die schnelle Entwicklung vermutlich weitergehen.

Keynote: Architektur in der Softwaretechnik

Christiane Floyd beleuchtete in ihrer kurzweiligen Keynote am zweiten Tag der Konferenz verschiedene grundlegende Aspekte der Softwarearchitektur und ihre historische Entwicklung. In den 1960er Jahren führte leistungsfähigere Hardware zur Entwicklung von großen Softwaresystemen. Man erkannte in der Praxis nach einigen Fehlschlägen schnell die Notwendigkeit von Softwarearchitektur. Das Ziel war es die Komplexität bei der Entwicklung großer Softwaresysteme zu reduzieren. Dazu wurden auch die heute allgemein bekannten, grundlegenden Prinzipien für Softwarearchitektur, wie das Geheimnisprinzip, Schichtung, Kopplung und Kohäsion, Datenabstraktion und Datenkapselung eingeführt. Erste Referenzarchitekturen, die diese Prinzipien umsetzten, entstanden. Dabei wurde außerdem bemerkt, dass sich bestimmte, allgemeine Lösungen für Probleme als Architekturmuster in anderen Softwaresystemen wiederverwenden lassen.

Seit etwa 1990 ist Softwarearchitektur als Fachgebiet etabliert. Jedoch ist das Berufsbild eines Software Architekten bis heute nicht genau definiert.Trotz der Einführung von neuen Werkzeugen und Methoden erfordert die Entwicklung einer Softwarearchitektur immer noch kreatives Denken und Abstraktionsvermögen. Neue Technologie, vernetzte Systeme und die Veränderung von anderen äußeren Gegebenheiten werden auch in Zukunft neue innovative Lösungsansätze im Bereich der Software Architektur erfordern.

Christiane Floyd beleuchtete auf ihrer Reise in die Historie der Softwarearchitektur viele weithin bekannte Aspekte auf sehr ansprechende Weise. Einen Schritt zurückzutreten und losgelöst von aktuellen Technologien die Historie unseres Arbeitsfeldes zu betrachten dürfte jedem Softwarearchitekten gut tun.

20 Jahre Design Patterns

Michael Stal von Siemens nahm die Teilnehmer mit auf eine historische Reise durch die Entwicklung und Etablierung von Design Pattern. Design Pattern als Lösungen für wiederkehrende Probleme sind wichtig und bewährt in der Softwarearchitektur. 1994, vor mittlerweile mehr als 20 Jahren startete die Pattern-Bewegung mit dem berühmten Gang-of-Four Buch (Gamma et al) „Design Patterns: Elements of Reusable Object-Oriented Software“. Die Design Patterns waren sprachunabhängig aber nah am Code. Der Ansatz wurde so populär, dass viel Patterns gefunden, gebraucht und auch missbraucht wurden.

Eine weitere wichtige Serie zu diesem Thema ist die Buchreihe „Pattern-Oriented Software Architecture“. Diese Bücher widmen sich eher Pattern auf der Systemebene, was eine wichtige Evolution der Design Patterns aus Architektensicht war. Weitere Ansätze und Trends ergaben sich:

  • Einführung von Patternsprachen
  • Automatisiertes Mining von Patterns mittels Reverse Engineering
  • Beschreibung von Anti-Pattern, die man eher vermeiden sollte
  • Versuche, Pattern zu patentieren
  • Versuche, Pattern stärker zu verallgemeinern, sodass sie für alle Kontexte passen
  • Dokumentation von Pattern
  • Erstellung von Pattern-Katalogen, um diese einfach zugänglich zu machen
  • Patterns, um bestimmte Qualitätsattribute wie Performance oder Skalierbarkeit zu erreichen

Auch nach 20 Jahren sind Design Pattern noch sehr relevant als Werkzeug für Softwarearchitekten. Pattern sind eine großartige Möglichkeit, um Expertenwissen zu bewahren. Dadurch können sie viel Zeit sparen und das gemeinsame Verständnis erleichtern. Es hat sich aber die Erkenntnis etabliert, dass Design Pattern nur ein Lösungsskelett und Baukasten sein können. Menschen müssen immer noch den Kontext verstehen, die konkreten Herausforderungen analysieren und die Patterns bestmöglich in die Gesamtlösung einpassen. Wir werden viele weitere Jahre von Design Pattern profitieren und es werden immer neue hinzukommen.

Nicht neu, aber wieder sehr aktuell …

Zwei Dinge fielen uns auf, die, obwohl schon etwas betagter, eine Art Revival erleben und Einzug in zahlreiche Vorträge gefunden haben:

  • Conway’s Law: Schon 1967 formuliert, drückt es den Zusammenhang zwischen der Architektur von Softwaresystemen und der Struktur der entwickelnden Organisation aus. Insbesondere im Zusammenhang mit Microservices taucht Conway’s Law wieder auf, aber auch bei der Analyse von technischen Schulden und der historischen Betrachtung von Legacysystemen.
  • Domain-Driven Design: 2004 stellte Eric Evans seine Leitlinie für die fachliche Modellierung von Systemen vor. Während davon auf Architekturkonferenzen über Jahre nichts zu hören war und fachliches Design eher außen vor war, haben gerade Microservices auch dieses Thema wieder aufleben lassen: Die Frage, wie Services fachlich geschnitten werden können, findet viele Anregungen und Antworten im Domain-Driven Design.

Fazit

Das Architecture Gathering war wieder ein voller Erfolg mit vielen zufriedenen Teilnehmern. Bleibt zu hoffen, dass es sich als feste Größe in der Konferenzlandschaft weiterhin etablieren kann und zahlreichen Softwarearchitekten als Treffpunkt dient.

Why Architects Fail | Architektur und UX | Microservices | Architektur im Code | Javascript | Architektur in der Softwaretechnik | 20 Jahre Design Patterns | Fazit

Kommentar schreiben

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.