Der Vortrag zeigt methodisches Vorgehen von Software-Reviews, beginnend mit dessen konkreten Zielen, dem Scope sowie den notwendigen Personen. Anschließend schauen wir auf verschiedene Untersuchungsbereiche, wie Architektur, Code, Technologie, Qualitätsanforderungen bis hin zu Anwendungsdaten und den Entwicklungs- und Rollout-Prozessen.
Der Kernbegriff dabei lautet "iterative Breitensuche".
Schließlich bekommen Sie noch Tipps, die Sie für überzeugende Darstellung und Kommunikation Ihrer Schlussfolgerungen und Empfehlungen beachten sollten.

Zielpublikum: Software-Architekt:innen, Entwickler:innen, technisches Management
Voraussetzungen: Projekterfahrung
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Jede Software besitzt "Potenzial", also "besser geht immer". Aber bevor wir anfangen, wild an unseren Systemen zu verschlimmbessern, benötigen wir zuerst einen ordentlichen Überblick über deren Stärken und Schwächen.
Der Vortrag zeigt methodisches Vorgehen solcher Reviews, beginnend mit dessen konkreten Zielen, dem (schwierigen) Scope sowie den notwendigen Personen (aka Stakeholder). Anschließend schauen wir etwas genauer auf verschiedene Untersuchungsbereiche, wie Architektur, Code, Technologie, Qualitätsanforderungen bis hin zu Anwendungsdaten und den Entwicklungs- und Rollout-Prozessen. Ein Kernbegriff dabei lautet "iterative Breitensuche", wobei wir die bedarfsgerecht durch Tiefensuche ergänzen. Zu jedem Untersuchungsbereich gebe ich Beispiele und zeige methodische Werkzeuge zum effektiven und praxisnahen Einsatz. Schließlich bekommen Sie noch Tipps, die Sie für überzeugende Darstellung und Kommunikation Ihrer Schlussfolgerungen und Empfehlungen beachten sollten.

Der Vortrag richtet sich an Software-Entwicklungsteams, Architekt:innen, Product Owner sowie technisches Management.

Eine Serverless-Anwendung besteht aus vielen voneinander unabhängigen Funktionen. Die Entwickler:innen können dabei aus zahlreichen Programmiersprachen auswählen. Der Cloud-Anbieter übernimmt den Betrieb und vor allem die Skalierung dieser Funktionen. Bezahlt wird pro Aufruf. Der Vortrag zeigt, welche technischen Herausforderungen eine Serverless-Anwendung mit sich bringt und wie sich Entwicklung und Betrieb anfühlen. Die Zuhörerenden bekommen zudem einen Einblick in die Cloud-Angebote der Azure- und AWS-Cloud und deren Kostenstruktur.

Zielpublikum: Architekt:innen, Entwickler:innen, Manager:innen und Entscheider:innen
Voraussetzungen: Grundlegende Kenntnisse bei der Entwicklung einer Anwendung in der Cloud sind ausreichend
Schwierigkeitsgrad: Anfänger

Extended Abstract:
Früher monolithische Anwendungen auf einem schwergewichtigen AppServer, heute vielleicht Microservices mit Docker und Kubernetes und morgen Serverless in der Cloud? Gerade im Umfeld großer und über einen langen Zeitraum gewachsener Systeme lassen sich Architekturentscheidungen nur schwer ändern und daher müssen Anpassungen umsichtig und mit Weitblick geplant werden. Aber auch abseits schnelllebiger Startups dürfen Innovationen nicht völlig ausbleiben. Daher wagt dieser Vortrag einen vorsichtigen Ausblick sowohl auf die Chancen als auch die zu erwartenden Herausforderungen des neusten Hypes unter dem Schlagwort „Serverless“.

Wie baut man eigentlich eine Anwendung aus lauter einzelnen Funktionen zusammen? Wie verbindet man diese Funktionen? Warum und unter welchen Voraussetzungen kann das eine gute Idee sein? Wie kann man dabei den Überblick über die gesamte Anwendung behalten? Diese und viele weitere Fragen werden im Laufe des Vortrags gestellt und mit den heute zur Verfügung stehenden Lösungen beantwortet. Dabei werden Fragen, auf die es heute noch keine zufriedenstellende Antwort gibt, bewusst nicht ausgespart.

SOLID principles are well-known for designing object-oriented systems. But what if you are developing microservices? IDEALS, is yet another silly mnemonic acronym and are the core principles for microservice design. The acronym stands for: Interface segregation, Deployability, Event-driven, Availability over consistency, Low Coupling, and Single responsibility. We will relate these IDEALS to techniques, tools, technologies, and domain modeling principles we use today to develop modern service-based distributed systems (microservices).

Target Audience: English, Developers, Architects, QAs, Testers, Product Owners, Managers
Prerequisites: Basic Understanding of architecture and microservices and familiarity with domain modeling
Level: Advanced

Extended Abstract:

It's been seven years since we've started creating microservices. Practice has shown what design principles give you a sound foundation for a successful microservice architecture. Join us in this session to find out what they are, and how to realize them. For OO systems, Robert Martin compiled the five SOLID principles. For designing microservice-based solutions, we propose developers follow the "IDEALS":  

(I) Interface segregation tells us that different types of clients (e.g., mobile apps, web apps, CLI programs) should be able to interact with services through the contract that best suits their needs. 

(D) Deployability (is on you) acknowledges that in the microservice era, which is also the DevOps era, there are critical design decisions and technology choices developers need to make regarding packaging, deploying and running microservices. 

(E) Event-driven suggests that whenever possible we should model our services to be activated by an asynchronous message or event instead of a synchronous call. 

(A) Availability over consistency reminds us that more often end users value the availability of the system over strong data consistency, and they're okay with eventual consistency. 

(L) Loose-coupling remains an important design concern in the case of microservices, with respect to afferent (incoming) and efferent (outgoing) coupling. 

(S) Single responsibility is the idea that enables modeling microservices that are not too large or too slim because they contain the right amount of cohesive functionality. 

We will relate these IDEALS to techniques, tools, technologies and domain modeling principles we use today to develop modern service-based distributed systems (microservices).

Das Gesetz von Conway, Domain-driven Design, Microservices - die aktuell wichtigsten Architektur-Ansätze – nutzen die Organisation als Werkzeug für Architektur. Aber Software-Architekt:innen können die Organisation oft nur bedingt beeinflussen. Dieser Vortrag zeigt, was es genau heißt, die Organisation als Werkzeug für Architektur zu nutzen, und wie man als Software-Architekt dabei ganz konkret vorgehen kann.

Zielpublikum: Technische Projektleiter:innen, Architekt:innen, Entwickler:innen
Voraussetzungen: Grundlegendes Verständnis über Software-Entwicklung
Schwierigkeitsgrad: Anfänger

Extended Abstract:
In meiner Arbeit nehme ich zunehmend die Organisation als das entscheidende Werkzeug wahr, um Architekturen zu beeinflussen. Mittlerweile ist vielen Architekt:innen zwar klar, dass sie kommunizieren müssen. Aber ich denke, es geht noch viel weiter. Dazu kommt, dass sowohl Conway's Law wie auch Domain-driven Design bereits die Wechselwirkungen zwischen Architektur und Organisation darstellen.