← Zurück zum Glossar

System Design

[object Object]

Was ist System Design?

System Design ist Phase 3 der TRANSFORM-Methodik und bezeichnet den Architektur-Neuentwurf nach der Root Cause Analysis. Das zentrale Element ist die Implementierung eines API Gateways — einer expliziten Zugriffskontroll-Schicht, die reguliert, wer und was Zugriff auf Zeit, Aufmerksamkeit und Ressourcen des Leaders bekommt. Parallel werden SPOFs identifiziert und durch redundante Strukturen ersetzt.

System Design ist nicht die Umsetzung. Es ist der Entwurf. Umgesetzt werden die neuen Regeln in Phase 4 (Continuous Deployment).

Wie funktioniert das?

Ein API Gateway in der Lebens-Architektur hat drei Funktionen:

Authentifizierung. Wer darf überhaupt Anfragen stellen? Interne Stakeholder, enge Familie, zahlende Kunden, strategische Partner — jede Kategorie hat klare Berechtigungen. Random Anfragen von außen haben keine Standard-Berechtigung.

Rate Limiting. Wie viele Anfragen dürfen pro Zeiteinheit durchkommen? Ein Kunde mit unbegrenztem Zugriff ist ein SPOF — er kann das gesamte System auslasten. Klare Grenzen schützen die Kapazität.

Filterung und Routing. Welche Anfragen gehen direkt zum Leader, welche werden asynchron behandelt, welche werden an andere Komponenten (Team, Assistent, Automatisierung) geroutet? Synchron an den Leader ist die teuerste Option und darf nicht Default sein.

Parallel zum Gateway läuft die SPOF-Eliminierung: Wo gibt es Einzelpunkte, deren Ausfall das System killt? Diese werden entweder durch Redundanz abgesichert (zweites Einkommen, zweite Fähigkeit, zweite Regulationsquelle) oder durch bewusste Risiko-Akzeptanz mit Notfallplan adressiert.

Technisches Konzept und Lebens-Architektur

In der Microservice-Architektur ist das API Gateway der zentrale Eingangspunkt: Keine Anfrage geht direkt an einen Service, alle laufen durch das Gateway. Das Gateway prüft Auth, Rate Limits, Versionierung und Routing. Dahinter können Services flexibel ausgetauscht werden, weil die Außenschnittstelle stabil bleibt.

In der Lebens-Architektur entspricht das Gateway den Kommunikationsprotokollen eines Leaders: Wie erreicht man ihn, über welchen Kanal, mit welcher Erwartung an Antwortzeit, für welche Arten von Anfragen. Ein klar definiertes Gateway ist der Unterschied zwischen reaktivem und steuerndem Leadership.

Ohne Gateway bekommt jeder Slack-Ping, jede E-Mail, jeder Anruf gleich behandelt — der Leader wird zur synchronen CPU für alles. Mit Gateway sind die Zugriffspfade klar, und der Leader kann sich auf die wirklich wichtigen Anfragen konzentrieren.

In der Praxis

Typische System-Design-Entscheidungen:

  • Kein Slack-DM für Themen, die in einem öffentlichen Kanal diskutiert werden sollten — die Zugriffsregel wird explizit kommuniziert.
  • Keine Telefonanrufe außerhalb definierter Notfälle — stattdessen asynchrone Kommunikation mit klaren Antwort-SLAs.
  • Strategische Stakeholder haben einen vereinbarten wöchentlichen 1:1-Slot, keine Ad-hoc-Meetings.
  • Kunden-Anfragen laufen über ein klar definiertes Ticket-System, nicht direkt an den Leader.
  • Personal-Gespräche haben feste Slots, keine spontanen „kannst du kurz" im Gang.

Die Regeln sind nicht unhöflich — sie sind transparent. Unhöflich wäre, Zugriff zu erlauben und dann nicht zu antworten. Höflich ist, klare Protokolle zu haben, die Verlässlichkeit erzeugen.

Häufige Fragen

Macht das nicht distanziert und bürokratisch? Das Gegenteil ist der Fall. Ohne klare Zugriffsregeln entsteht Unberechenbarkeit — manche Anfragen werden sofort beantwortet, andere gehen verloren, und niemand versteht das Muster. Klare Regeln erzeugen Verlässlichkeit, und Verlässlichkeit erzeugt Vertrauen. Bürokratisch wird es nur, wenn die Regeln rigide ohne Rücksicht auf Kontext angewandt werden — gutes System Design bleibt kontextsensitiv.

Wie erkläre ich das neue Gateway meinem Team? Direkt und als Architektur-Entscheidung, nicht als persönliche Befindlichkeit. „Ich strukturiere meine Kommunikation so, dass ich schneller und besser entscheiden kann — das hilft euch mehr als meine bisherige permanente Erreichbarkeit." Die Begründung muss für das Team einen erkennbaren Nutzen enthalten, nicht nur für den Leader.

Was, wenn mein Arbeitgeber das Gateway nicht akzeptiert? Dann ist das selbst eine wichtige Information — entweder über den Arbeitgeber, über die Rolle oder über die Erwartungs-Mismatches. System Design ist nicht gegen den Arbeitgeber gerichtet, aber es kann aufdecken, dass die aktuelle Konstellation dauerhafte Überlastung systemisch erfordert. Das ist eine Erkenntnis, keine Niederlage.