Kapitel 4. Das Conway'sche Gesetz und die Suche nachden richtigen Grenzen

Diese Arbeit wurde mithilfe von KI übersetzt. Wir freuen uns über dein Feedback und deine Kommentare: translation-feedback@oreilly.com

Jede Organisation, die ein System entwirft, ... wird ein Design produzieren, dessen Struktur eine Kopie der Kommunikationsstruktur der Organisation ist.

Melvin E. Conway

Sobald du mehr als ein Team hast, musst du dein System aufteilen (denn effektive Teams haben das alleinige Eigentum an dem Code, an dem sie arbeiten).

Zu Beginn dieses Kapitels erläutere ich, was das Conway'sche Gesetz ist und welche Auswirkungen es auf deine Organisationsstruktur hat.

Dann erkläre ich dir, wie du die richtigen Grenzen zwischen den Teams findest (die auch die Grenzen deiner Architektur sein werden) und wie du erkennst, wann sich diese Grenzen ändern müssen. Du solltest damit rechnen, dass sich die Anforderungen deines Unternehmens, die verfügbare Technologie oder die Dinge, auf die du dich konzentrierst, ändern - aber das wird auch passieren, wenn du deine Domänen besser verstehst.

Aufgrund des Conway'schen Gesetzes solltest du sowohl am organisatorischen Design als auch an der Systemarchitektur arbeiten. Wenn du 10 Entwickler hast, brauchst du dann drei Teams oder zwei? Das hängt davon ab, wie du das System am besten aufteilen kannst. Du suchst nach logischen Aufteilungen in der Geschäftsdomäne, die sich in der Architektur widerspiegeln und jedem Team eine Arbeit zuweisen, die seine Kapazität nicht übersteigt.

Um dies effektiv zu tun, brauchst du ein gutes Verständnis für das Geschäft, aber auch ein hohes Maß an technischem Fachwissen. Ruth Malan sagt: "Wenn Manager entscheiden, welche Dienste von welchen Teams entwickelt werden, entscheiden sie auch über die Systemarchitektur."1

Beginnen wir mit dem Conway'schen Gesetz.

Conway's Gesetz

1968 veröffentlichte Mel Conway eine kurze Abhandlung - nur 45 Absätze lang - mit dem Titel "How Do Committees Invent?"2

Die zu Beginn dieses Kapitels zitierte Schlussfolgerung des Artikels ist als Conway's Law bekannt geworden, und wie Martin Fowler sagt, ist es "wichtig genug, um jedes System zu beeinflussen, das mir begegnet ist, und mächtig genug, dass du zur Niederlage verurteilt bist, wenn du versuchst, es zu bekämpfen."

Das Conway'sche Gesetz besagt, dass Softwareentwicklungsunternehmen Softwarearchitekturen produzieren, die ihre Organisationsstruktur widerspiegeln: Wenn du zwei Entwicklungsteams hast, wirst du am Ende zwei Subsysteme haben.3

Conway beginnt mit der Feststellung, dass "jedes System von Bedeutung aus kleineren Subsystemen aufgebaut ist, die miteinander verbunden sind." Man unterteilt immer wieder in kleinere Systeme, bis man zu einem System gelangt, das einfach genug ist, um verstanden zu werden. Verschiedene Teams entwerfen dann diese verschiedenen Teilsysteme.

Wie Conway betont, haben sowohl Organisationen als auch Systeme eine Graphenstruktur, die aus Knoten und Linien besteht. Bei einem System stehen die Knoten für die Teilsysteme und die Schnittstellen zwischen ihnen, bei einer Organisation für die Teilgruppen und die Kommunikationswege (denn die Gruppen müssen miteinander reden, um sich über die Schnittstellen zwischen den Teilsystemen zu einigen). Conway stellt fest, dass das System und die Organisation, die es entwickelt, die gleiche Form haben. Mit anderen Worten: Die Teilsysteme und Schnittstellen entsprechen den Teilgruppen und Kommunikationswegen. Abbildung 4-1 zeigt, wie das aussieht.4

Four subsystems with interfaces map neatly to three subgroups within communication lines, with one group owning two subsystems.
Abbildung 4-1. Systeme und Untergruppen sind beides Graphen, und du kannst einen Graphen dem anderen zuordnen.

Die einzelnen Gruppen, die Teilsysteme entwerfen, müssen sich abstimmen, damit die Teilentwürfe zu einem einzigen Entwurf zusammengeführt werden können. Du wirst feststellen, dass Teams, die näher beieinander sind, auch engere Entwürfe erstellen, weil es für sie einfacher ist, miteinander zu kommunizieren und etwas über die Systeme des anderen zu lernen. Wenn die verschiedenen Gruppen lose gekoppelt sind, wird auch der Entwurf eher lose gekoppelt sein: Die Schnittstellen sind relativ stabil und die beiden Gruppen müssen ihre Arbeit nicht so oft koordinieren. Eine Studie von Alan MacCormack und Kollegen verglich die Entwürfe kommerzieller Unternehmen mit Open-Source-Alternativen und stellte fest, dass erstere viel stärker gekoppelt sind, wie es das Conway'sche Gesetz vorhersagen würde.5

Das hat einige interessante Konsequenzen. Erstens: Da die Arbeit auf die bestehenden Gruppen aufgeteilt wird, werden alle Einschränkungen, die du in der Organisation hast, auch in den Systemen abgebildet. Eine hierarchische Organisation führt zu einem ganz anderen Systemdesign als eine, die eher eine graphische Struktur aufweist. Das bedeutet auch, dass einige Arten von Systemdesign nicht möglich sind, weil die Organisation sie nicht unterstützen kann - zum Beispiel, wenn es eine Kommunikationslücke zwischen zwei Gruppen gibt, die eng zusammenarbeiten müssten, um das Design zu erstellen.

Zweitens triffst du mit der Aufteilung von Teilsystemen zwangsläufig bereits Designentscheidungen: Jede Delegation schließt bestimmte alternative Designs aus. Und so zwingt deine Organisationsstruktur dein System dazu, auf eine bestimmte Weise auszusehen.

Um ein konkretes Beispiel aus meiner eigenen Karriere zu nennen: Wenn du ein Unternehmen hast, das drei Gruppen hat: Frontend, Backend und DBAs, dann hast du wahrscheinlich drei verschiedene Systeme: eine Webanwendung, die Geschäftslogik und die Datenbank. Leider handelt es sich dabei nicht um ein lose gekoppeltes Design, denn so ziemlich alles, was du tun willst, erfordert eine Änderung jeder Schicht: Wenn du zum Beispiel zusätzliche Informationen über einen Kunden erfassen willst, musst du sie auf der Website sammeln und an die Datenbank weiterleiten. Um die Architektur zu ändern, musst du auch die Organisationsstruktur ändern. Für ein lose gekoppeltes Design musst du zu funktionsübergreifenden Teams wechseln, die sich an den Geschäftsbereichen und nicht an den technischen Fähigkeiten orientieren; mehr dazu in Kapitel 5.

In The DevOps Handbook von Gene Kim et al. beschreiben die Autoren die Auswirkungen von eng gekoppelten Teams bei Etsy.6 Etsy hatte ursprünglich zwei Teams, die Entwickler und die DBAs, und stellte fest, dass Änderungen in der Regel von beiden Teams vorgenommen werden mussten. Sie versuchten zunächst, dieses Problem mit einem Dienst namens Sprouter zu lösen, der die Datenbankimplementierung kapseln sollte, aber Sprouter führte tatsächlich zu einer engen Kopplung zwischen den Entwicklungs- und Datenbankteams und fügte eine zusätzliche Ebene hinzu, die geändert werden musste. Etsy löste dieses Problem durch organisatorische und architektonische Änderungen, die die Geschäftslogik von der Datenbank in die Anwendung verlagerten, so dass Änderungen nur noch in der Anwendungsschicht vorgenommen werden mussten.

Es gibt noch zwei weitere Dinge, die Conway in seinem Artikel anspricht, die ich sehrinteressant finde.

Erstens wird die Forschung, die zu Techniken führt, die eine effizientere Kommunikation zwischen Teams ermöglichen, eine äußerst wichtige Rolle in der Technologie des Systemmanagements spielen. Jedes Teilsystem muss verstehen, was die anderen Teilsysteme tun, damit ein kohärentes Gesamtkonzept entstehen kann, aber Kommunikation ist kostspielig. Conway weist darauf hin, dass "die elementare Wahrscheinlichkeitstheorie besagt, dass die Anzahl der möglichen Kommunikationswege in einer Organisation ungefähr halb so groß ist wie das Quadrat der Anzahl der Personen in der Organisation. Selbst in einer mäßig kleinen Organisation wird es notwendig, die Kommunikation einzuschränken, damit die Menschen ihre Arbeit erledigen können." Diese Erkenntnis ist der Kern der jüngsten Erkenntnisse über die Optimierung des Arbeitsflusses in Organisationen, die in den nächsten Kapiteln näher erläutert werden: Die Koordination zwischen den Teams sollte auf ein Minimum reduziert werden, wenn die Menschen effektiv arbeiten sollen.

Microservices (und andere lose gekoppelte Architekturen) sind hier ein Werkzeug. Sie reduzieren den Kommunikationsaufwand, weil sie einen Großteil der Informationen über ein System - alle Teile, die andere Systeme nicht kennen müssen - hinter einer klar definierten Schnittstelle verbergen. Die Teams müssen nur über Änderungen kommunizieren, die diese Schnittstelle verändern.

Der zweite interessante Punkt ist die Frage nach der "Richtigkeit" eines Entwurfs. Conway weist darauf hin, dass "erfahrene Systemdesigner davon ausgehen, dass irgendjemand eines Tages ein besseres Design für dieselbe Aufgabe finden wird". Du wirst das Design nicht "richtig" hinbekommen, sondern nur in dem spezifischen Kontext, in dem du dich gerade befindest: die dir zur Verfügung stehende Technik und dein aktuelles Wissen über den Bereich.

Das bedeutet, dass du davon ausgehen solltest, dass du iterieren musst, wenn du ein besseres Verständnis dafür entwickelst, was dein Systemdesign leisten muss, oder wenn sich der Kontext ändert. Das Beste, was du tun kannst, ist, dich auf die Weiterentwicklung des Designs einzustellen. Nach dem Conway'schen Gesetz wird sich die Iteration sowohl auf die Organisationsstruktur als auch auf das Design auswirken.

Das umgekehrte Conway-Manöver

Du kannst die Wahrscheinlichkeit erhöhen, dass du erfolgreich ein neues System aufbaust, wenn du das Design des Systems an das Design deiner Organisation anpasst. Du kannst auch einen Schritt weiter gehen und das umgekehrte Conway-Manöver versuchen. Dabei entwickelst du das Design deiner Organisation so weiter, dass es einfacher wird, dein System so aufzubauen, wie du es möchtest.7

Wahrscheinlich musst du sogar die Organisation und die Architektur gemeinsam weiterentwickeln, vor allem, wenn du bereits ein System eingeführt hast. Es bringt nichts, die Organisation zu ändern, um damit in Konflikt zu geraten, und zu hoffen, dass alles gut geht. In "Conway's Law Doesn't Apply to Rigid Designs" (Conways Gesetz gilt nicht für starre Designs) sagt Mathias Verraes: "Eine Umstrukturierung wird ein kaputtes Design nicht reparieren." Hier kann ein schrittweiser Ansatz helfen, bei dem Teile des Systems und der Organisation herausgenommen werden und nur diese Teile iterativ verändert werden.

Genug der Theorie, kommen wir zur Sache. Beim Inverse Conway Maneuver geht es nicht um eine große Umstrukturierung, sondern darum, das Design deiner Organisation zu verändern, indem du die Art und Weise, wie du Teams zusammenstellst und leitest, sowie die Organisationskultur änderst, was im nächsten Kapitel behandelt wird. Es geht auch darum, die richtigen Grenzen zwischen den einzelnen Teilen deiner Organisation zu finden - die Grenzen, die effektiv funktionieren - und damit beschäftigen wir uns im nächsten Kapitel.

Menschen sind keine Ressourcen

Bis zu diesem Punkt habe ich eine Menge Theorie präsentiert, und vielleicht fängst du jetzt an, diese auf die Struktur deiner eigenen Organisation zu übertragen und zu überlegen, wie sich die Dinge ändern müssen. Du solltest jedoch sehr vorsichtig damit sein, alles in die Luft zu werfen, vor allem dann, wenn das bedeutet, dass bestehende Teams aufgelöst werden.

Umstrukturierungen sind stressig,8 und beeinträchtigen die Produktivität der Mitarbeiter/innen über Wochen oder Monate. Sie können auch ein Katalysator sein, der den Menschen hilft, ihre eigene Trägheit zu überwinden, wodurch die Wahrscheinlichkeit steigt, dass sie das Unternehmen verlassen.

Du wirst wahrscheinlich nicht von vornherein wissen, wie die Architektur und das Organisationsdesign im Endzustand aussehen sollen, also behalte die Teams so weit wie möglich zusammen und entwickle sie mit der Zeit weiter.9

Mögliche Begrenzungen

Wie kannst du entscheiden, wo die Grenzen zwischen den Teams verlaufen?

Auf der obersten Ebene kannst du wahrscheinlich anfangen, Grenzen zu erkennen, indem du dir die Kunden und deine Stakeholder ansiehst. Bei der Financial Times ist es sinnvoll, dass eine Gruppe von Entwicklern mit der Redaktion zusammenarbeitet, die Werkzeuge für die Erstellung, Verwaltung, Kennzeichnung und Veröffentlichung verschiedener Arten von Inhalten benötigt. Es gibt auch eine natürliche Gruppe von internen Abteilungen, die Software für ihre Bedürfnisse benötigen: HR, Finanzen und Marketing. Manchmal gibt es aber auch mehrere Interessengruppen für einen bestimmten Bereich. Bei der FT muss die Gruppe von Entwicklern, die an der ft.com-Website arbeitet, unter anderem die Bedürfnisse der Redaktion und des Marketings berücksichtigen, aber ihr Hauptaugenmerk liegt auf den Abonnenten der FT. Die "natürliche" Aufteilung auf höherer Ebene kann also auf verschiedenen Interessengruppen, verschiedenen Geschäftsfähigkeiten oder einer Mischung aus beidem basieren. Sie bilden Geschäftsbereiche.

Unterhalb dieser höchsten Ebene, d.h. wenn du versuchst, die Arbeit auf Teams und nicht auf Gruppen aufzuteilen, gibt es mehrere mögliche Bruchlinien, die du nutzen kannst(Team Topologies nennt diese "Fracture Planes"). In deinem Unternehmen gibt es zum Beispiel Grenzen zwischen verwendeten Technologien, Teamstandorten oder Compliance-Anforderungen.

Warnung

Du solltest dir sehr genau überlegen, ob du deine Organisation oder deine Systemarchitektur auf etwas anderes als die Geschäftsdomäne aufteilst - tust du es, weil es sinnvoll ist, oder weil es zu schwierig ist, ein anderes Problem zu lösen?

Für eine Microservice-Architektur ist es bei weitem am wahrscheinlichsten, dass die Grenzen durch Geschäftsdomänen festgelegt werden.

Business Domains

Nick Tune definiert die Domänen des Unternehmens als "Bereiche, in denen das Unternehmen Werkzeuge und Fähigkeiten (auch Produkte genannt) entwickelt, um Menschen zu unterstützen, die einen Zweck haben (z. B. Nutzer/innen und Kund/innen)."10

Es gibt viele Möglichkeiten, ein System aufzuteilen. Eine Domäne ist also im Grunde eine willkürliche Abgrenzung einer Teilmenge von Konzepten wie z. B. Aufträge und Positionen oder Kunden und Konten.

Du kannst Domains in der Regel in kleinere Subdomains unterteilen. Unser Ziel ist es, die Domänen weiter zu unterteilen, bis wir Domänen in Teamgröße (oder kleiner!) haben. Wenn du ein Team auf einen bestimmten Geschäftsbereich ausrichtest, hat dieses Team einen klaren und kohärenten Zweck.

Die richtige Größe ist wichtig, denn wenn das Team zu viel zu tun hat, leidet es unter kognitiver Überlastung. Wenn es zu wenig ist, kann es passieren, dass sich das Team langweilt und nicht mehr motiviert ist.

Du kannst einem Team mehrere Domänen zuweisen, aber sei vorsichtig - das funktioniert nur bei einfachen Domänen und selbst dann besteht die Gefahr, dass sich das Team in zwei Teile aufspaltet, anstatt den Overhead des Kontextwechsels zu bewältigen.

Domain-driven Design (DDD) ist ein gut etablierter Ansatz zur Identifizierung von Domänengrenzen. Er konzentriert sich auf das Softwaredesign, oft auf einer niedrigeren Ebene als der, über die wir jetzt sprechen, aber Werkzeuge wie Event Storming, eine Workshop-basierte Technik, die sich darauf konzentriert, einen Geschäftsprozess schnell als eine Reihe von Domänenereignissen zu modellieren, können sehr hilfreich sein, um Grenzen zu finden.

DDD spricht von "begrenzten Kontexten". Das sind Bereiche innerhalb des Systems, in denen die Menschen dieselbe Sprache verwenden, um über Dinge zu sprechen.11 Sobald du feststellst, dass ein und derselbeBegriff - z. B. "Lead" - für zwei Stakeholder unterschiedliche Bedeutungen hat, weißt du, dass dein Modell anders sein muss, und du hast separate Domänen identifiziert.

DDD kann für Diskussionen mit wichtigen Stakeholdern und Führungsteams zu niedrigschwellig und technisch ausgerichtet sein. Matthew Skelton hat mir kürzlich von der Independent Service Heuristik (ISH) als Alternative erzählt. Sie bietet einen Rahmen, um über Grenzen nachzudenken, indem sie die Fragen stellt: Könntest du dir das als eine Art Dienstleistung vorstellen? Könntest du das als separate Website betreiben?

Die Checkliste mit den Fragen auf dem GitHub-Repository für ISH ist eine nützliche Methode, um zu beurteilen, ob du einen Bereich gefunden hast, der "Sinn macht", um ihn abzugrenzen; das ist wahrscheinlich etwas, das du mit einem Arbeitsstrom verbinden kannst.

Sobald du einen Kandidaten für einen Bounded Context hast, lohnt es sich, ihn etwas genauer zu untersuchen. Das Bounded Context Canvas von Nick Tune bietet dafür eine Vorlage, die dich durch den Entwurfsprozess eines Bounded Contexts führt, indem sie dich dazu auffordert, die Schlüsselelemente des Designs zu berücksichtigen und auszuwählen, von der Namensgebung über die Verantwortlichkeiten bis hin zur öffentlichen Schnittstelle und den Abhängigkeiten.

Daten

Ein Aspekt der ISH-Checkliste, der mir besonders auffällt, weil er sehr schmerzhaft sein kann, wenn man ihn falsch macht, betrifft die Daten. Die Frage ist, ob es möglich ist, die Eingangsdaten (aus anderen Quellen), die ein potenziell unabhängiger Dienst benötigt, klar zu definieren:

  • Ist sie ziemlich unabhängig von anderen Datenquellen?

  • Sind die Quellen intern (unter unserer Kontrolle, nicht extern)?

  • Sind die Eingabedaten sauber (nicht unordentlich)?

  • Werden die Eingabedaten in Form eines Self-Service bereitgestellt? Kann das Team die Eingabedaten "als Service" in Anspruch nehmen?

Du möchtest wirklich, dass Daten, die sich gemeinsam ändern, am selben Ort und im Besitz desselben Teams sind, um verteilte Transaktionen zu vermeiden.

Standorte

Dabei sollte es darum gehen, die Geschäftsbereiche, die du identifizierst, den Teams auf der Grundlage ihres Standorts zuzuweisen, anstatt den Standort selbst als Bruchebene zu verwenden.

Kommunikation ist eine so zentrale Voraussetzung für effektive Teams, dass alles, was diese beeinträchtigt, den Erfolg erschwert. Martin Fowler stellt fest: "Wenn Teams in verschiedenen Stockwerken desselben Gebäudes untergebracht sind, wird die Kommunikation bereits erheblich eingeschränkt. Wenn sich die Teams in verschiedenen Städten und Zeitzonen befinden, wird ein regelmäßiges Gespräch noch mehr behindert.... Komponenten, die in verschiedenen Zeitzonen entwickelt werden, müssen eine klar definierte und begrenzte Interaktion haben, weil ihre Erfinder nicht einfach miteinander reden können." Bei Remote-First-Working sind zwar alle online, aber die Zeitzonen können trotzdem einen großen Einfluss haben, weil sie die Zusammenarbeit im Team erschweren.

Wenn du über verschiedene Zeitzonen, Länder, Städte, Büros oder sogar Stockwerke verteilt bist, solltest du sicherstellen, dass deine Domains auf dieselbe Weise aufgeteilt sind.

Technologien

Als ich das erste Mal in der IT gearbeitet habe, mit eher monolithischen Systemen, haben wir die Arbeit so aufgeteilt. Wir hatten meist eine dreistufige Architektur und entsprechend drei Teams: Frontend-, Backend- und DBA-Teams. Das Frontend sprach nicht mit der Datenbank, und das Frontend-Team sprach in der Regel auch nicht mit den DBAs.

Ein offensichtliches Problem bei dieser Aufteilung ist, dass die Geschäftsfunktionalität auf drei Schichten verteilt ist und jede Funktion in der Regel Änderungen in allen Schichten erfordert, was die Arbeit von drei verschiedenen Teams erschwert. Die Leute würden Wege finden, um zu vermeiden, dass sie die anderen Teams um eine Änderung bitten müssen, was dazu führt, dass die Geschäftslogik an den falschen Stellen sitzt. Ich bin so froh, dass wir nicht mehr so arbeiten und alle drei Bereiche in einem funktionsübergreifenden Team vertreten sind!

Das heißt aber nicht, dass es nicht manchmal gute Gründe gibt, ein System nach Technologien aufzuteilen. Das kann an unterschiedlichen Leistungsanforderungen liegen, an Systemen von Drittanbietern, mit denen du zusammenarbeitest, oder daran, dass tiefgreifendes Fachwissen erforderlich ist (hier kommt das Team Topologies Complicated Subsystem ins Spiel), das wir in Kapitel 5 näher betrachten werden.

Wir haben festgestellt, dass sich die Zuständigkeiten unseres Reliability Engineering-Teams bei der FT aufgrund der Programmiersprache aufteilen. Die Websites der FT sind fast alle in Node.js geschrieben, aber die Entscheidung, Prometheus als Basis für einen Monitoring-Stack zu nutzen, hat uns dazu gebracht, Go für einige Dienste zu verwenden, die mit Prometheus verbunden sind. Mit der Zeit wurde dies zu einer Bruchlinie innerhalb des Teams, da dieselben Leute dazu neigten, die Arbeit zu übernehmen, für die sie Go schreiben mussten. Das war zwar in der Praxis nicht besonders schmerzhaft, aber es brachte uns dazu, zu überprüfen, ob das Team nur einen einzigen Zweck verfolgte, und durch eine spätere Änderung unserer Teams und Dienste wurde die Verantwortung für die Überwachung auf andere Metrik- und Logging-Tools übertragen.

Compliance

Wie ich in Kapitel 3 erwähnt habe, kann die Einhaltung guter Grenzen zwischen Teilen des Systems, die gesetzlichen oder Compliance-Anforderungen unterliegen, und dem Rest des Systems ein zwingender Grund für den Einsatz von Microservices sein.

Indem du die Bereiche auf diese Weise trennst, kannst du den Umfang des Systems, der strengen Anforderungen unterliegt, begrenzen. Das beteiligte Team wird zu Experten und kann eng mit den Verantwortlichen für Recht und Compliance zusammenarbeiten.

Diese Art der Aufteilung ist sehr sinnvoll. In der Praxis folgt sie in der Regel den Geschäftsbereichen - zum Beispiel ist die Zahlungsfunktionalität sowohl ein anderer Bereich als auchein Bereich mit Compliance-Anforderungen rund um PCI (Payment Card Industry ComplianceRequirements).

Das kann auch mit der Wahl der Technologie zusammenhängen. Rob Donovan und Ioana Creanga haben auf der QCon London 2022 einen fantastischen Vortrag darüber gehalten, wie die Starling Bank, eine digitale Bank in Großbritannien, ihren eigenen Kartenprozessor für die Genehmigung vonKartenzahlungen entwickelt hat.

Der Teil, den ich hier hervorheben möchte, ist die Entscheidung, alle kryptografischen Validierungen in einer Zero-Trust-VPC durchzuführen, in der Microservices nur dann miteinander kommunizieren können, wenn der Zugang explizit konfiguriert wurde - zum Beispiel die Überprüfung der eingegebenen PIN und die Überprüfung, dass eine Transaktion nicht manipuliert wurde. Das bedeutet, dass das System so in Dienste aufgeteilt ist, dass das Risiko minimiert wird, wenn jemand Zugang zu einem bestimmten Dienst erhält. Sensible Informationen, wie die PIN eines Kunden, werden in Diensten gespeichert, die nur mit Daten antworten, wenn sie mit dem korrekten Zugangstoken versehen sind, und die Dienste, die Daten speichern, sind von denen getrennt, die sie zur Überprüfung verwenden.

Toleranz für Misserfolge

Es ist eine gute Idee, die Anforderungen an die Zuverlässigkeit und so weiter für die Fähigkeiten zu berücksichtigen, die du als Teil des Systems aufbaust, indem du die kritischen Dienste von den "Good-to-haves" trennst. Auf diese Weise kannst du die Anzahl der Dienste minimieren, die multiregional sein müssen, die rund um die Uhr unterstützt werden müssen usw.

Das ist gut für die Kostenkontrolle: Du willst nicht jeden Dienst in zwei Regionen betreiben, wenn einige von ihnen wirklich nur in mehreren Verfügbarkeitszonen sein müssen. Außerdem können sich die Mitarbeiter, die außerhalb der Geschäftszeiten Support leisten, auf einen kleineren Bereich konzentrieren, den sie kennen müssen.

Und schließlich kann sie eine andere Einstellung zum Risiko einer Veränderung ermöglichen. Wenn du mit Prototypen arbeitest und experimentierst, kannst du dich freier fühlen, etwas Neues zu versenden, wenn die Konsequenzen eines Fehlers nicht so hoch sind. Ich plädiere hier nicht dafür, weniger zu versenden, sondern eher dafür, Änderungen in bestimmten Bereichen gelassener zu sehen.

Als ich dort arbeitete, gab es zum Beispiel bei der FT keine Code-Sperren, aber wir erinnerten die Mitarbeiter an wichtige Ereignisse wie den britischen Haushalt oder die US-Wahlen und an Feiertage, wenn viele Mitarbeiter nicht im Büro waren. Die Entwickler und Teams konnten ihre eigene Risikoeinschätzung vornehmen. Das kann bei Änderungen an der Homepage der Website anders sein als bei einem internen Tool.

Häufigkeit der Änderungen

Die Idee dahinter ist, dass du die Bereiche , die sich schnell verändern, von denen trennst, die sich nicht so stark verändern.

Ich habe ein paar Bedenken, wenn es darum geht, mit diesem Blickwinkel langfristige Entscheidungen zu treffen. Was jetzt stabil ist, kann sich häufig ändern, wenn eine neue Technologie oder eine Veränderung in der Unternehmenslandschaft eine Chance eröffnet. Aber ich mache mir eher Sorgen, dass es schwieriger wird, einen Teil des Systems als "langsam" zu bezeichnen, wenn es darum geht, in die Beschleunigung des Lieferprozesses zu investieren. Im Allgemeinen sind kleine Änderungen, die oft veröffentlicht werden, eine große Verbesserung gegenüber großen Änderungen, die selten veröffentlicht werden, weil es einfacher ist, eine kleine Änderung zu verstehen, zu testen, freizugeben und, falls nötig, wieder rückgängig zu machen, und weil du in der Lage bist, Feedback zu bekommen, bevor du zu einer anderen Aufgabe übergegangen bist und den Kontext vergessen hast. Selbst bei Systemen, die sich nicht so oft ändern, ist es sinnvoll, den Prozess der Freigabe von Änderungen weniger schmerzhaft zu gestalten, wenn du es doch tun musst!

Die Dinge werden viel einfacher, wenn du in deiner gesamten Codebasis den Grundsatz entwickelst, dass der Code nie unveröffentlichbar ist, indem du eine stammbasierte Entwicklung durchführst oder sehr kurzlebige Zweige verwendest, Feature Flags einsetzt und generell davon ausgehst, dass alles, was du im Hauptcodezweig hast, jederzeit von jedem veröffentlicht werden kann. Das bedeutet auch, dass es keine zwei Teams gibt: die, die schnell vorankommen und neue Funktionen entwickeln, und die, die sich durch mühsame Prozesse quälen und Wartungsarbeiten durchführen.

Es gibt einige Bereiche, in denen die Häufigkeit von Änderungen eine nützliche Kennzahl ist. Erstens bei der Ablösung eines bestehenden Monolithen, wo es sehr sinnvoll ist, sich auf Teile des Codes zu konzentrieren, an denen sehr aktiv gearbeitet wird, und diese zuerst als Services zu extrahieren, damit du den Vorteil von unabhängig einsetzbaren Services und einem schnellen Wertefluss hast.

Und zweitens trennst du die Teile deines Systems, die einen externen Genehmigungs- und Freigabeprozess durchlaufen müssen - ich denke dabei an Apps und den Genehmigungsprozess im App Store - von denen, die du nach Belieben freigeben kannst. Du möchtest vielleicht immer noch kleine Änderungen intern vornehmen und sie testen, aber du wirst sie nicht jedes Mal über den App Store freigeben.

Empfehlungen

OK, ich habe verschiedene potenzielle Grenzen erwähnt, aber was ist mein Ratschlag, welche du priorisieren solltest?

Ich würde immer damit beginnen, Geschäftsdomänen zu nutzen, um die Grenzen für deine Microservices zu finden. Beginne damit, dein Unternehmen zu betrachten und versuche, die begrenzten Kontexte zu identifizieren: die Orte, an denen die Menschen dieselbe Sprache verwenden, um über ihre Probleme zu sprechen. Das sind die natürlichsten Bruchstellen in der Organisation.

Wenn in deiner aktuellen Organisationsstruktur die Verantwortung für einen bestimmten begrenzten Kontext auf mehrere Teams verteilt ist, musst du das unbedingt ändern. Das kann bedeuten, dass du die Teams umstellen musst - zum Beispiel auf funktionsübergreifende Teams, die für vertikale Teile des Systems zuständig sind, statt für solche, die an eine architektonische Schicht gebunden sind (z. B. Frontend, Backend, Datenbank).

Wenn du an mehreren Standorten tätig bist, versuche eine Aufteilung zu finden, die jedem Standort das Eigentum an einer oder mehreren Domänen in ihrer Gesamtheit gibt. Wie Martin Fowler in seinem Blogbeitrag über das Conway'sche Gesetz von einer Führungskraft erzählt, die gerade zum Architekten eines großen Projekts ernannt worden war, das von sechs Teams in sechs verschiedenen Städten durchgeführt werden sollte: "Ich habe meine erstearchitektonische Entscheidung getroffen", sagte er mir. "Es wird sechs große Subsysteme geben. Ich habe keine Ahnung, welche das sein werden, aber es wird sechs davon geben."

Bei den anderen möglichen Grenzen sehe ich gute Gründe, Compliance-Anforderungen oder eine unterschiedliche Fehlertoleranz zu berücksichtigen. Ich würde technologische Unterschiede in Betracht ziehen, wenn diese auf externen Zwängen beruhen, z. B. weil du Software in einer bestimmten Sprache verwendest oder integrierst - wie in unserem Beispiel mit den Prometheus-Plug-ins. Wenn es um die internen Entscheidungen geht, würde ich stattdessen die Aufteilung in Geschäftsbereiche bevorzugen. Ein Team muss vielleicht eine neue Technologie erlernen oder einen Dienst in eine Technologie umwandeln, mit der es besser vertraut ist. Die Häufigkeit der Änderungen ist nichts, was ich jemals bei der Betrachtung von Grenzen verwendet habe!

Erkennen, wann Grenzen falsch sind

Wenn du nicht bereits ein tiefes Verständnis für deinen Bereich hast, ist es wahrscheinlich, dass du die Grenzen nicht gleich beim ersten Mal richtig ziehen kannst.

Hinweis

Die Wahrscheinlichkeit, dass die Grenzen falsch gesetzt werden, ist besonders hoch, wenn die Personen, die über diese Grenzen auf höchster Ebene entscheiden, dies nicht mit Blick auf die Architektur tun, obwohl sie nach dem Conway'schen Gesetz durchaus Entscheidungen treffen, die sich in derArchitektur widerspiegeln werden!

Die erste Herausforderung besteht darin, zu erkennen, wo eine Grenze an der falschen Stelle ist.

Ein guter Anfang ist es, die Leute zu fragen! Teams, die ihren Zweck gut kennen, werden dir sagen können, was sie besitzen, was nicht zu ihrem Zweck passt, und was sie eigentlich besitzen sollten, aber nicht besitzen. Es kann sein, dass es Systeme gibt, von denen niemand glaubt, dass sie dazugehören, oder auf die mehrere Teams Anspruch erheben - aber zumindest weißt du das und kannst eine Entscheidung treffen.

Hinweis

Als eines meiner Teams bei der FT gegründet wurde, übernahmen wir die Verantwortung für einen bunten Strauß von Tools und Drittsystemen. Wir legten die Kernziele des Teams fest, erstellten eine Liste der Dinge, die nicht passten, und hängten kleine Bilder von jedem System an die Wand. Dann taten wir unser Bestes, um sie stillzulegen, auf SaaS-Optionen umzustellen oder sie (mit deren Einverständnis) an andere Teams zu übertragen. Jeder Erfolg wurde mit einer Zeremonie markiert, bei der jemand ein großes Kreuz durch das Bild machte. Das war ein gutes Gefühl!

Achte auf Teams, in denen viel kommuniziert wird, sei es über einen gemeinsamen Slack-Kanal oder ein wöchentliches Treffen zu Abhängigkeiten. Wenn sie ständig kommunizieren müssen, um Dinge zu erledigen, ist das ein Zeichen dafür, dass die Grenzen am falschen Ort liegen.

Achte auch auf Anzeichen von Schmerzen oder Reibung. Sie deuten wahrscheinlich darauf hin, dass mehr gekoppelt wird, als du erwartet hast. Gibt es Dienste, die du immer zur gleichen Zeit änderst? Wahrscheinlich sollten es keine separaten Dienste sein, und sie sollten definitiv nicht von verschiedenen Teams betrieben werden.

Viele eingehende Pull-Requests oder Feature-Requests von einem Team, das deinen Service nutzt, sind ein ähnliches Problem: Wenn ihre Änderungen häufig Änderungen an deiner internen Implementierung erfordern, sind sie zu stark gekoppelt.

Gibt es Dienste, bei denen Releases häufig zu Produktionsproblemen führen? Das könnte an einer schlecht gestalteten Schnittstelle liegen, bei der die interne Implementierung nach außen dringt (was bedeutet, dass es für das Team nicht sicher ist, sie zu ändern), aber es könnte auch ein Zeichen dafür sein, dass du versehentlich eine Domäne geteilt hast.

Ist es schwierig, sich auf das Modell für bestimmte Konzepte zu einigen, weil nicht klar ist, was sie darstellen? Das könnte darauf hindeuten, dass zwei verschiedene Bereiche miteinander kombiniert werden.

Und haben mehrere Teams einfach losgelegt und Versionen von genau demselben Ding erstellt? Hier geht es nicht um doppelten Code - in einer Microservice-Architektur ist es oft eine gute Entscheidung, bestimmte Funktionen mehr als einmal zu erstellen. Das Beispiel, das Sam Newman in seinem Buch Monolith to Microservices anführt, ist die PDF-Erstellung: Wenn ein zweites Team eine PDF-Datei erstellen muss, kannst du einen Dienst extrahieren oder du kannst akzeptieren, dass du durch eine gewisse Duplizierung schneller vorankommst. Ich spreche jedoch davon, wenn zwei Teams glauben, dass sie für die Erstellung einer bestimmten Funktion, wie z. B. einer Empfehlungsmaschine, verantwortlich sind. Das deutet auf eine schlecht verstandene Abgrenzung hin.

Wichtig ist, dass du dir darüber im Klaren bist, dass selbst wenn du wie durch ein Wunder die Grenzen richtig gezogen hast, sie nicht richtig bleiben werden!

Die Dinge werden sich mit der Zeit ändern. Vielleicht musst du einen Bereich aufteilen, weil er für das bestehende Team zu groß geworden ist. Es kann sein, dass sich die verfügbare Technologie ändert: Zum Beispiel hat jemand eine Standardversion von etwas entwickelt, das dein Unternehmen früher selbst bauen musste. Denke an die Auswirkungen der Cloud auf die Art und Weise, wie Systeme gebaut werden.

Außerdem kann sich die Gesetzeslage ändern oder das Unternehmen muss seine Strategie ändern, um die neuen Möglichkeiten optimal zu nutzen.

Was ich damit sagen will, ist, dass das nicht etwas ist, das einmal gemacht wird und dann nie wieder überprüft werden muss. Es ist normal, dass man Dinge umstellen muss.

In der Zusammenfassung

Um mit einem bestimmten Architekturstil erfolgreich zu sein, musst du sicherstellen, dass du die richtige Art von Organisation hast. Denn das Conway'sche Gesetz besagt, dass die Architektur der Organisation gewinnt, wenn die Architektur des Systems und die Architektur der Organisation im Widerspruch zueinander stehen.12

Es ist wichtig, die Grenzen zwischen den verschiedenen Teilen deines Betriebs zu finden, aber du wirst es wahrscheinlich nicht beim ersten Mal richtig machen, und du solltest damit rechnen, dass du Änderungen vornehmen musst, wenn sich das Umfeld ändert - zum Beispiel, wenn neue Technologien oder neue Geschäftsbereiche auftauchen.

Diese Grenzen basieren wahrscheinlich auf Geschäftsbereichen, können aber auch auf unterschiedlichen Standorten, Technologien, Compliance-Anforderungen, Fehlertoleranz oder Veränderungsgeschwindigkeiten beruhen.

In diesem Kapitel habe ich darüber gesprochen, wie man die richtigen Grenzen zwischen Teams findet. Im nächsten Kapitel möchte ich darüber sprechen, wie diese Teams aussehen müssen, um effektiv zu sein, und wie die Kultur aussehen muss, die sie umgibt.

1 Wie in Team Topologies zitiert, für einen Blogbeitrag, der nicht mehr online ist, aber über das Webarchiv verfügbar ist.

2 Melvin E. Conway, "How Do Committees Invent?", veröffentlicht in der Zeitschrift Datamation im April 1968.

3 Conways ursprüngliches Papier ist weiter gefasst und spricht über jede Art von Design und die Organisation, die es herstellt.

4 Da Untergruppen mehr als ein System entwerfen können, geht die Zuordnung nur in eine Richtung: Du kannst nicht immer von einer Untergruppe zu einem einzelnen Teilsystem wechseln.

5 Alan MacCormack, Carliss Baldwin und John Rusnak, "Exploring the Duality Between Product and Organizational Architectures: A Test of the Mirroring Hypothesis".

6 Gene Kim et al., The DevOps Handbook (Portland: IT Revolution Press, 2016).

7 Jonny Leroy und Matt Simons von Thoughtworks erwähnten dies erstmals in der Dezember-Ausgabe 2010 des Cutter IT Journals, und 2014 wurde es im Thoughtworks Tech Radar vorgestellt.

8 Wie in einer Reihe von Blogbeiträgen von Cyrille Dupuydauby erwähnt.

9 Wie Heidi Helfand in ihrem Buch " Dynamic Reteaming" feststellt, verändern sich Teams im Laufe der Zeit ohnehin und es lohnt sich, gut mit diesen Veränderungen umzugehen.

10 Nick Tune, "Was ist eine Domain?".

11 Ehrlich gesagt kann ich niemanden finden, der eine wirklich prägnante Beschreibung eines begrenzten Kontexts geschrieben hat, also ist dies mein Versuch. Ich fand, dass Martins relativ kurzer Blogbeitrag mir geholfen hat, dieses nützliche Konzept zu verstehen.

12 Dies sind die Worte von Ruth Malan aus einem archivierten Blogbeitrag.

Get Erfolgreiche Microservices ermöglichen now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.

Start your free trial