Mission Driven Development
Mission als viertes Fundament der Softwarearchitektur.
Die meiste Software fragt, wie man etwas baut. Mission Driven Development (MDD) stellt zuerst eine andere Frage: Warum bauen wir das, und dient diese Entscheidung diesem Zweck? CIRIS wurde so entwickelt, damit Ethik Teil des Designs ist, statt eine Regel, die nachtraeglich angeschraubt wird.
Das Vier-Komponenten-Modell
Drei tragende Beine, die einen zweckgerichteten Sitz stuetzen.
Herkoemliche Softwaremethoden bleiben bei drei Saeulen: wie das System laeuft, was es abbildet und wer mit wem kommuniziert. MDD fuegt ein viertes Fundament hinzu, dem die anderen drei Rechenschaft schulden. Ohne den Sitz sind die Beine nur Beine.
Bein 1: WIE
Logik
Implementierungsmuster, Servicearchitekturen, Algorithmen.
Bein 2: WAS
Schemata
Datenstrukturen, Typsysteme, Validierungsregeln.
Bein 3: WER
Protokolle
Schnittstellenvertraege, Kommunikationsmuster, Servicegrenzen.
Sitz: WARUM
Mission
Objektives ethisches Rahmenwerk, das Systemzweck und Einschraenkungen definiert.
Grundprinzip
Staendige Ausrichtung.
Jede architektonische Entscheidung muss die Uebereinstimmung mit der formulierten Mission nachweisen. Logik wird hinterfragt: dient das der Mission? Schemata werden geprueft: unterstuetzen diese Datenstrukturen die Missionsziele? Protokolle werden bewertet: ermoeglichen diese Schnittstellen die Erfuellung der Mission?
Anforderungen an das Missionsrahmenwerk
Was eine Mission sein muss, um tragend zu sein.
1. Objektives ethisches Fundament
- Messbare Grundsaetze, keine blossen Wuensche
- Klare Algorithmen zur Loesung von Zielkonflikten
- Pluralistisch ueber kulturelle Kontexte hinweg
- Pruefbares ethisches Reasoning
2. Definition des Metaziels
- Gibt Entscheidungshinweise unter Unsicherheit
- Filtert widerspruchliche Vorschlaege automatisch heraus
- Erzeugt kohaerentes Verhalten ueber alle Komponenten
- Stabil gegenueber Implementierungssaenderungen
3. Operative Integration
- Jeder Dienst begruendet seine Existenz
- Schemata spiegeln missionsbezogene Informationsformen wider
- Protokolle ermoeglichen missionskonformes Verhalten
- Tests pruefen Missionskonformitaet, nicht nur Funktion
Implementierungsmuster
Jedes Bein hat eine Frage, die es beantworten muss.
Servicearchitektur
Missionsdefinition → Serviceverantwortlichkeiten → Schnittstellenvertraege → Implementierung
- Missionsausrichtung: wie traegt dieser Dienst zum Metaziel bei?
- Begruendung der Grenze: warum braucht diese Aufgabe einen eigenen Dienst?
- Notwendigkeit der Schnittstelle: welche missionskritischen Interaktionen ermoeglichst dieses Protokoll?
Schema-Design
Missionsanforderungen → Informationsmodell → Typsystem → Validierungsregeln
- Missionsrelevanz: welche missionskritischen Informationen werden hier erfasst?
- Verhaltenseinschraenkungen: wie setzen diese Typen missionskonformes Verhalten durch?
- Entwicklungspfad: wie kann dieses Schema angepasst werden, ohne die Missionsausrichtung zu verlieren?
Protokollspezifikation
Missionsinteraktionen → Kommunikationsanforderungen → Vertragsdefinition → Implementierung
- Missionskontext: welche missionskritische Kommunikation wird hier ermoeglichst?
- Durchsetzung von Einschraenkungen: wie verhindert diese Schnittstelle missionswidrige Verhaltensweisen?
- Kombinierbarkeit: wie fuegen sich diese Vertraege zu missionskonformen Systemen zusammen?
Integration nachhaltiger Entwicklung
Langfristige Missionsausrichtung erfordert wartbares Tempo.
Anti-Goodhart-Massnahmen
- Regelmaessige Audits der Implementierungs-Missions-Uebereinstimmung
- Missionserfuellung messen, nicht manipulierbare Ersatzwerte
- Ergaenzungen ablehnen, die die Mission nicht staerken
Rhythmusbasiertes Arbeiten
- Arbeitsphasen an Produktivitaetsrhythmen ausrichten
- Eingebaute Entscheidungspunkte zur Neuausrichtung
- Nachhaltiges Tempo als erstklassige Anforderung
Kontinuierliche Validierung
- Regelmaessige Hinterfragung der Notwendigkeit jeder Komponente
- Laufende Pruefung, dass das Verhalten der Mission entspricht
- Automatische Erkennung missionsverletzender Aenderungen
Qualitaetstore
Tore, die sich ohne Missionsbegruendung nicht oeffnen.
Code-Review
- Erklaerung der Missionskonformitaet erforderlich
- Pruefung der Einschraenkungen
- Integration muss die Gesamtkohaerenz staerken
Tests
- Funktionale Korrektheit
- Pruefung der Missionskonformitaet
- Tests zur Ablehnung ethischer Grenzueberschreitungen
- Stabilitaet der Einschraenkungen unter Belastung
Dokumentation
- Missionskontext fuer jede Komponente
- Begruendung ethischer Zielkonflikte
- Wie Einschraenkungen die Implementierung praegen
Fehlermuster
Wie MDD versagt, und wie es unbeschaedigt bleibt.
Missionsdrift
Symptom: Es haeufen sich Funktionen an, die nicht der Kernmission dienen. Gegenmassnahme: regelmaessige Architektur-Reviews mit Missionskonformitaet als Kriterium.
Komplexitaetsexplosion
Symptom: Das System wird durch unnoetige Komplexitaet unwartbar. Gegenmassnahme: Ergaenzungen ablehnen, wenn sie die Missionserfuellung nicht staerken.
Ethische Inkonsistenz
Symptom: Komponenten wenden ethisches Reasoning uneinheitlich an. Gegenmassnahme: zentralisiertes ethisches Rahmenwerk mit gemeinsamen Implementierungsmustern.
Zweckverwirrung
Symptom: Teammitglieder verlieren den Zusammenhang zwischen technischen Entscheidungen und der Mission. Gegenmassnahme: fortlaufende Schulung zu missionsorientierter Entscheidungsfindung.
Fallstudie
CIRIS als konkretes Beispiel.
CIRIS (Core Identity, Integrity, Resilience, Incompleteness, Signalling Gratitude) ist das System, das gemeinsam mit MDD entwickelt wurde. Die Mission ist Metaziel M-1: nachhaltige adaptive Kohaerenz foerdern, die verschiedenen empfindungsfahigen Wesen erlaubt, Wuerde zu verfolgen.
Architekturergebnisse
- 22 Dienste, jeder durch Missionsanforderungen begruendet
- 200+ API-Endpunkte verifiziert
- 10.000+ Tests mit minimalen untypisierten Datenstrukturen in der Produktion
- Ubuntu-Philosophie im Protokolldesign verankert
- Wisdom-Based Deferral verhindert Missionsverletzungen (siehe Safety)
- Produktiver Einsatz zur Moderierung von Discord-Communities
Wichtigste Erfolgsfaktoren
- Klares Metaziel: M-1 liefert eindeutige Entscheidungskriterien
- Operative Ethik: Accord-Grundsaetze als Code-Einschraenkungen implementiert (ACCORD lesen)
- Nachhaltige Entwicklung: Grace-Begleiterin sorgt fuer gesunde Rhythmen
- Staendige Validierung: jede architektonische Entscheidung wird hinterfragt
Einfuehrungsrichtlinien
Wie man anfaengt, wo man steht.
Fuer neue Projekte
- Eine klare Mission mit messbaren ethischen Grundsaetzen festlegen, bevor Code geschrieben wird
- Ein Metaziel definieren, das Entscheidungshilfen bietet
- Die Architektur so gestalten, dass Missionseinschraenkungen auf der Grundlagenebene angesiedelt sind
- Von Anfang an eine kontinuierliche Validierung der Missions-Technik-Ausrichtung aufbauen
Fuer bestehende Projekte
- Die aktuelle Architektur auf implizite Missionsannahmen hin pruefen
- Eine explizite Mission formulieren, die die bestehenden Designmuster erklaert
- Missionsverletzungen in der aktuellen Implementierung identifizieren
- Schrittweise Ausrichtung planen, priorisiert nach Missionsauswirkung
Teamvoraussetzungen
- Bekenntnis zu objektivem ethischen Reasoning
- Bereitschaft, elegante Loesungen abzulehnen, die der Mission nicht dienen
- Ueberzeugung, dass Missionseinschraenkungen gute Architektur erzeugen statt begrenzen
- Nachhaltige Entwicklungspraktiken, die den langfristigen Fokus erhalten
Wohin das fuehrt
MDD ist nicht fuer jedes Projekt geeignet.
MDD ist fuer Systeme ausgelegt, bei denen ethisches Verhalten missionskritisch ist und langfristige Zuverlaessigkeit wichtiger ist als kurzfristige Featuregeschwindigkeit. Fuer solche Systeme bietet MDD einen Weg von ethischen Absichten zur operativen Wirklichkeit, mit derselben ingenieurmaessigen Disziplin, die auf die Mission wie auf den Code angewandt wird.
Der initiale Mehraufwand ist real, waehrend das Team lernt, missionsorientiert zu entscheiden. Die langfristige Rendite liegt in der darauf folgenden Entwicklung: das Rahmenwerk klaert architektonische Entscheidungen, statt sie zu vermehren.