Die Spezifikationsschulden

Das klinische Audit

Es gibt Dokumente, die nur zu den falschen Zeitpunkten geöffnet werden. Die DSFA für das klinische Triage-System wurde im April 2024 unterzeichnet und im Compliance-Ordner abgelegt, aus dem sie nie wieder herausgekommen ist, so wie keine DSFA jemals aus dem Compliance-Ordner herauskommt. Achtzehn Monate später öffnet sie jemand. Kein Jurist, sondern ein Berater, der für ein Sicherheits-Audit gekommen ist, und er öffnet sie aus Routinegründen, weil er prüfen will, ob die erklärten Maßnahmen den implementierten entsprechen.

Das Dokument beschreibt ein System, das ein deterministisches Scoring-Modell verwendet, auf einem geschlossenen Datensatz trainiert, mit expliziten Regeln für die Klassifizierung der Dringlichkeit. Die Verarbeitungszwecke sind vier. Die Rechtsgrundlagen sind dem korrekten Erwägungsgrund der Verordnung zugeordnet. Die Rechte der betroffenen Personen sind einzeln aufgeführt, mit den operativen Verfahren, sie auszuüben. Grenzüberschreitende Datenflüsse existieren nicht, weil alles im europäischen Rechenzentrum des Anbieters bleibt. Der Berater liest, macht ein paar Notizen, dann hebt er den Blick und fragt den CIO, ob er das System im Betrieb sehen kann.

Das System im Betrieb ist ein anderes. Drei Monate nach der Unterzeichnung der DSFA hat der Anbieter das deterministische Modell durch einen neuronalen Klassifikator ersetzt, der kontinuierlich auf den klinischen Daten der letzten sechs Monate trainiert. Der Datensatz ist nicht mehr geschlossen. Die Klassifizierungsregeln sind nicht mehr explizit. Die offiziellen Zwecke sind weiterhin vier, aber eine fünfte Funktion wurde auf Anfrage der Notaufnahme hinzugefügt, und es ist eine Funktion, die die DSFA nicht vorsieht. Grenzüberschreitende Datenflüsse existieren weiterhin nicht, bis sie eines Tages doch existieren, weil der Anbieter den Hyperscaler gewechselt hat und nun ein Teil des Datenverkehrs durch ein irisches Rechenzentrum läuft, das von einer US-amerikanischen Tochtergesellschaft betrieben wird. Nichts davon ist anderswo dokumentiert. Das System funktioniert. Die Nutzer sind zufrieden. Die internen Audits werden bestanden, weil sie sich darauf beschränken zu prüfen, dass das System existiert und kohärenten Output liefert.

Der Berater wendet sich an den CIO und fragt, wer die fünfte Funktion autorisiert hat. Der CIO antwortet, es sei eine dringende Anfrage des Notaufnahmeleiters gewesen, in einer Woche bearbeitet, mit dem Anbieter, der am darauffolgenden Donnerstag nach einem Staging-Test in die Produktion ausgerollt hat. Es gibt ein Jira-Ticket, das die Änderung verfolgt, eine Pull Request, von zwei Reviewern genehmigt, ein internes Changelog. Alles in Ordnung auf operativer Ebene. Der Berater fragt, ob die DSFA aktualisiert wurde. Der CIO sieht ihn an mit dem Ausdruck eines Menschen, der nie daran gedacht hat, dass es nötig wäre, weil die DSFA zu einem anderen Kreislauf gehört, von einer anderen Person verwaltet, in einem anderen Ordner, mit Zeiten, die nichts mit den Zeiten der Releases zu tun haben. Der Berater schließt die DSFA und nennt sie nicht mehr DSFA. Er nennt sie Geister-Spezifikation, weil sie ein System beschreibt, das nur auf unterzeichnetem Papier existiert.

Eine gewöhnliche Bedingung

Die Geister-Spezifikation ist, entgegen verbreiteter Meinung, eine gewöhnliche Bedingung. Wer in einer Organisation gearbeitet hat, die Software für einen regulierten Kunden produziert, oder für sich selbst unter reguliertem Regime, weiß, dass sich zwischen dem Dokument, das das System beschreibt, und dem System, das tatsächlich in Betrieb ist, nach einigen Monaten ein Abstand öffnet, der jede Woche wächst und den niemand zu schließen beauftragt ist. Nicht, weil jemand lügt. Sondern weil der Code einen Stoffwechsel hat, den die Spezifikation nicht hat, und weil der Lebenszyklus der Spezifikation in der Software, die wir wirklich machen, von keinem Werkzeug verwaltet wird, das mit jenen vergleichbar wäre, die wir für den Code haben.

Der Einwand, den man gewöhnlich gegen diesen Punkt hört, ist vernünftig und muss adressiert werden, bevor man weitergeht. Der Einwand sagt: Der Code ist die wahre Spezifikation. Die Dokumentation ist eine vereinfachte Projektion des Systemverhaltens, und sie ist per Definition verspätet, daher ist die einzig sinnvolle Strategie, den Code in Ordnung zu halten und zu akzeptieren, dass der Rest Literatur ist. Das ist das Prinzip code as documentation in einer etwas anspruchsvolleren Variante, und es hat die Ingenieurkultur der Software seit mindestens zwanzig Jahren beherrscht. Es funktionierte, weil es auf einer impliziten Annahme beruhte, die heute nicht mehr stimmt: dass Software auf der Grundlage dessen beurteilt wird, was sie tut, wenn sie läuft.

Der neue Bewertungsstatus

Software wird unter dem juristischen Regime, das sich in Europa zwischen 2024 und 2027 konsolidiert, nicht mehr nur auf der Grundlage dessen beurteilt, was sie tut. Sie wird auf der Grundlage dessen beurteilt, was sie versprochen hat zu tun, und das Versprechen lebt in der geschriebenen Spezifikation, nicht im ausgeführten Code. Die Überarbeitung der Product Liability Directive, Ende 2024 angenommen, mit Umsetzungsfrist 9. Dezember 2026, hat Software ausdrücklich in den Produktbegriff einbezogen. Das bedeutet, dass der Hersteller von Software für Schäden haftet, die durch Mängel des Produkts verursacht werden, nach einem Regime der verschuldensunabhängigen Haftung. Zu diesem Punkt habe ich vor einiger Zeit einen Text geschrieben mit dem Titel Die letzte Flasche von Mrs Donoghue, der den Gründungsfall der Produzentenhaftung im englischen Recht von 1932 wiederaufnahm und auf die zeitgenössische Software projizierte. Was ich dort nur angedeutet hatte und was ich hier in den Fokus rücken möchte, ist die epistemologische Konsequenz des neuen Regimes. Der Begriff des Mangels deckt sich unter der verschuldensunabhängigen Haftung nicht mit dem Bug. Er deckt sich mit dem Abstand zwischen dem, was man legitimerweise vom Produkt erwarten konnte, und dem, was das Produkt tatsächlich getan hat. Legitime Erwartungen werden, in Ermangelung anderer Parameter, aus der technischen Dokumentation des Produkts rekonstruiert, aus den Erklärungen des Herstellers, aus Werbematerialien, aus den in den Risikobewertungen kartierten Konformitätsanforderungen. Sie werden, mit anderen Worten, aus der Spezifikation rekonstruiert.

Der Cyber Resilience Act, voll anwendbar ab dem 11. Dezember 2027, macht denselben Schritt auf der Sicherheitsseite. Konformität wird durch die technische Dokumentation des digitalen Produkts nachgewiesen, und diese Dokumentation umfasst die Risikobewertung, die implementierten Sicherheitsmaßnahmen, die aktualisierte SBOM, die Verfahren zum Umgang mit Schwachstellen, den Supportplan und die Updates für den Lebenszyklus des Produkts. Der AI Act verlangt für Hochrisiko-Systeme eine noch umfangreichere technische Dokumentation, definiert in Anhang IV, die die architektonische Beschreibung des Systems umfasst, die für das Training verwendeten Datensätze und die Verfahren der Datenverwaltung, die Performance- und Genauigkeitsmetriken, das in Artikel 9 vorgesehene Risikomanagementsystem, die Verfahren der Marktbeobachtung nach dem Inverkehrbringen. Es sind unterschiedliche Verordnungen mit unterschiedlichen Anwendungsbereichen, aber mit einer identischen epistemischen Struktur. Das Software-Produkt hat seinen Bewertungsstatus geändert. Es wird als Übereinstimmung zwischen einem geschriebenen Versprechen und einem beobachteten Verhalten beurteilt, und wenn die beiden auseinanderfallen, sieht der Richter oder die Aufsichtsbehörde auf das geschriebene Versprechen. Nicht, weil sie glauben, die Spezifikation sei das wirkliche System. Sondern weil die geschriebene Spezifikation der einzige Fixpunkt ist, auf dem ein Urteil gegründet werden kann.

Eine kleine Rahmen-Präzisierung ist hier nötig, um ein leicht aufkommendes Missverständnis zu vermeiden. Ich behaupte nicht, dass das europäische Regime die Spezifikation in ein magisches Objekt verwandle, das unabhängig vom System gelte. Der Richter oder die Behörde beschränkt sich nicht darauf, das Dokument zu lesen und Konformität zu erklären. Sie konfrontieren das Dokument mit dem System, bewerten die Kohärenz, hören technische Sachverständige an. Was sich gegenüber dem vorherigen Regime ändert, ist, dass das Dokument aufhört, ein Anhang des Produkts zu sein, und zu einem konstitutiven Teil der Bewertung wird, auf derselben Ebene wie das Verhalten des Systems. Wenn die beiden auseinanderfallen, wird das Dokument nicht mehr automatisch als überholt abgetan. Der Hersteller muss erklären, warum er ein anderes System ausgeliefert hat als das beschriebene, und diese Erklärung ist in einem Rechtsstreit erheblich teurer, als sie es heute ist.

Alles für den Code, fast nichts für die Spezifikation

Angesichts dieser Verschiebung verfügt die Industrie über ein Arsenal an Werkzeugen, um den Lebenszyklus des Codes zu verwalten, und über fast nichts, um den Lebenszyklus der Spezifikation zu verwalten. Der Code hat atomare Versionierung, und wenn sich eine Zeile ändert, gibt es einen Commit mit Autor, Datum und Nachricht. Er hat Blame, das es erlaubt, den Ursprung jeder im Quelltext sichtbaren Entscheidung zurückzuverfolgen. Er hat Tests, die automatisch fehlschlagen, wenn das Verhalten von einer kodifizierten Erwartung abweicht. Er hat Deprecation Warnings, die ein zurückgenommenes Versprechen signalisieren. Er hat sicheres Refactoring, gestützt auf Type-Systeme und Regressionssuiten. Er hat Code Review, in Pull Requests ritualisiert, die eine Spur hinterlassen. Er hat Continuous Integration, die verhindert, dass eine inkompatible Änderung unbemerkt in den Hauptzweig eindringt. Er hat Branch Protection Rules, die physisch verhindern, dass der Prozess umgangen wird. Er hat Rollback in einem Befehl, was die Kosten des Fehlers reduziert. Jedes dieser Werkzeuge ist das Produkt eines ingenieurmäßigen Drucks, der sich in den letzten dreißig Jahren angesammelt hat, und ist heute Infrastruktur der täglichen Praxis, derart verstoffwechselt, dass jene, die jetzt in das Handwerk eintreten, sie als selbstverständlich nehmen und sich kaum eine Welt ohne sie vorstellen können.

Die Spezifikation hat ihre Version, und das war’s. Eine DSFA wird unterzeichnet, datiert, als PDF archiviert, und in dem Moment, in dem sich das System ändert, gibt es keinen automatischen Mechanismus, der dem Unterzeichner oder dem Beauftragten sagt, dass seine Unterschrift jetzt ein anderes System abdeckt. Architekturentscheidungen, die in ADRs festgehalten sind, sammeln sich in Confluence, in Notion, in SharePoint-Ordnern, und niemand liest sie wieder, es sei denn, ein spezifisches Audit verlangt es. Sicherheitsanforderungen, die Verträgen beigefügt sind, werden unterzeichnet, im CRM hinterlegt, und existieren von da an als Backoffice-Anhänge bis zur Verlängerung. Die für die Konformität mit dem AI Act bei Hochrisiko-Systemen erstellten Risikobewertungen werden periodische Aktualisierungen erfordern, aber der Mechanismus, der die Aktualisierung an konkrete Änderungen des Systems bindet, wird in der überwiegenden Mehrzahl der Fälle ein Kalender oder ein vertraglicher Trigger sein, kein Code-Ereignis. Die Spezifikation hat, anders als der Code, keinen inneren Druck, aktuell zu bleiben. Sie überlebt in einer Zone der langsamen Zeit, in der die Unterschrift mehr zählt als die Frische, und in der das Altern sich nicht als funktionale Verschlechterung manifestiert, sondern als fortschreitende Entfernung von der Realität, die das Dokument beschreiben sollte.

Die Gründe für diese Asymmetrie sind kultureller Art. Technisch existieren die Werkzeuge, um Spezifikationen mit derselben Ernsthaftigkeit wie Code zu behandeln, seit Jahrzehnten. Ausführbare Spezifikationen im BDD-Stil, in Gherkin geschriebene Test-Spezifikationen, formale Verträge in Sprachen wie TLA+ oder Alloy, Schnittstellenspezifikationen in OpenAPI oder gRPC, Beweisassistenten wie Lean oder Coq. Jedes dieser Systeme setzt voraus, dass die Spezifikation ein erstklassiges Artefakt ist, ausführbar oder verifizierbar, lebendig im Repository neben dem Code. In der industriellen Praxis ist nichts davon die Norm. Die Norm ist, dass die Spezifikation in einem Word-Dokument lebt, von einer Person aus dem Recht oder der Compliance überarbeitet wird, unterzeichnet wird, archiviert wird, und ihr Schicksal ist von dem Moment an vom Schicksal des Codes getrennt.

Der agile Ursprung

Der Ursprung dieser Trennung ist historisch und verdient es, mit einigen Details rekonstruiert zu werden. Die Software-Kultur ist in Opposition zur Dokumentations-Kultur aufgewachsen, weil Dokumentation als Auflage des Engineering-Managements im Wasserfall-Stil wahrgenommen wurde, und Agile hat unter anderem deshalb gewonnen, weil es versprach, das Gewicht des Dokuments zugunsten von funktionierender Software zu reduzieren. Das Agile Manifest, im Februar 2001 in Snowbird unterzeichnet, sagt ausdrücklich „working software over comprehensive documentation“. Die Formulierung war vorsichtig, weil die Autoren am Ende des Dokuments schrieben „while there is value in the items on the right, we value the items on the left more“, die Dokumentation wurde also relativiert, nicht abgeschafft. Aber die industrielle Lesart der zwei folgenden Jahrzehnte war drastischer als die ursprüngliche Formulierung. Umfassende Dokumentation wurde zum Synonym für überflüssige Dokumentation, und Projekte, die es wagten, mehr als ein README, ein paar Kommentare und eine Handvoll Diagramme zu produzieren, gerieten in Verdacht, restliche Wasserfall-Praktiken zu pflegen. Das Versprechen war in seinem Kontext sinnvoll, weil die Software, die in den frühen 2000ern geschrieben wurde, an funktionalen und kommerziellen Kriterien gemessen wurde, und das Dokument war tatsächlich ein Kostenposten, der nach den ersten Wochen des Projektlebens wenig informativen Wert produzierte. Es war auch ein politischer Kostenposten, weil es oft dazu benutzt wurde, Gate-Keeping-Prozesse zu erzwingen, die die Arbeit verlangsamten, ohne Qualität hinzuzufügen.

Was sich geändert hat und was die Ingenieurkultur noch nicht verarbeitet hat, ist der Bewertungskontext. Die Software, die wir heute schreiben, wird in regulierten Märkten verkauft, in Lieferketten integriert, die sie als zertifiziertes Bauteil behandeln, Konformitätspflichten unterworfen, die lebendige Dokumentation verlangen. Das Dokument hat aufgehört, das interne Werkzeug einer Bürokratie zu sein, die Entwickler kontrollieren will. Es ist zum Werkzeug geworden, durch das sich das Produkt dem Regulator präsentiert, dem regulierten Kunden, dem eventuellen Richter. Die Ingenieurkultur behandelt die Spezifikation weiterhin als Nebenprodukt des Prozesses, während der normative Rahmen sie zum primären Artefakt erhebt. Der Abstand zwischen diesen beiden Wahrnehmungen ist das Terrain, in dem die Spezifikationsschulden ungestört wachsen.

Spec-driven, BDD und ihre Grenzen

Es wäre unredlich vorzugeben, es gäbe keine Versuche, diese Lücke zu schließen, und einige dieser Versuche sind ernsthaft. Das Spec-driven Development in der Form, die es in den letzten zwei Jahren angenommen hat, mit Werkzeugen wie SpecKit von GitHub und mit der Praxis, ein CLAUDE.md pro Projekt als Kontext-Briefing für KI-Agenten zu führen, versucht, den Schwerpunkt der Arbeit vor den Code zu verlagern. Die Spezifikation wird zum Eingang der assistierten Generierung für einen Agenten, der Code, Tests und begleitende Dokumentation in einem einzigen kohärenten Durchgang produziert. Das Versprechen ist, dass die Spezifikation ausführbar sei, in dem Sinn, dass sie ein System produziert, und damit durch den Druck aufrechterhalten wird, funktionierenden Code zu erzeugen. Das ist eine interessante Richtung, und in den Projekten, in denen ich sie angewandt habe, hat sie die Ökonomie der Arbeit auf nicht triviale Weise verändert. Die Zeit, die ich vorher dafür aufgewendet habe, Anforderungen in Code zu übersetzen, hat sich verringert, aber die Zeit, die mit dem Schreiben präziser Anforderungen zugebracht wurde, ist gewachsen, und das ist ein günstiger Trade-off, weil Präzision auch dann einen Restwert hat, wenn der Code neu geschrieben wird.

Die Grenze, die ich nach einigen Monaten Praxis sehe, ist, dass Spec-driven Development die Synchronisation zwischen Spezifikation und Code im Moment der ersten Generierung löst, und das ist ein realer Gewinn, aber die spätere Drift nicht löst. Wenn das System in Produktion geht und in Reaktion auf Kundenanfragen, Vorfälle, Veränderungen der operativen Umgebung verändert wird, kann die formalisierte Spezifikation aktualisiert werden oder auch nicht, und die praktischen Anreize spielen gegen ihre Aktualisierung. Die Spezifikation zu aktualisieren kostet Zeit und Strenge und erzwingt eine Verhandlung zwischen jenem, der die Änderung im Vorbeigehen geschrieben hat, und jenem, der Hüter des Dokuments ist. Unter Delivery-Druck verliert das Dokument. Der Code in Produktion gewinnt immer, weil er das ist, was die Nutzer benutzen. Die Spezifikation wird wieder zum Gespenst, auch wenn sie in einer formalen Sprache geschrieben wurde.

Ausführbare Spezifikationen vom Typ BDD haben dasselbe Problem, in abgeschwächter Form. Eine Gherkin-Suite, die das Verhalten des Systems beschreibt, bleibt synchron, solange jemand sie scheitern lässt und neu ausrichtet, aber wenn der Delivery-Druck steigt, werden Szenarien übersprungen, als pending markiert, gelöscht. Ich habe Suiten von Hunderten von Szenarien gesehen, die innerhalb eines Jahres und einer Hälfte auf einige Dutzend zusammengeschrumpft sind, nicht weil die beschriebenen Verhaltensweisen aus dem System verschwunden waren, sondern weil die Suite zu einer Reibung geworden war, die das Team nicht mehr die Zeit hatte zu verwalten. Die ausführbare Spezifikation bleibt widerstandsfähiger als eine DSFA, weil sie Code ist und damit den Anreizen des Codes unterliegt, aber sie ist nicht immun gegen die Drift. Sie driftet nur langsamer. Und es gibt ein zweites, subtileres Problem. Ausführbare Spezifikationen decken funktionales Verhalten gut ab, also den Teil des Systems, der sich automatisch verifizieren lässt. Sie decken viel weniger den Teil des Systems ab, den die neue europäische Compliance zu dokumentieren verlangt: die Risikobewertung, die architektonischen Entscheidungen, die Verarbeitungszwecke, die Minderungsmaßnahmen. Dieser Teil entzieht sich der Automatisierung, weil er nicht verhaltensbezogen ist, und bleibt konstitutiv für das Produkt als juristisches Objekt. Kein Test-Framework sagt einem, ob er noch kohärent mit dem System ist.

Eine Unterkategorie, kein Synonym

Man könnte an dieser Stelle einwenden, die Spezifikationsschulden seien bereits im allgemeinen Begriff der technischen Schulden enthalten, und davon getrennt zu sprechen sei eine elegante Art, den Mond neu zu entdecken. Der Einwand ist formal richtig. Die Taxonomien der technischen Schulden, die sich in den zwei Jahrzehnten nach Ward Cunninghams ursprünglicher Formulierung entwickelt haben, insbesondere die Arbeiten von Martin Fowler und derjenigen, die das Quadrant der Ursachen verfeinert haben, schließen veraltete Dokumentation als eine Form der Schuld ein. Die Unterscheidung, die ich vorschlage, ist eher ökonomischer als konzeptueller Natur. Klassische technische Schulden haben natürliche Anreize zur Tilgung, weil sie einen verlangsamen, einen täglich irritieren, einem Onboarding und Entwicklungszeit kosten. Spezifikationsschulden haben fast keine Anreize, bis ein auslösendes Ereignis eintritt, und die Anreize, die sie haben, sind bürokratisch und kalendarisch, nicht operativ. Diese Differenz rechtfertigt es, sie als Unterkategorie mit eigenen Dynamiken zu behandeln, vor allem jetzt, da der normative Rahmen sie asymmetrisch gegenüber den anderen Schuldformen mit Wert auflädt.

Was ich Spezifikationsschulden nenne, ist die unsichtbare Version der technischen Schulden. Die technischen Schulden sind der Preis, den man in Form von langsamer Entwicklung, wiederkehrenden Bugs, schwierigem Onboarding bezahlt. Es ist ein Preis, den man kontinuierlich, in kleinen Raten bezahlt, und der einen motiviert, in das Refactoring zu investieren, weil man den Schmerz spürt. Die Spezifikationsschulden spürt man nicht. Sie verlangsamen die Entwicklung nicht, weil derjenige, der entwickelt, die Spezifikation nicht liest, und wenn er sie liest, findet er sie oft als historische Referenz nützlich, aber nicht bindend. Sie erzeugen keine Bugs, weil der Code aus Sicht der Ausführung schon die wahre Spezifikation ist. Sie behindern das Onboarding nicht, weil der, der ins Team eintritt, vom Code und von Kollegen lernt, nicht von archivierten Dokumenten. Die Spezifikationsschulden produzieren nur eine Art von Schaden, und sie produzieren ihn dann, wenn ein Ereignis einen zwingt, sich der Spezifikation als bindendem Objekt zu stellen. Ein Audit Dritter. Ein Sicherheitsvorfall, der zum Gerichtsfall wird. Ein Auskunftsersuchen zu personenbezogenen Daten, auf das man nicht antworten kann, weil die Verarbeitungslandkarte für ein anderes System erstellt worden war. Eine Beanstandung eines Kunden, der den Vertrag gelesen hat und mit einigem Recht erklärt, etwas gekauft zu haben, das ihm nicht geliefert wurde.

Wenn dieses Ereignis eintritt, werden die Spezifikationsschulden auf einen Schlag sichtbar, und der Preis ist gegenüber den technischen Schulden asymmetrisch. Technische Schulden zahlt man in Raten, Spezifikationsschulden zahlt man in einer einzigen Rate, in der Regel höher als die Summe der Raten, die man bezahlt hätte, wenn man sie über die Zeit verwaltet hätte. Es gibt auch einen Unterschied in der Natur des Kostenpostens. Technische Schulden zahlt man in Entwicklungszeit, und diese Zeit hat man selbst unter Kontrolle. Spezifikationsschulden zahlt man in Anwaltszeit, in externen Beratern, in außerordentlichen Audits, in auferlegten Abhilfemaßnahmen, und in Reputation, die die teuerste Währung von allen ist, weil sie sich nicht refinanziert. Schließlich gibt es einen zeitlichen Unterschied, den niemand bemerkt, bis er ihn auf den Kopf bekommt. Die technischen Schulden zahlt man schrittweise, während man arbeitet. Die Spezifikationsschulden zahlt man auf einen Schlag, während man etwas anderes tut, und in der Regel zu einem Zeitpunkt, an dem man keinen Spielraum hat. Die Krisen, die sie offenlegen, kommen immer im schlechtest möglichen Moment, weil sie der Moment sind, an dem jemand anderes beschlossen hat, anzusehen, was man selbst nicht angesehen hat.

Archäologie und Aktivposten

In den letzten Monaten ist es mir passiert, an einer Compliance-Bewertung für ein klinisches Workflow-Management-System zu arbeiten, das für ein großes Forschungskrankenhaus entwickelt worden war, und der Kunde des Kunden, also die endgültige klinische Stiftung, hatte einen Sicherheitsanhang mit zehn Kontrollbereichen verlangt, die auf Artikel 28 DSGVO und auf eine Liste branchenspezifischer Anforderungen abgebildet werden sollten. Die ursprüngliche Spezifikation des Systems war drei Jahre zuvor verfasst worden, zu einem Zeitpunkt, als das System eine relativ einfache Plattform zur Datenerhebung war. In der Zwischenzeit war das System gewachsen, hatte Verarbeitungsmodule erworben, war an Drittsysteme angebunden worden, hatte den Hosting-Anbieter gewechselt. Der Abstand zwischen dem Ausgangsdokument und dem aktuellen System war enorm. Die Arbeit, die ich sechs Wochen lang machen musste, bestand im Wesentlichen darin, die Spezifikation aus dem System zu rekonstruieren, also Reverse Engineering des Verhaltens zu betreiben, um ein neues Dokument zu schreiben, das mit der Realität kohärent war.

Das operative Detail dieser Arbeit ist lehrreich, weil es erzählt, was es wirklich bedeutet, die Spezifikationsschulden zu verwalten, wenn sie zur Verantwortung gerufen werden. Ich musste mit sechs verschiedenen Personen sprechen, jede Hüterin eines nicht dokumentierten Wissensteils. Ich musste den Code von drei Microservices lesen, die nach der Unterzeichnung der DSFA hinzugefügt worden waren. Ich musste einen externen Anbieter ausfindig machen, um ihn zu fragen, welchen Anonymisierungsalgorithmus er auf die Daten anwendete, die durch ihn liefen, weil niemand im internen Team es genau wusste. Ich musste den Fluss der personenbezogenen Daten zwischen fünf verschiedenen Systemen rekonstruieren, indem ich Netzwerkkonfigurationen und Anwendungs-Logs ansah, weil das ursprüngliche Diagramm unbrauchbar geworden war. All diese Arbeit war der Entwicklung fremd. Sie war reine Rekonstruktion einer dokumentarischen Wahrheit, die im Lauf der Zeit hätte gepflegt werden müssen und stattdessen von Grund auf neu geschrieben werden musste. Es war genau die Operation, die das normative Regime voraussetzt, dass sie nie nötig sei, weil die Spezifikation auf dem Weg gepflegt worden sein sollte, und es war genau die Operation, die fast immer nötig ist, weil der Weg nie so verwaltet wird.

In einem anderen Projekt, einer Plattform zur juristischen Risikobewertung für eine spezialisierte Kanzlei, haben wir an einem bestimmten Punkt entschieden, den gesamten Stack von Python zu Laravel 12 zu migrieren. Die Migration ist im Gang, und wir sind bei rund achtundsiebzig Prozent. Was ich in dieser Migration gelernt habe, ist, dass der wirklich übertragene Aktivposten nicht der Code war, sondern die funktionale Spezifikation. Der Python-Code ist zum großen Teil weggeworfen und neu geschrieben worden, das Datenmodell ist neu entworfen worden, die Framework-Entscheidungen haben sich radikal geändert. Was überlebt hat, ist das präzise Wissen, formalisiert in der Produktdokumentation und in den Verträgen mit dem Kunden, darüber, was das System tun muss, in welcher Reihenfolge, mit welchen Einschränkungen, gegenüber welchen externen Schnittstellen. Ohne diese Spezifikation wäre die Migration unmöglich gewesen. Mit dieser Spezifikation, und mit einem Team, das sie während der Arbeit als aktive Referenz behandelte, ist die Migration schwierig, aber machbar gewesen.

Der Unterschied zwischen diesem Projekt und dem klinischen Fall, der oben erzählt wurde, ist ein Unterschied der Praxis, nicht der Natur der Spezifikation. In beiden Fällen existierte eine geschriebene Spezifikation. Im klinischen Fall war die Spezifikation unterzeichnet und dann verlassen worden. Im Fall der Migration wurde die Spezifikation alle vierzehn Tage in der Retrospektive gelesen, beanstandet, wenn das Team Inkohärenzen fand, modifiziert, wenn eine Produktentscheidung sich änderte, ergänzt, wenn eine Funktion hinzugefügt wurde. Sie war ein lebendiges Objekt im Prozess, kein Erbstück der Compliance. Es ist dieselbe Unterscheidung, die ein Flughandbuch, das der Pilot vor jedem Start liest, von demselben Handbuch trennt, das in einer Bibliothek archiviert ist. Derselbe Text, zwei völlig verschiedene Funktionen, und zwei nicht vergleichbare operative Werte. Die Spezifikation als übertragbarer Aktivposten und die Spezifikation als Aktivposten, der je nach Behandlung altert oder nicht altert, sind zwei Seiten derselben Sache.

Die Werkzeuge, die uns noch fehlen

Eine Hypothese, die mir vernünftig erscheint, ist, dass das nächste Jahrzehnt der Software-Ingenieurkunst durch Werkzeuge für den Lebenszyklus der Spezifikation definiert werden wird, die jenen analog sind, die das vergangene Jahrzehnt für den Lebenszyklus des Codes definiert hat. Schon heute beginnen die ersten ernsthaften Versuche sichtbar zu werden. Nachverfolgbarkeitssysteme, die die Spezifikationsanforderungen an die Tests binden, die sie verifizieren, und die Tests an die Code-Änderungen, die sie berühren, so dass das System weiß, welche Anforderung beeinträchtigt wurde, wenn ein Test sich ändert, und die Aktualisierung des Dokuments anfordert. Drift-Detection-Werkzeuge auf Architekturen, die die deklarierte Service-Topologie mit der beobachteten Topologie vergleichen und Divergenzen melden. Versionierung von DSFA in Git-Repositories mit obligatorischen Reviews bei jeder strukturellen Änderung des Systems. Produktspezifikationen, die als versionierte Objekte neben dem Code leben, mit einer CI, die fehlschlägt, wenn der Abstand zwischen Spezifikation und Implementierung einen Schwellenwert überschreitet.

Ich versuche mir vorzustellen, wie die tägliche Praxis in fünf Jahren aussehen könnte, in einem Team, das diese Wende verarbeitet hat. Die DSFA hat ihre Form verändert und lebt als YAML-Datei in einem geschützten Repository, mit Versionsgeschichte, Autoren der Änderungen, Genehmigungsprozess durch Pull Requests. Wenn ein Entwickler eine neue Verarbeitung personenbezogener Daten einführt, erkennt eine Pipeline für statische Code-Analyse den neuen Datenfluss und markiert den Pull Request automatisch als „DSFA-relevant“. Der Merge bleibt blockiert, bis der Datenschutzbeauftragte die entsprechende Änderung des Verarbeitungsdokuments prüft und genehmigt. Die AI-Act-Risikobewertungen folgen einem analogen Mechanismus, mit Drift-Detektoren, die melden, wenn das Modell in Produktion von den in der technischen Dokumentation erklärten Metriken abweicht. Die SBOMs aktualisieren sich automatisch bei jedem Build und produzieren lesbare Diffs, die in die Produkt-Changelogs eingehen. All das eliminiert die Compliance-Arbeit nicht, aber es verwandelt sie aus rekonstruktiver Archäologie, wie jener, die ich sechs Wochen lang am klinischen System gemacht habe, in kontinuierliche Wartung, integriert in denselben Rhythmus wie die Entwicklungsarbeit. Der kulturelle Sprung, der zu machen ist, besteht im Verständnis, dass die Dokumentation des Systems unter diesem neuen Regime den Aufbau des juristisch relevanten Aktivpostens des Produkts darstellt und keinen administrativen Kostenposten, den es zu minimieren gilt. Wer es jetzt nicht tut, wird es in fünf Jahren tun, nachdem er einen Prozess verloren hat, und in diesem Moment wird es teurer sein.

Körper und Seele

Vor einigen Monaten habe ich auf diesem Blog einen Text geschrieben mit dem Titel Cruft, keine Patina, und das zentrale Argument war, dass die Software nicht so altern kann wie materielle Objekte, weil die Drift zwischen dem Code und der Umgebung, in der er läuft, ihn schneller erodiert, als die Ingenieurkultur sie verstoffwechseln kann. Es gab eine Passage, die von Unix als Ausnahme sprach, weil sich in Unix die Spezifikation vom Code abgelöst hatte und zu Kultur geworden war, die durch Zyklen vollständiger Umschreibung des Körpers überlebt. Diese Passage schloss mit einer Note vorsichtigen Optimismus zu der Tatsache, dass die Spezifikation, wenn sie sich ablöst, der stabile Plan ist, der den Wandel durchquert.

Ich muss diese Note qualifizieren. Die Spezifikation löst sich vom Code auf zwei verschiedene Arten, und der Unterschied zwischen den beiden entscheidet alles. Die erste Art ist die von Unix, in der die Spezifikation zu geteilter Kultur wird, in kanonischen Büchern beschrieben, von einer Gemeinschaft gepflegt, die sie auf neue Kontexte anzuwenden weiß, und die sich daher erneuert, ohne ihre Identität zu verlieren. Die zweite Art ist die der archivierten DSFA, in der die Spezifikation zu einem unterzeichneten Dokument wird, das nicht mehr gelesen wird, und das daher mit sich selbst identisch bleibt, während das System ein anderes wird. Im ersten Fall produziert die Ablösung Kontinuität. Im zweiten produziert die Ablösung Geister-Spezifikation. Der Unterschied zwischen den beiden Arten liegt nicht in der Natur der Spezifikation. Er liegt in den Praktiken derer, die sie benutzen. Eine Spezifikation, die gelesen, beanstandet, modifiziert, neu diskutiert, auf neue Fälle angewandt wird, ist eine Spezifikation, die lebt. Eine Spezifikation, die geschrieben, unterzeichnet, archiviert und dann bis zum nächsten Audit ignoriert wird, ist eine Spezifikation, die langsam stirbt, während niemand hinsieht.

Wenn ich die beiden Essays zusammensetze, ist das allgemeine Argument, das ich zu konstruieren versuche, dieses. Die Software hat ein doppeltes Problem mit der Zeit. Auf der einen Seite kann der Code nicht altern, weil seine Umgebung sich zu schnell ändert und die Drift ihn in Cruft verwandelt, statt in Patina. Auf der anderen Seite kann die Spezifikation, die der stabile Plan sein könnte, der die Umschreibung des Codes durchquert, das nur sein, wenn eine konstante Praxis sie am Leben erhält, und in der überwiegenden Mehrheit der Fälle gibt es diese Praxis nicht. Das Ergebnis ist, dass die Software unter dem juristischen Regime, das sich in Europa konsolidiert, in eine Epoche eintritt, in der sowohl der Körper als auch die Seele des Produkts fragil sind, und in der das Einzige, was die beiden Ebenen zusammenhalten kann, eine Disziplin der dokumentarischen Pflege ist, die die Ingenieurkultur erst noch aufbauen muss. Die Ingenieurkultur der Software hat die beiden Dinge noch nicht mit der nötigen Klarheit unterschieden, weil sie die Spezifikation lange Zeit als Nebenprodukt behandelt hat. Der normative Rahmen, der sich in Europa konsolidiert, zwingt sie, diese Unterscheidung zu treffen, und der Preis der nächsten Jahre wird von dem bezahlt, der es nicht rechtzeitig bemerkt.

Spezifikationsschulden sind die technischen Schulden, die man nicht sieht, bis sich jemand verletzt. Wir sammeln sie still an, in SharePoint-Ordnern, die niemand öffnet, in unterzeichneten PDFs, die keine getreue Darstellung der Systeme mehr sind, die sie zertifizieren, in DSFA, die auf dem Compliance-Server abgelegt sind, als wären sie Monumente. Der erste große europäische Gerichtsfall zur Software-Produkthaftung unter dem neuen Regime der Product Liability Directive wird über die Spezifikation entschieden. Wenn er kommt, und er wird bald kommen, wird sich die Industrie aufteilen in jene, die ihre Spezifikation am Leben gehalten haben, und jene, die nur fortgefahren sind, sie zu unterzeichnen.

Der Autor

Andrea MargiovanniKI

Ich verfolge das Verhältnis zwischen KI und europäischer Regulierung als politisches Faktum, nicht als technisches Spektakel. Ich arbeite mit Teams, die KI mit AI Act, CRA, NIS2 vereinbar machen müssen, ohne Compliance auf eine Checkliste zu reduzieren.

Zum Weg →