Am 16./17. Oktober fand in London die O’Reilly Conference Software Architecture statt. Wir waren mit unserem Talk „How do software architects find the way to user experience? With Google Maps“ dabei. In diesem Artikel lassen wir die Konferenz Revue passieren.

Die Konferenz war sehr gut besucht (geschätzt ca. 500 Leute) und zog Architekten und Entwickler aus ganz Europa, aber sogar auch von anderen Kontinenten an.

Ein interessantes Konzept waren die recht kurzen Keynotes (ca. 20 Minuten). So wurden statt einer langen Keynote gleich 3 Keynotes am Stück präsentiert, was zu sehr pointierten und kurzweiligen Vorträgen führte.

Auch eine interessante Beobachtung (wie bei einigen vergangenen Veranstaltungen): Firmen sind aktuell stärker auf der Suche nach neuen Mitarbeitern als nach neuen Kunden! Architekten und Software Engineers im Allgemeinen sind aktuell also sehr gesucht!

Es gab Talks zu unterschiedlichsten Aspekten von Softwarearchitektur. Wir orientieren uns hier im Artikel an einer Charakterisierung von Architekturkompetenz und Architekturthemen, die wir im Blog auch demnächst noch beschreiben werden. Die Darstellung der Talks hier im Artikel soll nicht repräsentativ sein, sie spiegelt eher wieder, welche Talks wir uns angesehen haben und für besonders sehenswert halten. Meist sind auch die Folien der Talks verfügbar oder sogar Videoaufzeichnungen, die wir dann verlinkt haben.

• Architekturgrundlagen
• Architekturmethoden und –Tools
• Architekturelle Systemexpertise (Herausforderungen, Lösungskonzepte, Technologien, Frameworks, …)
• Architekturaspekte rund um Menschen und Organisationen

Zum Abschluss gab es als Übung und gemeinsames Event noch Architecture Katas, die wir am Ende des Artikels beschreiben.

Architekturgrundlagen

Mark Richards widmete sich in seiner Keynote „The move toward modularity“ dem Thema Modularität, das eine zentrale Rolle für Softwarearchitektur spielt und durch Microservices wieder mehr ins Bewusstsein gerufen wurde. Mark Richards beleuchtete verschiedene Facetten von Modularität, insbesondere auch die dahinterstehenden Ziele (bei ihm: Agility, Testability, Deployability, Scalability, Availability).

Architekturmethoden und –Tools

Der neue CTO Patrick Kua vom deutschen Fintech-Unternehmen N26 sprach über in unterhaltsamer und anschaulicher Weise über Architekturdokumentation. Dazu verwendete er als Analogie den Reiseführer: „The travel guide to a software system“.

Er beschäftigte sich mit zahlreichen Fragen rund um die Erstellung von guter und pragmatischer Architekturdokumentation:

• Gründe, sich mit Architekturdokumentation zu beschäftigen
  • Menschen kommen und gehen
  • Organisationen wachsen
  • Man hinterlässt mit einem System ein Vermächtnis
  • Zukünftige Arbeiten sollte nicht mit Detektivarbeit starten müssen
• Wichtigste Inhalte
  • Historie (Kontext, Entstehungsgeschichte, Erfahrungen, wichtigste Entscheidungen, …)
  • Sinnvolle Fakten (Domänenwissen, Akronyme, Personas, wichtigste Use Cases, …)
  • Kultur (Coding Guidelines, Konventionen im Code, Entwicklungsprozess, …)
  • Karten / Sichten (Gesamtsicht, verschiedene Aspekte und Sichten des Systems (z.B. C4 Model von Simon Brown), Sequenzdiagramme, Flussdiagramme, …)
  • Sehenswürdigkeiten (Wichtigste Punkte im System, Systeme häufigster Änderungen, …)
  • Fun (Fun Facts zum System, Stellen, an denen besonders innovative oder kreative Lösungen zu finden sind, …)
• Die Reise zur Architekturdokumentation
  • Ausgangspunkt (Immer vom Leser her denken, was sind die Use Cases von Dokumentation)
  • Größe (hängt von Historie, Menschen, Änderungsgrad und –geschwindigkeit, Domänenkomplexität ab)
  • Aktuell halten

Architekturelle Systemexpertise (Herausforderungen, Lösungskonzepte, Technologien, Frameworks, …)

Eoin Woods, CTO von Endava, sprach über Security aus Sicht des Architekten: „Practical security principles for the working architect”. Der Talk war extrem kurzweilig und stellte zentrale Sicherheitsprinzipien dar, die bei jedem Design einer Systemarchitektur durchdacht werden sollten. Insbesondere die Betrachtung von Security jenseits der reinen Codeebene (wie z.B. Lücken wie Buffer Overflows) ist sehr wichtig und wird häufig in der Praxis vernachlässigt. Eoin Woods zeigte an guten Beispielen auf, wie Architekturentscheidungen und verschiedene Modularisierungen zu unterschiedlich sicheren Systemen führen können.

Auch unser Vortrag „How do software architects find the way to user experience? With Google Maps“ passt in diese Kategorie. Er illustriert den engen Bezug zwischen User Experience und Softwarearchitektur, der immer noch zu wenig Beachtung findet. Das liegt unter anderem auch an den unterschiedlichen Ausbildungshintergründen von Softwarearchitekten und UX Designern. Am Beispiel von Google Maps zeigen wir auf, welche Architekturentscheidungen getroffen wurden, um die bekannt gute User Experience von Google Maps zu erreichen.

Yan Cui sprach zum Thema serverless computing am Beispiel von Amazon Web Services Lambda: „Serverless in production: An experience report“. Er berichtete von Erfahrungen bei ersten Experimenten und realem Einsatz von AWS Lambda. Er konnte mit vielen Beispielen und Fallstricken punkten und konnte somit der aktuell sehr gehypeten Technologie eine gute Erdung und viele Tipps zur Umsetzung geben.

Architekturaspekte rund um Menschen und Organisationen

Nathaniel Schutta gab eine großartige Keynote zur Kommunikation von Softwarearchitekten: „Architect as storyteller”.

Zwei Aspekte hat er dabei insbesondere herausgearbeitet:

• Zur Kommunikation braucht mal als Architekt (wie in anderen Rollen auch) klar herausgearbeitete Messages und eine konsistente Story. Ein Architekt muss ein „Keeper of Tales“ sein, er muss also viele gute Stories kennen. Dabei ist es nicht zwingend erforderlich, dass er die Story, die er erzählt selbst erlebt hat. Hauptsache es ist eine wahre Story, die sich gut zum Erklären eines bestimmten Sachverhalts eignet.
• Je nach Zielgruppe muss man die Messages und die Story stark anpassen. Da der Architekt potentiell mit sehr vielen verschiedenen Zielgruppen / Stakeholdern (Manager, Kunden, Produktmanager, Projektleiter, Entwickler, Tester, …) arbeitet, muss entsprechend angepasst werden. Das verursacht zwar Aufwand, lohnt sich aber weil ansonsten die Message nicht verstanden wird und dadurch viele Probleme verursacht werden.

Nick Tune widmete sich dem Thema Organisationsgestaltung durch Architekten: „Great technical architects must be great organization architects”. Im Kontext von Microservices hat Conway’s Law wieder sehr viel Aufmerksamkeit bekommen. Nick Tune erläuterte anschaulich, wie die integrierte Gestaltung von Organisationsstrukturen und Softwarearchitekturen dafür sorgen kann, Reibung in der Entwicklung zu erkennen und zu vermeiden und damit schneller Software liefern zu können.

Dazu gab Nick konkrete Beispiele, welche organisatorischen Entscheiden mit Aspekten der Systemdekomposition zusammenspielen. Ankerpunkt war dabei natürlich Domain-Driven Design und Bounded Contexts.

Nick ging darüber hinaus auch auf das oft vorherrschende Bild von rein technischen Softwarearchitekten im Elfenbeinturm ein. Seinen Vortrag gestaltete er dann als Plädoyer für eine andere Art von Softwar

earchitekten (den Sociotechnical Architect), die sich ganzheitlichen Aufgaben widmen und trotzdem mit der gebotenen Demut an die Aufgabe herangehen.

Architecture Katas

Zum Abschluss der Konferenz gab es im großen Stil die Möglichkeit, an Architecture Katas teilzunehmen. Die Idee dabei ist, Architekten die Möglichkeit zu geben, Architekturarbeit zu üben …

Dazu die zwei folgenden Zitate:

• „How do we get great designers? Great designers design, of course.“ –Fred Brooks
• „So how are we supposed to get great architects, if they only get the chance to architect fewer than a half-dozen times in their career?“ –Ted Neward

Organisiert und moderiert waren die Katas durch Neil Ford. Die Aufgabenstellungen stehen auch online auf seiner Webseite.

Insgesamt konnten 30 Personen in 6 Gruppen aktiv teilnehmen und hatten 45 Minuten Zeit, um die Aufgabe so gut wie möglich zu bearbeiten. Die übrigen Teilnehmer waren Beobachter (oder unterhielten sich abseits bei Bier und Häppchen ;-)).

 

Matthias war beim Design in einer Gruppe dabei, Marcus war einer der Beobachter. Wir haben das in der Form zum ersten Mal gemacht und möchten gerne einige der Erfahrungen und Erkenntnisse von den Architecture Katas teilen.

Matthias als Teilnehmer am Design:

• 5 Teilnehmer einer Architekturkonferenz haben mitunter sehr unterschiedliche Auffassungen davon, was Architektur ist und wie man zu einer Architektur kommt 😉
• Man muss eigentlich alles diskutieren: Anforderungen, Scope der Aufgabe, Reihenfolge des Vorgehens, inhaltliche Architekturentscheidungen, Notationen, was soll überhaupt abgeliefert werden?, wer macht was?, …
• Dadurch dass die Katas so kurz formuliert sind, bieten sie erheblichen Ausgestaltungsspielraum, den Informatiker / Architekten / Entwickler natürlich direkt erkennen und zu diskutieren wissen
• Deshalb sind 45 Minuten wirklich kurz, um etwas auf die Beine zu stellen
• Es hat nicht unbedingt der Recht, der am lautesten redet 😉
• Die Aufgabe per Mikrofon weiter zu präzisieren, während 100 Leute schon arbeiten und reden, funktioniert nicht
• Wenn man die Teilnehmer nach Ablauf der Zeit nicht zwingt, aufzuhören, dann machen sie noch 20 Minuten weiter während die ausgewählten Gruppen schon ihr Ergebnis präsentieren müssen
• Es macht einen riesigen Unterschied, wer die Architektur letztlich vorstellt und wie gut er sie erklärt (insbesondere den Kontext, die Überlegungen, Einordnungen, Erklärungen, die alle nicht aufgeschrieben wurden in der kurzen Zeit)
• 5 Leute sind für eine Gruppe zu viel, um gut voranzukommen. Eine Gruppengröße von 2-3 Leuten wäre besser geeignet

Marcus als Beobachter:

• Alle 6 Gruppen sind sehr unterschiedlich vorgegangen.
• Das fängt schon bei der Art und Weise an, wie sie Gruppen sich aufgeteilt haben. Allen 6 Gruppen stand ein großer Runder Konferenz-Dinner Tisch sowie 2 Flipcharts zur Verfügung. 2 Gruppen haben sich dazu entschieden, sich um die Flipcharts zu stellen (darunter auch die Gruppe von Matthias). Die anderen 4 Gruppen haben sich an die Konferenztische gesetzt.
• Aus meiner Beobachtersicht heraus kamen die zwei Gruppen, die stehen geblieben sind, schneller voran.
• Die Gruppen an den Flipchart haben auch mehr als ganze Gruppe diskutiert, wohingegen die Gruppen an den Tischen eher in Kleingruppen (2-3er) diskutiert haben.
• Alle Gruppen haben direkt mit fachlichen Diskussionen angefangen. Keine der Gruppen hat sich mit „organisatorischen“ Dingen (direkt am Anfang) beschäftigt (z.B.: Welche Sichten benötigen wir? Sollen wir uns für Teilaufgaben aufteilen? Wer stellt am Ende das Ergebnis vor?)
• Es ging wohl so richtig in allen Gruppen erst voran, als einer oder zwei Gruppenteilnehmer die Initiative übernommen haben.
• Eine Gruppe hat sich sogar trotz der geringen Zeit von 45 Minuten dafür entschieden, einige Dokumente digital zu erstellen und nicht nur am Flipchart.
• Die Repräsentation der Ergebnisse war auch völlig unterschiedlich. Dabei beziehe ich mich nicht nur darauf, was die Gruppen gezeigt haben, sondern auch wie sie es dargestellt haben.
• Man sollte sich gerade in solchen „künstlichen“ Situationen auch direkt damit beschäftigen, wie das Ergebnis am Ende repräsentiert wird.
• Auch die Wahl des Präsentators sollte gut ausgewählt werden, insbesondere, wenn es etwas zu gewinnen gibt.

Insgesamt waren die Architecture Katas eine sehr interessante Erfahrung. Wir können es Architekten und Entwicklungsteams nur empfehlen, solche Übungen auch zu machen. Dabei kann der Scope durchaus auch ausgeweitet werden, um auch das Zusammenspiel mit anderen Disziplinen wie Requirements Engineering oder User Experience Design zu üben. Der Vorbereitungs- und Zeitaufwand ist gering, dafür lernt man vieles und kommt zu zahlreichen Erkenntnissen über die Zusammenarbeit mit Kollegen.