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
Urs Enzler ist Software-Architekt mit einem Fokus auf die .Net Plattform und Azure. Er baut gerne Produkte mit einem kurzen und häufigen Feedback-Zyklus. Neben der Arbeit am Zeiterfassungs-Produkt TimeRocket, ist er Berater für Software-Architektur und technische Aspekte für Teamarbeit mittels Continuous Delivery wie evolvierbares Design, Test-Driven-Development and ähnlichem. Und er ist Co-Host der .Net Usergroup Zentralschweiz und bloggt auf Planetgeek.ch.
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
Erik Wilde works in the Catalyst team at Axway. The team's mission is to help customers do the right things in the API and digital transformation space. Erik has been working in a variety of software companies, always focusing on questions of architecture and strategy. Erik's background is in computer science and he holds a Ph.D. from ETH Zurich, but over the course of his career it has become increasingly clear to him that technology rarely is the factor holding back organizations. So now he is helping organizations with their strategy to make sure that they are successful on their journeys.
Seitdem Artikel von M. Fowler und J. Lewis in 2012 sind Microservices die Antwort auf alle Fragen. Sie schienen die Antwort auf die steigende Komplexität von Softwareprojekten und Cloudanwendungen zu sein. Aber da sind Ausnahmen, die unterschiedlich beantwortet werden müssen. Im Workshop werden unterschiedliche Architekturansätze anhand von Beispielen diskutiert. Es werden gemeinsam Architekturvorschläge mit Hilfe von Domain Driven Design, Event Storming und Domain Story Telling erarbeitet. Die Lösungen werden mit den realen Lösungen verglichen und Vor-und Nachteile herausgearbeitet.
Zum Schluss können daraus verallgemeinerte Regeln abgeleitet werden, um sich für den einen oder anderen Architekturstil zu entscheiden.
Zielpublikum: Entwickler, Architekten
Voraussetzungen: Keine
Level: Basic
Annegret Junker ist Lead Architect bei Allianz Deutschland. Sie arbeitet seit mehr als 30 Jahren in der Software-Entwicklung in unterschiedlichen Rollen und unterschiedlichen Domänen wie Automotive, Versicherungen und Finanzdienstleistungen. Besonders interessiert sie sich für DDD, Microservices und alles, was damit zusammenhängt. Derzeit arbeitet sie in einem großen Versicherungs-Projekt als übergreifende Architektin.
Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/Annegret.Junker
Microservices sind angetreten, die Problem der Monolithen zu lösen. Oder doch nicht? Immerhin ist es mittlerweile Mode, Microservices zu verdammen - dann müssen Monolithen doch die richtige Lösung gewesen sein! Die Diskussion nervt und dass es sie überhaupt gibt, zeigt schon ein grundlegendes Missverständnis darüber, worum es eigentlich bei Architektur geht und dass unsere Branche leider erhebliche Schwächen hat, wenn es darum geht, ernsthaften Fortschritt zu machen.
Eberhard Wolff ist Head of Architecture bei SWAGLab und arbeitet seit mehr als zwanzig Jahren als Architekt und Berater, oft an der Schnittstelle zwischen Business und Technologie. Er ist Autor zahlreicher Artikel und Bücher, u.a. zu Microservices und trägt regelmäßig als Sprecher auf internationalen Konferenzen vor. Sein technologischer Schwerpunkt sind moderne Architektur- und Entwicklungsansätze wie Cloud, Domain-driven Design und Microservices.
Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/eberhard.wolff
Stefan Toth berät Entwickler, Teams und Unternehmen in Sachen Agilität und Software-Architektur. Fundiert, klar und effektiv. Seine Erfahrungen reichen vom Banken- und Versicherungssektor über sicherheitskritische Branchen bis hin zur Unterstützung von Internet Start-ups. Neben dem breiten technologischen Kontext ist die methodische Erfahrung aus agilen Projekten, Architekturbewertungen und IT-Transformationen sein größtes Kapital.
Vortrag Teilen
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 Cloud-spezifischer Architekturmuster? Wie kann uns das Cloud Maturity Model dabei helfen? Und was steckt eigentlich hinter Akronymen wie IaaS, PaaS, BaaS, SaaS und FaaS?
Im Rahmen des Workshops werden wie gemeinsam eine klassische Enterprise Anwendung Schritt für Schritt in die (AWS) Cloud migrieren und dabei die verschiedenen Stufen / Reifegrade des Cloud Maturity Models durchlaufen. Angefangen bei "Lift & Shift" bis hin zu "Cloud Native" und "Cloud Voodoo - aka Serverless"
Wer bei der einen oder anderen Übung selber Hand anlegen möchte, benötigt dazu lediglich ein AWS Account. Achtung es können ggf. Kosten in sehr geringem Umfang anfallen.
Lars Röwekamp, Gründer des IT-Beratungs- und Entwicklungsunternehmens open knowledge GmbH, beschäftigt sich im Rahmen seiner Tätigkeit als „CIO New Technologies“ mit der eingehenden Analyse und Bewertung neuer Software- und Technologietrends. Ein besonderer Schwerpunkt seiner Arbeit liegt derzeit in den Bereichen Enterprise und Cloud Computing sowie ML/AI, wobei neben Design- und Architekturfragen insbesondere die Real-Life-Aspekte im Fokus seiner Betrachtung stehen.
» Nimm kostenfrei am Entscheider-Track teil
Die Teilnehmer erlangen aktuelle praktische Kenntnisse bei Entwicklung und Einsatz von sicheren Web-basierten Architekturen, insbesondere Schutzmaßnahmen und Best Practices zur Vorbeugung gegen typische Schwachstellen auf Basis der aktuellen 'OWASP Top 10 Security Vulnerabilities' des 'Open Web Application Security Project'.
Jan Jürjens ist Director Research Projects am Fraunhofer ISST und leitet als Professor für Software Engineering das Institut für Softwaretechnik an der Universität Koblenz. Sein Arbeitsschwerpunkt ist die Entwicklung und das Testen sicherheitskritischer Software, für die er Ansätze und Werkzeuge in Kooperation mit Unternehmen entwickelt. Er ist Autor des Buches 'Secure Software Development with UML', das auch ins Chinesische übersetzt wurde.
» Nimm kostenfrei am Entscheider-Track teil
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
Arne Limburg ist Lead Architect bei der open knowledge GmbH in Oldenburg. Er verfügt über mehrjährige Erfahrung als Entwickler, Architekt und Trainer im Enterprise- und Microservices-Umfeld. Zu diesen Bereichen spricht er regelmäßig auf Konferenzen und führt Workshops durch. Darüber hinaus ist er im Open-Source-Bereich tätig, unter anderem als PMC Member von Apache Meecrowave, Apache OpenWebBeans und Apache DeltaSpike und als Urheber und Projektleiter von JPA Security.
» Nimm kostenfrei am Entscheider-Track teil
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
Annegret Junker ist Lead Architect bei Allianz Deutschland. Sie arbeitet seit mehr als 30 Jahren in der Software-Entwicklung in unterschiedlichen Rollen und unterschiedlichen Domänen wie Automotive, Versicherungen und Finanzdienstleistungen. Besonders interessiert sie sich für DDD, Microservices und alles, was damit zusammenhängt. Derzeit arbeitet sie in einem großen Versicherungs-Projekt als übergreifende Architektin.
Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/Annegret.Junker
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
Vortrag Teilen
Immer häufiger wird Software als verteiltes System mittels Microservices umgesetzt. Während der Programmcode je Service dabei kompakter und leichter testbar ist, werden die Schnittstellen untereinander eher komplexer und schwer zu testen. Häufig werden API-Designentscheidungen mit wenig Weitsicht getroffen, was mit der Zeit zu verschiedenen Problemen führt. Dieses Interview zeigt mit einem Augenzwinkern und anhand praktischer Beispiele, welche Fehler sich besonders dazu eignen, APIs mittels solcher Fehlentscheidungen und Antipatterns in den Ruin zu führen. Aber Vorsicht, wir empfehlen: Nicht nachmachen! Vielmehr soll das Gezeigte zum Nachdenken anregen, was man beim API Design und Test in verteilten Systemen alles beachten sollte.
Florian Pfleiderer beschäftigt sich als Senior Consultant bei Digital Frontiers mit agiler Software-Entwicklung. Seinen Kunden hilft er auf ihrem Weg in die Cloud und berät sie in den Bereichen Architektur, Microservices und Craftsmanship.
Frank Scheffler ist Senior Solution Architect und Mitbegründer bei Digital Frontiers. Er verfügt über langjährige Erfahrung als Berater und Coach in den Themen Microservices, Software Quality und agile Transformation.
Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/frank.scheffler
Vortrag Teilen
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
Matthias Haeussler is Chief Technologist at Novatec Consulting, university lecturer for distributed systems, awarded ambassador of Cloud Foundry and the organizer of the Stuttgart Cloud Foundry Meetup. He advises clients on Cloud strategies and supports implementations and migrations. Prior to that he was employed at IBM R&D Germany for more than 15 years. He has teaching experience from lectures at multiple universities in Stuttgart (DHBW, HSE, HfT). Besides that, he is frequent speaker at various national and international conferences and meetups. (e.g. Spring One Platform, Open Source Summit, KubeCon, Cloud Foundry Summit, Spring IO, WJAX & more).
Die Teilnehmer erlangen aktuelle praktische Kenntnisse bei Entwicklung und Einsatz von sicheren Web-basierten Architekturen, insbesondere Schutzmaßnahmen und Best Practices zur Vorbeugung gegen typische Schwachstellen auf Basis der aktuellen 'OWASP Top 10 Security Vulnerabilities' des 'Open Web Application Security Project'. Der Workshop beinhaltet praktische Übungen mittels Open-Source-Werkzeugen für die Sicherheitsanalyse von Softwarearchitekturen und ihrer Implementierungen, für die ein eigener Laptop benötigt wird. Wir denken uns dabei die Rolle eines Angreifers hinein und versuchen zusammen, eine dafür in einer sicheren Umgebung bereitgestellte Anwendung zu komprimittieren. Wir lernen einen Leitfaden für sichere Architekturen kennen, um die Schwachstellen vermeiden.
Maximale Teilnehmerzahl: 25
Zielpublikum: Architekten, Entwickler, QA-Manager, Projektleiter, Product Owners
Voraussetzungen: Grundlegendes Verständnis von Webanwendungen
Level: Basic
Jan Jürjens ist Director Research Projects am Fraunhofer ISST und leitet als Professor für Software Engineering das Institut für Softwaretechnik an der Universität Koblenz. Sein Arbeitsschwerpunkt ist die Entwicklung und das Testen sicherheitskritischer Software, für die er Ansätze und Werkzeuge in Kooperation mit Unternehmen entwickelt. Er ist Autor des Buches 'Secure Software Development with UML', das auch ins Chinesische übersetzt wurde.
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