Evolutionäres Prototyping

Ziel

Evolutionäres Prototyping dient dazu, eine funktionierende Lösung auszuliefern, während ihre Anforderungen noch entdeckt werden. Das Elizitation-Instrument ist die reale Nutzung eines realen Inkrements: Eine erste nutzbare Version geht in Betrieb, man beobachtet, was die Stakeholder damit tun, und was sie damit tun, entscheidet über die nächste Version. Der BABOK beschreibt diese Mechanik in einem deskriptiven Satz: Prototypen werden erstellt, um anfängliche Anforderungen zu einer funktionsfähigen Lösung auszubauen, während sich die Anforderungen durch die Nutzung der Stakeholder weiter präzisieren.

Das Ergebnis ist die Lösung selbst: Das Inkrement ist das Produkt, und genau deshalb muss es Produktionsqualität haben. Der BABOK fügt einen Vorbehalt hinzu, den man so stehen lassen sollte: Der Prototyp kann in der endgültigen Lösung verwendet werden. Das Rahmenwerk beschreibt eine Praxis und formuliert keinerlei Pflicht zu Architektur, Qualität oder Sicherheit. Diese Pflichten bestehen, sie sind schwer, und sie ruhen anderswo.

Weil nichts verworfen wird, gibt es keinen späteren Zeitpunkt, an dem Abkürzungen nachgeholt würden, und das Qualitätsfundament, Architektur, Sicherheit, Datenschutz, Tests, Betrieb, wird ab Inkrement null bezahlt. Die Entscheidung, die die Technik stützt, lautet: Was bauen wir als Nächstes? Sie stützt sie mit einem Nutzungsnachweis. Das ist ein echter Gewinn, und er muss präzis benannt werden, damit sichtbar wird, was er kostet: Was Menschen mit einem in Betrieb genommenen Inkrement tun, ist eine Anforderung; was sie im Workshop darüber sagen, ist eine Meinung über eine Anforderung.

Einsatz

Wann einsetzen

• Interface-Design und Design-System: Das Artefakt ist ab dem ersten Strich ein produktives Gut.
• Das Qualitätsfundament besteht bereits: Architektur, Authentifizierung, Logging, Tests und Lieferkette sind vorhanden.
• Die Anforderungen lassen sich nicht im Voraus formulieren: Nur die Nutzung eines wirklich nutzbaren Inkrements bringt sie hervor.
• Stabile Domäne, kleine Lösung: Die Nutzung wird die Architektur des ersten Inkrements kaum entwerten.
• Der Auftraggeber finanziert die Produktivsetzung ab dem ersten Inkrement: Das ist der wahre Preis der Technik.
• Die Lieferkette ist bereits durchgängig: Ohne sie dreht sich die Nutzungsschleife nicht.

Wann nicht einsetzen

• Die gestellte Frage lautet « was bauen? »: Wegwerf-Prototyping beantwortet sie zu einem Bruchteil der Kosten.
• Das Qualitätsfundament ist beim ersten Inkrement nicht finanzierbar: an einem Wegwerf-Prototyp lernen, dann die Lösung sauber bauen.
• Personendaten oder besonders schützenswerte Daten, kein Bedrohungsmodell: zuerst Bedrohungsmodell und Architektur festlegen, die Oberfläche mit einem Wegwerf-Prototyp erkunden.

Beschreibung

Zwei unabhängige Achsen

Der BABOK ordnet Prototypen entlang zweier verschiedener Elemente, und sie zu verwechseln ist teuer. Der Ansatz sagt, was aus dem Artefakt wird: Man wirft es weg, oder man lässt es zur Lösung wachsen. Die Methode sagt, woraus es besteht und was jemand damit tut: ein Storyboard, das man liest, ein Papier-Prototyp, den man bedient, eine Simulation, die die Maschine ausführt, oder die Modellierung von Arbeitsabläufen, eine geliehene Methode, deren Zuhause die Prozessmodellierung ist. Jeder Prototyp trägt eine Antwort auf jeder der beiden Achsen, und die beiden Antworten sind voneinander unabhängig. Evolutionäres Prototyping ist eine Antwort auf der Achse des Ansatzes: Es legt das Schicksal des Artefakts fest und sagt nichts über das Medium. Es ist das Prototyping als Ganzes, das die Weichenstellung zwischen den beiden Achsen regelt, und der einzige Vergleich, der Sinn ergibt, bleibt auf der Achse des Ansatzes: das Artefakt behalten oder es wegwerfen.

Das Artefakt wird zur Lösung

Die Mechanik besteht aus vier Schritten, die sich wiederholen. Ein Inkrement wird gebaut, es geht bei echten Nutzerinnen und Nutzern, die echte Arbeit verrichten, in Betrieb, die Nutzung wird beobachtet, und was man daraus lernt, entscheidet über das nächste Inkrement, gebaut auf derselben Codebasis. Das Wort, das alles trägt, ist in Betrieb: eine Vorführung im Sitzungszimmer, eine Sandbox, eine Abnahmeumgebung mit erfundenen Daten schliessen die Schleife nicht, denn sie erzeugen keine Nutzung. Sie erzeugen Kommentare, und dann hat man die Kosten des evolutionären Ansatzes ohne seinen Nutzen.

Daraus folgt das Einzige, was man sich von dieser Technik merken muss. Es gibt kein Verwurfsereignis, also gibt es auch kein Aufräumereignis. Kein Datum im Kalender trägt den Vermerk « wir werfen den Prototyp weg und schreiben die richtige Version ». Was Inkrement null ausgelassen hat, bleibt im Produkt, in der Produktion, für die Lebensdauer des Systems. Das Qualitätsfundament wird deshalb vollständig bezahlt, bevor die erste Frage ihre Antwort erhalten hat. Das ist die wahre Rechnung der Technik, und sie fällt am Anfang an.

Evolutionäres Prototyping durchführen

1. Den Ansatz ausdrücklich entscheiden, vor der ersten Zeile
   Die Wahl zwischen Behalten und Wegwerfen fällt einmal, und sie löst sich nicht billig wieder auf: Ab dem zweiten Inkrement heisst wegwerfen, Software wegzuwerfen, die in Betrieb ist. Die Entscheidung aufschreiben, ihren Grund aufschreiben und aufschreiben, was sie umstossen würde.
2. Das Umkehrsignal im Voraus aufschreiben
   Es ist die Art Signal, die man zu spät erkennt. Zwei gehören schwarz auf weiss festgehalten: Was die Nutzung eines Inkrements lehrt, entwertet die Architektur, die Inkrement null festgelegt hat, oder das nächste Inkrement darf unter der kantonalen Datenschutzgesetzgebung nicht rechtmässig in die Hände echter Nutzerinnen und Nutzer gegeben werden. Ist eines von beiden erreicht, besteht der nächste Schritt nicht darin, das Inkrement zu flicken. Er besteht darin, die Serie einzufrieren, das Laufende als Wegwerf-Prototyp zu behandeln, aus dem man die Lehre zieht, und das Fundament auf jener Architektur neu zu errichten, die die Nutzung schliesslich bezeichnet hat. Die Kosten dieser Umkehr wachsen mit jedem Inkrement, und genau deshalb wird ihre Schwelle vor dem ersten aufgeschrieben.
3. Das Fundament bezahlen und es Inkrement null nennen
   Authentifizierung und Autorisierung, Logging und Audit-Trail, Verschlüsselung, Rechtsgrundlage der Datenbearbeitung, Fehlerbehandlung, automatisierte Testsuite, Lieferkette, Überwachung, Sicherung und Wiederherstellung. Wenn diese Liste im Verhältnis zu der Frage, die man klären will, überdimensioniert wirkt, ist dieses Gefühl richtig, und es ist das Signal, dass ein Wegwerf-Prototyp gebraucht wird.
4. Das kleinste Inkrement definieren, das wirklich genutzt werden kann
   Von echten Menschen bei echter Arbeit, mit echten Daten. Das Kriterium ist die Fähigkeit, Nutzung zu erzeugen: Ein einziger, durchgängig behandelter Anwendungsfall ist mehr wert als fünf halb verdrahtete Bildschirme.
5. Produktiv setzen und nutzen lassen
   Das Elizitation-Instrument ist die reale Nutzung, ausgeübt von den Menschen, deren Beruf es ist, unter den Bedingungen, unter denen sie ihn ausüben.
6. Beobachten, was die Leute mit dem Inkrement tun
   Telemetrie, Abbruchpunkte, Support-Tickets, Fragen am Schalter, Umgehungen, die sich die Leute ausdenken. Eine Umgehung ist eine nicht erfüllte Anforderung, die reichhaltigste Angabe, die die Technik hervorbringt.
7. Das nächste Inkrement auf dieser Grundlage mit den Stakeholdern entscheiden und aufschreiben, was die Nutzung entschieden hat
   Diese letzte Klausel ist die, die Teams überspringen, und ihr Fehlen ist es, was evolutionäres Prototyping von einer blossen Folge von Lieferungen unterscheidet. Ohne sie erzeugt die Technik ein System und keine Anforderungen: Der Code kodiert die Entscheidung, niemand kann sie aussprechen.
8. Das Fundament bei jedem Inkrement halten
   Kein Inkrement sinkt darunter. An dem Tag, an dem eines darunter sinkt, hat die eingegangene Schuld keinen Rückzahlungstermin mehr, weil der Kalender keinen vorsieht.
9. Den Moment erkennen, in dem das Wort « Prototyp » aufhört zu arbeiten
   Wenn jedes Inkrement Produktionsqualität hat und jedes Inkrement ausgeliefert wird, betreibt das Team inkrementelle Lieferung, und es ist besser, das zu sagen und das Wort fallen zu lassen.

Es gibt drei Ergebnisse, und nur das erste ist jenes, das man sieht. Da ist die Lösung, Inkrement für Inkrement, denn das Artefakt ist das Produkt. Da ist das Protokoll, je Inkrement, dessen, was die Nutzung entschieden hat, und es ist die einzige Anforderungsspur, die die Technik hinterlässt. Und da sind die Architektur- und Sicherheitsentscheide von Inkrement null, die das Fundament bilden, auf dem alles Übrige ruht und das niemand wieder öffnen wird. HERMES 2022, die Methode der Schweizer Verwaltung, führt den Prototyp und seine Dokumentation im Übrigen als zwei eigenständige Ergebnisse der Prototyping-Aufgabe, getrennt von den Ergebnissen des Produkts selbst.

Das Qualitätsfundament lässt sich nicht nachholen

Die Sicherheit ist die Stelle, an der diese Eigenschaft aufhört, eine Vorliebe von Ingenieuren zu sein, und zu einem Sachzwang wird. Die OWASP formuliert es zu den Designfehlern denkbar klar: « Ein sicheres Design kann immer noch Implementierungsfehler aufweisen, die zu ausnutzbaren Schwachstellen führen. Ein unsicheres Design lässt sich durch eine perfekte Implementierung nicht beheben, denn per Definition wurden die nötigen Sicherheitskontrollen nie geschaffen, um sich gegen bestimmte Angriffe zu verteidigen. » Ein Implementierungsfehler wird durch einen Patch behoben. Ein unsicheres Design wird durch ein Design behoben, das heisst durch eine Neuschrift, das heisst durch jenes Verwurfsereignis, das dieser Ansatz gestrichen hat.

Die CISA und ihre internationalen Partner sagen dasselbe von der Herstellerseite her: Sicherheit wird ab Entwurf und Entwicklung im Produkt angelegt, und dafür haftet der Lieferant, nicht die Kundschaft. Ein Prototyp aber lässt die Sicherheit per Definition aus, und diese Auslassung ist ein Teil dessen, was ihn schnell macht. Den Prototyp behalten heisst, die Auslassung behalten. Sicherheit über ein Artefakt zu bauen, das ohne sie entworfen wurde, ist ein programmiertes Scheitern, im Wortsinn: Der Kalender enthält kein Feld, in dem dieses Nachholen stattfinden könnte.

In der Schweiz ist diese Forderung zudem rechtlich. Der Datenschutz durch Technik, der in Art. 7 des Bundesgesetzes über den Datenschutz verankert ist und von den kantonalen Datenschutzgesetzen aufgenommen wird, die für die kantonalen und kommunalen öffentlichen Organe gelten, verlangt technische und organisatorische Massnahmen ab der Planung der Bearbeitung sowie Voreinstellungen, die die Bearbeitung auf das Minimum beschränken. Ein Inkrement null, das Personendaten bearbeitet und den Datenschutz vertagt, ist im Fehler, bevor es online ist.

Boehms Spirale

Die korrekte Theorie des Prototyps als Instrument hat 1988 Barry Boehm geschrieben, und sie ist das genaue Gegenteil des evolutionären Ansatzes. Das Spiralmodell ist risikogetrieben: Jeder Zyklus benennt Ziele und Optionen, identifiziert und löst die Risiken auf, wobei der Prototyp dafür das Mittel der Wahl ist, und verpflichtet sich erst dann auf die nächste Ausarbeitungsstufe, wenn das Risiko abgekauft ist. Der Prototyp dient dort dazu, vor der Festlegung eine Verringerung der Unsicherheit zu kaufen.

Evolutionäres Prototyping legt sich zuerst fest. Inkrement null ist das Produkt, und die Architektur, die es fixiert, wird in dem Moment entschieden, in dem das Team so wenig weiss wie nie wieder. Das sind zwei entgegengesetzte Haltungen gegenüber demselben Instrument, und man sieht sie, sobald man die Spirale beim Namen nennt.

Was aus der Spirale in der Praxis geworden ist, lässt sich genau sagen. Zwölf Jahre nach dem Gründungsaufsatz musste Boehm am Software Engineering Institute einen Bericht veröffentlichen, der sechs Invarianten jeder Spiralentwicklung festhält, mit dem ausdrücklichen Zweck, die hazardous spiral look-alikes auszuschliessen, die falschen Ähnlichkeiten, die den Namen übernommen hatten. Die Modelle, die er ausschliesst, sind genau das, was die Teams unter diesem Etikett taten: eine Folge von Wasserfall-Inkrementen dort, wo die Annahmen des Wasserfalls nicht tragen, Zyklen, die wesentliche Stakeholder ausschliessen, inkrementelle Vorgehen ohne jede Architekturplanung, Ansätze, die auf die Entwicklung des ersten Codes fixiert sind. Der Bericht dokumentiert die Kluft: Unter dem Namen der Spirale taten die Teams etwas anderes, und es brauchte die Invarianten, um die echte Anwendung von den Ähnlichkeiten zu unterscheiden. Dass ein solcher Bericht zwölf Jahre nach dem Aufsatz nötig war, ist das Mass dieser Kluft. Und die häufigste dieser Ähnlichkeiten, eine Folge von Wasserfall-Inkrementen ohne Risikoanalyse, ist genau die Gestalt, die ein schlecht geführtes evolutionäres Prototyping annimmt.

Ersparnisse und Kosten des Ansatzes

Ein Prototyp dient dem Lernen. Die Frage, die er entscheidet, lautet « was bauen? », und das ist die teure Frage. Brooks hat es in No Silver Bullet festgehalten, und der Satz ist nicht gealtert: « Der schwierigste Einzelteil beim Bau eines Softwaresystems ist die Entscheidung, was genau gebaut werden soll. » Kein anderer Teil der konzeptionellen Arbeit ist so schwierig, keiner verstümmelt das entstehende System so sehr, wenn er schlecht gemacht wird, und keiner ist danach schwerer zu berichtigen. Der Rest, das Schreiben des Codes, gehört bei Brooks zum Akzidentellen.

Die Kosten, die evolutionäres Prototyping zu vermeiden vorgibt, sind die des Neuschreibens von Code. Das sind die günstigeren der beiden, und sie fallen an, nachdem das Lernen stattgefunden hat. Die Kosten, die es aufbürdet, das Qualitätsfundament, sind die schwereren, und sie werden vorher kassiert. Der Ansatz spart also die falschen Kosten, und er tut es zum ungünstigsten Zeitpunkt. In der Software ist er nicht die Standardwahl, und er sollte es nicht sein.

Brooks ist weiter gegangen, und seine Schlussfolgerung wird regelmässig für das falsche Lager vereinnahmt. In der Jubiläumsausgabe des Mythical Man-Month zieht er seinen Rat von 1975 zurück (ein erstes System bauen im Wissen, dass man es wegwerfen wird): « Ich sehe nun, dass das falsch ist, nicht weil es zu radikal wäre, sondern weil es zu simpel ist. » Was er stattdessen annimmt, ist das inkrementelle Wachstum. Doch was er wachsen lässt, ist das Produkt: Sein System beginnt mit einem Skelett des echten Systems, das läuft und noch nichts als leere Unterprogramme aufruft, und das man dann Stück für Stück auffüllt. Jede Stufe ist das Produkt. Er hat nie geschrieben, man solle ein Modell behalten und ausbauen, und er entscheidet die Debatte zwischen den beiden Ansätzen nicht: Er hält fest, dass die Wahl real ist und Folgen hat.

Die Disziplin, die beschreibt, was Brooks empfiehlt, trägt im Übrigen einen anderen Namen. Beck nennt sie inkrementelles Design: Das Design entsteht im Licht der Erfahrung, es wird bis zum letzten verantwortbaren Moment aufgeschoben, und jedes Inkrement hat Produktionsqualität und wird ausgeliefert. Sie ist die Primärquelle jener Praxis, die man mitunter als Kern der agilen Entwicklung beschreibt, und sie heisst nicht Prototyping.

Die Schlussfolgerung passt in einen Satz: Die Disziplin, die evolutionäres Prototyping zum Funktionieren bringt, ist dieselbe, die es aufhören lässt, ein Prototyp zu sein. Inkrement null nach Produktionsmassstab bauen, das Fundament bei jedem Inkrement halten, aufschreiben, was die Nutzung entschieden hat: In diesem Moment betreibt das Team inkrementelle Lieferung, und das Wort Prototyp leistet im Satz keinerlei Arbeit mehr. Wer das verfehlt, lässt eine Vorführung zu einem Produktivsystem wachsen. Der Ansatz hat keine ehrliche Mitte. Dieselbe Unterscheidung findet sich in der Struktur von HERMES 2022: Der erstellte Prototyp und seine Dokumentation sind dort Ergebnisse, das entwickelte Produkt ist ein anderes, und die Methode lässt das Produkt klassisch oder agil entstehen, ohne dass es Prototyp heissen müsste, um in Etappen geliefert zu werden.

Die Ausnahme: das Design

Es gibt einen Bereich, in dem der Ansatz ehrlich rentiert, und er verdient es, abgegrenzt zu werden. In einem Werkzeug für Interface-Design wie Figma und seinesgleichen ist das Artefakt ab dem ersten Strich ein produktives Gut. Das Design-System ist eine Menge von Standards, die wie lebender Code gepflegt und vom ausgelieferten Produkt konsumiert werden, so beschreibt es die Nielsen Norman Group. Design-Tokens sind Variablen, die das Design-Werkzeug und die Codebasis beide lesen. Das CSS geht unverändert über, und das HTML in gewissem Mass.

Der Grund ist strukturell, und er ist es, der die Ausnahme präzis macht: Unter einem Design-Artefakt gibt es keine Ausführung, keine persistierten Daten und keine Angriffsfläche. Es existiert daher kein Qualitätsfundament, das nachzuholen wäre. Nichts an einer Figma-Komponente lässt sich ausnutzen, kann einen Datensatz beschädigen oder die Adresse einer Einwohnerin preisgeben. Die Ausnahme endet genau dort, wo das Artefakt eine Ausführungsumgebung und eine Datenbank erhält: Der Bildschirmentwurf überlebt im Produkt, das Verhalten, das er verspricht, bleibt vollständig zu bauen, und dieses Verhalten trägt das Fundament.

Woran evolutionäres Prototyping scheitert

Die Vorführung, die zum System wird

Der BABOK benennt den Mechanismus: Ist der Prototyp sehr ausgearbeitet und detailliert, entwickeln die Stakeholder unrealistische Erwartungen an die endgültige Lösung, auch an Fertigstellungstermine, Leistung und Zuverlässigkeit. Ein Inkrement, das fertig aussieht, wird als fertig behandelt, vom Auftraggeber wie vom Team.

Technische Schuld ohne Rückzahlungstermin

Cunninghams Metapher ist präzis, und sie wird regelmässig verkehrt herum zitiert: Code auszuliefern, der im ersten Anlauf geschrieben wurde, heisst, sich zu verschulden, und eine kleine Schuld beschleunigt die Entwicklung, solange sie umgehend durch eine Neuschrift zurückgezahlt wird. Die Schuld, die er beschrieb, ist ein unreifes Verständnis der Domäne, ausgeliefert im Code, also genau das, was ein frühes Inkrement ist. Ein Ansatz, dessen Prämisse lautet, dass der Code nie neu geschrieben wird, hat dem Darlehen die Rückzahlung entzogen.

Die Migration echter Daten, bei jedem Inkrement

Das Artefakt ist in Betrieb, also gibt es keinen Moment, in dem man die Datenbank leert und von vorne beginnt. Jede Schemaänderung ab v1 ist eine Migration, ausgeführt auf den Datensätzen echter Menschen, mit ihrer Einführung, ihrer Umkehrbarkeit und ihrer Spur, unter dem Datenschutzfundament. Diese Arbeit steht in keiner Prototyp-Schätzung, und sie wächst mit jedem Inkrement.

Die von Inkrement null eingefrorene Architektur

Das erste Inkrement wird unter dem geringsten Wissen über das Problem geschrieben, das das Team je haben wird, und es wird zum Fundament für alles Weitere. Es spiegelt die vorige Falle, und es macht den Ansatz auf einer stabilen, kleinen Domäne tragfähig und auf einer explorativen strafend.

Die Kritik erlischt

Der BABOK beobachtet, dass sich Nutzerinnen und Nutzer bei einem Modell freier fühlen, kritisch zu sein, weil es weder fertig noch auslieferbereit ist. Ein Inkrement in Produktion ist auslieferbereit, es ist sogar schon ausgeliefert: Die Stakeholder kritisieren es dann als Produkt, mit Vorsicht.

Das « wie » verdrängt das « was »

Die erste Grenze des Prototyping laut BABOK, und dieser Ansatz ist ihr am stärksten ausgesetzt: Das Artefakt ist echter Code, also spricht der Raum über Implementierung, wo er über Bedarf sprechen sollte.

Die Anforderungen stehen nirgends geschrieben

Die Nutzung hat entschieden, niemand hat notiert, was sie entschieden hat. Drei Jahre später steht eine Regel im Code und ihr Grund nirgends.

Das spezialisierte Werkzeug wird zur Decke

Low-Code-Plattformen machen Inkrement null schnell und das Fundament unsichtbar: Authentifizierung, Datenstandort, Audit-Trail, Ausstiegskosten. Die Geschwindigkeit ist echt, und sie ist beim Fundament geborgt.

KI-Überlegungen

Eine Beobachtung beherrscht die übrigen, und sie ist dieser Technik eigen: Die KI macht ihren Fehlermodus wahrscheinlicher. Nie war es billiger, etwas herzustellen, das aussieht wie eine funktionierende Lösung: ein plausibles Inkrement, mit glaubwürdigen Bildschirmen und einem Ablauf, der durchläuft, ohne Bedrohungsmodell, ohne tragfähiges Datenmodell, ohne Fehlerbehandlung und ohne Betreibbarkeit. Der Abstand zwischen einer Vorführung und einem Produktivsystem ist nicht kleiner geworden; der Abstand zwischen dem Anschein einer Vorführung und dem Anschein eines Produktivsystems ist eingebrochen. Die Entscheidung « geht dieses Inkrement in Produktion? » bleibt menschlich und begründet eine Haftung.

Wo die Werkzeuge einen erheblichen Dienst leisten, leisten sie ihn am Fundament. Ein vollständiges Inkrement null zu erzeugen, ein Anwendungsskelett mit Authentifizierung, Autorisierung, Logging, Fehlerbehandlung, Testsuite und Integrationskette, kostet heute einen Bruchteil dessen, was es einmal kostete: Die Rechnung, die diese Technik nicht bezahlen will, ist gesunken, und das ist das Einzige, was ihre Ökonomie ändern kann. Jedes Inkrement an den Kategorien unsicheren Designs der OWASP zu messen, vor der Inbetriebnahme ein Bedrohungsmodell zu entwerfen, Support-Tickets, Abbruchpunkte und Telemetrie eines ausgelieferten Inkrements zu Anforderungskandidaten für das nächste zu verdichten, das Protokoll dessen zu verfassen, was die Nutzung entschieden hat, die Migrationsskripte zu schreiben, die jedes Inkrement verlangt, weil es auf echten Daten läuft: All das lässt sich sinnvoll delegieren.

Zwei Grenzen. Die erste: Die KI macht das Argument des Auftraggebers stärker. Wenn das Schreiben von Code noch weniger kostet als zuvor, dann kauft das Behalten des Prototyp-Codes, um ihn nicht neu schreiben zu müssen, noch weniger als zuvor, während der teure Teil, die Entscheidung, was zu bauen ist, genau dort bleibt, wo er war. Die zweite: Die Inkremente laufen ab Inkrement null auf echten Daten, auf den Daten echter Menschen. Kein Auszug aus dem Einwohnerregister geht in ein Modell, das ein Dritter betreibt, und das Datenschutzfundament bindet die Werkzeuge genauso, wie es das Produkt bindet.

Beispiele

Eine Gemeinde eröffnet einen virtuellen Schalter für ihre Einwohnerkontrolle. Inkrement null ist der Dienst in Produktion: Er steht den Einwohnerinnen und Einwohnern einer Pilotgemeinde offen, er stellt echte Wohnsitzbestätigungen aus dem echten Register aus, und er tut es vom ersten Tag an.

Inkrement null hat mehr gekostet als die drei folgenden zusammen. Die Authentifizierung und der Audit-Trail, die für es geschrieben wurden, laufen mehrere Jahre später noch in der Produktion: Sie haben überlebt, weil sie am ersten Tag nach Produktionsmassstab geschrieben wurden, auf einem Artefakt, das niemand je wegzuwerfen gedachte.

Die Gemeinde musste dieses Fundament ohnehin bezahlen. Die Bearbeitung betrifft Personendaten, und der Datenschutz durch Technik gilt für das Dossier vor der ersten Codezeile. Die Rechnung von v0 war also geschuldet, und das macht den Ansatz in diesem Fall vertretbar.

Das System kodiert die Entscheidung über die Vertretung einer Drittperson. Es spricht sie nicht aus, und niemand wird sie beim Lesen des Codes wiederfinden. Das Protokoll dessen, was die Nutzung entschieden hat, ist der einzige Ort, an dem diese Entscheidung als Anforderung existiert: Ohne es hätte die Technik einen Schalter geliefert und sonst nichts.

Visualisierungen

Was man in der Kette der Inkremente sehen muss, ist ein Fehlen: Nirgends ein Abfallbehälter, nirgends ein Aufräumschritt, kein Datum, an dem jemand noch einmal darübergeht. Dieses Fehlen ist die Technik selbst. Das Protokoll der Inkremente trägt die andere Hälfte desselben Befundes: was die Nutzung auf jeder Stufe entschieden hat und was das Fundament ein für alle Mal gekostet hat.

Dieselbe Kette, neben ein reales Projekt gelegt, ist ein Audit-Instrument, und drei Prüfungen lassen sich an ihr ablesen. Beginnt das Band des Fundaments wirklich bei Inkrement null, oder beginnt es irgendwo mitten in der Kette? Durchläuft jedes Inkrement tatsächlich eine Nutzung oder nur eine Vorführung? Und gibt es irgendwo im Plan ein Datum, an dem man noch einmal darübergeht? Lautet die Antwort auf die letzte Frage « wir räumen später auf », ist die Antwort eine Absicht, und die Technik sieht keinen Moment vor, sie auszuführen.

Aufwand

Werkzeuge

Die Ausnahme verfügt über eigene Werkzeuge, und sie ist der einzige Fall, in dem das Wort Prototyp und das Wort Produktion ohne Vorbehalt dasselbe bezeichnen. Figma und seinesgleichen, mit ihrer Komponentenbibliothek, die Design-Tokens und ein lebender Komponentenkatalog wie Storybook erzeugen ein Artefakt, das das ausgelieferte Produkt direkt konsumiert. Das Design-System wird wie Code gepflegt, und es wird wie Code versioniert.

Für die Software hält der BABOK fest, dass der Ansatz gewöhnlich ein spezialisiertes Prototyping-Werkzeug oder eine spezialisierte Sprache verlangt, was heute die Low-Code- und Rapid-Development-Plattformen meint (OutSystems, Mendix, Power Apps, Retool). Sie halten ihr Versprechen: Inkrement null ist schnell draussen. Sie machen auch das Fundament unsichtbar, und das ist die Falle des ganzen Kapitels: Authentifizierung, Datenstandort, Audit-Trail und die Ausstiegskosten der Plattform sind Architekturentscheide, vom Werkzeug per Voreinstellung getroffen, oft ohne dass sie jemand vorbeiziehen sah. Die Wahl einer solchen Plattform behandelt man als Architekturwahl.

Die Werkzeuge, die die Technik wirklich tragen, sind die Lieferkette: kontinuierliche Integration und Auslieferung, automatisierte Testsuite, Feature-Flags, Umgebungen, Überwachung und Rückrollung. Das ist zugleich die schnellste Diagnose überhaupt: Wenn die Werkzeuge, die eine Prototyping-Technik verlangt, eine vollständige Lieferkette sind, dann ist das, was das Team betreibt, eine Lieferung, und die Werkzeuge sagen es, bevor es das Team bemerkt.

Bleibt die Beobachtung der Nutzung, ohne die der Schritt, der die Anforderungen bestimmt, kein Material hat: Anwendungstelemetrie, Protokollierung der Abläufe, Abbruchpunkte, Support-Tickets, Rückmeldungen vom Schalter. Im Schweizer öffentlichen Sektor geschieht all das unter dem kantonalen Datenschutzregime, mit konformem Hosting und konformer Authentifizierung ab Inkrement null, und das ist eine Architekturbedingung, bevor es eine Werkzeugbedingung ist.

Quellen

• IIBA, A Guide to the Business Analysis Body of Knowledge (BABOK Guide) v3, §10.36 Prototyping: der evolutionäre oder funktionale Ansatz, die durch die Nutzung der Stakeholder präzisierten Anforderungen, das spezialisierte Werkzeug und die Grenzen (unrealistische Erwartungen, Versanden im « wie »).
• Frederick P. Brooks Jr., The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition, Kap. 19, Addison-Wesley, 1995: der Widerruf des Rats von 1975 und das inkrementelle Wachstum des Produkts.
• Frederick P. Brooks Jr., No Silver Bullet: Essence and Accidents of Software Engineering, IEEE Computer 20(4), 1987: Zu entscheiden, was genau zu bauen ist, ist der schwierigste Einzelteil und die Unterscheidung zwischen wesentlicher und akzidenteller Schwierigkeit.
• Barry W. Boehm, A Spiral Model of Software Development and Enhancement, IEEE Computer 21(5), 1988, S. 61-72: der Prototyp als Instrument der Risikoreduktion, aufgelöst vor der Festlegung.
• Barry Boehm (Wilfred J. Hansen, Hrsg.), Spiral Development: Experience, Principles, and Refinements, Special Report CMU/SEI-2000-SR-008, Software Engineering Institute, 2000: die sechs Invarianten und die hazardous spiral look-alikes, die sie ausschliessen.
• Kent Beck mit Cynthia Andres, Extreme Programming Explained: Embrace Change, 2. Aufl., Addison-Wesley, 2004: das inkrementelle Design, das Design im Licht der Erfahrung und das in Produktionsqualität ausgelieferte Inkrement.
• OWASP, Top 10:2021, A04 Insecure Design: Ein unsicheres Design lässt sich durch eine perfekte Implementierung nicht beheben.
• CISA und internationale Partner, Shifting the Balance of Cybersecurity Risk: Principles and Approaches for Secure by Design Software: die ab Entwurf und Entwicklung eingebaute Sicherheit und die Verantwortung des Lieferanten.
• Ward Cunningham, The WyCash Portfolio Management System, OOPSLA '92: die Metapher der technischen Schuld in den Worten ihres Urhebers und die Rückzahlung durch die Neuschrift.
• Schweizerische Eidgenossenschaft, Bundesgesetz über den Datenschutz (DSG), SR 235.1, Art. 7: Datenschutz durch Technik und datenschutzfreundliche Voreinstellungen, ein Grundsatz, den die kantonalen Datenschutzgesetze aufnehmen.
• HERMES 2022, Aufgabe Prototyping durchführen: der erstellte Prototyp und die Prototyp-Dokumentation als eigenständige Ergebnisse, getrennt von den Ergebnissen des Produkts.
• Nielsen Norman Group, Design Systems 101: das Design-System als Menge von Standards, die gepflegt und vom ausgelieferten Produkt konsumiert werden.