Software architecture as code

Simon Brown

Over the past few years, I've been distilling software architecture down to its essence, helping organisations adopt a lightweight style of software architecture that complements agile approaches. This includes doing „just enough“ up front design to understand the significant structural elements of the software, some lightweight sketches to communicate that vision to the team, identifying the highest priority risks and mitigating them with concrete experiments. Software architecture is inherently about technical leadership, stacking the odds of success in your favour and ensuring that everybody is heading in the same direction.

But it's 2015 and, with so much technology at our disposal, we're still manually drawing software architecture diagrams in tools like Microsoft Visio. Furthermore, these diagrams often don't reflect the implementation in code, and vice versa. This session will look at why this happens and how to resolve the conflict between software architecture and code through the use of architecturally-evident coding styles and the representation of software architecture models as code.

Teile und herrsche - Time To Market mit Microservices

Oliver Wegner

Die Fähigkeit von Unternehmen, schnell auf Marktveränderungen zu reagieren, ist zum kritischen Erfolgsfaktor geworden. Agile Softwareentwicklung und Continuous Delivery sind bewährte Konzepte zum schnellen Ausliefern von neuen Software-Releases bei gleichzeitig hoher Qualität im Enterprise-Umfeld. Doch jeder kennt das Phänomen, dass das Verändern der Software im Laufe der Zeit immer aufwändiger wird. Mit diesen höheren Aufwänden entwickeln sich schleichend längere Prozesse und höhere Testaufwände, so dass die Umsetzungsgeschwindigkeit insgesamt deutlich sinkt.

Wie kann man architektonisch dieser Herausforderung begegnen? Microservices bieten eine Antwort auf diese Fragestellungen. Kleine Systeme, die unabhängig voneinander entwickelt und separat betrieben werden können. In diesem Vortrag zeige ich auf, welche Anforderungen Systeme erfüllen müssen, die in so einem hoch dynamischen Umfeld betrieben werden. Diese Anforderungen werde ich anhand von praktischen Beispielen aus dem Otto.de-Umfeld demonstrieren und gleichzeitig nützliche Tipps für den Weg von Monolithen Richtung Microservice-Architekturen geben.

ATAM Anthologie. Eine Architektur im Wandel der Zeit

Stefan Zörner

Viele Softwaresysteme blicken auf eine bewegte Vergangenheit zurück. Änderungen im Umfeld, etwa im Markt oder durch technologische Neuerungen, setzten sie unter Druck. Mitunter stand am Ende die Neuentwicklung der Lösung oder zumindest großer Teile davon. Die Geschichte solcher Systeme wird selten erzählt.

Nicht so hier: In diesem Vortrag unternehmen wir eine kleine Zeitreise und bewerten eine prominente Software-Lösung, die bereits viele Jahre in zahllosen Umgebungen produktiv ist, zu verschiedenen Zeitpunkten gleich mehrmals. Zum Einsatz kommen Werkzeuge aus qualitativen Evaluierungsmethoden wie ATAM, gezielt ergänzt um quantitative Techniken. Wir fokussieren dabei auf gravierende Veränderungen im Softwaresystem – wichtigen Ereignissen in seiner Biographie. Wodurch waren die Schritte motiviert? Welche Risiken wurden bewusst in Kauf genommen, welche Kompromisse eingegangen? Haben sie sich rückblickend bewährt?

Continuous Delivery, DevOps, Cloud - Neue Anforderungen für neue Architekturen

Eberhard Wolff

In der IT ist einiges in Bewegung: Ständig neue Releases mit Continuous Delivery, enge Kollaboration zwischen Entwicklung und Betrieb durch DevOps und ganz andere Hardware in der Cloud. Das führt zu anderen Architekturen. Dieser Vortrag zeigt, welche Qualitätsziele sich aus den neuen Anforderungen ableiten lassen und welche Konsequenzen sich für Architekturen daraus ergeben. Einfaches Deployment oder der Umgang mit weniger ausfallsicherer Cloud-Hardware werden für künftige Architekturen entscheidend sein.

Technische Schulden in Architekturen abbauen

Carola Lilienthal

Zu Beginn eines Projekts bringen die Software-Entwickler und –Architekten in der Regel ihre besten Erfahrung und ihr gesammeltes Knowhow in die Architektur ein. Sie entwickeln eine Blaupause, die den funktionalen und nicht-funktionalen Anforderungen gerecht werden sollte, und hoffen darauf, dass diese Blaupause während der Implementierung eine gute Vorgabe ist, die immer wieder diskutiert und angepasst wird.

Während der Implementierung bleibt aber keine Zeit für Architekturdiskussionen und die Entwickler weichen oft ungewollt mehr und mehr von der Blaupause ab: Einerseits macht der Projektdruck Abweichungen notwendig, andererseits entstehen die Abweichungen ungewollt und unbemerkt. Die Architektur des Systems erodiert und das Entwicklungsteam baut Schritt für Schritt technische Schulden auf. Wartung und Erweiterung der Software werden immer teurer bis zu dem Punkt, an dem jede Änderung zu einer schmerzhaften Anstrengung wird.

In diesem Vortrag berichte ich von meinen Erfahrungen der letzten zehn Jahre mit der Analyse von Softwarearchitekturen in Java, C++, C# und ABAP: Wie entstehen technische Schulden? Wie können technische Schulden vermieden werden? Um technische Schulden sichtbar zu machen und ihnen rechtzeitig entgegenzusteuern, wurden in den letzten zehn Jahren verschiedene Architekturanalysewerkzeuge entwickelt (Sotograph, SonarQube, JDepend, XRadar, Axovion Bauhaus, Structure101, Lattix u.v.m.). Ich werde Ihnen am Ende des Vortrags einen Überblick über diese Werkzeuge und ihre Einsatzmöglichkeiten geben.

Die Zuhörer wissen nach meinem Vortrag, welche Fehler sie in ihren Softwareprojekten bei der Umsetzung der Architektur nicht machen sollten, welche Prinzipien Sie einhalten sollen, um technische Schulden nicht entstehen zu lassen, welche Tools helfen, technische Schulden aufzuspüren und wie technische Schulden abgebaut werden können.

Moderne Zeiten - Architekturen für Unternehmen von morgen

Uwe Friedrichsen

Die IT ist das Nervensystem praktisch jedes Unternehmens. Das bedeutet, dass die IT Systeme stets laufen und zügig antworten müssen. Das bedeutet auch: Keine Business-Änderung ohne eine Änderung der IT-Systeme, d.h. die IT limitiert die mögliche Änderungsgeschwindigkeit des Unternehmens. Aber wie sehen Architekturen aus, die sowohl super-robust in Produktion und gleichzeitig total flexibel in der Weiterentwicklung sind?

In dieser Session arbeiten wir zunächst konkrete Anforderungen an solche Architekturen heraus. Diese stellen wir gegen eine Reihe von Architekturtrends und prüfen, wie sehr die Trends die Anforderungen unterstützen. Microservices? Reactive? Cloud? Docker? CQRS? Oder? Was hilft, was nicht?

Basierend auf diesen Erkenntnissen werden wir einen konkreten Architekturstil betrachten, der die Anforderungen erfüllt. Dabei lernen wir auch, wie man diverse Einzellösungen kombinieren muss, um die gewünschten Ziele zu erreichen und dass eine gute Architektur häufig viel mehr ist als nur ein wenig Struktur. Neue Erkenntnisse garantiert ... ;-)

Panel: „Das Teufelszeug kommt zurück?“

Wolfgang Keller

Microservices sind einer der aktuellen Architekturtrends zu Agilisierung großer Entwicklungsvorhaben. DevOps heben teilweise die Trennung von Betrieb und Entwicklung wieder auf. Vor 25 Jahren waren Architekten stolz darauf, Säulenarchitekturen durch Schichtung zu vermeiden und IT-Manager waren froh, Betrieb und Entwicklung sauber getrennt zu haben. Es stellt sich nun die Frage ob Microservices und DevOps alte Gespenster in neuer Erscheinungsform sind oder was sich hier geändert hat, beziehungsweise welche Einflussfaktoren (Forces) hier eine Rolle spielen.

Software architecture as code

Simon Brown

Over the past few years, I've been distilling software architecture down to its essence, helping organisations adopt a lightweight style of software architecture that complements agile approaches. This includes doing „just enough“ up front design to understand the significant structural elements of the software, some lightweight sketches to communicate that vision to the team, identifying the highest priority risks and mitigating them with concrete experiments. Software architecture is inherently about technical leadership, stacking the odds of success in your favour and ensuring that everybody is heading in the same direction.

But it's 2015 and, with so much technology at our disposal, we're still manually drawing software architecture diagrams in tools like Microsoft Visio. Furthermore, these diagrams often don't reflect the implementation in code, and vice versa. This session will look at why this happens and how to resolve the conflict between software architecture and code through the use of architecturally-evident coding styles and the representation of software architecture models as code.

Mind The Gap - Architektur vs. Code

O. Fischer und D. Mahler

Software-Architekturen werden mit Begriffen beschrieben, für die keine überprüfbaren Repräsentationen in Programmiersprachen existieren. Die Folge: Architekturdefinitionen mit ihren Konzepten und Constraints sind nur als Dokumentation vorhanden, über deren Inhalt alle Entwickler auf dem Laufenden gehalten werden müssen. Dieses Vorgehen scheitert meist in der Praxis, ein Auseinanderdriften von Architektur und Code-Basis ist kaum zu verhindern. Der Vortrag präsentiert einen Ansatz der statischen Code-Analyse, welcher Informationen aus strukturrelevanten Artefakten – vom Buildsystem über Packages und Klassen, bis hin zu Framework-Deskriptoren – extrahiert und als Graph in einer Datenbank ablegt. Die gewonnenen Daten werden automatisiert über Regeln in Beziehung gesetzt, und um projektspezifische Konzepte bzw. Begriffe angereichert und validiert. Entwickler erhalten so stets aussagekräftiges Feedback über vorliegende Verletzungen.

Möglichkeiten und Grenzen der automatischen Analyse von Software-Architekturen – Erfahrungen aus Forschung und Praxis

Elmar Jürgens

Es gibt eine Reihe von statischen Analysewerkzeugen, die sich mit der Qualität von Software-Architekturen befassen. Angefangen von Konformitätsanalysen, die Unterschiede zwischen Soll- und Ist-Architektur identifizieren, bis hin zu spezifischen Metriken, die die Qualität von Architekturen bewerten. Oder das jedenfalls behaupten. In diesem Vortrag gibt Elmar Jürgens einen Überblick über verschiedene Analyseansätze. Dabei geht er auf Forschungsarbeiten und eigene Erfahrungen ein, um Sinn und Unsinn klar voneinander zu trennen; denn längst nicht alles, was sich einfach messen lässt und oft gemessen wird, lohnt auch die Messung. Außerdem stellt er seine eigenen Lessons Learned aus sieben Jahren Architekturanalyse in der Praxis vor, insbesondere im kontinuierlichen Einsatz und im Kontext von Architekturbewertungen.

Open Space

Moderation: Markus Wittwer

Ein Architekturthema, dass Dich brennend interessiert, aber zu dem es keinen Vortrag gibt?

Ein Thema, bei dem Dir der Vortrag nicht reicht und das Du noch dringend vertiefen möchtest?

Deine Architekturentscheidungen vorstellen und diskutieren?

In einem Open Space gestaltet ihr das Programm gemeinsam, Praktiker, Theoretiker, Fragende und Wissende. Hier wird ein Raum geöffnet, um mit Gleichgesinnten die Themen zu diskutieren, die Dir unter den Fingern brennen und gemeinsam neue Erkenntnisse zu sammeln.

Open Space

Moderation: Markus Wittwer

Ein Architekturthema, dass Dich brennend interessiert, aber zu dem es keinen Vortrag gibt?

Ein Thema, bei dem Dir der Vortrag nicht reicht und das Du noch dringend vertiefen möchtest?

Deine Architekturentscheidungen vorstellen und diskutieren?

In einem Open Space gestaltet ihr das Programm gemeinsam, Praktiker, Theoretiker, Fragende und Wissende. Hier wird ein Raum geöffnet, um mit Gleichgesinnten die Themen zu diskutieren, die Dir unter den Fingern brennen und gemeinsam neue Erkenntnisse zu sammeln.

Gerade genug Architektur vorneweg – Zur eigenen Architektur-Vision in 12 Minuten

Roland Mast

Big Design up front passt nicht zur agilen Vorgehensweise, aber wieviel Architektur-Arbeit ist im Voraus wirklich erforderlich? Wie gehe ich dabei vor und welche Ergebnisse sollen dabei entstehen? Egal ob Neuentwicklung oder größere Erweiterung, eine Phase 0 stellt den geeigneten Zeitraum für den Beginn der Architekturarbeit dar. Die ersten Ideen fließen in die Architektur-Vision ein und dienen als Startpunkt für die Entwicklung. Entwicklungsbegleitend wird die Architektur im Team weitergepflegt und die Ergebnisse fließen in die Architektur-Dokumentation ein. Bringen Sie Stift und Papier mit. Dann werden Sie im Rahmen einer 12-Minuten-Speed-Kata ihre eigene Erfahrung mit der Erstellung einer Architektur-Vision sammeln können.

Theorie leuchtet ein, Praxis ist einleuchtender – Architekturbewertung live und in Farbe als konkretes Fallbeispiel

Mahbouba Gharbi

Am lebhaften Beispiel einer existierenden Architektur führe ich Sie in die Kunst der qualitativen Softwarearchitekturbewertung ein.

Nach einer kurzen Einleitung, in der die Wichtigkeit der umfassenden Architekturbewertung im Detail dargestellt wird, widmet sich der Vortrag mit Workshop-Charakter einem konkreten Fallbeispiel. An diesem Fallbeispiel lernen Sie, welche Ergebnisse durch eine sorgsam durchgeführte Architekturbewertung nach ATAM möglich sind. Gemeinsam werden wir die Resultate unserer durchgängigen Beurteilung diskutieren, um Risiken und Chancen für Ihr weiteres Vorgehen zu erkennen.

Achtung: Teilnehmerzahl auf 15 Personen begrenzt.

Evolutionsstrategien: Refactoring im (ganz) Großen

Gernot Starke

Evolution und Verbesserung von Software müssen neben den Code-Umbauten im Kleinen auch das Große Ganze im Fokus halten, die langfristige Strategie: Wollen wir das bestehende System komplett ersetzen, oder nur Teile austauschen? Wollen wir einen Big-Bang, eine Database-first Migration, Legacy-Strangulation oder einen Change-by-Split?

In diesem Vortrag möchte ich Ihnen diese und andere Ansätze vorstellen, damit Sie für die langfristige, systematische Verbesserung Ihrer eigenen Systeme besser planen können.

ArchiteKultur – wie bekommen wir Architekturarbeit in den Alltag rein?

Matthias Bohlen

Stellen Sie sich vor, Sie haben fähige Entwicklungsteams, Product Owner, Projektleiter und diverse Kunden für ein existierendes, lauffähiges System. Es könnte alles so schön sein. Doch das System ist „wie Kraut und Rüben“. Die Entwicklung folgt keinen klaren Strukturen. Die Software ist viel zu schwer änderbar.

Wie kriegen Sie nun diesen „Flohzirkus“ dazu, eine Kultur zu entwickeln, in der konsequent Architekturarbeit gemacht wird? Eine Kultur, in der es nicht egal ist, wie eine Komponente heißt, von welchen anderen sie abhängt und wie schnell und wie unabhängig man sie in Betrieb nehmen kann? Eben eine Kultur, in der Architektur etwas gilt und Velocity bzw. Durchsatz der Teams nicht das alleinige Ziel sind.

Matthias Bohlen zeigt eine Mischung aus Bildern, Philosophien, Methoden und Tools, mit der Sie solch eine ArchiteKultur anziehen können – destilliert aus seiner Erfahrung in realen Projekten.

Technische Schulden - In the long run, we're all dead

Gerrit Beine

Als Softwarearchitekten balancieren wir ständig auf dem Grat der Entscheidungen. Und nur allzu oft bewahrheitet sich, dass die Softwarearchitektur die Summe teurer Entscheidungen ist: Technische Schulden geißeln uns.

An etlichen Stellen wird bereits der Ruf laut, dass der Begriff der Technischen Schuld überholt ist - oder von Anfang an falsch war. Die Suche nach einer neuen Metapher hat begonnen, wohin sie führt, wird sich zeigen.

Dieser Vortrag geht genau in die andere Richtung. Er zeigt, warum der Begriff der Technischen Schuld genau ins Schwarze trifft. Es wird deutlich, dass eine Diskussion über die Zukunft von Softwaresystemen mit Menschen, die keinen IT-Hintergrund haben, eine Brücke benötigt, die die Welten der Ökonomie und der IT zusammenführt. Abgerundet wird der Vortrag mit einer Methode zum Management Technischer Schulden, die sich bereits in vielen agilen Projekten bewährt hat.

Event Sourcing - Einführung und Best Practices

Michael Plöd

Unter Event Sourcing versteht man einen Architekturstil in dem Änderungen am Zustand der verwalteten Daten als eine Sequenz von Events festgehalten werden. Durch diese Herangehensweise können jederzeit Snapshots des Datenzustands erstellt und abgefragt werden. Des Weiteren ermöglicht uns das Persistieren von Events eine Optimierung der lesenden Zugriffe durch eine Denormalisierung des „Lese-Modells“ der Daten. Letzerer Aspekt ist aktuell insbesondere durch den Architekturansatz CQRS in aller Munde.

NoBullshit - Architekturarbeit neu gedacht

Stefan Toth

Klassische Architekturarbeit hat mit Modellen, Dokumenten und Richtlinien zu tun. Vielleicht werden auch Standards oder Metamodelle erarbeitet, Zielarchitekturen entworfen und größere Bewertungsworkshops geplant. Die Methoden dafür sind teilweise über 20 Jahre alt und gut verstanden.

Szenenwechsel: Moderne Internet-Frimen bauen große, komplizierte Applikationen in verteilten Projekten mit dutzenden Mitarbeitern - und von klassischer Architekturarbeit ist wenig zu sehen. Die Architekturdisziplin verwischt mit der Umsetzung, verliert ihre herausgehobene Stellung. Haben Spotify, Automattic (WordPress), Netflix oder Facebook einfach andere Voraussetzungen? Haben sie bessere Entwickler? Brauchen Web-Applikationen weniger Architektur?

In dieser Session wird mit einigen Vorurteilen und Mythen aufgeräumt und gezeigt, wie die Big Player des Internets Architektur gestalten und umsetzen. Dabei tauchen alt bekannte Architekturpraktiken in neuem Gewand auf, andere Praktiken werden neu gedacht oder auch verworfen. Konkrete Beispiele illustrieren den Wandel und zeigen Potenziale auf.

IoT und Architektur

Markus Schärtel

Das Internet of Things (aka Internet of Everything) ist in aller Munde, auch wenn niemand so recht weiß, was das ist und wo die „Reise“ hingeht. Jeder geht allerdings davon aus, dass es ohne mehr oder weniger Software nicht funktioniert und wendet mangels langfristiger Expertisen die bisher funktionierenden Mechanismen auf die neuen Herausforderungen an.

Der Beitrag erklärt anhand von realen Beispielen und Szenarien,

- wie und wo das IoT bereits in unser tägliches Leben Einzug gehalten hat und welche Trends sich abzeichnen

- wer die bekannten und die neuen Stakeholder in IoT-Projekten sind

- welchen Herausforderungen man sich aktuell und zukünftig stellen muss – sowohl als Hard- als auch als Softwerker

- warum die Ansätze und Mittel der klassischen Enterprise-Software-Entwicklung oft nicht (mehr) funktionieren

- welche „neuen“ (oft schon alten) Ansätze der Software-Entwicklung erfolgversprechend erscheinen

- mit welchen Unsicherheiten man als Architekt konfrontiert wird und warum diese den Blick wieder auf das Wesentliche fokussieren.

Ganz nebenbei entsteht in diesem Vortrag ein Bild des neuen Architekten im Umfeld des IoT, der sich jetzt (wieder) um Dinge Gedanken machen muss, die über die des klassischen Software-Architekten hinaus gehen.

Evolutionsstrategien: Refactoring im (ganz) Großen

Gernot Starke

Evolution und Verbesserung von Software müssen neben den Code-Umbauten im Kleinen auch das Große Ganze im Fokus halten, die langfristige Strategie: Wollen wir das bestehende System komplett ersetzen, oder nur Teile austauschen? Wollen wir einen Big-Bang, eine Database-first Migration, Legacy-Strangulation oder einen Change-by-Split?

In diesem Vortrag möchte ich Ihnen diese und andere Ansätze vorstellen, damit Sie für die langfristige, systematische Verbesserung Ihrer eigenen Systeme besser planen können.

Entwicklung verteilter Systeme - Herausforderungen nicht nur an die Architektur

Oliver Wehrens

Jede Platform wächst mit der Zeit. Mehr Entwickler mit noch mehr Ideen und Vorstellungen arbeiten alle gemeinsam an der Weiterentwicklung. Das System wird größer und auf viele Systeme verteilt. Häufig wird ein Technologie Stack vorgegeben, um es vermeintlich wartbarer und stabiler zu machen. Zusätzlich wird die Software oft dabei von Entwicklung zu QA weitergereicht und am Schluss von Operations deployed und betrieben. Das Ergebnis davon sind lange Releasezyklen und das verschenkte Potenzial, weil nicht die richtigen Tools genutzt werden konnten.

Dieser Vortrag erläutert unsere Leitplanken zur Entwicklung verteilter Systeme bei der E-POST. Wie erlauben wir es den 15 Teams mit 100 Personen „The right tool for the right job“ einzusetzen statt ein starres Korsett an Technologien vorzugeben? Welche Rahmenbedingungen müssen beachtet werden und wo kann ein Team autonom entscheiden wie eine Software zu entwickeln ist? Trotz wachsender Anzahl verteilter Systemen und steigender Komplexität wollen wir weiterhin eine stabile Platform zur Verfügung stellen. Es wird erklärt welche Anforderungen wir dabei in den Bereichen Architektur, Entwicklung, Testen, Deployment, Betrieb und Security vorgeben und was die Teams dabei beachten müssen.

Lightning Talks

u. a. Frank Pientka und Elmar Jürgens

Pragmatische Architektur – Frank Pientka

Die Anforderungen an Software steigen ständig. Einfache Anforderungen können zu aufwändigen und komplizierten Lösungen führen. Neben der Kommunikation stellt die bedarfsorientierte Dokumentation einer besonderen Herausforderung in agilen Projekten dar. Damit Projekte langfristig gelingen können, sind die bedarfsorientierte Architekturdokumentation und die nachhaltige Verfolgung der Qualitätsziele ein wesentlicher Erfolgsfaktor.

In der Sesseion werden Antworten und Lösungen auf folgende Fragen vorgestellt und diskutiert: Wo sind die Stärken und Schwächen von „Malen, schreiben oder basteln“? Darf`s ein bisschen weniger sein? Wie gelingt der Architekturentwurf im Team? Was ist bei der Erstellung einer „guten“ Architekturdokumentation zu beachten? Welche wichtige Rolle spielt gerade die Architekturdokumentation bei langlaufenden Produktentwicklungen mit vielen Stakeholdern?

Aufdeckung von fundamentalen Architekturproblemen durch Cross-Project-Clone-Detection – Elmar Jürgens

Clone Detection erkennt Copy & Paste Programmierung im Source Code. Typischerweise wird Clone Detection innerhalb einer Anwendung eingesetzt. Es gibt jedoch, gerade im Bereich der Architekturanalyse, einen weiteren interessanten Einsatzfall: Zur Erkennung von Copy & Paste im großen Stil zwischen verschiedenen Anwendungen. Im Lightning-Talk berichte ich von unseren Erfahrungen in der Cross-Project-Clone-Detection von Produktlinien, Produktfamilien und zwischen Abteilungen. Dabei konnten wir Architekturprobleme sowohl auf Organisations-, als auch auf technischer Ebene identifizieren.

iSAQB Advanced Module in 2 Minuten

In der iSAQB-Zertifizierung gibt es viele Advanced Module, die eine Vertiefung in Software-Architektur-Bereiche ermöglichen. Sie vermitteln so Wissen, von dem Software Architekten profitieren können - selbst wenn sie schon auf längere Erfahrung zurückblicken können. Jedes Modul bekommt zwei Minuten, um die Zuhörer von den Vorteilen zu überzeugen. So bietet die Session einen sehr konzentrierten Überblick darüber, wie es nach der iSAQB-Foundation-Zertifizierung im Advanced Level weitergehen kann.

Search Inside Yourself

Markus Wittwer

Eines der gefragtesten Fortbildungsprogramme innerhalb von Google ist jetzt öffentlich zugänglich: Search Inside Yourself ist ein innerhalb von Google entstandenes Programm zur Entwicklung von Emotionaler Intelligenz (EI). Neben technischer Kompetenz ist die Emotionale Intelligenz eine der Schlüsselfaktoren für exzellente (Architektur)Arbeit. Search Inside Yourself basiert auf neurowissenschaftlichen Erkenntnissen und kombiniert wirksame Übungen, um alle Bereiche emotionaler Intelligenz weiter zu entwickeln - ein intensives Fitnesstraining für den Geist.

Zur Zeit befinde ich mich in der Ausbildung zum Trainer für das Programm. Im Verlauf der Session stelle ich einige wesentliche Gedanken daraus vor und wir machen einige Übungen. Sie gehen (hoffentlich) erfrischt, mit einem Lächeln und Impulsen für eine Umsetzung im Alltag aus der Session heraus.

No Free Lunch: Microservices & Resilienz

Guido Steinacker

Microservice-Architekturen haben große Vorteile, wenn es um die technische und organisatorische Skalierbarkeit von Software-Systemen geht. Wie bei allen augenscheinlich „einfachen“ Lösungen, liegt der Teufel aber im Detail: Hochgradig verteilte Systeme bringen Herausforderungen mit sich, die man in einfacheren Architekturen so nicht findet. Fehlertoleranz ist ein solches Thema, welches in klassischen Architekturen eher stiefmütterlich behandelt wird, im Kontext von Microservices aber an Bedeutung gewinnt.

Patterns in a containerized world?

D. Benkert, M. Lübken

Structuring and developing applications in a containerized world involves new challenges. Some old best practices need to be adapted and new patterns evolve. In this talk we will give an overview of typical patterns that we have seen in developing, deploying and operating applications that leverage containers. Some of these are: immutable deployment artefacts, config via arguments, general purpose sidekicks, special sidekicks for logging and metrics, ambassador for service discovery or other networking related things, like load-balancing and circuit breaking. As containers are a fairly new concept for general purpose application development, we see this list far from complete. This talk can be seen as a starting point for a general discussion about best practices and resulting patterns.