Der nachfolgende Text wurden mit KI erstellt und kann Fehler enthalten. Fehler gefunden? Bei GitHub editieren
Die Website zu Self-contained Systems (SCS) ist über zehn Jahre alt. Der Artikel von Phillip Ghadir und Stefan Tilkov, auf den sie zurückgeht, ist sogar 15 Jahre alt. Eberhard Wolff, der den ersten Commit auf der Website gemacht hat, fragt in dieser Runde, was von dem Ansatz geblieben ist. Silvia Schreier arbeitet seit knapp zehn Jahren im Groß- und Einzelhandel mit SCS-Ideen. Johannes Seitz zerlegt als Berater bei INNOQ gewachsene Systeme, vor allem in der Finanzbranche und im E-Commerce. Simon Martinelli modernisiert als selbstständiger Berater Software, unter anderem bei einem Schweizer Großhändler.
Mehr als Microservices mit Oberfläche
Eberhards Ausgangsdefinition lautet: Self-contained Systems sind Microservices mit eigener Web-Oberfläche. Johannes sieht es anders, geprägt durch Stefan Tilkov, der Monolithen in einem Vortrag „total super“ fand und vorschlug, viele davon zu bauen. Ein SCS ist für ihn ein „begrenzter Monolith“, der alles von der UI bis zur Datenhaltung enthält, aber nicht grenzenlos gewachsen ist. Simon spricht lieber von Teilapplikationen; das verstehen auch Leute außerhalb der IT. Für Silvia ist die Oberfläche nicht das Wesentliche, sondern die Unabhängigkeit im Betrieb: „selbst wenn alle anderen Systeme weg sind, kann das eine Self-contained System immer noch seinen Job zu einem großen Teil erfüllen.“ In einer vertikalisierten Microservice-Landschaft, die nicht nach SCS-Regeln gebaut war, hat sie Dominoeffekte erlebt; bei SCS dagegen gelte: „wenn da einer umfällt, fallen die anderen in der Regel nicht auch mit um.“ Johannes ergänzt, dass SCS anders als Microservices eine klare Integrationspräferenz vorgibt.
Verfügbarkeit oder fachlicher Schnitt?
Eberhard widerspricht dem Konsens: Verfügbarkeit liefere oft schon Kubernetes, ihm sei der fachliche Schnitt wichtiger. Wer fachlich nicht vernünftig aufteile, habe Abhängigkeiten, egal wie er technisch baue; für ihn sei die Diskussion deshalb von Microservices zu Domain-driven Design gewandert. Johannes sieht beides Hand in Hand: Wer unabhängig betreibbar ist, kann auch lokal testen, ohne andere Systeme hochzufahren. Simon nennt Testcontainers mit generierten Testdaten als Voraussetzung dafür. Silvia hält an der Verfügbarkeit fest, weil auch in Kubernetes-Clustern Releases schiefgehen. Ein schlechterer fachlicher Schnitt lasse sich manchmal in Kauf nehmen, etwa wenn Teams unterschiedlich ausgelastet sind.
Die Nicht-Vernetzung zählt
Ralf D. Müller fand in einem Kommentar die Vernetzung der Systeme spannend. Eberhard dreht das um: „das Spannende ist die Nicht-Vernetzung der Systeme, nicht die Vernetzung der Systeme.“ Johannes stimmt zu: Die erste Empfehlung lautet, Integration zu vermeiden. Muss integriert werden, dann so lose wie möglich, im einfachsten Fall per Link, sonst durch eingebettete UI-Elemente. Asynchrone Kommunikation ist für Eberhard so selbstverständlich, dass er Netflix und Service Meshes mit ihrem Fokus auf synchrone Aufrufe nicht versteht. Synchron rufe er nur auf, wo es nicht anders geht, etwa bei einem kundenspezifischen Preisberechner.
Kaum geteilte Infrastruktur
Dass die Regel „kaum geteilte“ statt „keine geteilte Infrastruktur“ heißt, geht nach Eberhards Erinnerung womöglich auf ihn zurück: Ob ein Datenbank-Server dasteht oder mehrere, „ist aus meiner Sicht nahezu egal.“ Johannes erklärt, woher der Schmerz kommt: In Versicherungen und Banken laufe „bestimmt 80 Prozent der Integration zwischen Systemen über gemeinsam genutzte Datenbanken“, weil der Connection String schon da ist. Simon teilt Datenbankinstanzen, trennt aber über Schemas und Berechtigungen und prüft, dass kein Schema unerlaubt auf ein anderes zugreift. Daten repliziert sein Team bewusst, denormalisiert und gefiltert. Silvia würde ideal alles trennen, scheitert aber oft an den Kosten; ein geteiltes Kubernetes-Cluster bedeute zudem Upgrades, die sich über Wochen und Monate ziehen. Johannes sieht Self-Service-Plattformen als Teil der Antwort: Geteilte Infrastruktur sei „heute nicht mehr das gleiche Biest, was sie vor zehn Jahren vielleicht mal war.“
Information Hiding auch bei Datenbanken
Ist Datenbankintegration eine Erfolgsgeschichte? Johannes verneint: Viele hätten verstanden, dass es eine schlechte Idee ist, ihnen fehle aber die Erfahrung mit Alternativen. Wer jedes Detail preisgibt, muss bei jeder Modelländerung die ganze Firma abklappern. Eberhard verweist auf Information Hiding: Warum man nicht direkt auf Instanzvariablen zugreift, erklärt er in Trainings am Bankkonto, dessen Stand gespeichert oder aus Überweisungen berechnet sein kann. Bei Klassen sei das ein Tabu, bei Datenbanken fehle dieser Schluss. Johannes führt das auf die datenbankzentrische Tradition der Großrechner zurück, Simon auf durchgängige Hibernate-Mappings, die allen Modulen dieselbe Sicht auf die Daten aufzwingen. Modularität heißt für Johannes vor allem: Was geht über die Schnittstelle zwischen zwei Boxen, und wie viel sehen sie voneinander?
Das Team, an dem jedes Projekt hängt
Silvia hat in fast jedem Unternehmen ein Bottleneck-SCS erlebt, gern den Checkout im E-Commerce, an dem jede Initiative hängt. Wo eine neue Fähigkeit hingehört, entscheidet sich dann nicht nur fachlich, sondern auch danach, wie ausgelastet ein Team ist, in welchem Produktlebenszyklus es steckt und welche Skills es hat. Ein Team größer zu machen helfe selten. Simon organisiert die Teams nach Hauptdomänen wie Einkauf, Verkauf, Logistik und Finanzen; der Engpass sei meist das fachliche Know-how, das ein anderes Team auch nicht hätte. Aus dem Chat empfiehlt mklinke82 das Buch „Balancing Coupling in Software Design“ von Vlad Khononov; Johannes schließt sich an.
Gemeinsame Navigation
Ralf D. Müller wendet auf LinkedIn ein, Nutzer sollten keine x Systeme sehen, sondern eine gemeinsame Navigation. Simon hält das bei seinem Kunden für kaum ein Thema: Ein Designsystem und unveränderbare Links reichen, und Amazon habe früher für Suche, Checkout und Payment völlig unterschiedliche Oberflächen gehabt. Eberhard fragt, warum ein Checkout als Wizard aussehen soll wie die Produktsuche. Silvia betont dagegen den Nutzerwert guter Integration: Preise und Artikelnummern sollten konsistent aussehen, ein Link vom Nachbestellen ins BI-Tool spart Wege, und konzernweit habe man eine gemeinsame Navigationsleiste über mehrere CMS- und Shop-Systeme gebaut, die der Endkunde nicht bemerkt habe.
Kein Qualitätssiegel
Eine anonyme Frage lautet, ob ein reines Datenaustauschsystem wie andere Module zu behandeln ist. Eberhard verneint: Ohne Geschäftslogik genügt etwa ein Transaction Script, und ohne Oberfläche ist es kein SCS. Johannes verortet den Sweet Spot von SCS wie den von Domain-driven Design: hohe fachliche Komplexität und mehrere Teams. Bei einem Kunden mit Telefonanlagen-Software war die Komplexität technisch, dort passten Vertikalen nicht. Silvia rät, einzelne Regeln wie asynchrone Datenreplikation trotzdem zu übernehmen. Eberhard warnt davor, SCS als Qualitätssiegel zu sehen: „es geht nicht darum, dass wir Self-contained Systems bauen, sondern wir wollen halt eine Architektur bauen“. Johannes sieht Ideen auch für Mobile-Apps.
Duplikation und Autonomie
baumrinde-k8y berichtet aus einer großen SCS-Umsetzung von gigantischer Code-Duplikation und inkompatiblen Technologien bei über 20 Teams. Silvia bestätigt das Risiko; InnerSource helfe ein Stück, mit KI seien Änderungen an dupliziertem Code heute leichter. Simon sieht bei seinem Kunden praktisch keine Duplikation: Designsystem, geteilte Bibliotheken für Single Sign-on und Observability, ein Archetype für neue Systeme und ein Architektur-Board mit ADRs. Silvia nennt das eine bewusste Beschneidung der Freiheit in der Mikroarchitektur, die sie für richtig hält. Eberhard sieht einen Trade-off: Ein vorgeschriebenes Framework schafft Konsistenz, kann aber schaden, wenn es technisch schlecht ist.
Monolith als Alternative?
Der Kommentator sieht im Backend keinen Vorteil von SCS gegenüber Microservices und würde lange auf Monolithen setzen. Für Simons Kunden ist ein Monolith zu groß und zu unflexibel, Microfrontends brächten wieder Deployment-Abhängigkeiten. Ein Team setzt den ganzen vertikalen Schnitt um, und das passe zu KI, die ohnehin Full-Stack entwickle. Bei einer Schweizer Versicherung mit Microservices und Microfrontends kämpfe er gerade damit, welche Teile zu einem Use Case gehören. Johannes empfiehlt den klassischen Monolithen nur Start-ups, und auch dann mit Sollbruchstellen. Eberhard stört schon der Begriff modularer Monolith: Wer Monolithen nicht modularisieren wolle, dem fehle Softwarearchitektur.
Fazit
Reden wir in zehn Jahren noch über Self-contained Systems? Alle vier sagen Ja. Simon hält SCS für den optimalen Schnitt für KI, weil der Kontext für Mensch und Maschine begrenzt ist, und für schneller zu modernisieren als Monolithen, bei denen das drei bis fünf Jahre dauern kann. Für Johannes adressiert SCS Probleme, „die genauso alt sind wie Software-Systeme selbst“, und ist eine Sammlung bewährter Good Practices. Silvia erwartet, dass KI das Web verändert, aber fachlich sinnvolle, resiliente Systeme mit kleinem Blast-Radius bleiben. Eberhard fasst zusammen: Modularisierung ist auch für KI ein wichtiges Thema.