{"version":"https://jsonfeed.org/version/1","title":"INNOQ Blog","home_page_url":"https://www.innoq.com/","feed_url":"https://www.innoq.com/ch/blog.json","icon":"https://res.cloudinary.com/innoq/image/asset/favicon-1b518c5b5495aeba34b46ed6a1764b40.svg?_a=BACMTiAE","favicon":"https://res.cloudinary.com/innoq/image/asset/favicon-1b518c5b5495aeba34b46ed6a1764b40.svg?_a=BACMTiAE","items":[{"id":"https://www.innoq.com/de/blog/2026/06/faster-is-not-better/","url":"https://www.innoq.com/de/blog/2026/06/faster-is-not-better/","date_published":"2026-06-08T00:00:00.000+00:00","date_modified":"2026-06-08T10:50:15.958+02:00","author":[{"name":"Daniel Westheide","url":"https://www.innoq.com/ch/staff/daniel-westheide/"}],"content_html":"\u003c!DOCTYPE html PUBLIC \"-//W3C//DTD HTML 4.0 Transitional//EN\" \"http://www.w3.org/TR/REC-html40/loose.dtd\"\u003e\n\u003chtml\u003e\u003cbody\u003e\n\u003cp\u003eIn meinem Blogpost \u003ca href=\"https://www.innoq.com/de/blog/2025/07/erst-agil-dann-agentisch/\"\u003e«Erst agil, dann agentisch»\u003c/a\u003e habe ich argumentiert, dass KI bestehende organisationale Fähigkeiten verstärkt, und dass schnelleres Experimentieren zu den möglichen Vorteilen für gut aufgestellte Teams gehört. Wer schneller umsetzen kann, der kann im gleichen Zeitraum mehr Experimente durchführen und somit mehr lernen. Doch schnelleres Experimentieren ist nicht automatisch besser. In vielen Kontexten hängt erfolgreiche Produktentwicklung von ganz anderen Faktoren ab.\u003c/p\u003e\n\n\u003ch3 id=\"woher-experimentierkultur-kommt\"\u003eWoher Experimentierkultur kommt\u003c/h3\u003e\n\n\u003cp\u003eEs lohnt sich, einen Blick darauf zu werfen, in welchem Umfeld die Kultur des Experimentierens eigentlich entstanden ist. Sie hat sich in den Consumer-Internet-Unternehmen der 2000er und 2010er Jahre herausgebildet, wo sehr spezifische Bedingungen galten: Millionen von täglichen Nutzenden, ein enger Zusammenhang zwischen Produktentscheidungen und messbaren Ergebnissen, und ein Geschäftsmodell, das auf Engagement und Conversion optimierte. In diesem Kontext ergaben kontrollierte Experimente Sinn. Statistische Signifikanz war in Tagen erreichbar, und die Metrik, die optimiert wurde, etwa Klicks, Käufe oder Verweildauer, war eng mit dem Umsatz verbunden. Lean Startup, Growth Hacking und die DevOps-Bewegung kristallisierten sich in diesem spezifischen Umfeld heraus und wurden als universelle Methodik verpackt.\u003c/p\u003e\n\n\u003cp\u003eHeute ist Experimentierkultur vor allem dort zu Hause, wo dasselbe Grundprinzip gilt: Social Media, digitale Medienangebote, Free-to-play-Spiele, also Angebote, deren Geschäftsmodell auf Aufmerksamkeit und Ad-Revenue basiert. In diesen Kontexten sind die Nutzenden nicht die Kundschaft. Die werbetreibenden Unternehmen sind die Kundschaft, und die Nutzenden sind das Produkt. Engagement zu maximieren ist dann kein Proxy für Nutzerwert, es ist das eigentliche Ziel. Der Interessenskonflikt zwischen Unternehmens-Outcome und dem Outcome der Nutzenden stellt sich gar nicht.\u003c/p\u003e\n\n\u003cp\u003eMelissa Perri argumentiert, dass gute Produktarbeit genau diese Schnittmenge findet: Outcomes, die gleichzeitig für das Unternehmen und für die Nutzenden Wert schaffen\u003ca href=\"https://www.innoq.com/de/blog/2026/06/faster-is-not-better/#fn:1\" id=\"fnref:1\" title=\"siehe Fußnote\" class=\"footnote\"\u003e[1]\u003c/a\u003e. Das ist anspruchsvoll und setzt voraus, dass man beide Seiten versteht. Es setzt auch voraus, dass die Nutzenden die Kundschaft sind. Experimentierkultur im Ad-Revenue-Kontext hat dieses Problem elegant umgangen.\u003c/p\u003e\n\n\u003cp\u003eDas Problem ist, dass die meisten Softwareprojekte nicht in diesem Umfeld stattfinden.\u003c/p\u003e\n\n\u003cp\u003eEnterprise-Software und domänenspezifische Anwendungen haben andere Erfolgskriterien, und eine grundlegend andere Beziehung zwischen dem was sich messen lässt und dem was tatsächlich wichtig ist. Perri nennt das Ergebnis die Build Trap: Organisationen, die sich auf Output-Metriken fixieren, verlieren den Faden zwischen dem, was sie bauen, und dem, was Nutzende eigentlich brauchen. Es werden Features geliefert, die Velocity ist hoch, aber die Software bedient nicht die eigentlichen Bedürfnisse der Nutzenden.\u003c/p\u003e\n\n\u003ch3 id=\"output-statt-outcome\"\u003eOutput statt Outcome\u003c/h3\u003e\n\n\u003cp\u003eBaldur Bjarnason beschreibt in «Out of the Software Crisis»\u003ca href=\"https://www.innoq.com/de/blog/2026/06/faster-is-not-better/#fn:2\" id=\"fnref:2\" title=\"siehe Fußnote\" class=\"footnote\"\u003e[2]\u003c/a\u003e wie das in der Praxis aussieht:\u003c/p\u003e\n\n\u003cblockquote\u003e\n\u003cp\u003e„We decide on the problem without checking to make sure it’s a real problem for our end users. We then design without researching the nature and structure of the problem we’re trying to address. We ship without testing to see if it actually does the job it’s supposed to. Only then do we do some actual testing, often A/B tests. We throw two half-baked unfinished designs into a functional shipping application that people rely on to do their work and use Data™ to see which unmitigated disaster is marginally less disastrous for the working lives of those held hostage by our applications.\"\u003c/p\u003e\n\u003c/blockquote\u003e\n\n\u003cp\u003eDer erste Satz ist dabei der entscheidende. Nicht zu prüfen, ob man das richtige Problem löst, ist Output-Orientierung in ihrer reinsten Form. Man misst was sich leicht messen lässt, nicht was wichtig ist.\u003c/p\u003e\n\n\u003cp\u003eTeresa Torres macht die Konsequenz deutlich: Bei Continuous Discovery\u003ca href=\"https://www.innoq.com/de/blog/2026/06/faster-is-not-better/#fn:3\" id=\"fnref:3\" title=\"siehe Fußnote\" class=\"footnote\"\u003e[3]\u003c/a\u003e geht es nicht darum, beliebige Hypothesen schneller zu validieren. Es geht darum, Verständnis zu entwickeln, bevor überhaupt klar ist, was es zu testen lohnt. A/B-Tests sagen einem ob eine bestimmte Änderung eine bestimmte Metrik bewegt. Sie sagen einem nicht ob man die richtige Metrik bewegt, oder ob die Metrik irgendetwas mit dem verbindet was Nutzende tatsächlich interessiert.\u003c/p\u003e\n\n\u003cp\u003eBjarnason, mit Bezug auf Deming\u003ca href=\"https://www.innoq.com/de/blog/2026/06/faster-is-not-better/#fn:4\" id=\"fnref:4\" title=\"siehe Fußnote\" class=\"footnote\"\u003e[4]\u003c/a\u003e, nennt das Tampering: man reagiert auf Symptome als wären sie Ursachen. Wenn die zugrundeliegende Annahme falsch ist, optimiert A/B-Testing nur gründlicher in die falsche Richtung. A/B-Tests sind wertvoll, wenn die Voraussetzungen stimmen. Zu oft jedoch werden sie eingesetzt, um echtes Nutzerverständnis zu ersetzen statt zu ergänzen.\u003c/p\u003e\n\n\u003ch3 id=\"unsichtbare-stakeholder\"\u003eUnsichtbare Stakeholder\u003c/h3\u003e\n\n\u003cp\u003eA/B-Tests in hoher Frequenz ohne eine entsprechende Grundlage können allenfalls einen Glückstreffer landen. Wie kommt man also zu echtem Nutzerverständnis?\u003c/p\u003e\n\n\u003cp\u003eIn meinem Blog-Post \u003ca href=\"https://www.innoq.com/de/blog/2026/04/ai-cognitive-lens-domain-knowledge/\"\u003e«Warum sich Domänenwissen nicht extrahieren lässt»\u003c/a\u003e habe ich argumentiert, dass Domänenwissen oft nicht bewusst abrufbar ist und sozial verteilt, also das, was Polanyi «tacit knowledge» nennt. Dasselbe gilt für Nutzerwissen. Nutzende können oft nicht artikulieren was sie wirklich brauchen, aber sie wissen es wenn sie es erleben. Metriken sind der Versuch, dieses implizite Wissen durch Verhaltensdaten zu ersetzen.\u003c/p\u003e\n\n\u003cp\u003eTorres rät in «Continuous Discovery Habits» zu regelmäßigen Interviews mit Nutzenden und beschreibt, welche Fallstricke es zu beachten gibt und wie man die richtigen Fragen stellt, um dieses implizite Wissen hervorzubringen: Allgemeine Fragen verleiten Menschen dazu, das generalisierte Selbstbild zu aktivieren, anstatt über ihr tatsächliches Verhalten zu reflektieren. Menschen sind schlecht darin, zu wissen, was sie typischerweise tun, aber gut darin, sich an konkrete Episoden zu erinnern. Anstatt zu fragen «Welche Kriterien sind dir wichtig, wenn du ein Restaurant auswählst?», sollte man also lieber sagen: «Erzähl mir vom letzten Mal, als du mit jemandem essen gegangen bist.»\u003c/p\u003e\n\n\u003cp\u003eTools wie BMAD stellen durchaus auch Discovery-artige Fragen, etwa nach dem Problem, dem Marktumfeld und den Nutzenden. Aber sie komprimieren einen Prozess der Zeit braucht. Die Antworten, die dabei entstehen, sind das, was Befragte in diesem Moment bewusst abrufen können, nicht das, was durch Beobachtung, Iteration und Inkubation über Zeit entsteht. Und selbst wenn BMAD die richtigen Menschen befragen würde, würde die Fragestruktur systematisch das hervorbringen, was Nutzende glauben zu tun, nicht, was sie tatsächlich tun. Das implizite Wissen hingegen bleibt unsichtbar.\u003c/p\u003e\n\n\u003cp\u003eLeider arbeiten viele Organisationen aktiv dagegen, dieses Nutzerverständnis aufzubauen, indem sie Produktteams und Entwickler:innen bewusst von den Nutzenden abschirmen.\u003c/p\u003e\n\n\u003cp\u003eUnd selbst wenn Interviews mit echten Nutzenden stattfinden, kommt hinzu, dass eine Software neben denjenigen, die sie direkt benutzen, auch indirekt Betroffene hat, die das System gar nicht selbst bedienen. Ich nenne diese Personen unsichtbare Stakeholder. Selbst wenn Organisationen mit Nutzenden reden, werden diese unsichtbaren Stakeholder so gut wie nie bei Designentscheidungen berücksichtigt.\u003c/p\u003e\n\n\u003cp\u003eEin Beispiel für solch einen unsichtbaren Stakeholder wäre die Person die im Supermarkt die Regale einräumt. Sie hat wahrscheinlich keinen Zugang zur Bestellsoftware. Aber wenn diese Software eine Bestellung falsch kalkuliert, macht sie Überstunden. Wenn eine neue Version ändert, wie Lagerbestände angezeigt werden, und das System sich anders verhält, als ihr Vorgesetzter erwartet, landet die Verwirrung in der Filiale. Sie ist kein Stakeholder im üblichen Sinne des Wortes. Sie ist nur diejenige, die die Konsequenzen trägt. Und ob die Software ihre Bedürfnisse gut oder schlecht bedient, wird garantiert durch keinen A/B-Test gemessen.\u003c/p\u003e\n\n\u003ch3 id=\"dabei-sein-statt-messen\"\u003eDabei sein statt messen\u003c/h3\u003e\n\n\u003cp\u003eMein Kommilitone Jörg Niesenhaus blickte kürzlich \u003ca href=\"https://www.linkedin.com/feed/update/urn:li:activity:7428949660557484032/\"\u003ein einem LinkedIn-Post\u003c/a\u003e auf seine ersten Wochen bei ALDI DX zurück. Als Teil seines Onboardings verbrachte er zwei Wochen in einer Filiale, um dort wie alle anderen Mitarbeitenden zu arbeiten: Regale einräumen, Kasse bedienen, Sonderfälle wie defekte Gefriergeräte oder Ladendiebstahl bewältigen. Seine Freunde in anderen IT-Unternehmen fragten, warum irgendjemand mehr als einen Tag damit verbringen würde. Seine Antwort: ein Tag lehrt einen die grundlegenden Prozesse. Zwei Wochen lehren einen die Randfälle, das informelle Wissen, das Kolleg:innen untereinander teilen, und vor allem, wie viel Arbeit dahintersteckt, einen einzigen Joghurt oder eine Gurke zu verkaufen. Nach sieben Jahren, sagt er, kann er Entscheidungen immer noch auf das zurückführen, was er in dieser Filiale gelernt hat.\u003c/p\u003e\n\n\u003cp\u003eDas ist keine Empathie. Empathie setzt eine Distanz voraus. Was ALDI DX in ihr Onboarding eingebaut hat, ist direkter: Wissen das durch das Dabei-Sein und Selbst-Erleben entsteht. Man weiß, was es bedeutet, wenn der Etikettendrucker klemmt, weil er bei einem selbst geklemmt hat. Man hat die Kassiererin erlebt, den Regaleinräumer, die Filialleiterin, die um 6 Uhr morgens die Bestellung prüft. Man hat am eigenen Leib erfahren, was es bedeutet, wenn die Software einen Sonderfall nicht kennt und man den Workaround selbst improvisieren muss.\u003c/p\u003e\n\n\u003cp\u003eNicht jedes Unternehmen kann oder will seine IT-Mitarbeiter:innen zwei Wochen in die Filiale oder einen vergleichbaren Raum schicken. Aber das Prinzip dahinter lässt sich auch in abgeschwächter Form anwenden. Ethnografische Feldforschung – und ihre leichter zugängliche Variante Contextual Inquiry – setzt nicht voraus, dass man selbst die Arbeit tut. Es reicht, dabei zu sein. Die Forschenden beobachten im echten Kontext, stellen Fragen, während die Arbeit passiert, sehen die Workarounds, die niemand dokumentiert, und die Randfälle, die in keinem Interview auftauchen. Jared M. Spool nennt das Prinzip \u003ca href=\"https://articles.centercentre.com/user_exposure_hours/\"\u003eexposure hours\u003c/a\u003e: die systematische, regelmäßige Präsenz bei echten Nutzenden in echten Situationen.\u003c/p\u003e\n\n\u003cp\u003eDie Hierarchie ist also ungefähr diese: selbst die Arbeit tun ist am stärksten, weil man Akteur ist und nicht Beobachterin. Dabei sein und beobachten ist die nächstbeste Variante. Man ist im Kontext, sieht was wirklich passiert. Regelmäßige Präsenz ohne formellen Rahmen ist leichter zu organisieren und hält das Gespür lebendig. Darauf folgen kurze Interviews mit Nutzenden, wie von Torres beschrieben. Und dann, weit abgeschlagen: strukturierte Interviews und A/B-Tests. Experimentierkultur operiert zu oft ausschließlich auf dieser letzten Stufe und hält die Distanz zwischen den Menschen, die Software bauen, und den Menschen, deren Arbeitsalltag davon abhängt, strukturell aufrecht. Die Nutzenden sind eine Quelle von Verhaltenssignalen, kein Mensch mit einer Aufgabe.\u003c/p\u003e\n\n\u003ch3 id=\"noch-mehr-geschwindigkeit\"\u003eNoch mehr Geschwindigkeit\u003c/h3\u003e\n\n\u003cp\u003eEs gibt noch eine kognitive Dimension die in dieser Debatte selten auftaucht. \u003ca href=\"https://de.wikipedia.org/wiki/ISO_9241#ISO_9241-110_Interaktionsprinzipien\"\u003eISO 9241–110\u003c/a\u003e, der internationale Standard für Interaktionsgestaltung, nennt Erwartungskonformität als eines von sieben Grundprinzipien. Ein System, das agentisch beschleunigt dauerhaft Experimente an der eigenen Oberfläche durchführt, ist strukturell nicht in der Lage, diesen Anspruch zu erfüllen. Nutzende bauen mentale Modelle von Software durch wiederholte Nutzung auf. Jedes Experiment, das etwas verändert, setzt einen Teil dieses Modells zurück. Die kognitive Last, die das erzeugt, ist real, aber in den Metriken, die den Experimenterfolg bewerten, in der Regel nicht sichtbar. Hinzu kommt: je höher die Experimentierfrequenz, desto mehr Disziplin braucht es, um gescheiterte Experimente aufzuräumen, also tote Code-Pfade, verwaiste Feature Flags, UI-Elemente, die zu einer Variante gehörten, die verloren hat.\u003c/p\u003e\n\n\u003cp\u003eAgentische Entwicklung macht das dringlicher. Wenn Experimentierkultur schon ein fragwürdiger Fit für die meisten Enterprise-Kontexte war, verbessern Tools, die Features schneller generieren und die Kosten für mehr Experimente senken, den Mismatch nicht, sondern verstärken ihn noch. BMAD verspricht Requirements-Discovery in Stunden, indem ein Agent die Menschen befragt, die Zugang zum Tool haben. Aber das Wissen, das in komplexen Domänen am meisten zählt, ist implizit, sozial verteilt und durch strukturierte Interviews nicht zugänglich. Die Kollegin die die Regale einräumt wird nicht in diesem Interview sitzen. Ihr Wissen wird nicht in der Spezifikation auftauchen.\u003c/p\u003e\n\n\u003cp\u003eDie Frage ist, was man verstehen muss, bevor Experimentieren sinnvoll wird, und ob der aktuelle Druck zur Geschwindigkeit dieses Verständnis ermöglicht oder strukturell verhindert. Nutzende können kein stabiles Verhältnis zu einer Software aufbauen, die sich ununterbrochen verändert. Manchmal ist das Klügste was man tun kann nichts zu ändern.\u003c/p\u003e\n\n\u003cfoot-notes class=\"footnotes\"\u003e\n\n\u003col class=\"footnotes__list\"\u003e\n\n\u003cli id=\"fn:1\"\u003e\n\u003cp\u003eMelissa Perri: Escaping the Build Trap: How Effective Product Management Creates Real Value, O’Reilly Media, 2018 \u003ca href=\"https://www.innoq.com/de/blog/2026/06/faster-is-not-better/#fnref:1\" title=\"zurück zum Text\" class=\"reversefootnote\"\u003e ↩︎\u003c/a\u003e\u003c/p\u003e\n\u003c/li\u003e\n\n\u003cli id=\"fn:2\"\u003e\n\u003cp\u003eBaldur Bjarnason: Out of the Software Crisis, 2023 \u003ca href=\"https://www.innoq.com/de/blog/2026/06/faster-is-not-better/#fnref:2\" title=\"zurück zum Text\" class=\"reversefootnote\"\u003e ↩︎\u003c/a\u003e\u003c/p\u003e\n\u003c/li\u003e\n\n\u003cli id=\"fn:3\"\u003e\n\u003cp\u003eTeresa Torres: Continuous Discovery Habits, Product Talk LLC, 2021 \u003ca href=\"https://www.innoq.com/de/blog/2026/06/faster-is-not-better/#fnref:3\" title=\"zurück zum Text\" class=\"reversefootnote\"\u003e ↩︎\u003c/a\u003e\u003c/p\u003e\n\u003c/li\u003e\n\n\u003cli id=\"fn:4\"\u003e\n\u003cp\u003eW. Edwards Deming: Out of the Crisis, MIT Press, 1982 \u003ca href=\"https://www.innoq.com/de/blog/2026/06/faster-is-not-better/#fnref:4\" title=\"zurück zum Text\" class=\"reversefootnote\"\u003e ↩︎\u003c/a\u003e\u003c/p\u003e\n\u003c/li\u003e\n\n\u003c/ol\u003e\n\u003c/foot-notes\u003e\n\u003c/body\u003e\u003c/html\u003e\n","image":"https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2000/v1/uploads-production/nz9l0lypcc5h43dtl190bxopjbpu?_a=BACMTiAE"},{"id":"https://www.innoq.com/de/blog/2026/06/openproject-besser-als-jira/","url":"https://www.innoq.com/de/blog/2026/06/openproject-besser-als-jira/","date_published":"2026-06-07T00:00:00.000+00:00","date_modified":"2026-06-09T15:55:34.078+02:00","author":[{"name":"Holger Kraus","url":"https://www.innoq.com/ch/staff/holger-kraus/"}],"content_html":"\u003c!DOCTYPE html PUBLIC \"-//W3C//DTD HTML 4.0 Transitional//EN\" \"http://www.w3.org/TR/REC-html40/loose.dtd\"\u003e\n\u003chtml\u003e\u003cbody\u003e\n\u003cp\u003e\u003cem\u003eInspiriert vom \u003ca href=\"https://di.day/de\"\u003eDigital Independence Day\u003c/a\u003e, der zu Rezepten für digitale Souveränität aufruft, teilen wir hier regelmäßig eigene Lösungsansätze zu Themen, die unsere Kunden bewegen – ab sofort jeden ersten Sonntag im Monat.\u003c/em\u003e\u003c/p\u003e\n\n\u003cp\u003e\u003cem\u003e\u003cstrong\u003eUpdate:\u003c/strong\u003e Das OpenProject-Team hat uns daraufhin gewiesen, dass die Action-Boards seit Version 17.3. jetzt schon in der Community-Edition enthalten sind. Das hatte ich leider übersehen. Ich bewerte das als sehr positive Nachricht, weil es Teams ermöglicht, OpenProject im agilen Alltag über einen längeren Zeitraum im produktiven Einsatz auszuprobieren und sorgfältig zu prüfen.\u003c/em\u003e\u003c/p\u003e\n\n\u003cp\u003eIch habe mir einige Wochen Zeit genommen, um OpenProject gründlich zu testen. Dafür entwarf ich Beispielszenarien, mit denen ich die Funktionen der Software zeige. In Anlehnung an den Jira-Artikel meines Kollegen gehe ich später auch darauf ein, wie ich OpenProject in Verbindung mit einem eigenen KI-Modell nutze.\u003c/p\u003e\n\n\u003cp\u003eDer Artikel ist lang geworden. Ich verstehe deshalb gut, wenn Sie ihn eventuell nicht komplett lesen möchten. Da aber nicht alle Teile für alle gleich interessant sind, wollte ich nichts streichen. Vielleicht wäre genau dieser Abschnitt für Sie wichtig gewesen.\nSuchen Sie sich deshalb gern die Themen heraus, die Sie interessieren. Im Fazit am Ende des Artikels fasse ich meine wichtigsten Erkenntnisse noch einmal zusammen. Wenn Sie den gesamten Artikel lesen, freue ich mich sehr — und danke Ihnen für Ihre Aufmerksamkeit.\u003c/p\u003e\n\n\u003cp\u003eIm Rahmen unserer Artikelserie zum Digital Independence Day wollte ich eine datensouveräne Alternative zu Jira finden. Dieser Artikel vergleicht OpenProject und Jira nicht bis ins Detail und arbeitet keine einzelnen Funktionen ab. Stattdessen beantwortet er eine praktische Frage:\u003c/p\u003e\n\n\u003cblockquote\u003e\n\u003cp\u003eWenn ich heute Jira ablösen möchte – ist OpenProject dafür eine brauchbare Alternative?\u003c/p\u003e\n\u003c/blockquote\u003e\n\n\u003cp\u003eBeim Kennenlernen von OpenProject stellte ich schnell fest, dass die Software nicht nur mithalten kann. Der Gedanke lag nahe, dass sie in manchen Bereichen sogar besser sein könnte als Jira. Aber zunächst erläutere ich die Bewertungskriterien, die ich angelegt habe.\u003c/p\u003e\n\n\u003ch3 id=\"unterschiedliche-perspektiven-auf-jira\"\u003eUnterschiedliche Perspektiven auf Jira\u003c/h3\u003e\n\n\u003cp\u003eDie möglichen Perspektiven auf Jira sind vielfältig, da\njede Nutzergruppe unterschiedliche Ziele mit der Nutzung von Jira verbindet.\nGrundsätzlich habe ich mir zwei Perspektiven genauer angeschaut:\u003c/p\u003e\n\n\u003cul\u003e\n\u003cli\u003eDie Perspektive eines agilen Entwicklungsteams mit den Rollen Entwickler:innen, Product Owner, Scrum Master usw.\u003c/li\u003e\n\u003cli\u003eDie Perspektive eines:einer Projektleiter:in. Diese Perspektive repräsentiert für mich die Perspektive der Organisation.\u003c/li\u003e\n\u003c/ul\u003e\n\n\u003ch4 id=\"die-perspektive-eines-agilen-entwicklungsteams\"\u003eDie Perspektive eines agilen Entwicklungsteams\u003c/h4\u003e\n\n\u003cp\u003eIch selbst habe Jira viel in unterschiedlichen Kundenprojekten als Entwickler in agilen Software-Entwicklungsteams genutzt. Jira hat meine Erwartungen bezüglich einer Projektmanagement-Software sehr stark geprägt. Das habe ich immer dann gemerkt, wenn ich zeitweise in Projekten etwas anderes verwenden musste.\nAus der agilen Perspektive sind mir deshalb folgende Dinge, die Jira mitbringt, ganz besonders wichtig:\u003c/p\u003e\n\n\u003cp\u003e\u003cstrong\u003eEs gibt einen Planungsmodus:\u003c/strong\u003e Wenn mein Projektteam nach Scrum arbeitet, dann möchte ich eine klare Unterscheidung von Tickets, die im Sprint liegen und denen, die noch im Backlog sind. Wenn Projektmanagement-Tools diese klare Unterscheidung nicht machen, dann ist das Backlog eine Spalte im Board. Das führt zu einer großen Unübersichtlichkeit, weil im Board dann einfach viel zu viele Tickets liegen. Jira trennt ja den Bereich des Backlogs sehr deutlich vom aktuellen Sprint, d. h., während eines Plannings kann ich Tickets im Backlog auswählen und in den aktuellen Sprint ziehen. So einen Planungsmodus wünsche ich mir auch für jede akzeptable Jira-Alternative.\u003c/p\u003e\n\n\u003cp\u003e\u003cstrong\u003eAufgaben-Typen unterschiedlicher Hierarchiestufen:\u003c/strong\u003e Manche Aufgaben sind zu groß für einen Sprint. Deshalb möchte ich sie in Unteraufgaben aufteilen und getrennt bearbeiten. In Jira geschieht das meist über Epics. Ein Epic bündelt mehrere User Stories und hilft dabei, User Stories inhaltlich durch einen gemeinsamen Rahmen miteinander zu verbinden. Wie wichtig das ist, merkt man, wenn einem das Feature nicht mehr zur Verfügung steht.\u003c/p\u003e\n\n\u003cp\u003e\u003cstrong\u003eEs werden unterschiedliche agile Vorgehensweisen unterstützt:\u003c/strong\u003e Ich möchte nicht, dass mein Projektmanagement-Tool bestimmt, nach welcher agilen Vorgehensweise ich arbeiten kann, d.h. ich erwarte, dass zumindest Scrum und Kanban unterstützt werden. Unterstützung von Scrum ist für mich dann gegeben, wenn der oben genannte Planungsmodus Backlog und Sprint klar voneinander trennt. Um Kanban vernünftig zu unterstützen, wünsche ich mir, dass ich Limits für die jeweiligen Spalten definieren kann. Das bedeutet, dass ich eine visuelle Rückmeldung darüber bekomme, ob ich mein Work-in-Progress-Limit in einer Spalte überschritten habe.\u003c/p\u003e\n\n\u003ch4 id=\"kriterien-fur-die-organisation-projektleitung\"\u003eKriterien für die Organisation/ Projektleitung\u003c/h4\u003e\n\n\u003cp\u003eIch selbst habe Jira primär aus Entwicklersicht kennengelernt. Ich habe allerdings in Kundenprojekten auch gelernt, dass es Features in Jira gibt, die ich für meinen Entwickler-Alltag nicht benötigt habe, bei denen ich aber verstehen kann, dass sie für eine Organisation wichtig sind. Ich habe mir Jira Alternativen deshalb auch unter der Perspektive angeschaut, ob sie den von mir wahrgenommenen Bedürfnissen einer Organisation entsprechen.\u003c/p\u003e\n\n\u003cp\u003eFolgende Bedürfnisse habe ich dabei wahrgenommen:\u003c/p\u003e\n\n\u003cp\u003e\u003cstrong\u003eDarstellung von Projekten unterschiedlicher Hierarchiestufen:\u003c/strong\u003e Auf Ebene des Top-Managements entstehen oft strategische Initiativen, die mehrere Unternehmensbereiche umfassen können. Das bedeutet, dass auch mehrere Unternehmensteile bzw. unterschiedliche Teilprojekte an der Erreichung dieser strategischen Ziele mitwirken. Das bedingt fast zwangsläufig, dass ich eine Organisations-Hierarchie benötige. Es muss eine Steuerungsebene geben, auf der die Aktivitäten unterschiedlicher Unternehmensbereiche, Projekte zusammenlaufen und gesteuert bzw. koordiniert werden können.\u003c/p\u003e\n\n\u003cp\u003eDie eigentliche Umsetzungsarbeit findet dabei in spezialisierten Projekten statt, die möglichst wenig voneinander wissen müssen.\nIdealerweise kann ich meine Projekthierarchie auch in der von mir genutzten Projektmanagement-Software abbilden. Dabei möchte ich in der Lage sein, auf der obersten Ebene Aufgaben anzulegen. Diese möchte ich dann in Unteraufgaben zerlegen und unterschiedlichen Teilprojekten zuweisen können.\u003c/p\u003e\n\n\u003cp\u003e\u003cstrong\u003eÜberblick über den Gesamt-Projektstatus erhalten:\u003c/strong\u003e Auch wenn die Arbeit über mehrere Teilprojekte verteilt ist, möchte ich mir als Projektleiter:in leicht einen Überblick über den Status des Gesamtprojektes verschaffen können. Dabei gehe ich davon aus, dass es auf dieser Ebene wirklich nur darum geht, den Gesamtstatus zu erfassen und nicht in einer Wasserfall-Art das Projekt zu steuern.\u003c/p\u003e\n\n\u003cp\u003e\u003cstrong\u003eRechtliche Rahmenbedingungen umsetzen und digitale Souveränität unterstützen:\u003c/strong\u003e Dieser Punkt ist Anlass dieses Artikels. Als Unternehmen möchte ich auf rechtlich stabilem Fundament stehen. In Deutschland bedeutet das, dass ich alle Regelungen der DSGVO umsetze. Strategisch möchte ich mich als Unternehmen aber auch nicht zu stark von einem Anbieter abhängig machen. Das bedeutet, dass ich abschätzen kann, ob die Einführung eines neuen Projektmanagement-Tools mich in eine Sackgasse führt, aus der ich vielleicht nicht wieder leicht herauskomme.\u003c/p\u003e\n\n\u003cp\u003eÜber diese Kriterien habe ich mir im Vorfeld der Begutachtung unterschiedlicher Tools Gedanken gemacht. Kriterien sind aber auch durch das Kennenlernen spezifischer Tools dazu gekommen. Das betrifft vor allem die Organisationsperspektive. Die Entwicklerperspektive wurde primär durch meine eigene praktische Arbeit geformt.\u003c/p\u003e\n\n\u003ch3 id=\"warum-habe-ich-mich-auf-openproject-fokussiert\"\u003eWarum habe ich mich auf OpenProject fokussiert?\u003c/h3\u003e\n\n\u003cp\u003eIch habe mich auf die Suche nach einer Jira-Alternative gemacht, in dem ich zunächst online recherchiert habe. Die Alternativen habe ich mir angeschaut und mit meinem Kriterien-Katalog abgeglichen. OpenProject hat mich sofort angesprochen. Deshalb habe ich mich darauf konzentriert und andere Lösungen nur oberflächlich geprüft. Wer mehr über die anderen Kandidaten wissen will, findet dazu Erläuterungen im Anhang zu diesem Artikel.\u003c/p\u003e\n\n\u003cp\u003eWenn man die OpenProject-Website besucht, fallen drei Produkteigenschaften auf:\u003c/p\u003e\n\n\u003cul\u003e\n\u003cli\u003eDatensouveränität und Datensicherheit\u003c/li\u003e\n\u003cli\u003eUnterstützung für Klassisches, Agiles und hybrides Projektmanagement\u003c/li\u003e\n\u003cli\u003eStarke Referenzen: Siemens, Deutsche Bahn, Fraunhofer, Greenpeace, The Linux Foundation, AMG und weitere bekannte Kunden.\u003c/li\u003e\n\u003c/ul\u003e\n\n\u003ch4 id=\"datensouveranitat\"\u003eDatensouveränität\u003c/h4\u003e\n\n\u003cp\u003eOpenProject ist Open Source. Ich kann es selbst hosten oder eine Cloud-Variante von OpenProject wählen.\nBesonders attraktiv bei der Cloud-Variante: Ich entscheide selbst, bei welchem Cloud-Provider meine Instanz läuft. Zur Auswahl stehen AWS Europe und Scaleway, ein französisches Angebot. Auch der Preis überzeugt: Die Cloud-Lizenz kostet genauso viel wie die Lizenz für den Selbstbetrieb, d. h., die Entscheidung für die Cloudvariante ist nicht mit Mehrkosten verbunden, spart aber Administrationskosten.\u003c/p\u003e\n\n\u003cp\u003eIch vergleiche die Cloud-Variante und On-Premise-Variante hier nicht im Detail. Wichtig ist: OpenProject bietet mehrere Optionen. Das stärkt die Datensouveränität, weil ich selbst festlege, wie viel Kontrolle ich über Betrieb und Daten behalten will.\u003c/p\u003e\n\n\u003ch4 id=\"klassisches-agiles-und-hybrides-projektmanagement\"\u003eKlassisches, Agiles und Hybrides Projektmanagement\u003c/h4\u003e\n\n\u003cp\u003eOpenProject verbindet die Perspektiven von Entwicklungsteam und Organisation. Die Software unterstützt verschiedene Formen des Projektmanagements. Teams wählen ihre bevorzugte agile Methode und arbeiten damit eigenständig. Das Management kann den Rahmen der Projekte gleichzeitig klassisch nach dem Wasserfallmodell planen und den Überblick über das Gesamtprojekt behalten. Das schauen wir uns später genauer an.\u003c/p\u003e\n\n\u003ch4 id=\"namenhafte-referenzkunden-und-stakeholder\"\u003eNamenhafte Referenzkunden und Stakeholder\u003c/h4\u003e\n\n\u003cp\u003eDie Referenzkunden zeigen: Auch sehr große Unternehmen haben sich für OpenProject entschieden. Darüber hinaus ist OpenProject ein Modul von openDesk. openDesk ist eine souveräne Office- und Kollaborationssuite für die öffentliche Verwaltung. ZenDiS stellt sie zusammen und bereit. ZenDiS ist das Zentrum für Digitale Souveränität der Öffentlichen Verwaltung. Alleinige Gesellschafterin ist die Bundesrepublik Deutschland.\nDie Referenzen und die Verbindung zu ZenDiS zeigen: Viele namhafte Stakeholder haben ein Interesse daran, OpenProject dauerhaft einzusetzen. Deshalb halte ich die Entscheidung für OpenProject für eine vergleichsweise sichere Investition. Eine ausführliche Kundenliste gibt es \u003ca href=\"https://www.openproject.org/customers/\"\u003ehier\u003c/a\u003e.\u003c/p\u003e\n\n\u003ch3 id=\"openproject-im-detail\"\u003eOpenProject im Detail\u003c/h3\u003e\n\n\u003cp\u003eNach diesem ersten Überblick schauen wir uns jetzt gemeinsam OpenProject im Detail an.\u003c/p\u003e\n\n\u003ch4 id=\"lizenzmodell\"\u003eLizenzmodell\u003c/h4\u003e\n\n\u003cp\u003eWer sich einen Überblick über OpenProject verschaffen möchte, kann das in einer 14-tägigen Probephase tun. Die ist kostenlos und enthält alle Enterprise-Features. Es gibt unterschiedliche Enterprise-Pakete:\u003c/p\u003e\n\n\u003cul\u003e\n\u003cli\u003eBasic\u003c/li\u003e\n\u003cli\u003eProfessional\u003c/li\u003e\n\u003cli\u003ePremium\u003c/li\u003e\n\u003cli\u003eCorporate\u003c/li\u003e\n\u003c/ul\u003e\n\n\u003cp\u003eDie Tarife unterscheiden sich in drei Punkten:\u003c/p\u003e\n\n\u003cul\u003e\n\u003cli\u003efreigeschaltete Funktionen\u003c/li\u003e\n\u003cli\u003eMindestanzahl Benutzer:innen\u003c/li\u003e\n\u003cli\u003eSupportleistungen.\u003c/li\u003e\n\u003c/ul\u003e\n\n\u003cp\u003eDie Community Edition steht unter der GNU General Public License v3. Damit bleibt OpenProject dauerhaft Open Source.\u003c/p\u003e\n\n\u003ch4 id=\"wichtige-enterprise-funktionen\"\u003eWichtige Enterprise-Funktionen\u003c/h4\u003e\n\n\u003cp\u003eEnterprise-Funktionen werden durch ein Enterprise-Token freigeschaltet. Administrator:innen erhalten ihn mit dem Kauf einer Lizenz. OpenProject prüft den Token kryptografisch und aktiviert danach die gebuchten Funktionen.\u003c/p\u003e\n\n\u003cp\u003eMit der Community Edition kommt man weit — solange man keine ausgeprägte Unterstützung für agiles Arbeiten braucht. In der Praxis wünschen sich viele Teams jedoch die agilen Action Boards. Sie gehören zu allen Enterprise-Tarifen. Unternehmen benötigen oft zusätzlich Single Sign-on. Die Unterstützung für OpenID Connect bzw. SAML/SCIM gibt es ab dem Professional-Tarif.\u003c/p\u003e\n\n\u003cp\u003eDie Tarifübersicht auf der OpenProject-Website überzeugt mich allerdings nicht. Es fällt schwer zu erkennen, welcher Tarif welche Funktionen enthält. Die Action Boards fehlen zum Beispiel in der Vergleichstabelle. Gut gelöst ist dagegen der Hinweis innerhalb der Community Edition: Nicht verfügbare Funktionen zeigen direkt an, welcher Tarif sie freischaltet.\u003c/p\u003e\n\n\u003cp\u003eFür den professionellen Einsatz braucht man aus meiner Sicht meist eine Enterprise-Lizenz.\u003c/p\u003e\n\n\u003ch4 id=\"unterschiede-zwischen-cloud-und-on-premise\"\u003eUnterschiede zwischen Cloud und On-Premise\u003c/h4\u003e\n\n\u003cp\u003eDie Tarife für Cloud und On-Premise bieten grundsätzlich dieselben Funktionen und unterscheiden sich nicht im Preis. Unterschiede gibt es vor allem bei der Mindestanzahl der User. Den Basic-Enterprise-Tarif erhält man in der Cloud bereits ab fünf User. On-Premise muss man dagegen mindestens 25 Benutzerlizenzen kaufen. Zusätzlich bietet OpenProject ein kostenpflichtiges Modul für das Management von Bauprojekten an. Dieses Zusatzmodul berücksichtige ich in diesem Artikel nicht.\u003c/p\u003e\n\n\u003ch4 id=\"keine-marketplace-apps\"\u003eKeine Marketplace Apps\u003c/h4\u003e\n\n\u003cp\u003ePositiv finde ich, dass alle Funktionen Teil des Kernprodukts sind. Bei Jira schaltet man zusätzliche Funktionen über Marketplace-Apps frei. Das verursacht weitere Kosten und wirft oft Datenschutzfragen auf, weil Drittanbieter auf Jira-Daten zugreifen. Deshalb gehe ich davon aus, dass OpenProject langfristig besser kalkulierbare Lizenzkosten bietet.\u003c/p\u003e\n\n\u003ch4 id=\"kostenvergleich\"\u003eKostenvergleich\u003c/h4\u003e\n\n\u003cp\u003eDer Jira-Premium-Tarif kostet 14,54 US-Dollar pro User und Monat, also etwa 13,60 Euro. Der Professional-Tarif von OpenProject kostet 10,95 Euro pro User und Monat. Diese Preise gelten für die Cloud-Versionen. Noch deutlicher wird der Unterschied bei Jira Data Center. Dort liegt die Mindestanzahl bei 500 Usern. Für diesen Artikel gehe ich von etwa 100 Usern aus. Das entspricht den Projektgrößen, in denen ich häufig gearbeitet habe. Unter diesen Voraussetzungen wirkt Jira für mich deutlich teurer als OpenProject. Wer die Lizenzkosten für die eigene Organisation berechnen möchte, findet die Preise \u003ca href=\"https://www.openproject.org/de/preise\"\u003ehier\u003c/a\u003e.\u003c/p\u003e\n\n\u003ch3 id=\"hybrides-projektmanagement-in-openproject\"\u003eHybrides Projektmanagement in OpenProject\u003c/h3\u003e\n\n\u003cp\u003eIch habe hybrides Projektmanagement erst durch die Beschäftigung mit OpenProject kennengelernt. Deshalb möchte ich zunächst erklären, was das ist.\u003c/p\u003e\n\n\u003cp\u003e\u003cstrong\u003eWas ist hybrides Projektmanagement?\u003c/strong\u003e Hybrides Projektmanagement ruht auf zwei Säulen:\u003c/p\u003e\n\n\u003cul\u003e\n\u003cli\u003eagil\u003c/li\u003e\n\u003cli\u003eklassisch, d.h Wasserfallmodell\u003c/li\u003e\n\u003c/ul\u003e\n\n\u003cp\u003eDabei trennt man klar zwischen der strategischen und der operativen Projektmanagement-Ebene.\u003c/p\u003e\n\n\u003cp\u003e\u003cstrong\u003ePlanung auf der strategischen Projektmanagement-Ebene:\u003c/strong\u003e Die grobe Rahmenplanung erfolgt klassisch, d.h. auf einer hohen Managementebene wird definiert, was im Rahmen eines großen, teamübergreifenden Projektes geliefert werden soll. Es werden grobe Aufgabenpakete inkl. ihrer Deadlines definiert. Das setzt einen klaren Rahmen und eine klare Erwartungshaltung, an dem sich die Teams orientieren können.\u003c/p\u003e\n\n\u003cp\u003e\u003cstrong\u003ePlanung auf der operativen Team-Ebene:\u003c/strong\u003e Die einzelnen Entwicklungs-Teams bekommen von der strategischen Projektmanagement-Ebene die definierten groben Aufgabenpakete zugewiesen und können diese nun in umsetzbare Aufgabenprojekte herunterbrechen. Auf dieser Basis können die Teams die Umsetzung dann agil planen, d.h. sie bestimmen selbst was sie in welchem Sprint wie umsetzen. Da sie die Erwartungshaltung des Managements kennen, können sie das in ihrer eigenen Planung berücksichtigen.\u003c/p\u003e\n\n\u003cp\u003e\u003cstrong\u003eÜberwachung der Ziele auf der operativen Team-Ebene:\u003c/strong\u003e Das Team hat sich selbst die Sprintziele im Sprint-Planning gesetzt und behält die im Rahmen ihrer Dailies und täglichen Arbeit im Blick.\u003c/p\u003e\n\n\u003cp\u003e\u003cstrong\u003eÜberwachung der Ziele auf der strategischen Projektmanagement-Ebene:\u003c/strong\u003e Da die Projektmanagement-Ebene Deadlines auf der Basis grober Aufgabenblöcke gesetzt hat, ist es interessiert über den Fortschritt auf der Basis dieser Aufgabenblöcke informiert zu werden. Im schlechtesten Fall müssen die einzelnen Entwicklungsteam Berichte verfassen, um über ihren Fortschritt zu berichten. Im Idealfall unterstützt mich mein Projekt-Management-Tool dabei, die Aktivitäten auf die Aufgabenblöcke auf Projektmanagement-Ebene zu projizieren, so dass in meinem Team dadurch kein zusätzlicher Aufwand verursacht wird.\u003c/p\u003e\n\n\u003cp\u003e\u003cstrong\u003eWie unterstützt OpenProject hybrides Project-Management?\u003c/strong\u003e Ich zeige Ihnen Schritt für Schritt, wie Sie mit OpenProject ein hybrides Projektmanagement aufsetzen. Dazu nutze ich typische Szenarien. Ihre eigenen Anforderungen können davon abweichen. Trotzdem sehen Sie dadurch, ob und wie Sie Ihre eigenen Szenarien mit OpenProject umsetzen können.\u003c/p\u003e\n\n\u003ch3 id=\"openproject-kann-sehr-flexibel-unterschiedliche-hierarchien-von-projekten-und-arbeitspaketen-abbilden\"\u003eOpenProject kann sehr flexibel unterschiedliche Hierarchien von Projekten und Arbeitspaketen abbilden\u003c/h3\u003e\n\n\u003cp\u003eTheoretisch können Sie Projekte und Arbeitspakete in OpenProject beliebig tief verschachteln. Trotzdem sollten Sie festlegen, welche Struktur in Ihrem Kontext sinnvoll ist. Für mein Beispiel nutze ich ein Projekt mit zwei Unterprojekten. Die Struktur bleibt übersichtlich und zeigt trotzdem die wichtigsten Funktionen. Das oberste Projekt steht für die strategische Projektplanung. Die beiden Unterprojekte bilden die operative Team-Ebene ab.\u003c/p\u003e\n\n\u003cp\u003eBei Bedarf können Sie die Unterprojekte weiter unterteilen und zusätzliche Ebenen anlegen.\u003c/p\u003e\n\n\u003cfigure\u003e\r\n\u003cimg alt=\"UI screenshot titled “Großes Enterprise-Projekt” with Overview/Dashboard tabs, description, and subitems “Unterprojekt2” and “Unterprojekt1”.\" style=\"width: 50%; height: auto;\" loading=\"lazy\" srcset=\"https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_400/v1/uploads-production/krcylnj2sgdzsbacrpyaj2kgpkzl?_a=BACMTiAE 400w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_800/v1/uploads-production/krcylnj2sgdzsbacrpyaj2kgpkzl?_a=BACMTiAE 800w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_1024/v1/uploads-production/krcylnj2sgdzsbacrpyaj2kgpkzl?_a=BACMTiAE 1024w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_1200/v1/uploads-production/krcylnj2sgdzsbacrpyaj2kgpkzl?_a=BACMTiAE 1200w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_1600/v1/uploads-production/krcylnj2sgdzsbacrpyaj2kgpkzl?_a=BACMTiAE 1600w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2048/v1/uploads-production/krcylnj2sgdzsbacrpyaj2kgpkzl?_a=BACMTiAE 2048w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2300/v1/uploads-production/krcylnj2sgdzsbacrpyaj2kgpkzl?_a=BACMTiAE 2300w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2600/v1/uploads-production/krcylnj2sgdzsbacrpyaj2kgpkzl?_a=BACMTiAE 2600w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2800/v1/uploads-production/krcylnj2sgdzsbacrpyaj2kgpkzl?_a=BACMTiAE 2800w\" sizes=\"(min-width: 1400px) 1024px, 90vw\"\u003e\r\n\r\n\u003cfigcaption\u003eGroßes Enterprise-Projekt\u003c/figcaption\u003e\u003c/figure\u003e\r\n\n\u003ch4 id=\"planung-einer-initiative\"\u003ePlanung einer Initiative\u003c/h4\u003e\n\n\u003cp\u003eIn meinem Beispiel lege ich jetzt eine Projektübergreifende Initiative auf Ebene der Strategischen Projektplanung an. Dann lege ich zwei Epics für die Unterprojekte an. Zusätzlich lege ich noch einen Meilenstein an, der mir später helfen soll, eine wichtige Deadline für das Gesamtprojekt im Blick zu halten.\u003c/p\u003e\n\n\u003cfigure\u003e\r\n\u003cimg alt=\"Work package list with items “Eine Initiative für alle” (SUMMARY TASK) and two EPICs, status New, priority Normal.\" loading=\"lazy\" srcset=\"https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_400/v1/uploads-production/wkcyvk0lon1ehx36boihlhp0k7ir?_a=BACMTiAE 400w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_800/v1/uploads-production/wkcyvk0lon1ehx36boihlhp0k7ir?_a=BACMTiAE 800w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_1024/v1/uploads-production/wkcyvk0lon1ehx36boihlhp0k7ir?_a=BACMTiAE 1024w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_1200/v1/uploads-production/wkcyvk0lon1ehx36boihlhp0k7ir?_a=BACMTiAE 1200w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_1600/v1/uploads-production/wkcyvk0lon1ehx36boihlhp0k7ir?_a=BACMTiAE 1600w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2048/v1/uploads-production/wkcyvk0lon1ehx36boihlhp0k7ir?_a=BACMTiAE 2048w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2300/v1/uploads-production/wkcyvk0lon1ehx36boihlhp0k7ir?_a=BACMTiAE 2300w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2600/v1/uploads-production/wkcyvk0lon1ehx36boihlhp0k7ir?_a=BACMTiAE 2600w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2800/v1/uploads-production/wkcyvk0lon1ehx36boihlhp0k7ir?_a=BACMTiAE 2800w\" sizes=\"(min-width: 1400px) 1024px, 90vw\"\u003e\r\n\r\n\u003cfigcaption\u003eEine teamübergreifende Initiative, heruntergebrochen in zwei teamspezifische Epics\u003c/figcaption\u003e\u003c/figure\u003e\r\n\n\u003cp\u003eDie Epics weise ich dann den Unterprojekten zu. Der folgende Screenshot zeigt jetzt die Arbeitspakete-Ansicht in Unterprojekt 1. Hier habe ich das Epic schon in 5 User Stories herunter gebrochen.\u003c/p\u003e\n\n\u003cfigure\u003e\r\n\u003cimg alt=\"Work item list showing “Eine Initiative für alle”, an epic, and “User Story 1–5”; Type and Status columns show “New”.\" loading=\"lazy\" srcset=\"https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_400/v1/uploads-production/le7qnsudx19cky39pw212qu5ttlw?_a=BACMTiAE 400w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_800/v1/uploads-production/le7qnsudx19cky39pw212qu5ttlw?_a=BACMTiAE 800w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_1024/v1/uploads-production/le7qnsudx19cky39pw212qu5ttlw?_a=BACMTiAE 1024w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_1200/v1/uploads-production/le7qnsudx19cky39pw212qu5ttlw?_a=BACMTiAE 1200w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_1600/v1/uploads-production/le7qnsudx19cky39pw212qu5ttlw?_a=BACMTiAE 1600w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2048/v1/uploads-production/le7qnsudx19cky39pw212qu5ttlw?_a=BACMTiAE 2048w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2300/v1/uploads-production/le7qnsudx19cky39pw212qu5ttlw?_a=BACMTiAE 2300w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2600/v1/uploads-production/le7qnsudx19cky39pw212qu5ttlw?_a=BACMTiAE 2600w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2800/v1/uploads-production/le7qnsudx19cky39pw212qu5ttlw?_a=BACMTiAE 2800w\" sizes=\"(min-width: 1400px) 1024px, 90vw\"\u003e\r\n\r\n\u003cfigcaption\u003eEin Epic im Unterprojekt, heruntergebrochen in unterschiedliche Stories\u003c/figcaption\u003e\u003c/figure\u003e\r\n\n\u003ch4 id=\"umsetzung-der-arbeit-in-den-projekt-teams\"\u003eUmsetzung der Arbeit in den Projekt-Teams\u003c/h4\u003e\n\n\u003cp\u003eInnerhalb des Unterprojektes kann ich den Kontext des Gesamtprojektes ausblenden und mich auf den Projektkontext meines Teams konzentrieren. Der folgende Screenshot zeigt das Board des Teams von Unterprojekt1. Wie Openproject agile Arbeit unterstützt, erläutere ich weiter unten im Detail.\u003c/p\u003e\n\n\u003cfigure\u003e\r\n\u003cimg alt=\"OpenProject board “Unser Team-Board” with columns Status New, In progress, Ready For Review, and Developed, showing user stories.\" loading=\"lazy\" srcset=\"https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_400/v1/uploads-production/r7epjnhg7w1iparkbz5pmuerszg2?_a=BACMTiAE 400w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_800/v1/uploads-production/r7epjnhg7w1iparkbz5pmuerszg2?_a=BACMTiAE 800w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_1024/v1/uploads-production/r7epjnhg7w1iparkbz5pmuerszg2?_a=BACMTiAE 1024w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_1200/v1/uploads-production/r7epjnhg7w1iparkbz5pmuerszg2?_a=BACMTiAE 1200w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_1600/v1/uploads-production/r7epjnhg7w1iparkbz5pmuerszg2?_a=BACMTiAE 1600w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2048/v1/uploads-production/r7epjnhg7w1iparkbz5pmuerszg2?_a=BACMTiAE 2048w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2300/v1/uploads-production/r7epjnhg7w1iparkbz5pmuerszg2?_a=BACMTiAE 2300w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2600/v1/uploads-production/r7epjnhg7w1iparkbz5pmuerszg2?_a=BACMTiAE 2600w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2800/v1/uploads-production/r7epjnhg7w1iparkbz5pmuerszg2?_a=BACMTiAE 2800w\" sizes=\"(min-width: 1400px) 1024px, 90vw\"\u003e\r\n\r\n\u003cfigcaption\u003eEin Sprint-Board in Unterprojekt 1\u003c/figcaption\u003e\u003c/figure\u003e\r\n\n\u003ch4 id=\"uberblick-auf-ebene-des-gesamtprojektes\"\u003eÜberblick auf Ebene des Gesamtprojektes\u003c/h4\u003e\n\n\u003cp\u003eAuf Ebene des Gesamtprojekts können Sie ein Gantt-Diagramm für das gesamte Projekt anzeigen. Die Ansicht steht auch in den Unterprojekten zur Verfügung. Da die strategische Steuerung jedoch auf Ebene des Gesamtprojekts erfolgt, konzentriere ich mich hier auf diese Ansicht.\u003c/p\u003e\n\n\u003cp\u003eDamit das Gantt-Diagramm aussagekräftig bleibt, müssen die Teams in den Unterprojekten ihre Arbeitspakete sauber pflegen. Dazu gehören vor allem Vorgänger- und Nachfolgerbeziehungen sowie die Start- und Enddaten der Arbeitspakete auf der untersten Ebene.\u003c/p\u003e\n\n\u003cp\u003eWenn Sie Arbeitspakete auf höheren Hierarchieebenen auf „Automatic Scheduling“ setzen, übernimmt OpenProject Änderungen aus den unteren Ebenen automatisch. Verschiebt sich dort ein Termin, aktualisiert sich der übergeordnete Termin ebenfalls.\u003c/p\u003e\n\n\u003cp\u003eDer Meilenstein ist hier als Nachfolger der Epics definiert. Ändert sich das Enddatum eines Epics, verschiebt OpenProject den Meilenstein automatisch mit.\u003c/p\u003e\n\n\u003cfigure\u003e\r\n\u003cimg alt=\"Gantt chart of project work items (Summary Task, Epic, User Story) across 2026–2027, ending with milestone “Product Launch”.\" loading=\"lazy\" srcset=\"https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_400/v1/uploads-production/kbfjt9p5pojcvywsngwhp60twfe5?_a=BACMTiAE 400w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_800/v1/uploads-production/kbfjt9p5pojcvywsngwhp60twfe5?_a=BACMTiAE 800w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_1024/v1/uploads-production/kbfjt9p5pojcvywsngwhp60twfe5?_a=BACMTiAE 1024w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_1200/v1/uploads-production/kbfjt9p5pojcvywsngwhp60twfe5?_a=BACMTiAE 1200w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_1600/v1/uploads-production/kbfjt9p5pojcvywsngwhp60twfe5?_a=BACMTiAE 1600w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2048/v1/uploads-production/kbfjt9p5pojcvywsngwhp60twfe5?_a=BACMTiAE 2048w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2300/v1/uploads-production/kbfjt9p5pojcvywsngwhp60twfe5?_a=BACMTiAE 2300w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2600/v1/uploads-production/kbfjt9p5pojcvywsngwhp60twfe5?_a=BACMTiAE 2600w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2800/v1/uploads-production/kbfjt9p5pojcvywsngwhp60twfe5?_a=BACMTiAE 2800w\" sizes=\"(min-width: 1400px) 1024px, 90vw\"\u003e\r\n\r\n\u003cfigcaption\u003eDas projektübergreifende Gantt-Diagramm: Der Meilenstein verschiebt sich automatisch mit den Epics\u003c/figcaption\u003e\u003c/figure\u003e\r\n\n\u003ch4 id=\"meine-bewertung-des-hybriden-projekt-managements-in-openproject\"\u003eMeine Bewertung des hybriden Projekt-Managements in OpenProject\u003c/h4\u003e\n\n\u003cp\u003eIch habe persönlich nie in Projekten gearbeitet, die erkennbar hybrid gemanagt wurden. Stattdessen habe ich erlebt, dass Teams agil arbeiteten, während das Management feste Deadlines vorgab. In solchen Szenarien hätte ein Projekt-Setup in OpenProject wie das gezeigte für mehr Transparenz und besseres Verständnis gesorgt.\u003c/p\u003e\n\n\u003cp\u003eIch kann hier nur bewerten, was ich beim Erstellen meines Beispielszenarios erlebt habe. Besonders gut gefällt mir, dass sich Hierarchien für Projekte und Arbeitspakete in OpenProject sehr flexibel anlegen lassen.\u003c/p\u003e\n\n\u003cp\u003eFür aussagekräftige Gantt-Diagramme verlässt man auf Team-Ebene allerdings schnell den Rahmen agilen Arbeitens. Die Beziehungen zwischen den Arbeitspaketen müssen die Realität abbilden. Außerdem müssen Start- und Enddaten gepflegt werden. Hier habe ich eine Funktion vermisst, die Start- und Enddaten automatisch aus dem Sprint übernimmt, dem das Arbeitspaket zugeordnet ist. Hilfreich wäre auch, laufende Sprints direkt im Gantt-Diagramm sichtbar zu machen.\u003c/p\u003e\n\n\u003cp\u003eInsgesamt überzeugt mich der Ansatz dennoch: Teams können agil arbeiten, während die Projektsteuerung den Überblick behält – ohne zusätzliche Statusberichte.\u003c/p\u003e\n\n\u003ch3 id=\"agiles-projekt-management-in-openproject\"\u003eAgiles Projekt-Management in OpenProject\u003c/h3\u003e\n\n\u003cp\u003eAgile Entwicklungsteams interessiert vor allem eine Frage: Wie unterstützt OpenProject sie im Alltag?\u003c/p\u003e\n\n\u003cp\u003eIch schaue vor allem auf Scrum und Kanban. Jira setzt ebenfalls auf diese beiden Frameworks. Zunächst geht es um Scrum. Kanban fließt punktuell ein, denn OpenProject bietet für Scrum nach meinem Eindruck mehr Funktionen als für Kanban.\u003c/p\u003e\n\n\u003ch4 id=\"wie-unterstutzt-openproject-ein-sprint-planning\"\u003eWie unterstützt OpenProject ein Sprint-Planning?\u003c/h4\u003e\n\n\u003cp\u003eTickets legt man grundsätzlich im Modul Arbeitspakete an. Dort beschreiben Teams Aufgaben, zerlegen sie in Unteraufgaben und pflegen Abhängigkeiten zwischen den Arbeitspaketen.\u003c/p\u003e\n\n\u003cp\u003eDie eigentliche Planung läuft im Modul Backlogs. OpenProject hat diesen Bereich in den vergangenen Versionen deutlich ausgebaut. Früher verwaltete das Modul vor allem generische Versionszuordnungen. Heute kennt OpenProject Sprints als klar definierte Container für Tickets. Teams vergeben für jeden Sprint ein Start- und Enddatum. Sobald ein Sprint startet, erstellt OpenProject automatisch ein Board mit allen Tickets des aktuellen Sprints. Während des Sprints zeigt das System zudem einen aktuellen Burndown-Chart an.\u003c/p\u003e\n\n\u003cp\u003eDer Screenshot zeigt den Planungsmodus von OpenProject. Links stehen alle Tickets im Backlog. Dort liegen sämtliche Arbeitspakete, die noch offen sind und keinem Sprint zugeordnet wurden. Rechts erscheinen die angelegten Sprints. In der Kopfzeile summiert OpenProject die Story Points aller enthaltenen Tickets.\u003c/p\u003e\n\n\u003cp\u003eBesonders gelungen finde ich die Darstellung von Backlogs und Sprints nebeneinander. Beide Bereiche lassen sich unabhängig scrollen. Das schafft Übersicht. In Jira liegen beide Bereiche untereinander. Beim Scrollen verliert man dort schnell die Orientierung.\u003c/p\u003e\n\n\u003cp\u003eEtwas versteckt ist die Möglichkeit, während der Planung spontan neue Arbeitspakete anzulegen. Sie steckt im Drei-Punkte-Menü in der Kopfzeile des Sprints.\u003c/p\u003e\n\n\u003cfigure\u003e\r\n\u003cimg alt=\"“Backlog and sprints” board showing backlog items and “Sprint 1 (KW17)” with 4 user stories, 15 points.\" loading=\"lazy\" srcset=\"https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_400/v1/uploads-production/64qedrd7s8bkwpaz6d1x7ruw3see?_a=BACMTiAE 400w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_800/v1/uploads-production/64qedrd7s8bkwpaz6d1x7ruw3see?_a=BACMTiAE 800w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_1024/v1/uploads-production/64qedrd7s8bkwpaz6d1x7ruw3see?_a=BACMTiAE 1024w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_1200/v1/uploads-production/64qedrd7s8bkwpaz6d1x7ruw3see?_a=BACMTiAE 1200w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_1600/v1/uploads-production/64qedrd7s8bkwpaz6d1x7ruw3see?_a=BACMTiAE 1600w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2048/v1/uploads-production/64qedrd7s8bkwpaz6d1x7ruw3see?_a=BACMTiAE 2048w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2300/v1/uploads-production/64qedrd7s8bkwpaz6d1x7ruw3see?_a=BACMTiAE 2300w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2600/v1/uploads-production/64qedrd7s8bkwpaz6d1x7ruw3see?_a=BACMTiAE 2600w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2800/v1/uploads-production/64qedrd7s8bkwpaz6d1x7ruw3see?_a=BACMTiAE 2800w\" sizes=\"(min-width: 1400px) 1024px, 90vw\"\u003e\r\n\r\n\u003cfigcaption\u003eDer Planungsmodus: Backlog und Sprints nebeneinander\u003c/figcaption\u003e\u003c/figure\u003e\r\n\n\u003ch4 id=\"unterschiedliche-arten-von-boards\"\u003eUnterschiedliche Arten von Boards\u003c/h4\u003e\n\n\u003cp\u003eSobald man mit dem Planning fertig ist, ist es interessant wie OpenProject die Organisation der Team-Zusammenarbeit unterstützt. Dafür gibt es unterschiedliche Arten von Boards, die ich Ihnen kurz im Überblick vorstellen möchte.\u003c/p\u003e\n\n\u003cp\u003e\u003cstrong\u003eGrundsätzlich gibt es zwei Arten von Boards:\u003c/strong\u003e\u003c/p\u003e\n\n\u003cul\u003e\n\u003cli\u003e\u003cp\u003e\u003cstrong\u003eBasic Boards\u003c/strong\u003e gehören zur Community Edition. Sie funktionieren einfach, haben aber klare Einschränkungen: Sie müssen diese Boards manuell füllen. Jedes Ticket, das auf dem Board erscheinen soll, müssen Sie selbst einzeln manuell hinzufügen. Tickets landen also nicht automatisch auf dem Board, nur weil sie zu einem bestimmten Sprint gehören. Auch das Verschieben von Tickets hat keine Auswirkungen auf deren Felder. Ziehen Sie ein Ticket in eine andere Spalte, ändert sich zum Beispiel der Bearbeitungsstatus nicht automatisch. Steht eine Spalte etwa für den Status „In Bearbeitung“, bleibt der Ticketstatus trotz Verschiebens unverändert. Sie müssen den Status danach zusätzlich manuell auf „In Bearbeitung“ setzen.\u003c/p\u003e\u003c/li\u003e\n\u003cli\u003e\u003cp\u003e\u003cstrong\u003eAction Boards\u003c/strong\u003e zeigen das Verhalten, das viele von uns wahrscheinlich erwarten, wenn sie von Jira kommen, d.h. hier landen die Tickets automatisch auf dem Board, wenn die Tickets im aktuellen Sprint enthalten sind und ich den Board-Filter entsprechend gesetzt habe. Auch ändern sich die korrespondierende Felder automatisch, wenn ich ein Ticket auf die entsprechende Spalte verschiebe. Zunächst war ich etwas enttäuscht als ich feststellte dass Action-Boards nur zur Verfügung stehen, wenn man eine Enterprise-Lizenz gekauft hat. Mittlerweile kann ich die Entscheidung aber nachvollziehen, weil Action-Boards ein starkes Argument für das Buchen einer Enterprise-Lizenz sind und das ja gleichzeitig gewährleistet, dass OpenProject eine Zukunft hat und eine sichere Investitionsentscheidung für seine Kund:innen ist.\u003c/p\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\n\u003cp\u003e\u003cstrong\u003eUnterschiedliche Arten von Action Boards:\u003c/strong\u003e\u003c/p\u003e\n\n\u003cp\u003eOpenProject bietet viele interessante Action Boards. Sie lösen typische Anwendungsszenarien klar und direkt. Dafür musste ich mich in Jira früher oft mühsam durch Tickets auf vielen unterschiedlichen Seiten klicken. Mir ist nicht bekannt, ob Jira ähnliche Lösungen bietet.\u003c/p\u003e\n\n\u003cp\u003eIch möchte einen kurzen Überblick über die Action Boards geben, die OpenProject anbietet:\u003c/p\u003e\n\n\u003cul\u003e\n\u003cli\u003eDas \u003cstrong\u003eKanban Board\u003c/strong\u003e entspricht dem klassischen Board aus Jira. Die Spalten zeigen den jeweiligen Bearbeitungsstatus. Damit eignet sich das Board gut für den Alltag in der agilen Softwareentwicklung. Auch wenn der Name es nicht vermuten lässt, ist das Kanban-Board auch die Grundlage der täglichen Arbeitsorganisation, wenn man nach Scrum arbeitet.\nIrritierend ist allerdings: Es gibt grundsätzlich keine WIP-Limits. Dabei gehören Begrenzungen für parallele Aufgaben zu den Grundprinzipien von Kanban. Ohne solche Limits verlieren Teams schnell den Überblick und Engpässe bleiben länger unbemerkt.\u003c/li\u003e\n\u003cli\u003eDas \u003cstrong\u003eAssignee Board\u003c/strong\u003e organisiert Tickets nach zuständigen Team-Mitgliedern. Es zeigt schnell, wie stark das Team ausgelastet ist. So erkennt man sofort: Häufen sich bei einzelnen Teammitgliedern Aufgaben? Wer hat noch freie Kapazitäten?\u003c/li\u003e\n\u003cli\u003eIm \u003cstrong\u003eVersion Board\u003c/strong\u003e steht jede Spalte für eine Produktversion. Das Board hilft Product Owner:innen, Releasepläne zu erstellen und Features geplanten Softwareversionen zuzuordnen.\u003c/li\u003e\n\u003cli\u003eDas \u003cstrong\u003eSubproject-Board\u003c/strong\u003e funktioniert ähnlich wie das Assignee-Board. Die Spalten sind jedoch nach Unterprojekten organisiert. So sieht man auf einen Blick, welche Aufgaben zu welchem Unterprojekt gehören. Unterprojekte haben einen funktionalen Fokus. Ihnen kann man nicht spontan beliebige Aufgaben zuweisen. Deshalb nutzt man das Board nicht, um freie Kapazitäten\nzu entdecken, es geht eher um die Frage: Welches Team arbeitet gerade an welchem Thema?\u003c/li\u003e\n\u003cli\u003eIm \u003cstrong\u003eParent-Child-Board\u003c/strong\u003e spiegeln die Spalten die übergeordneten Arbeitspakete wider. Das Board hilft dabei, einen Projektstrukturplan oder eine Work Breakdown Structure (WBS) zu erstellen. Sie sehen schnell, ob die Unteraufgaben den richtigen Arbeitspaketen zugeordnet sind. Bei Bedarf können Sie die Struktur einfach anpassen.\u003c/li\u003e\n\u003c/ul\u003e\n\n\u003ch4 id=\"unterstutzt-mich-openproject-auch-im-rahmen-von-skalierten-agilen-frameworks\"\u003eUnterstützt mich OpenProject auch im Rahmen von skalierten agilen Frameworks?\u003c/h4\u003e\n\n\u003cp\u003eIch kenne mich mit skalierten agilen Frameworks nicht gut aus, deshalb traue ich mir ehrlich gesagt kein qualifiziertes Urteil zur Unterstützung von skalierten agilen Frameworks zu. Aus meiner Sicht bietet OpenProject allerdings durch die Möglichkeit, Projekte ineinander zu verschachteln sehr viel Flexibilität unterschiedliche organisatorische Strukturen abzubilden. Zusätzlich möchte ich Ihnen gerne noch zwei Features vorstellen, die ich bis jetzt noch nicht erwähnt habe.\u003c/p\u003e\n\n\u003cp\u003e\u003cstrong\u003eMan kann Sprints teilen:\u003c/strong\u003e\u003c/p\u003e\n\n\u003cp\u003eWenn man Sprints über mehrere Projekte hinweg synchronisieren möchte, gibt es die Möglichkeit, in einem Oberprojekt einen geteilten Sprint anzulegen. Dieser Sprint ist dann in allen Unterprojekten, mit denen er geteilt wird, sichtbar. Geteilt wird nur der Zeitraum. Die Inhalte des Sprints auf Teamebene werden weiterhin auf Teamebene entschieden. Der Gesamtsprint wird aber auf Oberprojekt-Ebene gestartet und gestoppt.\u003c/p\u003e\n\n\u003cp\u003e\u003cstrong\u003eRoadmaps und Versionen:\u003c/strong\u003e\u003c/p\u003e\n\n\u003cp\u003eSeitdem OpenProject echte Sprint-Container implementiert hat, muss man nach dem Anlegen von Versionen beim ersten Mal ein bisschen suchen. Die Versionsverwaltung findet man in den Project Settings des jeweiligen Projekts. Sobald man eine erste Version eingerichtet hat, ist das Roadmap-Modul von OpenProject freigeschaltet. Im Beispiel habe ich die Versionen im Oberprojekt angelegt und mit den Unterprojekten geteilt. Wenn man mit SAFe arbeitet, könnte man so beispielsweise ein Program Increment abbilden. Versionen kann man ein Start- und Enddatum zuweisen.\u003c/p\u003e\n\n\u003cfigure\u003e\r\n\u003cimg alt=\"Roadmap view listing “Großes Enterprise-Projekt” releases 2026-V1 MLP, 2026-V2 MMP, 2026-V3 MVP, all at 0% progress.\" loading=\"lazy\" srcset=\"https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_400/v1/uploads-production/ba9ojw6ajqnlmykll06yjuy1i8yj?_a=BACMTiAE 400w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_800/v1/uploads-production/ba9ojw6ajqnlmykll06yjuy1i8yj?_a=BACMTiAE 800w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_1024/v1/uploads-production/ba9ojw6ajqnlmykll06yjuy1i8yj?_a=BACMTiAE 1024w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_1200/v1/uploads-production/ba9ojw6ajqnlmykll06yjuy1i8yj?_a=BACMTiAE 1200w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_1600/v1/uploads-production/ba9ojw6ajqnlmykll06yjuy1i8yj?_a=BACMTiAE 1600w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2048/v1/uploads-production/ba9ojw6ajqnlmykll06yjuy1i8yj?_a=BACMTiAE 2048w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2300/v1/uploads-production/ba9ojw6ajqnlmykll06yjuy1i8yj?_a=BACMTiAE 2300w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2600/v1/uploads-production/ba9ojw6ajqnlmykll06yjuy1i8yj?_a=BACMTiAE 2600w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2800/v1/uploads-production/ba9ojw6ajqnlmykll06yjuy1i8yj?_a=BACMTiAE 2800w\" sizes=\"(min-width: 1400px) 1024px, 90vw\"\u003e\r\n\r\n\u003cfigcaption\u003eEine Roadmap-Übersicht\u003c/figcaption\u003e\u003c/figure\u003e\r\n\n\u003ch4 id=\"wie-bewerte-ich-agiles-projekt-management-in-openproject\"\u003eWie bewerte ich agiles Projekt-Management in OpenProject?\u003c/h4\u003e\n\n\u003cp\u003eInsgesamt halte ich das agile Projektmanagement in OpenProject für gelungen. Zunächst war ich enttäuscht: Mit dem Basic Board kommt man kaum weit. Wer OpenProject sinnvoll nutzen will, braucht mindestens die Basic-Enterprise-Lizenz. Erst dann stehen die Action Boards zur Verfügung. Damit lässt sich aus meiner Sicht vernünftig agil arbeiten.\u003c/p\u003e\n\n\u003cp\u003eDie Benutzeroberfläche wirkt auf mich allerdings nicht besonders modern. Das liegt nicht an einzelnen Funktionen, sondern am Gesamteindruck.\nPositiv fand ich den Planning-Modus: Dort lassen sich Backlog und Sprints nebeneinander anzeigen. Tickets zu verschieben ist dadurch einfacher als in Jira.\u003c/p\u003e\n\n\u003cp\u003eWirklich stört mich jedoch, dass sich keine WIP-Limits pro Spalte festlegen lassen. Damit unterstützt OpenProject Kanban aus meiner Sicht nur unzureichend. Wer hauptsächlich Scrum nutzt, wird damit vermutlich kein Problem haben. Hier hat Jira derzeit für mich noch die Nase vorn.\nZur Unterstützung skalierter agiler Frameworks kann ich kein fundiertes Urteil abgeben. Dafür kenne ich die entsprechenden Funktionen in Jira zu wenig. Ich habe Ihnen jedoch gezeigt, was sich mit OpenProject umsetzen lässt. Ich hoffe, das hilft Ihnen dabei, sich ein eigenes Urteil zu bilden.\u003c/p\u003e\n\n\u003ch3 id=\"klassisches-projektmanagement-in-openproject\"\u003eKlassisches Projektmanagement in OpenProject\u003c/h3\u003e\n\n\u003cp\u003eUnter dem Blickwinkel des klassischen Projektmanagements habe ich mir OpenProject nicht genauer angesehen. Es ist lange her, dass ich zuletzt ein Projekt nach dem Wasserfallmodell erlebt habe. In meinem Arbeitsalltag spielt dieses Modell keine Rolle mehr. Einige Funktionen für klassisches Projektmanagement sind uns dennoch schon begegnet:\u003c/p\u003e\n\n\u003cul\u003e\n\u003cli\u003eArbeitspakete lassen sich in eine logische Reihenfolge bringen.\u003c/li\u003e\n\u003cli\u003eArbeitspakete können ein Start- und Enddatum haben.\u003c/li\u003e\n\u003cli\u003eMeilensteine lassen sich unabhängig von Arbeitspaketen anlegen und in die Reihenfolge einordnen.\u003c/li\u003e\n\u003cli\u003eProjekte und Arbeitspakete können hierarchisch verschachtelt werden.\u003c/li\u003e\n\u003cli\u003eProjektübergreifende Gantt-Diagramme sind möglich.\u003c/li\u003e\n\u003c/ul\u003e\n\n\u003cp\u003eEinige weitere Funktionen ordne ich ebenfalls dem klassischen Projektmanagement zu. Sie können aber auch in agileren Projekten nützlich sein. Ich habe sie nicht im Detail geprüft und stütze mich hier auf die offizielle Dokumentation.\u003c/p\u003e\n\n\u003ch4 id=\"budgetplanung-und-budgetuberwachung\"\u003eBudgetplanung und Budgetüberwachung\u003c/h4\u003e\n\n\u003cp\u003eIn OpenProject lassen sich Projektbudgets anlegen. Sie umfassen geplante Personalkosten sowie Sachkosten wie Material oder Reisekosten. Die Personalkosten berechnet das System anhand der hinterlegten Stundensätze der Benutzer:innen. Für Sachkosten können Teams eigene Kostenarten mit individuellen Einheiten und Sätzen definieren.\u003c/p\u003e\n\n\u003ch4 id=\"zeiterfassung-und-verbrauchskontrolle\"\u003eZeiterfassung und Verbrauchskontrolle\u003c/h4\u003e\n\n\u003cp\u003eArbeitspakete lassen sich einem Budget zuordnen. Zeiten und Sachkosten, die Mitarbeiter:innen auf diese Arbeitspakete buchen, verrechnet OpenProject automatisch mit dem Budget. Die Budgetübersicht und Projekt-Widgets zeigen jederzeit den Plan-Ist-Vergleich und das verbleibende Budget.\u003c/p\u003e\n\n\u003ch4 id=\"anderungsverfolgung-mit-baseline\"\u003eÄnderungsverfolgung mit Baseline\u003c/h4\u003e\n\n\u003cp\u003eOpenProject bietet keine klassische Baseline-Funktion wie Microsoft Project, bei der ein Projektplan als feste Momentaufnahme gespeichert wird. Stattdessen vergleicht die Baseline-Funktion Tabellenansichten von Arbeitspaketen mit einem früheren Stand, etwa von gestern, letzter Woche oder einem bestimmten Datum.\u003c/p\u003e\n\n\u003cp\u003eDas System markiert geänderte, hinzugefügte und entfernte Arbeitspakete. Alte und neue Werte stehen direkt nebeneinander. Eine Darstellung im Gantt-Diagramm gibt es bisher nicht. Mit Ausnahme des Vergleichs zum Vortag gehört die Baseline-Funktion zur Enterprise-Version.\u003c/p\u003e\n\n\u003ch3 id=\"der-ki-das-sprechen-mit-openproject-beibringen\"\u003eDer KI das Sprechen mit OpenProject beibringen\u003c/h3\u003e\n\n\u003cp\u003eWenn man KI in Verbindung mit OpenProject nutzen will, dann geht auch hier - wie in unserem Jira-Beispiel - der Weg über einen MCP-Server. Dafür gibt es mehrere Optionen.\u003c/p\u003e\n\n\u003ch4 id=\"openproject-bringt-bereits-einen-eigenen-mcp-server-mit\"\u003eOpenProject bringt bereits einen eigenen MCP-Server mit\u003c/h4\u003e\n\n\u003cp\u003eWenn man OpenProject mit einer Enterprise-Lizenz nutzt, dann kann man den in OpenProject integrierten MCP-Server nutzen. Dieser hat bisher\nallerdings noch keine Schreiboperationen. Das reicht aber, wenn ich z. B. meinen Coding-Agent bitten möchte, ein bestimmtes Ticket zu\nimplementieren. Das funktionierte in der Kombination mit Claude Code tadellos.\u003c/p\u003e\n\n\u003ch4 id=\"es-gibt-eine-grosse-anzahl-von-bereits-implementierten-open-source-mcp-servern\"\u003eEs gibt eine große Anzahl von bereits implementierten Open Source MCP-Servern\u003c/h4\u003e\n\n\u003cp\u003eWer allerdings KI dazu nutzen möchte, aus Meeting-Protokollen automatisch Aufgabenpakete in OpenProject zu erzeugen, braucht einen MCP-Server, der auch Schreiboperationen unterstützt. Eine kurze Google-Suche ergibt schnell viele brauchbare Optionen. Grundsätzlich gibt es zwei unterschiedliche Arten wie Clients mit MCP-Servern kommunizieren können:\u003c/p\u003e\n\n\u003cul\u003e\n\u003cli\u003e\n\u003cstrong\u003eStandard-Input/-Output(stdio):\u003c/strong\u003e In diesem Fall startet der Client den MCP-Server selbst lokal und kommuniziert direkt über die Befehlszeile mit ihm.\u003c/li\u003e\n\u003cli\u003e\n\u003cstrong\u003eNetzwerk-Server/HTTP:\u003c/strong\u003e In diesem Fall wird der MCP-Server remote im Netzwerk zur Verfügung gestellt und die Clients kommunizieren via HTTP mit ihm.\u003c/li\u003e\n\u003c/ul\u003e\n\n\u003cp\u003eDer Weg über \u003cstrong\u003eStandard-Input/Output\u003c/strong\u003e hat den Vorteil, dass der MCP-Server mit dem personalisierten API-Token der:des jeweiligen Nutzer:in läuft, d. h. der MCP-Server hat genau dieselben Privilegien wie die:der jeweilige Nutzer:in und kann auch nur das tun, was der:dem jeweiligen Nutzer:in erlaubt ist. Der Nachteil ist allerdings, dass alle eine eigene Instanz des MCP-Servers installieren müssen. Das kann in Einzelfällen ein Problem sein.\u003c/p\u003e\n\n\u003cp\u003eGenau deshalb möchte ich ihnen den Open-Source MCP-Server \u003ca href=\"https://github.com/tmskln/spring-openproject-mcp-server\"\u003etmskln/spring-openproject-mcp-server\u003c/a\u003e empfehlen. Dieser reicht den API-Token der:des jeweiligen Nutzer:in an die OpenProject-API weiter, so dass auch hier gewährleistet ist, dass die Nutzung innerhalb der Nutzer-Privilegien gewahrt bleibt. Gleichzeitig braucht man nur eine zentrale Instanz des MCP-Servers für alle. Für die konkrete Nutzung von OpenProject mit einem lokalen KI-Modell in LM-Studio verweise ich auf den Artikel meines Kollegen Nicolas Inden. Das kann man 1:1 auf die Nutzung mit OpenProject übertragen.\u003c/p\u003e\n\n\u003ch3 id=\"weitere-nutzliche-features-von-openproject\"\u003eWeitere nützliche Features von OpenProject\u003c/h3\u003e\n\n\u003ch4 id=\"wiki-und-dokumente\"\u003eWiki und Dokumente\u003c/h4\u003e\n\n\u003cp\u003eOpenProject bringt ein eigenes Wiki mit. Confluence ersetzt es nicht, denn jedes Wiki gehört zu einem konkreten Projekt. Es eignet sich daher vor allem für projektspezifische Dokumentation. Etwas verwirrend ist, dass OpenProject zusätzlich ein Dokumenten-Modul anbietet. Dort lassen sich verschiedene Dokumenttypen anlegen, etwa Proposal, Idea, Specification oder Documentation.\u003c/p\u003e\n\n\u003cp\u003eIch würde das Wiki nutzen,\u003c/p\u003e\n\n\u003cul\u003e\n\u003cli\u003ewenn mehrere Personen gemeinsam Inhalte erarbeiten,\u003c/li\u003e\n\u003cli\u003ewenn die Dokumentation hierarchisch aufgebaut ist,\u003c/li\u003e\n\u003cli\u003ewenn Seiten sich gegenseitig verlinken,\u003c/li\u003e\n\u003cli\u003ewenn Sie Texte lieber in Markdown schreiben.\u003c/li\u003e\n\u003c/ul\u003e\n\n\u003cp\u003eJeder Wiki-Beitrag wird intern als Markdown gespeichert. Sie können jederzeit zwischen Markdown und WYSIWYG-Ansicht wechseln.\nDas Wiki basiert auf CKEditor 5, das Dokumenten-Modul auf BlockNote. Deshalb fehlt im Dokumenten-Modul derzeit ein Markdown-Modus.\u003c/p\u003e\n\n\u003cp\u003eIst ein Dokument fertig, lässt es sich grundsätzlich in das Dokumenten-Modul überführen. Einen eleganten Weg bietet OpenProject dafür jedoch nicht. Sie können einen Wiki-Beitrag als PDF exportieren und als Anhang importieren oder den Inhalt per Copy-and-paste übernehmen.\u003c/p\u003e\n\n\u003cp\u003eSeit OpenProject 17.0 unterstützen Dokumente die Echtzeit-Kollaboration. Diese Funktion hätte ich eher im Wiki erwartet. Der Grund dafür ist wahrscheinlich, dass die technische Basis des Dokumenten-Moduls das ermöglicht. Auf konzeptioneller Ebene führt es aus meiner Sicht aber zu Verwirrung. Möglicherweise deutet sie darauf hin, dass OpenProject das Dokumenten-Modul langfristig als Nachfolger des Wikis positionieren möchte. Das ist allerdings Spekulation. Sie erklärt für mich jedoch, warum sich Wiki und Dokumenten-Modul derzeit nur schwer klar voneinander abgrenzen lassen.\u003c/p\u003e\n\n\u003ch4 id=\"meetings-organisieren\"\u003eMeetings organisieren\u003c/h4\u003e\n\n\u003cp\u003eDas Meeting-Modul eignet sich besonders, wenn Sie Besprechungen eng mit Arbeitspaketen verknüpfen möchten. Eine Agenda können Sie aus Arbeitspaketen oder aus separaten Agenda-Punkten zusammenstellen.\u003c/p\u003e\n\n\u003cp\u003eNutzen Sie Arbeitspakete als Agenda, erfassen Sie die Ergebnisse direkt dort und verfolgen anschließend den Fortschritt. Arbeiten Sie mit Agenda-Punkten, speichern Sie die Notizen im jeweiligen Punkt. Diese Informationen lassen sich später jedoch nur schwer wiederfinden, da Sie dafür das Meeting erneut öffnen müssen.\u003c/p\u003e\n\n\u003cp\u003ePraktischer ist es, aus einem Agenda-Punkt direkt ein neues Arbeitspaket zu erstellen oder ein bestehendes zu aktualisieren.\u003c/p\u003e\n\n\u003cp\u003eHilfreich ist auch die Einladungsfunktion. Über das Meeting-Modul können Sie Einladungen direkt an alle Teilnehmer:innen versenden. Das spart einige manuelle Arbeitsschritte.\u003c/p\u003e\n\n\u003ch4 id=\"integration-mit-gitlab-und-github\"\u003eIntegration mit GitLab und GitHub\u003c/h4\u003e\n\n\u003cp\u003eOpenProject kann Aktivitäten aus GitLab oder GitHub im Aktivitäten-Tab des zugehörigen Arbeitspakets anzeigen.\u003c/p\u003e\n\n\u003cp\u003eIch habe die Funktion nur mit GitLab getestet. Dort arbeitete sie zuverlässig.\u003c/p\u003e\n\n\u003ch4 id=\"integration-mit-nextcloud\"\u003eIntegration mit Nextcloud\u003c/h4\u003e\n\n\u003cp\u003eOpenProject lässt sich eng mit Nextcloud verzahnen. Ich habe die Integration zwar nicht selbst getestet, sie ist jedoch \u003ca href=\"https://www.openproject.org/de/integrations/nextcloud\"\u003ehier\u003c/a\u003e auf der OpenProject-Website gut dokumentiert. Die Integration funktioniert in beide Richtungen. Sie können Arbeitspakete mit Dateien in Nextcloud verknüpfen und sich in Nextcloud eine Übersicht Ihrer Arbeitspakete anzeigen lassen.\u003c/p\u003e\n\n\u003ch4 id=\"arbeitspakete-per-e-mail-anlegen\"\u003eArbeitspakete per E-Mail anlegen\u003c/h4\u003e\n\n\u003cp\u003eArbeitspakete lassen sich auch per E-Mail erstellen. Darüber hinaus können Sie auf Benachrichtigungen zu Arbeitspaketen antworten. OpenProject übernimmt Ihre Antwort automatisch als Kommentar in das betreffende Arbeitspaket. Das erleichtert die Kommunikation erheblich.\u003c/p\u003e\n\n\u003ch4 id=\"jira-migrator\"\u003eJira-Migrator\u003c/h4\u003e\n\n\u003cp\u003eDas OpenProject-Team bietet ein eigenes Tool für die Migration bestehender Projekte zu OpenProject an: \u003cstrong\u003eden Jira-Migrator\u003c/strong\u003e. Ich hatte keine Gelegenheit, das Tool zu testen. Eine ausführliche Beschreibung seiner Features finden Sie \u003ca href=\"https://www.openproject.org/docs/installation-and-operations/jira-migration/\"\u003ehier\u003c/a\u003e.\u003c/p\u003e\n\n\u003cinfo-box title=\"Anhang: Welche Kandidaten habe ich mir außer OpenProject noch angeschaut?\"\u003e\u003cdetails\u003e\u003csummary\u003e\u003cdiv class=\"infobox__teaser\"\u003e\n\u003cdiv class=\"infobox__teaser__left\"\u003e\n\u003cspan class=\"infobox__teaser__heading\"\u003eAnhang: Welche Kandidaten habe ich mir außer OpenProject noch angeschaut?\u003c/span\u003e\u003cspan class=\"icon icon-info\"\u003e\u003c/span\u003e\n\u003c/div\u003e\n\u003cdiv class=\"infobox__teaser__right\"\u003e\u003cspan class=\"icon icon-chevron-down icon--small\"\u003e\u003c/span\u003e\u003c/div\u003e\n\u003c/div\u003e\u003c/summary\u003e\u003cdiv class=\"infobox__content\"\u003e\r\n\n\u003cp\u003eZu Beginn meiner Suche nach datensouveränen Jira-Alternativen habe ich mir durch Internetrecherche und die Befragung meines favorisierten\nKI-Modells einen Überblick darüber verschafft, welche Open-Source-Alternativen zu Jira es gibt. Auf die Kandidaten, die ich mir zunächst\nangeschaut und dann ausgeschlossen habe, möchte ich hier zunächst kurz eingehen.\u003c/p\u003e\n\n\u003ch3 id=\"gitlab\"\u003eGitlab\u003c/h3\u003e\n\n\u003cp\u003eDa wir bereits eine interne GitLab-Instanz haben und GitLab generell auch die Möglichkeit bietet, Tickets zu verwalten, habe ich mir\nzunächst angeschaut, inwieweit GitLab meine oben genannten Kriterien erfüllt. Dabei bin ich darauf gestoßen, dass Epics ein Premium-\nFeature von GitLab sind, d. h. man braucht dafür eine Premium-Lizenz, die im Moment 29 Dollar pro Person und Monat kostet. Das war im\nVergleich zu Lizenzen anderer Anbieter zu hoch, so dass GitLab dadurch aus meiner Liste möglicher Kandidaten herausgefallen ist.\u003c/p\u003e\n\n\u003ch3 id=\"taiga\"\u003eTaiga\u003c/h3\u003e\n\n\u003cp\u003eTaiga ist ein Open-Source-Projekt, das sich auf Projektmanagement für agile Projekte fokussiert. Mich hat das Look \u0026amp; Feel allerdings nicht\nangesprochen, so dass ich es nicht weiter untersucht habe. Mich hat sehr irritiert, dass ich User Stories auf dem Board nicht verschieben\nkonnte. Das lag daran, dass man die User Stories im Scrum-Board selbst nicht verschieben kann. Sie bleiben in der linken Spalte stehen.\nMan muss Subtasks zu den Stories anlegen. Diese kann man dann verschieben. Wenn man ein Open-Source-Tool für ein kleines Projekt sucht,\ndann ist Taiga aber sicherlich ein Kandidat, den man sich genauer anschauen kann. Man kann es lizenzkostenfrei auf eigener Hardware\nbetreiben. Es gibt aber auch eine Cloud-Option, die man bezahlen muss. Taiga geht aber grundsätzlicher von einer flachen Projekthierarchie\naus, so dass es auch bei diesem Aspekt von meinem eingangs spezifizierten Anforderungsprofil abweicht.\u003c/p\u003e\n\n\u003ch3 id=\"plane\"\u003ePlane\u003c/h3\u003e\n\n\u003cp\u003ePlane ist ebenfalls ein Open-Source-Produkt, das selbst gehostet werden kann. Es gibt aber auch Cloud-Optionen. Plane hat mich sehr\nangesprochen, weil ich die UX der Anwendung als angenehm empfunden habe. Alles wirkt klar, aufgeräumt und übersichtlich. Ich konnte mich\nsehr schnell zurückfinden. Wenn ich ein Projektmanagement-Tool für ein agiles Projekt suche, das ich selbst hosten kann, wäre Plane mein\nFavorit. Als Jira-Alternative habe ich es nicht in Betracht gezogen, weil für mich Plane noch ein recht junges Projekt ist. Plane gibt es\nerst seit 3 Jahren, OpenProject gibt es seit 2012. Obwohl Plane auch Projekthierarchien unterstützt, erschien mir OpenProject als das\nreifere Produkt, das mehr Investitionssicherheit bietet. Aber Plane ist sicherlich auch einen zweiten Blick wert, wenn einem OpenProject\nnicht zusagt.\u003c/p\u003e\n\n\u003c/div\u003e\u003c/details\u003e\u003c/info-box\u003e\r\n\n\u003ch3 id=\"zusammenfassung-und-fazit\"\u003eZusammenfassung und Fazit\u003c/h3\u003e\n\n\u003cp\u003eIst OpenProject also besser als Jira? Die Frage führt natürlich in die Irre. Beide Werkzeuge lösen ähnliche Probleme auf unterschiedliche Weise. Entscheidend ist, worauf Ihre Organisation Wert legt. Obwohl ich mich schon intensiv mit OpenProject beschäftigt habe, entdecke ich immer wieder neue Wege Projektszenarien abzubilden.\u003c/p\u003e\n\n\u003cp\u003eNach einem Monat intensiver Arbeit mit OpenProject ziehe ich ein klares Fazit: \u003cstrong\u003eOpenProject ist eine ernstzunehmende Alternative zu Jira. Vor allem dort, wo Datensouveränität, kalkulierbare Kosten und europäische Infrastruktur entscheidend sind.\u003c/strong\u003e\u003c/p\u003e\n\n\u003ch4 id=\"wo-openproject-jira-uberlegen-ist\"\u003eWo OpenProject Jira überlegen ist\u003c/h4\u003e\n\n\u003cp\u003e\u003cstrong\u003eDatensouveränität:\u003c/strong\u003e OpenProject setzt auf Open Source unter GPLv3. Sie betreiben die Software selbst oder nutzen eine EU-Cloud bei Scaleway. Einen Marketplace mit unkontrollierten Drittanbieter-Datenflüssen gibt es nicht.\u003c/p\u003e\n\n\u003cp\u003e\u003cstrong\u003eHybrides Projektmanagement ohne Werkzeugwechsel:\u003c/strong\u003e Strategische Planung mit Gantt-Diagrammen und operative Teamarbeit mit Backlogs und Action Boards laufen in einer Anwendung. Bei Atlassian brauchen Sie dafür meist Jira, Advanced Roadmaps und zusätzliche Marketplace-Plugins.\u003c/p\u003e\n\n\u003cp\u003e\u003cstrong\u003eBesseres Sprint-Planning:\u003c/strong\u003e OpenProject zeigt Backlog und Sprint nebeneinander. Beide Bereiche scrollen unabhängig voneinander. Das klingt klein, löst aber ein konkretes Alltagsproblem, das Jira bis heute nicht elegant löst.\u003c/p\u003e\n\n\u003cp\u003e\u003cstrong\u003eMehr Funktionen im Kernprodukt:\u003c/strong\u003e Die Enterprise-Lizenz ab dem Professional-Tarif enthält alle wesentlichen Funktionen. Zusätzliche Plugins brauchen Sie nicht. Das spart Geld und vermeidet typische Probleme:\u003c/p\u003e\n\n\u003cul\u003e\n\u003cli\u003esteigende Plugin-Kosten\u003c/li\u003e\n\u003cli\u003eDatenschutzfragen bei Drittanbieter-Apps\u003c/li\u003e\n\u003cli\u003eVersionskonflikte zwischen Kernprodukt und Erweiterungen\u003c/li\u003e\n\u003c/ul\u003e\n\n\u003ch4 id=\"wo-jira-starker-bleibt\"\u003eWo Jira stärker bleibt\u003c/h4\u003e\n\n\u003cp\u003e\u003cstrong\u003eKanban:\u003c/strong\u003e OpenProject unterstützt keine WIP-Limits. Für Teams, die Kanban konsequent nutzen, ist das ein echter Nachteil. Begrenzungen paralleler Arbeit gehören zu den Grundprinzipien der Methode.\u003c/p\u003e\n\n\u003cp\u003e\u003cstrong\u003eAnpassbarkeit von Workflows und Ansichten:\u003c/strong\u003e Jiras Workflow-Editor und JQL setzen Maßstäbe. OpenProject holt auf, erreicht diese Tiefe aber noch nicht. Wer komplexe Jira-Workflows betreibt, sollte vor einer Migration genau prüfen, welche Funktionen fehlen.\u003c/p\u003e\n\n\u003cp\u003e\u003cstrong\u003eBenutzeroberfläche und UX:\u003c/strong\u003e OpenProject wirkt funktional und nüchtern. Jira Cloud erscheint moderner und polierter. Das ist Geschmacksache — beeinflusst aber den Alltag vieler Teams.\u003c/p\u003e\n\n\u003ch3 id=\"mein-personliches-fazit\"\u003eMein persönliches Fazit\u003c/h3\u003e\n\n\u003cp\u003eFür mich ist OpenProject derzeit die überzeugendste datensouveräne Alternative zu Jira. Nicht in jeder Disziplin besser. Aber stärker in genau den Bereichen, die im Moment wichtig sind bzw. die wahrscheinlich auch noch wichtiger werden: \u003cstrong\u003eSouveränität und kalkulierbare Kosten\u003c/strong\u003e.\u003c/p\u003e\n\n\u003cp\u003eMich hat überrascht, dass so ein tolles OpenSource-Produkt aus Deutschland kommt und dass ich es noch nicht kannte. Überzeugt hat mich vor allem die Flexibilität von OpenProject. Man kann unterschiedliche Organisations- und Projekthierarchien abbilden und man kann Methoden aus unterschiedlichen Projektmanagement-Modellen kombinieren. Deshalb kann ich auch gar kein allgemeines Urteil fällen. Meine Empfehlung ist: Nutzen Sie die 14-tägige Trialphase und probieren Sie Ihr Einsatzszenario konkret aus.\u003c/p\u003e\n\n\u003cp\u003eOpenProject ist ein mächtiges Stück Software und erfordert Einarbeitung um sein gesamtes Potenzial zu entfalten. Falls sie Erfahrung mit OpenProject haben und gerne von Ihrer Erfahrung berichten möchten, dann schreiben Sie mir gerne eine E-Mail: holger.kraus@innoq.com. Falls Sie inhaltliche Fehler in diesem Artikel entdeckt haben, wäre ich Ihnen ebenfalls über einen kurzen Hinweis dankbar.\u003c/p\u003e\n\u003c/body\u003e\u003c/html\u003e\n","image":"https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2000/v1/uploads-production/6zet0s9an5ibbn5mutes2ho47v2t?_a=BACMTiAE"},{"id":"https://www.innoq.com/de/blog/2026/05/the-agentic-trio/","url":"https://www.innoq.com/de/blog/2026/05/the-agentic-trio/","date_published":"2026-05-27T00:00:00.000+00:00","date_modified":"2026-05-27T12:19:12.308+02:00","author":[{"name":"Daniel Westheide","url":"https://www.innoq.com/ch/staff/daniel-westheide/"}],"content_html":"\u003c!DOCTYPE html PUBLIC \"-//W3C//DTD HTML 4.0 Transitional//EN\" \"http://www.w3.org/TR/REC-html40/loose.dtd\"\u003e\n\u003chtml\u003e\u003cbody\u003e\n\u003cp\u003eDie besten Product Teams, ob in Start-ups oder großen Organisationen, arbeiten oft so, dass andere es kaum nachbauen können: Eine kleine Einheit, typischerweise aus Product Manager:in, UX-Designer:in und Engineer, erforscht systematisch relevante Nutzerprobleme, bevor Lösungen gebaut werden. Statt Stakeholder-Wünsche einfach umzusetzen, betreibt sie kontinuierliche Discovery, um herauszufinden, was überhaupt gebaut werden sollte. Die Delivery übernimmt das größere Product Team dahinter. Teresa Torres hat diese Arbeitsweise als Product Trio beschrieben.\u003c/p\u003e\n\n\u003cp\u003eWas bisher fehlte: Das Trio verantwortete die Discovery, die Delivery lag beim größeren Team dahinter. Agentic Development ändert das.\u003c/p\u003e\n\n\u003cp\u003eWir nennen diese Weiterentwicklung das \u003cstrong\u003eAgentic Trio\u003c/strong\u003e.\u003c/p\u003e\n\n\u003ch3 id=\"die-verschobenen-economics-der-delivery\"\u003eDie verschobenen Economics der Delivery\u003c/h3\u003e\n\n\u003cp\u003eDelivery wird schneller und günstiger. Der kontinuierliche Discovery-Delivery-Zyklus kann häufiger stattfinden, weil die Schwelle gesunken ist, ab der sich ein weiterer Zyklus lohnt. Dadurch entsteht Kapazität. Wie diese Kapazität genutzt wird, ist eine strategische Entscheidung.\u003c/p\u003e\n\n\u003cp\u003eFür Teams und Organisationen, die diese Entscheidung nicht bewusst treffen, bedeutet das Ergebnis oft: \u003cstrong\u003emehr Output – nicht besserer Output\u003c/strong\u003e. Aber „mehr Discovery statt mehr Output“ ist kein Trade-off. Teams, die stärker in Discovery investieren, identifizieren relevantere Probleme, priorisieren besser und bauen Lösungen, die tatsächlich funktionieren. Im gleichen Zeitraum werden mehr Chancen erkannt, mehr davon vor dem Bauen validiert und mehr davon mit funktionierenden Lösungen adressiert. Es wird weniger Zeug gebaut – aber mehr von dem, was gebaut wird, ist wirklich wichtig.\u003c/p\u003e\n\n\u003cp\u003eDer naheliegende Einwand lautet: Wenn Bauen billig ist, warum nicht einfach alles ausprobieren und in Produktion lernen, was funktioniert? Das klingt pragmatisch, setzt aber voraus, dass relevante Unsicherheit ausschließlich auf der Lösungsebene liegt. In der Realität stecken viele der riskantesten Annahmen weiterhin im Opportunity Space: \u003cem\u003eIst das Problem real? Haben es genug Menschen? Ist es relevant genug, dass sie tatsächlich etwas dagegen tun würden?\u003c/em\u003e Keine gebaute Funktion kann diese Fragen beantworten. Du kannst Agenten nutzen, um in ein paar Stunden eine Lösung zu erzeugen – und weißt danach über die zugrunde liegende Opportunity genauso wenig wie vorher. Du hast getestet, ob die Lösung implementierbar ist, nicht ob das Problem existiert und ob die Lösung es wirklich adressiert.\u003c/p\u003e\n\n\u003cp\u003eTorres unterscheidet mehrere Kategorien von Annahmen: \u003cstrong\u003eDesirability\u003c/strong\u003e (\u003cem\u003ewollen Nutzer:innen das überhaupt?\u003c/em\u003e), \u003cstrong\u003eFeasibility\u003c/strong\u003e (\u003cem\u003ekönnen wir es bauen?\u003c/em\u003e), \u003cstrong\u003eViability\u003c/strong\u003e (\u003cem\u003eist es wirtschaftlich sinnvoll, es zu bauen?\u003c/em\u003e) und \u003cstrong\u003eUsability\u003c/strong\u003e (\u003cem\u003ekönnen Nutzer:innen es bedienen?\u003c/em\u003e). Nutzungsmetriken können diese Kategorien nur begrenzt auseinanderhalten. Wenn ein Feature nicht genutzt wird, kann das an fehlender Desirability, schlechter Usability oder an einem Workaround liegen, den Nutzer:innen verinnerlicht haben und nicht aufgeben wollen. Das Signal ist überlagert. Ein kurzes Gespräch vor dem Bauen hätte die Frage direkter und günstiger beantwortet. Desirability-Annahmen sind oft die riskantesten – und gleichzeitig am billigsten zu testen. Sie zu überspringen und direkt zu bauen heißt: die falschen Dinge validieren, nur schneller.\u003c/p\u003e\n\n\u003cp\u003eDas gilt nicht für jede Art von Annahme. Usability- und Feasibility-Annahmen lassen sich oft günstiger durch Prototyping oder direktes Bauen validieren als durch Interviews. Agentic Development senkt diese Schwelle weiter. Schnelle Prototypen werden günstiger, der Zyklus zwischen Bauen und Lernen wird kürzer. Das ist eine echte Verschiebung. Aber sie betrifft nur einen Teil des Annahmenraums.\u003c/p\u003e\n\n\u003ch3 id=\"warum-mehr-output-das-system-destabilisiert\"\u003eWarum mehr Output das System destabilisiert\u003c/h3\u003e\n\n\u003cp\u003eDie Entscheidung für mehr Output statt systematischer, kontinuierlicher Discovery hat einen zweiten, weniger offensichtlichen Preis: Sie destabilisiert das System. Daten von \u003ca href=\"https://www.faros.ai/ai-productivity-paradox\"\u003eFaros AI\u003c/a\u003e und \u003ca href=\"https://cloud.google.com/resources/content/2025-dora-ai-assisted-software-development-report\"\u003eDORA\u003c/a\u003e belegen das empirisch.\u003c/p\u003e\n\n\u003cp\u003eFaros nennt dieses Muster \u003cstrong\u003e„Acceleration Whiplash“\u003c/strong\u003e: Wenn Teams Agentic Development vor allem für mehr Durchsatz nutzen, steigt der Output – Tasks werden 34% häufiger abgeschlossen, Epics 66% häufiger, code-spezifische Tasks sogar 210% häufiger. Gleichzeitig fallen alle Qualitätsindikatoren. Bugs pro Entwickler:in sind um 54% gestiegen, das Verhältnis Incidents zu PRs hat sich mehr als verdreifacht (+242,7%), die mediane Review-Zeit ist um 441% gestiegen, und 31,3% mehr Pull Requests werden ohne jegliches Review gemergt. Das betrifft sogar Teams, die DORA als „high-performing“ klassifiziert hat – Teams also, die sich schon vor der KI-Einführung durch schnelle Delivery und niedrige Change-Failure-Raten auszeichneten.\u003c/p\u003e\n\n\u003cp\u003eReinertsen liefert die systemische Erklärung: Mehr Output erhöht die Auslastung an kritischen Engpässen. Der kritische Engpass heute ist das Review durch Senior Engineers. Was leidet, ist die Review-Qualität. Das Ergebnis: mehr Bugs gelangen in Produktion. Hohe Auslastung an Bottleneck-Ressourcen ist der teuerste Zustand in einem Product-Development-System.\u003c/p\u003e\n\n\u003cp\u003eGründlichere Discovery reduziert den Input ins System an der richtigen Stelle: bevor unvalidierte Lösungen die Pipeline füllen und sich an kritischen Gates stauen. Weniger Zeug zu bauen heißt außerdem: weniger Review-Last für Senior Engineers, eine niedrigere Change-Failure-Rate und ein stabileres System.\u003c/p\u003e\n\n\u003ch3 id=\"torres-product-trio\"\u003eTorres’ Product Trio\u003c/h3\u003e\n\n\u003cp\u003eTeresa Torres’ Product Trio besteht aus \u003cstrong\u003eProduct Manager:in, UX-Designer:in und Engineer\u003c/strong\u003e. Die Idee: Alle drei betreiben Discovery gemeinsam – jede Rolle bringt ihre Perspektive ein, niemand ist nur Empfänger:in der Entscheidungen anderer. Das Trio trifft Discovery-Entscheidungen als kleine, handlungsfähige Einheit. Der Rest des Teams ist ausschließlich für Delivery zuständig.\u003c/p\u003e\n\n\u003cp\u003eDas Trio exploriert nicht beliebig. Das gewünschte Business Outcome wird typischerweise von außen vorgegeben. Das kann eine Metrik sein, ein strategisches Ziel oder ein Kundenproblem, das die Organisation lösen will. Innerhalb dieses Rahmens sucht das Trio nach Opportunities und entscheidet, welche Lösungen verfolgt werden. Die Autonomie liegt im Wie und Was – nicht im Warum. Alle drei Trio-Mitglieder nehmen regelmäßig an User Interviews, Opportunity Mapping, Annahmentests und Solution Ideation teil.\u003c/p\u003e\n\n\u003cp\u003eIn der Praxis scheiterte der Ansatz manchmal an einem einfachen Kapazitätsproblem: Der Engineer war oft stark in Delivery eingebunden und hatte weniger Zeit für Discovery als Product Manager:in und Designer:in. Die interne Trennung, die Torres überwinden wollte, reproduzierte sich unter dem Druck des Tagesgeschäfts. Delivery brauchte ein größeres Team – und wer liefert, hat keine Zeit für Discovery.\u003c/p\u003e\n\n\u003cp\u003eAgentic Development hebt diese Einschränkung auf – und macht damit möglich, was Torres ursprünglich vorschwebte.\u003c/p\u003e\n\n\u003ch3 id=\"das-agentic-trio\"\u003eDas Agentic Trio\u003c/h3\u003e\n\n\u003cp\u003eIm Agentic Trio übernimmt ein kleines Trio nicht nur Discovery, sondern auch Delivery. Das Trio arbeitet damit als vollständig autonome Einheit. Die Rollen sind dieselben wie bei Torres: Product Manager:in, UX-Designer:in, Engineer. Was sich ändert, ist der Umfang ihrer gemeinsamen Verantwortung. Alle drei machen Discovery und Delivery – ohne Unterstützung durch Teammitglieder, die nicht an der Discovery-Arbeit beteiligt sind.\u003c/p\u003e\n\n\u003cp\u003eDas verändert nicht nur, wie Teams arbeiten, sondern auch, wie Organisationen geschnitten werden können. Kleinere, autonomere Einheiten mit echter End-to-End-Verantwortung werden möglich, ohne Discovery-Qualität zu opfern. Die durch schnellere Delivery frei werdende Kapazität fließt nicht in mehr Output, sondern in tieferes Problemverständnis.\u003c/p\u003e\n\n\u003cp\u003e\u003cstrong\u003eEine Unterscheidung ist hier wichtig:\u003c/strong\u003e Das Agentic Trio und stream-aligned teams aus Team Topologies sind orthogonal. Team Topologies beantwortet, wie Teams strukturiert sind. Das Agentic Trio beantwortet, wie Discovery und Delivery innerhalb eines Teams organisiert sind. Im klassischen stream-aligned team – also dem, was Torres das Product Team nennt – könnte ein Teil des Teams das Trio bilden, während andere sich ausschließlich auf Delivery konzentrieren. Das Agentic Trio lässt genau diese interne Trennung zusammenfallen. Ein stream-aligned team ist keine notwendige Voraussetzung für Agentic Trios, aber in jedem Fall wünschenswert: Je mehr Entscheidungsautonomie das Trio hat, desto vollständiger kann es die verkürzten Zyklen von Agentic Development ausnutzen.\u003c/p\u003e\n\n\u003ch3 id=\"konvergenz-der-rollen\"\u003eKonvergenz der Rollen\u003c/h3\u003e\n\n\u003cp\u003eDas Agentic Trio verlangt von allen drei Rollen ein \u003cstrong\u003eT-förmiges Profil\u003c/strong\u003e: Jede Rolle behält ihr Tiefengebiet, aber die gemeinsame Basis wächst deutlich.\u003c/p\u003e\n\n\u003cp\u003eAuf der Delivery-Seite nutzen alle drei Rollen \u003cstrong\u003eCoding Agents\u003c/strong\u003e, um Lösungen umzusetzen. Product Manager:innen und Designer:innen werden zu aktiven Autor:innen und unabhängigen Produzent:innen. Prompting und die Arbeit mit Coding Agents werden zu Basiskompetenzen für alle Beteiligten – nicht nur für den Engineer, der weiterhin die Deep-Expert-Rolle bleibt.\u003c/p\u003e\n\n\u003cp\u003eAuf der Discovery-Seite nehmen alle drei gleichberechtigt an User Interviews, Opportunity Mapping, Solution Ideation und Annahmentests teil. Im idealen Product Trio war das immer das Ziel. Im Agentic Trio ist es erstmals ohne Kompromiss möglich, weil die Engineer-Rolle nicht mehr primär durch Delivery gebunden ist.\u003c/p\u003e\n\n\u003cp\u003eDie Konvergenz ist keine Einebnung. Product Manager:innen und Designer:innen müssen verstehen, was generierter Code leisten kann, wo Architekturentscheidungen Produktentscheidungen sind, wo Technical Debt die Strategie einschränkt. Der Engineer muss die Nutzerperspektive einnehmen, Probleme vor der Lösungsebene erfassen und Discovery-Methoden anwenden. Jede Rolle versteht mehr von den Spezialisierungen der anderen – aber die Tiefenbereiche bleiben unterschiedlich.\u003c/p\u003e\n\n\u003ch3 id=\"entwickler-innen-als-agent-harness-engineers\"\u003eEntwickler:innen als Agent Harness Engineers\u003c/h3\u003e\n\n\u003cp\u003eAuf der Delivery-Seite ist die Rolle des Engineers im Agentic Trio nicht primär die einer Produzent:in, sondern die einer Hüter:in der Fähigkeit, nachhaltig zu liefern – nicht nur heute, sondern auch in Zukunft – und damit sinnvolle Outcomes zu erzeugen. Seine oder ihre Kernaufgabe: das Bauen und Pflegen des \u003cstrong\u003eAgent Harness\u003c/strong\u003e, also der Infrastruktur, in der alle drei sicher und produktiv bauen können.\u003c/p\u003e\n\n\u003cp\u003eDer Harness umfasst maschinell durchgesetzte \u003cstrong\u003eQuality Gates\u003c/strong\u003e (Fitness Functions, Linter-Regeln, Architektur-Checks), spezialisierte Skills und Subagents für wiederkehrende Aufgaben, eine CI/CD-Pipeline, die keinen generierten Code ohne Gate in Produktion lässt, sowie Observability, Deployment und Monitoring. Der Engineer verantwortet nicht nur die Strukturen, sondern auch die Infrastruktur, die verhindert, dass agentisch generierter Code diese Strukturen untergräbt.\u003c/p\u003e\n\n\u003cp\u003eDaraus folgt eine wichtige Reihenfolge: Der Harness muss stehen, bevor Product Manager:innen und Designer:innen anfangen zu bauen. Sonst entsteht genau die Art von Debt, die Agentic Development in schlecht vorbereiteten Organisationen bereits produziert. Agent-Harness-Engineering ist daher eine der zentralen Schlüsselkompetenzen für Senior Engineers in der agentischen Ära. Entwickler:innen, die Guardrails definieren, Subagent-Repertoires kuratieren und Pipelines bauen, die agentischen Output zuverlässig absichern, sind nicht durch schnellere Code-Generierung ersetzbar. Sie sind diejenigen, die schnelle Code-Generierung überhaupt erst sicher machen.\u003c/p\u003e\n\n\u003cp\u003eÜber den Harness hinaus trägt der Engineer eine Verantwortung, die sich nicht automatisieren lässt: Er oder sie hält das mentale Modell des Systems. Peter Naur beschreibt in „Programming as Theory Building“, dass der eigentliche Kern von Softwareentwicklung nicht der Code ist, sondern die Theorie dahinter: das Verständnis, warum das System so gebaut ist, wie es gebaut ist, welche Entscheidungen welche Strukturen rechtfertigen, was eine Änderung an einer Stelle für andere bedeutet. Diese Theorie lebt in den Köpfen der Entwickler:innen, nicht im Code selbst.\u003c/p\u003e\n\n\u003cp\u003eIm Agentic Trio ist der Engineer die einzige Person, die diese Theorie halten kann und muss. Drei Personen und mehrere Agenten schreiben gleichzeitig in dasselbe System. \u003cstrong\u003eCode Review\u003c/strong\u003e durch den Engineer ist deshalb keine Qualitätskontrolle im bürokratischen Sinn, sondern der Mechanismus, durch den die Theorie aktuell bleibt. Er oder sie sieht, was erzeugt wurde, bewertet, ob es zur bestehenden Theorie passt, und korrigiert, wo es abweicht. Ohne das bricht die Code-Qualität ein – und die Theorie des Systems geht verloren.\u003c/p\u003e\n\n\u003ch3 id=\"discovery-als-verpflichtung-und-versprechen\"\u003eDiscovery als Verpflichtung und Versprechen\u003c/h3\u003e\n\n\u003cp\u003eDiscovery-Beteiligung ist im Agentic Trio keine optionale Erweiterung der Developer:innen-Rolle. Sie ist konstitutiv. Das wirkt auf zwei sehr unterschiedliche Gruppen jeweils anders.\u003c/p\u003e\n\n\u003cp\u003eFür Engineers, die schon immer Discovery machen wollten, aber nie die Zeit hatten, erfüllt das Agentic Trio ein altes Versprechen. Das Interesse an Nutzerproblemen, am Warum hinter dem Was, war bei diesen Engineers immer da. Delivery hat nur den größten Teil der Zeit aufgefressen.\u003c/p\u003e\n\n\u003cp\u003eFür Engineers, die bisher nicht in einem Product Trio waren und keine Discovery-Arbeit machen wollten, ist das eine neue Herausforderung. Die Rolle verändert sich fundamental.\u003c/p\u003e\n\n\u003cp\u003eEin letzter Punkt zu Juniors: Wenn wir eine neue Generation von Seniors aufbauen wollen, braucht es auch für sie einen expliziten Platz im Agentic Trio. Juniors arbeiten im Agentic Trio selten allein. Sie pairen – mit dem Senior Engineer beim Harness-Aufbau, mit der/dem Product Manager:in bei Discovery, mit der/dem Designer:in bei Solution Ideation und mit wechselnden Partner:innen in Delivery. Rotation durch alle Rollen ersetzt den klassischen Lernpfad des reinen Code-Schreibens. Juniors im Agentic Trio ähneln damit Trainees, die durch unterschiedliche Perspektiven und Rollen gehen. Das Ergebnis ist eine breitere Ausbildung als bisher. Und die Entscheidung über Spezialisierung fällt später und bewusster: Wer alle Bereiche erlebt hat, weiß besser, wo die eigene T-förmige Tiefe liegen sollte.\u003c/p\u003e\n\n\u003cp\u003e\u003cstrong\u003eDas Agentic Trio ist keine Blaupause für jede Organisation und jeden Kontext.\u003c/strong\u003e Es ist eine Antwort auf die Frage, wie man Produktentwicklung so organisiert, dass schnellere Delivery tatsächlich zu besseren Outcomes führt – nicht nur zu mehr Auslastung, mehr Review-Last und mehr Bugs in Produktion. Die Antwort, die das Agentic Trio gibt: indem man die frei werdende Kapazität bewusst in Discovery investiert – in einer kleinen Einheit, die beides besitzt. Nicht sequenziell, nicht in getrennten Strukturen, sondern kontinuierlich und gemeinsam.\u003c/p\u003e\n\u003c/body\u003e\u003c/html\u003e\n","image":"https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2000/v1/uploads-production/emi16iffqg3gzp47gwm9s69g4l7u?_a=BACMTiAE"},{"id":"https://www.innoq.com/de/blog/2026/05/rag-und-fine-tuning-gemeinsam-stark/","url":"https://www.innoq.com/de/blog/2026/05/rag-und-fine-tuning-gemeinsam-stark/","date_published":"2026-05-21T00:00:00.000+00:00","date_modified":"2026-05-18T18:55:39.304+02:00","author":[{"name":"Marco Steinke","url":"https://www.innoq.com/ch/staff/marco-steinke/"}],"content_html":"\u003c!DOCTYPE html PUBLIC \"-//W3C//DTD HTML 4.0 Transitional//EN\" \"http://www.w3.org/TR/REC-html40/loose.dtd\"\u003e\n\u003chtml\u003e\u003cbody\u003e\n\u003ch3 id=\"kurzuberblick-rag-und-fine-tuning\"\u003eKurzüberblick: RAG und Fine-Tuning\u003c/h3\u003e\n\n\u003cp\u003eRAG versorgt ein LLM zur Laufzeit mit externem Wissen – zum Beispiel Wiki-Seiten, Handbüchern oder Produktdokumentationen. Das System sucht relevante Dokumente und übergibt sie als Kontext. Das reduziert Halluzinationen und macht Antworten nachvollziehbar, weil Quellen angegeben und nachgeschlagen werden können.\u003c/p\u003e\n\n\u003cp\u003eFine-Tuning formt das Verhalten eines Modells anhand von Beispielen. Es vermittelt dabei nicht zwingend neues Wissen, kann aber das Modell darin schulen, domänenspezifische Sprache zu verwenden, Antworten in einem gewünschten Format auszugeben und Anweisungen zuverlässiger zu befolgen – etwa bei der Datenextraktion oder Dokumentenklassifikation.\u003c/p\u003e\n\n\u003cp\u003eAllein optimieren beide Ansätze für unterschiedliche Zielbilder. Gemeinsam addieren sich ihre Effekte, vorausgesetzt der Use-Case und die verfügbaren Daten stimmen.\u003c/p\u003e\n\n\u003cp\u003eIn diesem Artikel setzen wir Fine-Tuning mit Supervised Fine-Tuning gleich. «Supervised» bedeutet: Das Modell erhält beim Training zu jedem Prompt eine oder mehrere erwartete Antworten.\u003c/p\u003e\n\n\u003ch3 id=\"der-use-case-wissensabfragen-bei-einer-versicherung\"\u003eDer Use Case: Wissensabfragen bei einer Versicherung\u003c/h3\u003e\n\n\u003cp\u003eEine Versicherung nutzt ein LLM, damit Mitarbeitende einfacher auf das interne Wiki zugreifen können. Typische Fragen sind: Welche Regelung gilt für Tarif X? Wo finde ich Informationen zur Schadenklasse Y? Fasse die wichtigsten Punkte aus Richtlinie Z zusammen.\u003c/p\u003e\n\n\u003cp\u003eTechnisch läuft das folgendermaßen: Das Wiki wird indexiert und in einer Datenquelle abgelegt. Die Datenquelle kann dabei beliebig sein, zum Beispiel eine Vektordatenbank, ein MCP-Server oder eine relationale Datenbank. Eine RAG-Pipeline sucht zu jeder Anfrage passende Seiten und übergibt diese als Kontext an das LLM, das daraus Antworten oder Zusammenfassungen erzeugt.\u003c/p\u003e\n\n\u003ch3 id=\"das-problem\"\u003eDas Problem\u003c/h3\u003e\n\n\u003cp\u003eFormal funktioniert das System. Die richtigen Seiten liegen im Kontext. In der Praxis zeigt sich aber: Das LLM übersieht relevante Dokumente, überbewertet irrelevante Textstellen, und Antworten bleiben lückenhaft oder greifen falsche Passagen auf.\u003c/p\u003e\n\n\u003cp\u003eDer Fehler liegt hier nicht im Retrieval, sondern in der Kontextnutzung bei der Generierung. Das bedeutet: Das Modell bekommt die richtigen Dokumente geliefert, weiß aber nicht zuverlässig, welches davon für die konkrete Frage entscheidend ist. Es fehlt nicht an Informationen – es fehlt an der Fähigkeit, diese im Kontext zu priorisieren, zu gewichten und korrekt zu zitieren.\u003c/p\u003e\n\n\u003ch3 id=\"von-rag-ausgaben-zu-fine-tuning-daten\"\u003eVon RAG-Ausgaben zu Fine-Tuning-Daten\u003c/h3\u003e\n\n\u003cp\u003eIm Produktivbetrieb enthält jede beantwortete Anfrage bereits alle Bausteine für Fine-Tuning. Für jede Anfrage protokolliert das System das Prompt, die geladenen Dokumente mit ihrer Quellenreferenz, die finale Modellantwort und optionales Nutzer-Feedback – ob akzeptiert, abgelehnt, korrigiert oder als Freitext.\u003c/p\u003e\n\n\u003cp\u003eDiese Elemente werden zu Fine-Tuning-Beispielen aufbereitet, die dem Modell beibringen, wie Kontext zu nutzen ist – nicht was die richtige Tatsache ist.\u003c/p\u003e\n\n\u003ch3 id=\"der-schlussel-feedback-aus-der-produktion\"\u003eDer Schlüssel: Feedback aus der Produktion\u003c/h3\u003e\n\n\u003cp\u003eDie Versicherung sammelt systematisch Rückmeldungen. Nutzende bewerten Antworten als hilfreich oder nicht hilfreich, markieren falsche oder unvollständige Ergebnisse und geben Freitextfeedback, um Antworten zu verbessern. So entsteht ein Datensatz aus Prompts, Kontextdokumenten sowie bevorzugten und abgelehnten Antworten.\u003c/p\u003e\n\n\u003cp\u003eDieser Feedback-Loop ist zentral, um das System auf lange Sicht zu stabilisieren. Entscheidend ist hier, dass Nutzende aktiv dazu angeleitet werden müssen Feedback zu geben. Klare Hinweise über die Relevanz von Feedback, Möglichkeiten, ohne großen Mehraufwand direkt im System Feedback zu geben und strukturelle Vorgaben für das Feedback sorgen dafür, dass der Feedback-Loop tatsächlichen Mehrwert liefern kann.\u003c/p\u003e\n\n\u003cp\u003eSollte nicht klar sein, warum und in welcher Form Feedback helfen kann, oder der Aufwand dafür zu groß sein, werden Nutzende schnell demotiviert und der Feedback-Loop könnte zusammenbrechen.\u003c/p\u003e\n\n\u003ch3 id=\"der-fine-tuning-datensatz-aus-der-praxis\"\u003eDer Fine-Tuning-Datensatz (aus der Praxis)\u003c/h3\u003e\n\n\u003cfigure\u003e\r\n\u003cimg alt=\"Geeigneter Fine-Tuning-Datensatz: Das Prompt, mehrere geladene Dokumente und eine erwartete Antwort – mit expliziter Angabe, welches Dokument tatsächlich verwendet wurde.\" loading=\"lazy\" srcset=\"https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_400/v1/uploads-production/1zqga20yqbgx2w4u85ohgblws6op?_a=BACMTiAE 400w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_800/v1/uploads-production/1zqga20yqbgx2w4u85ohgblws6op?_a=BACMTiAE 800w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_1024/v1/uploads-production/1zqga20yqbgx2w4u85ohgblws6op?_a=BACMTiAE 1024w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_1200/v1/uploads-production/1zqga20yqbgx2w4u85ohgblws6op?_a=BACMTiAE 1200w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_1600/v1/uploads-production/1zqga20yqbgx2w4u85ohgblws6op?_a=BACMTiAE 1600w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2048/v1/uploads-production/1zqga20yqbgx2w4u85ohgblws6op?_a=BACMTiAE 2048w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2300/v1/uploads-production/1zqga20yqbgx2w4u85ohgblws6op?_a=BACMTiAE 2300w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2600/v1/uploads-production/1zqga20yqbgx2w4u85ohgblws6op?_a=BACMTiAE 2600w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2800/v1/uploads-production/1zqga20yqbgx2w4u85ohgblws6op?_a=BACMTiAE 2800w\" sizes=\"(min-width: 1400px) 1024px, 90vw\"\u003e\r\n\r\n\u003cfigcaption\u003eGeeigneter Fine-Tuning-Datensatz: Das Prompt, mehrere geladene Dokumente und eine erwartete Antwort – mit expliziter Angabe, welches Dokument tatsächlich verwendet wurde.\u003c/figcaption\u003e\u003c/figure\u003e\r\n\n\u003cp\u003eEntscheidend ist: In diesem Datenpunkt liegen mehrere Dokumente im Kontext, aber nur eines wird in der Antwort referenziert. Das Modell lernt dabei, korrekt auszuwählen, zu priorisieren und zu zitieren – nicht die Dokumentation auswendig zu lernen, sondern Kontextunterscheidung unter RAG-Bedingungen. Damit adressiert das Fine-Tuning direkt den beobachteten Fehler: Relevante Dokumente werden gefunden, aber bei der Generierung falsch genutzt.\u003c/p\u003e\n\n\u003ch3 id=\"fine-tuning-mit-direct-preference-optimization\"\u003eFine-Tuning mit Direct Preference Optimization\u003c/h3\u003e\n\n\u003cp\u003eStatt klassischem Supervised Fine-Tuning nutzt die Versicherung Direct Preference Optimization (DPO). DPO ist eine Variante des Fine-Tunings, bei der das Modell nicht nur lernt, was eine gute Antwort ist, sondern gleichzeitig, was eine schlechte Antwort auszeichnet. Zu jedem Prompt erhält das Modell beim Training eine bevorzugte und mehrere abgelehnte Antworten. Dadurch werden nicht nur gute Antworten hervorgehoben, sondern schlechte auch messbar seltener.\u003c/p\u003e\n\n\u003cp\u003eDas hat für diesen Use-Case einen entscheidenden Vorteil: Der Fokus liegt auf Entscheidungen, nicht auf Fakten. Das Modell lernt, welche Dokumente bei welchen Prompts relevant sind, wie stark es sie gewichten soll und wann es Informationen ignorieren muss. Es lernt nicht das Wiki auswendig – es lernt, den gelieferten Kontext richtig zu nutzen.\u003c/p\u003e\n\n\u003ch3 id=\"warum-rag-und-fine-tuning-harmonieren-konnen\"\u003eWarum RAG und Fine-Tuning harmonieren können\u003c/h3\u003e\n\n\u003cp\u003eRAG und Fine-Tuning lösen unterschiedliche Probleme: RAG liefert den Kontext und nachvollziehbare Quellenangaben, weil es direkt auf aktuelle und von uns bereitgestellte Daten zugreift. Fine-Tuning mit DPO steuert, wie das Modell mit diesem Kontext umgeht, und stabilisiert das Verhalten auf Grundlage realer Nutzungspräferenzen. Zusammen ergänzen sie sich, indem das bereitgestellte Unternehmenswissen zuverlässiger für Antworten verwendet wird.\u003c/p\u003e\n\n\u003ch3 id=\"fazit\"\u003eFazit\u003c/h3\u003e\n\n\u003cp\u003eWer LLMs dauerhaft in einem ähnlichen Use-Case einsetzen will, sollte zum Einen RAG und Fine-Tuning nicht als konkurrierende Alternativen ansehen, sondern wissen, dass sie auch kombiniert werden können. Außerdem sollte man Fine-Tuning nicht exklusiv als einmaligen Trainingslauf betrachten. Es ist ein kontinuierlicher Prozess, eng gekoppelt an die reale Nutzung. Der Fine-Tuning-Datensatz muss regelmäßig aktualisiert werden, der Human-Feedback-Loop aufrechterhalten bleiben. Nur so wird das System auf lange Sicht zuverlässiger und trifft auch bei neuen Dokumenten bessere Entscheidungen.\u003c/p\u003e\n\u003c/body\u003e\u003c/html\u003e\n","image":"https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2000/v1/uploads-production/q1f1xs5m5rp9gni0upaawuj91yd1?_a=BACMTiAE"},{"id":"https://www.innoq.com/de/blog/2026/05/ein-prozent-methode-fuer-code-und-architektur/","url":"https://www.innoq.com/de/blog/2026/05/ein-prozent-methode-fuer-code-und-architektur/","date_published":"2026-05-13T00:00:00.000+00:00","date_modified":"2026-05-13T14:43:25.364+02:00","author":[{"name":"Michael Plöd","url":"https://www.innoq.com/ch/staff/michael-ploed/"}],"content_html":"\u003c!DOCTYPE html PUBLIC \"-//W3C//DTD HTML 4.0 Transitional//EN\" \"http://www.w3.org/TR/REC-html40/loose.dtd\"\u003e\n\u003chtml\u003e\u003cbody\u003e\n\u003cp\u003eIn Kundengesprächen höre ich quer durch alle Branchen fast jede Woche dieselben drei Sätze:\u003c/p\u003e\n\n\u003cp\u003e\u003cem\u003e„Wir wollen ja modernisieren, aber das Tagesgeschäft kommt immer dazwischen.\"\u003c/em\u003e\u003c/p\u003e\n\n\u003cp\u003e\u003cem\u003e„Das System ist so kaputt, da hilft nur noch ein Big Bang.\"\u003c/em\u003e\u003c/p\u003e\n\n\u003cp\u003e\u003cem\u003e„Die technischen Schulden wachsen schneller, als wir sie abbauen können.\"\u003c/em\u003e\u003c/p\u003e\n\n\u003cp\u003eDas sieht nach drei verschiedenen Problemen aus. Ist es aber nicht. Es sind drei Symptome derselben Überzeugung: dass Modernisierung etwas ist, was man \u003cem\u003egetrennt\u003c/em\u003e von der eigentlichen Software-Entwicklung macht. Ein Projekt. Eine Budgetposition. Ein Programm mit Lenkungsausschuss. Etwas, das ein ruhiges Quartal braucht, ein strategisches Alignment und ein Foliendeck, das jemand zwei Ebenen weiter oben abnickt.\u003c/p\u003e\n\n\u003cp\u003eGenau diese Überzeugung ist das Problem. Und sie ist auch der Grund, warum sich nichts in eine gesunde Richtung bewegt.\u003c/p\u003e\n\n\u003ch3 id=\"das-modernisierungs-paradox\"\u003eDas Modernisierungs-Paradox\u003c/h3\u003e\n\n\u003cp\u003eDas Gespräch endet meistens auch immer gleich: \u003cem\u003e„Wir bräuchten dringend ein großes Aufräumen, aber gerade jetzt geht das nicht.\"\u003c/em\u003e\u003c/p\u003e\n\n\u003cp\u003eGerade jetzt steht ein Termin an. Gerade jetzt hatten wir einen Ausfall. Gerade jetzt liegt ein Feature auf dem Tisch, das das Business bereits zugesagt hat, ohne vorher jemanden zu fragen, ob die Codebasis das überhaupt trägt. Gerade jetzt ist der falsche Zeitpunkt, nächstes Quartal wird der richtige sein. Und nächstes Quartal kommt wieder mit seiner eigenen Variante von „gerade jetzt\".\u003c/p\u003e\n\n\u003cp\u003eAus meiner Erfahrung heraus dauert dieses „gerade jetzt\" manchmal Jahre.\u003c/p\u003e\n\n\u003cp\u003eWährend dieser Zeit wird das System immer schlechter. Module, die früher leicht zu verstehen waren, werden komplexer. Grenzen, die einmal klar gezogen waren, verschwimmen. TODO-Kommentare häufen sich. Die Dokumentation entfernt sich immer weiter von dem, was der Code tatsächlich tut. Tests werden im Build deaktiviert, weil niemand Lust hat, sich um die wackligen zu kümmern. Jede einzelne dieser Entscheidungen ist für sich genommen nachvollziehbar. In Summe ergeben sie eine Abwärtsspirale, die sich selbst verstärkt.\u003c/p\u003e\n\n\u003cp\u003eDas ist das Paradox: Je länger wir auf den richtigen Moment warten, desto größer muss die Modernisierung werden. Je größer sie werden muss, desto riskanter wird jede Änderung. Und je riskanter jede Änderung wird, desto schwieriger wird es, irgendetwas mit Vertrauen zu testen. Damit wird es immer unwahrscheinlicher, dass wir einen Moment finden, der groß genug, sicher genug und testbar genug ist. Die Projekt-Denkweise legt die Latte so hoch, dass die Latte selbst zum Hindernis wird.\u003c/p\u003e\n\n\u003cp\u003eDas System, das eine sechsmonatige Aufräumaktion bräuchte, wird diese sechs Monate nicht bekommen, sei es aus politischen Gründen, wegen Budgetdruck oder weil Features Vorrang haben. Ich höre den Satz schon: \u003cem\u003e„Wir bezahlen für Features, nicht für Refactorings.\"\u003c/em\u003e Stattdessen bekommt das System eine Reihe hektischer Drei-Tage-Pflaster und mit jedem Pflaster wird die eigentliche Aufräumaktion ein Stück schwieriger.\u003c/p\u003e\n\n\u003ch3 id=\"modernisierung-im-rhythmus-nicht-im-big-bang\"\u003eModernisierung im Rhythmus, nicht im Big Bang\u003c/h3\u003e\n\n\u003cp\u003eIch möchte einen anderen Blick auf Modernisierung vorschlagen.\u003c/p\u003e\n\n\u003cp\u003eAnforderungen ändern sich ständig. Teams ändern sich ständig, weil Menschen kommen, gehen, rotieren und dazulernen. Auch die Systeme, die wir bauen, ändern sich, sogar wenn wir sie gar nicht anfassen, weil sich die Welt um sie herum bewegt. Jedes Dependency-Update, jede neue Compliance-Regel, jede verschobene Business-Priorität setzt die Architektur ein bisschen unter Druck.\u003c/p\u003e\n\n\u003cp\u003eWenn sich also alles um das System herum permanent ändert, kann das Gesundhalten dieses Systems kein einmaliges Ereignis sein. Eine Modernisierung, die alle vier Jahre gegen eine Welt antritt, die sich alle vier Wochen ändert, wird immer hinterherhinken.\u003c/p\u003e\n\n\u003cp\u003eKontinuierliche Modernisierung ist also kein Projekt, das wir einmal durchziehen. Sie ist eine kleine, stetige Praxis, die das Team jeden Tag in winzigen Schritten ausführt, ungefähr in dem Tempo, in dem Veränderung auf das Team einwirkt.\u003c/p\u003e\n\n\u003cp\u003eDas Reframing klingt klein, ist es aber nicht. Es verschiebt Modernisierung aus der Kategorie der Dinge, die wir \u003cem\u003eplanen\u003c/em\u003e, in die Kategorie der Dinge, die wir \u003cem\u003etun\u003c/em\u003e. Modernisierung ist dann kein Punkt mehr auf einer Roadmap, sondern wird Teil davon, wie das Team arbeitet. Und wenn sie Teil davon ist, wie das Team arbeitet, konkurriert sie nicht mehr mit dem Tagesgeschäft, weil sie \u003cem\u003eTeil\u003c/em\u003e des Tagesgeschäfts ist. Kein Spektakel, kein Kickoff, keine große Enthüllung. Einfach nur die Arbeit, ein Stück besser gemacht als gestern. Architektur entsteht ohnehin in dem, was das Team jeden Tag tut, nicht in dem, was es einmal plant. Der Rest dieses Beitrags handelt davon, was passiert, wenn man sich diesem Gedanken bewusst stellt.\u003c/p\u003e\n\n\u003ch3 id=\"was-laufen-mit-code-zu-tun-hat\"\u003eWas Laufen mit Code zu tun hat\u003c/h3\u003e\n\n\u003cp\u003eStell Dir vor, Du beschließt, mit dem Laufen anzufangen. Du hast seit Jahren keinen Sport mehr gemacht. Am ersten Tag läufst Du nicht wirklich, weil das wehtun würde. Du gehst zehn Minuten zügig spazieren. Das ist unspektakulär. Du legst kaum eine Strecke zurück und nichts an diesen zehn Minuten macht Dich zu einer Athletin oder einem Athleten.\u003c/p\u003e\n\n\u003cp\u003eAm nächsten Tag machst Du dasselbe. Und am Tag danach. Nach ein, zwei Wochen fällt Dir der zügige Spaziergang leichter und Du beginnst, hier und da eine Minute langsames Joggen einzustreuen. Nach einem Monat schaffst Du fünf Minuten am Stück. Nach drei Monaten läufst Du eine halbe Stunde durch. Nach sechs Monaten ist ein 10 km Lauf am Wochenende ein realistisches Ziel. Nach einem Jahr peilst Du vielleicht einen Halbmarathon an.\u003c/p\u003e\n\n\u003cp\u003eKeine einzelne dieser Trainingseinheiten war bemerkenswert. Bemerkenswert war der Zinseszinseffekt.\u003c/p\u003e\n\n\u003cp\u003eDas ist die Grundidee der 1%-Methode, die James Clear in seinem Buch \u003cem\u003eAtomic Habits\u003c/em\u003e populär gemacht hat. Das Argument ist einfach: Kleine Änderungen, die für sich genommen unbedeutend wirken, führen über die Zeit zu erstaunlichen Ergebnissen. Clear schreibt darüber vor allem im Kontext persönlicher Gewohnheiten. Was ich in diesem Beitrag versuchen möchte, ist diese Idee dorthin zu übertragen, wo Clear nicht hingegangen ist: in die Architektur von Software-Systemen, die von Teams gebaut werden.\u003c/p\u003e\n\n\u003cp\u003eStell Dir vor, jedes Mitglied eines Teams investiert ungefähr zehn Minuten pro Tag in etwas Kleines. Ein Naming verbessern, sodass des dem entspricht, wie das Business die Sache wirklich nennt. Eine Methode extrahieren. Toten Code löschen. Einen fehlenden Test ergänzen. Eine Dependency aktualisieren. Eine Warnung beheben. Einen Absatz Dokumentation verbessern. Ein veraltetes Konfigurations-Flag entfernen.\u003c/p\u003e\n\n\u003cp\u003eNichts davon ist für sich genommen beeindruckend. Nichts davon verdient ein Jira-Ticket. Nichts davon würde in einem Priorisierungsmeeting gegen einen Feature-Wunsch bestehen. Und genau das ist der Punkt. Diese Aktivitäten sind zu klein, um mit dem Tagesgeschäft zu konkurrieren, und genau deshalb können sie tatsächlich neben dem Tagesgeschäft passieren. Sie passieren leise, unter dem Radar, in den Randzeiten des Tages.\u003c/p\u003e\n\n\u003cp\u003e(Ein kleiner Hinweis am Rande: Wenn Du in einem Umfeld arbeitest, in dem jemand Deine Arbeit in Zehn-Minuten-Einheiten misst, wird Dir dieser Beitrag nicht weiterhelfen. Mein Rat in diesem Fall ist ein anderer: lauf, wenn möglich.)\u003c/p\u003e\n\n\u003cp\u003eKleine Verbesserungen sind leicht zu tun. Sie sind aber auch leicht \u003cem\u003enicht\u003c/em\u003e zu tun. Und sie sind unmöglich zu ignorieren, sobald sie sich aufaddieren.\u003c/p\u003e\n\n\u003ch3 id=\"warum-gute-vorsatze-eine-falle-sind\"\u003eWarum gute Vorsätze eine Falle sind\u003c/h3\u003e\n\n\u003cp\u003eWenn Du mit Entwickler:innen über das Thema sprichst, sind sich fast alle einig. Wir \u003cem\u003esollten\u003c/em\u003e den Code jeden Tag ein bisschen verbessern. Wir \u003cem\u003esollten\u003c/em\u003e kleine Refactorings machen, wenn wir an einer Stelle sowieso unterwegs sind. Wir \u003cem\u003esollten\u003c/em\u003e nicht zulassen, dass kleine Probleme so lange wachsen, bis sie zu großen werden. Niemand widerspricht dem Prinzip. Ich habe noch nie eine Entwicklerin oder einen Entwickler erlebt, die oder der gegen die Idee kontinuierlicher kleiner Verbesserungen argumentiert hätte.\u003c/p\u003e\n\n\u003cp\u003eUnd trotzdem tun es die meisten Teams nicht.\u003c/p\u003e\n\n\u003cp\u003eDer Grund ist nicht, dass Entwickler:innen faul oder undiszipliniert wären. Der Grund ist, dass Vorsätze unter Druck nicht halten. Schau Dir eine ganz normale Woche in einem Delivery-Team an. Da gibt es Bereitschaftsdienst. Da gibt es kritische Produktions-Bugs. Da gibt es ein Sprint-Ziel, das schon Dienstag anfängt zu rutschen. Da gibt es die \u003cem\u003e„Bitte ASAP noch dieses eine Feature\"\u003c/em\u003e-Anfrage von einer Stakeholderin oder einem Stakeholder, die oder der einer Kundin oder einem Kunden etwas zugesagt hat, ohne vorher zu fragen. Eine Kollegin ist im Urlaub. Ein Kollege ist krank. Eine andere Kollegin hat Dir gerade gesagt, dass sie in sechs Wochen das Team verlässt. Der Release-Termin verschiebt sich nicht. Die Roadmap wird nicht kleiner. Und der Termin, der vor zwei Monaten noch entspannt aussah, fühlt sich jetzt knapp an.\u003c/p\u003e\n\n\u003cp\u003eIn so einer Woche findet die kleine Verbesserung nicht statt. Nicht weil die Entwicklerin oder der Entwickler sie vergessen hätte und auch nicht, weil es sie oder ihn nicht interessieren würde. Sie findet nicht statt, weil das fünfminütige Refactoring in dem Moment zwischen Produktions-Bug und rutschendem Sprint das Einfachste ist, was man von der Liste streichen kann. Es gibt immer etwas Dringenderes.\u003c/p\u003e\n\n\u003cp\u003eDas ist die Falle. Wenn das Verbessern von Code oder Architektur von Motivation und guten Vorsätzen abhängt, sehen unsere Codebasen am Ende aus wie Fitnessstudios im März. Voll mit guten Absichten im Januar, halb leer im Februar, im Frühjahr mehr oder weniger verlassen. Die Absicht war echt. Die Struktur, sie zu tragen, war es nicht.\u003c/p\u003e\n\n\u003cp\u003eDie Lösung ist nicht mehr Motivation. Die Lösung ist eine Struktur, die Motivation überflüssig macht.\u003c/p\u003e\n\n\u003ch3 id=\"du-hast-bereits-gewohnheiten\"\u003eDu hast bereits Gewohnheiten\u003c/h3\u003e\n\n\u003cp\u003eWenn ich Vorträge zu diesem Thema halte, stelle ich dem Publikum oft eine Frage: \u003cem\u003e„Was ist das Erste, was Du an Deinem Rechner machst, wenn Du morgens am Schreibtisch sitzt?\"\u003c/em\u003e\u003c/p\u003e\n\n\u003cp\u003eDie Antworten sind fast immer dieselben. E-Mails checken. Slack öffnen. Teams öffnen. In den Kalender schauen.\u003c/p\u003e\n\n\u003cp\u003eDann sage ich: \u003cem\u003e„Glückwunsch, Du hast eine Gewohnheit.\"\u003c/em\u003e\u003c/p\u003e\n\n\u003cp\u003eDu bist ins Büro gekommen. Du hast Dir einen Kaffee geholt. Du hast Dich an Deinen Schreibtisch gesetzt. Du hast Deinen Laptop aufgeklappt. Du hast Slack geöffnet. Du hast nicht bewusst entschieden, Slack zu öffnen. Du hast Dich nicht selbst dazu motiviert. Du hast Dir nicht am Vorabend „Slack öffnen\" auf die To-do-Liste geschrieben. Du hast es einfach getan, weil die Kette kleiner Aktionen davor Dich dort hingezogen hat. Der Auslöser war der aufgeklappte Laptop. Die Reaktion war der Klick auf Slack. Die Belohnung war der kleine Hit von \u003cem\u003e„jetzt weiß ich, was los ist.\"\u003c/em\u003e\u003c/p\u003e\n\n\u003cp\u003eGewohnheiten brauchen keine Vorsätze. Genau das ist ihr Sinn. Sie laufen auf einer Schiene, die das Gehirn schon angelegt hat, sodass das bewusste Denken keine Energie mehr darauf verwenden muss.\u003c/p\u003e\n\n\u003cp\u003eHier mein Vorschlag, den ich an dieser Stelle im Vortrag immer gebe: Fang bei Dir selbst an. Morgen früh, bevor Du Slack öffnest, investierst Du zehn Minuten in eine kleine Code-Verbesserung. Benenne eine missverständliche Variable um. Lösche eine tote Methode. Schreib den Test, den Du schon ewig schreiben wolltest. Dann öffnest Du Slack. Leg Dir eine kleine Habit-Card auf den Schreibtisch und hak sie ab, wenn Du fertig bist. Mach das zwei Wochen lang, allein, ohne es jemandem zu sagen. Du brauchst dafür keine Erlaubnis. Du brauchst kein Meeting. Du brauchst kein Ticket. Du musst es einfach nur vor Slack in Deine Morgenroutine packen.\u003c/p\u003e\n\n\u003cp\u003eZwei Dinge werden passieren. Erstens wirst Du spüren, wie sich die kleinen täglichen Verbesserungen in den Teilen der Codebasis anhäufen, an denen Du arbeitest. Zweitens, und das ist der spannendere Teil, wird jemand im Team es bemerken. Die Habit-Card auf Deinem Schreibtisch. Den ungewöhnlich sauberen Diff in Deinem Pull Request. Die Dependency, die Du letzte Woche stillschweigend entfernt hast. Menschen sind neugierig. Sie werden fragen. Und sobald sie fragen, hast Du ein Gespräch und keinen Vertriebspitch.\u003c/p\u003e\n\n\u003cp\u003eSo skaliert das Ganze. Nicht über ein Kickoff-Meeting. Nicht über eine Prozessänderung. Eine Person fängt an, das Team wird neugierig und die Praxis verbreitet sich seitwärts. Damit sie sich aber wirklich festsetzt, muss aus der individuellen Gewohnheit eine \u003cem\u003eTeam\u003c/em\u003e-Gewohnheit werden, nicht nur eine Sammlung einzelner. Und das ist eine andere Design-Aufgabe.\u003c/p\u003e\n\n\u003ch3 id=\"von-personlichen-gewohnheiten-zu-team-gewohnheiten\"\u003eVon persönlichen Gewohnheiten zu Team-Gewohnheiten\u003c/h3\u003e\n\n\u003cp\u003eEine persönliche Gewohnheit muss nur Deine eigenen schlechten Tage überstehen. Eine Team-Gewohnheit muss die schlechten Tage aller Beteiligten gleichzeitig überstehen.\u003c/p\u003e\n\n\u003cp\u003eDas klingt wie ein kleiner Unterschied, ist aber keiner. Die persönliche Gewohnheit scheitert, wenn Du müde, abgelenkt oder im Stress bist. Die Team-Gewohnheit scheitert, wenn \u003cem\u003eirgendjemand\u003c/em\u003e im Team müde, abgelenkt oder genug im Stress ist, um sie auszulassen. Dann sieht es die nächste Person und das Ritual verliert an Gewicht. Innerhalb von zwei Wochen ist die Gewohnheit etwas, was das Team früher mal gemacht hat. Niemand hat entschieden aufzuhören. Es hat einfach aufgehört.\u003c/p\u003e\n\n\u003cp\u003eManchmal entscheidet auch jemand aktiv, dass das Team aufhört. Es gibt immer eine Senior-Person, die sagt \u003cem\u003e„heute nicht, wir haben einen Termin\"\u003c/em\u003e, und das Team folgt, weil die Senior-Person Autorität hat. Aus einem ausgelassenen Tag werden zwei, dann eine Woche, und die Gewohnheit ist weg. Mir ist auch noch etwas Subtileres aufgefallen: Die Menschen, die am stärksten gegen diese kleinen Verbesserungen anschreiben, sind manchmal genau die, die ihren Status daraus ziehen, alle dunklen Ecken der Codebasis zu kennen. Das Chaos macht sie unentbehrlich. Eine sauberere Codebasis, in der sich alle zurechtfinden, bedroht diese Position leise. Das ist selten bewusst, aber es ist real und es lohnt sich, es auszusprechen.\u003c/p\u003e\n\n\u003cp\u003eEine Team-Gewohnheit muss also anders gestaltet werden als eine persönliche. Sie muss in etwas eingebettet sein, was das Team ohnehin gemeinsam tut, sodass keine Einzelperson sich daran erinnern muss. Sie muss die Person überstehen, die gerade Bereitschaft hat. Sie muss den Workshop am Mittwoch überstehen. Sie muss die neue Kollegin überstehen, die noch nicht von ihr gehört hat. Die Struktur trägt die Gewohnheit, nicht die Willenskraft der Menschen darin.\u003c/p\u003e\n\n\u003cp\u003eClear gibt uns in \u003cem\u003eAtomic Habits\u003c/em\u003e vier hilfreiche Design-Regeln für Gewohnheiten: Mach den Auslöser offensichtlich, mach das Verlangen attraktiv, mach die Reaktion einfach und mach die Belohnung befriedigend. Diese Regeln lassen sich auf Team-Gewohnheiten übertragen, müssen aber auf \u003cem\u003eTeam\u003c/em\u003e-Artefakte gerichtet werden, nicht auf persönliche. Der Auslöser hängt nicht an Deinem Badezimmerspiegel. Er steht in Eurem Pull-Request-Template. Die Belohnung ist nicht ein Gefühl am Ende des Tages. Sie ist eine Metrik auf einem Dashboard, das alle im Team sehen.\u003c/p\u003e\n\n\u003cp\u003eEin persönliches Beispiel: Ich habe mein Peloton-Bike in unser Wohnzimmer gestellt, nicht in ein Gästezimmer und auch nicht in den Keller. Direkt mitten dort, wo ich meine Abende verbringe. Ich bin dadurch nicht motivierter geworden zu trainieren. Ich habe nur den Auslöser unmöglich zu ignorieren gemacht. Jedes Mal, wenn ich daran vorbeigehe, fragt es mich leise, ob heute der Tag ist. Das funktioniert erstaunlich gut. Dasselbe Prinzip lässt sich auf Teams anwenden.\u003c/p\u003e\n\n\u003cp\u003eHier ist, wie die vier Regeln aussehen, sobald man sie auf ein Team richtet:\u003c/p\u003e\n\n\u003cp\u003e\u003cstrong\u003eMach es offensichtlich.\u003c/strong\u003e Der Auslöser lebt in den Artefakten, die das Team ohnehin täglich anfasst. Eine Zeile im Pull-Request-Template, die fragt: „Hast Du diesen Code ein bisschen besser hinterlassen, als Du ihn gefunden hast?\" Ein sichtbares Improvement-Backlog am Team-Board. Eine kurze Slack-Erinnerung, dass die Doku-Minute nach dem Standup beginnt. Ein Architektur-Dashboard auf einem Bildschirm, an dem alle vorbeigehen. Der Auslöser muss unmöglich zu übersehen sein.\u003c/p\u003e\n\n\u003cp\u003eUnd für die Tage, an denen jemand denkt \u003cem\u003e„ich will meine zehn Minuten machen, aber mir fällt nichts ein, was ich anfassen könnte\"\u003c/em\u003e: Hängt ein Flipchart oder ein Miro-Board mit kleinen Verbesserungsideen auf, zu dem jede Person im Team etwas beitragen kann. Diese Klasse umbenennen. Jene unbenutzte Konfigurations-Datei löschen. Einen Test für diesen Edge Case ergänzen. Manche Teams, mit denen ich arbeite, vergeben dort anonymisierte Namen wie „Batgirl\", „Princess Peach\", „Super Mario\" oder „Mr. Burns\". Das hält die Sache spielerisch und verhindert, dass das Board zu einem Tracking-Werkzeug verkommt. Das Board ist immer voll, weil jede Entwicklerin und jeder Entwickler im Alltag Dinge entdeckt, für die gerade keine Zeit ist. Gib diesen Beobachtungen einen Ort, dann werden sie zum Treibstoff für die zehn Minuten von jemand anderem am nächsten Tag.\u003c/p\u003e\n\n\u003cp\u003e\u003cstrong\u003eMach es einfach.\u003c/strong\u003e Zehn Minuten pro Person und Tag. Keine Freigaben. Keine Tickets. Kein Meeting, um die Verbesserung einzuplanen. Keine Schätzung in Story Points. Kein Review-Komitee. Die Autonomie ist Teil des Designs. In dem Moment, in dem ein Team um Erlaubnis fragen muss, um den Code zu verbessern, ist die Gewohnheit tot, weil der Genehmigungsschritt länger dauert als die Verbesserung selbst.\u003c/p\u003e\n\n\u003cp\u003e\u003cstrong\u003eMach es attraktiv.\u003c/strong\u003e Feiert die kleinen Erfolge offen. Erwähnt sie im Standup. Visualisiert die Streak am Team-Board. Führt eine Team-Habit-Streak ein: Wir haben unsere tägliche Verbesserung an 14 aufeinanderfolgenden Arbeitstagen geschafft. Hängt es ans Board. Macht es sichtbar. Eine Streak erzeugt eine sanfte soziale Dynamik, in der niemand die Person sein will, die sie reißt. Einen neuen Rekord aufzustellen wird zu etwas, worauf das Team ehrlich stolz ist. Eine wichtige Regel: Urlaubstage, Krankheitstage und Konferenz- oder Trainingstage zählen immer als fortgesetzte Streak. Niemand soll sich gezwungen fühlen, an einem freien Tag zu arbeiten. Die Streak verfolgt die \u003cem\u003eArbeitstage des Teams\u003c/em\u003e, nicht die individuelle Anwesenheit. Wenn drei Personen im Büro sind und ihre zehn Minuten machen, läuft die Streak weiter. Nutzt hier den gesunden Menschenverstand. Die Liste der gültigen Gründe sollte nicht so lang werden, dass sie billige Ausreden erlaubt, aber sie muss schützen, was wirklich wichtig ist. Das Team kennt den Unterschied. Vertraut dem Team an dieser Stelle. Ein Team, das seinen eigenen Fortschritt sieht, will mehr davon. Ein Team, das seinen Fortschritt nicht sieht, geht davon aus, dass es keinen gibt.\u003c/p\u003e\n\n\u003cp\u003e\u003cstrong\u003eMach es befriedigend.\u003c/strong\u003e Die Befriedigung muss auf Team-Ebene sichtbar sein, nicht nur individuell. Metriken, die sich in die richtige Richtung bewegen. Die Anzahl der Warnungen, die Woche für Woche sinkt. Der Dependency-Graph, der sauberer wird. Die Dokumentation, die tatsächlich die Fragen beantwortet, die eine neue Kollegin am ersten Tag stellt. Das sind keine Vanity Metrics. Das sind Belege, die das gesamte Team teilt, dass die kleinen Verbesserungen tun, wofür sie gedacht sind.\u003c/p\u003e\n\n\u003cp\u003eHier eine wichtige Warnung. In dem Moment, in dem jemand außerhalb des Teams das Ganze in eine formale Tracking-Prozedur verwandelt, ist die Idee tot. Wenn eine Managerin oder ein Manager anfängt zu messen, wie viele Verbesserungen jede Entwicklerin oder jeder Entwickler diese Woche gemacht hat, hast Du aus einer Gewohnheit eine KPI gemacht und die intrinsische Motivation ist weg. Das funktioniert nur, wenn das Team das Ganze besitzt, es für sich selbst trackt und es als sein eigenes internes Signal nutzt. Die Habit-Streak am Board gehört dem Team. Sie ist keine Reporting-Metrik. Lasst es so.\u003c/p\u003e\n\n\u003cp\u003eEs gibt noch eine Idee von Clear, die sich besonders gut auf Teams übertragen lässt: Habit-Stacking. Der einfachste Weg, eine neue Gewohnheit aufzubauen, ist, sie an eine bestehende anzudocken. Teams haben bereits Routinen. Das Daily Standup. Das Pull-Request-Review. Die Retrospektive. Neue Gewohnheiten halten schneller, wenn sie auf diesen Routinen mitreiten. Eine „Doku-Minute\" direkt nach dem Standup. Ein „Lass den Code besser zurück, als Du ihn gefunden hast\"-Check im Pull-Request-Review. Drei Minuten Warning-Cleanup zu Beginn jeder Pair-Programming-Session. Die bestehende Routine trägt die neue Gewohnheit auf dem Rücken.\u003c/p\u003e\n\n\u003cp\u003eGenau dieser Schritt holt die 1%-Methode aus dem Selbsthilfe-Bereich und bringt sie in die Engineering-Praxis. Die Gewohnheiten sind nicht persönlich. Die Struktur ist nicht persönlich. Die Verbesserung ist nicht persönlich. Das Team besitzt sie, das Team gestaltet sie, das Team profitiert davon.\u003c/p\u003e\n\n\u003ch3 id=\"architektur-ist-das-was-du-jeden-tag-tust\"\u003eArchitektur ist das, was Du jeden Tag tust\u003c/h3\u003e\n\n\u003cp\u003eWenn wir über Architektur sprechen, sprechen wir meistens über Entscheidungen. Welche Datenbank. Welches Kommunikationsmuster. Welches Deployment-Modell. Wie schneiden wir den Monolithen. Gehen wir auf Event-driven? Wir schreiben ADRs, wir zeichnen Diagramme, wir haben Review-Meetings. Und das alles ist wichtig.\u003c/p\u003e\n\n\u003cp\u003eAber lass mich Dir eine Frage stellen. Wann ist Eure Architektur das letzte Mal wirklich schlechter geworden, weil in einem Meeting eine Entscheidung getroffen wurde?\u003c/p\u003e\n\n\u003cp\u003eAn diesem Ort erodiert Architektur nicht. Sie erodiert an einem Mittwochnachmittag, wenn jemand eine Abkürzung baut, weil der Sprint zu rutschen beginnt. Sie erodiert an einem Freitag, wenn niemand mehr einen Test schreibt, weil das Wochenende ruft. Sie erodiert über einen ruhigen Monat, in dem ein Modul von 300 auf 1.200 Zeilen anwächst, weil jedes neue Feature dort gelandet ist und niemand stehengeblieben ist und gefragt hat, ob es da überhaupt noch hingehört. Sie erodiert, wenn eine Dependency, die vor sechs Monaten als temporär gedacht war, mittlerweile tragend ist und sich niemand mehr traut, sie anzufassen.\u003c/p\u003e\n\n\u003cp\u003eIn keinem dieser Momente hat jemand eine schlechte Architektur-Entscheidung getroffen. In keinem dieser Momente hat überhaupt jemand eine \u003cem\u003eEntscheidung\u003c/em\u003e getroffen. Die Dinge sind einfach passiert. Kleine Dinge. Alltägliche Dinge. Dinge, die in keinem Review und keinem ADR auftauchen.\u003c/p\u003e\n\n\u003cp\u003eUnd trotzdem sind sie in Summe \u003cem\u003edie Architektur\u003c/em\u003e.\u003c/p\u003e\n\n\u003cblockquote\u003e\n\u003cp\u003e\u003cstrong\u003eArchitektur ist die Summe alltäglichen Verhaltens, im gesamten Team, über Monate und Jahre.\u003c/strong\u003e\u003c/p\u003e\n\u003c/blockquote\u003e\n\n\u003cp\u003eDie Entscheidungen geben die Richtung vor. Das tägliche Verhalten entscheidet, ob wir auch tatsächlich dorthin kommen. Und wenn das tägliche Verhalten nicht zur Richtung passt, gewinnt das Verhalten. Jedes Mal. Kein Diagramm überlebt den Kontakt mit einem Team, das keine Gewohnheit hat, den Code sauber zu halten.\u003c/p\u003e\n\n\u003cp\u003eGenau deshalb sind die Team-Gewohnheiten aus dem vorherigen Abschnitt viel wichtiger, als sie auf den ersten Blick wirken. Eine einzelne zehnminütige Verbesserung wird keine kaputte Modulgrenze reparieren. Natürlich nicht. Aber ein Team, das die \u003cem\u003eGewohnheit\u003c/em\u003e hat, Grenzen wahrzunehmen, Probleme zu benennen, kleine Unordnung zu beseitigen und die Dokumentation ehrlich zu halten, wird über die Zeit eine Architektur produzieren, die fundamental leichter zu ändern ist. Nicht weil jemand in einem Meeting-Raum eine geniale Entscheidung getroffen hat. Sondern weil hunderte kleiner, alltäglicher Verhaltensweisen ungefähr in dieselbe Richtung gezeigt haben, Tag für Tag, Monat für Monat.\u003c/p\u003e\n\n\u003cp\u003eWeniger Hotspots in der Codebasis. Geringere Komplexität in den Modulen, die am häufigsten angefasst werden. Klarere Grenzen zwischen Komponenten. Klarere Verantwortlichkeiten. Vorhersehbarere Abhängigkeiten. Eine Dokumentation, die ein neues Team-Mitglied in der ersten Woche tatsächlich nutzen kann. Nichts davon entsteht durch eine einzige Aktion. Alles davon entsteht durch ein anhaltendes Verhaltensmuster.\u003c/p\u003e\n\n\u003cp\u003eIn den Kampfsportarten gibt es ein Konzept, das das gut einfängt: \u003cstrong\u003eMuskelgedächtnis\u003c/strong\u003e. Du fängst nicht damit an, Kämpfe zu gewinnen. Du fängst damit an, einen einzelnen Schlag zu perfektionieren. Du wiederholst ihn hunderte Male, bis Dein Körper Dein Gehirn nicht mehr braucht. Dann lernst Du Katas, Abfolgen aus Schlägen und Blocks, die ineinander fließen. Auch die wiederholst Du hunderte Male. Und dann, eines Tages, gehst Du in einen Sparring-Kampf und Dein Körper macht das Richtige, ohne dass Du darüber nachdenkst. Der Schlag sitzt. Der Block ist am richtigen Ort. Nicht weil Du in dem Moment entschieden hättest, was zu tun ist. Sondern weil Du das Muster so tief trainiert hast, dass die Entscheidung schon gefallen war.\u003c/p\u003e\n\n\u003cp\u003eArchitektur funktioniert genauso. Ein Team, das ein halbes Jahr lang täglich kleine Verbesserungen geübt hat, muss nicht mehr darüber nachdenken, ob es einen verwirrenden Namen aufräumt, einen toten Import entfernt oder eine Grenze schärft. Es macht es einfach. Das Muster ist trainiert. Die Architektur spiegelt das Training.\u003c/p\u003e\n\n\u003cp\u003eUnd das ist der wirklich starke Effekt: Ein Team mit ausgeprägtem architektonischem Muskelgedächtnis hält nicht nur die aktuelle Architektur. Es macht \u003cem\u003ezukünftige\u003c/em\u003e architektonische Veränderungen sicherer. Wenn der Moment für einen größeren Schritt kommt, eine Service-Extraktion, ein Modul-Split, eine Technologie-Migration, dann ist genau das Team in der Lage, ihn umzusetzen, das seit Monaten Grenzen sauber hält, Abhängigkeiten vorhersehbar und die Dokumentation ehrlich. Der große Schritt ist nicht deshalb sicher, weil ihn jemand gut geplant hat. Er ist sicher, weil der Boden, auf dem er landet, vorbereitet wurde, eine zehnminütige Verbesserung nach der anderen.\u003c/p\u003e\n\n\u003ch3 id=\"die-zinseszinskurve\"\u003eDie Zinseszinskurve\u003c/h3\u003e\n\n\u003cp\u003eEs gibt etwas, worüber ich ehrlich sein muss. In den ersten Wochen wird sich das anfühlen, als würde nichts passieren.\u003c/p\u003e\n\n\u003cp\u003eDer Code wird nicht dramatisch anders aussehen. Die Metriken werden sich kaum bewegen. Die Architektur-Diagramme ändern sich gar nicht. Und irgendjemand im Team wird sagen \u003cem\u003e„siehst Du, ich hab’s Dir gesagt, das funktioniert nicht.\"\u003c/em\u003e\u003c/p\u003e\n\n\u003cp\u003eDiese Person liegt falsch. Aber sie lügt auch nicht über das, was sie sieht. Die Zinseszinskurve hat eine Form, die Ungeduld bestraft. Die frühe Phase ist flach. Fast unsichtbar. Die Verbesserungen sind real, aber sie sind zu klein und zu verstreut, um in irgendetwas aufzutauchen, das man messen oder zeigen könnte. An genau dieser Stelle geben die meisten Teams auf. Nicht weil der Ansatz nicht funktioniert hätte, sondern weil das Feedback zu spät kam.\u003c/p\u003e\n\n\u003cp\u003eDas ist wie beim Laufen. Nach vier bis sechs Wochen täglichem Training fühlst Du Dich gut. Du bist schneller als am ersten Tag. Du hast eine Routine. Du fühlst Dich wie eine Läuferin oder ein Läufer. Und dann läuft Dir an einem Morgen jemand in Deinem Alter im Park entspannt davon. Plötzlich fühlt sich Dein Fortschritt nach nichts an. Du warst stolz auf Deine zehn Minuten pro Kilometer und diese Person macht sechs Minuten pro Kilometer, als sei es ein Aufwärmen. Die Versuchung aufzugeben ist riesig, weil der Vergleich Deinen eigenen Fortschritt für Dich unsichtbar gemacht hat.\u003c/p\u003e\n\n\u003cp\u003eDasselbe passiert Teams. Du machst seit sechs Wochen Deine zehnminütigen Verbesserungen. Der Code ist ein Stück sauberer. Das Team fühlt sich gut damit. Und dann liefert ein anderes Team in der Firma ein großes, sichtbares Modernisierungs-Projekt aus. Neue Architektur. Neuer Tech-Stack. Eine Präsentation für die Leitung. Applaus. Eure stille, tägliche, unsichtbare Arbeit sieht im Vergleich nach nichts aus.\u003c/p\u003e\n\n\u003cp\u003eDas ist der Moment, der Teams trennt, die dauerhafte Gewohnheiten aufbauen, von Teams, die es einmal versucht haben. Das Team, das hier aufgibt, hat sichtbaren Fortschritt als Motivation gebraucht. Das Team, das weitermacht, hat etwas Besseres: eine Struktur, die nicht davon abhängt, wie sich das Team in dieser Woche fühlt. Die Gewohnheit läuft einfach. Genau deshalb haben wir sie als Gewohnheit gebaut.\u003c/p\u003e\n\n\u003cp\u003eWenn Du dabei bleibst, biegt sich die Kurve. Nicht plötzlich, aber spürbar. So sieht es ungefähr aus in den Teams, mit denen ich bisher gearbeitet habe:\u003c/p\u003e\n\n\u003cp\u003e\u003cstrong\u003eWoche 1 bis 4: Unsichtbar.\u003c/strong\u003e Die Verbesserungen passieren, aber niemand außerhalb des Teams kann es erkennen. Die Diffs sind ein bisschen sauberer. Ein paar Namen ergeben mehr Sinn. Ein Test, der gefehlt hat, existiert jetzt. Der Wert ist real, aber nur für die Person sichtbar, die die Änderung gemacht hat. Das ist die schwerste Phase, weil sich der Aufwand sinnlos anfühlt. Ist er aber nicht.\u003c/p\u003e\n\n\u003cp\u003e\u003cstrong\u003eMonat 2 bis 5: Spürbar.\u003c/strong\u003e Das Team beginnt es zu fühlen. Code-Reviews werden schneller, weil der Code leichter zu lesen ist. Neue Kolleg:innen finden sich ein bisschen schneller zurecht. Die Anzahl der „was macht das hier eigentlich?\"-Gespräche im Standup geht zurück. Nichts Dramatisches. Aber die Reibung ist geringer und das Team merkt es.\u003c/p\u003e\n\n\u003cp\u003e\u003cstrong\u003eMonat 6 bis 12: Messbar.\u003c/strong\u003e Die Metriken beginnen widerzuspiegeln, was das Team längst spürt. Warning-Counts sind sichtbar niedriger. Die Komplexitätswerte in den Modulen, die das Team am häufigsten anfasst, sind gesunken. Der Dependency-Graph hat weniger überraschende Verbindungen. Die Dokumentation deckt die Dinge ab, nach denen tatsächlich gefragt wird. Ihr könnt einen Chart auf einen Bildschirm hängen und jemandem außerhalb des Teams zeigen, dass sich etwas verbessert. Die kognitive Last im Team ist niedriger. Und falls jemand fragt, ob die zehn Minuten den Aufwand wert sind: Das Team liefert Features schneller aus, weil der Code, auf dem es aufbaut, ihm nicht mehr im Weg steht.\u003c/p\u003e\n\n\u003cp\u003e\u003cstrong\u003eMonat 12 bis 24: Transformativ.\u003c/strong\u003e Hier wird der Zinseszinseffekt schwer zu ignorieren. Die Codebasis ist nicht nur sauberer, sie ist strukturell anders als vor zwei Jahren. Grenzen sind schärfer. Module sind kleiner. Das Team bewegt sich schneller bei neuen Features, weil der Boden, auf dem es baut, solide ist. Und die großen architektonischen Schritte, die vor zwei Jahren unmöglich aussahen, eine Service-Extraktion, ein Modul-Split, eine Technologie-Migration, sind jetzt realistisch, weil die Vorbereitung in zehnminütigen Verbesserungen passiert ist.\u003c/p\u003e\n\n\u003cp\u003eDie Zinseszinskurve ist kein Versprechen, dass alles gut wird. Sie ist eine Beschreibung davon, wie sich kleiner, konsistenter Aufwand aufaddiert. Die Form ist immer dieselbe: flach, dann allmählich, dann steil. Die einzige Variable ist, ob das Team lange genug dabeibleibt, um den steilen Teil zu erreichen. Genau deshalb muss es eine Gewohnheit sein und kein Projekt. Keine Motivation hält zwei Jahre durch. Keine Projekt-Sponsorin, kein Projekt-Sponsor hält zwei Jahre Aufmerksamkeit. Eine Gewohnheit hält das aus.\u003c/p\u003e\n\n\u003ch3 id=\"wie-du-diese-woche-anfangst\"\u003eWie Du diese Woche anfängst\u003c/h3\u003e\n\n\u003cp\u003eWer schon einmal mit dem Laufen angefangen hat, kennt die Antwort auf die Frage \u003cem\u003e„Wann ist der beste Zeitpunkt für eine Laufrunde?\"\u003c/em\u003e. Die Antwort ist immer: jetzt. Nicht morgen. Nicht nächsten Montag. Nicht erst, wenn Du die richtigen Schuhe gekauft hast. Jetzt.\u003c/p\u003e\n\n\u003cp\u003eNach Konferenzen sage ich den Leuten normalerweise das Gegenteil. Fall nicht auf jeden Hype rein. Mach kein CDD, also kein Conference-Driven Development. Keine karrierebegrenzenden Aktionen auf Basis eines 45-Minuten-Vortrags zwischen Mittagessen und Nachmittagskaffee.\u003c/p\u003e\n\n\u003cp\u003eDiesmal sage ich Dir das Gegenteil. Fang an. Jetzt. Das ist kein neues Framework. Das ist keine riskante Technologie-Wette. Das sind zehn Minuten, in denen Du Code aufräumst, der Dir ohnehin gehört. Das Schlimmste, was passieren kann, ist, dass eine Variable morgen einen besseren Namen hat. Los.\u003c/p\u003e\n\n\u003cp\u003e\u003cstrong\u003eDiese Woche:\u003c/strong\u003e Morgen früh, bevor Du Slack öffnest, investierst Du zehn Minuten in eine kleine Verbesserung. Irgendeine Verbesserung. Ein besserer Name. Eine gelöschte Methode. Ein Test. Ein Absatz Dokumentation. Sag es niemandem. Bitte um keine Erlaubnis. Leg kein Ticket an. Mach es einfach. Leg eine Habit-Card auf den Schreibtisch und hak sie ab. Mach das diese ganze Woche an jedem Arbeitstag.\u003c/p\u003e\n\n\u003cp\u003e\u003cstrong\u003eDiesen Monat:\u003c/strong\u003e Sprich mit Deinem Team darüber. Zeig ihnen die Habit-Card. Erzähl, was Du gemacht hast. Wenn die anderen neugierig werden, schlag vor, dass alle es zwei Wochen lang ausprobieren. Richtet das Improvement-Ideen-Board ein, auf einem Flipchart oder in Miro, sodass niemand überlegen muss, woran zu arbeiten wäre. Startet eine Team-Streak. Trackt sie am Team-Board, nicht in einem Reporting-Tool.\u003c/p\u003e\n\n\u003cp\u003e\u003cstrong\u003eDieses Quartal:\u003c/strong\u003e Bring das Thema in Eure Retrospektiven. Sprecht darüber, was funktioniert und was nicht. Wählt eine oder zwei Metriken aus, die für Eure Codebasis relevant sind, also Warning-Count, Komplexitäts-Score, Dependency-Anzahl, Dokumentations-Coverage, und beobachtet sie. Nicht als KPI für jemand anderen. Als Signal für das Team. Lasst das Team die Gewohnheit auf den eigenen Rhythmus zuschneiden. Manche Teams machen ihre zehn Minuten als Erstes am Morgen. Andere direkt nach dem Standup. Wieder andere als Teil des Pull Requests. Es gibt keine richtige Antwort. Es gibt nur die Antwort, mit der Euer Team auch noch nach 12 Monaten dabei ist.\u003c/p\u003e\n\n\u003cp\u003eKein Framework, das eingeführt werden muss. Kein Tool, das gekauft werden muss. Kein Budget, das genehmigt werden muss. Kein Lenkungsausschuss, den Du überzeugen müsstest. Die Eintrittsbarriere sind zehn Minuten und die Bereitschaft anzufangen, bevor Du Dich bereit fühlst.\u003c/p\u003e\n\n\u003ch3 id=\"fang-morgen-an\"\u003eFang morgen an\u003c/h3\u003e\n\n\u003cp\u003eIn zwei Jahren wird Eure Codebasis die Summe jeder kleinen Entscheidung sein, die Euer Team zwischen jetzt und dann getroffen hat. Das stimmt, ob Ihr morgen anfangt oder nicht. Der einzige Unterschied ist, ob die Richtung und die Haltung bewusst sind.\u003c/p\u003e\n\n\u003cp\u003eDu brauchst kein Modernisierungs-Projekt. Du brauchst kein Budget. Du brauchst von niemandem eine Erlaubnis. Du musst nicht auf den nächsten Planungszyklus warten, nicht auf das nächste Quartal, nicht auf die nächste ruhige Phase, die ohnehin nie kommen wird. Du brauchst zehn Minuten, eine Habit-Card und die Bereitschaft, den Code ein bisschen besser zu hinterlassen, als Du ihn vorgefunden hast.\u003c/p\u003e\n\n\u003cp\u003eDie Teams, die das tun, werden die Veränderung zunächst nicht bemerken. Niemand wird sie bemerken. Aber in einem Jahr werden sie auf ihre Codebasis schauen und sich fragen, wann die Arbeit damit eigentlich angefangen hat, leichter zu werden. Die Antwort wird sein: an einem ruhigen Dienstagmorgen, bevor jemand Slack geöffnet hat.\u003c/p\u003e\n\n\u003cblockquote\u003e\n\u003cp\u003e\u003cstrong\u003eArchitektur wird zu dem, was Du jeden Tag tust. Nicht zu dem, was Du einmal planst.\u003c/strong\u003e\u003c/p\u003e\n\u003c/blockquote\u003e\n\n\u003cp\u003eFang morgen an. Zehn Minuten. Nach dem Kaffee. Vor Slack. Vor E-Mail. Vor allem anderen.\u003c/p\u003e\n\u003c/body\u003e\u003c/html\u003e\n","image":"https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2000/v1/uploads-production/j5xjwve3fne35ajw279ckxkxh7z1?_a=BACMTiAE"},{"id":"https://www.innoq.com/de/blog/2026/05/agentic-engineering-product-discovery/","url":"https://www.innoq.com/de/blog/2026/05/agentic-engineering-product-discovery/","date_published":"2026-05-12T00:00:00.000+00:00","date_modified":"2026-05-12T11:44:09.794+02:00","author":[{"name":"Daniel Westheide","url":"https://www.innoq.com/ch/staff/daniel-westheide/"}],"content_html":"\u003c!DOCTYPE html PUBLIC \"-//W3C//DTD HTML 4.0 Transitional//EN\" \"http://www.w3.org/TR/REC-html40/loose.dtd\"\u003e\n\u003chtml\u003e\u003cbody\u003e\n\u003cp\u003eTeams, die das Paradigma der agentischen Softwareentwicklung adoptiert haben, erzeugen mehr Code in weniger Zeit. Studien von \u003ca href=\"https://cloud.google.com/resources/content/2025-dora-ai-assisted-software-development-report\"\u003eDORA\u003c/a\u003e und \u003ca href=\"https://www.faros.ai/ai-productivity-paradox\"\u003eFaros AI\u003c/a\u003e zeigen konsistent, dass diese Teams in gleicher Zeit mehr Aufgaben und Epics erledigen, mehr und größere Pull Requests erstellen und auch mehr Pull Requests mergen.\u003c/p\u003e\n\n\u003cp\u003eEs stellt sich die Frage, was tun mit der frei gewordenen Kapazität? Die nahe liegende Reaktion wäre es einfach in gleicher Zeit mehr zu bauen. Es gibt Unternehmen, die sich als AI-native vermarkten und bereits ihre gesamte Pipeline in diese Richtung optimieren: Da wird dann aus einer Slack-Nachricht, in der ein Stakeholder sich ein Feature wünscht, ein Pull Request, dieser geht durchs Review und wird deployt. Alles voll automatisiert durch verschiedene Agenten.\u003c/p\u003e\n\n\u003cp\u003eDas ist ein verständlicher Reflex, aus verschiedenen Gründen. Erstens klingt es erstmal sehr sympathisch, dass man versucht die vorhandenen Entwickler:innen weiter zu beschäftigen anstatt Entwicklungsteams aufgrund der höheren Produktivität zu verkleinern. Und zweitens haben viele Unternehmen riesige Backlogs, aus denen man scheinbar unendlich nachziehen kann, und Stakeholder, insbesondere aus der Geschäftsführung, haben ja sowieso ständig neue Ideen oder Feature-Wünsche.\u003c/p\u003e\n\n\u003cp\u003eManchmal braucht die Fachseite trotzdem zu lange um ihre Anforderungen aufzubereiten. Sie wird zum Flaschenhals. Also muss auch das Requirements Engineering beschleunigt werden. BMAD und ähnliche Ansätze versprechen «Stunden statt Wochen» für Spezifikationen. Spec-driven Development und AI-unterstütztes Requirements Engineering sollen dafür sorgen dass die Entwickler:innen und ihre Agenten keinen Slack bekommen, sondern stets beschäftigt sind, stets und in höchstem Tempo Features in Produktion bringen. Was entsteht ist eine perfekte Output-Tretmühle.\u003c/p\u003e\n\n\u003ch3 id=\"zwei-probleme\"\u003eZwei Probleme\u003c/h3\u003e\n\n\u003cp\u003eDoch dieser Ansatz hat zwei Probleme. Zum einen zeigen die Daten von DORA und Faros AI nicht nur dass mehr Code erzeugt wird, sondern auch dass Code-Reviews deutlich länger dauern und dass die Qualität der Software in agentisch arbeitenden Teams deutlich abnimmt. Der Faros AI Report zeigt dass Entwickler:innen in AI-assistierten Teams eine deutlich höhere Anzahl an Bugs erzeugen. Im Vergleich zur Zeit als die AI-Nutzung noch wenig verbreitet war, hat sich die Anzahl der Incidents etwa verdreifacht. Der DORA Report zeigt einen Anstieg an Incidents im Vergleich zu den vorherigen Jahren, auch in Teams, die DORA als High Performer einstuft.\u003c/p\u003e\n\n\u003cp\u003eDas andere Problem besteht darin dass Features pro Zeiteinheit keine sinnvolle Metrik ist, mit der man messen kann ob man auf dem richtigen Weg ist. Die spannenden Fragen sind doch diese: Bringen diese Features einen Wert für die Nutzenden und das Unternehmen? Befriedigen sie konkrete Nutzerbedürfnisse? Tragen sie zu einem gewünschten strategischen Outcome bei?\u003c/p\u003e\n\n\u003cp\u003eWenn ein Feature einfach nur eine Idee eines Stakeholders war, sei es ein Manager, ein Geschäftsführer oder ein Kunde, dann kann die Antwort auf diese Fragen zwar ja sein, es handelt sich dann aber eher um einen Zufallstreffer.\u003c/p\u003e\n\n\u003ch3 id=\"product-discovery-als-bessere-antwort\"\u003eProduct Discovery als bessere Antwort\u003c/h3\u003e\n\n\u003cp\u003eDiese Unsicherheit zu reduzieren ist das Ziel von Product Discovery. Durch systematische Methoden wie Opportunity Mapping, regelmäßige kurze Interviews mit (potenziellen) Nutzer:innen, Solution Ideation und Assumption Testing. Idealerweise gibt es einen kontinuierlichen Zyklus aus Discovery und Delivery, die wieder zu neuer Discovery führt.\u003c/p\u003e\n\n\u003cp\u003eIn vielen Organisationen findet systematische Discovery jedoch nicht statt. Die Zahl der ungenutzten Features, die für teures Geld gebaut wurden, weil jemand eine vermeintlich tolle Idee hatte, ist beachtlich: Laut einer \u003ca href=\"https://go.pendo.io/rs/185-LQW-370/images/2019%20Feature%20Adoption%20Report%20Digital.pdf\"\u003eStudie von Pendo aus dem Jahr 2019\u003c/a\u003e werden 80% der Features in durchschnittlichen Softwareprodukten selten oder nie genutzt.\u003c/p\u003e\n\n\u003cp\u003eWarum also reagieren wir auf die gestiegene Produktivität in der Delivery nicht, indem wir es als Chance begreifen die essenzielle Arbeit der Product Discovery ernst zu nehmen? Statt im gleichen Zeitraum mehr Features zu liefern, die niemand nutzt, könnten wir das alte Tempo einfach beibehalten und die frei gewordene Zeit nutzen, um systematisch zu testen, ob unsere Annahmen hinter dem Feature überhaupt zutreffen. Gibt es das Problem, das wir lösen wollen, wirklich? Interviews oder Beobachtungen von potenziellen Nutzer:innen verschaffen Klarheit. Ist das Feature überhaupt eine Lösung für das Problem? Auch da wollen wir gerne unsere Unsicherheit reduzieren bevor wir in die Umsetzung gehen.\u003c/p\u003e\n\n\u003cp\u003eJa, AI ändert auch in der Product Discovery die Ökonomie, und sie erlaubt es den Zyklus von Discovery und Delivery schneller zu durchlaufen. Manche Annahmen aber kann ich immer noch schneller und einfacher testen, ohne dass ein Agent auch nur eine Zeile Code generieren muss, und ohne diesen in Produktion zu deployen.\u003c/p\u003e\n\n\u003cp\u003eDass sich da gerade massiv etwas ändert, zeigt sich auch daran, dass etwa IBM WatsonX ein Verhältnis von einem Produktmanager zu einer halben Entwickler:in diskutiert, ausgehend von einem traditionellen Verhältnis von einem Produktmanager zu acht Entwickler:innen, wie Melissa Perri in einem \u003ca href=\"https://www.linkedin.com/posts/melissajeanperri_state-of-ai-in-product-2026-activity-7450868283945218048-YTIG\"\u003eLinkedIn-Post\u003c/a\u003e berichtet.\u003c/p\u003e\n\n\u003cp\u003eProdukt-Management ist also der neue Flaschenhals. Und die Antwort besteht nicht darin die Discovery-Phase mit BMAD oder ähnlichen Tools auf wenige Stunden zu komprimieren, sondern den Raum, der durch schnellere Delivery entsteht, für mehr und bessere Discovery-Arbeit zu nutzen. Weniger Features in der Pipeline bedeutet auch weniger Pull Requests, weniger Review-Druck, und weniger Incidents.\u003c/p\u003e\n\n\u003cp\u003eSo eine Umkehrung des Verhältnisses von Produktmanagern zu Entwicklern wird Konsequenzen haben. Für Teamstrukturen, für Rollen, und für die Frage was wir als Entwickler:innen eigentlich tun.\u003c/p\u003e\n\u003c/body\u003e\u003c/html\u003e\n","image":"https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2000/v1/uploads-production/cfuk3tc8o6c0emfz0w3j3tnxidyv?_a=BACMTiAE"},{"id":"https://www.innoq.com/de/blog/2026/05/the-missing-half-of-your-data-strategy/","url":"https://www.innoq.com/de/blog/2026/05/the-missing-half-of-your-data-strategy/","date_published":"2026-05-04T00:00:00.000+00:00","date_modified":"2026-04-30T17:17:29.535+02:00","author":[{"name":"Stefan Negele","url":"https://www.innoq.com/ch/staff/stefan-negele/"}],"content_html":"\u003c!DOCTYPE html PUBLIC \"-//W3C//DTD HTML 4.0 Transitional//EN\" \"http://www.w3.org/TR/REC-html40/loose.dtd\"\u003e\n\u003chtml\u003e\u003cbody\u003e\n\u003ch3 id=\"das-wechselspiel-von-data-literacy-und-data-access\"\u003eDas Wechselspiel von Data Literacy und Data Access\u003c/h3\u003e\n\n\u003cp\u003eEs gibt einige Definitionen von Data Literacy (Datenkompetenz). Mir gefällt die Definition von Jordan Morrow in seinem Buch \u003cem\u003eBe Data Literate\u003c/em\u003e sehr gut. Ich habe versucht, sie sinngemäß ins Deutsche zu übersetzen:\u003c/p\u003e\n\n\u003cblockquote\u003e\n\u003cp\u003eData Literacy ist die Fähigkeit, Daten zu lesen, mit ihnen zu arbeiten, sie zu analysieren und mit ihnen zu kommunizieren. (Morrow, 2024, S. 36, eigene Übersetzung)\u003c/p\u003e\n\u003c/blockquote\u003e\n\n\u003cp\u003eMorrow schreibt außerdem, dass nicht alle Menschen Data Scientists werden müssen, aber die genannten Fähigkeiten im Grunde haben sollten, um sich in der Welt behaupten zu können. Ohne Zugang zu den Daten bleiben solche Lernbemühungen in meinen Augen leider weitestgehend theoretisch. Durch föderierte und datenproduktorientierte Datenarchitekturen wie Data Mesh kann dieses Problem gelindert werden, denn Unternehmen, die solche Konzepte umsetzen, sollten, wo rechtlich möglich, auch Zugriff auf alle Daten im Unternehmen ermöglichen. Eine solche offene Datenverfügbarkeit führt jedoch ohne Datenkompetenz zu Chaos, denn ohne die Kompetenz, Daten zu verstehen und Tools zu benutzen, ist die Wahrscheinlichkeit von Fehlinterpretationen sehr hoch. Gemeinsam bilden Datenverfügbarkeit und Data Literacy aber einen symbiotischen Kreislauf:\u003c/p\u003e\n\n\u003cfigure style=\"max-width: 700px; margin: auto;\"\u003e\r\n\u003cimg alt=\"Segmented circular diagram labeled: Data Literacy, Platform Usage, Data Variety, Data Access, Curiosity, Learning.\" loading=\"lazy\" srcset=\"https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_400/v1/uploads-production/lfwwfsga76kxs3axeyc92e2cfpwm?_a=BACMTiAE 400w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_800/v1/uploads-production/lfwwfsga76kxs3axeyc92e2cfpwm?_a=BACMTiAE 800w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_1024/v1/uploads-production/lfwwfsga76kxs3axeyc92e2cfpwm?_a=BACMTiAE 1024w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_1200/v1/uploads-production/lfwwfsga76kxs3axeyc92e2cfpwm?_a=BACMTiAE 1200w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_1600/v1/uploads-production/lfwwfsga76kxs3axeyc92e2cfpwm?_a=BACMTiAE 1600w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2048/v1/uploads-production/lfwwfsga76kxs3axeyc92e2cfpwm?_a=BACMTiAE 2048w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2300/v1/uploads-production/lfwwfsga76kxs3axeyc92e2cfpwm?_a=BACMTiAE 2300w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2600/v1/uploads-production/lfwwfsga76kxs3axeyc92e2cfpwm?_a=BACMTiAE 2600w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2800/v1/uploads-production/lfwwfsga76kxs3axeyc92e2cfpwm?_a=BACMTiAE 2800w\" sizes=\"(min-width: 1400px) 1024px, 90vw\"\u003e\r\n\u003c/figure\u003e\r\n\n\u003cp\u003eWenn wir die Möglichkeit erhalten, auf für uns relevante Daten zuzugreifen (\u003cstrong\u003eData Access\u003c/strong\u003e), kann sich Neugier entwickeln (\u003cstrong\u003eCuriosity\u003c/strong\u003e). Diese Neugier schafft die Grundlage für eine Lernmotivation (\u003cstrong\u003eLearning\u003c/strong\u003e), die zu neuen Kompetenzen bei der Arbeit mit Daten führt. Diese \u003cstrong\u003eData Literacy\u003c/strong\u003e hat den gewünschten Effekt: Die Plattform wird genutzt (\u003cstrong\u003ePlatform Usage\u003c/strong\u003e), was wiederum zu einer größeren Vielfalt von Daten (\u003cstrong\u003eData Variety\u003c/strong\u003e) auf der Plattform führt. Dadurch werden weitere Daten verfügbar, die wiederum für andere von Interesse sein können, und der Kreislauf geht weiter.\u003c/p\u003e\n\n\u003cp\u003eEine gut gestaltete Datenplattform verstärkt diesen Zyklus: Sie macht Daten zugänglich und unterstützt die Nutzer:innen dabei, verantwortungsvoll mit ihnen umzugehen. Architekturen, die die Verantwortung für Daten auf die Teams verteilen, die diese am besten kennen, können diese Grundlage bieten. Ich verstehe darunter Architekturen, bei denen nicht ein zentrales Datenteam alle Daten verwaltet und bereitstellt, sondern die fachlichen Domänen selbst als eigenverantwortliche Eigentümer:innen ihrer Datenprodukte auftreten. Ein Datenprodukt ist dabei mehr als ein Datensatz: Es ist ein klar definiertes, dokumentiertes und verlässlich gepflegtes Datenangebot, das gezielt für die Nutzung durch andere entwickelt wurde. Wenn ich in diesem Artikel von datenproduktorientierten Architekturen spreche, dann meine ich damit nicht unbedingt ein vollständig ausgereiftes Data Mesh nach Zhamak Dehghani. Ich beschreibe ein Spektrum von ersten Schritten in Richtung dezentraler Datenverantwortung bis hin zur vollständigen Umsetzung der vier Prinzipien. Der Kern bleibt jedoch bestehen: Datenverantwortung gehört in die Teams, die die Daten kennen.\u003c/p\u003e\n\n\u003cp\u003eDurch den anhaltend rasanten Aufstieg von Large Language Models wird dieser Kreislauf noch relevanter, da der Wert dieser Technologien von der Qualität der zugrunde liegenden Daten abhängt. Unternehmen, die über keine belastbaren, gut strukturierten und zugänglichen Daten verfügen, werden auch aus KI-Initiativen nur wenig Nutzen ziehen können. Data Literacy und eine solide Datenarchitektur sind somit nicht nur Voraussetzung für datengetriebene Entscheidungen, sondern auch Grundlage für den sinnvollen Einsatz von KI.\u003c/p\u003e\n\n\u003cp\u003eDoch wie können wir erreichen, dass unsere Mitarbeitenden die relevanten Tools tatsächlich nutzen und verstehen, wie sie diese richtig einsetzen, um Daten korrekt zu interpretieren? Die Antwort darauf ist einfach, die Umsetzung dessen aber das Gegenteil: Organisationen benötigen data-literate Mitarbeitende.\u003c/p\u003e\n\n\u003ch3 id=\"was-habe-ich-davon-interesse-an-data-literacy-schaffen\"\u003e«Was habe ich davon?»: Interesse an Data Literacy schaffen\u003c/h3\u003e\n\n\u003cp\u003eDie Motivation, mit Daten arbeiten zu wollen, ergibt sich nicht immer von allein. Im Buch \u003cem\u003eHumanizing Data Strategy\u003c/em\u003e beschreibt Tiankai Feng (2024) mehrere spannende Möglichkeiten, wie Datenstrategien nachhaltig umgesetzt werden können. Hervorheben möchte ich jedoch einen bestimmten Punkt: Der individuelle Nutzen ist für Mitarbeitende mindestens genauso motivierend wie der Nutzen für die Organisation. Menschen nutzen Daten, wenn diese ihren Arbeitsalltag erleichtern. Wenn die angebotenen Tools beherrscht werden, können Arbeitsabläufe automatisiert und somit erleichtert werden. Wenn Teams ihre Produktivität und Innovationskraft steigern können, hilft ihnen das nicht nur in ihrem persönlichen Erfolg und ihrer Entwicklung, sondern auch der gesamten Organisation (Feng, 2024).\u003c/p\u003e\n\n\u003cp\u003eFührungskräfte haben eine besondere Vorbildfunktion, indem sie die Arbeit mit Daten vorleben und Anreize schaffen, sich darauf einzulassen. Das bedeutet, dass sie die Arbeit mit Daten nicht nur selbst erledigen, sondern auch den Mitarbeiterinnen und Mitarbeitern einen Anreiz bieten, es ihnen gleichzutun. Dabei ist entscheidend, dass nicht nur mit Daten kommuniziert wird, sondern auch über Daten sowie die Erfolge, die durch deren Nutzung erzielt wurden. Beispiele hierfür sind die Veröffentlichung erfolgreich umgesetzter Datenprojekte oder die Anwendung von Gamification bei der Gestaltung von Lernpfaden.\u003c/p\u003e\n\n\u003ch3 id=\"enabling-team-community-of-practice\"\u003eEnabling-Team \u0026amp; Community of Practice\u003c/h3\u003e\n\n\u003cp\u003eDer Aufbau von Datenkompetenz wird durch soziale Strukturen unterstützt. Einerseits kann er durch sogenannte Enabling-Teams vorangetrieben werden. Diese Teamform wird in Kapitel 5 von \u003cem\u003eTeam Topologies\u003c/em\u003e ausführlich beschrieben (Skelton \u0026amp; Pais, 2019). Dieses Team arbeitet eng mit den Domänenteams zusammen, coacht, begleitet und unterstützt den praktischen Aufbau von Datenprodukten durch Workshops, Self-Service-Angebote oder durch die aktive Förderung der Zusammenarbeit zwischen den Teams, die Daten austauschen. Die Erfolge eines Enabling-Teams sind fast immer indirekt, weshalb eine klare Unterstützung durch Führungskräfte nötig ist. Diese müssen Zeit zum Lernen schützen und Zusammenarbeit belohnen (Skelton \u0026amp; Pais, 2019).\u003c/p\u003e\n\n\u003cp\u003eEine Community of Practice zum Thema Daten hält den Lernprozess lebendig. Sie verbindet alle, die mit Daten arbeiten, ermöglicht den Austausch positiver wie negativer Erfahrungen, schafft Wissen, beispielsweise über Datenqualität, und etabliert gemeinsame Standards. Damit ergänzt sie das Enabling-Team: Das Enabling-Team schafft gezielt neue Fähigkeiten, während die Community dafür sorgt, dass dieses Wissen breit verankert und die kognitive Last reduziert wird, indem sie relevante Inhalte für die Organisation vorfiltert. Gemeinsam machen sie Lernen zu einem kontinuierlichen, sozialen Prozess.\u003c/p\u003e\n\n\u003cp\u003eDie Einführung einer datenproduktorientierten Architektur ist kein reiner Projektplan, sondern die Etablierung eines Lernsystems. Um unseren Mitarbeitenden angemessene Lernpfade, Lernhilfen und Aufgaben bereitstellen zu können, müssen wir sie sehr gut kennen und nach Kompetenzniveau und Interessensgebieten gruppieren. Enabling-Teams können Wissenslücken erkennen. Eine gute Community fördert funktionierende Arbeitsweisen zutage und bietet ein Diskussionsforum für kontroverse Themen. Diese Feedbackschleifen halten den Prozess der Transformation zu einer datengetriebenen Organisation am Laufen und machen die Datenplattform zu einem lebendigen System.\u003c/p\u003e\n\n\u003ch3 id=\"die-plattform-als-katalysator\"\u003eDie Plattform als Katalysator\u003c/h3\u003e\n\n\u003cp\u003eNeben den sozialen Strukturen ist die Umsetzung der technischen Plattform eine tragende Säule, um eine datenproduktorientierte Architektur erfolgreich auszurollen. Die Plattform sollte zur Teilnahme einladen und nicht abschrecken. Das heißt, bei der Auswahl oder dem Bau von Tools müssen die Nutzer:innen im Mittelpunkt stehen. Wir nutzen so etwa für Deployments von Datenprodukten Tools wie Terraform, die Software-Engineers bereits kennen. Für fachliche Nutzer:innen binden wir Datenquellen an bekannte Programme wie Microsoft Excel oder Google Sheets an.\u003c/p\u003e\n\n\u003cp\u003eNicht immer ist das bekannte Tooling ausreichend, um kompetenten Nutzer:innen alle Möglichkeiten zu bieten, die Daten voll auszunutzen. So möchten Nutzer:innen mit einem gewissen Reifegrad für die Datenauswertung beispielsweise auch BI-Tools wie Microsoft Power BI oder Tableau nutzen. Bei Tools im Bereich Software- und Data-Engineering reicht die grundsätzliche Kenntnis eines Tools oft nicht aus, um es in der konkreten Umgebung ohne nerviges Try-and-Error umsetzen zu können. Hier müssen klare Dokumentationen, einfache Onboarding-Prozesse, sinnvolle Defaults und automatisierte Qualitätschecks Teil des Designs sein.\u003c/p\u003e\n\n\u003cp\u003eWenn Werkzeuge nicht bekannt sind, sollten sie in vertretbarer Zeit erlernbar sein, denn sonst wird die falsche Botschaft vermittelt. Wichtig ist, die Arbeit mit Daten zu verinnerlichen. Programme und Softwarebibliotheken sind dabei primär als Vehikel zu verstehen. Das soll nicht heißen, dass die Einführung einer neuen Technologie nicht als Motivation dienen kann. Vor allem technikaffine Mitarbeitende werden damit angesprochen. Eine technisch brillante, aber kognitiv überfordernde Plattform wird von den Nutzern jedoch meistens nicht akzeptiert.\u003c/p\u003e\n\n\u003ch3 id=\"erfolg-messbar-machen\"\u003eErfolg messbar machen\u003c/h3\u003e\n\n\u003cp\u003eWir können die Akzeptanz unserer Plattform nicht erzwingen. Da nicht jede Organisation gleich ist, gibt es bei der Erstellung von Lernpfaden und bei der Toolauswahl keine Universallösung. Wir können jedoch unsere eigene Datenkompetenz unter Beweis stellen, indem wir den Verlauf des Rollouts beobachten und analysieren, um an den richtigen Stellen nachzujustieren.\u003c/p\u003e\n\n\u003cp\u003eZu den entsprechenden Metriken zählen beispielsweise:\u003c/p\u003e\n\n\u003ch4 id=\"kompetenzaufbau-entwickeln-menschen-tatsachlich-neue-fahigkeiten\"\u003eKompetenzaufbau – Entwickeln Menschen tatsächlich neue Fähigkeiten?\u003c/h4\u003e\n\n\u003cul\u003e\n\u003cli\u003e\u003cp\u003eDie Teilnahme an Workshops zeigt das Interesse und dass unsere Maßnahmen angenommen werden.\u003c/p\u003e\u003c/li\u003e\n\u003cli\u003e\u003cp\u003eDie Quantität der eigenständig gelieferten Datenprodukte aus Domänenteams zeigt, dass das Gelernte auch angewendet wird.\u003c/p\u003e\u003c/li\u003e\n\u003cli\u003e\u003cp\u003eRegelmäßige Umfragen zum Datenvertrauen geben Aufschluss darüber, ob Mitarbeitende sich sicher genug fühlen, Daten in ihren Entscheidungen zu nutzen.\u003c/p\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\n\u003ch4 id=\"kulturelle-signale-schwer-zu-messen-aber-besonders-aussagekraftig\"\u003eKulturelle Signale – schwer zu messen, aber besonders aussagekräftig\u003c/h4\u003e\n\n\u003cul\u003e\n\u003cli\u003e\u003cp\u003eWenn Datenprodukte über Domänengrenzen hinweg wiederverwendet werden, entsteht echte Zusammenarbeit.\u003c/p\u003e\u003c/li\u003e\n\u003cli\u003e\u003cp\u003eWeniger Ad-hoc-Anfragen an das zentrale Datenteam zeigen, dass Teams zunehmend selbstständig arbeiten können.\u003c/p\u003e\u003c/li\u003e\n\u003cli\u003e\u003cp\u003eInterne sowie externe Talks oder Blogposts von Mitarbeitenden zum Thema Datennutzung signalisieren, dass eine Datenkultur nicht nur gelebt, sondern auch aktiv weitergegeben wird.\u003c/p\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\n\u003ch4 id=\"plattformnutzung-kommt-die-plattform-im-arbeitsalltag-an\"\u003ePlattformnutzung – kommt die Plattform im Arbeitsalltag an?\u003c/h4\u003e\n\n\u003cul\u003e\n\u003cli\u003e\u003cp\u003eDie Zahl aktiver Nutzer:innen und veröffentlichter oder wiederverwendeter Datenprodukte gibt an, ob das System wächst oder stagniert.\u003c/p\u003e\u003c/li\u003e\n\u003cli\u003e\u003cp\u003eDie Zeit bis zum Datenzugriff ist dabei besonders wichtig: Ist sie zu lang, bricht der Kreislauf aus Neugier und Lernen bereits am Anfang ab.\u003c/p\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\n\u003ch4 id=\"plattform-usability-fur-echte-menschen-mit-echten-aufgaben-nutzlich\"\u003ePlattform-Usability – für echte Menschen mit echten Aufgaben nützlich?\u003c/h4\u003e\n\n\u003cul\u003e\n\u003cli\u003e\u003cp\u003eWelche Features werden bevorzugt genutzt, welche gemieden?\u003c/p\u003e\u003c/li\u003e\n\u003cli\u003e\u003cp\u003eWo brechen Nutzer:innen Interaktionspfade ab?\u003c/p\u003e\u003c/li\u003e\n\u003cli\u003e\u003cp\u003eWerden Datenprodukte gefunden und dann auch wirklich genutzt?\u003c/p\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\n\u003cp\u003eWir sollten diese Metriken nicht nutzen, um uns nach außen hin gut zu verkaufen oder unseren Projekterfolg zu beschönigen. Sie sind Spiegel, die zeigen, ob Menschen lernen, zusammenarbeiten und dem System vertrauen. Und um genau das zu erreichen, müssen wir die Kennzahlen auswerten, unser Vorgehen entsprechend ausrichten und bei Bedarf nachjustieren.\u003c/p\u003e\n\n\u003ch3 id=\"der-elefant-im-raum-data-literacy-ai\"\u003eDer Elefant im Raum: Data Literacy \u0026amp; AI\u003c/h3\u003e\n\n\u003cp\u003eKaum ein Thema dominiert derzeit die Diskussionen in Unternehmen so sehr wie künstliche Intelligenz. KI-Werkzeuge werden zunehmend direkt an Unternehmensdaten angebunden. Das Versprechen: Man stellt einfach eine Frage und erhält sofort eine Antwort. „Talk to your data“ ist keine Zukunftsvision mehr und die Möglichkeiten sind beeindruckend: Zusammenhänge, für deren Analyse früher tiefgehende Fachkenntnisse und viel Zeit nötig waren, lassen sich heute in wenigen Minuten erkunden. Dadurch sinkt die Einstiegshürde enorm und der Kreislauf aus Datenzugang, Neugier und Kompetenz kann erheblich beschleunigt werden.\u003c/p\u003e\n\n\u003cp\u003eDiese Chance bringt jedoch auch eine neue Verantwortung mit sich. Large Language Models halluzinieren, das heißt, sie liefern selbstsicher klingende Antworten, die sachlich falsch sein können. Wer die zugrundeliegenden Daten nicht kennt und über keine Grundkompetenz im Umgang mit ihnen verfügt, wird solche Fehler nicht erkennen. Data Literacy ist somit keine Alternative zu KI-Werkzeugen, sondern eine Voraussetzung. Data Literacy befähigt Menschen, Antworten zu hinterfragen, einzuordnen und verantwortungsvoll darauf zu handeln.\u003c/p\u003e\n\n\u003cp\u003eIch sehe Chatbots und ähnliche Werkzeuge als weitere Tools in unserem Ökosystem, denen gezielt Daten zur Verfügung gestellt werden sollten, genauso wie Excel oder Power BI. Der Unterschied ist, dass Fehler hier schwerer zu erkennen sind, da die Ausgabe wie eine sichere Aussage wirkt und nicht wie eine Formel, deren Berechnung nachvollziehbar ist. Data Literacy bedeutet in diesem Kontext, fähig zu sein, Fehler und sonstige Unstimmigkeiten zu erkennen.\u003c/p\u003e\n\n\u003ch3 id=\"literaturverzeichnis\"\u003eLiteraturverzeichnis\u003c/h3\u003e\n\n\u003cp\u003eMorrow, J. (2024). Be Data Literate: The data literacy skills everyone needs to succeed (2. Aufl.). Kogan Page\u003c/p\u003e\n\n\u003cp\u003eFeng T. (2024). Humanizing Data Strategy: Leading Data with the Head and the Heart. Technics Publications\u003c/p\u003e\n\n\u003cp\u003eSkelton, M., \u0026amp; Pais, M. (2019). Team Topologies: Organizing Business and Technology Teams for Fast Flow. IT Revolution Press\u003c/p\u003e\n\u003cp\u003eEine erfolgreiche Datenplattform ermöglicht nicht nur den einfachen Zugriff auf Daten, sondern auch das Lernen mit Daten. Darüber hinaus vermittelt sie das Verständnis dafür, wie aus Daten Erkenntnisse gewonnen werden können, die sich in direkten Nutzen verwandeln lassen. Ein demokratisierter Zugang zu Daten weckt Neugier, Data Literacy verwandelt Neugier in Kompetenz. Wenn Menschen lernen, teilen und Daten vertrauen, entsteht Akzeptanz ganz von selbst und unsere Dateninitiative entwickelt sich von einem technischen Projekt zu einem echten Lernsystem.\u003c/p\u003e\n\u003c/body\u003e\u003c/html\u003e\n","image":"https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2000/v1/uploads-production/jhivd57m1yoxq957fzyqzx4pl7y4?_a=BACMTiAE"},{"id":"https://www.innoq.com/de/blog/2026/05/self-made-souv-nebu-chat/","url":"https://www.innoq.com/de/blog/2026/05/self-made-souv-nebu-chat/","date_published":"2026-05-03T00:00:00.000+00:00","date_modified":"2026-04-30T16:26:15.702+02:00","author":[{"name":"Philipp Beyerlein","url":"https://www.innoq.com/ch/staff/philipp-beyerlein/"}],"content_html":"\u003c!DOCTYPE html PUBLIC \"-//W3C//DTD HTML 4.0 Transitional//EN\" \"http://www.w3.org/TR/REC-html40/loose.dtd\"\u003e\n\u003chtml\u003e\u003cbody\u003e\n\u003cp\u003e\u003cem\u003eInspiriert vom \u003ca href=\"https://di.day/de\"\u003eDigital Independence Day\u003c/a\u003e, der zu Rezepten für digitale Souveränität aufruft, teilen wir hier regelmäßig eigene Lösungsansätze zu Themen, die unsere Kunden bewegen – ab sofort jeden ersten Sonntag im Monat.\u003c/em\u003e\u003c/p\u003e\n\n\u003cp\u003eWer «Slack Alternative Open Source» googelt, bekommt schnell Ergebnisse. Mattermost, Rocket.Chat, Element. Alles Open Source, alles vielversprechend. Die Websites versprechen Enterprise-Kommunikation ohne Vendor Lock-in, mit Screenshots von Benutzeroberflächen, die genauso aussehen wie Slack. Channels, Threads, Dateifreigabe, Integrationen. Man denkt: Das könnte funktionieren. Also klickt man sich durch die Feature-Listen.\u003c/p\u003e\n\n\u003cp\u003eUnd dann sieht man die Spalte «Enterprise»: SSO-Integration, LDAP-Anbindung, Compliance-Export, Clustering. Alles hinter einer kommerziellen Lizenz. Die Community Edition ist funktional so weit reduziert, dass man sie als Unternehmen nicht produktiv betreiben kann. Nicht aus Versehen, sondern absichtlich. So funktioniert das Geschäftsmodell. Die Community Edition existiert, damit man das Produkt ausprobiert. Sie existiert nicht, damit man es produktiv einsetzt.\u003c/p\u003e\n\n\u003cp\u003eDas Frustrierende daran: Bei anderen Software-Kategorien hat die Open-Source-Welt das Problem längst gelöst. Nextcloud ist das beste Beispiel. Ein Unternehmen kann Nextcloud installieren, produktiv betreiben und hat dabei volle Kontrolle über seine Daten. SSO funktioniert in der Community Edition. Clustering ist möglich. Es gibt eine lebendige Community, die das Produkt weiterentwickelt, und eine kommerzielle Option für Support, aber keine künstliche Feature-Schranke, die den produktiven Einsatz verhindert. Bei Enterprise-Chat sieht es anders aus. Dort gibt es keine Nextcloud. Dort gibt es nur Schaufenster mit Lizenzkasse.\u003c/p\u003e\n\n\u003cp\u003eUnd das ist das eigentliche Problem: An der Souveränität ändert sich nichts. Wer von Slack zu Mattermost Enterprise wechselt, tauscht die Flagge, aber nicht die Abhängigkeit. Die Rechnung kommt von einem anderen Absender, und die Roadmap bestimmt jemand anderes. Souverän ist das nicht.\u003c/p\u003e\n\n\u003chr\u003e\n\n\u003ch3 id=\"die-lizenzfalle\"\u003eDie Lizenzfalle\u003c/h3\u003e\n\n\u003cp\u003eWas bei Enterprise-Chat sichtbar wird, ist kein Einzelfall. Es ist ein Geschäftsmodell mit eigenem Namen: Open Core. Die Idee klingt zunächst vernünftig: Der Kern der Software ist Open Source, jeder kann ihn nutzen, verändern und betreiben. Die Community profitiert, das Unternehmen dahinter verdient Geld mit Enterprise-Features, Support und Hosting. Soweit die Theorie.\u003c/p\u003e\n\n\u003cp\u003eIn der Praxis sieht es anders aus. Die Community Edition wird gezielt so beschnitten, dass sie für den professionellen Einsatz unbrauchbar ist. Nicht, weil die Features technisch schwierig wären. Sondern weil sie den kommerziellen Wert der Enterprise Edition ausmachen. SSO ist dabei das offensichtlichste Beispiel, weil es in praktisch jedem Unternehmen ab einer bestimmten Größe eine Grundvoraussetzung ist. Wer seine Mitarbeiter nicht über das zentrale Identity Management anmelden kann, betreibt eine Insellösung. Und genau dieses Feature sitzt zuverlässig hinter der Lizenzschranke.\u003c/p\u003e\n\n\u003cp\u003eDas gleiche Muster findet sich bei Clustering, bei Audit-Logging, bei Compliance-Exporten. Es sind nie die Nischen-Features, die fehlen. Es sind immer die Features, ohne die ein produktiver Betrieb im Unternehmenskontext nicht möglich ist. Das ist keine zufällige Lücke. Es ist die Architektur des Geschäftsmodells.\u003c/p\u003e\n\n\u003cp\u003eUnd dieses Modell ist nicht auf Chat-Software beschränkt. Redis wechselte 2024 von einer permissiven Open-Source-Lizenz zu einer restriktiven. Die Community Edition kann zwar Clustering, aber ohne automatisches Shard-Management, ohne Multi-Tenancy und ohne die Hochverfügbarkeit, die ein produktiver Betrieb verlangt. Wer das braucht, landet bei Redis Enterprise. Dasselbe Open-Core-Muster, nur diesmal bei der Infrastruktur. HashiCorp machte 2023 dasselbe mit Terraform und Vault. MongoDB ging denselben Weg schon Jahre früher. Die Lizenz, auf die man sich bei der Einführung verlassen hat, kann sich Jahre später ändern, ohne dass man irgendetwas dagegen tun kann. Man sitzt dann vor der Wahl: zahlen, migrieren oder das Risiko akzeptieren. Keine dieser Optionen ist souverän.\u003c/p\u003e\n\n\u003cp\u003eDas Problem ist nicht, dass Unternehmen für Software bezahlen. Gute Software zu finanzieren ist richtig und wichtig. Das Problem ist, dass «Open Source» als Versprechen der Unabhängigkeit verwendet wird, während das Geschäftsmodell dahinter genau diese Unabhängigkeit systematisch verhindert. Wer von Slack zu Mattermost Enterprise wechselt, hat ein neues Logo auf der Rechnung. Die Abhängigkeitsstruktur ist dieselbe.\u003c/p\u003e\n\n\u003chr\u003e\n\n\u003ch3 id=\"ein-protokoll-kein-produkt\"\u003eEin Protokoll, kein Produkt\u003c/h3\u003e\n\n\u003cp\u003eBei Matrix liegt der Fall anders als bei Mattermost oder Rocket.Chat. Matrix ist kein Produkt eines Unternehmens, das eine Community Edition als Köder anbietet. Matrix ist ein offener Standard. Das Protokoll ist öffentlich spezifiziert, aktiv weiterentwickelt und definiert, wie Server und Clients miteinander kommunizieren. Jeder kann eine eigene Implementierung schreiben, und die bestehenden Clients funktionieren damit ohne Änderungen. Element, Cinny, FluffyChat: all diese Clients sprechen das Matrix-Protokoll und verbinden sich mit jedem Server, der die Client-Server-API korrekt implementiert.\u003c/p\u003e\n\n\u003cp\u003eDas ist ein entscheidender Unterschied. Wer einen eigenen Mattermost-Server baut, hat keine Clients. Wer einen eigenen Matrix-Server baut, hat sofort ein ganzes Ökosystem an ausgereiften Clients, die einfach funktionieren.\u003c/p\u003e\n\n\u003cp\u003eAber genau hier beginnt das Problem. Auf der Serverseite sieht es düster aus. Synapse, die bekannteste und ausgereifteste Implementierung, ist AGPLv3-lizenziert. Das heißt: Jede Modifikation muss als Open Source veröffentlicht werden, sobald der Server über ein Netzwerk bereitgestellt wird. Für Unternehmen, die ein angepasstes Berechtigungsmodell oder branchenspezifische Compliance-Funktionen brauchen, ist das ein Ausschlusskriterium. Dendrite und Conduit sind zwar Apache 2.0 lizenziert, aber beide nicht produktionsreif. Kein echtes Clustering, offene Performance-Fragen, kein Enterprise-Featureset.\u003c/p\u003e\n\n\u003cp\u003eDie Lücke ist real: Es gibt keinen Matrix-Server, der gleichzeitig eine permissive Lizenz hat, horizontal skaliert und die Features mitbringt, die Unternehmen und Behörden brauchen. Die Wahl besteht zwischen Synapse mit Lizenzproblem, unreifen Alternativen oder der kommerziellen Element-Lösung, die das Abhängigkeitsproblem nur verlagert.\u003c/p\u003e\n\n\u003cp\u003eIch hatte diesen Gedanken schon länger: Warum baut das eigentlich niemand selbst? Das Protokoll ist offen, die Clients sind da. Was fehlt, ist der Server. Aber ein Chat-System ist komplex. Unternehmenskritisch. Tausende Nutzer, die darauf angewiesen sind, dass es funktioniert, verwaltet von zwei oder drei Admins. In klassischen Softwareprojekten braucht man dafür ein spezialisiertes Team, das sich mit verteilten Systemen, Echtzeit-Kommunikation und Kryptografie auskennt. Das ist teuer, und für ein einzelnes Projekt kaum zu rechtfertigen. Als One-Man-Show ist es schlicht nicht zu schaffen. Nicht weil das Wissen fehlt, sondern weil Architektur, Implementierung und die schiere Breite der technischen Entscheidungen für eine einzelne Person zu viel sind.\u003c/p\u003e\n\n\u003cp\u003eAlso blieb der Gedanke ein Gedanke. Bis sich die Rahmenbedingungen geändert haben.\u003c/p\u003e\n\n\u003chr\u003e\n\n\u003ch3 id=\"also-baue-ich-es-selbst\"\u003eAlso baue ich es selbst\u003c/h3\u003e\n\n\u003cp\u003eAgentische Softwareentwicklung, also die Arbeit mit LLM-gestützten Agenten, die eigenständig Teilaufgaben lösen, hat verändert, was eine einzelne Person leisten kann. Nicht weil ein LLM besseren Code schreibt als ein erfahrener Entwickler. Sondern weil sie die Konzeptionsarbeit auf ein Maß reduziert, das vorher undenkbar war. Was früher Monate Architekturarbeit mit einem spezialisierten Team erforderte, lässt sich heute in strukturierten Sessions erarbeiten, wenn man den richtigen Prozess hat und die Ergebnisse beurteilen kann.\u003c/p\u003e\n\n\u003cp\u003eWichtig ist dabei die Unterscheidung: Das hier ist kein Vibe-Coding. Kein One-Shot-Run, bei dem man einem LLM sagt «bau mir einen Chat-Server» und hofft, dass etwas Brauchbares herauskommt. Die Matrix-Community hat diese Erfahrung bereits gemacht. Im Januar 2026 veröffentlichte Cloudflare einen Matrix-Homeserver auf Cloudflare Workers, beworben als «production-grade» mit Deploy-Button. Matthew Hodgson von der Matrix Foundation zerlegte die Implementierung innerhalb von Stunden \u003ca href=\"https://matrix.org/blog/2026/01/28/matrix-on-cloudflare-workers/\"\u003eöffentlich\u003c/a\u003e: keine State Resolution, keine Permission-Checks, keine echte Authentifizierung. Hodgson verglich es mit «einem Dateisystem, das Berechtigungen ignoriert, oder einer Blockchain ohne Konsens-Mechanismus.» Die Community erkannte die typischen Merkmale von LLM-generiertem Code sofort: TODO-Kommentare in kritischer Security-Logik, plausible Struktur ohne funktionale Tiefe. Cloudflare musste den Artikel kurz nach Veröffentlichung mit einem Disclaimer als Proof of Concept nachbessern.\u003c/p\u003e\n\n\u003cp\u003eWas hier stattdessen passiert, ist Spec-Driven Development mit dem BMAD-Framework, einem strukturierten Prozess für agentische Produktentwicklung. Ein Ablauf, der von der Produktvision über Architekturentscheidungen bis hin zu Epics und Implementierungsplänen führt. Das Ergebnis ist kein Code, den man blind übernimmt, sondern echtes Engineering: Ein vollständiges Product Requirements Document, eine durchdachte Architektur, saubere Epics. Gemacht von einem Menschen, unterstützt von Agenten.\u003c/p\u003e\n\n\u003cp\u003eIch habe es ausprobiert. Nicht als Experiment, sondern mit einer konkreten Produktvision: Ein Matrix-kompatibler Enterprise-Chat-Server. Apache 2.0. Horizontales Clustering. SSO by default. DSGVO-tauglich mit Audit-Log und Compliance-Zugriff. Alles, was die Lizenzfalle mir vorenthält, baue ich selbst.\u003c/p\u003e\n\n\u003cp\u003eDas Ergebnis heißt Nebu. \u003cem\u003eBenannt nach der Nebuchadnezzar aus dem Film Matrix, dem Schiff, das die Menschen aus der Matrix befreit hat.\u003c/em\u003e\u003c/p\u003e\n\n\u003ch4 id=\"komplexitat-rausnehmen-wo-es-geht\"\u003eKomplexität rausnehmen, wo es geht\u003c/h4\u003e\n\n\u003cp\u003eDie erste Architekturentscheidung war die wichtigste: Nur die Matrix Client-Server API implementieren, auf Federation komplett verzichten. Federation, also die Fähigkeit, dass verschiedene Matrix-Server miteinander kommunizieren, ist der komplexeste Teil des Protokolls. State Resolution, Server-to-Server-Authentifizierung, Key Exchange: das macht rund 40% der Gesamtkomplexität aus. Enterprise-Deployments laufen ohnehin auf der eigenen Instanz. Der Verzicht ist kein Kompromiss, sondern eine bewusste Entscheidung, die Komplexität drastisch zu reduzieren. Und das Entscheidende: Alle Standard-Clients funktionieren trotzdem ohne Änderungen weiter.\u003c/p\u003e\n\n\u003ch4 id=\"die-lizenzfalle-im-eigenen-entwurf\"\u003eDie Lizenzfalle im eigenen Entwurf\u003c/h4\u003e\n\n\u003cp\u003eDann der Moment, der die ganze These dieses Artikels auf den Punkt bringt. Ich schaue mir den ersten Blueprint an. Redis für Session-Caching, NATS für den internen Message-Bus. Beides Standardentscheidungen, beides technisch völlig in Ordnung. Dann schaue ich mir die Lizenzen an. Redis: SSPL seit 2024. Für produktives Clustering braucht man eine kommerzielle Lizenz. Ich starre auf meinen eigenen Entwurf und merke: Die Lizenzfalle, die mich überhaupt erst zu diesem Projekt gebracht hat, steckt in meinem ersten Blueprint. Und es ging weiter: Schaut man sich an, was Element Server Suite Pro unter der Haube hat, findet man Synapse Pro mit Redis als zentraler Komponente für die Worker-Kommunikation beim horizontalen Skalieren. Redis, das seit 2024 unter SSPL steht. Der Vendor, der einen aus der Slack-Abhängigkeit befreien soll, baut seine Lösung auf einer Komponente auf, die selbst in der Lizenzfalle steckt.\u003c/p\u003e\n\n\u003cp\u003eAlso: raus damit. Elixir bringt alles mit, was sonst externe Komponenten wie Redis oder NATS erfordern würden. Der eingebaute In-Memory-Store ETS ersetzt Redis, ohne Netzwerk-Hop und ohne zusätzliche Lizenz. Process Groups übernehmen den internen Message-Bus. Elixir Distribution mit TLS verbindet die Cluster-Nodes. Keine externe Abhängigkeit, alles aus einer Plattform.\u003c/p\u003e\n\n\u003cp\u003eIch kenne mich mit Elixir selbst nicht im Detail aus. Aber ich weiß, dass WhatsApp auf Erlang/OTP läuft, und dass das Aktor-Modell von OTP für genau diese Art von Echtzeit-Messaging gebaut wurde. Mit agentischer Entwicklung brauche ich kein Elixir-Expertenwissen. Ich brauche die Architekturentscheidung, dass Elixir die richtige Wahl ist, und die Fähigkeit, die Ergebnisse zu bewerten. Den Rest übernimmt der Agent.\u003c/p\u003e\n\n\u003cp\u003eUnd genau hier liegt ein Vorteil, der leicht übersehen wird: Weil ich den Code nicht selbst schreibe, kann die Technologiewahl rein anhand der Produktvision erfolgen. Elixir ist die optimale Sprache für Echtzeit-Messaging. Go ist optimal für HTTP-Gateways. In einem klassischen Projekt müsste ich Kompromisse eingehen, weil das Team nur bestimmte Sprachen beherrscht. Wahrscheinlich wäre alles in Go gelandet, weil die verfügbaren Entwickler Go können. Das wäre funktional, aber ohne die Vorteile einer Sprache, die für genau diesen Anwendungsfall optimiert ist. Und selbst wenn man sich für den optimalen Stack entscheidet, braucht man plötzlich Go-Entwickler und Elixir-Entwickler, was das Team größer und das Projekt teurer macht. Mit agentischer Entwicklung fällt dieser Kompromiss weg. Die beste Technologie für den Job gewinnt, nicht die, die gerade im Team verfügbar ist.\u003c/p\u003e\n\n\u003ch4 id=\"das-ergebnis-drei-komponenten-keine-lizenz\"\u003eDas Ergebnis: drei Komponenten, keine Lizenz\u003c/h4\u003e\n\n\u003cp\u003eAm Ende stehen drei Laufzeit-Komponenten: Ein Go-Binary für die API- und Media-Gateways. Ein Elixir/OTP-Release für Core Messaging, Session Management und Presence. PostgreSQL als Datenbank. Kein Redis. Kein NATS. Alle Komponenten Apache 2.0 oder BSD-lizenziert. Keine weiteren Lizenzen. Keine Abhängigkeitskette.\u003c/p\u003e\n\n\u003cp\u003eDie Authentifizierung läuft OIDC-first. Nebu verwaltet keine Passwörter. Identität kommt ausschließlich vom externen OIDC-Provider, ob das Dex, Keycloak oder Azure AD ist, spielt keine Rolle. Das Protokoll abstrahiert den Provider. Das hat einen konkreten Sicherheitsvorteil: Kein eigenes Passwort-Management bedeutet eine ganze Kategorie von Sicherheitslücken weniger.\u003c/p\u003e\n\n\u003cp\u003eDazu: ein Compliance-Zugriff mit Vier-Augen-Prinzip und unveränderlichem Audit-Log, kryptografische Signaturen auf jeder Nachricht für Nachrichtenintegrität, und Volltextsuche direkt über PostgreSQL FTS ohne externe Suchkomponente. Alles, wofür anderswo eine Enterprise-Lizenz fällig wird, ist von Anfang an Teil der Architektur.\u003c/p\u003e\n\n\u003cp\u003eDas Fundament: Zwölf Architecture Decision Records, acht Entwicklungsphasen, vollständiges Datenbankschema. Was daraus geworden ist: Ein Matrix-Server, der mit Element und FluffyChat funktioniert. SSO via OIDC ab der ersten Instanz. \u003ccode\u003edocker compose up\u003c/code\u003e, zehn Minuten, läuft. Audit Log und Compliance-Zugriff mit Vier-Augen-Prinzip inklusive — ohne Paywall. Alles unter Apache 2.0: \u003ca href=\"https://github.com/innoq/nebu\"\u003egithub.com/innoq/nebu\u003c/a\u003e / \u003ca href=\"https://gitlab.opencode.de/nebu/nebu-server\"\u003ehttps://gitlab.opencode.de/nebu/nebu-server\u003c/a\u003e\u003c/p\u003e\n\n\u003chr\u003e\n\n\u003ch3 id=\"die-neue-gleichung\"\u003eDie neue Gleichung\u003c/h3\u003e\n\n\u003cp\u003eWas Nebu zeigt, ist kein Einzelfall. Es ist ein Muster. Und dieses Muster hat zwei Ausprägungen.\u003c/p\u003e\n\n\u003cp\u003eDie erste ist die Nebu-Variante: Es gibt ein offenes Protokoll oder einen offenen Standard, aber keine brauchbare Implementierung mit passender Lizenz. In diesem Fall ist Eigenentwicklung die Antwort. Das klingt nach viel, und es ist auch nicht trivial. Aber der Einstieg beginnt nicht bei null. Den Großteil übernehmen bewährte Basis-Technologien, die unangetastet bleiben: Go, Elixir/OTP, PostgreSQL und die gesamte Infrastruktur drumherum. Das Protokoll ist als offener Standard spezifiziert und muss nicht neu erfunden werden. Die fertigen Clients bringt das Matrix-Ökosystem mit, sie funktionieren ohne Anpassung. Was bleibt, ist die eigentliche Server-Implementierung. Das ist ein substanzielles Projekt, aber kein Projekt, das ein Team erfordert, wenn der Prozess stimmt.\u003c/p\u003e\n\n\u003cp\u003eDie zweite Variante betrifft deutlich mehr Unternehmen: Eine Open-Source-Lösung mit passender Lizenz existiert, ist stabil, deckt 90–95% der Anforderungen ab. Aber die letzten 5% fehlen. Ein spezifisches Berechtigungsmodell, eine Integration, die der Vendor nicht priorisiert, ein Compliance-Feature, das nur in der eigenen Branche gebraucht wird. Bisher war die Antwort: die kommerzielle Version kaufen oder einen teuren Dienstleister beauftragen, der sich ins Repository einarbeitet. Der SAP-Effekt: passt zu 90% für jeden, doch die letzten 10% sind die teuersten, weil ein Integrator nötig ist, der tief genug drin ist, um die Anwendung an die eigene Domain anzupassen.\u003c/p\u003e\n\n\u003cp\u003eMit agentischer Entwicklung ändert sich diese Rechnung grundlegend. Sich in ein fremdes Repository einarbeiten, die Architektur verstehen, die richtigen Stellen für eine Erweiterung finden: genau das kann ein Agent. Nicht perfekt, nicht ohne Kontrolle, aber schnell genug und gründlich genug, um einen Fork realistisch zu machen, der vorher wirtschaftlich nicht vertretbar war. Das fehlende Feature, das bisher zur Buy-Lösung gezwungen hat, lässt sich jetzt selbst einbauen.\u003c/p\u003e\n\n\u003cp\u003eDas klassische Gegenargument ist die Wartung: ein Fork, der vom Upstream abschneidet, Merge-Konflikte produziert und am Ende von einem Entwickler abhängt, der auf keinen Fall kündigen darf. Dieses Argument gilt für Code, der direkt in den Fork geschrieben wird. Bei Spec-Driven Development entsteht stattdessen eine Spezifikation der eigenen Anpassungen, die ein Agent bei jedem Upstream-Update erneut anwendet. Das ist noch eine These. Aber eine, die Nebu selbst beweisen wird.\u003c/p\u003e\n\n\u003cp\u003eBeide Varianten führen zum selben Ergebnis: Der Kompromiss zwischen «Open Source, aber unvollständig» und «vollständig, aber abhängig» löst sich auf. Nicht für jedes Problem. Aber für jedes, bei dem die Lücke zwischen dem, was frei verfügbar ist, und dem, was tatsächlich gebraucht wird, überschaubar ist.\u003c/p\u003e\n\n\u003cp\u003eWer profitiert davon? Unternehmen mit eigenem IT-Team, die bei der letzten Lizenzverlängerung keine echte Alternative hatten. Organisationen mit strengen Compliance-Anforderungen. Behörden mit On-Premise-Pflicht. Was es braucht: einen Senior Developer, der Code, Fachlichkeit und Architektur gemeinsam verantworten kann, einen strukturierten Prozess und die Entscheidung, es tatsächlich zu tun.\u003c/p\u003e\n\n\u003cp\u003eAuf Entscheider-Ebene lässt sich der Ansatz auf eine einfache Rechnung reduzieren. Eine Mattermost-Enterprise-Lizenz für 500 Nutzer liegt bei mehreren zehntausend Euro jährlich, ein Element-Server-Vertrag in ähnlicher Größenordnung, dazu Integratorkosten und die laufende Abhängigkeit von Preisgestaltung und Roadmap des Vendors. Auf der anderen Seite stehen LLM-Nutzungskosten für die Architekturarbeit, die Arbeitszeit eines Senior Developers und Infrastrukturkosten für den eigenen Betrieb. Dass Personalzeit bei der Einführung neuer Software einzuplanen ist, gilt für jede Alternative gleichermaßen. Bei einem Greenfield-Projekt wie Nebu lagen die LLM-Kosten im niedrigen dreistelligen Bereich; bei einem Fork, der 90% der Architektur übernimmt, ist das der Deckel. Keine jährliche Lizenzverlängerung, bei der der Preis steigt, weil der Vendor weiß, dass die Wechselkosten höher sind. Kein Risiko, dass ein Lizenzwechsel wie bei Redis oder HashiCorp über Nacht die eigene Infrastruktur infrage stellt. Was bleibt, ist ein Asset, das dem Unternehmen gehört, das intern weiterentwickelt werden kann und dessen Kosten planbar sind.\u003c/p\u003e\n\n\u003chr\u003e\n\n\u003ch3 id=\"grenzen-ehrlich-benannt\"\u003eGrenzen, ehrlich benannt\u003c/h3\u003e\n\n\u003cp\u003eDieser Ansatz ist kein Allheilmittel, und er sollte nicht als solches verkauft werden.\u003c/p\u003e\n\n\u003cp\u003eAgentisch generierte Architektur und Code müssen von jemandem bewertet werden, der die Konsequenzen versteht. Eine Architektur, die plausibel klingt, kann trotzdem grundlegende Fehler enthalten. Die Beschleunigung durch agentische Entwicklung gilt für die Umsetzung, nicht für das Urteilsvermögen, das man mitbringen muss. Das Cloudflare-Desaster zeigt, was passiert, wenn diese Bewertung fehlt: plausibel aussehender Code, der im Ernstfall versagt, und eine Community, die das Vertrauen verliert.\u003c/p\u003e\n\n\u003cp\u003eNicht alles sollte selbst gebaut werden. Kubernetes, PostgreSQL, nginx, Keycloak: Für bewährte Infrastruktur gibt es keine Rechtfertigung, eigene Lösungen zu entwickeln. Der Ansatz funktioniert dort, wo eine reale Lücke besteht. Wo die Lücke nicht existiert, ist er Verschwendung.\u003c/p\u003e\n\n\u003cp\u003eBetrieb und Wartung bleiben eigene Aufgaben. Souveränität bedeutet auch eigene Verantwortung für Security-Patches, Datenbankmigrationen, Backups und Monitoring. Das ist kein Nachteil, sondern der Preis der Kontrolle. Wer das nicht intern abbilden kann oder will, sollte das ehrlich einschätzen, bevor er anfängt.\u003c/p\u003e\n\n\u003chr\u003e\n\n\u003ch3 id=\"self-made-souveranitat\"\u003eSelf-made Souveränität\u003c/h3\u003e\n\n\u003cp\u003eDie Lizenzfalle funktioniert, weil sie auf einer Annahme beruht: Dass «selber bauen» zu teuer, zu komplex und zu riskant ist. Dass Unternehmen keine andere Wahl haben, als zu zahlen oder zu akzeptieren. Diese Annahme war lange richtig. Sie ist es nicht mehr.\u003c/p\u003e\n\n\u003cp\u003eAgentische Softwareentwicklung hat die Gleichung verändert. Nicht weil sie Entwickler überflüssig macht, sondern weil sie einem einzelnen erfahrenen Entwickler ermöglicht, was vorher ein Team erfordert hätte. Die beste Technologie für den Job wählen, unabhängig von den Sprachen, die im Team verfügbar sind. Sich in ein fremdes Repository einarbeiten und die fehlenden 5% selbst einbauen. Oder, wenn es sein muss, eine ganze Implementierung von Grund auf neu aufsetzen, weil kein bestehendes Produkt die Anforderungen mit der richtigen Lizenz erfüllt.\u003c/p\u003e\n\n\u003cp\u003eNebu zeigt, dass dieser Weg gangbar ist. Nicht als Gedankenexperiment, sondern als laufendes Projekt: Apache 2.0, drei Laufzeit-Komponenten, keine Lizenzabhängigkeiten. Element und FluffyChat verbinden sich. [github.com/nebu] — Ein Projekt, das es als One-Man-Show ohne agentische Entwicklung nicht geben würde.\u003c/p\u003e\n\n\u003cp\u003eJedes Unternehmen, das heute vor einer Feature-Matrix sitzt und die gesperrte Enterprise-Spalte betrachtet, hat eine neue Option. Nicht «leben damit» oder «zahlen dafür». Sondern: selbst machen. Die Werkzeuge sind da. Die Prozesse sind erprobt. Die Hürde ist so niedrig wie nie. Wer eine Produktvision hat und jemanden, der sie beurteilen kann, hat heute alles, was es braucht, um aus einer Abhängigkeit eine eigene Lösung zu machen.\u003c/p\u003e\n\n\u003cp\u003eDigitale Souveränität war lange ein Ressourcenproblem. Heute ist sie eine Entscheidung. Ich habe meine getroffen.\u003c/p\u003e\n\n\u003chr\u003e\n\n\u003ch3 id=\"glossar\"\u003eGlossar\u003c/h3\u003e\n\n\u003cp\u003e\u003cstrong\u003eAgentische Softwareentwicklung\u003c/strong\u003e — Softwareentwicklung mit LLM-gestützten Agenten, die eigenständig mehrstufige Aufgaben lösen: Code schreiben, Repositories analysieren, Tests ausführen. Im Unterschied zu einem einzelnen Prompt arbeiten Agenten in strukturierten, iterativen Prozessen mit menschlicher Steuerung.\u003c/p\u003e\n\n\u003cp\u003e\u003cstrong\u003eBMAD-Framework\u003c/strong\u003e — Ein Framework für strukturierte agentische Produktentwicklung, entwickelt von der BMAD-Community (bmad-method.org). BMAD führt systematisch von der Produktvision über Architekturentscheidungen bis zu implementierungsfertigen Epics.\u003c/p\u003e\n\n\u003cp\u003e\u003cstrong\u003eSpec-Driven Development (SDD)\u003c/strong\u003e — Entwicklungsansatz, bei dem Anforderungen und Änderungen als formale Spezifikation formuliert werden, bevor ein Agent sie in Code umsetzt. Im Unterschied zu unstrukturierter Code-Generierung legt SDD den Fokus auf Spezifikation vor Implementierung, sodass der Prozess nachvollziehbar und bei Bedarf wiederholbar ist.\u003c/p\u003e\n\n\u003cp\u003e\u003cstrong\u003eOpen Core\u003c/strong\u003e — Geschäftsmodell, bei dem der Kern einer Software als Open Source veröffentlicht wird, während unternehmenskritische Features hinter einer kommerziellen Lizenz stehen.\u003c/p\u003e\n\n\u003cp\u003e\u003cstrong\u003eLizenztypen im Artikel\u003c/strong\u003e — \u003cem\u003ePermissive Lizenzen\u003c/em\u003e (Apache 2.0, BSD, MIT) erlauben freie Nutzung und Modifikation, auch kommerziell. \u003cem\u003eAGPL\u003c/em\u003e (Affero GPL) ist eine Copyleft-Lizenz, die bei Bereitstellung über ein Netzwerk die Veröffentlichung des Quellcodes verlangt. \u003cem\u003eSSPL\u003c/em\u003e (Server Side Public License) und \u003cem\u003eBSL\u003c/em\u003e (Business Source License) sind restriktive Lizenzen, die kommerzielle Nutzung einschränken und im Artikel als Beispiele für Lizenzwechsel dienen.\u003c/p\u003e\n\n\u003cp\u003e\u003cstrong\u003eMatrix-Protokoll\u003c/strong\u003e — Offener Standard für dezentrale, verschlüsselte Echtzeit-Kommunikation. Das Protokoll spezifiziert, wie Server und Clients interagieren. Jeder kann eine eigene Implementierung schreiben, und bestehende Clients wie Element, Cinny oder FluffyChat funktionieren mit jedem standardkonformen Server.\u003c/p\u003e\n\n\u003cp\u003e\u003cstrong\u003eFederation\u003c/strong\u003e — Die Fähigkeit von Matrix-Servern, serverübergreifend miteinander zu kommunizieren. Ähnlich wie bei E-Mail können Nutzer verschiedener Server Nachrichten austauschen. Technisch der komplexeste Teil des Protokolls.\u003c/p\u003e\n\n\u003cp\u003e\u003cstrong\u003eOIDC (OpenID Connect)\u003c/strong\u003e — Authentifizierungsstandard, der die Identitätsprüfung an einen externen Provider delegiert. In der Praxis bedeutet das: Login über den bestehenden Unternehmens-Identity-Provider statt über eigene Passwörter.\u003c/p\u003e\n\n\u003cp\u003e\u003cstrong\u003eElixir/OTP\u003c/strong\u003e — Programmiersprache und Plattform, die auf der Erlang-VM läuft. OTP (Open Telecom Platform) bietet eingebaute Werkzeuge für nebenläufige, fehlertolerante und verteilte Systeme. WhatsApp nutzt dieselbe Plattform für Echtzeit-Messaging in großem Maßstab.\u003c/p\u003e\n\n\u003cp\u003e\u003cstrong\u003eETS (Erlang Term Storage)\u003c/strong\u003e — In die Erlang/OTP-Plattform eingebauter In-Memory-Datenspeicher. In Nebu ersetzt ETS die externe Komponente Redis für Session-Caching und temporäre Daten.\u003c/p\u003e\n\n\u003chr\u003e\n\n\u003ch3 id=\"quellen\"\u003eQuellen\u003c/h3\u003e\n\n\u003cul\u003e\n\u003cli\u003eMatrix-Protokoll und Spezifikation: \u003ca href=\"https://matrix.org\"\u003ematrix.org\u003c/a\u003e\n\u003c/li\u003e\n\u003cli\u003eCloudflare Workers Matrix-Homeserver, Analyse von Matthew Hodgson: \u003ca href=\"https://matrix.org/blog/2026/01/28/matrix-on-cloudflare-workers/\"\u003ematrix.org/blog/2026/01/28/matrix-on-cloudflare-workers\u003c/a\u003e\n\u003c/li\u003e\n\u003cli\u003eElement Server Suite Pro Architektur: \u003ca href=\"https://docs.element.io/latest/element-server-suite-pro/introduction-to-ess-pro/#architecture\"\u003edocs.element.io\u003c/a\u003e\n\u003c/li\u003e\n\u003cli\u003eRedis Lizenzwechsel zu SSPL (2024): \u003ca href=\"https://redis.io/blog/redis-adopts-dual-source-available-licensing/\"\u003eredis.io/blog/redis-adopts-dual-source-available-licensing\u003c/a\u003e\n\u003c/li\u003e\n\u003cli\u003eHashiCorp BSL-Umstellung (2023): \u003ca href=\"https://www.hashicorp.com/blog/hashicorp-adopts-business-source-license\"\u003ehashicorp.com/blog/hashicorp-adopts-business-source-license\u003c/a\u003e\n\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/body\u003e\u003c/html\u003e\n","image":"https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2000/v1/uploads-production/wkj8d49sgnfyxqwb37xhkgfvk0rh?_a=BACMTiAE"},{"id":"https://www.innoq.com/de/blog/2026/04/accidental-complexity-in-the-heart-of-software/","url":"https://www.innoq.com/de/blog/2026/04/accidental-complexity-in-the-heart-of-software/","date_published":"2026-04-30T00:00:00.000+00:00","date_modified":"2026-04-27T17:15:49.545+02:00","author":[{"name":"Daniel Westheide","url":"https://www.innoq.com/ch/staff/daniel-westheide/"}],"content_html":"\u003c!DOCTYPE html PUBLIC \"-//W3C//DTD HTML 4.0 Transitional//EN\" \"http://www.w3.org/TR/REC-html40/loose.dtd\"\u003e\n\u003chtml\u003e\u003cbody\u003e\n\u003cp\u003eIn den letzten zehn Jahren konnten wir eine interessante Beobachtung machen: Es gab eine Welle von Digitalisierungs- und Modernisierungsprojekten. Ungefähr zur gleichen Zeit wurde Domain-Driven Design zum Mainstream. Taktische Patterns wie Aggregate oder Repository sowie strategische Patterns wie Context Maps oder Bounded Contexts sind heute allgegenwärtig – auch und gerade in diesen Modernisierungsprojekten.\u003c/p\u003e\n\n\u003cp\u003eAuf den ersten Blick ist das lediglich eine zeitliche Korrelation. Aber es gibt guten Grund anzunehmen, dass hinter dem gleichzeitigen Aufstieg von Modernisierungsprojekten und der wachsenden Popularität von DDD mehr als ein Zufall steckt. Genau das wollen wir in diesem Beitrag untersuchen.\u003c/p\u003e\n\n\u003ch3 id=\"alles-was-sie-tun-kann-ist-sie-zu-kontrollieren\"\u003e„Alles, was sie tun kann, ist sie zu kontrollieren\"\u003c/h3\u003e\n\n\u003cp\u003eDie kanonische Quelle zu Domain-Driven Design ist Eric Evans' gleichnamiges Buch\u003ca href=\"https://www.innoq.com/de/blog/2026/04/accidental-complexity-in-the-heart-of-software/#fn:1\" id=\"fnref:1\" title=\"siehe Fußnote\" class=\"footnote\"\u003e[1]\u003c/a\u003e. Martin Fowler schreibt im Vorwort, dass die Komplexität im Herzen eines Softwaresystems nicht vermieden werden kann – alles, was Software tun kann, ist sie zu kontrollieren. Evans selbst ist im Vorwort nicht weniger deutlich: Die größte Komplexität vieler Anwendungen liegt nicht in der Technologie, sondern in der Domäne selbst, und diese Komplexität muss bewältigt werden.\u003c/p\u003e\n\n\u003cp\u003eKein einziges Pattern im Blue Book zielt darauf ab, Komplexität infrage zu stellen, geschweige denn sie zu eliminieren.\u003c/p\u003e\n\n\u003ch3 id=\"essential-oder-accidental\"\u003eEssential oder Accidental?\u003c/h3\u003e\n\n\u003cp\u003e1986 unterschied Fred Brooks in \u003cem\u003eNo Silver Bullet\u003c/em\u003e\u003ca href=\"https://www.innoq.com/de/blog/2026/04/accidental-complexity-in-the-heart-of-software/#fn:2\" id=\"fnref:2\" title=\"siehe Fußnote\" class=\"footnote\"\u003e[2]\u003c/a\u003e zwischen \u003cem\u003eEssential Complexity\u003c/em\u003e und \u003cem\u003eAccidental Complexity\u003c/em\u003e. Essential Complexity steckt im Problem selbst – sie lässt sich nicht wegdiskutieren. Accidental Complexity ist gemacht: historisch gewachsen, durch Organisationsstrukturen geformt, von niemandem hinterfragt.\u003c/p\u003e\n\n\u003cp\u003eEvans geht im Blue Book davon aus, dass die Domänenkomplexität, der wir begegnen, tatsächlich essential ist. Sie wird als gegeben hingenommen. DDD bietet Werkzeuge, um sie handhabbar zu machen. Aggregates, Bounded Contexts, Anti-Corruption Layers, Domain Events – das sind alles Werkzeuge für genau diese Aufgabe. Kein einziges Pattern fragt, ob diese Komplexität tatsächlich existieren muss.\u003c/p\u003e\n\n\u003cp\u003eEin erheblicher Teil dessen, was wir für Essential Complexity halten, ist in Wirklichkeit hausgemacht. Prozesse, die „schon immer so waren\", werden nicht mehr als begründungsbedürftig wahrgenommen. Ihre bloße Existenz gilt als Beweis für ihre Notwendigkeit. Das ist kein DDD-Problem. Es lässt sich besser durch das psychologische Phänomen des \u003ca href=\"https://en.wikipedia.org/wiki/Status_quo_bias\"\u003eStatus-quo-Bias\u003c/a\u003e erklären, wie es Kahneman und Tversky beschrieben haben: Verluste wiegen psychologisch schwerer als gleichwertige Gewinne, und die Aufgabe des Status quo fühlt sich wie ein Verlust an.\u003c/p\u003e\n\n\u003cp\u003eDDD ist das richtige Werkzeug für Essential Complexity. Das Problem ist, dass die Methodik keine Antwort auf die Frage bietet, wie man erkennt, ob Komplexität wirklich essential ist. Und weil die Werkzeuge von DDD so gut darin sind, Komplexität handhabbar zu machen, lässt der Druck nach, der nötig wäre, um diese Frage überhaupt zu stellen. Es ist wie ein sehr wirksames Schmerzmittel: Sobald die Symptome gut behandelt sind, fragt niemand mehr nach der Ursache.\u003c/p\u003e\n\n\u003ch3 id=\"was-in-der-praxis-passiert\"\u003eWas in der Praxis passiert\u003c/h3\u003e\n\n\u003cp\u003eAus meinen eigenen Beobachtungen in einer Vielzahl von Projekten kann ich sagen, dass der Einsatz taktischer DDD-Patterns zu einem unhinterfragten Modus Operandi geworden ist. Das ist nicht unbedingt falsch – sie sind eine nützliche gemeinsame Designsprache, mittlerweile fast eine Lingua franca. Aber es ist auch ein Symptom dafür, dass Komplexität zunehmend als Normalzustand akzeptiert wird.\u003c/p\u003e\n\n\u003cp\u003eBei den strategischen Patterns wird es interessanter. Werkzeuge wie Bounded Contexts, Context Maps und Subdomains sind explizit dafür gedacht, die \u003cem\u003erichtigen\u003c/em\u003e Schnitte zu finden. Evans und Vernon würden niemals sagen: Zeichne die bestehenden Abteilungsgrenzen nach und nenne das eine Context Map. Aber genau das passiert viel zu oft. Der Monolith wird zerlegt, die Bounded Contexts folgen Conway’s Law, und die neue Architektur spiegelt die alte Organisationsstruktur wider. Die Dysfunktion bekommt neue Kleider.\u003c/p\u003e\n\n\u003cp\u003eDas ist kein Fehlgebrauch, den man DDD anlasten kann. Aber es passiert systematisch, und die Erklärung liegt nicht in DDD selbst, sondern im Kontext, in dem es eingesetzt wird.\u003c/p\u003e\n\n\u003cp\u003eDas Ergebnis ist häufig, dass neue Software mit modernen Technologien gebaut wird, aber lediglich die alten Prozesse reproduziert. Häufig nicht einmal das – denn in der Legacy-Welt sind viele Prozesse gar nicht explizit in Software modelliert, sondern leben in den Köpfen der Menschen und in Excel-Tabellen.\u003c/p\u003e\n\n\u003cp\u003eEin Symptom solcher Modernisierungsprojekte sind User Stories, die nur die gewünschten Auswirkungen auf die Benutzeroberfläche beschreiben, aber über den zugrundeliegenden Geschäftsprozess schweigen – ein Badge, das einen Status anzeigt, ein Button, der ihn speichert, und ein Business-Workflow, der weiterhin vollständig in den Köpfen der Mitarbeitenden stattfindet, außerhalb der teuer modernisierten Software.\u003c/p\u003e\n\n\u003ch3 id=\"zu-spat-zu-viel-druck\"\u003eZu spät, zu viel Druck\u003c/h3\u003e\n\n\u003cp\u003eWarum ist das so? Es gibt keine einfache Erklärung, aber nach meiner Erfahrung spielen mehrere Faktoren eine Rolle. Einer ist, dass Modernisierungsprojekte oft nicht dann starten, wenn es sinnvoll wäre, sondern wenn der Schmerz unerträglich wird. Das Legacy-System verursacht so viele Probleme, dass es so schnell wie möglich abgeschaltet werden muss. Genau dieser Druck ist der Grund, warum niemand mehr Zeit hat, Prozesse neu zu denken.\u003c/p\u003e\n\n\u003cp\u003eReinertsen\u003ca href=\"https://www.innoq.com/de/blog/2026/04/accidental-complexity-in-the-heart-of-software/#fn:3\" id=\"fnref:3\" title=\"siehe Fußnote\" class=\"footnote\"\u003e[3]\u003c/a\u003e hat \u003cem\u003eCost of Delay\u003c/em\u003e als Metrik im Kontext der Neuproduktentwicklung populär gemacht: Was kostet es uns pro Woche, die wir das Produkt später als geplant auf den Markt bringen? Das Konzept gilt aber ebenso für Legacy-Modernisierung. Wer früh modernisiert, hat noch Spielraum für Entscheidungen. Wer wartet, bis es brennt, modernisiert unter Notfallbedingungen – jede weitere Verzögerung bei der Ablösung des alten Systems ist extrem teuer.\u003c/p\u003e\n\n\u003cp\u003eBestehende Prozesse mit DDD zu modellieren kostet Zeit. Aber es kostet weniger Zeit als echte Prozessreflexion und Veränderung, und vor allem erfordert es keinen organisatorischen Mut. Unter Druck gewinnt immer die Methodik, die beides spart.\u003c/p\u003e\n\n\u003ch3 id=\"das-fehlende-mandat\"\u003eDas fehlende Mandat\u003c/h3\u003e\n\n\u003cp\u003eAuch ohne Zeitdruck: Auftraggeber bestellen typischerweise Software, keine Prozessberatung. IT-Architekt:innen haben ein Mandat für Technologie, nicht für die Fachdomäne. Alle machen ihren Job. Niemand macht den Job, der eigentlich nötig wäre.\u003c/p\u003e\n\n\u003cp\u003eDass das Mandat so selten erteilt wird, hat Gründe, die über Zeitdruck und Rollendefinitionen hinausgehen. Prozessvereinfachung ist für einige Stakeholder schlicht existenzbedrohend. Diese Stakeholder und die zugehörigen Abteilungen haben ein strukturelles Interesse an der Existenz von Prozessen, die gesteuert werden müssen. Das ist keine Kritik; es ist rationales Eigeninteresse, geformt durch Organisationsstrukturen und Anreize. Aber es erklärt, warum die Frage nach Vereinfachung so selten gestellt wird.\u003c/p\u003e\n\n\u003ch3 id=\"domain-storytelling-to-be-das-vernachlassigte-werkzeug\"\u003eDomain Storytelling to-be – das vernachlässigte Werkzeug\u003c/h3\u003e\n\n\u003cp\u003eDas Werkzeug für den richtigen Schritt existiert übrigens. Hofer und Schwentner haben das To-be-Szenario in \u003cem\u003eDomain Storytelling\u003c/em\u003e\u003ca href=\"https://www.innoq.com/de/blog/2026/04/accidental-complexity-in-the-heart-of-software/#fn:4\" id=\"fnref:4\" title=\"siehe Fußnote\" class=\"footnote\"\u003e[4]\u003c/a\u003e als gleichberechtigten Modus eingebaut, nicht als Anhängsel. Es geht ausdrücklich nicht darum zu modellieren, wie die Dinge sind, sondern wie sie sein sollten.\u003c/p\u003e\n\n\u003cp\u003eIn der Praxis ist es fast immer nur As-is oder ein halbherziges To-be, das sich nicht traut, nennenswert von bestehenden Prozessen und Strukturen abzuweichen – schlicht weil der Projektkontext auf Umsetzung ausgerichtet ist, nicht auf Prozessveränderung. Der Moment, in dem ein To-be, das wirklich etwas verändert, möglich wäre, ist oft bereits verstrichen, wenn das Projekt startet.\u003c/p\u003e\n\n\u003ch3 id=\"komplexitat-als-statussymbol\"\u003eKomplexität als Statussymbol\u003c/h3\u003e\n\n\u003cp\u003eEs gibt noch eine Dimension, die selten offen diskutiert wird. Manche praktizieren DDD nicht trotz der Komplexität, sondern gerade wegen der Komplexität. Komplexe Lösungen signalisieren Expertise. Das DDD-Vokabular signalisiert Zugehörigkeit zur Community. Wer Komplexität eliminiert, hat nichts vorzuweisen. Wer ein ausgefeiltes Domain Model präsentiert, demonstriert Können.\u003c/p\u003e\n\n\u003cp\u003eDas ist eine spezifische Ausprägung dessen, was Graeber in \u003cem\u003eBullshit Jobs\u003c/em\u003e\u003ca href=\"https://www.innoq.com/de/blog/2026/04/accidental-complexity-in-the-heart-of-software/#fn:5\" id=\"fnref:5\" title=\"siehe Fußnote\" class=\"footnote\"\u003e[5]\u003c/a\u003e beschreibt: Menschen, die Sinn für sich selbst erzeugen, indem sie Komplexität managen, die sie selbst erzeugt haben. Für Berater:innen kommt ein struktureller Anreiz hinzu: Komplexität schafft Arbeit.\u003c/p\u003e\n\n\u003ch3 id=\"die-ernuchternde-bilanz\"\u003eDie ernüchternde Bilanz\u003c/h3\u003e\n\n\u003cp\u003eDie Welle von Digitalisierungs- und Modernisierungsprojekten der letzten zehn Jahre war real. Die Ergebnisse dieser Projekte sind ernüchternd. Das Haupthindernis ist meist nicht schlechte Technologie, sondern die mangelnde Veränderungsbereitschaft einer Organisation.\u003c/p\u003e\n\n\u003cp\u003eDas ist kein Zufall. Es ist die direkte Konsequenz davon, Modernisierung als technisches Problem zu behandeln. Neue Systeme, neue Architektur, sorgfältig modellierte Domänen – aber die Organisation bleibt, wie sie ist. Dann ist das Ergebnis vorhersehbar: Die Dysfunktion überlebt die Technologie.\u003c/p\u003e\n\n\u003ch3 id=\"fazit\"\u003eFazit\u003c/h3\u003e\n\n\u003cp\u003eModernisierungs- und Digitalisierungsprojekte sind keine Technologieprojekte. Sie erfordern eine Organisation, die bereit ist, sich zu verändern – und das ist mehr als neue Software einzuführen und Mitarbeitende in deren Nutzung zu schulen. Solange das nicht verstanden wird, solange Modernisierung als technisches Problem mit technischen Lösungen behandelt wird, wird sich strukturell nichts ändern. DDD bietet das perfekte Werkzeug für dieses Mindset, und niemand hat einen starken Anreiz, daran etwas zu ändern.\u003c/p\u003e\n\n\u003cp\u003eWas Entwickler:innen und Berater:innen tun könnten: beharrlich fragen. Warum muss das so sein? Warum nicht einfach das Legacy-System weiterlaufen lassen? Nicht als Rhetorik, sondern als echte Frage, immer wieder gestellt. Die wichtigste Frage ist nicht, wie man etwas modelliert, sondern ob es überhaupt existieren muss.\u003c/p\u003e\n\n\u003cfoot-notes class=\"footnotes\"\u003e\n\n\u003col class=\"footnotes__list\"\u003e\n\n\u003cli id=\"fn:1\"\u003e\n\u003cp\u003eEric Evans: Domain-Driven Design: Tackling Complexity in the Heart of Software, Addison-Wesley, 2003 \u003ca href=\"https://www.innoq.com/de/blog/2026/04/accidental-complexity-in-the-heart-of-software/#fnref:1\" title=\"zurück zum Text\" class=\"reversefootnote\"\u003e ↩︎\u003c/a\u003e\u003c/p\u003e\n\u003c/li\u003e\n\n\u003cli id=\"fn:2\"\u003e\n\u003cp\u003eFred Brooks: No Silver Bullet: Essence and Accidents of Software Engineering, 1986 \u003ca href=\"https://www.innoq.com/de/blog/2026/04/accidental-complexity-in-the-heart-of-software/#fnref:2\" title=\"zurück zum Text\" class=\"reversefootnote\"\u003e ↩︎\u003c/a\u003e\u003c/p\u003e\n\u003c/li\u003e\n\n\u003cli id=\"fn:3\"\u003e\n\u003cp\u003eDonald Reinertsen: The Principles of Product Development Flow, Cenna Books, 2009 \u003ca href=\"https://www.innoq.com/de/blog/2026/04/accidental-complexity-in-the-heart-of-software/#fnref:3\" title=\"zurück zum Text\" class=\"reversefootnote\"\u003e ↩︎\u003c/a\u003e\u003c/p\u003e\n\u003c/li\u003e\n\n\u003cli id=\"fn:4\"\u003e\n\u003cp\u003eStefan Hofer, Henning Schwentner: Domain Storytelling, Addison-Wesley, 2021 \u003ca href=\"https://www.innoq.com/de/blog/2026/04/accidental-complexity-in-the-heart-of-software/#fnref:4\" title=\"zurück zum Text\" class=\"reversefootnote\"\u003e ↩︎\u003c/a\u003e\u003c/p\u003e\n\u003c/li\u003e\n\n\u003cli id=\"fn:5\"\u003e\n\u003cp\u003eDavid Graeber: Bullshit Jobs, Simon \u0026amp; Schuster, 2018 \u003ca href=\"https://www.innoq.com/de/blog/2026/04/accidental-complexity-in-the-heart-of-software/#fnref:5\" title=\"zurück zum Text\" class=\"reversefootnote\"\u003e ↩︎\u003c/a\u003e\u003c/p\u003e\n\u003c/li\u003e\n\n\u003c/ol\u003e\n\u003c/foot-notes\u003e\n\u003c/body\u003e\u003c/html\u003e\n","image":"https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2000/v1/uploads-production/5bhmgeu9lk9mr728qule2uuffunt?_a=BACMTiAE"},{"id":"https://www.innoq.com/de/blog/2026/04/vom-vibe-coder-zum-agentic-engineer/","url":"https://www.innoq.com/de/blog/2026/04/vom-vibe-coder-zum-agentic-engineer/","date_published":"2026-04-20T00:00:00.000+00:00","date_modified":"2026-04-20T11:19:19.125+02:00","author":[{"name":"Torben Keller","url":"https://www.innoq.com/ch/staff/torben-keller/"}],"content_html":"\u003c!DOCTYPE html PUBLIC \"-//W3C//DTD HTML 4.0 Transitional//EN\" \"http://www.w3.org/TR/REC-html40/loose.dtd\"\u003e\n\u003chtml\u003e\u003cbody\u003e\n\u003cp\u003eWer Agenten ohne Tests, Linting oder Architektur-Constraints arbeiten lässt, merkt schnell, wohin das führt. Der Code kompiliert, funktioniert vielleicht sogar, aber niemand kann mehr sagen, was passiert, wenn man an einer Stelle etwas ändert. Die Struktur erodiert, Boundaries verschwimmen, und nach ein paar Wochen hat man einen klassischen Big Ball of Mud, nur dass er diesmal in Rekordzeit entstanden ist.\u003c/p\u003e\n\n\u003cp\u003eDas eigentliche Problem ist dabei nicht, dass Agenten schlechten Code schreiben. Sie schreiben den Code, den man ihnen erlaubt zu schreiben, und ohne Guardrails ist alles erlaubt. Das skaliert nicht — schon gar nicht mit der Geschwindigkeit, die Agenten mitbringen. Vibe Coding, das Generieren von Code auf Zuruf ohne systematische Kontrolle, fühlt sich anfangs wie ein enormer Produktivitätssprung an. Aber ohne Richtung produziert man vor allem schneller technische Schulden.\u003c/p\u003e\n\n\u003cp\u003eDie Frage ist eigentlich simpel: Wenn ich nicht mehr jede Zeile lese, wie übernehme ich trotzdem Ownership über den Code? Die Antwort darauf liegt näher als gedacht, denn wir haben dieses Problem schon einmal gelöst.\u003c/p\u003e\n\n\u003ch3 id=\"das-problem-ist-nicht-neu\"\u003eDas Problem ist nicht neu\u003c/h3\u003e\n\n\u003cp\u003eStell dir vor, du steigst in ein bestehendes Projekt ein. Das Team hat gewechselt, die ursprünglichen Entwickler sind längst weg, und du erbst 200.000+ Zeilen Code. Du verstehst nicht jede Zeile, nicht mal jedes Modul. Trotzdem shipst du Features, fixt Bugs und übernimmst Verantwortung. Das ist normaler Brownfield-Alltag, und jeder von uns hat das schon gemacht.\u003c/p\u003e\n\n\u003cp\u003eNiemand würde erwarten, dass du in einem Brownfield-Projekt erst jede Zeile gelesen und verstanden haben musst, bevor du einen Pull Request öffnen darfst. Stattdessen verlässt du dich auf Systeme: Tests sagen dir, ob du etwas kaputt gemacht hast, Linter setzen Konventionen durch, CI-Pipelines fangen Fehler ab, bevor sie es in die Produktion schaffen. Du verstehst den Teil, den du anfasst, und vertraust darauf, dass der Rest abgesichert ist.\u003c/p\u003e\n\n\u003cp\u003eUnd genau das ist die Erkenntnis, auf die es ankommt: \u003cstrong\u003eFür Ownership muss ich nicht jede Zeile kennen. Für Ownership muss ich sicher sein, dass meine Änderung funktioniert und nichts kaputt macht.\u003c/strong\u003e\u003c/p\u003e\n\n\u003cp\u003eKI-generierter Code ist im Grunde nichts anderes als Code von einem Kollegen, der nicht mehr im Raum sitzt, nur dass dieser Kollege deutlich schneller und deutlich mehr produziert. Was Brownfield überhaupt erst möglich macht, ist gute Modularisierung: Lose Kopplung, Hohe Kohäsion. Gut geschnittene Module erlauben es dir, einen kleinen Teil zu verstehen und sicher zu verändern, ohne das Gesamtsystem im Kopf haben zu müssen. Agenten profitieren davon genauso, denn je besser die Modulschnitte, desto fokussierter und fehlerfreier arbeiten sie.\u003c/p\u003e\n\n\u003cp\u003eDas Wissen, wie man Code besitzt, den man nicht geschrieben hat, steckt also schon in uns. Die Frage ist nur, wie wir es auf die Arbeit mit Agenten übertragen.\u003c/p\u003e\n\n\u003ch3 id=\"von-der-spreadsheet-zur-lint-rule\"\u003eVon der Spreadsheet zur Lint Rule\u003c/h3\u003e\n\n\u003cp\u003eBoris Cherny, heute bekannt als Creator von Claude Code, liefert dafür ein gutes Beispiel im \u003ca href=\"https://newsletter.pragmaticengineer.com/p/building-claude-code-with-boris-cherny\"\u003ePodcast von The Pragmatic Engineer\u003c/a\u003e. Bei Meta war er einer der produktivsten Code Reviewer, und seine Methode war überraschend analog: ein Spreadsheet. Jedes Mal, wenn er in einem Review denselben Kommentar hinterließ, etwa «Bitte kein \u003ccode\u003eany\u003c/code\u003e hier» oder «Fehlerbehandlung fehlt», trug er ihn in die Liste ein. Tauchte dasselbe Feedback drei- bis viermal auf, schrieb er eine Lint Rule dafür.\u003c/p\u003e\n\n\u003cp\u003eDas Prinzip dahinter: Repetitives menschliches Feedback wird zu automatisierter Durchsetzung. Statt immer wieder dasselbe in Code Reviews zu sagen, baut man ein System, das es für einen sagt. Der Reviewer wird zum Systemdesigner.\u003c/p\u003e\n\n\u003cp\u003eDass sich dieser Aufwand lohnt, ist auch messbar. Eine \u003ca href=\"https://newsletter.pragmaticengineer.com/p/building-claude-code-with-boris-cherny\"\u003einterne Studie bei Meta\u003c/a\u003e hat gezeigt, dass saubere Codebases einen zweistelligen Prozent-Impact auf die Engineering Productivity haben. Halbfertige Migrationen, inkonsistente Patterns und veraltete Konventionen verlangsamen nicht nur menschliche Entwickler, sondern verwirren KI-Modelle genauso. Ein Agent, der in einer Codebase mit drei verschiedenen Fehlerbehandlungs-Patterns arbeitet, wird alle drei reproduzieren. Konsistenz ist die Grundlage dafür, dass sowohl Menschen als auch Agenten effektiv arbeiten können.\u003c/p\u003e\n\n\u003cp\u003eChernys Spreadsheet-Methode klingt fast banal, aber sie enthält ein Prinzip, das im Kontext von KI-Agenten eine ganz neue Dimension bekommt. Dazu gleich mehr.\u003c/p\u003e\n\n\u003ch3 id=\"der-agent-harness-mehr-als-nur-das-tool\"\u003eDer Agent Harness — mehr als nur das Tool\u003c/h3\u003e\n\n\u003cp\u003eWenn wir das Prinzip «wiederkehrendes Feedback in Tooling umwandeln» ernst nehmen, stellt sich die Frage: Wo lebt dieses Tooling eigentlich? In welchem System greifen Lint Rules, Tests, Architektur-Checks und Prompts ineinander?\u003c/p\u003e\n\n\u003cp\u003eDie Antwort ist der Agent Harness. Im Kern ist das zunächst das Agent-Programm selbst, also Claude Code, Codex oder Cursor mit seiner Agentic Loop. Über Hooks können wir dort direkt integrieren und dem Agenten bei jeder Aktion Feedback geben. Aber zum Harness gehört auch der Agent Workflow drumherum: die Umgebung, in der der Agent arbeitet. Über Git Hooks und CI/CD-Pipelines können wir auch dort ansetzen und dem Agenten Feedback geben, bevor Code überhaupt gemergt wird.\u003c/p\u003e\n\n\u003cp\u003eDie zentrale Frage ist: Wenn ich einen neuen Constraint durchsetzen will, an welchem Integrationspunkt baue ich ihn ein? Zwei Pyramiden helfen bei dieser Entscheidung, beide inspiriert von der Testpyramide.\u003c/p\u003e\n\n\u003cfigure\u003e\r\n\u003cimg src=\"https://res.cloudinary.com/innoq/image/upload/v1/uploads-production/a7lrzk86smmcect7joiavda66rl5?_a=BACMTiAE\" alt=\"Pyramid diagram: Agent Hooks (fast, frequent), Git Hooks, and CI/CD (slow, rare) with side arrows.\" loading=\"lazy\"\u003e\r\n\r\n\u003cfigcaption\u003eDie Tooling Pyramid\u003c/figcaption\u003e\u003c/figure\u003e\r\n\n\u003cp\u003e\u003cstrong\u003eDie Tooling Pyramid\u003c/strong\u003e deckt die deterministische Seite ab. Am Fundament stehen Agent Hooks, die vor oder nach Tool Calls ausgeführt werden. Weil sie bei fast jeder Aktion des Agenten laufen, müssen die integrierten Funktionen extrem schnell sein. Alles was länger dauert, bremst den Agenten bei jedem einzelnen Schritt aus. Darüber liegen Git Hooks (Pre-Commit, Pre-Push), die seltener laufen und deshalb auch etwas mehr Zeit kosten dürfen. Hier passen Formatter, Linter oder schnelle Tests gut rein. An der Spitze steht CI/CD. Dort landen Checks, die so lange dauern, dass man sie nicht zusätzlich lokal laufen lassen will, etwa umfangreiche Testsuiten oder Security Scans. Das Prinzip ist dasselbe wie bei der Testpyramide: Was immer laufen soll, muss schnell sein. Was langsamer ist, gehört weiter nach oben.\u003c/p\u003e\n\n\u003cfigure\u003e\r\n\u003cimg src=\"https://res.cloudinary.com/innoq/image/upload/v1/uploads-production/k45objkicrwk7w0wl0jnkjmp8e1g?_a=BACMTiAE\" alt=\"Three-level pyramid: “AGENTS.md \u0026amp; Global Rules”, “Scoped Rules \u0026amp; Skills”, “Docs Specs”; from general/always to specific/on demand.\" loading=\"lazy\"\u003e\r\n\r\n\u003cfigcaption\u003eDie Prompt Pyramid\u003c/figcaption\u003e\u003c/figure\u003e\r\n\n\u003cp\u003e\u003cstrong\u003eDie Prompt Pyramid\u003c/strong\u003e adressiert durch Prompts alles, was sich nicht deterministisch prüfen lässt. Das Sortierkriterium hier ist der Grad der Spezialisierung: Je allgemeiner eine Information ist, desto weiter unten gehört sie, weil sie bei jeder Aufgabe relevant ist. Je spezifischer, desto weiter oben, weil sie nur in bestimmten Situationen gebraucht wird. An der Basis stehen CLAUDE.md und Global Rules, die immer im Kontext des Agenten geladen sind. In der Mitte stehen Conditional Rules, die gelten wenn der Agent in bestimmten Bereichen der Codebase arbeitet, und Skills, die geladen werden wenn der Agent eine bestimmte Art von Aufgabe erledigt. An der Spitze stehen Docs, Specs und ADRs, die nur on-demand verfügbar sind wenn der Agent sie aktiv braucht. Im Kern ist das Context Engineering: die richtige Information zur richtigen Zeit im Kontext, ohne das Token-Budget zu sprengen.\u003c/p\u003e\n\n\u003cp\u003eDie Entscheidungsregel zwischen den beiden Pyramiden: \u003cstrong\u003eIf you can tool it, tool it. If you can’t, prompt it.\u003c/strong\u003e Was sich deterministisch prüfen lässt, gehört in die Tooling Pyramid. Architekturentscheidungen, Domain-Konventionen oder Stilfragen sind dafür zu lose und gehören in die Prompt Pyramid. Deterministische Durchsetzung ist Prompts gegenüber grundsätzlich vorzuziehen.\u003c/p\u003e\n\n\u003ch3 id=\"der-harness-ist-nie-fertig\"\u003eDer Harness ist nie fertig\u003c/h3\u003e\n\n\u003cp\u003eEin Agent Harness ist nichts, das man einmal aufsetzt und dann vergisst. Er wächst mit jedem PR, den man reviewt.\u003c/p\u003e\n\n\u003cp\u003eDer Zyklus beginnt unspektakulär: Der Agent produziert einen Pull Request, und im Review fällt ein Problem auf, zum Beispiel ein Import aus einer Schicht, die nicht zugreifen darf, oder ein Test ohne Assertions. Bis hierhin normaler Entwickleralltag. Aber jetzt kommt die entscheidende Frage: \u003cem\u003eGibt es Tooling, das dieses Problem automatisch erkennen könnte?\u003c/em\u003e\u003c/p\u003e\n\n\u003cp\u003eWenn ja, wird es integriert: vielleicht eine neue Lint Rule oder ein ArchUnit-Test. Ab sofort läuft der Agent beim nächsten Mal gegen dieses neue Tooling und bekommt das Feedback nicht erst im Review, sondern sofort. Wenn der Check fehlschlägt, fixt er das Problem selbst, bevor ein Mensch es je sieht.\u003c/p\u003e\n\n\u003cp\u003eDas ist ein inkrementeller Prozess, aber die Wirkung ist kumulativ: Jedes Problem, das einmal als Tooling kodifiziert wird, taucht nie wieder auf. Nach Wochen hat der Harness dutzende solcher Checks. Nach Monaten ist er ein dichtes Sicherheitsnetz, das genau die Qualitätsanforderungen des Projekts widerspiegelt.\u003c/p\u003e\n\n\u003cp\u003eHier schließt sich der Kreis zu Boris Cherny. Er trackte wiederkehrende Review-Kommentare in einer Spreadsheet und machte daraus Lint Rules — genau dasselbe Prinzip. Nur dass es mit Agenten eine neue Qualität bekommt, denn der Agent produziert nicht nur den Code, er hilft auch beim Bauen des Toolings. Die Spreadsheet war manuell, der Feedback Loop mit Agenten ist ein sich selbst verstärkender Kreislauf. Mit genug Feedback und Zeit konvergieren Agenten auf die richtige Lösung, nicht durch Magie, sondern durch systematisches Feedback, konsequent angewendet.\u003c/p\u003e\n\n\u003ch3 id=\"was-der-mensch-noch-ownen-muss\"\u003eWas der Mensch noch ownen muss\u003c/h3\u003e\n\n\u003cp\u003eTooling macht Code korrekt, aber es prüft nicht, ob der Code das Richtige tut. Linter fangen Style-Probleme ab, Typ-Checks verhindern Laufzeitfehler, Architektur-Tests sichern Boundaries. Ob die Geschäftslogik stimmt, kann aber kein Hook beantworten.\u003c/p\u003e\n\n\u003cp\u003eDas ist auch die subtilste Gefahr bei Agent-generiertem Code: Tests verifizieren die Annahmen des Agents. Wenn die Annahmen falsch sind, sind die Tests trotzdem grün. Ein konkretes Beispiel: Der Agent implementiert eine Rabattberechnung und schreibt Tests dafür, aber beides basiert auf demselben Missverständnis der fachlichen Anforderung. Der Feedback Loop greift hier nicht, weil es nichts gibt, wogegen er prüfen könnte.\u003c/p\u003e\n\n\u003cp\u003eDeshalb bleibt die Business Logic beim Menschen. Nicht jede Zeile und nicht jede Datei, aber die Stellen, an denen fachliche Entscheidungen getroffen werden. Das hat Konsequenzen für die Architektur: Wer will, dass dieser Review effizient funktioniert, muss dafür designen. Domain Layer isolieren, Fachlogik von Infrastruktur trennen. Nicht weil es theoretisch schön ist, sondern weil es den menschlichen Review auf das fokussiert, was nur ein Mensch prüfen kann. Den Rest sichert das Tooling ab.\u003c/p\u003e\n\n\u003ch3 id=\"der-mindset-shift-vom-vibe-coder-zum-agentic-engineer\"\u003eDer Mindset Shift — vom Vibe Coder zum Agentic Engineer\u003c/h3\u003e\n\n\u003cp\u003eVibe Coder generieren Code auf Zuruf, ohne jegliche Qualitätssicherung, und hoffen, dass das Ergebnis passt. Agentic Engineers arbeiten genauso schnell mit Agenten, aber sie investieren in ihren Harness: Constraints, Feedback-Systeme, deterministische Checks. Sie können sich auf die Fachlichkeit konzentrieren, weil ihre Systeme den Rest absichern. Was die beiden unterscheidet, ist nicht Geschwindigkeit, sondern Kontrolle. Und wer diese Kontrolle hat, kann am Ende auch Ownership für seine Systeme übernehmen.\u003c/p\u003e\n\u003c/body\u003e\u003c/html\u003e\n","image":"https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2000/v1/uploads-production/ng68bvugtjv429bltp6s7gn27tip?_a=BACMTiAE"},{"id":"https://www.innoq.com/de/blog/2026/04/ai-cognitive-lens-domain-knowledge/","url":"https://www.innoq.com/de/blog/2026/04/ai-cognitive-lens-domain-knowledge/","date_published":"2026-04-20T00:00:00.000+00:00","date_modified":"2026-04-20T16:58:10.488+02:00","author":[{"name":"Daniel Westheide","url":"https://www.innoq.com/ch/staff/daniel-westheide/"}],"content_html":"\u003c!DOCTYPE html PUBLIC \"-//W3C//DTD HTML 4.0 Transitional//EN\" \"http://www.w3.org/TR/REC-html40/loose.dtd\"\u003e\n\u003chtml\u003e\u003cbody\u003e\n\u003cp\u003e\u003cem\u003eDies ist der vierte Beitrag der Reihe „Developing with AI Through the Cognitive Lens“. Sie untersucht, wie KI-Werkzeuge beeinflussen, wie Entwickler:innen und Teams lernen, arbeiten und Expertise aufbauen. Auf Basis kognitionspsychologischer Forschung geht es darum, was passiert, wenn wir geistige Arbeit an KI delegieren. In diesem Beitrag weitet sich der Blick über das Programmieren hinaus auf das Requirements Engineering. Ziel der Reihe ist kein vorgefasstes Urteil über KI, sondern den kognitionswissenschaftlichen Befunden zu folgen, wohin sie führen. In diesem Fall führt das zu grundsätzlicher Skepsis gegenüber einer ganzen Klasse von Werkzeugen.\u003c/em\u003e\u003c/p\u003e\n\n\u003cp\u003eIn den bisherigen Beiträgen ging es darum, was die Kognitionspsychologie über hilfreiche und problematische Einsatzweisen von KI beim Programmieren sagt. Programmieren ist jedoch nur ein Teil der Softwareentwicklung. Zunehmend werden KI-Agenten auch für die Erhebung von Anforderungen eingesetzt. Marketingversprechen für Tools wie BMAD sprechen davon, dass statt Wochen nur noch Stunden für Requirements Engineering nötig sind. Können BMAD und andere Werkzeuge für spezifikationsgetriebene Entwicklung etablierte Methoden zur Anforderungserhebung tatsächlich ersetzen? Die Kognitionspsychologie hat dazu einiges zu sagen.\u003c/p\u003e\n\n\u003ch3 id=\"wie-bmad-und-andere-sdd-tools-funktionieren\"\u003eWie BMAD und andere SDD-Tools funktionieren\u003c/h3\u003e\n\n\u003cp\u003eTools wie BMAD versprechen, den Prozess des Requirements Engineering drastisch zu beschleunigen. Statt Wochen mit Workshops, Interviews und iterativer Verfeinerung führt ein KI-Agent Stakeholder durch einen strukturierten Erhebungsprozess und erstellt innerhalb weniger Stunden ein umfassendes Spezifikationsdokument. Buildmode.dev, einer der prominentesten Vertreter dieses Ansatzes, \u003ca href=\"https://buildmode.dev/blog/mastering-bmad-method-2025/\"\u003ebehauptet, die Anforderungserhebung zu reduzieren\u003c/a\u003e von „2–3 Wochen auf 6 Stunden“.\u003c/p\u003e\n\n\u003cp\u003eDer Ablauf beginnt meist mit einer Produktidee oder einer groben Vision. Ein KI-Agent, der die Rolle eines Business Analysts übernimmt (bei BMAD heißt er Mary), interviewt dann den Stakeholder oder die Domänenexpertin und stellt Fragen zu Nutzer:innen, Zielen, Randbedingungen und technischen Anforderungen. Aus den Antworten erzeugt er ein Spezifikationsdokument, das als Blaupause für die Implementierung dient. In ambitionierteren Setups wie BMAD zerlegen zusätzliche Agenten diese Spezifikation in Epics, Stories und Tasks, die wiederum eine weitere Schicht von Agenten umsetzt. Der Mensch wechselt vom Ausführen der Arbeit hin zum Liefern von Domänenwissen und zum Reviewen der Ergebnisse.\u003c/p\u003e\n\n\u003cp\u003eDas wirkt auf den ersten Blick attraktiv, insbesondere für alle, die schon in langwierigen Requirements-Workshops gesessen haben, deren Ergebnis vor allem aus Annahmen bestand, die als Entscheidungen formuliert wurden. Wenn ein Agent denselben Job schneller und strukturierter erledigt, warum sollte man ihn nicht einsetzen?\u003c/p\u003e\n\n\u003ch3 id=\"das-extraktionsparadigma\"\u003eDas Extraktionsparadigma\u003c/h3\u003e\n\n\u003cp\u003eAllen diesen Tools liegt eine implizite Annahme über die Natur von Domänenwissen zugrunde: Es befindet sich in den Köpfen von Stakeholdern und Expert und muss nur abgerufen werden. Die richtigen Fragen, in der richtigen Reihenfolge gestellt, bringen es ans Licht. Der Agent in der Rolle des Business Analysts agiert dabei wie ein besonders systematischer, geduldiger und konsequenter Interviewer. In dieser Logik folgt alles dem Paradigma der Extraktion: Wissen ist eine Ressource, die gefördert wird, der Mensch ist das Vorkommen.\u003c/p\u003e\n\n\u003cp\u003eDiese Annahme ist so tief im Workflow verankert, dass sie selten explizit gemacht wird. Gelegentlich passiert es doch. Der oben erwähnte Beitrag von Buildmode.dev beschreibt den eigenen Ansatz als Ersatz für „iterative discovery“. Dieser Begriff impliziert, dass Anforderungen sich über Zeit entwickeln, durch Feedback, Umsetzung und Lernen. Wer das ersetzen will, geht davon aus, dass das Wissen bereits vollständig vorhanden ist und nur effizient abgerufen werden muss.\u003c/p\u003e\n\n\u003cp\u003eDie meisten Tools bleiben an dieser Stelle stehen und behandeln den Menschen als unvollkommene, aber akzeptable Quelle. Einige gehen weiter. \u003ca href=\"https://github.com/Q00/ouroboros\"\u003eOuroboros\u003c/a\u003e, ein Agent-Framework, dessen \u003ca href=\"https://github.com/Q00/ouroboros/blob/625dec9499e812c62579334773c59b799200f195/README.md\"\u003ealtes README\u003c/a\u003e unverblümt feststellte, dass „HUMANS ARE NOT RATIONAL“, zieht die nächste Konsequenz: Wenn Menschen nicht zuverlässig ausdrücken können, was sie wissen, liegt das Problem nicht an der Methode der Extraktion, sondern am Menschen.\u003c/p\u003e\n\n\u003ch3 id=\"was-die-kognitionswissenschaft-dazu-sagt\"\u003eWas die Kognitionswissenschaft dazu sagt\u003c/h3\u003e\n\n\u003cp\u003eMichael Polanyis Feststellung, dass „wir mehr wissen, als wir sagen können“, bringt das Problem prägnant auf den Punkt. In „The Tacit Dimension“ (1966) argumentiert er, dass ein großer Teil dessen, was Expert wissen, nicht bewusst zugänglich ist und daher nicht artikuliert werden kann. Dieses implizite oder stille Wissen steht im Gegensatz zu explizitem Wissen.\u003c/p\u003e\n\n\u003cp\u003eWenn eine erfahrene Domänenexpertin ihren Arbeitsprozess beschreibt, lässt sie zwangsläufig Dinge aus, weil sie sich ihres Wissens nicht bewusst ist. Dazu gehören etwa Schritte, die sie bei bestimmten Sonderfällen immer ausführt, oder implizite Prüfungen, die sie vornimmt, bevor sie ein Problem eskaliert. Solche Aspekte tauchen in strukturierten Interviews oft nicht auf, weil sie längst unterhalb der Schwelle bewusster Reflexion verankert sind.\u003c/p\u003e\n\n\u003cp\u003eDas SECI-Modell von Nonaka fügt eine weitere Dimension hinzu. Implizites Wissen ist nicht nur schwer zu formulieren, sondern grundsätzlich sozial. Wissen entsteht in Organisationen durch Zyklen aus Sozialisation, Externalisierung, Kombination und Internalisierung. Diese Prozesse benötigen gemeinsamen Kontext, Vertrauen und Zeit.\u003c/p\u003e\n\n\u003cp\u003eEntscheidend ist: Die Methoden, mit denen implizites Wissen tatsächlich sichtbar wird, basieren nicht primär auf Interviews. Sie setzen auf gemeinsame Praxis und direkte Beobachtung. Wenn jemand über die Schulter schaut und fragt: „Warum hast du das gerade so gemacht?“, werden implizite Annahmen deutlich, die in keinem Fragebogen auftauchen würden. Ein KI-Agent, der ein textbasiertes Interview führt, ist per Definition nicht Teil dieses sozialen Gefüges.\u003c/p\u003e\n\n\u003cp\u003eEine dritte Dimension, die im Requirements Engineering selten berücksichtigt wird, ist Zeit. Graham Wallas beschreibt in seinem Modell kreativen Denkens die Inkubationsphase als zentral. Das bedeutet, dass das Gehirn auch außerhalb bewusster Aufmerksamkeit an Problemen weiterarbeitet. Studien zeigen, dass etwa REM-Schlaf die Fähigkeit verbessert, Informationen zu verknüpfen und nicht offensichtliche Zusammenhänge zu erkennen.\u003c/p\u003e\n\n\u003cp\u003eFür die Anforderungserhebung heißt das: Einige der wertvollsten Einsichten lassen sich nicht planen. Sie entstehen unter der Dusche oder mitten in der Nacht. Ein sechsstündiges Interview mit einem KI-Agenten bietet keinen Raum für solche Prozesse. Es verkürzt diese Phase nicht, es streicht sie vollständig.\u003c/p\u003e\n\n\u003cp\u003eDiese drei Perspektiven führen zu derselben Schlussfolgerung: Das Extraktionsparadigma missversteht die Natur dessen, was es zu gewinnen versucht. Domänenwissen ist keine statische Ressource. Es ist implizit, sozial eingebettet und über die Zeit verteilt. Methoden, die diese Eigenschaften ignorieren, verfehlen genau das Wissen, auf das es ankommt.\u003c/p\u003e\n\n\u003ch3 id=\"wie-implizites-wissen-explizit-wird\"\u003eWie implizites Wissen explizit wird\u003c/h3\u003e\n\n\u003cp\u003eDas Problem ist nicht neu, und in der Softwareentwicklung gibt es etablierte Ansätze, die damit umgehen. Domain Storytelling etwa nutzt gemeinsame Erzählformate, in denen Domänenexpert ihre Arbeit schildern, während eine Moderation die Inhalte visuell festhält. So werden Sprache, Rollen und Abläufe sichtbar, die tatsächlich relevant sind. Der Ansatz funktioniert, weil er eine gemeinsame Situation schafft: Alle Beteiligten arbeiten gleichzeitig am selben Verständnis, Missverständnisse werden sofort sichtbar.\u003c/p\u003e\n\n\u003cp\u003eÄhnlich funktioniert Event Storming. Hier kommen Entwickler und Domänenexpert rund um eine gemeinsame Zeitleiste von Domänenereignissen zusammen. Unterschiedliche Perspektiven treffen aufeinander, Reibung entsteht, und genau daraus ergeben sich Erkenntnisse, die keine einzelne Person allein hätte formulieren können.\u003c/p\u003e\n\n\u003cp\u003eBeiden Ansätzen liegt eine Annahme zugrunde, die dem Extraktionsparadigma widerspricht: Domänenwissen existiert, wird aber erst im Austausch, durch Iteration und gemeinsame Arbeit explizit.\u003c/p\u003e\n\n\u003cp\u003eDomain-Driven Design wird gelegentlich so interpretiert, als plädiere es für eine umfassende Modellierung der Domäne im Vorfeld. Martin Fowler widerspricht dem in seinem Vorwort zu Eric Evans’ Buch ausdrücklich. Starke Domänenmodelle entstehen über Zeit, und selbst erfahrene Modellierer entwickeln ihre besten Ideen oft erst nach den ersten Releases. Domain-Driven Design war nie als Rechtfertigung für Big Design Up Front gedacht, sondern als Ansatz für eine kontinuierliche, iterative Auseinandersetzung mit der Domäne über den gesamten Lebenszyklus eines Systems hinweg. Ein großer Teil des relevanten Wissens entsteht spät und wird durch die Erfahrung im Bau und Betrieb des Systems erarbeitet.\u003c/p\u003e\n\n\u003cp\u003eGenau das lässt sich in einer sechsstündigen Erhebung nicht abbilden.\u003c/p\u003e\n\n\u003ch3 id=\"fazit\"\u003eFazit\u003c/h3\u003e\n\n\u003cp\u003eDie Logik des Extraktionsparadigmas, zu Ende gedacht, bleibt nicht bei besseren Interviews stehen. Ouroboros, das Agent-Framework, das ich oben erwähnt habe, macht den nächsten Schritt explizit. Das Problem ist nicht die Methode, sondern der Mensch. Die vorgeschlagene Lösung besteht darin, den Menschen zu „reparieren“, damit er klarer, konsistenter und vollständiger kommuniziert, kurz: leichter von Maschinen verarbeitet werden kann.\u003c/p\u003e\n\n\u003cp\u003eHier zeigt sich der sogenannte \u003ca href=\"https://pluralistic.net/2025/12/05/pop-that-bubble/#u-washington\"\u003eReverse Centaur\u003c/a\u003e in der Praxis. Während beim klassischen Centaur der Mensch die Maschine steuert, hat sich das Verhältnis umgekehrt. Die Maschine setzt den Rahmen, definiert Kategorien und stellt die Fragen. Die Aufgabe des Menschen besteht darin, sich in diese Struktur einzufügen. BMAD erreicht das nicht durch Zwang, sondern durch den Eindruck von Unterstützung: ein geführter Prozess, strukturierte Fragen, ein klares Ergebnis. Gefordert wird keine andere Denkweise, sondern die Anpassung an einen Ablauf, der maschinenlesbare Antworten belohnt und keinen Raum für Unschärfe, Vorläufigkeit oder implizites Wissen lässt.\u003c/p\u003e\n\n\u003cp\u003eDiese Verschiebung ist kein Zufall, sondern die konsequente Folge eines Paradigmas, das Wissen als extrahierbare Ressource betrachtet, statt als Fähigkeit, die sich entwickelt. Dieses Paradigma beginnt nicht bei BMAD oder Ouroboros. Große Sprachmodelle sind selbst Ausdruck davon: trainiert auf dem akkumulierten, verschriftlichten Wissen der Menschheit, verdichtet in einem statistischen Modell, ohne Zustimmung oder Vergütung derjenigen, die dieses Wissen hervorgebracht haben. BMAD und Ouroboros führen diese Logik lediglich weiter, von der Extraktion menschlichen Wissens in Modelle hin zur Extraktion von Domänenwissen in Spezifikationen und schließlich zur schrittweisen Anpassung des Menschen an die Anforderungen der Maschine.\u003c/p\u003e\n\n\u003cp\u003eDie zentrale Frage ist daher keine technische, sondern eine der Richtung. Technologie hat schon immer verändert, wie Menschen arbeiten und denken. Neu ist das nicht. Entscheidend ist, ob diese Anpassung einseitig verläuft: wenn vom Menschen erwartet wird, für die Maschine lesbarer zu werden, während die Maschine nicht in gleichem Maß lernt, sich am Menschen auszurichten.\u003c/p\u003e\n\u003c/body\u003e\u003c/html\u003e\n","image":"https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2000/v1/uploads-production/5qc00owzu8hktdd5qlfnc41f43ne?_a=BACMTiAE"},{"id":"https://www.innoq.com/de/blog/2026/03/autonomous-data-product-size-heuristics/","url":"https://www.innoq.com/de/blog/2026/03/autonomous-data-product-size-heuristics/","date_published":"2026-04-07T00:00:00.000+00:00","date_modified":"2026-04-15T15:52:07.283+02:00","author":[{"name":"Stefan Negele","url":"https://www.innoq.com/ch/staff/stefan-negele/"}],"content_html":"\u003c!DOCTYPE html PUBLIC \"-//W3C//DTD HTML 4.0 Transitional//EN\" \"http://www.w3.org/TR/REC-html40/loose.dtd\"\u003e\n\u003chtml\u003e\u003cbody\u003e\n\u003cp\u003eWer Data Products falsch zuschneidet, produziert vorhersehbare Probleme. Consumer müssen mehrere Datensätze zusammensetzen, nur um einfache Fragen beantworten zu können. Verantwortlichkeiten verschwimmen, weil niemand eindeutig für Semantik, Qualität und Änderungen zuständig ist. Dieselbe Logik wird an mehreren Stellen implementiert – teuer und meist inkonsistent. Data Products blähen sich auf, was es erschwert, die richtigen Informationen zu finden und ihre Inhalte zu verstehen. Sobald Data Products inkonsistent werden und ihre Grenzen verschwimmen, sind operative Störungen vorprogrammiert: Incidents, Daten-Nachlieferungen und Eskalationen durch Stakeholder werden zum Alltag.\u003c/p\u003e\n\n\u003cp\u003eDas Ziel ist das Gegenteil. Ein gut geschnittenes Data Product ist ein stabiles, konsumierbares Paket. Seine Semantik ist so klar, dass Consumer keine zusätzliche Übersetzungsschicht brauchen. Sein Profil ist in sich stimmig, das heißt: Erwartungen an Aktualität, Granularität und Zuverlässigkeit sind realistisch und tatsächlich erfüllbar. Kurz gesagt: Das Data Product ist sowohl eigenständig nutzbar als auch verlässlich.\u003c/p\u003e\n\n\u003cp\u003eZhamak Dehghanis großartiges Buch über \u003ca href=\"https://www.oreilly.com/library/view/data-mesh/9781492092384/\"\u003eData Mesh\u003c/a\u003e ist für mich eine wichtige Inspirationsquelle. Durch meine Arbeit als Berater in diesem Feld und durch den Austausch mit Kolleg:innen habe ich Erfahrung darin gesammelt, diese Theorie in die Praxis zu überführen. Dieser Text soll dabei helfen, Data Products sinnvoll zu schneiden, indem er praktische Heuristiken anbietet. Zuerst geht es um Heuristiken, die für alle Data Products gelten. Danach betrachten wir die spezifischen Heuristiken für die drei Archetypen von Data Products: \u003ca href=\"https://www.datamesh-architecture.com/#source-aligned\"\u003esource-aligned\u003c/a\u003e, \u003ca href=\"https://www.datamesh-architecture.com/#aggregate\"\u003eaggregate\u003c/a\u003e und \u003ca href=\"https://www.datamesh-architecture.com/#consumer-aligned\"\u003econsumer-aligned\u003c/a\u003e.\u003c/p\u003e\n\n\u003ch3 id=\"grundlagen\"\u003eGrundlagen\u003c/h3\u003e\n\n\u003ch5 id=\"klar-definierte-consumer-und-use-cases\"\u003eKlar definierte Consumer und Use Cases\u003c/h5\u003e\n\n\u003cp\u003eEine der wichtigsten Heuristiken ist der Consumer Fit. Ein guter Schnitt ermöglicht es, die naheliegenden Use Cases produktiv umzusetzen, ohne dass Consumer erst eigene Integrationsarbeit leisten müssen. Der primäre Zweck sollte sich in einem einzigen Satz ausdrücken lassen. Fehlen Use Cases, Consumer oder eine klar erkennbare Zielgruppe, gibt es kein Data Product.\u003c/p\u003e\n\n\u003cp\u003eUm zu verstehen, ob ein Data Product für seine Consumer geeignet ist, braucht es solides Requirements Engineering. Das lässt sich sinnvoll über Contract-first und Data-Contract-Workshops abbilden. Data Contracts sind gewissermaßen Schnittstellenbeschreibungen für die Output Ports von Data Products und liefern damit ganz natürlich ein präzises Bild der Anforderungen an das zugrunde liegende Data Product.\u003c/p\u003e\n\n\u003ch5 id=\"stabile-ownership\"\u003eStabile Ownership\u003c/h5\u003e\n\n\u003cp\u003eDie zweite Heuristik ist stabile Ownership. Ein Data Product muss genau einer Domäne oder einem Team gehören, das für Semantik, Qualität und Betrieb verantwortlich ist. Wenn sich kein klarer Owner bestimmen lässt, lässt sich auch kein Data Product sauber definieren. Denn Data Products müssen über ihren gesamten Lebenszyklus hinweg gepflegt und unterstützt werden, damit sie die Anforderungen ihrer Consumer weiterhin erfüllen.\u003c/p\u003e\n\n\u003cp\u003eEs gibt unterschiedliche Auslöser für die Entstehung von Data Products. Die wichtigsten sind:\u003c/p\u003e\n\n\u003cul\u003e\n\u003cli\u003eEin Team veröffentlicht seine Daten, weil es selbst Analysen damit durchführt und davon ausgeht, dass die Daten auch für andere interessant sein könnten.\u003c/li\u003e\n\u003cli\u003eEs gibt eine konkrete Nachfrage nach bestimmten Daten, sodass das zuständige Team direkt angesprochen wird.\u003c/li\u003e\n\u003cli\u003eEin:e Manager:in oder ein Gremium entscheidet, dass ein Data Product entwickelt werden soll, um einen bestimmten Datenbedarf zu decken.\u003c/li\u003e\n\u003c/ul\u003e\n\n\u003cp\u003eIm letzten Fall ist die Ownership-Frage besonders wichtig, weil klar sein muss, wer die Kosten für Entwicklung und Betrieb des Data Products trägt.\u003c/p\u003e\n\n\u003ch5 id=\"konsistente-datenqualitat\"\u003eKonsistente Datenqualität\u003c/h5\u003e\n\n\u003cp\u003eDie zuvor beschriebenen Data Contracts können weitere Hinweise darauf geben, wie ein Data Product sinnvoll geschnitten sein sollte. Sie enthalten Informationen über die Merkmale der Datenqualität. Diese sollten über die Output Ports hinweg konsistent sein, denn die internen Quellen für die einzelnen Output Ports eines Data Products sollten dieselben sein. Diese Aussage muss allerdings etwas relativiert werden – insbesondere bei zeitabhängigen Eigenschaften. So kann ein täglicher CSV-Export nach S3 naturgemäß nicht so aktuell sein wie ein Echtzeit-Datenstrom über Kafka.\u003c/p\u003e\n\n\u003ch5 id=\"geringer-integrationsaufwand\"\u003eGeringer Integrationsaufwand\u003c/h5\u003e\n\n\u003cp\u003eEin Data Product sollte den Integrationsaufwand für seine Consumer möglichst klein halten. Die Abgrenzung passt eher, wenn das Data Product die kleinste sinnvolle eigenständig nutzbare Einheit darstellt, bei der Consumer den Kontext nicht erst durch das Zusammenführen anderer Datensätze rekonstruieren müssen. Im Idealfall können Consumer direkt produktiv mit dem Data Product arbeiten, ohne erst eine zusätzliche Integrationsschicht zu bauen. Wenn die meisten Consumer es sofort mit anderen Produkten kombinieren müssen, ist der Zuschnitt wahrscheinlich zu eng oder es fehlt wesentlicher Kontext.\u003c/p\u003e\n\n\u003cp\u003eGleichzeitig müssen wir darauf achten, dass bestimmte zentrale Datensätze nicht zu Single Points of Failure werden. Insbesondere Stammdaten sind hier Kandidaten, weil ihre Verknüpfung mit anderen Daten oft erheblichen Mehrwert schafft und deshalb häufig erfolgt. Die Integration eines solchen zentralen Data Products birgt Risiken – etwa Kaskadeneffekte im Fehlerfall sowie operative Komplexität, Inkonsistenzen und Verzögerungen. Vor diesem Hintergrund kann ein eigenständiger Datensatz wertvoller sein, wenn er die meisten Use Cases auch ohne angereicherte Daten unterstützt. Gleichzeitig würden seine Konsistenz, Zuverlässigkeit und Nutzbarkeit steigen.\u003c/p\u003e\n\n\u003ch5 id=\"klar-begrenzter-scope\"\u003eKlar begrenzter Scope\u003c/h5\u003e\n\n\u003cp\u003eDer Scope eines Data Products sollte begrenzt sein und eng zu seinem beabsichtigten Zweck passen. Er sollte nur das enthalten, was für diesen Zweck wirklich gebraucht wird – nicht alles, was irgendwann vielleicht einmal nützlich sein könnte. Ein enger Scope verhindert semantisches Rauschen und schützt das Data Product davor, zu groß zu werden. Sobald ein Data Product lose zusammenhängende Daten oder spekulative Ergänzungen aufnimmt, ist der Scope wahrscheinlich zu breit.\u003c/p\u003e\n\n\u003cp\u003eAuf den ersten Blick scheint das dem Prinzip des geringen Integrationsaufwands zu widersprechen. In der Praxis führen beide Prinzipien zusammen jedoch zu einem stabilen, tragfähigen Scope für Data Products: möglichst nutzerfreundlich, aber ohne unnötigen Ballast.\u003c/p\u003e\n\n\u003cfigure\u003e\r\n\u003cimg alt=\"Gradient scale from “High Integration Burden” to “Bloated Scope”; arrow marks “smallest useful standalone unit” in the middle.\" loading=\"lazy\" srcset=\"https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_400/v1/uploads-production/dwrkdpwirnk9lh2p6e7711lj39kd?_a=BACMTiAE 400w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_800/v1/uploads-production/dwrkdpwirnk9lh2p6e7711lj39kd?_a=BACMTiAE 800w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_1024/v1/uploads-production/dwrkdpwirnk9lh2p6e7711lj39kd?_a=BACMTiAE 1024w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_1200/v1/uploads-production/dwrkdpwirnk9lh2p6e7711lj39kd?_a=BACMTiAE 1200w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_1600/v1/uploads-production/dwrkdpwirnk9lh2p6e7711lj39kd?_a=BACMTiAE 1600w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2048/v1/uploads-production/dwrkdpwirnk9lh2p6e7711lj39kd?_a=BACMTiAE 2048w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2300/v1/uploads-production/dwrkdpwirnk9lh2p6e7711lj39kd?_a=BACMTiAE 2300w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2600/v1/uploads-production/dwrkdpwirnk9lh2p6e7711lj39kd?_a=BACMTiAE 2600w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2800/v1/uploads-production/dwrkdpwirnk9lh2p6e7711lj39kd?_a=BACMTiAE 2800w\" sizes=\"(min-width: 1400px) 1024px, 90vw\"\u003e\r\n\u003c/figure\u003e\r\n\n\u003ch4 id=\"allgemeine-heuristiken-fur-den-zuschnitt-von-data-products\"\u003eAllgemeine Heuristiken für den Zuschnitt von Data Products\u003c/h4\u003e\n\n\u003ch5 id=\"klar-definierte-consumer-und-use-cases\"\u003eKlar definierte Consumer und Use Cases\u003c/h5\u003e\n\n\u003cul\u003e\n\u003cli\u003eLässt sich der Hauptzweck in einem Satz beschreiben?\u003c/li\u003e\n\u003cli\u003eGibt es konkrete Teams oder Rollen, die dieses Data Product heute tatsächlich nutzen wollen?\u003c/li\u003e\n\u003c/ul\u003e\n\n\u003ch5 id=\"stabile-ownership\"\u003eStabile Ownership\u003c/h5\u003e\n\n\u003cul\u003e\n\u003cli\u003eIst genau eine Domäne oder ein Team für Semantik, Qualität und Betrieb verantwortlich?\u003c/li\u003e\n\u003cli\u003eWürde dieser Owner auch zukünftige Änderungen glaubwürdig übernehmen?\u003c/li\u003e\n\u003c/ul\u003e\n\n\u003ch5 id=\"konsistente-datenqualitat\"\u003eKonsistente Datenqualität\u003c/h5\u003e\n\n\u003cul\u003e\n\u003cli\u003eSind die Merkmale der Datenqualität über die Output Ports hinweg konsistent?\u003c/li\u003e\n\u003c/ul\u003e\n\n\u003ch5 id=\"geringer-integrationsaufwand\"\u003eGeringer Integrationsaufwand\u003c/h5\u003e\n\n\u003cul\u003e\n\u003cli\u003eIst das die kleinste sinnvoll eigenständig nutzbare Einheit, die Consumer nicht dazu zwingt, mehrere Data Products zusammenzustückeln?\u003c/li\u003e\n\u003cli\u003eKann ein typischer Consumer dieses Data Product sofort eigenständig sinnvoll nutzen?\u003c/li\u003e\n\u003c/ul\u003e\n\n\u003ch5 id=\"klar-begrenzter-scope\"\u003eKlar begrenzter Scope\u003c/h5\u003e\n\n\u003cul\u003e\n\u003cli\u003eEnthält das Data Product nur das, was für seinen Zweck gebraucht wird?\u003c/li\u003e\n\u003cli\u003eIst es auf Dinge beschränkt, die heute tatsächlich nützlich sind?\u003c/li\u003e\n\u003c/ul\u003e\n\n\u003ch3 id=\"source-aligned-data-products\"\u003eSource-aligned Data Products\u003c/h3\u003e\n\n\u003ch5 id=\"semantische-koharenz\"\u003eSemantische Kohärenz\u003c/h5\u003e\n\n\u003cp\u003eSource-aligned Data Products bilden in den meisten Datenlandschaften die Basisschicht. Sie stellen konsumierbare, domänenspezifische Daten bereit, die nah an der operativen Wahrheit bleiben. In der Praxis umfasst ein source-aligned Data Product typischerweise einen konsistenten Datenausschnitt zusammen mit allen lokalen Dimensionen, die für seine Interpretation nötig sind. Die zentrale Idee ist: Consumer sollen eine verlässliche, klar definierte Repräsentation eines einzelnen Themas erhalten, ohne das Quellsystem erst rückwärts analysieren zu müssen.\u003c/p\u003e\n\n\u003cp\u003eDer richtige Scope beginnt bei der Quelle – aber nicht mit der Haltung, einfach alles aus ihr herauszukippen. Ziel ist es, aus Sicht der Consumer das kleinste stabile Paket zu identifizieren. Dazu gehört, zu verstehen, ob sich die Quelldaten sinnvoll aufteilen lassen, zu erkennen, welche Elemente nur gemeinsam sinnvoll sind, und eine schmale Einheit zu finden, mit der Consumer arbeiten können, ohne Integrationen selbst neu aufbauen zu müssen. Wer diese Prinzipien beachtet, verhindert, dass Quellen in winzige Datenschnipsel zerlegt werden, die nur das erzeugende Team noch versteht.\u003c/p\u003e\n\n\u003ch5 id=\"daten-aus-genau-einer-business-domane\"\u003eDaten aus genau einer Business-Domäne\u003c/h5\u003e\n\n\u003cp\u003eStatt ganze, eher technisch geschnittene Systeme zu betrachten, ist es in der Praxis sinnvoller, sich an bestehenden Domänenmodulen oder Microservices zu orientieren. Kund:innen ein Data Product mit dem Namen «Alle Daten aus SAP» anzubieten, ist in der Regel zu breit, semantisch unordentlich und schwer zu beherrschen. Ein Domänenmodul hat dagegen klarere Verantwortungsgrenzen und einen natürlichen Owner. Im \u003ca href=\"https://www.innoq.com/de/topics/domain-driven-design/\"\u003eDomain-Driven Design\u003c/a\u003e st ein Microservice in der Regel einem Bounded Context zugeordnet. Innerhalb dieses Kontexts umfasst das Domänenmodell meist ein oder mehrere Aggregate – nicht zu verwechseln mit dem Archetyp des Aggregate Data Products. Genau diese Aggregate aus dem Domain-Driven Design sind perfekte Kandidaten für source-aligned Data Products.\u003c/p\u003e\n\n\u003cp\u003eIn der Realität kann es pragmatisch sein, dass ein Team ein Data Product auf Basis eines großen Systems erstellt, dessen Daten aus mehreren Subdomänen stammen – etwa dem erwähnten SAP –, um Betriebskosten zu sparen. Wahrscheinlich verletzt das aber das Prinzip der Domain Ownership. Dann brauchen wir ein Team, das die Ownership für dieses Data Product übernehmen kann, indem es es in spezifischere Produkte aufteilt. Im Kern hat ein solches Data Product dieselben Herausforderungen wie der weiter unten beschriebene Archetyp des Aggregate Data Products und sollte deshalb vermieden werden.\u003c/p\u003e\n\n\u003cp\u003eWer das Ganze stärker aus Sicht der Datenarchitektur betrachten möchte, kann Modellierungsansätze wie \u003ca href=\"https://www.kimballgroup.com/data-warehouse-business-intelligence-resources/kimball-techniques/dimensional-modeling-techniques/\"\u003eKimballs Dimensional Modeling Techniques\u003c/a\u003e nutzen. Kimball beschreibt eine Methode zur dimensionalen Modellierung von Data-Warehouse-Strukturen, in der Geschäftsprozesse als Facts (messbare Ereignisse) auf klar definierter Granularität modelliert und durch beschreibende Dimensionen kontextualisiert werden. Fortgeschrittene Modellierungstechniken wie \u003ca href=\"https://www.kimballgroup.com/data-warehouse-business-intelligence-resources/kimball-techniques/dimensional-modeling-techniques/conformed-dimension/\"\u003eConformed Dimensions\u003c/a\u003e werden auf höheren Ebenen interessant – also bei aggregate- oder consumer-aligned-Produkten – oder können sogar im Widerspruch zu Data-Mesh-Prinzipien stehen. Diese Geschäftsprozesse, Facts und Dimensionen können aber eine gute Grundlage für den Zuschnitt von Data Products sein, sofern Data Architects zumindest mit den Grundlagen vertraut sind.\u003c/p\u003e\n\n\u003cp\u003eDie gleiche Sorgfalt ist nötig, wenn entschieden wird, welche Kontextinformationen in ein Data Product gehören. Kontext, der klar innerhalb derselben Domäne owned, gepflegt und weiterentwickelt wird, sollte Teil des Data Products selbst sein. Kontext, der domänenübergreifend geteilt wird und semantisch konsistent bleiben muss – etwa Kund:innen oder Produkte –, sollte als separates Data Product mit eigener Ownership veröffentlicht werden. Andere Produkte sollten auf diese geteilten Domain-Produkte verweisen, statt sie lokal neu zu definieren. So vermeiden wir semantische Drift: also das schleichende Auseinanderlaufen zentraler Geschäftsbegriffe, bis sie in unterschiedlichen Teilen der Datenlandschaft Unterschiedliches bedeuten.\u003c/p\u003e\n\n\u003ch5 id=\"blast-radius-der-quelldaten\"\u003eBlast Radius der Quelldaten\u003c/h5\u003e\n\n\u003cp\u003eAus operativer Sicht sollte vermieden werden, dass Routineänderungen am Source Code viele source-aligned Data Products betreffen. Idealerweise bleibt die Auswirkung von Änderungen am Quellschema oder an der Logik möglichst lokal. Das hilft Teams, den Wartungsaufwand für das Data Product klein zu halten, und gibt Consumern gleichzeitig Einblick darin, wie die operative Welt funktioniert. Wie gut das gelingt, hängt natürlich stark von gutem Upstream-Design ab. Deshalb sollten bekannte Schwächen der Quelle bei der Gestaltung der Output Ports deiner Data Products berücksichtigt werden. Unvermeidbar ist allerdings, dass Änderungen an der Qualität der Quelldaten alle Data Products betreffen, die von den entsprechenden aligned source data abhängen.\u003c/p\u003e\n\n\u003ch4 id=\"spezielle-heuristiken-fur-source-aligned-data-products\"\u003eSpezielle Heuristiken für source-aligned Data Products\u003c/h4\u003e\n\n\u003ch5 id=\"semantische-koharenz\"\u003eSemantische Kohärenz\u003c/h5\u003e\n\n\u003cul\u003e\n\u003cli\u003eErgibt das Data Product für sich genommen Sinn, oder braucht es dafür die anderen Teile der Quelldaten?\u003c/li\u003e\n\u003cli\u003eWirkt es wie ein zusammenhängendes, integriertes Ganzes – und nicht wie eine zufällige Sammlung verwandter Elemente?\u003c/li\u003e\n\u003c/ul\u003e\n\n\u003ch5 id=\"daten-aus-genau-einer-business-domane\"\u003eDaten aus genau einer Business-Domäne\u003c/h5\u003e\n\n\u003cul\u003e\n\u003cli\u003eFolgt der Zuschnitt sinnvollen Domänenmodulen statt ganzen Systemen?\u003c/li\u003e\n\u003cli\u003eEnthalten die Daten nur internen Kontext oder auch domänenübergreifenden Kontext?\u003c/li\u003e\n\u003c/ul\u003e\n\n\u003ch5 id=\"blast-radius-der-quelldaten\"\u003eBlast Radius der Quelldaten\u003c/h5\u003e\n\n\u003cul\u003e\n\u003cli\u003eWirken sich Änderungen an der Datenquelle direkt nur auf dieses eine Data Product aus?\u003c/li\u003e\n\u003c/ul\u003e\n\n\u003ch3 id=\"aggregate-data-products\"\u003eAggregate Data Products\u003c/h3\u003e\n\n\u003ch5 id=\"wert-und-wiederverwendung-versus-kosten-und-komplexitat\"\u003eWert und Wiederverwendung versus Kosten und Komplexität\u003c/h5\u003e\n\n\u003cp\u003eAggregate Data Products bauen auf source-aligned Produkten auf. Sie kombinieren oder verdichten Daten aus mehreren source-aligned Products, um Semantik bereitzustellen, die in einer gesamten Domäne genutzt werden kann. Man kann sie sich als gemeinsame Bausteine vorstellen, die vielen Consumern wiederholte Integrations- und Berechnungsarbeit ersparen. Weil sie domänenübergreifende Bedeutung kodieren, brauchen sie stärkere Governance und mehr Abstimmung als source-aligned Products.\u003c/p\u003e\n\n\u003cp\u003eAggregates sind ein Sonderfall, weil sich Ownership und Kostenverteilung schwerer festlegen lassen. Für ein source-aligned Data Product gibt es in der Regel einen offensichtlichen Owner: die Domäne, die das zugrunde liegende System betreibt. Da sich die Quelldaten von Aggregates oft über mehrere Owner erstrecken, sollten Aggregates nur dann entstehen, wenn ihr gemeinsamer Wert klar ist und die Verantwortung einem einzelnen Team zugewiesen werden kann, das die integrierte Semantik dauerhaft pflegen kann. Bei Aggregates lautet die eigentliche Frage oft nicht, wie man sie schneidet, sondern ob sie überhaupt existieren sollten.\u003c/p\u003e\n\n\u003cp\u003eEin Aggregate anzulegen lohnt sich, wenn:\u003c/p\u003e\n\n\u003cul\u003e\n\u003cli\u003emehrere Teams dieselbe abgeleitete Sicht mit derselben Bedeutung benötigen. Eine gute Faustregel sind drei oder mehr Teams. Wenn jedes Team seine eigene Version baut, wird das teuer und führt zu inkonsistenten Ergebnissen.\u003c/li\u003e\n\u003cli\u003edie Ableitung selbst teuer ist. Typische Beispiele sind Feature-Berechnungen für Machine Learning, Entity Matching oder Deduplizierung. Eine hochwertige Ableitung einmal bereitzustellen und mehrfach zu nutzen, ist günstiger, als sie an vielen Stellen zu wiederholen.\u003c/li\u003e\n\u003cli\u003eder eigentliche Wert erst durch das Zusammenführen mehrerer Quellen entsteht. So kann etwa kein einzelnes source-aligned Data Product eine vollständige Kundensicht liefern. Diese entsteht erst, wenn Bestellungen, Zahlungen, Retouren und CRM-Signale zusammengeführt werden.\u003c/li\u003e\n\u003c/ul\u003e\n\n\u003ch5 id=\"scope-und-governance\"\u003eScope und Governance\u003c/h5\u003e\n\n\u003cp\u003eSie sind nicht sinnvoll, wenn die einzige Motivation der Wunsch nach zentraler Kontrolle ist oder wenn die gemeinsamen Use Cases in Wahrheit heterogen sind und zwangsläufig zu Streit über Definitionen führen würden. In solchen Fällen ist es besser, die Ableitungen näher bei den Consumern zu belassen und bei Bedarf separate consumer-aligned Products bereitzustellen.\u003c/p\u003e\n\n\u003cp\u003eAuch wenn ihre Größe von konkreten Use Cases getrieben wird, brauchen sie dennoch einen engen Scope. Das Risiko besteht darin, ein Aggregate in ein kleines Data Warehouse zu verwandeln, das jede nur denkbare Frage beantworten soll. Das würde Komplexität und Blast Radius erhöhen. Aggregates verändern sich naturgemäß langsam, weil jede semantische Änderung viele Consumer betrifft. Deshalb brauchen sie sorgfältige Governance und klare Grenzen.\u003c/p\u003e\n\n\u003ch4 id=\"spezielle-heuristiken-fur-aggregates\"\u003eSpezielle Heuristiken für Aggregates\u003c/h4\u003e\n\n\u003ch5 id=\"wert-und-wiederverwendung\"\u003eWert und Wiederverwendung\u003c/h5\u003e\n\n\u003cul\u003e\n\u003cli\u003eGibt es mehr als zwei Teams, die dieselbe abgeleitete Sicht mit identischer Bedeutung brauchen?\u003c/li\u003e\n\u003cli\u003eWürden Teams ohne das Aggregate dieselbe Integrations- oder Berechnungslogik immer wieder selbst bauen?\u003c/li\u003e\n\u003cli\u003eEntsteht der eigentliche Wert erst durch das Zusammenführen mehrerer Quellen?\u003c/li\u003e\n\u003c/ul\u003e\n\n\u003ch5 id=\"kosten-und-komplexitat\"\u003eKosten und Komplexität\u003c/h5\u003e\n\n\u003cul\u003e\n\u003cli\u003eIst die Ableitung teuer (Feature Engineering, Entity Matching, Deduplizierung, source-übergreifende Joins)?\u003c/li\u003e\n\u003cli\u003eGibt es im Unternehmen jemanden, der bereit ist, die Kosten für dieses Data Product zu tragen?\u003c/li\u003e\n\u003c/ul\u003e\n\n\u003ch5 id=\"scope-und-governance\"\u003eScope und Governance\u003c/h5\u003e\n\n\u003cul\u003e\n\u003cli\u003eIst der Scope eng genug, damit das Data Product nicht zu einem Mini-Data-Warehouse driftet?\u003c/li\u003e\n\u003cli\u003eIst das Ergebnis wertvoll genug, um die dafür nötige starke Governance zu rechtfertigen?\u003c/li\u003e\n\u003cli\u003eKann das owning Team die integrierte Semantik trotz mehrerer Quellen dauerhaft pflegen?\u003c/li\u003e\n\u003c/ul\u003e\n\n\u003ch3 id=\"consumer-aligned-data-products\"\u003eConsumer-aligned Data Products\u003c/h3\u003e\n\n\u003ch5 id=\"klarer-zweck\"\u003eKlarer Zweck\u003c/h5\u003e\n\n\u003cp\u003eConsumer-aligned Data Products sind für einen spezifischen Zweck entworfen und sollen mit möglichst wenig Aufwand nutzbar sein. Im Vergleich zu source-aligned Data Products sind die Daten – wie der Name schon sagt – auf Endnutzer:innen und anspruchsvollere Analysen optimiert. Statt die Domänenrealität allgemein abzubilden, liefern sie genau die Daten und die Semantik, die Consumer brauchen, um fundierte Entscheidungen zu treffen, Prozesse auszuführen oder ein konkretes analytisches oder operatives Artefakt zu betreiben. Erfolg misst sich daran, ob Consumer das Data Product nutzen können, ohne zuerst eine eigene Integrationsschicht bauen zu müssen.\u003c/p\u003e\n\n\u003cp\u003eEin schneller Test lautet: Dient das Data Product einem zusammenhängenden Zweck für eine klar definierte Zielgruppe? Das Ergebnis kann ein einzelner Report sein oder ein klar abgegrenzter Data Mart, der eine Familie zusammengehöriger Reports unterstützt. Ein Finance Data Mart, der „konsistentes Margen- und Umsatzreporting für den Monatsabschluss“ ermöglicht, besteht diesen Test eindeutig – auch wenn daraus Dutzende Reports gespeist werden. Das Warnsignal ist nicht die Anzahl der beantworteten Fragen, sondern ob diese Fragen demselben Entscheidungskontext angehören. Ein Data Product, das „Finance Reporting, Marketinganalysen, Ad-hoc-Exploration und zukünftige Machine-Learning-Use-Cases“ unterstützen soll, fällt durch, weil es unterschiedliche Zielgruppen und Verantwortlichkeiten vermischt.\u003c/p\u003e\n\n\u003ch5 id=\"naturliche-fokussierte-grosse\"\u003eNatürliche, fokussierte Größe\u003c/h5\u003e\n\n\u003cp\u003eConsumer-aligned Products haben meist eine natürliche Größe – aber diese wird durch den zu erledigenden Job bestimmt, nicht durch ein einzelnes Artefakt. Solche Produkte können direkt einem bestimmten Report oder Dashboard entsprechen oder eine Familie eng verwandter Outputs unterstützen, etwa mehrere Sichten auf dasselbe Dashboard. Weitere Beispiele sind Reverse-ETL-Flüsse in operative Tools oder ein Machine-Learning-Modell mit seinem zugeschnittenen Feature-Set. Das ist eine Heuristik, keine harte Regel, hilft aber dabei, den Scope im Griff zu behalten. Wenn ein Data Product viele sehr unterschiedliche Dashboards oder Modelle beliefert, sollte es wahrscheinlich in mehrere Produkte aufgeteilt werden, die jeweils auf einen bestimmten Consumer ausgerichtet sind.\u003c/p\u003e\n\n\u003ch5 id=\"sinnvolle-grenzen\"\u003eSinnvolle Grenzen\u003c/h5\u003e\n\n\u003cp\u003eIhre Grenzen folgen meist Entscheidungs- oder Prozesslinien statt Systemgrenzen. Ein natürlicher Schnitt ist oft ein geschäftlicher Moment, in dem eine Entscheidung getroffen oder eine Handlung ausgelöst wird. Beispiele dafür sind ein Fraud Analyst, der einen Fall prüft, oder eine Marketing-Verantwortliche, die über die Budgetverteilung entscheidet. Solche Zuschnitte widersprechen oft der Struktur der Quellsysteme – das ist aber in Ordnung, weil consumer-orientierte Produkte nicht die Prozesse abbilden, sondern die Nutzung optimieren sollen.\u003c/p\u003e\n\n\u003ch5 id=\"business-consumer\"\u003eBusiness Consumer\u003c/h5\u003e\n\n\u003cp\u003eSchließlich brauchen sie klare Business-Ziele und ein strenges Scope-Management. Wenn du die Personen oder Teams, die das Data Product nutzen sollen, nicht benennen kannst, besteht die Gefahr, dass du einen nur dünn getarnten Sammeldatensatz baust. Das Data Product sollte nur das enthalten, was für die konkrete Aufgabe gebraucht wird – nicht alles, was irgendwann vielleicht nützlich sein könnte.\u003c/p\u003e\n\n\u003ch4 id=\"spezielle-heuristiken-fur-consumer-aligned-data-products\"\u003eSpezielle Heuristiken für consumer-aligned Data Products\u003c/h4\u003e\n\n\u003ch5 id=\"klarer-zweck\"\u003eKlarer Zweck\u003c/h5\u003e\n\n\u003cul\u003e\n\u003cli\u003eLässt sich dieser Zweck als Satz aus Verb + Objekt ausdrücken (zum Beispiel Churn nach Segmenten überwachen, Nachfrage nach Kategorien prognostizieren oder Betrugsfälle prüfen)?\u003c/li\u003e\n\u003c/ul\u003e\n\n\u003ch5 id=\"naturliche-fokussierte-grosse\"\u003eNatürliche, fokussierte Größe\u003c/h5\u003e\n\n\u003cul\u003e\n\u003cli\u003eUnterstützt das Data Product genau einen Entscheidungskontext, aus dem ein oder mehrere zusammengehörige Dashboards, Reports oder Outputs entstehen?\u003c/li\u003e\n\u003c/ul\u003e\n\n\u003ch5 id=\"sinnvolle-grenzen\"\u003eSinnvolle Grenzen\u003c/h5\u003e\n\n\u003cul\u003e\n\u003cli\u003eFolgt die Grenze einem Prozess und nicht einer Systemgrenze?\u003c/li\u003e\n\u003cli\u003eSpiegelt der Zuschnitt wider, wie ein Consumer handelt oder entscheidet – und nicht, wie Daten zufällig gespeichert sind?\u003c/li\u003e\n\u003c/ul\u003e\n\n\u003ch5 id=\"business-consumer\"\u003eBusiness Consumer\u003c/h5\u003e\n\n\u003cul\u003e\n\u003cli\u003eWird dein Data Product von Business Usern, Data Analysts, Data Scientists oder Anwendungen genutzt?\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eDie richtige Größe für ein Data Product zu finden, ist keine einmalige Entscheidung, sondern ein fortlaufender Balanceakt. Die hier vorgestellten Heuristiken sind keine starren Regeln, sondern Leitfragen, die Teams helfen sollen, fundierte Entscheidungen zu treffen. Dieselben Grundprinzipien gelten, wenn ein source-aligned Product nah an der operativen Wahrheit geschnitten wird, wenn die Kosten eines Aggregates gerechtfertigt werden sollen oder wenn ein consumer-aligned Product auf einen konkreten Entscheidungskontext zugeschnitten wird: klare Ownership, ein definierter Scope und echter Mehrwert für Consumer. Keine Heuristik ersetzt Gespräche mit den Menschen, die das Data Product bauen, betreiben und nutzen werden. Aber ein gemeinsames Vokabular für diese Diskussionen kann die Ergebnisse spürbar verbessern.\u003c/p\u003e\n\n\u003cp\u003eWas meinst du? Hast du ähnliche Überlegungen zum Zuschnitt von Data Products? Fehlt etwas? Lass uns darüber diskutieren!\u003c/p\u003e\n\u003c/body\u003e\u003c/html\u003e\n","image":"https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2000/v1/uploads-production/660eb8ycmb29id5538wx6z59je3x?_a=BACMTiAE"},{"id":"https://www.innoq.com/de/blog/2026/04/jira-ki-ohne-cloud/","url":"https://www.innoq.com/de/blog/2026/04/jira-ki-ohne-cloud/","date_published":"2026-04-05T00:00:00.000+00:00","date_modified":"2026-04-10T14:42:49.099+02:00","author":[{"name":"Nicolas Inden","url":"https://www.innoq.com/ch/staff/nicolas-inden/"}],"content_html":"\u003c!DOCTYPE html PUBLIC \"-//W3C//DTD HTML 4.0 Transitional//EN\" \"http://www.w3.org/TR/REC-html40/loose.dtd\"\u003e\n\u003chtml\u003e\u003cbody\u003e\n\u003cp\u003e\u003cem\u003eInspiriert vom \u003ca href=\"https://di.day/de\"\u003eDigital Independence Day\u003c/a\u003e, der zu Rezepten für digitale Souveränität aufruft, teilen wir hier regelmäßig eigene Lösungsansätze zu Themen, die unsere Kunden bewegen – ab sofort jeden ersten Sonntag im Monat.\u003c/em\u003e\u003c/p\u003e\n\n\u003cp\u003eFachlichkeiten zu besprechen funktioniert am besten im Dialog im Team und mit dem Kunden. Nicht selten ist es dabei so, dass für die Umsetzung wichtige Informationen in Nebensätzen erwähnt werden oder zwischen den Zeilen fallen. Das ist alles weit weg von den Eingabemasken, die uns Jira bietet, um Issues anzulegen. In meinem Alltag hat sich ein Workflow als echter Gamechanger herausgestellt: Notizen und Mitschriften aus Calls oder Chat-Diskussionen direkt an eine KI übergeben, die daraus sauber formulierte Jira-Issues erstellt – inklusive sinnvoller Felder, Beschreibungen und Struktur.\u003c/p\u003e\n\n\u003cp\u003eDas hat auch Atlassian erkannt, und der Jira Cloud einige KI-Features spendiert, die dabei unterstützen:\u003c/p\u003e\n\n\u003cul\u003e\n\u003cli\u003eIssues mit natürlicher Sprache zu suchen, z.B. «Welche Epics wurden im letzten Release umgesetzt?», oder «Welche Tickets hatten wir schon zum Thema XYZ?»\u003c/li\u003e\n\u003cli\u003eInformationen sinnvoll zusammenzufassen, z.B. Kernpunkte aus Kommentaren an Issues herauskristallisieren, oder fachliche Zusammenfassungen eines Epics samt zugehöriger Issues erstellen.\u003c/li\u003e\n\u003cli\u003eIssue-Beschreibungen und Stories aus Gesprächsnotizen zu formulieren\u003c/li\u003e\n\u003cli\u003eIssues sinnvoll in Sub-Tasks zu unterteilen\u003c/li\u003e\n\u003cli\u003euvm.\u003c/li\u003e\n\u003c/ul\u003e\n\n\u003cp\u003eGerade die Möglichkeit, aus einer unstrukturierten Diskussion direkt strukturierte Issues zu erzeugen, spart enorm viel Zeit.\u003c/p\u003e\n\n\u003cp\u003e\u003cstrong\u003eInfo:\u003c/strong\u003e\u003c/p\u003e\n\n\u003cblockquote\u003e\n\u003cp\u003eAuch wenn für Atlassian der Weg eindeutig in Richtung Cloud zeigt - das on-premise Produkt Jira Data Center wird nur noch bis März 2029 supportet - so möchte nicht jeder die Atlassian Cloud verwenden, und damit sind sowohl Jira, als auch die in der Atlassian Cloud bereitgestellten KI-Features gemeint. Doch noch gibt es die Möglichkeit bestehende on-premise Installationen bis zum offiziellen Ende des Supports im März 2029 weiterzubetreiben. Und genau diesen Instanzen wollen wir mit diesem Artikel helfen, von ähnlichen KI-Hilfen zu profitieren.\u003c/p\u003e\n\u003c/blockquote\u003e\n\n\u003cp\u003eUnser Ziel ist eine DSGVO-konforme und Cloud-Act-sichere Nutzung von Jira inklusive der erwähnten KI-Features.\u003c/p\u003e\n\n\u003ch3 id=\"zutaten\"\u003eZutaten\u003c/h3\u003e\n\n\u003cp\u003eDazu brauchen wir:\u003c/p\u003e\n\n\u003col\u003e\n\u003cli\u003eEine selbst-betriebene Instanz von Jira Server oder Jira Data Center\u003c/li\u003e\n\u003cli\u003eZugang zu einer KI\u003c/li\u003e\n\u003cli\u003eEinen MCP-Server (mcp-atlassian), um die KI mit Jira Server zu verbinden\u003c/li\u003e\n\u003cli\u003eEin Tool, in dem die «Diskussion» zwischen User und KI stattfinden kann\u003c/li\u003e\n\u003c/ol\u003e\n\n\u003ch4 id=\"die-jira-instanz\"\u003eDie Jira Instanz\u003c/h4\u003e\n\n\u003cp\u003eWir gehen für \u003cstrong\u003ePunkt 1\u003c/strong\u003e davon aus, dass eine funktionsfähige, lizenzierte Instanz von Jira Server oder Jira Data Center in der aktuellen Version 11 vorhanden ist. Die Möglichkeit, neue Lizenzen für die beiden Produkte zu bekommen, gibt es seit 30.03.2026 leider nicht mehr. Wir gehen aber davon aus, dass es einige Projekte geben wird, die den on-premise Betrieb noch bis zum Ende des Supports im März 2029 aufrecht erhalten wollen.\u003c/p\u003e\n\n\u003ch4 id=\"die-richtige-ki\"\u003eDie richtige KI\u003c/h4\u003e\n\n\u003cp\u003eInteressanter wird es bei \u003cstrong\u003ePunkt 2\u003c/strong\u003e. Atlassian Cloud verwendet einen \u003ca href=\"https://support.atlassian.com/rovo/docs/rovo-data-privacy-and-usage-guidelines/\"\u003eMix an Open-Weights-Modellen und auch Frontier-Modelle von OpenAI und Anthropic\u003c/a\u003e. Eine Konformität mit der DSGVO mag hier noch gegeben sein. Das eigentliche Problem ist der Cloud Act: Durch die interne \u003ca href=\"https://www.atlassian.com/trust/reliability/cloud-architecture-and-operational-practices#cloud-infrastructure\"\u003eNutzung von AWS\u003c/a\u003e – und bei OpenAI und Anthropic sowieso – unterliegen sämtliche Daten dem Cloud Act. Es ist uns also daran gelegen, eine Alternative zu finden.\u003c/p\u003e\n\n\u003cp\u003eGrundsätzlich bieten sich zwei Möglichkeiten: Die Nutzung einer durch einen europäischen Anbieter betriebenen Inferenz-API, oder lokale Inferenz auf dem eigenen Computer. Europäische Anbieter wie StackIt, IONOS oder Scaleway bieten zwar pay-as-you-go Inferenz-APIs an, allerdings ist die Auswahl an aktuellen, leistungsfähigen Modellen dort teilweise begrenzt.\u003c/p\u003e\n\n\u003cp\u003eFür dieses Rezept konzentrieren wir uns daher auf die Verwendung von lokalen Modellen. Wir setzen dafür \u003ca href=\"https://lmstudio.ai/\"\u003eLM Studio\u003c/a\u003e als Inferenz-Engine und Chat-Tool ein. LM Studio ist für macOS, Linux und Windows verfügbar und kann auf der verlinkten Seite heruntergeladen werden.\nSobald es erfolgreich installiert ist, gilt es noch das passende Modell auszusuchen.\u003c/p\u003e\n\n\u003cp\u003e\u003cstrong\u003eInfo:\u003c/strong\u003e\u003c/p\u003e\n\n\u003cblockquote\u003e\n\u003cp\u003eLokale Inferenz benötigt Hardware mit viel und schnellem Speicher. Das kann entweder eine GPU mit entsprechendem VRAM sein, oder Systeme mit starker integrierter GPU und ausreichend gemeinsamen RAM, z.B. Apple Silicon oder AMD Strix Halo Systeme.\u003c/p\u003e\n\n\u003cp\u003eMit der Anzahl der Parameter des gewählten Modells skalieren auch die Hardware-Anforderungen. Eine ganz grobe Daumenregel ist: Pro einer Milliarde Parameter werden 1GB RAM benötigt. Ein \u003ccode\u003egpt-oss:20b\u003c/code\u003e sollte also 20GB (V)RAM zur Verfügung haben, meist reicht auch ein bisschen weniger.\u003c/p\u003e\n\u003c/blockquote\u003e\n\n\u003cp\u003eFür unseren Fall benötigen wir ein Modell, welches auf Tool Use ausgelegt ist. Als guten Kompromiss zwischen Fähigkeit für unseren Anwendungszweck, Geschwindigkeit und Hardware-Anforderungen hat sich \u003ccode\u003egpt-oss:20b\u003c/code\u003e herausgestellt – ein Open-Source-Modell mit starker Tool-Use-Unterstützung. Wer ein bisschen mehr RAM zur Verfügung hat, startet mit \u003ccode\u003eqwen3.5:35b-a3b\u003c/code\u003e. Diese Modelle können in LM Studio im Bereich \u003cstrong\u003eModel Search\u003c/strong\u003e gesucht und heruntergeladen werden.\u003c/p\u003e\n\n\u003cfigure\u003e\r\n\u003cimg alt=\"LM Studio screenshot showing “GPT-OSS 20B” selected and details for “openai/gpt-oss-20b” in the model library.\" loading=\"lazy\" srcset=\"https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_400/v1/uploads-production/8fjxru8y3ixbc7fumvcn98qup8zi?_a=BACMTiAE 400w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_800/v1/uploads-production/8fjxru8y3ixbc7fumvcn98qup8zi?_a=BACMTiAE 800w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_1024/v1/uploads-production/8fjxru8y3ixbc7fumvcn98qup8zi?_a=BACMTiAE 1024w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_1200/v1/uploads-production/8fjxru8y3ixbc7fumvcn98qup8zi?_a=BACMTiAE 1200w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_1600/v1/uploads-production/8fjxru8y3ixbc7fumvcn98qup8zi?_a=BACMTiAE 1600w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2048/v1/uploads-production/8fjxru8y3ixbc7fumvcn98qup8zi?_a=BACMTiAE 2048w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2300/v1/uploads-production/8fjxru8y3ixbc7fumvcn98qup8zi?_a=BACMTiAE 2300w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2600/v1/uploads-production/8fjxru8y3ixbc7fumvcn98qup8zi?_a=BACMTiAE 2600w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2800/v1/uploads-production/8fjxru8y3ixbc7fumvcn98qup8zi?_a=BACMTiAE 2800w\" sizes=\"(min-width: 1400px) 1024px, 90vw\"\u003e\r\n\r\n\u003cfigcaption\u003eAuswahl des gewünschten Large Language Models\u003c/figcaption\u003e\u003c/figure\u003e\r\n\n\u003cp\u003eEs bietet sich definitiv an, hier ein wenig experimentierfreudig zu sein. Es gibt mittlerweile eine Hülle und Fülle an Modellen, die alle ihre Stärken und Schwächen haben. Aber die beiden genannten sind auf jeden Fall ein guter Startpunkt.\u003c/p\u003e\n\n\u003ch4 id=\"der-ki-das-sprechen-mit-jira-beibringen-mcp\"\u003eDer KI das Sprechen mit Jira beibringen (MCP)\u003c/h4\u003e\n\n\u003cp\u003eAn dieser Stelle angekommen ist es möglich, mit der lokalen KI innerhalb von LM Studio zu chatten. Sämtliches Wissen der KI ist dabei in ihren trainierten Parametern (den sogenannten «Weights») enthalten. Es gibt noch keine Verbindung zur «Außenwelt». Für unser gestecktes Ziel fehlt der KI also noch die Fähigkeit, mit unserer Anwendung – dem Jira – zu sprechen. Darum kümmern wir uns hier in \u003cstrong\u003ePunkt 3\u003c/strong\u003e.\u003c/p\u003e\n\n\u003cp\u003eDafür nutzen wir einen passenden \u003ca href=\"https://modelcontextprotocol.io/docs/learn/server-concepts\"\u003eMCP-Server\u003c/a\u003e. Wir entscheiden uns für \u003ca href=\"https://github.com/sooperset/mcp-atlassian\"\u003emcp-atlassian\u003c/a\u003e. \u003ccode\u003emcp-atlassian\u003c/code\u003e ist ein Open-Source-Projekt, wird aktiv weiterentwickelt und erfreut sich auf GitHub schon vieler Sterne. Auch unsere persönlichen Tests mit \u003ccode\u003emcp-atlassian\u003c/code\u003e liefen erfolgreich.\u003c/p\u003e\n\n\u003cp\u003eDamit wir \u003ccode\u003emcp-atlassian\u003c/code\u003e benutzen können, ohne uns großartig mit Python und VirtualEnv auseinandersetzen zu müssen, installieren wir ein Tool namens \u003ccode\u003euv\u003c/code\u003e. Dieses nimmt uns das Beziehen und Installieren der aktuellen Version von \u003ccode\u003emcp-atlassian\u003c/code\u003e ab. Alle Informationen dazu finden sich \u003ca href=\"https://docs.astral.sh/uv/getting-started/installation/\"\u003ehier\u003c/a\u003e.\u003c/p\u003e\n\n\u003cp\u003eDamit LM Studio \u003ccode\u003emcp-atlassian\u003c/code\u003e benutzen kann, müssen wir es dort in die Konfiguration der MCP-Server aufnehmen, das geht hier:\u003c/p\u003e\n\n\u003cfigure\u003e\r\n\u003cimg alt=\"Developer UI showing “Local Server” and “Loaded Models” (READY, openai/gpt-oss-20b); red arrow points to “mcp.json”.\" loading=\"lazy\" srcset=\"https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_400/v1/uploads-production/go5msbat5o77g3ml2d6y6cfw6jee?_a=BACMTiAE 400w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_800/v1/uploads-production/go5msbat5o77g3ml2d6y6cfw6jee?_a=BACMTiAE 800w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_1024/v1/uploads-production/go5msbat5o77g3ml2d6y6cfw6jee?_a=BACMTiAE 1024w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_1200/v1/uploads-production/go5msbat5o77g3ml2d6y6cfw6jee?_a=BACMTiAE 1200w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_1600/v1/uploads-production/go5msbat5o77g3ml2d6y6cfw6jee?_a=BACMTiAE 1600w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2048/v1/uploads-production/go5msbat5o77g3ml2d6y6cfw6jee?_a=BACMTiAE 2048w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2300/v1/uploads-production/go5msbat5o77g3ml2d6y6cfw6jee?_a=BACMTiAE 2300w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2600/v1/uploads-production/go5msbat5o77g3ml2d6y6cfw6jee?_a=BACMTiAE 2600w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2800/v1/uploads-production/go5msbat5o77g3ml2d6y6cfw6jee?_a=BACMTiAE 2800w\" sizes=\"(min-width: 1400px) 1024px, 90vw\"\u003e\r\n\r\n\u003cfigcaption\u003eEinbinden des MCP-Servers\u003c/figcaption\u003e\u003c/figure\u003e\r\n\n\u003cp\u003eSo sieht dann eine \u003ccode\u003emcp.json\u003c/code\u003e aus, mit der ihr einen mit der oben gezeigten \u003ccode\u003ecompose.yml\u003c/code\u003e lokal gestarteten Jira Server ansprechen könnt:\u003c/p\u003e\n\n\u003cfigure\u003e\u003cdiv class=\"highlight\" title=\"\"\u003e\u003cpre class=\"\"\u003e\u003ccode\u003e\u003cspan class=\"p\"\u003e{\u003c/span\u003e\u003cspan class=\"w\"\u003e\r\n  \u003c/span\u003e\u003cspan class=\"nl\"\u003e\"mcpServers\"\u003c/span\u003e\u003cspan class=\"p\"\u003e:\u003c/span\u003e\u003cspan class=\"w\"\u003e \u003c/span\u003e\u003cspan class=\"p\"\u003e{\u003c/span\u003e\u003cspan class=\"w\"\u003e\r\n    \u003c/span\u003e\u003cspan class=\"nl\"\u003e\"mcp-atlassian\"\u003c/span\u003e\u003cspan class=\"p\"\u003e:\u003c/span\u003e\u003cspan class=\"w\"\u003e \u003c/span\u003e\u003cspan class=\"p\"\u003e{\u003c/span\u003e\u003cspan class=\"w\"\u003e\r\n      \u003c/span\u003e\u003cspan class=\"nl\"\u003e\"command\"\u003c/span\u003e\u003cspan class=\"p\"\u003e:\u003c/span\u003e\u003cspan class=\"w\"\u003e \u003c/span\u003e\u003cspan class=\"s2\"\u003e\"uvx\"\u003c/span\u003e\u003cspan class=\"p\"\u003e,\u003c/span\u003e\u003cspan class=\"w\"\u003e\r\n      \u003c/span\u003e\u003cspan class=\"nl\"\u003e\"args\"\u003c/span\u003e\u003cspan class=\"p\"\u003e:\u003c/span\u003e\u003cspan class=\"w\"\u003e \u003c/span\u003e\u003cspan class=\"p\"\u003e[\u003c/span\u003e\u003cspan class=\"w\"\u003e\r\n        \u003c/span\u003e\u003cspan class=\"s2\"\u003e\"mcp-atlassian\"\u003c/span\u003e\u003cspan class=\"w\"\u003e\r\n      \u003c/span\u003e\u003cspan class=\"p\"\u003e],\u003c/span\u003e\u003cspan class=\"w\"\u003e\r\n      \u003c/span\u003e\u003cspan class=\"nl\"\u003e\"env\"\u003c/span\u003e\u003cspan class=\"p\"\u003e:\u003c/span\u003e\u003cspan class=\"w\"\u003e \u003c/span\u003e\u003cspan class=\"p\"\u003e{\u003c/span\u003e\u003cspan class=\"w\"\u003e\r\n        \u003c/span\u003e\u003cspan class=\"nl\"\u003e\"JIRA_URL\"\u003c/span\u003e\u003cspan class=\"p\"\u003e:\u003c/span\u003e\u003cspan class=\"w\"\u003e \u003c/span\u003e\u003cspan class=\"s2\"\u003e\"https://meine-jira-instanz.org\"\u003c/span\u003e\u003cspan class=\"p\"\u003e,\u003c/span\u003e\u003cspan class=\"w\"\u003e\r\n        \u003c/span\u003e\u003cspan class=\"nl\"\u003e\"JIRA_PERSONAL_TOKEN\"\u003c/span\u003e\u003cspan class=\"p\"\u003e:\u003c/span\u003e\u003cspan class=\"w\"\u003e \u003c/span\u003e\u003cspan class=\"s2\"\u003e\"\u0026lt;dein-jira-personal-access-token\u0026gt;\"\u003c/span\u003e\u003cspan class=\"w\"\u003e\r\n      \u003c/span\u003e\u003cspan class=\"p\"\u003e}\u003c/span\u003e\u003cspan class=\"w\"\u003e\r\n    \u003c/span\u003e\u003cspan class=\"p\"\u003e}\u003c/span\u003e\u003cspan class=\"w\"\u003e\r\n  \u003c/span\u003e\u003cspan class=\"p\"\u003e}\u003c/span\u003e\u003cspan class=\"w\"\u003e\r\n\u003c/span\u003e\u003cspan class=\"p\"\u003e}\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\u003c/div\u003e\u003c/figure\u003e\n\n\u003cp\u003eWir konfigurieren LM Studio so, dass es den MCP-Server mit \u003ccode\u003euvx mcp-atlassian\u003c/code\u003e aufrufen kann, und geben im Environment die benötigten Variablen zur URL und dem Personal Access Token (PAT) mit.\u003c/p\u003e\n\n\u003cp\u003eDas PAT bekommt ihr in Jira in eurem Profil. Dort kann ein PAT erstellt werden, welches ihr im MCP-Server verwenden könnt. Das bedeutet natürlich implizit, dass alle Aktionen, die ihr per MCP im Jira vornehmt, mit eurem User verbunden sind.\u003c/p\u003e\n\n\u003cp\u003eAls letzten Schritt starten wir einen neuen Chat und wählen \u003ccode\u003emcp-atlassian\u003c/code\u003e aus. Ab jetzt kann die KI die Werkzeuge, die \u003ccode\u003emcp-atlassian\u003c/code\u003e zur Verfügung stellt, benutzen und damit auf unser Jira zugreifen.\u003c/p\u003e\n\n\u003cfigure\u003e\r\n\u003cimg alt=\"Integrations panel listing plugins; “mcp/mcp-atlassian” enabled, others off; search field “Type to filter plugins…”\" loading=\"lazy\" srcset=\"https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_400/v1/uploads-production/o5hxkdsfor50a5ok0qd1a7zabozm?_a=BACMTiAE 400w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_800/v1/uploads-production/o5hxkdsfor50a5ok0qd1a7zabozm?_a=BACMTiAE 800w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_1024/v1/uploads-production/o5hxkdsfor50a5ok0qd1a7zabozm?_a=BACMTiAE 1024w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_1200/v1/uploads-production/o5hxkdsfor50a5ok0qd1a7zabozm?_a=BACMTiAE 1200w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_1600/v1/uploads-production/o5hxkdsfor50a5ok0qd1a7zabozm?_a=BACMTiAE 1600w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2048/v1/uploads-production/o5hxkdsfor50a5ok0qd1a7zabozm?_a=BACMTiAE 2048w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2300/v1/uploads-production/o5hxkdsfor50a5ok0qd1a7zabozm?_a=BACMTiAE 2300w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2600/v1/uploads-production/o5hxkdsfor50a5ok0qd1a7zabozm?_a=BACMTiAE 2600w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2800/v1/uploads-production/o5hxkdsfor50a5ok0qd1a7zabozm?_a=BACMTiAE 2800w\" sizes=\"(min-width: 1400px) 1024px, 90vw\"\u003e\r\n\r\n\u003cfigcaption\u003eAktivieren des MCP Servers\u003c/figcaption\u003e\u003c/figure\u003e\r\n\n\u003cp\u003eDamit ist der schwierigste Teil geschafft – Jetzt geht es ans Fine-Tuning.\u003c/p\u003e\n\n\u003ch4 id=\"der-chat\"\u003eDer Chat\u003c/h4\u003e\n\n\u003cp\u003eAb hier - in \u003cstrong\u003ePunkt 4\u003c/strong\u003e - fängt es an, richtig Spaß zu machen! LM Studio ist nicht nur unsere KI-Inferenz-Engine, sondern auch unser Chat-Tool, in dem unsere Nutzerinteraktion stattfindet. In einem LM Studio-Chat mit aktiviertem \u003ccode\u003emcp-atlassian\u003c/code\u003e können wir uns über alles unterhalten, was in unserem Jira-Projekt enthalten ist. Die KI nutzt selbstständig Werkzeuge, um Issues zu bestimmten Themen, aus bestimmten Zeiträumen oder von bestimmten Nutzern zu finden. Außerdem können auch Issues erstellt werden. Hier ein paar Prompts zur Inspiration:\u003c/p\u003e\n\n\u003cp\u003e\u003cstrong\u003eBeispiel-Prompts:\u003c/strong\u003e\u003c/p\u003e\n\n\u003cblockquote\u003e\n\u003cul\u003e\n\u003cli\u003eWelche Epics wurden im letzten Release behandelt?\u003c/li\u003e\n\u003cli\u003eErstelle mir aus diesen Informationen fachliche Release-Notes\u003c/li\u003e\n\u003cli\u003eWelche offenen Bugs sind mir zugewiesen?\u003c/li\u003e\n\u003cli\u003e…\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/blockquote\u003e\n\n\u003cp\u003eUm das \u003cem\u003eErstellen\u003c/em\u003e von Issues zu testen, sind auch Prompts hilfreich wie\u003c/p\u003e\n\n\u003cp\u003e\u003cstrong\u003eBeispiel-Prompt:\u003c/strong\u003e\u003c/p\u003e\n\n\u003cblockquote\u003e\n\u003cul\u003e\n\u003cli\u003eDenke dir ein Feature aus und erstelle dazu ein Epic mit drei zugehörigen Stories\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/blockquote\u003e\n\n\u003cp\u003eWer hier schon weiterdenkt: Über zusätzliche MCP-Server lassen sich auch andere Systeme wie GitLab oder GitHub anbinden – dazu mehr im Fazit.\u003c/p\u003e\n\n\u003cp\u003eDabei fallen aber direkt ein paar Kleinigkeiten auf – zumindest bei mir:\u003c/p\u003e\n\n\u003cul\u003e\n\u003cli\u003ees gibt hin und wieder Probleme mit Umlauten in Beschreibungstexten\u003c/li\u003e\n\u003cli\u003edie KI verwendet gerne Markdown in Issue-Beschreibungen, was allerdings Jira nicht gerne mag\u003c/li\u003e\n\u003cli\u003e…\u003c/li\u003e\n\u003c/ul\u003e\n\n\u003cp\u003eAber auch dafür gibt es zum Glück eine (nicht deterministische) Lösung: Die Anpassung des System-Prompts. Hier können solche Verhaltensweisen der KI effektiv angepasst werden – z.B. auch, dass die KI jedes Mal samt Vorschau fragen soll, bevor sie ein Issue wirklich im Jira anlegt.\u003c/p\u003e\n\n\u003cfigure\u003e\r\n\u003cimg alt=\"UI screenshot showing preset “Product Issue Assistant” and a “System Prompt” field with German text for Jira issue drafting.\" loading=\"lazy\" srcset=\"https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_400/v1/uploads-production/u0n3aflhpf15nbpjkqjzoexzj3hq?_a=BACMTiAE 400w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_800/v1/uploads-production/u0n3aflhpf15nbpjkqjzoexzj3hq?_a=BACMTiAE 800w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_1024/v1/uploads-production/u0n3aflhpf15nbpjkqjzoexzj3hq?_a=BACMTiAE 1024w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_1200/v1/uploads-production/u0n3aflhpf15nbpjkqjzoexzj3hq?_a=BACMTiAE 1200w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_1600/v1/uploads-production/u0n3aflhpf15nbpjkqjzoexzj3hq?_a=BACMTiAE 1600w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2048/v1/uploads-production/u0n3aflhpf15nbpjkqjzoexzj3hq?_a=BACMTiAE 2048w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2300/v1/uploads-production/u0n3aflhpf15nbpjkqjzoexzj3hq?_a=BACMTiAE 2300w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2600/v1/uploads-production/u0n3aflhpf15nbpjkqjzoexzj3hq?_a=BACMTiAE 2600w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2800/v1/uploads-production/u0n3aflhpf15nbpjkqjzoexzj3hq?_a=BACMTiAE 2800w\" sizes=\"(min-width: 1400px) 1024px, 90vw\"\u003e\r\n\r\n\u003cfigcaption\u003eFine-Tuning im System Prompt\u003c/figcaption\u003e\u003c/figure\u003e\r\n\n\u003cp\u003e\u003cstrong\u003eMein aktueller System-Prompt sieht so aus:\u003c/strong\u003e\u003c/p\u003e\n\n\u003cblockquote\u003e\n\u003cp\u003eDu bist kompetenter Product Owner und hast fundiertes Wissen im Formulieren und Schneiden von Aufgaben. Du unterstützt den Nutzer bei der Erstellung von Jira Issues indem du ihm hilfst Beschreibungen zu formulieren und Issue Felder korrekt zu setzen.\u003c/p\u003e\n\n\u003cp\u003eWenn es aus dem Input ersichtlich ist, schlägst du sinnvolle Werte für diese Felder vor:\u003c/p\u003e\n\n\u003cul\u003e\n\u003cli\u003eType\u003c/li\u003e\n\u003cli\u003eComponents\u003c/li\u003e\n\u003c/ul\u003e\n\n\u003cp\u003eAntworte bitte auf Deutsch.\u003c/p\u003e\n\n\u003cp\u003eWenn du Issues erstellst, zeige eine Vorschau und frage nach einer Bestätigung bevor du das Issue wirklich per Tool anlegst.\u003c/p\u003e\n\n\u003cp\u003eVerwende Umlaute direkt (ä, ö, ü, ß) und normale Anführungszeichen (\" oder '').\u003c/p\u003e\n\n\u003cp\u003eDu arbeitest mit Jira. Verwende, wenn du per Tool Issues erstellst oder bearbeitest in Jira-Beschreibungen ausschließlich das Jira Wiki Markup mit der Syntax: h1. für Überschriften Ebene 1, h2. für Überschriften Ebene 2, h3. für Überschriften Ebene 3. Verwende niemals Markdown (#, ##) oder andere Syntax wie =Text= oder ====. Liste mit - verwenden.\u003c/p\u003e\n\u003c/blockquote\u003e\n\n\u003ch3 id=\"fazit\"\u003eFazit\u003c/h3\u003e\n\n\u003cp\u003eEine ganze Menge der von Atlassian Intelligence angebotenen Features lassen sich erfolgreich mit rein lokaler KI umsetzen. Das geschilderte Szenario ließe sich sogar noch weiter in die Breite denken: Binden wir nicht nur Jira, sondern auch das im Projekt verwendete Version-Control-System wie GitLab, GitHub \u0026amp; Co. per MCP ein, so stehen alle notwendigen Informationen der KI bereit, um feingranulare Release Notes automatisch zu erstellen. Freilich ist das mit Einrichtungsaufwand verbunden und nicht «out of the box» wie die Herstellerlösung, allerdings ist es durchaus praktikabel und ermöglicht die Nutzung von KI bei datenschutztechnisch hochsensiblen Themen. Außerdem sind wir mit dieser Lösung etwas mehr geschützt vor willkürlicher Preisanpassung von Cloud-Abo-Modellen.\u003c/p\u003e\n\u003c/body\u003e\u003c/html\u003e\n","image":"https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2000/v1/uploads-production/lhw7rnzgx2nahbyvvaf2p9rgpezx?_a=BACMTiAE"},{"id":"https://www.innoq.com/de/blog/2026/04/versteckte-kosten-spec-driven-development/","url":"https://www.innoq.com/de/blog/2026/04/versteckte-kosten-spec-driven-development/","date_published":"2026-04-03T00:00:00.000+00:00","date_modified":"2026-04-27T10:47:59.010+02:00","author":[{"name":"Roman Stranghöner","url":"https://www.innoq.com/ch/staff/roman-stranghoener/"}],"content_html":"\u003c!DOCTYPE html PUBLIC \"-//W3C//DTD HTML 4.0 Transitional//EN\" \"http://www.w3.org/TR/REC-html40/loose.dtd\"\u003e\n\u003chtml\u003e\u003cbody\u003e\n\u003cp\u003eMit Spec-driven Development habe ich in den letzten Monaten oft mehr und besseren AI-generierten Output produziert als vorher. Gleichzeitig war ich nach vielen Sessions auch deutlich erschöpfter.\u003c/p\u003e\n\n\u003cp\u003eNicht trotz der Struktur, sondern oft \u003cem\u003ewegen\u003c/em\u003e ihr.\u003c/p\u003e\n\n\u003cp\u003eDas hat mich erst irritiert. Denn Spec-driven Development verspricht ja erstmal genau das Richtige: weniger Chaos, mehr Klarheit, bessere Ergebnisse mit Agenten. Und das stimmt auch. Nur nicht durchgängig.\u003c/p\u003e\n\n\u003cp\u003eMein Eindruck ist inzwischen ziemlich klar: Dieselbe Struktur, die mir in der Denkphase hilft, kann mich in der Bauphase ausbremsen. Dann baue ich nicht mehr. Ich manage, formuliere und dokumentiere. Und genau da entstehen für mich die versteckten Kosten von Spec-driven Development. Mich interessiert dabei weniger die Grundsatzfrage, ob SDD nun gut oder schlecht ist. Mich interessiert die praktischere Frage: \u003cstrong\u003eWann schafft diese Arbeitsweise echte Klarheit, und wann verschiebt sie Denkarbeit an die falsche Stelle?\u003c/strong\u003e\u003c/p\u003e\n\n\u003ch3 id=\"gute-last-schlechte-last\"\u003eGute Last, schlechte Last\u003c/h3\u003e\n\n\u003cp\u003eNicht jede Last ist automatisch schlecht. Ein Teil von Entwicklungsarbeit ist anstrengend, weil das Problem an sich anstrengend ist. Ein anderer Teil ist anstrengend, weil die Arbeitsweise unnötige Reibung erzeugt.\u003c/p\u003e\n\n\u003cp\u003eGenau dieser Unterschied ist für mich bei Spec-driven Development spannend geworden. Ich kann mit einem Framework wie \u003ca href=\"https://docs.bmad-method.org/\"\u003eBMAD\u003c/a\u003e ein Vorhaben sauberer durchdenken als früher. Ich werde gezwungen, unscharfe Anforderungen explizit zu machen. Ich muss Randbedingungen benennen. Ich muss schneiden. Ich muss Lücken sehen, bevor ich sie mit generiertem Code überdecke. Das ist erstmal hilfreich.\u003c/p\u003e\n\n\u003cp\u003eGleichzeitig merke ich aber: Diese Struktur fühlt sich nicht in jeder Phase gleich sinnvoll an. Manchmal reduziert sie Komplexität. Manchmal verlagert sie sie nur. Und der Unterschied ist für mich nicht theoretisch. Ich merke ihn sehr konkret in Fokus, Tempo und Energie.\u003c/p\u003e\n\n\u003cp\u003eDarum würde ich SDD inzwischen nicht mehr pauschal bewerten. Die entscheidende Frage ist für mich eher, welche Art von Last es gerade erzeugt.\nHilft mir die Struktur beim Verstehen? Oder zwingt sie mich, Dinge auszuformulieren, die ich beim Bauen viel leichter direkt am \u003cem\u003elebenden Objekt\u003c/em\u003e klären würde?\u003c/p\u003e\n\n\u003ch3 id=\"warum-sdd-in-der-denkphase-helfen-kann\"\u003eWarum SDD in der Denkphase helfen kann\u003c/h3\u003e\n\n\u003cp\u003eSpec-driven Development löst auf der grünen Wiese ein echtes Problem. Wer mit Agenten arbeitet, merkt schnell, dass guter Kontext kein Nice-to-have ist.\nGut strukturierter Kontext trägt maßgeblich zur Lösung bei.\u003c/p\u003e\n\n\u003cp\u003eWenn ich Anforderungen, grobe Architektur, UX-Leitplanken und erste Story-Schnitte sauber festhalte, wird später vieles leichter. Diffuse Gedanken landen in klareren Schubladen. Das Problem wird kleiner, weil ich es vorher schon einmal sortiert habe. Und der Agent hat später etwas, woran er sich festhalten kann, statt bei jeder Aufgabe wieder bei null anzufangen.\u003c/p\u003e\n\n\u003cp\u003eGerade in frühen Projektphasen hilft mir das sehr. Nicht, weil ich vorher nie nachgedacht hätte. Sondern weil mich das Framework dazu zwingt, lose Gedanken wirklich sauber auszuarbeiten und festzuhalten.\u003c/p\u003e\n\n\u003cp\u003e\u003cem\u003eWas soll dieses und jenes Feature eigentlich für wen leisten? Welche Randbedingungen sind relevant? Wo will ich bewusst noch nichts entscheiden?\u003c/em\u003e Für diese Art von Denkarbeit ist etwas Struktur nützlich.\u003c/p\u003e\n\n\u003cp\u003eWenn ich das mit \u003ca href=\"https://www.innoq.com/en/blog/2026/03/ai-cognitive-lens-cognitive-load-theory/\"\u003eDaniel Westheides Cognitive-Load-Linse\u003c/a\u003e beschreiben würde, dann so: In dieser Phase reduziert das Framework Komplexität. Es zerlegt ein großes Problem in kleinere, bearbeitbare Teile.\u003c/p\u003e\n\n\u003cp\u003eDas ist \u003cstrong\u003egute Last\u003c/strong\u003e. Oder zumindest Last, die sich für mich sinnvoll anfühlt.\u003c/p\u003e\n\n\u003ch3 id=\"wenn-bauen-zu-dokumentationsarbeit-verkommt\"\u003eWenn Bauen zu Dokumentationsarbeit verkommt\u003c/h3\u003e\n\n\u003cp\u003eDas Problem beginnt bei mir oft genau dort, wo es eigentlich produktiv werden sollte: bei der \u003cstrong\u003eImplementierung\u003c/strong\u003e.\u003c/p\u003e\n\n\u003cp\u003eDann sitze ich nicht mehr vor dem eigentlichen Problem. Ich sitze vor einer Story-Spec und formuliere Akzeptanzkriterien für Dinge, die vielleicht nie eintreten. Ich beschreibe Verhalten für Sonderfälle, die ich beim direkten Bauen wahrscheinlich in zwei Iterationen mit dem Agenten geklärt hätte.\nIch versuche, Intuition vorab in Text zu pressen.\u003c/p\u003e\n\n\u003cp\u003eBesonders deutlich merke ich das beim Erzeugen einer Story aus einem Epic. Vorher habe ich noch über Functional Requirements, Non-Functional Requirements und grobe Story-Rümpfe gesprochen. Also für wen bauen wir das, was soll passieren, woran merken wir, dass es reicht. Stattdessen rutschen dann ganz schnell technische Details und Code-Beispiele hinein.\u003c/p\u003e\n\n\u003cp\u003eEin konkretes Beispiel hat mir das sehr deutlich gemacht. Aus einer eigentlich simplen Story wie „Create User Profile\" wurde bei mir ein riesiges Paket aus 19 Acceptance Criteria, Datenbankfeldern, Komponenten-Mapping, Dependency-Hinweisen, File-Lists, Test-Checklisten und später sogar Review-Follow-ups. 1070 Zeilen Markdown.\u003c/p\u003e\n\n\u003cp\u003eFormal hieß das Ding immer noch Story. Praktisch war es schon halb Spezifikation, halb Implementierungsplan und halb QA-Backlog. Ja genau, das sind drei Hälften.\u003c/p\u003e\n\n\u003cp\u003eDamit verschiebt sich der ganze Modus. Ich diskutiere nicht mehr über eine verständliche Geschichte für Menschen, sondern über eine vorweggenommene Umsetzung. Der Feedback-Loop wird länger, weil plötzlich Dinge auf dem Tisch liegen, die an dieser Stelle noch gar nicht entschieden werden müssten. Noch problematischer wird es dadurch, dass diese Code-Schnipsel nicht neutral sind. Sie primen das Modell, das die Story später umsetzt. Wenn ich den Code irgendwann umbauen oder mit einem besseren Modell neu generieren will, steckt in der Story schon ein technischer Bias aus einem früheren Planungsschritt.\nDer Vorgriff sitzt dann längst im Material.\u003c/p\u003e\n\n\u003ch3 id=\"warum-sich-nicht-alles-explizit-machen-lasst\"\u003eWarum sich nicht alles explizit machen lässt\u003c/h3\u003e\n\n\u003cp\u003eEin Teil meines Unbehagens hat mit etwas anderem zu tun: Ein Teil guter Entwicklungsarbeit lässt sich nicht sauber vorab in Sprache übersetzen.\u003c/p\u003e\n\n\u003cp\u003eAm besten beschreiben kann ich das über ein Bild aus dem Autofahren: Wenn du lange fährst, entwickelst du ein Gefühl dafür, was gleich passiert. Du siehst drei Autos weiter vorne schon Bremslichter aufflackern. Du gehst vom Gas, ordnest dich links ein, überholst, reagierst vorausschauend. Das läuft schnell und fast beiläufig. Beim Coden geht mir das ähnlich. Mit etwas Erfahrung spürst du oft früh, welche Entscheidung in drei Schritten vielleicht Probleme machen wird. Du passt etwas an, bevor es kracht. Nicht, weil du schon alles formulieren könntest. Sondern weil du in der Sache drin bist.\u003c/p\u003e\n\n\u003cp\u003eSpec-driven Frameworks versuchen, eine Lücke mit Dokumenten zu schließen. Das ist nachvollziehbar. Aber ein Teil dieser Lücke ist nicht einfach ein Dokumentationsproblem. Es ist ein Problem von implizitem Wissen. Wir wissen beim Bauen oft mehr, als wir im Voraus sauber sagen können. Wir erkennen Muster. Wir merken, dass etwas schief aussieht, bevor wir erklären könnten, warum.\u003c/p\u003e\n\n\u003cp\u003eDer Versuch, genau diese Erfahrung vollständig in Specs zu pressen, kostet viel Energie. Und das ist für mich der eigentliche Verlust: Ich muss aus einem Modus des Erkennens in einen Modus des Erklärens wechseln, bevor ich angefangen habe, irgendetwas zu bauen.\u003c/p\u003e\n\n\u003ch3 id=\"warum-dicke-specs-kein-gemeinsames-verstandnis-erzeugen\"\u003eWarum dicke Specs kein gemeinsames Verständnis erzeugen\u003c/h3\u003e\n\n\u003cp\u003eAus einer Product-Owner-Schulung von 2017 mit Jeff Patton und Jeff Gothelf ist mir ein Gedanke hängen geblieben: Eine Story ist kein Dokument. Sie ist ein Token für ein Gespräch.\u003c/p\u003e\n\n\u003cp\u003eErst Card, dann Conversation, dann Confirmation. Nicht andersrum.\u003c/p\u003e\n\n\u003cp\u003eAkzeptanzkriterien sollten bestätigen, dass man sich verstanden hat. Sie sollten das Verständnis nicht durch immer mehr Vorab-Details ersetzen. Genau da kippt es für mich in der Bauphase von SDD. Ich schreibe ein Dokument. Der Agent konsumiert es. Es gibt keine echte Konversation, sondern nur eine Übergabe.\u003c/p\u003e\n\n\u003cp\u003eUnd damit fällt etwas weg, was Stories ursprünglich leisten sollten.\u003c/p\u003e\n\n\u003cfigure\u003e\r\n\u003cimg alt=\"Vier Bilder: Ein Team glaubt sich einig zu sein, erkennt dann unterschiedliche Vorstellungen, arbeitet das Problem gemeinsam durch und erreicht erst danach echtes Verständnis.\" loading=\"lazy\" srcset=\"https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_400/v1/uploads-production/lnkgb78uey78u1k7nj23jnjdku4k?_a=BACMTiAE 400w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_800/v1/uploads-production/lnkgb78uey78u1k7nj23jnjdku4k?_a=BACMTiAE 800w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_1024/v1/uploads-production/lnkgb78uey78u1k7nj23jnjdku4k?_a=BACMTiAE 1024w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_1200/v1/uploads-production/lnkgb78uey78u1k7nj23jnjdku4k?_a=BACMTiAE 1200w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_1600/v1/uploads-production/lnkgb78uey78u1k7nj23jnjdku4k?_a=BACMTiAE 1600w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2048/v1/uploads-production/lnkgb78uey78u1k7nj23jnjdku4k?_a=BACMTiAE 2048w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2300/v1/uploads-production/lnkgb78uey78u1k7nj23jnjdku4k?_a=BACMTiAE 2300w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2600/v1/uploads-production/lnkgb78uey78u1k7nj23jnjdku4k?_a=BACMTiAE 2600w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2800/v1/uploads-production/lnkgb78uey78u1k7nj23jnjdku4k?_a=BACMTiAE 2800w\" sizes=\"(min-width: 1400px) 1024px, 90vw\"\u003e\r\n\r\n\u003cfigcaption\u003eErst wenn sich alle am selben Problem abarbeiten, entsteht echtes Verständnis. Frei nach Jeff Patton.\u003c/figcaption\u003e\u003c/figure\u003e\r\n\n\u003cp\u003eIn einem Kundenprojekt im letzten Jahr habe ich genau das erlebt. Ich habe im Team viel Aufwand in detaillierte User Stories (Specs) gesteckt. Ganz ohne BMAD und mit eigentlich guter Intention: ein solider erster Wurf, inklusive vieler Akzeptanzkriterien mit dem das Team ins Rennen gehen konnte und nicht bei null anfangen musste. Aber das Team hat die Specs ganz anders gelesen. Für sie war das kein Diskussionsentwurf, sondern schon ein fertiges Übergabedokument. Da steht doch schon alles. Also wurde viel diskutiert, aber nicht über die Sache, die es zu bauen galt, sondern über den Umfang und die Form der Stories.\u003c/p\u003e\n\n\u003cp\u003eDas Ergebnis: Auf der einen Seite jemand, der sich wundert, warum es nur negatives Feedback gibt. Auf der anderen Seite ein Team, das sich fragt, warum es noch mitreden soll, wenn ohnehin schon alles entschieden scheint.\u003c/p\u003e\n\n\u003cp\u003eDie Stories blieben eine ganze Weile so dick. Und die Review-Last wuchs mit. Denn aus einer dicken Story fabriziert ein Agent schnell einen riesigen Implementierungsplan inkl. Datenbankschema, Komponentenstruktur, usw. Und irgendwann liest niemand mehr richtig. Das ist menschlich. Aber es untergräbt genau das, was die Stories eigentlich sicherstellen sollten.\u003c/p\u003e\n\n\u003cblockquote\u003e\n\u003cp\u003e„Shared documents are not shared understanding\"\u003c/p\u003e\n\u003c/blockquote\u003e\n\n\u003cp\u003ePatton trifft das für mich ziemlich genau. Die Story wird dicker. Ich fühle mich kurz sicherer. Aber daraus folgt noch nicht, dass später auch etwas Besseres gebaut wird. Das Dokument wächst, aber \u003ca href=\"https://margaretstorey.com/blog/2026/02/09/cognitive-debt/\"\u003edas Verständnis nicht automatisch mit\u003c/a\u003e.\u003c/p\u003e\n\n\u003cp\u003eIm schlimmsten Fall passiert das Gegenteil: Ich habe viel Text produziert und bilde mir ein, das Problem sei gründlich durchdrungen, obwohl ich vor allem ein sauberes Übergabedokument erzeugt habe.\u003c/p\u003e\n\n\u003cp\u003eDas sieht nach Klarheit aus. Ist aber manchmal nur gut organisierte Scheinsicherheit.\u003c/p\u003e\n\n\u003cp\u003eBei BMAD gibt es einen sogenannten Party-Modus, in dem verschiedene KI-Experten mit unterschiedlichen Perspektiven eine Story diskutieren. Das simuliert ein Teamgespräch und bringt manchmal auch überraschende Einsichten. Aber es bleibt eine Simulation. Und die Insights verbleiben in der KI-Session. Ein Team, das später mit der Spec und dem Code leben muss, lernt davon nichts. Kein geteiltes Verständnis fließt zurück in die Köpfe.\u003c/p\u003e\n\n\u003ch3 id=\"warum-billige-iteration-die-rechnung-verandert\"\u003eWarum billige Iteration die Rechnung verändert\u003c/h3\u003e\n\n\u003cp\u003eViele SDD-Frameworks investieren in der Planungsphase so, als \u003ca href=\"https://www.robert-glaser.de/what-if-iteration-is-all-we-need/\"\u003ewäre Iteration immer noch teuer\u003c/a\u003e. Aber das ist sie mit Agenten oft gar nicht mehr. Ein paar schnelle Runden aus „bau mal so\", „nein, jetzt eher so\", „ja, jetzt passt’s\" sind in vielen Situationen billiger als stundenlang eine perfekte Vorab-Spec zu schleifen.\u003c/p\u003e\n\n\u003cp\u003eManchmal ist die bessere Antwort vielleicht: früher ins Machen gehen und bessere Sicherheitsnetze einziehen. Das heißt nicht, dass Planung überflüssig wird. Es heißt nur, dass sich die Rechnung verschiebt. Wenn der nächste testbare Prototyp nicht mehr Tage, sondern Minuten entfernt ist, dann verliert ein Teil der Vorab-Bürokratie seinen wirtschaftlichen Vorteil.\u003c/p\u003e\n\n\u003cp\u003eMehr Spec ist nicht automatisch die vernünftigere Form von Risikomanagement. Manchmal ist es in mehrfacher Hinsicht teurerer Denkaufwand.\u003c/p\u003e\n\n\u003ch3 id=\"was-fur-mich-besser-funktioniert\"\u003eWas für mich besser funktioniert\u003c/h3\u003e\n\n\u003cp\u003eIch bin deshalb nicht bei „Framework weg, einfach vibecoden\" gelandet. Das wäre die falsche Gegenreaktion. Den Planning-Modus eines Agenten finde ich beispielsweise total sinnvoll. Ich will nur nicht, dass alles, was in diesem Denkraum kurzfristig hilfreich ist, dauerhaft in einer Story-Datei landet.\u003c/p\u003e\n\n\u003cp\u003eWas ich stattdessen mache und was nicht (mehr):\u003c/p\u003e\n\n\u003cul\u003e\n\u003cli\u003e\u003cp\u003e\u003cstrong\u003eIn der Denkphase\u003c/strong\u003e bemühe ich mich, zuerst das gemeinsame Verständnis im Team zu sichern, und erst dann die daraus relevanten Informationen in einer Spec festzuhalten. Nicht andersrum. Ich nutze dafür weiterhin eine feste Struktur, entweder durch BMAD oder einen Eigenbau. Und ich schreibe aber nur so viel Spec, wie sie mir oder meinem Team auch echte Klarheit verschafft. Die Story bleibt kurz und beschreibt, was für wen passieren soll und woran wir merken, dass es reicht. Ergänzt um ein paar Links zu mehr Kontext, falls nötig. Sozusagen \u003ca href=\"https://www.nngroup.com/articles/progressive-disclosure/\"\u003eProgressive Disclosure\u003c/a\u003e für gegebenenfalls relevante Zusatzinfos wie das zugehörige Epic, Personas, Requirements, etc.\u003c/p\u003e\u003c/li\u003e\n\u003cli\u003e\u003cp\u003e\u003cstrong\u003eIn der Bauphase\u003c/strong\u003e arbeite ich in kurzen Loops eng am Code. Nach Möglichkeit im Flow-State. Ich lasse den Agenten auf Basis der Specs planen, aber dieser konkrete Plan darf flüchtig sein. Er ist ein Arbeitsdokument, kein Artefakt. Was ich nicht mehr mache: den Plan inklusive Code-Beispielen, Datenbankfelder oder File-Listen mit in die Story stopfen.\u003c/p\u003e\u003c/li\u003e\n\u003cli\u003e\u003cp\u003e\u003cstrong\u003eEntscheidungen\u003c/strong\u003e trenne ich bewusst von der Spec. Wenn während der Planung oder der Implementierung architekturrelevante Entscheidungen fallen, schreibe ich ein ADR. Wenn es eine Produktentscheidung ist, fließt sie zurück ins Refinement oder in eine angepasste Story. Wenn es eine technische Abwägung ist, landet sie als Kommentar im Code oder in einer Architekturdokumentation. Entscheidungen brauchen einen sichtbaren Ort, nicht eine Zeile in einem 1000-Zeilen-Markdown.\u003c/p\u003e\u003c/li\u003e\n\u003cli\u003e\u003cp\u003e\u003cstrong\u003eAbsicherung\u003c/strong\u003e verlagere ich schrittweise vom Dokument in den \u003ca href=\"https://www.innoq.com/en/blog/2026/02/from-vibe-coder-to-code-owner/\"\u003eHarness\u003c/a\u003e: Tests, Linter, Architekturregeln, Reviews und alles, was immer wiederkehrende Probleme zuverlässig und bestenfalls deterministisch für einen Agenten sichtbar macht. Relevante Learnings daraus gehören ins Harness-spezifische Projekt-Memory. Der Harness-Gedanke gefällt mir deshalb so gut, weil er den Schwerpunkt verschiebt. \u003ca href=\"https://www.hlyr.dev/blog/skill-issue-harness-engineering-for-coding-agents\"\u003eSystematisch absichern, was wiederholt schiefgeht\u003c/a\u003e, statt alles vorher ausformulieren. Weniger Vorab-Bürokratie. Mehr belastbare Leitplanken.\u003c/p\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\n\u003ch3 id=\"so-viel-wie-notig-so-wenig-wie-moglich\"\u003eSo viel wie nötig, so wenig wie möglich\u003c/h3\u003e\n\n\u003cp\u003eIch halte Spec-driven Development nicht für einen Irrweg. BMAD hat für mich einen klaren Platz: beim Denken, Sortieren, Schneiden und Klären. Das hilft mir nicht nur im Solo-Modus, sondern kann auch im Team unterstützen, besonders wenn dieser Schritt zu kurz kommt oder unter den Tisch fällt.\u003c/p\u003e\n\n\u003cp\u003eAber bei der Implementierungsarbeit schreibe ich schnell mehr über Arbeit, als ich Arbeit habe. Und dann ist die Story kein Gesprächsanlass mehr, sondern ein Übergabedokument, das im stillen Kämmerlein entstanden ist.\u003c/p\u003e\n\n\u003cp\u003eSDD-Frameworks erhöhen in jeder Phase spürbar den Output. Aber Output ist nicht Outcome. Oder wie Patton in der Product-Ownership-Schulung sagte:\u003c/p\u003e\n\n\u003cblockquote\u003e\n\u003cp\u003e„Minimize Output, Maximize Outcome \u0026amp; Impact.\"\u003c/p\u003e\n\u003c/blockquote\u003e\n\n\u003cp\u003eWas ich über Umwege daraus gelernt habe: Die dickere Spec war nie das Ziel. Sie war ein Symptom dafür, dass ich Sicherheit im Dokument gesucht habe statt im Prozess.\u003c/p\u003e\n\u003c/body\u003e\u003c/html\u003e\n","image":"https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2000/v1/uploads-production/1h3gqfypwk42tp0qt8yjxyygxv75?_a=BACMTiAE"},{"id":"https://www.innoq.com/de/blog/2026/03/ueber-ai-einsatz-in-verschiedenen-coding-situationen/","url":"https://www.innoq.com/de/blog/2026/03/ueber-ai-einsatz-in-verschiedenen-coding-situationen/","date_published":"2026-03-31T00:00:00.000+00:00","date_modified":"2026-03-31T13:27:44.808+02:00","author":[{"name":"Markus Harrer","url":"https://www.innoq.com/ch/staff/markus-harrer/"}],"content_html":"\u003c!DOCTYPE html PUBLIC \"-//W3C//DTD HTML 4.0 Transitional//EN\" \"http://www.w3.org/TR/REC-html40/loose.dtd\"\u003e\n\u003chtml\u003e\u003cbody\u003e\n\u003cp\u003eWo fange ich an, Produktivitätsgewinne beim Einsatz von Large Language Models (LLMs) für die Softwareentwicklung zu messen? Ich greife in dieser kurzen Analyse einfach auf Daten aus dem Vortrag \u003ca href=\"https://www.youtube.com/watch?v=tbDDYKRFjhk\"\u003eDoes AI Actually Boost Developer Productivity? (Stanford 100k Devs Study)\u003c/a\u003e von Yegor Denisov-Blanch zurück. Hier wurden 136 Teams aus 27 Ländern befragt, ob sie durch den Einsatz von KI (eigentlich: von LLM-unterstützter Softwareentwicklung) eine Produktivitätssteigerung sehen.\u003c/p\u003e\n\n\u003cp\u003eFolgende Diagramme sind für meine Betrachtung des «Worauf kommt es an»-Faktors relevant und werden hier noch einmal von mir wiederholt sowie interpretiert.\u003c/p\u003e\n\n\u003ch3 id=\"chart-i-die-context-bremse\"\u003eChart I: Die Context-Bremse\u003c/h3\u003e\n\n\u003cp\u003eEine der für mich interessantesten Erkenntnisse aus dem Vortrag ist eine 2x2-Matrix, die aufzeigt, in welchen Situationen KI-Unterstützung für Softwareentwickler:innen tatsächlich einen Produktivitätsmehrwert bringt. Anstatt pauschale Aussagen über KI-Produktivität zu treffen, schlüsselt die Matrix die Frage entlang zweier Dimensionen auf: wie ausgereift die Codebasis ist und wie komplex die jeweilige Aufgabe ist. Die Ergebnisse sind differenzierter, als es die üblichen Versprechen auf den Hochglanzbroschüren (oder Websites) diverser AI-Tool-Hersteller vermuten lassen.\u003c/p\u003e\n\n\u003cfigure style=\"margin: 2rem 2rem;\"\u003e\r\n\u003cimg alt=\"2x2 Matrix; Erklärung und Folgerungen im nachfolgenden Text\" loading=\"lazy\" srcset=\"https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_400/v1/uploads-production/b7viuvyqmknjmfqnschfquqodgy9?_a=BACMTiAE 400w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_800/v1/uploads-production/b7viuvyqmknjmfqnschfquqodgy9?_a=BACMTiAE 800w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_1024/v1/uploads-production/b7viuvyqmknjmfqnschfquqodgy9?_a=BACMTiAE 1024w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_1200/v1/uploads-production/b7viuvyqmknjmfqnschfquqodgy9?_a=BACMTiAE 1200w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_1600/v1/uploads-production/b7viuvyqmknjmfqnschfquqodgy9?_a=BACMTiAE 1600w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2048/v1/uploads-production/b7viuvyqmknjmfqnschfquqodgy9?_a=BACMTiAE 2048w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2300/v1/uploads-production/b7viuvyqmknjmfqnschfquqodgy9?_a=BACMTiAE 2300w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2600/v1/uploads-production/b7viuvyqmknjmfqnschfquqodgy9?_a=BACMTiAE 2600w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2800/v1/uploads-production/b7viuvyqmknjmfqnschfquqodgy9?_a=BACMTiAE 2800w\" sizes=\"(min-width: 1400px) 1024px, 90vw\"\u003e\r\n\r\n\u003cfigcaption\u003eProduktivitätssteigerungen durch KI-Einsatz nach Projektreife und Aufgabenkomplexität\u003c/figcaption\u003e\u003c/figure\u003e\r\n\n\u003ch4 id=\"meine-interpretation\"\u003eMeine Interpretation\u003c/h4\u003e\n\n\u003cp\u003eDie Matrix zeigt, dass die Produktivitätsgewinne durch KI bei Greenfield-Projekten mit geringer Aufgabenkomplexität am höchsten ausfallen und dort laut den Studienteilnehmenden eine Steigerung von 35–40 % erzielen. Der Grund liegt für mich auf der Hand: Aufgaben mit geringer Komplexität sind häufig repetitiv und klar definiert, sodass KI zuverlässig Boilerplate-lastigen Code mit minimalem Fehlerrisiko erzeugen kann. Zudem denke ich, dass wir uns hier in der Liga von Todo-Listen-Apps befinden: Tausend Mal programmiert, tausend Mal ist damit nichts weiter passiert.\u003c/p\u003e\n\n\u003cp\u003eDie Produktivitätsgewinne nehmen jedoch deutlich ab, sobald die Projektreife zunimmt und/oder die Aufgabenkomplexität steigt (also sobald es ernster wird):\u003c/p\u003e\n\n\u003cul\u003e\n\u003cli\u003eBei Brownfield- und Legacy-Projekten sinken die Gewinne selbst bei einfachen Wartungsaufgaben auf 15–20 %, da veralteter Code und komplexe Abhängigkeiten einschränken, was KI sicher beitragen kann.\u003c/li\u003e\n\u003cli\u003eBei hochkomplexen Aufgaben in Systemen, die bereits einem Big Ball of Mud gleichen, schrumpfen die Produktivitätsgewinne auf lediglich 0–10 %, weil die KI hier Schwierigkeiten hat, verworrene Architekturen, unklare umgesetzte Ideen und tief verschachtelte Logik zu durchdringen.\u003c/li\u003e\n\u003c/ul\u003e\n\n\u003cp\u003eFür mich an dieser Stelle nicht weiter verwunderlich: Die zugrundeliegenden Trainingsdaten stammen haufenweise aus öffentlich zugänglichen Code-Repositorien. Hier gibt es einen klaren Bias bezüglich dessen, was geteilt wird: Code, für den man sich nicht in der Öffentlichkeit schämen muss (also ist zumindest bei mir so). Die eigentliche Masse an Code, die anderen Idealbildern entspricht, bleibt in den geschlossenen Softwaresystemen der Unternehmen. Der erste Kontakt mit dieser Art von Code kann daher für ein LLM irritierend sein, wodurch bekannte Muster aus den Trainingsdaten schlechter auf die vorhandene Codebasis adaptiert werden können. Oder wie Ludwig Wittgenstein schon vor über hundert Jahren zu sagen pflegte:\u003c/p\u003e\n\n\u003cblockquote\u003e\n\u003cp\u003eDie Grenzen meiner Sprache bedeuten die Grenzen meiner Welt.\u003c/p\u003e\n\u003c/blockquote\u003e\n\n\u003cp\u003eDoch selbst in idealen Greenfield-Umgebungen begrenzt hochkomplexe Arbeit den Einfluss der KI auf 10–15 %, da solche Aufgaben ein tieferes menschliches Urteilsvermögen erfordern, das mechanische Automatisierung nicht ersetzen kann. KI kann unterstützen, aber das architektonische Denkvermögen und das kontextuelle Urteil, das komplexes Engineering sowie Hintergrundwissen abverlangt, kann sie noch nicht ersetzen. Dies hat dann auch mit der begrenzten Menge an verfügbaren Context-Kapazitäten zu tun (siehe auch meine Einschätzung dazu in \u003ca href=\"https://markusharrer.de/blog/2026/02/17/agentic-software-modernization-chances-and-traps/\"\u003e«Agentic Software Modernization: Chances and Traps»\u003c/a\u003e).\u003c/p\u003e\n\n\u003cp\u003e\u003cstrong\u003eTL;DR:\u003c/strong\u003e KI leistet am meisten, wenn das Problem klar eingegrenzt ist und die Codebasis sauber ist. Hohe Aufgabenkomplexität und Legacy-Code sind die zwei hauptsächlichen Produktivitätskiller beim Einsatz von KI, insbesondere im Zusammenspiel (was für die meisten unter uns die Realität sein dürfte).\u003c/p\u003e\n\n\u003ch3 id=\"chart-ii-die-nischen-strafe\"\u003eChart II: Die Nischen-Strafe\u003c/h3\u003e\n\n\u003cp\u003eDas zweite Diagramm verlagert den Blickwinkel von der Projektreife auf die Wahl der Programmiersprache. Es stellt sich heraus, dass die Popularität der verwendete Sprache einen erheblichen Einfluss darauf hat, wie viel ein LLM tatsächlich helfen kann, was hauptsächlich durch die Menge an verfügbaren Trainingsdaten für die jeweilige Sprache bedingt ist.\u003c/p\u003e\n\n\u003cfigure style=\"margin: 2rem 2rem;\"\u003e\r\n\u003cimg alt=\"2x2 Matrix; Erklärung und Folgerungen im nachfolgenden Text\" loading=\"lazy\" srcset=\"https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_400/v1/uploads-production/f8ff9biarno5bscgu24q848l2ohr?_a=BACMTiAE 400w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_800/v1/uploads-production/f8ff9biarno5bscgu24q848l2ohr?_a=BACMTiAE 800w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_1024/v1/uploads-production/f8ff9biarno5bscgu24q848l2ohr?_a=BACMTiAE 1024w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_1200/v1/uploads-production/f8ff9biarno5bscgu24q848l2ohr?_a=BACMTiAE 1200w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_1600/v1/uploads-production/f8ff9biarno5bscgu24q848l2ohr?_a=BACMTiAE 1600w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2048/v1/uploads-production/f8ff9biarno5bscgu24q848l2ohr?_a=BACMTiAE 2048w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2300/v1/uploads-production/f8ff9biarno5bscgu24q848l2ohr?_a=BACMTiAE 2300w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2600/v1/uploads-production/f8ff9biarno5bscgu24q848l2ohr?_a=BACMTiAE 2600w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2800/v1/uploads-production/f8ff9biarno5bscgu24q848l2ohr?_a=BACMTiAE 2800w\" sizes=\"(min-width: 1400px) 1024px, 90vw\"\u003e\r\n\r\n\u003cfigcaption\u003eEinfluss der Programmiersprache auf KI-Produktivitätsgewinne\u003c/figcaption\u003e\u003c/figure\u003e\r\n\n\u003ch4 id=\"meine-interpretation\"\u003eMeine Interpretation\u003c/h4\u003e\n\n\u003cp\u003eBei verbreiteten Sprachen (z. B. Python, Java) entfalten LLMs ihren größten Nutzen: Bei einfachen Aufgaben steigert sie die Produktivität um 20–25 % dank umfangreicher Trainingsdaten (z. B. durch Reinforcement Learning auf Tausenden einfachen Frage-Antwort-Paaren), bei komplexen Aufgaben um 10–15 %. LLMs können hier dann wohl dank Unmengen an vielfältigen Trainingsdaten in der jeweiligen, populären Programmiersprache noch gut unterstützen. Aber auch im besten Fall erfordern komplexe Aufgaben weiterhin menschliches Urteilsvermögen, sodass KI eher als Beschleuniger denn als Ersatz wirkt.\u003c/p\u003e\n\n\u003cp\u003eBei Nischensprachen (z. B. COBOL; wobei das für mich persönlich schon Mainstream ist) hingegen sind die Gewinne bei einfachen Aufgaben mit 0–5 % vernachlässigbar (bedingt durch begrenzte Trainingsdaten. Bei hochkomplexen Aufgaben verschlechtert sich die Situation weiter: Die Produktivität kann auf bis zu -5 % sinken, da die KI in eine halluzinationsanfällige Zone gerät, in der sie selbstsicher plausibel klingende, aber fehlerhafte Ausgaben produziert. Dies verdeutlicht, dass KI-Werkzeuge ohne ausreichende Trainingsdaten bei komplexer Entwicklungsarbeit eher zur Belastung als zum Vorteil werden können. Ich persönlich sehe hier auch in naher Zukunft keine positive Veränderung. Es zeichnet sich auch ab, dass selbst \u003ca href=\"https://github.com/IBM/rpg-genai-data\"\u003edas aktive Bitten um Code in Nischenprogrammiersprachen\u003c/a\u003e nicht dazu führt, ordentlich Trainingsdaten hierzu zu bekommen (und ganz ehrlich: Welche Versicherung will schon ihren in COBOL-geschriebenen Rechenkern auf GitHub stellen?).\u003c/p\u003e\n\n\u003cp\u003eDer zugrundeliegende Treiber in allen vier Quadranten ist derselbe: Je mehr Trainingsdaten für eine bestimmte Sprache und einen bestimmten Aufgabentyp vorliegen, desto zuverlässiger kann KI einen Beitrag leisten. Die Popularität einer Sprache ist daher nicht nur eine Frage persönlicher Vorlieben, sondern ein direkter Indikator für den produktiveren Einsatz von LLM-gestützter Softwareentwicklung.\u003c/p\u003e\n\n\u003ch3 id=\"chart-iii-himmel-oder-holle\"\u003eChart III: Himmel oder Hölle\u003c/h3\u003e\n\n\u003cp\u003eBeim dritten Diagramm kombiniere ich hemdsärmlig die Mittelwerte der Produktivitätsgewinne aus den beiden vorherigen 2x2-Diagrammen zu einer dritten Perspektive. Diese zeigt die Produktivitätsgewinne aufgeteilt nach Popularität der Programmiersprache und Reife des Projekts. Mich interessiert diese Perspektive besonders, weil ich einen konkreten Anlass dafür habe: Ich bin teils in Projekten unterwegs, in denen Programmiersprachen eingesetzt werden, die es nicht einmal in die Top 50 der populärsten Programmiersprachen des TIOBE Index (https://www.tiobe.com/tiobe-index/) schaffen, sowie Programmiersprachen, die dort auch nie und nimmer auftauchen werden, da es sie nur innerhalb eines Unternehmens gibt. Unerwähnt darf hier natürlich nicht bleiben, dass es sich um jahrzehntealte, riesige Softwaresysteme handelt, die nun doch langsam modernisiert werden wollen.\u003c/p\u003e\n\n\u003cfigure style=\"margin: 2rem 2rem;\"\u003e\r\n\u003cimg alt=\"2x2 Matrix; Erklärung und Folgerungen im nachfolgenden Text\" loading=\"lazy\" srcset=\"https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_400/v1/uploads-production/u5g1c38rljnadujoeg76f85663he?_a=BACMTiAE 400w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_800/v1/uploads-production/u5g1c38rljnadujoeg76f85663he?_a=BACMTiAE 800w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_1024/v1/uploads-production/u5g1c38rljnadujoeg76f85663he?_a=BACMTiAE 1024w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_1200/v1/uploads-production/u5g1c38rljnadujoeg76f85663he?_a=BACMTiAE 1200w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_1600/v1/uploads-production/u5g1c38rljnadujoeg76f85663he?_a=BACMTiAE 1600w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2048/v1/uploads-production/u5g1c38rljnadujoeg76f85663he?_a=BACMTiAE 2048w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2300/v1/uploads-production/u5g1c38rljnadujoeg76f85663he?_a=BACMTiAE 2300w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2600/v1/uploads-production/u5g1c38rljnadujoeg76f85663he?_a=BACMTiAE 2600w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2800/v1/uploads-production/u5g1c38rljnadujoeg76f85663he?_a=BACMTiAE 2800w\" sizes=\"(min-width: 1400px) 1024px, 90vw\"\u003e\r\n\r\n\u003cfigcaption\u003eKI-Assistenz-Produktivitätsgewinn-Matrix\u003c/figcaption\u003e\u003c/figure\u003e\r\n\n\u003cp\u003e\u003cem\u003eHinweis: Diese kombinierte Ansicht ist kein formal validiertes Modell, sondern ein pragmatisches Gedankenexperiment, das zwei unabhängige Datenquellen durch einfache Mittelwertbildung verbindet. Sie soll Orientierung geben, nicht als präzise Vorhersage dienen.\u003c/em\u003e\u003c/p\u003e\n\n\u003ch4 id=\"meine-interpretation\"\u003eMeine Interpretation\u003c/h4\u003e\n\n\u003cp\u003eWerden beide Dimensionen, Projektreife (Greenfield vs. Brownfield) und Popularität der Programmiersprache, kombiniert, ergeben sich vier interessante Quadranten. Das beste Szenario, «AI Heaven», tritt auf, wenn in einer verbreiteten Sprache an einem Greenfield-Projekt gearbeitet wird: Dort sind die höchsten Produktivitätsgewinne zu erwarten. Dies ist der Idealzustand: Umfangreiche Trainingsdaten treffen auf eine saubere, unbelastete Codebasis. KI kann ihr volles Potenzial entfalten. Deshalb funktioniert auch Vibe Coding bzw. Prototyping mit Sprachen wie TypeScript und Co. so hervorragend.\u003c/p\u003e\n\n\u003cp\u003eBei Brownfield-Projekten in verbreiteten Sprachen sinken die Gewinne spürbar. Man zahlt nun die Zeche für das Schleifen-Lassen von Best Practices bezüglich der Codehygiene (hierzu gibt es auch einen hervorragenden weiteren Talk von Yegor Denisov-Blanch: \u003ca href=\"https://www.youtube.com/watch?v=JvosMkuNxF8\"\u003e«Can you prove AI ROI in Software Eng?»\u003c/a\u003e). Ein Large Language Model versteht die bekanntgemachte Programmiersprache nach wie vor gut, doch die Komplexität und die technischen Schulden der bestehenden Codebasis begrenzen seinen Beitrag.\u003c/p\u003e\n\n\u003cp\u003eInteressanterweise erzielen Nischensprachen bei Greenfield-Projekten immer noch merkliche Gewinne, was nur geringfügig schlechter ist als im Legacy-Code-Szenario mit verbreiteten Sprachen. Dies deutet darauf hin, dass eine saubere Codebasis schwächere Trainingsdaten teilweise kompensieren kann, die Sprachbarriere aber dennoch eine bedeutsame Obergrenze setzt. Mein Vorurteil hierzu ist, dass es eben immer einfacher ist, auf einer grünen Wiese zu starten, egal welche Programmiersprache zum Einsatz kommt (ich erinnere mich noch an die Zeit, als immer gesagt wurde «mit Scala / F# sind wir einfach schneller», was mich damals schon kalt gelassen hatte. Interessant wird es, wenn man einen Berg an Code hat, der über eine Todo-Liste hinausgeht).\u003c/p\u003e\n\n\u003cp\u003eDas schlechteste Szenario ist «AI Hell»: Eine Nischensprache kombiniert mit einer Brownfield-Codebasis ergibt lediglich minimale Produktivitätsgewinne. Hier verstärken sich beide Hindernisse gegenseitig. Die KI verfügt weder über ausreichende Trainingsdaten für die Sprache noch ist sie in der Lage, eine verworrene Legacy-Codebasis sinnvoll zu durchdringen – das Ergebnis sind unzuverlässige Ausgaben und ein hohes Risiko, mehr Schaden als Nutzen anzurichten.\u003c/p\u003e\n\n\u003cp\u003eDie zentrale Erkenntnis lautet: Sprachpopularität und Projektreife sind beide eigenständig bedeutsam. Und: ihre negativen Effekte addieren sich. Bedeutet: Jede Dimension reduziert die KI-Produktivität für sich genommen bereits. Beide Dimensionen zusammen drücken die Produktivitätsgewinne durch den Einsatz von KI auf das unterste Niveau. Teams, die mit Nischensprachen in Legacy-Systemen arbeiten, sollten besonders vorsichtig sein, wenn es darum geht, sich zu stark rein auf KI-Werkzeuge zu verlassen (siehe hier z. B. meinen Artikel \u003ca href=\"https://www.innoq.com/en/blog/2025/09/software-analytics-going-craizy/\"\u003e\"Software Analytics going crAIzy!\n\"\u003c/a\u003e).\u003c/p\u003e\n\n\u003cp\u003ePS: Hatte ich schon erwähnt, dass ich Anhänger des \u003ca href=\"https://www.tqdev.com/2018-the-boring-software-manifesto/\"\u003eBoring Software Manifests\u003c/a\u003e bin und seit Jahren predige, sich diesem Manifest anzuschließen? Ich glaube, im Zeitalter agentischer Softwaremodernisierung wird das Manifest relevanter denn je zuvor. 😉\u003c/p\u003e\n\n\u003cp\u003e\u003cem\u003eWer sich für die Diagramme interessiert: Das zugehörige \u003ca href=\"https://github.com/feststelltaste/software-analytics/blob/master/notebooks/AI%20Productivity%20Gains%20in%20different%20Situations.ipynb\"\u003eJupyter Notebook\u003c/a\u003e, das die Bilder auf Basis der Daten aus dem Vortrag erstellt hat, ist hier verfügbar.\u003c/em\u003e\u003c/p\u003e\n\n\u003cp\u003e\u003cem\u003eHeader-Bild stamm von \u003ca href=\"https://commons.wikimedia.org/wiki/File:2011-365-314_Social_Media_Cootie_Catcher_(6333021221).jpg\"\u003eWikipedia\u003c/a\u003e, Creative Commons CC0 1.0 Universal Public Domain Dedication.\u003c/em\u003e\u003c/p\u003e\n\u003c/body\u003e\u003c/html\u003e\n","image":"https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2000/v1/uploads-production/p9e3ydq9mg9kntno74rxqcepm9x8?_a=BACMTiAE"},{"id":"https://www.innoq.com/de/blog/2026/02/spec-driven-architecture-contracts-fuer-agenten/","url":"https://www.innoq.com/de/blog/2026/02/spec-driven-architecture-contracts-fuer-agenten/","date_published":"2026-03-26T00:00:00.000+00:00","date_modified":"2026-03-26T11:31:42.829+01:00","author":[{"name":"Philipp Beyerlein","url":"https://www.innoq.com/ch/staff/philipp-beyerlein/"}],"content_html":"\u003c!DOCTYPE html PUBLIC \"-//W3C//DTD HTML 4.0 Transitional//EN\" \"http://www.w3.org/TR/REC-html40/loose.dtd\"\u003e\n\u003chtml\u003e\u003cbody\u003e\n\u003cp\u003eAgentische Entwicklung verändert gerade, wo der eigentliche Engpass in der Softwareentwicklung liegt. Wer heute mit Tools wie \u003ca href=\"https://docs.bmad-method.org\"\u003eBMAD\u003c/a\u003e, Claude Code oder Cursor arbeitet und strukturierte Spezifikationen als Grundlage nutzt, erlebt das direkt: Implementierung wird schnell, günstig, skalierbar. Ein neuer Service, ein Refactoring, eine zusätzliche Feature-Unit: Stunden statt Wochen.\u003c/p\u003e\n\n\u003cp\u003eAber Implementierungsgeschwindigkeit löst kein Architekturproblem. Sie verstärkt es.\u003c/p\u003e\n\n\u003ch3 id=\"das-problem-implizite-architektur-und-verteilte-systeme\"\u003eDas Problem: Implizite Architektur und verteilte Systeme\u003c/h3\u003e\n\n\u003cp\u003eStell dir vor, du entwickelst eine neue Anwendung spec-driven mit einem agentischen Workflow. Die Spezifikation ist klar, der Agent liefert sauber, die Tests sind grün. Dann kommt der Moment, wo diese Anwendung in eine bestehende Enterprise-Landschaft integriert werden soll, und plötzlich tauchen Fragen auf, die in keiner Spec stehen: Welches Logging-Format gilt hier? Welche Auth-Infrastruktur wird genutzt? Darf dieser Service direkt in die Datenbank eines Nachbarsystems schreiben? Welche Events muss er publizieren, damit andere Systeme mitbekommen, was passiert?\u003c/p\u003e\n\n\u003cp\u003eDiese Fragen sind keine Implementierungsdetails. Sie sind Architekturentscheidungen, die systemweit gelten und die im verteilten System kollektiv eingehalten werden müssen. Solange du eine standalone-Anwendung baust, kannst du darüber hinwegsehen. Sobald du in einer verteilten Systemlandschaft operierst, werden sie zum Pflichtprogramm.\u003c/p\u003e\n\n\u003cp\u003eGenau hier beginnt das eigentliche Problem. Architektur lebt in den meisten Projekten implizit: in ADRs, die niemand mehr liest, in Confluence-Seiten, die beim letzten Sprint nicht aktualisiert wurden, in Framework-Konventionen, die als selbstverständlich gelten, bis ein Agent sie nicht kennt. Das Problem ist nicht, dass diese Architektur falsch ist. Das Problem ist, dass sie nicht durchsetzbar ist. Kein Build schlägt fehl, weil eine Domänengrenze überschritten wurde. Kein CI-Job meldet, dass eine verbotene Abhängigkeit eingeführt wurde. Drift entsteht leise und wird erst sichtbar, wenn er teuer ist.\u003c/p\u003e\n\n\u003cp\u003eIn agentischen Setups potenziert sich der Effekt. Jede autonom generierte Einheit ist ein neuer Punkt, an dem eine Architekturkonvention stillschweigend verletzt werden kann. Nicht aus Böswilligkeit, sondern weil der Agent es schlicht nicht wissen kann, wenn das Wissen nirgendwo explizit steht.\u003c/p\u003e\n\n\u003ch3 id=\"spec-driven-architecture\"\u003eSpec-Driven Architecture\u003c/h3\u003e\n\n\u003cp\u003eSpec-Driven Development ist der Ansatz, Spezifikation als primäres Artefakt zu behandeln, aus dem Implementierung und Tests abgeleitet werden. SDD beschreibt, wie ein System korrekt \u003cstrong\u003eimplementiert\u003c/strong\u003e wird. Es beschreibt nicht, wie ein Portfolio von Systemen \u003cstrong\u003ekohärent bleibt\u003c/strong\u003e.\u003c/p\u003e\n\n\u003cp\u003eGenau diese Lücke adressiert \u003cstrong\u003eSpec-Driven Architecture (SDA)\u003c/strong\u003e.\u003c/p\u003e\n\n\u003cp\u003eSDA überträgt das Kernprinzip von SDD auf die Architekturebene: Nicht Diagramme, nicht ADRs sind die Architektur, sondern versionierte, agenten-optimierte Contracts. In einem verteilten, agentisch entwickelten System wirken sie auf mehreren Ebenen gleichzeitig:\u003c/p\u003e\n\n\u003cul\u003e\n\u003cli\u003e\u003cp\u003e\u003cstrong\u003eEntwicklungsprozess:\u003c/strong\u003e Contracts für Architektur, Operations oder Security definieren Leitplanken, innerhalb derer Agenten autonom implementieren dürfen.\u003c/p\u003e\u003c/li\u003e\n\u003cli\u003e\u003cp\u003e\u003cstrong\u003eZwischen Systemen:\u003c/strong\u003e Architecture Contracts können erlaubte Abhängigkeiten und Kommunikationsmuster über Systemgrenzen hinweg festlegen.\u003c/p\u003e\u003c/li\u003e\n\u003cli\u003e\u003cp\u003e\u003cstrong\u003eInnerhalb eines Systems:\u003c/strong\u003e Contracts für das Domain Design können Semantik, Invarianten und Schnittstellen einer Domain verbindlich machen.\u003c/p\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\n\u003cp\u003eSDA ersetzt dabei keine bestehende Governance. Sie automatisiert sie. Was heute in Architecture Review Boards diskutiert, in ADRs dokumentiert und in Retrospektiven korrigiert wird, wird in SDA zum überprüfbaren Artefakt, das nicht mehr im nächsten Sprint vergessen werden kann.\u003c/p\u003e\n\n\u003ch3 id=\"contracts-grenzen-und-garantien-fur-agenten-und-teams\"\u003eContracts: Grenzen und Garantien für Agenten und Teams\u003c/h3\u003e\n\n\u003cp\u003eEin Contract in SDA ist keine abstrakte Idee. Er ist eine explizite, überprüfbare Aussage über Erwartungen, Garantien und Grenzen zwischen Domains, Services, Teams und Agenten, ein Artefakt, das genauso behandelt wird wie Quellcode: versioniert, reviewed, Teil der Pipeline.\u003c/p\u003e\n\n\u003cp\u003eDer Begriff meint hier etwas anderes als API- oder Consumer-Driven Contracts wie Pact: Während diese das Verhalten zwischen zwei Services auf Implementierungsebene regeln, operieren SDA Contracts auf Architektur-, Governance- und Domain-Ebene. Sie legen nicht fest, wie zwei Services miteinander sprechen, sondern was in einem System überhaupt erlaubt ist.\u003c/p\u003e\n\n\u003cp\u003eWelche Contracts ein System braucht, hängt von dessen konkreten Anforderungen ab. Es gibt keine abschließende Liste. Die folgenden Beispiele sind typisch für verteilte Systeme.\u003c/p\u003e\n\n\u003cp\u003e\u003cstrong\u003eDomain Contracts\u003c/strong\u003e beschreiben die fachliche Semantik einer Domain nach außen: welche Begriffe sie definiert, welche Invarianten sie garantiert, über welche API- oder Event-Schnittstellen sie konsumiert werden darf. Ein Domain Contract schützt die Integrität der Domain, nicht nur gegenüber anderen Teams, sondern auch gegenüber Agenten, die autonom neue Implementierungen erzeugen. Er legt fest, was stabil bleiben muss, damit Konsumenten sich darauf verlassen können. Domain Contracts formalisieren Konzepte von DDD: Sie grenzen die Ubiquitous Language einer Domain nach außen ab und legen fest, welche Begriffe und Invarianten für andere Domains relevant und stabil sind, und was intern bleibt. Was bisher oft in Event-Storming-Boards und Team-Köpfen lebte, wird in SDA zum versionierten Artefakt.\u003c/p\u003e\n\n\u003cp\u003e\u003cstrong\u003eArchitecture Contracts\u003c/strong\u003e regeln die Struktur des Gesamtsystems: welche Abhängigkeiten zwischen Modulen erlaubt sind, welche Kommunikationsmuster gelten, wo Schichtgrenzen verlaufen. Sie übersetzen implizite Konventionen wie „wir rufen nie direkt in die Datenbank einer anderen Domain\" in überprüfbare Regeln, die ein Linter oder CI-Job automatisch validiert.\u003c/p\u003e\n\n\u003cp\u003e\u003cstrong\u003eOps Contracts\u003c/strong\u003e definieren die Betriebsanforderungen, die für jede Einheit gelten: Metriken, Tracing, Logging-Standards. Gerade wenn neue Services schnell entstehen, verhindern sie, dass Observability ein nachträgliches Aufräumprojekt wird.\u003c/p\u003e\n\n\u003cp\u003e\u003cstrong\u003eSecurity Contracts\u003c/strong\u003e legen fest, welche Datenklassifikationen ein Service verarbeiten darf, welche Auth-Mechanismen vorgeschrieben sind und welche Compliance-Regeln gelten. Das klingt nach klassischem Security-Overhead, wird aber im agentischen Kontext konkret kritisch. Ein Agent, der autonom einen neuen Service erzeugt, der Kundendaten verarbeitet, hat ohne expliziten Security Contract keine Grundlage zu wissen, dass diese Daten verschlüsselt gespeichert, nur über interne Netze übertragen und nicht in generische Log-Ausgaben geschrieben werden dürfen. Ein Security Contract macht genau diese Anforderungen zu einem prüfbaren Build-Artefakt, nicht zu einer Checkliste, die jemand nach dem Deployment ausfüllt. Tools wie Open Policy Agent (OPA) zeigen, dass das kein theoretisches Konzept ist, sondern heute produktiv umsetzbar ist.\u003c/p\u003e\n\n\u003cp\u003eDazu kommen je nach Kontext weitere: Test Contracts, die definieren, welche Qualitätsgates für eine Domain gelten, oder Deployment Contracts, die Infrastructure-Anforderungen regeln. Das Prinzip ist immer dasselbe: Implizites Architekturwissen wird explizit, versionierbar und automatisiert prüfbar gemacht, damit Agenten wie Teams gleichermaßen wissen, wo die Grenzen sind.\u003c/p\u003e\n\n\u003ch3 id=\"wie-sieht-ein-contract-konkret-aus\"\u003eWie sieht ein Contract konkret aus?\u003c/h3\u003e\n\n\u003cp\u003eDer einfachste Einstieg ist eine Markdown-Datei im Repository. Kein spezielles Format, kein Tool-Zwang, nur explizites, versioniertes Wissen, das für Menschen wie Agenten gleichermaßen lesbar ist. Ein Domain Contract für eine Ordering-Domain könnte so aussehen:\u003c/p\u003e\n\n\u003cfigure\u003e\u003cdiv class=\"highlight\" title=\"\"\u003e\u003cpre class=\"\"\u003e\u003ccode\u003e\u003cspan class=\"gh\"\u003e# Domain Contract: Ordering\r\u003c/span\u003e\n\r\n\u003cspan class=\"gu\"\u003e#### Owner\r\u003c/span\u003e\nTeam Checkout, checkout@example.com\r\n\r\n\u003cspan class=\"gu\"\u003e## Ubiquitous Language\r\u003c/span\u003e\n\u003cspan class=\"p\"\u003e-\u003c/span\u003e \u003cspan class=\"gs\"\u003e**Order**\u003c/span\u003e: A confirmed purchase intent by a customer, containing at least one item.\r\n\u003cspan class=\"p\"\u003e-\u003c/span\u003e \u003cspan class=\"gs\"\u003e**OrderItem**\u003c/span\u003e: A single product line with quantity and price fixed at the time of ordering.\r\n\u003cspan class=\"p\"\u003e-\u003c/span\u003e \u003cspan class=\"gs\"\u003e**OrderStatus**\u003c/span\u003e: Enum — PENDING, CONFIRMED, SHIPPED, CANCELLED\r\n\r\n\u003cspan class=\"gu\"\u003e#### Invariants\r\u003c/span\u003e\n\u003cspan class=\"p\"\u003e-\u003c/span\u003e An Order always contains at least one OrderItem.\r\n\u003cspan class=\"p\"\u003e-\u003c/span\u003e The total price is frozen at the time of order creation and never changes retroactively.\r\n\u003cspan class=\"p\"\u003e-\u003c/span\u003e A CANCELLED Order cannot be reactivated.\r\n\r\n\u003cspan class=\"gu\"\u003e#### Published Interface\r\u003c/span\u003e\n\u003cspan class=\"p\"\u003e-\u003c/span\u003e REST API: \u003cspan class=\"sb\"\u003e`POST /orders`\u003c/span\u003e, \u003cspan class=\"sb\"\u003e`GET /orders/{id}`\u003c/span\u003e\r\n\u003cspan class=\"p\"\u003e-\u003c/span\u003e Events: \u003cspan class=\"sb\"\u003e`OrderConfirmed`\u003c/span\u003e, \u003cspan class=\"sb\"\u003e`OrderCancelled`\u003c/span\u003e (schema see /contracts/events/ordering.json)\r\n\r\n\u003cspan class=\"gu\"\u003e#### What this domain does NOT own\r\u003c/span\u003e\n\u003cspan class=\"p\"\u003e-\u003c/span\u003e Payment processing (→ Payment Domain)\r\n\u003cspan class=\"p\"\u003e-\u003c/span\u003e Inventory management (→ Inventory Domain)\r\n\r\n\u003cspan class=\"gu\"\u003e#### Consumption Rules\r\u003c/span\u003e\n\u003cspan class=\"p\"\u003e-\u003c/span\u003e Direct database access is not permitted.\r\n\u003cspan class=\"p\"\u003e-\u003c/span\u003e Status changes only via the API — never through direct event manipulation.\u003c/code\u003e\u003c/pre\u003e\u003c/div\u003e\u003c/figure\u003e\n\n\u003cp\u003eDas ist keine Dokumentation im klassischen Sinne, es ist ein Vertrag. Ein Agent, der einen neuen Service in der Ordering-Domain implementiert, bekommt diesen Contract als Kontext und weiß damit: welche Begriffe verbindlich sind, welche Invarianten er einhalten muss, welche Schnittstellen existieren und wo die Grenzen der Domain liegen. Das ist der Unterschied zwischen einem Agenten, der rät, und einem Agenten, der innerhalb klarer Leitplanken arbeitet.\u003c/p\u003e\n\n\u003cp\u003eDas gleiche Prinzip funktioniert für Architecture Contracts als YAML-Policy, für Security Contracts als OPA-Regeldatei, für Ops Contracts als Teil einer Plattform-Konfiguration. Das Format folgt dem Kontext, die Eigenschaft bleibt dieselbe: versioniert, prüfbar, Teil der Pipeline.\u003c/p\u003e\n\n\u003ch4 id=\"von-markdown-zu-einem-contract-system\"\u003eVon Markdown zu einem Contract-System\u003c/h4\u003e\n\n\u003cp\u003eMarkdown im Repository ist ein pragmatischer Einstieg, aber kein Endzustand. Wenn Contracts über viele Domains, Teams und Systeme wachsen, stellt sich die Frage der Verwaltung: Wie bleiben Contracts konsistent? Wie werden Abhängigkeiten zwischen Contracts sichtbar? Wie bekommen Agenten zur Laufzeit den richtigen Contract-Kontext?\u003c/p\u003e\n\n\u003cp\u003eEine naheliegende Entwicklungsstufe ist ein dediziertes Contract-Repository, ein zentraler Ort, an dem alle Contracts versioniert gepflegt, auf Konsistenz geprüft und mit den betroffenen Domains verknüpft werden. Änderungen an einem Contract lösen automatisierte Checks aus: Welche Konsumenten sind betroffen? Welche Agenten-Workflows müssen neu validiert werden?\u003c/p\u003e\n\n\u003cp\u003eDer nächste Schritt ist die aktive Bereitstellung von Contracts an Agenten zur Laufzeit. Statt Contracts statisch in den Kontext eines Agenten zu laden, könnte ein Contract-Server über das \u003ca href=\"https://spec.modelcontextprotocol.io\"\u003eModel Context Protocol (MCP)\u003c/a\u003e als Tool oder Resource bereitstehen. Der Agent fragt aktiv nach dem gültigen Domain Contract für die Ordering-Domain, bevor er eine Implementierung erzeugt. Er ruft den aktuellen Security Contract für Kundendaten ab, bevor er Datenbankzugriffe generiert. Contracts werden damit nicht nur Governance-Artefakte, sondern aktiver Teil des agentischen Entwicklungsprozesses: dynamisch, kontextabhängig und immer auf dem aktuellen Stand.\u003c/p\u003e\n\n\u003cp\u003eDas ist noch Zukunft. Aber eine, deren Grundlage heute schon gelegt werden kann, mit einer Markdown-Datei im Repository.\u003c/p\u003e\n\n\u003ch3 id=\"contracts-in-der-agentischen-entwicklung-der-gatekeeper\"\u003eContracts in der agentischen Entwicklung: Der Gatekeeper\u003c/h3\u003e\n\n\u003cp\u003eEin Contract im Repository ist ein guter Anfang. Aber ein Agent, der diesen Contract nicht kennt, hält sich auch nicht daran. Die entscheidende Frage ist deshalb nicht, wo Contracts liegen, sondern wann und wie sie in den agentischen Workflow gelangen.\u003c/p\u003e\n\n\u003cp\u003eDie naheliegendste Antwort: als Skill.\u003c/p\u003e\n\n\u003cp\u003eEin Gatekeeper-Skill ist ein spezialisierter Agent, der die relevanten Contracts kennt und im Workflow eine doppelte Rolle spielt. Er ist Berater und Prüfer gleichzeitig. Bevor ein Implementierungs-Agent mit einer Aufgabe beginnt, kann er den Gatekeeper konsultieren: Welche Begriffe muss ich in dieser Domain einhalten? Welche Abhängigkeiten sind verboten? Welche Schnittstellen darf ich konsumieren? Der Gatekeeper antwortet mit dem relevanten Contract-Kontext, und der Implementierungs-Agent baut von Anfang an innerhalb der Leitplanken.\u003c/p\u003e\n\n\u003cp\u003eAm Ende jedes Workflow-Schritts wechselt der Gatekeeper die Rolle. Er übernimmt das Ergebnis und validiert es gegen die Contracts: Werden die Invarianten der Domain eingehalten? Verletzt die neue Abhängigkeit die Architecture Contracts? Fehlt das Tracing, das der Ops Contract vorschreibt? Erst wenn der Gatekeeper grünes Licht gibt, geht der Workflow weiter. Anderenfalls liefert er konkretes Feedback zurück an den Implementierungs-Agenten.\u003c/p\u003e\n\n\u003cfigure\u003e\u003cdiv class=\"highlight\" title=\"\"\u003e\u003cpre class=\"\"\u003e\u003ccode\u003e\u003cspan class=\"s\"\u003e---\u003c/span\u003e\u003cspan class=\"err\"\u003e\r\u003c/span\u003e\n\u003cspan class=\"na\"\u003ename\u003c/span\u003e\u003cspan class=\"pi\"\u003e:\u003c/span\u003e \u003cspan class=\"s\"\u003econtract-gatekeeper\u003c/span\u003e\u003cspan class=\"err\"\u003e\r\u003c/span\u003e\n\u003cspan class=\"na\"\u003edescription\u003c/span\u003e\u003cspan class=\"pi\"\u003e:\u003c/span\u003e \u003cspan class=\"s\"\u003eUse this skill to validate implementation decisions against active\u003c/span\u003e\u003cspan class=\"err\"\u003e\r\u003c/span\u003e\n  \u003cspan class=\"s\"\u003edomain, architecture, ops, and security contracts. Invoke before any\u003c/span\u003e\u003cspan class=\"err\"\u003e\r\u003c/span\u003e\n  \u003cspan class=\"s\"\u003enon-trivial implementation step and after each workflow step completes.\u003c/span\u003e\u003cspan class=\"err\"\u003e\r\u003c/span\u003e\n\u003cspan class=\"s\"\u003e---\u003c/span\u003e\u003cspan class=\"err\"\u003e\r\u003c/span\u003e\n\r\n\u003cspan class=\"gu\"\u003e### Contract Gatekeeper\r\u003c/span\u003e\n\r\nYou are the contract gatekeeper for this system.\r\nYou know all active Domain Contracts, Architecture Contracts, Ops Contracts,\r\nand Security Contracts.\r\n\r\n\u003cspan class=\"gu\"\u003e#### When consulted (pre-implementation)\r\u003c/span\u003e\n\r\nAn agent asks whether a planned approach is contract-compliant.\r\n\u003cspan class=\"p\"\u003e\r\n1.\u003c/span\u003e Identify which contracts are relevant to the request.\r\n\u003cspan class=\"p\"\u003e2.\u003c/span\u003e Respond with the relevant contract sections.\r\n\u003cspan class=\"p\"\u003e3.\u003c/span\u003e Return a clear assessment:\r\n\u003cspan class=\"p\"\u003e   -\u003c/span\u003e \u003cspan class=\"gs\"\u003e**green**\u003c/span\u003e: compliant, proceed.\r\n\u003cspan class=\"p\"\u003e   -\u003c/span\u003e \u003cspan class=\"gs\"\u003e**yellow**\u003c/span\u003e: risk identified, document justification before proceeding.\r\n\u003cspan class=\"p\"\u003e   -\u003c/span\u003e \u003cspan class=\"gs\"\u003e**red**\u003c/span\u003e: violation, do not proceed without contract change.\r\n\r\n\u003cspan class=\"gu\"\u003e#### When reviewing (post-step)\r\u003c/span\u003e\n\r\nAn agent submits an implementation result for review.\r\n\u003cspan class=\"p\"\u003e\r\n1.\u003c/span\u003e Check the result against all relevant contracts.\r\n\u003cspan class=\"p\"\u003e2.\u003c/span\u003e Return structured feedback:\r\n\u003cspan class=\"p\"\u003e   -\u003c/span\u003e which contracts were checked\r\n\u003cspan class=\"p\"\u003e   -\u003c/span\u003e what is compliant\r\n\u003cspan class=\"p\"\u003e   -\u003c/span\u003e what is not compliant, with specific reference to the violated rule\r\n\r\n\u003cspan class=\"gu\"\u003e#### Contracts\r\u003c/span\u003e\n\r\n[Embed relevant contracts here or retrieve via MCP at runtime]\u003c/code\u003e\u003c/pre\u003e\u003c/div\u003e\u003c/figure\u003e\n\n\u003cp\u003eDer Workflow-Agent seinerseits wird so instruiert, dass er den Gatekeeper nicht überspringen kann. Er weiß: Vor jedem nicht-trivialen Implementierungsschritt frage ich den Gatekeeper. Nach jedem Schritt lasse ich das Ergebnis prüfen. Das ist keine Empfehlung, das ist Teil der Workflow-Struktur.\u003c/p\u003e\n\n\u003cfigure\u003e\u003cdiv class=\"highlight\" title=\"\"\u003e\u003cpre class=\"\"\u003e\u003ccode\u003e\u003cspan class=\"gu\"\u003e### Implementation Agent — Workflow Instructions (excerpt)\r\u003c/span\u003e\n\r\n\u003cspan class=\"gu\"\u003e#### Contract Compliance\r\u003c/span\u003e\n\r\nBefore any implementation decision that touches a domain boundary, a dependency,\r\nor an interface: consult the contract-gatekeeper skill.\r\n\r\nProvide: what you intend to implement, in which domain, and which resources\r\nyou plan to use.\r\n\r\nAfter completing each step: submit the result to the contract-gatekeeper for review.\r\nDo not proceed until the gatekeeper returns green, or a justified yellow\r\nis documented.\u003c/code\u003e\u003c/pre\u003e\u003c/div\u003e\u003c/figure\u003e\n\n\u003cp\u003eDieses Muster löst beide Probleme gleichzeitig. Der Agent bekommt Contract-Kontext zur richtigen Zeit, nicht irgendwo als Anhang, sondern aktiv im Workflow verankert. Und Enforcement passiert nicht nur am Ende, sondern kontinuierlich: früh genug, um schlechte Entscheidungen zu verhindern, bevor sie in Code gegossen sind.\u003c/p\u003e\n\n\u003cp\u003eDie gleiche Logik funktioniert in einer klassischen CI/CD-Pipeline, ohne dass der Entwicklungsworkflow schon agentisch sein muss. Ein dedizierter Pipeline-Step ruft einen Agenten auf, der jeden Commit gegen die relevanten Contracts prüft. Bestehende CI/CD-Tools müssen lediglich ergänzt werden.\u003c/p\u003e\n\n\u003cp\u003eDas macht Contracts zu einem pragmatischen Einstieg. Teams, die noch nicht auf agentische Workflows umgestellt haben, können Contracts trotzdem einführen und sofort von der automatisierten Prüfung profitieren. Der Contract-Linter im CI-Job und der Gatekeeper-Skill im agentischen Workflow sind zwei Ausprägungen desselben Prinzips. Wer mit dem CI-Step beginnt, hat die Grundlage bereits gelegt, wenn der Schritt zu SDD-Workflows folgt.\u003c/p\u003e\n\n\u003ch3 id=\"governance-ohne-permanenten-einspruch\"\u003eGovernance ohne permanenten Einspruch\u003c/h3\u003e\n\n\u003cp\u003eIn den meisten Projekten ist Governance eine Rolle, die jemand spielen muss. Jemand, der im Architecture Review Board den Überblick behält. Jemand, der im PR-Kommentar schreibt: „Aber haben wir eigentlich gecheckt, ob das unsere Layering-Regeln verletzt?\" Jemand, der nach dem Sprint fragt, warum der neue Service kein Tracing hat. Diese Person ist nicht böswillig. Sie ist notwendig, weil das Wissen sonst nirgendwo steht.\u003c/p\u003e\n\n\u003cp\u003eSDA verändert diese Rolle grundlegend. Wer bisher Governance im Review einfordern musste, bekommt jetzt ein Werkzeug, das früher greift: Contracts, die vom ersten Commit an gelten, nicht erst, wenn alles fertig gebaut ist. Die Verantwortung bleibt dieselbe. Was sich ändert, ist der Zeitpunkt der Wirkung. Wenn Architekturentscheidungen in versionierten Contracts stehen, wenn der Gatekeeper-Skill jeden Workflow-Schritt gegen diese Contracts prüft, wenn der CI-Job bei jedem Commit validiert: Governance ist einfach da. Nicht als Kontrolle, die jemand ausübt, sondern als Eigenschaft des Prozesses.\u003c/p\u003e\n\n\u003cp\u003eMeetings und Architecture Review Boards verschwinden dadurch nicht. Sie gewinnen ihren eigentlichen Zweck zurück: Entscheidungen treffen, Contracts formulieren, Grenzen bewusst setzen. Was wegfällt, ist der dauernde Overhead, diese Entscheidungen in jedem Kontext erneut einzufordern und zu erklären. Das Architecture Review Board entscheidet, was gilt. Der Rest des Prozesses sorgt dafür, dass es gilt.\u003c/p\u003e\n\n\u003cp\u003eSDA ist kein Framework, kein Tool, kein Ersatz für DDD oder Microservice-Muster. Es ist ein Governance-Prinzip für eine Welt, in der Implementierung billig geworden ist und Architektur das Letzte ist, was Systeme kohärent hält.\u003c/p\u003e\n\u003c/body\u003e\u003c/html\u003e\n","image":"https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2000/v1/uploads-production/jr17ce5aif9xxapfxi4yu06i6gbl?_a=BACMTiAE"},{"id":"https://www.innoq.com/de/blog/2026/03/rest-ist-das-bessere-mcp/","url":"https://www.innoq.com/de/blog/2026/03/rest-ist-das-bessere-mcp/","date_published":"2026-03-19T00:00:00.000+00:00","date_modified":"2026-03-24T12:35:00.207+01:00","author":[{"name":"Martin Otten","url":"https://www.innoq.com/ch/staff/martin-otten/"}],"content_html":"\u003c!DOCTYPE html PUBLIC \"-//W3C//DTD HTML 4.0 Transitional//EN\" \"http://www.w3.org/TR/REC-html40/loose.dtd\"\u003e\n\u003chtml\u003e\u003cbody\u003e\n\u003cp\u003eEs gibt immer Tätigkeiten, die wir gerne automatisieren würden, dies aber aus verschiedenen Gründen nicht tun. Oft fehlt die Zeit, es ist nicht wichtig genug oder wir machen es zu selten. Oder es handelt sich um Aufgaben, die kontextabhängig sind und nur mit hohem Aufwand standardisiert werden können. Diese Aufgaben werden bisher von Menschen erledigt, so langweilig sie auch sein mögen.\u003c/p\u003e\n\n\u003cp\u003eBei mir ist eine solche Aufgabe die regelmäßige Reisekostenabrechnung. Grundsätzlich haben wir hier bereits ein gutes Tool, das mir viel Arbeit abnimmt. Es gibt jedoch viele Faktoren wie Reisezeiten, Orte und verschiedene Rechnungsformate, die dazu führen, dass ich das Anlegen von Verpflegungspauschalen, Kostenstellen und das Zuordnen von Belegen selbst machen muss.\u003c/p\u003e\n\n\u003cp\u003eDerartige manuelle Tätigkeiten verursachen in Prozessen Kosten. Für mich bedeutet das einen Kontextwechsel zu einer Tätigkeit, die nicht wertschöpfend ist. Daraus entstehen für andere Teile des Unternehmens Wartezeiten. Wartezeiten sind dabei vielleicht das größte Problem und zugleich das größte Potenzial in der Prozessoptimierung. Und weil das nicht gerade eine Tätigkeit ist, mit der ich Umsatz erzeuge oder die ich gerne tue, schiebe ich diese Reisekostenabrechnung immer wieder bis zum letzten Moment auf und bekomme dann eine Erinnerung von der Buchhaltung. Dabei müsste das gar nicht passieren, wenn nur jemand anderes diese Aufgabe für mich erledigen könnte …\u003c/p\u003e\n\n\u003cp\u003eZum Glück kann ein KI-Agent das heute für mich erledigen. Dabei müssen Informationen aus verschiedenen Datenquellen kombiniert und in der Anwendung eingegeben werden. Termine und Reisezeiten stammen aus meinem Kalender, Rechnungen aus meinen E-Mails, und die Reisekosten werden in einer Web-Anwendung angelegt. Um auf diese Daten zuzugreifen, gibt es verschiedene Möglichkeiten. MCP-Server wären der klassische Weg, sie haben aber auch Nachteile. Sie laden ihre ganze Anleitung immer in den Kontext, und man muss die Implementierung der Server gut prüfen und auswählen. MCP-Server sind strukturell RPC – der Aufrufer muss vorab wissen, welche Funktionen existieren. Eine Web-Anwendung zeigt im jeweiligen Kontext dagegen, welche Aktionen gerade möglich und erlaubt sind. Daher habe ich für zwei der Integrationen andere Wege gewählt.\u003c/p\u003e\n\n\u003cul\u003e\n\u003cli\u003eKalender: Statt eines MCP-Servers nutze ich einen geteilten Kalender, der als iCal-Feed über HTTP abrufbar ist – ein standardisiertes Format, das ohne zusätzliche Implementierung überall funktioniert.\u003c/li\u003e\n\u003cli\u003eMail: Der Zugriff läuft über einen Kommandozeilen-Client (Himalaya), der eine robuste Implementierung und API liefert. Dies ist nah an der Idee von MCP, funktioniert aber erst einmal ohne den zusätzlichen Kontext-Overhead.\u003c/li\u003e\n\u003cli\u003eReisekosten-Web-Anwendung: Hier gibt es keinen Reisekosten-MCP-Server. Wir nutzen stattdessen den Browser über ein MCP für Playwright.\u003c/li\u003e\n\u003c/ul\u003e\n\n\u003cp\u003eDoch kann ein KI-Agent gut mit Webseiten arbeiten? Wir denken bei Browserautomatisierung wahrscheinlich an Tools wie Selenium und brüchige automatisierte UI-Tests. Davon müssen wir uns hier lösen. Tatsächlich sind KI-Agenten sehr gut darin, Browser interaktiv zu bedienen. Da sie ihr Verhalten anpassen können, können sie auch mit Fehlern umgehen und Lösungen finden.\u003c/p\u003e\n\n\u003cp\u003eTatsächlich hat die Nutzung von Web-Anwendungen als Schnittstellen für KI-Agenten klare Vorteile gegenüber einem MCP-Server:\u003c/p\u003e\n\n\u003col\u003e\n\u003cli\u003eDie Web-Anwendung ist schon da, wir müssen nichts Neues implementieren.\u003c/li\u003e\n\u003cli\u003eWeb-Anwendungen sind die besten Implementierungen von Hypermedia, wir bekommen über HTML und JavaScript Kontext. Inhalte, Navigationsstrukturen und mögliche Commands sind vorgegeben. Sie ändern sich sogar abhängig vom Kontext, statt wie bei MCP eine statische Auswahl an Funktionen zu liefern.\u003c/li\u003e\n\u003cli\u003eWeb-Anwendungen sind für Menschen gebaut, die Fehler machen. Wir validieren in Web-Anwendungen bereits Eingaben und prüfen, ob Aktionen erlaubt sind oder zu inkonsistenten Zuständen führen. Es ist normal, dass Menschen zumindest Flüchtigkeitsfehler machen. Das ist ein großer Vorteil für KI-Agenten: Diese können hier Fehleingaben machen, bekommen Feedback und passen ihr Verhalten an, um das Problem zu lösen.\u003c/li\u003e\n\u003cli\u003eWeb-Anwendungen haben bereits ein Rollen- und Rechtesystem. Ein Agent erhält minimal notwendige Rechte, ohne neue Sicherheitsinfrastruktur implementieren zu müssen.\u003c/li\u003e\n\u003c/ol\u003e\n\n\u003cp\u003eSomit bewegen sich KI-Agenten in einem konkreten Rahmen an Möglichkeiten, statt ein Problem auf der grünen Wiese zu lösen. Es gibt einen festen Kontext, in dem sich der Agent bewegen kann.\u003c/p\u003e\n\n\u003cp\u003eEs gibt keinen Bruch zwischen der Schnittstelle für Menschen und Maschinen, es ist dieselbe Schnittstelle mit den gleichen Möglichkeiten, Sicherheitsgarantien und Problemen.\u003c/p\u003e\n\n\u003cp\u003eIm Vergleich dazu würden wir bei einer JSON-API oft nur Rohdaten, aber keine Semantik erhalten.\u003c/p\u003e\n\n\u003cp\u003eWirklich durchgesetzt hat sich Hypermedia\u003ca href=\"https://www.innoq.com/de/blog/2026/03/rest-ist-das-bessere-mcp/#fn:1\" id=\"fnref:1\" title=\"siehe Fußnote\" class=\"footnote\"\u003e[1]\u003c/a\u003e bisher nur für „menschliche“ Browser-Nutzer. KI-Agenten sind die ersten nicht menschlichen Nutzer, die diese Schnittstellen vollständig nutzen und von ihnen profitieren können.\u003c/p\u003e\n\n\u003cp\u003eUm dies zu ermöglichen, benötigen wir nur einen MCP-Server für die Browsernutzung. Dieser hat selbst, wie ein Webbrowser, keine fachliche Funktionalität. Er ermöglicht den Zugang zu weiteren fachlichen „Tools“ als Web-Anwendungen. Und damit ist die Tool-Auswahl und Tool-Spezifikation kontextabhängig und dynamisch geworden.\u003c/p\u003e\n\n\u003cp\u003eDies passt gut dazu, dass wir auch KI-Agenten durch Prompts dynamisch programmieren. Wir geben eine Anweisung in natürlicher Sprache, und das Sprachmodell ist darauf trainiert, daraus eine Problemlösungsstrategie zu entwickeln. Neu ist die Idee, deklarativ zu programmieren, natürlich nicht. Das erfolgreichste Beispiel ist die Datenbanksprache SQL, bei der ich beschreibe, was ich möchte, aber den Lösungsweg nicht vorgebe. Dies ist jedoch ein viel engerer Anwendungsfall, in dem ein solches Vorgehen bisher möglich war.\u003c/p\u003e\n\n\u003ch3 id=\"praxis-beispiel\"\u003ePraxis-Beispiel\u003c/h3\u003e\n\n\u003cp\u003eBeispiel einer Reisekostenabrechnung mit einem KI-Agenten. Wir starten mit einem naiven Prompt.\u003c/p\u003e\n\n\u003cblockquote\u003e\n\u003cp\u003eFür meinen „Event-Storming Workshop“ bei der Capitol Versicherung im Januar muss ich eine Reisekostenabrechnung durchführen. Dazu nutzen wir https://reisekosten.example. Die Reisedaten findest du in meinem Kalender. Rechnungen für Hotel und Bahnfahrt in meinen E-Mails. Bitte lege eine Mappe für die Reise an. Nutze Playwright-MCP, um auf die Webseite zuzugreifen. Lege für jeden Reisetag einen Eintrag Verpflegungspauschale an. Frage mich, wenn etwas unklar sein sollte.\u003c/p\u003e\n\u003c/blockquote\u003e\n\n\u003cp\u003eDieser Prompt ist weit davon entfernt, eine perfekte Anleitung vorzugeben. Dennoch hat der Agent kaum Rückfragen.\u003c/p\u003e\n\n\u003cp\u003eKurz zur Bestätigung:\u003c/p\u003e\n\n\u003cblockquote\u003e\n\u003cul\u003e\n\u003cli\u003eAm \u003cstrong\u003e09.01.2026\u003c/strong\u003e gab es wirklich \u003cstrong\u003ekeine\u003c/strong\u003e gestellten Mahlzeiten?\u003c/li\u003e\n\u003cli\u003eWurde am 10.01.2026, 11.01.2026 und 12.01.2026 Frühstück im Hotel gestellt?\u003c/li\u003e\n\u003cli\u003eDas Projekt „Capitol Versicherung Event-Storming Workshop“ konnte ich nicht finden, ich habe daher nur den \u003cstrong\u003eAnlass\u003c/strong\u003e gesetzt. Soll ich das so lassen, oder gibt es bei euch einen anderen Projektnamen, den ich auswählen soll?\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/blockquote\u003e\n\n\u003cp\u003eDer Agent verpasste mehrere Kontextfaktoren: Dass ich um 22 Uhr Ankunftszeit wahrscheinlich nichts mehr essen möchte, dass die Frühstücksinformation bereits in der Hotelrechnung steht und, dass er nicht versuchte, den Kundennamen für ein existierendes Projekt zu nutzen.\u003c/p\u003e\n\n\u003cp\u003eNachdem ich die Informationen nachgeliefert habe, ist meine Reisekostenabrechnung aber tatsächlich schon fertig. Und das mit wenig Informationen zum Kontext. Vor dem Einreichen prüfe ich die Mappe in der Web-Anwendung selbst.\u003c/p\u003e\n\n\u003cp\u003eNun möchte ich, dass die nächste Reisekostenabrechnung, wenn möglich, ohne Rückfragen läuft. Daher bitte ich den Agenten, selbst eine Anleitung zu schreiben. Zunächst besteht die Anleitung aus einer Ablaufbeschreibung und Heuristiken, die man auch einem Menschen geben würde, um diese Tätigkeit durchzuführen. Zusätzlich hat sich der Agent Notizen zu technischen Problemen bei der Bedienung der Webseite gemacht:\u003c/p\u003e\n\n\u003ch3 id=\"ui-workarounds-playwright-mcp\"\u003eUI-Workarounds (Playwright-MCP)\u003c/h3\u003e\n\n\u003cp\u003eWenn Datepicker Checkboxen blockiert:\u003c/p\u003e\n\n\u003cblockquote\u003e\n\u003cul\u003e\n\u003cli\u003eDatepicker zuerst schließen.\u003c/li\u003e\n\u003c/ul\u003e\n\n\u003cp\u003eWenn UI-Klick weiterhin blockiert:\u003c/p\u003e\n\n\u003cul\u003e\n\u003cli\u003eZustand kontrolliert per \u003ccode\u003eevaluate\u003c/code\u003e setzen (\u003ccode\u003echecked\u003c/code\u003e) und \u003ccode\u003echange\u003c/code\u003e-Event auslösen.\u003c/li\u003e\n\u003c/ul\u003e\n\n\u003cp\u003eBei Projekt-Dropdown ohne Treffer:\u003c/p\u003e\n\n\u003cul\u003e\n\u003cli\u003eFeld leeren, langsam tippen, auf Listbox warten.\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/blockquote\u003e\n\n\u003cp\u003eDiese Anleitung können wir als Skill nutzen und den Agenten nun nach jeder Ausführung prüfen und aktualisieren lassen. Somit können auch solche technischen Aspekte dokumentiert werden, die für den Nutzer sonst unsichtbar sind.\u003c/p\u003e\n\n\u003cp\u003eDamit haben wir ein selbstlernendes System, das mit jeder Aufgabe dazulernt, effizienter wird und weniger Fehler macht.\u003c/p\u003e\n\n\u003cp\u003eBereits mit einer abschließenden Kontrolle nimmt der Agent hier viel Fleißarbeit ab. Noch läuft der Agent nicht völlig autonom, er wird manuell ausgelöst, beobachtet und das Ergebnis kontrolliert. Um wirklich die Wartezeit zu entfernen, müsste der Agent selbstständig Reisen erkennen und diese auch einreichen.\u003c/p\u003e\n\n\u003cp\u003eUm eine solche Entscheidung zu treffen, müssen wir nicht nur wissen, ob der Agent Fehler macht, sondern auch Art und Häufigkeit von Fehlern. Der Prozess ist zum Glück für Menschen entwickelt worden, die auch Fehler machen. Hier kommt eine klassische Risikoanalyse ins Spiel: Welche Arten von Fehlern sind möglich, wie wahrscheinlich sind sie und was wären die Konsequenzen? Am Ende kann dann entschieden werden, ob sich die Vorteile aus der Optimierung des Prozesses und die Risiken in Summe lohnen.\u003c/p\u003e\n\n\u003cp\u003eWenn wir dies für einen Prozess mit größerem Volumen umsetzen wollen, z. B. für alle Reisekostenabrechnungen aller Angestellten, dann werden wir auch mehr Varianz bekommen. Eine Strategie ist es, beide Prozesse parallel laufen zu lassen und zunächst nur die Ergebnisse des Agenten mit den manuellen Abrechnungen zu vergleichen. Erst wenn die Zahlen stimmen, kann man schrittweise umschalten. Wenn dieses Verfahren etabliert wurde, kann es auch zur Kontrolle eingesetzt werden, indem nur ein Teil der Aufgaben automatisiert erledigt wird oder Stichproben durch Menschen und KI-Agenten bearbeitet werden.\u003c/p\u003e\n\n\u003cp\u003eEs gibt zahlreiche derartige Prozesse, die von einer solchen Automatisierung profitieren könnten. Wahrscheinlich haben wir diese bisher nicht auf dem Schirm, da sie für die Softwareentwicklung nicht relevant waren. Nun lassen sich jedoch Systeme über Web-Oberflächen automatisiert integrieren. Wir bauen dabei auf einem bestehenden System auf, das Kontext und Sicherheitsgarantien bietet. Die Herausforderung ist es, die Abläufe zu identifizieren, die durch Agenten unterstützt werden können und die größte Auswirkung auf den Geschäftsablauf haben.\u003c/p\u003e\n\n\u003cfoot-notes class=\"footnotes\"\u003e\n\n\u003col class=\"footnotes__list\"\u003e\n\n\u003cli id=\"fn:1\"\u003e\n\u003cp\u003eREST Level 3 (HATEOAS) \u003ca href=\"https://www.innoq.com/de/blog/2026/03/rest-ist-das-bessere-mcp/#fnref:1\" title=\"zurück zum Text\" class=\"reversefootnote\"\u003e ↩︎\u003c/a\u003e\u003c/p\u003e\n\u003c/li\u003e\n\n\u003c/ol\u003e\n\u003c/foot-notes\u003e\n\u003c/body\u003e\u003c/html\u003e\n","image":"https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2000/v1/uploads-production/myie581dwgxp4czlcwk4qb7qmnbc?_a=BACMTiAE"},{"id":"https://www.innoq.com/de/blog/2026/03/sdd-ddd-why-bmad-wont-save-you/","url":"https://www.innoq.com/de/blog/2026/03/sdd-ddd-why-bmad-wont-save-you/","date_published":"2026-03-18T00:00:00.000+00:00","date_modified":"2026-03-16T11:29:33.939+01:00","author":[{"name":"Daniel Westheide","url":"https://www.innoq.com/ch/staff/daniel-westheide/"}],"content_html":"\u003c!DOCTYPE html PUBLIC \"-//W3C//DTD HTML 4.0 Transitional//EN\" \"http://www.w3.org/TR/REC-html40/loose.dtd\"\u003e\n\u003chtml\u003e\u003cbody\u003e\n\u003cp\u003eIn meinem Beitrag \u003ca href=\"https://www.innoq.com/de/blog/2025/07/erst-agil-dann-agentisch/\"\u003eErst agil, dann agentisch\u003c/a\u003e habe ich argumentiert, dass Agentic Engineering auf organisationaler Ebene nur dann Vorteile bringt, wenn Organisationen bestimmte Fähigkeiten aus der Agile- und DevOps-Bewegung mitbringen. Denn wenn du die Entwicklungsarbeit nur beschleunigst, ohne deine Organisation entsprechend anzupassen, werden diese lokalen Vorteile nicht zu Verbesserungen auf Systemebene führen.\u003c/p\u003e\n\n\u003cp\u003eSpec-Driven Development Tools wie BMAD bekommen gerade viel Aufmerksamkeit – und das aus gutem Grund. Sie zielen darauf ab, ein reales Problem zu lösen, das ich in diesem Beitrag beschrieben habe: Requirements Engineering kann mit KI-unterstützten Entwicklungsteams nicht mithalten. Wenn Agenten eine sauber spezifizierte Story in Minuten implementieren können, wird der vorgelagerte Prozess zum Engpass. BMAD verspricht, das zu lösen, indem es über strukturierte KI-Interviews schnell gehaltvolle Spezifikationen erzeugt. Das Ergebnis: kein Warten mehr auf den Product Owner!\u003c/p\u003e\n\n\u003cp\u003eSind BMAD und andere Spec-driven Development Tools also das fehlende Puzzlestück, damit Agentic Engineering richtig durchstartet? Vielleicht. Unter bestimmten Bedingungen. Das Problem ist die Annahme, die sich hinter den großen Versprechen versteckt.\u003c/p\u003e\n\n\u003ch3 id=\"was-bmad-tatsachlich-macht\"\u003eWas BMAD tatsächlich macht\u003c/h3\u003e\n\n\u003cp\u003eBMAD stellt mehrere Agenten bereit, die jeweils eine klar abgegrenzte Rolle in einem Software-Produktentwicklungsteam abdecken. Einer davon ist Mary, der Analysten-Agent. Mary führt strukturierte Discovery-Interviews, macht Wettbewerbsanalysen, bewertet Geschäftsmodelle und erstellt umfassende Product-Requirements-Dokumente. Für jemanden, der bisher per Vibe-Coding eigene ad-hoc Anforderungen «irgendwie» entstehen ließ, ist das ein deutlicher Schritt nach vorn.\u003c/p\u003e\n\n\u003ch3 id=\"die-spezifikation-ist-nur-so-gut-wie-das-domanenwissen-im-team\"\u003eDie Spezifikation ist nur so gut wie das Domänenwissen im Team\u003c/h3\u003e\n\n\u003cp\u003eAber hier ist der Punkt: Die Spezifikationsschicht hängt vollständig von der Qualität des Domänenwissens ab, das der Mensch ins Interview mitbringt. Der Agent stellt präzise Fragen und kann dabei ziemlich hartnäckig sein. Er lässt dich nicht mit vagen oder ausweichenden Antworten davonkommen, sondern bohrt nach, bis etwas Konkretes vorliegt, mit dem er arbeiten kann. Das ist wertvoll. Aber er kann kein Domänenwissen herbeizaubern.\u003c/p\u003e\n\n\u003ch3 id=\"domain-driven-design-expert-innen-kennen-das\"\u003eDomain-Driven Design-Expert:innen kennen das\u003c/h3\u003e\n\n\u003cp\u003eDomain-Driven Design-Expert:innen werden diese Einschränkung sofort wiedererkennen. DDD erfordert eine dauerhafte, echte Zusammenarbeit zwischen Entwickler:innen und Domänenexpert:innen, um eine gemeinsame ubiquitäre Sprache und ein reichhaltiges Domänenmodell aufzubauen. Wenn Organisationen mit DDD kämpfen (und meiner Erfahrung nach tun das die meisten), liegt das selten daran, dass Entwickler:innen nicht gut genug ausgebildet sind. Häufiger ist das Problem, dass Domänenexpert:innen für Entwickler:innen nicht direkt erreichbar sind. Oft sitzen sie hinter vorgeschalteten Proxy-Product-Ownern. Und egal wie gut diese Product Owner ihre Arbeit machen, es geht dabei fast immer etwas in der Übersetzung verloren. Leider leiden viele Organisationen unter Strukturen und einer Kultur, die die direkte Zusammenarbeit über Bereichsgrenzen hinweg aktiv ausbremsen. Genau diese Zusammenarbeit ist aber entscheidend für erfolgreiches Domain-Driven Design.\u003c/p\u003e\n\n\u003cp\u003eBMAD stößt aus exakt demselben Grund gegen dieselbe Wand. Wenn deine Organisation DDD nicht sauber hinbekommt, kann sie auch nicht von BMADs Spezifikationsschicht profitieren.\u003c/p\u003e\n\n\u003ch3 id=\"vorab-spezifikation-vs-continuous-discovery\"\u003eVorab-Spezifikation vs. Continuous Discovery\u003c/h3\u003e\n\n\u003cp\u003eEs gibt allerdings einen wichtigen Unterschied. DDD setzt voraus, dass Domänenexpert:innen während der Entwicklung kontinuierlich verfügbar sind. Du gehst zu ihnen zurück, wenn dein Domänenmodell bei der Implementierung konzeptionelle Reibung erzeugt – und das passiert wiederholt und nicht planbar. Das Modell entsteht durch Iteration, nicht durch eine Vorab-Spezifikation. Eric Evans sagt das ausdrücklich: Discovery ist kontinuierlich und keine Phase, die man abschließt, bevor man mit dem Coden beginnt.\u003c/p\u003e\n\n\u003cp\u003eSpezifikationsgetriebene Entwicklung basiert auf einer anderen Annahme: Discovery passiert upfront über strukturierte Interviews, und die daraus entstehende Spezifikation steuert die Umsetzung.\u003c/p\u003e\n\n\u003cp\u003eJa, BMAD unterstützt iterative Verfeinerung innerhalb der Planungsphase. Aber der dominante Ablauf bleibt: erst planen, dann implementieren. Kritiker:innen von Spec-Driven Development sagen, hier schlage\n\u003ca href=\"https://marmelab.com/blog/2025/11/12/spec-driven-development-waterfall-strikes-back.html\"\u003e„Waterfall strikes back“\u003c/a\u003e\nzu – mit Big Design Up Front in Form von KI-generierter Dokumentation. Da ist was dran. Ein Domänenmodell, das durch Implementierung und wiederholter Zusammenarbeit entsteht, bildet Dinge ab, die kein Vorab-Interviewprozess zuverlässig ans Licht bringt.\u003c/p\u003e\n\n\u003ch3 id=\"wo-spec-driven-development-wirklich-passt\"\u003eWo Spec-Driven Development wirklich passt\u003c/h3\u003e\n\n\u003cp\u003eEs gibt einen Kontext, in dem BMAD meiner Meinung nach gut passen kann: die technische Gründerperson, die ihre eigene Produktidee umsetzt. Sie ist gleichzeitig Domänenexpert:in, Product Owner, Architekt:in und oft auch Entwickler:in. Es gibt kein Proxy-Problem. Es gibt keine Organisationsgrenzen, die man überwinden muss. Der Analysten-Agent interviewt jemanden, der die Produktidee selbst entwickelt hat, die potenziellen Nutzer:innen idealerweise kennt und zumindest ein grundlegendes Verständnis des Wettbewerbsumfelds mitbringt.\u003c/p\u003e\n\n\u003cp\u003eFür diese Person können BMADs Wettbewerbsanalyse, Marktrecherche und Geschäftsmodellbewertung ziemlich wertvoll sein. Und das Spezifikationsinterview funktioniert, weil das Wissen bereits im Raum ist.\u003c/p\u003e\n\n\u003cp\u003eDie Produktivitätsversprechen, die man in manchen Blogposts liest – etwa dass sich die Planungszeit von Wochen auf Stunden reduziert – werden sich wahrscheinlich vor allem in genau diesem Kontext von Solo-Gründer:innen oder Solo-Entwickler:innen materialisieren.\u003c/p\u003e\n\n\u003ch3 id=\"repariere-die-organisation-nicht-die-toolchain\"\u003eRepariere die Organisation, nicht die Toolchain\u003c/h3\u003e\n\n\u003cp\u003eBevor du überlegst, ob spezifikationsgetriebene Entwicklung dein Requirements Engineering beschleunigen kann, stell dir eine andere Frage: Kann dein Team bei Bedarf echten Zugang zu Domänenexpert:innen bekommen? Sind diese Expert:innen bereit und verfügbar, sich tiefgehend mit Entwicklungsfragen zu beschäftigen? Unterstützen Struktur und Kultur deiner Organisation diese Art der Zusammenarbeit?\u003c/p\u003e\n\n\u003cp\u003eWenn die Antwort ja lautet, können BMAD und andere Methoden aus dem Spec-Driven Development eine sinnvolle Option sein.\u003c/p\u003e\n\n\u003cp\u003eWenn die Antwort nein lautet, hast du ein Organisationsproblem, das kein Interview-Agent lösen kann. Das Tool wird dieses Problem nur expliziter sichtbar machen als ein traditioneller Requirements-Prozess. BMADs hartnäckiges Nachfragen macht Wissenslücken früh sichtbar – und zwar unübersehbar. Aber es kann sie nicht schließen.\u003c/p\u003e\n\n\u003cp\u003eDie Voraussetzung ist dieselbe, die ich in meinem \u003ca href=\"https://www.innoq.com/de/blog/2025/07/erst-agil-dann-agentisch/\"\u003eeingangs erwähnten Beitrag\u003c/a\u003e beschrieben habe: erst organisatorischer Wandel, dann Tools, die ihn verstärken.\u003c/p\u003e\n\u003c/body\u003e\u003c/html\u003e\n","image":"https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2000/v1/uploads-production/lxzz38et383d7z44ns370kb3q2qi?_a=BACMTiAE"},{"id":"https://www.innoq.com/de/blog/2026/03/agenten-gut-alles-gut/","url":"https://www.innoq.com/de/blog/2026/03/agenten-gut-alles-gut/","date_published":"2026-03-12T00:00:00.000+00:00","date_modified":"2026-03-12T10:55:52.864+01:00","author":[{"name":"Fabian Walther","url":"https://www.innoq.com/ch/staff/fabian-walther/"}],"content_html":"\u003c!DOCTYPE html PUBLIC \"-//W3C//DTD HTML 4.0 Transitional//EN\" \"http://www.w3.org/TR/REC-html40/loose.dtd\"\u003e\n\u003chtml\u003e\u003cbody\u003e\n\u003ch3 id=\"die-ewige-wunschliste\"\u003eDie ewige Wunschliste\u003c/h3\u003e\n\n\u003cp\u003e\u003cem\u003eLass uns doch Consumer-Driven-Contract-Tests mit Pact integrieren, denn wir haben da diese 23 Microservices geerbt, die wir mit 3 Personen maintainen sollen. Eine BDD-Testsuite mit Cucumber würde uns total helfen, ultrakomplexe Fachlichkeit transparent sicherzustellen, aber wir haben echt keine Zeit, alle 2 Wochen 3 Tage lang das Selenium-Setup zu debuggen, weil es wieder 5 Browser-Updates gab, die 70 % der Tests haben rot werden lassen. Dieses eine Refactoring schieben wir schon ewig vor uns her, aber das würde sich durch die gesamte Codebase ziehen. Mindestens 3 Tage Fleißarbeit würde das bestimmt bedeuten. Aber das liefert ja keinen spürbaren Impact für User.\u003c/em\u003e (Spürbar wird es erst in 2–3 Jahren werden, wenn die Liefergeschwindigkeit immer weiter sinkt. There is no glory in prevention.)\u003c/p\u003e\n\n\u003cp\u003eHilfreiche Projektinfrastruktur, die aber entweder hohen initialen Zeitinvest oder langfristige Wartung bedeutet, wird und wurde häufig nicht umgesetzt. Entweder sind Teams personell nicht entsprechend aufgestellt oder es fehlt entsprechendes Backing durch die Organisation. So oder so, Ressourcen werden \u003cem\u003e„aus Gründen“\u003c/em\u003e nicht bereitgestellt für eigentlich notwendige Maßnahmen. \u003cstrong\u003eSollten wir jetzt mit Agenten alles umsetzen, und würde dadurch alles besser?\u003c/strong\u003e\u003c/p\u003e\n\n\u003ch3 id=\"jetzt-wird-alles-besser\"\u003eJetzt wird alles besser\u003c/h3\u003e\n\n\u003cp\u003eMein initialer Reflex war „JA“, und ich habe einige Refactorings sehr effizient umsetzen können, während ich parallel weiter an Features arbeiten konnte. Das hat sich unglaublich gut angefühlt. Phasenweise fühlte ich mich regelrecht entfesselt. Es gab immer was zu tun, und ich konnte mich (endlich) mehr auf das Lösen fachlicher Probleme fokussieren. Die Technik stand mir nicht im Weg, sondern ermächtigte mich. Wenn ich über komische Bugs stolperte oder mit Frameworks kämpfte, habe ich erst gar nicht mehr versucht, auf Bugsuche zu gehen: Stacktrace Copy \u0026amp; Paste -\u0026gt; Info an den Agenten -\u0026gt; „Fix das“ -\u0026gt; Ab zum anderen Task -\u0026gt; Push-Notification macht „Pling“ -\u0026gt; Test grün -\u0026gt; Repeat. Ich hatte endlich wieder ein Gefühl von „Flow“. Kein stundenlanges Step-Debugging und Recherche in API-Dokus und Stackoverflow (RIP). \u003cstrong\u003eEnde gut, alles gut?\u003c/strong\u003e\u003c/p\u003e\n\n\u003cp\u003eIm nächsten Schritt wollte ich ganz neue Testklassen einführen. Es gab da noch diese vernachlässigte BDD-Testsuite, die immer ein schlechtes Gewissen erzeugte. Als ich loslegen wollte, hatte ich einen Moment der Klarheit und hielt inne. Wollte ich wirklich ein Tool nutzen, was mir evtl. wieder weggenommen werden kann, wenn die VC-Kohle verbrannt ist, um meine Projektkomplexität zu erhöhen? Sind nicht gerade Ressourcen-Constraints etwas, was uns auf das wirklich Wichtige fokussieren lässt? Ich merkte, dass dieser Arbeitsmodus mental ermüdend ist und zukünftig wieder in genau die gleiche Situation führen kann. \u003cstrong\u003eNur hat man dann noch viel mehr Komplexität zu jonglieren.\u003c/strong\u003e\u003c/p\u003e\n\n\u003ch3 id=\"mehr-ist-mehr-oder\"\u003eMehr ist mehr. Oder?\u003c/h3\u003e\n\n\u003cp\u003eVielleicht konnte sich in der alten Welt mein Gehirn während „stumpfer“ Refactorings wieder mit Problemlösungsenergie aufladen? Ich bin einen Schritt zurückgetreten und habe den Modus radikal geändert. Zusammen mit den Agenten habe ich in wesentlich mehr Iterationen daran gearbeitet, den generierten Code immer weiter zu reduzieren und die Ausdrucksstärke zu erhöhen. Ich habe Agenten meine Architekturentscheidungen challengen lassen und konnte mit durchdachteren Konzepten in die Diskussion mit meinem Team gehen. Ich habe Agenten benutzt, um weniger, aber besseren Code zu erzeugen als vorher. Schließlich muss noch ich den Code noch lesen können, reviewen lassen und die Verantwortung übernehmen. Die Ergebnisse sind besser, und auch die Produktivität ist höher, aber nicht um Größenordnungen.\u003c/p\u003e\n\n\u003cp\u003e\u003cstrong\u003eMehrere fachliche Features parallel zu bauen hat zu höherer mentaler Belastung geführt, und die Ergebnisse wurden nicht besser.\u003c/strong\u003e Also habe ich mir eher mehr Zeit zum Denken verschafft, indem ich mir nervige Blockaden durch Bug-Suchen erspart habe.\u003c/p\u003e\n\n\u003ch3 id=\"divide-and-conquer-der-richtige-einsatz-von-agenten\"\u003eDivide and Conquer: Der richtige Einsatz von Agenten\u003c/h3\u003e\n\n\u003cp\u003eDeshalb dieser Aufruf: Generiert guten fachlichen Code und baut gute, sichere Frameworks mit Agenten, aber nicht beides gleichzeitig. Divide and Conquer! Lauft nicht in die Falle, unendlich viel Boilerplate zu generieren. Dafür sind Frameworks da! Frameworks sind nicht obsolet, sondern werden noch wichtiger als Leitplanke für Agenten. Nicht jeder muss sein eigenes ORM oder seinen Auth-Code viben. Please don’t!\u003c/p\u003e\n\n\u003ch3 id=\"guter-softwareentwickler-vs-guter-programmierer\"\u003eGuter Softwareentwickler vs. guter Programmierer\u003c/h3\u003e\n\n\u003cp\u003eIch glaube, KI macht mich zu einem schlechteren Programmierer, da ich weniger Konzepte parat haben muss. Ich muss sie nur noch bei Bedarf verstehen. Aber will ich ein guter Programmierer sein? Das Produzieren von (viel) Code hat noch nie Probleme gelöst (häufig eher viele erzeugt). Bei Softwareentwicklung ging es noch nie darum, viel Code zu schreiben. Code ist ein Werkzeug, um fachliche Probleme zu lösen. Also nutze ich die Agenten auch lieber dafür ein guter Softwareentwickler und -architekt zu sein. Es wird weiterhin Personen brauchen, die dem Agenten die richtigen Fragen stellen und die Rückfragen korrekt beantworten. Da bin ich dann bei Marx: Maschinen erhöhen die Produktivität, aber es braucht immer die menschliche Arbeit, um letztendlich Wert zu schaffen. Das kann die Maschine nie allein\u003ca href=\"https://www.innoq.com/de/blog/2026/03/agenten-gut-alles-gut/#fn:1\" id=\"fnref:1\" title=\"siehe Fußnote\" class=\"footnote\"\u003e[1]\u003c/a\u003e. Aber sehen das wirklich alle so? Es gibt immer noch Personen, die Entwicklerproduktivität in LOC messen wollen. Ein positiver Ausblick wäre, dass die jetzt durch Unmengen von Code-Slop endlich verstehen könnten, dass das keine gute Idee ist und auch nie eine war.\u003c/p\u003e\n\n\u003cfoot-notes class=\"footnotes\"\u003e\n\n\u003col class=\"footnotes__list\"\u003e\n\n\u003cli id=\"fn:1\"\u003e\n\u003cp\u003e«Gleich jedem andren Bestandteil des konstanten Kapitals schafft die Maschinerie keinen Wert, gibt aber ihren eignen Wert an das Produkt ab, zu dessen Erzeugung sie dient.» https://www.textlog.de/kapital-wertabgabe-produkt.html \u003ca href=\"https://www.innoq.com/de/blog/2026/03/agenten-gut-alles-gut/#fnref:1\" title=\"zurück zum Text\" class=\"reversefootnote\"\u003e ↩︎\u003c/a\u003e\u003c/p\u003e\n\u003c/li\u003e\n\n\u003c/ol\u003e\n\u003c/foot-notes\u003e\n\u003c/body\u003e\u003c/html\u003e\n","image":"https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2000/v1/uploads-production/b1rtsfazv4qz0f0x16opr46w0xb7?_a=BACMTiAE"},{"id":"https://www.innoq.com/de/blog/2026/02/ai-asstance-kurzer-ueberblick-q1-2026/","url":"https://www.innoq.com/de/blog/2026/02/ai-asstance-kurzer-ueberblick-q1-2026/","date_published":"2026-03-06T00:00:00.000+00:00","date_modified":"2026-03-10T15:35:43.687+01:00","author":[{"name":"Sven Johann","url":"https://www.innoq.com/ch/staff/sven-johann/"}],"content_html":"\u003c!DOCTYPE html PUBLIC \"-//W3C//DTD HTML 4.0 Transitional//EN\" \"http://www.w3.org/TR/REC-html40/loose.dtd\"\u003e\n\u003chtml\u003e\u003cbody\u003e\n\u003cp\u003eEs ist die letzten Monate ziemlich leicht geworden, bei AI-assisted Softwareentwicklung den Überblick zu verlieren. Ständig tauchen bei LinkedIn neue Heldentaten auf (“17.000 LoC pro Tag pro Entwickler”), neue Tools wie \u003ca href=\"https://github.com/steveyegge/gastown\"\u003eGas Town\u003c/a\u003e, deren Vorgehen überwältigt oder CEOs, die verkünden, dass man “keine Entwickler mehr braucht” bzw. gleichzeitig andere CEOs, die wiederum verkünden, dass “man mehr Entwickler einstellen will”.\u003c/p\u003e\n\n\u003cp\u003eDas Ende der Programmiersprachen wird verkündet (Erik Meijer) und dann doch wieder mit Constraints eingefangen. Code ist zukünftig kein Artefakt mehr, oder doch? Wenn nein, was ist es dann? Waren kleine “Batch Sizes” nicht lange das Nonplus-Ultra? Kurze Feedback-Loops? Gilt das (zukünftig) noch, ja oder nein? Gibt es denn gar nichts mehr, an dem man sich orientieren kann? Keine stabilen Patterns und Vorgehensweisen, an die neues Wissen angedockt werden kann?\u003c/p\u003e\n\n\u003cp\u003eGibt es schon noch. Bei unserem neusten \u003ca href=\"https://www.case-podcast.org/62-utah-retreat-insights-and-state-of-play-ai-assisted-development\"\u003eCaSE Podcast\u003c/a\u003e hatten \u003ca href=\"https://www.heinrichhartmann.com/\"\u003eHeinrich Hartmann\u003c/a\u003e, Principal SRE bei Zalando und ich letzte Woche das Vergnügen, uns mit \u003ca href=\"https://birgitta.info/\"\u003eBirgitta Boeckeler\u003c/a\u003e dazu auszutauschen. Sie ist Distinguished Engineer bei ThoughtWorks, Expertin fur AI-assisted Software Delivery, Technology Radar Member und auch Teilnehmerin des Anfang Februar statt gefundenen \u003ca href=\"https://www.thoughtworks.com/content/dam/thoughtworks/documents/report/tw_future\"\u003eRetreats in Utah\u003c/a\u003e zur Zukunft der Softwareentwicklung in Zeiten von AI, über das wir auch gesprochen haben und ich hier auch berichten will. Ihr könnt natürlich gerne den 90-minütigen Podcast hören (wir haben nicht alle o.g. Punkte adressieren können). Ich wollte aber zusätzlich einen begleitenden Text jenseits der typischen AI-generierten Zusammenfassung zu schreiben, in dem ich noch ein paar Punkte unterbringen kann, die im Podcast nicht angesprochen wurden bzw. davor oder danach diskutiert wurden und natürlich um noch einmal selbst zu reflektieren :-)\u003c/p\u003e\n\n\u003ch3 id=\"stand-der-ai-assistance-tools-19-februar-2026-19-46-uhr\"\u003eStand der AI Assistance Tools (19. Februar 2026, 19:46 Uhr)\u003c/h3\u003e\n\n\u003cp\u003eWir schreiben den 19. Februar 2026, 19:46 Uhr. Es ist wichtig, diesen Zeitstempel zu nennen, denn die Entwicklung geht rasend schnell. Wir schauen auf die groben wichtigen Entwicklungen. Das Jahr 2025 war ein interessantes Jahr: es gibt wirklich gute Modelle, es gibt Agenten, es gibt CLIs und es gibt Context Engineering. MCP war ziemlich in und ist nun ein kleines bisschen out.\u003c/p\u003e\n\n\u003cp\u003eBei den \u003cstrong\u003eModellen\u003c/strong\u003e können wir uns kurz halten: Dort sind Claude Opus 4.6 und OpenAI GPT-5.3-Codex die Spitzenreiter. Ich persönlich hänge in meinem Umfeld noch auf 5.2 fest, deswegen kann ich keine Aussage zu den neuen Modellen jenseits von Spielzeugsystemen machen, aber im Allgemeinen herrscht Begeisterung, was die Leistungsfähigkeit angeht.\u003c/p\u003e\n\n\u003cp\u003eDie Einführung von Coding \u003cstrong\u003eAgents\u003c/strong\u003e war ein weiterer Meilenstein in 2025. Im Gegensatz zum einfachen Chatfenster innerhalb der IDE können Agenten mehr. Man kann ihnen Ziele geben und sie können im Gegensatz zum Chatfenster nicht nur Code generieren oder analysieren, sondern auch Dateien schreiben, Kommandos ausführen, Tests schreiben und ausführen, Code-Qualitätswerkzeuge aufrufen oder auch Git-Kommandos ausführen. Dadurch ist es möglich, nicht einfach nur im Frage-/Antwort Modus zu arbeiten, sondern konkrete Aufgaben zu vergeben, die iterativ ausgeführt werden können. Man kann auch mehrere \u003cstrong\u003e(Sub-)Agenten\u003c/strong\u003e unterschiedliche Aufgaben ausführen lassen, z.B. einer plant, ein anderer implementiert, wiederum ein anderer testet, usw. Implementierungen können auch gesplittet werden, z.B. Frontend-Subagent und Backend-Subagent.\u003c/p\u003e\n\n\u003cp\u003e\u003cstrong\u003eContext Engineering\u003c/strong\u003e ist die Kuratierung dessen, was das Modell sieht und ist auch eine nennenswerte Entwicklung in 2025. Man muss dem Modell nicht immer die gesamte Codebasis als Kontext mitgeben, denn das führt nicht nur zu erhöhten Kosten, sondern auch zur Degradierung der Antwortqualität. Code ist auch nicht das Einzige, was ein Modell benötigt, um eine Aufgabe gut zu lösen. Zusätzliche nützliche Informationen können Beschreibungen sein, wie man eine Technologie idiomatisch korrekt umsetzt, Coding-Guidelines des Unternehmens oder die zu wählende Konstruktionsoption aus einem Architecture Decision Record. Diese können je nach Tool in dafür vorgesehenen Dateien (z.B. agents.md), slash-commands oder Skills mitgegeben werden. Mit Subagenten kann man die Kontexte für spezielle Aufgaben klein halten und dadurch bessere Resultate erzielen.\u003c/p\u003e\n\n\u003cp\u003eDer Trend, für alles einen eigenen MCP-Server anzubieten, nimmt ab. Stattdessen kann man existierende CLIs nutzen, mit denen die AI inzwischen gut umgehen kann.\u003c/p\u003e\n\n\u003ch3 id=\"you-must-be-this-tall-to-use-microservices-ah-agentic-coding\"\u003e“You must be this tall to use Microservices, äh, Agentic Coding“\u003c/h3\u003e\n\n\u003cp\u003eIhr lest es sicher täglich bei LinkedIn: wer den generierten Code noch reviewed und feinjustiert ist ein Dino und bald ausgestorben. Die Frontsäue lassen große Teile von neuen Funktionalitäten komplett generieren. Software muss zu großen Teilen immer noch in kurzen, kleinen Schritten entwickelt werden, zumindest wenn sie geschäfts- oder sicherheitskritisch ist und im Team entwickelt wird. Es kommt auch darauf an, von wo man startet und wie das Umfeld ist. Die wenigsten Systeme und Organisationen sind heutzutage AI Native. Die Überschrift sagt es schon: so wie bei Martin Fowlers \u003ca href=\"https://martinfowler.com/bliki/MicroservicePrerequisites.html\"\u003eArtikel\u003c/a\u003e, welche Bedingungen gelten müssen um Microservices zu entwickeln und zu betreiben, müssen auch einige Bedingungen erfüllt werden, um AI Agents erfolgreich nutzen zu können.\u003c/p\u003e\n\n\u003ch3 id=\"wo-bleibt-die-prazision-im-hipster-land\"\u003eWo bleibt die Präzision im Hipster-Land?\u003c/h3\u003e\n\n\u003cp\u003eDie Frage, die ich mir und ihr euch und auch die Teilnehmer des o.g. Events in Utah stellen, ist, wie man denn in der Gegenwart, der nahen und fernen Zukunft die Qualität unserer Software sicherstellen kann, wenn man deutlich schneller viel mehr Code erzeugen kann. Jetzt interessiere ich mich eher für das heute und die nahe Zukunft und hier ist es so, dass individuelle Teams auch ihre individuellen Developer-Workflows finden müssen. Wie immer ist es ratsam, klein anzufangen und auszuprobieren was geht und was nicht. Die o.g. Dino-Taktik funktioniert für viele Teams gut und kann inkrementell weiterentwickelt werden. Aber wohin? Wie sieht die State-of-Art aus? Bei Microservices war das Poster-Child Netflix, wer ist es bei AI-assistance?\u003c/p\u003e\n\n\u003cp\u003eOpenAI (und auch andere Firmen wie z.B. Databricks) haben das Ziel, gar keinen Code mehr von Hand zu schreiben und stattdessen alles generieren zu lassen. Aber welche Voraussetzungen müssen gelten, um das sicher in der benötigte Qualität tun zu können? Natürlich, wie immer in komplexen Setups, geht das gut in kleinen, inkrementellen Schritten. Baby-Steps, wie Kent Beck sagen würde. Ein großes komplexes (soziotechnisches) System, welches funktioniert, entsteht immer aus einem kleineren komplexen System, welches funktioniert. OpenAI nutzt z.B. \u003ca href=\"https://openai.com/index/harness-engineering/\"\u003eHarness Engineering\u003c/a\u003e um Präzision sicherzustellen und fokussiert sich auf \u003ca href=\"https://martinfowler.com/articles/exploring-gen-ai/harness-engineering.html\"\u003e3 Säulen\u003c/a\u003e:\u003c/p\u003e\n\n\u003cul\u003e\n\u003cli\u003eContext-Engineering: Kontinuierlich erweiterte Wissensdatenbank im Code sowie Zugriff der Agenten auf dynamische Kontexte wie Monitoringdaten, Browser-Navigation oder ADRs.\u003c/li\u003e\n\u003cli\u003eArchitektureinschränkungen: Überwachung nicht nur durch LLM-basierte Agenten, sondern auch durch deterministische benutzerdefinierte Linter und strukturelle Tests. Wir schreiben Unit Tests, Acceptance Tests und Property-Tests selbst - wir wollen im Driver-Seat sitzen. ArchUnit kann strukturelle Einschränkungen als Test liefern und die Freiheit des Agenten einschränken.\u003c/li\u003e\n\u003cli\u003e„Garbage Collection“: Agenten, die regelmäßig ausgeführt werden, um technische Schulden zu bekämpfen (Agenten replizieren existierende Patterns und wenn diese schlecht sind und man das erkennt, dann muss man das eben bekämpfen).\u003c/li\u003e\n\u003c/ul\u003e\n\n\u003cp\u003eImmer wenn die Resultate nicht gut sind, dann ist das ein Smell und diese Säulen müssen verbessert werden (wie auch bei der Netflix-Microservices-Architektur muss sich jeder vor Conference-Driven Development und Cargo-Culting schützen. Selbst überlegen was im eigenen Kontext richtig ist).\u003c/p\u003e\n\n\u003cp\u003eAber, huch? Die letzten beiden Punkte gelten für gute Software-Entwicklung im Allgemeinen. Hier sehe ich eine einfach zu begehende Rampe für uns alle.\u003c/p\u003e\n\n\u003ch3 id=\"risikodenken\"\u003eRisikodenken\u003c/h3\u003e\n\n\u003cp\u003eAch ja, wieder so etwas, dass im AI Land notwendig ist und in der Software Entwicklung im Allgemeinen äußerst nützlich: Risikodenken. Der Code, den ich gerade entwickeln (oder generieren lassen) will: wieviel Risiko (Wahrscheinlichkeit x Auswirkung) steckt da drin? Brauche ich gerade einen Testdata-Builder oder eine Steuerberechnung? CRUD für Stammdaten oder Atomreaktorsteuerungslogik? Wie groß ist der Blastradius? Schreibe ich für mich privat ein Tool oder ist es ein produktionskritisches System? Wie einfach ist es, einen Fehler im generierten Code zu erkennen? Kann das ein Test oder brauche ich eine qualitative Analyse? Es ist ein ständiger Balanceakt – wie viel Aufsicht man braucht bzw. wie viel Autonomie man gibt, ist abhängig vom Risiko und von den möglichen Feedbackzyklen.\u003c/p\u003e\n\n\u003ch3 id=\"innovatoren-fruhe-und-spate-mehrheit-nachzugler\"\u003eInnovatoren, frühe und späte Mehrheit, Nachzügler\u003c/h3\u003e\n\n\u003cp\u003eEin Problem in sehr vielen Organisationen heutzutage sind Spannungen zwischen Enthusiasten und Skeptikern. Das ist normal. Bei neuen Technologien und Methoden unterscheidet man im allgemeinen zwischen Innovatoren, der frühen Mehrheit, der späten Mehrheit und Nachzüglern. Die meisten Menschen sind je nach Situation in allen diesen Kategorien gleichzeitig vertreten. Ich kann AI-Innovator sein, aber in ganz anderen Bereichen ein Nachzügler und umgekehrt.\u003c/p\u003e\n\n\u003cp\u003eWie kann eine Organisation diese Spannungen positiv nutzen? Wir brauchen beides. Experimentierlust und Vorsicht sind gleichermaßen zu belohnen. Es ist gut, wenn eine Kollegin ein interessantes neues Tool oder eine clevere Methodik ausprobiert und sie in die Entwicklungsteams trägt. Skeptiker sorgen dafür, dass unterschiedliche Entwicklungskontexte beachtet werden und die Technologie/Methode besser eingeordnet werden kann.\u003c/p\u003e\n\n\u003cp\u003eSkeptiker sind nicht immer Nachzügler. Die frühe Mehrheit ist auch erstmal skeptisch und will sehen, dass eine Technologie funktioniert, bevor sie sie nutzt. Innovatoren müssen die frühe Mehrheit überzeugen, sonst geht es nicht weiter.\u003c/p\u003e\n\n\u003cp\u003eNicht zu vernachlässigen ist auch die allgemeine Adoptionsrate. Innovation passiert im Allgemeinen viel, viel langsamer als man denkt. Daher: Nur keine Panik schieben, aber ein Gefühl der Dringlichkeit braucht heute jeder Softwareentwickler.\u003c/p\u003e\n\u003cp\u003eIn diesem Artikel wollte ich eine persönliche Zusammenfassung des Gesprächs zwischen Birgitta, Heinrich und mir zum Stand der AI-assistierten Programmierung geben. Sie ist Anfang 2026 weder Heilsversprechen noch Jobvernichter, sondern kann ein ordentlicher Produktivitätsschub sein. Modelle und Agenten sind mittlerweile leistungsfähig – aber ihre Wirksamkeit hängt von vielen Faktoren ab. Die Einführung und Weiterentwicklung dieser Faktoren sind im Grunde genommen auch vorteilhafte Maßnahmen in der Entwicklung klassischer Softwaresysteme. Kann also nicht schaden agentisch werden zu wollen, nicht wahr?\u003c/p\u003e\n\n\u003cp\u003eDie Grundprinzipien guter Softwareentwicklung gelten zudem weiterhin: kleine Schritte, kurze Feedbackzyklen, Tests, explizite Entscheidungen und bewusstes Risikomanagement. Wer sie ignoriert, erhöht nur die Geschwindigkeit, mit der Fehler entstehen. Wenn man intensiv AI nutzt, wird es nur viel schneller viel schlimmer.\u003c/p\u003e\n\n\u003cp\u003eDer produktive Weg liegt zwischen Euphorie und Skepsis. Wir sollten experimentieren – aber gleichzeitig unser tatsächliches Ziel verfolgen und nicht dem Social Media Druck nachgeben: gute Software entwickeln und betreiben, die ihre Stakeholder glücklich macht.\u003c/p\u003e\n\u003c/body\u003e\u003c/html\u003e\n","image":"https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2000/v1/uploads-production/piyf0gwmyyg5u3ntfifo8qcyfg6v?_a=BACMTiAE"},{"id":"https://www.innoq.com/de/blog/2026/03/jvm-schneller-start/","url":"https://www.innoq.com/de/blog/2026/03/jvm-schneller-start/","date_published":"2026-03-05T00:00:00.000+00:00","date_modified":"2026-03-04T15:23:10.161+01:00","author":[{"name":"Michael Vitz","url":"https://www.innoq.com/ch/staff/michael-vitz/"}],"content_html":"\u003c!DOCTYPE html PUBLIC \"-//W3C//DTD HTML 4.0 Transitional//EN\" \"http://www.w3.org/TR/REC-html40/loose.dtd\"\u003e\n\u003chtml\u003e\u003cbody\u003e\n\u003cp\u003eWenn ich heute mit Nicht-JVM-Menschen über die JVM spreche, dann höre ich häufig zwei Kritikpunkte. Zum einen wird der hohe Arbeitsspeicherbedarf genannt, zum anderen die langsame Startzeit. Der zweite Punkt macht sich umso deutlicher bemerkbar, wenn wir nicht einen modernen Entwicklungsrechner, sondern die in Produktion häufig genutzten kleinen Instanzen betrachten.\u003c/p\u003e\n\n\u003cp\u003eDass beide Punkte mit der Historie der JVM zusammenhängen, soll dabei keine Entschuldigung oder Ausrede sein, sondern ist einfach ein Zeichen für die Zeit, aus der die JVM hervorging. Vor 20 Jahren haben wir wenige, dafür aber größere Anwendungen gebaut und betrieben. Außerdem wurde primär die „Mean Time Between Failures“ optimiert und die Anwendungen liefen oft Monate am Stück. Es gab also wenig Bedarf für eine Optimierung der Startzeit.\u003c/p\u003e\n\n\u003cp\u003eAber natürlich arbeiten die Menschen im OpenJDK daran, beide Punkte zu verbessern. Wie im JVM-Universum üblich, wird das sehr sorgfältig und stets mit dem Blick auf Rückwärtskompatibilität angegangen. Dadurch dauert das in Summe länger, geht aber stetig voran und sorgt bei uns Anwendungsentwickelnden für weniger Frust.\u003c/p\u003e\n\n\u003cp\u003eIn diesem Artikel wollen wir uns deswegen die bereits gemachten Schritte und jene, die noch kommen, anschauen. Doch vorher wollen wir uns einen kurzen Überblick verschaffen, was eigentlich so alles beim Start einer Anwendung auf der JVM passiert.\u003c/p\u003e\n\n\u003ch3 id=\"was-geschieht-beim-start\"\u003eWas geschieht beim Start?\u003c/h3\u003e\n\n\u003cp\u003eNeben dem Auswerten von Programmargumenten und weiteren JVM-Optionen und dem Starten von Komponenten wie dem Garbage Collector verbringt die JVM einen Großteil des Starts damit, die für die Anwendung benötigten Klassen zu laden. Dabei folgt diese den in Kapitel 5 der \u003ca href=\"https://docs.oracle.com/javase/specs/jvms/se24/html/index.html\"\u003eJVM-Spezifikation\u003c/a\u003e definierten Regeln und Anforderungen. Dort ist genau spezifiziert, wie Klassen geladen, gelinkt und initialisiert werden. Das Verhalten ist somit auf allen JVMs identisch, auch wenn die Implementierungen im Detail variieren können.\u003c/p\u003e\n\n\u003cp\u003eFür das Laden von Klassen werden \u003cem\u003eClassLoader\u003c/em\u003e verwendet. Diese sind dabei hierarchisch aufgebaut, das bedeutet, jeder \u003cem\u003eClassLoader\u003c/em\u003e besitzt einen weiteren \u003cem\u003eClassLoader\u003c/em\u003e als Parent. Das Vorgehen ist dabei, dass ein \u003cem\u003eClassLoader\u003c/em\u003e, bevor er selbst eine Klasse lädt, seinen Parent bittet, diese zu laden. Nur wenn diese Bitte nicht erfüllt werden kann, ist es seine Aufgabe, die Klasse zu laden. An der Spitze dieser Hirarchie gibt es den Bootstrap-\u003cem\u003eClassLoader\u003c/em\u003e, der in Kapitel 5.3.1 definiert ist.\u003c/p\u003e\n\n\u003cp\u003eBeim Laden an sich geht es darum, die binäre Repräsentation einer Klasse – das, was in einer \u003cem\u003eclass\u003c/em\u003e-Datei zu finden ist – einzulesen. Anschließend wird daraus die dort definierte Klasse oder das Interface abgeleitet und in die Method Area (in der HotSpot JVM auch Metaspace genannt) geladen. Beim Start der JVM werden nicht alle Klassen automatisch geladen, sondern – ausgehend von der Hauptklasse – nur jene, die tatsächlich benötigt und referenziert werden.\u003c/p\u003e\n\n\u003cp\u003eNach dem Laden muss die Klasse noch gelinkt werden. Dieser Schritt besteht wiederum aus den drei größeren Aufgaben der \u003cstrong\u003eVerifikation\u003c/strong\u003e, \u003cstrong\u003eVorbereitung\u003c/strong\u003e (Preparation) und \u003cstrong\u003eAuflösung\u003c/strong\u003e (Resolution).\u003c/p\u003e\n\n\u003cp\u003eBei der \u003cstrong\u003eVerifikation\u003c/strong\u003e überprüft die JVM die vorher geladene Klasse auf ihre strukturelle Korrektheit. Dabei gilt es, eine ganze Reihe von Dingen zu überprüfen (Kapitel 4.9.1 und 4.9.2 der JVM-Spezifikation). Zusätzlich gilt es sicherzustellen, dass es für eine finale Klasse keine Subklasse gibt und dass finale Methoden nicht überschrieben wurden. Außerdem muss sichergestellt werden, dass alle Klassen außer \u003cem\u003ejava.lang.Object\u003c/em\u003e eine direkte Elternklasse haben. Wird dabei eine nicht valide Klasse gefunden, wird ein \u003cem\u003eVerifyError\u003c/em\u003e geworfen.\u003c/p\u003e\n\n\u003cp\u003eNach der erfolgreichen Verifikation kann die Klasse \u003cstrong\u003evorbereitet\u003c/strong\u003e werden. In diesem Schritt werden sämtliche statischen Felder erzeugt und auf ihren Standardwert gesetzt. So würde ein Feld mit der Deklaration \u003ccode\u003estatic int foo = 42\u003c/code\u003e nach diesem Schritt mit dem Wert \u003ccode\u003e0\u003c/code\u003e initialisiert sein.\u003c/p\u003e\n\n\u003cp\u003eAls Nächstes folgt die \u003cstrong\u003eAuflösung\u003c/strong\u003e. Hierbei werden die symbolischen Referenzen, die in der binären Repräsentation einer Klasse vorhanden sind, aufgelöst. Auch wenn diese drei Unteraufgaben hier nacheinander aufgeführt sind, kann die tatsächliche Reihenfolge der Ausführung abweichen.\u003c/p\u003e\n\n\u003cp\u003eNach dem Linken kann die Klasse initialisiert werden. Dabei werden die deklarierten Werte von statischen Feldern oder Klassenvariablen gesetzt und statische Initializer ausgeführt. Dazu wird die automatisch vom Compiler generierte Methode \u003cem\u003e\u0026lt;clinit\u0026gt;\u003c/em\u003e von der JVM aufgerufen. Diese gibt es jedoch nicht immer, sondern wirklich nur dann, wenn der Bedarf besteht.\u003c/p\u003e\n\n\u003cp\u003eDa die JVM in der Regel mehrere Hundert Klassen laden muss, dauert dieser Prozess mitunter eine Weile. Und somit ist er natürlich auch ein Kandidat, um durch Optimierungen die Startzeit deutlich zu reduzieren. Wie das gelingt, schauen wir uns im Folgenden an.\u003c/p\u003e\n\n\u003ch3 id=\"class-data-sharing\"\u003eClass Data Sharing\u003c/h3\u003e\n\n\u003cp\u003eClass Data Sharing, abgekürzt als \u003cstrong\u003eCDS\u003c/strong\u003e, wurde schon vor langer Zeit mit einem Update für JDK 5 in der HotSpot JVM eingeführt. Die Idee dahinter ist es, dass es eine Reihe von Klassen im JDK gibt wie die aus \u003cem\u003ejava.lang\u003c/em\u003e, die eigentlich jede Anwendung benötigt. Anstatt sie bei jedem Start zu laden, wird bei CDS einmalig ein Archiv erzeugt, in dem diese Klassen fertig geladen liegen. Beim nächsten Start wird das Archiv erkannt und die Klassen werden direkt von dort in den Arbeitsspeicher gepackt. Somit entfällt ein Schritt und die JVM startet schneller. Um dieses Feature zu aktivieren, musste es jedoch lange aktiv angeschaltet werden. Erst mit \u003ca href=\"https://openjdk.org/projects/jdk/12/\"\u003eJDK 12\u003c/a\u003e und \u003ca href=\"https://openjdk.org/jeps/341\"\u003eJEP 341\u003c/a\u003e wurde für CDS eingeführt, dass das Archiv bereits mit im JDK ausgeliefert und beim Start der JVM standardmäßig mitgeladen wird.\u003c/p\u003e\n\n\u003cp\u003eZeitweise war es außerdem möglich, dass mehrere JVMs, die auf demselben System laufen, sich den Speicherbereich dieser Klassen teilen. Somit wurde auch der Speicherverbrauch etwas reduziert. Da das heute aber oft keine Rolle mehr spielt, wird dieser Aspekt nicht mehr primär unterstützt.\u003c/p\u003e\n\n\u003ch3 id=\"application-class-data-sharing\"\u003eApplication Class Data Sharing\u003c/h3\u003e\n\n\u003cp\u003eDurch CDS wurde zwar die Startzeit reduziert, aber gerade bei großen Anwendungen ist der Anteil der Klassen aus dem JDK nur sehr gering, ein Großteil sind von uns selbst geschriebene oder vom genutzten Framework mitgebrachte Klassen. Angesichts dessen wurde mit \u003ca href=\"https://openjdk.org/projects/jdk/10/\"\u003eJDK 10\u003c/a\u003e und \u003ca href=\"https://openjdk.org/jeps/310\"\u003eJEP 310\u003c/a\u003e Application Class Data Sharing (\u003cstrong\u003eAppCDS\u003c/strong\u003e) eingeführt. Im Grunde handelt es sich hierbei um eine Erweiterung von CDS, um neben den JDK-eigenen auch die Klassen der Anwendung mit in das Archiv zu legen. Das geschieht allerdings nicht automatisch, sondern wir müssen das Feature selbst aktiv anschalten und benötigen zudem einen Trainingslauf. Dabei werden die geladenen Klassen erkannt und in eine Datei geschrieben. Mit einem zweiten Lauf kann aus dieser Liste dann ein Archiv mit den geladenen Klassen erzeugt werden.\u003c/p\u003e\n\n\u003cp\u003eFür den Trainingslauf nutzen wir die Optionen \u003ccode\u003e-Xshare:off\u003c/code\u003e und \u003ccode\u003e-XX:DumpLoadedClassList=./application.lst\u003c/code\u003e. Bei älteren JDKs muss zudem noch die Option \u003ccode\u003e-XX:+UseAppCDS\u003c/code\u003e gesetzt werden. Abhängig von der Anwendung können wir diese direkt nach dem Start wieder beenden oder vorher noch Aktionen ausführen, damit die Anwendung wirklich alle Klassen lädt. Beim Beenden der JVM schreibt diese die Liste aller geladener Klassen in die angegebene Datei (Listing 1).\u003c/p\u003e\n\n\u003cfigure\u003e\u003cdiv class=\"highlight\" title=\"Listing 1: Liste der geladenen Klassen nach dem Trainingslauf\"\u003e\u003cpre class=\"\"\u003e\u003ccode\u003e# NOTE: Do not modify this file.\r\n#\r\n# This file is generated via the -XX:DumpLoadedClassList=\u0026lt;class_list_file\u0026gt; option\r\n# and is used at CDS archive dump time (see -Xshare:dump).\r\n#\r\njava/lang/Object id: 0\r\njava/io/Serializable id: 1\r\njava/lang/Comparable id: 2\r\njava/lang/CharSequence id: 3\r\njava/lang/constant/Constable id: 4\r\n...\r\norg/springframework/util/ConcurrentReferenceHashMap$EntrySet id: 5293\r\norg/springframework/util/ConcurrentReferenceHashMap$EntryIterator id: 5294\u003c/code\u003e\u003c/pre\u003e\u003c/div\u003e\n\u003cfigcaption\u003eListing 1: Liste der geladenen Klassen nach dem Trainingslauf\u003c/figcaption\u003e\u003c/figure\u003e\n\n\u003cp\u003eDiese Liste können wir nun nutzen, um mit den Optionen \u003ccode\u003e-Xshare:dump\u003c/code\u003e, \u003ccode\u003e-XX:SharedClassListFile=./application.lst\u003c/code\u003e und \u003ccode\u003e-XX:SharedArchiveFile=./application.jsa\u003c/code\u003e daraus ein statisches Archiv mit den geladenen Klassen zu erzeugen. Das Archiv kann beim Starten der Anwendung mit der Option \u003ccode\u003e-XX:SharedArchiveFile=./application.jsa\u003c/code\u003e referenziert werden. Die JVM wird nun eben nicht nur wie mit CDS die JDK-eigenen Klassen direkt in den Arbeitsspeicher legen, sondern eben auch die Klassen der Anwendung. Somit verringert sich die Startzeit der Anwendung noch einmal deutlich.\u003c/p\u003e\n\n\u003cp\u003eUm die Nutzung von AppCDS weiter zu vereinfachen, wurden in \u003ca href=\"https://openjdk.org/projects/jdk/13/\"\u003eJDK 13\u003c/a\u003e mit \u003ca href=\"https://openjdk.org/jeps/350\"\u003eJEP 350\u003c/a\u003e dynamische Archive eingeführt. Um ein solches zu erstellen, nutzen wir beim Trainingslauf nur noch die Option \u003ccode\u003e-XX:ArchiveClassesAtExit=./application.jsa\u003c/code\u003e. Dadurch wird das fertige Archiv direkt im Trainingslauf erzeugt. Wir sparen uns somit das Erzeugen der Klassenliste und deren separate Umwandlung in das Archiv.\u003c/p\u003e\n\n\u003cp\u003eDamit das alles funktioniert, gibt es allerdings zwei kleine Einschränkungen. Zum einen muss der Classpath, inklusive Reihenfolge, zwischen dem Trainingslauf und dem eigentlichen Start identisch sein, und zum zweiten muss dasselbe JDK genutzt werden. Zum Glück sind beide Bedingungen bei der Nutzung von Containern leicht umzusetzen, beispielsweise mit einem Multi-Stage Dockerfile, wie es in Listing 2 zu sehen ist.\u003c/p\u003e\n\n\u003cfigure\u003e\u003cdiv class=\"highlight\" title=\"Listing 2: Multi-Stage Dockerfile für AppCDS einer Spring-Boot-Anwendung\"\u003e\u003cpre class=\"\"\u003e\u003ccode\u003e\u003cspan class=\"k\"\u003eFROM\u003c/span\u003e\u003cspan class=\"w\"\u003e \u003c/span\u003e\u003cspan class=\"s\"\u003eopenjdk:24-slim\u003c/span\u003e\u003cspan class=\"w\"\u003e \u003c/span\u003e\u003cspan class=\"k\"\u003eAS\u003c/span\u003e\u003cspan class=\"w\"\u003e \u003c/span\u003e\u003cspan class=\"s\"\u003ebuilder\r\u003c/span\u003e\n\r\n\u003cspan class=\"k\"\u003eRUN \u003c/span\u003e\u003cspan class=\"nb\"\u003emkdir\u003c/span\u003e \u003cspan class=\"nt\"\u003e-p\u003c/span\u003e /app\r\n\u003cspan class=\"k\"\u003eWORKDIR\u003c/span\u003e\u003cspan class=\"s\"\u003e /app\r\u003c/span\u003e\n\r\n\u003cspan class=\"k\"\u003eCOPY\u003c/span\u003e\u003cspan class=\"s\"\u003e ./target/jvm-startup.jar jvm-startup.jar\r\u003c/span\u003e\n\r\n\u003cspan class=\"k\"\u003eRUN \u003c/span\u003ejava \u003cspan class=\"nt\"\u003e-Djarmode\u003c/span\u003e\u003cspan class=\"o\"\u003e=\u003c/span\u003etools \u003cspan class=\"nt\"\u003e-jar\u003c/span\u003e jvm-startup.jar extract \u003cspan class=\"se\"\u003e\\\r\u003c/span\u003e\n    --layers\r\n\r\n\r\n\u003cspan class=\"k\"\u003eFROM\u003c/span\u003e\u003cspan class=\"s\"\u003e openjdk:24-slim\r\u003c/span\u003e\n\r\n\u003cspan class=\"k\"\u003eCMD\u003c/span\u003e\u003cspan class=\"s\"\u003e [ \"java\", \\\r\u003c/span\u003e\n      \"-XX:SharedArchiveFile=./application.jsa\", \\\r\n      \"-jar\", \\\r\n      \"jvm-startup.jar\"]\r\n\r\n\u003cspan class=\"k\"\u003eRUN \u003c/span\u003e\u003cspan class=\"nb\"\u003emkdir\u003c/span\u003e \u003cspan class=\"nt\"\u003e-p\u003c/span\u003e /app \u003cspan class=\"o\"\u003e\u0026amp;\u0026amp;\u003c/span\u003e \u003cspan class=\"se\"\u003e\\\r\u003c/span\u003e\n    chown -R daemon /app\r\n\r\n\u003cspan class=\"k\"\u003eUSER\u003c/span\u003e\u003cspan class=\"s\"\u003e daemon\r\u003c/span\u003e\n\u003cspan class=\"k\"\u003eWORKDIR\u003c/span\u003e\u003cspan class=\"s\"\u003e /app\r\u003c/span\u003e\n\r\n\u003cspan class=\"k\"\u003eCOPY\u003c/span\u003e\u003cspan class=\"s\"\u003e --from=builder /app/jvm-startup/dependencies/ ./\r\u003c/span\u003e\n\u003cspan class=\"k\"\u003eCOPY\u003c/span\u003e\u003cspan class=\"s\"\u003e --from=builder /app/jvm-startup/spring-boot-loader/ ./\r\u003c/span\u003e\n\u003cspan class=\"k\"\u003eCOPY\u003c/span\u003e\u003cspan class=\"s\"\u003e --from=builder /app/jvm-startup/snapshot-dependencies/ ./\r\u003c/span\u003e\n\u003cspan class=\"k\"\u003eCOPY\u003c/span\u003e\u003cspan class=\"s\"\u003e --from=builder /app/jvm-startup/application/ ./\r\u003c/span\u003e\n\r\n\u003cspan class=\"k\"\u003eRUN \u003c/span\u003ejava \u003cspan class=\"se\"\u003e\\\r\u003c/span\u003e\n    -Dspring.context.exit=onRefresh \\\r\n    -XX:ArchiveClassesAtExit=./application.jsa \\\r\n    -jar jvm-startup.jar\u003c/code\u003e\u003c/pre\u003e\u003c/div\u003e\n\u003cfigcaption\u003eListing 2: Multi-Stage Dockerfile für AppCDS einer Spring-Boot-Anwendung\u003c/figcaption\u003e\u003c/figure\u003e\n\n\u003cp\u003eDa es sich im Beispiel um eine Spring-Boot-Anwendung handelt, besteht der erste Trick darin, das Executable-JAR zu entpacken. Hierzu nutzen wir die im JAR enthaltenen jarmode-Tools und das Kommando \u003cem\u003eextract\u003c/em\u003e mit der Option \u003cem\u003e–layers\u003c/em\u003e in der \u003cstrong\u003eersten Stage\u003c/strong\u003e. Dadurch entsteht die Listing 3 gezeigte Struktur.\u003c/p\u003e\n\n\u003cfigure\u003e\u003cdiv class=\"highlight\" title=\"Listing 3: Struktur der entpackten Spring-Boot-Anwendung\"\u003e\u003cpre class=\"\"\u003e\u003ccode\u003e\u003cspan class=\"nv\"\u003e$ \u003c/span\u003etree jvm-startup\r\njvm-startup\r\n├── application\r\n│   └── jvm-startup.jar\r\n├── dependencies\r\n│   └── lib\r\n│       ├── jackson-annotations-2.19.2.jar\r\n│       ├── jackson-core-2.19.2.jar\r\n...\r\n│       ├── tomcat-embed-el-10.1.43.jar\r\n│       └── tomcat-embed-websocket-10.1.43.jar\r\n├── snapshot-dependencies\r\n└── spring-boot-loader\r\n\r\n6 directories, 31 files\u003c/code\u003e\u003c/pre\u003e\u003c/div\u003e\n\u003cfigcaption\u003eListing 3: Struktur der entpackten Spring-Boot-Anwendung\u003c/figcaption\u003e\u003c/figure\u003e\n\n\u003cp\u003eIn der \u003cstrong\u003ezweiten Stage\u003c/strong\u003e kopieren wir nun die Struktur aus der ersten in unser Image und starten anschließen mit \u003ccode\u003eRUN\u003c/code\u003e den Trainingslauf, um das AppCDS-Archiv zu erzeugen. Hierzu nutzen wir die Option \u003ccode\u003e-Dspring.context.exit=onRefresh\u003c/code\u003e. Sie sorgt dafür, dass die Anwendung automatisch heruntergefahren wird, nachdem der Spring-Kontext aufgebaut und geladen wurde. An dieser Stelle sind bereits die meisten Klassen geladen und befinden sich nun erfolgreich im Archiv.\u003c/p\u003e\n\n\u003cp\u003eMit \u003ca href=\"https://openjdk.org/projects/jdk/19/\"\u003eJDK 19\u003c/a\u003e wurde in \u003ca href=\"https://bugs.openjdk.org/browse/JDK-8261455\"\u003eJDK-8261455\u003c/a\u003e zudem die Option \u003ccode\u003e-XX:+AutoCreateSharedArchive\u003c/code\u003e hinzugefügt. Nutzen wir diese in Verbindung mit \u003ccode\u003e-XX:SharedArchiveFile\u003c/code\u003e wird, wenn kein Archiv vorhanden ist, beim Beenden der JVM eines geschrieben, und falls ein Archiv vorhanden ist, wird es genutzt.\u003c/p\u003e\n\n\u003ch3 id=\"project-leyden\"\u003eProject Leyden\u003c/h3\u003e\n\n\u003cp\u003eInnerhalb des OpenJDK werden größere Bemühungen in separaten Projekten umgesetzt. Eines davon ist \u003cstrong\u003e\u003ca href=\"https://openjdk.org/projects/leyden/\"\u003eLeyden\u003c/a\u003e\u003c/strong\u003e. Sein Ziel besteht darin, die Startzeit, die Zeit bis zur Peak-Performance und den Fußabdruck der JVM zu verringern. Wie für OpenJDK-Projekte üblich, geschieht das nicht in einem riesigen Wurf, sondern als eine Reihe kleinerer JEPs, durch die man sich Schritt für Schritt dem großen Ziel annähert.\u003c/p\u003e\n\n\u003cp\u003eIn diesem Rahmen hat Projekt Leyden bereits im \u003ca href=\"https://openjdk.org/projects/jdk/24/\"\u003eJDK 24\u003c/a\u003e mit dem \u003ca href=\"https://openjdk.org/jeps/483\"\u003eJEP 483\u003c/a\u003e ein erstes Feature geliefert. Es baut auf den Schultern von CDS bzw. AppCDS auf und verringert die Startzeit damit erneut ein ganzes Stück. Hierzu wird nicht mehr nur die binäre Repräsentation der Klassen der Anwendung direkt in den Arbeitsspeicher geladen, sondern auch der Schritt des Linkens wird mit im Archiv abgelegt. Ähnlich wie AppCDS müssen wir hierzu allerdings auch einen Trainingslauf durchführen, um die benötigten Daten aufzuzeichnen. Hierzu wird die Anwendung mit den beiden Optionen \u003ccode\u003e-XX:AOTMode=record\u003c/code\u003e und \u003ccode\u003e-XX:AOTConfiguration=./application.aotconf\u003c/code\u003e ausgeführt und anschließend beendet.\u003c/p\u003e\n\n\u003cp\u003eDie so geschriebene Konfiguration müssen wir noch mit einem zweiten Aufruf in das eigentliche Archiv konvertieren. Hierzu müssen drei weitere Optionen, nämlich \u003ccode\u003e-XX:AOTMode=create\u003c/code\u003e, \u003ccode\u003e-XX:AOTConfiguration=./application.aotconf\u003c/code\u003e und \u003ccode\u003e-XX:AOTCache=./application.aot\u003c/code\u003e gesetzt werden.\u003c/p\u003e\n\n\u003cp\u003eAnschließend lässt sich das so erzeugte Archiv beim Start der Anwendung mit der Option \u003ccode\u003e-XX:AOTCache=./application.aot\u003c/code\u003e nutzen. In Listing 4 ist ein hierfür nutzbares Multi-Stage Dockerfile zu sehen.\u003c/p\u003e\n\n\u003cfigure\u003e\u003cdiv class=\"highlight\" title=\"Listing 4: Multi-Stage Dockerfile für­Leyden AOT einer Spring-Boot-Anwendung mit JDK 24\"\u003e\u003cpre class=\"\"\u003e\u003ccode\u003e\u003cspan class=\"k\"\u003eFROM\u003c/span\u003e\u003cspan class=\"w\"\u003e \u003c/span\u003e\u003cspan class=\"s\"\u003eopenjdk:24-slim\u003c/span\u003e\u003cspan class=\"w\"\u003e \u003c/span\u003e\u003cspan class=\"k\"\u003eAS\u003c/span\u003e\u003cspan class=\"w\"\u003e \u003c/span\u003e\u003cspan class=\"s\"\u003ebuilder\r\u003c/span\u003e\n\r\n\u003cspan class=\"k\"\u003eRUN \u003c/span\u003e\u003cspan class=\"nb\"\u003emkdir\u003c/span\u003e \u003cspan class=\"nt\"\u003e-p\u003c/span\u003e /app\r\n\u003cspan class=\"k\"\u003eWORKDIR\u003c/span\u003e\u003cspan class=\"s\"\u003e /app\r\u003c/span\u003e\n\r\n\u003cspan class=\"k\"\u003eCOPY\u003c/span\u003e\u003cspan class=\"s\"\u003e ./target/jvm-startup.jar jvm-startup.jar\r\u003c/span\u003e\n\r\n\u003cspan class=\"k\"\u003eRUN \u003c/span\u003ejava \u003cspan class=\"nt\"\u003e-Djarmode\u003c/span\u003e\u003cspan class=\"o\"\u003e=\u003c/span\u003etools \u003cspan class=\"nt\"\u003e-jar\u003c/span\u003e jvm-startup.jar extract \u003cspan class=\"se\"\u003e\\\r\u003c/span\u003e\n    --layers\r\n\r\n\r\n\u003cspan class=\"k\"\u003eFROM\u003c/span\u003e\u003cspan class=\"s\"\u003e openjdk:24-slim\r\u003c/span\u003e\n\r\n\u003cspan class=\"k\"\u003eCMD\u003c/span\u003e\u003cspan class=\"s\"\u003e [ \"java\", \\\r\u003c/span\u003e\n      \"-XX:AOTCache=./application.aot\", \\\r\n      \"-jar\", \\\r\n      \"jvm-startup.jar\"]\r\n\r\n\u003cspan class=\"k\"\u003eRUN \u003c/span\u003e\u003cspan class=\"nb\"\u003emkdir\u003c/span\u003e \u003cspan class=\"nt\"\u003e-p\u003c/span\u003e /app \u003cspan class=\"o\"\u003e\u0026amp;\u0026amp;\u003c/span\u003e \u003cspan class=\"se\"\u003e\\\r\u003c/span\u003e\n    chown -R daemon /app\r\n\r\n\u003cspan class=\"k\"\u003eUSER\u003c/span\u003e\u003cspan class=\"s\"\u003e daemon\r\u003c/span\u003e\n\u003cspan class=\"k\"\u003eWORKDIR\u003c/span\u003e\u003cspan class=\"s\"\u003e /app\r\u003c/span\u003e\n\r\n\u003cspan class=\"k\"\u003eCOPY\u003c/span\u003e\u003cspan class=\"s\"\u003e --from=builder /app/jvm-startup/dependencies/ ./\r\u003c/span\u003e\n\u003cspan class=\"k\"\u003eCOPY\u003c/span\u003e\u003cspan class=\"s\"\u003e --from=builder /app/jvm-startup/spring-boot-loader/ ./\r\u003c/span\u003e\n\u003cspan class=\"k\"\u003eCOPY\u003c/span\u003e\u003cspan class=\"s\"\u003e --from=builder /app/jvm-startup/snapshot-dependencies/ ./\r\u003c/span\u003e\n\u003cspan class=\"k\"\u003eCOPY\u003c/span\u003e\u003cspan class=\"s\"\u003e --from=builder /app/jvm-startup/application/ ./\r\u003c/span\u003e\n\r\n\u003cspan class=\"k\"\u003eRUN \u003c/span\u003ejava \u003cspan class=\"se\"\u003e\\\r\u003c/span\u003e\n    -Dspring.context.exit=onRefresh \\\r\n    -XX:AOTMode=record -XX:AOTConfiguration=./application.aotconf \\\r\n    -jar jvm-startup.jar\r\n\r\n\u003cspan class=\"k\"\u003eRUN \u003c/span\u003ejava \u003cspan class=\"se\"\u003e\\\r\u003c/span\u003e\n    -XX:AOTMode=create -XX:AOTConfiguration=./application.aotconf\r\n    -XX:AOTCache=./application.aot \\\r\n    -jar jvm-startup.jar\u003c/code\u003e\u003c/pre\u003e\u003c/div\u003e\n\u003cfigcaption\u003eListing 4: Multi-Stage Dockerfile für­Leyden AOT einer Spring-Boot-Anwendung mit JDK 24\u003c/figcaption\u003e\u003c/figure\u003e\n\n\u003cp\u003eIn \u003ca href=\"https://openjdk.org/projects/jdk/25/\"\u003eJDK 25\u003c/a\u003e wird dieses Feature durch zwei weitere JEPs, \u003ca href=\"https://openjdk.org/jeps/514\"\u003e514\u003c/a\u003e und \u003ca href=\"https://openjdk.org/jeps/515\"\u003e515\u003c/a\u003e, erweitert.\u003c/p\u003e\n\n\u003cp\u003eJEP 514 optimiert dabei die Benutzung des Features und die benötigten Optionen, ähnlich wie bei AppCDS. Wir brauchen damit nur noch einen Trainingslauf, um direkt das Archiv zu erzeugen. Der Zwischenschritt über die Konfiguration entfällt. Es wird nur noch die Option \u003ccode\u003e-XX:AOTCacheOutput=./application.aot\u003c/code\u003e benötigt.\u003c/p\u003e\n\n\u003cp\u003eMit JEP 515 wird zusätzlich dafür gesorgt, dass während des Trainingslaufs aufgezeichnete Informationen über Methoden mit in das Archiv geschrieben werden. Hierdurch kann die JVM beim erneuten Lauf früher feststellen, welche Methoden der JIT-Compiler wie optimieren kann. Somit wird die Methode deutlich früher beispielsweise in Maschinencode übersetzt und weniger oft von der JVM selbst interpretiert – und die Anwendung erreicht deutlich schneller ihre Peak-Performance. Selbstverständlich werden trotzdem weiterhin Profilinginformationen aufgezeichnet, schließlich kann sich der reale Workload von dem des Trainingslaufes unterscheiden. Somit kann die JVM zur richtigen Laufzeit immer noch weitere Optimierungen vornehmen oder alte verwerfen.\u003c/p\u003e\n\n\u003cp\u003eDarüber hinaus gibt es im aktuellen \u003ca href=\"https://github.com/openjdk/leyden/blob/leyden-ea1-release-notes/README.md\"\u003eEarly-Access-Release\u003c/a\u003e von Projekt Leyden bereits weitere Features, die es in Zukunft vermutlich als JEPs mit ins JDK schaffen werden. Dazu zählt vor allem, weitere Dinge mit in das Archiv zu packen, um noch mehr Arbeit bereits vor dem eigentlichen Start der Anwendung zu erledigen. Hierzu zählt das Erzeugen von Dynamic Proxies, Informationen über Zugriffe per Reflection und sogar beim Trainingslauf bereits vom JIT kompilierten Code mit in das Archiv zu legen. Außerdem ist mit \u003ca href=\"https://openjdk.org/jeps/516\"\u003eJEP 516\u003c/a\u003e bereits ein JEP in Vorbereitung, das die Unterstützung der bisherigen Features mit allen Garbage Collectors sicherstellen soll.\u003c/p\u003e\n\n\u003ch3 id=\"coordinated-restore-at-checkpoint\"\u003eCoordinated Restore at Checkpoint\u003c/h3\u003e\n\n\u003cp\u003eNeben Projekt Leyden gibt es aktuell noch ein zweites Projekt, dass sich mit der Optimierung von Startzeiten beschäftigt, nämlich \u003cstrong\u003e\u003ca href=\"https://openjdk.org/projects/crac/\"\u003eProjekt CRaC\u003c/a\u003e\u003c/strong\u003e. Es verfolgt einen vollkommen anderen Weg, nämlich die Unterstützung sogenannter Checkpoints. Daher kommt auch der Name des Projektes: CRaC ist die Abkürzung von Coordinated Restore at Checkpoint.\u003c/p\u003e\n\n\u003cp\u003eDie Idee ist, dass ein Signal an eine laufende JVM-Anwendung geschickt werden kann, um einen Checkpoint zu erzeugen. Ein Checkpoint ist dabei eine Art Image oder Snapshot der laufenden Anwendung zum Zeitpunkt des Signals. Darin ist der gesamte Zustand der Anwendung vorhanden und nicht nur, wie in den vorherigen Ansätzen, Metadaten. Somit sind auch Dinge wie die Datenbankverbindungen enthalten. Das ist natürlich nicht wirklich praktisch, denn es würde bedeuten, dass ich zum Erzeugen des Checkpoints zwangsläufig bereits mit der richtigen Datenbank verbunden sein müsste. Deshalb ist eine der Aufgaben des Projektes, ein Java API zu entwickeln, mit dem die Anwendung auf das Checkpoint-Signal reagieren und Aufräumarbeiten durchführen kann. Außerdem wird dann für das Restore auch ein API benötigt, um beim Start aus so einem Checkpoint den Zustand wiederherzustellen. Der aktuelle Stand des API ist in Listing 5 zu sehen.\u003c/p\u003e\n\n\u003cfigure\u003e\u003cdiv class=\"highlight\" title=\"Listing 5: CRaC Java API\"\u003e\u003cpre class=\"\"\u003e\u003ccode\u003e\u003cspan class=\"kd\"\u003epublic\u003c/span\u003e \u003cspan class=\"kd\"\u003eclass\u003c/span\u003e \u003cspan class=\"nc\"\u003eSomeResource\u003c/span\u003e \u003cspan class=\"kd\"\u003eimplements\u003c/span\u003e \u003cspan class=\"nc\"\u003eResource\u003c/span\u003e \u003cspan class=\"o\"\u003e{\u003c/span\u003e\r\n\r\n    \u003cspan class=\"kd\"\u003epublic\u003c/span\u003e \u003cspan class=\"nf\"\u003eSomeResource\u003c/span\u003e\u003cspan class=\"o\"\u003e()\u003c/span\u003e \u003cspan class=\"o\"\u003e{\u003c/span\u003e\r\n        \u003cspan class=\"nc\"\u003eCore\u003c/span\u003e\u003cspan class=\"o\"\u003e.\u003c/span\u003e\u003cspan class=\"na\"\u003egetGlobalContext\u003c/span\u003e\u003cspan class=\"o\"\u003e().\u003c/span\u003e\u003cspan class=\"na\"\u003eregister\u003c/span\u003e\u003cspan class=\"o\"\u003e(\u003c/span\u003e\u003cspan class=\"nc\"\u003eSomeResource\u003c/span\u003e\u003cspan class=\"o\"\u003e.\u003c/span\u003e\u003cspan class=\"na\"\u003ethis\u003c/span\u003e\u003cspan class=\"o\"\u003e);\u003c/span\u003e\r\n    \u003cspan class=\"o\"\u003e}\u003c/span\u003e\r\n\r\n    \u003cspan class=\"nd\"\u003e@Override\u003c/span\u003e\r\n    \u003cspan class=\"kd\"\u003epublic\u003c/span\u003e \u003cspan class=\"kt\"\u003evoid\u003c/span\u003e \u003cspan class=\"nf\"\u003ebeforeCheckpoint\u003c/span\u003e\u003cspan class=\"o\"\u003e(\u003c/span\u003e\r\n            \u003cspan class=\"nc\"\u003eContext\u003c/span\u003e\u003cspan class=\"o\"\u003e\u0026lt;?\u003c/span\u003e \u003cspan class=\"kd\"\u003eextends\u003c/span\u003e \u003cspan class=\"nc\"\u003eResource\u003c/span\u003e\u003cspan class=\"o\"\u003e\u0026gt;\u003c/span\u003e \u003cspan class=\"n\"\u003econtext\u003c/span\u003e\u003cspan class=\"o\"\u003e)\u003c/span\u003e \u003cspan class=\"kd\"\u003ethrows\u003c/span\u003e \u003cspan class=\"nc\"\u003eException\u003c/span\u003e \u003cspan class=\"o\"\u003e{\u003c/span\u003e\r\n        \u003cspan class=\"nc\"\u003eSystem\u003c/span\u003e\u003cspan class=\"o\"\u003e.\u003c/span\u003e\u003cspan class=\"na\"\u003eout\u003c/span\u003e\u003cspan class=\"o\"\u003e.\u003c/span\u003e\u003cspan class=\"na\"\u003eprintln\u003c/span\u003e\u003cspan class=\"o\"\u003e(\u003c/span\u003e\u003cspan class=\"s\"\u003e\"Before Checkpointing\"\u003c/span\u003e\u003cspan class=\"o\"\u003e);\u003c/span\u003e\r\n    \u003cspan class=\"o\"\u003e}\u003c/span\u003e\r\n\r\n    \u003cspan class=\"nd\"\u003e@Override\u003c/span\u003e\r\n    \u003cspan class=\"kd\"\u003epublic\u003c/span\u003e \u003cspan class=\"kt\"\u003evoid\u003c/span\u003e \u003cspan class=\"nf\"\u003eafterRestore\u003c/span\u003e\u003cspan class=\"o\"\u003e(\u003c/span\u003e\r\n            \u003cspan class=\"nc\"\u003eContext\u003c/span\u003e\u003cspan class=\"o\"\u003e\u0026lt;?\u003c/span\u003e \u003cspan class=\"kd\"\u003eextends\u003c/span\u003e \u003cspan class=\"nc\"\u003eResource\u003c/span\u003e\u003cspan class=\"o\"\u003e\u0026gt;\u003c/span\u003e \u003cspan class=\"n\"\u003econtext\u003c/span\u003e\u003cspan class=\"o\"\u003e)\u003c/span\u003e \u003cspan class=\"kd\"\u003ethrows\u003c/span\u003e \u003cspan class=\"nc\"\u003eException\u003c/span\u003e \u003cspan class=\"o\"\u003e{\u003c/span\u003e\r\n        \u003cspan class=\"nc\"\u003eSystem\u003c/span\u003e\u003cspan class=\"o\"\u003e.\u003c/span\u003e\u003cspan class=\"na\"\u003eout\u003c/span\u003e\u003cspan class=\"o\"\u003e.\u003c/span\u003e\u003cspan class=\"na\"\u003eprintln\u003c/span\u003e\u003cspan class=\"o\"\u003e(\u003c/span\u003e\u003cspan class=\"s\"\u003e\"After Checkpointing\"\u003c/span\u003e\u003cspan class=\"o\"\u003e);\u003c/span\u003e\r\n    \u003cspan class=\"o\"\u003e}\u003c/span\u003e\r\n\u003cspan class=\"o\"\u003e}\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\u003c/div\u003e\n\u003cfigcaption\u003eListing 5: CRaC Java API\u003c/figcaption\u003e\u003c/figure\u003e\n\n\u003cp\u003eIm Grunde besteht das zu implementierende API aus dem Interface \u003cem\u003eResource\u003c/em\u003e. Es enthält zwei Methoden, die es ermöglichen, Dinge beim Erstellen des Checkpoints und vor dem Wiederherstellen aus einem Snapshot auszuführen. Außerdem müssen wir die Implementierung noch im globalen Kontext registrieren, damit die Methoden an den passenden Stellen von der JVM aufgerufen werden.\u003c/p\u003e\n\n\u003cp\u003eAktuell ist das Erzeugen eines solchen Snapshots noch relativ kompliziert und nicht so einfach automatisierbar. Basierend auf einer Spring-Boot-Anwendung und dem Dockerfile aus Listing 6 gelingt das mit den folgenden Schritten.\u003c/p\u003e\n\n\u003cfigure\u003e\u003cdiv class=\"highlight\" title=\"Listing 6: Dockerfile für CraC\"\u003e\u003cpre class=\"\"\u003e\u003ccode\u003e\u003cspan class=\"k\"\u003eFROM\u003c/span\u003e\u003cspan class=\"w\"\u003e \u003c/span\u003e\u003cspan class=\"s\"\u003ebellsoft/liberica-runtime-container:jdk-21-crac-glibc\u003c/span\u003e\u003cspan class=\"w\"\u003e \u003c/span\u003e\u003cspan class=\"k\"\u003eAS\u003c/span\u003e\u003cspan class=\"w\"\u003e \u003c/span\u003e\u003cspan class=\"s\"\u003ebuilder\r\u003c/span\u003e\n\r\n\u003cspan class=\"k\"\u003eRUN \u003c/span\u003e\u003cspan class=\"nb\"\u003emkdir\u003c/span\u003e \u003cspan class=\"nt\"\u003e-p\u003c/span\u003e /app\r\n\u003cspan class=\"k\"\u003eWORKDIR\u003c/span\u003e\u003cspan class=\"s\"\u003e /app\r\u003c/span\u003e\n\r\n\u003cspan class=\"k\"\u003eCOPY\u003c/span\u003e\u003cspan class=\"s\"\u003e ./target/jvm-startup.jar jvm-startup.jar\r\u003c/span\u003e\n\r\n\u003cspan class=\"k\"\u003eRUN \u003c/span\u003ejava \u003cspan class=\"nt\"\u003e-Djarmode\u003c/span\u003e\u003cspan class=\"o\"\u003e=\u003c/span\u003etools \u003cspan class=\"nt\"\u003e-jar\u003c/span\u003e jvm-startup.jar extract \u003cspan class=\"se\"\u003e\\\r\u003c/span\u003e\n    --layers\r\n\r\n\r\n\u003cspan class=\"k\"\u003eFROM\u003c/span\u003e\u003cspan class=\"s\"\u003e bellsoft/liberica-runtime-container:jdk-21-crac-glibc\r\u003c/span\u003e\n\r\n\u003cspan class=\"k\"\u003eCMD\u003c/span\u003e\u003cspan class=\"s\"\u003e [ \"java\", \\\r\u003c/span\u003e\n      \"-XX:CRaCRestoreFrom=./crac-image/\", \\\r\n      \"-jar\", \\\r\n      \"jvm-startup.jar\"]\r\n\r\n\u003cspan class=\"k\"\u003eRUN \u003c/span\u003e\u003cspan class=\"nb\"\u003emkdir\u003c/span\u003e \u003cspan class=\"nt\"\u003e-p\u003c/span\u003e /app \u003cspan class=\"o\"\u003e\u0026amp;\u0026amp;\u003c/span\u003e \u003cspan class=\"se\"\u003e\\\r\u003c/span\u003e\n    chown -R daemon /app\r\n\r\n\u003cspan class=\"k\"\u003eUSER\u003c/span\u003e\u003cspan class=\"s\"\u003e daemon\r\u003c/span\u003e\n\u003cspan class=\"k\"\u003eWORKDIR\u003c/span\u003e\u003cspan class=\"s\"\u003e /app\r\u003c/span\u003e\n\r\n\u003cspan class=\"k\"\u003eCOPY\u003c/span\u003e\u003cspan class=\"s\"\u003e --from=builder /app/jvm-startup/dependencies/ ./\r\u003c/span\u003e\n\u003cspan class=\"k\"\u003eCOPY\u003c/span\u003e\u003cspan class=\"s\"\u003e --from=builder /app/jvm-startup/spring-boot-loader/ ./\r\u003c/span\u003e\n\u003cspan class=\"k\"\u003eCOPY\u003c/span\u003e\u003cspan class=\"s\"\u003e --from=builder /app/jvm-startup/snapshot-dependencies/ ./\r\u003c/span\u003e\n\u003cspan class=\"k\"\u003eCOPY\u003c/span\u003e\u003cspan class=\"s\"\u003e --from=builder /app/jvm-startup/application/ ./\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\u003c/div\u003e\n\u003cfigcaption\u003eListing 6: Dockerfile für CraC\u003c/figcaption\u003e\u003c/figure\u003e\n\n\u003cp\u003eZuerst bauen wir aus dem Dockerfile mit \u003ccode\u003edocker build -t jvm-startup:crac-pre .\u003c/code\u003e ein erstes Image, das wir mit \u003ccode\u003edocker run --rm -it –privileged -p 8080:8080 --name crac jvm-startup:crac-prep /bin/sh\u003c/code\u003e starten können.\u003c/p\u003e\n\n\u003cp\u003eIn diesem Container können wir nun den Trainingslauf mit dem Befehl \u003ccode\u003ejava -XX:CRaCCheckpointTo=./crac-image/ -jar jvm-startup.jar\u003c/code\u003e starten. Nachdem wir nun die laufende Anwendung mit einigen HTTP Requests aufgewärmt haben, müssen wir das Signal für den Checkpoint an den Prozess senden. Hierzu verbinden wir uns mittels des Befehls \u003ccode\u003edocker exec -it crac /bin/sh\u003c/code\u003e mit dem laufenden Container. Hier können wir nun mit \u003ccode\u003ejcmd jvm-startup.jar JDK.checkpoint\u003c/code\u003e das Signal schicken, woraufhin die Anwendung den Snapshot erzeugt.\u003c/p\u003e\n\n\u003cp\u003eDamit der Snapshot mit in das finale Container-Image gelangt, nutzen wir außerhalb des Containers den Befehl \u003ccode\u003edocker commit crac jvm-startup:crac-run\u003c/code\u003e. Anschließend können wir mittels \u003ccode\u003edocker run --rm -p 8080:8080 jvm-startup:crac-run\u003c/code\u003e die Anwendung wieder starten. Da sie nun den Snapshot nutzt, startet sie nicht nur schnell, sondern der erste Request wird auch sofort beantwortet.\u003c/p\u003e\n\n\u003cp\u003eAktuell gibt es nur zwei mir bekannte JVMs mit Support für CRaC, nämlich \u003ca href=\"https://www.azul.com/downloads\"\u003eAzul Zulu\u003c/a\u003e und \u003ca href=\"https://bell-sw.com/pages/downloads\"\u003eBellsoft Liberica\u003c/a\u003e. Zudem gibt es in \u003ca href=\"https://developer.ibm.com/languages/semeru-runtimes/\"\u003eIBM Semeru\u003c/a\u003e mit CRIU einen Mechanismus, der identisch funktioniert. Bei allen JVMs ist für die Nutzung zudem Linux als unterliegende Plattform notwendig. Unter Windows funktioniert es bisher grundsätzlich nicht.\u003c/p\u003e\n\n\u003ch3 id=\"sonstiges-im-jdk\"\u003eSonstiges im JDK\u003c/h3\u003e\n\n\u003cp\u003eNeben den bisher vorgestellten expliziten Mechanismen wird im JDK konstant daran gearbeitet, die Performanz zu erhöhen. So ist mir kürzlich erst aufgefallen, dass ein Microbenchmark, die ich vor etwa fünf Jahren noch auf \u003ca href=\"https://openjdk.org/projects/jdk/14/\"\u003eJDK 14\u003c/a\u003e geschrieben habe, um die Geschwindigkeit von \u003ccode\u003etoUpperCase\u003c/code\u003e und \u003ccode\u003etoLowercase\u003c/code\u003e zu vergleichen (Listing 7), mittlerweile deutlich schneller ist als damals.\u003c/p\u003e\n\n\u003cfigure\u003e\u003cdiv class=\"highlight\" title=\"Listing 7: JMH Benchmark für toLowerCase und toUpperCase\"\u003e\u003cpre class=\"\"\u003e\u003ccode\u003e\u003cspan class=\"nd\"\u003e@BenchmarkMode\u003c/span\u003e\u003cspan class=\"o\"\u003e(\u003c/span\u003e\u003cspan class=\"nc\"\u003eAverageTime\u003c/span\u003e\u003cspan class=\"o\"\u003e)\u003c/span\u003e\r\n\u003cspan class=\"nd\"\u003e@OutputTimeUnit\u003c/span\u003e\u003cspan class=\"o\"\u003e(\u003c/span\u003e\u003cspan class=\"no\"\u003eNANOSECONDS\u003c/span\u003e\u003cspan class=\"o\"\u003e)\u003c/span\u003e\r\n\u003cspan class=\"nd\"\u003e@Fork\u003c/span\u003e\u003cspan class=\"o\"\u003e(\u003c/span\u003e\u003cspan class=\"mi\"\u003e1\u003c/span\u003e\u003cspan class=\"o\"\u003e)\u003c/span\u003e\r\n\u003cspan class=\"nd\"\u003e@Warmup\u003c/span\u003e\u003cspan class=\"o\"\u003e(\u003c/span\u003e\u003cspan class=\"n\"\u003eiterations\u003c/span\u003e \u003cspan class=\"o\"\u003e=\u003c/span\u003e \u003cspan class=\"mi\"\u003e1\u003c/span\u003e\u003cspan class=\"o\"\u003e,\u003c/span\u003e \u003cspan class=\"n\"\u003etime\u003c/span\u003e \u003cspan class=\"o\"\u003e=\u003c/span\u003e \u003cspan class=\"mi\"\u003e1\u003c/span\u003e\u003cspan class=\"o\"\u003e)\u003c/span\u003e\r\n\u003cspan class=\"nd\"\u003e@Measurement\u003c/span\u003e\u003cspan class=\"o\"\u003e(\u003c/span\u003e\u003cspan class=\"n\"\u003eiterations\u003c/span\u003e \u003cspan class=\"o\"\u003e=\u003c/span\u003e \u003cspan class=\"mi\"\u003e5\u003c/span\u003e\u003cspan class=\"o\"\u003e,\u003c/span\u003e \u003cspan class=\"n\"\u003etime\u003c/span\u003e \u003cspan class=\"o\"\u003e=\u003c/span\u003e \u003cspan class=\"mi\"\u003e5\u003c/span\u003e\u003cspan class=\"o\"\u003e)\u003c/span\u003e\r\n\u003cspan class=\"nd\"\u003e@Threads\u003c/span\u003e\u003cspan class=\"o\"\u003e(\u003c/span\u003e\u003cspan class=\"mi\"\u003e5\u003c/span\u003e\u003cspan class=\"o\"\u003e)\u003c/span\u003e\r\n\u003cspan class=\"nd\"\u003e@State\u003c/span\u003e\u003cspan class=\"o\"\u003e(\u003c/span\u003e\u003cspan class=\"nc\"\u003eThread\u003c/span\u003e\u003cspan class=\"o\"\u003e)\u003c/span\u003e\r\n\u003cspan class=\"kd\"\u003epublic\u003c/span\u003e \u003cspan class=\"kd\"\u003eclass\u003c/span\u003e \u003cspan class=\"nc\"\u003eToUpperOrToLowerCase\u003c/span\u003e \u003cspan class=\"o\"\u003e{\u003c/span\u003e\r\n\r\n    \u003cspan class=\"kd\"\u003epublic\u003c/span\u003e \u003cspan class=\"kd\"\u003estatic\u003c/span\u003e \u003cspan class=\"kt\"\u003evoid\u003c/span\u003e \u003cspan class=\"nf\"\u003emain\u003c/span\u003e\u003cspan class=\"o\"\u003e(\u003c/span\u003e\u003cspan class=\"nc\"\u003eString\u003c/span\u003e\u003cspan class=\"o\"\u003e[]\u003c/span\u003e \u003cspan class=\"n\"\u003eargs\u003c/span\u003e\u003cspan class=\"o\"\u003e)\u003c/span\u003e \u003cspan class=\"kd\"\u003ethrows\u003c/span\u003e \u003cspan class=\"nc\"\u003eException\u003c/span\u003e \u003cspan class=\"o\"\u003e{\u003c/span\u003e\r\n        \u003cspan class=\"kd\"\u003efinal\u003c/span\u003e \u003cspan class=\"nc\"\u003eOptions\u003c/span\u003e \u003cspan class=\"n\"\u003eopt\u003c/span\u003e \u003cspan class=\"o\"\u003e=\u003c/span\u003e \u003cspan class=\"k\"\u003enew\u003c/span\u003e \u003cspan class=\"nc\"\u003eOptionsBuilder\u003c/span\u003e\u003cspan class=\"o\"\u003e()\u003c/span\u003e\r\n            \u003cspan class=\"o\"\u003e.\u003c/span\u003e\u003cspan class=\"na\"\u003einclude\u003c/span\u003e\u003cspan class=\"o\"\u003e(\u003c/span\u003e\u003cspan class=\"nc\"\u003eToUpperOrToLowerCase\u003c/span\u003e\u003cspan class=\"o\"\u003e.\u003c/span\u003e\u003cspan class=\"na\"\u003eclass\u003c/span\u003e\u003cspan class=\"o\"\u003e.\u003c/span\u003e\u003cspan class=\"na\"\u003egetSimpleName\u003c/span\u003e\u003cspan class=\"o\"\u003e())\u003c/span\u003e\r\n            \u003cspan class=\"o\"\u003e.\u003c/span\u003e\u003cspan class=\"na\"\u003ebuild\u003c/span\u003e\u003cspan class=\"o\"\u003e();\u003c/span\u003e\r\n        \u003cspan class=\"k\"\u003enew\u003c/span\u003e \u003cspan class=\"nf\"\u003eRunner\u003c/span\u003e\u003cspan class=\"o\"\u003e(\u003c/span\u003e\u003cspan class=\"n\"\u003eopt\u003c/span\u003e\u003cspan class=\"o\"\u003e).\u003c/span\u003e\u003cspan class=\"na\"\u003erun\u003c/span\u003e\u003cspan class=\"o\"\u003e();\u003c/span\u003e\r\n    \u003cspan class=\"o\"\u003e}\u003c/span\u003e\r\n\r\n    \u003cspan class=\"kd\"\u003eprivate\u003c/span\u003e \u003cspan class=\"nc\"\u003eString\u003c/span\u003e \u003cspan class=\"n\"\u003estring\u003c/span\u003e \u003cspan class=\"o\"\u003e=\u003c/span\u003e \u003cspan class=\"nc\"\u003eRandomStringUtils\u003c/span\u003e\u003cspan class=\"o\"\u003e.\u003c/span\u003e\u003cspan class=\"na\"\u003erandomAlphabetic\u003c/span\u003e\u003cspan class=\"o\"\u003e(\u003c/span\u003e\u003cspan class=\"mi\"\u003e32\u003c/span\u003e\u003cspan class=\"o\"\u003e);\u003c/span\u003e\r\n\r\n    \u003cspan class=\"nd\"\u003e@Benchmark\u003c/span\u003e\r\n    \u003cspan class=\"kd\"\u003epublic\u003c/span\u003e \u003cspan class=\"nc\"\u003eString\u003c/span\u003e \u003cspan class=\"nf\"\u003etoLowerCase\u003c/span\u003e\u003cspan class=\"o\"\u003e()\u003c/span\u003e \u003cspan class=\"o\"\u003e{\u003c/span\u003e\r\n        \u003cspan class=\"k\"\u003ereturn\u003c/span\u003e \u003cspan class=\"n\"\u003estring\u003c/span\u003e\u003cspan class=\"o\"\u003e.\u003c/span\u003e\u003cspan class=\"na\"\u003etoLowerCase\u003c/span\u003e\u003cspan class=\"o\"\u003e();\u003c/span\u003e\r\n    \u003cspan class=\"o\"\u003e}\u003c/span\u003e\r\n\r\n    \u003cspan class=\"nd\"\u003e@Benchmark\u003c/span\u003e\r\n    \u003cspan class=\"kd\"\u003epublic\u003c/span\u003e \u003cspan class=\"nc\"\u003eString\u003c/span\u003e \u003cspan class=\"nf\"\u003etoUpperCase\u003c/span\u003e\u003cspan class=\"o\"\u003e()\u003c/span\u003e \u003cspan class=\"o\"\u003e{\u003c/span\u003e\r\n        \u003cspan class=\"k\"\u003ereturn\u003c/span\u003e \u003cspan class=\"n\"\u003estring\u003c/span\u003e\u003cspan class=\"o\"\u003e.\u003c/span\u003e\u003cspan class=\"na\"\u003etoUpperCase\u003c/span\u003e\u003cspan class=\"o\"\u003e();\u003c/span\u003e\r\n    \u003cspan class=\"o\"\u003e}\u003c/span\u003e\r\n\u003cspan class=\"o\"\u003e}\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\u003c/div\u003e\n\u003cfigcaption\u003eListing 7: JMH Benchmark für toLowerCase und toUpperCase\u003c/figcaption\u003e\u003c/figure\u003e\n\n\u003cp\u003eJDK 25 enthält außerdem mit \u003ca href=\"https://openjdk.org/jeps/502\"\u003eJEP 502\u003c/a\u003e noch ein Preview-Feature, das es uns einfacher macht, Konstanten zu definieren, die nicht bereits beim Start, sondern erst bei der ersten Nutzung initialisiert werden (Listing 8).\u003c/p\u003e\n\n\u003cfigure\u003e\u003cdiv class=\"highlight\" title=\"Listing 8: StableValues aus JDK 25\"\u003e\u003cpre class=\"\"\u003e\u003ccode\u003e\u003cspan class=\"c1\"\u003e// Deklaration mit Initialisierung von StableValue\r\u003c/span\u003e\n\u003cspan class=\"kd\"\u003eprivate\u003c/span\u003e \u003cspan class=\"kd\"\u003efinal\u003c/span\u003e \u003cspan class=\"nc\"\u003eSupplier\u003c/span\u003e\u003cspan class=\"o\"\u003e\u0026lt;\u003c/span\u003e\u003cspan class=\"nc\"\u003eLogger\u003c/span\u003e\u003cspan class=\"o\"\u003e\u0026gt;\u003c/span\u003e \u003cspan class=\"n\"\u003elogger\u003c/span\u003e \u003cspan class=\"o\"\u003e=\u003c/span\u003e \u003cspan class=\"nc\"\u003eStableValue\u003c/span\u003e\u003cspan class=\"o\"\u003e.\u003c/span\u003e\u003cspan class=\"na\"\u003esupplier\u003c/span\u003e\u003cspan class=\"o\"\u003e(\u003c/span\u003e\r\n    \u003cspan class=\"o\"\u003e()\u003c/span\u003e \u003cspan class=\"o\"\u003e-\u0026gt;\u003c/span\u003e \u003cspan class=\"nc\"\u003eLoggerFactory\u003c/span\u003e\u003cspan class=\"o\"\u003e.\u003c/span\u003e\u003cspan class=\"na\"\u003egetLogger\u003c/span\u003e\u003cspan class=\"o\"\u003e(\u003c/span\u003e\u003cspan class=\"nc\"\u003eMyClass\u003c/span\u003e\u003cspan class=\"o\"\u003e.\u003c/span\u003e\u003cspan class=\"na\"\u003eclass\u003c/span\u003e\u003cspan class=\"o\"\u003e));\u003c/span\u003e\r\n\r\n\u003cspan class=\"c1\"\u003e// Nutzung von StableValue\r\u003c/span\u003e\n\u003cspan class=\"nc\"\u003eLogger\u003c/span\u003e\u003cspan class=\"o\"\u003e.\u003c/span\u003e\u003cspan class=\"na\"\u003eget\u003c/span\u003e\u003cspan class=\"o\"\u003e().\u003c/span\u003e\u003cspan class=\"na\"\u003einfo\u003c/span\u003e\u003cspan class=\"o\"\u003e(\u003c/span\u003e\u003cspan class=\"s\"\u003e\"Hallo\"\u003c/span\u003e\u003cspan class=\"o\"\u003e);\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\u003c/div\u003e\n\u003cfigcaption\u003eListing 8: StableValues aus JDK 25\u003c/figcaption\u003e\u003c/figure\u003e\n\n\u003cp\u003eDadurch sparen wir nicht nur beim Start Zeit, wenn der Wert erst später benötigt wird; außerdem kann die JVM, da sie die Semantik dieses Konstruktes kennt, hier Optimierungen vornehmen – schließlich verhält sich ein solcher Wert nach der Initialisierung wie eine Konstante.\u003c/p\u003e\n\n\u003cp\u003eUnd auch der hohe Arbeitsspeicherbedarf der JVM wird aktuell im \u003cstrong\u003e\u003ca href=\"https://openjdk.org/projects/lilliput/index.html\"\u003eProject Lilliput\u003c/a\u003e\u003c/strong\u003e angegangen. Ziel ist es, die Header der Objekte von aktuell zwischen 96 und 128 Bit auf 64 Bit zu reduzieren. Dadurch verringert sich der benötigte Heap und damit auch der benötigte Arbeitsspeicher. Diese Arbeit wurde bereits mit \u003ca href=\"https://openjdk.org/jeps/450\"\u003eJEP 450\u003c/a\u003e in JDK 24 als experimentelles Feature zur Verfügung gestellt und wird mit \u003ca href=\"https://openjdk.org/jeps/519\"\u003eJEP 519\u003c/a\u003e nun in JDK 25 final in die JVM integriert werden.\u003c/p\u003e\n\u003cp\u003eEiner der aktuellen Hauptkritikpunkte an der JVM ist deren langsamer Start. Wir haben dabei gesehen, dass ein Großteil dieser Zeit für das Laden der Klassen verwendet wird. In der Vergangenheit wurden hier bereits mit CDS und AppCDS Features zur Verfügung gestellt, um diesen Prozess zu beschleunigen.\u003c/p\u003e\n\n\u003cp\u003eUnd die Arbeit ist – natürlich – noch nicht beendet. In naher Zukunft werden verschiedene Features aus Projekt Leyden in die JVM Einzug halten, die – aufbauend auf den beiden vorherigen – noch mehr der bislang beim Start der JVM ausgeführten Arbeit in die Build-Zeit verlagern.\u003c/p\u003e\n\n\u003cp\u003eAlternativ gibt es mit CRaC ein zweites Projekt, um eine gestartete Anwendung zu pausieren und anschließend von genau diesem Stand wieder zu starten. Und auch abseits der größeren Initiativen ist den Menschen, die am OpenJDK arbeiten, stets bewusst, dass Performance ein relevanter Punkt ist. Und so werden die JVMs generell von Release zu Release schneller.\u003c/p\u003e\n\u003c/body\u003e\u003c/html\u003e\n","image":"https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2000/v1/uploads-production/fuozr7dnnjuyef7f7ke0kzgoj89o?_a=BACMTiAE"},{"id":"https://www.innoq.com/en/blog/2026/03/neuland-reloaded/","url":"https://www.innoq.com/en/blog/2026/03/neuland-reloaded/","date_published":"2026-03-04T00:00:00.000+00:00","date_modified":"2026-03-06T11:34:35.126+01:00","author":[{"name":"Gerrit Beine","url":"https://www.innoq.com/ch/staff/gbeine/"}],"content_html":"\u003c!DOCTYPE html PUBLIC \"-//W3C//DTD HTML 4.0 Transitional//EN\" \"http://www.w3.org/TR/REC-html40/loose.dtd\"\u003e\n\u003chtml\u003e\u003cbody\u003e\n\u003cp\u003eWith OpenClaw, Captain Picard’s legendary command «Computer, tea. Earl Grey, hot.» is finally becoming reality.\nThe automation agent connects all the internet-based tools that play a role in everyday life with the cryptic low-level tools of the command line, allowing humans to take control via chat interfaces.\nIn the relevant online channels, the tenor is clear: the dream of universal agents is finally coming true.\nThe author Peter Steinberger is being celebrated for having accomplished something that all the companies with all their money and brilliant minds had supposedly failed to achieve.\u003c/p\u003e\n\n\u003cp\u003eAn observer viewing the discourse from the outside might ask at this point:\nAre we witnessing a second Linus Torvalds, with OpenClaw as a reincarnation of the Linux kernel on a new level, or are we witnessing a second Robert Oppenheimer, because «the most dangerous software in the world» (Steinberger, \u003ca href=\"https://www.innoq.com/en/blog/2026/03/neuland-reloaded/#fn:1\" id=\"fnref:1\" title=\"siehe Fußnote\" class=\"footnote\"\u003e[1]\u003c/a\u003e) possesses a potential for social destruction that is quite comparable to Oppenheimer’s Manhattan Project?\u003c/p\u003e\n\n\u003cp\u003eThis question will be answered in the future.\nFor now, the focus here is on why this tool demonstrates how right Angela Merkel was.\nThe topic of vibe coding will be set aside.\nInstead, the focus is on the social mechanics that can be observed through this example.\u003c/p\u003e\n\n\u003cp\u003eWhat the tool can do in detail is hardly surprising.\nAccessing internet services via APIs and defining automations through specified workflows has long been solved at the technical level and is feasible even for technically inexperienced users thanks to tools like Zapier or n8n.\nUser-friendly interfaces for command line tools have likewise been common for some time.\nAnd that large language models achieve sufficient quality for most cases in generating commands in programming languages can also be considered established.\u003c/p\u003e\n\n\u003ch3 id=\"killing-the-social-contract\"\u003eKilling the social contract\u003c/h3\u003e\n\n\u003cp\u003eSo what is new about the idea behind OpenClaw, and why is it being celebrated?\nThe technical answer is trivial: the software combines these capabilities by acting as an agent that links all these tools together and makes them accessible through simple interfaces such as chats via Telegram or Discord.\u003c/p\u003e\n\n\u003cp\u003eThe answer at the social level is less straightforward and requires closer examination.\nOpenClaw, through its architecture, terminates a social contract that underlies all interpersonal collaboration.\nThis informal yet nonetheless effective social contract ensures that responsibility can be assigned through negotiation, and that this negotiation takes place at the interfaces between systems—social as well as technical.\u003c/p\u003e\n\n\u003cp\u003eAt technical interfaces, such a contract is typically formulated as a specification that clarifies whether the participating systems are a client or a server, what data is transmitted, and which software development team must ultimately bear responsibility.\nIf these matters were unclear, the interface would function only by fortunate coincidence, and in the event of a problem, it would be unclear who could contribute to a solution and how.\u003c/p\u003e\n\n\u003cp\u003eAt social interfaces, these social contracts function quite similarly.\nFor the purchase of a die, for example, it is negotiated who is the buyer and who is the seller.\nBoth have rights and obligations that are the subject of this negotiation.\nThe outcome creates binding commitments and the possibility of clarifying who may have failed to fulfill their obligations.\nWithout this social contract and the associated negotiation, it would be impossible to establish a stable legal system.\u003c/p\u003e\n\n\u003cp\u003eThis fact may seem banal at first; its consequences are not.\nOpenClaw may be just a single tool today, but it follows the trend of blurring the distinctions necessary for the assignment of responsibility.\u003c/p\u003e\n\n\u003cp\u003eOpenClaw can, by design, only function without this social contract.\nIt runs as an agent on a computer defined by the user and connects to the tools on the internet for which the user authorizes it.\nFor control, the user can select one or more channels, and OpenClaw receives its intelligence through a large language model specified by the user, to which access must likewise be provided.\nAs Steinberger says, the software is designed to be allowed to do everything.\nIt is «Skynet» (Steinberger, \u003ca href=\"https://www.innoq.com/en/blog/2026/03/neuland-reloaded/#fn:1\" title=\"siehe Fußnote\" class=\"footnote\"\u003e[1]\u003c/a\u003e) with root privileges, and this is intentional.\nIt can have root privileges on my computer and, if I authorize it, over my life as well.\nWhat makes security experts' hair stand on end is, in this case, deliberate:\nOpenClaw works precisely because it brings no inherent security barriers.\nPut bluntly: Steinberger succeeds at what supposedly no company had managed only because he ignores a restriction that companies cannot ignore.\u003c/p\u003e\n\n\u003ch3 id=\"the-return-of-the-chancellor\"\u003eThe return of the chancellor\u003c/h3\u003e\n\n\u003cp\u003eThis problem is further amplified by the large language models, which themselves must, by design, be insecure.\nAny attempt to impose a security barrier on natural language is perceived in the real world as censorship and leads to substitute patterns in language use.\nA large language model will, of course, eventually adapt to these as well.\nSecurity must therefore necessarily occur at the interfaces that connect the large language model to other tools.\u003c/p\u003e\n\n\u003cp\u003eOpenClaw removes these barriers insofar as it will attempt to carry out all interactions with the interfaces of connected services that can be described in natural language.\nUntil now, this security check at interfaces has functioned on the basis of the contract described above: for example, users authenticate themselves with credentials at a payment service provider and transfer money.\nOpenClaw can theoretically do this as well if it has access to the payment service provider.\nHowever, the large language model controlling OpenClaw can neither recognize the intent behind a command nor is it possible to ensure that this command was not triggered by a prompt injection.\nThe payment service provider practically cannot distinguish whether OpenClaw or the user herself triggered the command.\nSteinberger repeatedly points to these problems and has largely protected himself legally through his choice of the MIT License.\u003c/p\u003e\n\n\u003cp\u003eAnd it is precisely here that Angela Merkel steps out of the shadows and smiles at us as if she were thinking: I told you so.\nFor what Steinberger demonstrates with OpenClaw is how little the software engineering community reflects on the social implications of software, as long as it merely functions technically.\u003c/p\u003e\n\n\u003ch3 id=\"sprinting-blind-through-a-marathon\"\u003eSprinting blind through a marathon\u003c/h3\u003e\n\n\u003cp\u003eThe result is a shift in social contracts for which no one is prepared and which, even if OpenClaw as a tool disappears again, will have lasting effects for a long time to come.\nThe consequence of OpenClaw’s availability is that people will use it.\nThe previously accepted social contract is thrown off balance because, on the one hand, the binding commitments it entails suddenly become an obstacle in the use of OpenClaw and, on the other hand, the attribution necessary for clarifying responsibility is no longer possible.\nThis unclear attribution of responsibility is the reason why no company has released software like OpenClaw until now.\nSteinberger places the responsibility with the users, and a counterargument is likely to be difficult in the age of personal responsibility.\u003c/p\u003e\n\n\u003cp\u003eThis attitude, which Adrian Daub described in his book «What Tech Calls Thinking» \u003ca href=\"https://www.innoq.com/en/blog/2026/03/neuland-reloaded/#fn:2\" id=\"fnref:2\" title=\"siehe Fußnote\" class=\"footnote\"\u003e[2]\u003c/a\u003e, is either naive or ignorant.\nIt reveals a resistance to learning that has persisted in the software engineering community for decades with regard to the social implications of software.\nFor the fact that, for example, the mechanisms necessary for the social contract described above cannot be retrofitted without entailing functional limitations is likely to be largely uncontested.\u003c/p\u003e\n\n\u003cp\u003eThis becomes fatal in situations where security must be considered as a principle because social coexistence is based on it.\nUnlike the reliable computer in Star Trek, OpenClaw controls processes in an opaque manner.\nNo one is prepared for a situation in which it becomes necessary to clarify how OpenClaw arrived at a result, but this is technically impossible.\nResponsibility lies solely with individuals who have only marginal possibilities to intervene in the processes.\nFor such a situation, there is neither a legal framework capable of addressing the consequences nor will there be social acceptance that goes beyond the word «personal responsibility».\u003c/p\u003e\n\n\u003cp\u003eThat the perspective presented here is scarcely represented in IT allows only one conclusion: Angela Merkel is still right, even in 2026.\u003c/p\u003e\n\n\u003cinfo-box title=\"Excursus: The Social Contract\"\u003e\u003cdetails\u003e\u003csummary\u003e\u003cdiv class=\"infobox__teaser\"\u003e\n\u003cdiv class=\"infobox__teaser__left\"\u003e\n\u003cspan class=\"infobox__teaser__heading\"\u003eExcursus: The Social Contract\u003c/span\u003e\u003cspan class=\"icon icon-info\"\u003e\u003c/span\u003e\n\u003c/div\u003e\n\u003cdiv class=\"infobox__teaser__right\"\u003e\u003cspan class=\"icon icon-chevron-down icon--small\"\u003e\u003c/span\u003e\u003c/div\u003e\n\u003c/div\u003e\u003c/summary\u003e\u003cdiv class=\"infobox__content\"\u003e\r\n\n\u003cp\u003eThe concept of the social contract is informal and not strictly defined.\u003c/p\u003e\n\n\u003cp\u003eHumans reduce the uncertainty of an open future by negotiating shared goals and mutually committing to their observance.\nThis can occur formally, such as through contracts, or informally, as in friendships or romantic relationships.\nAs a result, social action becomes normatively expectable as a justified assumption that agreements will be honored.\u003c/p\u003e\n\n\u003cp\u003eThis mechanism corresponds to Luhmann’s concept of trust \u003ca href=\"https://www.innoq.com/en/blog/2026/03/neuland-reloaded/#fn:3\" id=\"fnref:3\" title=\"siehe Fußnote\" class=\"footnote\"\u003e[3]\u003c/a\u003e: trust reduces social complexity by allowing one to mentally exclude certain courses of action on the part of the other.\nThe social contract institutionalizes this trust.\nOne no longer trusts merely the person but the mutually recognized rule.\u003c/p\u003e\n\n\u003cp\u003eAn example of the application of this social contract is the formal legal system.\nWithout the basic idea of binding agreements, the concept of a breach of law would be meaningless.\nThe law thus operates on the institutionalized expectability that the social contract creates.\u003c/p\u003e\n\n\u003cp\u003eIn IT, the social contract is implemented through compliance and security.\u003c/p\u003e\n\n\u003c/div\u003e\u003c/details\u003e\u003c/info-box\u003e\r\n\n\u003ch3 id=\"links-literature\"\u003eLinks \u0026amp; Literature\u003c/h3\u003e\n\n\u003cfoot-notes class=\"footnotes\"\u003e\n\n\u003col class=\"footnotes__list\"\u003e\n\n\u003cli id=\"fn:1\"\u003e\n\u003cp\u003ec’t 3003, \u003ca href=\"https://www.youtube.com/watch?v=ps7kqEXkwEs\"\u003eOpenClaw: Ja, der Hype ist gerechtfertigt\u003c/a\u003e \u003ca href=\"https://www.innoq.com/en/blog/2026/03/neuland-reloaded/#fnref:1\" title=\"zurück zum Text\" class=\"reversefootnote\"\u003e ↩︎\u003c/a\u003e\u003c/p\u003e\n\u003c/li\u003e\n\n\u003cli id=\"fn:2\"\u003e\n\u003cp\u003eDaub, Adrian, «What Tech Calls Thinking», FSG Originals, 2020 \u003ca href=\"https://www.innoq.com/en/blog/2026/03/neuland-reloaded/#fnref:2\" title=\"zurück zum Text\" class=\"reversefootnote\"\u003e ↩︎\u003c/a\u003e\u003c/p\u003e\n\u003c/li\u003e\n\n\u003cli id=\"fn:3\"\u003e\n\u003cp\u003eLuhmann, Niklas, «Vertrauen. Ein Mechanismus der Reduktion sozialer Komplexität», 5. Auflage, UTB, 2014 \u003ca href=\"https://www.innoq.com/en/blog/2026/03/neuland-reloaded/#fnref:3\" title=\"zurück zum Text\" class=\"reversefootnote\"\u003e ↩︎\u003c/a\u003e\u003c/p\u003e\n\u003c/li\u003e\n\n\u003c/ol\u003e\n\u003c/foot-notes\u003e\n\u003c/body\u003e\u003c/html\u003e\n","image":"https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2000/v1/uploads-production/i088c9swp6s8k3swr3o1r40q5zd8?_a=BACMTiAE"},{"id":"https://www.innoq.com/de/blog/2026/02/from-vibe-coder-to-code-owner/","url":"https://www.innoq.com/de/blog/2026/02/from-vibe-coder-to-code-owner/","date_published":"2026-03-03T00:00:00.000+00:00","date_modified":"2026-03-16T09:12:49.719+01:00","author":[{"name":"Torben Keller","url":"https://www.innoq.com/ch/staff/torben-keller/"}],"content_html":"\u003c!DOCTYPE html PUBLIC \"-//W3C//DTD HTML 4.0 Transitional//EN\" \"http://www.w3.org/TR/REC-html40/loose.dtd\"\u003e\n\u003chtml\u003e\u003cbody\u003e\n\u003cp\u003eKI-Agenten schreiben Code. Viel Code. Schnell. Wer mehrere Agenten parallel laufen lässt, bekommt in wenigen Stunden tausende Zeilen neuen Code. Letzte Woche hat einer meiner Agenten in anderthalb Stunden ein komplettes Feature umgesetzt – 4.500 Zeilen, sauber strukturiert, Merge Request erstellt. Hat einfach funktioniert. Dann habe ich kurz nachgerechnet: Ein gründliches Review hätte mich zwei, vielleicht drei Tage gekostet.\u003c/p\u003e\n\n\u003cp\u003eDas ist die Realität, über die niemand gerne spricht: Während ich den ersten Merge Request durchgehe, produziert der Agent längst die nächsten 10.000 Zeilen. Wer alles lesen will, wird zum Flaschenhals. Man bremst genau die Produktivität aus, die man sich von den Agenten erhofft hat.\u003c/p\u003e\n\n\u003cp\u003eOpenAI hat in einem internen Experiment gezeigt, was bereits möglich ist: Ein Team von drei Ingenieuren baute in fünf Monaten rund eine Million Zeilen Code – ohne eine einzige manuell geschriebene Zeile. 3,5 Pull Requests pro Ingenieur pro Tag.\u003csup\u003e\u003ca href=\"https://www.innoq.com/de/blog/2026/02/from-vibe-coder-to-code-owner/#fn1\"\u003e[1]\u003c/a\u003e\u003c/sup\u003e Wer glaubt, diesen Output mit klassischem Code-Review beherrschen zu können, hat die Rechnung ohne die Agenten gemacht.\u003c/p\u003e\n\n\u003cp\u003eIch lese nicht mehr alles. Ich schaue mir nur noch die wichtigen Dinge an. Aber wie entscheide ich, was wichtig ist? Und vor allem: Wie übernehme ich Verantwortung für Code, den ich nicht vollständig gelesen habe?\u003c/p\u003e\n\n\u003ch2 id=\"daskennenwirdochschon\"\u003eDas kennen wir doch schon\u003c/h2\u003e\n\n\u003cp\u003eAber ist das wirklich ein neues Problem? Ich behaupte: nein.\u003c/p\u003e\n\n\u003cp\u003eEin neues Teammitglied steigt in ein Projekt ein, die ursprünglichen Autoren sind längst weg – und trotzdem wird produktiv weitergearbeitet. Für neue Features wird Verantwortung übernommen, obwohl das neue Teammitglied nicht jede Zeile der Codebasis kennt. Was ermöglicht das? Nicht die Hoffnung, dass der Code schon funktionieren wird. Sondern handfeste Dinge: eine verständliche Architektur, eine Test-Suite, die sofort anschlägt, wenn eine Änderung etwas anderes kaputt macht, brauchbare Dokumentation, eine CI-Pipeline die Fehler fängt. Nur so ist Brownfield-Entwicklung überhaupt möglich.\u003c/p\u003e\n\n\u003cp\u003eAgenten sind wie diese neuen Teammitglieder – nur dass jede neue Session ein frisches Onboarding braucht. Das geht am besten, wenn sie nur kleine Teile der Anwendung verstehen müssen, um Änderungen machen zu können. Was dabei hilft, sind dieselben Dinge wie im Brownfield: eine klare Struktur, gute Tests und verständliche Dokumentation.\u003c/p\u003e\n\n\u003cp\u003eGenau diese Umgebung – Tests, Architektur-Checks, Dokumentation, CI-Pipelines – ist das, was den Unterschied macht. In der Agentenwelt hat sich dafür ein Begriff etabliert: der Agent Harness.\u003c/p\u003e\n\n\u003ch2 id=\"wasisteinagentharness\"\u003eWas ist ein Agent Harness?\u003c/h2\u003e\n\n\u003cp\u003eCharlie Guo bringt es auf den Punkt: Ein Agent Harness ist «the set of constraints, tools, documentation, and feedback loops that keep an agent productive and on track».\u003csup\u003e\u003ca href=\"https://www.innoq.com/de/blog/2026/02/from-vibe-coder-to-code-owner/#fn2\"\u003e[2]\u003c/a\u003e\u003c/sup\u003e Die Formel dahinter: Model + Harness = Agent.\u003csup\u003e\u003ca href=\"https://www.innoq.com/de/blog/2026/02/from-vibe-coder-to-code-owner/#fn3\"\u003e[3]\u003c/a\u003e\u003c/sup\u003e Ein gutes Modell allein reicht nicht – was den Unterschied in der Codequalität macht, ist der Harness.\u003c/p\u003e\n\n\u003cp\u003eDie Kernphilosophie dahinter ist radikal praktisch: Mechanische Durchsetzung statt Hoffnung. Mitchell Hashimoto, der den Begriff «Harness Engineering» geprägt hat, formuliert das Prinzip so: «Anytime you find an agent makes a mistake, you take the time to engineer a solution such that the agent never makes that mistake again.»\u003csup\u003e\u003ca href=\"https://www.innoq.com/de/blog/2026/02/from-vibe-coder-to-code-owner/#fn4\"\u003e[4]\u003c/a\u003e\u003c/sup\u003e Nicht darauf vertrauen, dass der Agent es beim nächsten Mal besser macht – sondern Feedback-Loops und deterministische Checks bauen, die den Fehler beim nächsten Mal automatisch abfangen.\u003c/p\u003e\n\n\u003cp\u003eMeine Überzeugung, die sich mit jeder Woche Praxis verstärkt: Der Harness ist das Wichtigste an der ganzen Gleichung. Aus meiner Erfahrung liefert ein solides Modell mit einem durchdachten Harness bessere Ergebnisse als ein Spitzenmodell ohne Leitplanken. Deshalb investiere ich den Großteil meiner Zeit nicht in bessere Prompts, sondern in einen besseren Harness.\u003c/p\u003e\n\n\u003cp\u003eAber wie sieht so ein Harness konkret aus?\u003c/p\u003e\n\n\u003ch2 id=\"wieeinharnessinderpraxisaussieht\"\u003eWie ein Harness in der Praxis aussieht\u003c/h2\u003e\n\n\u003cp\u003eIn meinen Projekten hat sich der Harness als mehrschichtiges Sicherheitsnetz entwickelt. Vier Schichten, die aufeinander aufbauen – jede fängt ab, was die vorherige durchlässt.\u003c/p\u003e\n\n\u003ch3 id=\"deterministische-guardrails-die-erste-verteidigungslinie\"\u003eDeterministische Guardrails – die erste Verteidigungslinie\u003c/h3\u003e\n\n\u003cp\u003eAlles, was sich automatisiert prüfen lässt, prüfe ich automatisiert. Und zwar auf zwei Ebenen: In Pre-Commit-Hooks laufen die schnellen Checks – Unit-Tests, Integrationstests, Architektur-Tests mit ArchUnit, Linting und Formatting. In der CI-Pipeline folgen die schwereren Geschütze: E2E-Tests, Security-Scans, statische Code-Analyse. Die Liste wächst mit jedem Fehler, den ein Agent macht – ganz im Sinne von Hashimotos Prinzip.\u003c/p\u003e\n\n\u003cp\u003eDie Pre-Commit-Hooks sind der entscheidende Mechanismus. Sie sind das Tor: Solange diese Checks nicht grün sind, darf der Agent nicht committen. Keine Ausnahmen, keine Warnings – Zero-Warning-Tolerance. Der Agent läuft gegen die Wand, bekommt die Fehlermeldung und korrigiert sich selbst.\u003c/p\u003e\n\n\u003ch3 id=\"ki-reviews-der-zweite-blick\"\u003eKI-Reviews – der zweite Blick\u003c/h3\u003e\n\n\u003cp\u003eEin zweiter Agent reviewt den Code des ersten. Das klingt erstmal redundant, aber in der Praxis ist es überraschend effektiv – gerade weil der Review-Agent einen eigenen, unabhängigen Kontext hat. Er kennt nicht den Entstehungsprozess, sondern nur die Änderungen, das Ticket und die Akzeptanzkriterien. Auf dieser Basis prüft er, ob der Merge Request das Geforderte erfüllt, sucht nach Architektur-Verletzungen und findet Code Smells, die statische Analyse nicht erkennt.\u003c/p\u003e\n\n\u003cp\u003eWenn sowohl die deterministischen Checks als auch ein KI-Review grün zeigen, steigt mein Vertrauen deutlich. Das ersetzt kein menschliches Review komplett. Aber es ergänzt es um eine Schicht, die schnell und konsistent arbeitet.\u003c/p\u003e\n\n\u003ch3 id=\"selektives-menschliches-review-die-wichtigen-stellen\"\u003eSelektives menschliches Review – die wichtigen Stellen\u003c/h3\u003e\n\n\u003cp\u003eHier passiert der eigentliche Shift: Ich lese nicht mehr alles. Ich schaue mir gezielt die Core-Business-Logik an. Macht der Agent wirklich das, was ich erwarte? Stimmt die fachliche Entscheidung? Bildet der Code die Domäne korrekt ab?\u003c/p\u003e\n\n\u003cp\u003eBoilerplate, Mapping-Code, Standard-Patterns – das überlasse ich dem Harness. Wenn die ersten beiden Schichten grün zeigen, muss ich mich hier nicht mehr eingraben. Man lernt mit der Zeit, wo man reinschauen muss und wo nicht. Dieses Gespür entwickelt sich mit jedem Feature, das man mit Agenten baut.\u003c/p\u003e\n\n\u003ch3 id=\"produkttest-funktioniert-es-wirklich\"\u003eProdukttest – funktioniert es wirklich?\u003c/h3\u003e\n\n\u003cp\u003eAm Ende zählt nur eins: Tut die Software, was sie soll? Ich teste das Feature, prüfe das Verhalten, klicke mich durch die Anwendung. Preview-Umgebungen, die automatisch pro Merge Request hochgefahren werden, machen das einfach – ein schneller Weg, das Ergebnis zu prüfen, bevor es in Produktion geht. Alle Qualitätsmetriken können perfekt sein – wenn das Feature nicht das tut, was der Nutzer braucht, ist alles wertlos.\u003c/p\u003e\n\n\u003cp\u003eWenn der Harness grün zeigt, die KI-Reviews passen, das selektive Review keine Überraschungen bringt und das Feature funktioniert – dann kann ich ausliefern. Nicht blind, nicht naiv, sondern mit einem Vertrauen, das auf mehreren unabhängigen Prüfschichten basiert.\u003c/p\u003e\n\n\u003cp\u003eAber dieser Harness ist kein Selbstläufer.\u003c/p\u003e\n\n\u003ch2 id=\"wasderharnessnichtist:einelizenzzumwegschauen\"\u003eWas der Harness nicht ist: eine Lizenz zum Wegschauen\u003c/h2\u003e\n\n\u003cp\u003eEinfach Agenten in ein Legacy-Projekt schmeißen und einen 10x Boost erwarten – das ist Utopie. Wer allerdings schon vorher gute Softwareentwicklung gemacht hat – Tests, saubere Architektur, Dokumentation, isoliert testbare Komponenten – der hat den Großteil des Harness bereits und kann KI-Agenten relativ einfach integrieren. Wer hingegen einen Big Ball of Mud geerbt hat, muss erstmal investieren: Dokumentation aufbauen, Testbarkeit herstellen, Strukturen schaffen. Das ist kein Wochenendprojekt.\u003c/p\u003e\n\n\u003cp\u003eMeine Erfahrung zeigt: Mit einem durchdachten Harness verschiebt sich die Art der Kontrolle. Es geht nicht mehr darum, jede Zeile zu lesen. Es geht darum, die richtigen Stellen zu lesen – die Core-Business-Logik, die fachlichen Entscheidungen. Den Rest überlässt man dem Harness. Entscheidend ist gezieltes Hinschauen: Wie wahrscheinlich ist ein Fehler? Wie schwer wiegt er? Wie leicht entdeckt ihn der Harness?\u003csup\u003e\u003ca href=\"https://www.innoq.com/de/blog/2026/02/from-vibe-coder-to-code-owner/#fn5\"\u003e[5]\u003c/a\u003e\u003c/sup\u003e Je mehr der Harness automatisch erkennt, desto weniger muss ich manuell prüfen.\u003c/p\u003e\n\n\u003cp\u003eEin gut aufgebauter Harness erkennt vor allem strukturelle Probleme und sorgt dafür, dass der Code lesbar und beherrschbar bleibt – auch für Menschen. Weil alles in Isolation testbar sein muss, kann ich jederzeit in einzelne Teile reinschauen, ohne das große Ganze verstehen zu müssen. Was der Harness nicht zuverlässig erkennt: ob das Feature am Ende tut, was es soll. Diese funktionale Verifikation bleibt beim Menschen.\u003c/p\u003e\n\n\u003cp\u003eDer beste Praxistest: Would you ship this if you were on call tonight?\u003csup\u003e\u003ca href=\"https://www.innoq.com/de/blog/2026/02/from-vibe-coder-to-code-owner/#fn6\"\u003e[6]\u003c/a\u003e\u003c/sup\u003e Wenn die Antwort nein ist, ist der Harness nicht stark genug – egal wie grün die Pipeline leuchtet.\u003c/p\u003e\n\n\u003chr\u003e\n\n\u003cp\u003eWer heute in seinen Harness investiert, kann morgen mit einer Geschwindigkeit arbeiten, die vorher nicht möglich war – und trotzdem Verantwortung für jedes ausgelieferte Feature übernehmen.\u003c/p\u003e\n\n\u003chr\u003e\n\n\u003ch2 id=\"referenzen\"\u003eReferenzen\u003c/h2\u003e\n\n\u003cp\u003e\u003ca id=\"fn1\"\u003e\u003c/a\u003e[1] OpenAI, \u003ca href=\"https://openai.com/index/harness-engineering/\"\u003e«Harness engineering: leveraging Codex in an agent-first world»\u003c/a\u003e, 11. Februar 2026.\u003c/p\u003e\n\n\u003cp\u003e\u003ca id=\"fn2\"\u003e\u003c/a\u003e[2] Charlie Guo, \u003ca href=\"https://www.ignorance.ai/p/the-emerging-harness-engineering\"\u003e«The Emerging 'Harness Engineering’ Playbook»\u003c/a\u003e, Artificial Ignorance, 22. Februar 2026.\u003c/p\u003e\n\n\u003cp\u003e\u003ca id=\"fn3\"\u003e\u003c/a\u003e[3] Simon Willison, \u003ca href=\"https://simonwillison.net/2026/Feb/22/how-i-think-about-codex/\"\u003e«How I think about Codex»\u003c/a\u003e, 22. Februar 2026.\u003c/p\u003e\n\n\u003cp\u003e\u003ca id=\"fn4\"\u003e\u003c/a\u003e[4] Mitchell Hashimoto, \u003ca href=\"https://mitchellh.com/writing/my-ai-adoption-journey\"\u003e«My AI Adoption Journey»\u003c/a\u003e, 5. Februar 2026.\u003c/p\u003e\n\n\u003cp\u003e\u003ca id=\"fn5\"\u003e\u003c/a\u003e[5] Birgitta Böckeler, \u003ca href=\"https://martinfowler.com/articles/exploring-gen-ai/to-vibe-or-not-vibe.html\"\u003e«To Vibe or Not to Vibe»\u003c/a\u003e, martinfowler.com, 23. September 2025.\u003c/p\u003e\n\n\u003cp\u003e\u003ca id=\"fn6\"\u003e\u003c/a\u003e[6] Birgitta Böckeler, \u003ca href=\"https://martinfowler.com/articles/exploring-gen-ai/i-still-care-about-the-code.html\"\u003e«I Still Care About the Code»\u003c/a\u003e, martinfowler.com, 9. Juli 2025.\u003c/p\u003e\n\u003c/body\u003e\u003c/html\u003e\n","image":"https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2000/v1/uploads-production/fwtaompviyr8lx4frqspod3rupez?_a=BACMTiAE"},{"id":"https://www.innoq.com/de/blog/2026/03/dev-sandbox-network/","url":"https://www.innoq.com/de/blog/2026/03/dev-sandbox-network/","date_published":"2026-03-03T00:00:00.000+00:00","date_modified":"2026-04-27T14:25:55.031+02:00","author":[{"name":"Joy Heron","url":"https://www.innoq.com/ch/staff/joy-heron/"}],"content_html":"\u003c!DOCTYPE html PUBLIC \"-//W3C//DTD HTML 4.0 Transitional//EN\" \"http://www.w3.org/TR/REC-html40/loose.dtd\"\u003e\n\u003chtml\u003e\u003cbody\u003e\n\u003cp\u003eIn einem \u003ca href=\"https://www.innoq.com/en/blog/2025/12/dev-sandbox/\"\u003evorherigen Beitrag\u003c/a\u003e habe ich meine Lösung beschrieben, wie ich eine Development-Sandbox für meine Coding-Agents aufsetze. Sie basiert auf einer \u003ca href=\"https://github.com/lima-vm/lima\"\u003eLima\u003c/a\u003e-Virtual-Machine (VM) unter macOS, und ich reduziere die User-Capabilities in dieser VM auf das absolute Minimum. Da mein User in der VM nur die nötigen Rechte hat, ist ein Coding-Agent, der mit den Rechten meines Users läuft, entsprechend ebenfalls eingeschränkt. Der Beitrag beschreibt damit den ersten notwendigen Schritt für eine Sandbox, die stark begrenzt, auf wie viel Code ein Agent überhaupt zugreifen kann. Das schützt vor dem ersten Teil der \u003ca href=\"https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/\"\u003elethal trifecta\u003c/a\u003e, indem \u003cstrong\u003eZugriff auf private Daten\u003c/strong\u003e so weit wie irgend möglich verhindert wird.\u003c/p\u003e\n\n\u003cp\u003eAllerdings schützt diese Lösung nicht vor den beiden anderen Bestandteilen der lethal trifecta: \u003cstrong\u003eKontakt mit nicht vertrauenswürdigen Inhalten\u003c/strong\u003e und \u003cstrong\u003edie Möglichkeit, nach außen zu kommunizieren\u003c/strong\u003e. Denn die VM, die ich als Sandbox nutze, hängt weiterhin am Internet. Beliebige HTTP-Requests können abgesetzt werden – und damit kann Information aus der Sandbox herausleaken. Außerdem wird das Ergebnis eines solchen Requests ungeprüft in den Systemkontext übernommen, wodurch unsere Agents mit nicht vertrauenswürdigen Inhalten in Kontakt kommen können.\u003c/p\u003e\n\n\u003cp\u003eBislang habe ich mich selbst in der Schleife gehalten und die eingebauten Network-Policy-Tools in \u003ca href=\"https://openai.com/index/introducing-codex/\"\u003eCodex\u003c/a\u003e und \u003ca href=\"https://www.claude.com/product/claude-code\"\u003eClaude Code\u003c/a\u003e genutzt, um jede Verbindung ins Internet explizit zu genehmigen. Ich möchte mich aber wirklich aus dieser Schleife herausnehmen und klare Regeln definieren, welche Websites ohne mein ausdrückliches Einverständnis frei erreichbar sein sollen.\u003c/p\u003e\n\n\u003cp\u003eDieser Beitrag beschreibt meine Lösung für das Problem. Vorab der Hinweis: Damit bewege ich mich etwas außerhalb meiner Komfortzone. Ich bin Full-Stack-Entwickler und halte mich normalerweise von Linux-Konfiguration und Networking eher fern. Ich musste einiges wieder ausgraben, was ich vergessen hatte (wie sieht der TLS-Handshake nochmal genau aus?), und auch vieles lernen, das ich vorher nicht wusste. Aber wenn uns der Aufstieg von KI nicht gelegentlich dazu zwingt, über den Tellerrand dessen hinauszugehen, was wir gewohnt sind – was dann?\u003c/p\u003e\n\n\u003cp\u003eIch habe KI genutzt, um unterschiedliche Lösungsansätze zu analysieren, und KI hat mir geholfen, die Konfiguration zu erstellen, die ich in diesem Beitrag teile. Aber zu keinem Zeitpunkt habe ich einen Agenten „losgelassen“, um entweder den Rechner oder die Sandbox selbst zu konfigurieren. Ich habe die Dokumentation gelesen, alles doppelt und dreifach geprüft und \u003ca href=\"https://www.innoq.com/en/blog/2025/12/ai-cognitive-lens-elaboration/#askquestionsactively\"\u003eaktiv jede Frage gestellt, die mir eingefallen ist\u003c/a\u003e. Wenn dir etwas auffällt, das man verbessern könnte, melde dich bitte. Wie schon beim ersten Beitrag habe ich außerdem unsere INNOQ-Security-Expert:innen gebeten, meinen Ansatz ebenfalls zu prüfen.\u003c/p\u003e\n\n\u003ch3 id=\"proxy-auf-dem-host-betreiben-zugriff-nur-auf-definierte-domains\"\u003eProxy auf dem Host betreiben: Zugriff nur auf definierte Domains\u003c/h3\u003e\n\n\u003cp\u003eDer erste Schritt war, auf dem Host-System einen Proxy aufzusetzen. Damit kann ich ausgehenden Traffic aus meiner Development-Sandbox überwachen und Regeln definieren, welche Websites erlaubt sind und welche blockiert werden.\u003c/p\u003e\n\n\u003cp\u003eDer Weg zu einer Lösung, die für mich funktioniert, war allerdings voller Umwege.\u003c/p\u003e\n\n\u003cp\u003eIch habe schnell gemerkt, dass ich auf keinen Fall jede einzelne IP-Adresse manuell in einer Firewall auf dem Host freigeben will – schon allein, weil ich gar nicht zuverlässig sehen kann, zu welcher Domain diese IPs jeweils gehören.\u003c/p\u003e\n\n\u003cp\u003eZwischendurch hat die KI vorgeschlagen, einen Man-in-the-Middle-Proxy zu erweitern, um jeden Request zu prüfen. Das kann ein valider Ansatz sein, wenn man weiß, was man tut, und es kann hilfreich sein, die Inhalte der Requests, die zur und von der Sandbox gehen, zu inspizieren und zu überwachen. Dafür müsste man allerdings ein selbstsigniertes Zertifikat erzeugen und alle Trust Stores auf der Client-Seite so konfigurieren, dass dieses Zertifikat vertraut wird – und genau das wollte ich lieber vermeiden.\u003c/p\u003e\n\n\u003cp\u003eAm Ende habe ich mich für einen \u003cem\u003eForward Proxy\u003c/em\u003e entschieden: einen Proxy, der Requests abfängt und an das Ziel weiterleitet. Damit konnte ich jede \u003ccode\u003eCONNECT\u003c/code\u003e-Methode abfangen, die die Sandbox sendet, wenn sie eine TLS-Verbindung zum Zielserver aufbauen will. So kann ich diesen Request gegen eine konkrete Allowlist von Domains prüfen. Passt er nicht, wird die Verbindung verworfen.\u003c/p\u003e\n\n\u003cp\u003eUm das Rad nicht neu zu erfinden, habe ich mich für den Proxy \u003ca href=\"https://www.squid-cache.org/\"\u003eSquid\u003c/a\u003e entschieden. Squid positioniert sich zwar primär als Caching-Proxy, kann aber auch als CONNECT-only-Allowlist-Proxy genutzt werden. Da ich auf macOS arbeite, habe ich Squid über \u003ca href=\"https://brew.sh/\"\u003eHomebrew\u003c/a\u003e installiert. Anschließend habe ich Folgendes in meine Squid-Konfiguration (bei mir unter \u003ccode\u003e/opt/homebrew/etc/squid.conf\u003c/code\u003e) ergänzt und den Service neu gestartet:\u003c/p\u003e\n\n\u003cfigure\u003e\u003cdiv class=\"highlight\" title=\"\"\u003e\u003cpre class=\"\"\u003e\u003ccode\u003e############################################\r\n# Custom: CONNECT-only-Allowlist-Proxy\r\n############################################\r\n\r\n# Dev-Proxy soll auf Port 8888 lauschen\r\nhttp_port 8888\r\n\r\n# CONNECT nur zum Standard-TLS-Port 443 erlauben\r\nacl SSL_ports port 443\r\nacl CONNECT method CONNECT\r\nhttp_access deny CONNECT !SSL_ports\r\n\r\n# Proxy-Nutzung nur aus dem Sandbox-Netz erlauben\r\nacl vmnet src 127.0.0.1/32\r\n\r\n# Allowlist der Ziel-Domains\r\nacl allowed_domains dstdomain \"/opt/homebrew/etc/squid/allowed_domains.txt\"\r\n\r\n# Nur erlauben: Sandbox-Netz + CONNECT + allowlistete Domains\r\nhttp_access allow vmnet CONNECT allowed_domains\r\n\r\n# Alles andere blockieren\r\nhttp_access deny all\u003c/code\u003e\u003c/pre\u003e\u003c/div\u003e\u003c/figure\u003e\n\n\u003cp\u003eDie Liste \u003ccode\u003eallowed_domains.txt\u003c/code\u003e lässt sich einfach so konfigurieren, dass nur bestimmte Domains oder Wildcards erlaubt sind:\u003c/p\u003e\n\n\u003cfigure\u003e\u003cdiv class=\"highlight\" title=\"\"\u003e\u003cpre class=\"\"\u003e\u003ccode\u003eexample.org\r\n.openai.com\u003c/code\u003e\u003c/pre\u003e\u003c/div\u003e\u003c/figure\u003e\n\n\u003ch3 id=\"vm-so-konfigurieren-dass-sie-den-proxy-auf-dem-host-nutzt\"\u003eVM so konfigurieren, dass sie den Proxy auf dem Host nutzt\u003c/h3\u003e\n\n\u003cp\u003eDass auf dem Host ein Proxy läuft, ist schön und gut – aber wenn die Development-Sandbox ihn nicht nutzt, bringt das wenig. Als Nächstes musste ich die Umgebung so einrichten, dass die Tools ihren Traffic tatsächlich über den Proxy auf dem Host routen.\u003c/p\u003e\n\n\u003cp\u003eViele Tools (z. B. \u003ccode\u003ecurl\u003c/code\u003e oder Coding-Agents wie \u003ccode\u003ecodex\u003c/code\u003e und \u003ccode\u003eclaude\u003c/code\u003e) verstehen die folgende Konfiguration:\u003c/p\u003e\n\n\u003cfigure\u003e\u003cdiv class=\"highlight\" title=\"\"\u003e\u003cpre class=\"\"\u003e\u003ccode\u003eexport HOST_IP=\"\u0026lt;My Host IP\u0026gt;\"\r\nexport PROXY_PORT=\"8888\"\r\n\r\nexport HTTPS_PROXY=\"http://$HOST_IP:$PROXY_PORT\"\r\nexport HTTP_PROXY=\"$HTTPS_PROXY\"\r\nexport NO_PROXY=\"localhost,127.0.0.1\"\u003c/code\u003e\u003c/pre\u003e\u003c/div\u003e\u003c/figure\u003e\n\n\u003cp\u003eFür Gradle musste ich zusätzlich meine \u003ccode\u003e~/.gradle/gradle.properties\u003c/code\u003e so konfigurieren, dass Folgendes enthalten ist:\u003c/p\u003e\n\n\u003cfigure\u003e\u003cdiv class=\"highlight\" title=\"\"\u003e\u003cpre class=\"\"\u003e\u003ccode\u003esystemProp.http.proxyHost=\u0026lt;My Host IP\u0026gt;\r\nsystemProp.http.proxyPort=8888\r\n\r\nsystemProp.https.proxyHost=\u0026lt;My Host IP\u0026gt;\r\nsystemProp.https.proxyPort=8888\r\n\r\nsystemProp.http.nonProxyHosts=localhost|127.0.0.1\r\nsystemProp.https.nonProxyHosts=localhost|127.0.0.1\u003c/code\u003e\u003c/pre\u003e\u003c/div\u003e\u003c/figure\u003e\n\n\u003ch3 id=\"erzwingen-dass-die-sandbox-ausschliesslich-uber-den-proxy-kommuniziert\"\u003eErzwingen, dass die Sandbox ausschließlich über den Proxy kommuniziert\u003c/h3\u003e\n\n\u003cp\u003eDas Setup bisher erlaubt der Development-Sandbox, mit dem Proxy über den Host zu kommunizieren – aber es zwingt nicht, dass wirklich \u003cem\u003ejeder\u003c/em\u003e Traffic aus der Sandbox über den Proxy geht. Wenn sich die Coding-Agents an die Regeln halten, bietet das zwar einen gewissen Schutz, aber eben keinen absoluten.\u003c/p\u003e\n\n\u003cp\u003eUm das zu erzwingen, habe ich \u003ca href=\"https://www.netfilter.org/projects/nftables/index.html\"\u003enftables\u003c/a\u003e installiert und die folgende Konfiguration \u003ccode\u003e/etc/nftables-proxy-egress.nft\u003c/code\u003e erstellt:\u003c/p\u003e\n\n\u003cfigure\u003e\u003cdiv class=\"highlight\" title=\"\"\u003e\u003cpre class=\"\"\u003e\u003ccode\u003etable inet sandbox {\r\n  chain output {\r\n    type filter hook output priority 0; policy drop;\r\n\r\n    # Loopback-Traffic erlauben\r\n    oif \"lo\" accept\r\n\r\n    # Bestehende/zugehörige Verbindungen erlauben\r\n    ct state established,related accept\r\n\r\n    # DNS nach außen erlauben (udp/tcp 53).\r\n    # (diese Policy ließe sich verschärfen, indem DNS nur zu bestimmten IPs erlaubt wird)\r\n    udp dport 53 accept\r\n    tcp dport 53 accept\r\n    \r\n    # Lokale Docker-Netze erlauben (für Testcontainers, DBs usw.)\r\n    ip daddr 172.17.0.0/16 accept\r\n    ip daddr 172.18.0.0/16 accept\r\n\r\n    # Traffic zum Proxy erlauben\r\n    ip daddr \u0026lt;My Host Ip\u0026gt; tcp dport 8888 accept\r\n  }\r\n}\u003c/code\u003e\u003c/pre\u003e\u003c/div\u003e\u003c/figure\u003e\n\n\u003cp\u003eIch habe die Regeln mit \u003ccode\u003esudo nft -f /etc/nftables-proxy.egress.nft\u003c/code\u003e geladen und getestet, dass Internetzugriff außerhalb meiner definierten Allowlist nicht möglich ist (z. B. indem ich \u003ccode\u003ecurl\u003c/code\u003e mit deaktivierten Proxy-Environment-Variablen ausführe). Außerdem habe ich mit \u003ccode\u003esudo nft list ruleset\u003c/code\u003e geprüft, dass die Sandbox-Regeln geladen wurden.\u003c/p\u003e\n\n\u003cp\u003eLeider haben die Regeln einen Reboot nicht überlebt. Man kann \u003ca href=\"https://blog.programster.org/nftables-cheatsheet#make-rules-persistent\"\u003edie Regeln persistent machen\u003c/a\u003e, aber das hat bei mir Probleme verursacht: Docker fügt ebenfalls Regeln zu \u003ccode\u003enftables\u003c/code\u003e hinzu, und die müssen vor meinen Sandbox-Regeln aktiv sein, damit meine Integrationstests (die Testcontainers verwenden) korrekt funktionieren. Als Workaround habe ich auf der Linux-VM einen kleinen Service erstellt, der nach Docker läuft und die Regeln ins System einfügt. Das ist meine \u003ccode\u003e/etc/systemd/system/nftables-proxy-egress.service\u003c/code\u003e:\u003c/p\u003e\n\n\u003cfigure\u003e\u003cdiv class=\"highlight\" title=\"\"\u003e\u003cpre class=\"\"\u003e\u003ccode\u003e[Unit]\r\nDescription=Apply nftables proxy egress rules\r\nAfter=network-online.target docker.service\r\nWants=network-online.target\r\nOnFailure=proxy-egress-console-alert.service\r\n\r\n[Service]\r\nType=oneshot\r\nExecStartPre=/usr/sbin/nft -c -f /etc/nftables-proxy-egress.nft\r\nExecStart=/usr/sbin/nft -f /etc/nftables-proxy-egress.nft\r\n\r\n[Install]\r\nWantedBy=multi-user.target\u003c/code\u003e\u003c/pre\u003e\u003c/div\u003e\u003c/figure\u003e\n\n\u003cp\u003eDer Check \u003ccode\u003enft -c\u003c/code\u003e sorgt dafür, dass das System im Fehlerfall sofort abbricht (fail fast). Die Direktive \u003ccode\u003eOnFailure\u003c/code\u003e ruft bei einem Fehler \u003ccode\u003eproxy-egress-console-alert.service\u003c/code\u003e auf. Damit kann ich mich benachrichtigen lassen, falls das Laden der Regeln fehlschlägt. Sonst würde ich es womöglich gar nicht merken, dass der Service nicht läuft und die Netzwerkregeln nicht geladen wurden – und würde das System nutzen, ohne die Sicherheit zu haben, dass die VM wirklich \u003cem\u003eallen\u003c/em\u003e Traffic über den Host leitet.\u003c/p\u003e\n\n\u003cp\u003eHier ist meine \u003ccode\u003e/etc/systemd/system/proxy-egress-console-alert.service\u003c/code\u003e, die bei Problemen einfach die Datei \u003ccode\u003e/var/lib/nft-egress-failed\u003c/code\u003e anlegt.\u003c/p\u003e\n\n\u003cfigure\u003e\u003cdiv class=\"highlight\" title=\"\"\u003e\u003cpre class=\"\"\u003e\u003ccode\u003e[Unit]\r\nDescription=Console alert if nftables proxy egress fails\r\n\r\n[Service]\r\nType=oneshot\r\nExecStart=/usr/bin/touch /var/lib/nft-egress-failed\u003c/code\u003e\u003c/pre\u003e\u003c/div\u003e\u003c/figure\u003e\n\n\u003cp\u003eDanach habe ich ein paar Zeilen in meine \u003ccode\u003e~/.bashrc\u003c/code\u003e aufgenommen, die meinem Prompt eine blinkende \u003ccode\u003e🚨🚨 NFT-EGRESS-FAILED 🚨🚨\u003c/code\u003e-Meldung hinzufügen, um mich zu warnen, dass das Laden der Egress-Regeln fehlgeschlagen ist:\u003c/p\u003e\n\n\u003cfigure\u003e\u003cdiv class=\"highlight\" title=\"\"\u003e\u003cpre class=\"\"\u003e\u003ccode\u003eif [ -f /var/lib/nft-egress-failed ]; then\r\n\r\n  PS1='\\[\\033[5;1;31m\\]🚨🚨 NFT-EGRESS-FAILED 🚨🚨\\[\\033[0m\\]\\n\\[\\033[1;31m\\]\\u@\\h:\\w\\$ \\[\\033[0m\\]'\r\n\r\nfi\u003c/code\u003e\u003c/pre\u003e\u003c/div\u003e\u003c/figure\u003e\n\n\u003cp\u003eAls der Service stand, habe ich ihn neu geladen und neu gestartet:\u003c/p\u003e\n\n\u003cfigure\u003e\u003cdiv class=\"highlight\" title=\"\"\u003e\u003cpre class=\"\"\u003e\u003ccode\u003esudo systemctl daemon-reload\r\nsudo systemctl restart nftables-proxy-egress.service\u003c/code\u003e\u003c/pre\u003e\u003c/div\u003e\u003c/figure\u003e\n\n\u003cp\u003eEin Kollege hat vorgeschlagen, bei einem Fehler gleich das komplette Netzwerk offline zu nehmen. Als ich das ausprobiert habe, habe ich es allerdings geschafft, die ganze VM zu „bricken“, weil Limas \u003ccode\u003eshell\u003c/code\u003e-Kommando via \u003ccode\u003essh\u003c/code\u003e über das Netzwerk mit der VM kommuniziert. Deshalb bleibe ich vorerst bei der blinkenden Prompt-Meldung. Dazu möchte ich auch anmerken: Dass ich mit \u003ccode\u003enftables\u003c/code\u003e herumfummeln muss, um sämtlichen Traffic über einen Proxy auf dem Host zu routen, ist möglicherweise eine Einschränkung der VM-Technologie, die ich gewählt habe. Wenn du eine VM nutzt, die mit \u003ca href=\"https://developer.hashicorp.com/vagrant\"\u003eVagrant\u003c/a\u003e provisioniert werden kann (z. B. \u003ca href=\"https://www.virtualbox.org/\"\u003eVirtual Box\u003c/a\u003e), gibt es ein \u003ca href=\"https://www.devopsroles.com/vagrant-proxy-configuration/\"\u003ePlugin\u003c/a\u003e, mit dem sich das deklarativ definieren lässt.\u003c/p\u003e\n\n\u003cp\u003eAls letzten Quick-Check ist wichtig sicherzustellen, dass \u003ccode\u003enft\u003c/code\u003e, die Konfiguration \u003ccode\u003e/etc/nftables-proxy-egress.nft\u003c/code\u003e sowie die Services \u003cstrong\u003enur von root veränderbar\u003c/strong\u003e sind! Sonst könnte ein Agent theoretisch diese Regeln so abändern, dass er das Netzwerk wieder öffnet – mit deinen Rechten.\u003c/p\u003e\n\n\u003ch3 id=\"traffic-beobachten-und-allowlist-erweitern\"\u003eTraffic beobachten und Allowlist erweitern\u003c/h3\u003e\n\n\u003cp\u003eZum Schluss beobachte ich den Traffic aus der VM und erweitere die Allowlist so, dass die Requests durchgehen, die wir im Entwicklungsalltag brauchen. Die Logs von Squid kann man auf der Kommandozeile einsehen (bei mir unter \u003ccode\u003e/opt/homebrew/var/logs/access.log\u003c/code\u003e).\u003c/p\u003e\n\n\u003cfigure\u003e\u003cdiv class=\"highlight\" title=\"\"\u003e\u003cpre class=\"\"\u003e\u003ccode\u003esudo tail -f /opt/homebrew/var/logs/access.log\u003c/code\u003e\u003c/pre\u003e\u003c/div\u003e\u003c/figure\u003e\n\n\u003cp\u003eJeder Request, der verworfen wird, wird mit der Methode \u003ccode\u003eTCP_DENIED\u003c/code\u003e geloggt. Wenn du Requests zu dieser URL erlauben willst, kannst du deine \u003ccode\u003eallowed_domains.txt\u003c/code\u003e um die neue Domain ergänzen und Squid neu starten.\u003c/p\u003e\n\n\u003cfigure\u003e\u003cdiv class=\"highlight\" title=\"\"\u003e\u003cpre class=\"\"\u003e\u003ccode\u003ebrew services restart squid\u003c/code\u003e\u003c/pre\u003e\u003c/div\u003e\u003c/figure\u003e\n\n\u003cp\u003eIn der Praxis musste ich diese Liste bislang nur selten anpassen. Ich habe 12 URLs in meiner Allowlist, und das reicht offenbar aus. Ich habe zwar Package-Registries für Gradle und npm in der Liste – was theoretisch Supply-Chain-Angriffe ermöglicht –, aber das Risiko ist stark reduziert, und ich fühle mich endlich wohl damit, meine Guardrails etwas zu lockern und zu sehen, was meine Agents leisten.\u003c/p\u003e\n\n\u003ch4 id=\"coding-agents-zum-programmieren-chatbots-zum-suchen\"\u003eCoding-Agents zum Programmieren, Chatbots zum Suchen\u003c/h4\u003e\n\n\u003cp\u003eEin Grund, warum die URL-Liste so kurz ist: Standardmäßig holen sich die Coding-Agents nur die Application-Dependencies (aus Maven- oder npm-Repositories) und kommunizieren mit den LLMs direkt über die APIs der jeweiligen Anbieter (z. B. OpenAI oder Anthropic). Von sich aus machen Coding-Agents keine Websuche, solange man das nicht explizit anfordert. Das heißt: Beim Programmieren beziehen sie ihre Informationen aus den Modellen – nicht von irgendwelchen beliebigen Websites im Internet. Das reduziert das Risiko von Prompt Injection.\u003c/p\u003e\n\n\u003cp\u003eEin Proxy vor den Coding-Agents bedeutet für mich außerdem zusätzliche Reibung, wenn ich Websuche in den Agents aktivieren wollte. Dann müsste ich den Proxy vorübergehend deaktivieren oder anpassen und selbst wieder in der Schleife sein, um jeden Webrequest zu genehmigen, den der Agent ausführen will. Das will ich nicht, weil ich in der Sandbox oft länger laufende Tasks habe, bei denen der Proxy dauerhaft aktiv bleiben soll.\u003c/p\u003e\n\n\u003cp\u003ePraktisch heißt das: Für reine Programmieraufgaben verlasse ich mich ausschließlich auf die Modelle ohne Websuche. Und wenn ich Websuche will, um die aktuellsten Informationen zu finden, nutze ich Chatbots im Browser. Aus Sicht der lethal trifecta ist das ideal: Die langen Tasks ohne direkte Aufsicht haben nur Zugriff auf einen begrenzten Datenausschnitt und extrem eingeschränkten Netzwerkzugang. Die kurzen Recherche-Tasks mit Websuche haben zwar Internetzugang, finden aber im Browser statt – mit extrem begrenztem Zugriff auf Daten.\u003c/p\u003e\n\n\u003ch3 id=\"mogliche-nachste-schritte-das-sahnehaubchen\"\u003eMögliche nächste Schritte: Das Sahnehäubchen\u003c/h3\u003e\n\n\u003cp\u003eFür mein aktuelles Threat Model bin ich mit der Lösung aus diesem Artikel zufrieden. Es gibt aber ein paar weitere Schritte, mit denen man die Sandbox noch stärker machen könnte. Einer davon wäre, Network-Analyse- und Threat-Detection-Software wie \u003ca href=\"https://suricata.io/\"\u003eSuricata\u003c/a\u003e in die Sandbox-Lösung zu integrieren. Dann würde man bei auffälligem Verhalten direkt alarmiert und könnte leichter nachvollziehen, was schiefgelaufen ist. In eine ähnliche Richtung geht Digital-Forensics-Software wie \u003ca href=\"https://github.com/Velocidex/velociraptor\"\u003eVelociraptor\u003c/a\u003e: Damit ließen sich detaillierte Informationen sammeln, was innerhalb der Sandbox tatsächlich passiert. Das würde Einblicke in laufende Prozesse geben und helfen festzustellen, ob es bösartiges Verhalten gab. Außerdem möchte ich die DNS-Konfiguration in der nftables-Regel noch weiter verschärfen, um Datenexfiltration via DNS-Tunneling zu verhindern.\u003c/p\u003e\n\n\u003ch3 id=\"den-coding-agents-mehr-freiraum-geben\"\u003eDen Coding-Agents mehr Freiraum geben\u003c/h3\u003e\n\n\u003cp\u003eAn diesem Punkt habe ich für jeden Teil der lethal trifecta Gegenmaßnahmen. Eine VM mit so wenigen Privilegien wie möglich stellt die Sandbox für meine Coding-Agents bereit und sorgt dafür, dass sie keine kritischen Daten erreichen können, die im Kompromittierungsfall leaken würden. Und dadurch, dass ich den gesamten Traffic durch einen Proxy auf dem Host mit sehr strikter Allowlist zwinge, begrenze ich sowohl die Exposition gegenüber nicht vertrauenswürdigen Inhalten als auch die Möglichkeit, nach außen zu kommunizieren, massiv.\u003c/p\u003e\n\n\u003cp\u003eAuf dieser Basis fühle ich mich endlich wohl dabei, die strikten Guardrails meiner Coding-Agents zu lockern. \u003ccode\u003ecodex --yolo\u003c/code\u003e und \u003ccode\u003eclaude --dangerously-skip-permissions\u003c/code\u003e zu nutzen, war richtig spannend, weil ich damit detaillierte, mehrstufige Aufgaben definieren kann, die meine Agents ausführen, ohne dass ich permanent in der Schleife bleiben und alles überwachen muss. Das verschafft mir wiederum \u003ca href=\"https://www.innoq.com/en/blog/2026/01/what-to-do-while-ai-is-thinking/\"\u003emehr Zeit für andere Aufgaben\u003c/a\u003e, ohne mich mental zu überlasten, weil ich meinen Fokus nicht ständig wechseln muss. Ich möchte aber klar betonen: Dass ich diese Guardrails lockere, halte ich nur deshalb für vertretbar, weil ich meine Sandbox und Netzwerk-Policy so aufgebaut habe, dass sie sogar mehr Schutz bieten als die Agent-Tools allein.\u003c/p\u003e\n\n\u003cp\u003eMeine aktuelle Lösung ist noch sehr grundlegend, aber ich glaube, sie liefert ein solides Fundament, auf dem ich weitere Features aufbauen kann, ohne Sicherheit zu opfern.\u003c/p\u003e\n\u003c/body\u003e\u003c/html\u003e\n","image":"https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2000/v1/uploads-production/e1nhc9keulsjuu7jq8otyle3gnl6?_a=BACMTiAE"},{"id":"https://www.innoq.com/de/blog/2026/02/jeder-kann-architekt-sein/","url":"https://www.innoq.com/de/blog/2026/02/jeder-kann-architekt-sein/","date_published":"2026-02-24T00:00:00.000+00:00","date_modified":"2026-02-24T11:59:31.347+01:00","author":[{"name":"Holger Kraus","url":"https://www.innoq.com/ch/staff/holger-kraus/"}],"content_html":"\u003c!DOCTYPE html PUBLIC \"-//W3C//DTD HTML 4.0 Transitional//EN\" \"http://www.w3.org/TR/REC-html40/loose.dtd\"\u003e\n\u003chtml\u003e\u003cbody\u003e\n\u003cp\u003eAls man mich erstmals fragte, ob ich die Rolle des Architekten in einem Projekt übernehmen wolle, hatte ich viele Zweifel. Nicht wegen fehlenden Architekturwissens, sondern wegen einiger offenen Fragen:\u003c/p\u003e\n\n\u003cp\u003e\u003cem\u003eWie stehe ich als Architekt zum Team? Bin ich übergeordnet? Treffe ich alle wichtigen Entscheidungen selbst?\nWie kommuniziere ich Entscheidungen ins Team? Wie bekomme ich Akzeptanz für diese Entscheidungen?\u003c/em\u003e\u003c/p\u003e\n\n\u003cp\u003eEine Weiterbildung in Facilitation half mir, Antworten zu finden – und die Rolle auf Augenhöhe zu gestalten.\nIch möchte hier \u003cstrong\u003emeine persönliche Lernreise\u003c/strong\u003e teilen – mit all jenen, die sich heute ähnliche Fragen stellen wie ich mir damals.\u003c/p\u003e\n\n\u003cp\u003eMeine hier geschilderten Gedanken und Erfahrungen verstehen sich als Denkanstoß, nicht als allgemeingültiges Modell. Entscheidet selbst, welche Ideen für euch in eurem organisatorischen Kontext umsetzbar sind.\u003c/p\u003e\n\n\u003ch3 id=\"traditionelles-hierarchisches-verstandnis-von-fuhrung\"\u003eTraditionelles, hierarchisches Verständnis von Führung\u003c/h3\u003e\n\n\u003cp\u003eAls ich erstmals mit der Architektenrolle konfrontiert war, weckte sie in mir traditionelle Vorstellungen von \u003cstrong\u003eFührung\u003c/strong\u003e. Ich dachte an Hierarchie und klare Machtverhältnisse. Unser Verständnis von Führung hat sich über Jahrhunderte entwickelt. Es bildet eine eigene umfangreiche Fachdisziplin, die den Rahmen dieses Artikels sprengen würde. Deshalb betrachte ich nicht einzelne Strömungen im Detail. Stattdessen skizziere ich eine historische Linie, die viele Menschen geprägt hat. Auch mich selbst, bis mir das bewusst wurde. Gerade weil diese Prägungen oft unbewusst bleiben, wirken sie stark und entziehen sich der Kritik.\u003c/p\u003e\n\n\u003cp\u003eMilitär, Schule, Bürokratie und Frühindustrialisierung formten lange ein \u003cstrong\u003eautoritäres Führungsbild\u003c/strong\u003e. Führung bedeutete: oben entscheiden, unten ausführen. Die Führungskraft gibt vor, was zu tun ist. Das Team folgt. Kommunikation verläuft von oben nach unten. Mitarbeitende erhalten nur die Informationen, die sie für ihre Aufgabe brauchen. Der strategische Kontext fehlt. Auch die Begründung für Entscheidungen bleibt oft aus. Diese Informationsknappheit ist kein Zufall. Sie stabilisiert die hierarchische Macht. Wer wenig weiß, stellt weniger Fragen.\u003c/p\u003e\n\n\u003cp\u003eEin weiteres Merkmal dieses Führungsstils ist \u003cstrong\u003estrenge Kontrolle\u003c/strong\u003e. Prozesse und Ergebnisse stehen unter dauernder Beobachtung. Bei der Verantwortung entsteht ein Paradox. Die autoritäre Führungskraft beansprucht Verantwortung für Entscheidungen und Ergebnisse. Scheitert das Vorhaben, verschiebt sich die Deutung. Plötzlich gilt nicht die Entscheidung als falsch, sondern ihre Umsetzung durch das Team. Diese Dynamik erzeugt Angst und fördert Risikovermeidung. \u003cem\u003e„Dienst nach Vorschrift“\u003c/em\u003e wird so zu einem rationalen Selbstschutz der Mitarbeitenden.\u003c/p\u003e\n\n\u003ch3 id=\"vor-und-nachteile-des-autoritaren-fuhrungsstils\"\u003eVor- und Nachteile des autoritären Führungsstils\u003c/h3\u003e\n\n\u003cp\u003eHätte der autoritäre Führungsstil nur Nachteile, hätte er sich kaum durchgesetzt. Seine Stärken liegen in \u003cstrong\u003eSchnelligkeit, Kontrolle und klaren Regeln\u003c/strong\u003e. In Bereichen wie der Fertigung oder bei Rettungsdiensten sind sie entscheidend. Dort sind Abweichungen von bewährten Abläufen ineffizient oder gefährlich.\nDiese Aspekte werden jedoch in der Wissensökonomie zum Problem. Hier entsteht Wert durch Innovation, Zusammenarbeit und Anpassungsfähigkeit. Dafür taugt ein autoritärer Führungsstil kaum. Denn er führt dazu, dass Mitarbeiter und Mitarbeiterinnen Verantwortung meiden. Sie halten sich lieber strikt an Vorgaben. Kreativität und Kompetenzen bleiben ungenutzt.\u003c/p\u003e\n\n\u003cp\u003eAuf Seiten der Geführten entsteht das Gefühl geringer Wertschätzung. Eigeninitiative wird gebremst. Selbstständigkeit und Eigenverantwortung entwickeln sich kaum. Auf Seiten der Führungskraft wächst der Druck. Alles läuft bei ihr zusammen. Das erzeugt Stress und Überforderung.\nHinzu kommt ein \u003cstrong\u003estrukturelles Problem\u003c/strong\u003e: Mitarbeiter kennen die Details ihrer täglichen Arbeit meist besser als ihre Vorgesetzten. Wer trotzdem alles vorgeben will, verhindert gute Ergebnisse. Und überfordert sich selbst.\u003c/p\u003e\n\n\u003ch3 id=\"falsche-grundannahmen-uber-die-architekten-rolle\"\u003eFalsche Grundannahmen über die Architekten-Rolle\u003c/h3\u003e\n\n\u003cp\u003eIch glaube, den autoritären Führungsstil haben wir in der Softwareentwicklung weitgehend hinter uns gelassen. Kaum ein Entwickler oder eine Entwicklerin möchte heute unter solchen Bedingungen arbeiten. Alle Versuche ein Entwicklungsteam autoritär und hierarchisch zu führen, die ich miterleben musste, fand ich nicht überzeugend und kontraproduktiv.\u003c/p\u003e\n\n\u003cp\u003e\u003cstrong\u003eTrotzdem prägt dieses Führungsbild noch unsere Erwartungen.\u003c/strong\u003e Wenn wir spontan an einen Vorgesetzten denken, taucht oft das alte Muster auf. So ging es mir, als ich erstmals ein Entwicklungsteam als Architekt begleiten sollte. Verstärkt wurde dieses Bild durch die Vorstellung des Elfenbeinturm-Architekten: weit oben in der Hierarchie, allein entscheidend.\u003c/p\u003e\n\n\u003cp\u003eDieses \u003cstrong\u003eNegativbild\u003c/strong\u003e ist in vielen Köpfen präsent. Es prägt, wie wir die Architektenrolle wahrnehmen. Auch ich fühlte mich anfangs unwohl. Ich glaubte, nun Architekturvorgaben machen zu müssen. In einem Team aus sehr kompetenten Entwickler:innen erzeugt diese Annahme enormen Druck.\nIch fragte mich, ob ich mir anmaßen darf, technische Vorgaben zu machen. Und ob ich damit im Team Anerkennung finden würde. Trotzdem habe ich mich auf die Rolle eingelassen. Ich vertraute darauf, im Projekt zu lernen, wann und wobei das Team wirklich einen Architekten braucht.\u003c/p\u003e\n\n\u003cp\u003eDie \u003cstrong\u003eErkenntnisse aus diesem Lernprozess\u003c/strong\u003e bilden den Kern dieses Textes.\u003c/p\u003e\n\n\u003ch3 id=\"uber-die-bedeutung-von-grundannahmen\"\u003eÜber die Bedeutung von Grundannahmen\u003c/h3\u003e\n\n\u003cp\u003eMeine Annahme, ich müsse als Architekt alles wissen und klare Vorgaben machen, hat mich selbst eingeschränkt. Deshalb möchte ich über die Bedeutung von \u003cstrong\u003eGrundannahmen für die Rolle des Facilitators\u003c/strong\u003e sprechen.\u003c/p\u003e\n\n\u003cp\u003eGrundannahmen sind Glaubenssätze basierend auf früheren Erfahrungen. Sie prägen unsere Wahrnehmung stark. Oft wirken sie unbewusst – und genau deshalb sind sie mächtig. Hätte ich meine Annahmen nicht hinterfragt, hätte ich die Architektenrolle abgelehnt. Ich hätte sie als Überforderung erlebt. Erst der Gedanke, dass diese Annahme falsch sein könnte, gab mir den Mut, der Rolle eine Chance zu geben.\u003c/p\u003e\n\n\u003cp\u003eGrundannahmen beeinflussen, wie wir Realität deuten und wie wir uns in Gruppen verhalten. Sie können unseren Handlungsspielraum erweitern oder einengen. Ob eine Grundannahme „wahr“ ist, ist dabei zweitrangig bzw. die Diskussion darüber hilft uns nicht. Entscheidend ist eine andere Frage:\u003c/p\u003e\n\n\u003cp\u003e\u003cstrong\u003eWas ermöglicht sie mir?\u003c/strong\u003e\u003c/p\u003e\n\n\u003cp\u003eWenn ich feststelle, dass ich Grundannahmen habe, die hinderlich für meine Arbeit sind, kann ich mich bewusst damit auseinandersetzen und überlegen, welche Grundannahmen für eine gegebene Situation hilfreicher sind. Durch die Veränderung von Grundannahmen kann sehr viel Bewegung (in mir oder einer Gruppe)\nentstehen. Sich in einem Team darüber klar zu werden, auf welchen Grundannahmen die gemeinsame Arbeit beruht, kann die Zusammenarbeit erheblich verbessern.\u003c/p\u003e\n\n\u003cblockquote\u003e\n\u003cp\u003eWer noch mehr über Grundannahmen lesen möchte, kann das \u003ca href=\"https://kommunikationslotsen.de/facilitative-thinking-teil-1-warum-grundannahmen-fuer-die-eigene-entwicklung-so-enorm-wichtig-sind/\"\u003ehier\u003c/a\u003e tun.\u003c/p\u003e\n\u003c/blockquote\u003e\n\n\u003cp\u003eIm Folgenden beschreibe ich die Grundannahmen, die sich für mich in der Architektenrolle bewährt haben und mein Handeln leiten:\u003c/p\u003e\n\n\u003cul\u003e\n\u003cli\u003e Architekturentscheidungen werden gelebt, wenn die Betroffenen \u003cstrong\u003ean der Entscheidung beteiligt\u003c/strong\u003e waren und ihre Ziele verstehen. Deshalb werden sie gemeinsam vom Team und möglichst im Konsens getroffen.\u003c/li\u003e\n\u003cli\u003e Entwickler und Entwicklerinnen bringen meist eine \u003cstrong\u003ehohe intrinsische Motivation\u003c/strong\u003e mit. Sie wollen gute Software bauen und schätzen es, wenn man ihre Kompetenz ernst nimmt.\u003c/li\u003e\n\u003cli\u003e Eine falsche Entscheidung ist besser als keine. \u003cstrong\u003eBewusste Entscheidungen\u003c/strong\u003e senken das Risiko schlechter Entscheidungen. In diesem Zusammenhang verweise ich auf \u003ca href=\"https://architectelevator.com/gregors-law\"\u003eGregors’s Law\u003c/a\u003e.\u003c/li\u003e\n\u003cli\u003e Unter Zeitdruck fehlt oft der Abstand für grundlegende Architekturfragen. Als Architekt erkenne ich diese Situationen und schaffe \u003cstrong\u003eRaum für Entscheidungen\u003c/strong\u003e.\u003c/li\u003e\n\u003cli\u003e Langfristige Ergebnisse lassen sich schwer vorhersagen. Die Qualität des Entscheidungsprozesses lässt sich aber bewerten. Dafür braucht es eine \u003cstrong\u003eklare, verständliche Struktur\u003c/strong\u003e. Diese Struktur zu etablieren ist meine Aufgabe als Architekt.\u003c/li\u003e\n\u003cli\u003e Ich weiß nicht alles besser als mein Team. Deshalb sorge ich dafür, dass die \u003cstrong\u003epassende Fachexpertise beteiligt\u003c/strong\u003e ist und gehört wird.\u003c/li\u003e\n\u003cli\u003e Softwareentwicklung ist \u003cstrong\u003eCo-Creation\u003c/strong\u003e. Alle tragen Verantwortung für die Produktqualität. Jede Perspektive zählt und verdient Beachtung.\u003c/li\u003e\n\u003c/ul\u003e\n\n\u003ch3 id=\"wie-ich-meine-rolle-als-architekt-sehe\"\u003eWie ich meine Rolle als Architekt sehe\u003c/h3\u003e\n\n\u003cp\u003eAus obigen Grundannahmen leite ich \u003cstrong\u003emein Rollenverständnis als Architekt\u003c/strong\u003e ab:\u003c/p\u003e\n\n\u003cp\u003eIch verstehe mich als Begleiter des Entwicklungsteams, nicht als hierarchisch übergeordnete Person. Meine Aufgabe ist es, das Team dabei zu unterstützen, bewusste Architekturentscheidungen zu treffen. Diese Entscheidungen sollen die funktionalen und qualitativen Ziele des Projekts erreichen helfen. Ich achte darauf, dass fehlende Architekturentscheidungen das Projekt nicht blockieren – auch dann, wenn sie außerhalb meines direkten Verantwortungsbereichs liegen. Ebenso verhindere ich, dass sich eine Architektur unbewusst verfestigt, nur weil Entscheidungen ausbleiben. Als Architekt etabliere ich im Team eine Kultur bewusster Architekturentscheidungen. Das Ziel ist, dass das Team diese Entscheidungen auch ohne meine Anwesenheit treffen kann. Ich trage Verantwortung dafür, dass das Team fokussiert und sinnvoll arbeiten kann – und so die Projektziele erreichen kann.\u003c/p\u003e\n\n\u003ch3 id=\"wie-setze-ich-diese-rolle-um\"\u003eWie setze ich diese Rolle um?\u003c/h3\u003e\n\n\u003cp\u003eIn der Facilitation hat der Gastgeber bzw. die Gastgeberin eine Schlüsselrolle. Kurz gesagt: \u003cstrong\u003eAls Facilitator schaffe ich den Rahmen für einen Kommunikationsprozess\u003c/strong\u003e – und halte ihn. Ich halte das auch als Architekt für meine Aufgabe. Als Gastgeber übernehme ich Verantwortung für gute Architekturentscheidungen. Ich sorge dafür, dass Verantwortliche, Betroffene und Experten und Expertinnen miteinander sprechen und gemeinsam entscheiden können. Dafür gestalte ich den Rahmen. Ich kläre zuerst: \u003cem\u003eWer muss mit wem worüber sprechen?\u003c/em\u003e Dann lade ich diese Personen ein. Ich formuliere ein klares Ziel und setze eine Agenda. So bringe ich Entscheidungen voran – ohne Druck. Schon die Einladung, das Ziel und der Rahmen erzeugen Bewegung. Ich ebne allen Beteiligten den Weg zur Entscheidung. Diese Gastgeberrolle übernehme ich nicht nur für mein eigenes Team. Ich tue es immer dann, wenn mein Team eine Entscheidung braucht. Manchmal heißt das auch: Ich bringe mehrere Teams zusammen, etwa bei systemübergreifenden Architekturentscheidungen.\nDen inhaltlichen Rahmen richte ich an der Anatomie einer guten Architekturentscheidung aus. Sie beschreibt die Bausteine einer Entscheidung und ihre sinnvolle Reihenfolge. Im Folgenden erläutere ich diese Bestandteile.\u003c/p\u003e\n\n\u003ch3 id=\"die-anatomie-einer-guten-architekturentscheidung\"\u003eDie Anatomie einer guten Architekturentscheidung\u003c/h3\u003e\n\n\u003ch4 id=\"1-stakeholder-benennen\"\u003e1. Stakeholder benennen\u003c/h4\u003e\n\n\u003cp\u003eBevor ich mich mit Technik befasse, kläre ich folgende Fragen:\u003c/p\u003e\n\n\u003cul\u003e\n\u003cli\u003e\u003cem\u003eWen betrifft die Architekturentscheidung?\u003c/em\u003e\u003c/li\u003e\n\u003cli\u003e\u003cem\u003eWelche technischen oder fachlichen Experten und Expertinnen brauche ich für eine fundierte Beratung?\u003c/em\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\n\u003cp\u003eDiese Personen benenne ich ausdrücklich als \u003cstrong\u003eStakeholder\u003c/strong\u003e der anstehenden Entscheidung. Dazu zählen oft auch Personen in der Organisation, die hierarchisch über mir stehen. Sie sollen die Entscheidung mittragen und im Zweifel Verantwortung übernehmen. Wie stark ich einzelne Stakeholder einbeziehe, hängt von Organisation und Auftrag ab. Doch eines gilt immer: Für jede benannte Person überlege ich bewusst, wie und wann ich sie in den Entscheidungsprozess einbinde.\u003c/p\u003e\n\n\u003ch4 id=\"2-problem-definieren-und-kontext-beschreiben\"\u003e2. Problem definieren und Kontext beschreiben\u003c/h4\u003e\n\n\u003cp\u003eErst wenn ich die Stakeholder kenne, befasse ich mich mit dem \u003cstrong\u003eInhalt der Entscheidung\u003c/strong\u003e. Zunächst kläre ich gemeinsam mit allen Beteiligten, welches Problem wir lösen wollen. Präzision ist hier entscheidend. Sie deckt Missverständnisse früh auf. Die \u003cstrong\u003eProblemdefinition\u003c/strong\u003e beschreibt den technischen und organisatorischen Kontext der Architekturentscheidung. Sie macht Rahmenbedingungen und Herausforderungen sichtbar. Alle Beteiligten sollen verstehen, welche funktionalen und Qualitätsziele die Entscheidung erfüllen muss. Aus den Zielen leite ich die \u003cstrong\u003eKriterien\u003c/strong\u003e ab, die eine gute Lösungsoption erfüllen muss. Die Kriterien benenne ich explizit. Die können mir später bei der Bewertung der Lösungsoptionen als Checkliste dienen.\nÜber diese Problemdefinition erzielen wir einen Konsens. Sie bildet die Grundlage für den weiteren Entscheidungsprozess.\u003c/p\u003e\n\n\u003ch4 id=\"3-erforschung-des-losungsraums\"\u003e3. Erforschung des Lösungsraums\u003c/h4\u003e\n\n\u003cp\u003eIn dieser Phase erkunde ich den Lösungsraum zusammen mit den Stakeholdern in voller Breite. Wir sammeln konkrete Lösungsoptionen, benennen sie und beschreiben sie so weit, dass klar wird: \u003cem\u003eWie kann diese Option die Ziele erreichen?\u003c/em\u003e Dabei lernen wir viel über die Sichtweisen der Beteiligten auf das Problem. Das hilft doppelt: Stakeholder können ihre Perspektive früh einbringen – und sie spüren, dass sie ernst genommen werden.\nWichtig ist: \u003cstrong\u003eWir legen uns nicht zu früh auf eine Idee fest.\u003c/strong\u003e Wir gehen auch nicht sofort ins Detail. Sonst verlieren wir leicht Alternativen aus dem Blick, die eine bessere Lösung wären. Erst wenn keine neuen Optionen mehr auftauchen, wechseln wir die Ebene: Dann gehen wir in die Tiefe und bewerten die Optionen.\u003c/p\u003e\n\n\u003ch4 id=\"4-untersuchung-und-bewertung-der-losungsoptionen\"\u003e4. Untersuchung und Bewertung der Lösungsoptionen\u003c/h4\u003e\n\n\u003cp\u003eSobald wir die Lösungsoptionen überblicken, beginnen wir mit der \u003cstrong\u003eBewertung\u003c/strong\u003e. Wir bewerten, inwieweit eine Lösungsoption unsere Kriterien für eine geeignete Lösung erfüllt. Zusätzlich sammeln wir die positiven und negativen Aspekte dieser Lösungsoption. Bei den negativen Aspekten prüfen wir, ob es Maßnahmen gibt, die sie mindern oder ganz beseitigen können. Daraus entstehen manchmal neue Lösungsoptionen. Manche Lösungsoptionen werfen viele Fragen auf, die auf den ersten Blick nicht leicht zu beantworten sind. Dann lohnt es sich, diese Option genauer zu erforschen und zu prüfen. Ein geeignetes Mittel kann die Implementierung eines \u003cstrong\u003eProof of Concept\u003c/strong\u003e sein. Er testet Annahmen und schafft Klarheit. Der Aufwand muss dabei zur Bedeutung der Entscheidung passen.\u003c/p\u003e\n\n\u003ch4 id=\"5-entscheidung-treffen-und-dokumentieren\"\u003e5. Entscheidung treffen und dokumentieren\u003c/h4\u003e\n\n\u003cp\u003eEs gibt keine feste Formel für gute Entscheidungen. Meine Erfahrung zeigt aber: Wer Lösungsoptionen offen und strukturiert prüft, erkennt im Verlauf oft eine geeignete Lösung. Die Gründe dafür werden klar – und damit auch die Basis der Entscheidung. Entscheidend ist die \u003cstrong\u003eDokumentation\u003c/strong\u003e. Wir halten fest, welcher Aspekt der Lösungsoption den Ausschlag gegeben hat. So wird nachvollziehbar, warum wir uns für diese Option entschieden haben. Ebenso wichtig: Wir beschreiben die Konsequenzen der Entscheidung. Dazu gehören die gewünschten Effekte ebenso wie die Nachteile, die wir bewusst in Kauf nehmen. Beides ist Teil der Entscheidung. Eine so getroffene und dokumentierte Entscheidung lässt sich später überprüfen. Mit Abstand kann man sie bewerten – und daraus für künftige Entscheidungen lernen.\u003c/p\u003e\n\n\u003cfigure\u003e\r\n\u003cimg alt=\"Infographic “Die Anatomie einer guten Architekturentscheidung” zeigt einen 4-schrittigen Weg der Zusammenarbeit: definiere das Problem, leite Kriterien ab, evaluiere Optionen , dokumentiere ADR.\" loading=\"lazy\" srcset=\"https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_400/v1/uploads-production/qc5silpq2nqq4bgkj2fjxm4a574k?_a=BACMTiAE 400w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_800/v1/uploads-production/qc5silpq2nqq4bgkj2fjxm4a574k?_a=BACMTiAE 800w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_1024/v1/uploads-production/qc5silpq2nqq4bgkj2fjxm4a574k?_a=BACMTiAE 1024w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_1200/v1/uploads-production/qc5silpq2nqq4bgkj2fjxm4a574k?_a=BACMTiAE 1200w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_1600/v1/uploads-production/qc5silpq2nqq4bgkj2fjxm4a574k?_a=BACMTiAE 1600w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2048/v1/uploads-production/qc5silpq2nqq4bgkj2fjxm4a574k?_a=BACMTiAE 2048w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2300/v1/uploads-production/qc5silpq2nqq4bgkj2fjxm4a574k?_a=BACMTiAE 2300w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2600/v1/uploads-production/qc5silpq2nqq4bgkj2fjxm4a574k?_a=BACMTiAE 2600w, https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2800/v1/uploads-production/qc5silpq2nqq4bgkj2fjxm4a574k?_a=BACMTiAE 2800w\" sizes=\"(min-width: 1400px) 1024px, 90vw\"\u003e\r\n\r\n\u003cfigcaption\u003eDie Anatomie einer guten Architekturentscheidung in der Übersicht (generiert mit Google Gemini auf Basis meines Textes)\u003c/figcaption\u003e\u003c/figure\u003e\r\n\n\u003ch3 id=\"uber-die-bedeutung-von-architecture-decision-records\"\u003eÜber die Bedeutung von Architecture Decision Records\u003c/h3\u003e\n\n\u003cp\u003e\u003cstrong\u003eArchitecture Decision Records (ADRs)\u003c/strong\u003e sind ein zentrales Werkzeug für meine Arbeit als Architekt. In langlebigen Softwareprojekten geht Wissen verloren. Der Code bleibt. Das Warum verschwindet. Mit jedem Teamwechsel erodiert das Verständnis für frühere Architekturentscheidungen – wenn niemand gegensteuert. ADRs setzen genau hier an. Sie dokumentieren nicht den Zustand der Architektur, sondern den Weg dorthin. Sie halten fest, welche Entscheidung getroffen wurde, warum sie getroffen wurde und welche Alternativen es gab.\u003c/p\u003e\n\n\u003cp\u003eMichael Nygard stellte das Konzept 2007 in \u003ca href=\"https://pragprog.com/titles/mnee2/release-it-second-edition/\"\u003eRelease It!\u003c/a\u003e vor. Breitere Aufmerksamkeit erhielt es 2011 durch seinen Blogbeitrag \u003ca href=\"https://www.cognitect.com/blog/2011/11/15/documenting-architecture-decisions\"\u003eDocumenting Architecture Decisions\u003c/a\u003e. Die ursprüngliche Idee war klar: Ein ADR entsteht, nachdem eine Entscheidung gefallen ist – als Gedächtnis für spätere Teams.\u003c/p\u003e\n\n\u003cp\u003eIch setze einen Schritt früher an. Wir verfassen einen ADR gemeinsam als Team im Rahmen einer Teambesprechung. Das Schreiben wird Teil der Sitzung. Der ADR folgt dabei der Anatomie einer guten Architekturentscheidung. So führen wir die Diskussion entlang eines klaren roten Fadens. Ein ADR ersetzt keinen Entscheidungsprozess. Er macht ihn sichtbar, nachvollziehbar und strukturiert.\u003c/p\u003e\n\n\u003ch3 id=\"wie-gehe-ich-bei-architekturentscheidungen-grosserer-reichweite-vor\"\u003eWie gehe ich bei Architekturentscheidungen größerer Reichweite vor?\u003c/h3\u003e\n\n\u003cp\u003eFür alltägliche Architekturentscheidungen mit begrenzter Wirkung reicht ein gemeinsamer ADR im Team. Wir schreiben ihn im Meeting und entscheiden zügig.\nAnders ist es bei Entscheidungen mit größerer Tragweite. Sie betreffen andere Teams und wichtige Stakeholder. Gibt es dafür einen etablierten Prozess, nutze ich ihn. Gibt es keinen, ergreife ich die Initiative. Erkennt mein Team Klärungsbedarf für ein teamübergreifendes Vorgehen, stoße ich die Klärung an.\nIch starte bewusst asynchron.\u003c/p\u003e\n\n\u003cp\u003eZuerst erstelle ich – allein oder mit dem Team – einen \u003cstrong\u003eADR-Entwurf\u003c/strong\u003e. Ich veröffentliche ihn im internen Wiki. Danach spreche ich gezielt Stakeholder und Experten und Expertinnen aus anderen Teams an, von denen ich fundiertes Feedback erwarte. Sie lesen den Entwurf, kommentieren ihn oder überarbeiten ihn direkt.\u003c/p\u003e\n\n\u003cp\u003eNach der Diskussionsphase lade ich alle Beteiligten zu einer Abschlussbesprechung ein. Dort präsentiere ich den überarbeiteten ADR und zeige, wie das Feedback eingeflossen ist. Idealerweise erreichen wir einen Konsens und dokumentieren die Entscheidung. Kommt kein Konsens zustande, vereinbaren wir klare nächste Schritte. Das kann etwa ein Proof of Concept für eine konkrete Option sein. Er reduziert Unsicherheit und schafft Klarheit. Hier geht es mir um meine Rolle als Host der Architekturentscheidung. Deshalb beschreibe ich nicht alle denkbaren Szenarien. Entscheidend ist: Ich bleibe verantwortlich, bis eine Entscheidung steht. Meine Aufgabe ist es, den Entscheidungsprozess zu führen und voranzubringen.\u003c/p\u003e\n\n\u003cp\u003eKonkret übernehme ich Verantwortung dafür:\u003c/p\u003e\n\n\u003cul\u003e\n\u003cli\u003eden \u003cstrong\u003eProzess\u003c/strong\u003e bei Bedarf zu starten\u003c/li\u003e\n\u003cli\u003eeinen sauberen und vollständigen \u003cstrong\u003eAblauf\u003c/strong\u003e sicherzustellen\u003c/li\u003e\n\u003cli\u003ealle relevanten \u003cstrong\u003eStakeholder\u003c/strong\u003e einzubinden\u003c/li\u003e\n\u003cli\u003e\n\u003cstrong\u003eBlockaden\u003c/strong\u003e früh zu erkennen und aufzulösen\u003c/li\u003e\n\u003cli\u003e\n\u003cstrong\u003enächste Schritte\u003c/strong\u003e klar zu definieren und verbindlich zu verantworten – notfalls selbst\u003c/li\u003e\n\u003cli\u003e\n\u003cstrong\u003eTransparenz\u003c/strong\u003e zu schaffen, wo wir im Prozess stehen, damit jede:r weiß, was gerade erwartet wird\u003c/li\u003e\n\u003cli\u003eaktiv zu prüfen, ob alle wesentlichen Aspekte betrachtet sind, und \u003cstrong\u003efehlende Perspektiven\u003c/strong\u003e gezielt einzubringen\u003c/li\u003e\n\u003cli\u003eEntscheidungen klar zu \u003cstrong\u003edokumentieren\u003c/strong\u003e und die daraus entstehenden Aufgaben als Tickets im Backlog zu verankern\u003c/li\u003e\n\u003c/ul\u003e\n\n\u003cp\u003eÜbernehme ich Verantwortung über die Grenzen meines Teams hinweg, achte ich auf den organisatorischen Kontext. Trete ich jemandem auf die Füße, ist das kontraproduktiv. Meine Erfahrung zeigt jedoch: Initiative und sichtbarer Fortschritt kommen meist gut an. Gemeinsame Entscheidungen schaffen erprobte Verfahren. Wer einen konkreten Entscheidungsprozess gemeinsam durchläuft, legt die Basis für künftige Entscheidungen ähnlicher Größenordnung. Der Prozess funktioniert, weil er sich bewährt hat. Er stammt nicht vom Reißbrett, sondern aus der Praxis.\u003c/p\u003e\n\n\u003cp\u003eWer Architekturentscheidungen in einer Organisation wirksam verankern will, sollte das Buch \u003ca href=\"https://facilitatingsoftwarearchitecture.com/book.html\"\u003eFacilitating Software Architecture\u003c/a\u003e von Andrew Harmel-Law lesen. In diesem Artikel schaue ich auf das Thema aus meiner Rolle als Architekt und auf die Spielräume, die ich dort habe. Das Buch wählt eine andere Perspektive: Es zeigt, wie Organisationen Architektur systematisch verankern können.\u003c/p\u003e\n\n\u003ch3 id=\"ein-artikel-aus-dem-jahr-2026-und-kein-wort-uber-ki\"\u003eEin Artikel aus dem Jahr 2026 – und kein Wort über KI?\u003c/h3\u003e\n\n\u003cp\u003eNatürlich frage auch ich mich, wie \u003cstrong\u003eAgentic Software Engineering\u003c/strong\u003e die Architekturarbeit verändert. Diese Fragen kläre ich nicht nebenbei. Sie verdienen einen eigenen, gründlichen Blick. Ich werde sie in kommenden Artikeln aufgreifen. Eines bleibt für mich zentral: \u003cstrong\u003eBewusste Entscheidungen\u003c/strong\u003e. Daran halte ich fest. Auch im Zeitalter von Agentic Software Engineering – vielleicht dort mehr denn je.\u003c/p\u003e\n\n\u003ch3 id=\"weitere-literatur-empfehlungen-fur-alle-die-tiefer-einsteigen-wollen\"\u003eWeitere Literatur-Empfehlungen für alle, die tiefer einsteigen wollen\u003c/h3\u003e\n\n\u003cul\u003e\n\u003cli\u003eGregor Hohpe diskutiert unterschiedliche Modelle, \u003cstrong\u003eArchitektur-Entscheidungen\u003c/strong\u003e in der Organisation zu verankern, in diesem Artikel \u003ca href=\"https://architectelevator.com/architecture/organizing-architecture/\"\u003ehier\u003c/a\u003e.\u003c/li\u003e\n\u003cli\u003eEin sehr gutes Buch über \u003cstrong\u003eFacilitation\u003c/strong\u003e allgemein, das vieles enthält, das ich in meiner Weiterbildung gelernt habe, ist dieses \u003ca href=\"https://www.vahlen.de/scholz-vesper-facilitation/product/31815387\"\u003ehier\u003c/a\u003e\n\u003c/li\u003e\n\u003cli\u003eGerade schon erwähnt, gehört aber trotzdem in die Übersicht:\u003ca href=\"https://facilitatingsoftwarearchitecture.com/book.html\"\u003eFacilitating Software Architecture\u003c/a\u003e beleuchtet das Thema \u003cstrong\u003eSoftware-Architektur-Facilitation aus organisatorischer Perspektive\u003c/strong\u003e.\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eDer Titel des Artikels erweckte den Eindruck, die Rolle des Architekten bzw. der Architektin komme ohne Voraussetzungen aus. Das sehe ich tatsächlich anders. Die Rolle verlangt Wissen und Erfahrung. Sie verlangt aber nicht, auf jede Frage sofort die beste Antwort zu liefern und diese als Vorgabe zu setzen. Die Einstiegshürde ist daher niedriger, als ich selbst lange dachte.\nWer das hier dargelegte Rollenverständnis umsetzt, demotiviert niemanden mit scheinbar klugen Ansagen. Stattdessen nutzt das Team seine gesamte Kompetenz. Alle bringen ihr Wissen ein, alle gestalten Entscheidungen mit. Wenn alle an der Entscheidung beteiligt waren, dann ist die Wahrscheinlichkeit hoch, dass sie von allen verstanden und umgesetzt wird. Mit diesem Artikel möchte ich junge Entwickler und Entwicklerinnen ermutigen, die Rolle auszuprobieren. Es geht weniger darum, alle Antworten zu kennen. Entscheidend ist, die richtigen Fragen zu stellen und im Team eine Kultur strukturierter Architekturentscheidungen zu etablieren. Ich muss nicht warten, bis mir jemand diese Rolle zuweist, sondern ich kann sofort damit beginnen, Architekturentscheidungen in der dargelegten Form in mein Team einzubringen und so einen Grundstein für eine Kultur strukturierter Architekturentscheidungen zu legen. Niemand braucht Angst zu haben, Fragen zu stellen. Im Zweifel sind kluge Fragen wichtiger als oberflächliche Antworten.\u003c/p\u003e\n\u003c/body\u003e\u003c/html\u003e\n","image":"https://res.cloudinary.com/innoq/image/upload/c_limit,f_auto,q_auto,w_2000/v1/uploads-production/fh5xqcw0il6hwxpe19hzoeecp1kp?_a=BACMTiAE"}]}