Publiziert: Zuletzt aktualisiert:

Systemarchitektur

Grenzen entscheiden mehr als das Framework

Architektur ist keine einmalige Wahl, sondern eine Folge von Trade-off-Entscheidungen entlang konkurrierender Qualitätsattribute. Der pragmatische Pfad führt vom strikt modularisierten Modulithen schrittweise zu Services, nur dort, wo die Kräfte es erzwingen. Die Modularisierung schlägt die initiale Framework-Wahl.

Eine fehlerhafte Weichenstellung in frühen Phasen erzeugt technische Schulden, deren Kosten in späteren Wachstumsphasen überproportional steigen. Der Hebel dagegen ist nicht das „richtige" Framework, sondern saubere Grenzen, dokumentierte Entscheidungen (Architecture Decision Records, also ADRs) und die Freiheit, einzelne Bausteine später auszutauschen. Wie diese Disziplin als laufender Betrieb aussieht, zeigt unsere Kompetenz Platform Engineering und Internal Developer Platform.

Die Kräfte: konkurrierende Qualitätsattribute treiben die Architektur

Architektur ist die Optimierung gegen konkurrierende Qualitätsattribute. Kein Attribut ist gratis, jede Stärkung des einen schwächt ein anderes. Diese Kräfte, nicht die Mode, treiben jede gute Entscheidung:

  • Skalierbarkeit: Müssen Teile des Systems unabhängig voneinander Last tragen? Eine selten genutzte Reporting-Funktion skaliert anders als ein Bestellabschluss unter Lastspitze.
  • Wartbarkeit: Wie schnell versteht ein neues Teammitglied einen Bereich und ändert ihn sicher? Das hängt direkt an der Grenzschärfe der Module.
  • Markteinführungszeit (Time-to-Market): Wie schnell liefert ein Team eine Funktion aus, ohne andere zu blockieren?
  • Team-Topologie: Wie viele Teams arbeiten am System, und wie autonom müssen sie sein? Das beantwortet Conway's Law.
  • Betriebsreife: Verträgt die Organisation verteilte Systeme? Observability, Deployment-Automatisierung und Bereitschaftsdienst sind die Voraussetzung, nicht die Folge.
  • Datenkonsistenz: Braucht der Fall starke Konsistenz (eine Transaktion) oder genügt eventual consistency, also letztliche Konsistenz? Diese Frage entscheidet über Service-Schnitte mehr als jede andere.
  • Souveränität: Bleiben die Bausteine austauschbar und selbst-hostbar? Dazu die Austauschbarkeit als Qualitätsattribut weiter unten.

Wer diese Kräfte nicht benennt, entscheidet trotzdem, nur unbewusst. Die folgenden Abschnitte machen das Abwägen sichtbar.

Die Bausteine und ihre Grenzen

Eine Architektur besteht aus Bausteinen (Module, Services) und den Grenzen dazwischen. Die zentrale Einsicht: Grenzen entstehen fachlich, nicht technisch. Ein Schnitt entlang von Domänengrenzen (Bounded Contexts aus dem Domain-Driven Design) bleibt stabil; ein Schnitt entlang technischer Schichten (Frontend, Backend, Datenbank) erzeugt nur verteilte Kopplung.

Die API ist der Vertrag: Kommunizieren Bausteine ausschliesslich über definierte Schnittstellen, bleibt das Innere austauschbar. Diese Vertrags-Disziplin steht im Zentrum von API-First. Ob ein Baustein als Modul im selben Prozess oder als eigener Service läuft, ist eine Frage der Auslieferung, nicht des Schnitts. Die fachliche Grenze ist davon unabhängig.

Das folgende Diagramm zeigt den pragmatischen Standardfall als ein einziges Bild: ein Modulith mit strikten internen Grenzen, von dem ein Kontext bereits als Service ausgelagert ist. Monolith, Modulith und Services sind hier kein Entweder-Oder, sondern ein Kontinuum.

architecture-beta
    group edge(cloud)["Zugriff"]
    group core(server)["Modulith"]
    group legacy(server)["Ablösung"]
    service client(cloud)["Client"] in edge
    service gateway(server)["API Gateway"] in edge
    service katalog(server)["Modul Katalog"] in core
    service kunden(server)["Modul Kunden"] in core
    service bestellung(server)["Modul Bestellung"] in core
    service rechnung(server)["Service Rechnung"] in legacy
    service erp(database)["Legacy ERP"] in legacy
    client:R -- L:gateway
    gateway:R -- L:katalog
    katalog:R -- L:kunden
    kunden:R -- L:bestellung
    gateway:B -- T:rechnung
    rechnung:R -- L:erp

Das Diagramm liest sich so: Der Modulith bleibt der Standard; ein erzwungener Schnitt (die Rechnung) ist als eigener Service ausgelagert und löst über den Strangler-Fig-Mechanismus schrittweise das Legacy-ERP ab. Das API-Gateway ist die einzige Kommunikations-Grenze nach aussen. Es ist kein Alles-auf-einmal-Microservices-Bild, sondern ein gezielter Schnitt entlang der Kräfte.

Das Spektrum: vom Monolithen über den Modulithen zu Services

„Monolith oder Microservices?" ist die falsche Frage. Es gibt ein Spektrum, und jede Stufe optimiert andere Attribute. Die Wahl ist ein Trade-off, kein Glaubensbekenntnis:

  • Entwicklungs-Geschwindigkeit (klein)
    • Monolith: hoch
    • Modulith (Default): hoch
    • Microservices: niedrig (Verwaltungsaufwand)
  • Betriebskomplexität
    • Monolith: niedrig
    • Modulith (Default): niedrig
    • Microservices: hoch (verteilt)
  • Skalierungs-Granularität
    • Monolith: grob (alles)
    • Modulith (Default): grob (alles)
    • Microservices: fein (pro Service)
  • Team-Autonomie
    • Monolith: gering
    • Modulith (Default): mittel
    • Microservices: hoch
  • Latenz / Konsistenz
    • Monolith: einfach (lokal)
    • Modulith (Default): einfach (lokal)
    • Microservices: schwierig (Netz, eventual)
  • Voraussetzung Betriebsreife
    • Monolith: gering
    • Modulith (Default): gering
    • Microservices: hoch

Der Modulith, ein Monolith mit strikt durchgesetzten internen Modulgrenzen, ist für die meisten Schweizer KMU der pragmatische Standard: einfacher Betrieb wie ein Monolith, aber mit sauberen Schnitten, die eine spätere Auslagerung erlauben. Die gefährliche Zwischenstufe ist der verteilte Monolith: Services dem Namen nach, aber so eng gekoppelt, dass sie nur gemeinsam ausrollbar sind. Das ergibt die Betriebskomplexität von Microservices ohne deren Autonomie-Gewinn. (Vergleiche Microservices für das Spektrum-Ende und die MACH-Architektur für einen konkreten Punkt darauf.)

Fehlermodi

Architektur scheitert selten am fehlenden Wissen, sondern an vorhersehbaren Mustern:

  • Big Ball of Mud: der unstrukturierte Monolith, in dem jede Änderung unvorhersehbare Seiteneffekte auslöst. Das Team verbringt mehr Zeit mit Fehlerbehebung als mit neuen Funktionen.
  • Verteilter Monolith: Microservices ohne echte Entkopplung, nur gemeinsam ausrollbar, geteilte Datenbank, synchrone Aufrufketten. Schlechter als ein Monolith, weil verteilt.
  • Vorzeitige Zerlegung: Services schneiden, bevor die Domänengrenzen verstanden sind. Falsche Schnitte sind im verteilten System viel teurer zu korrigieren als im Modulithen.
  • Geteilte Datenbank als versteckte Kopplung: zwei Services, eine Datenbank. Die Schnittstelle ist heimlich das Schema, nicht die API. Jede Migration koppelt beide Teams. (Siehe Data-Architecture.)
  • Fehlende Betriebsreife: Microservices ohne Observability und Platform Engineering verlagern Komplexität in den Betrieb, wo sie niemand sieht, bis es brennt.

Vier dieser fünf Fehlermodi sind Folge eines zu frühen oder zu schlechten Service-Schnitts, was direkt zum Evolutionspfad führt.

Der Evolutionspfad

Architektur entwickelt sich. Der belastbare Pfad beginnt einfach und schneidet nur unter nachgewiesenem Druck, also do the forces force a cut? Das Tor im Diagramm ist die zentrale Disziplin: Ohne erzwingende Kraft bleibt der Modulith.

graph TB
    A["Monolith"] --> B["Modulith:<br/>strikte Grenzen"]
    B --> G{"Kräfte erzwingen<br/>einen Schnitt?"}
    G -->|"nein"| B
    G -->|"ja"| C["Strangler-Fig-<br/>Auslagerung"]
    C --> D["API-First-<br/>Entkopplung"]
    D --> E["ADRs als<br/>Gedächtnis"]
    E --> G

Das Diagramm liest sich so: Vom Monolithen zum Modulithen mit sauberen Grenzen, dann ein Entscheidungs-Tor. Erst wenn eine konkrete Kraft (unterschiedliche Skalierung, Team-Autonomie, Technologie-Zwang) den Schnitt erzwingt, wird ein einzelner Kontext per Strangler Fig ausgelagert, per API-First entkoppelt und die Entscheidung als ADR festgehalten. Die Schleife zurück zum Tor macht klar: Jeder weitere Schnitt durchläuft dieselbe Prüfung. Saubere Modulgrenzen entstehen dabei laufend durch Refactoring, und das Diagramm-Vokabular (Context, Container, Component) liefert das C4-Modell. Ob ein Schnitt wirklich reif ist, prüft neutral unsere Leistung Service-Delivery-Assessment.

Wer so vorgeht, muss eine Architektur nicht „in 5 Jahren neu bauen". Sie bleibt austauschbar, weil die Grenzen sauber und die Entscheidungen dokumentiert sind. Modularisierung ist wichtiger als die initiale Framework-Wahl.

Architektur und Team: Conway's Law

Conway's Law besagt: Organisationen produzieren Systeme, die ihre Kommunikationsstruktur abbilden. Drei Teams, die kaum miteinander reden, erzeugen drei kaum integrierte Subsysteme, unabhängig vom Architektur-Diagramm an der Wand. Der Umkehrschluss, das Inverse Conway Maneuver, macht daraus ein Werkzeug: Zuerst die Ziel-Architektur definieren, dann die Teams danach schneiden. Wer Bestellabschluss und Katalog als getrennte Services will, braucht getrennte, autonome Teams. Das Framework Team Topologies (Skelton/Pais) formalisiert das in vier Team-Typen (Stream-aligned, Platform, Enabling, Complicated Subsystem). Vertiefung im Thema Conway's Law.

Austauschbarkeit als Architektur-Qualitätsattribut

Eine Architektur aus austauschbaren, selbst-hostbaren Bausteinen mit offenen Schnittstellen hält die Kontrolle über Daten und Betrieb im Haus und das System anpassbar. Diese Souveränität ist kein Compliance-Häkchen, sondern ein Architektur-Qualitätsattribut, und sie wird zur Entwurfszeit gewonnen oder verloren. Genau hier zahlt die API-als-Vertrag-Disziplin doppelt: Wer seine Bausteine hinter klaren Schnittstellen kapselt, kann einen proprietären Dienst gegen eine offene Alternative tauschen, ohne das System umzubauen. Die Vermeidung von Vendor-Lock-in ist damit eine Architektur-Entscheidung, kein nachträglicher Einkaufs-Trick, und der Kern der digitalen Souveränität, die le dot für Schweizer Unternehmen als Positionierung vertritt. Der Geschäfts-Kontext für den Strangler-Fig-Pfad ist meist die Legacy-Modernisierung.

Verwandte Themen

Referenzen