SAP CPI vs. MuleSoft vs. Boomi vs. ….. neu betrachtet

Vergleiche werden uns jeden Tag und überall serviert. Kaum etwas kaufen wir, ohne zu vergleichen. Vergleiche wie Android vs iPhone, Xbox vs PS oder Pepsi vs Coke sind Dauerbrenner der Debatte. Erst gestern habe ich fast drei Stunden damit verbracht, die richtigen In-Ear-Kopfhörer mit Bluetooth 5, IPX7, USB-C und Noise Cancelling auszuwählen. Dank der Auswahl und damit auch der Vergleiche auf Amazon!

Es ist also alles andere als ungewöhnlich, SAP Cloud Platform Integration (ab hier CPI) mit den unzähligen anderen Middlewares da draußen zu vergleichen. Wir schreiben das Jahr 2020, und die Debatte ist wieder da.

• Ist CPI besser als MuleSoft oder umgekehrt?
• Ist CPI besser als Boomi oder umgekehrt?
• Ist Boomi besser als MuleSoft? Oder ist Informatica besser als alle zusammen?

Das „Best-of-Breed“-Unternehmen

Während das für Beraterinnen, Berater und Technikbegeisterte Anlass zur Debatte sein mag, haben Unternehmen und damit auch CIOs kaum den Luxus, diese Wahl zu treffen. Das gilt besonders für große Enterprise-Kunden oder überhaupt für jedes Unternehmen, das anorganisch gewachsen ist. Ihre Landschaft ist kein homogenes Blau, Orange, Rot oder was auch immer. Sie gleicht eher einem Regenbogen. Unterschiedliche Systeme, Cloud wie On-Premise, von unterschiedlichen Anbietern, die alle zusammenwirken, um den bestmöglichen Wert für das Business zu liefern: So sieht es in der Regel aus.

Für sie ist die Middleware, die mit einem Produkt kommt, etwa CPI bei SAP oder MuleSoft bei Salesforce, oft eine Erweiterung des Produkts selbst. ERP-Daten hole ich mir aus CPI, Vertriebsdaten aus Mule und so weiter. Diese Daten werden dann konsolidiert und über einen ESB (der ebenfalls MuleSoft sein kann), eine Message Queue oder ein ähnliches Konstrukt 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

Eine maßgeschneiderte Architektur für einen LE-Kunden, an der INTEGRTR beteiligt war.

Prozess- vs. Datenintegration

Prozess- vs. Datenintegration spielt ebenfalls eine große Rolle. Wenn eine Middleware eine aktive Rolle in der Prozessintegration spielt, zum Beispiel SuccessFactors nach S4HANA/HCM, wo der Hire-to-Pay-Prozess buchstäblich von CPI getragen wird, ergibt es keinen Sinn, sie einfach abzuschalten, nur weil an anderer Stelle in der Landschaft MuleSoft oder Talend im Einsatz ist. Wenn Sie umgekehrt Ihre SuccessFactors-Mitarbeiterdaten in ein Cloud-BW wie Amazon Redshift bringen (typische Datenintegration), ergibt es wenig Sinn, das über CPI zu tun. Die Frage ist hier nicht, ob CPI genutzt werden kann, um SF mit Redshift zu verbinden, das können Sie ganz sicher. Sollten Sie das in Ihrem konkreten Kontext tun, wenn es einen vorherrschenden, klar definierten, zentral gesteuerten Mechanismus zur Datenlieferung nach Redshift gibt, der etwa auf Talend oder Matillion läuft? Das ist die eigentliche Frage, und die Antwort lautet nein.

Skillsets der IT-Teams

Ein großer Teil der Entscheidungsfindung hängt auch mit den Skills der IT-Teams im Unternehmen zusammen. Nehmen wir an, ein Unternehmen war bislang überwiegend Mule-Kunde, und eine neue Middleware kommt hinzu, etwa SAP CPI zusammen mit SuccessFactors. Langfristige Wartung, Upgrades, Security-Flows und Monitoring (oft über voreingestellte APMs) wären dann Themen. In solchen Fällen ist es häufig sinnvoll, die Content-Pakete, die mit der neuen Middleware kommen, auf der vorherrschenden Middleware nachzubauen. Im vergangenen Jahr haben wir bei einem „Mule-lastigen“ Kunden genau das getan. Statt CPI zu nutzen, um Employee Central mit SAP HCM zu verbinden, haben wir einen Mule Flow gebaut.

Habe ich damit gerade dem widersprochen, was ich im vorherigen Punkt festgehalten habe? Ja. Und genau darauf will ich hinaus: Diese Entscheidungen sind kontextabhängig.

Punkt-zu-Punkt-Integrationen

Und schließlich: eingebaute Konnektoren und Content. Moderne Apps bringen ihre eigenen eingebauten Konnektoren mit, die relevante Daten direkt an der Quelle abgreifen. Möglich wird das durch die sichere Interoperabilität auf API-Ebene. Eine Identity-Lösung, für die sich ein Kunde entschied, machte die Integration über CPI oder anderweitig praktisch überflüssig, weil sie die Daten direkt aus SuccessFactors las. SF ermöglichte das mit seinen offenen, öffentlichen OData-APIs. Wäre das HR-System jedoch ein On-Premise-System tief hinter mehreren Firewall-Schichten, wäre das kaum möglich. Sehen Sie, da habe ich gerade den nächsten Vergleich angefangen, die Debatte Cloud vs. On-Premise. Oder etwa nicht?

Zum Schluss

Die Wahl der Middleware in einem Unternehmen ist rein kontextabhängig und weitgehend wertgetrieben. Am Ende dreht sich die Debatte immer um den Wert, den eine Middleware auf den Tisch bringt. Ich wage die These: Dieser Wert wird in erster Linie durch Content und Out-of-the-Box-Konnektivität geliefert; alles andere, einschließlich der technischen Reife einer Middleware und damit ihrer Entwicklerfreundlichkeit, kommt erst in zweiter Reihe.

Als Integrationsberaterinnen und -berater ist Vielseitigkeit der Schlüssel. Sie können Mule-Consultant sein. Sollte Sie das davon abhalten, auch CPI-Consultant oder Boomi-Consultant zu sein? Das überlasse ich Ihnen.