Ausgewählte Vorträge

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 bei schwierigen Rahmenbedingungen wie begrenzten Kommunikationszeiten und -herausforderungen beim Spezifizieren oder beim Berücksichtigen der unterschiedlichen Hintergründe der Gesprächspartner.

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.

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 haben wir dann das James Webb Teleskop erfolgreich ins All geschossen – und aufgebaut – mit sage und schreibe 344 Single Points of Failure. 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?

Während wir unaufhörlich kleine, aber inkrementelle Fortschritte machen, sind die wirklich großen Herausforderungen, die uns als Unternehmen und Gesellschaften antreiben sollten, noch weitgehend unberührt. Unstrukturierte Daten türmen sich in unseren Systemen. Wir widmen uns weiter mit Inbrunst dem Kleinteiligen. Während wir gleichzeitig die großen Herausforderungen in den Hintergrund drängen. Unsere Zeit ist endlich. Haben wir aufgegeben?

Talk+ (Vortrag zum Nachlesen)

Wer würde denn gerne mal zum Mars fliegen? Tatsächlich gehen ein paar Hände hoch. Oft ist es aber auch so, dass keine einzige Hand hochgeht - zu viele negative Konnotationen zum Mars. Elon ist da nur eines der Probleme. Für viele ist es keine besonders reizvolle Idee, für andere wiederum total. Aber ich würde euch gerne mitnehmen - lasst uns mal probieren, dorthin zu fliegen.

Kurz zu mir, bevor wir einsteigen: Ich bin Robert von INNOQ und dort Head of Data und AI. Nebenbei mache ich noch einen Podcast - wenn euch das interessiert, hört gerne mal rein. Meine Kollegin und ich sprechen dort mit den verschiedensten Menschen zum Thema AI. Wir hatten schon spannende Gäste dabei: einen Designer, einen FAZ-Journalisten, eine Verhaltensmathematikerin und weitere. Wir sind noch relativ frisch, haben also noch nicht allzu viele Folgen.

Wer weiß, was diese Dinge hier sind? Die Titelfolie hat es ja schon verraten - das sind Nadeldrucker. Als ich früher noch als Consultant bei uns arbeitete - wir sind ja eine IT-Beratung - bin ich noch viel geflogen. Ein Projekt hatte ich in Zürich, da ging es einmal die Woche zum Flughafen Zürich, hin und zurück. Das ist übrigens kein Foto vom Züricher Flughafen, das stammt aus dem Internet.

Wenn man regelmäßig am Flughafen sitzt, fängt man irgendwann an, sich Fragen zu stellen. Das kennen bestimmt einige von euch. Bei mir war es diese eine Sache: Irgendwann ist es dem Businesskasper oder der Businesskasperin regelrecht ins Blut übergegangen - wenn der Nadeldrucker rattert, muss alles stehen und liegen gelassen werden, das Boarding beginnt. Dieses charakteristische Geräusch ertönt noch bevor die Ansage kommt, dass die Boarding-Gruppen nach vorne kommen sollen. Manche Länder sind mittlerweile so schlau, dass sie das mit den Boarding-Gruppen gar nicht mehr machen. Aber der Businesskasper weiß: Wenn der Nadeldrucker rattert, geht es los.

Ich war damals in einem Digitalisierungsprojekt und fragte mich: Warum? Das kann doch nicht wahr sein! Warum sitze ich hier seit gefühlt Ewigkeiten am Flughafen und höre immer noch ratternde Nadeldrucker? Was ist da los? Wir sind doch eigentlich weiter. In meiner Vorstellung war das das ältestmögliche Museumsstück an Technik, dem man im Alltag noch regelmäßig begegnet.

Bei der Recherche dazu geriet ich in ein regelrechtes Rabbit Hole. Ihr kennt diese Internet-Rabbit-Holes - man fängt an zu recherchieren und landet meistens auf Reddit, wo man dann ewig hängenbleibt. Bei mir begann es auf Twitter - damals hieß es noch Twitter. Interessanterweise stellte nicht nur ich mir diese Fragen. Das Internet ist voll davon: “Warum leiten Nadeldrucker das Boarding ein?” Es gibt unzählige Weisheiten und Witze dazu. Wenn man nach Nadeldruckern auf Social Media sucht, findet man erstaunlich viel Unterhaltsames.

Der Weg führt einen natürlich immer zu Reddit, wo alles erschöpfend von der Community diskutiert wird. Die besten Antworten stehen ganz oben. Die Antwort eines Users - den es mittlerweile scheinbar nicht mehr gibt - fand ich besonders interessant. Sie enthielt vieles, wo ich mich überhaupt nicht hineinversetzen konnte oder wollte.

Aber ein Punkt war faszinierend: Es ist ein UX-Problem, das diese Drucker lösen. Man hält an ihnen fest, weil sie im Gegensatz zu normalen Tintenstrahl- oder Laserdruckern auf einem endlosen Papier drucken können. Bei Passagierlisten ist so ein langes, rollbares Blatt Papier, auf dem man auch wieder zurückgehen kann, ausgesprochen praktisch. Der menschliche Körper interagiert mit einem solchen Stück Papier erstaunlich effektiv.

Und: sie sind einfach verdammt robust. Wer hat denn einen Tintenstrahldrucker zu Hause oder hatte einen? Ich hatte bestimmt schon zehn Stück. Die sind nicht für Robustheit entwickelt, sondern dafür, Tintenpatronen zu verkaufen. Manche nennen das sogar einen Scam.

Aber zurück zu den Nadeldruckern und zu mir als Digitalisierungsconsultant am Boarding Gate der Swiss Air. Da habe ich mich gefragt: Bist du nicht eigentlich ein bisschen überheblich? Da sitzt du, der Businesskasper-Consultant, der den Leuten erzählt, wie sie ihre Digitalisierungsprojekte voranbekommen sollen - oder daran mitarbeitet. Du sitzt am Boarding Gate und rümpfst die Nase: “Ach ihr Deppen, wieso benutzt ihr in Zeiten der Digitalisierung noch Nadeldrucker? Wie lächerlich.”

Im Rückblick fand ich mich da ziemlich überheblich. Und dann fragte ich mich: Liegt uns das irgendwie? Ich sage jetzt “uns”, aber eigentlich meine ich mich - bitte fühlt euch nicht angegriffen. Wenn man in der IT-Branche arbeitet, erwischt man sich schon dabei. Wir lösen ja Digitalisierungsthemen im Kleinen wie im Großen. Man ertappt sich nicht nur bei der Nadeldrucker-Überheblichkeit dabei, wie man urteilt, Leute abstempelt: “Ah, die Deppen, die wissen es nicht besser” oder “Die Drucker stehen da halt seit 1000 Jahren, hat mal jemand vergessen auszutauschen.” Meistens haben die Leute aber gute Gründe.

Wer weiß, was das hier ist? “Rakete” höre ich von vielen Seiten, es geht in die Richtung. Das war das Transportfahrzeug für die Saturn V-Rakete der Apollo 11-Mission, um sie zur Abschussrampe zu fahren. Dieses Fahrzeug hatte keine andere Aufgabe, wurde nur dafür gebaut. Beeindruckend sind die Größenverhältnisse - ein gigantisches Vorhaben, dieses Transportfahrzeug für ein paar hundert Meter zu bauen, das danach nicht mehr benutzt wird. Und das ist nur ein kleiner Teil eines gewaltigen Vorhabens wie der Mondmission. Solche Details großer Projekte zu betrachten und einen Schritt zurückzutreten, finde ich faszinierend.

Wer sich dafür interessiert: Es gibt eine großartige Dokumentation namens “Apollo 11” von Todd Douglas Miller. Ich weiß nicht, wie viele Apollo 11-Dokus es gibt - wenn man auf Netflix danach sucht, findet man sicher einige. Diese ist besonders, weil niemand etwas erzählt. Man sieht nur Originalaufnahmen aus der Zeit der Mission. Es ist eine sehr beobachtende Dokumentation. Ich hing gebannt vorm Fernseher und fand es unglaublich intensiv, weil eben niemand spricht - du bist einfach dabei.

Sie haben enormen Aufwand betrieben, diese alten Filmmaterialien unter anderem mit KI und anderen Verfahren hochzuskalieren. Man bekommt sogar 8K-Neuabtastungen des Materials. Auf einem guten Fernseher ist das extrem beeindruckend. Und nie sagt jemand ein Wort. Absolut empfehlenswert.

Wer weiß, was das hier ist? Das sind Teile des James Webb-Weltraumteleskops. Der Mitarbeiter, den man hier sieht, macht die Endabnahme, bevor das Teleskop gefaltet, verpackt, zur Startrampe transportiert, in die Kapsel verladen und zum Lagrange-Punkt geschossen wird. Ich hätte keinen Bock auf so eine Endabnahme. Das Problem ist: Wenn da ein Staubkorn drauf ist, dann ist es da für immer. Auch das ist wieder so ein Thema der großen Vorhaben.

Das finde ich total beeindruckend - diese Endabnahme, und dann noch mal mit dem Staubwedel drüber, bevor das Teleskop zum Lagrange-Punkt geschossen wird. Wenn ich da etwas vergesse, war es das. Oder wenn der Staubwedel noch schmutzig war vom Bücherregal. Das ist ein echter Single Point of Failure.

Hier sehen wir das ganze Teleskop noch einmal. Gerade haben wir Teile gesehen, jetzt nur noch ein Element. Es ist ein gewaltiges Gerät, wenn auch in den Dimensionen natürlich nicht mit Apollo 11 vergleichbar. Aber es zeigt, was passiert, wenn man in einen Ausschnitt solcher Vorhaben eintaucht. Das waren ja gesamtgesellschaftliche Projekte - Apollo 11 sicherlich noch mehr als James Webb.

Das ist kein gewöhnliches Projekt, keine Digitalisierung, keine Prozessautomatisierung. Was da dranhängt, ist Wahnsinn. Beim James Webb-Weltraumteleskop gab es 344 Single Points of Failure. Für Apollo 11 habe ich keine genaue Zahl gefunden - vielleicht waren es mehr, vielleicht weniger. Aber selbst diese dreistellige Zahl klingt erstmal relativ niedrig. Doch was bedeutet ein Single Point of Failure? Wenn einer dieser Fälle eintritt, ist die Mission katastrophal gescheitert.

Ein Staubkorn kann man vielleicht noch ausgleichen, das ist kein Single Point of Failure. Aber wenn irgendetwas schiefgeht - der Transport zur Startrampe, falsches Verpacken, wenn sich das Sonnensegel am Lagrange-Punkt nicht entfaltet, irgendeine Sicherung rausfliegt - von solchen kritischen Punkten gibt es 344. Dann kann ich die vielen, vielen Milliarden, die in dieses Projekt geflossen sind, abschreiben. Das war’s dann. Man hat kein zweites Exemplar.

Wir wissen ja, dass wir es geschafft haben. Jetzt bekommen wir super schöne Bilder. Wobei - das Ding macht natürlich keine Fotos, auch wenn man sich das so vorstellt. Es nimmt Rohdaten auf verschiedenen Lichtwellenlängen auf, aus denen man dann solche Bilder generieren kann. Die werden auch umfangreich nachbearbeitet, mittlerweile ist da auch viel KI im Einsatz. Es liefert gigantisch viel mehr Daten als das Hubble-Teleskop.

Da habe ich mich gefragt: Warum macht man das überhaupt? Es löst ein Problem, das wir bisher nicht lösen konnten: Wir konnten nicht weit genug in die Vergangenheit schauen. Ihr kennt das alle - wenn Papa oder Mama erzählt haben: “Schau mal da oben, die Sterne am Himmel. Den Stern dort gibt es vielleicht schon gar nicht mehr, weil das Licht so lange zu uns braucht.” Als Kind ist man davon total fasziniert. Mit dem Teleskop können wir das jetzt im großen Maßstab: Wir können so weit zurückschauen, bis zum Ursprung der Photonen und anderen Daten, dass wir quasi die Entstehung des Universums erforschen können. Vieles deutet darauf hin, dass wir das damit entschlüsseln werden. Das ist schon ein gewaltiges Projekt, finde ich.

Also - wer will noch zum Mars? Wer will denn weiter? Ich würde auch lieber weiter. Mars haben wir schon so oft gesehen, wie viele Roboter hatten wir da schon? Elon versucht es immer noch, es wird jetzt wahrscheinlich sehr viel schneller gehen. Aber was sollen wir da? Die Atmosphäre ist giftig, die Schwerkraft ist anders, die Oberfläche ist nicht bewohnbar. Um in Bunkern zu leben, muss ich nicht dorthin.

Eigentlich ist doch interstellare Raumfahrt viel interessanter. Da gibt es vielleicht Sternensysteme mit bewohnbaren Planeten. Vieles deutet darauf hin, dass es sie gibt - das erforscht man jetzt auch mit dem James Webb Teleskop. Ich finde es immer gut, Bücher aus völlig anderen Domänen zu lesen. Avi Loeb ist ein faszinierender Wissenschaftler, der in Harvard lehrt und schon lange Themen wie interstellare Raumfahrt erforscht.

So, wenn wir jetzt sagen: Mars? Nee, lass uns lieber eine Nummer größer denken, irgendwohin, wo vielleicht Leben möglich wäre - dann müssen wir interstellar reisen. Mein eigentliches Thema für den Vortrag - falls wir den Nadeldrucker schon vergessen haben - ist: Lasst uns doch wieder die großen Sachen als Gesellschaft anpacken. Dieses Wühlen im Kleinen und Meckern über “Wieso benutzt ihr nur Nadeldrucker?” nervt. Eigentlich müsste man zwei Schritte zurücktreten und sich wieder die großen Bretter vornehmen und die bohren.

Das tun wir Menschen irgendwie nur ganz, ganz selten. Alle Jubeljahrzehnte mal: Apollo 11, James Webb. So wahnsinnig viel gibt es da nicht. Was wir gut können, sind Kriege dazwischen. Aber bleiben wir mal beim Thema.

Also: Mars - keinen Bock, aus welchen Gründen auch immer. Wir wollen mal zu Tau Ceti oder so fliegen. Was brauchen wir dafür? Zunächst müssen wir schauen, wo wir überhaupt stehen.

In dem Buch von Avi Loeb wird die sogenannte Kardaschow-Skala erwähnt. Dort ordnet man Zivilisationen in Schubladen ein. Wir lieben ja Schubladen, aber manchmal sind sie ganz hilfreich, um zu sehen, wer wo steht. Interstellare Raumfahrt ist einfach das härteste Problem, das eine Zivilisation - müssen nicht die Menschen sein - lösen kann. Es gibt nichts Härteres, das weiß man.

Wo stehen wir denn? Es gibt die Typ-1-Zivilisationen, die können die auf ihrem Heimatplaneten verfügbare Energie vollständig nutzen. Da können wir aufhören zu lesen, weil das können wir nicht. Damit fangen wir gerade erst an, wenn man in großen Maßstäben denkt. Typ 2 - wie gesagt, wir brauchen nicht so weit lesen - kann die gesamte Energie ihres Sterns nutzen, Dyson-Sphäre drumherum bauen, keine Energieverluste. Da geht man schon sehr weit in die Science-Fiction. Und Typ 3 kann die Energie der ganzen Galaxie, in unserem Fall der Milchstraße, nutzen.

Warum brauchen wir so viel Energie? Wenn wir uns anschauen, was interstellare Raumfahrt für eine Energie kostet, merkt man schnell, dass man sie braucht. In dem Buch gibt es einen interessanten Fall, der tatsächlich erforscht wird. Man experimentiert damit, eine winzige Sonde vom Gewicht einer Briefmarke mit einem Laser zu beschleunigen - von der Erde aus oder besser der Erdumlaufbahn, damit man die Gravitation schon überwunden hat. Wir bündeln Lichtenergie auf eine briefmarkengroße Fläche und versuchen, ein Sensormodul mit ein paar Sensoren in Richtung eines anderen Sonnensystems zu schießen.

Ganz klein, aber ein Riesenvorhaben. Man braucht derart viel Energie, um diese Briefmarke auf die nötigen Geschwindigkeiten zu bringen, dass man in den nächsten Jahrhunderten vielleicht noch mitbekommt - wir oder unsere Nachfolgegenerationen - was das Ding dann für Daten zurückübermittelt. Denn die müssen ja auch wieder zurück. Wenn man da einmal eintaucht - nächstes Rabbit Hole - ist es unfassbar. Das ist das größte Problem. Wir haben gesehen: Wir sind noch nicht mal Typ 1.

Was sind wir denn? Das können wir auch nachlesen - sehr eindrücklich: Wir sind eine “Consumer Goods to Trash Civilization”. Wir haben es leider perfektioniert, im industriellen Maßstab Konsumgüter herzustellen, die direkt in die Tonne wandern. Darin sind wir Meister. Man kann es kaum besser machen.

Was begegnet uns noch bei diesen großen Vorhaben? Kennt den jemand? Der “Point of Diminishing Returns” ist ein faszinierendes Konzept, weil es so universell ist. Wir sehen es in der Softwareentwicklung, im Alltag - überall. Die Kurve sieht grundsätzlich so aus: Man forscht an etwas, entwickelt etwas und macht zunächst viele Fortschritte in kurzer Zeit. Aber am Ende flacht die Kurve ab. Ob bei der Entwicklung einer Technologie oder bei großen Vorhaben - dieses Muster sieht man oft. Der Point of Diminishing Returns liegt meist da, wo man sehr viel investieren muss, aber kaum noch Fortschritte erzielt.

Einer unserer Points of Diminishing Returns ist zum Beispiel die Weiterentwicklung des Verbrennungsmotors. Das Ding ist tot, das wissen alle, die Autoindustrie am besten. Aber wie viele Ressourcen haben wir in den letzten Jahrzehnten reingesteckt, um diese Technologie noch minimal zu verbessern? Es gibt in Deutschland eigene Studiengänge für Maschinenbau und Motorenbau - irrsinnig, was wir da als einzelnes Land investieren, nur damit ein Motor vielleicht 0,1 Liter weniger Sprit verbraucht. Leider waren sogar Software-Tricks nötig, weil wir das Ding eigentlich gar nicht mehr so weit bekommen, wie wir es bräuchten, um Gesetze zu erfüllen.

Jetzt wissen wir ungefähr, wo wir als Menschheit stehen. Dann können wir eigentlich loslegen, oder? Wir wollen interstellar reisen. Wenn wir ehrlich sind - darum geht es auch in dem Buch - müssen wir von allem Gelernten zurücktreten, vor allem von uns selbst, und schauen: Was brauchen wir dafür? Eine Prämisse in dem Buch ist, dass wir dafür Software brauchen.

Wo stehen wir denn mit Software? Es gibt da ein paar kluge Leute - Bill Gates hat zwar auch schon viel Unsinn erzählt, wie er selbst zugibt, aber das fand ich eindrücklich: Er brennt seit jeher für Software, sie hat ihn reich gemacht mit Microsoft und seiner Stiftung, mit der er viel Gutes tut. Aber er sagt auch: Software ist immer noch ziemlich dumm. Es ist immer noch so wie damals, als er DOS und Windows mit seinem Kollegen entwickelt und Microsoft gegründet hat. In vieler Hinsicht ist Software immer noch sehr, sehr beschränkt.

Wir brauchen aber Software, um solche großen Vorhaben wie Reisen zu anderen Sternensystemen zu bewältigen.

Weiß jemand, was das hier ist? Keine Sorge, ich will euch nicht mit UFO-Videos langweilen - aber ja, ich zeige euch UFO-Videos. Diese hat das Pentagon erst letztes Jahr freigegeben. Es gab diverse Sichtungen - sie heißen übrigens nicht mehr UFOs, ich habe den neuen Terminus vergessen. Das war eine Sichtung der US Navy. Es gibt fünf Videos davon, man findet sie auch auf YouTube, alle seriösen Medien haben darüber berichtet. Das war hier der Guardian.

Was man da sieht - man hört es auch im Ton - sah aus wie eine Art Kreisel. Die Navy-Piloten haben das gefilmt. Es war zunächst schwierig, das Objekt im Tracking-Sensor ihrer Kameras zu erfassen, weil es sich mit einer Geschwindigkeit bewegte, die nach den Gesetzen der Gravitation eigentlich unmöglich ist. Dann vollführte es Manöver - das sieht man am Ende - wo es plötzlich zehnmal so schnell wie eine Gewehrkugel fliegt und dann abrupt stehenbleibt und sich dreht. Das sind alles Dinge, die eigentlich nicht möglich sind - wurden aber gefilmt und waren lange unter Verschluss. Es gab eine Freigabe, auch Einordnungen vom Pentagon und anderen Behörden. Man kann sich da reinlesen, aber letztlich weiß niemand, was es ist. Ganz am Anfang heißt es ja relativ oft, die Dinger seien chinesische Wetterballonn - das passt hier nicht so ganz. Man weiß einfach nicht, was es ist.

In dem Buch geht es darum: Die einzige Möglichkeit, in ein anderes Sternensystem zu kommen, ist, dass man es nicht selbst tut. Wir können es per Definition nicht selbst tun. In der Science Fiction gibt es viele Lösungskonzepte dafür. Ihr kennt alle den Kryoschlaf - aber so viel spricht technisch dagegen. Es gibt Generationenschiffe, die tausende Jahre zum Ziel fliegen. Da leben dann Generationen von Familien, alles muss erhalten bleiben. Aber auch so ein Schiff verrottet ja. Menschen verrotten auch, wenn man sie lange einschließt - oder eben nicht. Das ist unglaublich kompliziert.

Deswegen ist die Lösung - und das ist die Hypothese von Avi Loeb: Wenn wir das hinkriegen wollen, dürfen wir es nicht selbst machen. Was haben wir denn für Technologien, um etwas nicht selbst zu tun, aber sehr viel Entscheidung, Autonomie und Wissen zu konzentrieren? Das ist tatsächlich die KI. Was in den letzten zwei Jahren passiert ist, und auch schon davor, war ein völlig normaler industrieller Skaleneffekt, gepaart mit dem neu erfundenen Attention-Mechanismus und der Transformer-Architektur. Wir haben eine eigentlich sehr alte Technologie - neuronale Netze sind nichts Neues - durch Skalierung im industriellen Maßstab, durch gigantische Investments - ihr wisst alle, auf welchen Rechnerbergen die großen Large Language Models trainiert werden - so weit gebracht, dass wir heute Wahnsinnssachen damit machen können. Mit allen Nebenwirkungen, die das so hat.

Aber zurück zum Flughafen. Wir sind die IT, was sagen wir? “Das ist doch nur ein statistischer Papagei”, “Generative KI ist doch nur Next Token Prediction”. Ich könnte die Argumente noch fortführen, ist aber müßig. Und da habe ich mich wieder erwischt - das habe nicht ich gesagt, ich habe es aber gehört. Das hat mich so an den Nadeldrucker am Flughafen erinnert, an meine Aussagen dort. Ich sitze hier als Digitalisierer und ordne das erstmal ein. Was ich sage, stimmt wahrscheinlich, weil ich bin Technologe, ich bin ITler, ich bin Software Engineer.

Wir digitalisieren ja die Gesellschaft, wir sagen der Gesellschaft, welche Prozesse sie digitalisieren muss und wie - nur dann geht es weiter. Wir ordnen schon immer die Sachen ein: Entwicklung für Leute, Kunden, Behörden, Firmen. In dieser Rolle waren wir lange sehr gut. Und jetzt sitzen wir im Zentrum des Sturms, der in den letzten zwei Jahren passiert ist. Wir wissen alle nicht, was nächste Woche released wird, das weiß niemand - und wir sagen: “Ach komm, das ist doch nur Statistik.” Ja, natürlich ist es Statistik, aber wir setzen einen Punkt dahinter.

Das hat mich getriggert, deswegen bin ich in dieses Rabbit Hole abgestiegen und habe mich gefragt: Warum sagen wir das denn? Was wollen wir mit solchen Aussagen bewirken? Ich bin auf Recherche gegangen: Was sagen denn die Leute zu dem, was in den letzten zwei Jahren passiert ist, die neuronale Netze schon lange erforschen?

Da ist Professor Sam Bowman von der NYU (heute: Anthropic), der sagt: Es gibt immer mehr Indizien, also substanzielle Beweise, dass Large Language Models interne Repräsentationen der Welt bis zu einem gewissen Grad entwickeln und dass diese Repräsentationen der realen Welt ihnen erlauben, zu einem gewissen Grad “Reasoning” zu betreiben. Niemand versteht aber gerade, warum. Weil die Dinger sind gigantische schwarze Löcher - wieder die Analogie zum All. Wir können da nicht reingucken.

Was Bowman herausgefunden hat: Mit IT-Skills kommen wir denen nicht bei, um sie zu erforschen. Wir kommen ihnen nur mit Geisteswissenschaften näher und vor allem biotechnologischen Ansätzen. Er ist Sprachwissenschaftler, die kommen da rein, aber es ist ein irrsinniger Aufwand. Da stehen wir ganz am Anfang. Wir sind quasi in der Steinzeit der KI, haben aber gerade einen explosiven Sprung hinter uns.

Was sagt er noch? Diese neuronalen Netze können wir sehr klein haben, Machine Learning und so weiter, und bei den Large Language Models sind sie je nach Parametergröße gigantisch. Ich habe gestern hier auf meinem Mac ein 70-Milliarden-Parameter-Modell in den Speicher geladen und habe die Tokens herauströpfeln sehen. Und 70 Milliarden Parameter ist ja mittelgroß, aber wirklich groß ist das noch nicht.

Er sagt, in diesen neuronalen Netzen - die sind nichts Neues - hat man durch schiere Größe Effekte und Fähigkeiten erreicht, die vorher nicht möglich waren. Man hat eigentlich nichts anderes gemacht. Klar, es gab noch die Transformer-Architektur und den Attention-Mechanismus.

Und er sagt, es gibt so viele Verbindungen in diesen neuronalen Netzen, die man sich als Neurowissenschaftler angucken sollte. Dann kann man versuchen zu verstehen, warum sie Dinge können, die ganz offenkundig nicht aus den Trainingsdaten stammen. Das wird erforscht.

Und da habe ich mich gefragt, wieder zurück zum Flughafen und den Nadeldruckern: Wir sind doch die IT. Ich habe mich und viele, die ich kenne, immer so verstanden: Wir sind progressiv, weil wir die Leute in die Moderne bringen. Wer mal wieder leiden will - heute Abend im Hotel, ARD Mediathek, einfach mal “BAföG-Amt” eintippen. Ich hoffe, es ist niemand vom BAföG-Amt hier, ich will auch niemanden dissen, bitte nicht falsch verstehen. Aber es zeigt uns eindrücklich, was wir als Gesellschaft immer noch für Prozesse haben. Da wird ausgedruckt, abgeheftet, wegsortiert, ausgedruckt, eingescannt, Ausdrucke eingescannt. Es ist irre, diese Doku. Man ist ja einiges gewohnt, aber die Doku hat das noch mal wirklich deutlich gemacht.

Trotzdem frage ich mich: Jetzt stehen wir quasi im Auge des Sturms. So ein Durchbruch passiert nicht alle fünf Jahre, auch nicht alle zehn Jahre. Einige sagen, das ist ein technologischer Durchbruch, den man nur einmal in der Generation erlebt. Das heißt, wir, die hier sitzen, erleben das jetzt einmal, und dann vielleicht unsere Kinder noch mal.

Jetzt frage ich mich: Warum sind ausgerechnet wir, die Speerspitze der Digitalisierung, auf einmal so defensiv und sagen “Ja komm, das ist nur Next Token Prediction”, “das ist ein glorifiziertes Autocomplete”, “das ist ein statistischer Papagei”? Da denke ich mir: Ja, so kann man die Technologie natürlich auch framen. Man hat damit nicht völlig unrecht, aber man verkennt, was damit möglich ist und was gerade passiert. Ich will aber auch nicht alles glorifizieren, nicht hier stehen und sagen: “Das ist der heilige Gral, wir haben ihn endlich gefunden.”

Es gibt smarte Leute, zum Beispiel von Apple - die Studie GSM-Symbolic ist noch gar nicht so alt, ein paar Wochen. Die forschen auch. Unternehmen werfen jetzt Wahnsinns-Investments rein, auch Apple, auch wenn sie etwas spät dran sind. Die haben Top-Leute und forschen daran: Können diese Systeme wirklich räsonieren? Sie kamen zum Schluss: Nach mathematischem Verständnis können sie es nicht. Okay, also widerlegt: LLMs können formal-definitionsmäßig kein Reasoning machen.

Jetzt könnten wir als ITler sagen: “Ja, hab ich doch gesagt, die können nicht nachdenken, die können kein Reasoning machen.” Gestern ist OpenAI’s Reasoning-Modell o1 erschienen, inkl. o1 Pro - das sind Reasoning-Modelle, das sind andere Skalierungsansätze. Wenn wir uns immer wieder hinstellen und sagen “Ja, aber lass uns erstmal gucken, kann dieses Ding Reasoning nach Formaldefinition?” - wir haben geforscht, geforscht, geforscht, ein Paper beweist, dass es das nicht kann. Was aber passiert, ist, dass Menschen es erfolgreich für Reasoning einsetzen.

Ich finde die Menschenanalogie bei dieser Technologie immer sehr interessant. Ich selbst kann nicht behaupten, ich könnte formal-definitiv Reasoning - kann ich nicht. Ich bin eine Katastrophe in Mathe. Ich setze mich auch nicht hin und mache alles formal-definitiv korrekt. Die Frage ist: Wer von uns tut das? Und wir können ja trotzdem viel bewegen als Menschheit, auch wenn wir in der Mehrheit wahrscheinlich nicht nach Formaldefinition Reasoning können.

Deswegen habe ich ChatGPT gefragt, wie man das nennt, wenn wir als Technologen so eine Aussage wie “Das ist doch nur ein statistischer Papagei” treffen, um eine Technologie jemandem zu erklären, der nicht aus der Technologie kommt. ChatGPT hat relativ schnell gesagt: Das ist eine ganz bekannte Form von Gatekeeping. Jetzt frage ich mich: Sind wir jetzt auf einmal Gatekeeper? Wir sind doch die Progressiven. Wir zeigen doch allen, wie man eine Gesellschaft, wie man Organisationen digitalisiert. Warum sind wir jetzt auf einmal die Stillen? Oder warum sind wir noch nicht still, sondern sogar voreilig im Framen?

Diesem Mann solltet ihr folgen: Ethan Mollick. Der hat gar nichts mit KI-Entwicklung oder Informatik zu tun, ist eigentlich Wirtschaftsprofessor an der Wharton School. Er hat aber relativ schnell erkannt, was in den letzten zwei Jahren passiert, hat sofort seine Curricula umgeschmissen, baut alles neu auf. Er hat gesagt: Das Ding ist jetzt in der Welt. Wer bin ich, meinen Studenten zu sagen “Benutzt das nicht” oder “Lernt erstmal zu Fuß eure Business- und BWL-Skills, dann dürft ihr vom goldenen Trunk kosten”?

Es gibt ja viele solcher Gatekeeping-Mechanismen. Wir wissen aber alle: Was verboten ist, wird sofort benutzt. Er schaut sich relativ viel an und forscht aus der Sicht eines Menschen, der eigentlich kein Technologe ist. Er ist natürlich nah an der Technologie, aber ich finde es immer hilfreich mir anzugucken, was andere Leute damit machen, die nicht aus meiner Branche kommen. Oft sitzt man doch zu lange in seinem Silo.

Er sagt: Hier passiert gerade etwas, was man nicht oft sieht. Die üblichen Wege, Technologie für andere zu erklären und zu erschließen - was unsere Aufgabe ist - funktionieren auf einmal nicht mehr. Nichts funktioniert hier mehr, es steht alles Kopf.

Man kann das von verschiedenen Enden des Spektrums beleuchten: Blue Collar Work, White Collar Work. Wir machen ja White Collar Work - auch wenn wir meistens keine weißen Hemden tragen, aber wir sind Wissensarbeiter in dem Sinne. Die Blue Collars haben schon diverse industrielle Revolutionen und Iterationen hinter sich, die sind Disruption gewohnt. Es wird auch nicht alle zehn Jahre eine Dampfmaschine erfunden, aber die können damit umgehen. Die sind organisiert, haben Gewerkschaften. Die Industriearbeiter sind nicht geschockt, wenn jemand etwas Neues erfindet und ihre Arbeit plötzlich nicht mehr dasselbe wert ist wie vorher.

Wir sind das, glaube ich, gar nicht so gewohnt und wir sehen gerade mehr oder weniger bewusst nicht, dass es uns an den Kragen geht. Man kann das sehr radikal formulieren - ich sehe das persönlich nicht so.

Erik Meijer - kennt ihr vielleicht, bekannter niederländischer Informatiker, tritt auf allen möglichen großen Konferenzen auf - hat jetzt einen Talk gegeben. Er ist ja relativ harsch und ein sehr unterhaltsamer Typ. Er hat gesagt: “Ich habe für mich festgestellt, ich bin die letzte Generation von Programmierern. Ich hatte nie Bock auf Commit Messages, ich hatte keinen Bock auf Stand-ups, ich hatte keinen Bock auf Scrum-Rituale. Ich wollte doch einfach immer nur coden.” Und er meinte ganz ehrlich: “Ich wette darauf, ich bin der letzte meiner Generation, die diesen Skill fulltime als Arbeit leben wird. Also lasst uns doch einfach Spaß haben dabei.”

Worauf ich hinaus will: Es ist ganz paradox, was hier gerade passiert. Meiner Wahrnehmung nach waren wir immer enorm schnell darin, Technologien zu adaptieren - mehr oder weniger auf der Skala schnell. Klar, es gibt große Organisationen, kleine Organisationen, alles. Aber im großen Ganzen waren wir die, deren Job es ist, Technologie zu erkennen, zu verstehen, Anwendungszwecke zu erkennen und damit Wert zu schaffen. Jetzt sind wir aber auf einmal die Stillen oder die, die sagen: “Ja, das ist eben nur ein statistischer Papagei” oder “Copilot ist irgendwie cool, so eine Autocompletion zu haben. Manchmal ist das schon ganz praktisch, aber irgendwie weiß ich nicht…”

Ethan Mollick sagt, man soll alles damit probieren - wenn es nicht gut funktioniert, in zwei Wochen nochmal angucken. Die Entwicklungsgeschwindigkeit ist so schnell gerade, vieles hängt auch an diesem verdammten Kontextfenster. Aber das ist ein anderer Talk.

Ich glaube, wir haben hier ein Technologie-Adaptions-Paradox. Ich wollte immer schon mal ein Paradox erfinden - Wikipedia-Eintrag will ich, bitte! Aber ich glaube, wir haben hier den Fall. Das ist total paradox, weil wir Technologen sind, aber gerade nicht zur Adoption beitragen, weil wir auf einmal nicht mehr in unseren Sphären erklären können. Wir wissen genauso wenig wie unsere Manager, wie unsere Bandarbeiter, wie andere Wissensarbeiter. Wir sind nicht mehr die Vorhut, die das sondiert, erklärt oder eben gar nicht erklärt, sondern einfach anwendet.

Wenn wir uns angucken, was unser Handwerk ist - wir sind ja White Collars, aber am Ende machen wir auch Handwerk. Erik Meijer: “Ich habe Bock zu programmieren, ich wollte nie was anderes in diesem Handwerk.” In den Software Craft ist ganz schön viel Bullshit eingezogen in den letzten Jahrzehnten. Wie viele API-Specs wollen wir denn noch erfinden? Wie viele Methoden, Syntaxen, die man in Markdown einbetten kann, um Diagramme für Softwarearchitektur zu erstellen, wollen wir denn noch erfinden? Wir lösen halt alles zehnmal, wir werden iterativ besser, aber Point of Diminishing Returns und so. Tests schreiben - wer schreibt denn gerne Tests? Ich will das nicht. (Ein paar Hände gehen hoch) – Ja, fair, total fair. Ich nicht.

Ich programmiere auch gerne, aber ich bin ja Software Engineer, auch wenn ich nicht mehr so viel programmiere wie früher. Und ich will nichts abwerten - das ist nur meine Bestandsaufnahme.

Wenn wir die großen Bretter bohren wollen - interstellare Raumfahrt nicht wörtlich nehmen - aber wenn wir uns mal wieder die großen Herausforderungen vornehmen wollen, statt ständig Quatsch neu zu erfinden, der schon zehnmal gelöst wurde… Da müssen wir doch mal gucken: Was machen wir eigentlich den ganzen Tag? Governance-Regeln schreiben. Da ist er wieder: der Point.

Wo stehen wir denn da? Ich frage mich: Programmieren wir uns eigentlich zu Tode, wenn wir denn noch die Ehre haben zu programmieren? Aber wir machen und machen und machen. Vielleicht kennt ihr das Gefühl, ich hatte es schon öfter: Macht freitags den Rechner zu und denkt “Was habe ich die Woche eigentlich gemacht?” Ganz schön viel programmiert, viele Stand-ups gehabt, viele Meetings, aber was habe ich produziert? Das verschwindet manchmal in der Schwemme der Dinge, die wir tun. Wir tun so viele Dinge - und Vorsicht bei dem Begriff.

Es gibt dazu ein Buch, es heißt “Bullshit Jobs” und ein Job ist ja eigentlich nur eine Bündelung von Tasks. Die Tasks können sich ändern. Am Job hängt meistens ein Mensch. Mensch kriegt ein Paket von Aufgaben, da fließen mal welche raus, da gehen welche rein. Work ist eine Kapselung von Aufgaben für einen Job. Wie viel von dem Sch… - Entschuldigung - haben wir schon entwickelt? Suchen-und-Ersetzen-Dialoge…

Das ist also immer noch hilfreich im Alltag, aber es gibt auch viele Neuerfindungen davon. Die Frage ist: Wie lange wollen wir uns damit noch aufhalten? Worauf müssen wir uns eigentlich konzentrieren, wenn wir die dicken Bretter bohren wollen? Das dickste Brett von allen: interstellare Raumfahrt.

Was brauchen wir dafür wirklich? Lasst uns von der Tastatur zurücktreten. Von Avi Loeb haben wir gelernt: Wir fliegen nicht selbst dort hoch - ein autonomes Objekt fliegt hoch und das muss gesteuert werden. Es muss Messwerte erfassen, aus diesen Messwerten Erkenntnisse gewinnen. Verschiedene Maschinen müssen miteinander kommunizieren. Aber wie viel Maschine-zu-Maschine-Kommunikation haben wir schon erfunden? Wie viele JSON-API-Specs wollen wir noch entwickeln, damit APIs miteinander oder mit Clients sprechen können? Wofür braucht es noch weitere Formate?

Was ihr hier seht, ist der Figure-Roboter in der BMW-Testfabrik in Spartanburg. Ein kalifornisches Startup. Die Robotik explodiert gerade, auch wenn man das in der breiten Wahrnehmung kaum mitbekommt. Was dort gerade passiert, ist wirklich krass. Was wir als Menschen längst gelöst haben - Point of Diminishing Returns und so - ist die Mechanik eines Roboters. Die gibt es schon ewig: Aktuatoren, diese kleinen Motoren, die Finger biegen und drehen. Da gibt es in Deutschland viele kleine Hersteller, die Milliardenumsätze damit machen. Das ist längst gelöst.

Was nie funktioniert hat, ist, dass die Dinger Aufgaben übernehmen, wo echtes Reasoning nötig ist. “Schmeiße ich jetzt das kleine Kind in das heiße Fett am Herd oder drehe ich lieber die Herdplatte runter?” Was ergibt im Interesse des Menschen am meisten Sinn? Oder im Sinne des Gemeinwohls: Was muss ich in einer Fabrik tun, um dieses Auto zusammenzusetzen?

Figure - das ist jetzt nur ein Beispielhersteller - mit einer amerikanischen Produktentwicklungsmentalität an die Sache herangegangen. Sie haben keine revolutionären Robotergelenke oder Motoren erfunden, sondern einen guten humanoiden Roboter gebaut, der auf einmal sehen und hören kann. Das ging bisher nicht - jetzt geht es.

Roboter bauen wir ja schon immer. Diese ASIMO-Demos, wo das Ding die Treppe runterfällt, kennt ihr alle. Ihr kennt auch die Boston-Dynamics-Tiere. Das wirkt schon sehr gruselig, diese militaristischen Roboterhunde, die Treppen hoch und runter rennen. Will ich mir nicht auf dem Battlefield vorstellen - wird aber passieren. Ein negativer Effekt der Weiterentwicklung. Wobei “negativ” - am Ende muss man das auch differenziert betrachten. Wir leben in Zeiten, wo man sich offenbar doch wieder verteidigen können muss.

Aber zurück zu den Fabriken. BMW erprobt das mit Figure. Ich finde es bezeichnend, dass das ein US-Hersteller ist und kein deutscher, wo die Deutschen doch eigentlich immer super darin waren, Roboter zu bauen. Die Deutschen stehen gerade da und schauen zu. Wenn es um die zentrale Komponente geht - wie mache ich einen Roboter so, dass er sich durch eine Fabrik bewegen kann, wo auch Menschen rumlaufen, niemand anrempelt und seinen Job macht, aber alles im Blick hat und ein grundsätzliches Weltverständnis besitzt - das geht jetzt. Das kriegen aber scheinbar die Amerikaner für deutsche Unternehmen gelöst, obwohl wir die Kompetenz eigentlich haben müssten.

Was wir da sehen, ist eigentlich eine Neukonzeption der Fabrik. Eine Fabrik ist ja eigentlich - Henry Ford und so weiter - nichts weiter als eine Verlängerung des menschlichen Körpers. Das Förderband, die ganze Produktionshalle ist als Verlängerung des menschlichen Körpers gedacht. Die Bandhöhe eines Förderbands ist so, dass ich bequem daran arbeiten kann, niemand sich den Rücken krumm biegen muss. Die Armbewegungen sind so ausgelegt, dass sie möglichst kurz sind und ich auf Strecke angenehm mit Menschen produzieren kann.

Aber wenn ich jetzt Roboter habe - wie sehen dann die Fabriken aus? Also Roboter, die sich wie Menschen verhalten können, aber nicht müssen? Die werden wir wahrscheinlich nächstes Jahr schon in Produktionshallen neben Menschen sehen. Bei Amazon genauso, in Warenhäusern. Die Frage ist aber: Was kommt danach? Ich glaube, wir werden nicht mehr endlos Teile an Fließbändern zusammensetzen. Ist ja jetzt schon nicht mehr so - ein organischer Verlauf der Dinge.

Was wir da warten, ist sehr viele menschliche Arbeit in Produktionshallen. Der Roboter als Instandhalter ist in dem Sinne nichts Neues, aber jetzt haben wir Humanoide, die sich mit anderen Maschinen und Menschen verständigen können. Die bewegen sich ein bisschen anders als wir, aber das ist auch Teil der UX. Diese hühnerartigen Bewegungen der Roboter sind übrigens Absicht, um keine Angst zu machen. Wenn zwischen uns in solchen Produktionshallen ultraschnelle, smooth Bewegungen wie bei Boston Dynamics wären - das wäre schon ein bisschen scary. Für den Anfang. Wir werden uns auch daran gewöhnen.

Was brauchen wir noch für andere Sternensysteme? Wer weiß denn, was das hier ist? Die Voyager Deep Space Mission kennt ihr bestimmt. Da hat die NASA vor Jahrzehnten eine Deep Space Sonde losgeschickt. Da ist nicht viel drauf, sie wiegt auch nicht viel, aber es ist eine goldene Metallplatte dabei, die ähnlich funktioniert wie eine Vinylplatte, eine Schallplatte. Darauf sind menschliche Stimmen zu hören, Tier- und Naturgeräusche - alles, was hypothetisch eine andere Zivilisation über die Menschheit lernen könnte. Da ist sogar ein David Bowie Song drauf, kulturelle Errungenschaften der Menschheit, der Natur und der Tierwelt.

Wir brauchen heute nichts mehr in goldene Schallplatten zu kratzen. Denn wer weiß denn, wie die das abspielen wollen, wenn es jemand findet? Klar, wenn das jemand findet, ist die Zivilisation wahrscheinlich auch sehr weit entwickelt. Aber vielleicht können die sich nicht zurückerinnern, dass man eine Nadel als Tonabnehmer braucht, die man in eine Rille legt. Und was die dann überhaupt hören können - das weiß man ja auch nicht. Ist ja ein atmosphärisch bedingtes Ding.

Was wir jetzt haben, ist zum ersten Mal ein Mechanismus zur Abstraktion von Wissen. Sprachunabhängig. Wie viele Papyrusrollen und Bücher haben wir schon vollgeschrieben? Ist aber alles in Sprachen. Mathematik ist auch so eine Abstraktion von Wissen. Aber jetzt haben wir einen Mechanismus, wo unser ganzes menschliches Wissen reinkondensiert werden kann. Und nicht nur als ZIP-Paket, sondern mit Reasoning, in Anführungszeichen. Sprachunabhängig. Wir wissen, 32 Sprachen und so weiter, aber am Ende sind es Tokens, keine Sprachen. Sprachen sind ein netter Nebeneffekt. Das wäre schon ganz praktisch, so etwas in einer Sonde zu haben. Besser als die goldene Schallplatte.

Stichwort: die ganze Energie des Heimatplaneten nutzen. Kernfusion - mein Gott - zu jeder Wahl wird wieder neu darüber geredet. “Ja, wir investieren in Kernfusion und bis das gelöst ist, lassen wir alle Kohlemeiler laufen.” Kernfusion ist wahrscheinlich lösbar, aber es braucht gigantische Investments und Geduld. Man muss, glaube ich, viele verschiedene Dinge tun, nicht nur alles in Kernfusion stecken.

Ihr kennt das Problem wahrscheinlich: die Funktionsweise der Sonne im Kleinen, das ist Kernfusion. Ich muss ein sogenanntes Plasma entfachen, das irrsinnig heiß wird, Millionen von Grad, in so einem Donut-artigen Gebilde, und ich muss das stabil in der Mitte halten – sonst erlischt es. Wenn ich das schaffe, habe ich im Prinzip die Energie der Sonne im Kleinen auf der Erde. Dann haben wir de facto kein Energieproblem mehr. Dann kann man wieder Innovationen machen. Das ist so ein dickes Brett, das man jetzt mal bohren könnte. Man sieht ja auch Fortschritte, Gott sei Dank setzen sich Leute da hin. In einem Experiment haben sie es geschafft, dieses Ding deutlich stabiler zu halten - durch KI.

Ethan Mollick sagt in seinem Buch “Co-Intelligence”, für die von uns, die Technologie schon lange beobachten und erklären: Das, was zuletzt passiert ist, nämlich generative KI und diese gigantischen neuronalen Netze - wir haben auf einmal eine neue General Purpose Technology.

Das sehen wir wahrscheinlich nur einmal in der Generation. Wann waren die letzten GPTs - General Purpose Technologies? Weiß das noch jemand? Internet ist die letzte gewesen. Was kam davor? Dampfmaschine, das war’s. Und auf dieser Skala müssen wir das eigentlich betrachten.

Bei der Dampfmaschine hat es fast 120 Jahre gebraucht, bis Gesellschaften sich die Produktivitätssteigerungen und Innovationen, die zweitausendein Wirkeffekte, zu Nutze gemacht haben. Beim Internet ging es sehr viel schneller, auch wenn es bis heute keine Studie gibt, die belegen kann, dass das Internet zu Produktivitätssteigerungen beiträgt. Aber ich glaube, das wissen wir alle. Es ist unglaublich schwer zu belegen bei diesen General Purpose Technologies. Beim Internet sagt man 25 Jahre.

Und jetzt sitzen wir schon seit zwei Jahren im Auge des Sturms und es passiert so viel - das sind gerade mal zwei Jahre rum. Als Gesellschaften werden wir schneller in der Adaption und Dinge passieren einfach viel, viel schneller als die 120 Jahre mit der Dampfmaschine. Aber so etwas haben wir hier halt vor uns.

Deswegen noch mal den Bogen zurück zu uns: Warum sitzen wir denn da und sagen Sachen wie “Das ist ja doch nur ein statistischer Papagei”? Da frage ich mich manchmal: Lieben wir denn diese Bullshit Work? Also manchmal habe ich ja auch Tage, wo ich sage, ich will jetzt heute mal was Berechenbares machen.

Klar, gestern Abend war lang, da mache ich heute mal berechenbare Arbeit. Aber ich glaube, ganz tief in uns drin lieben wir diese Bullshit Work. Wir haben das schon ganz gern. Und schlimmer noch: Wir bilden das ja sogar in unseren Organisationen ab. Ganze Firmen, ganze Abteilungen beschäftigen sich nur mit dieser Bullshit Work.

Nicht vergessen: Bullshit Work ist eine Ansammlung von Tasks zu verwalten, aber an die eigentlichen Tasks geht keiner ran. Die machen wir, bis wir umfallen, oder wir automatisieren die kleinen davon zuerst, weil das die einfachen sind. Dann können wir schneller Erfolge zeigen. Aber eigentlich haben wir jetzt etwas, womit wir dicke Bretter bohren können.

Und was tun wir? Wir machen weiter das Berechenbare. Ich würde sogar sagen, wir müssen das Zeitalter der Algorithmik eigentlich verlassen, um die Riesenbretter jetzt zu bohren. Niemand muss jetzt seine Programmierskills wegwerfen - ein bisschen polemisch, aber ich glaube, das Zeitalter der Algorithmik faded gerade aus. Wir müssen jetzt einfach Verantwortung abgeben, weil wir nur mit sehr hohem, wenn nicht unendlichem Aufwand Dinge tun können, die eben sehr schwere Probleme sind.

Ich sage oft, die KI, die wir jetzt haben, ist vielleicht das Ende von “zu teuer”. Wenn wir Prozesse automatisieren, Features bauen - ihr kennt das alle im Backlog: “Geht in dem Sprint nicht. Sorry, ist auch in zwei Sprints nicht möglich. Oh ne, das ist so ein dickes Brett, das müssen wir erstmal zerschneiden.” Dann zerschneiden wir das dicke Brett in ganz viele Späne, setzen fünf Späne um in 365 Tagen und haben am Ende vergessen, wie das Brett aussah.

Aber das können wir nicht mit endlicher Arbeit, nicht mit unseren Hard Skills. Wenn wir uns jetzt hinstellen und sagen: “Ja okay, aber die KI-Modelle haben nur eine Accuracy von 85% und der Rest sind Halluzinationen.” Ja, aber ist das bei uns anders? Wer von uns hat denn eine Accuracy von 100% in seiner oder ihrer Arbeit? Das ist doch abstrus. Und das jetzt auf dem Grad zu messen…

Es gibt Techniken, Halluzinationen zu reduzieren, aber es ist ein Feature. Es ist kein Bug dieser Technologie, das ist ein Feature. Diese Technologie würde nicht funktionieren, gäbe es das nicht. Genau wie wir als Menschen nicht funktionieren würden, würden wir nicht auch ab und zu mal halluzinieren oder Quatsch erzählen oder verquer denken oder in irgendwelche abstrusen Konzepte reinbeißen und dran bleiben.

Ganz viele Gespräche, die ich gerade führe, sind: “Das ist ja schon beeindruckend, aber wir brauchen 100% Accuracy.” Da sage ich: “Ja, aber ihr könnt den Prozess doch nicht mit endlicher Arbeit lösen. Wie viele Abteilungen wollt ihr denn noch aus dem Boden stampfen?” Und ihr kapselt diese Work in Bullshit Jobs. Das sind ja auch keine Jobs, die Leute auf Dauer erfüllen. Niemand ist happy. Es gibt Studien dazu, das sind “Burnout-Abteilungen”, nennt man die manchmal, die diese Ochsenarbeit - gar nicht abwertend gemeint - machen müssen.

Voranmeldung für einen Hauskredit, Vorprüfung Stufe eins, first wave, second wave - das konnten wir schon vor zwei Jahren automatisieren, das können wir heute automatisieren. Das ist aber nur Automatisierung. Und das werden wir jetzt viel machen, weil das für uns greifbare Probleme sind. Und wir werden auch sehr viel über Workshift reden. Was machen wir denn mit den Jobs, die bisher diese Work gemacht haben? Aber Work ist ja nur eine Kapselung von Aufgaben.

Es wäre doch total toll, wenn man den Leuten Aufgaben geben könnte, die ein bisschen erfüllender sind. Und das hat die Zeit ja auch immer gezeigt, dass das passiert. Aber ich will jetzt auch nicht den Propheten machen. Es kann sehr gut sein, weil das so eine Querschnittstechnologie ist, weil die so mächtig ist, dass hier nicht einfach durch die Bank alles 100% shiftet - weiß niemand, beschäftigen sich schlauere Leute als ich damit.

Deswegen: Wir müssen ins Zeitalter des Reasonings einsteigen. Wir müssen lernen, Verantwortung abzugeben. Wir müssen uns als Engineers im Gegenteil jetzt darauf fokussieren, wie wir unsere Engineering Skills anwenden, um Ergebnisse zu prüfen und in die richtige Richtung zu bringen.

Deswegen frage ich nochmal: Haben wir vielleicht Angst? Wie begreifen wir Veränderung? Manche wissen es vielleicht - “Oh shit!” Man hat ja gar nicht damit gerechnet, dass die programmieren können. Das war so ein Zufallsfund, und am Anfang war da auch noch sehr viel Quatsch. Aber mittlerweile können wir mittelgroße, lokale Modelle auf dem Rechner laufen lassen, die verdammt gut programmieren können. Wir müssen erstmal Patterns kennenlernen und erfinden, damit umzugehen. Da geht es nicht nur um Autocompletion von Syntax.

Der Grund, warum die das so gut können, ist, weil Code ja nur eine vereinfachte Repräsentation von Sprache ist. Sprache ist ja sehr viel komplexer, menschliche Sprache. Und deswegen können die Code besonders gut, weil die menschliche Sprache auch besonders gut können und Code halt noch sehr viel besser.

Es wird leider nicht schlechter. Deswegen sollten wir uns fragen: Haben wir vielleicht doch ein bisschen Angst? Klar, ich bin auch gelernter Programmierer, Software Engineer. Das ist ein Hard Skill Set, was ich habe, und ich bin mir sehr bewusst, dass es daran geht. Ob das eine Entwertung ist, kann ich noch nicht sagen, aber was in den letzten zwei Jahren passiert - schon. Zumindest macht es das billiger.

Dann bin ich wieder in so eine Reddit Rabbit Hole abgetaucht. Ich habe gesucht: “Wird KI Software Engineers ersetzen?” Da findet man wieder wahnsinnig schlaue Leute. Und dann dachte ich “Ja, der hat es endlich kapiert.”

Die erste Regel, die man hat, wenn man Software Engineer ist: “Man muss adaptiv bleiben”. Generell für alle Menschen eine gute Eigenschaft. Dinge verändern sich, wir müssen uns darauf einstellen. Das ist doch eigentlich, worum es geht.

Dann habe ich weitergelesen und am Ende gefunden: “It’s just another tool in your tool belt.” Da dachte ich: Irgendwie hast du das jetzt alles mit dem Allerwertesten wieder eingerissen, was du am Anfang aufgebaut hast. Klar, so kann man es begreifen. Man macht es sich aber sehr einfach. Es ist auch nicht abwertend gemeint, es ist menschlich. Man muss Dinge für sich einfacher machen, wenn sie zu groß sind.

Um mir in 8 Stunden eine endliche Zahl von Use Cases für eine Allzwecktechnologie auszudenken… Also mit der Abstraktion von Wissen, Kernfusion, Programmieren, Texte zusammenfassen - was liest man überall, was man mit generativer KI machen kann? “Texte zusammenfassen”, ja, kann man auch. Ist aber derartig faul, heute noch Artikel zu veröffentlichen und zu sagen “Ja, damit können Sie besonders gut Texte zusammenfassen. Und Übersetzung geht auch ganz gut.” Das ist einfach ein Tropfen Wasser in einem Meer von Use Cases.

Da wackeln gerade ganze Geschäftsmodelle. Belegdatenerkennung zum Beispiel: Es gibt Unternehmen am Markt, die machen Belegdatenerkennung, Mehrwertsteuer 7%, 19% mit Custom Machine Learning Modellen. Wir verpflichten uns vertraglich, unsere manuellen Menschenkorrekturen denen zurückzuliefern, damit die ihr Machine Learning Modell trainieren können.

Und da sind natürlich persönliche Daten drin. Was wir mit generativer KI jetzt hören, ist: “Ja okay, aber wir können das hausintern nicht nutzen, weil bei KI müssen wir besonders aufpassen mit dem Datenschutz.” Da denke ich wieder: Leute, KI-Cloud-Anbieter, OpenAI, besonders Anthropic - ihr habt mit euren ganzen SaaS-Dienstleistern noch nie so gute Bedingungen für die Handhabung eurer Daten bekommen wie mit denen.

Guckt euch das doch erstmal an. Man stellt sich die LLMs gerne als schwarzes Loch vor, aber bestimmte Daten, die ihr denen schickt, die bewahren die wie jeder Anbieter, mit dem ihr Verträge habt, für x Tage auf. Danach löschen die die. Ins Modell gehen Tokens, dann kommen andere Tokens raus. Da bleibt nichts im Modell. Keiner trainiert damit, keiner hat Interesse an eurem Datengefriemel. Da geht es um völlig andere Skalenmaßstäbe.

Niemand will eure Daten jetzt mehr, das ist übersprungen. Niemand interessiert sich für eure Unternehmensdaten für das Weitertrainieren der Modelle. Die sind so weit, die verkaufen euch Finetuning-Lösungen, damit ihr die Modelle mit euren Daten bei euch oder bei ihnen finetunen könnt, was auch eine Form von Training ist. Die interessieren sich aber nicht für eure Daten, die sind schon viel, viel weiter. Eure internen Daten sind ein Glas Wasser im Regen.

Und wenn dann - das sind auch Gatekeeping-Aussagen, nicht wahr? “Befassen wir uns dieses Jahr nicht mehr mit, ist wegen Datenschutz.” - “Besonders bei KI müssen wir aufpassen!” Das Gegenteil ist der Fall. Besonders bei KI könnt ihr sofort starten, man findet Dienstleister mit hervorragenden vertraglichen Bedingungen. Jeder Datenbank-Host ist komplexer aus DSGVO-Sicht als ein LLM.

Um einen Strich drunter zu machen: Lasst uns wieder groß denken. Ich zitiere Deichkind: “Denken Sie groß.”

Qualitätsziele helfen uns, Architekturentscheidungen fundierter zu treffen. Die genau richtige Qualität ist jedoch oft subjektiv und ändert sich über die Zeit hinweg. Dies macht das Arbeiten mit und an Qualitätszielen vor allem bei langlebigen Softwaresystemen spannend.

In diesem Vortrag stelle ich eine neue Sicht auf Softwarequalität vor, bei der wir Qualität im evolutionären Kontext betrachten. Als Basis verwende ich das ISO 25010 Qualitätsmodell sowie Wardley Mapping, um die passende Qualität nach Wichtigkeit und Evolutionsstufen zu finden.

Aufzeichnung des Vortrags

In der Anwendungsentwicklung müssen wir heute nicht mehr alles selbst erfinden, sondern wir nutzen Bibliotheken von Drittanbietern. Mit den Vorteilen dieser Bibliotheken geht jedoch auch die Verantwortung einher, sie regelmäßig zu aktualisieren, um potenzielle Sicherheitsrisiken zu minimieren. Die zeitnahe Durchführung dieser Updates, ohne das Überspringen von Releases, reduziert dabei Risiko und Aufwand. In diesem Vortrag wird deswegen Renovate vorgestellt, ein Open-Source-Bot für das automatisierte Updaten von Abhängigkeiten.

In einer Data-Mesh-Architektur werden Datenprodukte entwickelt und zwischen verschiedenen Teams ausgetauscht. Wir brauchen eine skalierbare Möglichkeit, uns auf die Qualität und Stabilität der Daten zu verlassen. Hier kommen Data Contracts ins Spiel. Der Datenanbieter definiert das Schema der bereitgestellten Daten und ihre Qualitätsattribute, aber auch Beispieldatensätze und die domänenspezifische Bedeutung der Attribute. Data Contracts legen außerdem die Nutzungsbedingungen für die Daten fest.

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 haben wir dann das James Webb Teleskop erfolgreich ins All geschossen – und aufgebaut – mit sage und schreibe 344 Single Points of Failure. 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?

Während wir unaufhörlich kleine, aber inkrementelle Fortschritte machen, sind die wirklich großen Herausforderungen, die uns als Unternehmen und Gesellschaften antreiben sollten, noch weitgehend unberührt. Unstrukturierte Daten türmen sich in unseren Systemen. Wir widmen uns weiter mit Inbrunst dem Kleinteiligen. Während wir gleichzeitig die großen Herausforderungen in den Hintergrund drängen. Unsere Zeit ist endlich. Haben wir aufgegeben?

Key Points

• Aktuelle Herausforderungen bei der Einführung von Technologien
• Wirkliche Herausforderungen erkennen und meistern statt dem Kleinteiligen widmen
• Gestaltung zukunftsfähiger IT-Strategien mit Fokus auf Künstliche Intelligenz

“Lose Kopplung und hohe Kohäsion” sind wichtige Designprinzipien für die Erstellung wartbarer und verständlicher Software. Während es bereits viele Vorträge und Workshops zum Thema Kopplung auf verschiedenen Konferenzen gab, wurde das Thema Kohäsion noch nicht so oft behandelt. In diesem Vortrag geht es um Kohäsion.

Wir werden zunächst die grundlegenden Prinzipien der Kohäsion im Softwaredesign erkunden und ihre Bedeutung für die Schaffung klarer, wartbarer und skalierbarer Systeme erläutern. In diesem Kurs werden Sie lernen, was Kohäsion ist und welche Arten von Kohäsion es gibt. Wir werden über Arten von Kohäsion im Softwaredesign wie funktionale, sequenzielle, zeitliche oder zufällige Kohäsion sprechen. Wir werden uns aber auch mit dem Begriff Kohäsion in anderen Disziplinen wie Chemie, Geologie, Sozialverhalten oder Bodenmechanik beschäftigen.

Viele große Unternehmen arbeiten immer noch mit zentralisierten architekturbezogenen Teams. Deren Aufgabe besteht häufig darin, anderen Teams architektonische Spezifikationen vorzugeben und dafür zu sorgen, dass diese Spezifikationen bei der Umsetzung eingehalten werden. Diese Teams werden oft als “Elfenbeinturm-Architektur”-Teams bezeichnet, die darauf abzielen, hochqualifizierte Architekt:innen zu bündeln. Diese Rolle ist auf dem Markt sicherlich nicht in Hülle und Fülle vorhanden. Sie passen jedoch nicht in eine agile Umgebung, in der wir den Teams die Möglichkeit geben wollen, ihre eigenen Entscheidungen zu treffen. Bestimmte Leitplanken sind dennoch notwendig, um sicherzustellen, dass das Gesamtkonstrukt funktioniert. Darüber hinaus können gut gewählte Leitplanken auch den Abstimmungsbedarf zwischen den Teams drastisch reduzieren. Wir müssen diese Teams in die Lage versetzen, den größten Teil der architektonischen Arbeit selbst zu erledigen, und gleichzeitig dafür sorgen, dass die einzelnen Teile zusammenpassen. An dieser Stelle kommen Team Topologies ins Spiel, eine von Matthew Skelton und Manuel Pais eingeführte Methode. Dort gibt es den Teamtyp des “Enabling Teams”, welches – knapp zusammengefasst – andere Teams mit Wissen und Methodik unterstützt.

Dieser Vortrag gibt Ihnen einen Überblick über diesen Wandel sowie eine praktische Anleitung, wie Sie ein zentralisiertes Architekturteam in ein Enabling Team umwandeln können, dessen Aufgabe es ist, die Architekturarbeit in anderen Teams zu verbessern. Sie werden lernen:

• Welche Stakeholder Sie in diesen Prozess einbeziehen sollten
• Warum das künftige Enabling-Team ebenfalls befähigt werden muss und wie man das macht
• Wo häufige Fallstricke auf dieser Reise liegen
• Warum diese Reise auf agile Weise mit kontinuierlichem Lernen und Retrospektiven durchgeführt werden muss

Dieser Vortrag wird auch viele Beispiele aus der Praxis enthalten, die eine solche Transformation begleiten.

Die Arbeit von Softwarearchitekten findet in klassisch aufgestellten Teams oft abseits der Entwicklungsarbeit statt - sowohl räumlich als auch zeitlich getrennt. Dass das auch anders geht, zeigt Joshua in seinem Vortrag. Er arbeiten seit mehr als 3 Jahren in einem Remote Mob, in dem das ganze Team bei Bedarf die Rolle des Architekten einnimmt. So wird die Arbeit an Domänen- und Lösungsarchitektur genauso vom ganzen Team gemeinsam durchgeführt, wie die Entwicklung und der Betrieb der Lösungen. In diesem Vortrag erfahrt ihr, wie ein Mob funktioniert und welche Veränderungen die synchrone Zusammenarbeit bei Architektur-Methoden mit sich bringt.

Data Mesh is a socio-technical approach to data management that enables teams to perform data analysis independently within their domain to make data-driven decisions. Data mesh promotes sharing data with other teams as data products and defined data contracts.

Data Mesh adopts the principles from Domain-driven Design, Team Topologies and Microservices to the data world. However, it has many organizational implications, such as ownership and federated governance.

In this talk, Simon and Jochen from INNOQ describe how a Data Mesh architecture can be implemented in practice, which organizational transformations will be necessary and which technologies are suitable in this context.

Agenda This talk is part of Softwareaarchitektur Hamburg Meetup

• 18:30 Open doors
• 19:00 Talks (ca. 60 min + Q&A)
• Afterwards: Networking

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.

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

Key takeaways

• You will learn about the importance of aligning teams with architecture and domains
• You will learn two methodologies for visualizing and talking about sociotechnical architectures: Team Topologies and Context Maps
• You will learn how to combine Team Topologies and Context Maps together

Team Topologies and Context Maps are two interesting approaches to visualize sociotechnical architectures. However, using each method on its own, you will not be able to capture a truly holistic view of the system as a whole, but you can use both in combination and this is what this talk is about. This talk will introduce a Systems Thinking perspective on those two approaches and explain how both can be leveraged in combination to get a deep dive on many interactions in a system of teams and software. Those interactions include: - team relationships - team dependencies - propagation of domain models - governance related communication - provisioning of APIs services. However, we will also look at the components of the system with Team Topologies being team centric and Context Maps being bounded context centric. I will finally explain how you can use both methods to visualize alignments between domains, bounded contexts and teams. This talk assumes that you have a basic understanding of strategic Domain-Driven Design (esp. Bounded Contexts and Context Maps) open_in_new

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.

Große Sprachmodelle (LLM) sind eine neue Technologie, die die Welt in kürzester Zeit erobert hat. KI-Chatbots wie ChatGPT haben KI durch die Verwendung natürlicher Sprache steuerbar und damit für die breite Öffentlichkeit zugänglich und äußerst nützlich gemacht.

Die meisten Menschen haben wahrscheinlich schon mit diesem oder einem anderen Chatbot experimentiert und ähnliche Erfahrungen gemacht: Sie wissen auf fast jede Frage eine Antwort, schreiben detaillierte Texte und reagieren sogar auf Gegenfragen. Dabei gibt es ein großes Problem: Die Chatbots halluzinieren, d.h. sie erfinden Inhalte, die richtig klingen, aber nicht richtig sind. Außerdem ist es aufgrund der riesigen Menge an Trainingsdaten nicht mehr möglich, zu rekonstruieren, woher eine Information stammt.

Wir haben uns mit diesem Problem auseinandergesetzt und versucht, eine Lösung zu finden, bei der ein Chatbot seine Antworten innerhalb einer bestimmten Domäne aufbaut und Quellen für die Herkunft der verwendeten Informationen aus der Domäne angibt. Solche wissensbasierten Chatbots können in praktisch jedem Bereich eingesetzt werden, z. B. zum Chatten mit Dokumentationen, Inhalten einer Datenbank oder einer Website, unter Verwendung natürlicher Sprache, ohne das Risiko von Halluzinationen. Wir haben auch Ideen wie die Verwendung von Open-Source-LLMs (z. B. LLama2), Skalierbarkeit und Kostenmanagement untersucht.

One of the superpowers of APIs is to design them as products with a focus on making them reusable. That helps with innovation and reuse, as teams can now consume the capabilities of other teams without having to coordinate with them, leading to faster flow. For this to work well, API versioning must be handled in a way that allows the API to evolve while at the same time not breaking existing consumers. What do you have to version? Why does it matter? When should you version? We present tips that help to improve your API design, description and documentation practices.

Slides: http://dret.net/lectures/innoq-tech-day-2024/

Die Hotspot-Analyse ist eine weit verbreitete Methode zur Untersuchung bestehender Softwaresysteme, mit dem Ziel, Verbesserungsarbeiten am vorhandenen Code gezielt zu priorisieren. Sie ermöglicht die Darstellung der Verbesserungsdringlichkeit und Code-Komplexität für die gesamte Codebasis in einer anschaulichen Visualisierung, aus der sich schnell die wichtigsten Schwerpunkte ableiten lassen sollen.

In diesem Vortrag werfen wir einen Blick hinter die Kulissen dieser Analysemethode. Wir werden die technischen Aspekte der Analyse beleuchten, mögliche Fallstricke aufdecken und die weiteren Potenziale dieser faszinierenden Analysetechnik erkunden. Alle, die schon immer einmal wissen wollten, was hinter den bunten Visualisierungen der Analyse-Tools steckt, finden hier wertvolle Einblicke – auch für ihre ganz eigenen Analyseideen.

Viele Architektur-Reviews betrachten häufig strukturelle und technische Entscheidungen vor dem Hintergrund von Qualitätsanforderungen. Und das ist auch gut so! In den letzten Jahren häufen sich jedoch Qualitätsanforderungen, die nicht nur rein architektonisch gelöst werden können. Dazu zählen unter anderem sehr schnelle Release-Zyklen oder minimale Abstimmungen zwischen Teams (aka Team-Autonomie). Wir behaupten: Architektur-Reviews können auch untersuchen, inwieweit eine Software-Architektur autonome Teams mit klaren Grenzen für eigene fachliche Entscheidungen unterstützt.

An dieser Stelle setzt unser Workshop an: Wir stellen vor, wie man Architektur-Reviews mit einer ganzheitlichen Perspektive betreiben kann. Dabei stellen wir einerseits kurz klassische Review-Methoden vor, z.B. ATAM, und legen einen Schwerpunkt darauf, wie man diese so erweitern kann, dass auch Perspektiven wie Domänen und Teams mit berücksichtigt werden. Auch das Alignment zwischen vertikalen Modulen in der Architektur, Domänen und Teams wird dabei beleuchtet. Wir werden hierbei diverse methodische Elemente aus dem Softwarearchitektur-, Domain-Driven Design- und Team Topologies-Umfeld aufgreifen und unsere eigenen Erfahrungen bei der Durchführung solcher Reviews einbringen. Zudem wird der Workshop auch auf Stakeholder der Bewertung und politische Fallstricke solcher ganzheitlichen Reviews eingehen.

Diese Session zeigt auf, wie sich die Ideen von DevOps und DDD ergänzen und warum man beide Ansätze kombinieren sollte. Wir werden dabei auf die kulturellen Aspekte beider Ansätze eingehen und herausarbeiten, dass die Kombination aus DevOps und DDD zu sehr gut geschnittenen cross-funktionalen Teams mit Ende-zu-Ende-Verantwortung für einen klar abgegrenzten fachlichen Bereich führt.

Der Vortrag zeigt zudem auf, welche Wege sie beschreiten können, damit aus einem “you build it, you run it” ein “you design it, you build it and you run it” wird.

Zielpublikum: Architekt:innen, Projektleiter:innen, Entscheider Voraussetzungen: DevOps- und DDD-Grundlagen sind vorteilhaft Schwierigkeitsgrad: Fortgeschritten

Einer Studie zufolge geht ein größerer Teil erfolgreicher Cyberangriffe im Jahr 2022 auf das Konto gestohlener Passwörter. Für die vorigen Jahre dürfte es nicht viel anders sein. Die Mehrheit dieser Angriffe hätte mit 2FA verhindert werden können. Trotzdem etabliert sich 2FA nur schleppend. Im Gegenteil, momentan stehen eher die verschiedenen Techniken der Passwortlose-Anmeldung im Vordergrund.

Wie ist der Stand der Dinge bei 2FA, welche 2FA Verfahren sollten heute eingesetzt werden und welche nicht, welche Herausforderungen behindern die Ausbreitung, oder brauchen wir 2FA in Zukunft gar nicht mehr? Diesen und weiteren Fragen wollen wir in diesem Vortrag auf den Grund gehen.

Lernziele

• Überblick über die verschiedenen 2FA Verfahren
• Vor- und Nachteile der verschiedene 2FA Verfahren
• Probleme und Herausforderungen beim Deployment der verschiedenen 2FA Verfahren
• Vor- und Nachteile von 2FA im Vergleich mit Passwort-Managern oder Passwortlose-Anmeldungen

Team Topologies and Context Maps are two interesting approaches to visualize sociotechnical architectures. However using each method on its own you will not be able to capture a truly holistic view of the system as a whole but you can use both in combination and this is what this talk is about. This talk will introduce a Systems Thinking perspective on those two approaches and explain how both can be leveraged in combination to get a deep dive on many interactions in a system of teams and software.

Those interactions include:

• team relationships
• team dependencies
• propagation of domain models
• governance related communication
• provisioning of APIs / services

However we will also look at the components of the system with Team Topologies being team centric and Context Maps being bounded context centric. I will finally explain how you can use both methods to visualize alignments between domains, bounded contexts and teams. This talk assumes that you have a basic understanding of strategic Domain Driven Design (esp. Bounded Contexts and Context Maps)

Livestream: https://youtu.be/xbH2rxXsaI0

Wardley Maps is a technique for visualizing and understanding the evolution of systems, services, and development teams. It is a valuable tool for software developers to identify the key components of a system and understand how they change over time.

In this talk, I will introduce you to the fundamental concepts of Wardley Maps and the process of creating a map for a software system. I will also discuss how Wardley Maps can be used to identify opportunities for innovation and how to use it for communicating the current state and future direction of your system.

I provide examples of how I use Wardley Maps in real-world software development projects, and how I derive strategic decisions from them. Although Wardley Maps is not a silver bullet, it may be a useful technique in your toolbox where you need a bird’s eye view of your system and discuss ideas for its evolution with others – especially businesspeople.

Häufig wird im Zusammenhang mit Spring Boot das Wort “Magie” erwähnt. Tatsächlich können der Einsatz von Annotationen und die sonstigen Mechanismen, die unter der Haube von Spring Boot werkeln, gerade auf Menschen ohne jahrelange Spring Erfahrung magisch wirken. Diese Session zeigt, aus welchen Bestandteilen Spring Boot besteht und wie diese im Detail funktionieren. Dabei wird auch klar, welche Arbeit uns das Framework abnimmt. Am Ende angekommen wirkt das ganze dann nicht mehr magisch, sondern eher wie mit Wasser kochen.

In Unternehmen werden Datenanalysen intensiv genutzt, um aus Geschäftsdaten wertvolle Einsichten zu gewinnen. Warum nutzen wir als SoftwareentwicklerInnen Datenanalysen dann nicht auch für unsere eigenen Daten?

In diesem Workshop stelle ich Vorgehen und Best Practices von Software Analytics vor. Wir sehen uns die dazugehörigen Open-Source-Werkzeuge an, mit denen sich Probleme in der Softwareentwicklung zielgerichtet analysieren und kommunizieren lassen.

Im Praxisteil mit Jupyter, pandas, jQAssistant, Neo4j & Co. erarbeiten wir gemeinsam wertvolle Einsichten aus Datenquellen wie Git-Repositories, Performancedaten, Qualitätsberichten oder auch direkt aus dem Java-Programmcode. Wir suchen nach besonders fehleranfälligem Code, erschließen No-Go-Areas in Altanwendungen und priorisieren Aufräumarbeiten entlang wichtiger Programmteile.

Development teams usually don’t like to write documentation. By way of contrast, a certain amount of documentation often proves useful in the long run. Why not give the established Canvas pattern a chance to shine in software architecture?

In this talk, you will learn a highly pragmatic approach to document and communicate the most important aspects of your architecture (and implementation). It is compatible with the established arc42 template, but significantly shorter. Prepare yourself for an example-ridden talk and plenty of practical tips that will make documentation fun and productive!

Backing article: Concise Documentation – Revisited

A reliable HTTP client is an indispensable tool in the everyday life of a web developer. These tools make it possible to efficiently test and manage API requests, significantly easing development and debugging processes. While Postman and Insomnia have been the preferred tools for these tasks in recent years, a new HTTP client is now gaining popularity: Bruno.

Bruno distinguishes itself from Postman and Insomnia by its deliberate avoidance of cloud services, allowing for a completely offline-based usage. Bruno enables the storage and versioning of request collections using Git and its own Bru Markup Language, ensuring seamless team collaboration and easy tracking of changes. Compared to the established tools, Bruno is a lightweight and user-friendly alternative.

In this talk, we will explore the functionality of Bruno in detail and experiment together to see how Bruno compares to Insomnia and Postman.

In his book “The Software Architect Elevator” Gregor Hohpe uses the analogy of an elevator in a high building for the daily work which software architects should be doing: They are supposed to talk to folks who build and maintain stuff in the engine room but also make sure that the managment which is residing on the penthouse floors understand and gain interest in what is happening in the engine room.

In my talk I will build upon Gregors ideas and show you how you can leverage ideas from Domain Driven Design in this daunting communication tasks. But rest assured: I will not only present the obvious strategic Domain Drivend Design elements like core / supporting / generic subdomains here. We will go deeper and explore links to other initiatives in an org like DevOps, Agile and / org Design Thinking as well which are of interest for the leadership of an organization.

We as a community should get better at this topic because Domain Driven Design needs a healthy, blame free and safe environment in order to flourish and this environment needs to be established and lived by the leadership folks.

PS: The talk idea and usage of Gregors elevator analogy have been approved by Gregor

Data Science gains new insights from business data. As software developers, why don’t we use Data Science to analyze our data from our software systems, too?

In this session, I will talk about approaches to mine software data based on the many ideas from the Data Science field. We’ll also look at the standard tools used in this area to analyze and communicate software development problems easily. With tools such as computational notebooks, data analysis frameworks, visualization, and machine learning libraries, we make hidden issues visible in a data-driven way.

Attendees will learn how to leverage scientific thinking, manage the analysis process, and apply literate statistical programming to analyze software data in an understandable way. The main part will be hands-on live coding with Open Source tools like Jupyter notebook, Python, pandas, jQAssistant, and Neo4j. I’ll show which new insights we can gain from data sources such as Git repositories, performance measurements, or directly from source code.

Ein großer Teil der Softwareentwicklung besteht aus Wartungsarbeit. In Ausbildung und Studium haben wir oft jedoch nur die Neuentwicklung kennengelernt. Überforderung droht, Frust baut sich auf und die Freude an der Softwareentwicklung geht verloren. Das muss nicht sein!

Wir stellen die Rolle “Evolutionist” vor, welche sich auf die qualitativ angemessene Weiterentwicklung bestehender Systeme fokussiert. Wir blicken auf das notwendige Skill- und Mindset sowie erste Praktiken, um mit großen und langlebenden Softwaresystemen zurecht zu kommen.

Der Browser hat sich in der letzten Dekade zur dominierenden Applikationsplattform entwickelt. Leider besteht das unterliegende Applikationsmodell daraus, Code aus potenziell nicht vertrauenswürdigen Quellen auszuführen. Damit daraus keine Gefahr von einer Website für eine andere Website erwächst - und für den Browser selbst - haben die Browserhersteller:innen in Laufe der Zeit eine ganze Reihe von Sicherheitsmaßnahmen entwickelt:

• Content-Security-/Cross-Origin Resource-/Cross-Origin-Embedder-/Same-Origin-Policy

• Cross-Origin Resource Sharing

• diverse HTTP-Header

• Cookie-Attribute u. a.

Hierbei den Überblick zu behalten, ist schwer. Diese Keynote hilft dabei.

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:

• Welche Stakeholder Du in diesen Prozess einbeziehen solltest
• Warum und wie das zukünftige Enabling-Team ebenfalls befähigt werden muss
• Wo typische Fallstricke dieser Transformation lauern
• Warum dieser Wandel auf agile Weise, geprägt von kontinuierlichem Lernen und Retrospektiven, stattfinden sollte

Zudem werden im Vortrag zahlreiche Praxisbeispiele vorgestellt, die diesen Transformationsprozess begleiten.

Manche Entscheidungen beim Entwurf und der Evolution von Softwarearchitekturen lassen sich nicht immer rational begründen. Zahlen, Daten und Fakten sprechen klar für die eine Lösung, jedoch wird sich zu oft “aus dem Bauch heraus” für die andere Lösung entschieden. Was treibt uns hier an? Welche unsichtbaren Kräfte wirken hier auf uns ein, ohne dass wir es merken?

In diesem Talk betrachten wir ein spannendes Feld, welches in der Softwarearchitekturarbeit bisher wenig präsent ist: Behavioral Economics. Wir sehen uns an, woher es kommt, dass wir uns in manchen Situationen von unserem eigenen Gehirn austricksen lassen. Wir lernen aber auch, wie wir uns in der täglichen Arbeit als Softwarearchitekt:innen etwas besser davor schützen. Dazu stelle ich Techniken und Workshop-Formate vor, welche einige Denkfallen vermeiden.

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.

‍

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.

Die Cloud-Migration ist oftmals eine notwendige Evolution und stellt Unternehmen vor essenzielle Entscheidungen: Optimierung bestehender Systeme, Neuentwicklung von Cloud-Native Architekturen und strukturelle Anpassungen im Unternehmen selbst. In dieser praxisorientierten Session werden die zentralen Eckpfeiler der Cloud-Migration beleuchtet: Organisation, Infrastruktur und Architektur.

Darüber hinaus stehen pragmatische Strategien im Fokus, damit Bestandssysteme lauffähig in die Cloud gehoben werden können. Bekannte Muster wie 6 R’s bieten einen strukturierten Rahmen, um zu evaluieren, welche Anwendungen unverändert migriert werden können und welche neu entwickelt oder komplett ersetzt werden müssen.

Die Prinzipien hinter der DevOps-Bewegung sind schon recht alt. Dennoch haben die meisten Unternehmen nach wie vor Probleme damit, DevOps-Praktiken lösungsorientiert anzuwenden. Dadurch bleiben viele der Vorzüge auf der Strecke und die Qualität der zu entwickelnden Produkte sinkt.

Im halbtägigen Webinar mit Anja Kammer und Sven Johann lernen Sie anhand praktischer Beispiele, wie Sie Wissens- und Kompetenzsilos auflösen. Mit Value Stream Mapping und weiteren Techniken können Sie dann Ihre Prozesse analysieren und Flaschenhälse ihrer Software-Delivery identifizieren. Abschließend lernen Sie mit Team Topologies, Community of Practice und dem Spotify-Modell verschiedene, gut funktionierende Praxisbeispiele kennen.

In verteilten Systemen eignen sich asynchron entkoppelte Schnittstellen, um Daten zu replizieren und um Domain Events auszutauschen. Bei asynchronen Schnittstellen denkt man dabei häufig sofort an Message Broker wie Apache Kafka, RabbitMQ und ähnliche Technologien.

Dies führ allerdings zu Komplexität und technologischen und organisatorischen Abhängigkeiten.

Dabei können asynchrone Schnittstellen auch ohne zusätzliche Middleware-Systeme einfach über HTTP-APIs realisiert werden.

Wir schauen uns ATOM, Server-Sent Events und Long-Polling-Ansätze wie REST-Feeds näher an und diskutieren die Anforderungen an solche APIs.

Mit Java 17 gibt es seit dem 14.9. ein neues Long-Term-Support Release, das auf Java 11 folgt. Obwohl die Möglichkeit bestand, alle sechs Monate auf das jeweils aktuellste Zwischenrelease zu migrieren, haben viele auf genau dieses neue LTS-Release gewartet. Bei einem Wechsel kommen jetzt natürlich alle neuen Features der letzten 3 Jahre zusammen. Darum wollen wir uns in diesen 45 Minuten die Zeit nehmen, um uns die, meiner Meinung nach, wichtigsten Features gemeinsam anzuschauen.

Git ist heute das wohl am weitesten verbreitete Versionskontrollsystem. Die Meisten verwenden aber nur wenige Features wie Commit, Push, Branch und Merge. Für Problemlösungen werden irgendwelche Umwege beschritten, da gar nicht bekannt ist, dass es dafür Hausmittel gibt.

In diesem Vortrag möchte ich von einigen dieser verborgenen Schätze berichten und zeigen, wann es Sinn macht, diese zu verwenden. Wir werden uns unter anderem auf die Suche nach Commits machen, die unsere Anwendung kaputt gemacht haben, Encoding-Problemen entgegentreten, verschiedene farbige Darstellungen unserer Historie ausprobieren, Repositorys aus anderen Versionskontrollsystemen (SVN) importieren und dabei Daten und Inhalte filtern und unsere Konfigurationen aufräumen.

Einiges davon könnt ihr sicherlich in euren Arbeitstag mitnehmen.

Das ganze Team sitzt in einem Online-Meeting und entwickelt gemeinsam. Einer tippt den Code, die anderen diskutieren. Klingt ungewöhnlich? Das ist Remote Mob Programming, eine spannende Arbeitsweise für verteilte Teams.

Seit über 3 Jahren arbeitet Joshua Töpfer Vollzeit in einem Remote Mob und möchte nicht mehr anders arbeiten. Was es damit auf sich hat, was die Vor- und Nachteile dieser Methodik sind und wie ihr herausfinden könnt, ob diese Methodik etwas für euer Team ist, erfahrt ihr in diesem Vortrag.

Vielleicht kennst du das auch: Umstrukturierungen stehen an und auf einmal wird das Operations-Team umbenannt. Euer Management ist clever und weiß ganz genau, dass es keine DevOps-Teams geben kann, also ist der neue Name: Plattform-Team.

Aber verdient solch ein Team eigentlich diese Bezeichnung und was ist der Unterschied zwischen Operations- und Plattform-Teams?

In diesem Vortrag spreche ich außerdem darüber, was interne Development Plattformen eigentlich ausmachen, warum ein Operations-Team keine solche Plattform anbieten kann und was das ganze eigentlich mit DevOps und Einhörnern zu tun hat.

“GitOps ist doch nichts anderes als Infrastructure-as-Code.” Dieses Missverständnis von GitOps hält sich hartnäckig und ist vermutlich der Grund, weshalb das Verständnis über die Vorteile von GitOps noch nicht bei allen Entwickler:innen angekommen ist. Git wird dabei als Schnittstelle für einen Operator verwendet, der Deployment- und Betriebsaufgaben innerhalb der Zielumgebung ausführt. In dieser Session räume ich mit Vorurteilen auf und zeige, welche Fallstricke bei der Anwendung dieser neuen Deployment- und Betriebsstrategie lauern. Außerdem gebe ich Tipps bei der schrittweisen Transformation – weg von traditionellen CI/CD Pipelines hin zu Cloud-Native Deployment und Betrieb mit GitOps.

Having AI that doesn’t know your company is like having a brilliant strategist who wakes up from years in a coma and realizes they’ve never heard of your business. Can you really expect insider tips from them?

How can we ensure that AI systems are accurate, transparent, and always up-to-date? All Large Language Models (LLMs) have a cut-off date after which their world knowledge stops. And they know nothing about your company’s internal workings. Even the leading models have hallucination rates that can’t be completely ignored. However, they offer enormous potential for productivity, efficiency, and creativity.

This is where Retrieval-Augmented Generation (RAG) comes in: LLMs are enhanced through targeted information retrieval. In this presentation, we’ll explore the architecture of RAG-based systems. We’ll discuss the integration into existing IT infrastructures and the optimization of data quality and context management. We’ll learn how RAG helps to fill knowledge gaps and improve the accuracy and reliability of generative AI applications.

Eine KI, die Dein Unternehmen nicht kennt, ist wie eine brillante Strategin, die nach Jahren im Koma aufwacht und feststellt, dass sie noch nie von Deiner Firma gehört hat. Kannst Du von ihr Insider-Tipps erwarten?

Wie können wir sicherstellen, dass KI-Systeme präzise, nachvollziehbar und stets auf dem neuesten Stand sind? Alle Large Language Models (LLMs) haben ein Cut-off-Datum, an dem ihr Weltwissen endet. Und über Unternehmensinterna wissen sie nichts. Dazu haben selbst die führenden Modelle noch Halluzinationsraten, die man nicht völlig ignorieren kann. Sie bieten aber gewaltiges Potenzial für Produktivität, Effizienz und Kreation.

Retrieval-Augmented Generation (RAG) setzt genau hier an: LLMs werden durch gezielte Informationsbeschaffung erweitert. In diesem Vortrag schauen wir uns die Architektur von RAG-basierten Systemen an. Wir besprechen die Integration in bestehende IT-Infrastrukturen und die Optimierung von Datenqualität und Kontext-Management. Wir lernen, wie RAG dazu beiträgt, Wissenslücken zu schließen und die Genauigkeit und Zuverlässigkeit von Anwendungen auf Basis von generativer KI verbessert.

Bounded Contexts gehören zum strategischen Domain-Driven Design und sind derzeit in aller Munde. Viele Teams versprechen sich durch die Modularisierung mit Bounded Contexts einen guten fachlichen Schnitt für ihre Software. Es stellt sich jedoch häufig die Frage, wie wir denn überhaupt zu einem guten Bounded-Context-Schnitt kommen.

Genau um diese Frage dreht sich der Vortrag. Ich werde zeigen, wie man mithilfe kollaborativer Modellierungsmethoden (z.B. Event Storming) eine Abgrenzung seiner Problemdomäne erreichen kann und wie man von dort unter Berücksichtigung verschiedener Perspektiven (Regeln, Sprache, Schnittstellen, etc.) zu einem ausgewogenen Bounded-Context-Schnitt kommt.

One of the important aspects of platforms and platform engineering is to provide solutions for problems that occur in many APIs of a platform. This way API designers don’t have to spend effort on solving the same problem over and over again, and API consumers can benefit from a more coherent design across the APIs of a platform. How to deal with problems that can occur is one of those questions that every API design needs to address. In this presentation we look at typical issues, some patterns and anti-patterns how to address them, and we also look at some standardized building blocks for representing those patterns. This allows designers and developers to spend less time figuring out what to do when everything is not OK.

Langsame Entwicklung? Unter Last ächzende Server? Unglückliche User? Es gibt viel anzupacken in der Softwareentwicklung! Aber wo anfangen?

In diesem Vortrag gebe ich eine Einführung in den systematischen Umgang und der Lösung von vertrackten Situationen für Softwarearchitekt:innen. Wir sehen uns fundamentale Denkfehler an, die Problemlösende bereits bei der Sammlung und der Formulierung von „Problemen“ oft begehen. Damit gewappnet, suchen wir systematisch nach den echten Knacknüssen. Wir nutzen die „Landkarte der Probleme“, um zusätzlich Ursachen und Auswirkungen in Beziehung zu setzen. Der neu gewonnen Überblick erlaubt es dann, die uns möglichen Maßnahmen zu finden, die ein Softwaresystem immer mehr ein kleines Stückchen besser machen.

Im Web lauert eine Vielzahl von Sicherheitsgefahren. Deshalb sollten ein paar grundlegende Vorkehrungen getroffen werden: Angefangen bei der richtigen TLS-Konfiguration, über Schutzmaßnahmen wie dem Einrichten einer Content-Security-Policy und dem Überprüfen nachgeladener Ressourcen mittels Subresource Integrity, bis hin zur Absicherung von Cookies sowie dem Schicken oder Vermeiden bestimmter HTTP-Header. Welche grundlegenden Maßnahmen es zu beachten gilt und wie man diese umsetzt, erfahren Sie in diesem Vortrag.

WebAssembly, oft abgekürzt als WASM, ist ein binäres Ausführungsformat für Webanwendungen. Es handelt sich um eine plattformübergreifende Technologie, die in modernen Webbrowsern nativ unterstützt wird. In letzter Zeit findet WebAssembly als Laufzeitumgebung auch außerhalb des Browsers immer mehr Verbreitung, z. B. als Alternative zu Containern. Sowohl strukturell als auch von den Zielen ähnelt WebAssembly dabei Java und der JVM.

In diesem Vortrag erfahren Sie mehr über die aufregende Welt von WebAssembly und können herauszufinden, wie Java-Entwickler:innen von dieser innovativen Technologie profitieren können.

• Lernziele: Nach dem Vortag sollten die Teilnehmer:innen einen Überblick über WebAssembly haben und die grundlegenden Vor- und Nachteile sowie die Unterschiede und Gemeinsamkeiten zu Java und der JVM kennen.
• Vorkenntnisse: Programmierkenntnisse in einer (oder mehreren) Mainstream-Programmiersprachen.

Software-Supply-Chain-Security ist ein Thema, das immer mehr an Bedeutung gewinnt. Leider wird es häufig auf 3rd-Party-Software, Package-Management und Tooling zum Aufspüren von bekannten Sicherheitslücken verkürzt.

Zweifellos sind diese wichtigen Bestandteile der Software-Supply-Chain-Security, dennoch verbergen sich noch eine Menge weitere, ebenso wichtige Aspekte hinter einer sicheren Software-Supply-Chain: von kulturellen, psychologischen und soziotechnischen Facetten über vertrauenswürdige Quellen, Builds und Tools sowie Standards und Maßnahmen.

Lernen Sie in diesem Vortrag das volle Spektrum der Software-Supply-Chain-Security kennen.

Lernziele

Nach dem Vortrag sollten die Teilnehmer:innen eine Vorstellung davon haben, was alles zur Software-Supply-Chain-Security gehört, und wie sie diese in ihren Projekten berücksichtigen können.

… vom Strategieelfenbeinturm in den Codemaschinenraum

Besonders die Werkzeuge des strategischen DDD (z. B. Finden von Bounded Contexts) haben sich in vielen Projekten bewährt. Doch die Umsetzung der gefundenen fachlichen Strukturen im Code kann herausfordernd sein.

Übermäßiger Einsatz von DDD-Konzepten hat teilweise zu Vorurteilen gegenüber DDD geführt („Das ist doch nur Bloat!“), denn nicht jeder Kontext profitiert von zusätzlicher Komplexität im Code.

In diesem Vortrag werden wir nach einer kurzen Einführung in taktisches DDD anhand von Beispielen aus der Praxis Tricks, Fallstricke und Erfahrungen diskutieren, um neue Codebases besser zu strukturieren und Bestandssysteme zu verbessern.

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-premises 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.

Das Entwickeln von komplexen CI/CD-Pipelines gestaltet sich oft mühsam, da wir bei Änderungen immer wieder den Lauf der Pipelines abwarten müssen. Besonders für Teams mit einem Fokus auf Infrastruktur-, DevOps- und Plattform-Themen sind Pipelines häufig ein zentraler Aspekt ihrer Produkte und schnelles, iteratives Arbeiten ist dort essenziell. Aber wäre es nicht generell großartig komplette Pipelines lokal laufen lassen zu können? Genau da setzt dagger.io an. Durch clevere Kombination von Containern als Laufzeitumgebung für Build-Steps und der (Dependency-)Graph-Execution-Engine BuildKit (Ja, die aus Docker) entsteht ein sehr flexibles Buildsystem, welches sich über SDKs nativ in gewohnten Programmiersprachen verwenden und erweitern lässt. Es ist keine neue Syntax zu lernen und wer schon mit Containern gearbeitet hat, kann die grundlegenden Konzepte schnell erfassen.

Im Talk schauen wir an einem Beispiel auf die verwendeten Konzepte / Komponenten und lernen wie die Brücke zwischen Buildsystem, CI/CD-Server und Plattform geschlagen werden kann. Und das alles ohne YAML.

Data Mesh ist ein neuer sozio-technischer Ansatz für eine dezentrale Datenarchitektur mit dem Ziel, auch in großen Unternehmen Mehrwert aus Daten zu schöpfen. Im Vortrag geht es um die vier grundlegenden Prinzipien von Data Mesh. Es wird auch explizit darauf eingegangen, was Data Mesh nicht ist. Anschließend lernen wir eine Methodik kennen, um das Herzstück von Data Mesh: ‘Daten Produkte’ zu designen.

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.

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.

Wir kennen das alle, die neue Unternehmensstrategie liest sich auf den ersten Blick aufregend: mehr Kundenfokus, bessere Produkte bei gleichzeitiger Kostensenkung. Die neue IT-Strategie schlägt dazu eine Cloud-native-Transformation vor, um diese Ziele zu erreichen. Hierzu gehören die neuesten Cloud-Technologien, Self-Service Infrastruktur und Two-Pizza Teams, die kontinuierlich neue Features ausliefern. Natürlich all das, während der Chaos Monkey munter wütet. Aber wie sieht die Welt aus, fünf Jahre später? Wir haben keines der Unternehmensziele erreicht, nur die Infrastrukturkosten sind explodiert.

Um tragfähig in die Cloud zu gehen, bringt oft ein alleiniger Fokus auf neueste Cloud-Technologien nicht den erhofften Erfolg, sondern es braucht auch unterstützende Teamstrukturen und Interaktionsmodi für Entwicklungsteams. Aus unserer Consulting-Praxis bringen wir realistische Fallstricke mit und zeigen, wie wir sie überwunden haben oder besser überwunden hätten. Wir sprechen dabei über Ideen aus Team Topologies, Produktmanagement und interne Entwicklungsplattformen.

Um Anwendungen zu deployen haben sich Container mittlerweile flächendeckend etabliert. Doch bevor wir einen Container deployen können müssen wir diesen erst einmal bauen. Hierzu gibt es innerhalb des Java-Universums mittlerweile eine große Anzahl an Möglichkeiten. Neben dem bauen gibt es zudem den ein oder anderen Fallstrick um einen Java-Prozess sauber innerhalb des Containers laufen zu lassen.

In dieser Session schauen wir uns deshalb mehrere Wege an eine kleine Spring Boot Anwendung in einen Container zu packen und diese anschließend sauber in diesem auszuführen. Die vorgestellten Tools und Tipps können dabei fast alle auch auf eine nicht Spring-Anwendung angewandt werden.

Das Repository mit Beispielcode ist unter https://github.com/mvitz/javaspektrum-spring-container zu finden.

Unser Job als Entwickler oder Entwicklerin ist schon schwierig: Ständig hören wir von neuen Hypes mit all ihren Vorteilen. Oft haben wir diese direkt in unseren Projekten eingesetzt und wunderten uns dann, dass es an allen Ecken und Enden knarzt. Wenn wir das doch nur schon vorher gewusst hätten! Dabei ist die Frage, ob ein Hype auch zu unserer Art des Entwickelns passt, eigentlich ganz einfach zu beantworten: Es kommt drauf an!

In diesem Vortrag durchleuchten wir das „Es kommt drauf an!“ etwas genauer. Dazu nutzen wir das Denk- und Kommunikationswerkzeug „Wardley Maps“. Wardley Maps sind evolvierende Strategielandkarten, welche ein kontextspezifisches Situationsbewusstsein für die eigenen Softwaresysteme schaffen. Sie bieten uns einen Ort zum Diskutieren: Welches Entwicklungspraktiken wollen wir einsetzen? Welches Vorgehensmodell ist das Richtige? Auf welche Technologie sollen wir umstellen? Was bauen wir selbst und was holen wir uns woanders?

Mit Wardley Maps erstellen wir für diese Art von Fragen Landkarten, um unsere eigene Situation besser verstehen zu können. Somit lernen wir unser eigenes „Es kommt drauf an!“ besser kennen, um in Zukunft weniger oft den letzten Hypes zu verfallen.

Der Umfang der MLOps-Prozesse und -Technologien hängt von dem AI „Maturity Level“ der jeweiligen Organisation ab. Das Umsetzen von kanonischem MLOps kann zu einer unnötigen Komplexität in der Architektur und Organization führen. Das “AI Readiness”-Framework definiert den Reifegrad einer Organisation bei der Nutzung von ML/AI und ordnet es in eine der drei Stufen ein: Tactical, Strategic und Transformational. In dem Vortrag gehe ich auf die drei “AI-Readiness”-Stufen ein und zeige, wie man eine MLOps Roadmap ableitet.

Wie wir an der Softwarearchitektur eines Softwaresystems arbeiten, hängt stark von der jeweiligen Situation ab. In diesem Vortrag werfe ich einen Blick auf einen besonders wichtigen Faktor davon: der Softwareevolution. Denn je nachdem, wie weit ein Softwaresystem evolviert ist, unterscheidet sich damit auch potenziell der Ansatz, wie Softwarearchitekturen erarbeitet werden: Von “No-Architecture” über “Architekturdiktatur” und “Multi-Level-Architektur” hin zu “Architekturspezialisten” diskutieren wir, wann welcher Ansatz welche Stärken ausspielt und wann es dringend Zeit für einen Wechsel ist. Wer sich jemals in endlosen Diskussionen über das “Warum?”, “Wie?” und “Wie viel?” Softwarearchitektur verloren hat, findet in diesem Vortrag erste Antworten für einen systematischen Ansatz der Softwarearchitekturentwicklung.

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 Einstieg in die visuelle Welt des strategischen Denkens für Softwareentwickelnde

Wardley Maps ist eine Methode, um dein Situationsbewusstsein für Softwaresysteme zu verbessern und deine nächsten Schritte bei Umbauarbeiten zu motivieren: Warum sollten wir besser nicht mehr unser liebgewonnenes, selbstgeschriebenes Logging-Framework weiterentwickeln? Warum müssen wir uns nun plötzlich doch um Dokumentation kümmern? Wie schaffen wir es, unseren Marktmitbegleitern einen Schritt voraus zu sein? Mit Wardley Maps werden komplexe Zusammenhänge zwischen Business und Technik visualisiert und nachvollziehbare Lösungen für die Zukunft aufgezeigt.

Der Vortrag bietet dir anhand zahlreicher Beispiele und Erfahrungen aus dem Entwicklungsalltag einen praxisnahen Einstieg in die visuelle Welt des strategischen Denkens mittels Wardley Maps. Abgerundet wird der Vortrag mit zahlreichen Tipps und Tricks für die nächsten, eigenständigen Schritte.

Aufzeichnung des Talks auf Vimeo: https://vimeo.com/875184620

“Stellt euch vor, ihr seid Teil eines kleinen Teams von vier Softwareentwickler:innen, die von zu Hause aus arbeiten. Ihr trefft euch jeden Tag um 9 Uhr in eurem Zoom-Teamraum. Nach dem obligatorischen Kaffee und etwas Smalltalk wählt ihr die wichtigste User Story aus, diskutiert diese gemeinsam und beginnt dann mit der Umsetzung. Eine Person teilt den Bildschirm und fungiert als Typist, während die anderen über die Umsetzung diskutieren und dem Typist Anweisungen geben. Nach 10 Minuten übergibt der Typist seine aktuelle Arbeit an den nächsten Typist. Dies wird so lange wiederholt, bis die User Story fertig ist, woraufhin ihr die nächst-wichtige User Story auswählt. Um 17 Uhr haltet ihr inne, reflektiert kurz gemeinsam über den Tag und macht dann Feierabend. Klingt verrückt? Ich habe das über drei Jahre lang gemacht. Und ich möchte nicht mehr anders arbeiten. In diesem Vortrag möchte ich euch unsere Geschichte erzählen. Ich möchte euch erzählen, wie wir zusammengearbeitet haben und was die Konsequenzen für uns waren. Kurz gesagt, ich möchte euch erzählen, wie wir trotz Homeoffice zusammengewachsen sind. Aber lasst mich an dieser Stelle ein Wort der Warnung aussprechen: Wenn ihr diese Art der Zusammenarbeit einmal ausprobiert habt, werdet ihr vielleicht nie wieder zurückkehren können!”

Bio

Dr. Simon Harrer ist ein neugieriger Tech Lead bei INNOQ, der es liebt, zusammenzuarbeiten und sein Wissen zu teilen. In seinem letzten Projekt entdeckte er seine bevorzugte Arbeitsweise, nämlich Remote Mob Programming, für die er natürlich eine Website und ein kurzes Buch als Co-Autor verfasste und dabei Remote Mob Programming einsetzte. Neben seinen typischen Beratungsprojekten coacht er heute Remote-Teams, damit sie nicht nur besser zusammenarbeiten, sondern auch zusammenwachsen.

Auf Basis von über 6 Jahren Java Lehre an der Uni Bamberg und dem Korrigieren von unzähligen Java-Aufgaben haben wir - Jörg Lenhard, Linus Dietz und Simon Harrer - ein Buch geschrieben, welches die typischen Fehler in einer innovativen Vorher/Nachher-Darstellung aufzeigt und erklärt: Java by Comparison. Durch diese Vergleiche können Einsteigerinnen und Einsteiger schneller eine Intuition für “Clean Code” entwickeln, Profis hilft es, ihre Denkweisen Einsteigern besser zu erklären und vielleicht das eine oder andere aufzufrischen. Wir stellen erst die Geschichte des Buches vor und gehen dann konkret auf ein paar der Vergleiche aus dem Buch ein. Danach wollen wir gemeinsam kreativ sein und mit euch ein von uns entwickeltes Spiel namens Comparison Jeopardy spielen.

Wir freuen uns auf euch!

Alle wollen gute Software schnell entwickeln. Alle möchten in ihren Rollen dazu beitragen und bringen aus ihren Sichtweisen gut gemeinte Maßnahmen mit ein:

• Agile Coaches führen SCRUM ein. Also auch JIRA.
• Entwickler:innen entwickeln flexible Lösungen.
• Architekt:innen definieren Referenz-Architekturen.
• Operations führt Kubernetes ein.
• Security Experts erstellen Checklisten.
• HR stellt Ninjas ein.
• Team-Leads wollen den Teams helfen und stellen Jour-Fixes ein.
• CIO fordert Vendor-Independence.
• Irgendjemand führt plötzlich MS Teams ein.

In der Theorie sind diese gut gemeinte Maßnahmen sehr hilfreich. In der Praxis zeigt sich jedoch oft ein anderes Bild: Alle sind irgendwie unzufrieden. Software-Projekte dauern immer länger.

Ihr begleitet in diesem kurzweiligen Vortrag ein initial engagiertes Team, das immer mehr gut gemeinte Maßnahmen aufgedrückt bekommt. Lernt, wie ihr solche Maßnahmen erkennen könnt und wie ihr erfolgreich dagegensteuert.

Analytische Daten werden häufig von einem zentralen Daten-Team eingesammelt und verwaltet. Aber wir (als Entwickler:innen) bekommen kaum Feedback. Und das, was wir sehen, ist auch häufig noch falsch. Dabei werden Datenauswertungen immer wichtiger, um unsere Kund:innen zu verstehen und den Nutzen von User Stories zu bewerten. Mit Machine Learning werden zudem ganz neue Funktionen für unsere Systeme ermöglicht.

Mit Data Mesh wird ein soziotechnischer Ansatz vorgestellt, der basierend auf Konzepten wie Domain-driven Design, Product Thinking und Team-Topologies die Verantwortung für Daten an die Entwicklungsteams zurückgibt.

Jochen Christ, Co-Autor von datamesh-architecture.com, zeigt, welche Vorteile sich daraus ergeben, aber auch vor welchen Herausforderungen Entwicklungsteams stehen werden.

Daten endlich sinnvoll nutzen! Data Mesh befähigt Entwicklungsteams, innerhalb ihrer Domäne Datenanalysen selbstständig durchzuführen, um ihre Services selbstständig verbessern zu können. Über definierte Schnittstellen werden qualitativ hochwertige analytische Daten als Produkte auch anderen Teams zur Verfügung gestellt.

Zielpublikum: Architekt:innen, Entwickler:innen, Entscheider Voraussetzungen: Keine Schwierigkeitsgrad: Fortgeschritten

… and escape YAML-hell along the way

Build and CI/CD systems are powerful tools which complement each other well.

Systems like Gradle or maven take us a long way from code to running software artifacts. But if we get into a highly collaborative setting the need for a central CI/CD system will emerge soon. Scalable and reproduceable build environments for a team are just too helpful to go without them.

Sadly testing and developing complex pipelines often turns out to be tedious, because we have to wait for the central system to pick up and process our jobs. Wouldn’t it be fabulous if we could develop and run our pipeline steps locally without modifying them? Exactly this is where dagger.io is coming into play.

Through the smart combination of using containers to isolate build steps and cuelang for expressive, declarative and type safe configuration of our pipeline dagger.io creates a flexible build system which - thanks to containers - can be extended in different programming languages.

In the talk we will look into the concepts and components of dagger.io by example and learn about its inherent advantages in comparison to other build and CI/CD systems. We will learn why we definitely want to use cuelang instead of YAML in the future and define our first own build steps.

Jeder kennt sie. Niemand mag sie. Einige fürchten sie. Die Rede ist von Software-Dämonen. Verhältnismäßig große Commits mit aussageloser Commit-Nachricht – z.B. „some little changes“ bei mehr als 35 betroffenen Dateien – oder verwirrende Methodennamen wie „void actReqInter4ProcUp(string aHaMesCo)“ sind nur zwei Exemplare von derartigen Dämonen.

Die folgenden zwei Fragen müssen wir uns unter anderem stellen, um solche Dämonen nicht zu beschwören:

• Was genau soll in Commit-Messages stehen?
• Wie benennt man diese Funktion/dieses Member?

Beide Fragen zielen auf das Gleiche ab: das Benennen von Dingen, die wir geschaffen haben. Dieser Vortrag gibt mit vielen zum Teil lustigen aber auch schrecklichen Beispielen aus dem Projekt-Alltag auf beide Fragen Antworten. Und praktische Tipps stellen dar, wie ihr in Zukunft selbst Dämonen austreiben könnt.

Dieser Vortrag richtet sich an unerfahrene sowie auch an erfahrene Entwicklerinnen und Entwickler, die sich genau diese Fragen immer wieder stellen und bisher keine zufriedenstellende Antwort gefunden haben.

Aufzeichnung des Livestreams

Beim nächsten Mal dabei sein

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, wieviel 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”.

Kinder zu bekommen ist das eine, täglich mit ihnen zu leben das andere. So richtig darauf vorbereitet hat mich niemand. Dafür trainieren mich meine beiden Kleinen 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.

Hast du letztens in nem Blog ein Framework entdeckt und es gleich am nächsten Tag ins eigene Projekt „zum damit Spielen” eingebaut? Musstest du deine Anwendung schon öfter „skalierbarer”, „performanter” oder „zuverlässiger” machen und zogst dir einen Tech-Stack von den “Big Five” rein, um damit das nächste Amazon, Netflix, WhatEver zu werden?

Wahrscheinlich klang das zu dem Zeitpunkt logisch und nach einer superguten Idee. Aber ein paar Monate später weiß man selbst oft gar nicht mehr, was der eigentliche Grund für den Einsatz war. Man macht es, ohne genau zu wissen, warum: Cargo Cult par excellence!

In diesem Vortrag zeige ich, wie sich Entscheidungen für Technologien, Vorgehen und Praktiken strukturiert auswählen und nachvollziehbar motivieren lassen. Wir sehen uns an, was uns bei der Auswahl (oft unerkannt) antreibt. Dazu fischen wird zuerst die geforderte Qualität für Features aus User Stories und bauen uns ein Netz aus den qualitativen Ansprüchen für den Überblick. Mit einer ordentlichen Portion Architekturtaktiken in den Segeln schippern wir in den sicheren Hafen der fundierten Entscheidungen.

Key takeaways

• You will learn, how to use data contracts as a collaboration tool to discuss data requirements.
• You will also learn, how data contracts be used for automation, later in the development process.
• You will understand, that a data contract is more than just a schema.
• You will be able to write your first data contract as a YAML document.

In the world of software engineering, we know how important explicit, clearly documented, and stable interfaces are, and what effects unannounced breaking changes can have. We use Swagger, OpenAPI or AsyncAPI for this purpose, and on top of that tools for code generation or contract-based testing. In the world of data, there has never been anything comparable, and unannounced breaking changes, such as schema changes, are unfortunately common there.

Data contracts are something like OpenAPI, but for data. Data contracts bring the producer of data and their consumers together. Data Contracts allow the specification of the structure of the data, and its quality requirements. Data contracts contain sample data, and a semantic description. Data contracts specify terms of use for the data. Consumers can rely on data contracts.

In this talk, I want to introduce the Data Contract Specification (datacontract.com) in more detail. I want to show how interfaces are described in the world of data, and how this interface documentation differs from the world of software engineering. We will design an interface together in Data Contract Studio (studio.datacontract.com), and then use the Data Contract CLI (github.com/datacontract/cli) to simulate detecting a breaking change.

Am 28.06.2025 tritt das Barrierefreiheitsstärkungsgesetz (BFSG) in Kraft. Privatwirtschaftliche Unternehmen in bestimmten Branchen müssen ab diesem Zeitpunkt barrierefreie Produkte und Dienstleistungen anbieten. Für die Vorbereitung und Entwicklung bleibt also weniger als 1 Jahr, es bestehen aber noch viele offene Fragen. Darunter so grundlegende Fragen wie:

• Was umfasst der Begriff „Accessibility“ bzw. Barrierefreiheit konkret?
• Welche Branchen sind gemäß BFSG verpflichtet, barrierefreie Produkte und Dienstleistungen anzubieten?
• Welche Anforderungen an Produkte und Dienstleistungen stellt das BFSG eigentlich?
• Hat Accessibility negative Auswirkungen auf die Entwicklungsdauer, Ressourceneinsatz, Kreativität, etc.?
• Wie kann man schon während der Entwicklung feststellen, ob ein Produkt oder eine Dienstleistung barrierefrei ist? Grundsätzlich unterstützt Accessibility jeden einzelnen Nutzer. Accessibility sollte selbstverständlicher Bestandteil der Produktentwicklung und selbstverständlicher Teil der Unternehmenskultur sein. Die Session richtet sich an Führungskräfte, Entwickler, Designer, (Informations-)Architekten, Tester und weitere Rollen, die an dem Entwicklungsprozess von Produkten und Dienstleistungen beteiligt sind.

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.

‍

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.

„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.

Nervt dich die statische Codeanalyse in deinem Projekt? Hast du dich noch letzte Woche furchtbar darüber aufgeregt? Herzlichen Glückwunsch, dann benutzt ihr sie vermutlich falsch.

Statische Codeanalyse soll dazu dienen, die Codequalität zu bewerten und kontinuierlich zu verbessern. Klingt in der Theorie hervorragend, jedoch sieht die Realität oft anders aus: Entwickler:innen fürchten die Bewertung, das Management interpretiert Zahlen falsch, und trotz des Mehraufwands gibt es immer wieder Programmierfehler im Code.

In meinem Vortrag zeige ich euch die häufigsten Fehler bei der Verwendung statischer Codeanalyse, die mir regelmäßig in Projekten begegnen. Gemeinsam werden wir Lösungen und Tipps erarbeiten, um diese Fehler künftig zu vermeiden. Und wer weiß, vielleicht begegnen uns auch Zombies auf unserem Weg zur besseren Codequalität.

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“ 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.