Ansatz

Die Batunet Engineering Method.

Wie wir denken — von der ersten Frage bis zum Betrieb nach Jahren. Kein Projektprozess, sondern ein technisches Betriebsmodell.

Prinzipien

Sechs Überzeugungen, die in jeder Phase gelten.

Verstehen vor Bauen. Teure Entscheidungen zuerst. Den schwierigen Pfad zuerst beweisen. Betreiben, was wir bauen.

01

Verstehen vor Bauen

Keine Zeile Code, bevor das Problem definiert und sein Erfolg messbar ist. Der teuerste Fehler ist die gut gebaute Lösung für das falsche Problem.

02

Die teuren Entscheidungen zuerst

Wenige Entscheidungen sind teuer umkehrbar. Wir treffen sie bewusst und schreiben das Warum auf — bevor die günstigen Entscheidungen die Aufmerksamkeit verbrauchen.

03

Umkehrbarkeit vor Vorhersage

Wir sagen die Zukunft nicht voraus, wir halten Änderung günstig. Jede wichtige Entscheidung ist als umkehrbar oder nicht klassifiziert.

04

Den schwierigen Pfad zuerst beweisen

Risiko wird am Anfang ausgeräumt, nicht am Ende entdeckt. Der riskanteste Pfad läuft End-to-End, bevor die einfachen Funktionen entstehen.

05

Auf Absicht scheitern

Wir entwerfen für den Fehlerfall und proben ihn, bevor es die Produktion tut. Ein System, dessen Fehlerfälle unbekannt sind, ist nicht fertig.

06

Betreiben, was wir bauen

Betreibbarkeit ist eine Entwurfsentscheidung vom ersten Tag, keine Übergabe am letzten. Wir bauen, als müssten wir es zehn Jahre selbst betreiben.

Vorgehen

Sieben Phasen. Frame bis Operate.

Jede Phase ist ein eigener Denkmodus, keine Kalenderstufe — und beantwortet eine Frage, bevor die nächste beginnt.

  1. 01

    FrameRahmen

    Welches Problem lösen wir wirklich — und was passiert, wenn nicht?

    Das eigentliche Problem, seine Grenzen und ein messbarer Erfolg werden definiert, bevor eine Lösung erwogen wird.

  2. 02

    ModelModellieren

    Wo verlaufen die echten Grenzen dieses Systems?

    Die Domäne wird modelliert und in Kontexte geschnitten — mit einer präzisen, gemeinsamen Sprache.

  3. 03

    DecideEntscheiden

    Welche Entscheidungen sind teuer umkehrbar — und haben wir sie bewusst getroffen?

    Die tragenden Entscheidungen fallen zuerst, bewusst und dokumentiert, solange Ändern noch günstig ist.

  4. 04

    ProveBeweisen

    Funktioniert der schwierigste Pfad End-to-End?

    Ein lauffähiges Skelett beweist die Architektur auf dem riskantesten Pfad — vor der Breite.

  5. 05

    BuildBauen

    Ist jedes Inkrement für sich auslieferbar, getestet und umkehrbar?

    Auf dem bewiesenen Skelett entsteht das System in prüfbaren, umkehrbaren Schritten — Fortschritt wöchentlich sichtbar.

  6. 06

    HardenHärten

    Wie fällt dieses System aus — und was passiert dann?

    Fehlerfälle, Last und Sicherheit werden geprüft, nicht angenommen. Aus „läuft“ wird „hält“.

  7. 07

    OperateBetreiben

    Wird jemand dieses System in fünf Jahren sicher ändern können?

    Wir betreiben, überwachen und entwickeln weiter — und halten das System verständlich und änderbar.

Gedächtnis

Entscheidungen, die dokumentiert bleiben.

Das Gedächtnis der Methode sind ihre Entscheidungsprotokolle (ADRs). Jede Phase ergänzt sie, jede Phase kann sie revidieren. Ein ADR hält fest: Kontext, Optionen, Entscheidung, Konsequenzen — und ob die Entscheidung umkehrbar ist.

So bleibt nicht nur erhalten, was ein System ist, sondern auch warum. Wo das Warum überlebt, kann ein System zehn Jahre lang sicher geändert werden. Wo es verloren geht, ist jede Änderung ein Risiko.

Artefakt

So sieht eine Entscheidung aus.

Ein generischer Auszug — ohne Kundenbezug. Das Format, in dem wir tragende Entscheidungen festhalten.

Architecture Decision RecordAuszug
ADR-014AngenommenZahlungen idempotent verarbeiten
Kontext
Zahlungsereignisse werden mit At-least-once-Zustellung verarbeitet. Eine doppelte Zustellung darf keine doppelte Buchung erzeugen.
Entscheidung
Jede Zahlung trägt einen idempotenten Schlüssel. Er wird in derselben Transaktion wie die Buchung geprüft und persistiert. Bekannte Schlüssel werden als No-op quittiert.
Konsequenzen
Doppelverarbeitung ist strukturell ausgeschlossen. Der Schlüsselspeicher wächst mit dem Durchsatz und braucht eine Retention. Konsumenten müssen den Schlüssel mitführen.
Verworfen
Nachgelagerte Deduplizierung per Abgleich — erkennt Doppelbuchungen zu spät.

Sprechen wir über Ihr Vorhaben.

Kein Vertrieb. Ein direktes Gespräch mit der Geschäftsführung. Antwort innerhalb eines Werktags.