Workshops

Software Architecture Summit 2016
Das große Trainingsevent für Softwarearchitektur
26. - 28. September 2016, Hotel Titanic Chaussee Berlin

Workshops Details

Day 1
26 Sep 2016
Day 2
27 Sep 2016
Day 3
28 Sep 2016

Fortgeschrittene REST-Architektur

REST als der Architekturstil des Webs ist mittlerweile keine Neuigkeit mehr, sondern in den meisten Fällen die bevorzugte Alternative für die Umsetzung von Web Services. Die Diskussion darüber hat sich mittlerweile von Einsteigerthemen und Rechtfertigungen weg und zu fortgeschrittenen Fragestellungen hin entwickelt. In diesem Workshop diskutieren Holger Kraus und Silvia Schreier mit den Teilnehmern fortgeschrittene Aspekte jenseits der Grundlagen. Zu den Themen gehören Versionierung, Dokumentation, Hypermedia, die Entwicklung von Clients, Teststrategien und vieles mehr. Dabei werden sowohl theoretische Architekturaspekte wie auch praktische Werkzeuge behandelt. Die Teilnehmer bekommen die Gelegenheit, alle Fragen zu stellen, zu denen sie noch nie befriedigende Antworten bekommen haben.
Holger Kraus
Silvia Schreier

The Core of Domain-driven Design

Bei Softwareentwicklungsprojekten kommt oft nicht das heraus, was sich der Fachanwender vorgestellt hat. Die Kommunikationsprobleme zwischen Fachleuten und Entwicklern werden erst beim Einsatz des Softwaresystems und damit viel zu spät sichtbar. Wie wäre es, wenn Fachseite und Entwickler miteinander in derselben Sprache sprechen und dadurch frühzeitig merken würden, ob sie sich verstehen? Hier setzt Domain-driven Design (DDD) an: Fachexperten und Techniker entwickeln ganz bewusst eine gemeinsame Fachsprache, die die Basis für die domänengetriebene Architektur bildet. Aber nicht nur die Fachanwender und die Entwickler missverstehen sich, sondern auch die Entwickler untereinander haben verschiedene Vorstellungen von der Architektur des zukünftigen Systems. Um auch an dieser Stelle hohe Qualität zu gewährleisten, bietet DDD vordefinierte Muster, wie Entity, Value Object, Service etc. an. Diese DDD-Muster vereinfachen die Kommunikation im Entwicklungsteam und führen zu einer einheitlichen Architektur. Dr. Carola Lilienthal zeigt Ihnen in diesem Workshop, wie eine Fachsprache entwickelt und die DDD-Muster eingesetzt werden, um eine an der Fachdomäne orientierte Anwendung zu entwerfen. Gemeinsam üben wir an einer Beispielanwendung die einzelnen Schritte hin zu einer anwendungsorientierten und qualitativ hochwertigen Architektur. Sie werden erleben, wie einfach ein Entwurf sein kann, wenn man sich auf die Fachdomäne und die architektonischen Leitplanken von DDD einlässt!
Carola Lilienthal

Event Storming und Strategic Design: DDD mit vielen Teams

Im Domain-driven Design haben Fachleute und Entwickler eine gemeinsame Fachsprache geformt. Die Entwickler haben gelernt, wie die DDD-Muster Entity, Value Object, Service usw. anzuwenden sind, mit den Fachleuten ein Domänenmodell entworfen und parallel dazu eine Anwendung für eine verständliche Domäne gebaut. Alles gut, oder? Was passiert nun, wenn die Anforderungen wachsen und der Entwurf sehr komplex wird? Da muss Ordnung in das Domänenmodell hinein, sonst verliert man den Überblick. DDD gibt darauf eine Antwort: strategisches Design. Durch Strategisches Design können Sie die Kerndomäne, in der Ihr Business abläuft, in abgegrenzte Bereiche (Bounded Contexts) zerlegen, sodass mehrere Teams daran parallel arbeiten und den Überblick behalten können. Für die Kommunikation der Teams und der dort entstehenden Softwarekomponenten gibt es bewährte Muster wie Upstream-Downstream Relationships, Open Host/Published Language, Anti Corruption Layer und vieles mehr. Mit strategischem Design entwerfen Sie auch große Systeme, ohne dabei verrückt zu werden. Matthias Bohlens Workshop baut auf dem auf, was Dr. Carola Lilienthal Ihnen vorher gezeigt hat. Wir beginnen das strategische Design mit einem hoch interaktiven Event Storming. Gemeinsam in der Gruppe verbrauchen wir viele Post-its, um die zentra­len Business Events der Kerndomäne zu finden und daraus die Bounded Contexts abzuleiten. Sie erleben, wie sich daraus ganz natürlich eine Teamaufteilung ergibt, mit der Sie in ein großes Softwareprojekt aufbrechen können.
Matthias Bohlen

Architektur einer IT Transformation: 37 Dinge, die ein Chefarchitekt wissen muss

„Digital Disruptors“ fordern etablierte Konzerne durch ihre hohe Agilität, Freiheit von Legacysystemen und tiefem Verständnis für Einsatzmöglichkeiten neuer Technologien heraus. Bei der notwendigen Transformation traditioneller Unternehmen spielen IT Architekten eine Schlüsselrolle, weil sie die Brücke zwischen Geschäftsleitung und technischer Implementierung schlagen können. Architekten benötigen dazu allerdings auch exzellente organisatorische, politische, und kommunikative Fähigkeiten. Ziel dieses Workshops ist es, den Horizont von Architekten zu erweitern, um die Digitale Transformation mitgestalten zu können.
Gregor Hohpe

Cloud Native Architectures an einem Beispiel

Wenn wir Systeme für die Cloud bauen, stehen verschiedenste Infrastruktur- und Plattformdienste zur Verfügung. Die Optionen reichen von der einfachen Nutzung virtueller Maschinen bis hin zum Aufbau beliebig komplexer Datenverarbeitungslogik – ganz ohne (eigene) Server. Cloud-Anbieter erlauben uns, Services auf Knopfdruck zu abonnieren. Neue virtuelle Maschinen, Repositories, Datenbanken, Message-Queues und Event-Hooks sind nur wenige Mausklicks oder Cloud-API-Aufrufe entfernt. Dieser Workshop stellt verschiedene Architektur-Alternativen und unterschiedliche Cloud-Services an einem konkreten Beispiel vor und verknüpft dies mit den Themen aus den vergangenen Summits: der Kopplung von Self-Contained Systems & Microservices über Web-APIs und der Integration per Reactive Extensions.
Phillip Ghadir

Reaktive Microservices mit Akka

Das Reaktive Manifest beschreibt essenzielle Eigenschaften, welche moderne Systeme erfüllen müssen, um heutigen und zukünftigen Anforderungen gerecht zu werden: Stete Antwortbereitschaft als Grundlage für Funktion und Benutzbarkeit bedingt Widerstandsfähigkeit und Elastizität, realisiert durch Nachrichtenorientierung. In diesem Workshop beleuchten wir die Konsequenzen aus „Reaktiv“ für eine Microservice-Architektur, sowohl für den einzelnen Service, als auch für deren Kollaboration. Weiter zeigen wir anhand von Codebeispielen und Livedemos, wie wir reaktive Microservices mit Akka erstellen können.
Heiko Seeberger

Architekturanalyse im Team

Das Leben von Entwicklern ist heute nicht mehr Neuentwicklung – es ist Wartung. Die typischen Programmierer entwickeln heute keine Software mehr auf der grünen Wiese, sondern sie reparieren, erweitern, verändern und bauen vorhandene Software aus. Das größte Problem ihrer täglichen Arbeit ist, dass sich Wartung mit der Zeit von strukturierter Programmierung hin zu defensiver Programmierung verändert. Der Code wird zu komplex, um ihn zu warten. Die Entwickler fangen an, Code zu schreiben, von dem sie wissen, dass er aus Architektursicht schlecht ist. Aber er ist die einzige Lösung, die, wenn man Glück hat, funktioniert. Wartung wird immer schwieriger und teurer. In diesem Workshop werde ich Ihnen zeigen, wie Architekturanalyse im Team hilft, erst gar nicht in diese angeblich unvermeidbare Sackgasse abzubiegen. Sie werden sehen, welche Architekturen überlebensfähig sind und wie Sie ihre Architektur in diese Richtung bewegen. An praktischen Beispielen werden wir ausloten, welche Prinzipien Sie bei der Umsetzung der Architektur im Sourcecode einhalten sollen und welche Tools helfen, technische Schulden aufzuspü­ ren und abzubauen (Sotograph, Lattix, Structure101, TeamScale, SoftwareDiagnostics, SonarQube, u.v.m.). Wie kann man diese Techniken effektiv anwenden und Ergebnisse erzeugen, die die Wartungskosten reduzieren?
Carola Lilienthal

Microservices in der Cloud – Mit AutoScout24 auf die Überholspur

Keine Lust mehr auf Stau im Rechenzentrum? Wieso nicht einen Gang zulegen und auf die Überholspur wechseln? Lernen Sie, wie AutoScout24 die Autobahn in der Cloud baut. Wir erfinden uns grundlegend neu und wechseln vom Monolithen zu Microservices, von .NET auf Windows zu Scala auf Linux, vom Rechenzentrum zu AWS und von getrennter Entwicklung und Betriebsabteilung zu einer Kultur der Zusammenarbeit. An diesem Beispiel aus der Praxis werden sie erfahren, wieso diese Transformation wichtig ist, wie man „Cloud-native“ wird, wie eine Architektur sich entwickelt, wie autonome Teams Software entwickeln und betreiben und wie Prinzipien Orientierung geben.
Christian Deger

Self-contained Systems: Ein anderer Ansatz für Microservices (Teil 1)

Microservices sind gerade der Architekturhype. Aber man braucht mehr als nur einige kleine Services. Self-contained Systems (SCS, scs-architecture.org) sind ein auf Microservices basierender Architekturansatz, wie ihn auch Otto, Kaufhof oder Kühne+Nagel nutzten. SCS erlauben es, Software nicht nur in komplexen und gro­ ßen Projekten auch langfristig effizient zu entwickeln, sondern sie passen auf sehr viele Szenarien. Dabei sind sie nicht besonders kompliziert. Dieser Workshop erläutert Self-contained Systems, ihre Vorund Nachteile, den Unterschied zu Microservices und die Integration von Systemen im Frontend – eine wesentliche Basis für SCS. Wir erarbeiten außerdem eine fachliche und technische Architektur für ein SCS-System.
Eberhard Wolff

Bewertungsmethoden unter der Lupe: Architekturziele nachhaltig absichern (Teil 1)

Softwarearchitektur gezielt weiterzuentwickeln bedeutet Entscheidungen zu treffen: Strukturen, Technologien, Vorgehen. Sind Sie auf dem richtigen Weg? Können Ihre Architekturideen in der Umsetzung aufgetretene Probleme effektiv lösen? Helfen sie bei der Erreichung Ihrer Ziele oder behindern sie diese eher? Architekturbewertung kann Sicherheit schaffen und Risiken aufzeigen und damit helfen, die Aufwände im Projekt zu fokussieren. Als Entwicklungsteam können Sie Ihre Softwarelösungen mit einer Vielzahl unterschiedlicher Methoden bewerten. Jede hat ihren Zeitpunkt und jede richtet sich auf andere Fragestellungen. In diesem ganztägigen Workshop mit hohem Praxisanteil zeigen wir Ihnen, wie Sie Bewertungsmethoden in laufende Projekte integrieren und diese als Treiber für Ihre Architekturarbeit etablieren können. Am Vormittag steht die Differenzierung von qualitativen und quantitativen Analysemethoden im Vordergrund. Wir stellen sie kurz vor und zeigen Stärken, Schwächen und Kombinationsmöglichkeiten der beiden Methodenfamilien. Dabei wird zum Beispiel klar, was argumentative, Workshop-basierte Verfahren leisten können und welche Aspekte Ihrer Architekturziele sich mit statischen Codeanalysen verknüpfen lassen. Am Nachmittag geht es tiefer in die Details der quantitativen Analyse: Wie komme ich zu den „richtigen“ Metriken? Welche Fallstricke gibt es? Wie baue ich meine Dashboards auf? Diese und weitere Fragen klä­ ren wir gemeinsam im Übungsteil.
Harm Gnoyke
Stefan Zörner

Bewertungsmethoden unter der Lupe: Architekturziele nachhaltig absichern (Teil 2)

Softwarearchitektur gezielt weiterzuentwickeln bedeutet Entscheidungen zu treffen: Strukturen, Technologien, Vorgehen. Sind Sie auf dem richtigen Weg? Können Ihre Architekturideen in der Umsetzung aufgetretene Probleme effektiv lösen? Helfen sie bei der Erreichung Ihrer Ziele oder behindern sie diese eher? Architekturbewertung kann Sicherheit schaffen und Risiken aufzeigen und damit helfen, die Aufwände im Projekt zu fokussieren. Als Entwicklungsteam können Sie Ihre Softwarelösungen mit einer Vielzahl unterschiedlicher Methoden bewerten. Jede hat ihren Zeitpunkt und jede richtet sich auf andere Fragestellungen. In diesem ganztägigen Workshop mit hohem Praxisanteil zeigen wir Ihnen, wie Sie Bewertungsmethoden in laufende Projekte integrieren und diese als Treiber für Ihre Architekturarbeit etablieren können. Am Vormittag steht die Differenzierung von qualitativen und quantitativen Analysemethoden im Vordergrund. Wir stellen sie kurz vor und zeigen Stärken, Schwächen und Kombinationsmöglichkeiten der beiden Methodenfamilien. Dabei wird zum Beispiel klar, was argumentative, Workshop-basierte Verfahren leisten können und welche Aspekte Ihrer Architekturziele sich mit statischen Codeanalysen verknüpfen lassen. Am Nachmittag geht es tiefer in die Details der quantitativen Analyse: Wie komme ich zu den „richtigen“ Metriken? Welche Fallstricke gibt es? Wie baue ich meine Dashboards auf? Diese und weitere Fragen klä­ ren wir gemeinsam im Übungsteil.
Harm Gnoyke
Stefan Zörner

Self-contained Systems: Ein anderer Ansatz für Microservices (Teil 2)

Microservices sind gerade der Architekturhype. Aber man braucht mehr als nur einige kleine Services. Self-contained Systems (SCS, scs-architecture.org) sind ein auf Microservices basierender Architekturansatz, wie ihn auch Otto, Kaufhof oder Kühne+Nagel nutzten. SCS erlauben es, Software nicht nur in komplexen und gro­ ßen Projekten auch langfristig effizient zu entwickeln, sondern sie passen auf sehr viele Szenarien. Dabei sind sie nicht besonders kompliziert. Dieser Workshop erläutert Self-contained Systems, ihre Vorund Nachteile, den Unterschied zu Microservices und die Integration von Systemen im Frontend – eine wesentliche Basis für SCS. Wir erarbeiten außerdem eine fachliche und technische Architektur für ein SCS-System.
Eberhard Wolff