Vor ein paar Jahren wurde ich von einem unserer Kunden gebeten, ihm dabei zu helfen, seine Integrationsschicht besser zu nutzen. Seitdem haben mein Team und ich an einem Framework gearbeitet, das dies unterstützt. Dies ist der dritte Teil einer Reihe von Blogs über die Entwicklung unseres Frameworks und über die Herausforderungen, die wir zu bewältigen hatten.
Im letzten Blog dieser Serie habe ich die Ziele erwähnt, die wir erreichen mussten. Um das zu erreichen, mussten wir natürlich eine Menge Herausforderungen meistern. Damit dieser Blog nicht den Umfang eines der Bücher der 'Herr der Ringe'-Trilogie erreicht, beschränke ich mich auf die folgenden fünf, die zusammen ein ziemlich gutes Bild dessen ergeben, was wir zu bewältigen hatten.
Herausforderungen
1. Widerstand in der Organisation
Es gibt etwas, das eine Integrationsschicht mit SOA gemeinsam hat und einer der Gründe ist, warum beide so oft scheitern: Sobald Sie bekannt machen, was Sie tun wollen, beginnen die Leute, sich auf das zu versteifen, was sie denken, was Sie tun (im Gegensatz zu dem, was Sie tatsächlich tun). Außerdem müssen sie plötzlich bestimmte Regeln befolgen, um ihre Daten aus anderen Systemen zu erhalten, was für sie nur statisch ist. Außerdem ist in ihren Augen die Leistung immer ein Problem (auch wenn sie es nicht ist, ganz zu schweigen von der Tatsache, dass wir in diesem Bereich nie Probleme hatten). Das Schlimmste daran ist, dass Sie sich immer verteidigen müssen. Wenn zwei Systeme über die Integrationsebene miteinander kommunizieren und etwas schief geht, ist standardmäßig die Integrationsebene schuld (erschießen Sie den Boten!). Schuldig, bis die Unschuld bewiesen ist.Die Antwort liegt natürlich darin, die Leute immer auf dem Laufenden zu halten und sehr eng mit den Projektteams zusammenzuarbeiten (und bei Bedarf sogar für längere Zeit Teil eines solchen Teams zu werden, wie es die Scrum-Methodik vorsieht). Es ist hilfreich, wenn es architektonische Richtlinien gibt, wie die derzeitige, die die Verwendung der Integrationsschicht vorschreibt, wenn Dienste in anderen Domänen aufgerufen werden.
2. generische Funktionen generisch halten
Dies war besonders bei der Entwicklung des Großteils des Frameworks der Fall. Wir waren Teil eines großen Projekts, bei dem wir versuchten, zwei Systeme miteinander zu verknüpfen, die eigentlich nicht für diese Art von Aufgaben gedacht waren. Je näher der Abgabetermin rückte, desto größer wurde der Druck, ein paar Abkürzungen zu nehmen, um bestimmte Anforderungen zu erfüllen. Glücklicherweise hatten wir einen Projektleiter, der in der Lage war, das große Ganze im Auge zu behalten. Dennoch erinnere ich mich an Meetings mit viel Geschrei.
3. Umgang mit mangelndem SOA-Wissen
Wenn ich eines in den letzten Jahren herausgefunden habe, dann ist es, dass viele Leute keine Ahnung von SOA haben, aber trotzdem so tun, als ob sie es wüssten (oder noch schlimmer: davon überzeugt sind). Das hat es besonders schwer gemacht, einige der SOA-beeinflussten Entscheidungen zu verkaufen (wie die Verwendung bestimmter WS-*-Standards, und ja, sie funktionieren in unserem Fall, vielen Dank). Das schlimmste (oder beste, je nachdem, wie man es betrachtet) Beispiel war, als mir ein Softwareentwickler sagte, dass SOAP und Warteschlangen nicht zusammenpassen, wodurch ein Teil unseres Frameworks in seinen Augen hinfällig wurde. Das Einzige, was man in so einem Fall tun kann, ist natürlich, die Leute durch Präsentationen, Workshops, schriftliche Dokumentation und Diskussionen aufzuklären.
4. Der Umgang mit mangelnden Plattformkenntnissen
In der Zwischenzeit war auf der Implementierungsseite nicht alles gut. Wir hatten diese Appliance, die wir verwenden mussten und die viele Optionen bot, von denen wir tatsächlich profitieren konnten, aber nicht allzu viele Experten zur Verfügung hatte. Das bedeutete, dass wir uns wirklich die Hände schmutzig machen mussten und dass wir auch einige Anfängerfehler machen mussten, bevor wir die Dinge zum Laufen brachten. Zu diesem Zeitpunkt hatten wir es bereits geschafft, einige Leute zu verärgern, da wir in ihren Augen nicht liefern konnten. Erinnern Sie sich, was ich vorhin über Konzept und Umsetzung geschrieben habe? Das war der Punkt, an dem es weh tat.
5. Arbeiten ohne kanonisches Datenmodell
Das mag seltsam klingen, aber denken Sie einmal darüber nach: All diese verschiedenen Anwendungen in den unterschiedlichen Domänen, die versuchen, miteinander zu kommunizieren, aber ihre eigene Sprache sprechen. Die Integrationsschicht in der Mitte, die Nachrichten hin und her transformiert. Die Verträge für den Verbraucher und den Anbieter sind gerade so unterschiedlich, dass Sie in eine Versionierungshölle geraten, wenn Sie nicht vorsichtig sind. Plötzlich macht dieses Ziel der 'intrinsischen Interoperabilität' des Service-orientierten Computing, von dem alle coolen Kids reden, sehr viel Sinn.
Fazit
Wie bereits erwähnt, ist dies nur die Spitze des Eisbergs. Am Ende geht es nur darum, ob Sie liefern können, was wir glücklicherweise konnten. Und bis zu diesem Zeitpunkt war es hilfreich, eine Elefantenhaut zu haben.
Das war's für dieses Mal, im nächsten Beitrag geht es um die Bausteine des Frameworks.
