Die Vielzahl unterschiedlicher Software-as-a-Service Applikationen und weiterer Cloud-Services nimmt stetig zu. Das führt neben einem schwierigen Überblick ebenfalls zu einer höheren Komplexität. Ein Trend sind Cloud Marketplaces, die einen Katalog verschiedener Services kategorisieren und damit ein Gesamtportfolio ergeben. Was diesen Marketplaces derzeit jedoch noch fehlt, ist die Integration der vorhanden Services und Applikationen. Das führt dazu, dass nicht auf einer gemeinsamen Datenbasis gearbeitet wird und wie aus vielen on-Premise Infrastrukturen bekannt, Daten- und Applikationssilos entstehen.
Stand der Dinge
Die Problematik der Cloud Datensilos besteht nicht nur in den Cloud Marketplaces. So werden auch Integrationsmöglichkeiten von z.B. einer CRM SaaS Lösung mit einer Office Suite beworben. In der Praxis ist die Umsetzung jedoch eher bescheiden gelöst. Irgendwie sind die Systeme zwar verbunden. Im Endeffekt arbeitet man aber auf unterschiedlichen Systemen, auf getrennten Daten und muss sich auch bei beiden separat anmelden.
Es fehlt der Cloud derzeit also die Integration unterschiedlicher und voneinander unabhängiger Services für die Arbeit auf einer gemeinsamen Datenbasis.
Integration ist zwingend erforderlich
Spricht man von Integration meint man Schnittstellen und Daten. Ich hatte vor längerer Zeit mal angedeutet, dass Cloud Computing für Unternehmen die Chance bedeuten kann, mit ihren historisch gewachsenen Insellösungen aufzuräumen. Unternehmen mit Insellösungen haben es durch die Cloud nun einfacher ein Einzelsystem dieser Insellösung gegen einen Cloud Service auszutauschen, um darüber sukzessive ein vollständig integriertes (Gesamt)-System von mehreren Cloud Services zu erhalten. Die Praxis ist an dieser Stelle zwar noch nicht so weit, es gibt aber erste Bestrebungen dieses zu ändern. Und das ist unumgänglich, um die Vielfalt unterschiedlicher Cloud Services zu nutzen. Ein entscheidender Punkt hierbei ist der Zugriff der jeweiligen Cloud Services auf einen gemeinsamen Datenbestand. Das bedeutet, dass jede Anwendung in einen quasi zentralen Speicher ihre Daten ständig ablegt und von dort auch wieder aufrufen muss.
Für den Integrationslayer ist zwangsläufig aber keine zentrale und persistente Datenbasis erforderlich. Eine Möglichkeit besteht auch darin, die Daten in Echtzeit aus den integrierten Systemen zu laden. Diese werden anschließend aufbereitet und auf einer einheitlichen Oberfläche dargestellt. So kann zum Beispiel auch ein beliebiger Cloud-Storage eingebunden werden, auf dem Daten (Bilder, Videos, usw.) abgelegt sind. Das bedeutet jedoch, dass alle Cloud Services, die Teil dieses Ökosystems werden wollen ihre APIs nach Außen öffnen müssen, um die Daten laden und zurückspeichern zu können.
Der Browser wird das Betriebssystem
Unabhängig davon wie die Integration im Einzelnen gelöst wird. Der Browser wird das “one face to the customer“, also zum zentralen Interface, wenn der Benutzer auf das Internet zugreift. Die von mir vor kurzem beschriebenen Desktop-as-a-Services (DaaS) sind dabei nur ein Zwischenschritt zum eigentlichen Endzustand. Zwar stellen DaaS vollwertige Arbeitsumgebungen inkl. klassischen Applikationen über die Cloud bereit. Jedoch läuft der DaaS normalerweise im Browser. Das bedeutet, man startet zunächst seinen Rechner, dann den Browser um erneut ein Betriebssystem zu starten. Würde ein Unternehmen somit auf Software-as-a-Service Lösungen als auch DaaS setzen, enstehen wieder die Daten- und Applikationssilos.
Das Ziel besteht daher in der Entwicklung einer Art “Über Cloud”, über die per Single Sign-On auf sämtliche Services in der Cloud – die Teil des Ganzen sein möchten – unter einer einheitlichen Oberfläche zugegriffen wird. Das ist wohlgemerkt kein neues Konzept und wird bereits erfolgreich umgesetzt. Jedoch nur auf einer sehr proprietären Basis mit Services von einem einzelnen Unternehmen. Sollen hier externe Services eingebunden werden, scheitert dieser Ansatz bisher.
Diese “Über Cloud” kann entweder als Public Cloud Service oder als private Lösung bereitstehen. Die private Lösung hätte den Vorteil, dass die IT-Abteilungen sie wie einen Service-Broker bzw. wie ein Serviceportal inkl. Applikationsfirewall für die Mitarbeiter nutzen können und darüber ein wenig Kontrolle über Business-Applikationen erhalten.
Das Szenario würde bedeuten, dass ein Mitarbeiter sich an der “Über Cloud” anmeldet und alle für ihn relevanten Business-Anwendungen sieht. Anhand der Anmeldung an der “Über Cloud” ist er direkt an alle anderen Anwendungen angemeldet.
Die “Über Cloud” sollte dabei wie ein Plugin-System aufgebaut werden, mit der sich jedes Unternehmen für seine Zwecke eine ganz persönliche Productivity Cloud zusammenstellen kann. Durch das Plugin-System lassen sich unterschiedliche Apps/ Services einbinden, wenn deren API dies zulässt. Entweder werden die Daten innerhalb einer gemeinsamen Oberfläche dargestellt. Die Daten also zur Laufzeit geladen und nach Veränderungen zurückgespeichert oder die jeweiligen Services in “Tabs” organisiert. Wichtig ist nur, dass die Daten in einer Art zentralen Zugriff stehen. So würde sich bspw. auch jeder beliebige Cloud Storage nutzen, da dieser nur angedockt wird. Wo die Daten liegen bestimmt damit das Unternehmen selbst.
Der Browser wird das Betriebssystem werden, jedoch müssen dafür noch die richtigen und unabhängigen Plattformen geschaffen werden.