Lexikon

Cloud-basierte Integration

Einleitung

Analysten der Synergy Group schätzen, dass der Markt für Cloud-Computing allein im Jahr 2015 weltweit um 28% auf insgesamt 110 Milliarden USD gewachsen ist und weiter wächst (Synergy 2016). Besonders stark wachsen „Public Cloud“ -Angebote [Zur Unterscheidung zwischen Public-, Private- und Hybrid-Cloud vgl. NIST (2011)], bei denen ein Anbieter Dienstleistungen öffentlich für verschiedene Nutzer über das Internet anbietet. Zu diesen Leistungen zählen Infrastructure as a Service, Platform as a Service (z. B. Amazon Web Services, Internet of Things-Plattformen) und Software as a Service (z. B. Salesforce CRM, Microsoft Office 365). Aufgrund der zunehmenden Nutzung dieser Cloud-Dienstleistung wachsen die IT-Landschaften vieler Unternehmen «ausserhalb» der eigenen Unternehmensgrenzen. Dieses Wachstum wird noch zusätzlich durch die steigende Zahl von unternehmensbezogenen Anwendungen auf mobilen Geräten wie Smartwatches und in „physischen Dingen“ wie im Auto gefördert.  Oft ist der Informationsaustausch zwischen den Cloud-basierten Anwendungen untereinander erforderlich. So kommuniziert etwa die Fitness-Tracker App auf der Smartwatch mit einem zentralen Server, damit Aktivitätsdaten vom Benutzer auch am Computer zu Hause eingesehen werden können. Aber auch Cloud-Anwendungen und lokale („On-Premise“) Anwendungen (z.B. Backend-Systeme) kommunizieren häufig. So kann z.B. das Cloud-basierte Customer Relationship Management (CRM) Kontaktdaten von Kunden speichern, die ebenfalls im lokalen Buchhaltungssystem zur Abrechnung benötigt werden. In vielen Fällen stellt sich daher die Frage, wie die beteiligten Anwendungen vernetzt werden können. Klassische On-Premise Integrationstools sind allerdings oftmals komplex und teuer. Eine Alternative stellen Cloud-basierte Integrationstools dar, die oftmals einfacher zu bedienen, flexibler in der Nutzung und kostengünstiger sind (Ebert und Weber 2015). Aber auch wenn verschiedene Unternehmen miteinander Informationen austauschen, kann die Integration in der Cloud vorteilhaft sein. In der Luftfahrtbranche stand die Oneworld Alliance (American Airlines, British Airways, Air Berlin, etc.) vor der Herausforderung die Frequent Flyer-Systeme von 14 Mitgliedsgesellschaften zu integrieren. Passagiere sollten bei einer beliebigen Gesellschaft Meilen sammeln und bei einer anderen einlösen können. Da die direkten Verbindungen jedes Systems mit jedem anderen sehr aufwändig und wartungsanfällig waren, entschloss sich die Allianz einen zentralen Cloud-basierten „Integrationshub“ zu etablieren. Dieser konnte bequem als Dienstleistung bezogen werden (Oneworld 2012). Abbildung 1 zeigt drei verschiedene Cloud-basierte Integrationsalternativen für die Integration von Anwendungen, die nachfolgend beschrieben werden.

Direkte Kopplung

Eine direkte Kopplung mittels Application Programming Interface (API) setzt auf der Schicht der Daten und Funktionalität der beteiligen Anwendungen an. Innerhalb eines CRM-Systems kann z.B. über eine API die Adresse eines Kunden abgerufen und mit einem Zielsystem synchronisiert werden. Oder es kann automatisch eine neue Kundenanfrage im CRM-System angelegt werden, nachdem ein Außendienstmitarbeiter eine Anfrage mit einer Smartphone-App erfasst hat. 

Wenn eine Anwendung über ein öffentliches API verfügt, kann sie über das Internet aufgerufen werden. Die Website www.programmableweb.com listet aktuell über 16.600 verschiedene öffentliche APIs von Google Maps, über den Speicherdienst Dropbox und smarte Personenwaagen, bis zu Geschäftsanwendungen wie dem Enterprise Resource Planning (ERP) - System von Netsuite auf. Oftmals werden diese APIs zustandslos per REST [Representational State Transfer bezeichnet ein Programmierparadigma für verteilte Systeme, insbesondere für Webservices.] angesprochen. Auch interne Unternehmensanwendungen können via API über das Internet zugänglich gemacht werden. Diesen Prozess unterstützen Cloud-basierte API-Management-Systeme wie beispielsweise ApiUmbrella.io, welche Entwicklung, Veröffentlichung, Monitoring und Verrechnung der Schnittstellen unterstützen (Weisbecker u. a. 2014).

Eine Schwierigkeit der direkten Kopplung zweier Anwendungen über eine API ist, dass eine „führende“ Anwendung in der Lage sein muss, die API der anderen An-wendung „aktiv“ aufzurufen. Beispielsweise bietet Salesforce CRM die Möglichkeit, in bestimmten Geschäftsvorfällen die APIs anderer Anwendungen aufzurufen und die so erhaltenen Daten selbst weiterzuverarbeiten. Viele andere Software as a Service-Anwendungen bieten jedoch keine Möglichkeit selbst „aktiv" die APIs anderer Anwendungen aufzurufen, sondern stellen lediglich aufrufbare APIs bereit. Zusätzlich sind die „aktiven“ Aufrufmöglichkeiten vom Hersteller auf bestimmte Geschäftsvorfälle und Datenobjekte begrenzt. Bei der direkten Kopplung entsteht zudem eine hohe Komplexität, falls viele Anwendungen miteinander vernetzt werden. Wenn, wie im Beispiel von Oneworld, jede Anwendung mit jeder verbunden ist, steigt die Anzahl bidirektionaler Schnittstellen bei n Anwendungen auf    an. Nach der ursprünglichen Entwicklung müssen diese Schnittstellen dann später auch gewartet und getestet werden, da eine Änderung an einer Schnittstelle direkte Auswirkungen auf die verbundenen Anwendungen hat.

Integration Platform as a Service

Eine weitere Möglichkeit zur Cloud-Integration ist die Nutzung von „Integration Plat-form as a Service“ (IPaaS). IPaaS verbinden die Vorteile von Cloud-basierten Lösungen (z.B. geringe Kapitalbindung, hohe Flexibilität, reduzierter Bedarf an spezifischem IT-Know-how) mit den Vorteilen von Enterprise Application Integration (EAI)-Plattformen (z.B. reduzierte Anzahl Schnittstellen, standardisierte Anwendungsadapter). Wie bei der direkten Kopplung von Anwendungen setzt IPaaS bei der Daten- und Funktionsintegration an, wobei jedoch die Kopplung der Anwendungen über einen zentralen „Hub“ in der Cloud erfolgt. Weil jede Anwendung lediglich mit dem Hub verbunden werden muss, wird die Gesamtanzahl der erforderlichen Schnittstellen gegenüber dem Ansatz der direkten Kopplung reduziert. Das Schweizer Pharmaunternehmen Novartis ist ein prominentes Beispiel für die Verwendung einer Cloud-basierten Integrationslösung (Ovum 2013).IPaaS bieten einfache bis komplexe Standard-Anwendungsadapter (z.B. Google Mail, SAP ERP). Zur Abbildung der Integrationslogik zwischen den Anwendungen können einerseits Abbildungsregeln grafisch zwischen Datenobjekten („Datamap-ping“) definiert werden. Zum anderen existieren zahlreiche Operatoren zur Modellierung des Datenflusses zwischen den Anwendungen (z.B. Verzweigungen, Fehlerbehandlung) (Ebert und Weber 2015). Die Ausführung der Integrationslogik wird entweder durch einen Aufruf von außen (z.B. „Neuer Kunde im Quellsystem erfasst“) oder ereignisgesteuert (z.B. „Alle zwei Stunden“) gestartet. Abbildung 2 zeigt beispielhaft die Integrationslogik zwischen einem Salesforce CRM-System und einer lokalen Datenbank in Dell Boomi. Dabei wird zu Beginn ein Kundenkontakt durch einen Salesforce-Adapter ausgelesen. Wenn der Kontakt in der lokalen Datenbank bereits existiert, erfolgt lediglich ein Update. Falls der Kontakt jedoch noch nicht existiert, wird ein neuer Datenbankeintrag angelegt und eine E-Mail an den Datenbankadministrator gesendet. 

Im Gegensatz zu klassischen On-Premise EAI-Plattformen sind die IPaaS oftmals einfacher zu bedienen, leichter skalierbar und der Prozess von der Entwicklung der Integrationslogik bis zur produktiven Ausführung in einer dedizierten Laufzeitumge-bung wird verkürzt. Verschiedene IPaaS bieten neben Standard-Anwendungsadaptern auch bereits vordefinierte Integrationslogik und Datenmap-pings für häufig auftretende Integrationsszenarien an oder schlagen, auf Basis der Mappings anderer Nutzer, automatisch mögliche Mappings zwischen Anwendungen vor (Ebert und Weber 2015).

Business Process Management Platform as a Service

Wie bei einer IPaaS handelt es sich bei einer Business Process Management Plat-form as a Service (BPM PaaS) um eine zentrale Integrationsplattform in der Cloud, die als Dienstleistung genutzt werden kann. Zwei Beispiele für Anbieter sind Run-MyProcess und Kissflow.

Im Gegensatz zur direkten Kopplung oder einem IPaaS ermöglicht ein BPM PaaS nicht nur die Integration auf Daten- und Funktionsebene, sondern auch auf Ebene der Benutzeroberfläche. Die Modellierung der Integrationslogik erfolgt mit Geschäftsprozessmodellen z.B. entsprechend der Business Process Model and Notation (BPMN). Neben Aufrufen zu anderen Anwendungen können auch manuelle Schritte modelliert werden, die die Interaktion mit dem Anwender erfordern. Zu diesem Zweck bieten die Plattformen Werkzeuge für die Erstellung von web-basierten Anwenderformularen (z.B. Aufgabenlisten, einfache Eingabemasken) und Funktionalitäten zur Rollen- und Rechteverwaltung. 

So kann beispielsweise mittels eines BPM PaaS in einer Website ein Webformular gestaltet werden, mit dem Kunden Serviceanfragen an den Kundendienst erfassen können. Anschliessend kann ein Mitarbeiter die Anfrage über ein weiteres Webformular des BPM PaaS vorqualifizieren und einer zuständigen Serviceabteilung zuweisen, bevor die Anfrage durch das BPM PaaS automatisch in das CRM-System der Serviceabteilung übertragen wird. Abbildung 3 zeigt beispielhaft die Benutzeroberfläche des BPM PaaS RunMyProcess. 
 

Fazit

In vielen Unternehmen ist die Integration von Cloud-Anwendungen eine wichtige Fragestellung, auch wenn sich dies den Endbenutzern (Kunden, Mitarbeiter in den Fachabteilungen, etc.) oft nicht erschliesst. Die direkte Kopplung von Anwendungen stösst dabei allerdings sehr schnell an Grenzen. Als Alternativen bieten sich die genannten Cloud-Plattformen an. Deren Markt ist allerdings aktuell noch sehr jung und fragmentiert (vgl. z.B. Guttridge u. a. 2016). 

Generell stellt sich bei der Nutzung einer Plattform die Frage nach dem Vertrauen in den Dienstleister. Bei einer Integrationsplattform handelt es sich zudem um einen kritischen Infrastrukturbaustein, dessen Ausfall gravierende Konsequenzen für die Geschäftsprozesse und der davon betroffenen Nutzer haben kann. Viele Anbieter stellen daher mehrere Hosting-Standorte zur Wahl, von denen der Anwender dann einen geographisch günstigen Standort auswählen kann. Damit werden die Auswirkungen von potentielle Systemausfällen oder Engpässen bei der Datenübertragung über das Internet reduziert. Zudem befinden sich die Plattformen oftmals auf Cloud-Infrastrukturen von etablierten Anbietern (z.B. Amazon Web Services), um die Wahrscheinlichkeit eines Ausfalls oder Datenverlustes zu reduzieren. 
 
Neben technischen Herausforderungen stellt sich auch die Frage nach dem Schutz und der Sicherheit der verarbeiteten Daten – insbesondere, wenn unternehmensinterne Daten über das Internet transferiert und mit dem Plattformbetreiber geteilt werden. Viele Betreiber stammen aus den USA und informieren nur minimal über ihr Datenschutzniveau (Ebert und Weber 2016). Aktuell ist in diesem Fall davon abzuraten, die US-Plattformen zur Integration von unternehmenskritischen oder personenbezogenen Daten zu nutzen. Anders gestaltet sich der Fall jedoch, wenn gar keine Anwendungsdaten in der Cloud verarbeitet werden: einige Plattformen ermöglichen die Ausführung der Integrationslogik in einer lokalen Laufzeitumgebung, so dass keine Bewegungsdaten mit dem Plattformbetreiber geteilt werden müssen. Zusätzlich gibt es auch Plattformbetreiber aus Deutschland wie elastic.io , der eine Cloud-Infrastruktur der Telekom Tochtergesellschaft T-Systems nutzt und sich an deut-sches und europäisches Recht hält. 

Mittlerweile gibt es auch im deutschsprachigen Raum viele Unternehmen, die An-wendungen in der Cloud nutzen. Einige davon nutzen zur Integration Cloud-basierte Integrationsplattformen. Diese Entwicklung steckt derzeit aber noch in den Kinderschuhen. Mit der zunehmenden Verbreitung von Anwendungen ausserhalb der lokalen IT-Landschaft wird in Unternehmen jedoch der Druck zur Anwendungsintegration zunehmen. Gleichzeitig ist anzunehmen, dass das Angebot an Integrationsplattformen, die betriebswirtschaftlichen, technischen und rechtlichen Anforderungen genügen, weiter zunehmen wird. 

Literatur

Autoren und Copyright

Nico  Ebert und Ueli  Schlatter
Institut  für Wirtschaftsinformatik,
Zürcher  Hochschule  für Angewandte  Wissenschaften,
Winterthur,  Schweiz
E-Mail


© Springer-Verlag  Berlin  Heidelberg  2017