Architecture-first Consulting: was es wirklich bedeutet

„Architecture-first“ ist ein Begriff, der in einem Website-Hero gut klingt und für die Leute, die Consulting einkaufen, nichts bedeutet. Jede Agentur wird Ihnen sagen, dass ihre Architects Senior sind. Jede Boutique behauptet, Design vor Code zu stellen. In der Praxis schicken die meisten in Woche eins Junior-Entwickler zum Codieren und beschreiben das Ergebnis im Nachhinein als Architektur.

Machen wir es also überprüfbar. Hier ist, was Architecture-first in unseren Engagements tatsächlich bedeutet, und vier konkrete Dinge, die wir deshalb ablehnen.

Arbeitsdefinition

Architecture-first bedeutet: Bevor die erste Zeile Produktionscode geschrieben wird, haben wir aufgeschrieben — und mit Ihnen vereinbart — wie die Lösung aussieht, welche Teile davon riskant sind und warum wir sie gegenüber den drei Alternativen gewählt haben, die wir in Betracht gezogen haben.

Konkret ist das ein Architecture Decision Document. Es hat drei Abschnitte:

1. Das Diagramm. Eine System-Level-Zeichnung, die die Bausteine, ihre Trust Boundaries und die Hauptflüsse zeigt. Kein UML-Meisterwerk — ein Bild in Whiteboard-Qualität, das jeder technisch Versierte in 90 Sekunden lesen kann.
2. Die Entscheidungen. 5–15 nummerierte ADRs (Architecture Decision Records). Jede sagt: „Wir haben X statt Y gewählt, weil Z.“ Das war's. Zukünftige Maintainer können sie in zehn Minuten überfliegen und verstehen, warum das System so aussieht, wie es aussieht.
3. Die Risiken. Was schiefgehen kann, wie hoch wir die Wahrscheinlichkeit einschätzen und was wir tun werden, wenn es passiert. Kein performatives Händeringen — 3 bis 7 echte Punkte, die Aufmerksamkeit verdienen.

Das ist das Artefakt. Seine Aufgabe ist es, Meinungsverschiedenheiten billig und sichtbar zu machen, bevor sie zu umgeschriebenem Code werden.

Vier Dinge, die wir ablehnen

1. Wir starten nicht mit „lass uns einfach prototypen“

„Prototyp zuerst, Architektur später“ ist ein legitimer Ansatz, wenn das Problem klar unbekannt ist. In 95 % der Fälle ist das Problem bekannt — es ist das Commercial-Team unter Druck, schnell etwas zu zeigen. Prototype-first erzeugt in diesen Fällen Code, der in die Produktion geht, ohne dass die Architektur je aufgeschrieben wird. Sechs Monate später ist es „der Prototyp“, an den sich niemand mehr traut.

Wenn ein Prototyp tatsächlich der richtige Zug ist (z. B. um eine neuartige technische Annahme zu validieren), legen wir vorab ein Wegwerf-Budget fest: zwei Wochen, ein Entwickler und die ausdrückliche Erlaubnis, alles zu löschen.

2. Wir stellen Ihnen nicht in Rechnung, Allzweck-Frameworks zu schreiben

Consulting-Projekte haben die schlechte Angewohnheit, interne Frameworks wachsen zu lassen, die nur innerhalb des Projekts Sinn ergeben. Custom-Formular-Libraries, maßgeschneiderte i18n-Wrapper, hauseigene State Machines. Sie fühlen sich für den Entwickler, der sie schreibt, produktiv an und werden in dem Moment zur Belastung, in dem jemand Neues dazukommt.

Die Regel: Wenn eine vernünftige Third-Party-Library existiert, benutzen wir sie. Chakra UI, React Hook Form, TanStack Query, Zod, Prisma — das ist nicht glamourös, aber diese Libraries werden von mehr Leuten gepflegt, als es jedes Consulting-Projekt je könnte. Wir bauen nur dann Custom, wenn die Domäne wirklich keine äquivalente Off-the-shelf-Option hat.

3. Wir trennen nicht „den Architect“ von „den Engineers“

Ein klassisches Fehlermuster: Der Senior Architect entwirft das System, Junior-Engineers schreiben es, und der Architect verschwindet zum nächsten Projekt. Unvermeidliches Ergebnis — das Junior-Team stößt auf einen Design-Edge-Case, den der Architect nie vorausgesehen hat, improvisiert drumherum, und die Architektur driftet innerhalb von Wochen vom Diagramm ab.

In unseren Projekten schreibt derjenige, der die Architektur geschrieben hat, auch Produktionscode in diesem Projekt. Nicht als Kontrollmechanismus — als Feedback-Loop. Wenn eine Design-Entscheidung den Code umständlich macht, merken wir das in Woche zwei, nicht in Monat sechs, wenn die Integrations-Tests es aufdecken.

4. Wir machen keine reine Beratung

Wir machen nicht das Klischee von „wir schreiben Ihnen einen Bericht und sind dann weg“. Schriftliche Empfehlungen, die niemand umsetzt, sind nichts wert. Schriftliche Empfehlungen, bei deren Umsetzung wir helfen, sind das wert, wofür sie bezahlt wurden.

Wenn wir ein Architekturdokument schreiben, begleiten wir es entweder bis zum Go-live, oder wir übergeben es mit einem namentlich benannten Engineer, der das tut — kein vages „vielleicht kann Ihr Team den ADRs folgen“. Das bedeutet normalerweise, mindestens bis zum ersten produktiven Release dessen dabei zu bleiben, was das Dokument beschreibt.

Warum das für Ihr Projekt wichtig ist

Die meisten Consulting-Horrorgeschichten lassen sich auf eines dieser vier Dinge zurückführen. Der Prototyp, der in die Produktion ging. Das maßgeschneiderte Framework, das niemand pflegen kann. Der Architect, der verschwunden ist. Der Bericht, der in einem geteilten Laufwerk liegen geblieben ist.

Architecture-first Consulting bedeutet nicht, monatelang zu brauchen, bevor Sie Code sehen. In der Praxis werden unsere Architekturdokumente typischerweise in 48 Stunden nach dem ersten Gespräch geschrieben. Sie sind kurz, pointiert und in kleinen Punkten falsch, die im Code korrigiert werden. Der Punkt ist nicht, das Design einzufrieren — der Punkt ist, Meinungsverschiedenheiten sichtbar zu machen, solange sie noch billig sind.

Wenn Sie Consulting-Optionen bewerten, ist der einfachste Test: Bitten Sie um das zuletzt produzierte Architekturdokument, redigiert für Vertraulichkeit. Wenn sie eines für das Meeting erfinden müssen, wissen Sie, was Sie kaufen.