# Self-Contained Systems Strategy for Resilient Enterprise Architecture

**Podcast:** Software Architektur im Stream
**Published:** 2026-11-03

## Transcript

Hallo, mein Name ist Alaa Heuschenbach.
Organisiert ihr User Groups, Konferenzen oder andere Tech-Veranstaltungen?
Dann trage sie gerne auf treff.tech ein.
Eine nicht kommerzielle Plattform für Tech-Veranstaltungen im deutschsprachigen Raum.
Kostenlos, ohne Werbung und ohne Tracking.
Schaut einfach vorbei unter treff.tech.
oder scannt einfach den QR-Code.
Den Link findet ihr außerdem in der Videobeschreibung.
Und übrigens, ihr findet alle Termine von Softwarearchitektur im Stream natürlich auch auf Treff.tech.
Bei Fragen meldet euch gerne bei mir.
So, dann herzlich willkommen zu einer weiteren Episode von Softwarearchitektur im Stream.
Dieses Mal geht es um die Self-Contained Systems Runde und ich habe mir dazu drei weitere Personen eingeladen und freue mich, dass die auch alle gekommen sind.
Wir wollen loslegen mit einer Vorstellungsrunde und die Vorstellungsfrage ist, wer bist du und welche Rolle spielen Safe Content Systems für dich?
Silvia, möchtest du als erste Person was dazu sagen?
Gerne.
Ja, ich bin Silvia, Informatikerin aus Leidenschaft, würde ich sagen, und ein bisschen sehr Zusammenhang.
Ich war früher bei InnoQ, aber inzwischen bin ich seit knapp zehn Jahren im Groß- und Einzelhandels unterwegs.
Was hat das mit SCS zu tun?
Klar, bei InnoQ bin ich mit dem Thema schon in Kontakt bekommen und jetzt in meiner ganzen Handelszeit war ich eigentlich immer in vertikalisierten Systemlandschaften, zumindest teilweise unterwegs und manchmal mit SCS gebaut, manchmal nicht und habe da so ein bisschen was zu erzählen, wie sich das dann aus verschiedensten Rollen dann auch heraus anfühlt.
Genau, und dazu wäre vielleicht noch zu ergänzen, dass eben der Otto-Versand, dass man auf der Webseite eben eins von den großen Beispielen ist für Self-Content Systems.
Also das eben auch in Nutzung, aber wird eben auch sein.
Genau, Johannes, möchtest du dich auch kurz vorstellen?
Gerne, ich bin der Johannes, ich arbeite als Software-Architekt und Berater bei InnoQ und häufig helfe ich Unternehmen, gerade aus der Finanzbranche, aber auch E-Commerce dabei, wenn sie große, gewachsene, sehr komplexe Systeme haben, die so zu zerlegen, dass Teams unabhängig daran arbeiten können.
Und da spielt Self-Contained Systems natürlich eine ganz große Rolle.
Außerdem gebe ich Architekturtrainings, unter anderem nach dem ISAQB oder schreibe über Self-Contained Systems.
Simon, möchtest du auch noch was zu dir sagen?
Gerne.
Ich bin selbstständiger Berater und bin seit ungefähr zehn Jahren vor allem mit Software-Modernisierungsprojekten betraut.
Und auch im Grosshandel in der Schweiz, also auch E-Commerce-Systeme.
Und dort passt die Vertikalisierung, wie Silvia bereits erwähnt hat, sehr gut.
Und weil es so gut funktioniert, habe ich auch Artikel geschrieben und spreche an Konferenzen über dieses Thema.
Und es passt super zu KI-getriebener Softwareentwicklung im Übrigen.
Und dann, also ich bin Ibarhard.
Meine Beziehung zu Self-Content Systems ist, dass ich tatsächlich vor über zehn Jahren den ersten Commit auf der Self-Content Systems Webseite gemacht habe und den so ein bisschen aus der Taufe gehoben habe.
Ich habe ja außerdem verschiedene Bücher geschrieben über das Thema Microservices und bin damit halt irgendwie lange durch die Gegend gelaufen.
Da sind halt Self-Content Systems, fand ich, ein sehr guter Ansatz, um das halt vernünftig auf die Reihe zu bekommen.
Vielleicht sogar vielversprechender als Microservices selber.
Und das ist so ein bisschen mein Hintergrund.
sozusagen es historisch zu klären.
Ich weiß nicht, ob wir da noch zukommen.
Also ich habe zwar diesen Commit gemacht auf diese Webseite, aber ursprünglich geht das Ganze eben zurück auf diesen Artikel von Philipp Gradier und Stefan Tilkoff, dem mittlerweile verstorbenen Stefan Tilkoff, wo es halt um das Thema Self-Contained Systems letztendlich ging.
Das ist also so ein bisschen der historische Ursprung.
Und der ist 15 Jahre alt und ist auf der Self-Contained Systems Webseite verlinkt.
Wir werden auch irgendwie nachher, also wir haben jetzt schon eine große Menge an Links.
Da wird es also sicherlich in den Show Notes noch irgendwie Informationen geben.
Gut.
Fragt sich also ein bisschen, worüber wir eigentlich reden.
Self-Content Systems.
Und die Frage ist, was das eigentlich ist.
Für mich ist so ein bisschen die Definition, die mir am nächsten liegt, die Definition, das sind eben Microservices mit einer eigenen Web-Oberfläche.
Passt das für euch oder habt ihr eine andere Definition?
Ist das etwas, was für euch das vernünftig ausdrückt oder wie seht ihr das?
Ich habe tatsächlich auch durch Stefan Tilkoff geprägt, das Ganze ein bisschen anders sehen gelernt.
Der hat nämlich irgendwann mal gesagt, in einem Konferenzvortrag Monolithen findet er total super, lass uns viele davon bauen.
Und aus der Richtung kommend ist für mich ein Self-Contained-System inzwischen.
eher an einem sehr kleinen, überschaubaren Monolithen, der sehr, sehr viele Vorteile hat im Sinne von, ich habe alles, was ich brauche, um Feature umzusetzen, von der UI bis zur eigenen Datenhaltung quasi in diesem System drin und muss mich nicht mit anderen abstimmen, ob ich da jetzt irgendwas ändern kann.
Und deswegen sage ich, es ist eigentlich eher so eine Art...
begrenzter Monolith, der halt nicht grenzenlos gewachsen ist und deswegen all die negativen Eigenschaften bekommen hat, die wir mit Monolithen inzwischen verbinden würden.
Ja, ich spreche gerne von Teilapplikationen, also dass ich eigentlich eine grosse Applikation in Teile aufteile.
Ich glaube, das ist ein Begriff, der ist uralt.
Ich bin zumindest schon sehr lange in der Softwareentwicklung tätig.
Und das erklärt es auch für Nicht-Leute aus 3T sehr gut.
Die wissen, okay, wir haben und das System aufgeteilt in verschiedene Teile und die arbeiten unabhängig und ich arbeite jetzt mit einem oder mehreren Teilen und ich merke gar nicht eigentlich, mit welchem Teil ich arbeite als Benutzer.
Und deshalb denke ich, ist der Begriff vielleicht auch nicht so schlecht.
Und ich würde sagen, das Thema Web-Oberfläche, ja, ich glaube, im Großteil der Fälle braucht es das.
Also für mich ist es ein System, was alles alleine kann und dazu gehört meistens auch eine Nutzerinteraktion, mag aber auch SCS geben, die vielleicht wenig, weil es keine brauchen, dann wäre das für mich auch okay.
Für mich ist eigentlich, zumindest in der Praxis, das wichtigste Feature mal gewesen, dass es relativ unabhängig im Betrieb ist.
Das heißt natürlich, das System redet mit anderen Systemen, aber selbst wenn alle anderen Systeme weg sind, kann das eine Self-Contained System immer noch seinen Job zu einem großen Teil erfüllen.
Das wäre so für mich eigentlich die wichtigste.
Natürlich brauche ich Load-Balance und was auch immer noch technisch drumherum, aber so das SCS in sich kann immer noch einen Business-Mehrwert schaffen, wenn der etwas reduziert.
Und diese Laufzeitenunabhängigkeit zu einem gewissen Grad ist für mich eigentlich das zentrale Feature.
Wie das dann innen drin technisch aussieht und wie es sich mit anderen dann integriert, ich glaube, da muss man dann Einzelfallentscheidungen vielleicht auch treffen, was in dem Kontext wichtig ist.
Aber diese Resilienz zur Laufzeit ist für mich eigentlich der größte Benefit.
Ich denke, das ist auch so eine Abgrenzung zu den Plain Microservices, weil die ja ohne eine vorgeschriebene, ich sage jetzt mal Integrationspräferenz kommen, während SCS ganz, ganz deutlich sagt, hier ist eine Art und Weise, wie Systeme interagieren sollten, wie sie integrieren sollten, die diese wahnsinnige Laufzeitunabhängigkeit zur Folge hat.
Und das ist...
eine Sache, wo dieses Microservices plus UI, glaube ich, ein bisschen zu kurz greift in der Definition.
Ich denke auch eben diese Resilienz oder diese Unabhängigkeit spiegelt sich ja auch wieder bei der Release-Barkeit der einzelnen Self-Contained-System, damit eben die Benutzer, die das verwenden, nicht gestört werden, auch wenn wir vielleicht mal einen Ausfall hätten, weil das wichtige Thema ist ja nicht jeder Self-Contained-System hat die gleichen Verfügbarkeitsanforderungen, das heisst, es könnte Self-Contained-Systems geben, sehr wenig verfügbar oder nicht eine hohe Verfügbarkeit haben müssen und die könnten wir dann aus Betrieb nehmen für eine Release zum Beispiel, aber das Gesamtsystem würde davon eigentlich gar nichts mitkriegen.
Ich würde auf Johannes hin mit den Microservices, weil was ich erlebt habe, ist so eine Microservices-Landschaft, die war vertikalisiert.
Aber es war eben nicht SCS-Style und dann, wenn ein Microservice ausgefallen ist, dann ist so diese Domino-Kette los und du konntest dann anhand welcher Symptome du gesehen hast schon fast darauf schließen, was der Ursprung der Domino-Steine war, die umgefallen sind.
Und das habe ich halt bei SCSen selten erlebt.
Man hat dann andere Probleme, da habe ich auch schon mal was zu erzählt, aber da würde ich sagen, wenn da einer umfällt, fallen die anderen in der Regel nicht auch mit um und das finde ich es schon.
Das habe ich auch in Produktion mehrfach gesehen.
Das funktioniert wirklich.
Also was ich daran gut finde an der Diskussion ist, das bedeutet halt, dass der Begriff Self-Content Systems gut gewährt ist.
Weil das, was ihr jetzt irgendwie in den Mittelpunkt stellt, bedeutet eben genau diese Selbstabgeschlossenheit.
Es gab auch mal diese Idee, das System of Systems zu nennen und irgendwie, ich weiß nicht mehr, wo die Diskussion war, das ist halt dann verworfen worden.
Eine Frage, also um mal den großen Konsens ein bisschen sozusagen zu brechen.
Das impliziert ja, dass die herausragende Eigenschaft eigentlich die Verfügbarkeit ist.
Also ich kriege halt Self-Content Systems, die halt getrennt verfügbar sind und getrennt halt ausfallen.
Und also ich bin nicht sicher, wie wichtig das ist, weil ich halt erwarten würde, dass halt in vielen Fällen diese Self-Content, die ja Verfügbarkeit sowieso garantieren können, weil eben nicht Kubernetes, das Cluster da ist und so weiter und so weiter.
Und ich habe immer das Gefühl, bei Softwarearchitektur oder das, was ich versuche in den Mittelpunkt zu stellen, ist mal so eine fachliche, vernünftige Aufteilung.
Und da sind ja Self-Contained Systems auch stark, weil sie halt sagen, das ist halt eine Domäne und ich habe dann eben alles für diese Fachlichkeit, alle technischen Aspekte, inklusive der Web-Buchfläche halt in einem System, sodass das eigentlich für mich wichtiger ist als die Verfügbarkeit.
Und da bin ich dann vielleicht einer anderen Meinung oder vielleicht kriegen wir das halt auch hin, dass das eben beides eigentlich dasselbe ist oder wie auch immer.
Ich würde sagen, beides geht Hand in Hand.
Also du hast auf der einen Seite diese unabhängige Entwicklbarkeit, aber diese unabhängige Betreibbarkeit unterstützt zu einem großen Teil auch die unabhängige Entwicklbarkeit, weil das für mich zum Beispiel bedeutet, ich kann sehr viel in meiner lokalen Entwicklungsumgebung testen, ohne dass ich dafür andere Systeme auch hochfahren muss.
Also ich kann mir deren Daten, die bei mir lokal repliziert vorhanden sind, einfach in die Datenbank reintun.
Und solange sie sich an das gleiche Format halten, was mal ausgemacht wurde, kann ich mir relativ sicher sein, dass diese Integration dann auch in Produktion funktionieren würde.
Und das bedeutet für mich, also ich bin organisatorisch in der Entwicklung relativ lose gekoppelt an die anderen Teams und halt aber auch gleichzeitig durch die gleichen Integrationsmuster in der Laufzeitumgebung, falls dieses andere System kurzzeitig weg sein sollte.
Das finde ich ein sehr wichtiger Aspekt, weil bis jetzt bei monolithischen Applikationen vor allem hatte man sehr viele Abhängigkeiten zwischen den Entwicklungsteams, also wenn es etwas Größeres war natürlich.
Und so verwenden wir überall mittlerweile Testcontainers mit generierten Testdaten und nicht mehr Kopien wie früher vom Produktivsystem zum Beispiel.
Und das macht die unabhängige Entwicklung erst so richtig möglich.
Also das heisst, die Teams können wirklich einen Selfcontain-Test klonen bei sich, damit arbeiten, testen und sind überhaupt nicht angewiesen auf irgendwelche andere Dienste, die irgendwie laufen müssen.
Das ist sehr wichtig.
Also ich glaube, diese fachliche Trennung und die Vorteile, die da mit sich kommen, unabhängige Entwicklungen und so weiter, und auch Parallelisierbarkeit vielleicht, ist genauso wichtig.
Für mich würde aber immer noch, wenn ich mich entscheiden müsste, es hilft mir nichts, wenn ich ein System ganz schnell und super unabhängig entwickeln kann und es dann aber zur Laufzeit ständig mir umfällt.
Das hilft mir da nicht, deswegen würde ich sagen, im besten Fall ist es die Mischung, glaube ich, aus beidem.
Aber...
Trotzdem ist diese Verfügbarkeit einfach ein so riesiges Asset in der Realität, weil auch in Kubernetes Clustern jemand macht einen Release und das zerhagelt.
Und wenn alle anderen Abhängigkeit auf diesen einen Service haben oder viele andere, dann ist der Rest halt in dem Moment auch weg.
Und Menschen oder auch die KI heute machen immer noch Fehler.
Also es wird immer was schief gehen.
Da können wir ja mal ausgehen.
Und selbst wenn es nicht mal wir selbst sind, dementsprechend würde ich sagen, das Fachliche ist auch super wichtig.
Hat auch genauso viele Challenges, glaube ich, noch zusätzlich.
Also wir haben diese technischen Challenges, nur weil ich weiß, wie ich es baue, ist ja trotzdem noch nicht einfach und alles.
Aber ich glaube, fachlich gut geschnitten und was bedeutet das dann auch über den Lebenszyklus?
Das ist nochmal eine ganz andere Herausforderung, wenn ich so ein System baue, betreibe.
Okay, also spannend, weil ich hatte halt gedacht, dass so ein bisschen die Antwort hier in der Luft, also die für mich eigentlich in der Luft lag, irgendwie die Aussage ist, naja, eigentlich machen wir halt vernünftige Modularisierung.
Wir machen insbesondere fachlich vernünftige Modularisierung und wir haben dann, und das ist eigentlich der Auslöser, also sprich, wenn ich das nicht hinbekomme, das fachlich vernünftig aufzuteilen, sodass ich da eben beherrschbare Abhängigkeiten habe, dann nützt mir das halt, also dann werde ich trotzdem Abhängigkeiten haben, egal wie ich das halt technisch ausführe als Self-Content Systems oder nicht.
Und dann habe ich aber eben mit Self-Content Systems diese, ich sage mal, vernünftige technische Modularisierung, die halt sagt, okay, ich habe eben ein Ding, was alle drei Schichten hat.
Und dadurch, also eben inklusive UI, was eben dadurch dann mir ermöglicht, diese fachliche Unabhängigkeit auch zu einer sehr starken Unabhängigkeit bei der Umsetzung von fachlichen Anforderungen zu überführen, dahin zu überführen, dass sich dort eben dann auch alle drei Schichten durch die fachliche Anforderungen ja typischerweise gehen, eben in einem zu ändern.
Also das ist so ein bisschen das, was mein Gefühl ist, was dann auch bedeutet, dass, glaube ich, oder für mich persönlich zumindest, dann die Diskussion irgendwann weggegangen ist von diesem Thema mit den Microservices hin zu diesem Thema mit Domain-Service und Design, und bekomme ich das Fachlich vernünftig hin, dass das Problem hauptsächlich ist.
Wir haben ein Gefühl, aber ja.
Ja, würde ich auch sagen, also beim Grosshandelskund zum Beispiel geht es ja auch darum, dass eigentlich nur eine Abteilung für ein Self-Content System nötig ist, um das zu entwickeln.
Weil sonst hast du Stakeholder-Management übergreifend über verschiedene Abteilungen und das ist immer schwierig, da Konsens zu finden und vor allem mit denen zusammenzuarbeiten.
Und deshalb hilft es auch den Product Owner zum Beispiel bei der Firma, dass sie wirklich nur einen Ansprechpartner haben.
Also auf beiden Seiten macht es dann die fachliche Trennung viel einfacher.
Ich glaube aber, ich kann im Zweifelsfall mal...
Ein guter Schnitt erleichtert es mir auch eine gute Modularisierung und eine gute technische Umsetzbarkeit.
Es wird aber bei Schnitten immer, ich sag mal, Grauzonen geben und ich kann da auch mal einen ausgründen, einen schlechteren fachlichen Schnitt nehmen, aber kann es trotzdem noch technisch gut und stabil bauen.
Also ich glaube, auch da muss man manchmal wirklich sagen, da gibt es Trade-offs, eben weil ich nicht immer in der Realität dann fachlich perfekt schneiden kann oder will oder es irgendwelche Beweggründe geben mag.
Und da sehe ich dann schon, Wenn ich natürlich richtig schlecht fachlich schneide, dann habe ich so viele Abhängigkeiten und dann wird es technisch auch unmachbar.
Deswegen muss ich beides berücksichtigen.
Aber man kann da vielleicht mal Abstriche machen, wenn es dem großen Ganzen dient, wenn ich nämlich Auslastungskapazitätsprobleme habe in den Teams.
Weil das ist natürlich schon, finde ich, eine Herausforderung, wenn ich mehrere Teams habe, die Arbeit auch unter den Teams möglichst gleich zu verteilen.
Das ist dann eher so diese organisatorische Frage wieder drauf.
Genau, ich will jetzt, damit wir das sozusagen auch noch einmal eingeblendet haben, also der Ralf, der ja auch mit dem Stream arbeitet, hat halt geschrieben, die grobe Definition, ich nehme an, das ist halt diese von wegen, das ist halt ein Microservice mit Web, ist halt meines Erachtens leichter zu verstehen.
Die Vernetzung der Systeme finde ich spannend.
Die Aussage finde ich spannend, weil ich würde behaupten, oder das wäre halt die Frage, ich würde behaupten, eigentlich sagen, Self-Contained Systems, auch durch den Namen, nicht Self-Contained, das ist ja fast die Abwesenheit einer Vernetzung.
Also ja, es gibt halt diese Idee, dass ich halt diese Systeme asynchron integrieren kann und dass ich eine UI-Integration haben will, aber eigentlich sagt halt Self-Contained und auch meiner Ansicht nach Modularisierung, dass das eigentlich ein Minimum sein sollte.
Deswegen...
Würde ich mich dazu hinreißen lassen, zu sagen, das Spannende ist die Nicht-Vernetzung der Systeme, nicht die Vernetzung der Systeme.
Ich finde, das sieht man auch ganz gut reflektiert, wenn man sich anguckt, was empfohlen wird bei der Systemintegration von Self-Contained Systems.
Weil das Erste und eigentlich implizite ist, wenn ich eine Integration vermeiden kann, sollte ich sie auch vermeiden.
Und das spricht zum Beispiel aus dieser...
kaum geteilte Infrastruktur, Kriteriumsregel, die auf der Seite beschrieben ist.
Wenn ich mir nichts teile, dann bin ich auch wesentlich unabhängiger mit einem anderen System.
Und das sollte meine erste Präferenz sein.
Wenn ich tatsächlich integrieren muss, sollte ich dann die loseste Form der Integration wählen, die es gibt oder die ich mir leisten kann.
Und im Zweifelsfall ist das dann Vielleicht nur auf einer UI-Ebene, dass ich einen Link von A nach B setze, damit ich von A nach B gelangen kann.
oder ein bisschen größer gefasst, dass ich mir ein UI-Element aus einer anderen Applikation in meine eigene Applikation reinnehme und die bei mir anzeige, ohne dass ich genau wissen muss, was steckt jetzt dahinter, was verbirgt sich da an Datenstruktur, was ist das fachlich genau, was ich mir da reingeholt habe.
Ich zeige es dem Nutzer nur an und biete ihm vielleicht im Kontext irgendwelche Operationen aus einer fremden Fachlichkeit an.
Vollkommen natürlich und bis hin zu dem, dass ich nicht verstehe.
Also Netflix ist ja irgendwie ein populäres System, was halt sehr stark synchron integriert und es scheint auch so zu sein, wenn man sich Service-Meshers anguckt, dass die halt insbesondere synchrone Kommunikation halt unterstützen.
Und es ist so, dass ich es nicht verstehe.
Also ich verstehe, dass es Dinge gibt, wo ich eine synchrone Integration benötige.
Das Beispiel, was ich halt immer nenne, ist ein Preisberechner.
Wenn ich den Preis eines Produkts in der Webseite anzeigen will und da habe ich einen Preisberechner, der das aufgrund von komplexen Dingen tut, dann werde ich den synchron aufrufen müssen.
Es geht eben nicht anders, wenn das eben spezifisch für den Kunden und so weiter ist.
Und da bin ich halt dazu gezwungen, da habe ich halt keine Wahl.
Sonst finde ich halt den Fokus auf asynchrone Integration Eben völlig natürlich, weil synchrone Kommunikation bedeutet eben, dass ich halt diesen Ausfallaspekt habe und es ist insgesamt eigen, also es gibt ja auch diese Fallacy, dass irgendwie dieses Verbergen von Netzwerk, dass das eben eine schlechte Idee ist, weil das Netzwerk kann irgendwie ausfallen und so weiter.
Und deswegen ist das für mich so natürlich, dass es eigentlich fast nicht mehr erwähnenswert ist.
Bei dieser kaum geteilten Infrastruktur, die du ja ansprachst, muss ich halt gestehen, also in meiner Erinnerung ist es halt so, dass das irgendwie als zusätzlicher Punkt reinkam.
Und ich bin der Meinung, dass es eine Diskussion gab und ich möglicherweise daran schuld bin, dass es eben kaum geteilte Infrastruktur heißt und nicht keine geteilte Infrastruktur, weil ich ehrlich gesagt diesen Punkt nie wirklich für mich verstanden habe.
Also, dass mehrere Komponenten sich zum Beispiel in der Datenbank teilen, ist etwas, was halt jahrelang lang umgeben war und was irgendwie bis zu einem gewissen Maß bei einer bestimmten Skalierung halt auch nicht so lange die Datenbank hat skaliert.
Das ist, glaube ich, auch irgendwie kein Problem.
Und ich verstehe nicht, warum man dort sagt, dass man möglichst wenig geteilte Infrastruktur haben will.
weil das auch so ein weiches Kriterium ist.
Also will ich jetzt eine gemeinsame Datenbank haben, ja oder nein, hängt halt von technischen Eigenschaften ab.
Komme ich halt an das Skalierungsende dieser Datenbank und ist diese Datenbank ausreichend verfügbar?
Das ist irgendwie, also das ist halt ein weicher Faktor.
Also es ist nicht hart so wie, oder es ist für mich nicht so entscheidend.
Es ist für mich, ob da jetzt ein Datenbankserver steht oder mehrere, aus meiner Sicht nahezu egal.
Und ich kann es ja auch revidieren.
Also ich kann halt aus, wenn ich getrennte Datenbankschema da habe, relativ easy aus einem Datenbankserver mehrere machen.
Also für eine Definition von easy.
Aber ich glaube, da genau kommt dieser Satz und auch der Schmerz, der sich dahinter verbirgt, her.
Wenn du halt einen gemeinsam genutzten Datenbankserver hast, was gefühlt bei 80 bis 90 Prozent der Unternehmen, die ich berate, eigentlich die zentrale Realität und die zentrale Datenquelle ist, dann macht es das sehr, sehr einfach, auf eine Systemintegration zu verzichten und einfach zu sagen, wenn du das brauchst, lies es doch aus der Datenbank.
Du hast doch den Connection String und es steht in deinem Schema, du brauchst nur die Tabelle einfach lesen.
Und warum sollten wir hier irgendwie eine Schnittstelle bauen und de facto Ist es so, dass wenn ich mich umgucke in der Versicherungswelt, in der Bankenwelt, wo ich unterwegs bin, geschieht bestimmt 80 Prozent der Integration zwischen Systemen über gemeinsam genutzte Datenbanken?
Vielleicht kann ich dazu etwas sagen.
Wir haben auch technisch gesehen eine oder mehrere Datenbankinstanzen.
Die sind auch geteilt, weil ich bin eigentlich Eberhards Meinung, das spielt eigentlich gar nicht so eine Rolle, rein aus Applikationssicht, weil die Schnittstellen respektive die Isolation passiert über das Schema, also grundsätzlich über Berechtigung, was man in der Datenbank darf und was nicht.
Und zur asynchronen Kommunikation möchte ich noch ergänzen, dass wir auch asynchron Daten replizieren.
Also wir haben Datenreplikation zwischen Self-Contained System, weil wir grundsätzlich ein System haben, das verantwortlich ist für einen bestimmten Datenbereich und die Daten werden dann auch je nachdem, wie aktuell die sein müssen, repliziert.
Also nicht, dass wir...
Down-Events herumschieben und irgendwie Event-Sourcing oder sowas betreiben, sondern wir replizieren bewusst gewisse Daten von System A nach System B.
Die aber dann denormalisiert in der Regel und gefiltert repliziert werden, damit wir die Datenmenge möglichst klein halten.
Und das ist halt so, weil man, du hast Artikelstammdaten zum Beispiel, die brauchst du praktisch überall, gewisse davon.
Die werden dann halt einfach so repliziert.
Und wir versuchen eigentlich eben...
über Berechtigungssteuerung und Schemas und Views und materialisierte Views und was auch immer wir zur Verfügung stellen, eine starke Entkopplung auf Datenbank-Ebene zu erreichen, die auch überwacht wird.
Also grundsätzlich wird dann geprüft, dass nicht irgendwie ein Schema auf ein anderes Schema zugreift, das da nicht erlaubt ist.
Ähnlich wie wenn wir auf das Package-Strukturebene machen würden, machen wir das auch auf Datenbank-Ebene.
Ich würde auch sagen, pragmatisch kann ich bei der Infrastruktur Abstriche machen.
In einer idealen Welt würde ich die Infrastruktur auch komplett trennen.
Das scheitert, ich sage mal, oft an Kosten, weil überall eine eigene Datenbankinstanz, überall ein eigenes Kubernetes-Cluster und Betrieb.
Wobei ich jetzt ja heute sagen würde, mit KI müsste dieser ganze Wartungsbetriebsaufwand vielleicht wieder besser werden.
Aber es ist nicht nur, wir teilen uns die Datenbank.
Natürlich sollte ich das Schema trennen.
Also da stimme ich vollkommen zu.
Minimum dafür, dass ich sowas dann zustimmen würde.
Aber wenn es dann schon Richtung Kubernetes Cluster geht, da dreht irgendwo was durch.
Natürlich kann ich das auch absichern, aber irgendjemand macht was in seinem Kubernetes Cluster und das ist geteilt, da läuft der Rest auch drauf.
Und zack ist meine Unabhängigkeit zur Laufzeit halt auch dahin.
Das ist das Gleiche bei Datenbanken.
Das ist das eine und das andere ist.
Wir machen Upgrades der Infrastruktur.
Wir hatten ein geteiltes Kubernetes Cluster.
Alle Teams müssen sich rechtzeitig vorbereitet haben und dann zieht sich so ein Upgrade über Wochen und Monate, weil wir haben da gerade was Wichtigeres und jetzt ist hier nochmal.
Und das sind halt so die Sachen, je weniger geteilt ist, desto mehr Unabhängigkeit hast du dann auch in der Entwicklung.
Aber die Realität zeigt auf, das ist halt auch ein Skill-Betriebskostenthema, was dann da schnell mit dazu kommt.
Genau, es kommt auf die Grösse der Firma drauf an, im Endeffekt.
Ich glaube auch tatsächlich, dass ein Teil der Antwort jetzt inzwischen ist, dass zunehmend Self-Service-Plattformen in den Unternehmen diese Koordinationsaufwände zu einem Teil auch ...
zu drücken versuchen, dass ich mir selbst dann das Kubernetes-Update verpasse oder dass ich sage, ich bestimme selbst, wann ich von A nach B umziehe, weil wir beide Cluster für eine Zeit lang parallel betreiben können und dass deswegen diese geteilte Infrastruktur nicht mehr so schmerzt, wenn ich sie halt mehr in die Kontrolle der Stream-Aligned-Teams, wenn ich mal die Team-Topologies-Terminologie benutzen darf, legen würde.
Und das war früher, also Anfang der 2010er Jahre, wo dieses Self-Contained-Systems-Thema, glaube ich, das erste Mal so richtig hochgekocht ist, war das, glaube ich, nicht der Standard.
Es sei denn, man war ganz vorne im Cloud-Business mit dabei.
Das verschiebt, glaube ich, auch so ein bisschen zugunsten von, die geteilte Infrastruktur ist heute nicht mehr das gleiche Biest, was sie vor zehn Jahren vielleicht mal war.
Ich will noch eine Frage stellen.
an dich, Johannes, oder auch diskutieren.
Du hast ja vorhin gesagt, diese Integration über die Datenbanken und das kam fast an wie so ein Naturgesetz, so nach dem Motto, das ist halt das, was die Menschen machen.
Ich habe, glaube ich, eine etwas oder ich glaube, eine andere Wahrnehmung zu haben, auch darüber, was halt sozusagen der Rest der Welt darüber denkt.
Und ich habe halt eher so einen Kundenpattern, wo die Kunden halt irgendwie sagen, okay, cool, wir haben halt diese gemeinsame Datenbank.
Und das ist ja eine große Katastrophe.
Wir kommen davon irgendwie nicht weg.
Und daraus hätte ich jetzt so ein bisschen abgeleitet.
Es ist schon so, dass halt mindestens größere Teile unseres Businesses verstanden haben, dass halt eine Integration mit einer Datenbank eine echt schlechte Idee ist, weil das eben bedeutet, dass diese Systeme halt sehr stark aneinander gebunden sind.
Und ich kriege halt super komplizierte Datenbankmodellierung, die halt irgendwie auch niemand mehr versteht und so weiter.
Und ich hatte das Gefühl, das war jetzt bei dir eher so, naja, das machen die Leute halt.
simpliziert ja das ja damit, zufrieden sind.
Ist deine Wahrnehmung da eine andere?
Also ist das bei dir eine Success Story oder ist das eher so eine, die haben verstanden, dass das eigentlich eine schlechte Idee ist?
Ich glaube, viele haben verstanden, dass es eine schlechte Idee ist.
Das Problem ist so ein bisschen, wenn man das seit Jahren oder Jahrzehnten gelebt hat und einem die Alternativerfahrung fehlt.
Also wenn man noch nie eine Schnittstelle gebaut hat, die halt dieses gemeinsam genutzte, unternehmensweite Modell von der Domäne so ein bisschen versteckt absichtlich, sondern weil man sagt, wir haben doch schon immer auf alles zugreifen können und wenn wir alles preisgeben, dann braucht man die Schnittstelle ja nie ändern, weil dann ist die quasi stabil.
Sie ist ja allumfänglich und egal, welche Anforderungen wir morgen haben, die Daten sind schon da.
Was halt die Kehrseite der Medaille ist, wenn ich das bestehende Modell irgendwie ändern möchte oder die Annahmen, die da reingeflossen sind, ändern möchte, dann muss ich die komplette Firma abklappern und muss herausfinden, wer benutzt und interpretiert denn die Daten in dieser Schnittstelle.
Und das ist dann der Riesen-Change, der ein firmenweites Programm auf den Plan ruft.
Und gerade wenn ich Geschäftsmodell Innovation betreibe, wenn ich versuche, neue Kundenkreise zu erschließen, wie in diesen wahnsinnig gesättigten Märkten bei den Banken und Versicherern, dann ist das halt das größere Hindernis, dass ich sage, ich muss irgendwie an dieses gemeinsam geteilte Modell im Kern ran, muss das ändern können.
Und eine saubere Schnittstelle, die sehr viel versteckt von dem gemeinsam oder von den Daten, die mich eigentlich fachlich nichts angehen, hätte in dem Fall einfach sehr, sehr geholfen, das Geschäftsmodell schneller weiterzuentwickeln und neue Funktionen umzusetzen.
Wenn ich da vielleicht noch...
kurz ergänzen darf, also was ich halt bei meinen Trainings mittlerweile öfter mal mache, ist halt irgendwie die Frage stellen, warum darf man eigentlich auf Instanzvariable von Klasse nicht zugreifen?
Und die, also nicht direkt zugreifen.
Und die Antwort ist aus meiner Sicht Information-Hiding.
Also ich möchte halt die Implementierung und insbesondere die Datenmodellierung verstecken.
Und das Beispiel, was ich da halt immer nehme, ist halt ein Konto.
Also ein Bankkonto ist eben, da kann ich jetzt irgendwie abspeichern, dass ich gerade...
42 Euro auf dem Konto habe oder ich kann das halt berechnen aus den letzten Überweisungen.
Und wenn ich jetzt sage, gib mir den Kontostand, also nicht den Kontostand exponiere, kann ich die eine Implementierung in die andere überführen.
Und meine Beobachtung ist halt, es sind eigentlich zwei Dinge.
Die eine Beobachtung ist halt, dass man das nicht soll, Instanzvariablen nach draußen zugreifbar machen.
Das ist irgendwie klar.
ist mein Gefühl oder ist das, was ich halt irgendwie merke, es kann immer daran liegen, nicht wie ich die Fragen stelle und so weiter, nicht klar oder nicht so richtig bekannt ist irgendwie diese Beziehung hin zu dem Information-Hiding.
Und der Grund, warum ich das halt irgendwie erzähle, ist, weil das ist genau das Problem, das wir halt haben.
Bei dem Zugriff auf die Datenbanken.
Wenn ich halt die Datenbanken nutze, dann bedeutet das, dass eben die Modellierung in der Datenbank eine Abhängigkeit halt ist.
Und irgendwie ist das bei Klassen total klar.
Also es ist halt ein Tabu.
Also tatsächlich Tabu im Sinne von, es ist vielleicht gar nicht klar, warum das halt nicht gemacht wird, aber es ist halt ein Tabu.
Und bei den Datenbanken fehlt irgendwie dieser Schluss.
Und das ist...
Was mich dabei halt so fasziniert ist, das ist halt eine fundamentale Softwarearchitekturfrage, nicht?
Information Hiding ist halt fundamental, das ist Modularisierung und eigentlich ergibt sich das daraus und dann kann man halt, naja, weiter diskutieren und das ist aber so ein bisschen die Grundlage.
Ich habe das Gefühl, wir kämpfen da aber auch zu einem Teil gegen eine Herangehensweise an die Softwareentwicklung an, die historisch sehr datenbankzentrisch geprägt war.
Also wenn ich einen Großrechner entworfen habe, habe ich als erstes das Datenbankschema modelliert und habe das umgesetzt.
Und auf der Basis entstanden dann all die Prozeduren, die auf den Daten operiert haben und all die Batchläufe etc.
Dieser Gedanke von das Schema ist das Zentrum und das Fundament meiner Anwendung, der ist noch sehr stark in den Köpfen, gerade bei den alteingesessenen Unternehmen, die sehr früh auf Grossrechner gesetzt haben.
Ich denke, das Problem ist auch, dass die Leute nicht begriffen haben, dass verschiedene Module in einem System nicht dieselbe Sicht auf die Daten haben.
Also zum Beispiel nehmen wir an, wir haben ein Artikelstammsystem, das hat sehr ein...
normalisierte Strukturen und Sicht auf die Artikel mit Preishistory und so weiter.
Und das braucht das Verkaufssystem nicht, weil dort gilt ein Preis und ganz wenige Informationen vom Artikel.
Also eigentlich hätten wir das schon in einer monolithischen Applikation mit einer riesen Datenbank gehabt.
Man hat es aber nicht gemacht, sondern man hat eigentlich ein durchgängiges HyperNight-Mapping gemacht, sehr häufig.
Und dann haben alle auf dieselben Entitäten zugegriffen.
Und eigentlich wäre es viel cleverer gewesen, wenn man zum Beispiel dort schon Views definiert hätte oder halt Aggregation von Daten, die man austauscht und nicht direkt auf dieselbe Datenbasis geht.
Das gilt auch fürs Kleine.
Also auch wenn man kleine Applikationen macht, ist das sehr häufig eigentlich ein Unding, dass man dieses globale Datenmodell irgendwie allen Komponenten zur Verfügung stellt.
Ich würde auch sagen, was ganz viele...
Denken, was Modularität bedeutet, ist, dass ich gewisse Teile in eine Box gepackt habe und andere Teile habe ich in eine andere Box gepackt.
Aber sehr viel relevanter und sehr viel interessanter ist, wenn diese beiden Boxen miteinander sprechen, was genau geht über diese Schnittstelle zwischen den beiden Boxen drüber und wie viel können die voneinander sehen?
Also das Information-Hiding, was du schon erwähnt hast, Eberhard.
Dass das eigentlich der Punkt ist und dass ich das eigentlich am liebsten auf jeder Ebene haben möchte.
Mikroarchitektur in der eigenen Anwendung drin, aber auch vor allem in der Makroarchitektur, wenn ich zwischen verschiedenen Anwendungen gucke, möchte ich, dass ich an den Schnittstellen nur wirklich das sehe, was auch wirklich notwendig ist zu sehen.
Kurz nochmal ein ganz anderes Thema, was ich halt aus der Vorbesprechung mitgenommen habe, was ich irgendwie spannend fand, um das halt anzusprechen, das ist halt diese Geschichte mit, das hattest du Silvia auch schon kurz versucht anzuschneiden, Also wenn ein SCSI im Team gehört, aber ich habe irgendwie diese nicht gleichmäßige Verteidigung von das, wie gehe ich damit um?
Ich glaube, das war halt das Thema, was du da genannt hattest.
Möchtest du dazu was sagen?
Ja, kann ich kurz nicht glauben.
Ich glaube, da kommen wir ein bisschen auf die Brücke zu diesen Datenbank-Integrationen spielen, weil ich glaube, das ist auch vielleicht ganz oft passiert, weil sie geht schnell.
Wenn ich schon Zugriff auf die Datenbank habe und die Tabellen liegen da, dann ist auch kein Aufwand, die da dran zu kommen.
Wenn ich aber...
Bisher habe ich Artikelstammdaten, habe ich vielleicht schon, aber vielleicht habe ich bisher keine Kundenstammdaten gebraucht.
Jetzt brauche ich zukünftig Kundenstammdaten, die sind aber noch nicht so exposed oder nicht mit den Attributen, die ich brauche.
Natürlich war das leicht in die Kundendatenbank-Tabelle und dann werde ich damit schon klarkommen.
Wenn jetzt aber jemand anders für mich diese Daten bereitstellen muss, weil die noch nicht so, wie ich sie brauche, da sind oder nicht vollständig, dann ist das eine Abhängigkeit.
Und das ist das, was ich ganz oft erlebt habe, dass die Teams zwar an sich unabhängig voneinander entwickeln können, Aber sie haben natürlich trotzdem fachlich-inhaltliche Abhängigkeiten und brauchen sich gegenseitig.
Das ist so dieses eine.
Deswegen glaube ich, hängt das so ein bisschen zusammen.
Das war früher halt leichter.
Das Problem ist auch heute immer noch da, dass ich, ich will was bauen, ich brauche Dinge von anderen Teams.
Das andere ist aber, wenn ich neue Sachen baue, dann habe ich es fast in jedem Unternehmen erlebt, es gibt immer dieses Bottleneck-System, das Bottleneck-SCS, das immer gebraucht wird, egal was wir bauen, gerne der Checkout im E-Commerce.
Oder das eine Team, was das, also es gibt immer so dieses eine Team, das ist immer mit involviert bei jeder Initiative, bei jedem Projekt, weil, seien wir auch ehrlich, je größer so eine Initiative, Projekte in einem Unternehmen, desto mehr Teams sind daran beteiligt.
Die haben aber auch alle noch irgendwas anderes, ihre eigenen Produktverbesserungen und so weiter.
Und dieses Scheduling, dann zu entscheiden, ich will ein neues Feature bauen, eine neue Fähigkeit in mein System bringen, wo packe ich es denn hin?
Oft gibt es, okay, da ungefähr passt es hin, dann fange ich aber drüber nachzudenken, dann gibt es diese Grauzonen.
Und das ist für mich so die eigentliche Herausforderung, mit der ich mich dann beschäftigen muss.
Es gibt das Idealbild, dieses Team hat aber eigentlich gerade gar keine Zeit.
Wenn ich das aber jetzt haben will, weil das ist mein Business-Need, dann gucke ich, kann ich es vielleicht woanders hinbauen, mache ich das Team größer, das ist dann immer so der zweite Versuch.
Aber wir wissen alle, mehr Leute machen es halt auch nicht besser.
Und ich habe mal mit einem Kollegen...
einen Vortrag ausgearbeitet, ich glaube, den hatten wir für die Shownotes vorgesehen.
Und da haben wir das unterschieden in, es gibt diese ideale Seite, wie ich etwas verorte, also den fachlichen Schnitt mache.
Ich mache es schön vertikal, ich berücksichtige die fachlichen Prozesse, ich berücksichtige vielleicht auch technische Abhängigkeiten.
Weil gerade wenn ich mich mit Third Partys integrieren will, will ich dann, dass sich zehn Teams mit dem gleichen alten Legacy-System integrieren oder will ich das womöglich in einem Team kapseln?
Auch solche Fragestellungen kommen dann mit rein.
Und auf der anderen Seite, Die Realität, wie viele Themen liegen schon in dem Team?
Wie viel hat das Team gerade zu tun?
Also in welchem Produktlebenszyklus ist es?
Hat es gerade lauter neue Sachen, die noch ganz viel Weiterentwicklung brauchen, weil das ist alles MVP, was da gerade rumschwirrt und eigentlich muss das erstmal noch ein bisschen besser werden?
Oder sind die eigentlich in so einem Wartungsmodus und hätten eigentlich kapper, was Neues reinzubauen?
Und das ist halt was, das wirst du auf einer technischen Seite nie unbedingt sehen.
Und dann auch, welche Skills hat das Team?
Oh, ich will da jetzt was Machine Learning-mäßiges reinbauen.
Hat das Team überhaupt die Fähigkeiten?
Passt das da rein?
Wie sieht der Tech-Stack aus, den ich jetzt dafür brauche?
Was für eine Datenbank brauche ich?
Und das sind so für mich Aspekte, die kommen einfach noch dazu in der Realität.
Das sind so ein bisschen soziotechnische Themen dann auch oft.
Aber das ist das, was für mich schon über den Lauf der Zeit dann eigentlich das Thema ist.
Und auch wann.
Also das SCS kann nicht verschwinden, aber wann brauche ich das Team noch?
Wie viel SCS kann auch ein Team besitzen?
Auch das ist eine Frage, die ich mir irgendwann im Laufe der Organisationsentwicklung mal stellen muss.
Wir haben das so gemacht, dass wir eigentlich Hauptdomänen definiert haben.
Also wenn man Handel anschaut, hat man in der Regel Einkauf, Verkauf, Logistik, Finanzen und noch irgendwelche Basisdienste.
Und die Teams werden organisiert nach diesen Strukturen.
Es ist natürlich klar, dass das Verkaufsdomäne die grösste ist.
Weil Logistik ist typischerweise eingekauft und macht man nicht selber.
Also das sind dann die fremden Self-Contained Systems sozusagen, die auch erwähnt werden.
Und grundsätzlich ist genau das Thema.
Also wie kriegen wir die Leute da hin?
Das hat natürlich auch mit der Makroarchitektur zu tun zum Beispiel.
damit sich die Leute eigentlich relativ rasch zurechtfinden.
Das Problem ist ja in der Regel jetzt in diesem Kontext nicht unbedingt das Technische zurechtfinden, sondern das Fachliche zurechtfinden.
Also wer versteht dann die Anforderungen, die implementiert werden müssen?
Und das ist eigentlich der Haupttreiber dann.
Und dort nutzt es auch nichts, wenn es ein anderes Team machen würde, weil die hätten das Fach-Know-how eben wahrscheinlich eben auch nicht.
Genau, es gab einen Hinweis in der Literaturempfehlung von dem M.
Klinke 82.
Bei YouTube, Balancing Coupling and Software Design von Vlad Kononov.
Das wäre dort eine Idee.
Johannes, du schoenst den Bezug.
Kann ich empfehlen.
Wir können springen zu einem etwas anderen Thema, also nahezu ein Klassiker, den, glaube ich, Ralf Jambi auch wieder aufmacht, im Kommentar bei LinkedIn.
Dort hat er Aber ich möchte gegenüber dem Nutzer ja nicht X-Systeme zeigen, sondern zum Beispiel eine gemeinsame Navigation und einen nicht sichtbaren Sprung zwischen zum Beispiel Warenkatalog und Bestellsystem vermeiden.
Und das ist, glaube ich, so dieser Hinweis zu der Vernetzung der Systeme, über den wir vor einiger Zeit gesprochen haben.
Das ist also mit Vernetzung gemeint.
Wir haben vorhin auch kurz, du hattest das glaube ich gesagt, Simon, ich glaube du hast das als Erster in den Mund genommen in dieser Session, den Begriff von Makroarchitektur, ich glaube der hängt damit zusammen.
Also was ist da eure Erfahrung, ist das ein Thema, wie geht man das an?
Und ich glaube, das ist ja auch ein bisschen so ein Klassiker, den er da aufwirft.
Das ist bei uns fast kein Thema.
Weil wir relativ wenige Self-Contained Systems haben, die tatsächlich von mehreren Benutzerkreisen benutzt werden, vom Schnitt her.
Auf der anderen Seite haben wir ein Designsystem, das für alle passt.
Wir haben auch Konzepte, wie wir verlinken.
Zum Beispiel, wie machen wir Links zwischen Applikationen, die unveränderbar sind, damit, wenn wir dort Daten übertragen, dass die nicht verändert werden können.
Und im Endeffekt merken, dass die Benutzer nicht.
Also wir haben einen typischen Fall.
Wir haben im Prinzip das...
Das Auftragserfassungssystem, das das Callcenter braucht und die haben auch Qualitätsbeanstandungen oder Rückrufaktionen von Lieferanten.
Das sind zwei getrennte Systeme.
Die müssen dort hin und her springen, aber die merken das im Wesentlichen nicht.
Ich nehme da immer gerne das Beispiel von Amazon.
Weil Amazon, ohne dass sie gedacht haben, sind eigentlich Self-Contained Systems.
Also wenn du dann Produkte suchst, zum Beispiel Bücher suchst, dann bist du in einem Self-Contained System und dann der ganze Checkout ist ein zweites System und das Payment ist ein drittes System.
Heute sieht man es nicht mehr so gut, aber früher hat sich da Amazon überhaupt keine Mühe gegeben.
Die drei Teile haben alle völlig anders ausgesehen.
Und im Endeffekt...
stört das vielleicht weniger, wenn man es richtig macht.
Man darf auch nicht vergessen, dass sehr häufig in Geschäftsanwendungen die User sowieso mit verschiedenen Systemen unterwegs sind.
Die sind nicht nur eins, die haben noch zum Beispiel ein Mail-System, ein CRM, die haben vielleicht noch irgendeinen Logistik-Monitor, der vom Hersteller von einem anderen System da ist.
Ich denke, das stört gar nichts.
Es ist eher, wenn es eben Customer-Facing-Applikationen sind, dann möchte man natürlich, dass das ziemlich seamless ist.
Aber wie gesagt, durch den Schnitt kann man steuern, wie viel Integration es da tatsächlich braucht auf dieser Ebene.
Ich hatte ja auch...
Genau, zwei Sätze.
Ich hatte, ich als jemand, der nicht so wahnsinnig tief in E-Commerce drinsteckt, habe ich auch immer gefragt, warum jetzt ein Checkout hat, irgendwie, da Sintia Wizard ist, genauso aussehen soll, wie Produktsuche und Produkte browsen.
Und das sind eben unterschiedliche Sachen, die ich jetzt gedacht habe.
Weiß ich nicht.
Silvia, ich habe dich unterbrochen.
Nein, zwei Seiten.
Also ich glaube, ja, sie sehen unterschiedlich aus, aber gewisse Informationen sollten auch konsistent aussehen.
Also ein Preis und eine Artikelbeschreibung sollte nicht jedes Mal irgendwie völlig anders strukturiert sein, Artikelnummern, auch wenn es einmal in der Suche und einmal im Checkout ist.
Ich glaube aber, das, was total wichtig ist, ist die Integrations- oder ...
wie gut Systeme integriert sind, so viel höher ist der Nutzerwert.
Das heißt, ich habe durchaus noch diese Anforderung an, wie gut lassen sich meine Systeme integrieren.
Also ja, ich erlaube DeepLinks, ist so für mich, also das ist das absolute Basic unveränderbare DeepLinks.
Ich habe womöglich UI-Komponenten, die ich einbetten kann, hatte Johannes vorhin schon gesagt.
Also dieses ganze Frontend-Web-Integrations-Thema, die Möglichkeiten sind da.
Ich muss es, glaube ich, dann zum einen technisch machen und ich muss es aber auch von der...
Produktseite herdenken.
Wir hatten bei uns das Beispiel, es gibt das typische BI-Tool, wo ich mir Abverkaufszahlen zu meinen Artikeln anschauen kann als Händler.
Gleichzeitig habe ich ein System, wo ich Sachen nachbestellen kann.
Das ist doch das naheliegendste eigentlich zu sagen, ich bin gerade auf einer Produktseite, wo ich was nachbestellen kann.
Ich schaue mir nochmal die Performance von dem Artikel an.
Will ich den oder wie viel brauche ich davon?
Da einen Link tief ins BI-Tool rein.
Aber auf solche Sachen muss ich erstmal kommen.
Das heißt, oft muss die Integration gar nicht eins zu eins sein.
Ich darf auch sehen, dass es einen Systembruch gibt.
Das ist so das eine.
Und das andere Extrem ist, wir haben einmal sogar unternehmensübergreifend, also im Konzern, eine gemeinsame Navigationsleiste über mehrere CMS- und Shop-Systeme hinweggebaut.
Und ich behaupte, der Endkunde hat das nicht gemerkt.
Das heißt, es gab ein Designsystem, so ein bisschen das ganze CI-Thema abgebildet und eben diese Navigationsleiste wurde dann von einem System ausverteilt.
Ja, da muss ich mir dann wieder über die Kopplung Gedanken machen.
Aber ich glaube, das geht und da steckt extrem viel Benefit für den Nutzer hinter.
Wenn ich Glück habe, ich muss nur eins benutzen, gerade in so Backoffice-Anwendungen ist das, glaube ich, üblich, dass ich ein, zwei Systeme vielleicht habe.
Aber der echte Mehrwert von den Systemen kommt, wenn sie gut integriert sind, ich direkt von einer Analyse in eine Aktivität abspringen kann und so weiter, auch bei internen Mitarbeitern, je nachdem, wie es sich halt verhält.
Es gibt Bereiche, die dann doch irgendwie...
fünf Informationsquellen brauchen oder so.
Es gibt eine Frage, die ist durch das Tool reingekommen, also durch die Website reingekommen und ist deswegen anonym.
Ich habe sie jetzt irgendwie nochmal so zwingend in YouTube veröffentlicht, damit wir sie hier auch einblenden können und habe sie auch etwas reformuliert.
Ich hoffe, dass das okay ist.
Also die Frage ist, ist ein System für den Austausch von Daten mit verschiedenen Tools und Programmen ebenso zu behandeln bei seinen Styles, wie das Modellitätsthema sonst auch gehandhabt wird?
Und wenn...
Ich mich daran versuchen darf, ich würde behaupten, nein, weil ein System, was halt nur Daten von links nach rechts schaufelt, hat eine technische Aufgabe in erster Linie.
Und da sind viele von den Techniken, über die wir sonst reden, für Businesslogik Schwergewichte nicht so relevant, weil ich einfach keine Geschäftslogik habe.
Und diese ganzen Sachen, die ich bei taktischem DDD mache mit Entities und Aggregates und Services und so weiter, die würde ich zum Beispiel unterlassen.
Es macht vielleicht auch, so ein System hat vielleicht auch gar keine Benutzeroberfläche, sodass es kein Safe Content System sein kann.
Und manchmal ist es da, deswegen gibt es ja solche Sachen wie Transaction Script oder so, womit ich dann einfach sage, hier ist halt ein Stück Code, ich gehe mal kurz auf die Datenbank, mache halt irgendetwas oder schicke die Daten halt irgendwo hin und das ist es dann.
Ich würde vielleicht noch anmerken, dass solche Systeme manchmal die Chance vertun, Geschäftslogik zu haben.
Also ein System, wo jetzt BenutzerInnen sagen, ich will halt nur diese Daten sehen.
Da sollte man jetzt nächstes fragen, warum und was machst du damit?
Weil das ist das, was tatsächlich interessant ist.
Also werden die interpretiert, wird damit irgendetwas getan und das ist ja eigentlich die Geschäftslogik und vielleicht will ich das automatisieren.
Ich finde, das bringt auch ganz gut den Punkt heraus.
SCS ist natürlich nicht die Silver Bullet, die überall passt, sondern ich glaube, der Sweet Spot für diese Architektur ist ähnlich verortet wie auch der...
Sweetspot für Domain-Driven Design im Allgemeinen ist.
Also wenn ich eine wahnsinnige fachliche Komplexität habe, idealerweise so viel, dass es nicht ein Team alleine stemmen kann, sondern ich verschiedene Teams habe, die daran parallel arbeiten möchten und weitgehend unabhängig sein möchten.
Und wie gesagt, die Komplexität ist fachlicher Natur.
Sie ist nicht aufgrund der technischen Lösungen, nicht aufgrund dem, was wir machen.
Ich hatte mal einen Kunden, der hat Telefonanlagen-Software gebaut.
Und bei denen war die Komplexität nicht fachlicher Natur, sondern vor allem technischer Natur.
Verschiedene Standards von Telefonverbindungen, SIP muss mit ISDN und hast du nicht gesehen.
Und da kam die Komplexität halt einfach wo ganz woanders her.
Da hat das mit dem Self-Contained Systems und Mach-Vertikalen und so einfach nicht draufgepasst auf deren Domäne.
Ich hätte auch gesagt, man kann aber trotzdem potenziell von self-contained systems lernen, weil man muss das Ding nicht als ganzes Paket kaufen, sondern ich muss eigentlich verstehen, welche der Regeln bringt mir welchen Benefit und dann kann ich auch sagen, oh, asynchrone Datenreplikation ist echt nützlich.
Das ganze UI-Zeug brauche ich nicht, weil deswegen, ich war mir bei der Frage gerade gar nicht sicher, macht dieses Tool wirklich nichts mit den Daten oder hat das doch eine Geschäftslogik, hat aber keine Nutzer in...
Interaktion und braucht deswegen diesen UI-Teil nicht.
Ich glaube, ja, dann muss ich nicht alles, was dieses UI bedingt haben, aber ich kann trotzdem, asynchrone Datenreplikation kann auch total nützlich sein ohne eine UI oder die geteilte Infrastrukturthematik kann ich mir auch rauspicken und überlegen, was das für mich bedeutet.
Genau.
Ich denke, da bei unseren Systemen, also beim Grosshandelskunden, hat es natürlich ganz viele Kundenschnittstellen, es hat Lieferantenschnittstellen.
Und jetzt ist die Frage, was machen die?
Also gehen die direkt auf die Datenbanken, die Daten sammeln oder haben die eben auch eine Sicht oder eine Replikation auf die Daten, die sie brauchen und exportieren die dann von dort?
Also das hat sicher, unabhängig davon, dass es eben kein UI gibt, wobei es meistens eben trotzdem ein UI geben könnte, weil vielleicht jemand sehen möchte, was da gerade läuft oder wenn es Probleme gibt.
Und deshalb könnte das dort ja auch irgendwann gelten.
Und ich glaube, das ist ein ganz wichtiger Punkt, also zu sagen, dass das halt eine Inspirationsquelle ist und eine Zusammensetzung von bestimmten Ansätzen.
Und was ich manchmal so als Frage bekomme, bekommen habe, insbesondere in den Trainings, ist, naja, ich habe hier ein System, keine Benutzungsfläche, wie mache ich denn daraus Self-Contained Systems?
Und also die Antwort ist, naja, macht man halt nicht.
Und ich glaube, da ist halt so ein bisschen dieses Problem, dass das scheinbar so eine Art, wie soll ich sagen, Qualitätssiegel ist nicht.
Also ja, offiziell Self-Contained System.
Und das ist irgendwie am Ziel vorbei.
Also es geht nicht darum, dass wir Self-Contained Systems bauen, sondern wir wollen halt eine Architektur bauen und die Architektur soll irgendwie das unterstützen, was wir gerade tun.
Self-Contained Systems sind irgendwie besonders, merkt man hier ja auch, eben in sowas wie Web e-Commerce, insbesondere dort.
allgemein eben für Web-Systeme hilfreich.
Und das bedeutet, dass es halt in anderen Bereichen eben nicht hilfreich ist und man was anderes machen sollte.
Wobei ich jetzt nicht ausschließen würde, dass man gewisse Systeme, die per Definition ein Deployment-Monolith sind, nicht auch irgendwie Ideen draus nehmen kann.
Also ich denke vor allem an Mobile-Apps.
Die lassen sich zu einem gewissen Grad auch vertikalisieren.
Und sei es, indem ich Teile davon zur Web-App mache und sage, dieser Tab hier ist eine reine Webview oder dass ich hergehe und versuche, das halt als modulare, monolithische Codebasis zu pflegen, aber auch dann wieder mit unabhängigen Teams, die unabhängig Module voneinander entwickeln und beisteuern dürfen.
Also es kann durchaus Inspiration sein, wie ihr schon gesagt habt.
Und da ist aber dann für mich tatsächlich der Fokus eben Modularisierung, Domain-Groven-Design und dieses ganze Zeug.
Und deswegen ist ja, also ich halte das tatsächlich...
Es gibt ja in unserer Branche viele Sachen, die man halt kritisieren kann.
Aber dass jetzt eben wir stärker über diese Themen reden, obwohl Domain-Driven-Design ja noch älter ist, das ist irgendwie, ich glaube, 25 Jahre alt mindestens, finde ich halt designend gut.
Ah, hier ist ein Kommentar von Baumrinde K8Y bei YouTube.
Er oder sie schreibt nur meine drei Cent zum Thema.
Hat eine Querschnittsrolle, Performance Engineer für eine signifikant große SCS-Umgebung.
Und dann kommt halt die Aussage, das Konzept führt zu gigantischen Duplikationen von Code, insbesondere im Bereich der Webfrontends, weil es ein Uphill-Battle gegen größer 20 Teams, gegen Inkompetenz, Duplikation, inkompatible Technologien.
Ich sehe nicken.
Ich würde sagen...
Ja, bestimmt.
Also die Wahrscheinlichkeit, dass sich Code dupliziert, ist groß.
Da muss ich mir dann, glaube ich, Gedanken machen, mache ich sowas wie Inner Source oder also Shared Libraries im Sinne von, als wären sie Open Source.
Das kann das ein Stück weit helfen, aber auch das hat in der Realität sich dann oft auch sehr unabhängig von weiterentwickelt.
Die Frage ist, ja, es ist ein Preis, den ich zahle, für einen Benefit wirklicherweise, dass ich die Unabhängigkeit habe.
Da bin ich jetzt vielleicht auch zu lange weg aus der Entwicklung.
Heute mit KI, wie schlimm ist die Code-Duplikation vielleicht noch?
Also die Frage ist, da würde ich sagen, das war vor fünf Jahren noch deutlich schlimmer, weil dann wollte ich was upgraden oder verbessern oder verändern.
Das würde ich sagen, ist heute deutlich leichter geworden.
Inkonsistenz, ja, gutes Designsystem hilft an der Stelle, was dann auch möglichst nicht unbedingt dupliziert ist.
Auf der anderen Seite auch da wieder der Trade-off, merkt es der Kunde überhaupt, stürzt den Kunden, wird er deswegen nicht kaufen oder kauft er nicht, weil mein System nicht da ist.
Also ich glaube, das ist, ja.
Also ich würde sagen, wir haben praktisch keine Duplikation, weil wir ein sehr gutes Designsystem haben.
Das liegt auch mit der Web-Technologie zusammen, die wir verwenden.
Und auf der anderen Seite haben wir ganz viele Integrationssachen, zum Beispiel für Single Sign-On oder für andere Dinge, Monitoring, Tracing, Observability.
Und das ist alles geteilt.
Also das heisst, wir haben diesen praktisch Open-Source-Gedanken, dass wir Libraries zur Verfügung stellen, die dann von den Teams gewählt werden.
Auch wenn ein Self-Contained-System gestartet wird, gibt es ein Arket-Type, um das zu starten.
Und nicht jeder macht dann von Hand irgendwas, bis das Projekt da ist.
Und man kann die Duplikation schon reduzieren, wenn man sich das bemusst macht.
Also auch in den Teams oder teamsübergreifend eben.
Das ist Architekturarbeit, dass man Vorteile aufzeigt und Antworten holt und dann das versucht.
In dem Moment beschneidest du ein Stück weit die vermeintliche Freiheit in der Mikroarchitektur.
Ich glaube, meiner Meinung nach, ist das eine gute Entscheidung, die in gewissen Grenzen zu setzen für eine Mikroarchitektur.
Nur weil ich kann, heisst das noch lange nicht, dass ich diese Freiheit nutzen muss für das grosse Ganze, für die Effizienz.
Gesamtunternehmen, Projekt, Flexibilität zwischen Teams und so weiter.
Genau.
Wir haben auch ein Architektur-Board, wo wir ADRs definieren, die übergreifend gelten sollen.
Und wenn es eben anders sein muss, gibt es Ausnahmen.
Also ganz normaler Architektur.
Also ein Prozess an und für sich.
Genau.
Er oder Sie schreibt jetzt auch, die einzige Lösung, auf die ich kam, war mit grosser Verfahrenfrage, Dinge wie ein Designsystem einzuführen.
Da sind wir halt offensichtlich der Meinung, dass das eine gute Idee ist.
und abgespacede Lösungen zum Beispiel für Caching einzuführen.
Da bin ich mir nicht sicher.
Also was das bedeuten soll, ich würde halt behaupten, das ist eben ein Teil von Architekturarbeit im Bereich von Safe Content Systems.
Und sozusagen auf die Gefahr, mich unbeliebt zu machen, das ist halt ein Trade-off.
Inkonsistenzen und das hat sich ein bisschen schon angekündigt oder ist ja schon in der Diskussion so ein bisschen angeklungen.
Wenn ich halt Inkonsistenzen tatsächlich vermeiden will, dann müsste ich halt irgendwie die Freiheit der Teams signifikant beschneiden.
Und das geht manchmal nach hinten los.
Also ich kenne ein Beispiel, was ja auch gar nicht so abwegig ist, wo irgendwie die Aussage ist, ihr müsst halt alle irgendwie ein Framework benutzen.
Das ist halt in dem Legacy-System, ist halt ein Framework.
Das war damals die Architekturentscheidung.
Es gab ja auch diese Generation von Architektinnen, die halt irgendwie darauf geachtet haben, dass irgendwie ein einheitliches Framework gebaut und dann umgesetzt wird.
Und das ist halt in dem spezifischen Fall, natürlich führt das zur Konsistenz, weil alle halt das Framework benutzen und das ist technisch alles irgendwie dasselbe.
Und es hat halt andere dramatische Konsequenzen, weil dieses Framework halt technisch einfach schlecht ist.
Und das ist halt sozusagen das andere.
Ich glaube, die Aussage ist, es gibt hier eine gewisse Gefahr, es gibt einen starken Fokus auf eine Autonomie.
Und das, was hier beschrieben wird, ist, dass dieser starke Fokus auf die Autonomie eben sich in einen Nachteil verwandelt.
Da muss man halt aufpassen.
Das gilt aber, glaube ich, für jeden Architekturansatz.
Und da ist es dann die Aufgabe der Architektin, dafür zu sorgen, dass eben diese Nachteile eben ausgeglichen werden mit dem Designsystem.
Was er hier noch schreibt, oder siehe, im Backend sehe ich gegenüber Microservices überhaupt kein Vorteil von SCS.
Im Webfrontend würde ich, falls nötig, Microfrontends einführen.
und lange auf Monolithen setzen.
Naja, also es sagt ja, dass es kein Backend und Frontend gibt.
Und wenn man mit Monolithen sein Problem erschlägt, ist das für mich auch fein.
Ich habe Schwierigkeiten mir vorzustellen, dass in den Kontexten, in denen sich Silvia und Simon zumindest bewegen, der ja so durchklingt, also ist da Monolith eine Alternative?
Nein, viel zu groß.
Ja, also zu gross und zu unflexibel, würde ich behaupten.
Und Microservices und Microfrontends würden überhaupt nicht gut passen, weil wir dann eben wiederum eine Deployment-Abhängigkeit hätten.
Und das löst ja auch das Designproblem im Endeffekt nicht, das vorher angesprochen wurde.
Ich denke, der Charme von Self-Contained System ist primär der, dass eben der ganze vertikale Schnitt umgesetzt wird von einem Team und es eben keine Trennung gibt zwischen Backend und Frontend im Sinne von, wir machen verschiedene Teams, die dann unabhängig voneinander entwickeln.
Und auf der anderen Seite, wenn wir an KI-Entwicklung denken, ist das der richtige Schnitt, weil KI ein Fullstack-Entwickler ist sowieso.
Und da gibt es keine, dieses Rebirth-Conway-Manöver brauchen wir dort nicht zu machen, weil wir grundsätzlich sowieso alles implementieren können.
Und deshalb, ich habe einen Kunden, eine grosse Versicherung in der Schweiz, die haben Micro-Services und Micro-Frontends.
Und da kämpfen wir im Moment darum, wie können wir jetzt zum Beispiel speck-driven arbeiten, welche Microfrontend-Teile und welche Microservices gehören jetzt zu diesem Use Case, den wir im Moment gerade umsetzen wollen.
Das ist, denke ich, eine grosse Herausforderung in solchen Architekturen.
Und das hilft bei Self-Contained System, weil sich eben in dem Umfeld, in dem wir uns bewegen, eigentlich wie natürlich daherkommen.
Es gibt Trade-offs und Crowd-Zone, als Silvia mehrfach erwähnt.
Aber der Schnitt ist sehr natürlich eigentlich, wenn man drauf schaut.
Ich denke, so den klassischen Monolithen würde ich auch wenigen Firmen wirklich noch ans Herz legen.
Ich würde, wenn dann dort, wo ich wirklich als kleines Team starten möchte oder starten muss, weil ich ein Startup bin, würde ich vielleicht so beginnen.
Und selbst dann würde ich relativ...
Bald, wenn klar ist, wo das Geschäftsmodell hinfährt, gucken, dass ich zumindest in eine Modularisierung innerhalb dieses Monolithen investiere und gucke, dass ich quasi Sollbruchstellen habe, wenn ich irgendwann zum Scale-Up werde, dass ich sagen kann, dieser Teil geht an ein Team, dieser Teil geht an ein anderes Team.
Das lässt sich mit ein bisschen strategischem Architektur...
Voraussicht lässt sich das relativ gut gestalten, dass man so einen Monolithen strukturiert aufbaut und splitbar macht in verschiedene Self-Contained-Systems, Microservices, was auch immer man da anstrebt.
Ich würde mir wünschen, dass wir in einer Realität leben würden, in der es klar ist, dass man Monolithen modularisieren will.
Also du gehst noch ein bisschen weiter und sagst, dass es Säubruchstellen geben soll, aber ich finde halt immer diese Geschichte mit den modularen Monolithen halt schwierig, weil Also wer halt ernsthaft sagt, wir wollen Monolithen nicht modularisieren, okay, das bedeutet halt die Abwesenheit von Software-Architektur.
So ein bisschen als Abschlussfrage, wir sind ein bisschen über die Zeit.
Das Interessante bei dieser Episode ist eben tatsächlich, dass Self-Contained Systems die Webseite zehn Jahre alt ist.
Der Artikel von Philipp und Stefan ist sogar 15 Jahre alt.
Sprechen wir also in zehn Jahren noch über Self-Contained Systems.
Zehn Jahre ist vielleicht mit Kai.
Zeitrechnung ein wenig lange.
Aber ich würde sagen, ja, weil ich es bereits erwähnt habe, für KI finde ich Self-Content-Systems der optimale Schnitt, weil nicht nur für den Menschen der Kontext geschnitten wird und eine gewisse Grenze darstellt, sondern auch für KI.
Also das heisst, eigentlich passt das super gut.
Das ist auch ein Teil meiner Vorträge, deshalb habe ich eine schöne Überleitung bei meinen Vorträgen von Self-Content-Systems zu KI-getriebener Softwareentwicklung.
Und deshalb denke ich, das hilft.
Ich denke, kleine Applikationen auch in Bezug auf Modernisierung sind viel besser.
Ich mache Modernisierungsprojekte und einen Monolithen zu modernisieren dauert vielleicht drei bis fünf Jahre oder länger, je nachdem.
Und wenn wir jetzt Self-Contained Systems modernisieren würden, wären wir natürlich viel schneller, weil wir nur einzelne Teile der Applikation austauschen müssten.
Also das hat definitiv auch auf die Nachhaltigkeit einer Software.
Architektur einen großen Einfluss.
Ich sehe es relativ ähnlich.
Die Probleme, die damit adressiert werden mit der Architektur, sind einfach Probleme, die genauso alt sind wie Software-Systeme selbst.
Also Sachen werden zu groß, Sachen werden zu komplex und ich möchte sie irgendwie so zerteilen in verschiedene Teilsysteme, dass sie halt relativ unabhängig voneinander sind.
Also wir sind am Kern der Software-Architektur, der Software-Modularisierung dran.
Und Self-Contained Systems ist für mich eine Sammlung von Good Practices, die sich bewährt haben in den Szenarien, die ich vorhin schon genannt habe.
Also komplexe Fachlichkeit, verschiedene Teams, die daran arbeiten möchten.
Und solange wir diese Szenarien haben, denke ich, wird da irgendwas drin sein, was wir rausziehen können, was uns die Arbeit vielleicht in irgendeiner Weise vereinfachen wird.
Ich hätte so eine Mischung aus beiden.
KI wird vielleicht das Web verändern.
Also ob unsere UX noch in zehn Jahren genauso aussieht, das traue ich mich jetzt nicht zu sagen.
Aber der Grundgedanke dahinter, fachlich sinnvolle Systeme, die resilient laufen, ich glaube, die wird es auch in zehn Jahren noch benötigen, die Aspekte davon auf jeden Fall.
Wie die dann integriert vielleicht werden, was sich da noch verändert, da lassen wir uns überraschen.
Und für die Entwicklung mit KI sind die eben durch diese Abgeschlossenheit, diese Unabhängigkeit, habe ich auch da.
viel kleineren Blastradius.
Das heißt, das ist, glaube ich, weiterhin ein guter Ansatz, auch für die nächsten zehn Jahre.
Ja, also ich habe dem wenig hinzuzufügen.
Ich glaube, Modularisierung ist für AI sicherlich auch ein sehr wichtiges Thema und das ist zweifellos so.
Und daher ist das, glaube ich, sehr klar.
Also wir wollen halt einfach schauen, dass wir Systeme bauen können aus kleinem Anteil.
Dann würde ich sagen, Vielen Dank, dass ihr da wart und eure Erfahrungen, Ideen und Meinungen ausgetauscht habt.
Ich fand es sehr spannend und interessant und hilfreich und ich wünsche schon mal ein schönes Wochenende und vielleicht sehen wir uns auf einer Konferenz oder so.
Bis dahin.
Tschüss.
Tschau.
Tschüss.
Join us on-site.
You'll find more about the program and special discount code for our community on our website software-architecture.tv