Für Unternehmen kann es durchaus attraktiv werden, in Zukunft selbst als Cloud (Service) Provider aufzutreten. Genau dann, wenn sie sich im Laufe der Evaluation doch für den Einsatz einer Private Cloud im eigenen Rechenzentrum entschieden haben. Wir erinnern uns: Eine Private Cloud bedarf Unmengen an physikalischen Ressourcen um den Wunsch nach Flexibilität und quasi unendlichen virtuellen Ressourcen zu befriedigen. Heißt im Umkehrschluß daher für Private Cloud freundliche Unternehmen: Investieren, das eigene Rechenzentrum umbauen und cloudfähig zu machen. Der dabei entstehende „Überschuss“ an Ressourcen kann bspw. anderen Unternehmen angeboten werden. Aber auch ohne die eigene Private Cloud ist der Weg zum Cloud Service Provider ohne weiteres möglich. Speziell dann, wenn das Unternehmen aus dem Bereich der klassischen Anwendungsentwicklung kommt und nun auf SaaS als Vertriebsmodell setzt. Hier reicht z.B. die Nutzung einer Public Cloud, um auf dieser Infrastruktur die eigenen Services auszuliefern.
Soll es allerdings dazu kommen, müssen jedoch zunächst viele Veränderungen innerhalb der IT-Infrastruktur aber auch strukturelle Änderungen in der Organisation und in den Köpfen der Beteiligten stattfinden. Das fängt bereits damit an, dass ein Unternehmen, das Cloud Services anbieten möchte, selbst Cloud Computing nutzen muss. Nicht nur um die Glaubwürdigkeit zu unterstreichen, sondern ebenfalls, um die notwendige Expertise mit dem Umgang von Cloud Computing zu erlernen und aufzubauen.
Um den Transformationsprozess zu starten benötigt es natürlich keine Private Cloud, im Gegenteil. Aber auf jedenfall detaillierte Analysen und das Verständnis für den bisherigen Einsatz der IT im Unternehmen und das Identifizieren möglicher Ansätze die Aufzeigen, wie Cloud Computing hier gezielt eingesetzt werden kann. Erst dann kann eine Entscheidung für oder gegen Cloud Computing getroffen werden.
Unternehmen, deren Geschäftsmodell in erster Linie darin besteht Softwareapplikationen nach Bedarf zu entwickeln und ggf. die Daten für die Kunden zu hosten, bietet Cloud Computing ein enormes Potential und hat einen entscheidenen Einfluss auf die IT, den Softwareentwicklungsprozess sowie die interne Zusammenarbeit innerhalb des Projektteams und in Richtung der Fachabteilungen.
Ein Fallbeispiel
Um die im letzten Abschnitt genannte Situation zu vertiefen, werde ich im Folgenden ein reales Szenario aus der Praxis (anonym) beschreiben und hierfür einen möglichen Ansatz für den Einsatz von Cloud Computing aufzeigen.
Das Unternehmen entwickelt auf Basis von Projektgeschäften Java Anwendungen, wobei die Kundenanzahl pro Projekt und Geschäftsfeld variiert. So existieren Projekte mit maximal einem Kunden und Projekte mit mehr als 10. Dieses Beispiel beschreibt ein Projekt mit ca. 12 Kunden, wobei die Kunden alle dieselben Anforderungen an die Software besitzen und daher alle mit ein und derselben Anwendung arbeiten können. Die größte Herausforderung besteht, abgesehen von der fachlichen Komplexität, in der sorgfältigen Trennung der Daten der jeweiligen Kunden.
Die Daten aller Kunden sind auf den Servern des Unternehmens gespeichert und werden mittels Java Clients abgerufen. Bei den Client Anwendungen handelt es sich um Swing GUIs, die für die Ansicht und die Eingabe der Daten dienen. Parallel wurde auf Wunsch der Kunden im Laufe der Zeit eine Web Anwendung entwickelt, die lediglich für den Lesezugriff genutzt werden darf. Die Grundlage der Web Anwendung ist eine Art Swing Übersetzer, um den Code der Swing GUI auch im Web auf eine einfache Weise weiterzuverwenden.
Probleme
Die aktuellen Probleme bestehen zunächst in der Trennung der Projektrepositories zwischen der Fachabteilung und dem Entwicklungsteam. Die Fachabteilung verwaltet die Business Cases auf Basis eines Microsoft SharePoint. Das Entwicklungsteam nutzt das Open Source Versionsverwaltungssystem Subversion. Im ersten Moment klingt das nicht nach einem Problem. Die Fachabteilung speichert und überarbeitet die Business Cases auf ihrem SharePoint. Das Entwicklungsteam kopiert die fertigen Business Cases anschließend manuell in das eigene Subversion Repository. Das hört sich im ersten Moment nicht nach einem Problem an. Allerdings kommt es dadruch häufiger vor, dass die Fachabteilung weitere Änderungen an den Business Cases vornimmt und vergisst das Entwicklungsteam darüber zu informieren. Dadurch werden bestimmte Anforderungen von der Fachabteilung softwaretechnische nicht umgesetzt, da das Entwicklungsteam von den Änderungen keine Kenntnisse besitzt. Es wird daher auf unterschiedlichen Versionsständen entwickelt.
Ein weiteres Problem besteht in dem Deployment der Anwendungen in Richtung des Kunden. Der Prozess von dem vorab Test der Anwendung, über den Build bis hin zur eigentlichen Auslieferung dauert (inkl. Automatisierung) bis zu einer Stunde. Hinzu kommt, dass für die Java Clients und die Web Applikation zwar auf den selben Programmcode zurückgegriffen wird, auf Grund des Swing Übersetzers jedoch immer wieder manuelle anpassungen vorgenommen werden müssen.
Darüber hinaus sind lokale Java Anwendungen nicht mehr zeitgemäß und Web Applikationen werden die Zukunft bestimmen.
Ein weiteres Problem besteht mit dem internen IT-Dienstleister, der das unternehmenseigene Rechenzentrum verwaltet und für die Bereitstellung der für das Projekt benötigten Produktivsysteme und Testsysteme verantwortlich ist. Die genauen Probleme bestehen hier in den Kosten sowie der langsamen Bereitstellung der Server und der Wartung.
Ein möglicher Lösungsansatz
Der Lösungsansatz is sehr generisch und kann im Prinzip von jedem Unternehmen, das noch klassisch Software entwickelt adaptiert werden.
Die Problematik mit dem Repository kann bspw. durch die Nutzung einer SaaS Cloud Office Suite wie z.B. Google Apps oder Office 365 gelöst werden. Abgesehen von der tatsächlichen Umsetzung muss aber zunächst bei allen Beteiligten erkannt werden, dass ein zentraler Ansatz, also ein gemeinsames Repository für die Fachabteilung als auch für das Entwicklungsteam notwendig ist, um in Zukunft auf denselben Versionsständen zu arbeiten.
Für das Deployment bzw. der gesamten Anwendungsentwicklung sollte ein vollständig neuer Ansatz verfolgt werden. Was hier benötigt wird, ist eine Cloud Developement Platform. Auf dieser wird zugleich auf Basis von PaaS die Software entwickelt, um im Anschluss den Kunden mittels SaaS die Software bereitszustellen.
Zudem haben beide Lösungsansätze (Cloud Repository, Cloud Developement Platform) den Vorteil, dass damit ebenfalls die verteilte Entwicklung von Software von unterschiedlichen Standorten aus sehr bequem und flexibel stattfinden kann.
Ausgehend davon, dass sich das Unternehmen für den Einsatz einer eigenen Private Cloud entscheidet, würde der Einsatz einer internen Hybrid Cloud am meisten Sinn machen. Eine interne Hybrid Cloud deswegen, da für die Softwareentwicklung sowie dem Dokumenten- und Informationsaustausch eine Private Cloud benötigt wird und für die Bereitstellung der Software per SaaS nur eine Public Cloud mit öffentlichen Zugriff eingesetzt werden sollte. Für diesen Fall kann sich der interne IT-Dienstleister ebenfalls überlegen, eine externe Entwicklungsplattform auf Basis von PaaS öffentlich anzubieten, um damit seine Infrastruktur besser auszulasten.
Der interne IT-Dienstleister kann natürlich auch umgangen werden und das Projekt bzw. das Unternehmen bedient sich direkt bei einem Cloud Anbieter. In diesem Fall ist es aber zunächst selbst für das Deployment der Serversysteme zuständig.
Fazit
Bei diesem Beispiel handelt es sich tatsächlich um ein echtes Fallbeispiel aus der Praxis. Wie man sieht, ist der Umstieg von der klassischen Softwareentwicklung hin zum Deployment von SaaS Anwendungen nicht trivial und mit vielen Hürden verbunden. Hier sind ganz neue Ansätze gefragt, die viele Bereiche eines Unternehmens und zwischen Unternehmen beeinflussen. Es handelt sich hier nur um einen möglichen, nicht bis ins Detail betrachteten, Lösungsansatz. Ein Vollständiger (inkl. exakter Problembeschreibung und Lösung) würde ohne weiteres ein Buch füllen.
Was hier allerdings sehr deutlich wird ist, dass sich ein Unternehmen in diesem Fall verändern muss. Alle Beteiligten müssen daran mitwirken und das Unternehmen muss im Prinzip um 180° gedreht werden. Denn die Art wie Software entwickelt wird hat sich verändert, was auch Auswirkungen auf den gesamten Softwareentwicklungsprozess hat. Dabei sollte niemals vergessen werden, dass es sich um keine triviale Aufgabe handelt, eine Software verteilt, skalierbar, hochverfügbar, usw. zu entwickeln.