Vergleiche werden uns jeden Tag und überall aufgetischt. Wir machen kaum einen Kauf, ohne zu vergleichen. Vergleiche wie Android vs. iPhone, Xbox vs. PS, Pepsi vs. Cola sind ein ständiger Anlass für Diskussionen. Erst gestern habe ich fast drei Stunden damit verbracht, mich für die richtigen In-Ear-Kopfhörer mit Bluetooth 5, IPX7-Beschwerde, USB-C und Noise Cancelling zu entscheiden. Höfliche Auswahl und daher Vergleich auf Amazon!
Es ist also ungewöhnlich, SAP Cloud Platform Integration (CPI) nicht mit einer Vielzahl anderer Middlewares zu vergleichen. Wir schreiben das Jahr 2020 und die Debatte ist wieder zurück.
- Ist CPI besser als MuleSoft oder andersherum?
- Ist CPI besser als Boomi oder vice versa?
- Ist Boomi besser als MuleSoft? Oder ist Informatica besser als sie alle?
Das "Best-of-breed"-Unternehmen
Während dies für Berater und Technologieliebhaber eine Frage der Diskussion sein könnte, haben Unternehmen und damit auch CIOs kaum den Luxus, diese Entscheidung zu treffen. Dies gilt insbesondere für große Unternehmenskunden oder für Unternehmen, die ein anorganisches Wachstum erlebt haben. Ihre Landschaft ist kein homogener Farbton von Blau, Orange oder Rot oder was auch immer. Sie ist eher wie ein Regenbogen. Verschiedene Systeme, sowohl in der Cloud als auch vor Ort, von verschiedenen Anbietern, die alle zusammenarbeiten, um den bestmöglichen Nutzen für ihr Unternehmen zu erzielen - das ist normalerweise der Fall.
Für sie ist die Middleware, die mit einem Produkt wie CPI mit SAP oder MuleSoft mit Salesforce einhergeht, oft eine Erweiterung des Produkts selbst. ERP-Daten - ich beziehe sie von CPI, Verkaufsdaten von Mule und so weiter. Diese Daten werden dann konsolidiert und über einen ESB (könnte auch MuleSoft sein), eine Nachrichtenwarteschlange oder eine ähnliche Einrichtung an andere Systeme geliefert.
Eine maßgeschneiderte Architektur für einen LE-Kunden, an der INTEGRTR beteiligt war - CPI ist nicht die einzige Middleware im Spiel
Prozess-/Datenintegration
Auch die Prozess- bzw. Datenintegration spielt eine große Rolle. Wenn eine Middleware eine aktive Rolle bei der Prozessintegration spielt, z. B. SuccessFactors zu S4HANA/HCM, wo der Prozess von der Einstellung bis zur Bezahlung buchstäblich durch CPI erleichtert wird, macht es keinen Sinn, sie einfach zu verwerfen, nur weil Mulesoft oder Talend an anderer Stelle in der Landschaft unterwegs sind. Wenn Sie Ihre SuccessFactors-Mitarbeiterdaten in eine Cloud-BW wie Amazon Redshift übertragen (typisch für die Datenintegration), macht es ebenfalls wenig Sinn, dies über CPI zu tun. Die Frage ist hier nicht, ob CPI verwendet werden kann, um SF mit Redshift zu verbinden - ich bin sicher, dass Sie das können. Sollten Sie das in Ihrem speziellen Kontext tun, in dem es einen herausragenden, gut definierten, zentral gesteuerten Mechanismus für die Datenbereitstellung an Redshift gibt, auch wenn er beispielsweise auf Talend oder Matillion läuft? Das ist die eigentliche Frage - die Antwort ist ein Nein.
Qualifikationen der IT-Teams
Ein großer Teil der Entscheidungsfindung hat auch mit den Fähigkeiten der IT-Teams in einem Unternehmen zu tun. Nehmen wir an, ein Unternehmen war bisher überwiegend Mule-Kunde und eine neue Middleware kommt auf den Markt - z. B. SAP CPI zusammen mit SuccessFactors - dann sind langfristige Wartung, Upgrades, Sicherheitsabläufe und Überwachung (oft über voreingestellte APMs) ein Problem. In solchen Fällen ist es oft ratsam, Content-Pakete, die mit der neuen Middleware geliefert werden, auf der vorherrschenden Middleware neu zu erstellen. Letztes Jahr haben wir genau dasselbe bei einem "Mule-lastigen" Kunden gemacht. Anstatt CPI zu verwenden, um Employee Central mit SAP HCM zu verbinden, haben wir ein Maultierfluss.
Habe ich damit gerade dem widersprochen, was ich im vorherigen Punkt festgestellt hatte? Ja. Das ist es, worauf ich hinaus will - diese Entscheidungen sind kontextabhängig.
Punkt-zu-Punkt-Integrationen
Und schließlich: integrierte Konnektoren/Inhalte. Neuzeitliche Anwendungen verfügen über ihre eigenen integrierten Anschlüsse, die relevante Daten direkt von der Quelle beziehen. Dies ist aufgrund der sicheren Interoperabilität auf API-Ebene möglich. Eine Identität Lösung, für die sich ein Kunde entschied, machte eine Integration über CPI oder auf andere Weise fast überflüssig, da sie Daten direkt aus SuccessFactors las. SF mit seinen offenen, öffentlichen OData-APIs ermöglichte diese Möglichkeit. Dies ist jedoch kaum möglich, wenn das HR-System ein On-Premise-System ist, das tief in Schichten von Firewalls liegt. Sehen Sie, ich habe soeben einen weiteren Vergleich gestartet, die Cloud vs. On-Premise-Debatte. Stimmt's?
Zum Schluss
Die Wahl der Middleware in einem Unternehmen ist rein kontextabhängig und weitgehend wertorientiert. Letztendlich dreht sich die Debatte immer um den Wert, den eine Middleware mit sich bringt. Um es vorwegzunehmen: Dieser Wert wird in erster Linie durch den Inhalt und die sofortige Konnektivität geliefert; alles andere, einschließlich der technischen Reife einer Middleware und damit ihrer Entwicklerfreundlichkeit, steht in der zweiten Reihe.
Als Integrationsberater ist Vielseitigkeit der Schlüssel. Sie können ein Mule-Berater sein; sollte Sie das davon abhalten, ein CPI-Berater oder ein Boomi-Berater zu sein? Das möchte ich Ihnen überlassen.
