Kohäsion, Kopplung, Komplexität

Letztes Update: 08.03.2024

In der IT-Architektur sind Kopplung, Kohäsion und daraus resultierende Komplexität wichtige Konzepte, die die Skalierbarkeit und Wartbarkeit von Anwendungslandschaften grundlegend beeinflussen. Falsch angewendet führen diese Konzepte zu überlangen Projektlaufzeiten und ständigen Fragen nach Verantwortlichkeiten. Richtig angewendet können sie eine schnelle, effiziente, wartbare und skalierbare Anwendungslandschaft schaffen, die jederzeit durch reibungslos laufende Projekte an sich ändernde Anforderungen angepasst werden kann.

Definitionen

Kohäsion

In der Unternehmensarchitektur bezieht sich Kohäsion auf die interne Struktur einer Anwendung und beschreibt, wie gut die Anwendung organisiert ist und wie gut ihre Komponenten zusammenarbeiten, um eine bestimmte Funktionalität bereitzustellen. Eine hohe Kohäsion bedeutet, dass die Anwendung gut strukturiert und abgegrenzt ist und somit ihre Aufgaben eigenständig mit möglichst wenigen Abhängigkeiten erfüllen kann. Eine geringe Kohäsion bedeutet, dass eine Anwendung mit vielen anderen Anwendungen kommunizieren muss, um notwendige Prozessschritte auszuführen.

Hohe Kohäsion in der Anwendung oben im Bild, niedrige in der unteren.

Kopplung

Kopplung bezieht sich im Kontext der Unternehmensarchitektur auf die Abhängigkeiten und Beziehungen zwischen verschiedenen Anwendungen. Hohe Kopplung bedeutet, dass Anwendungen eng miteinander verbunden sind und eine Änderung in einer Anwendung Auswirkungen auf andere Anwendungen hat. Eine geringe Kopplung bedeutet, dass die Anwendungen unabhängiger voneinander sind und eine Änderung in einer Anwendung wenig Auswirkungen auf eine andere hat.

Abnehmende Anwendungskopplung von oben nach unten

Komplexität

Komplexität ist ein Maß für die Anzahl der Beziehungen zwischen Anwendungen. Je mehr Beziehungen zwischen einzelnen Anwendungen bestehen oder bestehen können, desto komplexer ist das Gesamtsystem. Die folgende Abbildung zeigt, wie die Komplexität (K) mit der Anzahl der Entitäten (E) und deren Beziehungen zunimmt:

Zunehmende Komplexität

Allgemein kann die Komplexität nach folgender Formel berechnet werden (wobei n die Anzahl der Entitäten ist):

Berechnung der Komplexität

Bezogen auf die Anwendungslandschaft zeigt die folgende Abbildung eine Architektur mit hoher Komplexität. Die Kommunikationsbeziehungen zwischen den Anwendungen entwickeln sich weitgehend willkürlich und erreichen dadurch schnell einen hohen Komplexitätsgrad. Änderungen an einem solchen System werden mit jeder Iteration aufwändiger und langsamer.

Schlechte Architektur

Die Komplexität kann reduziert werden, indem Anwendungen nicht mehr von anderen Anwendungen abhängen, sondern von Geschäftsobjekten, die über Integrationssysteme vermittelt werden. Damit die Integrationssysteme selbst aber nicht zum Flaschenhals und Single Point of Failure werden, sollten sie Geschäftsobjekte nicht persistent speichern, sondern nur zwischen Anwendungen vermitteln.

Ziel

Das Ziel einer guten Unternehmensarchitektur ist ein ausgewogenes Verhältnis zwischen Kohäsion und Kopplung, um die Integrität, Wartbarkeit und Skalierbarkeit der Anwendungslandschaft zu gewährleisten. Höhere Kohäsion und geringere Kopplung tragen dazu bei, dass die Anwendungen und die Anwendungslandschaft leichter zu verstehen und zu warten sind und Projekte effizienter ablaufen. Dies sollte jedoch nicht ins Extrem getrieben werden: Maximale Kohäsion und minimale Kopplung schaffen einen Monolithen, der wiederum schwer zu warten ist. Geringe Kohäsion und hohe Kopplung hingegen können zu unstrukturierten und übermäßig komplexen Anwendungslandschaften führen. Die Folge sind hohe Wartungskosten und lange Projektlaufzeiten. Die Kunst besteht darin, die beiden Konzepte gegeneinander abzuwägen, um das Optimum mit der geringsten Komplexität zu finden.

Die Komplexität ist dann am niedrigsten, wenn Kohäsion und Kopplung ausgewogen sind

Konsequenzen

Eine IT-Landschaft, die die Prinzipien der Kohäsion, Kopplung und Komplexität nicht beachtet, wird unter anderem mit folgenden Problemen konfrontiert:

• Schwierigkeiten bei der Wartung: Eine komplexe IT-Landschaft ist schwer zu verstehen und zu warten, was bedeutet, dass es länger dauert, Fehler zu finden, neue Anwendungen hinzuzufügen oder bestehende Anwendungen zu ersetzen.

• Fehleranfälligkeit: Eine komplexe IT-Landschaft ist anfälliger für Fehler in den Geschäftsprozessen, da es schwieriger ist, alle möglichen Auswirkungen von Änderungen im System vorherzusehen.

• Längere Projektlaufzeiten: Projekte in komplexen IT-Landschaften benötigen mehr Zeit und Ressourcen, da es schwieriger ist, alle technischen und organisatorischen Abhängigkeiten im Blick zu behalten.

• Schwierigkeiten bei der Skalierbarkeit: Eine komplexe IT-Landschaft ist schwieriger zu skalieren, d.h. sie ist nicht in der Lage, den Anforderungen eines wachsenden Unternehmens oder einer wachsenden Nutzerbasis gerecht zu werden.

• Schwierigkeiten bei der Zusammenarbeit: Die Arbeit in einer komplexen Systemlandschaft ist für Teams aufwändiger, da es schwieriger ist, ein gemeinsames Verständnis des Gesamtsystems und seiner Funktionsweise zu entwickeln.

Um diese Probleme zu vermeiden, ist es wichtig, die Strukturen einer IT-Landschaft so einfach wie möglich zu halten, indem durch eine gute Integrationsstrategie die richtige Balance zwischen Kohäsion und Kopplung gefunden wird.

Maßnahmen

Auch ohne eine ausgefeilte strategische Integrationsarchitektur gibt es einige Maßnahmen, die eine Enterprise Architektur ergreifen kann, um die Komplexität der IT-Landschaft in den Griff zu bekommen:

• Verwendung expliziter, kontrollierter Schnittstellen: Die Schnittstellen zwischen den Anwendungen sollten durch Design by Contract definiert und durch eine von den Anwendungen unabhängige Governance gesteuert werden. Ergänzend können die Schnittstellen durch Monitoring-Systeme technisch und fachlich überwacht werden.

• Einsatz von Middleware zur Integration: Middleware-Systeme können zur Übertragung von Daten und Nachrichten zwischen Anwendungen eingesetzt werden und ermöglichen so eine lose Kopplung. Dabei ist auf die Skalierbarkeit der Middleware selbst zu achten. Die Middleware sollte möglichst zustandslos sein - wo das Architekturmuster REST anwendbar ist, sollte dieses bevorzugt werden. Andere Middleware muss für den Anwendungsfall geeignet sein (z.B.: Message Broker, IoT Middleware). Die Middleware sollte eine angemessene Rolle im Unternehmen spielen und selbst als Produkt mit expliziten Product Ownern (z.B. Enterprise Architekten) betrachtet werden.

• Einsatz von SOA oder MASA (Service Oriented Architecture, Meshed Application and Service Architecture): Die Verwendung von SOA- oder MASA-Prinzipien ermöglicht es, dass Anwendungen als voneinander unabhängig bereitgestellt werden können und über standardisierte Schnittstellen miteinander kommunizieren.

• Einsatz von ereignisgesteuerter Architektur (Event Driven Architecture, EDA): EDA ermöglicht es Anwendungen, auf Ereignisse zu reagieren, ohne direkt aufeinander abgestimmt zu sein.

• Einsatz von Containern und Microservices: Der Einsatz von Containern und Microservices ermöglicht es, Anwendungen als unabhängige, skalierbare Einheiten bereitzustellen, die über standardisierte Schnittstellen miteinander kommunizieren.

Durch die Umsetzung dieser Maßnahmen kann eine lose Kopplung von Anwendungen in einer IT-Landschaft erreicht werden, die es ermöglicht, Änderungen in einer Anwendung ohne tiefgreifende Auswirkungen auf andere durchzuführen und damit das Gesamtsystem leichter wartbar und skalierbar zu machen. Mit der Zeit werden Projekte, die in dieser Systemlandschaft entwickelt werden, ebenfalls schneller werden.

Fallstricke

Bei dem Versuch, die Komplexität einer Anwendungslandschaft zu reduzieren, können folgende Fehler gemacht werden:

• Integrationssysteme, die nichts abgrenzen: Auf keinen Fall sollte man willkürlich ein Integrationssystem in eine IT-Landschaft stellen. Es muss immer ein Konzept vorhanden sein, das deutlich macht, welche Teile einer IT-Landschaft durch eine Middleware abgegrenzt werden.

• Zu viele Integrationssysteme: Es gibt viele Anbieter von Middleware auf dem Markt und jede große Anwendungsplattform bevorzugt die eigene, die sie direkt mitbringt. Es bedarf einer starken IT-Governance, um nicht der Versuchung zu erliegen, zu viele Integrationssysteme in der Anwendungslandschaft zu haben. Man gewinnt nichts, wenn jeder kleine Datenaustausch über 3 Middlewares läuft.

• Integrationssysteme als persistenter Speicher: Ein Integrationssystem hat die Aufgabe, Nachrichten oder Geschäftsobjekte vom Sender zum Empfänger zu transportieren. Auch wenn es dabei Daten cachen kann, darf es keine Persistenzschicht sein. Wird ein Integrationssystem als Persistenz verwendet, erhöht es die Komplexität im Netzwerk: Einerseits sinkt die Kohäsion, da ein System für grundsätzlich verschiedene Zwecke (Nachrichtentransport vs. Persistenz) verwendet wird. Andererseits steigt die Kopplung, da die Anwendungen elementar auf die im persistenten Integrationssystem gespeicherten Daten angewiesen sind. Ein System mit Persistenz ist kein Integrationssystem. Und ein Integrationssystem hat keine Persistenz.

• Fehlende Governance: Die Komplexität der Integration einer Anwendungslandschaft wird nur beherrschbar, wenn sie explizit gesteuert wird. Idealerweise wird sie im Sinne des agilen Arbeitens als eigenständiges Produkt betrachtet. Wird die Integration nicht gesteuert, entsteht ein Wildwuchs an Schnittstellen mit unterschiedlichen Technologien und Abstraktionsebenen, was wiederum die Komplexität des Gesamtsystems erhöht.

• Conway’s Law: Wenn Strukturen in einer Unternehmenslandschaft geschaffen werden, sollten entweder die organisatorischen Strukturen im Unternehmen folgen oder die technischen Strukturen sollten sich an den organisatorischen Strukturen orientieren. Geschieht beides nicht, sind Missverständnisse und immer wiederkehrende Fragen nach Zuständigkeiten und Verantwortlichkeiten an der Tagesordnung.

Fazit

Es klingt zunächst sehr abstrakt, sich mit den Prinzipien Kohäsion, Kopplung und Komplexität zu beschäftigen. Wenn man aber gute und schlechte Anwendungslandschaften gesehen hat, die diesen Prinzipien entsprechen, dann erkennt man die ganz praktischen Auswirkungen sehr deutlich: In Anwendungslandschaften, die diese Prinzipien berücksichtigen, sind Anwendungen gut und kostengünstig wartbar und schnell austauschbar. Außerdem laufen Projekte in solchen Umgebungen schnell und problemlos. Diese zunächst akademisch und abstrakt klingenden Prinzipien haben also sehr schnell sehr konkrete Auswirkungen auf die Finanzen eines Unternehmens. Ihre Bedeutung kann daher nicht hoch genug eingeschätzt werden!