Top 10 SOA-Fallstricke: #Nr. 10 - Das Syndrom "Not Invented Here

Bei Xebia sind wir an einer ganzen Reihe von SOA-Projekten ( Service Oriented Architecture ) beteiligt, von kleinen bis hin zu großen. In dieser Eigenschaft sehen wir eine Menge guter Dinge, aber wir sehen auch eine ganze Reihe von Projekten, die ins Stocken geraten oder gescheitert sind. Um unsere Erfahrungen mit diesen SOA-Projekten zu teilen, haben Gero Vermaas, Viktor Grgic, Rik de Groot und ich beschlossen, eine Reihe von Blogs über die ärgerlichsten Fallstricke von SOA zu schreiben. Jede Woche werden wir einen Punkt aus dieser Liste veröffentlichen. Auf diese Weise hoffen wir, das Bewusstsein für diese Gefahren zu schärfen und Ihnen eine Checkliste an die Hand zu geben, auf die Sie achten sollten. Wie immer bei solchen Listen sind sie natürlich nicht vollständig und nicht alle Probleme sind so absolut, wie der Titel vermuten lässt. YMMV! Der erste Punkt, den wir besprechen möchten, ist das Not Invented Here Syndrom (NIH). Natürlich ist dies etwas, das in mehreren Bereichen der IT zu beobachten ist, aber in einem SOA-Kontext trifft es tatsächlich auf zwei verschiedene Ebenen zu. Zunächst einmal besteht die Idee einer SOA darin, vorhandene Dienste wiederzuverwenden. Wenn Abteilung A einen Service get_personal_details erstellt, macht es wenig Sinn, wenn Abteilung B einen Service get_address erstellt. Vorausgesetzt, der get_personal_details-Dienst liefert die vollständige Adresse. Natürlich kann es mehrere Gründe geben, warum Abteilung B dies tut:

1. Sie wissen nichts über den Dienst get_personal_details. In diesem Fall gibt es keine richtige Service-Registrierung, ein Punkt, den wir später besprechen werden.
2. Die Art und Weise, wie sie ihre Anwendung entwerfen, veranlasst sie nicht, über Wiederverwendung nachzudenken. Das ist eines der Dinge, die bei der Anwendung von Big Design Up Front passieren können. Das werden wir auch in einem zukünftigen Blog besprechen (so wird die Spannung aufgebaut, nicht wahr? ;-) ).
3. Sie kennen den Dienst get_personal_details, möchten ihn aber nicht nutzen. Vielleicht wissen sie nicht, was er genau tut, vielleicht trauen sie Abteilung A nicht zu, dass sie es richtig macht oder richtig hält, oder vielleicht möchten sie lieber die volle Kontrolle über die Implementierung haben. In diesem Fall haben Sie es mit einem klassischen NIH zu tun. Dies ist der richtige Zeitpunkt, um über die Eigentumsrechte an den Diensten zu sprechen und sowohl Abteilung A als auch Abteilung B das Gefühl zu geben, die Kontrolle zu haben.

Diese Art von NIH ist zwar nicht sehr hübsch, aber sie lässt sich auf der Basis der einzelnen Dienste beheben, sobald das Bewusstsein dafür vorhanden ist. Die andere Art von NIH, mit der wir in einer SOA zu tun haben, ist die, bei der Sie am Ende Ihren eigenen Enterprise Service Bus (ESB) aufgebaut haben, eine Situation, die schwerer zu lösen ist. Wir haben zwei Möglichkeiten gesehen, wie dies geschehen konnte:

1. Anfang der 2000er Jahre entdeckten Unternehmen, die die nachrichtenbasierte Integration nutzen, den Bedarf an wiederverwendbaren generischen Diensten (z.B. Übersetzung, Routing, Transport usw.). Dies führte zur Entwicklung zahlreicher selbst entwickelter Messaging-Frameworks, die in der Regel auf einem Messaging-System wie MQ Series aufsetzen. Obwohl diese Frameworks damals einen Bedarf erfüllten, haben sie sich aufgrund ihrer Beschaffenheit mit vielen Unternehmensanwendungen verflochten und dadurch die Einführung eines ESB nach Industriestandard behindert.
2. Aber selbst jetzt schreiben die Leute ihre eigenen ESB-ähnlichen Dienste. Viele Architekten haben den Eindruck, dass ESBs von den Anbietern stark forciert werden und betrachten ESBs als nutzlose Systeme, auf die sie verzichten können. Das mit dem Drängen mag zwar stimmen ;-), aber eigene Übersetzungs-, Routing- und Transportdienste zu schreiben, halten wir nicht für eine sehr vernünftige Antwort. Sie bauen in der Tat Ihren eigenen ESB auf!

In beiden Fällen ist der Ausstieg aus dieser Situation mit viel Arbeit verbunden. Diese proprietären Systeme sind das Herzstück Ihrer Systeme, so dass ihre Abschaffung viel Zeit in Anspruch nehmen wird. Wenn Sie sich beispielsweise für den Kauf eines COTS ESB entscheiden würden, bräuchten Sie ein Migrationsszenario, bei dem Sie einen Dienst nach dem anderen von dem alten System auf den neuen ESB migrieren. Für diese Übergangszeit würden Sie eine Brücke zwischen dem alten und dem neuen System benötigen. Wir haben allerdings noch nicht erlebt, dass ein solches Migrationsszenario bis zum Ende funktioniert, da das alte System in der Regel noch in irgendeiner Ecke des Unternehmens verbleibt. Die Moral von der Geschicht: Bevor Sie anfangen, Ihre eigenen Dienste und Ihren eigenen ESB zu schreiben, sollten Sie sich ansehen, was bereits verfügbar ist. Ihr "temporärer" Dienst wird wahrscheinlich noch sehr lange existieren! Nächste Woche wird Rik de Groot mit Fallstrick #9 fortfahren.