Die fünf Fragen, die ich stelle, bevor ich ein System baue
Die meisten Systeme scheitern nicht, weil die Technologie falsch war, sondern weil das Problem vor Baubeginn nicht klar genug verstanden wurde. Die wichtigsten Architekturentscheidungen werden in den ersten Stunden eines Projekts getroffen — oft bevor eine einzige Zeile Code oder ein einziger Automatisierungsschritt geschrieben wird.
Im Laufe der Zeit habe ich fünf Fragen entwickelt, die ich zu Beginn jedes Projekts stelle. Sie sind kein Framework. Sie sind Drucktests. Jede ist darauf ausgelegt, eine Annahme aufzudecken, die, wenn sie unkontrolliert bleibt, später Probleme verursachen wird.
1. Was ist die eigentliche Einschränkung?
Nicht das Symptom. Nicht das Tool, das die Leute frustriert. Die eigentliche Einschränkung — der Punkt im Prozess, an dem sich Arbeit ansammelt, verlangsamt oder verschwindet. Bei fast jedem Projekt, an dem ich gearbeitet habe, sind das angegebene Problem und die eigentliche Einschränkung verschiedene Dinge. Jemand sagt "wir brauchen eine bessere Datenbank" und das eigentliche Problem ist, dass Daten inkonsistent an der Quelle eingegeben werden. Jemand sagt "wir brauchen Automatisierung" und das eigentliche Problem ist, dass sich niemand einig ist, wie die Ausgabe aussehen soll.
Die eigentliche Einschränkung zu finden erfordert normalerweise, die erste Antwort zu ignorieren und erneut zu fragen.
2. Wie sieht Erfolg um 3 Uhr morgens aus?
Jedes System wird ohne Aufsicht laufen. Die Frage ist, was es tut, wenn etwas schief geht und niemand zuschaut. Scheitert es elegant? Benachrichtigt es jemanden? Läuft es in einem reduzierten Modus weiter, bis ein Mensch eingreifen kann? Korrumpiert es still Daten?
Das Entwerfen für das 3-Uhr-morgens-Szenario zwingt Sie, Fehlerzustände, Wiederholungslogik, Überwachung und Benachrichtigung als erstklassige Anliegen zu betrachten — nicht als Nachgedanken. Ein System, das in der Demo perfekt funktioniert und in der Produktion still scheitert, hat das Problem nicht gelöst.
3. Wo schafft menschliches Urteilsvermögen den größten Wert?
Automatisierung sollte aggressiv auf das Vorhersehbare und Regelbasierte angewendet werden. Aber jedes System hat Punkte, an denen menschliches Urteilsvermögen unersetzlichen Wert schafft — wo der Randfall zu nuanciert, der Einsatz zu hoch oder der Kontext zu mehrdeutig ist, damit eine Maschine zuverlässig damit umgehen kann.
Diese Punkte vor dem Bauen zu identifizieren bestimmt die Architektur. Das System sollte diese Entscheidungen effizient an Menschen weiterleiten — mit dem richtigen Kontext, zum richtigen Zeitpunkt, über den richtigen Kanal. Alles andere ist ein Kandidat für Automatisierung.
4. Wie sieht dieses System in zwei Jahren aus?
Nicht weil ich für zwei Jahre im Voraus bauen muss — das tue ich nicht. Aber weil das Nachdenken darüber, wohin ein System gehen muss, Architekturentscheidungen aufdeckt, die zu Beginn korrekt zu treffen billig und später zu ändern teuer sind. Datenbankschema. API-Design. Die Art, wie Datensätze verknüpft sind. Die Art, wie Fehler protokolliert werden. Diese Dinge summieren sich.
Ein System, das nur für den heutigen Maßstab ausgelegt ist, wird ersetzt werden. Ein System, das mit den Einschränkungen von morgen im Kopf entworfen wurde, wird erweitert werden.
5. Was passiert, wenn sich die Eingaben ändern?
Jedes System nimmt etwas über seine Eingaben an. Der Barcode ist immer gültig. Die API gibt immer das erwartete Schema zurück. Die Datei ist immer im richtigen Format. Diese Annahmen werden verletzt werden. Die Frage ist, ob das System damit elegant umgeht oder bricht.
Diese Frage vor dem Bauen zu stellen zwingt Sie dazu, Eingabevalidierung, Normalisierung und Fallback-Behandlung als Teil der Kernarchitektur zu entwerfen. Es ist der Unterschied zwischen einem System, das konstante Wartung benötigt, und einem, das reale Variabilität ohne Eingriff handhabt.
Die Antworten sind die Architektur
Bis ich diese fünf Fragen mit klarem Kopf durchgearbeitet habe, ist die Form des Systems normalerweise offensichtlich. Die Technologieentscheidungen folgen aus den Antworten — nicht umgekehrt. Das ist die Reihenfolge, die funktioniert.