Kategorie: Konferenzbericht

Architekten als Geschichtenerzähler, Soziotechnologen, Dokumentierer und mehr (O’Reilly Architecture Conference London 2017)

4. November 2017 / Marcus & Matthias / Keine Kommentare

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.

Warum Beispiele so wichtig für den Erfolg sind (UX Day 2017)

4. November 2017 / Marcus Trapp / Keine Kommentare

Beispielhafter Erfolg & Beispiellose Niederlage – Warum gute Beispiele so wichtig für den Erfolg eigener Ideen sind habe ich in meinem Talk beim UX Day 2017 in Mannheim vorgestellt.

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:

Michael Lewrick zum Thema „Design Thinking für digitale Innovationen“. Der recht allgemeine Titel lässt es nicht vermuten, aber der Talk beschäftigt sich fast ausschließlich mit der Gestaltung von Software Ecosystems, eine Thema das Matthias und mir sehr am Herzen liegt.
Javier Bargas-Avila zum Thema „Me no speak English“. Wie wichtig und schwierig es ist ist, einen internationalen Webauftritt in jeder Sprache wirklich gut hin zu bekommen, zeigt der Javier Bargas-Avila von Google am Beispiel von Youtube.
Alper Çugun zum Thema „Conversational Interfaces“. Kann man eigentlich jede (non-business) Anwendung als Chat-Anwendung gestalten? Im Vortrag erfahrt ihre die Antwort.
Reinhard Karger zum Thema „KI ist das neue Bio!“. Wenn ein Vortrag „Zugabe“-Rufe bekommt, dann kann er nicht so schlecht sein.

Wenn euch mein Vortrag gefallen (oder auch nicht) oder wenn ihr Anregungen und Fragen zum Thema habt, dann schreibt einfach einen Kommentar.

Never Again Offline?!? Video von SATURN 2015

19. August 2015 / Matthias Naab / Keine Kommentare

Bei der SATURN 2015 hatte ich mit Ralf Carbon und Susanne Braun einen Vortrag zu: Never again offline?!? Experiences on the outstanding role of data in a large-scale mobile app ecosystem. Jetzt gibt es den Vortrag (und viele andere von der SATURN) als Video.

Links:

Time-to-Market und Architekturwissen (WICSA 2015)

24. Mai 2015 / Matthias Naab / Keine Kommentare

Die WICSA 2015 fand vom 04. bis 07. Mai zusammen mit der CompArch in Montreal statt.

Das gesamte Programm war sehr abwechslungsreich und beleuchtete viele Facetten rund um Softwarearchitektur. Das ausgerufene Konferenzthema war „Architecting in Context“, insgesamt gab es aber keine dominierenden thematischen Schwerpunkte. In meinem Bericht greife ich deshalb einfach Themen und Vorträge auf, die mich am meisten angesprochen haben.

Clemens Szyperski hielt am Auftakttag im Rahmen der WCOP eine Keynote „Maintaining composure: The long journey along the path of compositional software engineering”. Sein Hauptfokus waren kompositionale Aspekte in der Softwareentwicklung, von der Komposition von Funktionen über Komponenten bis hin zu Services. Eine interessante Beobachtung dabei ist, dass Komposition in der Softwareentwicklung immer nur ein Einbinden von ausgelagertem Code ist, wenn auch auf unterschiedlichen Größenordnungen. Das steht im Gegensatz zu Komposition z.B. im chemischen Bereich, wo tatsächlich andere Verbindungen entstehen können durch chemische Reaktionen. Das einzige Beispiel aus der Softwareentwicklung, das etwas anders ist, ist die Aspektorientierung. Die hat Clemens aber nochmal besonders im Hinblick auf Komposition hervorgehoben: Sie funktioniert zuverlässig eigentlich nur, wenn man nur einen Aspekt einwebt, und somit keine Interaktion zwischen Aspekten hat. Somit ist die Komponierbarkeit „etwas eingeschränkt“.

Clemens hatte noch einen weiteren sehr interessanten Aspekt in seiner Keynote: Er verglich das Architekturdesign mit „negativem Zeichnen“ („negative space drawing“). Dabei zeichnet man nicht das eigentliche Objekt, sondern alles außenrum, sodass das Objekt dadurch sichtbar wird. Negatives Zeichnen bewirkt im Gehirn andere Denkprozesse und arbeitet das zu zeichnende Objekt anders heraus. Bezogen auf Softwarearchitektur stellte Clemens heraus, wie ein Softwarearchitekt nicht die konkrete Lösung vorgibt, sondern eher Pfeiler einschlägt, indem er vorgibt, wie gewisse Aspekte auf keinen Fall umzusetzen sind. Ganz im Sinne einer Keynote führte dies zu sehr angeregten Diskussionen, die auch noch am Nachmittag in einer Working Session fortgesetzt wurden. Wir kamen zu dem Schluss, dass der veränderte Blickwinkel auf die Erzeugung von Architekturentscheidungen durchaus nützlich sein kann, dass aber umgekehrt auch viele Fragen offen bleiben, wie z.B. die nach der geeigneten Dokumentation von so getroffenen Architekturentscheidungen. Wie bei so vielen Analogien zu Softwarearchitektur hatten wir am Schluss den Eindruck, dass sie in einigen Bereichen sehr nützlich sein kann, aber doch auch viele Limitierungen hat.

Len Bass hielt eine Keynote “Design for Deployment”. Das dahinterstehende Ziel ist eine schnelle Time-to-Market für neue Features und damit verbunden die Fähigkeit zu schnellen Releases. Len schloss damit an die Themen „DevOps und Microservices“ der SATURN an. Er arbeitete heraus, dass für eine hohe Releasehäufigkeit die Abstimmung zwischen Teams reduziert werden muss. Dazu arbeiten Teams eigenverantwortlich an einem klar definierten Systemteil (Microservice) und interagieren mit den Systemteilen der anderen Teams über klar definierte Schnittstellen. Das stellt eine sehr konsequente Umsetzung von Conway’s Law dar. Über einen hohen Automatisierungsgrad im Test und die integrierte Verantwortung für Entwicklung und Betrieb (DevOps) kann dann die hohe Releasehäufigkeit erreicht werden. Len stellte weitere Implikationen für die Architektur heraus, z.B. Aspekte wie Zustandslosigkeit von Services, um sie möglichst gut skalieren zu können. Ein zentrales Thema in der Keynote war auch das Upgrade von Services auf neuere Versionen und was das im Zusammenspiel mit anderen Services und für die Realisierung von neuen Features bedeutet. Len stellte dafür Strategien vor und erläuterte die Rolle von Feature Toggles, mit denen ein Feature global oder selektiv freigeschaltet werden kann, wenn das Deployment abgeschlossen ist. Auch die Nutzung von Feature Toggles für sogenannte Canary Tests (bei denen neue Features mit einer ausgewählten Submenge der Gesamtnutzer vorsichtig getestet werden) arbeitete Len heraus. Len hielt wie immer einen Vortrag von hoher praktischer Relevanz, in dem er sowohl die dahinterliegende Motivation als auch die Architekturkonzepte und konkrete Umsetzungstechnologien klar herausarbeitete.

Jan Bosch hielt eine mitreißende Keynote „From Opinions to Facts: Building Products Customers Actually Use”. Wer Jan schon einmal auf der Bühne erlebt hat weiß, dass seine Vorträge extrem unterhaltsam und mit sehr vielen konkreten Beispielen illustriert sind. Seine Kernaussagen waren

„Kunden wissen nicht, was sie wollen. Deshalb ist es nötig, schnell Experimente machen zu können.“ Dazu zitierte er natürlich Henry Ford: „If I had asked people what they wanted, they would have said faster horses.”
„Eine schnelle Time-to-Market ist absolut essentiell und ein entscheidender Wettbewerbsvorteil, und unabdingbar für schnelle Experimente.“

Jan illustrierte sowohl den Wert von schneller Time-to-Market als auch methodische und architekturelle Aspekte, um sie zu erreichen. Architekturell schließt sich das an die Keynote von Len Bass an und greift DevOps und Microservices Ideen auf. Er sieht Architekten als Coaches direkt in den Entwicklungsteams, die meist auch noch direkt mitentwickeln. Jan betonte, dass wirtschaftlich eine schnelle Time-to-Market auf jeden Fall einen höheren Wert hat als Geld einzusparen durch eine höhere Produktivität. Er beschreibt eine 5-stufige „stairway to heaven“:

Traditionelle Entwicklung
Agile Entwicklung
Continuous Integration
Continuous Delivery
R&D als ein Innovationssystem mit schnellen Experimenten

Um Kunden genau die Produkte und Features liefern zu können, die sie brauchen und nutzen, läuft es auf das schnelle Experimentieren heraus: der Produktanbieter beobachtet die Nutzer bei der Produktnutzung und fährt auch direkte Vergleiche von Systemvariationen (A/B-Tests). Dies ist nur möglich, wenn der Produktanbieter neue Features und Variationen sehr schnell releasen kann. Um dies zu erreichen müssen strategische, methodische, organisatorische, und architekturelle Aspekte der Entwicklung und des Betriebs optimal aufeinander abgestimmt werden. Jan überraschte in seiner Keynote damit, dass er mit seiner Gruppe aktuell daran arbeitet, diese Art des schnellen Experimentierens nicht nur für Internetfirmen nutzbar zu machen sondern auch für eingebettete Systeme wie Autos, wo er mit Volvo kollaboriert.

Ian Gorton stellte eine sehr interessante Arbeit zum Thema Architekturwissen und Wissensmanagement vor: Während Technologien häufig sehr ausführlich in Bezug auf ihre Benutzung beschrieben werden, findet man fast nie eine gute Beschreibung der architekturellen Implikationen. Ian stellte dazu am Beispiel von aktuellen Big Data Technologien vor, wie solches Wissen aufbereitet und bereitgestellt werden kann. Dazu wurde am SEI eine Erweiterung zu MediaWiki erstellt, was Konzepte wie Architekturtreiber und Architekturentscheidungen aufgreift und im Sinne strukturierter Daten erfassbar macht. Das Wiki führt durch die Erfassung und Dokumentation architekturrelevanter Aspekte und macht das Auffinden leicht. Initial gefüllt ist das Wiki mit dem Namen QuABaseBD mit Architekturwissen zu Big Data Technologien. Nach wie vor ist das Erstellen solchen Wissens mit sehr viel Aufwand verbunden und es ist schwierig, die richtige Abstraktionsebene zu finden, um im konkreten Nutzungsfall dem Architekten die richtigen Antworten zu liefern. Es ist definitiv noch einiges an Forschung nötig, um die richtige Art der Informationserfassung, -aufbereitung, -suche und –verwendung von Architekturwissen zu bestimmen.

Eltjo Poort hat untersucht, inwiefern sich die Einbeziehung von Architekten in der Projektanbahnungsphase auswirken kann. Er arbeitet für die niederländische Firma CGI, die viele Softwareprojekte mit Festpreisangeboten anbietet und deshalb auf eine präzise Kostenschätzung angewiesen ist. Eltjo stellte eine Methode vor, in der Projektmanager, Kostenschätzungsexperten und Architekten zusammenarbeiten, um zu einer Kostenschätzung zu kommen, die möglichst präzise ist. Dazu wird eine erste grobe architekturelle Zerlegung des Systems vorgenommen, um mit diesem Wissen bessere Schätzungen machen zu können. Dazu konnte er auch aus einer wissenschaftlichen Untersuchung Zahlen präsentieren: In untersuchten Projekten kam es zu deutlich weniger Budgetüberziehungen (3% statt 22%) und weniger Zeitüberziehungen (8% statt 48%) wenn entsprechende Architekturarbeiten in der Kostenschätzung durchgeführt wurden.

Ich hielt meinen Vortrag als Plädoyer dafür, Daten mehr Aufmerksamkeit beim Architekturdesign zu widmen. Das mag in Zeiten von Big Data erst mal grotesk erscheinen. Betrachtet man aber Daten in einer Architekturbeschreibung, so beschränkt sich das meist auf einen Datenmanagement-Layer mit Datenbanken und ein Datenmodell. Das wird dem Einfluss von Daten auf das Architekturdesign und die Erreichung von Qualitätseigenschaften nicht annähernd gerecht. Insbesondere der Einfluss auf User Experience und Performance und natürlich auf Security ist enorm. Um die richtigen Daten zum richtigen Zeitpunkt am richtigen Ort zu haben, müssen Architekten sich bedeutend mehr Gedanken machen als eine Datenbank auszuwählen und ein Datenmodell zu designen. Am Beispiel eines Projekts von John Deere und Fraunhofer IESE haben wir gezeigt, wie vielfältig die Anforderungen und geforderten Qualitätseigenschaften sich um Daten drehen, und welche Architekturentscheidungen dafür getroffen wurden. Dabei ging es um Themen wie Inter-App-Kommunikation, Offline-Fähigkeit, Mandantenfähigkeit, Mehrsprachigkeit uvm. Im Anschluss gab es in der Working Session eine angeregte Diskussion zum Thema, die eine breite Mehrheit dafür fand, dass Daten wirklich mehr Aufmerksamkeit brauchen (und wir reden hier nicht davon, dass man den derzeit allgegenwärtigen Einsatz von Big Data Technologien fordert: dann wird nämlich oft genau der gleiche Fehler gemacht ;-).

Ian Gorton, Jean-Guy Schneider, Len Bass, Patricia Lago und Ralf Reussner diskutierten in einem teils humoristisch und teils ernst geführten Panel „Future Directions for Software Architecture Research”. Aus dieser Diskussion gebe ich hier nur einige Ausschnitte wieder.

Die Forschung zu Softwarearchitektur soll …

… endlich die großen Probleme angehen und nicht nur die „low-hanging fruits“ ernten (Ian Gorton)
… sich mehr um aktuelle innovative Themen kümmern, wie z.B. die „16 Dinge“ von Andreessen Horowitz (von Len Bass ins Spiel gebracht mit einer Vorauswahl)
„16 Dinge“ von Andreessen und Horowitz (http://a16z.com/2015/01/22/16-things/)
… sich noch mehr um verschiedene Sichten auf Softwaresysteme kümmern und wie diese konsistent gehalten werden können (Ralf Reussner)
… sich mehr damit auseinandersetzen, was die kognitiven Limitierungen von Menschen im Engineering sind und wie Methoden und Tools deshalb gestaltet werden müssen (Ralf Reussner)
… sich mehr um das Thema Skalierbarkeit kümmern, insbesondere vor dem Hintergrund wie große skalierbare Systeme getestet werden können (Jean-Guy Schneider)
… sich mehr um die Integration in den gesamten Entwicklungsprozess und den Lebenszyklus von Systemen kümmern
… mehr zusammenarbeiten und auch fokussieren, um von zu vielen isolierten Forschungsinseln wegzukommen
… durch Benchmarks und Vergleichbarkeit von Methoden sich gegenseitig zu neuen Ideen anstacheln
… gemeinsam Architekturwissen sammeln, aufbereiten und der Praxis zugänglich machen, um mehr Einfluss zu gewinnen

Die WICSA 2015 war eine sehr kurzweilige Veranstaltung mit vielen interessanten Denkanstößen und Erkenntnissen. Der Modus einer „Working Conference“, das heißt mit Impulsvorträgen und dann längerer Diskussion, führte zu sehr angeregten und tiefen Diskussionen, manchmal sogar zu Grundsatzdiskussionen des Software Engineering. Umso wichtiger ist aber auch die aktive Teilnahme des Publikums, das sich heute manchmal eher hinter dem Laptop versteckt als aufmerksam zuzuhören. Einer der Session Chairs hat vorgemacht, wie das umgangen werden kann: Er hat alle Zuhörer nach vorne geholt und Laptops für unerwünscht erklärt – und damit die diskussionsreichste Session der Konferenz ermöglicht.

2016 wird die WICSA wieder zusammen mit der CompArch stattfinden, dann in Venedig. Ich freue mich schon drauf!

Betroffenheit und Business Artists (BITKOM UUX)

8. Mai 2015 / Marcus Trapp / Keine Kommentare

Ich komme gerade vom BITKOM UUX Fachgruppentreffen in Berlin und warte am Flughafen Tegel auf meinen Rückflug. Die Teilnahme hat sich voll und ganz gelohnt. Zum angekündigten Streitgespräch kam es jedoch nicht. Im Großen und Ganzen waren sich die Teilnehmer einig, obwohl sehr viel und auch sehr emotional diskutiert wurde. Deutlich mehr als bei ähnlichen Veranstaltungen, vor allem sobald das Thema Scrum oder Design Thinking angesprochen wurde.

Es wurden zwar unterschiedlichste Themen rund um das Thema Usability und User Experience diskutiert, in jedem Vortrag oder der zugehörigen Diskussion wurde jedoch auf die eine oder andere Art über die Evaluation von Usability und UX gesprochen: Wann sollte man mit welcher Methode und wie oft evaluieren? Ulf Schubert (DATEV) hat hierzu etwas Interessantes erzählt. Bei der DATEV muss das gesamte Entwicklungsteam während einer Usability Evaluation anwesend sein. Es sind somit nicht nur die Qualitätssicherungs- und Usability Experten anwesend, sondern alle an der Entwicklung beteiligten Personen. Das Team kann die Testnutzer durch eine Scheibe im Usability Labor beobachten. So bekommt jeder im Team direkt mit, sobald ein Testnutzer ein Problem mit der Benutzung hat. Kommt ein Testnutzer in größere Schwierigkeiten bei der Benutzung, so löst das beim anwesenden Projektteam Betroffenheit aus. Genau das ist das Ziel von Ulf Schubert: „Im Projektteam soll Betroffenheit hervorgerufen werden.“ Ich habe auch schon die Erfahrung gemacht, dass man deutlich besseres Verständnis im Projektteam erreicht, wenn man Videos von Problemen während der Nutzung von Testnutzern zeigt und nicht nur die Anzahl von Problemen in einer Tabelle listet. Zwar hört sich „18 von 20 Nutzern haben das Produkt nicht auf die intendierte Art und Weise gestartet“ auch nicht gerade gut an, zeigt man aber einen Video-Zusammenschnitt dieser 18 (oder 20) Starts, so stellt sich Betroffenheit und anschließend Verständnis im Projektteam viel schneller und eindringlicher ein. Nach Aussage von Ulf Schubert, funktioniert es aber noch besser, wenn das Projektteam live beim Test mit anwesend ist. Das Projektteam hat auch immer Whiteboards zur Verfügung, um direkt Verbesserungsvorschläge zu diskutieren. Natürlich nur untereinander und nicht mit den Testnutzern. Weitere Tipps von Ulf Schubert gibt es in seinem User Experience Blog. Er hat auch zwei Beträge zum Fachgruppentreffen verfasst (Vormittag, Nachmittag).

Eine weitere Interessante Frage, die diskutiert wurde ist: Wer führt zukünftig eigentlich UX Tests durch? Momentan liegt diese Kompetenz hautsächlich bei Beratungshäusern und Usability/UX Agenturen. Derzeit bauen aber immer mehr Design Agenturen diese Kompetenz auf und bieten auch UX Tests an. Hinzu kommt, dass immer mehr Unternehmen eigene UX Test-Kompetenz aufbauen, um die Evaluation selbst durchführen zu können. Immer öfter werden UX Test sogar im unternehmenseigenen UX Labor durchgeführt. Wohin sich das entwickelt, werden wir in den nächsten Jahren feststellen. Es bleibt also spannend.

Mit seinem Vortrag „Do you understand me? Supernatural and innovative interactions“ eröffnete Sascha Wolter (Deutsche Telekom) das Fachgruppentreffen fulminant. Wer die Gelegenheit hat, sollte sich unbedingt einmal eine Präsentation von Sascha Wolter ansehen (hier stehen seine Vortragstermine). Voller Energie und Enthusiasmus berichtete er vom Internet of Things (IoT). Interessant fand ich seine Aussage „Die Erotik-Branche schiebt neue Technologien an.“ Das galt für die das Internet, die DVD, HD-Video, usw. „Als nächstes ist wohl das IoT dran. Es ist unglaublich, was es da schon alles gibt.“

Wenn es um neue Interaktionsmöglichkeiten geht, es ist es wichtig, dass man nicht nur darüber redet, sondern diese unbedingt persönlich ausprobiert. Nur dann kann man wirklich auch wirklich darüber reden. Entwickelt man selbst gerade eine neue Interaktionsform, dann sollte man diese unbedingt prototypisch umsetzen und ausprobieren. Das gilt nicht nur für die Software, sondern auch für die zugehörige Hardware. Es muss ja nicht immer gleich perfekt sein. 3D Drucker, Bausätze und ähnliche Hilfsmittel unterstützen uns heute immer mehr dabei. Sascha Wolter ist ein großer Fan vom Ausprobieren und hat z.B. auch das Autofahren mit einer Blackbox seiner Versicherung getestet, die guten Autofahrern bessere Tarife verspricht: „Ich probiere das alles mal aus und sehe mir an, wozu das führt und erziehe meine Kinder zu einem bewussten Umgang mit Daten.“

Besonders wenn es um das IoT geht bedauert Sascha Wolter, dass die Systeme immer noch zu wenig Empathie besitzen. Wir können heute jede Lampe in jedem Raum unserer Wohnung oder unseres Hauses dazu bringen, genau das richtige Farbschema zu erzeugen, das am besten zu unserer momentanen Gemütslage passt. Allerdings müssen wir dieses Farbschema noch selbst auswählen. Die Systeme können unsere Gemütslage momentan noch nicht ausreichend gut erkennen. Die notwendige Technologie ist hierzu wahrscheinlich sogar schon vorhanden. So gibt es beispielsweise in Japan Getränkeautomaten, die mit einfachen Sensoren die Gemütslage den Käufers (vorgeben zu) erkennen und ein passendes Getränk auswählen.

Am Nachmittag hat Dirk Dobiéy (SAP) mit „Learning from creative disciplines for better outcomes in business and society“ eine weitere beeindruckende Präsentation gehalten. „Es wird immer mehr automatisiert, nicht nur der Börsenhandel, sondern sogar die Berichte über den Börsenhandel. Immer mehr Wissensarbeiter werden automatisiert. Welche Eigenschaften müssen wir denn überhaupt zukünftig haben?“ Dirk Dobiéy und seine Kollegen von Age of Artist glauben, dass solche Eigenschaften in künstlerischen Bereichen gefunden werden können und haben mit Künstlern aus unterschiedlichsten Bereichen gesprochen. Dabei haben sie versucht herauszufinden, was Künstler ausmacht, was sie antreibt und ob es gemeinsame Eigenschaften gibt. Diese Eigenschaften werden dann immer in Bezug oder besser in Kontrast zum momentanen Business-Alltag gesetzt. Um wieder das Beispiel der Evaluation aufzugreifen, ist ihnen beispielsweise aufgefallen, dass in der Geschäftswelt leider immer noch oft gesagt wird „Das gefällt mir nicht!“ oder „Ich würde das nicht so machen!“. Künstler sprechen in einer Evaluation subjektiver und emotionaler „Ich sehe hier…“ oder „Ich fühle dabei…“. Dirk Dobiéy gibt folgende Eigenschaften von Künstlern an, die sie von Geschäftsleuten unterscheiden:

Planning by Doing. Making to Learn.
Exploration without Intention.
Substantial Amounts of Search and Reflection.
Accepting Ambiguity and Crisis.
Appreciating Feeling and Emotions.
Everything is a Derivative: Finding again the New.
Non-Linear.

Zudem gibt Dirk Dobiéy folgende Eigenschaften an, die wir entwickeln müssen, um „Business Artists“ zu sein:

Observation & Listening
Dialogue & Conversation
Exploring & Deconstructing
Abstracting & Simplification
Generating Ideas & Experimenting
Problem Solving
Collaboration & Cooperating
Giving Feedback & Dealing with Critique
Reframing & Improvising
Designing & Performing

Knowledge-Worker benötigen schon heute aber vor allem in der Zukunft andere Fähigkeiten, vor allem Soft Skills. Es reicht zudem nicht aus, nur einen gut ausgeprägten Soft Skill zu haben, sondern wir werden immer mehr beherrschen müssen. Ob es genau diese Skills sind, die im Vortrag angesprochen wurden ist dabei gar nicht so wichtig. Der vorgestellte Ansatz, bei Künstlern nach solche Eigenschaften zu suchen, ist jedoch sehr spannend.

Ich freue mich schon auf das nächste UUX Fachgruppentreffen, das wohl noch dieses Jahr stattfinden wird.

Architekten im Aufzug (SATURN 2015)

7. Mai 2015 / Matthias Naab / Keine Kommentare

Die SATURN 2015 des Software Engineering Institute (SEI) fand vom 27. bis 30. April in Baltimore statt. Die Konferenz war mit mehr als 200 Teilnehmern die bestbesuchte SATURN bisher und wurde ihrem Anspruch, eine Community für Praktiker zu sein, vollends gerecht. Eine gelungene Mischung aus Tutorials, eingeladenen Vorträgen, Keynotes und lustigen Events machte die Entscheidung schwierig, welche Session man am besten besuchen sollte.

Inhaltliche Schwerpunkte waren diese Themen:

DevOps und Microservices
Architektur im Spannungsfeld zwischen Business und Entwicklern
Technical Debt und Modernisierung
Agilität und Architektur

Netflix ist derzeit das meistzitierte Beispiel für den erfolgreichen Einsatz von Microservices. Getrieben durch Anforderungen wie niedrige Time-to-Market, schnelle Releasefähigkeit (Continuous Delivery) und hoher Parallelisierung der Entwicklung haben sich Microservices entwickelt und sind weiter auf dem Vormarsch.

Dabei sind Microservices weit mehr als ein weiterentwickelter Architekturstil (basierend auf Service-Orientierung), zumindest dann, wenn die genannten Anforderungen wirklich erreicht werden sollen. Microservices machen sehr stark deutlich, wie sehr es auf das Zusammenspiel von Systemarchitektur, Organisationsstruktur und Prozessen ankommt. Gemäß Conway’s Law gibt es eine Abstimmung zwischen Systemstruktur und Organisationsstruktur, nämlich die Zuordnung von Verantwortlichkeiten für Microservices auf Teams. Darüber hinaus ist dann ein Team nicht nur für die Entwicklung, sondern auch den Betrieb des Services zuständig, was dann unter dem Begriff DevOps bekannt ist. Dadurch dass mittlerweile die komplette Betriebsinfrastruktur als Cloud-Service bezogen werden kann, können sich die Entwicklungsteams somit rein auf den Applikationsbetrieb fokussieren.

Len Bass zeigte auf, was architekturell beachtet werden muss, um Microservices und DevOps umzusetzen, z.B. das Deployment von Microservices, die Abbildung auf Teamstrukturen oder der Umgang mit Upgrades,. Sam Newman (ThoughtWorks) stellte Prinzipien vor, die bei der Umsetzung von Microservices helfen, z.B. Modellierung nach Business Domains, Kultur für Automatisierung, Dezentralisierung, unabhängiges Deployment, Fehlerisolation und hohe Beobachtbarkeit.

Ein weiterer eng mit Microservices und DevOps verbundener Trend ist der Einsatz von Containern, in denen Ausführungsumgebung und Applikation gepackaged sind und dann einfach nur komplett auf Hardware deployed werden können (z.B. mit Docker). Dieser Trend setzt auf dem schon länger anhaltenden Trend zur Virtualisierung auf. Ein Vortrag von Google gab Einblicke in die Praktiken bei Google, wie dort die Verwaltung von Hardware und Infrastruktur durchgeführt wird. Große Teams sind nur für die Entwicklung Bereitstellung der Google-eigenen Infrastruktur zuständig, mit Hilfe derer dann riesige Mengen von Maschinen automatisch mit der richtigen Software versorgt werden können. Dazu kommen dann ganze „Produktionslinien“ zum Einsatz, um die entsprechend konfigurierten Container zu erzeugen („Image Bakery“). Unter dem Stichwort „Immutable Infrastructure“ versteht Google, dass solche Container nie wieder verändert, sondern immer wieder neu erzeugt werden.

Anhand der Beispiele Netflix, Google, etc. wird klar, dass sich insbesondere sehr große Firmen aus dem Internetbusiness derzeit leisten können, so massiv in die umgebende Infrastruktur und die Prozesse zu investieren, um Qualitätsattribute wie Time-To-Market zu erreichen. Trotzdem wird durch die immer besseren Cloudangebote auch ermöglicht, dass auch kleinere Firmen davon profitieren können.

Die Diskussion um Microservices war so stark präsent auf der SATURN, dass sie sich teilweise zum Running Gag entwickelte. Simon Brown (selbständiger Berater) hat das Thema in seinem Vortrag auch aufgegriffen und folgendermaßen diskutiert: „Wie möchten Firmen, die derzeit noch nicht einmal ihr System richtig strukturiert bekommen, das komplexe Geflecht aus Services, Prozessen und Organisationsstruktur meistern?“. Microservices kann man nicht als Technologie kaufen und man kann sie nicht von heute auf morgen einführen: Eine Organisation muss eine entsprechende Reife in der Architektur, in der Entwicklungsorganisation und in den Prozessen aufbauen und aufeinander abstimmen.

Gregor Hohpe (Allianz) charakterisierte in seiner Keynote einen Architekten unter anderem dadurch, dass er im Aufzug zwischen verschiedenen Ebenen eines Unternehmens unterwegs ist, die im Extremfall vom Vorstand bis zum einzelnen Entwickler reichen. Dabei ist es Aufgabe des Architekten, sich an die Bedürfnisse der jeweiligen Stakeholder anzupassen und mit Ihnen in Ihrer Sprache zu kommunizieren.

Jochem Schulenklopper (inspearit) stieg dazu provokant ein: „Why they just don’t get it: Communicating Architecture to Business Stakeholders“. Genauso provokant ging es weiter: Weil die Architekten es ihnen nicht richtig erklären können. Er berichtete von Architekten, die sich einfach nicht auf die Sprache von Nicht-Informatikern einlassen wollen und keine Empathie für ihr Zielpublikum haben. Er zeigte Vorschläge von Darstellungsformen, die sich an der Sprache von Managern orientieren. Insbesondere hielt er ein Plädoyer dafür, dass Kommunikation eine so essentielle Aufgabe von Architekten ist, dass man den Aufwand nicht scheuen darf, für einzelne Zielgruppen und Vorträge individuell angepasste Darstellungen zu erarbeiten. Wiederverwendung von Diagrammen aus dem Modellierungstool ist hingegen oft nicht die richtige Wahl.

Eltjo Poort (CGI) arbeitete auch die Beziehung von Architekten zum Management heraus. In seinem Vortrag legte er insbesondere Wert auf die Kommunikation von Wert und Risiken, die sich aus Architekturentscheidungen ergeben und für Managemententscheidungen besonders relevant sind.

Simon Brown betonte in seinem Vortrag „Software Architecture as Code“ besonders die Beziehung zwischen Architektur und Entwicklern und stellte die Entwickler als die wichtigste Zielgruppe von Architektur heraus, weil sie die geplante Architektur ja umsetzen müssen. Er bemängelte, dass sehr häufig in der Praxis Architekturdiagramme erzeugt werden, die sehr schwer bis gar nicht auf den Code abzubilden sind, z.B. weil sie nur Laufzeitstrukturen zeigen, aber keine Sicht auf die Implementierung. Mit seinen 4Cs (Context, Container, Component, Class) stellte Simon seinen Ansatz vor, um die Lücke zwischen Architektur und Code überwindbar zu halten. Dabei stellte er die Wichtigkeit von Architecture-Evident Coding Styles heraus, die es zum expliziten Ziel haben, eine erkennbare Abbildung der Architektur im Code zu erzeugen. Simons Ansatz erfordert in der Praxis allerdings auch eine Ergänzung um Laufzeitaspekte, Datenaspekte, etc., die nicht Bestandteil des Vortrags waren.

In der Praxis sind technische Schulden nicht zu vermeiden: Es geht nur um die Frage, wie eine Firma damit umgeht. Ipek Ozkaya (SEI) und Robert Nord (SEI) hielten dazu ein Tutorial, in dem sie das strategische Management von technischen Schulden beleuchteten.

Technische Schulden können vielerlei Ausprägung haben, z.B. schlechte Codequalität oder auch mangelnde Dokumentation. Die schlimmsten Auswirkungen (weil am schwierigsten und aufwendigsten zu beheben) haben aber Defizite in der Architektur.

Häufig sind technische Schulden das Ergebnis davon, dass schnelle Auslieferung Vorrang hatte vor langfristiger Qualität. Wenn dieser Kompromiss gemacht wird, dann sollte er zumindest bewusst gemacht werden. An dieser Stelle kommt Architekten eine wichtige Rolle zu: Sie müssen sich häufig dafür einsetzen, dass nicht zu viele technische Schulden gemacht werden und regelmäßig aufgeräumt wird („Schulden zurückzahlen“). Insbesondere agile Entwicklungsorganisationen legen häufig zu viel Wert auf schnelle Featureproduktion, mit dem Ergebnis dass die Architektur vernachlässigt wird.

Ipek und Robert zeigten im Tutorial Ansätze zur Messung von technischen Schulden und zum aktiven strategischen Management. Dabei kommen bewährte Ansätze aus dem Bereich Softwaremetriken und Architekturbewertung zum Einsatz. Wie immer ist der schwierigste Teil dabei die geeignete Interpretation der Ergebnisse und die Ableitung von Maßnahmen.

Agile Softwareentwicklung hat ihren Weg in sehr viele Entwicklungsorganisationen gefunden. Dass das Anwenden von Methoden wie SCRUM oder Kanban dabei nur die halbe Miete ist, hat sich mittlerweile herumgesprochen. Wie man agile Entwicklung aber um sinnvolle Engineering-Praktiken ergänzt ist weniger offensichtlich. Etliche Sessions haben sich auf dieses Thema fokussiert und Anregungen gegeben.

Eltjo Poort hat in „Agilizing the Architecture Department“ Anregungen gegeben, wie Architekten ihre Arbeit selbst mehr nach agilen Prinzipien gestalten können und wie sie ihre Architekturarbeit in den SCRUM-Prozess einbetten können.

Joseph Yoder (The Refactory) hat in Rückblick auf sein berühmtes Paper „Big Ball of Mud“ agile Prinzipien Revue passieren lassen und aufgezeigt, wie Entwickler mit viel Verantwortungsgefühl zu einer hohen Qualität beitragen können.

Mary Shaw (Carnegie Mellon University) gab eine Keynote „Progress Toward an Engineering Discipline of Software”. Darin verglich sie Software Engineering als Disziplin mit anderen Engineering-Disziplinen wie dem Bauingenieurswesen. Sie skizzierte die Historie der Gebäudearchitektur über mehrere Jahrtausende und analysierte ihre Entwicklung von Handwerk über die Kommerzialisierung bis hin zum heutigen Engineering auf Grundlage vielfältiger wissenschaftlicher Erkenntnisse.

„Es ist kein Engineering, wenn man sich einfach nur so arg anstrengt wie man kann!“ brachte Mary Shaw den Zustand vieler Software Engineering Projekte auf den Punkt. In ihrem Vergleich kam sie zum Schluss, dass die Zielsetzungen von sonstigem Engineering und Software Engineering nahezu Deckungsgleich sind. Woran es beim Software Engineering noch fehlt sind die fundierten Grundlagen zur Unterstützung von Entscheidungen, mit deren Hilfe reproduzierbare Ergebnisse geliefert werden können.

Gregor Hohpe gab eine Keynote „It’s good to be architect”. Darin verglich er einen Softwarearchitekten mit mehreren anderen Rollen: Master Planner (macht im Voraus einen guten Plan), Gärtner (greift lenkend ein und weiß, dass er nicht alles kontrollieren kann), Tour Guide (erklärt anderen die großen Zusammenhänge und manches Detail). Außerdem skizzierte er den „Architektenaufzug“, mit dem er die Fähigkeit eines Architekten beschrieb, sich auf unterschiedlichsten Abstraktionsebenen mit unterschiedlichsten Stakeholdern geeignet zu unterhalten.

Eine weitere Analogie war der Architekt als Barkeeper, der gerne mixt. Damit spielte Gregor auf die Rolle des Architekten an, in einem sich rasch wandelnden Feld aus Business und Technologie Gelegenheiten zu erkennen und Business und Technologie so zu „mixen“, dass neue Geschäftsmöglichkeiten entstehen.

Zusammen mit Ralf Carbon (John Deere) habe ich einen Vortrag gehalten, in dem wir unsere Erfahrungen zur Wichtigkeiten von Daten beim Design von mobilen Ökosystemen vorgestellt haben. Am Beispiel eines Projekts von John Deere und Fraunhofer IESE haben wir gezeigt, wie vielfältig die Anforderungen und geforderten Qualitätseigenschaften sich um Daten drehen, und welche Architekturentscheidungen dafür getroffen wurden. Der Vortrag zeigte auf, dass Daten beim Architekturdesign zu häufig vernachlässigt werden und erläutert Lessons Learned, die Praktikern helfen können, Daten geeignet zu berücksichtigen.

In einem Battledeck konnten 6 Sprecher einen Vortrag von 6 Minuten halten. Dazu hatten sie 10 Folien, die aber jemand anderes vorbereitet hatte und die sie im Moment des Vortrags zum ersten Mal gesehen haben.

Sam Newman und Simon Brown lieferten sich einen sehr provokanten Schlagabtausch zum Thema pro und contra von Microservices. Dabei ließen sie keine Gelegenheit aus, ihre Position ins Extreme zu ziehen und dem Gegner damit eine Steilvorlage zu liefern.

Len Bass berichtete von den Anfängen seines Berufslebens in den 60ern und war dabei wie immer extrem unterhaltsam und lustig.