Wenn wir mit Kund:innen über Team Topologies reden, stehen häufig komplizierte Subsysteme im Mittelpunkt, deren Beibehaltung als unbedingt nötig angesehen wird. Dabei sind komplizierte Subsysteme eher Ausnahmen in gut strukturierter Softwareeentwicklung, in der sie der kognitiven Entlastung der Teams dienen. Sobald sie eher Software- oder Organisationsartefakte unpassendere organisatorische Schnitte sind, produzieren sie unnötige Handoffs und weisen auf Veränderungsbedarf hin.
Complicated Subsystems - technisch bedingte Produkte - manchmal auf Zeit
“A complicated-subsystem team is responsible for ... a part of the system, that depends heavily on specialist knowledge, to the extent that most team members must be specialists in that area of knowledge. (...) Examples of complicated subsystems might include a video processing codec, a mathematical model, (...) or a face-recognition engine.”
Die für komplizierte Subsysteme verantwortlichen Teams sollen die stream aligned teams entlasten, in dem sich nötige und rare Spezialfähigkeiten in einem Team und in einem speziellen Subsystem konzentrieren. Die Seltenheit dieser Fähigkeiten kann in der besonderen Neuheit und Spezifik des notwendigen Wissens begründet liegen oder auch in der Seltenheit als aussterbender Kompetenz. Die für die Entwicklung und den Betrieb solcher Systeme benötigten seltenen technischen Fähigkeiten machen diese Systeme für andere kompliziert und verhindern die Aufteilung auf die Entwicklungsteams.
Teams, die komplizierte Subsystem verantworten, kollaborieren gleichwohl intensiv mit anderen Entwickler:innen, sobald ihre Leistung spezifisch auf die Interessen der jeweiligen stream aligned teams zugespitzt werden muss. Der Nutzen komplizierter Systeme für das Gesamtsystem entsteht durch Vereinfachung nach außen im betreffenden Team. Nach der initialen Aushandlung durchlaufen complicated subsystems den Weg zunehmender Entkopplung von der Kollaboration über die Kommunikation via API bis zu X-as-a-service. Sie scheinen damit den Plattform Teams verwandt.
Das stimmt aber nur zum Teil, denn sie sind - aus technischer Sicht - die ersten Kandidat:innen für Ablösung oder Veränderung:
-
Komplizierte Subsysteme können in stream aligned teams aufgehen, sobald das bisher exklusive Spezialwissen breit verteilt wird, z.B. in dem Basiswissen der data science ubiquitär wird.
-
Die Verbreitung dieser Kompetenzen kann durch die Transformation vom complicated subsystem team zum enabling team stattfinden. Ob dabei tatsächlich das Subsystem in die Teams getragen und z.B. in Teilen dort repliziert wird oder der Ersatz der spezialisierten Technik durch teameigene Lösungen erfolgt, ist dabei nachrangig.
-
Kompliziertes Wissen gelangt auch breit in die stream aligned teams, sobald es in geschlossenen Produkten oder Bibliotheken zusammengefasst wird (z.B. sind die im Zitat genannten Gesichtserkennungssoftwaren heute weit verbreitet und verfügbar).
-
Logischerweise sterben komplizierte Subsysteme und die sie tragenden Teams auch ab, wenn die Software- und System-Dinosaurier durch neue Lösungen ersetzt werden, z.B. wenn die letzten mainframes das Unternehmen verlassen.
-
Systematisch wandert das Wissen in den Bereich intrinsic cognitive load, wenn es sich zum notwendigen Handwerkszeug aller Entwicklungsteams wandelt (z.B. Data Science oder Securityaspekte) oder es wird Bestandteil der Plattform, in dem es in einer internen Struktur der Plattform aufgeht oder durch standardisierte Plattformbestandteile ersetzt wird (z.B. Authentifizierung und basale User-Security).
-
Dauerhafte komplizierte Subsysteme entstehen, wenn das Ergebnis des Spezialwissens für viele Teams verfügbar gemacht werden muss, dieses aber möglichst unbelastet via einfacher APIs erfolgt, z.B. bei PIM im E-Commerce, komplexen Media Asset Systemen oder - Stand heute - bei Zahlungsarten.
Insofern können die komplizierten Subsysteme entspannt verhandelt werden. Man braucht sie, bis die Leistung auch anderswo oder auf andere Weise erbracht werden kann. In ganz wenigen Fällen verbleiben sie vollständig gekapselt und werden im Unternehmen oder als Zukauflösung realisiert (z.B. Zahlungssysteme, Risikomanagement, Bonitätsprüfungen oder Frauddetection).
Bis zu diesem Zeitpunkt funktionieren sie unproblematisch und entlasten ähnlich wie Plattformen andere Teams. Auch komplizierte Subsysteme werden in der Team Topology als Produkte entwickelt und angepasst: Sie finden ihren Ort als Ergebnis zunehmender technischer Reife.
Sobald Team Topologies implementiert werden, entstehen neue komplizierte Subsysteme eher als Binnenstrukturen in Plattformen oder stream aligned teams. Sie werden als solche wenig sichtbar.
Complicated Subsystems und organisatorisches Beharrungsvermögen
Wenn wir Bestandsaufnahmen von Teams und Systemen machen und im Rahmen von Vertikalisierungsdiskussionen über die vermutlich sinnvollen Team Topologies sprechen, wird das rote Sechseck anfangs häufig verwendet.
Viele fachlich begründete Silos, Abteilungen, die erfolgreich Aufgaben eingeworben haben, funktionsangereicherte Übergabeschichten, die Brüche in Wertströmen überwinden und deren technische Abbildungen werden als unverzichtbare "komplizierte Subsyteme" markiert.
Sie können aus Sicht der Protagonist:innen aufgrund der besonderen Bedeutung
a) nicht verändert werden,
b) liegen quer zum flow der stream aligned teams und
c) werden oft von selbstbewussten Teams und Manager:innen vertreten, die ihr jeweiliges Spezialwissen herausstreichen und auf allen unternehmerischen Bühnen einzusetzen wissen.
In diesen Fällen muss man abschichten und mit dem Verhältnis technischer und fachlich-organisatorischer Strukturen beginnen:
-
In welchem Verhältnis stehen die komplizierten Subsysteme zu den stream aligned teams. Welche unabweisbaren technischen Spezialitäten verhindern die Integration in die am zu stiftenden Kundenwert ausgerichtete Vertikale? Wie lange ist das noch erforderlich, lohnt sich die Migration?
-
Können vorhandene Middlewares durch flexible technische Konfektionen ersetzt werden? Schließen die Schnittmuster (fractal plans) die complicated subsystems ein?
-
Wichtig: Handelt es sich lediglich um fachlich-organisatorische Spezialitäten, ist in der Regel kein eigenes technisches Subsystem nötig sondern vielmehr eine Integration der Fachlichkeit in die Vertikale gefordert.
Ein Beispiel wären Sicherheits- und Datenschutzfeatures, die gerne von Legal-Abteilungen als "Add-on" und vom Wertstrom abgesetztes Thema definiert werden (und so eigene Teams und Systeme begründen sollen). Sie gehören aber in als jeweils angepasstes Funktionsbündel in jede Vertikale. Nur, wenn in jeder Vertikale die DGSVO von Anfang an beachtet wird und die “berechtigten Interessen” die Verwendung und Speicherung der Daten leiten, wird diesem Teil der Domäne Rechnung getragen.
Oder vereinfacht gesprochen: Wenn jede Vertikale nur speichert, was sie darf und braucht, sind Datenlöschungen und notwendigerweise asynchrone komplizierte DGSVO Prozesse nicht mehr nötig. Und die Rechtsabteilung verwandelt sich vom Inhaber und Betreiber eines eigenen Systemes in einen Stakeholder, dessen Interessen durch die Entwicklungsteams beachtet und bedient werden, in dem man die Interessen der Kund:innen beachtet und bedient.
-
Welche technischen und fachlichen Kern enthalten die Subsysteme, wie können Übergaben an die konsumierenden Vertikalen und stream aligned teams, ggf. auch als Replikationen mit je eigenen Ergänzungen via API erfolgen.
-
Welche Funktionen gehören in die Plattformteams und -produkte, welche werden via enabling in die Teams getragen.
-
Welche wenigen komplizierten Subsysteme verbleiben dann und wie können sie als Produkte mit dem Blick auf ihre Kund:innen, nämlich die stream aligned teams, gestaltet werden.
-
Dabei gilt: Wenn komplizierte Subsysteme nötig sind, möge sich die Kommunikation möglichst von der Kollaboration hin zur robusten API entwickeln.
Fazit
Sogenannte komplizierte Subsysteme sind häufig entweder Artefakte alter Organisation und Technik oder Residuen unvollkommener fachlicher Schnittmuster. Sie liefern vielfach Hinweise auf einen nicht zu Ende gedachten stream of change und die blinden Flecken der Organisation.
Viele scheinbar dauerhafte komplizierte Subsysteme sterben in reifen und auf stream of change ausgerichtete Organisationen ab. Sie werden als Wissen (intrinsic) oder Plattformbestandteil (extraneous) ubiquitär. Insbesondere beim Einsortieren in den Werkzeugkasten der Entwickelnden hilft Enabling.
Echte complicated subsystems sind entweder eine zeitlich begrenzte Notwendigkeit oder eine echte Speziallösung, die es nicht rechtfertigt in den Kanon des intrinsischen Wissens übernommen zu werden. Sie wandern daher häufig in die Binnenstruktur größerer und skalierter Teams (stream aligned oder platform). Sie können dort Hinweise auf neue Bruchlinie liefern, sind aber prinzipiell unkritisch, wenn sie dem Zweck der Vertikalen verpflichtet sind.
Für wenige Themen werden komplizierte Subsysteme dauerhaft sinnvoll sein. Diese “Produkte” bieten robuste und einfache APIs, kapseln ihre Kompliziertheit und sind soweit als möglich entkoppelt. Unter diesen Bedingungen können technisch begründete komplizierte Systeme gut im Gesamtsystem wirken. Im E-Commerce sind PIM Systeme manchmal complicated Subsystems.
Mehr zum Thema der Team Topologies:
Team Topologies in Auftraggeber-Dienstleister Konstellationen
Team Topologies II - Defining Streams
Team Topologies III - Optimizing Flow
