Die Arbeit mit Stakeholdern gehört für uns als Software Architekt(inn)en zweifelsohne zum täglichen Geschäft. Wir sprechen täglich mit verschiedenen Personengruppen: Betrieb, Management, Entwicklung oder Test. Allerdings kommt eine Gruppe in unseren Abstimmungen häufig zu kurz: Leute mit tiefem fachlichem Know-How. Diese werden entweder organisatorisch viel zu weit von der Entwicklungstätigkeit abgekapselt oder sie kämpfen in Meetings mit viel zu viel IT-Slang.
Diese Keynote soll dazu aufrufen, diese äußerst wertvolle Zielgruppe wieder näher an die Entwicklung zu bringen. Dazu ist auch auf unserer Seite ein Umdenken erforderlich: wir müssen Rahmenbedingungen schaffen, in denen Personengruppen aus unterschiedlichen Unternehmensteilen auf Augenhöhe und ohne Barrieren miteinander kommunizieren können. Dazu ist vor allem eines gefordert: gegenseitige Empathie. Genau darum geht es in dieser Keynote: sie ist ein Plädoyer mit Lösungsvorschlägen für mehr gegenseitige Empathie um mittelfristig bessere und passendere Produkte entwerfen, entwickeln und ausliefern zu können, so dass aus „you build it, you run it“ ein „you design it, you build it, and you run it“ wird.
Hier stellen die Trainer, deren Workshops im Anschluss folgen, den Inhalt ihrer Workshops vor. Diese kurze Einführung soll den Teilnehmern dabei helfen, sich für einen Workshop zu entscheiden.
Mit Context Maps wird versucht, den Kontakt zwischen Bounded Contexts auf formeller Ebene in ganzheitlicher Sicht darzustellen. Dabei geht es neben den üblichen Liefer- und Leistungsbeziehungen aber auch sehr stark um organisatorische Aspekte. Der Workshop startet mit einer kurzen Einführung zum Thema Bounded Context um dann mit diesem Wissen alle Facetten der Context Map zu erklären. Hierbei gehen wir unter anderem auch auf die Begriffe Up- und Downstream System ein. Weiterhin werden alle Patterns, die sich inzwischen in der DDD Community rund um die Context Map angesammelt haben, praxisnah erläutert. Abschließend werden im Rahmen des Workshops noch Notationsformen für Context Maps vorgestellt. Der Workshop besteht aus ca 70% Theorie und 30% Praxis. Ein grobes Vorwissen zu DDD und Bounded Contexts wäre wünschenswert.
Die Erstellung einer Microservice-Architektur alleine garantiert noch lange keinen Projekterfolg. Eine Verteilung auf das Netzwerk hilft zweifelsohne dauerhaft Modulgrenzen einzuhalten, beantwortet allerdings nicht die Frage, wo diese Grenzen idealerweise zu ziehen sind. Fachliche Dekomposition wie im Strategic Design des DDD ist in aller Munde, stößt aber an Grenzen, wenn technische Querschnittsthemen die Fachlichkeit überlagern und liefert uns außerdem keinen Mechanismus zur Prüfung, ob die Abgrenzung der Services oder Module effizient erfolgt ist.
Auch früher war nicht alles schlecht, und längst nicht jeder Deployment-Monolith endete als Big-Ball-of-Mud. In diesem Workshop übertragen wir auf Metriken basierende Strukturansätze auf moderne Architekturstile, welche uns helfen eben diese Modul- und Servicegrenzen an der richtigen Stelle zu ziehen. Dabei kombinieren wir Microservices mit Ansätzen wie Clean Architecture, Modulithen, SCS, MonolithFirst oder Right-Sized-Services und schaffen das Rüstzeug um die Fehler der Vergangenheit nicht zu wiederholen.
Es gibt mehr gestohlene Nutzerkonten (ca. 5 Mrd.) als Internetnutzer (ca. 4 Mrd.). Bei vielen dieser Konten ist es möglich das Passwort zu rekonstruieren, da sie nur unzureichend geschützt sind, z. B. per MD5- oder SHA-Hashing. Der sichere Umgang mit Anmeldedaten hat zahlreiche Anforderungen, beispielsweise: sicheres Hashing von Passwörtern, nutzerfreundliche, aber sichere Passwort-Wiederherstellung und Passwort-Richtlinien, sowie passwortlose und Multi-Faktor-Authentifizierung. Erwerben Sie in diesem Workshop die relevanten Kenntnisse und Methoden. Setzen Sie diese direkt in praktischen Übungen um und profitieren Sie vom gegenseitigen Erfahrungsaustausch.
Hier stellen die Trainer, deren Workshops im Anschluss folgen, den Inhalt ihrer Workshops vor. Diese kurze Einführung soll den Teilnehmern dabei helfen, sich für einen Workshop zu entscheiden.
Zahlreiche Softwareprojekte scheitern nicht nur wegen der gewählten Technologien, sondern vor allem an einem Mangel an interdisziplinärer Kommunikation. Entwickler und Fachleute sprechen verschiedene Sprachen und verstehen einander nicht. In den vergangenen Jahren hat sich Domain-driven Design (DDD) zunehmend als Vorgehensweise etabliert, das Problem zu lösen. Doch wie funktioniert DDD, und welchen Bezug hat es zu Event-Sourcing und CQRS? Die drei Konzepte werden häufig in einen Topf geworfen, sind tatsächlich aber unabhängig voneinander – unter gewissen Umständen können sie einander aber ergänzen. In dem Workshop entwirren Sie gemeinsam mit Golo Roden das Geflecht. Außerdem zeigt er Ihnen, wie man auf der Basis von DDD, Event-Sourcing und CQRS eine Anwendung für die Cloud mit JavaScript entwickeln kann.
Moderne Web-Frontends erfordern genauso schwierige Architekturentscheidungen wie das Backend – und die Entscheidungen haben genauso weitreichende Konsequenzen. Auch die Herausforderungen sind ähnlich: Wartbarkeit und parallele Arbeit in weitgehend unabhängigen Teams müssen ermöglicht werden. Hinzu kommen Web-spezifische Anforderungen wie die Lauffähigkeit in den diversen Browsern, die Größe auszuliefernder Artefakte oder Fehlerbehandlung.
Dieser Workshop behandelt komponentenorientierte Modularisierungskonzepte von HTML, CSS und JavaScript. Dazu gehören die Atomic-Design-Methodik, verschiedene Modularisierungsansätze wie BEM (Block Element Modifier) sowie erprobte Werkzeuge der Frontend-Gemeinde wie CSS Präprozessoren und JavaScript Transpiler. Darüber hinaus stellt der Workshop verschiedene Architekturmuster gegenüber, etwa die Abwägung zwischen Server- und Client-lastigen Anwendungen. Zum Schluss behandeln wir das Thema Frontend in verteilten Systemen wie Microservice-Architekturen oder Self-contained Systems und stellen Styleguides vor.
Wir leben in einer Zeit, in der so manch altes Softwaresystem nicht mehr einfach durch ein neues ersetzt werden kann. Dennoch begegnen viele Entwickler den wichtigen, sogenannten „Legacy-Systemen“ mit einer gewissen ablehnenden Haltung. In diesem Workshop stellen wir vor, wie Entwickler und Softwarearchitekten mit agilen, systematischen Ansätzen und modernen Werkzeugen ihren (klaren) Kopf behalten können. Wir zeigen, wie gewinnbringende Maßnahmen identifiziert werden können, um Software wirtschaftlich und nachhaltig zu verbessern. Wir stellen Analysetechniken vor, welche uns mit Zahlen-Daten-Fakten Mittel gegen verkrustete Strukturen und überholte Entscheidungen liefern. Zusätzlich demonstrieren wir live, wie Software datenorientiert analysiert und schmerzfrei nachdokumentiert werden kann. Wir identifizieren spielerisch Risiken und Chancen, bewerten unsere Entwicklungsaktivitäten ganz neutral und machen technische Umbauarbeiten für Nicht-Techniker nachvollziehbar.
In software development, we strive for inspection and adaptation. In order to make the best of this, we have to feel good about ourselves and with each other. Fun and laughter is something I have always tried to enhance in the places where I work, but only recently have I started looking into why it is helpful.
Diving into this subject, I was amazed by how big an impact fun and laughter can have on your social life, your wellbeing, and your energy levels. Join me for a session with brain research, examples of fun, and case studies from real life. Bring an open mind and leave with knowledge about why you should have fun every day.
Any idea how to climb the ladder but remain technical? Or how to avoid being promoted away from what you love?
Did you realise when you started your career just how important non-technical skills would be? What other skills would make life easier but are undervalued?
How do you stay ahead of the curve? Stay relevant? In this session Trisha is going to share some lessons she learnt the hard way while managing her career as a developer / lead / technical advocate. She’ll give you tools for working out what your next steps are. And plenty of examples of what not to do!
Hier stellen die Trainer, deren Workshops im Anschluss folgen, den Inhalt ihrer Workshops vor. Diese kurze Einführung soll den Teilnehmern dabei helfen, sich für einen Workshop zu entscheiden.
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. Die Software sammelt immer mehr technische Schulden an.
In diesem Workshop zeige ich Ihnen, wie Domain-driven Design Ihrem Team hilft, diese angeblich unvermeidbare Sackgasse zu vermeiden. Die Konzepte und Lösungen von DDD sollten zu Beginn eines Projekts eingesetzt werden, aber sie verbessern die Situation auch in einem laufenden Projekt und in der Wartung.
In diesem Workshop beschäftigen wir uns mit der Architektur und den technischen Grundlagen des Blockchain-Ansatzes. Der Schwerpunkt liegt dabei darauf, die Technik zu durchdringen und am Beispiel von verschiedenen konkreten Implementierungen (inkl. der üblichen Verdächtigen Bitcoin und Ethereum) deren Anwendung zu demonstrieren. Schließlich sehen wir uns mögliche Anwendungsfälle für öffentliche und nicht-öffentliche Blockchains an. Anders formuliert: Was Sie schon immer über Blockchains wissen wollten, aber noch nie zu fragen wagten – oder was Ihnen noch nie ordentlich beantwortet wurde.
In diesem Workshop teilen wir eine Domäne mit Domain-driven Design in mehrere Microservices auf. Dann entscheiden wir über die Integrationstechnologie und bringen die Anwendung auf Kubernetes in Produktion. Schließlich kümmern wir uns um das Monitoring und Logging. So zeigt das Tutorial an einem einfachen Beispiel, wie man eine konkrete Microservices-Anwendung von der Architektur über die Implementierung bis in Produktion bringt. Der Beispiel-Code liegt auf GitHub bereit, um die Ideen auf dem eigenen Laptop nachvollziehen zu können.
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. Die Software sammelt immer mehr technische Schulden an.
In diesem Workshop zeige ich Ihnen, wie Domain-driven Design Ihrem Team hilft, diese angeblich unvermeidbare Sackgasse zu vermeiden. Die Konzepte und Lösungen von DDD sollten zu Beginn eines Projekts eingesetzt werden, aber sie verbessern die Situation auch in einem laufenden Projekt und in der Wartung.
In diesem Workshop beschäftigen wir uns mit der Architektur und den technischen Grundlagen des Blockchain-Ansatzes. Der Schwerpunkt liegt dabei darauf, die Technik zu durchdringen und am Beispiel von verschiedenen konkreten Implementierungen (inkl. der üblichen Verdächtigen Bitcoin und Ethereum) deren Anwendung zu demonstrieren. Schließlich sehen wir uns mögliche Anwendungsfälle für öffentliche und nicht-öffentliche Blockchains an. Anders formuliert: Was Sie schon immer über Blockchains wissen wollten, aber noch nie zu fragen wagten – oder was Ihnen noch nie ordentlich beantwortet wurde.
In diesem Workshop teilen wir eine Domäne mit Domain-driven Design in mehrere Microservices auf. Dann entscheiden wir über die Integrationstechnologie und bringen die Anwendung auf Kubernetes in Produktion. Schließlich kümmern wir uns um das Monitoring und Logging. So zeigt das Tutorial an einem einfachen Beispiel, wie man eine konkrete Microservices-Anwendung von der Architektur über die Implementierung bis in Produktion bringt. Der Beispiel-Code liegt auf GitHub bereit, um die Ideen auf dem eigenen Laptop nachvollziehen zu können.
Am Dienstag bietet der "Ballroom" eine sehr gute Gelegenheit wichtige Softwarearchitekturthemen mit den Trainern in entspannter Atmosphäre zu diskutieren. An speziellen Thementischen können Teilnehmer – zu Snacks und Getränken – die Experten jedes Themengebietes befragen oder mit anderen Teilnehmern diskutieren. Hier kann von den Teilnehmern auch unverbindlich und individuell ein eigenes Thema vorgeschlagen werden.
Durch das halbe Jahrhundert, das inzwischen Software entwickelt wird, zieht sich ein überraschendes Phänomen: Wir, die Entwickler und Architekten, haben nicht nur immer wieder neue Technologien und Architekturansätze in die Welt gesetzt, sondern wir haben Methoden und Vorgehensweisen erdacht, die über das reine Programmieren von Software hinausgehen. Weil das ingenieursmäßige Wasserfallmodell für Softwareentwicklung nicht passt, haben wir die Projektleiter und Manager mit agiler Softwareentwicklung überrascht. Weil die Trennung von Betrieb und Entwicklung viel zu schwerfällig ist, versuchen wir DevOps zu etablieren. Weil Pflichtenhefte und UserStories die eigentlichen Bedürfnisse der Anwender nur unzureichend berücksichtigen, bringen wir mit Domain-Driven Design die Anwender, Business Analysten und uns selbst wieder dichter zusammen. Gleichzeitig versuchen wir zusammen mit Designern nicht nur schöne, sondern auch verwendbare Software zu entwickeln und aus Designern werden Interaktionsdesigner. Und schließlich zeichnet sich am Horizont ab, dass wir zum Thema Digitalisierung den Digitalisierungsbeauftragten eine ganze Menge zu sagen haben, weil wir eben seit Jahrzehnten Digitalisierung betreiben.
Hier stellen die Trainer, deren Workshops im Anschluss folgen, den Inhalt ihrer Workshops vor. Diese kurze Einführung soll den Teilnehmern dabei helfen, sich für einen Workshop zu entscheiden.
Fortschritte bei Algorithmen und Hardware haben neuronalen Netzen in den vergangenen Jahren neue Einsatzfelder eröffnet. Dieser Workshop richtet sich an Architekten, die einen Überblick über die Grundlagen, Einsatzmöglichkeiten und Frameworks für die Implementierung maschinellen Lernens mit neuronalen Netzen erhalten möchten.
Es werden Anwendungsbeispiele aus den Bereichen Bilderkennung, Zeitreihenanalyse und Spachverarbeitung vorgestellt. Der Teilnehmer erhält eine Einführung in verbreitete ML-Frameworks TensorFlow, PyTorch und Caffe.
Glaubt man den Analysten, dann ist Serverless das „next big Thing“. Eine einzelne Severless Function zu implementieren und produktiv zu stellen ist dank NoOps-Ansatz denkbar einfach. Nur leider macht ein Frühling noch keinen Sommer und eine einzelne Serverless Function noch keinen sinnvollen Anwendungsfall oder gar eine sinnvolle Anwendung! Um an Ende nicht im Chaos zu versinken, benötigt auch eine auf Serverless Functions basierende Anwendung eine Architektur und die Verwendung von Patterns.
Im Rahmen des Workshops werden wir uns verschiedene Anwendungsszenarien für Serverless Functions anschauen und für diese passende Architekturansätze entwerfen. Wir werden dabei natürlich auch dem einen oder anderen Stolperstein begegnen. Aber das kann uns nicht aufhalten.
Funktionale Sprachen sind ideal geeignet, um Domain-driven Design umzusetzen. Wir zeigen, wie die wichtigsten taktischen Elemente von DDD (Entitäten, Wertobjekte, Aggregate, …) in funktionalen Sprachen umgesetzt werden und von diesen profitieren. Das funktionale Programmierparadigma unterstützt DDD durch seine erweiterten Abstraktionsmöglichkeiten und Typsysteme in besonderem Maße und führt gegenüber den üblichen OO-Sprachen zu lesbarerem und leichter wartbarem Code. Natürlich bieten funktionale Sprachen auch eine hervorragende Unterstützung zur Modularisierung des Codes auf der Makroebene (Stichwort “Bounded Contexts”). Auch darüber geben wir einen Überblick.
Wir werden für die Code-Beispiele die funktionale Sprache Haskell verwenden - für Haskell-Neulinge führen wir am Anfang in die für den Workshop relevanten Teile ein.
Hier stellen die Trainer, deren Workshops im Anschluss folgen, den Inhalt ihrer Workshops vor. Diese kurze Einführung soll den Teilnehmern dabei helfen, sich für einen Workshop zu entscheiden.
Der agile Hype ist vorbei. DevOps hat das Ruder übernommen, getrieben von der Notwendigkeit, IT ganzheitlich zu beschleunigen, ohne die Zeche in Produktion zahlen zu müssen. Gleichzeitig verwandelt die 2. Welle der digitalen Transformation IT-Systeme in Kernbestandteile unserer Geschäftsmodelle.
In einem solchen Umfeld ist gute Architekturarbeit essentiell. In der Praxis sehen wir aber häufig ein eher zufälliges Vorgehens-Potpourri, vom klassischen BDUF über Hype- und Silberkugel-Architekturen bis hin zum dogmatischen, pseudo-agilen "Null Architektur".
Jetzt geht es bei Architektur um die Entscheidungen, die richtig weh tun, wenn man sie falsch trifft. Aber wie können wir das Schmerzrisiko minimieren, insbesondere wenn es schnell gehen muss? Was ist denn das richtige Vorgehen?
In diesem Workshop betrachten wir zuerst die Herausforderungen von Architekturarbeit in einer post-agilen IT Welt. Danach werden wir ein überraschend einfaches und bodenständiges Vorgehen für moderne Architekturarbeit definieren, das wir dann Schritt für Schritt mit Leben füllen - Diskussionen, Tipps, Tricks und Fallstricke inklusive.
Am Ende des Workshops werden wir keine weitere Silberkugel gegossen haben - die gibt es eh nicht. Aber Sie werden ein deutliches klareres Verständnis haben, worum es bei Architekturarbeit heute geht, was wichtig ist, was nicht und wie man es in der Praxis umsetzen kann.
„Funktionierende Software ist wichtiger als umfassende Dokumentation“ – so lautet eines der vier Werte-Statements des Manifests für Agile Softwareentwicklung. In diesem Workshop werden wir darüber reden, wann Dokumentation uns Wert bringt, und wann vielleicht nicht. Besonderer Fokus liegt hier auf der Kommunikation in einem agilen Team.
Themen werden sein:
• Know your audience: “Personas”
• Klarheit erlangen darüber, was man mit Dokumentation erreichen möchte
• Typen von Dokumentation
• Balance zwischen Struktur und Chaos
• Dokumentations-”Auslöser”: Zeichen, dass etwas dokumentiert werden sollte
Idealerweise haben die Teilnehmer ein konkretes Team im Kopf, für das sie ein Dokumentationskonzept erarbeiten wollen.
Event Storming bedeutet effektives und gemeinsames Modellieren von komplexen Geschäftsprozessen. Doch wie geht das in der Praxis? Und woher wissen wir, ob unser Modell der Realität standhalten wird?
Mit Post-Its, Stiften und viel freier Fläche entwickeln wir zunächst gemeinsam ein repräsentatives Modell des Prozesses, unser Domänenmodell. Dabei finden wir ein gemeinsames Verständnis der Domäne anhand von realen Schlüssel-Ereignissen (Events) und suchen dann nach natürlichen Modellgrenzen um unser Domänenmodell zu partitionieren.
Das Ergebnis ist ein implementierungsnahes Modell, das die fachlichen Erfordernisse beinhaltet und die Zusammensetzung des Systems nach Domain Driven Design (DDD) vorbereiten.
Gemeinsam mit Euch evaluieren wir in diesem Workshop, wie sich die Methode im Kontakt mit der Realität schlägt. Dazu überprüfen wir unser bereits erarbeitetes Modell aus Sicht des Endnutzers und kritischer Domänen Experten um es entsprechend zu verfeinern. Darüber hinaus werden wir versuchen unser eigenes Modell zu sabotieren, um so Inkonsistenzen und Reibungspunkte zuverlässig zu entdecken und die fachliche Korrektheit zu verbessern.
Wir zeigen euch, wie Event Storming als Wegbereiter für Domain Driven Design fungiert und geben Euch Tipps für den Einsatz im eigenen Unternehmen.