RÜCKBLICK AUF DAS PROGRAMM 2021

Thema: Architecture

Nach Tracks filtern
Nach Themen filtern
Alle ausklappen
  • Montag
    08.02.
  • Dienstag
    09.02.
  • Mittwoch
    10.02.
  • Donnerstag
    11.02.
  • Freitag
    12.02.
, (Montag, 08.Februar 2021)
10:00 - 17:00
Mo 2
Domain-Driven Design-Tutorial: DDD hands-on
Domain-Driven Design-Tutorial: DDD hands-on

In den Zeiten von Microservices wird klar, wie wichtig Domain-Driven Design (DDD) nach wie vor ist. Denn nur mit Strategischem Design (also DDD im Großen) und dem Aufteilen der Domäne in Bounded Contexts kann ein sinnvoller (nämlich fachlicher) Schnitt für die Microservices gefunden werden.

In diesem Workshop nehmen wir uns einen Tag Zeit, um DDD näher anzuschauen. Der Workshop besteht aus abwechselnd Vortrag, Diskussion und Übungen.

Zielpublikum: Architekt:innen, Entwickler:innen, Projektleiter:innen, Fachexpert:innen
Voraussetzungen: Projekterfahrung
Schwierigkeitsgrad: Anfänger

Extended Abstract:
In den Zeiten von Microservices wird klar, wie wichtig Domain-Driven Design (DDD) nach wie vor ist. Denn nur mit Strategischem Design (also DDD im Großen) und dem Aufteilen der Domäne in Bounded Contexts kann ein sinnvoller (nämlich fachlicher) Schnitt für die Microservices gefunden werden.

Aber auch Taktisches Design (also DDD im Kleinen) mit der Ubiquitous Language und den "Building Blocks" Entities, Value Objects, Aggregates, Services und Co. haben nichts an Aktualität verloren.

In diesem Workshop nehmen wir uns einen Tag Zeit, um DDD näher anzuschauen. Der Workshop besteht aus abwechselnd Vortrag, Diskussion und Übungen.

Der Aufbau wird so sein, dass wir zunächst einen Überblick über DDD geben und uns dann die einzelnen Themen detailliert betrachten. Dabei nähern wir uns DDD gewissermaßen von außen nach innen. Inhaltlicher Aufbau:

  1. Einführung und Überblick
  2. Domäne kennenlernen
  3. Domäne aufteilen
  4. Sprache lernen und bauen
  5. Domäne modellieren
  6. Modell implementieren
Henning liebt Programmieren in hoher Qualität. Diese Leidenschaft lebt er als Coder, Coach und Consultant bei der WPS - Workplace Solutions aus. Dort hilft er Teams dabei, Ihre gewachsenen Monolithen zu strukturieren oder neue Systeme von Anfang an mit einer tragfähigen Architektur zu errichten. Häufig kommen dann Microservices oder Self-Contained Systems heraus. Henning ist Autor von »Domain Storytelling« und dem www.LeasingNinja.io sowie Übersetzer von »Domain-Driven Design kompakt«.
Henning Schwentner
Henning Schwentner
flag VORTRAG MERKEN

Vortrag Teilen

10:00 - 13:00
Mo 8
Mach mir (k)ein Szenario - Szenarien und Software-Architekturen
Mach mir (k)ein Szenario - Szenarien und Software-Architekturen

Nichtfunktionale Eigenschaften haben entscheidenden Einfluss auf Software-Architekturen. Ihre effektive Umsetzung ist daher kritisch.

Das Tutorium führt in szenariobasierte Architekturerstellung und -bewertung ein (u.a.mit ADD, ATAM, CBAM). Um das konzeptionelle Wissen gut zu verankern, führen die Teilnehmenden praktische Übungen durch. Adressiert werden auch Fallstricke und wie sie sich vermeiden lassen, ebenso wie Beteiligung und Verantwortlichkeiten verschiedener Rollen.

Zielpublikum: Software-Architekt:innen, Entwickler:innen
Voraussetzungen: Praxiswissen Software-Architekturen
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Bekanntlich haben nichtfunktionale Eigenschaften den größten systemischen Einfluss auf Software-Architekturen.

Attribute-Driven Design (ADD) illustriert, wie sich Qualitätsattribute gezielt in Architekturen einfügen lassen.

Methoden wie ATAM (Architecture Tradeoff Analysis Method) und CBAM (Cost Benefit Analysis Method) sind nützlich, um Software-Architekturen hinsichtlich nichtfunktionaler Eigenschaften zu überprüfen. Alle genannten Methoden basieren auf Szenarios.

Das Tutorium führt in die Grundlagen szenariobasierter Architekturerstellung und -bewertung ein. Um das konzeptionelle Wissen gut zu verankern, führen die Teilnehmenden praktische Übungen durch. Das Tutorium adressiert dabei auch Fallstricke und wie sie sich umgehen lassen sowie die Beteiligung und Verantwortlichkeiten verschiedener Rollen beim szenariobasierten Vorgehen.

Michael Stal beschäftigt sich bei der Siemens AG mit Software-Architekturen, verteilten Systemen und KI. Er ist Professor für Software-Engineering und Chefredakteur von JavaSPEKTRUM.
Michael Stal
Michael Stal
Vortrag: Mo 8
Themen: Architecture
flag VORTRAG MERKEN

Vortrag Teilen

14:00 - 17:00
Mo 12
Really Simple Reactive Architecture and Programming
Really Simple Reactive Architecture and Programming

Applications, services, and systems are changing out of necessity because of the kinds of platforms that are available today: distributed and multi-core. Have you been curious about Reactive Architecture and Programming but haven't had time to dig in? Join this session.

Maximum number of participants: 75

Target Audience: Architects and Developers
Prerequisites: Java Programming
Level: Advanced

Extended Abstract:
Applications, services, and systems are changing out of necessity because of the kinds of platforms that are available today: distributed and multi-core. Have you been curious about Reactive Architecture and Programming but haven't had time to dig in? Join this session and you will be in a good position to put Reactive to use on your projects. We will start from foundational building blocks and scale up to full Reactive implementations. If you bring your laptop and Java 1.8+ or C# for .NET Core 2.1+ you can try out Reactive during the session.

Vaughn Vernon is an entrepreneur, software developer, and architect with more than 35 years of experience in a broad range of business domains. Vaughn is a leading expert in Domain-Driven Design and Reactive, and champions simplicity. He consults and teaches around Domain-Driven Design and Reactive software development, helping teams and organizations realize the potential of business-driven and reactive systems as they transform from technology-driven legacy web implementation approaches. Vaughn is the author of three best-selling books published by Pearson/Addison-Wesley, and has been commissioned by them as the curator and editor of his own Vaughn Vernon Signature Series.
Vaughn Vernon
Vaughn Vernon
flag VORTRAG MERKEN

Vortrag Teilen

18:30 - 20:00
Nmo 1
Being Agile with Architecture Decisions: A Short Workshop on Architecture Decision Records
Being Agile with Architecture Decisions: A Short Workshop on Architecture Decision Records

Some architecture decisions are more consequential and higher impact than others, and need to be preserved. We work on systems where the architecture is too large for each person to hold all the details in their head. New team members struggle to understand what they need to know about the architecture. Current team members have challenges knowing what architecture decisions were made, by whom, and for what reason. Architecture Decision Records (ADRs) are a useful, agile, lightweight approach to tackling these, and other challenges.

Target Audience: Anyone who affects, or is affected by architecture decisions
Prerequisites: Some experience in software design and architecture would be beneficial
Level: Advanced

Extended Abstract:
Are you working on a system where the architecture is too large for each person on the team to hold all the details in their head for all time? Do new team members struggle to understand what they need to know about the architecture? Do current team members have challenges in knowing what architecture decisions were made, by whom, and for what reason? Some architecture decisions are more consequential and higher impact than others, and need to be preserved.

The right level of architecture documentation supports agility. Architecture Decision Records (ADRs) are a useful, lightweight approach for this. Often no more than a page in length, they capture the key decisions that we need to remember. This hands-on session shares experiences with ADRs, giving you a set of tools to be successful in your team.

Through this interactive session we will explore these questions together:

What are Architecture Decision Records (ADRs) and why are they useful?
How do ADRs promote or help agility?
What are the motivations that led to trying ADRs for preserving decisions?
What are some scenarios and examples where ADRs are helpful?
What kinds of decisions should we record with ADRs, and why?
What are some of the cultural challenges associated with using ADRs, and how do we address them?

This session provides participants with hands-on practice of creating and reviewing ADRs. The session draws from experiences with multiple large-scale, global organisations and system architectures, and builds on established work with ADRs from other authors and practitioners.

Ken Power is an architect, engineering leader, consultant, researcher, coach, and educator. He works with large, global technology organizations to start, grow, and transform organizations, improving their product and service delivery capability, and helping them be more effective and joyful businesses. Ken has authored more than 35 peer-reviewed publications on software engineering topics He was co-editor of the 2019 IEEE Software special issue on Large-Scale Agile Development.
Ken Power
Ken Power
Vortrag: Nmo 1
flag VORTRAG MERKEN

Vortrag Teilen

18:30 - 20:00
Nmo 4
Domain-Driven Design und Strategic Design: Umsetzung und Praxis-Tipps
Domain-Driven Design und Strategic Design: Umsetzung und Praxis-Tipps

Domain-driven Design (DDD) erlebt gerade eine Renaissance: Es ist ein vielversprechender Ansatz für die Modularisierung großer Systeme und für Microservices. In der DDD-Praxis ergeben sich aber oft Missverständnisse und Herausforderungen. Dieser Vortrag greift die typischen Herausforderungen auf und zeigt mögliche Lösungen. Dabei geht es beispielsweise um organisatorische Auswirkungen, das Schneiden von Bounded Contexts, die möglichen Beziehungen zwischen Bounded Contexts und auch die Daten-Konsistenz zwischen Bounded Contexts.

Zielpublikum: Technische Projektleiter:innen, Architekt:innen, Entwickler:innen
Voraussetzungen: Grundlegendes Verständnis über Software-Entwicklung
Schwierigkeitsgrad: Anfänger

Extended Abstract:
Durch meine Architektur-Beratungen sehe ich immer wieder Missverständnisse und Probleme bei der Umsetzung von DDD. Ich würde hier gerne Lösungen dafür diskutieren. Mein Ziel ist es, Zuhörer:innen abzuholen, die sich an einer DDD-Architektur versucht haben. Ihnen möchte ich gerne zeigen, wie man typische Probleme löst.

Selbst grundlegende Begriffe wie Bounded Context oder Upstream / Downstream sind schon nicht einfach zu verstehen. Hinzu kommt, dass diese Konzepte Domänenmodelle, organisatorische Elemente und sprachliche Aspekte (Ubiquituous Language) vermengen. Das führt in der Praxis immer wieder zu Herausforderungen. Neben einem Bewusstsein für das Problem möchte ich aufzeigen, dass man diese Aspekte auch getrennt betrachten kann.

Die Strategic Design Patterns wie Conformist oder Customer / Supplier lösen Situationen unterschiedlich. Dazu möchte ich Orientierung und Auswahlkriterien geben. www.heise.de/hintergrund/Grosse-Systeme-mit-Domain-driven-Design-entwerfen-4684074.html zeigt dazu die wesentlichen Ideen.

Daten-Konsistenz wird meistens als Problem wahrgenommen. Wenn man die Domäne genau genug fachlich untersucht, dann ist die Konsistenz oft kein Problem. Dafür möchte ich Beispiele zeigen.

Eberhard Wolff ist Fellow bei INNOQ und arbeitet seit mehr als fünfzehn Jahren als Architekt und Berater, oft an der Schnittstelle zwischen Business und Technologie. Er ist Autor zahlreicher Artikel und Bücher, u.a. zu Continuous Delivery und Microservices, und trägt regelmäßig als Sprecher auf internationalen Konferenzen vor. Sein technologischer Schwerpunkt sind moderne Architektur- und Entwicklungsansätze wie Cloud, Continuous Delivery, DevOps und Microservices.
Eberhard Wolff
Eberhard Wolff
Vortrag: Nmo 4
flag VORTRAG MERKEN

Vortrag Teilen

, (Dienstag, 09.Februar 2021)
09:00 - 10:30
Di 1.1
The Art of Software-Reviews
The Art of Software-Reviews

Der Vortrag zeigt methodisches Vorgehen von Software-Reviews, beginnend mit dessen konkreten Zielen, dem Scope sowie den notwendigen Personen. Anschließend schauen wir auf verschiedene Untersuchungsbereiche, wie Architektur, Code, Technologie, Qualitätsanforderungen bis hin zu Anwendungsdaten und den Entwicklungs- und Rollout-Prozessen.
Der Kernbegriff dabei lautet "iterative Breitensuche".
Schließlich bekommen Sie noch Tipps, die Sie für überzeugende Darstellung und Kommunikation Ihrer Schlussfolgerungen und Empfehlungen beachten sollten.

Zielpublikum: Software-Architekt:innen, Entwickler:innen, technisches Management
Voraussetzungen: Projekterfahrung
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Jede Software besitzt "Potenzial", also "besser geht immer". Aber bevor wir anfangen, wild an unseren Systemen zu verschlimmbessern, benötigen wir zuerst einen ordentlichen Überblick über deren Stärken und Schwächen.
Der Vortrag zeigt methodisches Vorgehen solcher Reviews, beginnend mit dessen konkreten Zielen, dem (schwierigen) Scope sowie den notwendigen Personen (aka Stakeholder). Anschließend schauen wir etwas genauer auf verschiedene Untersuchungsbereiche, wie Architektur, Code, Technologie, Qualitätsanforderungen bis hin zu Anwendungsdaten und den Entwicklungs- und Rollout-Prozessen. Ein Kernbegriff dabei lautet "iterative Breitensuche", wobei wir die bedarfsgerecht durch Tiefensuche ergänzen. Zu jedem Untersuchungsbereich gebe ich Beispiele und zeige methodische Werkzeuge zum effektiven und praxisnahen Einsatz. Schließlich bekommen Sie noch Tipps, die Sie für überzeugende Darstellung und Kommunikation Ihrer Schlussfolgerungen und Empfehlungen beachten sollten.

Der Vortrag richtet sich an Software-Entwicklungsteams, Architekt:innen, Product Owner sowie technisches Management.

Dr. Gernot Starke (INNOQ Fellow), Coach und Berater für methodische Software-Architektur und -Engineering. (Mit-)Gründer von arc42.org, Gründer von aim42.org. Gernot Starke war an Architektur und Implementierung von mittelgroßen und großen Systemen für Organisationen aus verschiedenen Geschäftsbereichen beteiligt, hauptsächlich in den Bereichen Finance, Automotive, Logistik und Telekommunikation, derzeit mit Schwerpunkt auf der Entwicklung und Verbesserung von Legacy-Systemen. Er hat zahlreiche Bücher über Software-Architektur und -muster geschrieben, veröffentlicht regelmäßig technische Artikel und gibt seine Erfahrungen in Trainings und auf Konferenzen weiter. Er lebt mit seiner Familie in Köln.
Gernot Starke
Gernot Starke
Vortrag: Di 1.1
Themen: Architecture
flag VORTRAG MERKEN

Vortrag Teilen

09:00 - 10:45
Di 2.1
Es muss nicht immer Kubernetes sein - Von Legacy zu Cloud-Native
Es muss nicht immer Kubernetes sein - Von Legacy zu Cloud-Native

In vielen Institutionen gibt es noch jede Menge Software, die monolithisch aufgebaut ist und von einem eher klassisch aufgestellten und organisatorisch separierten IT-Betrieb betrieben wird. Doch mal eben Kubernetes einzuführen ist 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: Architekt:innen Entwickler:innen, DevOpser, Manager:innen, Entscheider:innen
Voraussetzungen: Grundverständnis verteilter Architekturen
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
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. In Fachzeitschriften, Online-Artikeln und Konferenzen wird vorgeführt, wie einfach es doch ist, einen Hello-World Spring Boot Microservice mit mehreren Instanzen auf Kubernetes zu deployen. Doch zurück im Unternehmen wird klar: Sollte man es tatsächlich schaffen, alle notwendigen Personen davon zu überzeugen, ab sofort Kubernetes einzuführen, wird das für einen meist auch personell am Limit arbeitenden IT-Betrieb schnell zu einem Projekt mit vermutlich 1-2 Jahren Laufzeit (je nach Erfahrung), mit möglichen Seiteneffekten wie reduzierter Handlungsfähigkeit für das laufende Geschäft und dem Zurückstellen anderer Modernisierungsmaßnahmen. In diesem Vortrag werden wir die sich kontinuierlich entwickelnde (evolving) Architektur einer Anwendungslandschaft hin zu Cloud-native betrachten und dabei mehrere spezielle Open-Source-Werkzeuge kennenlernen für die schrittweise Anpassung der on-premise Infrastruktur, ohne Kubernetes.

Stephan Kaps leitet die Softwareentwicklung im Bundesamt für Soziale Sicherung und ist Gründer der Java User Group Bonn. Als Software-Architekt und Entwickler hat er seit 2002 mit Java zu tun. Weitere Schwerpunkte liegen in der Konzipierung und Optimierung von Software-Entwicklungsprozessen, DevOps & OpenSource Werkzeugen. Darüber hinaus ist er als Speaker und Autor aktiv.
Cloud-Transformation: Jede große Reise beginnt mit einem kleinen Schritt
Cloud-Transformation: Jede große Reise beginnt mit einem kleinen Schritt

Die Cloud-Transformation basiert häufig auf hohem Kostendruck, Engpässen bei Rechenkapazitäten, Verlagerung des Rechenzentrums oder Erschließung digitaler Geschäftsmodelle.

Die Definitionen von Visionen und Cloud-Modellen sind nicht mehr ausreichend, um erfolgreich zu sein.

In unserem interaktiven Vortrag beleuchten wir gemeinsam die Optionen Re-Hosting, Re-Platform, Re-Tire sowie Re-Architecting und diskutieren mit Ihnen Rahmenbedingungen, Voraussetzungen als auch Dos und Don’ts auf dem Weg in die Cloud.

Zielpublikum:
Architekt:innen, Entscheider:innen, Manager:innen
Voraussetzungen: Projekterfahrung, grundlegende Cloud-Kenntnisse
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Die Transformation in die Cloud beginnt typischerweise mit dem Business Need gefolgt von einer Zieldefinition des Unternehmens sowie der Wahl eines Cloud-Modells und -Anbieters. Hoher Kostendruck, Engpässe bei Rechenkapazitäten, die Verlagerung des Rechenzentrums wegen fehlender Wachstumskapazität oder die Erschließung digitaler Geschäftsmodelle und -felder können mögliche Motivationen für die Transformation in die Cloud sein.

Die Definition unternehmens-übergreifender Visionen als auch die Vorgabe eines Cloud-Modells - Public, Private oder Hybrid - sind schon lange nicht mehr ausreichend, um als Unternehmen in der Cloud erfolgreich zu sein.

Die Migration in die Cloud erfolgt idealerweise inkrementell: Pro Anwendung, die in die Cloud migriert wird, sollte eine eigene Strategie erarbeitet werden. Erfahrungen aus bereits durchgeführten Migrationen müssen in weitere Planungen einfließen.

In unserem interaktiven Vortrag beleuchten wir gemeinsam die Optionen Re-Hosting, Re-Platform, Re-Tire sowie Re-Architecting und diskutieren mit Ihnen Rahmenbedingungen, Voraussetzungen als auch Dos und Don’ts auf dem Weg in die Cloud.

Alexander Simon arbeitet als externer Software-Architekt in der Telekommunikations-, Banken- und Versicherungs-Branche und unterstützt diese bei der Digitalisierung von Geschäftsprozessen.
Patrick Müller arbeitete in den letzten 15 Jahren sowohl als externer sowie als interner Requirement Engineer, IT-Architekt und Product Owner in verschiedenen Branchen.
Stephan Kaps
Alexander Simon, Patrick Müller
Stephan Kaps
Vortrag: Di 2.1-1

Vortrag Teilen

Alexander Simon, Patrick Müller
Vortrag: Di 2.1-2
flag VORTRAG MERKEN

Vortrag Teilen

11:00 - 12:00
KeyDi1
KEYNOTE & CONFERENCE OPENING: What’s Past is Prologue: a Story of Event-Driven Architecture
KEYNOTE & CONFERENCE OPENING: What’s Past is Prologue: a Story of Event-Driven Architecture

The growth of Kafka inside an organization sometimes follows the development of the broader Kafka ecosystem over its lifetime. The initial use case may be something conceptually simple, like mainframe offload or point-to-point integration, evoking the simple Large Pipe architectures of Kafka’s infancy. Then those newly populated streams of events present themselves as fertile grounds for real-time analytics, as stream processing applications grow up around them to perform analysis event-by-event, leaving behind legacy ETL processes and their long batch times. Finally, a rich set of event streams gradually comes to describe more and more of the evolving state of the business, forming the substrate on which an ecosystem of event-driven microservices can thrive.This growth in architectural sophistication of an organization’s Kafka usage mirrors the development of those same concepts in the Kafka community over the past decade. In many cases, the process can be played forward at an accelerated rate as leaders draw on lessons learned and concepts developed by the community. This talk traces this development, ending with a comprehensive vision of an event-driven architecture suitable for the next generation of information technology deployments. You’ll leave knowing where you need to go and how this new architectural paradigm will help you get there.

Tim is a teacher, author, and technology leader with Confluent, where he serves as the Senior Director of Developer Experience. He can frequently be found at speaking at conferences in the United States and all over the world. He is the co-presenter of various O’Reilly training videos on topics ranging from Git to Distributed Systems, and is the author of Gradle Beyond the Basics. He tweets as @tlberglund, blogs very occasionally at http://timberglund.com, and lives in Littleton, CO, USA with the wife of his youth and their youngest child, the other two having mostly grown up.
Tim Berglund
Tim Berglund
Track: Keynote
Vortrag: KeyDi1
Themen: Architecture

 

 

flag VORTRAG MERKEN

Vortrag Teilen

14:00 - 14:45
Di 1.2
Serverless - ist das was für mich?
Serverless - ist das was für mich?

Eine Serverless-Anwendung besteht aus vielen voneinander unabhängigen Funktionen. Die Entwickler:innen können dabei aus zahlreichen Programmiersprachen auswählen. Der Cloud-Anbieter übernimmt den Betrieb und vor allem die Skalierung dieser Funktionen. Bezahlt wird pro Aufruf. Der Vortrag zeigt, welche technischen Herausforderungen eine Serverless-Anwendung mit sich bringt und wie sich Entwicklung und Betrieb anfühlen. Die Zuhörerenden bekommen zudem einen Einblick in die Cloud-Angebote der Azure- und AWS-Cloud und deren Kostenstruktur.

Zielpublikum: Architekt:innen, Entwickler:innen, Manager:innen und Entscheider:innen
Voraussetzungen: Grundlegende Kenntnisse bei der Entwicklung einer Anwendung in der Cloud sind ausreichend
Schwierigkeitsgrad: Anfänger

Extended Abstract:
Früher monolithische Anwendungen auf einem schwergewichtigen AppServer, heute vielleicht Microservices mit Docker und Kubernetes und morgen Serverless in der Cloud? Gerade im Umfeld großer und über einen langen Zeitraum gewachsener Systeme lassen sich Architekturentscheidungen nur schwer ändern und daher müssen Anpassungen umsichtig und mit Weitblick geplant werden. Aber auch abseits schnelllebiger Startups dürfen Innovationen nicht völlig ausbleiben. Daher wagt dieser Vortrag einen vorsichtigen Ausblick sowohl auf die Chancen als auch die zu erwartenden Herausforderungen des neusten Hypes unter dem Schlagwort „Serverless“.

Wie baut man eigentlich eine Anwendung aus lauter einzelnen Funktionen zusammen? Wie verbindet man diese Funktionen? Warum und unter welchen Voraussetzungen kann das eine gute Idee sein? Wie kann man dabei den Überblick über die gesamte Anwendung behalten? Diese und viele weitere Fragen werden im Laufe des Vortrags gestellt und mit den heute zur Verfügung stehenden Lösungen beantwortet. Dabei werden Fragen, auf die es heute noch keine zufriedenstellende Antwort gibt, bewusst nicht ausgespart.

Thorsten Maier arbeitet bei der Trivadis Germany GmbH in Mannheim. Er erschließt kontinuierlich bessere Wege, Software zu entwickeln, indem er selbst als leidenschaftlicher Java-Software-Entwickler unterwegs ist und anderen als Berater, Trainer, Autor sowie Speaker dabei hilft. Trotz seiner Begeisterung für Neues sind ihm Menschen stets wichtiger als Technologien. Sein Hauptaugenmerk liegt daher auf der Frage, wie sich modernste Technologien in gewachsene Umgebungen einbinden lassen und wann man besser auf Bestehendes zurückgreifen sollte.
Thorsten Maier
Thorsten Maier
Vortrag: Di 1.2
flag VORTRAG MERKEN

Vortrag Teilen

14:00 - 14:45
Di 2.2
The Art of the Necessary
The Art of the Necessary

How much can you separate what you are building from how you are building it? This becomes an increasingly relevant question with IT moving from building systems to cultivating ecosystems. At the enterprise architecture level, one of the challenges nowadays is to decide which constraints to put in place to get a robust and evolvable landscape of interacting components, while at the same time it is important to minimize these constraints so that teams and units have some autonomy, and that the overall architecture can evolve continuously.

Target Audience: Interest in enterprise & software architecture and in digital transformation
Prerequisites: None
Level: Advanced

Extended Abstract:
In this presentation, we look at this interesting challenge from the standpoint of APIs, and how they can help to reduce the constraints to the necessary ones, while still resulting in an effective architecture.

One of the main challenges of enterprise architecture and software architecture today is to move from building systems to cultivating ecosystems. With business and IT moving closer together, and the demands on businesses to become better at changing and adapting, this introduces new constraints into architecture that looked different when the main goals were mostly centered around being secure, robust, and efficient.

Ecosystems exhibit different qualities from systems in the sense that they afford more autonomy to components, while at the same time introducing models of fitness and continuous change. With today's demand on business and IT to become faster and more effective at changing, the question is how to reflect those demands in new practices and models for architecting. We argue that one way of doing this is to focus on constraints, and to also focus on minimizing the constraints so that components can adapt and evolve as freely as possible.

We present a model of how to address API issues in the four areas of strategy, program, platform, and products. The goal of this model is to have as much coordination and alignment between these areas as necessary. The way this is done is by having clearly structured guidelines that represent and communicate the constraints, and that always clearly explain the rationale, the constraint itself, as well as possible ways how to comply with the constraint and how to test for compliance. The goal of this is to create loose coupling while still having a structure that allows governance. While in practice it would be ideal to fully automate all tests so that governance can be done in a full self-service model, so far we have concluded that automated testing is a good goal to have, but that some constraints still need a process of human review and approval.

Erik Wilde works in the Axway Catalyst team and focuses on API strategy, API programs, and API platforms. His main goal is to make sure that organizations make the right decisions when it comes to using APIs as the foundation of their digital transformation initiatives. Erik has a Ph.D. from ETH Zurich, is the author of many articles, papers, and books, is a frequent speaker at global API events, and contributes to standardization activities to help improving the way how APIs are designed, managed, and used.
Erik Wilde
Erik Wilde
flag VORTRAG MERKEN

Vortrag Teilen

14:00 - 14:45
Di 3.2
Sichere Speicherung kritischer Daten in der Cloud
Sichere Speicherung kritischer Daten in der Cloud

Nicht nur regulatorische Anforderungen, auch die geänderte Bedrohungslage in der Cloud sind bei der Speicherung und Verarbeitung kritischer Daten eine Herausforderung für Architektur und Technik.

Wir diskutieren verschiedene Architekturen und Technologien, wie sich Defense-in-Depth, Mandantentrennung, Absicherung von Data-at-Rest und Data-in-Transit, Daten-Autonomie und Retention Policies umsetzen lassen, sprechen über Nachvollziehbarkeit und Separation-of-Concerns und teilen Erfahrungen aus der Praxis.

Zielpublikum: Architekt:innen, Entwickler:innen
Voraussetzungen: Ein grundlegendes Verständnis für Architektur ist hilfreich, aber keine Voraussetzung
Schwierigkeitsgrad: Anfänger

Andreas Zitzelsberger ist Entwickler und Architekt aus Leidenschaft und arbeitet als Technischer Geschäftsbereichsleiter bei QAware. Seine Schwerpunkte sind Cloud und Cloud Native Security.
Andreas Zitzelsberger
Andreas Zitzelsberger
Vortrag: Di 3.2
flag VORTRAG MERKEN

Vortrag Teilen

16:15 - 17:15
Di 1.3
Fundamental IDEALS for Modeling Microservices
Fundamental IDEALS for Modeling Microservices

SOLID principles are well-known for designing object-oriented systems. But what if you are developing microservices? IDEALS, is yet another silly mnemonic acronym and are the core principles for microservice design. The acronym stands for: Interface segregation, Deployability, Event-driven, Availability over consistency, Low Coupling, and Single responsibility. We will relate these IDEALS to techniques, tools, technologies, and domain modeling principles we use today to develop modern service-based distributed systems (microservices).

Target Audience: English, Developers, Architects, QAs, Testers, Product Owners, Managers
Prerequisites: Basic Understanding of architecture and microservices and familiarity with domain modeling
Level: Advanced

Extended Abstract:

It's been seven years since we've started creating microservices. Practice has shown what design principles give you a sound foundation for a successful microservice architecture. Join us in this session to find out what they are, and how to realize them. For OO systems, Robert Martin compiled the five SOLID principles. For designing microservice-based solutions, we propose developers follow the "IDEALS":  

(I) Interface segregation tells us that different types of clients (e.g., mobile apps, web apps, CLI programs) should be able to interact with services through the contract that best suits their needs. 

(D) Deployability (is on you) acknowledges that in the microservice era, which is also the DevOps era, there are critical design decisions and technology choices developers need to make regarding packaging, deploying and running microservices. 

(E) Event-driven suggests that whenever possible we should model our services to be activated by an asynchronous message or event instead of a synchronous call. 

(A) Availability over consistency reminds us that more often end users value the availability of the system over strong data consistency, and they're okay with eventual consistency. 

(L) Loose-coupling remains an important design concern in the case of microservices, with respect to afferent (incoming) and efferent (outgoing) coupling. 

(S) Single responsibility is the idea that enables modeling microservices that are not too large or too slim because they contain the right amount of cohesive functionality. 

We will relate these IDEALS to techniques, tools, technologies and domain modeling principles we use today to develop modern service-based distributed systems (microservices).

Paulo Merson has been programming in the small and programming in the large for over 25 years. Paulo is a software developer at the Brazilian Federal Court of Accounts. He is a Visiting Scientist with the Software Engineering Institute (SEI) and is also a certified instructor for SOASchool and a faculty member of the master program in Applied Computing at University of Brasilia. Paulo often delivers professional training to software developers in the US, Latin America, and Europe.
Joseph (Joe) Yoder is president of the Hillside Group and principle of The Refactory. He is best known as an author of the Big Ball of Mud pattern, illuminating fallacies in software architecture. Joe teaches and mentors developers on agile and lean practices, architecture, flexible systems, clean design, patterns, refactoring, and testing. Joe has presented many tutorials and talks, arranged workshops, given keynotes, and help organized leading international agile and technical conferences.
Paulo Merson, Joseph Yoder
Paulo Merson, Joseph Yoder
flag VORTRAG MERKEN

Vortrag Teilen

16:15 - 17:15
Di 2.3
Enterprise-Architektur für Business Agility
Enterprise-Architektur für Business Agility

Sich rasch wandelnde Märkte und Business-Modelle stärken den Ruf nach Flexibilität. Reaktionsfähigkeit soll Unternehmen auszeichnen. Wie genau kann Enterprise-Architektur (EA) hier unterstützen? Können langfristige Planung, Enterprise Repositories, Standardisierung und Governance im agilen Kontext tatsächlich nützen?

Diese Session zeigt, welche Ziele sich EA im agilen Kontext stecken sollte. Mit Erfahrungen aus der Praxis untermauert, werden wichtige Zusammenhänge illustriert und Tipps aus kleinen und großen Erfolgen abgeleitet.

Zielpublikum: Solution-, Enterprise-Architekt:innen, CTOs, interessierte Manager:innen
Voraussetzungen: Erfahrung in der Entwicklung größerer Systeme und Systemlandschaften
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract
:
Sich rasch wandelnde Märkte und Business-Modelle stärken den Ruf nach Flexibilität. Reaktionsfähigkeit soll Unternehmen auszeichnen, sich bietende Möglichkeiten wollen rasch genutzt werden. Wie genau kann Enterprise-Architektur (EA) hier unterstützen? Können langfristige Planung, Enterprise Repositories, Standardisierung und Governance im agilen Kontext tatsächlich nützen?

Diese Session zeigt, welche Ziele sich EA im agilen Kontext stecken sollte. Dazu werden organisatorische, methodisch/agile und technische Trends der IT-Industrie eingeordnet. Es entstehen sechs Themenblöcke, mit denen sich wandelnde Unternehmen in den letzten Jahren viel beschäftigt haben. Experimentierkultur und empirische Prozesse zu stärken, technisches und organisatorisches Feedback auf allen Ebenen zu fördern, oder auch gut gelebte Transparenz und die Öffnung von einst etwas "elitären" Architekturdiskussionen sind einige Beispiele, die ich diskutieren werde.

Mit Erfahrungen aus der Praxis untermauert, werden wichtige Zusammenhänge illustriert und Tipps aus kleinen und großen Erfolgen der eigenen Arbeit abgeleitet. Ein paar Mythen der EA-Disziplin könnten am Weg leiden.

Stefan Toth ist Geschäftsführer und Mitgründer der embarc GmbH. Seine Beratungsschwerpunkte liegen in der Konzeption und der Bewertung mittlerer bis großer Softwarelösungen, der Weiterentwicklung von Systemlandschaften sowie der Verbindung dieser Themen zu agilen Vorgehen. Er ist Autor zahlreicher Artikel und des Buchs „Vorgehensmuster für Software-Architektur“.
Stefan Toth
Stefan Toth
Vortrag: Di 2.3
flag VORTRAG MERKEN

Vortrag Teilen

17:45 - 18:45
Di 1.4
Organisation: Ein Werkzeug für Architektur
Organisation: Ein Werkzeug für Architektur

Das Gesetz von Conway, Domain-driven Design, Microservices - die aktuell wichtigsten Architektur-Ansätze – nutzen die Organisation als Werkzeug für Architektur. Aber Software-Architekt:innen können die Organisation oft nur bedingt beeinflussen. Dieser Vortrag zeigt, was es genau heißt, die Organisation als Werkzeug für Architektur zu nutzen, und wie man als Software-Architekt dabei ganz konkret vorgehen kann.

Zielpublikum: Technische Projektleiter:innen, Architekt:innen, Entwickler:innen
Voraussetzungen: Grundlegendes Verständnis über Software-Entwicklung
Schwierigkeitsgrad: Anfänger

Extended Abstract:
In meiner Arbeit nehme ich zunehmend die Organisation als das entscheidende Werkzeug wahr, um Architekturen zu beeinflussen. Mittlerweile ist vielen Architekt:innen zwar klar, dass sie kommunizieren müssen. Aber ich denke, es geht noch viel weiter. Dazu kommt, dass sowohl Conway's Law wie auch Domain-driven Design bereits die Wechselwirkungen zwischen Architektur und Organisation darstellen.

Eberhard Wolff ist Fellow bei INNOQ und arbeitet seit mehr als fünfzehn Jahren als Architekt und Berater, oft an der Schnittstelle zwischen Business und Technologie. Er ist Autor zahlreicher Artikel und Bücher, u.a. zu Continuous Delivery und Microservices, und trägt regelmäßig als Sprecher auf internationalen Konferenzen vor. Sein technologischer Schwerpunkt sind moderne Architektur- und Entwicklungsansätze wie Cloud, Continuous Delivery, DevOps und Microservices.
Eberhard Wolff
Eberhard Wolff
Vortrag: Di 1.4
Themen: Architecture
flag VORTRAG MERKEN

Vortrag Teilen

17:45 - 18:45
Di 2.4
You Can't Put a Price on Architecture? Then Please Don't Call It Architecture!
You Can't Put a Price on Architecture? Then Please Don't Call It Architecture!

Architecture work is all about trade-offs. We weigh security against ease of use, we balance availability with maintainability and contrast performance with reliability. But how do we evaluate the cost and benefits of change? As architecture is a means to an end, not an end in itself, architectural improvements have to be governed by sound reasoning, and more often than not that has to be based on numbers. Which in turn implies the need for good practices for the financial evaluation of technical decisions. Here we'll explore a dozen of these.

Target Audience: Software architects, developers, managers
Prerequisites: Some experience with real world architectural and design decision (even without putting numbers on them)
Level: Advanced

After quite a while in software development in the last century Michael Mahlberg turned to consulting on software architecture and processes in general around the turn of the Millennium. Always with a strong focus on continuous improvement and sustainable change he now spends most of his time supporting clients in their quest for more effective ways to work, mostly by applying lean and agile concepts.
Michael Mahlberg
Michael Mahlberg
Vortrag: Di 2.4
Themen: Architecture
flag VORTRAG MERKEN

Vortrag Teilen

, (Mittwoch, 10.Februar 2021)
09:00 - 10:30
Mi 1.1
So gehen Architektur-Reviews! Die deutsche Corona-Warn-App unter der Lupe
So gehen Architektur-Reviews! Die deutsche Corona-Warn-App unter der Lupe

Architekturbewertungen sichern Lösungsansätze ab, zeigen Risiken auf und schaffen Transparenz. In dieser Session wenden wir ausgewählte Bewertungsansätze passgenau auf eine aktuell im Rampenlicht stehende Software an: die deutsche Corona-Warn-App. Als Ergebnis erhalten Sie einen umfassenden Überblick über zeitgemäße Bewertungsmethodik mit den jeweiligen Vor- und Nachteilen der Ansätze und spannende Einblicke in die Funktionsweise des technisch anspruchsvollen, verteilten Softwaresystems.

Zielpublikum: Primär Software-Entwickler:innen und -architekt:innen, im Grunde alle mit Interesse an Software-Entwicklung
Voraussetzungen: Erfahrung in Software-Entwicklungsvorhaben (Rolle eigentlich egal)
Schwierigkeitsgrad: Anfänger

Extended Abstract:
Architekturbewertungen sichern Lösungsansätze ab, zeigen Risiken auf und schaffen Transparenz. Im Juni 2020 hatte das Virus die Welt fest im Griff, als die deutsche Corona-Warn-App zum Download bereitstand. Das Vertrauen der Bevölkerung in die Software war entscheidend — ohne breite Beteiligung wäre sie zum Scheitern verurteilt.

Was kann Architekturbewertung hier leisten? Der Softwarehersteller hat neben umfassender Dokumentation immerhin auch den kompletten Quelltext offengelegt. Das eröffnet die Möglichkeit einer fundierten Analyse. Im Umfeld der Architekturbewertung gibt es ein reiches Arsenal an Methoden und Werkzeugen. Sie reichen von qualitativen Ansätzen wie ATAM bis zum Auswerten von Metriken oder dem Messen von Antwortzeiten, Durchsatz oder ähnlichem.

In dieser Session wenden wir ausgewählte Bewertungsansätze passgenau auf die Corona-Warn-App an. Unsere Zuhörenden nehmen daher gleich zwei Dinge mit: Einen umfassenden Überblick über zeitgemäße Bewertungsmethodik mit den jeweiligen Vor- und Nachteilen der Ansätze. Und Einsichten in die Funktionsweise der Corona-Warn-App. Mit ihren Stärken, Schwächen und Kompromissen. Hätte man das nicht auch alles ganz anders machen können. Klar, aber was wären die Konsequenzen gewesen? Finden Sie es gemeinsam mit uns heraus!

Stefan Zörner ist Software-Architekt bei embarc in Hamburg. Er wirkt bei Entwurfs- und Umsetzungsfragen mit, unterstützt beim Festhalten von Architektur und beleuchtet Lösungsansätze in Bewertungen.
Falk Sippach ist bei der embarc Software Consulting GmbH als Softwarearchitekt, Berater und Trainer stets auf der Suche nach dem Funken Leidenschaft, den er bei seinen Teilnehmern, Kunden und Kollegen entfachen kann. Bereits seit über 15 Jahren unterstützt er in meist agilen Softwareentwicklungsprojekten im Java-Umfeld. Als aktiver Bestandteil der Community (Mitorganisator der JUG Darmstadt) teilt er zudem sein Wissen gern in Artikeln, Blog-Beiträgen, sowie bei Vorträgen auf Konferenzen oder User Group Treffen und unterstützt bei der Organisation diverser Fachveranstaltungen.
Stefan Zörner, Falk Sippach
Stefan Zörner, Falk Sippach
Vortrag: Mi 1.1
flag VORTRAG MERKEN

Vortrag Teilen

09:00 - 10:30
Mi 2.1
Managing Polarities in Software Design and Engineering
Managing Polarities in Software Design and Engineering

Do you find yourself, or your team facing unsolvable problems? Problems that start to polarise and get decided by the people with the most rank? Or the majority vote decided and it resolves in a split in the team or in people feeling left out, or excluded? Perhaps you find yourself excluded from a team or company? Polarities cannot be solved, only managed. With polarity mapping we manage that polarity and go from either-or thinking to both-and thinking, and this way includes the entire team in managing that polarity.

Target Audience: Architects, Developers, Decision Makers, CTO, Tech Leads, designers, facilitators
Prerequisites: None
Level: Advanced

Extended Abstract:
Do you find yourself, or your team facing unsolvable problems? Problems that start to polarise and get decided by the people with the most rank? Or the majority vote decided and it resolves in a split in the team or in people feeling left out, or excluded? Perhaps you find yourself excluded from a team or company? And the moment you think you solved it they come back again. The thing is, polarisations like these cannot be solved, like breathing in and breathing out but need to be managed. If we don't, we will make compromises or stay in one polarity and experience the downside of both. To identify and manage polarities, we need to discuss and start using polarity mapping.

In this session, we will interactively expose you to polarity thinking. We will explore how to identify polarities and how we can start managing them with Barry Johnson Polarity Mapping. We will take a common polarity in software design, like too much vs too little upfront design, mob/pair programming vs programming in isolation, and planning vs taking action. By filling in the polarity map together, we show you the power of visualisation to manage the polarity. We will go from either-or thinking to both-and thinking, and this way includes the entire team in managing that polarity.

Leveraging Deep Democracy, Domain-Driven Design, Continuous Delivery and visual collaborate tools, Kenny Baas-Schwegler empowers organisations, teams and people in building valuable software products.
Evelyn van Kelle is a strategic software delivery consultant, with experience in coaching, advising and guiding organisations and teams in designing socio-technical systems.
Gien Verschatse, a software developer with 10 years of experience, mainly in a .NET environment, who likes to start her day with coffee. She specialises in bridging the gap between users and developers by practicing domain driven design. Besides that she loves to learn how teams can improve the way they make decisions both on a technical and organisational level. She is a strong believer of continuously learning by deliberate practice and knowledge sharing, which is why she dedicates a lot of her free time speaking at conferences or user groups.She also helps to organise an F# conference in the US, Open FSharp. When she is not busy with all of the above, you will find her on the sofa, reading a book (yes, with coffee).
Kenny Baas-Schwegler, Evelyn van Kelle, Gien Verschatse
Kenny Baas-Schwegler, Evelyn van Kelle, Gien Verschatse
flag VORTRAG MERKEN

Vortrag Teilen

09:00 - 10:45
Mi 7.1
If you can read my mind - Dokumentation und Code lesen und verstehen
If you can read my mind - Dokumentation und Code lesen und verstehen

Haben Sie schon einmal gesagt bekommen: Arbeite Dich mal in dieses Projekt ein - wir sollen es übernehmen?

Haben Sie dann Unmengen von Doku bekommen (aber nicht Unmengen von Zeit), um in ein paar Tagen ein Statement dazu abzugeben?

Die ganze Informatik-Ausbildung ist darauf ausgerichtet, Software zu schreiben.

In der Praxis angelangt, stellt man aber schnell fest, dass dies weniger als "die halbe Miete" ist.

Warum? Weil Entwickler:innen viel mehr Zeit damit verbringen, Software bzw. deren Dokumentation zu lesen, als neue zu schreiben.

Zielpublikum: Architekt:innen, Entwickler:innen, Projektleiter:innen
Voraussetzungen: Projekterfahrung
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Haben Sie schon einmal gesagt bekommen: Arbeite Dich mal in dieses Projekt ein - wir sollen es übernehmen?

Haben Sie dann Unmengen von Doku bekommen (aber nicht Unmengen von Zeit), um in ein paar Tagen ein Statement dazu abzugeben?

Die ganze Informatik-Ausbildung ist darauf ausgerichtet, Software zu schreiben.

In der Praxis angelangt, stellt man aber schnell fest, dass dies weniger als "die halbe Miete" ist.

Warum? Weil Entwickler:innen viel mehr Zeit damit verbringen, Software bzw. deren Dokumentation zu lesen, als neue zu schreiben.

Dieser Talk zeigt Tipps und Best Practices, wie man effizient Dokumentation und Code lesen und erfassen kann.

Dabei liefert er auch einen Einblick in das, was dort nicht steht, bzw. Tipps, wie man genau diese Lücken füllen kann.

Er gibt Tipps zum schnellen Erfassen des Inhaltes bzw. zur zielgerichteten Analyse. Aus der Praxis - für die Praxis!

Lernen Sie die "Kunst des Unperfekten" kennen!

Thomas Ronzon arbeitet seit 2000 als Projektleiter und Senior Software-Entwickler bei der w3logistics AG in Dortmund. Dabei beschäftigt er sich vor allem mit der Modernisierung von unternehmenskritischen Logistikanwendungen.

In der Zeitschrift JavaSPEKTRUM berichtet er regelmäßig über neue 'Tools' für Architekten ('The Tool Talk'). Darüber hinaus veröffentlicht er regelmäßig Fachartikel und spricht auf Konferenzen. Thomas taucht leidenschaftlich gerne und tief in technische Aspekte ein, verliert dabei jedoch nie den Bezug für die Fachlichkeit. Mit viel Empathie, Erfahrung und konkreten Lösungsvorschlägen schlägt er damit immer wieder die Brücke zwischen Business und IT.

Evidenz ist nicht die Mehrzahl von Anekdote
Evidenz ist nicht die Mehrzahl von Anekdote

Die aktuellen "Best Practices" in der Software-Entwicklung, von TDD, Domain-Driven Design, Continous-Delivery, agiles Vorgehen usw., haben eine Gemeinsamkeit: Ihre Erfolgsversprechen basieren vor allem auf Anekdoten in Blogposts, Konferenzvorträgen und anderen Veröffentlichung von den Digitalchampions Google, Amazon, Facebook und anderen "Koryphäen". Warum ist das eigentlich so? Kann es auch anders sein? Diese und viele andere Fragen werden in diesem Vortrag diskutiert.

Zielpublikum: Architekt:innen, Entwickler:innen
Voraussetzungen: Keine
Schwierigkeitsgrad: Anfänger

Extended Abstract:
Die aktuellen "Best Practices" in der Software-Entwicklung, von TDD, Domain-Driven Design, Continous-Delivery, agiles Vorgehen usw., haben eine Gemeinsamkeit: Ihre Erfolgsversprechen basieren vor allem auf Anekdoten: Blogposts, Konferenzvorträgen und andere Veröffentlichung von den Digitalchampions Google, Amazon, Facebook sowie den "Koryphäen" unseres Faches erzählen davon, wie sie verschiedene Probleme bei der Software-Entwicklung gelöst haben. Jedoch handelt es sich meistens um Einzelfälle in ganz spezifischen Kontexten. Und die Problemlösungen ändern sich rasend schnell. Systematische Untersuchungen, welches Vorgehen bei welchem Problem das richtige ist, haben dagegen Seltenheitswert. Arbeiten aus der akademischen Welt sind oft praxisfern. Bestenfalls münden sie in exotischen Programmiersprachen, deren Ideen vielleicht irgendwann mal in der Praxis landen. Warum ist das eigentlich so? Kann es auch anders sein? Diese und viele andere Fragen werden in diesem Vortrag diskutiert.

Christoph Iserlohn ist Senior Consultant bei INNOQ. Er hat langjährige Erfahrung mit der Entwicklung und Architektur von verteilten Systemen. Sein Hauptaugenmerk liegt dabei auf den Themen Skalierbarkeit, Verfügbarkeit und Sicherheit.
Thomas Ronzon
Christoph Iserlohn
Thomas Ronzon

Vortrag Teilen

Christoph Iserlohn
flag VORTRAG MERKEN

Vortrag Teilen

11:00 - 11:45
Mi 1.2
Rethink Processes and User Experience to Leverage The Full Potential Of Your Hipster Architecture
Rethink Processes and User Experience to Leverage The Full Potential Of Your Hipster Architecture

Modern architectures (e.g. event-driven and reactive) will gain more traction as we build more complex systems, connect more distributed components and slice systems into smaller autonomous pieces. Unfortunately, many companies don’t update their business processes to reflect this. I’ll give an example and discuss the consequences, motivating you to advocate for a redesign of your business processes internally. Too much attention gravitates towards the technical side of reactive, without thinking about the user journey or business implications.

Target Audience: Architects, Developers, Business Analysts
Prerequisites: Experiences with software architecture
Level: Advanced

Extended Abstract:
There is a lot of buzz around reactive architectures. Take, for example, event-driven architectures, event-streaming or reactive programming. These architectures will gain more and more traction as we build more complex systems, connect more distributed components and slice systems into smaller autonomous pieces. Unfortunately, I see many companies that don’t update their business processes to reflect this new world. In this talk, I’ll give an example and discuss the consequences, hopefully motivating you to advocate for a redesign of your business processes internally–because too much attention gravitates towards the technical side of reactive, without thinking about the user journey or business implications.

Bernd Ruecker has been in the software development field for more than 15 years, automating highly scalable workflows at global companies including T-Mobile, Lufthansa and Zalando and contributing to various open source workflow engines. He is Co-Founder and Chief Technologist of Camunda – an open source software company reinventing workflow automation. Along with his Co-Founder, he wrote "Real-Life BPMN," a popular book about workflow modeling and automation. He regularly speaks at international conferences and writes for various magazines, focusing on new workflow automation paradigms that fit into modern architectures around distributed systems, microservices, domain-driven design, event-driven architecture and reactive systems.
Bernd Rücker
Bernd Rücker
Vortrag: Mi 1.2
Themen: Architecture
flag VORTRAG MERKEN

Vortrag Teilen

11:00 - 11:45
Mi 4.2
Mit C++ Modules in eine neue Ära der Modularisierung
Mit C++ Modules in eine neue Ära der Modularisierung

Eine der ganz großen Innovationen im neuen C++-Sprachstandard (C++20) ist C++ Modules. Dieses Modulsystem soll das Ende der Header-Dateien und des Präprozessors, sowie der damit einhergehenden Probleme, einläuten.

In meinem Vortrag erläutere ich nicht nur die Funktionsweise, Unterschiede sowie die Vor- und Nachteile von C++ Modules im Vergleich zum alten Modularisierungskonzept mit Header- und Implementierungsdateien. Ich möchte insbesondere auch mal eine holistische Perspektive anbieten: Welchen Einfluss hat Modules auf die Software-Architektur?

Zielpublikum: Entwickler:innen, Software-Architekten:innen
Voraussetzungen: Kenntnisse in der Programmiersprache C++ sind hilfreich.
Schwierigkeitsgrad: Anfänger

Extended Abstract:
Das Interessante an dem neuen Feature "C++ Modules" ist nicht nur sein Potenzial, das mittlerweile antiquiert erscheinende, schwache und mit vielen Problemen (z.B. ODR violations) behaftete Modularisierungskonzept von der prozeduralen Programmiersprache C loszuwerden. Die Auswirkungen auch auf die Software-Architektur eines C++-Entwicklungsprojekts dürften bemerkenswert sein und die Art und Weise, wie C++-Entwicklungsprojekte in den nächsten Jahrzehnten strukturiert werden, massiv verändern. Genau diesem Aspekt möchte ich in meinem Vortrag auch Raum geben.

Stephan Roth ist Trainer und Berater bei der oose Innovative Informatik eG, mit Schwerpunkten in den Bereichen modellbasiertes Systems Engineering und Softwaretechnik mit UML/SysML, Software-Architektur und -design, Software Craft und Clean Code. Mit der Programmiersprache C++ im professionellen Kontext ist Stephan seit 2001 vertraut. Er ist zudem Fachbuchautor und regelmäßiger Sprecher auf Konferenzen.
Stephan Roth
Stephan Roth
flag VORTRAG MERKEN

Vortrag Teilen

11:00 - 11:45
Mi 7.2
Evolving Monoliths to Microservices
Evolving Monoliths to Microservices

This talk will examine principles that assist with successfully evolving from a monolith to Microservices. Deciding what to decouple along with when and how to incrementally evolve a system are the main architectural challenges in this process. It is important to commit to "stop adding to the monolith" - all new code is added as microservices; the "Strangler Pattern". The new features are microservices, occasionally replacing part of the monolith. Also, when writing new microservices code, it is important to avoid dependencies to the monolith.

Target Audience: English, Developers, Architects, QAs, Testers
Prerequisites: Basic Understanding of architecture and microservices and familiarity with domain modeling
Level: Advanced

Extended Abstract:
Being Agile, with its attention to extensive testing, frequent integration, and focusing on important product features, has proven invaluable to many software teams. When building complex systems, focus on features provides a lot of value and starting with a monolith architecture can be advantageous. However, over time, although you might be committed to keeping the code clean, and having lots of tests — the architecture can become harder to evolve. Ultimately technical debt and design problems will creep in until it becomes muddy, making it hard to deliver new features quickly and reliably. Also, evolving the system quickly can become harder. If things are changing quickly with lots of teams, evolving using the microservices architectural style can have many possible benefits.

Many Microservices architectures start from the evolution of a Monolith system by gradually applying the microservices architectural style. There are considerations and principles that assist with successfully evolving from a monolith to Microservices. Deciding what to decouple along with when and how to incrementally evolve a system are the main architectural challenges in this process. There are good principles that help with this evolutionary process. For example, it is important to commit to "stop adding to the monolith" - all new code is added as microservices. This is the core of the "Strangler Pattern". The new features are microservices, occasionally replacing part of the monolith. Also, there might be important pieces of the monolith that are getting hard to maintain and you want to pull these out. When this happens, you find design seams within the monolith, refactoring these out to components, that can ultimately be replaced with microservices. Early on, it is ok to create macro services first and then evolve (refactor) them to microservices. Also, when writing new microservices code, it is important to avoid dependencies to the monolith. Finally, you can use DDD modeling to identify aggregates and bounded contexts to pull them out from the monolith. This talk will examine various patterns when evolving from the monolith to microservices specifically with variations of the Strangler Pattern.

Joseph (Joe) Yoder is president of the Hillside Group and principle of The Refactory. He is best known as an author of the Big Ball of Mud pattern, illuminating fallacies in software architecture. Joe teaches and mentors developers on agile and lean practices, architecture, flexible systems, clean design, patterns, refactoring, and testing. Joe has presented many tutorials and talks, arranged workshops, given keynotes, and help organized leading international agile and technical conferences.
Joseph Yoder
Joseph Yoder
flag VORTRAG MERKEN

Vortrag Teilen

14:30 - 15:30
Mi 1.3
Streamlining der Steuersoftware-Entwicklung bei DATEV mittels DSLs
Streamlining der Steuersoftware-Entwicklung bei DATEV mittels DSLs

Das spezifische Wissen der Fachexperten effizient in Software umzusetzen, ist für den Geschäftserfolg vieler Unternehmen - auch den der DATEV - entscheidend. Für die Entwicklung der zentralen Komponenten, den Steuerberechnungen, hat sich DATEV entschieden, dieses Wissen in Form von DSL-basierten Modellen abzubilden und die Software daraus automatisch zu generieren. Im Vortrag gehen wir auf die Vor- und Nachteile des Konzepts ein, erläutern Herausforderungen bei Entwicklung und Einführung sowie generelle - positive wie negative - Lessons Learned.

Zielpublikum: Architekt:innen, Management
Voraussetzungen: Keine
Schwierigkeitsgrad: Anfänger

Extended Abstract:
Deutschlands Steuerberater erstellen pro Jahr mehrere Millionen Steuererklärungen unter Verwendung der DATEV-Software. Kern dieser Software ist eine weitreichende Implementierung des deutschen Steuerrechts, das den Nutzern als Win32-Desktopanwendung sowie zukünftig als SaaS zur Verfügung gestellt wird.

Ein wesentlicher Faktor für den weiteren Geschäftserfolg der DATEV ist, die Steuerfachlichkeit schnell und in hoher Qualität zu implementieren und dann auf verschiedenen Plattformen zur Verfügung zu stellen.

Um diesen Prozess weiter zu optimieren, entwickelt DATEV eine domänenspezifische Sprache. Diese zeichnet sich dadurch aus, dass die durch die gesetzlichen Regelungen implizierte Struktur und Rechenlogik unmittelbar als Modell “hinschreibbar” ist. Durch einen in der IDE integrierten Interpreter lassen sich die Modelle direkt ausführen, testen und debuggen. Damit kann die fachliche Korrektheit der Steuerlogik direkt -- ohne Generierung, Build oder Deployment -- und unabhängig von der technischen Implementierung sichergestellt werden.

Nachgelagert wird aus den Modellen ein inkrementeller C-Rechenkern für die Win32-Anwendung generiert; eine Implementierung der Berechnung in Java zur Verwendung in Spring-basierten Microservices für die SaaS-Plattform ist in Entwicklung.

In diesem Vortrag beschreiben wir die Motivation für die Entwicklung der DSL, die wichtigsten Spracheigenschaften, Integration in existierende Systeme, Erfahrungen mit Einführung bei den Fachentwicklern sowie – positive und negative – Lessons Learned.

Yulia Komarov arbeitet als Software-Architekt bei DATEV. Seit mehreren Jahren unterstützt sie die Entwicklung der Steuer-Software als Technical Lead, Architekt und Sparringspartner für Fachexperten.
Markus Völter ist Physikingenieur und Informatiker und arbeitet als freiberuflicher Berater zu Sprach- und Werkzeugbau. Nebenher ist er Podcaster zu Themen aus Wissenschaft und Technik und hat Anfang 2020 ein Buch zu einigen der Themen aus 10 Jahren Podcast veröffentlicht. Der Vortrag basiert auf dieser journalistischen Tätigkeit.
Yulia Komarov, Markus Völter
Yulia Komarov, Markus Völter
flag VORTRAG MERKEN

Vortrag Teilen

14:30 - 15:30
Mi 7.3
“Das neue System muss aber das Gleiche können wie das alte!” “NEIN!” - Systeme richtig modernisieren
“Das neue System muss aber das Gleiche können wie das alte!” “NEIN!” - Systeme richtig modernisieren

Wenn ein Softwaresystem modernisiert werden soll, kommt oft reflexartig die Anforderung „Das neue System muss aber das Gleiche können wie das alte!” Was sich auf den ersten Blick sinnvoll anhören mag, ist es keineswegs. Warum das so ist, erklären wir vor dem Hintergrund häufiger Modernisierungsziele und typischer Systemhistorien. Damit sollten alle Zuhörenden in Zukunft argumentativ gerüstet sein, diesen Fehler nicht mehr zu begehen. Darüber hinaus zeigen wir Stolperfallen und Best Practices für die Planung einer erfolgreichen Modernisierung.

Zielpublikum: Architekt:innen, Projektleiter:innen; Management
Voraussetzungen: Erfahrung in Software-Projekten
Schwierigkeitsgrad: Anfänger

Extended Abstract:
Systeme leben häufig über viele Jahre oder gar Jahrzehnte, werden sorgsam gepflegt und immer wieder geflickt. Aber irgendwann wirkt das UI angestaubt, Änderungen brauchen ewig und man will von Möglichkeiten moderner Technologien profitieren.

Die Entscheidung, das System zu modernisieren, wird gefällt. Und dann kommt die einfachste Anforderung der Welt, die wir alle schon gehört haben: “Das neue System muss aber das Gleiche können wie das alte!”. Dass wir diese Anforderung so häufig hören, ist nicht verwunderlich: Sie ist einfach, man kann sie auch formulieren, wenn man das System nur oberflächlich kennt, und scheint dabei umfassend und präzise zu sein. Tatsächlich ist diese Anforderung ziemlich unsinnig.

Über die Jahre entstehen bei zu modernisierenden Systemen fast immer Kompromisslösungen, nachträgliche Ergänzungen und technische Schulden. Diese wollen wir gerade nicht mit ins neue System nehmen, sondern die Chance der Modernisierung nutzen. Das Gleiche gilt für die Sicht der User Experience. Wenn man das System schon umbaut, bietet es sich an, das User Interface grundlegend zu überdenken. Außerdem zeigen viele Untersuchungen, dass ein Großteil der Features einer Software so gut wie nie verwendet wird und der Wert eigentlich nur durch einige wenige Funktionalitäten generiert wird. Bei einer Modernisierung haben wir also die Möglichkeit zu konsolidieren, unnötigen Ballast abzuwerfen und mit leichterem Gepäck in die Zukunft zu gehen.

In diesem Vortrag erklären wir im Detail, warum die einfachste Anforderung der Welt Unsinn ist, und geben Erfahrungen, Hinweise und Best Practices für die frühen Phasen eines Modernisierungsvorhabens, in denen es darum geht, den Zielzustand zu gestalten und den Weg der Modernisierung zu planen. Wir sprechen darüber, wie man entscheidet, welche Features tatsächlich übernommen werden sollten, wie man das Modernisierungsvorhaben im Unternehmen und in den Teams verankert und wie man die Tiefe und Umfang der Modernisierung plant. Unsere Erfahrung und Hinweise illustrieren wir anhand von konkreten Beispielen und Erfahrungen aus Projekten.

Matthias Naab ist Softwarearchitekt am Fraunhofer IESE und leitet seit 2020 die Hauptabteilung Information Systems. Seit 2010 verantwortet er die Weiterentwicklung von Architekturmethoden und die Beratung von Kunden aus der Wirtschaft. Er hat in zahlreichen Projekten in unterschiedlichsten Branchen Architekturen bewertet, Systeme verbessert und innovative Systeme mitgestaltet. Matthias Naab hält regelmäßig Vorträge zu Softwarearchitektur und Digitalen Ökosystemen.
Dominik Rost ist seit 2009 Softwarearchitekt am Fraunhofer IESE und leitet dort seit 2020 die Abteilung »Architecture-Centric Engineering (ACE)«. Er berät Kunden aller Branchen dabei, die Architektur ihrer Produkte zu entwickeln, zu evaluieren und zu dokumentieren, und die Skills im Bereich Softwarearchitektur zu verbessern. Über seine Erfahrungen spricht er regelmäßig bei Konferenzen. Darüber hinaus leitet er das Seminar »Softwarearchitektur« der Fraunhofer Academy.
Marcus Trapp leitet die Abteilung "UX & RE " am Fraunhofer IESE. Er unterstützt Unternehmen bei der kreativen Ideenfindung zum Aufbau oder der Modernisierung von Software-intensiven Systemen.
Matthias Naab, Dominik Rost, Marcus Trapp
Matthias Naab, Dominik Rost, Marcus Trapp
flag VORTRAG MERKEN

Vortrag Teilen

15:45 - 16:30
KeyMi2
KEYNOTE: Software Architecture: The Past, The Present, and the Future
KEYNOTE: Software Architecture: The Past, The Present, and the Future

Over the history of software systems, the way we build such artifacts, the way we design them, the way we express them have evolved in seemingly disruptive ways. Even today, the pendulum swings between low ceremony agile methods to more rigid waterfall-ish ones; from big balls of mud to microservices and then back to big balls of microservices. In this talk, we'll examine the past, the present, and the future of software architecture: the role it plays in software systems, and the timeless fundamentals that remain across the fullness of time.

Grady Booch is Chief Scientist for Software Engineering at IBM Research where he leads IBM’s research and development for embodied cognition. Having originated the term and the practice of object-oriented design, he is best known for his work in advancing the fields of software engineering and software architecture. A co-author of the Unified Modeling Language (UML), a founding member of the Agile Alliance, and a founding member of the Hillside Group, Grady has published six books and several hundred technical articles, including an ongoing column for IEEE Software. Grady was also a trustee for the Computer History Museum. He is an IBM Fellow, an ACM and IEEE Fellow, has been awarded the Lovelace Medal and has given the Turing Lecture for the BCS, and was recently named an IEEE Computer Pioneer. He is currently developing a major trans-media documentary for public broadcast on the intersection of computing and the human experience.
Grady Booch
Grady Booch
Track: Keynote
Vortrag: KeyMi2
flag VORTRAG MERKEN

Vortrag Teilen

17:00 - 18:00
Mi 1.4
Die Matrix: Enterprise-Architekturen jenseits von Microservices
Die Matrix: Enterprise-Architekturen jenseits von Microservices

Man gewinnt den Eindruck, Microservices seien die Universallösung für all unsere (Architektur-)Probleme. Dabei sind Microservices lediglich Mittel zum Zweck. Was also, wenn meine Probleme nicht zur Lösung „Microservices“ passen? Ist es nach wir vor legitim, einen Monolithen zu bauen? Oder gibt es andere Architekturansätze, mit denen sich Monolithen aufbrechen lassen? In der Session werfen wir einen kritischen Blick auf Microservices und beleuchten – immer ausgehend von bestehenden Problemfeldern – eine Reihe alternativer Architekturen.

Zielpublikum: Architekt:innen, Entwickler:innen, Projektleiter:innen, Management, Entscheider:innen
Voraussetzungen: Projekterfahrung, Enterprise Computing
Schwierigkeitsgrad: Anfänger

Extended Abstract:
Getreu dem Motto "choose Microservices for the benefits and not because your codebase is a mess."
(Zitat: Simon Brown), beleuchtet die Session typische Problemstellungen aus großen Projekten und zeigt auf, für welche dieser Microservices eine Lösung darstellen und für welche eher nicht. Anhand verschiedener Real-Life-Anforderungen, werden alternative Architekturen als Lösungsansätze gezeigt und bewertet.

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, wobei neben Design- und Architekturfragen insbesondere die Real-Life-Aspekte im Fokus seiner Betrachtung stehen.
Lars Röwekamp
Lars Röwekamp
Vortrag: Mi 1.4
flag VORTRAG MERKEN

Vortrag Teilen

17:00 - 18:00
Mi 3.4
Application Integration Patterns (not only) for Microservices
Application Integration Patterns (not only) for Microservices

Eine wesentliche Auswirkung beim Einsatz einer Microservice-Architektur ist, dass ein großer Teil der Kommunikation zwischen den einzelnen Komponenten über das Netzwerk erfolgt. Um die Vorteile dieses Architekturstils auch wirklich nutzen zu können, dürfen die einzelnen Microservices lose miteinander gekoppelt sein. In dieser Session lernen Sie die grundlegenden Integrations-Muster kennen, und sehen anhand eines konkreten Szenarios, wie Sie diese Patterns zu einer funktionierenden Anwendung verknüpfen können.

Zielpublikum: Architects, Developers
Voraussetzungen: Basic architectural knowledge
Schwierigkeitsgrad: Fortgeschritten

Dennis Traub ist Developer Advocate bei Amazon Web Services (AWS). Er arbeitet seit über 25 Jahren in der Web- und Software-Entwicklung, u.a. bei ThoughtWorks, codecentric und zuletzt als Global Solutions Architect bei AWS. Heute teilt er seine Erfahrung mit Entwickler:innen, Architekt:innen und Systemadministrator:innen und zeigt ihnen, wie sie sichere und hochverfügbare Anwendungen in der Cloud entwickeln und betreiben können.
Dennis Traub
Dennis Traub
Vortrag: Mi 3.4
flag VORTRAG MERKEN

Vortrag Teilen

17:00 - 18:00
Mi 5.4
Der Beitrag des Software-Engineering zur Digitalen Transformation
Der Beitrag des Software-Engineering zur Digitalen Transformation

Dieser Talk berichtet von den Erfahrungen der letzten 7 Jahre bei der Digitalen Transformation der DATEV aus der Sicht des Software-Engineering. Während es einfach scheint, den Buzzwords der Zeit nachzulaufen und sich dadurch inmitten der sogenannten “Digitalen Transformationen” zu fühlen, ist es meist doch viel diffiziler, eine Firma nachhaltig und zum Besseren zu entwickeln. Dieser Vortrag geht auf nicht ganz so offensichtliche Aspekte und deren Wechselwirkungen ein.

Zielpublikum: Architekt:innen, Management
Voraussetzungen: Keine
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Dieser Talk berichtet von den Erfahrungen der letzten 7 Jahre bei der Digitalen Transformation der DATEV aus der Sicht des Software-Engineering. Während es einfach scheint, den Buzzwords der Zeit nachzulaufen und sich dadurch inmitten der sogenannten “Digitalen Transformationen” zu fühlen, ist es meist doch viel diffiziler, eine Firma nachhaltig und zum Besseren zu entwickeln. Dieser Vortrag geht auf nicht ganz so offensichtliche Aspekte und deren Wechselwirkungen ein.

Während bekanntlich alle Teile eines Unternehmens ihren Beitrag leisten müssen, um die gewünschten Ziele zu erreichen, befasst sich der Talk speziell mit einem Blick aus Sicht des Software-Engineering. Das Lernen der Organisation und die Ausrichtung auf maximalen Kundenwert bei allgemeiner “Business Agility” sind das Ziel. Dabei müssen sämtliche Dimensionen zusammenspielen, sowohl das Business, die Architektur, die Prozesse als auch die Organisation. Es ist entscheidend, sich der Wechselwirkungen zwischen den Dimensionen bewusst zu sein, ja sie auch bewusst zu beeinflussen. Während zu Beginn mancher Software-Engineer alles als Interpolation der teamlokalen agilen Arbeitsweise verstand, ist heute jedem klar, dass dies weit gefehlt war.

Michael Kircher verantwortet als Leitender Angestellter bei der DATEV eG die Themen Technologiestrategie, Software-Architektur, als auch die Software-Entwicklungsprozesse und -methoden. Von 2007 bis 2014 verantwortete er die technische Leitung der syngo Plattform der Siemens Healthcare. Seit über 30 Jahren ist er dem Software-Engineering verbunden: praktizierend, fordernd und fördernd.
Michael Kircher
Michael Kircher
flag VORTRAG MERKEN

Vortrag Teilen

17:00 - 18:00
Mi 7.4
Testen Sie Ihre Software-Architektur – Lebe lang und sei erfolgreich!
Testen Sie Ihre Software-Architektur – Lebe lang und sei erfolgreich!

Automatisiertes Testen von Funktionalität ist heutzutage Standard und ermöglicht kurze Releasezyklen. Für die Software-Architektur ist die resultierende hohe Änderungshäufigkeit eine Herausforderung und führt in vielen Projekten zu Architektur Drift und Erosion.

In der Session behandeln wir das systematische Testen von Software-Architektur. Sie bekommen einen Überblick über gängige Methodik und Lösungen anhand von Beispielen aus realen Projekten. Im Praxisteil lernen Sie, wie Architektur einfach automatisiert getestet werden kann.

Zielpublikum: Software-Architekt:innen, Entwickler:innen, Projektleiter:innen
Voraussetzungen: Grundkenntnisse Software-Architektur und Testautomatisierung
Schwierigkeitsgrad: Fortgeschritten

Matthias Herbort arbeitet als Principal Key Expert für Software-Architektur bei der Siemens AG. Er hat mehr als 15 Jahre Erfahrung in der Modernisierung und Sanierung von mittleren und großen unternehmenskritischen Software-Systemen. Dabei arbeitet er oft an der Schnittstelle zwischen Architektur und Business.
Matthias Herbort
Matthias Herbort
flag VORTRAG MERKEN

Vortrag Teilen

18:30 - 20:00
Nmi 1
Mono-, Modu-, Microliths - oder welche Steine nutze ich zum Bauen
Mono-, Modu-, Microliths - oder welche Steine nutze ich zum Bauen

Seit dem 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. The Vortrag diskutiert Vorteile und Nachteile von Microservices, Modulithen und Monolithen unter Benutzung von realen Beispielen. Als Ergebnis werden Checklisten vorgestellt, die die Entscheidungen in einem solchen komplexen Umfeld einfacher machen.

Zielpublikum: Architekt:innen, Entwickler:innen, Entscheider:innen
Voraussetzungen: Prinzipielles Verständnis von Software-Architektur
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Microservices als ein einfacher Service ist einfach zu verstehen. Aber eine ganze Sammlung von ihnen ist schwierig zu verstehen. Ein Monolith als solcher ist einfach zu verstehen, aber all die komplexe Geschäftslogik innerhalb ist schwierig zu verstehen.

Wo ist die Linie zwischen beiden – was kann verstanden werden und wann wird es zu kompliziert? Der Vortrag diskutiert diese Fragen und gibt zumindest einige Antworten.

Dr. Annegret Junker ist Lead Architect bei Allianz Deutschland AG. Dr. Junker arbeitet seit mehr als 25 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.
Annegret Junker
Annegret Junker
Vortrag: Nmi 1



flag VORTRAG MERKEN

Vortrag Teilen

, (Donnerstag, 11.Februar 2021)
09:00 - 10:30
Do 1.1
Conway’s Law und Soziologie in der Software-Architektur
Conway’s Law und Soziologie in der Software-Architektur

Conway’s Law erlebt seit einigen Jahren ein Revival.

Mit diesem Vortrag soll Conway’s Law aus einer anderen Perspektive betrachtet werden: Systemtheorie und Konstruktivismus.

Was denken Softwaearchitekten über Software-Architekten, die Software-Architekten beobachten?

Und warum beeinflusst uns das mehr, als die Struktur unserer Organisation?

Was unterscheidet eigentlich ein IT-System von einem sozialen System?

Zielpublikum: Software-Architekt:innen, Lead Developer, Projektleiter:innen, Agile Coaches
Voraussetzungen: Software-Architekturkenntnisse, Conway's Law sollte bekannt sein
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Der Vortrag ist kontrovers - er korrigiert ein häufiges Missverständnis von Conway's Law, nämlich dass ein intentionales Organisationsdesign zu besserer Architektur führt.

Es wird anhand von Erkenntnissen und Modellen der Soziologie und Organisationspsychologie klar, warum das gar nicht möglich ist.

Auf dem Software-Architektur-Meetup in Nürnberg gab es nach dem Vortrag noch 180 Minuten angeregte Diskussion über die Frage, ob Software-Architektur sich nicht weiter an die Sozialwissenschaften wagen sollte.

Gerrit Beine ist Berater & Trainer bei der innoQ Deutschland GmbH und seit 1998 in der IT unterwegs, seit 2001 mit agilen Methoden. Er war viele Jahre lang Software-Architekt in großen Projekten. In den letzten 10 Jahren baut er immer wieder Brücken zwischen agilen Organisationen und langlebigen Software-Architekturen.

Gerrit hat Informatik studiert, ist Autor zahlreicher Fachartikel und regelmäßig als Sprecher auf Konferenzen zu den Themen Software-Architektur und Agile zu treffen.
Gerrit Beine
Gerrit Beine
Vortrag: Do 1.1
Themen: Architecture
flag VORTRAG MERKEN

Vortrag Teilen

09:00 - 10:30
Do 5.1
Software Architecture for AI-intensive Systems
Software Architecture for AI-intensive Systems

The problem at hand is partly the application of software engineering best practices to AI, but more so the evolution of software engineering to attend to software-intensive systems that contain AI components. In this lecture, I'll examine both dimensions: emerging AI architectures, neuro-symbolic systems, designing/testing/deploying/refactoring/maintaining systems with AI components; the future of software engineering.

Target Audience:
Software engineers
Prerequisites: Curiosity and a desire to think different
Level: Advanced

Grady Booch is Chief Scientist for Software Engineering at IBM Research where he leads IBM’s research and development for embodied cognition. Having originated the term and the practice of object-oriented design, he is best known for his work in advancing the fields of software engineering and software architecture. A co-author of the Unified Modeling Language (UML), a founding member of the Agile Alliance, and a founding member of the Hillside Group, Grady has published six books and several hundred technical articles, including an ongoing column for IEEE Software. Grady was also a trustee for the Computer History Museum. He is an IBM Fellow, an ACM and IEEE Fellow, has been awarded the Lovelace Medal and has given the Turing Lecture for the BCS, and was recently named an IEEE Computer Pioneer. He is currently developing a major trans-media documentary for public broadcast on the intersection of computing and the human experience.
Grady Booch
Grady Booch
flag VORTRAG MERKEN

Vortrag Teilen

09:30 - 10:30
Do 2.1
Erfolgsgeschichte Blume 2000: Moderne Architektur mit altbewährten Konzepten
Erfolgsgeschichte Blume 2000: Moderne Architektur mit altbewährten Konzepten

In einer Fallstudie möchte ich darstellen, warum der Microservices und Single-Page Application Hype dazu geführt hat, dass viele Unternehmen vor einer unnötig komplexen Architektur stehen.

Natürlich ist das hier kein "back to the monolith" pitch, vielmehr soll es darum gehen, sinnvolle Fragestellungen und Lösungen aufzuzeigen, die es ermöglichen, mit alt-bewährten Konzepten eine Architektur zu finden, in der sich schnell neue Funktionen entwickeln lassen.

Es wird um Themen wie Self-Contained Systems, DevSecOps & Accelerate gehen.

Zielpublikum: Architekt:innen, Entscheider:innen, Lead Developer
Voraussetzungen: Arbeitserfahrung als Entscheider / Führungskraft / Abteilungsleiter
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Ich glaube, es ist an der Zeit, mit dem Microservice Hype und Single-Page Application Hype abzurechnen.

Viel zu leichtsinnig haben sich viele Unternehmen in diese vermeintlich alle Probleme lösenden Ansätze gestürzt und stehen jetzt vor dem Problem, noch langsamer und komplexer zu sein als vorher.

Mein Talk soll zeigen, dass das auch anders geht und man mit den guten alten HTML-Techniken und fachlich geschnittenen Makroservices gepaart mit DevOps-Praktiken unfassbar schnell wird.

Entscheider sollen diese Erfahrungen und Learnings nutzen können, um für ihre eigenen Abteilungen / Bereiche, richtige Entscheidungen abzuleiten.

Als Basis für den Talk dienen vorherige Studien und Talks, wie Accelerate von Jez Humble und Self-Contained Systems von INNOQ.

Benedikt Stemmildt ist leidenschaftlicher Software-Architekt, Full-Stack-Entwickler und Speaker mit Begeisterung für Technologie, Architektur und Organisation. Er entwickelt und betreibt Software, datengetrieben mit Fokus auf Kundenmehrwert. Bildet sich und andere gern aus und weiter. Stolzes Gründungsmitglied der Hacker-School.
Benedikt Stemmildt
Benedikt Stemmildt
Vortrag: Do 2.1
Themen: Architecture
flag VORTRAG MERKEN

Vortrag Teilen

11:00 - 11:45
Do 1.2
CQRS und Event Sourcing unter Strom: Lessons Learned aus der Praxis
CQRS und Event Sourcing unter Strom: Lessons Learned aus der Praxis

CQRS und Event Sourcing sind bekannt, haben aber in der praktischen Anwendung oft das Nachsehen gegenüber bewährten Schichtenarchitekturen. Wir fragten uns: Lohnt es sich, hier umzudenken?

Die Vorteile sind bekannt, aber asynchrone Ergebnisverarbeitung, Exception Handling in verteilten Umgebungen und Backupfähigkeit des Event Stores waren nur einige der Herausforderungen, die wir zu bewältigen hatten.

In diesem Vortrag wollen wir unsere Erfahrungen und Lessons Learned zu CQRS/Event Sourcing mit Spring und Axon bei einem Energieversorger teilen.

Zielpublikum: Architekt:innen, Entwickler:innen
Voraussetzungen: Architektur, verteilte Umgebungen
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Die Themen CQRS und Event Sourcing sind den meisten Entwicklern heutzutage bekannt. Die Hürde, diese in der Praxis einzusetzen, ist jedoch nicht zu unterschätzen. Dieser Architekturstil erfordert ein Umdenken, vor allem, wenn man bisher gewohnt war, bewährte Schichtenarchitekturen einzusetzen. Macht sich dieses Umdenken in der Praxis bezahlt?

Vor dieser Frage standen auch wir! Die Vorteile von CQRS/Event Sourcing hatten uns schnell überzeugt. Die Umsetzung in die Praxis gestaltete sich jedoch kniffliger als erwartet. Asynchrone Ergebnisverarbeitung, Exception Handling in verteilten Umgebungen und Backupfähigkeit des Event Stores waren nur einige der Herausforderungen, die wir zu bewältigen hatten.

In diesem Vortrag wollen wir unsere Erfahrungen und Lessons Learned mit euch teilen. Wir zeigen euch, wie wir bei einem Energieversorger erfolgreich CQRS/Event Sourcing mit Spring und Axon umgesetzt haben.

Frank Scheffler ist Senior Solution Architect bei Digital Frontiers. Er verfügt über langjährige Erfahrung als Berater und Coach in den Themen Microservices, Software Quality und agile Transformation.
Matthias Grünewald ist CTO von HöchstDigital, einem Startup der Süwag Energie AG, und verantwortet dort den Aufbau und die Weiterentwicklung digitaler Kundenkanäle.
Frank Scheffler, Matthias Grünewald
Frank Scheffler, Matthias Grünewald
Vortrag: Do 1.2
flag VORTRAG MERKEN

Vortrag Teilen

11:00 - 11:45
Do 2.2
Auf gehts in die Cloud: „Das kann doch nicht so schwer sein!“
Auf gehts in die Cloud: „Das kann doch nicht so schwer sein!“

„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? Und was steckt eigentlich hinter Akronymen wie IaaS, PaaS, BaaS, SaaS und FaaS?

Zielpublikum: Architekt:innen, Entwickler:innen, Projektleiter:innen, Management, Entscheider:innen
Voraussetzungen: Keine
Schwierigkeitsgrad: Anfänger

Extended Abstract:
Im Rahmen der Session werden ich 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.

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, wobei neben Design- und Architekturfragen insbesondere die Real-Life-Aspekte im Fokus seiner Betrachtung stehen.
Lars Röwekamp
Lars Röwekamp
Vortrag: Do 2.2
flag VORTRAG MERKEN

Vortrag Teilen

11:00 - 11:45
Do 3.2
Software-Architektur für Entscheiderinnen und Entscheider
Software-Architektur für Entscheiderinnen und Entscheider

Die Metapher „Software-Architektur“ wirkt oft sehr abstrakt, und man könnte manchmal das Gefühl bekommen, sie stehe für Entwicklungsabteilungen, die sich lieber mit sich selbst als mit den Anforderungen von Nutzenden und Fachabteilungen beschäftigen. Tatsächlich aber ist die Architektur unserer Systeme der entscheidende Erfolgsfaktor für eine erfolgreiche Digitalisierung. In diesem Vortrag werden wir diskutieren, welche Rolle Architektur für Entscheiderinnen und Entscheider spielt, wie sie sie beeinflussen können und von ihr beeinflusst werden und wie dazu eine kluge Arbeitsteilung zwischen Management, Entwicklung und Usern gestaltet werden kann.

Stefan Tilkov ist Geschäftsführer und Principal Consultant bei der INNOQ, wo er sich vorwiegend mit der strategischen Beratung von Kunden im Umfeld von Softwarearchitekturen beschäftigt. Er ist Autor des Buchs “REST und HTTP”, Mitherausgeber von “SOA-Expertenwissen” (beide dpunkt.verlag), Autor zahlreicher Fachartikel und häufiger Sprecher auf internationalen Konferenzen.
Stefan Tilkov
Stefan Tilkov
Vortrag: Do 3.2
Themen: Architecture
flag VORTRAG MERKEN

Vortrag Teilen

14:30 - 15:30
Do 1.3
Eventual Consistency – Du musst keine Angst haben
Eventual Consistency – Du musst keine Angst haben

Der Trend zu hochskalierenden Cloud-Anwendungen, die auf datengetriebene Features setzen, ist ungebrochen und immer mehr Anwendungen laufen nur noch unter Eventual Consistency. Nebenläufige Änderungen auf inkonsistenten Daten können zu Replikations-Anomalien wie Lost Updates führen, deren Behandlung selbst für erfahrene Software-Architekt:innen eine Herausforderung darstellt. Der Vortrag vereint die neuesten Forschungsergebnisse und Lessons Learned aus mehreren Case Studies mit konkreten Entwurfsmustern für Architekt:innen.

Zielpublikum: Architekt:innen, Entwickler:innen
Voraussetzungen: Fachkenntnisse Verteilte Systeme, Eventual Consistency, Isolation / Transaktionen
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
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 Case Studies und unserer laufenden Forschung 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 mit unserer Open-Source-Lösung.

Susanne Braun ist Software-Architektin am Fraunhofer IESE und verantwortet Projekte, die sich mit der Entwicklung von Digitalen Ökosystemen beschäftigen. So begleitet sie seit vielen Jahren Kundenprojekte im „Smart Farming“-Umfeld. Als Urheberin des Projektes „Digitale Teams“ ist sie nun zusätzlich im Bereich „New Work“ aktiv. In ihrer PhD forscht sie an Daten-Replikations-Konzepten. Sie ist Sprecherin auf zahlreichen Konferenzen und Mitglied im Programm-Komitee der JavaLand.
Susanne Braun
Susanne Braun
flag VORTRAG MERKEN

Vortrag Teilen

14:30 - 15:30
Do 2.3
Software-Modernisierung mit Wardley Maps
Software-Modernisierung mit Wardley Maps

Software-Modernisierung ist ein schwieriges Terrain: Bewährte Systeme sollen abgeschaltet, neue Prozesse geschaffen, Mitarbeitende umgeschult und überhaupt alles auf den Kopf gestellt werden. Daher muss eine Modernisierung von den strategischen Zielen nachvollziehbar abgeleitet werden, um möglichst viele mitzunehmen.

Hierfür stelle ich in diesem Vortrag evolvierende Strategielandkarten in Form von Wardley Maps vor. Damit lassen sich die eingeschlagenen Wege bei Software-Modernisierungsvorhaben verständlich diskutieren und kommunizieren.

Zielpublikum: Software-Architekt:innen, Entscheider:innen
Voraussetzungen: Etwas Interesse an IT-Strategie
Schwierigkeitsgrad: Anfänger

Extended Abstract:
Wardley Maps schaffen ein kontextspezifisches Bewusstsein für die eigene IT-Situation. Sie bringen Technies und Entscheider:innen an einen Platz (bzw. einer Karte) zusammen, um gemeinsam über den Status quo zu reden und neue Ideen und Ziele für beide Seiten verständlich veranschaulichen zu können.

Insbesondere bei Software-Modernisierungen helfen Wardley Maps, die vorhandene IT-Landschaft mit ständigem Blick auf den Kundennutzen zu kartografieren, um sich nicht in Details zu verlieren. Es entsteht ein Überblick etwa über mögliche Fehlinvestitionen, suboptimale Entwicklungspraktiken oder Know-how-Engpässe auf neutralem Boden. Daraus lassen sich fundierte Erkenntnisse für Make-or-Buy-Entscheidungen, Outsourcing oder der Reorganisationen von Teams ableiten.

Markus Harrer arbeitet seit über zwölf Jahren in der Software-Entwicklung. Seine Spezialgebiete sind Clean Code, Softwaresanierung, Performance-Optimierung und Software Analytics. Als Berater bei INNOQ hilft er, Software nachhaltig und strategisch sinnvoll zu verbessern.
Markus Harrer
Markus Harrer
Vortrag: Do 2.3
Themen: Architecture
flag VORTRAG MERKEN

Vortrag Teilen

14:30 - 15:30
Do 7.3
Design-Erosion - Hege und Pflege von Software-Architekturen
Design-Erosion - Hege und Pflege von Software-Architekturen

Software-Architekturen sind lebendige Organismen, die einer gründlichen Pflege bedürfen. Vernachlässigt man sie, so führt dies zu Verwachsungen, Wucherungen und weiteren Schäden. Der Vortrag adressiert zum einen, wie sich eine Pflege von Software-Architekturen durchführen lässt. Und zum anderen stellt er vor, wie Architekt:innen Probleme in den Griff bekommen können. Anhand von Beispielen erkennen Teilnehmende, warum dabei Lernen aus Fehlern ein wichtiges Werkzeug darstellt.

Zielpublikum:
Architekt:innen, Entwickler:innen
Voraussetzungen: Praxiskenntnisse Software-Architekturen
Schwierigkeitsgrad: Fortgeschritten

Michael Stal beschäftigt sich bei der Siemens AG mit Software-Architekturen, verteilten Systemen und KI. Er ist Professor für Software-Engineering und Chefredakteur von JavaSPEKTRUM.
Michael Stal
Michael Stal
flag VORTRAG MERKEN

Vortrag Teilen

14:30 - 15:30
Do 9.3
Deployment Patterns for Confidence: Quality Delivery Pipeline
Deployment Patterns for Confidence: Quality Delivery Pipeline

DevOps as a software engineering practice unifies software development (Dev) and software operation (Ops). To assist with quality delivery in with DevOps you need to provide a “Quality Delivery Pipeline” to assure the delivery meets the requirements and proper validation and checks are done before releasing into full production. This talk will focus on the “Quality Delivery Pipeline” as a practice that can help sustain delivering with confidence by addressing important qualities in the pipeline.

Target Audience:
English, Developers, Architects, QAs, Testers, Product Owners
Prerequisites: Basic Understanding of architecture and microservices and familiarity with DevOps
Level: Advanced

Extended Abstract:
Many software development processes such as Agile and Lean focus on the delivery of working software that meets the needs of the end-users. Many of these development processes help teams respond to unpredictability through incremental, iterative work cadences, and through empirical feedback. There is a commitment to quickly deliver reliable working software that has the highest value to those using or benefiting from the software. DevOps has become a common practice to assist with quality delivery in these practices, specifically when developing using the microservices architectural style. DevOps as a software engineering practice unifies software development (Dev) and software operation (Ops). To assist with quality delivery in these practices you need to provide a “Quality Delivery Pipeline” to help assure the delivery meets the requirements and proper validation and checks are done before releasing into full production. At the end of the pipeline the validated system will be deployed into production. There are various deployment techniques to help successfully and reliably deploy more quickly. The goal is to give confidence by providing "reliable, working software" to the user (making the user confident in the system). Also, the teams will have more confidence the system is working. This talk will focus on the “Quality Delivery Pipeline” as a practice that can help sustain delivering with confidence by addressing important qualities in the pipeline.

Joseph (Joe) Yoder is president of the Hillside Group and principle of The Refactory. He is best known as an author of the Big Ball of Mud pattern, illuminating fallacies in software architecture. Joe teaches and mentors developers on agile and lean practices, architecture, flexible systems, clean design, patterns, refactoring, and testing. Joe has presented many tutorials and talks, arranged workshops, given keynotes, and help organized leading international agile and technical conferences.
Ademar Aguiar is a Professor at Faculty of Engineering of University of Porto (FEUP) and researcher at INESC Porto, with over more than 20 years of experience on software development, software architecture and design (patterns, frameworks, infrastructures), agile methods, wikis, and open collaboration tools.
Joseph Yoder, Ademar Aguiar
Joseph Yoder, Ademar Aguiar
flag VORTRAG MERKEN

Vortrag Teilen

17:00 - 18:00
Do 1.4
Datengetriebene Software-Architekturen
Datengetriebene Software-Architekturen

In modernen Systemarchitekturen befinden sich die Daten „im Fluss“ (engl. Flow): IoT-Geräte, Fahrzeuge, Trucks usw. übertragen Daten in die Cloud- oder dedizierte Serverumgebungen. Diese Daten sind volatil, denn ein Merkmal dieser Daten ist der Aspekt, dass diese nicht mehr nur durch Benutzerinteraktionen an einer UI oder einem Terminal erzeugt werden oder in vorgegebenen Strukturen erwartet werden. In dieser Session sollen Architekturmöglichkeiten zum Umgang mit diesen Daten vorgestellt werden.

Zielpublikum:
Architekt:innen, Entwickler:innen, Projektleiter:innen, Entscheider:innen
Voraussetzungen: Fachkenntnisse in Datenhaltungen, SQL, NoSQL, Kafka, Java-Kenntnisse
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Klassisch bedingt, befinden sich Daten allzu oft in Datensenken innerhalb eines Unternehmens oder Konzerns. Dieses beruhte auf der Funktionsbereichstrennung, die in klassischen Unternehmen seit dem Taylorismus vorherrschte. Diese Ansicht hat Software-Architekturen lange Zeit geprägt.

Moderne, prozessorientierte Unternehmen besitzen diese Trennung nicht mehr: Cross-funktionale Teams realisieren Teilprozesse oder Schritte in komplexen Systemlandschaften (oft auf Microservice-Basis realisiert).

Aktuelle Systeme gehen noch weiter: Sie fokussieren ihre Wirkungsweise nicht mehr auf Daten, die in Datensenken gespeichert sind, sondern auf Datenflüsse. Event-Mechanismen, wie sie beispielsweise Apache-Kafka realisiert, sind hier Mittel der Wahl, um Massendatenströme korrekt zu verarbeiten.

Doch es bedarf noch mehr: Was bedeutet es, wenn wir uns als Software-Architekt:innen auf die zu verarbeitenden Daten fokussieren?

Welche evolutionären Ausprägungen und Entwicklungen von datenorientierten Architekturen hat es bis dato gegeben?

In dieser Session soll zum einen die historische Entwicklung der Datenhaltungen, angefangen bei der Entwicklung des "relationalen Empires" hin zu NoSQL-Variationen aufgezeigt werden. Insbesondere soll auf deren Einsatzzwecke und Möglichkeiten in Bezug auf Datenflüsse eingegangen werden.

Stream-orientierte Sprachkonstrukte (wie beispielsweise in Java oder in Kotlin vorhanden), sollen betrachtet werden, um an dieser Stelle aufzuzeigen, wie diese Sprachen SQL-Konstrukte zukünftig ablösen können - insbesondere deren Einsatzzweck in Bezug auf die eingangs beschriebenen Datenflüsse aus oder auf Geräten vorgestellt werden.

Dieser Talk verspricht somit eine spannende Reise durch die Entwicklung von Daten(-haltungsmöglichkeiten) hin zu modernen "state-of-the-art"-Aspekten (Kafka, Kotlin etc.) von Datenflüssen und deren Auswirkungen auf Software-Architekturen.

Holger Tiemeyer hat an der Universität Hamburg Informatik mit Nebenfach Psychologie studiert.
Er realisiert in der Rolle als Senior Software-Architekt unterschiedliche Projekte in verschiedenen Enterprise-Kontexten bei der AUSY Technologies Germany AG. Seine Hauptaufgabe liegt in dem Entwurf und der Umsetzung von komplexen Software-Architekturen.
Er ist Mitglied im iSAQB e.V. und leitet dort die Arbeitsgruppe Hochschulen.
Holger Tiemeyer
Holger Tiemeyer
Vortrag: Do 1.4
Themen: Architecture
flag VORTRAG MERKEN

Vortrag Teilen

17:00 - 18:00
Do 2.4
From Capabilities to Services: Modelling for Business-IT Alignment
From Capabilities to Services: Modelling for Business-IT Alignment

Service-orientation seems to be in vogue again, this time dressed up as microservices. Many seem to get going with very little plan and thought, running the risk of sliding down the slippery slope towards distributed monoliths. Some experts try to encourage domain-driven design, but that may confuse even more. We crave more guidance. Maybe the classic business capability maps could help?

Target Audience:
Architects, developers
Prerequisites: Some experience with modularisation and enterprises
Level: Basic

Extended Abstract:
Service-orientation is still a surprisingly hard and complicated endeavour after all these years and the risk of getting it wrong, potentially ending up with a distributed monolith with its tight coupling, fragility, and high cognitive load, is still very real to many. Our industry is fairly immature and moves so fast that internalising acquired knowledge seems difficult and we often go through cycles of re-discovery of findings made decades ago. Maybe some SOA practitioners from the previous attempts made some breakthroughs that we have missed as we now have another go with microservices?

The concept of business capabilities from business architecture can be one approach to take a closer look at, with its holistic outside-in perspective of the company. The capability vantage point inherently abstracts away the 'what' a company does from the 'how' , describing the essence of what the business offers. In this talk we will take a closer look at what they are and what they can help us with, all the way from business strategies and analysis, via organisational design to data management and technical design. They may just be the tool we need to design services, micro or not, as parts in a business aligned sociotechnical system, where people, information, processes, and technology are jointly driving business outcomes.

Trond Hjorteland is an IT architect and aspiring sociotechnical systems designer from the consulting firm Scienta.no and has many years experience with large, complex, and business critical systems, primarily as a developer and architect on middleware and backend applications. His main interests are service-orientation, domain-driven design, event-driven architectures, and sociotechnical systems, working in industries like telecom, media, TV, and public sector. Mantra: Great products emerge from collaborative design.
Trond Hjorteland
Trond Hjorteland
Vortrag: Do 2.4
Themen: Architecture
flag VORTRAG MERKEN

Vortrag Teilen

17:00 - 18:00
Do 5.4
The Future Is Already Here?
The Future Is Already Here?

When we look at where we are now with software development and applications, we can see the roots of today's world in the past. Ideas in current practice are not new, they are just more popular — machine learning, (micro)services, DevOps, Agility, etc. And some things have always been promised as revolutionary but have never taken centre stage, such as the story of CASE tools, MDA, AOP and generative programming. We trace back through time to examine these trends so that we can go forward. What are we seeing now that will be our future?

Target Audience:
Anyone interested in developing and delivering software
Prerequisites: Experiences in software architecture and development
Level: Advanced

Extended Abstract:

Science fiction author William Gibson said that "The future is already here — it's just not very evenly distributed." When we look at where we are now with software development and applications, we can see the roots of today's world in the past. Ideas in current practice are not new, they are just more popular — machine learning, (micro)services, DevOps, functional programming, Agile development, etc. And some things have always been promised as revolutionary but have never taken centre stage, such as the story of CASE tools, MDA, AOP and generative programming. We trace back through time to examine these trends so that we can go forward. What are we seeing now that will be our future?

Kevlin Henney is an independent consultant, speaker, writer and trainer. His development interests are in patterns, programming, practice and process. He is co-author of “A Pattern Language for Distributed Computing” and “On Patterns and Pattern Languages”, two volumes in the Pattern-Oriented Software Architecture series, and editor of “97 Things Every Programmer Should Know” and “97 Things Every Java Programmer Should Know”.
Frank Buschmann ist Senior Principal Engineer bei Siemens Corporate Technology in München. Dort erforscht er moderne Software-Architektur und Entwicklungsansätze für die industrielle Digitalisierung. Die Produktentwicklung unterstützt Frank bei der effizienten Anwendung dieser Technologien. Seine aktuellen Forschungsschwerpunkte sind Architekturen für Cyber-Physikalische Systeme, das Internet of Things, Intelligente Systeme sowie industrielles DevOps. Frank ist Co-Autor von vier Bänden der von John Wiley & Sons veröffentlichten 'Pattern-Oriented Software Architecture'.
Kevlin Henney, Frank Buschmann
Kevlin Henney, Frank Buschmann
flag VORTRAG MERKEN

Vortrag Teilen

17:00 - 18:00
Do 7.4
Gute Legacy? Schlechte Legacy?
Gute Legacy? Schlechte Legacy?

Seit über sechzig Jahren bauen wir Software, die immer größer und komplexer wird. Inzwischen haben wir nicht nur Mainframe-Altsysteme, sondern auch die Systeme in objektorientierten Programmiersprachen sind in den letzten zwanzig Jahren so schnell und immer wieder unkontrolliert gewachsen, dass sie zu einem großen Knäul geworden sind. All dieser Legacy-Code treibt die Entwicklungskosten in die Höhe und führt dazu, dass wir diese alten Softwaresysteme nicht mehr gerne anfassen. Ist das unvermeidbar? Oder gibt es auch gute Legacy?

Zielpublikum: Architekt:innen, Entwickler:innen, Projektleiter:innen, Management, Entscheider:innen
Voraussetzungen: Projekterfahrung
Schwierigkeitsgrad: Fortgeschritten

Dr. Carola Lilienthal ist Geschäftsführerin bei der WPS Workplace Solutions GmbH. Sie hat an der Universität Hamburg studiert und dort zum Thema "Komplexität von Software-Architekturen" promoviert. Seit 2003 analysiert sie im Auftrag ihrer Kunden in ganz Deutschland regelmäßig die Zukunftsfähigkeit von Software-Architekturen und spricht auf Konferenzen über dieses Thema.
Carola Lilienthal
Carola Lilienthal
flag VORTRAG MERKEN

Vortrag Teilen

17:00 - 18:00
Do 9.4
Agile Threat Modeling: Bedrohungsmodellierung als Teil von DevSecOps
Agile Threat Modeling: Bedrohungsmodellierung als Teil von DevSecOps

Agile Software-Entwicklung und kontinuierliches Threat Modeling: Geht das? Ja, und zwar ganz getreu dem DevSecOps-Sinne mittels “Threat-Model-as-Code”!

Sehen Sie in dem Talk die Ideen hinter diesem Ansatz: Entwicklerfreundliches Bedrohungsmodellieren direkt aus der IDE heraus, ganz stilecht mit einer Live-Demo mittels Open-Source-Werkzeugen: In IDEs editierbare und in Git diffbare Modelle, interaktive Modellerstellung, automatisch regel-basiert abgeleitete Risiken sowie grafische Diagramm- und Reportgenerierung inkl. Mitigationsmaßnahmen.

Zielpublikum:
Architekt:innen, Entwickler:innen, Security Consultants
Voraussetzungen: Architekturerfahrung & Security-Interesse
Schwierigkeitsgrad: Fortgeschrittee

Extended Abstract:
Nachdem die Herausforderung, Security in agile Projektmethoden und DevOps-Verfahren zu integrieren, mittels DevSecOps angegangen wurde, steht direkt das nächste Integrationsproblem vor der Tür: Bedrohungsmodellierung!

Wenn wir durch Pipeline-as-Code zuverlässig, reproduzierbar und jederzeit schnell unsere Software bauen können und nun auch durch passende Werkzeuge Securityscans automatisiert haben, wie können wir dann die Risikolandschaft unserer Projekte ebenfalls schnell erfassen?

Eigentlich geschieht so etwas in aufwendigen Workshops mit viel Diskussion sowie Modellarbeit am Whiteboard mit Kästchen, Pfeilen & Wölkchen. Diese Veranstaltungen sind durchaus sinnvoll und wichtig, da nur mit dieser Tiefe manche Bedrohungen in einer Architektur rechtzeitig erkannt werden. Schade nur, dass es meistens dann auch aufhört: Anstelle eines lebenden Modells entsteht ein langsam aber sicher erodierendes Artefakt.

Um diesem Verfallsprozess entgegenzuwirken, muss etwas Kontinuierliches her, etwas wie "Threat-Model-as-Code" im DevSecOps-Sinne. Sehen Sie in diesem Talk die Ideen hinter diesem Ansatz: Agiles und entwicklerfreundliches Bedrohungsmodellieren direkt aus der IDE heraus — ganz stilecht mit einer Live-Demo mittels Open-Source-Werkzeugen.

Ergebnis? In Entwickler-IDEs editierbare und in Git diffbare Modelle, automatisch regel-basiert abgeleitete Risiken inklusive grafischer Diagramm- und Reportgenerierung mit Mitigationsmaßnahmen. Die Architektur ändert sich? Ein erneuter Lauf liefert die aktuelle Risikosicht …

Christian Schneider ist als freiberuflicher Whitehat Hacker, Trainer und Security-Architekt tätig. Als Software-Entwickler mit über 20 Jahren Erfahrung fand er 2005 seinen Themenschwerpunkt im Bereich IT-Security. Er berät DAX-Konzerne und mittelständische Unternehmen im Bereich der sicheren Software-Entwicklung durch Security Architecture Consulting und Penetrationtesting. Sein aktuelles Lieblingsthema ist agiles Threat Modeling im Rahmen von DevSecOps.
Christian Schneider
Christian Schneider
flag VORTRAG MERKEN

Vortrag Teilen

18:30 - 20:00
Ndo 1
Architekturmuster im Team vereinbaren
Architekturmuster im Team vereinbaren

Architektur ist das, was man einführt und dann nicht mehr so leicht ändern kann, richtig? Also sollten Teams gut überlegen, welche Architekturmuster sie einsetzen und diese dann konsequent durchhalten. Mit dieser "rule of least surprise" lässt sich die Software gut weiterentwickeln.

Doch wie vereinbart man in einem selbstorganisierten Team nützliche Muster? Matthias zeigt an Beispielmustern und an Quellcode, wie Teams Architekturmuster für sich selbst definieren, die ihrer Plattform und ihren Skills angemessen und im Team breit akzeptiert sind.

Zielpublikum: Architekt:innen, Entwickler::innen
Voraussetzungen: Erfahrung in der Software-Entwicklung, erlittener Schmerz beim Lesen fremden Codes
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Was in einem Team gute Architektur ist, muss es für ein anderes Team noch lange nicht sein. Ich möchte Teams ermöglichen, gute Architektur-Ansätze auf dem Markt zu studieren und sie dann auf eigene Situation und Bedürfnisse anzupassen.

Als Beispiele bringe ich die 9 Standardbausteine aus dem Domain-Driven Design (Entity, Value Object, Service usw.), verbunden mit einer Ports&Adapters-Struktur (Port, Adapter, primary, secondary ...).

An sich sind diese Muster bewährt und gut – nur sollte man sie nicht einfach "irgendwie" realisieren oder 1:1 von einer Konferenz übernehmen, sondern auf die eigene Plattform- und Team-Situation abbilden und dazu einen Team-Beschluss herbeiführen.

Die Muster werden dann eher von allen getragen und eingehalten, was der Qualität sehr förderlich ist.

Matthias Bohlen spent 20 years as a software developer, followed by almost another 20 years as a freelance consultant for software engineering and as a trainer for software architecture and domain-driven design. He worked with many agile teams who want to produce good software in reasonable time with superb quality, without going nuts in that process!
Matthias Bohlen
Matthias Bohlen
Vortrag: Ndo 1
Themen: Architecture
flag VORTRAG MERKEN

Vortrag Teilen

, (Freitag, 12.Februar 2021)
09:00 - 16:00
Fr 3
(AUSGEBUCHT) Designing Bounded Contexts for Microservices Using Visual Collaboration
(AUSGEBUCHT) Designing Bounded Contexts for Microservices Using Visual Collaboration

There is an industry trend where businesses are moving towards autonomous product teams. These teams aim to be end-to-end responsible for the product they are building and maintaining. To achieve end-to-end team autonomy, companies move towards a microservices architecture to successfully inspect and adapt. However, to be successful organisations need to have the correct boundaries for the microservices. Using the bounded context pattern from Domain-Driven Design it is possible to achieve team autonomy!

Maximum number of participants: 24

Target Audience: Architects, Developers, Testers, Analysts, Product Owner, Manager, Decision Makers
Prerequisites: None. It is an interactive workshop, with brown paper, post-its and whiteboards
Level: Basic

Extended Abstract:
There is an industry trend where businesses are moving towards autonomous product teams. These teams aim to be end-to-end responsible for the product they are building and maintaining. With the help of Continuous Delivery, teams have faster feedback cycles in which they can probe if a certain feature works. To achieve end-to-end team autonomy, companies move towards a microservices architecture to successfully inspect and adapt. To be effective with a microservices architecture, we require Conway's alignment, engineering teams aligned to business models/products; to achieve Conway’s alignment it’s required to design and model the domain. Domain-Driven Design’s bounded context is the essential pattern that helps to create Conway’s alignment.

Join us in this hands-on session where we show you how visual collaboration is the most effective way in co-creating sustainable Conway’s alignment. We will distil bounded contexts with visual collaboration tools Big Picture EventStorming, Context Mapping and the Bounded Context Canvas.

With visual collaboration:


- We create a shared understanding of the business flow, uncovering inconsistencies and competing goals

- Using the Theory of Constraints, we can discover, highlight and create a shared vision and strategy to focus our effort

- A critical part of doing visual collaboration is effective facilitation, especially facilitating workshops with +30 people at the same time

You leave our session understanding that to be effective with microservices, you need to start discover and design bounded contexts. You will learn heuristics that guide you in using visual tools in specific situations, and how to move on towards microservices.

João Rosa believes that empowered teams working in a network-based system are the future of organisations. He uses Domain-Driven Design, Visual Collaboration Tools and Teal organisation principles to help companies to move to new operating models.
Leveraging Deep Democracy, Domain-Driven Design, Continuous Delivery and visual collaborate tools, Kenny Baas-Schwegler empowers organisations, teams and people in building valuable software products.
João Rosa, Kenny Baas-Schwegler
João Rosa, Kenny Baas-Schwegler
flag VORTRAG MERKEN

Vortrag Teilen

Zurück