Track: Software Architecture: New Approaches & Fundamentals
- Dienstag
07.02. - Mittwoch
08.02. - Donnerstag
09.02.
Software-Architektur ist allgegenwärtig. Trotzdem gibt es in vielen Organisationen kaum eine weitgehend anerkannte Definition der Rolle. Somit stellt sich die Frage, wie wir feststellen können, ob wir unseren Job "gut" machen.
In diesem Vortrag werden wir konkrete Wege kennenlernen, wie wir Architekturarbeit effektiv gestalten können. Wir streifen Themen wie Dokumentation, Entscheidungsfindung, Kommunikation und Skillset. Außerdem lernen wir Prinzipien kennen, die uns im Alltag als Software-Architekten eine Stütze sein können.
Zielpublikum: Software-Architekt:innen, Software-Entwickler:innen, Manager, Entscheider
Voraussetzungen: Grundwissen in Software-Entwicklung und -Architektur
Schwierigkeitsgrad: Anfänger
Extended Abstract:
Die Rolle von Software-Architekten ist in vielen Organisationen nicht klar oder gar explizit definiert, geschweige denn gibt es eine Definition der Rolle, die allgemein anerkannt ist und entsprechend gelebt wird. Oft fehlt für diese Rolle im Berufsalltag eine klare Zielsetzung. Somit stellt sich die Frage, wie wir feststellen können, ob wir unseren Job "gut" machen.
Wir könnten nun versuchen, den Rollenbegriff von Software-Architekten bestmöglich zu schärfen. Doch ist das wirklich zielführend? Gerade in der Software-Entwicklung haben wir mit unterschiedlichsten Kontexten zu tun, die sich obendrein ständig ändern. Das macht eine einheitliche Definition der Rolle umso schwieriger.
Ein anderer Ansatz wäre, dass wir von Good Practices und (mehr oder weniger) etablierten Prinzipien ausgehen, um unseren Berufsalltag effektiv zu gestalten. Der Vorteil dieses Ansatzes ist, dass wir kontextspezifisch entscheiden können, welche Prinzipien für uns passen. Somit ergibt sich die Jobbeschreibung von Software-Architekten nicht aus einer allgemein gültigen Definition, sondern immer aus konkreten, kontextabhängigen Richtlinien.
Die Good Practices und Prinzipien versuchen wir im Vortrag aus folgenden Fragen abzuleiten:
- Sollte man in der Rolle als Software-Architekt coden?
- Ist breites oder tiefes technisches Wissen wichtiger?
- Wie viele Vorgaben sollen effektive Architekturentscheidungen machen?
- Wann ist der beste Zeitpunkt, um Architekturentscheidungen zu treffen?
- Wie viel Kontrolle soll man in der Rolle als Software-Architekt ausüben?
- Sollte man Top-Down oder Bottom-Up vorgehen?
- Wie kann man die Zielerreichung von Software-Architektur unter ständiger Veränderung sicherstellen?
- Sollte es die Rolle "Software-Architekt" überhaupt geben?
Aufgrund der oben erwähnten kontextspezifischen Unterschiede der Architekturrolle soll dieser Vortrag Raum für Interaktion bieten, um die Fragestellungen aus verschiedenen Gesichtspunkten durchleuchten zu können.
Teilnehmer sollen die Session mit Anregungen zum Nachdenken verlassen, wie sie ihre eigene Architekturarbeit effektiver gestalten können.
Alexander Kaserbacher ist Berater für Software-Architektur bei embarc. Mehrjährige Erfahrungen aus der agilen Software-Entwicklung helfen ihm dabei, den Mehrwert von Software-Architektur zu vermitteln und diese effektiv umzusetzen. Neben Cloud-Anwendungen, Microservices und evolutionärer Architektur umfasst seine Leidenschaft für Technologie auch die verschiedensten Auswirkungen von Software auf Unternehmen und gesellschaftliche Faktoren.
Mal angenommen, es gäbe ein (natürlich fiktives) Großprojekt zur Implementierung einer Microservices-Architektur. Die Entwickler:innen sind in zahlreichen Teams organisiert. Zudem gibt es ein übergreifendes Architekturgremium. Selbstverständlich wird auch ein proprietäres Framework programmiert. In jedem Team existiert die Rolle des "Technischen Architekten".
Kommt Ihnen das bekannt vor? Und haben Sie sich auch schon öfters gefragt, was er/sie eigentlich die ganze Zeit macht? In diesem unterhaltsamen Praxisbericht können Sie es herausfinden.
Zielpublikum: Entwickler:innen, Architekt:innen, Manager
Voraussetzungen: Keine
Schwierigkeitsgrad: Fortgeschritten
Extended Abstract:
Tatsächlich erscheint es für viele Projektmitarbeitende immer wieder fraglich, was der/die Technical Software Architect eigentlich den ganzen Tag so macht. Scheinbar werden doch die Architekturvorgaben vom dafür verantwortlichen Gremium erarbeitet. In der Praxis ist es jedoch oft so, dass tatsächlich zahlreiche Themen anstehen.
Dazu zählt die Bewertung der Folgen solcher Technologievorhaben für das eigene Team, genauso wie der Versuch der Beeinflussung des Gremiums bei der Entscheidungsfindung. Hinzu kommen diverse "politische" Themen oder die Sicherstellung der Einhaltung von Architekturvorgaben und der Softwarequalität. Über die Jahre habe ich hier eine Reihe sehr interessanter und oftmals auch (rückblickend) amüsanter Erfahrungen gemacht, die ich gerne weitergeben möchte.
Thilo Frotscher arbeitet als freiberuflicher Software-Architekt und Trainer. Als Experte für Java, APIs und Systemintegration unterstützt er seine Kunden überwiegend durch die Mitarbeit in Projekten, Reviews oder die Durchführung von Schulungen. Thilo ist (Co-) Autor mehrerer Bücher in den Bereichen Java, (Web-) Services und Systemintegration, hat zahlreiche Fachartikel verfasst und spricht regelmäßig auf Fachkonferenzen und Schulungsveranstaltungen sowie bei Java User Groups.
Vortrag Teilen
Vortrag Teilen
Vor drei Jahren als Idee gestartet, gibt es heute viele Produkte & Unternehmen im Data-Bereich, die mit dem Mesh werben. Höchste Zeit zu schauen: Was ist die Kernidee? Welche Probleme soll es eigentlich lösen?
Was ist der Unterschied zwischen Mesh und Data Lake & Data Warehouse? Wie kann es technologisch umgesetzt werden und welche weiteren Bereiche müssen angegangen werden: Organisatorische Aspekte wie Teamschnitt & Skills, Abstimmung zwischen Teams und notwendige Skills in Produkt- und Entwicklerteams.
Zielpublikum: Architekten:innen, Entscheider
Voraussetzungen: Grundlegende Erfahrungen mit Datenarchitekturen, insbesondere für analytische Zwecke
Schwierigkeitsgrad: Fortgeschritten
Extended Abstract:
Die bessere Nutzung von Daten im Unternehmen ist schon seit Langem ein viel diskutiertes Thema. In diesem Kontext entstand die Idee des Data Mesh. In diese Session wird diese Idee nach einer kurzen Vorstellung kritisch hinterfragt: Wo sind Chancen? Wo sind Nachteil zu sehen? Insbesondere im Vergleich zu den bisherigen Konzepten, wenn es um die Bereitstellung und Nutzung von Daten für analytische Zwecke geht: Dem Data Warehouse und einem Data Lake.
So kommen wir in dem Talk auch zu der Frage, welche Unternehmen und Organisation die Prinzipien des Data Mesh näher betrachten sollten. Und wer diesen Hype auch getrost ziehen lassen kann.
Matthias Niehoff ist als Data Architect sowie Head of Data & AI für die codecentric unterwegs und unterstützt Kunden bei Design und Umsetzung von Datenarchitekturen. Dabei liegt sein Fokus weniger auf dem Modell, sondern viel mehr auf der notwendigen Infrastruktur & Organisation, um Daten & KI-Projekten zum Erfolg zu verhelfen.
Vortrag Teilen
Many approaches to software architecture assume that architecture be planned at the beginning from the project's quality goals. This is problematic as the macroarchitecture is hard to change, and the quality goals it's based on tend to be unknown at the beginning of a project, or change later. Consequently, it would really be preferable if we could defer the macroarchitectural decisions until later.
This talk shows how to do this using systematic modelling and functional programming.
Target Audience: Developers, Architects
Prerequisites: Basic architecture knowledge
Level: Advanced
Extended Abstract:
What should we do first then? We should write down what we know, at the time we know it, and do it in such a way that we generate reusable components that can be assembled into any macroarchitecture.
Concretely, this can be done by using staple techniques from functional programming:
• building small, flexible combinators instead of fixed attribute-structure OO models
• decoupling pervasively using abstraction
• using immutability to avoid hidden dependencies
The talk shows how to do this, and report on our experience in several concrete projects.
Michael Sperber is CEO of Active Group in Tübingen, Germany. Mike specializes in functional programming and has been an internationally recognized expert in the field: He has spoken at the top conferences in programming languages, authored many papers on the subject as well as several books. Moreover, he is an expert on teaching programming.
Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/michael.sperber
Vortrag Teilen
Integrationsarchitekturen sind der entscheidende Schlüssel in einer sich schnell entwickelnden Welt. Dabei ändern sich sowohl Geschäftsmodelle als auch technologische Grundlagen schnell und nachhaltig. Wir können aber nicht bei jeder Änderung die Software neu auf der grünen Wiese entwickeln.
Der Beitrag diskutiert den Prozess des Architekturdesigns und typische Integrationsmuster in hybriden Cloud- und On-Promise-Umgebungen.
Zielpublikum: Entwickler:innen, Architekt:innen
Voraussetzungen: Prinzipielle Architekturkenntnisse
Schwierigkeitsgrad: Anfänger
Extended Abstract:
1. Entwicklung einer Architekturvision mit Domain Storytelling und Event Storming
2. Anwendung der Vision in der realen Welt
3. Allgemeine Architekturmuster für Integrationen
4. Eventintegration für Server-zu-Server-Integrationen
5. REST-Integrationen für Benutzerzugriffen
6. Take Aways
Annegret Junker ist Lead Architect bei Allianz Deutschland. Sie arbeitet seit mehr als 30 Jahren in der Software-Entwicklung in unterschiedlichen Rollen und unterschiedlichen Domänen wie Automotive, Versicherungen und Finanzdienstleistungen. Besonders interessiert sie sich für DDD, Microservices und alles, was damit zusammenhängt. Derzeit arbeitet sie in einem großen Versicherungs-Projekt als übergreifende Architektin.
Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/Annegret.Junker
Vortrag Teilen
API Expand Contract ist ein Pattern zur Weiterentwicklung von APIs. Aber was verbirgt sich hinter der Idee? Wie kann ich damit eine API weiterentwickeln, ohne dass Client und/oder Server im Wartungsaufwand alter Schnittstellen(-Versionen) ersticken?
In der Realität erweist sich Management von APIs und deren Versionen als gar nicht so einfach. Diese Session zeigt mögliche Wege und Alternativen, um der Versionierungshölle zu entkommen und dabei das oberste Gebot beim API-Design - nämlich „Don’t break the Client“ - jederzeit einzuhalten.
Zielpublikum: Architekt:innen, Entwickler:innen, Projektleiter:innen
Voraussetzungen: Kenntnisse in der API-Entwicklung, Projekterfahrung
Schwierigkeitsgrad: Fortgeschritten
Extended Abstract:
Der Thoughtworks-Technologie-Radar empfiehlt, das Pattern „Expand-Contract“ auf APIs anzuwenden.
Aber was verbirgt sich hinter der Idee?
Und wie kann ich das in der Praxis realisieren?
Wie kann ich sicherstellen, dass trotz Weiterentwicklung alle meine Clients weiterhin funktionieren und dennoch APIs unabhängig vom Server aktualisiert werden können - und das Ganze am besten ohne, dass Client und/oder Server im Wartungsaufwand alter Schnittstellen(-Versionen) ersticken?
Welche Versionierungsstrategie sollte ich in welcher Situation fahren und wie implementiere ich die verschiedenen Strategien geschickt?
In der Realität erweist sich Management von APIs und deren Versionen als gar nicht so einfach. Diese Session zeigt mögliche Wege und Alternativen, um der Versionierungshölle zu entkommen und dabei das oberste Gebot beim API-Design - nämlich „Don’t break the Client“ - jederzeit einzuhalten.
Arne Limburg ist Lead Architect bei der open knowledge GmbH in Oldenburg. Er verfügt über mehrjährige Erfahrung als Entwickler, Architekt und Trainer im Enterprise- und Microservices-Umfeld. Zu diesen Bereichen spricht er regelmäßig auf Konferenzen und führt Workshops durch. Darüber hinaus ist er im Open-Source-Bereich tätig, unter anderem als PMC Member von Apache Meecrowave, Apache OpenWebBeans und Apache DeltaSpike und als Urheber und Projektleiter von JPA Security.
Microservices sind der Hammer, aber nicht alles ist ein Nagel. Trotzdem ist man leicht in der Versuchung, immer diesen Hammer auszupacken, wenn man eine gut modularisierte Software-Architektur zimmern will. Genau das hatten wir mit unserem System auch vor. Wir erzählen euch die Geschichte, warum wir unsere erste Entscheidung revidiert und mit modularen Monolithen ein passenderes Architektur-Werkzeug für uns gefunden haben.
Zielpublikum: Architekt:innen, Entwickler:innen
Voraussetzungen: Grundlagen zu Architektur- und Designpatterns
Schwierigkeitsgrad: Fortgeschritten
Extended Abstract:
Woran lässt sich erkennen, ob das jeweilige Architekturproblem in die Kategorie „Nagel“ fällt oder nicht? Das kommt auf die Rahmenbedingungen an: Hat man die Domain schon so gut verstanden, dass die Modellgrenzen oder „Bounded Contexts“ klar sind? Ist es wichtig, einzelne Bausteine unabhängig ausrollen zu können? Wenn nicht, können Modulare Monolithe anstelle von Microservices zwei Vorteile bringen: Erstens verbinden sie ein einfaches Deployment mit einer fachlichen Modularisierung. Damit gewinnt man die Flexibilität, den Code einfach umzubauen. Zweitens spart man sich den Verwaltungs-Overhead von Microservices, ohne dabei den Weg zu einer stärkeren Trennung zu verbauen.
Das klingt attraktiv, aber der Teufel steckt im Detail. Wie stellt man sicher, dass die einzelnen Module getrennt bleiben und kein „Big Ball of Mud“ entsteht? Wie kann man auf der anderen Seite eine Kommunikation zwischen den Modulen erlauben, um fachliche Abhängigkeiten abzubilden?
Wir zeigen euch an unserem System, wie wir die Trennung der fachlichen Module, aber auch die Kommunikation zwischen ihnen umgesetzt haben, auf welche Probleme wir gestoßen sind, welche Lösungen wir gefunden haben und welche Kompromisse wir eingegangen sind.
Damit möchten wir euch einen Eindruck vermitteln, welche Herausforderungen wir mit dem Werkzeug „Modularer Monolith“ meistern konnten, damit ihr es ebenfalls in euren Architektur-Werkzeugkoffer aufnehmen könnt.
André Kappes ist seit 2015 Software Craftsman aus Leidenschaft. Auf seiner Suche, wie man handwerklich gute Software entwickelt, sammelt er immer wieder neue Erkenntnisse rund um Clean Code und Test-driven development, um Software-Architektur, Domain-Driven Design und Continuous Delivery. Zu seinem Glück hat er in jedem seiner bisherigen Projekte zuhauf spannende Fragen gefunden und neue Einsichten bekommen. Er begleitet derzeit ein internes Ausbildungsprojekt als technischer Coach.
Vortrag Teilen
Vortrag Teilen
With GraphQL a modern and flexible way of providing APIs for our data is emerging.
The clients specify which data they need, the provisioning of data becomes more flexible and dynamic. Over-fetching or under-fetching are history.
But does this mean we have to rewrite all APIs to benefit? How can we retrofit a GraphQL API onto our existing API landscape?
We will explore three different approaches.
Target Audience: Architects, Developers
Prerequisites: Basic knowledge in API design and Java
Level: Advanced
Extended Abstract:
In this talk we explore three different alternatives:
- The Developer Way: Writing a GraphQL API layer by hand
- The Cloud-native Way: Using lightweight API gateways such as Gloo or Tyk
- The Serverless Way: Using Cloud Provider native services
We will look at all three approaches conceptually and justify when and why each makes sense. Additionally, we will show in a live demo how GraphQL APIs can be added to an existing REST API.
Sonja Wegner is Lead Software Architect at QAware. Her current focus is on design and implementation of complex systems and software architectures.
Stefan Schmöller is Senior Software Engineer at QAware. He is mainly interested in Java frameworks and microservice architectures.
Vortrag Teilen
How to structure your program right? This has been a central question since the beginning of software development. Layers are a start, but not enough. Hexagonal, Onion, and Clean Architecture have joined the club together with DDD's Tactical Design and Pattern Languages. Great system design is not achieved with one of these alone. Putting all the ingredients together we can build the Architecture Hamburger – the combination that makes high quality software possible.
Target Audience: Architects, Developers
Prerequisites: Experience in mid-size to large projects
Level: Advanced
Henning Schwentner loves programming in high quality. He lives this passion as coder, coach, and consultant at WPS – Workplace Solutions in Hamburg, Germany. There he helps teams to structure their monoliths or to build new systems from the beginning with a sustainable architecture. Microservices or self-contained systems are often the result. Henning is author of “Domain Storytelling – A Collaborative Modeling Method” and the www.LeasingNinja.io as well as translator of “Domain-Driven Design kompakt”.
Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/henning.schwentner
Vortrag Teilen
One of the fundamental strategies of Agile Modeling is that artifacts, including architecture models, should be just barely good enough (JBGE). Another way of saying this is your models should be sufficient for the task at hand, no more and no less. But sufficiency is contextual in nature, it depends.
In this session we will look at the issue of model sufficiency, exploring the risk factors that motivate us to model more as well as the conditions that enable us to model less.
Target Audience: Software Architects, Software Developers
Prerequisites: Basic knowledge of agile, understanding of software architecture
Level: Advanced
Extended Abstract:
One of the fundamental strategies of Agile Modeling is that artifacts, including architecture models, should be just barely good enough (JBGE). Another way of saying this is your models should be sufficient for the task at hand, no more and no less. But sufficiency is contextual in nature, it depends.
In this session we will look at the issue of model sufficiency, exploring the risk factors that motivate us to model more as well as the conditions that enable us to model less. We model to think things through, to identify potential avenues for moving forward so that we can choose what we believe to be the most likely path for success. But the more effort we spend doing so potentially motivates us to make commitments earlier than we should and to lose time, and value, doing so. Balancing these tensions is how we determine model sufficiency in the context that we face. Proven agile architecture strategies that enable us to invest in less up-front modeling will also be explored. It's never just about modeling.
Agenda:
1. Architecture throughout the agile lifecycle.
2. What is initial architecture modeling?
3. What does it mean to be just barely good enough (JBGE)?
4. What risk factors motivate us to invest in more up-front modeling?
5. What factors enable us to invest in less up-front modeling?
6. What are the development practices that support an agile approach to architecture?
Scott Ambler is the Chief Methodologist of Ambysoft Inc. He is the creator of the Agile Modeling and Agile Data methods, as well as co-creator of PMI's Disciplined Agile tool kit. He has worked with organizations around the world to improve their software development ways of working (WoW). Scott is an award-winning author of 20+ books and an international keynote speaker.
Vortrag Teilen
In a microservices architecture, services shall be as loosely coupled as possible. Still, they need to communicate with each other in order to fulfill business requirements. This talk will help you shape an answer for the typical questions (like shall I be synchronous or asynchronous and what's a good protocol to use?). You will better understand not only the architectural implications but also the effect on the productivity of your teams.
Target Audience: Developers, Architects
Prerequisites: Basic programming skills helpful
Level: Advanced
Extended Abstract:
In a microservices architecture, services shall be as loosely coupled as possible. Still, they need to communicate with each other in order to fulfill business requirements. Now there are so many questions about this communication:
• What are the general possibilities to communicate? For example, synchronous, asynchronous, or event-driven communication. What are the tradeoffs and which communication style should you prefer?
• What is the influence on the coupling of your services? For example, asynchronous communication reduces temporal coupling between services.
• What do I have to consider when selecting a certain communication style?
For example, you need to apply certain resilience patterns if you want to use synchronous communication.
This talk will help you answer these questions for your project. You will better understand not only the architectural implications but also the effect on the productivity of your teams.
Bernd Rücker is a software developer at heart who has been innovating process automation deployed in highly scalable and agile environments of industry leaders such as T-Mobile, Lufthansa, ING, and Atlassian. He contributed to various open-source workflow engines for more than 15 years and he is the Co-Founder and Chief Technologist of Camunda – an open-source software company reinventing process automation. He is the author of "Practical Process Automation" and co-author of "Real-Life BPMN".
Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/bernd.ruecker
Vortrag Teilen
APIs sind die Bindeglieder moderner Architekturen und nicht selten integriert ein System APIs im zweistelligen Bereich. Damit die API-Integration nicht zur Irrfahrt wird, unterstützen API-Guidelines die Developer Experience. Mit einem Blick auf öffentliche Guidelines und APIs gibt der Vortrag einen Eindruck von der allgemeinen Situation und liefert Impulse für das eigene API-Management. Da es in der Regel zu kurz gegriffen ist, einfach öffentliche API-Guidelines zu referenzieren, geben wir Tipps für eigene API-Guidelines und deren Etablierung.
Zielpublikum: Architekt:innen und Entwickler:innen
Voraussetzungen: Erfahrung oder Interesse am Design von Remote APIs
Schwierigkeitsgrad: Anfänger
Extended Abstract:
APIs sind die Bindeglieder unserer modernen, verteilten Systemarchitektur und nicht selten liegt die Anzahl der APIs im zweistelligen Bereich, wenn ein System integriert werden muss. Damit der Überblick gelingt und die API-Integration nicht zur Irrfahrt wird, unterstützen API Style Guidelines bei einer besseren Developer Experience und sind ein wichtiger Bestandteil der API Governance.
Mit einem Blick auf öffentlich zugängliche API-Guidelines und der Analyse öffentlicher APIs werden wir uns einen Eindruck von der allgemeinen Situation verschaffen und liefern Impulse für das eigene API-Management und -Design.
Hierüber wird auch schnell klar, warum es in der Regel zu kurz gegriffen ist, einfach eine öffentliche API-Guideline zu referenzieren. Deshalb werden wir auch Wege zur eigenen API-Design-Guideline aufzeigen und Tipps geben, die bei der Etablierung im Unternehmen helfen werden.
Benjamin Klatt ist Integrationsarchitekt und Agile Coach. Seine Schwerpunkte liegen in der Digitalisierung von Produkten und Prozessen, Integrationsarchitekturen sowie neuen Arbeitsweisen.
Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/benjamin.klatt
Constanze Klaar ist IT-Beraterin mit Fokus auf der Entwicklung von Java-basierten Enterprise-Anwendungen. Seit vielen Jahren setzt sie sich mit dem Design guter APIs und API-Management auseinander.
Vortrag Teilen
Eine der größten Herausforderungen im Systems Engineering ist die viel beschworene Beherrschung der Komplexität. Bisher in der Praxis etablierte Ansätze betrachten die Strukturierung von Anforderungen und die Dokumentation der Realisierung durch die entsprechenden Architekturelemente. Aber was ist mit den Testfällen, dem Feature-Tree für Produktvarianten und der Organisationsstruktur? Diese Strukturen gilt es im Rahmen der Systementwicklung angemessen zu berücksichtigen und nachvollziehbar mit anderen Arbeitsergebnissen in Beziehung zu setzen.
Zielpublikum: Entwickler:innen, Architekt:innen, Requirements-Engineers, Systems Engineers
Voraussetzungen: Verständnis zum Zusammenspiel der Entwicklungsdisziplinen
Schwierigkeitsgrad: Experte
Extended Abstract:
Bei der Entwicklung von komplizierten technischen Systemen treffen unterschiedliche Disziplinen wie Anforderungs- und Architekturentwicklung, Test und Abnahme etc. aus verschiedenen Gewerken (Software- und Hardwareentwicklung) aufeinander. Trotz unterschiedlicher Ausrichtungen und Schwerpunkte leisten alle Beteiligten einen Beitrag in Form von Arbeitsergebnissen zum fertigen Produkt. Jedoch unterscheiden sich diese Arbeitsergebnisse häufig in ihrer Darstellung, betrachten aber letztlich doch das gleiche System und stehen dadurch inhaltlich in einem Zusammenhang.
Eine wesentliche Herausforderung ist es, diese Zusammenhänge in den Arbeitsergebnissen (Anforderungen, Architekturdokumentation, Testfälle etc.) transparent zu machen und zu nutzen, um dadurch disziplinen- und gewerkübergreifend eine durchgängige Systementwicklung zu gewährleisten. Für Anforderungen und Architekturdokumentationen haben sich dafür sowohl das Twin-Peaks-Modell als auch das SPES 2020-Framework mit dem RFLP-Ansatz etabliert. Beide Modelle vernachlässigen allerdings weitere Disziplinen der Systementwicklung wie z. B. Integration, Test und Abnahme oder das Produkt- und Portfoliomanagement und verzichten auf eine Betrachtung der dabei erzeugten Arbeitsergebnisse. Und wie sind diese Disziplinen eigentlich in der Organisation verortet? Welche Abteilung oder welches Team leistet welchen Beitrag am Gesamtprodukt?
Ziel dieses Vortrages ist es, ein Denkmodell zu vermitteln, das unterschiedliche, graphen- oder baumartige Strukturen und Sichten miteinander in Beziehung setzt, um dadurch typische Probleme in der Systementwicklung wie z. B. unklare Verantwortlichkeiten transparent zu machen und zu lösen. Anhand eines durchgängigen Beispiels erfahren Sie, welche weiteren Sichten neben den Anforderungen und der Architekturdokumentation auf unterschiedlichen Abstraktionsebenen in der Systementwicklung (System, Subsysteme, Komponenten) sinnvoll sein können. Neben einer Motivation, den Inhalten dieser Sichten und deren Wechselwirkungen erhalten Sie einen Einblick, welche Probleme mithilfe dieses Denkmodells gelöst werden können.
Als Berater und Product Owner ist Alexander Barth schon lange im Thema Requirements Engineering tätig. Die Lösungen für den Automotive, Fashion und Sport Bereich beinhalteten immer auch Systeme, die den Workflow der Nutzer:innen unterstützen, Prozesse automatisierten und Daten verarbeiteten.
Der Weg zu diesen Lösungen insbesondere in direkter Zusammenarbeit mit den Kunden:innen und den Teams macht ihm sehr viel Spaß: Problem- oder Zielbeschreibung zu erarbeiten und daraus die Anforderungen zu erstellen; technische Lösungen mit dem Entwicklungsteam zu erarbeiten; Präsentation, und Abnahmen von Spezifikationen, Lieferung von Meilensteinen und finalen Lösungen sowie Trainings sind nur ein paar Punkte auf dem Weg zum Ziel.
Die letzten fünf Jahre in der Projektarbeit gingen einher mit der Transformation zu agileren Arbeitsmethoden. Kern dieser Veränderung war zunächst sein kleines Scrum Team. Nach und nach hat er aber auch die verschiedenen Geschäftsteams an die agile Arbeitsweise, Rollen und Werkzeuge herangeführt und trainiert. Neben diesen praktischen Erfahrungen, ist Alexander Barth auch zertifiziert als Product Owner, Scrum Master und Certified Professional for Requirements Engineering - Foundation Level.
Vortrag Teilen
Software Development based on a distributed architecture provides both several advantages and new challenges. In order to take advantage of the distribution it requires implementation of service discovery, routing, load-balancing, resilience mechanisms and more. These requirements can be covered by language frameworks or the underlying platform.
This talk will walk through a comparison of various approaches with focus on frameworks, Kubernetes and extending options like Service Meshes and eBPF. The talk will be lecture style with demo.
Target Audience: Developers, Architects, DevOps
Prerequisites: Introductory style, basic IT and dev skills probably helpful, but not required
Level: Basic
Extended Abstract:
Software Development based on a cloud-native (or distributed) architecture provides both several advantages and new challenges. In order to take advantage of the distribution it requires implementation of service discovery, routing, load-balancing, resilience mechanisms and more. Initially software frameworks provided dedicated implementations for API Gateways, Service Registries, Circuit Breakers and many more. These functionalities are declared as code dependencies and need to be set at build time.
With Kubernetes there are alternative options to address these requirements. Kubernetes provides concepts for service discovery, load-balancing and resilience. So-called service meshes extend this functionality with more granular network interaction. They are not part of the application code and can hence be added during runtime. A fairly new approach is emerging with the eBPF technology, which claims to enable service meshes with minimal overhead.
With this talk Matthias wants to explain "the why" of cloud-native application design and how various cloud-native technologies facilitate this. It shows the possibilities and limitations of technologies and which forms of integration can make sense. The talk mostly consists of graphical visualisations/explanations and contains a live demo.
Matthias Haeussler ist Principal Cloud Advocate bei der NovaTec Consulting GmbH und der Veranstalter des Stuttgart Cloud Foundry Meetups. Er berät Kunden bei deren Cloud Strategie und unterstützt aktiv Implementierungen und Migrationen. Daneben unterrichtet er Cloud Native Development an den Hochschulen für Technik in Stuttgart und Esslingen. Davor war er über 15 Jahre bei der IBM R&D beschäftigt. Er hält regelmäßig Vorträge auf nationalen sowie internationalen Konferenzen und Meetups wie z.B. WJAX, OOP, den IT Tagen sowie der KubeCon, IBM InterConnect & Cloud Foundry Summit.
Vortrag Teilen