SOFTWARE MEETS BUSINESS:
Die Konferenz für Software-Architektur
08. - 12. Februar 2021, Online-Konferenz
SOFTWARE MEETS BUSINESS:
Die Konferenz für Software-Architektur
08. - 12. Februar 2021, Online-Konferenz
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, arbeitet als Coach und Berater für Software-Entwicklung und -Architektur. Er ist Mitbegründer und Betreuer der Open-Source-Projekte arc42 (https://arc42.de) und aim42 (https://aim42.github.io), Buchautor und gelegentlicher Konferenzsprecher.
Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/gernot.starke
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.
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).
Joseph (Joe) Yoder is president of the Hillside Group and principal 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.
Vortrag Teilen
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 Head of Architecture bei SWAGLab und arbeitet seit mehr als zwanzig Jahren als Architekt und Berater, oft an der Schnittstelle zwischen Business und Technologie. Er ist Autor zahlreicher Artikel und Bücher, u.a. zu Microservices und trägt regelmäßig als Sprecher auf internationalen Konferenzen vor. Sein technologischer Schwerpunkt sind moderne Architektur- und Entwicklungsansätze wie Cloud, Domain-driven Design und Microservices.
Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/eberhard.wolff
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. Sein Wissen und seine Erfahrung teilt er regelmäßig in Vorträgen, Artikeln und Workshops. Stefan ist aktives Board-Mitglied im iSAQB und Autor des Buchs „Softwarearchitekturen dokumentieren und kommunizieren“ (Hanser-Verlag).
Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/stefan.zoerner
Falk Sippach ist bei der embarc Software Consulting GmbH als Software-Architekt, 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.
Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/Falk.Sippach
Vortrag Teilen
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 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
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.
Markus Völter ist freiberuflicher Berater zu (domänenspezifischen) Sprachen und Entwicklungswerkzeugen sowie den Systemarchitekturen und Prozessanpassungen um sie in Produkte/Projekte zu integrieren.
Vortrag Teilen
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 sowie ML/AI, wobei neben Design- und Architekturfragen insbesondere die Real-Life-Aspekte im Fokus seiner Betrachtung stehen.
Vortrag Teilen
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 Trainer und Berater bei INNOQ. Er ist seit 1998 in der IT unterwegs, seit 2001 mit agilen Methoden. Er war viele Jahre lang Software-Architekt in großen Projekten. Nach 10 Jahren agile Coaching baut er zwischen Organisationsstrukturen 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.
Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/gerrit.beine
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 und Mitbegründer bei Digital Frontiers. Er verfügt über langjährige Erfahrung als Berater und Coach in den Themen Microservices, Software Quality und agile Transformation.
Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/frank.scheffler
Vortrag Teilen
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 ist Entwicklerin, Software-Architektin und Forscherin am Fraunhofer IESE. Sie hat mehr als 12 Jahre professionelle Erfahrung und war zunächst für Capgmeini sd&m und die Accso GmbH tätig, bevor sie zu Fraunhofer wechselte. In ihrer PhD erforscht sie wie man zu besseren Software-Architektur-Konzepten für moderne, verteilte Systeme kommt. Sie spricht regelmäßig auf Konferenzen, ist aktives Mitglied der Java User Group Community, Mitglied im Programm-Komitee der JavaLand, Co-Organisatorin der CyberLand Events.
Vortrag Teilen
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.
Verantwortung, Pragmatismus, Fachwissen um die Domäne und Professionalität. Dieses sind die grundlegenden Werte und Attribute, die erfolgreiche Software-Architekt:innen kennzeichnen. Basierend auf langjährigen Projekterfahrungen vermittelt Holger Tiemeyer diese Fähigkeiten und Kenntnisse in seinen Trainings, spricht darüber auf Konferenzen und publiziert Artikel in Fachmagazinen. Als studierter Informatiker mit Nebenfach Psychologie vertritt er in seiner Rolle als Stellvertretender Vorsitzender und Schatzmeister des iSAQB e.V sowohl die finanziellen Belange des Vereins als auch soziale Aspekte rund um die Menschen, die Software-Architekturen gestalten.
Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/holger.tiemeyer