Wer sich mit Architektur beschäftigt, kennt die Herausforderung, die richtige Balance zwischen zwei extremen Positionen herzustellen. So gilt auch bei der Frage, ob ein zentralistischer oder ein dezentraler Ansatz für einen gegebenen Satz an Anforderungen die bessere Lösung ist, dass es nicht nur eine Schwarz/weiß-, sondern auch eine Graustufenlösung gibt. In diesem Vortrag werden wir die Problematik anhand einiger konkreter Beispiel diskutieren und versuchen, Entscheidungshilfen herauszuarbeiten.
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.
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.
Nicht-manuelle Tests stellen die Qualität einer Softwarelösung auf effiziente Weise sicher und sind Standard in der Software-Entwicklung. Auch weil die Automatisierung in der Regel zu Fehlern und anderen Unschönheiten früher Rückmeldung gibt. Der Ansatz ist auf verschiedenen funktionalen Ebenen gängig — Unit-Tests, Modul-Tests, Integrationstests...
Wäre es nicht toll, auch Aspekte Eurer Softwarearchitektur automatisch testen zu können? Was heißt es überhaupt, Eure Architektur zu testen? In diesem Workshop diskutieren wir zunächst kurz verschiedene Ansatzpunkte und Möglichkeiten dazu. Und wir räumen mit Mythen und Missverständnissen auf. So ist eine Überprüfung, ob eine Implementierung bestimmte Vorgaben einhält, zwar für einzelne Aspekte problemlos möglich, wenn aber die Vorgaben nichts taugen ist das Ergebnis gleichzeitig uninteressant (und die Tests sind Verschwendung). Konsequenterweise konzentrieren wir uns anschließend auf effektive Ansätze aus dem Chaos Engineering und Fitness Functions. Denn diese können bei richtiger Anwendung die Wirksamkeit Eurer Architekturansätze langfristig absichern. Sie erlauben zudem eine zielgerichtete Weiterentwicklung Eurer Softwarelösung. Anders als typische Literatur über Evolutionäre Architekturen hören wir nicht da auf, wo es konkret wird, sondern zeigen Real World-Beispiele und Implementierungsoptionen im Freiflug. Interaktive Elemente und die Anwendung der Konzepte auf Eure Softwarelösungen runden den Workshop ab.
Um Software zu konstruieren, müssen wir unsere Domäne und ihre Sprache verstehen. In diesem Workshop zeigen wir, wie man mithilfe der Collaborative Modelling Tools von Event Storming und Domain Storytelling dieses Verständnis aufbauen und dann in konkrete Software umsetzen kann. Event Storming bedeutet, dass Entwickler und Anwender mit haufenweise Klebezetteln ausgerüstet aufeinandertreffen. Der Schwerpunkt wird dabei zunächst auf die Domain Events gelegt, also das, was in der Fachlichkeit geschieht. Weil die Methode so leichtgewichtig ist, fokussiert sie uns das, was wirklich wichtig ist: weg von Technologie und Werkzeugen hin zur Domäne. Domain Storytelling heißt, dass wir Domänenexperten und Entwickler zusammenbringen. Wir lassen sie uns Geschichte über ihre Domäne erzählen. Während wir zuhören, zeichnen wir die Domain Stories vor den Augen der Fachexperten mit einer Bildsprache auf. Dadurch können alle Beteiligten unmittelbar sehen, ob sie richtig verstanden wurde. Schon nach wenigen Domain Stories haben wir die wesentlichen Akteure, Aufgaben, Werkzeuge, Arbeitsgegenstände und Ereignisse einer Domäne herausgearbeitet.
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.
Beim Entwurf größerer Anwendungen liegen vertikale Architekturstile wie Microservices und Self-contained Systems im Trend. Sie erlauben eine konsequente Aufteilung nach Fachlichkeit und ermöglichen, dass sich mehrere Teams voll auf „ihr" Thema konzentrieren können. Der Schnitt geht dann gleichzeitig glatt durch die Oberfläche. Das wirft die Frage nach einer geeigneten Frontend-Architektur für Eure Anwendung auf. Oft steht dann der Wunsch nach einer Single-Page Application auf Basis moderner JavaScript-Technologien wie React oder Angular im Raum.
Welche Fragestellungen rund ums UI solltet ihr im Vorfeld klären? Hier lernt ihr darüber hinaus auch die gängigen Antworten. Und wie ihr entscheidet! Anhand von typischen Anforderungen an ein SPA-Projekt gehen wir durch die Auswahl des Frameworks (oder keines), zeigen wie ihr einen Anwendungsteil in Komponenten aufteilt und diese zusammensetzt. Für eine Anwendung im größeren Stil sehen wir uns dann an, wie ihr eine SPA in möglichst unabhängige Teile zerlegen und dann wieder zu einem möglichst konsistenten ganzen zusammenführen könnt. Auch über Team-Grenzen hinweg.
Kurz: In diesem interaktiven Workshop lernst du als Teilnehmer einen Prozess kennen, mit dem du die Anforderungen einer SPA erfasst und dazu auf nachvollziehbare Weise die passende Architektur bestimmst. Nie wieder das UI einfach oben draufklatschen.
Softwareentwicklung ist Modell-Bildung. Wir bauen einen Teil der Wirklichkeit als Programm nach und verbessern sie so. Ein traditioneller Ansatz ist, die Domäne als Ganzes möglichst detailgetreu nachzubilden. Aber ist das eigentlich der Zweck von Modellen? Wenn wir genau hinschauen, bemerken wir, dass ein Modell eigentlich genau das Gegenteil ist – Ein Modell ist nämlich eine Abstraktion der Wirklichkeit, in die nur das Wesentliche übertragen und das Unwesentliche weggelassen wird. Was wesentlich und was unwesentlich ist, ergibt sich aus dem Kontext. Ein einfaches Modell ist leichter zu verstehen als ein kompliziertes. Deshalb ist es eine gute Idee, von einer komplizierten Wirklichkeit mehrere einfache (und einfach verständliche) Modelle zu bilden. Genau diesen Effekt machen sich Microservices und DDD mit seinem Strategisches Design zu Nutze. Hier werden statt dem einen großen unternehmensweiten Modell, mehrere kleine gut verständliche Modelle gebildet. In diesem Workshop betrachten wir, welche Mittel uns zur Verfügung stehen, um gute Modelle zu bauen und die Domäne so aufzuteilen, dass wir auch mit mehreren sinnvoll und unabhängig arbeiten können.
Der agile Hype ist vorbei und hat seine Spuren hinterlassen. Schauen wir auf Architekturarbeit, dann finden wir uns in einem großen Durcheinander an Meinungen und Empfehlungen ohne klare Richtung wieder. Jetzt heißt es ja, dass es bei Architektur um die Entscheidungen geht, die richtig wehtun, wenn man sie falsch trifft. Wie aber können wir das Schmerzrisiko minimieren?
In diesem Workshop erzeugen wir zunächst einmal eine klare Richtung, indem wir (wieder-)entdecken, warum wir Architekturarbeit überhaupt benötigen. Nach dem Diskutieren der Herausforderungen von Architekturarbeit in einer post-agilen IT-Welt werden wir dann ein überraschend einfaches und bodenständiges Vorgehen für moderne Architekturarbeit definieren. Dieses werden wir anschließend Schritt für Schritt mit Leben füllen.
Zuletzt werden wir die folgenden Fragen diskutieren und so das entstandene Bild vervollständigen: Wann sollten wir was tun? Wie viel sollten wir unter welchen Rahmenbedingungen tun? Wie können wir eine nachhaltige Architektur gestalten und wo sind die Grenzen?
Am Ende des Workshops werden wir kein Architektur-Patentrezept erstellt haben. Aber Sie werden ein deutliches klareres Verständnis haben, worum es bei Architekturarbeit eigentlich geht, was wichtig ist, was nicht und wie man es in der Praxis umsetzen kann.
We so often consider constraints to be a negative. We have become convinced that they stop us doing what we want and that, therefore, they prevent us from being our most creative. But constraints are actually the most beautiful thing in the world. Constraints are what give us direction. Constraints are what give us focus. Constraints are what give us empathy. In this talk Charlie will tell us how constraints are something that should be sought out and embraced, especially in the infinite chaos of the web.
Moving from monolithic systems to microservices introduce us to a new set of challenges for both development and operational teams.
How would we prevent a major outage? How would you plan your system capacity and How would you act in a disaster? Join me to discover more about the solutions for resiliency for both infrastructure and applications.
Have you seen those three dimensional modern art installations that look like a complete mess until you see it from the correct angle and a nice picture emerges?
Software can be like that. What might look like a mess from one angle, is beautiful from a different one.
“We’ve got too many applications!”, “Just look at this architecture diagram! Lines all over the place”, “It’s a mess!”
These are common complaints from architects and developers alike in large organisations with software that performs all sorts of different tasks. But are we looking at the diagram from the correct angle?
At university we were taught that good software needs to have loose coupling and high cohesion. But what does that mean? Without an understanding of what cohesion really is, or what should be loosely coupled, we all too often end up with applications where the solution is no longer coupled to the problem. Applications where the diagrams might look nice, but are very impractical to work with, or make it hard to create good user experiences.
Christin will present some examples and discuss how to reason about large software portfolios., go through which parts go together and which ones can or should be decoupled, and help identify that angle that gives us the best view of our systems.
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.
„You build it, you run it“ ist der Leitspruch, um die Verantwortung für einzelne Microservices in die Hände der Entwicklungsteams zu legen. Aber wo bleibt bei diesem Ansatz die globale Architektur? Wie passen Querschnittsaspekte in dieses Konzept.
In diesem Workshop wird erarbeitet, welche globalen architektonischen Vorgaben in Mikroservice-Architekturen notwendig und welche ggf. sinnvoll sind. Außerdem werden Techniken vorgestellt, wie diese in der Praxis sichergestellt werden können und wie trotz decentralized Governance der Überblick über die existierenden Microservices behalten werden kann.
Dabei werden wir verschiedene Themen wie z.B. Consumer-Driven Contracts auch in der Praxis ausprobieren. Die Teilnehmer benötigen dazu einen Laptop auf dem sich eine Docker-Installation befindet.
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.
Die Verwendung von Microservices hat sich als ein moderner, flexibler und skalierbarer Architekturstil etabliert. Was aber bei neuen Projekten einfach umzusetzen sein mag, ist für Legacy-Systeme eher Traum als Realität. Zu groß sind die Hürden, einen Monolithen überhaupt auf einen Stand zu bringen, auf dem es sinnvoll ist, über eine Zerlegung nachzudenken.
Der Workshop nimmt die Teilnehmer auf eine Reise, auf welcher eine reales, in Java implementiertes monolithisches E-Commerce-System getrieben durch geschäftliche Anforderungen schrittweise in eine Microservices-Struktur überführt wird. Dabei werden interaktiv typische Probleme aufgedeckt, Lösungsansätze sowie ihre Anwendbarkeit diskutiert und natürlich auch umgesetzt.
„You build it, you run it“ ist der Leitspruch, um die Verantwortung für einzelne Microservices in die Hände der Entwicklungsteams zu legen. Aber wo bleibt bei diesem Ansatz die globale Architektur? Wie passen Querschnittsaspekte in dieses Konzept.
In diesem Workshop wird erarbeitet, welche globalen architektonischen Vorgaben in Mikroservice-Architekturen notwendig und welche ggf. sinnvoll sind. Außerdem werden Techniken vorgestellt, wie diese in der Praxis sichergestellt werden können und wie trotz decentralized Governance der Überblick über die existierenden Microservices behalten werden kann.
Dabei werden wir verschiedene Themen wie z.B. Consumer-Driven Contracts auch in der Praxis ausprobieren. Die Teilnehmer benötigen dazu einen Laptop auf dem sich eine Docker-Installation befindet.
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.
Die Verwendung von Microservices hat sich als ein moderner, flexibler und skalierbarer Architekturstil etabliert. Was aber bei neuen Projekten einfach umzusetzen sein mag, ist für Legacy-Systeme eher Traum als Realität. Zu groß sind die Hürden, einen Monolithen überhaupt auf einen Stand zu bringen, auf dem es sinnvoll ist, über eine Zerlegung nachzudenken. Der Workshop nimmt die Teilnehmer auf eine Reise, auf welcher eine reales, in Java implementiertes monolithisches E-Commerce-System getrieben durch geschäftliche Anforderungen schrittweise in eine Microservices-Struktur überführt wird. Dabei werden interaktiv typische Probleme aufgedeckt, Lösungsansätze sowie ihre Anwendbarkeit diskutiert und natürlich auch umgesetzt.
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.
If your mobile phone is in silent/vibrate mode right now, would you say that you're using an accessibility feature, or just a feature of your phone? If you've ever adjusted the size of onscreen content by pinching or stretching, do you feel like you have a disability, or are you simply using your phone as it was meant to be used? In this keynote, Scott Davis (Principal Engineer and Web Architect, ThoughtWorks) discusses Universal Design, in which we design features for everyone to use, not just an arbitrary subset of our users. Granted, over 1 billion people across the world have some form of disability - that's between 15% and 20% of the planet. And the top 1 million websites average over 60 accessibility errors per page - that's one error for every 13 elements on the page. So yes, we as an industry have quite a bit of work to do to support the 20% of our users that need our accessibility efforts the most. But if you have plans to add a Conversational UI (like Siri, Alexa, or Cortana) to your product, is your plan to limit that interface to only your blind and low-vision users, or is it something that you hope all of your users will enjoy?
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.
Your web browser doesn't have a cute name like Alexa, Siri, or Cortana, but it can be just as talkative. Your smartphone, with a built-in speaker and microphone, is a perfect device for building a browser-based Conversational UI. In this workshop, Scott Davis demonstrates how easy it is to build a Conversational UI in a web app. Without downloading a single third-party library, you'll learn how to leverage the native browser capabilities for text-to-speech and speech-to-text. These W3C standards have been in place for years - now it's time for you to take advantage of these stable, ubiquitous APIs in your own web app. Our primary focus will be on leveraging the Web Speech API, with an emphasis on naturally integrating the SpeechSynthesis and SpeechRecognition components into a web application.
Inzwischen wissen wir, Microservices sind kein free lunch. Der Service-Schnitt macht sich nicht von selbst, und wenn man einen gefunden hat, müssten die Services doch wieder integriert werden. Das wirft Fragen zur Authentisierung, Autorisierung, den Integrationsprotokollen und ganzheitlichen Monitoring-, Log- und Tracing-Konzepten auf, die beantwortet und implementiert werden müssen. All diese Funktionen, die wir rund um unsere Microservices „nebenbei“ implementieren, haben ein wenig Überhand genommen. Genau das verspricht ein Service Mesh zu ändern. Es hebt Monitoring, Resilienz, Routing und Sicherheit in die Infrastruktur. In diesem Workshop erfahren Sie, wie ein Service Mesh das macht und was der Preis dafür ist. Wir werden konkrete Technologien (z.B. Istio) und verschiedene Anwendungsfälle für Service Meshes diskutieren.
Der Workshop wird von mittlerem Schwierigkeitsgrad sein und Praxiserfahrung mit Kubernetes voraussetzen. Die Teilnehmenden brauchen einen eigenen Rechner.
Im Domain-driven Design dreht sich vieles um die direkte Zusammenarbeit zwischen fachlichen Experten und Entwickler(inne)n. Jedoch gestaltet sich diese Kollaboration in der Praxis häufig schwieriger als sie initial auf dem Papier erscheint. Die technischen Mitarbeiter(innen) werfen zu schnell mit UML und Fachbegriffen um sich und/oder die Fachbereiche schieben die Verantwortung an Designentscheidungen für ihre (meist digitalen) Produkte mit dem Satz „das ist IT, darum sollen die sich kümmern“ von sich weg. Im Laufe der Zeit haben sich jedoch inner- und außerhalb der Domain-driven-Design-Community einige Methoden entwickelt, die genau diese Zusammenarbeit vereinfachen sollen und um genau diese Methoden dreht sich der Workshop. Ziel ist es, Ihnen in den drei zur Verfügung stehenden Stunden einen Überblick über Methoden wie Domain Storytelling, Event Storming, User Story Mapping und Example Mapping (aus dem Behavior-driven Development) zu geben. Selbstredend hat der Workshop nicht den Anspruch, jede der Methoden im Detail vorzustellen. Es geht primär um die Vermittlung eines Überblicks und um die Eignung bzw. die Vor- und Nachteile dieser Ansätze.
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.
Wer kennt sie nicht aus seinem beruflichen Alltag: tödlich langweilige, mit Details überhäufte PowerPoint Präsentationen, die die Zuhörer und Leser mit Bullet-Point Wüsten in den Schlaf treiben und primär der Selbstbeweihräucherung des Referenten dienen? Anders gefragt: wer ist als Entwickler*in oder Architekt*in schon einmal mit einer Präsentation, in der man seinem Management eine tolle neue Technologie schmackhaft machen wollte, an eine Wand gelaufen weil man einfach nicht die richtigen Worte fand um Zugang zur Führungsebene zu erhalten?
Dabei ist das Erstellen guter Präsentationen oder das Strukturieren einer schlüssigen Argumentation kein Hexenwerk, welches nur Unternehmensberatern oder Design Spezialisten vorbehalten ist. Jede*r kann gute Präsentationen erstellen. Stellen wir einmal das Layout und Design der Folien zurück, werden wir erkennen, dass die Basis eine solide Story und eine gute Argumentations-Kette sein muss. Genau an dieser Stelle setzt dieser Workshop an und vermittelt Ihnen ein einfaches Vorgehen mit dem Sie zielgerichtet ihre Argumentationen und Präsentationen strukturieren und verbessern können. Dabei werden folgende Themen vermittelt:
- Analyse der Zielgruppe
- Aufbau einer Storyline
- Nutzung bewährter Argumentationstechniken
- Hinweise zum Aufbau und Design von Folien
- Tipps und Tricks für Vorbereitung und Durchführung von Präsentationen vor Publikum
Der Schwerpunkt des Workshops sind Argumentationen und Präsentationen im geschäftlichen Alltag, allerdings werden auch Hinweise für öffentliche Präsentationen auf Konferenzen oder Meetups eingestreut.
In diesem Workshop beschäftigen wir uns mit der Architektur der Ethereum-Blockchain und allem was dazu gehört. Der Schwerpunkt liegt auf dem tiefgreifenden Verständnis von Smart Contracts und wo sich deren Entwicklungsmethoden vom klassischen Software Engineering abheben. Natürlich wird es auch ein Blick auf Ethereum-Varianten und zukünftige Entwicklungen geben. Der Workshop ist geeignet für Menschen, die vorher schon einmal in Blockchain-Themen hereingeschnuppert haben und an der Entwicklung von Smart Contracts interessiert sind. Und keine Sorge, Bugs in den live entwickelten Verträgen gefährden nur Testgeld, keine echte Kryptowährung.
Bei DDD orientiert sich der Code eng am Modell, um Erkenntnisse zur Domäne zu reflektieren. Die besten Modelle machen tiefe Einsichten in die Domäne sichtbar. Aber wie generieren wir tiefe Einsichten? Die Kombination von DDD und funktionaler Programmierung macht einen besonders effektiven Ansatz möglich, "Denotational Design" (der Begriff wurde von Conal Elliott geprägt): Wir entwickeln ein Modell als Code und betrachten dieses losgelöst von der Domäne. Dann erhöhen wir den Abstraktionsgrad durch Refaktorisierung und suchen nach mathematischen Eigenschaften, die oft erstaunliche - tiefe - Einsichten in die Domäne liefern. Wer gelernt hat, diese Eigenschaften zu erkennen, kann nicht nur neues Domänenwissen aus der Luft zaubern, sondern auch auf die reichhaltigen Libraries zurückgreifen, die funktionale Sprachen dafür bieten. Diese wiederum erleichtern die Lösung komplexer Probleme in der Architektur. Der Prozess ist systematisch, nachvollziehbar und allgemein anwendbar.
Die dazugehörigen Begrifflichkeiten sind zwar abstrakt, aber nicht komplex - und darum auch nicht so schwer zu erlernen, wie manche Unkenrufe behaupten. Der Vortrag führt in DDDD ein sowie die nötigen mathematischen Konzepte. (Schulmathematik reicht als Voraussetzung.)