Wie wir in Projekten vorgehen.
Ein Projekt läuft bei uns in vier Schritten ab — vom ersten Gespräch bis zum Betrieb. Diese Seite zeigt, welche technischen Arbeitsweisen wir in jedem Schritt anwenden.
Vier Schritte — und was in ihnen passiert.
In jedem Schritt beantworten wir bestimmte Fragen, bevor die Arbeit weitergeht. Intern fassen wir diese Arbeitsweisen als Batunet Engineering Method zusammen.
- 01
Verstehen und Anforderungen klären
Im ersten Gespräch mit der Geschäftsführung geht es um Ihr Vorhaben, Ihre Abläufe und die vorhandenen Systeme. Danach halten wir Ziele und Anforderungen schriftlich fest und sagen offen, ob eine individuelle Entwicklung sinnvoll ist.
Problem eingrenzen
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.
Fachlichkeit modellieren
Wo verlaufen die echten Grenzen dieses Systems?
Die Domäne wird modelliert und in Kontexte geschnitten — mit einer präzisen, gemeinsamen Sprache.
- 02
Lösung und Architektur planen
Wir schlagen eine technische Lösung vor, legen Umfang und Reihenfolge der Umsetzung fest und dokumentieren die tragenden Entscheidungen mit ihrer Begründung.
Tragende Entscheidungen treffen
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.
Kritischen Pfad erproben
Funktioniert der schwierigste Pfad End-to-End?
Ein lauffähiges Skelett beweist die Architektur auf dem riskantesten Pfad — vor der Breite.
- 03
Entwickeln und gemeinsam prüfen
Wir entwickeln in Etappen, mit Tests und Code-Reviews. Zwischenstände stellen wir regelmäßig vor, damit Sie früh prüfen und Prioritäten anpassen können.
Schrittweise entwickeln
Ist jedes Inkrement für sich auslieferbar, getestet und umkehrbar?
Auf dem bewiesenen Skelett entsteht das System in prüfbaren, umkehrbaren Schritten — Fortschritt regelmäßig sichtbar.
Belastbarkeit prüfen
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“.
- 04
In Betrieb nehmen und weiter betreuen
Nach dem Start übernehmen wir im vereinbarten Umfang Wartung, Updates, Überwachung und Weiterentwicklung. Der projektspezifische Quellcode und die Dokumentation gehen an Sie über.
Betreiben und weiterentwickeln
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.
Sechs Grundsätze, die in jedem Schritt gelten.
Verstehen vor Bauen. Teure Entscheidungen zuerst. Den schwierigen Pfad zuerst beweisen. Betreiben, was wir bauen.
Verstehen vor Bauen
Wir entwickeln erst, wenn das Problem definiert ist und feststeht, woran Erfolg gemessen wird. Der teuerste Fehler ist die gut gebaute Lösung für das falsche Problem.
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.
Umkehrbarkeit vor Vorhersage
Wir sagen die Zukunft nicht voraus, wir halten Änderung günstig. Jede wichtige Entscheidung ist als umkehrbar oder nicht klassifiziert.
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.
Fehlerfälle einplanen
Wir entwerfen für den Fehlerfall und proben ihn, bevor es die Produktion tut. Ein System, dessen Fehlerfälle unbekannt sind, ist nicht fertig.
Betreiben, was wir bauen
Betreibbarkeit ist eine Entwurfsentscheidung vom ersten Tag, keine Übergabe am letzten. Wir bauen so, als müssten wir das System über Jahre selbst betreiben.
Entscheidungen, die dokumentiert bleiben.
Das Gedächtnis eines Projekts sind seine Entscheidungsprotokolle (Architecture Decision Records, kurz ADRs). Jeder Schritt ergänzt sie, jeder Schritt 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 erhalten bleibt, lässt sich ein System auch nach Jahren sicher ändern. Wo es verloren geht, ist jede Änderung ein Risiko.
So sieht eine Entscheidung aus.
Ein generischer Auszug — ohne Kundenbezug. Das Format, in dem wir tragende Entscheidungen festhalten.
- 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.
Beschreiben Sie kurz Ihr Vorhaben. Das erste Gespräch führen Sie direkt mit der Geschäftsführung.
