Wann ein Feature-Team den Code nicht anfassen sollte: Der Fall für ein Complicated-Subsystem-Team

Ihr Team entwickelt eine E-Commerce-Plattform. Sie sind verantwortlich für den Checkout-Prozess, den Produktkatalog und die Benutzerprofilseite. Alles läuft gut – bis eine Änderung am Zahlungsmodul nötig wird. Plötzlich erfordert das einfachste Update drei Code-Reviews, zwei Freigaben und ein Stoßgebet vor dem Deployment. Eine einzige falsche Zeile könnte einen Kunden doppelt belasten oder eine Transaktion komplett verlieren. Das Team wird langsamer, nicht weil es aus schlechten Ingenieuren besteht, sondern weil die Zahlungsmaschine ein ganz anderes Kaliber ist.

Diese Situation ist alltäglich. Jede Anwendung hat Teile, die zu riskant, zu spezialisiert oder zu komplex sind, um sie einem generalistischen Feature-Team sicher zu überlassen. Die übliche Stream-aligned-Teamstruktur funktioniert hervorragend für die meisten Features, aber sie versagt, wenn der Code tiefes, enges Fachwissen erfordert. Hier kommt das Complicated-Subsystem-Team ins Spiel.

Was ein Subsystem kompliziert macht

Nicht jedes Stück Code braucht ein eigenes dediziertes Team. Ein kompliziertes Subsystem hat bestimmte Merkmale. Es ändert sich selten, aber wenn es sich ändert, sind die Auswirkungen weitreichend und gefährlich. Es erfordert Wissen, das Monate oder Jahre dauert, um es aufzubauen. Das Verhalten ist nicht offensichtlich: Randfälle, Race Conditions und subtile Zustandsabhängigkeiten, die sich erst in der Produktion zeigen.

Denken Sie an eine Zahlungsmaschine, ein zentrales Datenbankschema, ein Abrechnungssystem oder ein Betrugserkennungsmodul. Diese sind nicht nur komplex im Sinne von vielen Codezeilen. Sie sind kompliziert, weil die Kosten für einen Fehler hoch sind und der Weg zum richtigen Ergebnis schmal ist. Ein Feature-Team, das an Produktseiten arbeitet, kann es sich nicht leisten, drei Wochen damit zu verbringen, die Eigenheiten des Zahlungs-Gateways zu lernen, nur um eine neue Zahlungsmethode hinzuzufügen.

Wie ein Complicated-Subsystem-Team arbeitet

Dieses Team existiert für einen Zweck: ein bestimmtes Subsystem zu besitzen und zu warten, das tiefgehendes Fachwissen erfordert. Es entwickelt keine benutzerseitigen Features. Es reagiert nicht direkt auf Kundenanfragen. Seine Aufgabe ist es, das Subsystem stabil, sicher und für andere Teams nutzbar zu halten.

Das Interaktionsmodell ist X-as-a-Service. Das Complicated-Subsystem-Team bietet eine klare Schnittstelle, in der Regel eine API, die Stream-aligned-Teams aufrufen können, ohne die Interna zu verstehen. Das Zahlungsteam stellt Endpunkte für die Zahlungsabwicklung, die Überprüfung des Transaktionsstatus und die Einleitung von Rückerstattungen bereit. Das Feature-Team ruft diese Endpunkte auf und macht weiter. Es muss nie wissen, wie die Bankverbindung funktioniert oder wie die Abgleichlogik doppelte Transaktionen behandelt.

Diese Grenze ist entscheidend. Sie schützt das Feature-Team vor Komplexität, die es nicht braucht, und sie schützt das Subsystem vor Änderungen durch Personen, die es nicht vollständig verstehen.

Wenn Zusammenarbeit notwendig wird

Das X-as-a-Service-Modell funktioniert gut für Routineoperationen, aber manchmal braucht ein Feature-Team etwas Neues vom Subsystem. Vielleicht benötigt es eine Teilrückerstattungsfunktion, die es noch nicht gibt. In diesem Fall arbeiten die beiden Teams vorübergehend zusammen. Das Feature-Team erklärt die Anforderung. Das Complicated-Subsystem-Team entwirft die Änderung, implementiert sie und erweitert die API. Sobald die neue Funktion verfügbar ist, endet die Zusammenarbeit. Das Feature-Team kehrt zum Aufruf der API zurück, und das Complicated-Subsystem-Team kehrt zur Wartung des Subsystems zurück.

Diese vorübergehende Zusammenarbeit ist kein Scheitern des Modells. Sie ist die Art und Weise, wie das Modell nützlich bleibt. Der Schlüssel ist, dass die Zusammenarbeit einen klaren Umfang und ein definiertes Ende hat. Sie entwickelt sich nicht zu einer dauerhaften Abhängigkeit, bei der Feature-Teams für jede kleine Änderung auf das Complicated-Subsystem-Team warten.

Den Engpass vermeiden

Das größte Risiko bei einem Complicated-Subsystem-Team ist, dass es zu einem Engpass wird. Wenn jede Änderung am Subsystem die Beteiligung des Teams erfordert, werden Feature-Teams langsamer. Die Lösung besteht darin, stark in die Schnittstelle zu investieren. Die API muss flexibel, gut dokumentiert und so gestaltet sein, dass sie häufige Anwendungsfälle abdeckt, ohne ständige Aktualisierungen zu erfordern. Das Team sollte auch eine robuste CI/CD-Pipeline für sein eigenes Subsystem unterhalten, einschließlich gründlicher Integrationstests und sicherer Bereitstellungsstrategien wie Blue-Green- oder Canary-Releases.

Wenn die Schnittstelle gut ist, müssen die meisten Feature-Teams nie mit dem Complicated-Subsystem-Team sprechen. Sie nutzen einfach die API und machen weiter. Das Team wird nur dann einbezogen, wenn wirklich etwas Neues benötigt wird.

Praktische Checkliste zur Identifizierung eines komplizierten Subsystems

Bevor Sie ein Complicated-Subsystem-Team aufbauen, prüfen Sie, ob der Code wirklich dem Profil entspricht:

• Hat ein einziger Fehler in diesem Code hohe finanzielle, sicherheitstechnische oder betriebliche Kosten?
• Erfordert es spezialisiertes Wissen, das Monate dauert, um es zu erwerben?
• Ändert es sich selten, aber mit weitreichenden Auswirkungen, wenn es sich ändert?
• Wäre ein Feature-Team deutlich langsamer, wenn es diesen Code besitzen müsste?

Wenn Sie die meisten dieser Fragen mit Ja beantwortet haben, ist ein Complicated-Subsystem-Team eine Überlegung wert. Wenn nicht, behalten Sie den Code im Feature-Team und investieren Sie stattdessen in bessere Tests und Dokumentation.

Die Erkenntnis

Ein Complicated-Subsystem-Team geht nicht darum, Code zu hüten oder Hierarchien zu schaffen. Es geht darum, sowohl das Subsystem als auch die Feature-Teams vor unnötigen Risiken zu schützen. Das Feature-Team bleibt schnell, weil es die Interna einer Zahlungsmaschine nicht lernen muss. Das Subsystem bleibt sicher, weil nur Personen, die es wirklich verstehen, Änderungen vornehmen. Die Schnittstelle zwischen ihnen ist der Vertrag, der dies ermöglicht. Investieren Sie in diese Schnittstelle, und beide Teams gewinnen.