Grenzen der Abgrenzung

Eine Anwendung besteht oft aus einer Vielzahl von Systemen, die zusammenarbeiten müssen. Da gibt es z.B. eine Webanwendung, die Bestellungen entgegennimmt. Diese Information wird an ein Ordermanagementsystem übergeben, das wiederum die Information an ein ERP-System, ein Logistkiksystem und ein Kundenmanagementsystem weiterleitet. In komplexen Fällen kommen leicht ein Dutzend beteiligter Systeme zusammen.

Wenn sich Anforderungen ändern, hat das gewöhnlich Auswirkungen auf mehrere Systeme. Gewöhnlich werden die einzelnen Systeme unabhängig voneinander von verschiedenen Teams entwickelt und anschließend integriert. Jedes Team ist natürlich daran interessiert, seine Umgebung möglichst stabil zu halten, da nur so die Termine zu halten sind. Wie kann man sich möglichst gut mit Änderungen aus den umgebenden Systemen umgehen?

Eine umfassende Darstellung verschiedener Szenarien findet sich in dem Buch von Eric Evans "Domain Driven Design". Ich werde dies hier nicht wiederholen, sondern mich auf wenige Aspekte beschränken.

Politik

Der Ausmaß von Änderungen für ein System ist oft Verhandlungssache. Manchmal kann die Notwendigkeit in Frage gestellt werden. Oft geht es aber um verschiedene Lösungsmöglichkeiten, die sich dadurch unterscheiden, wie sehr die einzelnen Systeme betroffen sind. Das endet dann in einer Pokerpartie zwischen den Projektleitern. Die Karten werden dadurch bestimmt, wer mehr zu verlieren hat, wenn es bei der Integration zu Problemen kommt. Der Rest ist Bluff.

Technische Abgrenzung

Wie die meisten technischen Themen - mit Ausnahme des Baues eines Perpetuum Mobiles, d.h. einer risikofreien Energieversorgung - ist hier die Lösung verhältnismäßig einfach. Hier gibt es z.B. die Möglichkeit nach innen eine einheitliche technische Schnittstelle zu haben und nach außen hin flexibel zu sein, indem man einen Enterprise Service Bus einsetzt. Es gibt eine großes Angebot von Systemen, die gewöhnlich mit einer Vielzahl von fertigen Adaptern kommen.

Auch wenn man nicht ein solches Produkt einsetzt, so empfiehlt es sich immer, die technische Schnittstelle von der fachlichen zu entkoppeln. Man kann dann ein System so modular aufbauen, daß verschiedene technische Schnittstellen (z.B. SOAP über HTTP gegen Queueing System gegen Tuxedo ...) und verschiedene fachliche Schnittstellen einfach durch Konfiguration zusammengebracht werden können. Dies führt zu einer hohen Wiederverwendbarkeit der technischen Schnittstelle.

Unterschiedliche Sichten

Verschiedene Systeme benötigen unterschiedliche Sichten auf die Daten. So sind die Bedürfnisse an die Daten für ein Logistiksystem offensichtlich andere als für das System, daß die Rechnung stellt.

In vielen Fällen gibt es eine Menge von Daten, die z.B. im Ordermanagementsystem zusammengebracht wird, von der die Daten, die die übrigen Systeme benötigen. in Form von verschiedenen Untermengen abgeleitet werden können. Manchmal sind kompliziertere Abbildungen notwendig. Solange es aber möglich eine Abbildung zu finden, ist bewiesen, daß die Sichten der einzelnen System kompatibel sind.

Man kann sich die Arbeit vereinfachen, falls man genügend Einfluß auf die Entwicklung der einzelnen Systeme hat, indem man ein übergeordnetes Modell bildet. Jedes System beschränkt sich dann darauf, ausschließend Untermengen dieses übergeordneten Modells zu verwenden und bestenfalls einfache technische Transformationen durchzuführen. Dies bedeutet, daß dieses Modell dann die zentrale Instanz ist. Wenn Änderungen in der Gesamtanwendung erforderlich sind, müssen sie hier eingepflegt werden und jedes System muß entsprechend angepaßt werden, wenn es die entsprechenden Elemente übernommen hat.

Antikorruptionsschicht

Wenn es nicht möglich ist, alle Systeme an ein gemeinsames Modell anzupassen, z.B. weil ein Altsystem dabei ist, so kann man zumindestens verhindern, daß sich Konzepte aus dem einen System in das andere einschleichen. Das entsprechende Muster bezeichnet Evans als "Antikorruptionsschicht". Was man damit nicht verhindern kann, ist, daß fachliche Anforderungen der so abgeschotteten Systems erfüllt werden müssen. Das bedeutet dann, daß man nicht nur sein System anpassen muß, sondern auch die Antikorruptionsschicht.

Außerdem muß man bedenken, daß eine zusätzliche Schicht auch ein zusätzlicher Ort von Fehlern ist. Wenn man eine schlecht konstruierte, instabile Antikorruptionsschicht hat, kann es sein, daß sich die Probleme dadurch vergrößern, da das System jetzt nicht nur geändert werden muß, wenn von außen neue Anforderungen kommen, sondern auch dann, wenn Probleme in der Zwischenschicht entdeckt werden.

Während die Antikorruptionsschicht häufig das Leben deutlich vereinfacht, ist für eine gute Umsetzung auch Aufwand notwendig. Es sollte also überlegt werden, ob die Probleme, die damit gelöst werden können, so groß sind, daß sie das Risiko und den Aufwand wert sind.