In the fast moving startup world, there’s often not a lot time to think about architecture. As I grew N26 from 55 to more than 350 people in two years, I wanted to make sure that we didn’t only grow quickly but also delivered a quality product.
This talk explores how I introduced a number of practices how to decentralise and scale out architectural decision making.
Die Trainer*innen geben einen Einblick in die folgenden Workshops.
Die Trainer*innen geben einen Einblick in die folgenden Workshops.
Eine grundsätzliche Frage bei der Softwareentwicklung ist, wie man die Domäne richtig schneiden kann. In Zeiten von Microservices ist das besonders bewusst geworden, aber auch unabhängig davon muss man diese Frage beantworten. Ziel ist es, zu einer tragfähigen Architektur und einem guten Domänenmodell zu kommen. Dabei ist erstens wichtig, die Bounded Contexts und Subdomänen herauszuarbeiten. Wir zeigen, wie uns Collaborative Modeling Methoden wie Event Storming und Domain Storytelling dabei helfen.
Sie möchten also Ihr eigenes Framework entwickeln? Wir hatten vor einigen Jahren die gleiche Idee... und wir haben unsere Lektion gelernt! Dieser Workshop beschäftigt sich mit spannenden und langweiligen Dingen: Mit Dingen, die gut funktioniert haben, und mit Dingen, die rückblickend eine schlechte Idee waren. Es wird um HTTP/2, Proxies, SSL-Hacks, Datenbanken, CLIs, REST und viele andere Themen gehen. Aber am Ende ist es die Antwort auf eine einzige Frage: Wenn Sie Ihr eigenes Framework entwickeln wollen – worauf müssen Sie achten?
Nachdem sie schon einige Jahre fast ausschließlich remote gearbeitet hatte, beschloss Nicole, sich für ein Jahr als "Digitaler Nomade" auf Weltreise zu begeben. In diesem Vortrag verrät sie einige Tipps und Tricks und was man bei einem solchen Vorhaben alles bedenken sollte. Und natürlich wird auch das eine oder andere Urlaubsfoto dazwischengeschmuggelt ;-)
Would you fly in a plane designed by a craftsman or would you prefer your aircraft to be designed by engineers? Engineering is the application of iterative, empirical, practical science to real-world problems. Craftsmanship is a wonderful thing, and as a reaction to the terrible abuses of the term Engineering in software development Software Craftsmanship has helped in our learning of what really works.
The term "Software Engineering" has gained a bad reputation. It implies "Big up-front design" and "Mathematically provable models" in place of working code. However, that is down to our interpretation, not a problem with "Engineering" as a discipline.
In recent years we have discovered what really works in software development. Not everyone practices approaches like Continuous Delivery, but it is widely seen as representing the current state-of-the-art in software development. This is because at its root CD is about the application of an iterative, practical, empirical, maybe even science based approach to solving problems in software development. Is this a form of software engineering?
Software isn't bridge-building, it is not car or aircraft development either, but then neither is Chemical Engineering, neither is Electrical Engineering. Engineering is different in different disciplines. Maybe it is time for us to begin thinking about retrieving the term "Software Engineering" maybe it is time to define what our "Engineering" discipline should entail.
Die Trainer*innen geben einen Einblick in die folgenden Workshops.
Wir entwerfen ein Domänenmodell direkt im Code, und zwar in einer funktionalen Programmiersprache, so dass das Ganze auch für Nicht-Entwickler lesbar und verstehbar wird. Damit lässt sich bereits in einem sehr frühen Stadium mit den Domänenexperten diskutieren und das beiderseitige Verständnis abgleichen.
Zuerst werden die Teilnehmer in die funktionale Sprache F# eingeführt, soweit erforderlich (Syntax und Semantik der verschiedenen Typdefinitionen). Anschließend werden die Teilnehmer in kleinen Gruppen anhand eines konkreten Beispiels eine eigene Modellierung am Rechner durchführen. Anschließend werden verschiedene Lösungsansätze vorgestellt und besprochen.
In Unternehmen werden Datenanalysen intensiv genutzt, um aus Geschäftsdaten wertvolle Einsichten zu gewinnen. Warum nutzen wir als SoftwarearchitektInnen nicht auch Datenanalysen, um besser Einsichten in unsere Software und deren Entwicklung zu bekommen? In diesem Workshop stelle ich Vorgehen und Best Practices von Software Analytics sowie zugehörige Werkzeuge (wie Jupyter, pandas, jQAssistant, Neo4j und Co.) vor. Damit gewinnen wir gemeinsam wertvolle Einsichten aus Datenquellen wie Git-Repositories, Performancedaten, Qualitätsberichten oder auch direkt aus dem Programmcode. Gerne kann bei diesem interaktiven Workshop direkt mitgearbeitet werden. Ein Notebook mit Internetzugang reicht hierfür völlig aus.
Die Trainer*innen geben einen Einblick in die folgenden Workshops.
Qualitätsziele von Softwaresystemen geben uns eine wertvolle Basis, um richtige Architekturentscheidungen treffen zu können. Aber wie kommen wir zu verständlich definierten Qualitätszielen? Wie können wir diese Ziele später validieren? Und wie erreichen wir überhaupt hierzu passende Lösungen?
In diesem Workshop lernen TeilnehmerInnen, wie sie Qualitätsziele ermitteln, präzisieren und konkret erfüllen können. Zudem wird die Entscheidungsfindung unter den gegebenen Zielen und Randbedingungen geschult. All diese Themen werden anhand eines konkreten Fallbeispiels in Theorie und (Spiel-)Praxis vermittelt.
What an architect can learn from retrospective failures
Based on 15 years of experience with facilitating retrospectives for software developers, I have described the most common challenges in 24 antipatterns. Antipatterns are like patterns, just more informative in that you first learn what the immediate bad solution is before you get a better solution. Alongside the retrospectives I have facilitated architecture reviews and there are a lot of similarities between these two activities. Both include a shared experience that needs to be reflected on, both include people with pride and shame in what has been created, and both are under the usual time and resource constraints. Join me for a sad and entertaining talk about how your architecture review sessions can improve based on all my mistakes.
Die Trainer*innen geben einen Einblick in die folgenden Workshops.
Machine Learning ist als Daten getriebenes Thema reizvoll, es erschließt sich jedoch nicht ohne weiteres. In diesem Workshop sprechen wir daher über die Motivation warum man überhaupt Machine Learning machen sollte, was man dazu braucht und welche Anwendungsgebiete sich anbieten.
Eine Strategie für den Einsatz von Machine Learning im Unternehmen oder im Projekt ist dabei weder von organisatorischen, noch von architektonischen Fragestellungen zu trennen. Daher beschäftigen wir uns ebenso mit Rollen und Prozessen wie mit den Anforderungen und Qualitätszielen für Machine Learning.
Jeder Teil wird durch Übungen gestützt, die sowohl vor Ort als auch online in Gruppen durchgeführt werden können.
Alle Teilnehmer*innen nehmen am Ende des Workshops einen anschaulichen Leitfaden zum Thema Machine Learning mit, der den behandelten Stoff reich bebildert zusammenfasst.
„Cloud is the new Normal”, so Andrew R. Jassy (CIO AWS). Was also liegt näher, als genau jetzt den Schritt in die Cloud zu wagen? Denn schließlich wollen wir ja alle irgendwie ein klein wenig „normal“ sein. Aber ist dieser Schritt wirklich so einfach, wie uns die verschiedenen Cloudanbieter glauben machen? Lässt sich eine klassische Enterprise-Architektur einfach so in die Cloud überführen oder bedarf es neuer cloudspezifischer Architekturmuster? Im Rahmen des Workshops werden wir Schritt für Schritt eine bestehende Enterprise-Anwendung in die Cloud migrieren. Angefangen bei der Nutzung von Cloudinfrastruktur (IaaS) über die Anbindung von Cloudplattformkomponenten (PaaS) und Backend-Services (BaaS) bis hin zu Serverless Functions (FaaS) werden wir für die unterschiedlichen Anwendungsszenarien unserer Applikation passende Architekturansätze entwerfen und deren Vor- und Nachteile diskutieren. Natürlich sprechen wir dabei auch Themen wie Testing, Monitoring und automatisiertes Deployment an.
Die Trainer*innen geben einen Einblick in die folgenden Workshops.
Architekturentscheidungen werden beinahe täglich und zumeist implizit getroffen. Da eine Dokumentation dieser nur in den seltensten Fällen erfolgt, existiert das Wissen über die Entscheidungen nur in den Köpfen der Entwickler und eine Weitergabe an neue Entwickler ist schwer bis nicht möglich. Dadurch mangelt es häufig an der Umsetzung der Architekturregeln und es kommt zu einem Wildwuchs verschiedener Stile und Umsetzungsarten. Das Zurechtfinden in der Anwendung wird dadurch immer schwieriger.
Dieser Workshop möchte mit Michael Nygards "Architecture Decision Records" einen leichtgewichtigen Ansatz zur Dokumentation und Kommunikation von Architekturentscheidungen aufzeigen. Am Beispiel soll erläutert werden, wie sich das Treffen und Kommunizieren von Entscheidungen mit ADRs effizient in den Entwicklungsprozess integrieren lassen. Das Hauptaugenmerk liegt dabei insbesondere in dem Nachvollziehbar-machen der Entscheidungen für alle Entwickler. Es wird gezeigt, wie sich ADRs mit AsciiDoc versioniert und nachvollziehbar im Projekt integrieren lassen, diese zentral allen zur Verfügung gestellt werden können und wie die Einhaltung der Entscheidungen automatisiert geprüft werden kann.
Mit Event Storming Workshops kann man schnell Domänen erforschen, über die man in der Gruppe bisher noch kein gemeinsames Verständnis hatte. Es hilft dabei sehr, wenn man die "Flughöhe" vorher festlegt:
Geht es vielleicht...
a) um einen Überblicksworkshop zum Erforschen des Business,
b) um Prozessmodellierung für einen einzelnen Prozess, oder
c) um Software Design, um tatsächlich gemeinsam einzelne Aggregates zu entwerfen, bis in die Details zu Commands und Read Models?
Für alle drei Ebenen hat Event Storming passende Modellierungsweisen.
Matthias Bohlen geht in dieser Session auf Fragen ein:
Was sind die Unterschiede zwischen diesen drei Workshoptypen?
In welcher Situation nimmt man welchen Workshoptyp?
Welcher Typ braucht welche Beteiligten?
Was kommt dabei heraus und was ist der Vorteil?
Wie passt das Ganze in ein iteratives Vorgehen wie z.B. XP, Scrum oder FDD hinein?