Track: Vortrag
- Mittwoch
06.10. - Donnerstag
07.10.
Die Architektur von modernen Softwaresystemen muss sich ständig anpassen an geänderte Benutzerbedürfnisse, Technologieänderungen und neue technische Möglichkeiten. Einfachheit – Simplicity – ist dabei bei weitem der wichtigste Faktor, um die Evolution der Softwarearchitektur zu unterstützen.
In diesem Vortrag zeige ich euch ein Modell, um über Architektur-Einfachheit zu reflektieren und mehrere Techniken und Prinzipien um die Softwarearchitektur so simpel wie möglich zu gestalten, wie Continous Refactoring, Entscheidungs-Dekomposition und konkrete, spezifische statt abstrakte, generische Designs.
Zielpublikum: Architekten, Entwickler
Voraussetzungen: Grundwissen zu Softwarearchitektur
Level: Advanced
The promise of APIs is to increase collaboration and innovation by making it easier for teams to reuse existing facilities. The reality of many API initiatives is that teams have difficulties identifying what APIs to build, and that teams also have difficulties finding and understanding APIs. The concept of API stories is similar to that of user stories as an informal description of capabilities of a software component, but the focus is on an application as the component user. API stories help producing teams to think with consumers and product value in mind, and allow consuming teams to understand the value that is being exposed through an API. Using API stories is a path to better API design and documentation because they make it easy to communicate about an API's value proposition.
Aims at: Architects, Enterprise Architects, Product Managers, API Platform Owners, API Developers
Prerequisites: A basic understanding of APIs, but we will not go into the details of API technologies and descriptions
Level: Basic
In Softwareentwicklung und -architektur haben sich viele Muster etabliert, die der domänengetriebenen Entwicklung (dem DDD) entstammen. Die soziologische Systemtheorie nach Luhmann fokussiert auf Kommunikation, und bringt neue Sichtweisen in die Prozesse: Unabhängiges Beobachten ist unmöglich, Realität ist immer die Konstruktion des Beobachters!
Dies hat Einfluss darauf, wie das Gesetz von Conway verstanden werden kann, und wie relevante Kommunikation zwischen Anwendergruppen und nachrichtengetriebene Softwarelösungen zusammenspielen können. Die Kombination dieser abstrakt erscheinenden Theorien hat ganz konkrete Konsequenzen auf Anforderungsfindung, agile Vorgenhensweisen und die Zusammenarbeit von Teams in der Softwareentwicklung. Ziel ist die Verbesserung der Anwenderzufriedenheit.
Zielpublikum: Requirements Engineers, Softwareentwickler und -architekten, Scrum Master und Product Owner
Voraussetzungen: Keine besonderen Vorkenntnisse nötig; Projekterfahrung mit agilen Methoden ist hilfreich
Level: Advanced
Ebenso wie klassische Software-Entwicklung ist Machine Learning eine Art, Software zu entwickeln. Dazu braucht es nach wie vor Software-Entwickler, und Software-Architektur nur mit anderen Fähigkeiten und anderen Grundsätzen.
Andrej Karpathy, Director of AI bei Tesla, hat dafür den Term Software 2.0 geprägt, der sich seitdem etabliert hat und weiter ausgearbeitet wurde. In diesem Talk erläutere ich einige überraschende Eigenschaften dieser Art der Software-Entwicklung wie 'konstante Laufzeit', 'natürliche, hochgradige Parallelisierbarkeit' und 'übermenschliche Leistung'.
Zielpublikum: Alle Teilnehmer, die sich für Softwareentwicklung und dessen Zukunft interessieren
Voraussetzungen: Keine
Level: Basic
Oliver Zeigermann ist Softwareentwickler und -architekt aus Hamburg und hat seit mehr als drei Jahrzehnten Erfahrungen in der Software-Entwicklung gesammelt. Seine Spezialgebiete sind Frontend-Entwicklung und maschinelles Lernen. Er ist Autor mehrerer Videokurse und Fachbücher.
Vortrag Teilen
Eine der größten Herausforderungen von Microservices ist es, den Überblick über die Gesamtarchitektur zu bekommen und zu behalten. Welcher Service spricht eigentlich mit welchem? Wie kann ich sicherstellen, dass die Kommunikationswege der geplanten und dokumentierten Architektur entsprechen? Und welche Version eines Services ist eigentlich auf welcher Stage deployed? Wie kann ich automatisiert sicherstellen, dass die deployten Versionen der Services zueinander passen?
Mit Live-Demos wird gezeigt, wie Consumer-Driven Contracts, Tracing Server und Service Meshes eingesetzt werden können, um Architekturen zu visiualisieren und Vorgaben sicherzustellen.
Zielpublikum: Architekten, Entwickler, Projektleiter
Voraussetzungen: Projekterfahrung in service-orientierten Architekturen
Level: Advanced
Funktionaler Softwarearchitektur hat vielfältige Vorteile: Weniger Komplexität, weniger Kopplung, bessere Domänenmodelle. Toll wäre das natürlich im aktuellen Softwareprojekt, aber das ist ja meist objektorientiert-imperativ mit Java oder C# entwickelt. Ist es möglich, auch da von funktionalen Ansätzen zu profitieren? (Ja!) Und wie geht das am besten? Den funktionalen Ansatz in den alten Sprachen umsetzen? Alles wegwerfen und neu schreiben? Rapid Prototyping mit FP und dann doch wieder Java? Einfach mit Scala oder F# weiterprogrammieren? Erstmal umfangreich refaktorisieren? Meist gibt es einen inkrementellen Ansatz, der sich schnell amortisiert, aber der jeweils beste Weg hängt vom konkreten Projekt und vom Team ab. Der Vortrag greift Beispiele aus realer Projekterfahrung auf, zeigt in was für Situationen sich der Umstieg auf FP lohnt und wie ihn Softwarearchitekten und Entwickler am besten umsetzen.
Der Trend zu hochskalierenden Cloud-Anwendungen, die stark auf datengetriebene Features setzen, ist ungebrochen. Dadurch laufen immer mehr Anwendungen nur noch unter Eventual Consistency. Nebenläufige Änderungsoperationen auf inkonsistenten, replizierten Datenbeständen können allerdings zu schweren Replikations-Anomalien wie Lost Updates führen. Das Implementieren korrekter Merge-Logik im Fall von Schreibkonflikten ist eine große Fehlerquelle und selbst für sehr erfahrene Software-Architekt:innen eine Herausforderung. Basierend auf unseren Erfahrungen aus verschiedenen Kunden- und Forschungsprojekten entwickeln wir Architektur-Empfehlungen und Entwurfsmuster für das Design von Anwendungen, die unter Eventual Consistency laufen. Parallel treiben wir die Entwicklung eines Open-Source-Replikations-Frameworks, welches unsere Methoden unterstützt, voran. Der Vortrag gibt konkrete Hilfestellungen für Architekt:innen und beinhaltet eine Demo-Session.
Single-Page-Applications -ursprünglich als kleines fancy Frontend gestartet- sind in den letzten Jahren zu großen, schwergewichtigen eigenen Applikationen angewachsen, die fehleranfällig, schwer wartbar und langsam in der Weiterentwicklung sind. Aber woran liegt das eigentlich? Im Frontend gibt es als Abstraktion zumeist nur das Konzept der Komponenten. Eine tiefergehende Analyse der benötigten Bausteine bleibt in der Regel aus. Im Backend hingegen, erfolgen solche Analysen seit Jahren.
Aber lassen sich die Backend-Architektur-Konzepte ohne weiteres für das Frontend übernehmen? Was sind die Herausforderungen, in denen sich moderne Frontends von klassischen Backends unterscheiden? Wo braucht man daher andere Lösungen? Neben der Problemanalyse gibt dieser Talk konkrete Bausteine an die Hand.
Zielpublikum: (Frontend)Entwickler, Architekten
Voraussetzungen: Erfahrung mit Single-Page-Applications von Vorteil
Level: Basic
Vortrag Teilen
In unseren Audits identifizieren wir die größten Herausforderungen für die Zukunftsfähigkeit von Softwaresystemen. Das Spektrum reicht dabei von der öffentlichen Verwaltung über DAX-Konzerne und Startups bis zur Kirche. Dabei begegnen uns immer wieder Probleme, die zwar abstrakt bekannt sind, aber auch uns in ihrer konkreten Ausprägung immer wieder überraschen. In diesem Vortrag teilen wir diese Erfahrungen aus der Praxis.
Wir beschäftigen uns unter anderem mit Zoos an Programmiersprachen, Vintage Technologie-Stacks und flachen Hierarchien in der Architektur. Wir treffen aber auch auf kreative Wiederverwendung und den Optimismus, dass bestimmter Code nie ausgeführt wird. Dabei zeigen wir, wie man diese Herausforderungen identifiziert und adressiert, oder noch besser, direkt vermeidet.
Zielpublikum: Architekten, Entwickler, Projektleiter, Manager, Entscheider - alle die wissen wollen was die Zukunftsfähigkeit von Software in der Praxis beeinträchtigt
Voraussetzungen: Keine besonderen Fachkenntnisse. Aber Spaß an Erfahrungen und Anekdoten aus der Praxis
Level: Basic
Wann darf ich Open Source-Software nutzen, wann muss ich meinen Source Code ebenfalls veröffentlichen? Wie verstehe ich die Vielzahl an Lizenzen und welche Feinheiten gilt es zu beachten? Haften ich oder mein Unternehmen für die eingebundene Software? Und wer kennt das nicht: In Stack Overflow steht die Lösung für mein Problem, also füge ich das Codebeispiel ein - nur, darf ich das überhaupt?
Der Vortrag gibt einen für Laien gut verständlichen Einblick mit detaillierten rechtlichen und technischen Hintergründen, Fragen in der Haftung, in lizenz- und urheberrechtliche Fragestellungen wie auch der prozessualen Einbindung in den Entwickler- und Unternehmensalltag in Build-Pipelines mit Lösungen wie Blackduck, WhiteSource & Co. Außerdem werden Open Chain und Oracle vs. Google beleuchtet.
Zielpublikum: Entwickler, Projektleiter, Manager, Architekten
Voraussetzungen: Projekterfahrung sinnvoll
Level: Advanced
Softwarearchitekturen entwickeln sich über verschiedene Systeme hinweg weiter. Weiterentwicklung betrifft meistens nicht nur die Technik, sondern auch die (Team/Projekt-) Organisation und deren Fähigkeiten.
In diesem Vortrag stellen wir Wardley Maps - evolvierende Strategielandkarten - vor und wie sich diese in der Weiterentwicklung von komplexen Softwaresystemen pragmatisch einsetzen lassen.
Wardley Maps helfen bei der Entscheidungsfindung sowie der Kommunikation der eingeschlagenen Strategien und den gewählten Lösungsansätzen: Welche Entwicklungspraktiken einsetzen? Auf welche Technologie umstellen? Make or Buy?
Anhand eines Praxisbeispiels entsteht während der Session eine Map, die kritische Entscheidungspunkte im Projekt zeigt, Hindernisse benennt und die Strategie kommuniziert.
Eine sauber Architektur entwirft man am besten für Greenfield-Projekte. Das Leben besteht aber eher aus Legacy-Systemen und eine Architektur muss sich evolutionär anpassen - sonst wird sie auch sehr schnell zu Legacy. So wird Greenfield zur Ausnahme.
Dieser Vortrag zeigt verschiedene Ansätze, wie man Legacy-Systeme mit Domain-driven Design verbessern kann. Dabei geht es um verschiedene Techniken zum Einführen von Bounded Contexts und die Bewertung, wo Verbesserungen notwendig sind. So wird Domain-driven Design dort möglich, wo es am dringendsten gebraucht wird - bei den existierenden Systeme, die oft aus Geschäftssicht sehr erfolgreich und kritisch sind, aber ursprünglich ohne Rücksicht auf DDD entwickelt worden sind.
Zielpublikum: Alles an Software-Architektur Interessierten - Software-Architekt:innen, technische Projektleiter:innen, Entwickler:innen
Voraussetzungen: Grundlegendes Verständnis über Software-Architektur, idealerweise Erfahrungen mit den Herausforderungen bei Legacy-Systemen
Level: Basic
Die Theorie der „Dualität von Technik“ behauptet, dass sich Technik und die Struktur der Organisation, in der sie genutzt wird, wechselseitig beeinflussen und bedingen. Prognosen sind sich einig, dass Quantencomputer in dieser Dekade ihren Durchbruch erleben werden. Damit stellt sich die Frage, was mit einer Organisation passiert, wenn Quantencomputer in den Arbeitsalltag einziehen. Dieser Vortrag stellt - ausgehend von den absehbaren Potenzialen der Quantentechnologie - Prognosen auf, wie Quantencomputer die Aufbau- und Ablauforganisation verändern könnten, was das für Unternehmen bedeutet, und wie sich eine Organisation darauf vorbereiten könnte.
Zielpublikum: Architekten, Projektleiter, Manager, Entscheider
Voraussetzungen: Keine
Level: Basic
Immer mehr Unternehmen bauen E-Commerce-Lösungen mit Vertikalisierung - doch der Teufel steckt im Detail. Welches Team verantwortet was? Wie ist das aus Gesamtarchitektursicht zu bewerten? Wie steht es um Motivation, Unterforderung, Herausforderung oder Überforderung der Teams?
Die Vertikalisierung von breuninger.com startete mit 5 Teams entlang der Customer Journey. 5 Jahre später arbeitet eine zweistellige Anzahl an Teams an der Plattform. In dieser Zeit hat sich auch unser Verständnis der Vertikalisierung weiterentwickelt: Es gibt keinen immer richtigen Schnitt, sondern nur den richtigen Schnitt zur richtigen Zeit! In diesem Vortrag teilen wir unsere Erfahrungen, Perspektiven und Methoden zur Bestimmung von Teamverantwortlichkeiten innerhalb einer vertikalisierten Facharchitektur.
Zielpublikum: Entwickler, Architekten, Manager, Entscheider, Product Owners
Voraussetzungen: Vertikalisierung als Grundidee
Level: Basic
In dieser Rolle hilft er Teams ihre Architekturen zu gestalten und in den Gesamtkontext zu integrieren. Zu seinen Leidenschaften gehöhren Clean Code, DevOps und *-as-a-Service. Vor Breuninger hat Sebastian sich bei Tipico und IBM mit Architektur, Systemintegration, verteilten Systemen und I/P/SaaS beschäftigt.
Vortrag Teilen
In diversen Communities haben sich in den letzten Jahren zahlreiche Methoden zur kollaborativen Modellierung von fachlichen Anforderungen etabliert. Bekannte Beispiele hierfür sind EventStorming oder Domain Storytelling. Diese Ansätze setzen darauf, dass wir skillübergreifend ein besseres gemeinsames Verständnis über die Fachlichkeit erlangen. Was ist aber mit den Anforderungen an die Qualität der zu erstellenden Software? Gerade hier ist eine kollaborative Vorgehensweise immens wichtig, um nicht perfekten Idealvorstellungen hinterherzulaufen, die Kosten und Komplexität von Produkten explodieren lassen. An dieser Stelle setzt das Workshop-Format Quality Storming an, das ich im Laufe dieses Vortrags vorstellen möchte.
Zielpublikum: Architekt:innen, Entwickler:innen, Requirements Engineers, Business Analysts, Projekleiter:innen
Voraussetzungen: Keine
Level: Basic
Leuchtturmprojekt, Kostengrab, Hoffnungsträger und wichtiger Baustein in der Pandemiebekämpfung - das deutsche Corona-Warn-App-System (kurz CWA) besteht nicht nur aus der App. Zur Umsetzung von Use Cases wie der persönlichen Risikoermitttlung oder dem Melden von (positiven) Testergebnissen, gehört auch eine vielteilige Server-Lösung. Sie basiert auf einem zeitgemäßen Architekturstil, einem aktuellen Technologie-Stack und wurde unter hohem Zeitdruck realisiert. Das öffentliche Interesse an diesem Projekt ist hoch, die Transparenz bei der Entwicklung erfreulicherweise ebenfalls. Wir diskutieren die prägenden architekturrelevanten Anforderungen und die getroffenen Entscheidungen. Zum Abschluss bewerten wir die gewählten Lösungsansätze und arbeiten Stärken, Hindernisse und Kompromisse heraus.
Zielpublikum: Architekten, Entwickler, Entscheider
Voraussetzungen: Grundkenntnisse von Software-Architektur, Microservices
Level: Basic
Ein typischer Workflow in moderner Software Entwicklung beinhaltet oft folgende Schritte: Den Code in eine git Repo, kompilieren, ein Container Image bauen, das Image in eine Registry und Deployment auf einen Kubernetes Cluster. In dem Bereich Image Build scheinen Dockerfiles die Option mit der größten Akzeptanz zu sein. Es gibt jedoch mittlerweile einige Alternativen, die ein paar Stolperfallen vermeiden und diesen Teil des Prozesses noch mehr standardisieren können. Dieser Vortrag gibt tiefere Einblicke in diese Optionen und vergleicht (multi-stage) Dockerfiles mit Cloud-Native Buildpacks, Paketo und Google's JIB anhand der Kriterien Geschwindigkeit, Größe des Image und mehr.
Zielpublikum: Entwickler, DevOps, Projektleiter
Voraussetzungen: Keine
Level: Basic
Der Betrag diskutiert, ob und wie man event-getriebene Architekturen als eine Form der reaktiven Architekturen in einer Beratungssoftware einsetzen kann. Dabei wird der Bogen von den Geschäftsanforderungen bis hin zur technischen Umsetzung gespannt. Warum wurde für diese Beratungssoftware der event-getriebene Ansatz gewählt? Es werden sowohl die geschäftlichen als auch die technischen Anforderungen diskutiert, die zur Wahl dieses Architekturansatzes geführt haben. Der event-getriebene Ansatz erwies sich als der richtige, um eine Entkopplung der Systeme und ein gesamthaftes Bild der einzelnen Aktivitäten für den Benutzer sicherzustellen.
Zielpublikum: Architekten, Entwickler, Manager
Voraussetzungen: Keine
Level: Advanced
Gibt es eigentlich etwas, das mir als Software-Entwickler:in oder als Architekt:in hilft, ganz grundlegende Fähigkeiten weiter zu entwickeln, die für meine Arbeit nützlich sind? Also so etwas wie ein großes Update oder ein Refactoring, nachdem die Dinge dann viel leichter, schneller und entspannter gehen. Nur eben nicht für die Software, die wir gerade entwickeln sondern für meinen Geist?
Ich glaube, dass eine moderne Achtsamkeitspraxis genau das leistet und Dir hilft, fokussierter und gelassener mit deiner Arbeit umzugehen und letztlich bessere Systeme zu entwickeln. Wir schauen uns an, was so eine moderne Achtsamkeitspraxis ausmacht und räumen dabei gleich mit üblichen Missverständnissen auf (z.B. Esoterik-Schwurbelei, Räucherstäbchen und lautes Ohm-Singen). Du lernst, wie ein regelmäßiges Achtsamkeitstraining Dir in Deiner Arbeit helfen kann, aber auch, warum es kein Quick-Fix ist
Er ist zertifizierter Trainer für "Search Inside Yourself", ein Programm zur Entwicklung von Achtsamkeit und emotionaler Intelligenz, das innerhalb von Google entwickelt wurde.
Wieso eine IIoT-Plattform kaufen, wenn man sie auch selbst entwickeln kann? Vor dieser Wahl standen wir am Anfang unserer Reise und haben uns gegen den einfachen Weg entschieden und mit der Entwicklung begonnen. Wieso wir das getan und was wir dabei gelernt haben, wollen wir in diesem Vortrag zeigen. Dabei gehen wir auf grundsätzliche Herausforderungen und Risiken bei der Entwicklung und dem Betrieb einer skalierbaren IIoT-Plattform ein und erläutern, wie wir diese bewältigt haben. Dies umfasst unter anderem das Speichern und Verarbeiten von Telemetrie- und Metadaten, die Steuerung und Verwaltung von Devices aus der Cloud heraus sowie das adäquate Reagieren auf Ausfälle während des Betriebs.
Zielpublikum: Architekten, Entwickler, Entscheider, CTO
Voraussetzungen: Keine Vorkenntnisse erforderlich
Level: Basic
Vortrag Teilen
In vielen größeren Institutionen gibt es noch jede Menge Software, die eher monolithisch aufgebaut ist, die häufig in Applikation-Servern auf dedizierten virtuellen Maschinen von einem eher klassisch aufgestellten und organisatorisch separierten IT-Betrieb betrieben wird. Doch mal eben Kubernetes einzuführen, wie auf Konferenzen häufig mit einem Hello-World Service präsentiert, ist ohne Expertenwissen, ohne Erfahrung und mit einem meist bereits am Limit arbeitenden IT-Betrieb, eine gewaltige Aufgabe. In diesem Vortrag werden wir die sich kontinuierlich entwickelnde (evolving) Architektur einer Anwendungslandschaft hin zu Cloud Native betrachten und dabei (OpenSource) Werkzeuge kennen lernen für die schrittweise Anpassung der on-premise Infrastruktur, ohne Kubernetes.
Zielpublikum: Entwickler, Architekten, DevOps Engineers
Voraussetzungen: Grundlagen von verteilten Architekturen
Level: Advanced
