Warum das Integrationserbe in der Cloud wichtig ist

Ein JSON-Format für einen traditionellen, XML-basierten ESB zu verwenden, ist, als würde man aus einem Sack Seide ein Ei machen.

- Die Analogie von Loraine Lawson in Bezug auf den Artikel: Why Buses Don?t Fly in the Cloud: Überlegungen zu ESBs

Vor kurzem habe ich darüber geschrieben, warum der Legacy Enterprise Service Bus (ESB) in der Cloud nicht funktionieren wird. Loraine Lawson von IT BusinessEdge hat den Artikel gelesen und die Frage gestellt: Spielt das Integrationserbe in der Cloud eine Rolle? Wir bei SnapLogic sind der festen Überzeugung, dass das Erbe eine Rolle spielt, und haben unsere elastische Integrationsplattform von Grund auf neu aufgebaut, um schnell, mehrpunktfähig und modern zu sein. Hier erfahren Sie, warum wir glauben, dass die Herkunft von Integrationsprodukten wichtig ist:

1. Das Innovator?s Dilemma schafft große Hürden für herkömmliche Integrationsanbieter, die sich vollständig in diesen neuen Bereich von Social, Mobile, Analytics, Cloud und (Internet of) Things wagen, den wir SMACT nennen.
2. Versuche, auf ihren bisherigen Erfolgen aufzubauen, führen zu Experimenten und halbgaren Lösungen.

Sie wären überrascht, wie viele Produktmanager für On-Premise-Integration im Silicon Valley mehr Zeit damit verbringen, sich über die Bedrohung des Gewinns pro Aktie (EPS) Gedanken zu machen als über die Zukunft des ESB!

Schauen wir uns also die beiden Gründe an, warum das Integrationserbe wichtig ist.

Das Dilemma der Innovatoren Herausforderung
Die Worte von Clayton Christensen hallen heute in den Vorstandsetagen des Silicon Valley wider, da wir mit so vielen technologischen Innovationen und Umwälzungen auf den traditionellen Märkten konfrontiert sind. Es ist äußerst schwierig, das Modell der unbefristeten Lizenzierung von Softwarewartung aufzugeben. Die Umstellung auf ein Abonnement-Preismodell, ganz zu schweigen von den kulturellen Veränderungen, die Software as a Service (SaaS) erfordert, ist keine einfache Option. Selbst wenn die Führungskräfte des Unternehmens bereit sind, diese Umstellung vorzunehmen, wären die Aktionäre sehr unglücklich, wenn die Betriebsgewinnspanne von 30-40 % auf einen einstelligen Prozentsatz sinken würde. Wenn Sie in der Vorstandsetage eines Unternehmens mit On-Premise-Erbe, das in den Cloud-Markt einsteigen will, mitfiebern würden, wäre "Kannibalisierung" das meistgehörte Wort. Und selbst wenn der Vorstand und die Führungskräfte es verstehen, viel Glück dabei, den alten Produktteams zu sagen, dass ihr Baby nicht mehr schön ist, und dem Vertriebsteam, dass Sie einen Cloud-Service einführen werden, der nicht mehr den On-Premise-Bootsanker als Preisschild erfordert.

Halbgare 'hybride' Integrationslösungen
Ein weiterer Grund, warum sich Unternehmen, die Software vor Ort anbieten, schwer tun, sich von ihrem Erbe zu lösen, ist, dass sich die meisten bedeutenden technologischen Innovationen nicht so einfach wie der sprichwörtliche "Lippenstift auf dem Schwein" auftragen lassen, es sei denn, das neue Angebot wird von Grund auf neu entworfen und entwickelt, um den neuesten Marktanforderungen und -spezifikationen zu entsprechen. Nicht viele erfolgreiche Unternehmen haben den Appetit, eine komplette Neuplanung vorzunehmen, und zwar aus den im obigen Abschnitt "Das Dilemma des Innovators" genannten Gründen. Um eine Analogie zu ziehen: Es ist, als würde ein Autohersteller mit Verbrennungsmotor kosmetische Änderungen an seinem Auto mit Verbrennungsmotor vornehmen und erwarten, dass er mit einem hochmodernen Auto wie Tesla auf dem Markt für Elektroautos konkurrieren kann. Nissan musste sein Leaf-Auto von Grund auf neu bauen, um den Markt für Elektroautos zu bedienen, indem es ein völlig neues Getriebe, einen neuen Motor und eine neue Energieversorgung entwickelte.

Um auf die Besonderheiten des Integrationsmarktes zurückzukommen und zu verstehen, warum das Erbe der Anbieter wichtig ist, hier einige technische Gründe dafür:

1. Resilienz im Kontext der Integration ist die Fähigkeit von Integrationsabläufen, Änderungen und Variationen in Datenstrukturen zu verarbeiten, ohne zusammenzubrechen. Die meisten Legacy-Integrationsprodukte sind stark typisiert oder eng gekoppelt. Das bedeutet, dass die Plattform die genauen Spezifikationen der Daten kennen muss, die sie bei der Ausführung der Flows verarbeiten muss. Leider ist die SMACT-Welt nicht so konform, wie wir es gerne hätten. Änderungen an Schemata und Datenstrukturen sind an der Tagesordnung. Das Hinzufügen von Spalten zu Datenbanktabellen oder das versehentliche Hinzufügen zusätzlicher Datenfelder durch einen Partner in einem Dokument, das an Sie gesendet wird, sollte Ihre Integrationen und damit Ihr Unternehmen nicht in die Knie zwingen. Resilienz oder ein schwach typisiertes/locker gekoppeltes Paradigma ist nichts, was man nachträglich in ein Produkt einführen kann. Die Einführung von Resilienz ist ein ebenso komplexer Prozess wie der Austausch des Getriebes, der notwendig ist, um von einem Verbrennungsmotor auf ein Elektroauto umzusteigen. Die Plattform muss von der Entwurfsphase an nach solchen modernen Grundsätzen gestaltet werden. Das Erbe der Integration ist also wichtig.

2. Ältere Integrationsprodukte, die aus dem Bereich Extrahieren, Transformieren und Laden (ETL) stammen, wurden für relationale Datenanwendungen optimiert, z. B. für die Übertragung großer Datenmengen aus relationalen Datenquellen in relationale Data Warehouses. Diese Produkte wurden entwickelt, um Zeilen und Spalten zu lesen, mit ihnen zu arbeiten und Zeilen und Spalten zu schreiben. Diese Produkte haben heute Schwierigkeiten, wenn es um die Verarbeitung hierarchischer Daten geht. In ähnlicher Weise wurden die EAI-Tools (Enterprise Application Integration ) für nachrichtenorientierte Integrationen entwickelt, die hierarchische Daten verarbeiten können, aber für Echtzeit-Integrationen optimiert sind, um eine Nachricht nach der anderen so effizient wie möglich zu verarbeiten. Dieses Erbe abzuschütteln, um breitere Anwendungsfälle zu handhaben, ist keine leichte Aufgabe. Es ist, als würde man den Motor seines Autos auf Batteriebetrieb umstellen. Jeder, der schon einmal einen Motorschaden hatte, weiß, dass Mechaniker eher den Kauf eines brandneuen Autos empfehlen, als ihn zu ersetzen!

3. Und schließlich werden Integrationsprodukte, die vor Ort entwickelt werden, auch vor Ort entwickelt. Konfigurationen und Produktbibliotheken werden lokal auf jedem physischen Server angelegt. Diese lokalen Bestände müssen manuell gepflegt werden, wenn es um Produkt-Upgrades und Patch-Fixes geht. Die Verwaltung dieser lokalen Dateien, insbesondere in einer stark verteilten Umgebung, wird schnell zum Albtraum. Dies ist eine weitere dieser Altlasten, die nicht ohne eine komplette Neukonzeption des Produkts beseitigt werden können. Stellen Sie sich das Lifecycle-Management der Heritage-Plattform wie einen Ölwechsel vor, den Sie bei Ihrem Verbrennungsmotor häufig durchführen müssen. Wie die meisten Menschen müssen auch Sie als Besitzer eines Autos mit Verbrennungsmotor Ihren vollen Terminkalender unterbrechen und das Auto für kleinere und größere Ölwechsel in die Werkstatt bringen. Bei Teslas ist kein Ölwechsel erforderlich, und die gesamte Produktwartung ist softwaredefiniert. Alle Upgrades werden automatisch über das Mobilfunknetz auf das Auto heruntergeladen, und die Kunden haben keine Ausfallzeiten.

Zusammenfassend lässt sich sagen, dass das Erbe eher ein Nachteil in der sich schnell verändernden Welt der technologischen Innovation ist. Technologie-Paradigmenwechsel sind immer noch von großem Ausmaß und erfordern oft einen neuen Ansatz und eine Neugestaltung von Produkten und Technologien. In diesem Artikel haben wir eine Analogie zwischen historischen Integrationsplattformen und Verbrennungsmotoren sowie zwischen modernen Integrationsplattformen und Elektroautos wie den Teslas gezogen. Natürlich kann man immer zu Recht argumentieren, dass beide Autos Sie am Ende des Tages an Ihr Ziel bringen werden. Aber, wie man so schön sagt, nicht das Ziel, sondern die Qualität der Reise macht das Ziel lohnenswert. Und mit einer modernen Integrationsplattform als Service(iPaaS) ist Ihre Reise schneller, kostengünstiger und mit weniger erzwungenen Ausfallzeiten, was sie wirklich angenehm macht.

Nächste Schritte:

• Lesen Sie die Beiträge von Greg Benson über die SnapLogic-Architektur und Plattformdienste.
• Schauen Sie sich einige unserer Ressourcen an, um mehr über die SnapLogic Integration Cloud zu erfahren.