Podcast

Kopplung

Zwischen Abhängigkeit und Autonomie

Kopplung ist ein Balance-Akt: Zu viel Kopplung reduziert die Delivery-Geschwindigkeit und Wartbarkeit. Keine bis wenig Kopplung ist unrealistisch. In dieser Episode des INNOQ Podcasts diskutieren Sven Johann und Erik Wilde über diesen Balance-Akt, Arten der Kopplung, Hyrum's Law, API Design und das Bezos Mandate. Ein Gespräch über Kopplung als strategisches Designprinzip.
Listen to other episodes

Shownotes & Links

🎥 Hinweis: Diese Podcast-Folge ist auch als Video auf YouTube verfügbar.

Transkript

show / hide transcript

This transcript was generated automatically and has not been manually reviewed. It may therefore contain errors. The spoken word in the recording is always authoritative.

Sven Johann: Ja. Hallo und herzlich willkommen zu einer neuen Folge vom INNOQ Podcast. Heute mal wieder mit Erik Wilde. Erik, wie geht’s dir?

Erik Wilde: Ja, hallo auch. Danke. Mir geht’s gut. Ich freue mich drauf, es macht immer Spaß, mit dir zu reden, und ich bin gespannt, was heute so dabei rauskommt.

Sven Johann: Heute haben wir tatsächlich mal ein Old-School-Thema. Normalerweise würde jeder erwarten, dass wir über LLMs oder so was reden. Thorsten meinte auch: „Erik ist im Podcast, da geht’s bestimmt um APIs.“ Und so ähnlich stimmt das auch. Wir reden heute nämlich über Kopplung im Software-Design. Bevor wir einsteigen – vielleicht kennt dich noch nicht jeder. Stell dich doch mal kurz vor.

Erik Wilde: Hallo, mein Name ist Erik Wilde. Ich bin seit gut einem Jahr bei INNOQ. Ich komme aus dem Bereich Kommunikationssysteme und habe mich lange mit APIs beschäftigt, daher wahrscheinlich der Kommentar. Ich bin so ein bisschen „Mister API“. Mich interessiert vor allem die Frage, wie man nicht nur gute Systeme, sondern gute Ökosysteme baut. Also, was sind die Qualitäten, auf die man in solchen größeren Strukturen achten muss. Ich habe mich lange mit Webtechnologien beschäftigt, auch in sehr großem Maßstab – und mich fasziniert, warum das Web so gut funktioniert. Mein Hintergrund ist eher konzeptionell: weniger System-Design, mehr eine Ebene darüber.

Sven Johann: Vielleicht klären wir mal die Begriffe. Warum ist Kopplung eigentlich so wichtig in der Softwareentwicklung?

Erik Wilde: Über Begriffe könnte man stundenlang reden. Ich habe mal ein Paper geschrieben – „Why is the Web Loosely Coupled?“ –, das ist tatsächlich eines meiner am meisten zitierten. Da haben wir 2009 analysiert, warum das Web so gut funktioniert. Im Grunde ist es ja auch ein verteiltes, serviceorientiertes System. Wir haben damals verschiedene Facetten herausgearbeitet, die erklären, warum das Web auch nach über 35 Jahren immer noch auf dem gleichen Grunddesign basiert – trotz vieler technischer Weiterentwicklungen. Es gibt keinen „Kopplungspapst“, der eine exakte Definition vorgibt. Deshalb muss man sich zunächst fragen: Warum diskutieren wir überhaupt über Kopplung? Welche Ziele verfolgen wir? Wo liegen die Probleme? Und worauf muss ich im Design achten, um Schwierigkeiten zu vermeiden.

Sven Johann: Wenn du von Zielen sprichst – was sind denn typische Ziele? Ich denke bei Kopplung vor allem an Architekturziele: Time-to-Market, Wartbarkeit, Erweiterbarkeit. Je mehr Kopplung ich zu anderen Teams habe, desto langsamer werde ich. Das spielt bei Systemarchitekturen oft eine große Rolle. Aber was sind auf deiner Ebene, in Ökosystemen, die Ziele?

Erik Wilde: Wenn ich von APIs spreche, dann meistens in größeren Unternehmenslandschaften. Da gibt es nicht nur ein System, sondern viele Systeme, die miteinander kommunizieren. Ziele sind dann: zu wissen, was es alles gibt, einfach kommunizieren zu können und dabei nicht zu enge Bindungen einzugehen. Keine Kopplung ist kein sinnvolles Ziel – ohne Kopplung passiert nichts. Die Kunst ist, Abhängigkeiten so zu gestalten, dass sie möglichst wenig einschränken. Zum Beispiel so, dass man ein System weiterentwickeln kann, ohne dass alle Konsumenten sofort nachziehen müssen. Man möchte möglichst viele Freiheiten behalten und trotzdem effizient zusammenarbeiten.

Sven Johann: Genau. Wir wollen lose Kopplung, keine enge. Denn enge Kopplung bedeutet, dass, wenn System A etwas ändert, System B sofort nachziehen muss.

Erik Wilde: Richtig. Und oft ist es ja nicht nur A und B, sondern A und 100 Konsumenten. Je komplexer das Abhängigkeitsnetzwerk wird – wie in großen Organisationen –, desto wichtiger wird es, Kopplungen bewusst zu gestalten, um nicht noch mehr Komplexität zu erzeugen.

Sven Johann: Ja, enge Kopplung ist nicht nur anstrengend, sondern auch teuer. Aber Kopplung an sich ist ja etwas Gutes, richtig?

Erik Wilde: Genau. In unserer Zeit ist Kopplung unvermeidlich. Die Frage ist also nicht „ob“, sondern „wie“.

Sven Johann: Welche Arten von Kopplung gibt es?

Erik Wilde: Grob gesagt gute und schlechte Kopplung. In unserem Paper haben wir z.B. Facetten wie Discovery untersucht: Wie finde ich Systeme? Auch die technische Kopplung ist entscheidend. Das Web war so erfolgreich, weil es keine enge Bindung an spezifische Plattformen hatte. Du konntest einen Browser auf Windows oder Unix nutzen – und es funktionierte. Ein weiterer Aspekt ist die Autonomie von Systemen: Können sie sich unabhängig weiterentwickeln? Viele denken bei Kopplung zuerst an diese technische Abhängigkeit: Man kann ein System nicht ändern, ohne ein anderes mitzuziehen. Das führt zu Koordinationsaufwand und macht große Systeme träge.

Sven Johann: Ja, das sehe ich genauso. Und diese Abhängigkeiten potenzieren sich, wenn viele Systeme involviert sind.

Erik Wilde: Absolut. Deshalb muss man Kopplung bewusst steuern.

Sven Johann: Spannend finde ich auch, dass man Kopplung oft als etwas Statisches betrachtet. Aber sie hängt auch vom Konsumenten ab – wie bei APIs mit Callback-Mechanismen.

Erik Wilde: Genau. Gute APIs erlauben Konsumenten, selbst zu entscheiden, wie eng sie gekoppelt sein wollen. Ein einfaches Request-Response ist oft genug. Aber wenn man mehr Kontrolle oder Feedback braucht, kann man z.B. Webhooks nutzen. Das erhöht zwar die Komplexität, gibt aber mehr Flexibilität.

Sven Johann: Das erinnert mich an PayPal-Integrationen – da sind Callbacks Pflicht. REST ist ja oft schlicht – aber genau das macht es so erfolgreich.

Erik Wilde: Ja, REST ist simpel, aber robust. Es funktioniert überall, und man kann es in jeder Sprache nutzen. Diese Einfachheit ist ein echter Vorteil.

Sven Johann: Und was ist mit Event-driven Architecture? Viele sagen, Messaging sorgt für lose Kopplung.

Erik Wilde: Es kommt darauf an. Nur weil du statt zwei Pfeilen einen hast, bedeutet das nicht automatisch weniger Kopplung. Event-driven Systeme bringen andere Herausforderungen: Wo laufen Messages, wie verwaltest du sie, was passiert bei Änderungen im Payload? Man muss die zusätzliche Komplexität bedenken. Asynchrone Kommunikation ist in manchen Szenarien perfekt, in anderen ist synchrone Kommunikation sinnvoller. Es gibt kein Schwarz-Weiß.

Sven Johann: Stimmt. Gerade in Versicherungen nutze ich Messaging, weil viele Services instabil sind. Aber der Umgang mit fehlenden Antworten oder Timeouts ist aufwändig.

Erik Wilde: Genau. Du verschiebst die Komplexität, löst sie aber nicht automatisch.

Sven Johann: Kommen wir mal zu Teams. Wie wirkt sich Kopplung auf Teams aus?

Erik Wilde: Das ist ein spannender Punkt. Conway’s Law besagt: Deine Software spiegelt die Kommunikationsstrukturen deiner Organisation wider. Wenn Teams sehr eng miteinander arbeiten müssen, spiegelt sich das in enger Kopplung der Systeme wider. Deshalb ist es oft besser, Schnittstellen klar zu definieren und Teams autonomer arbeiten zu lassen – auch wenn das mehr Aufwand bedeutet.

Sven Johann: Und wie siehst du das Bezos Mandate in diesem Zusammenhang?

Erik Wilde: Das Bezos Mandate – jede Funktion wird als API angeboten – kann helfen, Kopplung sauber zu gestalten. Aber es ist teuer und erfordert Disziplin, Tooling und organisatorische Unterstützung. Viele Unternehmen verkünden das Mandat, setzen es aber nicht wirklich um. APIs müssen gepflegt, dokumentiert und auffindbar sein. Ohne diese Infrastruktur bleibt es eine schöne Idee, die in der Praxis nicht greift.

Sven Johann: Ja, das sehe ich auch so. Ich glaube, viele unterschätzen den Aufwand dahinter.

Erik Wilde: Definitiv. Aber wenn man es ernsthaft umsetzt, gewinnt man langfristig enorm an Flexibilität.

Sven Johann: Spannend. Wir sind weit gekommen – von Kopplung bis zu Consumer-Driven Contracts und Teamstrukturen. Vielleicht machen wir mal eine eigene Folge zum Bezos Mandate.

Erik Wilde: Gerne. Ich habe übrigens auch ein Video dazu – wie zu fast allen Themen, die wir angesprochen haben.

Sven Johann: Perfekt. Dann danke ich dir für das Gespräch. Viel Erfolg nächste Woche beim API-Training!

Erik Wilde: Danke! Es macht immer Spaß, mit dir zu reden. Und wer weiß, nächstes Mal reden wir vielleicht über Conway’s Law oder wieder über APIs.

Sven Johann: Genau. Bis dann!

Erik Wilde: Ciao.

Senior Consultant

Sven Johann is Senior Consultant at INNOQ and has been involved in the modernization of medium and large Java applications for many years. He is an active participant in various workshops of the Software Engineering Institute (Managing Technical Debt) and the Leibnitz Zentrum für Informatik (Dagstuhl Seminar “Managing Technical Debt”). He is also Program Chair of GOTO Amsterdam and Show Host of Software Engineering Radio.

Principal Consultant

With over 10 years of experience in the API field, Erik is passionate about helping organizations on their digital transformation journeys, making sure that vision, strategy, and technology are aligned, and that they are driven by well-aligned business and organizational initiatives. As an OAI Ambassador at the OpenAPI Initiative, he promotes the adoption and use of open standards and best practices for API design and management, and with Getting APIs to Work, I provide consulting and training services for API programs.