Technology Day
13. November 2023
1100 Teilnehmer:innen
Danke!
Ein Tag (und ein Abend) mit Vorträgen, Diskussion und Networking zu Softwarearchitektur, -entwicklung und IT-Strategie.
Ein Tag (und ein Abend) mit Vorträgen, Diskussion und Networking zu Softwarearchitektur, -entwicklung und IT-Strategie.
Most of data science projects never make it to production contributing to an endless Jupyter notebooks graveyard. Is there a secret recipe to overcome the PoC phase succeeding into a real data science product? Enjoy the five lessons leant to apply onto product management principles as a result of transforming a bunch of scripts into fully automated models productive in 23 countries!
Viele große Unternehmen setzen noch immer auf zentralisierte, architekturbezogene Teams. Oftmals geben diese Teams anderen Teams architektonische Vorgaben und sorgen dafür, dass diese Vorgaben in der Praxis eingehalten werden. Solche Teams werden häufig als „Elfenbeinturm-Architektur”-Teams bezeichnet, die darauf ausgerichtet sind, hochqualifizierte Architekten und Architektinnen zu bündeln. Solche Rollen sind auf dem Markt zwar selten, passen aber nicht in eine agile Umgebung. In der agilen Welt möchten wir den Teams die Freiheit geben, eigene Entscheidungen zu treffen. Dennoch sind bestimmte Leitplanken erforderlich, um das Gesamtkonstrukt funktionsfähig zu halten. Richtig gewählte Leitplanken können zudem den Koordinationsaufwand zwischen den Teams erheblich verringern. Unser Ziel sollte es sein, die Teams zu befähigen, den Großteil der architektonischen Arbeit selbst zu übernehmen, während gleichzeitig sichergestellt wird, dass alle Komponenten zusammenpassen. Hier setzt das Konzept der Team Topologies von Matthew Skelton und Manuel Pais an. Insbesondere der Teamtyp des „Enabling Teams”, welcher, kurz gesagt, andere Teams mit Wissen und Methodik unterstützt.
In diesem Vortrag erhältst Du einen Überblick über diesen Wandel sowie praktische Tipps, wie Du ein zentrales Architekturteam in ein Enabling Team umwandeln kannst. Das Hauptziel dieses Teams ist es, die Architekturarbeit in anderen Teams zu verbessern. Du wirst lernen:
Zudem werden im Vortrag zahlreiche Praxisbeispiele vorgestellt, die diesen Transformationsprozess begleiten.
Seit einer gefühlten Ewigkeit ist die letzte industrielle Revolution im Gange: Industrie 4.0. Manche Leser werden nun stöhnen und sagen: Wieder einer, der versucht, die Industrie zu digitalisieren und erzählt, wie toll alles sein könnte? Das wirst Du hier bestimmt nicht hören. In diesem kleinen Interview werden Fragen aus aktuellen Projekterfahrungen in diesem Bereich diskutiert.
Waren alle vorherigen industriellen Revolutionen von bahnbrechenden Erfindungen geprägt, so ist das in der Industrie 4.0 wesentlich vielschichtiger und komplexer. Industrie 4.0 ist weniger eine Revolution als eine Evolution. Viele Technologien wurden in den letzten Jahren erst entwickelt, um eine digitale, vernetzte Industrie schaffen zu können. Doch wo endet diese Evolution? Am Ende wird der digitale Zwilling entstehen, leben und sterben. Ein Objekt, das ein real existierendes Ding widerspiegelt. Dieser Zwilling enthält alle Informationen, welche das echte Ding beschreiben, aber auch lebendige Daten aus dessen Lebenszyklus. Für die Handhabung der Daten helfen Konzepte aus Bereichen der dezentralen Datenhaltung und IoT. Für den Austausch der Daten kommt die AssetAdministrationShell ins Spiel.
Neben Antworten auf die Frage, was eine AssetAdministrationShell genau ist und was es in diesem Ökosystem noch so alles gibt, werden auch konkrete Zukunftsprojekte angesprochen, die nicht nur zum Erfassen von Daten dienen, sondern auch das Ziel haben, diese einzusetzen, um die Umwelt zu verbessern.
In letzter Zeit findet WebAssembly (WASM) als Laufzeitumgebung auch außerhalb des Browsers immer mehr Verbreitung, z. B. als Alternative zu Containern. Mit Tools wie Emscripten können notorisch unsichere Sprachen wie C und C++ nach WebAssembly kompiliert werden. Grund genug, sich näher mit den Security-Mechanismen von WebAssembly auseinanderzusetzen.
Nach einer kurzen Einführung in WebAssembly und einem Überblick über die vorhandenen Implementierungen schauen wir uns die Security-Mechanismen von WebAssembly genauer an, und vergleichen diese mit den Security-Mechanismen von anderen Laufzeitumgebungen.
Arbeitest Du an einem Legacy-System, das schwer zu warten ist? Du willst es modernisieren, aber weißt nicht, wie? Lass’ uns das besser machen!
In diesem kurzen Workshop bekommst Du keine Folien, sondern migrierst ein Legacy-System als praxisnahes Beispiel. Du arbeitest spielerisch mit anderen zusammen, um die neuen Anforderungen umzusetzen. Dabei liegt der Fokus auf der Mikroarchitektur eines Teilsystems.
Das Hauptziel ist, Dich auf die häufigsten Herausforderungen bei einer Migration vorzubereiten.
Moderne Datenarchitekturen verwenden das Konzept eines Datenprodukts, um die Bereitstellung und Nutzung von Daten besser zu organisieren.
Ein Datenprodukt bildet eine logische Einheit um fachlich relevante Daten und umfasst alle Komponenten, um diese Daten zu speichern, aufzubereiten, zu aggregieren, zu erklären und für die Nutzer:innen so einfach wie möglich zugänglich zu machen.
Jochen Christ, Autor von datamesh-architecture.com, zeigt, wie ein Datenprodukt in der AWS-Cloud implementiert werden kann, welche Funktionen eine gute Datenplattform zur Verfügung stellen sollte, und wie Datenprodukt-Governance mit dem Data Mesh Manager unterstützt wird.
Nachdem barrierefreie Websites, mobile Anwendungen und softwaregestützte interne Prozesse in der öffentlichen Verwaltung schon längst gesetzlich vorgeschrieben sind, tritt am 28.06.2025 eine ähnliche Verpflichtung europaweit für die Privatwirtschaft in Kraft. Dann müssen beispielsweise Webshops, Apps, Bankdienstleistungen und Fahrkartenautomaten barrierefrei sein.
In der Schulung „Accessibility von Software“ erhältst du einen umfassenden Überblick über die Details dieser gesetzlichen Vorgabe. HTML- und ARIA-Beispiele veranschaulichen die Umsetzungsmöglichkeiten, während praktische Übungen das Gelernte vertiefen. Mit dieser Schulung wirst du in die Lage versetzt, die aktuellen 50 gesetzlichen Anforderungen zu meistern.
Zielgruppe:
Die Schulung richtet sich an Software-Entwickler:innen, Interaction Designer:innen, Visual Designer:innen, Screen Designer:innen, Informationsarchitekt:innen und Führungskräfte, die ihr Wissen über Accessibility aufbauen, stärken und erweitern möchten und Best Practices für HTML und ARIA zur barrierefreien Gestaltung verschiedener UI-Elemente kennenlernen wollen.
Wir sprechen in unserem Vortrag darüber, was soziotechnische Systeme sind, grenzen den Begriff ein und nähern uns den Herausforderungen, denen wir gegenüberstehen, wenn sich Technologie und soziale Systeme verflechten.
Data Contracts (https://datacontract.com/) sind ein zentrales Element für eine saubere Implementierung eines Data Mesh. Während die Data Products die Knoten des Mesh bilden, stellen die Data Contracts die verbindenden Kanten dar. Sie definieren somit alle Beziehungen zwischen den Data Products, indem sie Metainformationen über die verwendeten Daten und deren Verwendung festhalten. Ein Data Contract sollte immer die Grundlage für die Nutzung eines Data Products sein, da er als Dokumentation hilft, Richtlinien für Datenqualität und Governance einzuhalten und Zugriffskontrollen zu automatisieren. Im Vortrag werden die grundlegenden Begriffe geklärt, um ein gutes Verständnis für Data Contracts und deren Bedeutung zu schaffen.
Datenarchitekt:innen und Dateningenieur:innen diskutieren derzeit, wie genau Data Contracts implementiert werden sollen. Denn während sich bei operationalen APIs OpenAPI als Standard für Schnittstellenbeschreibungen durchgesetzt hat, konnte sich in diesem noch recht jungen Bereich noch kein Standard etablieren. Wir möchten hier einen Überblick geben und die Vor- und Nachteile verschiedener Ansätze beleuchten.
Mit dem Tool Datacontract CLI (https://cli.datacontract.com/) arbeitet Stefan Negele an einer Open Source Lösung, um Data Contracts zu erstellen und deren Stabilität zu gewährleisten. Im Talk werden die wichtigsten Funktionen vorgestellt und erklärt, wie es helfen kann, die Robustheit von Data Contracts zu gewährleisten.
Der Vortrag richtet sich an alle, die ein tieferes Verständnis für die Rolle von Data Contracts gewinnen wollen. Entwickler:innen, Architekt:innen und Datenexpert:innen erhalten wertvolle Einblicke in eine der wesentlichen Grundlagen für eine erfolgreiche und skalierbare Datenintegration.
E-Commerce ist nicht immer gleich E-Commerce. Das gilt ganz besonders für Fleurop. Was dieses Projekt so besonders macht, möchten wir euch in diesem kurzen Vortrag zeigen. Dabei werden wir sehen, was eigentlich so alles im Hintergrund passiert, wenn vorne im Shop nach Blumen gesucht und bestellt wird.
In den meisten Projekten treffen wir auf folgende Arten von Architekturdokumentation: Entweder gibt es gar keine Dokumentation, oder es existiert veraltete Dokumentation in gigantischem Umfang. Unabhängig davon ist der Effekt jedoch der gleiche – es wird nichts Neues mehr dokumentiert. Begründet wird dies meist mit „Das liest doch niemand”, „Dafür haben wir keine Zeit” oder „Das findet ja niemand mehr”. Kommt Euch bekannt vor? Dann ist dieser Vortrag genau das Richtige für Euch.
Wir stellen Euch den Architecture Communication Canvas (ACC) vor, mit dem Ihr in kurzer Zeit die wichtigsten Aspekte Eurer Architektur dokumentieren und kommunizieren könnt. Der Canvas ist kompatibel zum arc42-Template, jedoch wesentlich kompakter. Mit Beispielen aus der Praxis sowie praktischen Tipps zeigen wir Euch, dass Dokumentation zugleich sparsam erstellt werden und dabei nützlich für Stakeholder sein kann – und das Ganze auch noch Spaß macht!
).png)
Bei den „Advent Of Code“-Programmierproblemen stößt du auf die absurdesten Herausforderungen. Wie findest du beispielsweise den besten Weg durch ein Höhlensystem, um eine Horde Elefanten zu retten? Oder welche Roboter baust du, um möglichst viele Geoden zu knacken?
Die Lösungen für diese Fragen liegen in (mehr oder weniger) bekannten Algorithmen der Informatik, die im täglichen (Berufs-)Leben selten Anwendung finden. Umso spannender – wenn auch nicht immer praktisch – ist es, sich wieder damit auseinanderzusetzen.
In diesem Vortrag schauen wir uns anhand der genannten Probleme einige Graphalgorithmen an. Gemeinsam erforschen wir, wie diese optimiert werden können und wie du selbst in einer eher maschinenfernen Sprache wie Java deutlich an Laufzeit sparen kannst.
Schnelle Software Delivery hängt heute u.a. an der Etablierung von autonomen Teams, die unabhängig voneinander Funktionalität entwickeln und liefern können. Aber wie schaffen wir es, dass diese Teams nicht in unterschiedliche Richtungen laufen, sondern ein gemeinsames Architektur- und Technologieverständnis entwickeln, aber gleichzeitig einen eigenen Entscheidungsspielraum haben?Um diese Fragen zu beantworten, diskutieren wir Architektur-Prinzipien, Makroarchitektur und Service Templates (aka Golden Path, Paved Road, Sensible Defaults, Follow the Trail) und wie diese Ideen hier helfen können, aber auch wo deren Fallstricke liegen
Was haben Entwicklung und Architektur mit dem Business und den Nutzer:innen zu tun?
Die Antwort ist einfach: sehr viel. Das gesamte Team sollte verstehen, für wen das Produkt gedacht ist, an dem es arbeitet, und welchem höheren Ziel die einzelnen Aufgaben dienen. Niemand sollte Aufgaben einfach nur abarbeiten, die in Tickets beschrieben sind.
Die digitale Produktentwicklung ist nicht nur Bestandteil eines Teams, das sich „die Produktmenschen“ oder „die UXler:innen“ nennt. Sie ist ein elementarer Bestandteil der digitalen Transformation und bildet die Basis für erfolgreiche – oder eben nicht erfolgreiche – digitale Produkte.
Die Digitalisierung schreitet kontinuierlich voran. Daher müssen Prozesse, Strukturen und Wertschöpfungsketten flexibel und regelmäßig angepasst werden. Das bedeutet, dass unsere Software und die zugrundeliegende Architektur ebenso reagieren müssen.
Wie schaffen wir es jedoch, als Team mit dieser Geschwindigkeit Schritt zu halten und unsere Software, Services und Produkte dennoch qualitativ hochwertig zu liefern? Wie müssen wir zusammenarbeiten, um flexibel auf den Markt und die Menschen dahinter reagieren zu können?
In diesem Talk fokussieren wir uns auf digitale Produktentwicklung – jedoch mit dem Bewusstsein, dass ein harmonisches Zusammenspiel von Mindset, Menschen und Methode gegeben sein muss.
In diesem Training Bite geben wir dir einen Einblick in unser neues eintägiges Training „Domain-driven Design für Führungskräfte”. Dieses Training hat das Ziel, Personen in Führungspositionen einen Überblick über Domain-driven Design (DDD) und dessen Relevanz für IT-Lieferorganisationen zu bieten. Dabei sprechen wir über folgende Themen:
Residuality theory is a revolutionary new theory of software design that aims to make it easier to design software systems for complex business environments. Residuality theory models software systems as interconnected residues - an alternative to component and process modeling that uses applied complexity science to make managing uncertainty a fundamental part of the design process.
Höher, schneller, weiter: Was ist gut genug?
Qualität wird für Software immer wichtiger. Unsere Systeme sollen ständig online, hochperformant, robust, elastisch, skalierbar und sicher sein, oder was immer eure Stakeholder so unter Qualität verstehen. Das jedoch stellt bereits einen Teil des Problems dar: Meine Stakeholder zumindest wissen oftmals nicht genau, was genau sie an Qualität denn brauchen. Und wenn sie es wissen, ist es oftmals schwer zu erklären und bleibt dann _implizit_.
Als eine mögliche Abhilfe hat die ISO (International Standardization Organization) schon vor vielen Jahren begonnen, Standards für Software-Produktqualität zu definieren. Leider jedoch hilft deren Vorschlag dem normalen Entwicklungsprojekt etwa so, wie ein Grashalm gegen den Hunger: Theoretisch schon, praktisch kaum.
Im Vortrag zeige ich zuerst auf, was „normale“ Entwicklungsprojekte in punkto Qualitätsanforderungen brauchen – nämlich: konkrete, spezifische und vor allem überprüfbare Anforderungen.
Dazu gibt’s einen pragmatischen und einfachen (open source) Weg, der Entwicklungsteams und anderen Stakeholdern ohne Einstiegshürde zu brauchbaren Qualitätsanforderungen führt. Ganz nebenbei finden Teams damit zu einer gemeinsamen Sprache rund um Qualität.
Wardley Maps sind eine Technik zur Visualisierung und zum Verständnis der Weiterentwicklung von Systemen, Services und Entwicklungsteams. Sie sind ein nützliches Werkzeug für Softwareentwickelnde, um die wichtigsten Komponenten eines Systems zu identifizieren und zu verstehen, wie sie sich im Laufe der Zeit verändern.
In diesem Vortrag führe ich Euch in die grundlegenden Konzepte von Wardley Maps und den Prozess der Erstellung einer Map für ein Softwaresystem ein. Ich werde auch vorstellen, wie Wardley Maps verwendet werden können, um Möglichkeiten für Innovationen zu identifizieren und wie man sie für die Kommunikation des aktuellen Zustands und der zukünftigen Ausrichtung eines Systems nutzen kann.
Ich gebe Beispiele dafür, wie ich Wardley Maps in realen Softwareentwicklungsprojekten einsetze und wie ich daraus kleine und große strategische Entscheidungen ableite. Obwohl Wardley Maps kein Allheilmittel sind, kann es eine nützliche Technik im Werkzeugkasten von Softwareentwickler:innen sein, um Ideen für die Weiterentwicklung von Softwaresystemen mit anderen – insbesondere der Geschäftsseite – zu besprechen.
Unsere Systeme werden immer komplexer und wir verwenden Ansätze wie Microservices oder Functions, um unsere Systeme immer kleinteiliger aufzuteilen. Dadurch verlieren wir jedoch schnell den Überblick über das gesamte System. Wir stellen uns Fragen wie: Welche Services und Libraries gibt es? Wer ist für sie verantwortlich? Wo finde ich den Code und die API-Dokumentationen? Welche Services werden von anderen genutzt und wo befinden sie sich im Lebenszyklus? Ist der Service aktiv und wann wurde er zuletzt aktualisiert? Die Antworten auf diese und weitere Fragen sind im gesamten System verstreut - einige sind in Wikis, andere in der Betriebsplattform oder in der Build-Umgebung. Im schlimmsten Fall besitzt nur ein kleiner Kreis das notwendige Wissen. Um diese Informationsflut unter Kontrolle zu bekommen, benötigen wir eine Einstiegshilfe, die die Informationen zentralisiert und auffindbar macht. In diesem Vortrag werden wir Backstage vorstellen, ein Framework für die Entwicklung und den Betrieb eines solchen zentralen Entwicklungsportals. Wir werden einen Blick hinter die Kulissen werfen, um zu sehen, wie es funktioniert und wie man es auf die eigenen Bedürfnisse anpassen kann.
Kinder zu bekommen ist das eine, täglich mit ihnen zu leben das andere. So richtig darauf vorbereitet hat mich niemand. Dafür trainiert mich mein Zweijähriger im Bootcamp „Familie” täglich für die Herausforderungen in der Kommunikation zwischen Fach(-abteilungen) und IT – sei es unter schwierigen Rahmenbedingungen wie begrenzten Kommunikationszeiten und Herausforderungen, beim Spezifizieren oder beim Berücksichtigen der unterschiedlichen Hintergründe der Gesprächspartner:innen.
In diesem Talk teile ich Learnings aus meinem ganz persönlichen Bootcamp „Familie“ und gebe Anregungen für die erfolgreiche Abstimmung zwischen Fach- und IT-Seite.
Der Betrieb eines Softwaresystems geht immer mit dem Risiko eines Angriffs einher. Insbesondere weltweit erreichbare Webanwendungen sind einer Vielzahl von Angriffen ausgesetzt. Christoph erklärt in diesem Training Bite, wie dir sein iSAQB WEBSEC Training hilft, sichere Anwendungen auch ohne externe Spezialist:innen zu schreiben und die Sicherheit deiner Softwarearchitektur zu jedem Zeitpunkt im Entwicklungszyklus zu gewährleisten – samt offiziellem Zertifikat!
Die größte Privatbrauerei Deutschlands hat seit einigen Jahren mit den „Krombacher Freunden” ein Kundenbindungs-Programm, welches Konsument:innen exklusive Vorteile bietet. Um die Kunden noch intensiver an die Marke zu binden und deren Interessen ins Zentrum zu rücken, war der nächste Schritt ein langfristig angelegtes Loyalitäts-Programm, in dem die Kund:innen für ihre Treue belohnt werden. Mit Krombacher Plus haben die Konsument:innen die Möglichkeit, durch das Einreichen von Kassenzetteln Punkte zu sammeln und diese gegen attraktive Prämien einzutauschen.Um diesen vermeintlich einfachen Prozess für die Konsument:innen und das Unternehmen so reibungslos wie möglich zu gestalten, wurde ein ausgereiftes, automatisiertes Softwareprodukt entwickelt, das die Verarbeitung von besonders vielen Kassenzetteln erlaubt. Da die Prüfung von Kaufbelegen ein ganz zentraler Bestandteil ist, nehmen wir diese in unserem Vortrag genauer unter die Lupe und beleuchten dabei die einzelnen Schritte der digitalen Produktentwicklung sowie die Herausforderungen der technischen Umsetzung.
Developing innovative software products starts with an understanding that AI/ML should solve a real problem. However, the whole process, from identifying the use case to the introduction of ML models in the company, is not trivial. Larysa will talk about EventStorming and the ML Design Canvas, which help domain experts and developers get a shared understanding of a business domain and identify use cases for AI/ML technologies. We formulate each use case as an ML problem using the ML Design Canvas.
Als Kim frisch von der Uni in ihr erstes Projekt kommt, merkt sie schnell, dass selbst heute Werkzeuge und Prozesse zur Qualitätssicherung selten vorhanden sind: unsauberer Code, keine Regeln und kaum Tool-Unterstützung. Kim führt Coding-Guidelines, Qualitätstools und Reviews ein, oft gegen den Willen der Teammitglieder. Sie merkt nicht, wie viel Kraft sie diese Konflikte kosten - und dass sie sich dabei zwar sehr einbringt, aber den Erfolg gefährdet.
Kim wechselt den Arbeitgeber und findet eine ähnliche Situation vor: keine Regeln, keine Automatisierung und keine gute Softwarequalität. Doch dieses Mal macht sie alles anders und erarbeitet gemeinsam mit ihrem Team verschiedene Maßnahmen.
Dieser Vortrag zeigt mit zwei Beispielen, dass Softwarequalität eine wichtige Rolle spielen muss und nicht Werkzeuge entscheidend sind, sondern die Einstellung der Teammitglieder zu verbessern, zum Beispiel über „Collective Ownership of Code” oder die „Pfadfinderregel”.
Have you ever wished to give a new developer, HR or your management a quick overview of your tech stack? Was the only thing you found a long document or a dead wiki page that nobody wanted to read?
This short talk introduces the Tech Stack Canvas, a tool for creating, documenting, and communicating a product’s tech stack. We’ll explore its key elements and the process of creating a new canvas. The goal is to empower tech teams to make informed technology decisions and effectively communicate their tech stack to stakeholders. For a quick overview, visit techstackcanvas.io
Bei der Migration von Bestandsdaten ist es wichtig, zu verstehen, was diese Daten bedeuten. Dieses Verständnis hilft bei der Entscheidung, wie Daten zu behandeln sind, und welcher Aufwand betrieben werden muss, um Sonderfälle zu behandeln. In diesem Vortrag werde ich einige Werkzeuge vorstellen, die es vereinfachen, eine Übersicht über die eigenen Bestandsdaten zu kriegen. Angefangen von einfachen statistischen Werkzeugen und Begriffen werden ich auch Softwaretools und -bibliotheken kurz vorstellen, mit denen ich diese Anforderungen meistere.
Das Buch Team Topologies von Matthew Skelton und Mauel Pais hat sich in den letzten drei Jahren als Referenz für den Entwurf und vor allem auch die Evolution von Delivery Organisationen etabliert. Im Kern werden in Team Topologies vier fundamentale Team-Arten und drei grundlegende Team-Interaktionsformen definiert und in einen evolutionären Ansatz gegossen.
Seit ca. einem Jahr gibt es zudem noch das unFIX Modell von Jurgen Appelo, welches an einigen Stellen stark von Team Topologies beeinflusst ist aber zusätzliche Facetten beleuchtet.
In diesem Vortrag werden beide Ansätze vorgestellt und miteinander verglichen. Des Weiteren gehen wir darauf ein, wie beide Ideen in der praktischen Arbeit zum Einsatz kommen können.
Dieser Vortrag betrachtet am Beispiel eines seit Jahren laufenden und wiederkehrenden Qualifizierungsprogramms für Software-/IT-Architekt:Innen die Herangehensweise, die uns bei dem Entwurf und der Abstimmung geleitet hat.
Status Quo, Marktänderungen, die beteiligten Individuen sowie die Organisationsstrukturen liefern in der Regel konkurrierende Zielsetzungen und Erwartungen, die an eine Qualifizierungsmaßnahme gestellt werden.
In diesem Vortrag geht es um die Organisation und den Aufbau einer erfolgreichen Qualifizierungsmaßnahme, die nicht nur aus Trainings besteht, sondern auch aus sinnvollen Miniprojekten und anderen begleitetenden Aktivitäten.
Large Language Models (LLM) are a new technology that has taken over the world in no time. AI chatbots like ChatGPT have made AI controllable by using natural language and thus accessible and extremely useful to the general public.
Most people have probably already experimented with this or another chatbot and had similar experiences: They know the answer to almost every question, write detailed texts and even respond to counter-questions. There is one very big problem: The chatbots hallucinate, i.e. they invent content that sounds correct but is not correct. In addition, due to the vast amount of training data, it is no longer possible to reconstruct where a piece of information came from.
We have dealt with this problem and tried to find a solution by which a chatbot builds its answers within a given domain and gives sources for the origin of the information used from the domain.
Such knowledge-based chatbots can be used in practically any domain, for example, to chat with documentation, contents of a database or website, using natural language, without the risk of hallucination. We also looked at ideas such as the use of open source LLMs (e.g. LLama2), scalability and cost management.
Im Juni 2023 haben wir einen Event organisiert. Ein Tech Festival mit einem 100%-female Line-up. Women+ in Data and AI Summer Festival in Berlin war eine einzigartige und “not your usual tech conference”. Wie wir auf die Idee gekommen sind, was war unsere Motivation und Mission und welche Auswirkung das Festival hat, erzählen wir in unserem Talk “W+DAI 2023. Unity. Empowerment. Bravery.”
Historisch gewachsene Softwaresysteme befinden sich häufig in einem hybriden Betriebs-Setup, das die Vorteile verschiedener Betriebsplattformen nutzt. Legacy-Systeme werden häufig aufgrund bestimmter Compliance-Anforderungen für Datenschutz und Sicherheitsprüfungen On-Premise betrieben oder schlicht, weil sie technisch nicht in eine dynamische Betriebsumgebung passen. Weniger kritische und neu entwickelte Systeme finden ihren natürlichen Weg in die Public oder Private Cloud. Mit der Verteilung der Systemkomponenten auf unterschiedliche Betriebsplattformen und dem Wachstum der IT-Organisation wachsen jedoch auch die Herausforderungen, Compliance effektiv sicherzustellen. Zu den wirksamsten Maßnahmen zählen unserer Erfahrung nach die Schaffung unterstützender Teamstrukturen und die Anpassung der Software-Delivery-Prozesse.
Versioned or historical data has long been essential for strategic decision-making based on data analysis. In data driven companies, an efficient versioning of data is a must.
Data versioning therefore has become a prominent piece of modern data architectures. This talk provides an overview of typical use cases for data versioning and discusses the pros and cons of the existing methods and tools.
Flutter ist ein Cross-Plattform UI-Framework, das in den letzten Jahren immer mehr an Popularität gewinnt. Flutter verspricht aus einer Codebase Apps für IOS, Android, Web, Desktop, MacOS, Linux & Embedded erzeugen zu können, die mit einer ähnlichen Performance wie native Apps laufen. Dem werde ich in dem Vortrag auf den Grund gehen und Empfehlungen geben für welche Anwendungsfälle Flutter eine sinnvolle Wahl ist.
„Hättet ihr das nicht früher sagen können, dann hätten wir das System anders gebaut!“. Wie seltsam und frustrierend das Leben in der IT manchmal ist, merkt man, wenn spätestens zum dritten Mal Dinge, die “garantiert nie passieren” werden, dann doch passieren. Schade, wenn dann die Aufwände unnötig hoch sind, um unsere Systeme an diese Veränderung anzupassen.
Architekturoptionen können in solchen Situationen Gold wert sein. Dabei investieren wir zu einem früheren Zeitpunkt für einen günstigen Preis (also vergleichsweise wenig Aufwand) in das Bauen einer Architekturoption (z. B. das Einziehen eines Interfaces), die es uns ermöglicht, später zu einem wesentlich günstigeren Preis eine Option zu ziehen (z. B. das Herauslösen eines Moduls als eigener Microservice).
In diesem Talk erkunden wir den schmalen Grat zwischen Overengineering und fahrlässiger Hartcodierung. Ich werde euch die Theorie der Realoptionen vorstellen und zeigen, wie sie euch als Softwarearchitektinnen oder Softwarearchitekten helfen kann, über Projektrisiken nachzudenken und diese gegebenenfalls abzumildern. Anschließend werden wir uns verschiedene Beispiele für Architekturoptionen ansehen und ihr werdet sehen, dass einige dieser Optionen eine Investition sind, die nahezu jedes Softwaresystem eingehen sollte.
Durch KI-Systeme wie ChatGPT werden auch als komplizierter eingestufte Angriffe heutzutage immer leichter. Diese neue Generation von KI-unterstützten Angreifern und Angreiferinnen sind effektiver als vorausgehende Generationen und können Organisationen ernsthaft bedrohen.
Der Vortrag zeigt die Methoden auf, die von der neuen Generation von KI-unterstützten Angreifern und Angreiferinnen eingesetzt werden können, beschreibt die Herausforderungen der Erkennung und Abwehr und teilt Best Practices für den Schutz von Systemen und Daten.
Wie läuft eine Prüfung eigentlich ab, was solltest Du beachten und was lieber vermeiden – wir helfen Dir bei allen Fragen, die Du zur iSAQB-Zertifizierung hast.
Gen-Varianten beeinflussen die individuelle Verträglichkeit von Medikamenten und die Interaktionen bei Polymedikation. Mittels pharmakogenetischen Abklärungen lassen sich Nebenwirkungen reduzieren und die Wirkung medikamentöser Therapien verbessern. Für zunehmend mehr Medikamente werden pharmakogenetische Abklärungen empfohlen oder von Behörden vorgeschrieben.
Die Firma PharmGenetix ist technologisch führend auf dem Gebiet der pharmakogenetischen Analysen. Ihr qualitativ hochstehendes Analyseverfahren und die eigene Softwarelösung ermöglichen einem Arzt, ohne viel Arbeitsaufwand, die Wirkung von Medikamenten patientenbezogen zu beurteilen. Für abgefragte Medikamente wird direkt angezeigt, wie sie ein Patient verträgt, wie sie zu dosieren sind und wie sie mit anderen Medikamenten interagieren.
INNOQ ist seit rund einem Jahr beteiligter Partner von PharmGenetix und unterstützt bei der weiterführenden Digitalisierung. Im Zentrum stehen die Optimierung und Skalierbarkeit der Produktionsprozesse, die zielgruppenspezifische Serviceorientierung der Produkte sowie die Realisierung eines neuartigen Medikations- und Analyse-Dossier für Privatpersonen.
Mit Fokus auf die Digitalisierung und Zusammenarbeit wird in diesem Beitrag vorgestellt, wo das ganze Vorhaben steht, welche Ziele verfolgt werden und welche Herausforderungen anstehen.
One of the most contentious words in technology culture today is “Architect.” I experience an endless stream of divisive, confusing opinions about what "architecture" means. At a conference, an attendee noticed that my badge said "architect" and told me "I want to be an architect too, but I don't know enough about Kubernetes yet".
Architecture, in the systems age, is not (just) Kubernetes. It's not the implementation of any particular toolset. Architecture is designing relationships between parts and adapting those relationship patterns as circumstances change. This requires engaging our mental models and working together to transform them.
The architecture skillset is sociotechnical -- a blend of social and technology skills. It is a way of thinking and communicating. In the modern age, there is no division between the way we think together and the code running in production. Our thinking designs our architecture.
Architecture is structuring good systems thinking.
In this talk, I will admit that *sometimes* architecture is Kubernetes. And share five essential qualities that make a good architect a great architect, regardless of the toolset they employ.
1969 gelang es der Menschheit, mit Apollo 11 auf dem Mond zu landen. Ein gigantisches gesellschaftliches Vorhaben mit unzähligen möglichen Single Points of Failure. Vor Kurzem dann haben wir das James Webb Teleskop erfolgreich ins All geschossen (und aufgebaut), das sage und schreibe 344 Single Points of Failure hatte. Und doch: Bei jedem beginnenden Flugzeugboarding hören wir das vertraute Geräusch von Nadeldruckern. Seit wie vielen Jahrzehnten versuchen wir, synchronisierte Terminkalender (und Termineinladungen) zu lösen? Wie lange werden wir noch Suchen-und-Ersetzen verwenden? Mit welchen technologischen Unzulänglichkeiten müssen wir uns als Menschen herumschlagen, welche Probleme müssen wir bewältigen, um irgendwann eine interplanetare Spezies zu werden? Haben wir den Blick fürs Wesentliche bereits verloren?
Kaffee – ein eigentlich großartiges, geschmacklich vielfältiges Getränk in verschiedensten Ausprägungen. Dennoch fällt es mir gerade in Deutschland schwer, außer Haus guten Kaffee zu finden.
Kommt mit auf eine Reise durch die Historie des Kaffees und Deutschlands Kaffeeproblem, lasst uns gemeinsam mit einigen Vorurteilen aufräumen und genießt einen Ausblick auf eine Reihe von Zubereitungsmöglichkeiten mit INNOQs Coffee Consultant – Horrorgeschichten und -fotos inklusive.
Michael wurde als Jugendlicher in der Metal- und Hardcore-Punk-Szene sozialisiert und hatte dabei das große Glück, dass er das Ganze Ende der 90er erleben durfte. Was auf den ersten Blick aussieht wie „Krach, den zutätowierte Langhaarige fabrizieren”, stellt sich auf den zweiten Blick aber als eine Musikszene mit viel Tiefgang dar. Das Motto lautete „Hardcore is more than music” und entsprechend wurden auch andere Themen besetzt. Es drehte sich in dieser Subkultur Ende der 90er / Anfang der 00er viel um Veganismus, Straight Edge (keine Drogen, keine Zigaretten, keine Promiskuität), Politik und vor allem eine Do It Yourself Einstellung. Beispielsweise hatte einer der größten europäischen Großhändler für vegane Nahrungsmittel seine Ursprünge in diesem Umfeld.
Als Special Guest wird in diesem Talk Maik Weichert von der Band Heaven Shall Burn dabei sein. Heaven Shall Burn entsprangen genau der eben beschriebenen Szene und gehören inzwischen zu den größten Metal Bands in Deutschland. Ihr letztes Album stieg auf Platz 1 in den deutschen Album Charts ein. Die beiden werden Euch ein wenig von dieser Subkultur erzählen und dabei ein paar persönliche Anekdoten einstreuen.
Most of data science projects never make it to production contributing to an endless Jupyter notebooks graveyard. Is there a secret recipe to overcome the PoC phase succeeding into a real data science product? Enjoy the five lessons leant to apply onto product management principles as a result of transforming a bunch of scripts into fully automated models productive in 23 countries!
Residuality theory is a revolutionary new theory of software design that aims to make it easier to design software systems for complex business environments. Residuality theory models software systems as interconnected residues - an alternative to component and process modeling that uses applied complexity science to make managing uncertainty a fundamental part of the design process.
One of the most contentious words in technology culture today is “Architect.” I experience an endless stream of divisive, confusing opinions about what "architecture" means. At a conference, an attendee noticed that my badge said "architect" and told me "I want to be an architect too, but I don't know enough about Kubernetes yet".
Architecture, in the systems age, is not (just) Kubernetes. It's not the implementation of any particular toolset. Architecture is designing relationships between parts and adapting those relationship patterns as circumstances change. This requires engaging our mental models and working together to transform them.
The architecture skillset is sociotechnical -- a blend of social and technology skills. It is a way of thinking and communicating. In the modern age, there is no division between the way we think together and the code running in production. Our thinking designs our architecture.
Architecture is structuring good systems thinking.
In this talk, I will admit that *sometimes* architecture is Kubernetes. And share five essential qualities that make a good architect a great architect, regardless of the toolset they employ.
Viele große Unternehmen setzen noch immer auf zentralisierte, architekturbezogene Teams. Oftmals geben diese Teams anderen Teams architektonische Vorgaben und sorgen dafür, dass diese Vorgaben in der Praxis eingehalten werden. Solche Teams werden häufig als „Elfenbeinturm-Architektur”-Teams bezeichnet, die darauf ausgerichtet sind, hochqualifizierte Architekten und Architektinnen zu bündeln. Solche Rollen sind auf dem Markt zwar selten, passen aber nicht in eine agile Umgebung. In der agilen Welt möchten wir den Teams die Freiheit geben, eigene Entscheidungen zu treffen. Dennoch sind bestimmte Leitplanken erforderlich, um das Gesamtkonstrukt funktionsfähig zu halten. Richtig gewählte Leitplanken können zudem den Koordinationsaufwand zwischen den Teams erheblich verringern. Unser Ziel sollte es sein, die Teams zu befähigen, den Großteil der architektonischen Arbeit selbst zu übernehmen, während gleichzeitig sichergestellt wird, dass alle Komponenten zusammenpassen. Hier setzt das Konzept der Team Topologies von Matthew Skelton und Manuel Pais an. Insbesondere der Teamtyp des „Enabling Teams”, welcher, kurz gesagt, andere Teams mit Wissen und Methodik unterstützt.
In diesem Vortrag erhältst Du einen Überblick über diesen Wandel sowie praktische Tipps, wie Du ein zentrales Architekturteam in ein Enabling Team umwandeln kannst. Das Hauptziel dieses Teams ist es, die Architekturarbeit in anderen Teams zu verbessern. Du wirst lernen:
Zudem werden im Vortrag zahlreiche Praxisbeispiele vorgestellt, die diesen Transformationsprozess begleiten.
Schnelle Software Delivery hängt heute u.a. an der Etablierung von autonomen Teams, die unabhängig voneinander Funktionalität entwickeln und liefern können. Aber wie schaffen wir es, dass diese Teams nicht in unterschiedliche Richtungen laufen, sondern ein gemeinsames Architektur- und Technologieverständnis entwickeln, aber gleichzeitig einen eigenen Entscheidungsspielraum haben?Um diese Fragen zu beantworten, diskutieren wir Architektur-Prinzipien, Makroarchitektur und Service Templates (aka Golden Path, Paved Road, Sensible Defaults, Follow the Trail) und wie diese Ideen hier helfen können, aber auch wo deren Fallstricke liegen
Wardley Maps sind eine Technik zur Visualisierung und zum Verständnis der Weiterentwicklung von Systemen, Services und Entwicklungsteams. Sie sind ein nützliches Werkzeug für Softwareentwickelnde, um die wichtigsten Komponenten eines Systems zu identifizieren und zu verstehen, wie sie sich im Laufe der Zeit verändern.
In diesem Vortrag führe ich Euch in die grundlegenden Konzepte von Wardley Maps und den Prozess der Erstellung einer Map für ein Softwaresystem ein. Ich werde auch vorstellen, wie Wardley Maps verwendet werden können, um Möglichkeiten für Innovationen zu identifizieren und wie man sie für die Kommunikation des aktuellen Zustands und der zukünftigen Ausrichtung eines Systems nutzen kann.
Ich gebe Beispiele dafür, wie ich Wardley Maps in realen Softwareentwicklungsprojekten einsetze und wie ich daraus kleine und große strategische Entscheidungen ableite. Obwohl Wardley Maps kein Allheilmittel sind, kann es eine nützliche Technik im Werkzeugkasten von Softwareentwickler:innen sein, um Ideen für die Weiterentwicklung von Softwaresystemen mit anderen – insbesondere der Geschäftsseite – zu besprechen.
Das Buch Team Topologies von Matthew Skelton und Mauel Pais hat sich in den letzten drei Jahren als Referenz für den Entwurf und vor allem auch die Evolution von Delivery Organisationen etabliert. Im Kern werden in Team Topologies vier fundamentale Team-Arten und drei grundlegende Team-Interaktionsformen definiert und in einen evolutionären Ansatz gegossen.
Seit ca. einem Jahr gibt es zudem noch das unFIX Modell von Jurgen Appelo, welches an einigen Stellen stark von Team Topologies beeinflusst ist aber zusätzliche Facetten beleuchtet.
In diesem Vortrag werden beide Ansätze vorgestellt und miteinander verglichen. Des Weiteren gehen wir darauf ein, wie beide Ideen in der praktischen Arbeit zum Einsatz kommen können.
„Hättet ihr das nicht früher sagen können, dann hätten wir das System anders gebaut!“. Wie seltsam und frustrierend das Leben in der IT manchmal ist, merkt man, wenn spätestens zum dritten Mal Dinge, die “garantiert nie passieren” werden, dann doch passieren. Schade, wenn dann die Aufwände unnötig hoch sind, um unsere Systeme an diese Veränderung anzupassen.
Architekturoptionen können in solchen Situationen Gold wert sein. Dabei investieren wir zu einem früheren Zeitpunkt für einen günstigen Preis (also vergleichsweise wenig Aufwand) in das Bauen einer Architekturoption (z. B. das Einziehen eines Interfaces), die es uns ermöglicht, später zu einem wesentlich günstigeren Preis eine Option zu ziehen (z. B. das Herauslösen eines Moduls als eigener Microservice).
In diesem Talk erkunden wir den schmalen Grat zwischen Overengineering und fahrlässiger Hartcodierung. Ich werde euch die Theorie der Realoptionen vorstellen und zeigen, wie sie euch als Softwarearchitektinnen oder Softwarearchitekten helfen kann, über Projektrisiken nachzudenken und diese gegebenenfalls abzumildern. Anschließend werden wir uns verschiedene Beispiele für Architekturoptionen ansehen und ihr werdet sehen, dass einige dieser Optionen eine Investition sind, die nahezu jedes Softwaresystem eingehen sollte.
Moderne Datenarchitekturen verwenden das Konzept eines Datenprodukts, um die Bereitstellung und Nutzung von Daten besser zu organisieren.
Ein Datenprodukt bildet eine logische Einheit um fachlich relevante Daten und umfasst alle Komponenten, um diese Daten zu speichern, aufzubereiten, zu aggregieren, zu erklären und für die Nutzer:innen so einfach wie möglich zugänglich zu machen.
Jochen Christ, Autor von datamesh-architecture.com, zeigt, wie ein Datenprodukt in der AWS-Cloud implementiert werden kann, welche Funktionen eine gute Datenplattform zur Verfügung stellen sollte, und wie Datenprodukt-Governance mit dem Data Mesh Manager unterstützt wird.
Data Contracts (https://datacontract.com/) sind ein zentrales Element für eine saubere Implementierung eines Data Mesh. Während die Data Products die Knoten des Mesh bilden, stellen die Data Contracts die verbindenden Kanten dar. Sie definieren somit alle Beziehungen zwischen den Data Products, indem sie Metainformationen über die verwendeten Daten und deren Verwendung festhalten. Ein Data Contract sollte immer die Grundlage für die Nutzung eines Data Products sein, da er als Dokumentation hilft, Richtlinien für Datenqualität und Governance einzuhalten und Zugriffskontrollen zu automatisieren. Im Vortrag werden die grundlegenden Begriffe geklärt, um ein gutes Verständnis für Data Contracts und deren Bedeutung zu schaffen.
Datenarchitekt:innen und Dateningenieur:innen diskutieren derzeit, wie genau Data Contracts implementiert werden sollen. Denn während sich bei operationalen APIs OpenAPI als Standard für Schnittstellenbeschreibungen durchgesetzt hat, konnte sich in diesem noch recht jungen Bereich noch kein Standard etablieren. Wir möchten hier einen Überblick geben und die Vor- und Nachteile verschiedener Ansätze beleuchten.
Mit dem Tool Datacontract CLI (https://cli.datacontract.com/) arbeitet Stefan Negele an einer Open Source Lösung, um Data Contracts zu erstellen und deren Stabilität zu gewährleisten. Im Talk werden die wichtigsten Funktionen vorgestellt und erklärt, wie es helfen kann, die Robustheit von Data Contracts zu gewährleisten.
Der Vortrag richtet sich an alle, die ein tieferes Verständnis für die Rolle von Data Contracts gewinnen wollen. Entwickler:innen, Architekt:innen und Datenexpert:innen erhalten wertvolle Einblicke in eine der wesentlichen Grundlagen für eine erfolgreiche und skalierbare Datenintegration.
Developing innovative software products starts with an understanding that AI/ML should solve a real problem. However, the whole process, from identifying the use case to the introduction of ML models in the company, is not trivial. Larysa will talk about EventStorming and the ML Design Canvas, which help domain experts and developers get a shared understanding of a business domain and identify use cases for AI/ML technologies. We formulate each use case as an ML problem using the ML Design Canvas.
Large Language Models (LLM) are a new technology that has taken over the world in no time. AI chatbots like ChatGPT have made AI controllable by using natural language and thus accessible and extremely useful to the general public.
Most people have probably already experimented with this or another chatbot and had similar experiences: They know the answer to almost every question, write detailed texts and even respond to counter-questions. There is one very big problem: The chatbots hallucinate, i.e. they invent content that sounds correct but is not correct. In addition, due to the vast amount of training data, it is no longer possible to reconstruct where a piece of information came from.
We have dealt with this problem and tried to find a solution by which a chatbot builds its answers within a given domain and gives sources for the origin of the information used from the domain.
Such knowledge-based chatbots can be used in practically any domain, for example, to chat with documentation, contents of a database or website, using natural language, without the risk of hallucination. We also looked at ideas such as the use of open source LLMs (e.g. LLama2), scalability and cost management.
Versioned or historical data has long been essential for strategic decision-making based on data analysis. In data driven companies, an efficient versioning of data is a must.
Data versioning therefore has become a prominent piece of modern data architectures. This talk provides an overview of typical use cases for data versioning and discusses the pros and cons of the existing methods and tools.
Arbeitest Du an einem Legacy-System, das schwer zu warten ist? Du willst es modernisieren, aber weißt nicht, wie? Lass’ uns das besser machen!
In diesem kurzen Workshop bekommst Du keine Folien, sondern migrierst ein Legacy-System als praxisnahes Beispiel. Du arbeitest spielerisch mit anderen zusammen, um die neuen Anforderungen umzusetzen. Dabei liegt der Fokus auf der Mikroarchitektur eines Teilsystems.
Das Hauptziel ist, Dich auf die häufigsten Herausforderungen bei einer Migration vorzubereiten.
In den meisten Projekten treffen wir auf folgende Arten von Architekturdokumentation: Entweder gibt es gar keine Dokumentation, oder es existiert veraltete Dokumentation in gigantischem Umfang. Unabhängig davon ist der Effekt jedoch der gleiche – es wird nichts Neues mehr dokumentiert. Begründet wird dies meist mit „Das liest doch niemand”, „Dafür haben wir keine Zeit” oder „Das findet ja niemand mehr”. Kommt Euch bekannt vor? Dann ist dieser Vortrag genau das Richtige für Euch.
Wir stellen Euch den Architecture Communication Canvas (ACC) vor, mit dem Ihr in kurzer Zeit die wichtigsten Aspekte Eurer Architektur dokumentieren und kommunizieren könnt. Der Canvas ist kompatibel zum arc42-Template, jedoch wesentlich kompakter. Mit Beispielen aus der Praxis sowie praktischen Tipps zeigen wir Euch, dass Dokumentation zugleich sparsam erstellt werden und dabei nützlich für Stakeholder sein kann – und das Ganze auch noch Spaß macht!
Höher, schneller, weiter: Was ist gut genug?
Qualität wird für Software immer wichtiger. Unsere Systeme sollen ständig online, hochperformant, robust, elastisch, skalierbar und sicher sein, oder was immer eure Stakeholder so unter Qualität verstehen. Das jedoch stellt bereits einen Teil des Problems dar: Meine Stakeholder zumindest wissen oftmals nicht genau, was genau sie an Qualität denn brauchen. Und wenn sie es wissen, ist es oftmals schwer zu erklären und bleibt dann _implizit_.
Als eine mögliche Abhilfe hat die ISO (International Standardization Organization) schon vor vielen Jahren begonnen, Standards für Software-Produktqualität zu definieren. Leider jedoch hilft deren Vorschlag dem normalen Entwicklungsprojekt etwa so, wie ein Grashalm gegen den Hunger: Theoretisch schon, praktisch kaum.
Im Vortrag zeige ich zuerst auf, was „normale“ Entwicklungsprojekte in punkto Qualitätsanforderungen brauchen – nämlich: konkrete, spezifische und vor allem überprüfbare Anforderungen.
Dazu gibt’s einen pragmatischen und einfachen (open source) Weg, der Entwicklungsteams und anderen Stakeholdern ohne Einstiegshürde zu brauchbaren Qualitätsanforderungen führt. Ganz nebenbei finden Teams damit zu einer gemeinsamen Sprache rund um Qualität.
Als Kim frisch von der Uni in ihr erstes Projekt kommt, merkt sie schnell, dass selbst heute Werkzeuge und Prozesse zur Qualitätssicherung selten vorhanden sind: unsauberer Code, keine Regeln und kaum Tool-Unterstützung. Kim führt Coding-Guidelines, Qualitätstools und Reviews ein, oft gegen den Willen der Teammitglieder. Sie merkt nicht, wie viel Kraft sie diese Konflikte kosten - und dass sie sich dabei zwar sehr einbringt, aber den Erfolg gefährdet.
Kim wechselt den Arbeitgeber und findet eine ähnliche Situation vor: keine Regeln, keine Automatisierung und keine gute Softwarequalität. Doch dieses Mal macht sie alles anders und erarbeitet gemeinsam mit ihrem Team verschiedene Maßnahmen.
Dieser Vortrag zeigt mit zwei Beispielen, dass Softwarequalität eine wichtige Rolle spielen muss und nicht Werkzeuge entscheidend sind, sondern die Einstellung der Teammitglieder zu verbessern, zum Beispiel über „Collective Ownership of Code” oder die „Pfadfinderregel”.
Historisch gewachsene Softwaresysteme befinden sich häufig in einem hybriden Betriebs-Setup, das die Vorteile verschiedener Betriebsplattformen nutzt. Legacy-Systeme werden häufig aufgrund bestimmter Compliance-Anforderungen für Datenschutz und Sicherheitsprüfungen On-Premise betrieben oder schlicht, weil sie technisch nicht in eine dynamische Betriebsumgebung passen. Weniger kritische und neu entwickelte Systeme finden ihren natürlichen Weg in die Public oder Private Cloud. Mit der Verteilung der Systemkomponenten auf unterschiedliche Betriebsplattformen und dem Wachstum der IT-Organisation wachsen jedoch auch die Herausforderungen, Compliance effektiv sicherzustellen. Zu den wirksamsten Maßnahmen zählen unserer Erfahrung nach die Schaffung unterstützender Teamstrukturen und die Anpassung der Software-Delivery-Prozesse.
In letzter Zeit findet WebAssembly (WASM) als Laufzeitumgebung auch außerhalb des Browsers immer mehr Verbreitung, z. B. als Alternative zu Containern. Mit Tools wie Emscripten können notorisch unsichere Sprachen wie C und C++ nach WebAssembly kompiliert werden. Grund genug, sich näher mit den Security-Mechanismen von WebAssembly auseinanderzusetzen.
Nach einer kurzen Einführung in WebAssembly und einem Überblick über die vorhandenen Implementierungen schauen wir uns die Security-Mechanismen von WebAssembly genauer an, und vergleichen diese mit den Security-Mechanismen von anderen Laufzeitumgebungen.
Bei den „Advent Of Code“-Programmierproblemen stößt du auf die absurdesten Herausforderungen. Wie findest du beispielsweise den besten Weg durch ein Höhlensystem, um eine Horde Elefanten zu retten? Oder welche Roboter baust du, um möglichst viele Geoden zu knacken?
Die Lösungen für diese Fragen liegen in (mehr oder weniger) bekannten Algorithmen der Informatik, die im täglichen (Berufs-)Leben selten Anwendung finden. Umso spannender – wenn auch nicht immer praktisch – ist es, sich wieder damit auseinanderzusetzen.
In diesem Vortrag schauen wir uns anhand der genannten Probleme einige Graphalgorithmen an. Gemeinsam erforschen wir, wie diese optimiert werden können und wie du selbst in einer eher maschinenfernen Sprache wie Java deutlich an Laufzeit sparen kannst.
Unsere Systeme werden immer komplexer und wir verwenden Ansätze wie Microservices oder Functions, um unsere Systeme immer kleinteiliger aufzuteilen. Dadurch verlieren wir jedoch schnell den Überblick über das gesamte System. Wir stellen uns Fragen wie: Welche Services und Libraries gibt es? Wer ist für sie verantwortlich? Wo finde ich den Code und die API-Dokumentationen? Welche Services werden von anderen genutzt und wo befinden sie sich im Lebenszyklus? Ist der Service aktiv und wann wurde er zuletzt aktualisiert? Die Antworten auf diese und weitere Fragen sind im gesamten System verstreut - einige sind in Wikis, andere in der Betriebsplattform oder in der Build-Umgebung. Im schlimmsten Fall besitzt nur ein kleiner Kreis das notwendige Wissen. Um diese Informationsflut unter Kontrolle zu bekommen, benötigen wir eine Einstiegshilfe, die die Informationen zentralisiert und auffindbar macht. In diesem Vortrag werden wir Backstage vorstellen, ein Framework für die Entwicklung und den Betrieb eines solchen zentralen Entwicklungsportals. Wir werden einen Blick hinter die Kulissen werfen, um zu sehen, wie es funktioniert und wie man es auf die eigenen Bedürfnisse anpassen kann.
Bei der Migration von Bestandsdaten ist es wichtig, zu verstehen, was diese Daten bedeuten. Dieses Verständnis hilft bei der Entscheidung, wie Daten zu behandeln sind, und welcher Aufwand betrieben werden muss, um Sonderfälle zu behandeln. In diesem Vortrag werde ich einige Werkzeuge vorstellen, die es vereinfachen, eine Übersicht über die eigenen Bestandsdaten zu kriegen. Angefangen von einfachen statistischen Werkzeugen und Begriffen werden ich auch Softwaretools und -bibliotheken kurz vorstellen, mit denen ich diese Anforderungen meistere.
Flutter ist ein Cross-Plattform UI-Framework, das in den letzten Jahren immer mehr an Popularität gewinnt. Flutter verspricht aus einer Codebase Apps für IOS, Android, Web, Desktop, MacOS, Linux & Embedded erzeugen zu können, die mit einer ähnlichen Performance wie native Apps laufen. Dem werde ich in dem Vortrag auf den Grund gehen und Empfehlungen geben für welche Anwendungsfälle Flutter eine sinnvolle Wahl ist.
Wir sprechen in unserem Vortrag darüber, was soziotechnische Systeme sind, grenzen den Begriff ein und nähern uns den Herausforderungen, denen wir gegenüberstehen, wenn sich Technologie und soziale Systeme verflechten.
Was haben Entwicklung und Architektur mit dem Business und den Nutzer:innen zu tun?
Die Antwort ist einfach: sehr viel. Das gesamte Team sollte verstehen, für wen das Produkt gedacht ist, an dem es arbeitet, und welchem höheren Ziel die einzelnen Aufgaben dienen. Niemand sollte Aufgaben einfach nur abarbeiten, die in Tickets beschrieben sind.
Die digitale Produktentwicklung ist nicht nur Bestandteil eines Teams, das sich „die Produktmenschen“ oder „die UXler:innen“ nennt. Sie ist ein elementarer Bestandteil der digitalen Transformation und bildet die Basis für erfolgreiche – oder eben nicht erfolgreiche – digitale Produkte.
Die Digitalisierung schreitet kontinuierlich voran. Daher müssen Prozesse, Strukturen und Wertschöpfungsketten flexibel und regelmäßig angepasst werden. Das bedeutet, dass unsere Software und die zugrundeliegende Architektur ebenso reagieren müssen.
Wie schaffen wir es jedoch, als Team mit dieser Geschwindigkeit Schritt zu halten und unsere Software, Services und Produkte dennoch qualitativ hochwertig zu liefern? Wie müssen wir zusammenarbeiten, um flexibel auf den Markt und die Menschen dahinter reagieren zu können?
In diesem Talk fokussieren wir uns auf digitale Produktentwicklung – jedoch mit dem Bewusstsein, dass ein harmonisches Zusammenspiel von Mindset, Menschen und Methode gegeben sein muss.
Kinder zu bekommen ist das eine, täglich mit ihnen zu leben das andere. So richtig darauf vorbereitet hat mich niemand. Dafür trainiert mich mein Zweijähriger im Bootcamp „Familie” täglich für die Herausforderungen in der Kommunikation zwischen Fach(-abteilungen) und IT – sei es unter schwierigen Rahmenbedingungen wie begrenzten Kommunikationszeiten und Herausforderungen, beim Spezifizieren oder beim Berücksichtigen der unterschiedlichen Hintergründe der Gesprächspartner:innen.
In diesem Talk teile ich Learnings aus meinem ganz persönlichen Bootcamp „Familie“ und gebe Anregungen für die erfolgreiche Abstimmung zwischen Fach- und IT-Seite.
Have you ever wished to give a new developer, HR or your management a quick overview of your tech stack? Was the only thing you found a long document or a dead wiki page that nobody wanted to read?
This short talk introduces the Tech Stack Canvas, a tool for creating, documenting, and communicating a product’s tech stack. We’ll explore its key elements and the process of creating a new canvas. The goal is to empower tech teams to make informed technology decisions and effectively communicate their tech stack to stakeholders. For a quick overview, visit techstackcanvas.io
Im Juni 2023 haben wir einen Event organisiert. Ein Tech Festival mit einem 100%-female Line-up. Women+ in Data and AI Summer Festival in Berlin war eine einzigartige und “not your usual tech conference”. Wie wir auf die Idee gekommen sind, was war unsere Motivation und Mission und welche Auswirkung das Festival hat, erzählen wir in unserem Talk “W+DAI 2023. Unity. Empowerment. Bravery.”
Durch KI-Systeme wie ChatGPT werden auch als komplizierter eingestufte Angriffe heutzutage immer leichter. Diese neue Generation von KI-unterstützten Angreifern und Angreiferinnen sind effektiver als vorausgehende Generationen und können Organisationen ernsthaft bedrohen.
Der Vortrag zeigt die Methoden auf, die von der neuen Generation von KI-unterstützten Angreifern und Angreiferinnen eingesetzt werden können, beschreibt die Herausforderungen der Erkennung und Abwehr und teilt Best Practices für den Schutz von Systemen und Daten.
Ein hochkarätiges Event! Inhaltlich vielfältig und lehrreich bei gleichzeitig hervorragenden RednerInnen – Der Technology Day war jede Minute meiner Zeit wert.
Wieder ein breites und kompetentes Programm, das man sich remote persönlich zuschneiden konnte. Danke, dass Ihr Klimaschutz in den Mittelpunkt rückt.
Sehr authentisch, einladend und ein tolles, diverses Speaker:innen-LineUp. Ich fühlte mich willkommen und komme sehr gerne wieder!
Sehr inspirierend.
Für die Veranstaltung gilt der Berlin Code of Conduct
Wende Dich gerne an technologyday@innoq.com
