Track: Vorträge
- Dienstag
22.10. - Mittwoch
23.10.
Die richtige Datenarchitektur und Plattform für Datenanalyse und AI unterscheidet sich für jedes Unternehmen. Welche unterschiedlichen Wege gibt es? Welche Rahmenbedingungen beeinflussen Weg und Lösung? Wollen alle die eine, magische Plattform oder gibt es auch sehr spitz zugeschnittene, spezifische Lösungen? Auch die Herausforderungen unterscheiden sich: Den einen fehlt Know-how und Kapazität, andere sind erschlagen von der Komplexität der eigenen IT-Landschaft, wieder andere müssen alles ohne Hilfe von Managed Services aufbauen.
Mit hohem Praxisbezug berichte ich von unterschiedlichen Projekten und Situationen – und zeige einen großen Teil der Bandbreite moderner Datenprojekte und der Herangehensweisen.
Matthias Niehoff arbeitet als Head of Data und Data Architect für die codecentric AG und unterstützt Kunden bei der Konzeption und Umsetzung von Datenarchitekturen. Sein Fokus liegt dabei weniger auf dem ML-Modell, sondern vielmehr auf der notwendigen Infrastruktur und Organisation, um Data-Science-Projekte zum Erfolg zu führen.
Why are we always complaining about old code? Why are we rarely happy when digging into old stuff, especially old code by other people?
It is very tempting to believe that you can easily do it better than that. And that you can improve the situation by rewriting code. By making stuff simpler. In the first park of this talk, I will dive into why we believe this. Expect some insights into psychology and into how our brains work :)
Second part: Why we are wrong, most of the times. Again, this will be about psychology and biases, about code reading and about the IT as a business.
I'm Anja, Principal Fullstack Engineer working at Mister Spex @ Berlin, Germany. We are right now breaking down a monolith and replacing parts of it by future-ready technology. Previously, I have worked for eBay.
Also, I'm sports enthusiast and current local champion in wakeskating. I love to find and cross the borders of what seems achievable.
Eine auf (Micro-)Services basierende Architektur umzusetzen bedeutet, dass auch die Datenhaltung auf die verschiedenen Services verteilt werden muss. Was aber bedeutet das in der Praxis? Was ist, wenn Daten einer Entität – vollständig oder in Teilen – in mehreren Services benötigt werden? Wie wird referenzielle Integrität über mehrere Services hinweg realisiert? Wie lassen sich serviceübergreifende Transaktionen realisieren? Dies sind nur einige von vielen Fragen, die im Rahmen dieser Session beantwortet werden. So viel vorab: Umdenken ist gefragt!
Im Rahmen der Session beschäftigen wir uns mit den Auswirkungen des Datasource-per-Service Pattern und wie man diesen sinnvoll begegnet. Die aufgezeigten Lösungsansätze sind das Resultat aus mehr als fünf Jahren praktischer Erfahrung in Microservices-Projekten.
Lars Roewekamp, Gründer und Geschäftsführer bei der open knowledge GmbH in Oldenburg, beschäftigt sich als „CIO New Technologies“ mit der Analyse und Bewertung neuer Software- und Technologietrends.
Ein besonderer Schwerpunkt seiner Arbeit liegt derzeit auf Enterprise- und Cloud-Computing, Big Data und KI, wobei neben Design- und Architekturfragen insbesondere die Real-Life-Aspekte im Fokus seiner Betrachtung stehen.
Er ist Autor vieler Fachartikel und -bücher und beschäftigt sich seit der Geburtsstunde von Java mit dieser Programmiersprache.
Mit Architekturbewertungen ist es möglich, Schwächen und Potenziale von Softwarelösungen herauszuarbeiten, Entscheidungen abzusichern und Verbesserungsmaßnahmen zu bewerten. Klassische Analyseansätze aus diesem Umfeld wie ATAM sind fundiert, kommen aber gerade in beweglichen Softwarevorhaben etwas schwergewichtig, mitunter fast zeremoniell daher. In diesem Vortrag lernt ihr mit LASR (Lightweight Approach for Software Reviews) eine leichtgewichtige Herangehensweise kennen. Ihr könnt diese mit eurem Team unmittelbar anwenden, euer Softwaresystem beleuchten und zügig zu ersten Erkenntnissen kommen. Wir greifen auf die Essenzen etablierter Bewertungsmethoden zurück. Und erarbeiten uns einen roten Faden durch ein Review, inkl. möglicher Vertiefungspunkte für eine höhere Konfidenz im Bewertungsergebnis.
Stefan Zörner ist Softwareentwickler und -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“.
Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/experten/stefan-zoerner/
Vortrag Teilen
Was bedeutet es eigentlich, Domain-driven Design (DDD) umzusetzen? Dieser Vortrag führt durch ein vollständiges Beispiel und zeigt, wie verschiedene Techniken wie Event Storming, strategisches Design und taktisches Design zusammenwirken, um den Aufbau von Anwendungen zu unterstützen. Auf diese Weise bekommen die Teilnehmer praktische Hinweise, wie sie mit einem einfachen, aber vollständigen Ansatz mit DDD beginnen können.
Eberhard Wolff ist Head of Architecture bei SWAGLab und arbeitet seit mehr als zwanzig Jahren als Architekt und Berater, oft an der Schnittstelle zwischen Geschäft und Technologie. Er ist Autor zahlreicher Artikel und Bücher, u. a. zu Microservices, trägt regelmäßig als Sprecher auf internationalen Konferenzen vor und streamt wöchentlich zum Thema Softwarearchitektur. 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/experten/eberhard-wolff/
Vortrag Teilen
Wie werde ich in der Architekturarbeit agiler, wenn ich "alte", historisch gewachsene Architekturen modernisieren muss, damit sie sich in die aktuellen IT-Plattformen integrieren lassen.
Architekturarbeit findet nicht immer auf der grünen Wiese statt. Wie im richtigen Leben, kommt es sehr selten vor, dass wir komplexe Architekturen auf dem Reißbrett neu konzipieren. Softwarearchitekturen werden ja immer gerne mit dem Städtebau assoziiert. In der Regel werden Städtebau-Architekten die meiste Zeit damit beschäftigt sein, Probleme in bestehenden Städten zu lösen und die Architektur an die aktuellen Herausforderungen anzupassen. Es kommt äußerst selten vor, dass man eine neue Stadt komplett neu konzipieren kann. Im Gegensatz zu den Start-ups in der IT-Welt, sind Städtebauvorhaben definitiv komplexer und wenn man dort Entscheidungen getroffen hat, sind diese wortwörtlich in Stein, respektive Beton gemeißelt.
Haben sie schon mal Legacy-Start-ups gesehen?
In dem Vortrag versuche ich, folgende Fragestellungen zu beantworten:
- Was zeichnet Legacy-Architekturen aus?
- Was ist zu modernisieren, warum und wie?
- Muss ich meine Plattform wechseln?
- Was bringt es mir, das alles agil zu tun?
- Gibt es Architekturen, die zur Agilität passen?
- Wie verkaufe ich agiles Vorgehen in der Organisation?
- Gute und schlechte Beispiele
- Wie lange dauert es, was kostet es und lohnt sich das Ganze überhaupt?
Als Software- und IT-Architekt mit über 30 Jahren Berufserfahrung wurde Peter Diefenthäler geprägt durch die Entwicklungen in der IT vom Mainframe bis hin zu modernen Cloud-Plattformen. Der Wandel von der EDV zur modernen IT ist zu einem seiner Steckenpferde geworden. Es liegt ihm am Herzen, Brücken zwischen Technologie und Organisation zu bauen und sich dafür einzusetzen, dass man alte Zöpfe ein Stück weit abschneidet, um das Maximum aus den heute verfügbaren Möglichkeiten herauszuholen.
Vortrag Teilen
Auch wenn ihr Microservices bereits umgesetzt habt, hängt ein wirklich erfolgreiches Produkt von technisch weiterführenden, methodischen und organisatorischen Themen ab. Wie stark ist die vertikale Idee ausgeprägt? Gibt es eine "Thinnest Viable Platform" und einen Pfad des geringsten Widerstands? Wie gut sind empirische Prozesse ausgeprägt und wie dezentral sind eure Entscheidungswege? In diesem Talk stelle ich ein Self-Assessment vor und biete damit Impulse, Microservices besser zu leben.
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, verteilten Systemen und evolutionärer Architektur umfasst seine Leidenschaft für Technologie auch die verschiedensten Auswirkungen von Software auf Unternehmen und gesellschaftliche Faktoren.
Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/experten/alexander-kaserbacher/
Vortrag Teilen
Wahrscheinlich liegt es am einprägsamen Bild der Testpyramide: Projekte strotzen nur so von tausenden winziger Tests mit zweifelhafter Bedeutung, und die Software funktioniert trotzdem nicht. Das ist nicht verwunderlich, denn diese Minitests vernachlässigen die Kollaboration der Bestandteile, auf die es genauso ankommt. Wir werden nicht für einzelne Klassen bezahlt, sondern für Features und Usecases, und die gilt es primär zu testen. Also mal Umdenken: Testunits nicht so klein, sondern so groß wie möglich, Mockito und Selenium raus, Datenbank rein und konsequentes "Design for Test", wo es in der Architektur knifflig wird. Die Session zeigt Beispiele und Architekturmuster aus der Praxis, um das Konzept der "sociable Unittests" zu fördern, die auf ganze Usecases abzielen und eine andere Größenordnung von Absicherung schaffen.
Jan Leßner ist Software-Entwickler, Architekt und System-Analyst bei S&N Invent. Er ist Buchautor und Java-Programmierer der ersten Stunde und engagiert sich in verschiedenen Open-Source-Frameworks. Seit über 10 Jahren ist er in Enterprise-Projekten mit den Schwerpunkten Bilanzanalyse, Loyalty-Programme und Telekommunikation tätig. Dort beschäftigt er sich nicht nur mit der eigentlichen Entwicklung, sondern auch mit dem Aufbau eines eleganten Software-Engineerings.
Vortrag Teilen
In the world of software development, legacy code often poses significant challenges. Existing codebases, built years ago, may lack documentation and understanding of the original domain. This lack of knowledge can hinder effective maintenance, upgrades, and feature development. The process of rediscovering the domain of legacy code is invaluable for developers seeking to enhance and extend these systems.
In this talk we'll delve into various domain re-discovery patterns that help in identifying and reconstructing the domain model that the legacy code represents. These patterns go beyond merely deciphering the code's functionality; rather, they provide strategies to comprehend the underlying concepts, behaviors, and relationships in the domain.
Attendees can expect to gain practical insights, methodologies, and practical tips to tackle the challenges associated with legacy codebases. By embracing domain rediscovery patterns, developers can bring order and coherence to legacy systems, paving the way for future enhancements and system evolution.
Richard is a software archeologist, tailor and auditor. After 10 years in the business he's almost no longer a junior and about to become a teenager developer. He's consulted legacy and greenfield projects at all large german organizations or knows someone who has and has now held multiple talks about his experience at international conferences and meetups. He enjoys mastering TDD, BDD, DDD, decoupled design and even practices that don't include two D's. Most importantly though is that he likes to break the fourth wall and engage his audience. Do you like that as well?
Softwareentwicklung muss branchenübergreifend immer kürzeren Releasezyklen gerecht werden. Dieser Trend hat starke Auswirkungen auf die Qualitätssicherung, denn wir können Releases nicht länger in dedizierten Test- und Stabilisierungsphasen absichern. Vielmehr müssen wir dafür sorgen, dass unsere Softwaresysteme praktisch jederzeit die Qualitätsansprüche für ein Release erfüllen. Deshalb führen wir mit "Continuous Quality Control" Maßnahmen zur Qualitätssicherung (Codeanalyse, Tests, Reviews) entwicklungsbegleitend und änderungsgetrieben durch.
Dieser Vortrag erklärt auf Basis der Erfahrung von 10 Jahren und dutzenden Kundenprojekten, wie Continuous Quality Control funktioniert. Die Teilnehmer lernen, wie sie
- erstens statische Codeanalyse änderungsgetrieben einsetzen können, um Qualitätsdefizite zu vermeiden und historisch gewachsene Systeme zu verbessern,
- zweitens mit Test-Gap-Analyse risikoorientiert automatisierte Test-Suites aufbauen können, und
- drittens durch Reviews und Retrospektiven Transparenz schaffen, das Entwicklungsteam abholen und ein gemeinsames Qualitätsbewusstsein verankern können.
Dr. Tobias Röhm hat über Softwareanalysen und Programmverstehen promoviert, mehrere Jahre als Freelancer Software entwickelt und ist seit vielen Jahren Berater für Softwarequalität. Mit seinem Team unterstützt er vierzig Entwicklungsteams, Qualitätsanalysen durchzuführen und alltagstaugliche QS-Prozesse aufzusetzen und zu leben. Er hat Best-Paper-Awards auf zwei renommierten wissenschaftlichen Konferenzen gewonnen und spricht regelmäßig auf Konferenzen wie DWX, ESE, JFS und OOP.
Wie schafft man es, die sich stetig ändernden Anforderungen in Langzeit-Projekten kontinuierlich umzusetzen? Bestehende Qualitätsanforderungen stehen immer in einem Spannungsfeld zu neuen Qualitätsanforderungen und neuen fachlichen Anforderungen. Das lässt sich besonders bei Legacy-Software beobachten: Dort ist es typischerweise entscheidend, dass das System erweiterbar und wartbar bleibt – dies bringt aber oft größere Anpassungen der Architektur mit sich.
Dieses Dilemma beleuchten wir anhand eines etwa 8 Jahre alten Projekts zur Verwaltung und Auslieferung von Firmware-Updates für IoT-Geräte. Wir betrachten konkrete Beispiele, wie wir in der Praxis die Architektur des Systems kontinuierlich an neue Anforderungen angepasst haben.
Dazu stellen wir unter anderem die Einführung eines neuen Technologiestacks, die Anpassung eines Prozesses an vollständig geänderte Qualitätsanforderungen und das Error Handling in unserer Microservice-Landschaft vor.
Als leidenschaftlicher Softwareentwickler hat Benedikt Hunger seine Begeisterung für Softwarearchitektur entdeckt und hilft als Consultant bei INNOQ dabei, Softwareprojekte erfolgreich und nachhaltig zu entwickeln. In agilen Projekten im verschiedenen Branchen trägt er nicht nur zur Entwicklung der Software bei, sondern übernimmt auch die Kommunikation mit externen Stakeholdern und die explizite Anforderungsanalyse. Bei der Entwicklung legt er besonderen Wert darauf, dass langfristige Ziele und Konsequenzen stets im Blick behalten werden.
Studied CS (Informatik) B.Sc at University of Augsburg.
Worked as an intern and working student at Secomba GmbH, helping with the development of Boxcryptor, a cloud encryption software product.
Then started as a full time employee at Scandio, working on the firmware distribution solution for BSH IoT home appliances.
Vortrag Teilen
Immer mehr Softwareprojekte setzen auf eventgetriebene Architekturen, da sie einfache Erweiterbarkeit, Robustheit und Skalierbarkeit sowie lose Kopplung versprechen. Oft wird dabei jedoch die Komplexität der Implementierung unterschätzt. Diese ergibt sich nicht nur aus technischen Herausforderungen, die gelöst werden müssen, sondern auch daraus, dass viele unterschiedliche Vorstellungen davon existieren, was eine eventgetriebene Architektur eigentlich ist und wie sie zu funktionieren hat.
Diese unterschiedlichen Auffassungen können einerseits zu Problemen im Betrieb führen, andererseits kann ein wachsendes System neue Herausforderungen mit sich bringen, die man anfangs nicht berücksichtigt hat. Basierend auf unseren eigenen leidvollen Erfahrungen in Projekten und teils ähnlichen Erlebnissen unserer Kollegen haben wir eine Liste von Anti-Patterns identifiziert, die entweder aus unterschiedlichen Auffassungen und deren Umsetzung resultieren oder die durch Evolution des Systems die Entwicklung und den Betrieb eines solchen Systems erheblich erschweren können. In diesem Vortrag stellen wir diese Anti-Patterns vor, zeigen, welche Probleme sie verursachen und wie man sie vermeiden kann.
As Co-Founder and Senior Consultant at Digital Frontiers, Florian Pfleiderer focuses on agile software development. He advises his clients in the areas of architecture, microservices and craftsmanship and helps them to make their way into the cloud sustainably and with high-quality software.
Frank Steimle ist Senior Consultant bei Digital Frontiers. Er fokussiert sich auf agile Softwareentwicklung in Kombination mit Domain-Driven Design. Er interessiert sich dabei besonders für Event Modeling, CQRS, Event Sourcing und alle Arten von eventgetriebenen Architekturen.
Vortrag Teilen
Migration von lange gewachsener Legacy-Softwareentwicklung birgt von vornherein viele Risiken. Häufig ist das Detailwissen zu großen Teilen der Fachlichkeit verloren gegangen. Der Code ist komplex und Tests gibt es sowieso nicht. Da liegt es in der Natur der Sache, dass der Aufwand für ein Migrationsprojekt schwer geschätzt werden kann. Das Ergebnis sind häufig Zeit- oder Budget-Überschreitungen. Nicht selten werden solche Projekte abgebrochen und als gescheitert erklärt.
Was kann man dagegen tun? Ein Schlüssel zu einer erfolgreichen Legacy-Migration ist ausreichendes Testen. Dabei geht es zunächst darum, die bestehende Applikation mit automatisierten Tests zu versehen, um einerseits ein Gefühl für die Funktionalität und den Umfang zu bekommen und andererseits eine deutlich höhere Sicherheit bei der Migration selbst.
In der Session zeige ich, wie das gelingen kann und wie wir es dadurch geschafft haben, Migrationsprojekte, die vorher bereits als gescheitert oder unmöglich erschienen, erfolgreich zu Ende zu führen.
Arne Limburg ist Lead Architect bei der open knowledge GmbH in Oldenburg. Er verfügt über mehrjährige Erfahrung als Entwickler, Architekt, Trainer und Coach 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 OpenWebBeans und Apache DeltaSpike sowie als Urheber und Projektleiter von JPA Security.
Resilience is an important issue these days. Many companies claim to have a resilient IT, very few have one.
What does it mean to be resilient? How do I get there? How can I figure out where I currently am? How can I improve?
We will look at several gradations of becoming resilient. We will examine their properties and tradeoffs and how to get there. We will discuss what we can achieve at an IT system level and when we need to address the whole socio-technical system.
At the end of the session, we will have drawn a map from here to resilience you can use as a travel guide towards your resilient IT.
Uwe Friedrichsen. Langjähriger Reisender in der IT. Dot Connector. Kartograph unbekannter Gebiete. Bewahrer zeitlosen Wissens. Vermittler zwischen den Welten. Systemdesign. Resilienz. Nachhaltigkeit. Mag keine langen Biografien. Versucht, die IT (ein wenig) besser zu machen. CTO @ codecentric.
Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/experten/uwe-friedrichsen/
Domain-Driven Design ist kein Patentrezept und löst kein Problem auf magische Weise. Die Herausforderungen und die Komplexität, die wir mit DDD zu bewältigen versuchen, sind schwierig, und es gibt keinen einfachen Lösungsansatz. Nichtsdestotrotz gibt es eine wachsende Popularität und Wertschätzung für das Thema auf dem Markt, was zu überhöhten Erwartungen und schließlich zu Enttäuschungen führen kann.
Der Referent dieses Vortrags arbeitet seit 17 Jahren mit Domain-Driven Design an vielen Softwaresystemen, und dieser Vortrag handelt von meinen Erfahrungen mit dem Scheitern. Glauben Sie mir: Ich bin oft gescheitert, aber es gibt immer eine Gelegenheit, etwas daraus zu lernen. Der Vortrag zielt darauf ab, Ihnen die Möglichkeit zu geben, aus den Fehlern von mir als Berater und den Teams/Organisationen, mit denen ich gearbeitet habe, zu lernen.
Der Vortrag behandelt Themen wie:
- Domain-Driven Design im Wasserfall
- Ignoranz für Code (aka nur Fokus auf strategisches Design)
- übermäßiger Gebrauch von Mustern um ihrer selbst willen
- kulturelle Implikationen
- Cargo-Kult
- Developer Experience
- eingeschränkte Verfügbarkeit von Fachexperten
- Umgang mit etablierten Modellierungstechniken/Methoden
- Unkenntnis über die Definitionen/Bedeutung von Heuristiken und Mustern
Dieser Vortrag zielt darauf ab, Ihnen eine Sensibilität für potenzielle Gefahren zu vermitteln, wenn Sie versuchen, DDD für Ihr Team und Ihre Organisation einzuführen, und wird nur reale Situationen beschreiben, die tatsächlich passiert sind. Jeder beschriebene Misserfolg wird mit einer Erkenntnis darüber einhergehen, wie man es besser machen kann.
Es handelt sich um einen interaktiven Vortrag, bei dem Ihnen, dem Publikum, Fragen und Umfragen (über ein Online-Tool) gestellt werden. Sie werden sich beteiligen können.
Michael Plöd ist ein Fellow bei INNOQ. Seine derzeitigen Schwerpunkte sind Domain-driven Design, Team Topologies, soziotechnische Architekturen und die Transformation von IT-Organisationen in Richtung Collaboration und lose gekoppelte Teams. Michael ist Autor des Buches „Hands-on Domain-driven Design – by example“ auf Leanpub, Übersetzer des Buches „Team Topologies“ ins Deutsche für O’Reilly und ein regelmäßiger Speaker auf nationalen und internationalen Konferenzen.
Finding the right balance at work is neither an individual task nor is it only a team’s responsibility. It’s an interaction of both - and more! Leaders also play a vital role as they often (still) have a higher organizational lever.
In this session I will:
- define what sustainable pace is
- share common pitfalls that can “unbalance” a system (i.e. team, whole company, and also yourself)
- offer simple yet powerful self-care practises for individuals and for teams
- mix in psychological background (e.g. on stress & coping)
YOU are invited!
Cosima Laube is an independent leadership coach and socio-technical consultant with experience e.g. in automotive, finance, healthcare and the public sector.
Building on a strong foundation as technical and people lead in IT, she enhanced her portfolio with solid coaching skills (ICF-PCC) and Psychology (BSc.).
Cosima cares more about systems thinking than local optimization, she is an introvert, a runner and a passionate community "gardener".
Her credo is: respect & adapt to achieve more TOGETHER!
usePAT ist Anbieter einer neuen Ultraschalltechnologie, die von einem multidisziplinären Team entwickelt wird. Die angebotenen IoT Systeme schließen Hard- und Softwarekomponenten ein, die Schnittstellen sind besonders komplex. Sie verbinden einerseits das Gerät mit der Steuerung eines industriellen Prozesses und andererseits die im Gerät erhobenen Daten mit den Menschen dahinter. Es werden auf Grund der Analysen sicherheitskritische Entscheidungen getroffen, die regulatorischen Anforderungen an diese Systeme sind dementsprechend anspruchsvoll.
Diese Komplexität gab den konkreten Ausschlag für die Evaluation einer neuen Methodik. usePAT hat sich dabei entschieden, die modellbasierte Systementwicklung als strategisches Entwicklungselement über das gesamte Unternehmen einzuführen, um diese Komplexität zu meistern.
Die Herangehensweise:
- ermöglicht durch Daten-, Infrastruktur- und Applikationsarchitekturen eine ganzheitliche Entwicklung von IoT Systemen,
- dokumentiert diese Systementwicklung über den gesamten Lebenszyklus,
- stellt das Wissensmanagement auch bei Fehlentwicklungen sicher.
Diese Evaluation und Einführung der modellbasierten Systemarchitektur erfolgt im Rahmen des EU Förderprojektes PENTA „ECOMAI“, Ecological Motor Control and Predictive Maintenance with Artificial Intelligence.
Salomé Wagner ist Certified Management Consultant mit mehr als 20 Jahren Erfahrung in der IT-Branche. Nach Expertenrollen im Bereich Service Development in internationalen Großkonzernen ist sie heute für Sparx Systems CE tätig. Ihr fachlicher Schwerpunkt liegt in der Weiterentwicklung modell-basierter Methoden und Frameworks. Dabei begleitet sie auch das internationale PENTA Forschungsprojekt «ECOMAI» (Ecological Motor Control and Predictive Maintenance with AI). Salomé Wagner ist Mitbegründerin von WomeninICT, eine Interessensgruppe des VÖSI, der österreichischen Organisation für Softwareinnovationen.
Die Veröffentlichung von ChatGPT jährt sich nun bald zum zweiten Mal. Ein Ende des Hypes ist noch lange nicht abzusehen. Zu groß sind die Mehrwerte dieser Technologie, zu intuitiv ist der Umgang in Form eines Chats. Für das Jahr 2024 wurde erwartet, dass der Sprung vom explorativen Herumspielen mit Large Language Models (LLMs) zum produktiven Einsatz gewagt wird. Diese Prognose bewahrheitete sich und viele Unternehmen lagerten beispielsweise den Customer Support auf LLM-powered ChatBots aus. Dass dies nicht immer eine gute Entscheidung war, zeigten Fälle wie der des DPD-ChatBots, welcher anstelle nützlicher Antworten lieber Gedichte über den schlechten Service des eigenen Unternehmens verfasste. Auch die sogenannten Halluzinationen von LLMs führten immer wieder zu Versprechungen oder Preisnachlässen, welche es in dieser Form nie gab.
Eine Lösung, derartige Probleme zu mitigieren, bietet die RAG-Architektur (Retrieval Augmented Generation). Durch ein vorgeschaltetes Retrieval, um relevante Informationen aus einer eigenen dynamischen Datenbasis hinzuziehen, können fundierte Antworten geliefert werden. Halluzinationen können vermieden und toxische Sprache durch weitere Mechanismen abgefangen werden. Anhand eines konkreten Praxis-Beispiels möchte ich zeigen, wie ein RAG-System funktioniert und welche Vorteile es bietet. Zudem werde ich auch auf noch ungelöste Herausforderungen eingehen.
Tim Wüllner arbeitet als Machine Learning Engineer in Oldenburg. Nach mehreren Jahren in der Forschung im Bereich der autonomen Schifffahrt, führte ihn sein Verlangen nach praxis-orientierter Arbeit zur OPEN KNOWLEDGE GmbH. Hier wechselte der Fokus dann von zunächst "klassischer" Webentwicklung im Front- und Backend zu Machine Learning spezifischen Aufgaben, insbesondere der Computer Vision und der Anwendung von Large Language Models. In der Verknüpfung von Webentwicklung und Machine Learning steckt großes Potential, welches Tim in verschiedenen Kundenprojekten bestmöglich ausschöpfen möchte.
Single-Page-Anwendungen (SPA) sind einerseits weit verbreitet, andererseits aber auch umstritten. Sie bieten ein hohes Maß an Interaktivität und Komfort für Benutzer:innen, aber nicht für jede Anforderung ist eine SPA deswegen automatisch die richtige Wahl. Auf der anderen Seite wiederum sind "klassische" auf dem Server gerenderte Anwendungen oftmals nicht ausreichend, wenn es um Webanwendungen mit viel Interaktivität geht. Diese Lücke möchte die Bibliothek HTMX schließen, die serverseitiges Rendering mit einem beliebigen Backend ermöglicht. Im Frontend verspricht sie sowohl eine nahezu JavaScript-freie Entwicklung als auch feingranulare Aktualisierungen der Oberfläche, ähnlich wie von SPAs gewohnt. Ist HTMX also die perfekte Allzwecklösung fürs Frontend?
Anhand praktischer Beispiele möchte ich Single-Page-Anwendungen und HTMX gegenüberstellen. So werden wir sehen, wo die Stärken und Schwächen der beiden Ansätze liegen und für welche Anwendungen sie jeweils geeignet sind.
Neben Beispielen mit Java und Spring werde ich ein paar React-Beispiele zeigen, die du aber auch ohne React-Vorkenntnisse verstehen wirst. Wenn du dich also für moderne Webentwicklung interessierst, bist du in diesem Vortrag genau richtig!
Nils Hartmann ist freiberuflicher Software-Entwickler und -Architekt. Seine Schwerpunkte sind die Entwicklung von Backends mit Java und Spring sowie Frontends mit React und Next.js. Er gibt Schulungen und Workshops zu diesen Themen und hat ein Buch über React geschrieben und Videokurse zu GraphQL veröffentlich (u.a. heise academy). Kontakt: https://nilshartmann.net.
Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/experten/nils-hartmann/
Vor zehn Jahren habe ich zum ersten Mal einen Vortrag über Event-driven Architecture gehalten. Kafka war gerade seit zwei Jahren Open Source und bei Version 0.8, und nur ein paar Wochen vorher war Java 8 erschienen, und die erste Version von Spring Boot. Damals war gerade das Label "reactive" populär, und so hieß er "From Enterprise To Reactive". Unter anderem habe ich das Saga-Pattern propagiert.
In den zehn Jahren habe ich einiges dazugelernt - musste aber vor allem auch vieles erst einmal verlernen. In diesem Vortrag ziehe ich eine kleine Bilanz: Welche Ansätze haben sich in den zehn Jahren bewährt, und welche waren für mich enttäuschend? (In welcher Kategorie wird wohl das Saga-Pattern wieder auftauchen?)
Nicht alles wird sich übertragen lassen, aber manche Einsicht kann vielleicht hilfreich sein.
Lutz ist Head of Engineering für Investment & Custody Solutions bei Upvest. Zuvor hat er als Architekt oder Engineering Manager die Entwicklung von Software für die Containerschifffahrt, Online-Händler, Finanzinstitute, Kreuzfahrtschiffe und andere vorangetrieben. Sein derzeitiger Fokus liegt auf Domain-driven Design und Event-driven Architecture.
Softwaresysteme bestehen aus Bausteinen. Aber kann ein Softwaresystem Baustein eines anderen sein? Andersherum: Besteht ein System aus "Bausteinen all the way down"? Das wäre gut, weil beim Zusammensetzen die Details verschwinden und so konsequent abstrahiert wird – wir komponieren dann, anstatt einfach nur zu basteln. Das gleiche gilt für Domänenmodelle – sogennante Kombinatormodelle sind flexible Baukästen statt starrer Formulare.
Die Realität der meisten Systeme sieht leider anders aus: Softwaresysteme und ihre Bausteine werden mehr schlecht als recht miteinander verschaltet, bedingt auch durch gängige Architekturmuster wie die hexagonale Architektur, die einfach nicht komponieren. Bei den Domänenmodellen ist es ähnlich: Elemente typischer OO-Modelle lassen sich oft nur begrenzt zusammensetzen – in der obersten Schicht ist Schluss. Entsprechend groß ist der Refaktorisierungs- und Modernisierungsaufwand, wenn sich die Anforderungen ändern.
Im Talk gehen wir auf eine Reise der Kompositionalität auf verschiedenen Ebenen: Wir besuchen Projekte aus der Praxis, bei denen Kompositionalität ein zentrales Designprinzip ist, nahezu unbegrenzt flexible Kombinatormodelle und kompositionale Modulsysteme. Wir ziehen Paralleln zum Prinzip "closure of operations" im DDD und zeigen die Prinzipien, die du beim Einsatz von Komposition beachten solltest.
Dr. Michael Sperber ist Geschäftsführer der Active Group GmbH, die Individualsoftware ausschließlich mit funktionaler Programmierung entwickelt. Er ist international anerkannter Experte für funktionale Programmierung und wendet sie seit über 20 Jahren in Forschung, Lehre und industrieller Entwicklung an. Außerdem hat er zahlreiche Fachartikel und Bücher zum Thema verfasst. Michael Sperber ist Mitbegründer des Blogs funktionale-programmierung.de und Mitorganisator der Entwicklerkonferenz BOB.
Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/experten/michael-sperber/
Vortrag Teilen