Wechsel auf die Cloud – was ist zu beachten?

Alle sprechen von der Cloud und Oracle macht seinen Kunden mit viel Marketing auch deutlich, wo die Zukunft liegt. Als unabhängiger Berater möchte ich in diesem Beitrag auch die weniger genannten Punkte mal aufgreifen, die auch zu einem Wechsel auf die Cloud gehören. Ich beziehe mich in meinen Überlegungen auf einen Wechsel von einer Oracle Hyperion Planning Applikation auf die Planning and Budgeting Cloud Service.

Was ist die Ausgangssituation und das Ziel Bild?

In meinem fiktiven Beispiel hat Kunde A 2 größere und 2 kleinere Planning Applikationen auf der Produktionsumgebung. Hierzu hat dieser Kunde Lizenzen auf Rechenkernbasis, und ca. 200 Benutzer. Es gibt eine Entwicklungs- und Testumgebung wo Anpassungen an die Applikationen gemacht werden. Dieses wird von der BI-Abteilung gemacht, teilweise mit externer Unterstützung, wenn es größere oder schwierige Anpassungen betrifft.

Die Hard- und Software wird von der IT-Abteilung betreut und es wird regelmäßig ein Upgrade ausgeführt. Hierzu wird, wenn nötig externer Support eingekauft.

Das Ziel Bild wäre, das die Planning Applikationen sich auf der Oracle Cloud befinden, und die Benutzer sich dort anmelden und ihre gewohnte Arbeit machen. Die BI-Abteilung hat eine eigene Cloud-Instanz als eine Entwicklungs- und Testumgebung. Die Integration von Quellen und Ziel für Bewegungsdaten und Metadaten wurde neu aufgebaut. Die IT-Abteilung hatte, nach dem „aufräumen“ der Server, deutlich weniger Arbeit.

Der Weg zum Ziel

Eine Machbarkeitsstudie wurde ausgeführt und die Vor- und Nachteile, sowie die Kosten dargestellt. Das Management hatte sich von einem Wechsel in eine PBCS Umgebung überzeugt und entsprechend wurde ein Projekt initiiert. Hierin wurde mit Hilfe von externem Support ein Migrations- und Integrationsplan aufgesetzt und durchgeführt. Auch wurden die vertraglichen Dinge geklärt und der Mietvertrag abgeschlossen.

In einer Übergangsphase gab es sowohl Lokale Planning Applikationen als auch Cloud Applikationen. Einerseits war dieses notwendig, um die Integration der Datenschnittstellen umzustellen, andererseits um die Applikationen zu konsolidieren und weniger Cloud Instanzen zu mieten und damit Kosten zu sparen.

 

Übergang auf die Cloud: Was ist alles so zu beachten?

Es gibt vieles zu beachten, bevor die Entscheidung getroffen wird, um mit Oracle Hyperion Planning auf die PBCS Cloud zu schwenken. Hier ist eine Liste, deren Punkte ich über die Monate zusammengetragen habe. Sie hat keinen Anspruch auf Vollständigkeit, aber kann ihnen als Gedankenstütze dienen, bei der strategischen Entscheidung um einen vollständigen oder teilweisen Übergang auf PBCS zu machen.

Wichtig zu beachten ist: Cloud ist nicht gleich Cloud. Was für PBCS gilt, gilt schon lange nicht für z.B. Essbase (OAC).

 

Lizenzkosten

Die PBCS ist ein Dienst, und die Nutzung ist in einem Mietvertrag untergebracht. Hierin gibt es nach meiner Meinung nur eine „Named User“ Lizenz in der pro registrierten Anwender bezahlt wird. Bisher habe ich keine Option gesehen, die einer „CPU“ Lizenz gleich war, in der eine bestimmte Rechenleistung anstatt Anzahl der Benutzer zählte. Dieses könnte für bestimmte Kunden oder Applikationen ungünstiger sein.

Ein anderer Unterschied zu gängigen Software Lizenzen ist die Laufzeit. Der Vertrag hat eine bestimmte Laufzeit und davon abhängig ist auch der Preis. Innerhalb dieser Laufzeit sind die Kosten fix, danach sind diese wieder offen. In wie weit es für Kunden Optionen gibt bestimmte Teuerungsraten oder zukünftige Preisniveaus zu vereinbaren, ist mir nicht bekannt.

Bei Software Lizenzen gibt es neben dem Kaufpreis auch die jährlich wiederkehrenden Service Kosten für Support und Patches. Diese gibt es bei den Cloud Lizenzen nicht.

Weil es eine strategische Entscheidung ist, sollte der Lizenzkostenvergleich über einen längeren Zeitraum gemacht werden, und nicht nur über 3 Jahre. Hierbei spielt vielleicht auch eine Rolle, dass bestehende Lizenzen abgeschrieben werden können. Ich habe noch nicht vernommen, dass bestehende Lizenzen für Cloud-Lizenzen getauscht oder verrechnet werden können. Diese sind dann wertlos geworden.

 

Verfügbare Betriebszeit (Uptime)

Die PBCS hat eine tägliche Downtime von einer Stunde. Dieses ist nicht viel, denn bei vielen meiner Kunden machen wir auch so etwas, um einen guten Backup zu machen und Ressourcen wieder frei zu geben. Wenn es dabei bleibt, dann ist die verfügbare Betriebszeit gut.

In wie fern Oracle dieses in Verträge auch garantiert kann ich leider nicht sagen. Ich bin kein Jurist und möchte hier nichts vom „Hörensagen“ aufschreiben.

Die Uptime ist in der Planung oft nur zu bestimmten Zeiten äußerst wichtig und das sollte dann auch vertraglich gewährleistet sein.

Eng mit der Betriebszeit ist auch die minimale Leistungsfähigkeit verbunden. Normalerweise, wenn es Performance Probleme gibt, dann sind verschiedene interne Abteilungen involviert: wer überwacht hier die Leistung, liegt es an den „Platten“, liegt es am Netzwerk, was macht die BI gerade,…? Dieses wird in einer Cloud-Umgebung dann auch außerhalb der Firma getragen. Und dort steht ein „Riese“ wie Oracle – hat hier jemand Probleme? Es gibt neuerdings bessere Logdateien und Performance Übersichten, aber direkten Zugriff hat man nie. Es ist und bleibt eine gemeinsam genutzte Plattform in einem (oder mehreren) Datencentern.

Oracle sagt, sie überwachen die Leistung und geben mehr Ressourcen wenn nötig. Bisher habe ich auch keine Probleme gehabt oder davon gehört. Was vertraglich festgelegt werden kann, ist mir noch unklar.

Technische Unterstützung (Support)

Technische Unterstützung ist sehr wichtig, denn ein Ausfall einer Applikation kann schon schnell viele Mitarbeiter betreffen und wichtige Arbeiten verzögern. Daher sind Qualität und Verfügbarkeit von Technischer Unterstützung essentiell für Betriebsapplikationen. In der Cloud wird es weniger Fragen vom Support geben, denn die Version und die Konfiguration sind ja alle gleich. Damit hat man also viel Zeit gespart!

Auch hinsichtlich einer oft vernommenen Lösung des Problems, bitte upgraden, wird nicht mehr zutreffen. Die Patches kommen automatisch und es gibt kein Stopp oder Verzögerung bei der Installation mehr.

Auch die von Support fast schon obligatorisch geforderte Websession, um das Problem zu sehen, wird sich ändern. Technisch könnte der Support sich direkt auf die Cloud Instanz schalten, nur habe ich dieses noch nicht vernommen, dass dieses passiert. In meinen Augen wäre dieses auch ein großer Eingriff in die Vertraulichkeit.

 

Sicherheit

Die Sicherheit ist eines der am meisten besprochenen Themen rund um die Cloud. Hier gibt es den Aspekt der Angreifbarkeit durch Schwachstellen und Sicherheitslücken und die Betriebssicherheit, die ich weiter oben schon besprochen habe.

Oft wird dagegen gesetzt, wie sicher ist das eigene Firmennetzwerk? Könnte man es nicht besser Experten überlassen, die sich tagtäglich hierum kümmern? Die einen Tag nach Bekanntgabe einer Sicherheitslücke diese schließen?

Sicherlich sind die Möglichkeiten von Großkonzerne in der Software viel besser. Sie können das beste Talent einkaufen, haben mehr Geld für Entwicklung und vieles mehr. Jedoch sollte man die Fähigkeiten der eigenen IT-Abteilung auch nicht unterschätzen. Wenn die Architektur stimmt und der Betrieb richtig aufgesetzt ist, dann macht man es das Eindringen von Außen nicht einfach. Solange die Daten auf dem eigenen Firmennetz sind und bleiben, hat die lokale Installation einen deutlichen Vorteil. Wenn etwas schief geht, dann weiß man, wer verantwortlich ist.

Die lokale Installation wie auch die Cloud haben immer eine Verbindung mit dem Rechner der Benutzer. Eine Verbindung von SmartView an den lokal installierten Oracle Hyperion Planning Webserver, wie auch an den Webserver der PBCS, verwendet dieselbe Technologie. Der Unterschied, der erste geht wahrscheinlich nur über ein Firmennetzwerk, der Zweite über das reguläre Internet. Beide können mit denselben Sicherheitsmaßnahmen ausgestattet werden.

Bei Patch-Updates auf den Servern und den damit verbundenen Kosten ist sicherlich die Cloud im Vorteil. Aus meiner Erfahrung wird das Einspielen von Patches oft nicht gemacht, weil intern die Notwendigkeit nicht erkannt wird. Nur wenn es konkrete Produktfehler gibt, dann werden gezielt Patches installiert. Das es hierdurch Sicherheitslücken geben kann, liegt auf der Hand.

Ein Release-Wechsel  ist immer mit viel Arbeit und damit Kosten verbunden. Dem Management sind solche Kosten oft schwer zu erklären, denn es gibt erst einmal nichts wesentlich Neues. Die neue Funktionalität wird ja oft erst später sichtbar. Mehr Betriebssicherheit ist auch nicht echt sichtbar. Eine Cloud-Umgebung wird auch auf ein neues Release gebracht, aber in der vereinbarten Downtime. Ein Nachteil kann sein, dass es hieran kein „Entrinnen“ gibt. Egal welche wichtigen Prozesse gerade anstehen, der Upgrade kommt!

Zum Testen gibt es 2 Wochen, denn zuerst kommt das Update (Upgrade) auf die Entwicklungsumgebung. Sie sehen direkt, ob die Anpassungen auch in der neuen Umgebung noch funktionieren. Dann kommt die neue Version auf die Produktionsumgebung. Soweit ich gesehen habe, ist hierfür der jeweilige Freitag ausgewählt. Also wenn man am Wochenende nichts vor hat….

Interessant wird es, wenn ein SmartView-Upgrade notwendig wird. Dieses ist noch immer eine Installation in das MS Office hinein. Dieses zieht dann schon einiges nach sich, und hierauf sollten die Administratoren sich schon vorbereiten.

Compliance (einhalten von Gesetze und Regeln)

Oft wird dieses als das größte Hindernis zum Wechsel auf die Cloud gesehen. Oft wird nach Gesetzestexte verwiesen, wo steht dass die Daten im Ursprungsland verbleiben müssen, und Vieles mehr. Ich bin kein Jurist, und daher hätte ich bei den vielen Verweisen auf die Gesetzestexte auch gern mal konkret die Paragrafen bekommen. Vielleicht kann ja einer der Leser mir hier weiterhelfen.

Die Cloud-Anbieter reagieren mit Datacenter in verschiedenen Ländern, vielleicht auch nur, um dieser Diskussion aus dem Weg zu gehen.

 

Betriebskosten

Die Einstiegskosten werden in der Cloud als relative gering angesehen, aber wie steht es mit den Betriebskosten?

Nun, die Einstiegkosten sind vor allem für Neue und auf sich stehende Applikationen überschaubar. Für bereits existierende Applikation, die oft viele Schnittstellen auf andere Systeme und damit bestehende Automatisierung haben, kann der Aufwand für die Migration auf die Cloud doch groß sein. Einer der Gründe ist, das bestehende Tools nicht immer Cloudfähig sind. Hier müssen dann abweichende Prozeduren entwickelt werden, und besteht eine Lernkurve mit neuen Best-Practices. Ein anderer Faktor ist, dass die Werkzeuge, die Oracle anbietet noch in der Reife-Phase sind. Wir sehen, dass es neue Versionen des „EPM Automate Utility“ gibt, und Export Formate sich ändern.

Über die Betriebskosten im Verhältnis zur Cloud kann ich weniger sagen, denn diese sind von Konzern zu Konzern unterschiedlich. Das Herausnehmen einiger (im Verhältnis zu anderen) Applikationen führt in der Regel nicht zu den großen Kosteneinsparungen, denn die Festkosten bleiben vorhanden. Hier ist also die Berechnung für den Einzelfall zu machen.

 

Fazit

Ein Wechsel auf die Cloud hat auch andere Seiten und diese wollte ich in diesem Beitrag darstellen. Der Beitrag sollte nicht so verstanden werden dass ich ihnen abrate, auf die Cloud zu migrieren. Ein unabhängiger Berater kann und sollte aber auch andere Aspekte beschreiben, die weniger in der Öffentlichkeit beschrieben werden. Eine gute Entscheidung erfordert Informationen aus verschiedenen Blickwinkeln.

 

Ihr Philip Hulsebosch.

Veröffentlicht unter EPM & BI, Essbase Getagged mit: , , , ,

Schreibe einen Kommentar

  • Ein Fehler ist aufgetreten – der Feed funktioniert zur Zeit nicht. Versuche es später noch einmal.