Unsere Microservices-Architektur spiegelte exakt unser Organigramm. Das ist Conway's Law in Aktion.

Die Ausgangslage:

  • Team A (5 Personen) → User Service
  • Team B (5 Personen) → Order Service
  • Team C (5 Personen) → Payment Service
  • Teams kommunizieren über API-Contracts

Was bei der Reorganisation passierte:

  • Teams A und B wurden zusammengelegt
  • Das neue Team besitzt User- + Order-Service
  • Aber User und Order haben enge API-Contracts
  • Jetzt koordiniert sich dasselbe Team über HTTP
  • Overhead ohne jeden Nutzen

Das umgekehrte Problem:

  • Team C wurde in Payment- + Fraud-Team aufgeteilt
  • Aber der Payment-Service erledigt beides
  • Zwei Teams, eine Codebasis
  • Ständige Merge-Konflikte
  • Kein unabhängiges Deployment

Die Lektion:

  • Systemdesign folgt Teamgrenzen
  • Reorganisationen erfordern Architekturänderungen
  • Oder die Architektur schränkt Reorganisationen ein
  • Keines von beidem ist kostenlos

Lektion: Entwerfen Sie Ihre Teams, bevor Sie Ihre Architektur entwerfen. Oder rechnen Sie später mit schmerzhafter Neuausrichtung — beides im Einklang zu halten ist ebenso eine organisatorische Übung wie eine Frage des DevOps-Engineerings.

← Zurück zu Lessons Learned

Incidents wie dieser sind vermeidbar. Unser AWS Managed Services-Team überwacht Kundenumgebungen 24/7 mit KI-gestütztem Monitoring und Senior Engineers am Pager — damit Geschichten wie diese im Archiv bleiben.

Tags: #Microservices #Organisation #Conway #Architektur