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.
Zum Abschluss gab es als Übung und gemeinsames Event noch Architecture Katas, die wir am Ende des Artikels beschreiben.
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).
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:
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.
Nathaniel Schutta gab eine großartige Keynote zur Kommunikation von Softwarearchitekten: „Architect as storyteller”.
Zwei Aspekte hat er dabei insbesondere herausgearbeitet:
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.
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:
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:
Marcus als Beobachter:
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.
Am 10.10.2017 fand wieder der UX Day in Mannheim in der Alten Feuerwache statt. Ich bin ein großer Fan der Veranstaltung und wurde auch in diesem Jahr wieder nicht enttäuscht. Bei der Closing Keynote gab es sogar „Zugabe“-Rufe, was auf Konferenzen eher nicht der Fall ist. Auch in 2017 war ich wieder mit einem Vortrag vertreten. Worum es ging, erfahrt ihr hier und den Link zum Vortragsvideo findet ihr unten:
„Hast du mal ein Beispiel, damit ich es besser verstehen kann?“, „Wie muss ich mir das vorstellen, zeigst du das noch am Beispiel?“, „Das hast du aber sehr vereinfacht erklärt, hast Du noch ein realitätsnahes Beispiel?“ – Diese oder ähnliche Aussagen sind oft die ersten Reaktionen auf die Präsentation einer neuen Idee. Obwohl wir selbst den Präsentierenden oft als Erstes nach einem guten Beispiel fragen, vergessen wir bei unseren eigenen Präsentationen gerne, wie wichtig gute Beispiele sind, um andere von unseren neuen Ideen zu überzeugen. Der Vortrag zeigt, warum „Lorem Ipsum“, „Max Mustermann“, „Unternehmen 1“ und „Kundengruppe A“ nicht ausreichen, um andere für die Umsetzung eigener Ideen zu begeistern.
Oft sind es gute Beispiele, die über den Erfolg oder Misserfolg einer Idee entscheiden. Verwenden wir keine oder schlechte Beispiele, wenn wir unsere Ideen anderen erklären, so stoßen wir oft auf Missverständnis oder gar Unverständnis. Da wir uns selbst so lange mit der Idee beschäftigt haben, fällt uns das Fehlen von Beispielen oft gar nicht so leicht auf, da wir selbst kein Beispiel (mehr) benötigen. Wenn wir jedoch Pech haben, dann wird unsere Ideen direkt nach unserer Präsentation abgelehnt, ohne dass wir die Chance haben, die Idee noch einmal besser zu erklären. Wenn wir Glück haben, dann werden wir direkt nach einem guten Beispiel gefragt, um unsere Ideen zu illustrieren oder zu visualisieren. Dann müssen wir jedoch spontan reagieren und uns ein Beispiel ad hoc überlegen. Das funktioniert meistens nicht gut. Denn gute Beispiele für die Erklärung von neuen Ideen zu erstellen ist harte Arbeit. Es ist meist ein langwieriger Prozess, bei dem viel ausprobiert werden muss. Ein gutes Beispiel muss „groß genug“ sein, um realitätsnah zu sein und nicht direkt als „vereinfachter Spezialfall“ abgehandelt zu werden. Eine moderate Komplexität ist zudem wichtig, um ein oft gewünschtes „durchgängiges Beispiel“ zu erhalten, dass uns erlaubt, die Idee aus unterschiedlichen Blickwickeln zu zeigen und möglichst vielen Facetten zu beleuchten. Das Beispiel muss aber auch klein genug sein, dass wir nicht die ganze Vortragszeit benötigen, um das Beispiel zu erklären. Die Realitätsnähe zum tatsächlichen Anwendungsfalls ist immens wichtig. Warum „Max und Maria Mustermann“, „Lorem Ipsum“, „Unternehmen 1“ und „Kundengruppe A“ daher nur bedingt geeignet sind, um gute Beispiele zu erstellen und worauf wir noch achten müssen, um unsere Ideen zu beispielhaften Erfolg zu führen, wird im Vortrag aufgezeigt.
Auch in diesem Jahr gab es wieder sehr viele gute Vorträge. Insbesondere möchte ich euch die folgenden Vorträge ans Herz legen:
Wenn euch mein Vortrag gefallen (oder auch nicht) oder wenn ihr Anregungen und Fragen zum Thema habt, dann schreibt einfach einen Kommentar.
© 2023 mibinu
Theme von Anders Noren — Nach oben ↑
Neueste Kommentare