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.
Die Problematik der Cloud-Datensilos besteht nicht nur in Form der Cloud-Marketplaces. So werden auch Integrationsmöglichkeiten zum Beispiel von 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, dies 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 Integrations-Layer 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 oder Präsentationen) 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 inklusive klassischer 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 sowohl auf Software-as-a-Service-Lösungen als auch auf DaaS setzen, entstünden erneut 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.
Public-Cloud-Service oder private Lösung
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 beziehungsweise wie ein Serviceportal inklusive Applikations-Firewall 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 Plug-in-System aufgebaut werden, mit der sich jedes Unternehmen für seine Zwecke eine ganz persönliche Productivity-Cloud zusammenstellen kann. Durch das Plug-in-System lassen sich unterschiedliche App-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 zentralem Zugriff stehen. So lässt sich beispielsweise auch jeder andere 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. (hal)
Dieser Artikel basiert auf einem Blog-Beitrag von CloudUser.de.