Cloud Sourcing Lifecycle Operation

Cloud Sourcing LifeCycle – Part 5: Cloud Sourcing Operation

Es gibt verschiedene Adaption-Strategien, wie eine Cloud in Betrieb genommen werden kann. Ob virtuelle Maschinen quasi 1:1 (V2V) migriert, Applikationen mit «Lift and Shift» verschoben oder die gesamte IT Architektur den neuen Möglichkeiten der Cloud angepasst und somit transformiert wurde. Am Ende sind diese Cloud-Umgebungen dem Nutzer zur Verfügung zu stellen, zu betreiben und zu überwachen. Das kann mit internen, externen, privaten, öffentlichen oder hybriden Services geschehen- aus Sicht des Unternehmens ist die Fülle der Beteiligten Dienste und Provider ein zusammenhängendes Service-Eco-System, das beherrscht werden will. Die Reise der Cloud-Journey endet jedoch nicht bereits hier im Operation. Hier fängt sie erst richtig an. Hier steht oder fällt es, ob die Cloud einen Mehrwert für das Business liefern kann (Value Creation) oder ob sich die Cloud zur Hypothek und Kostenfalle entwickelt (Value Leakage)  – und ob sie die Grundlage für die digitale Transformation liefert. In diesem letzten der fünfteiligen Blog-Serie über den «Cloud Sourcing LifeCycle» stelle ich nun die Phase «Cloud Sourcing Operation» im Detail vor. Wenn die Arbeiten in den Phasen Strategie, Design und Transformation gut gemacht wurden, dann ist die Organisation bestens vorbereitet. Die Bedürfnisse des Business, die gemachten Erfahrungen und das immer mehr gewonnene Vertrauen in die neue Technologie sowie die rasant entwickelnde Cloud-Industrie sorgen unablässig dafür, dass der «Cloud Sourcing LifeCycle» sich weiterdreht und nicht stehen bleibt.

Obwohl hinter jeder Cloud letztlich irgendwo auch ein physischer Server mit wahrhaftigen Netzwerkanschlüssen steht, bleibt die Cloud für die meisten von uns nicht körperlich greifbar.  Die Cloud ist letztlich nur noch ein Dienst – ein Service, welcher mit definierten Leistungsparametern bezogen werden kann und welcher je nach Vertrag nur bezahlt wird, wenn der Service auch tatsächlich genutzt wird. Die Fülle des immer stärker wachsenden Cloud-Serviceangebots steht in der Regel nur im öffentlichen Cloud-Raum (Public Cloud) verfügbar, während abgeschottete private Clouds oft nur Effizienzpotentiale durch Automatisierung bei der Bereitstellung für sich beanspruchen können. Der Trend geht eindeutig in Richtung Public Cloud. Gemäss Forbes sind dies alleine 18% Zuwachs im 2017 – und soll bereits im 2020 40% des Cloud-Marktes ausmachen. Mit dem Essen kommt bekanntlich der Appetit – und damit auch mehr Vertrauen in die professionellen Anbieter. Lesen Sie auch den Blog von Mike Chan «Cloud-Computing in 2017: The 10 Most Important Trends to Monitor» von Thorn Technologies.

Mit dem Einzug der Cloud ins Unternehmen wird sich das Betriebsumfeld der IT-Organisation massiv verändern. Ob es eine eigene IT-Organisation dann noch braucht oder ob diese Funktion aufgrund der nicht mehr zwingend notwendigen IT-Technologie-Affinität vollständig in den Business-Prozessen integriert werden kann, sind Diskussionen, welche derzeit eher spekulativ sind. Ich bin überzeugt, dass es auch in Zukunft eine Organisation, eine Art Center of Excellence braucht, welche als Drehscheibe zwischen Beratung und Unterstützung bei Business-Bedürfnissen sowie der Steuerung und Durchsetzung der Supply-Chain von IT-Diensten fungiert.  Eine einmalige Chance für viele IT-Spezialisten, welche sich aufgrund dieser Veränderung neu orientieren müssen.

Cloud Sourcing Operation ist der «Moment of Truth». Hier zeigt sich, ob die Strategie aufgeht und der Mehrwert für das Business erbracht und damit die digitale Transformation ermöglicht werden kann. Ich fokussiere mich in diesem Blog auf folgende zwei Schwerpunktthemen:

  1. Multi Cloud Management
  2. Cloud Service Delivery Betriebsmodell
Cloud Sourcing Lifecycle Operation
Cloud Sourcing Lifecycle Operation

1. Multi Cloud Management

Auch wenn die Cloud noch intern und privat betrieben wird, werden Werkzeuge und Dienste von externen Anbietern in Anspruch genommen, welche eine Automatisierung und Standardisierung im Aufbau der Cloud erst ermöglichen. Das Business wird Public SaaS Lösungen einsetzen wollen, was letztlich zu einer Hybrid-Umgebung führt. Eine Cloud bleibt selten allein (Siehe dazu mein Artikel «Eine Cloud macht noch keinen Frühling» im IT-Markt von diesem April 2017. Die Organisation wird sich auf ein Multi-Sourcing- und Multi-Cloud-Modell ausrichten müssen. Gut ist, wenn diese Entwicklung bereits in der Strategie berücksichtigt ist. Ansonsten stolpert man per Zufall in die Multi-Cloud-Situation und stellt ernüchternd fest, dass der Organisation die Kontrolle über die Cloud entglitten ist.

Eine Organisation ist gut beraten, wenn sie auch weiterhin intern im Driving-Seat sitzt und damit die Kontrolle über die Governance der IT und der Prozesse innehat. Die Unternehmen sind sehr schnell mit einer Vielzahl von Providern konfrontiert, die es zu beherrschen gilt. Ich spreche dabei nicht von 2-5 externen Providern, sondern von 20-50 oder gar mehr. Services gegenüber dem Business setzen sich aus einer Vielzahl von externen Services zusammen, welche teils aus den diversen Cloud-Anbietern und teilweise aus externen und internen On-Premise-Leistungen bestehen. Die Rolle des «Service Integrators» wird in Zukunft eminent wichtig werden, weil er die End-to-End Service-Qualität, -Verfügbarkeit, -Kapazität, -Kontinuität und -Sicherheit garantieren muss.

Das wird nicht einfach, wenn jeder Provider sein eigenes Verständnis für LifeCycle Management, Wartungs-Fenster und Support-Modell beim Kunden durchsetzt. Der Umgang mit Major-Incidents oder die Analyse von Problemen welche verschiedene Provider involviert wird schwierig einzufordern sein, wenn alle Provider von sich behaupten, dass ihre Services einwandfrei funktionieren.

Die Positionierung der IT-Organisation als Service Integrator in der Phase Strategie und der damit notwendigen Governance, Prozesse und Skills im Cloud Betriebsmodell (Target Operation Modell) aus dem Cloud Sourcing Design bilden die Grundlage für ein effektives Multi-Cloud Management. Ein guter Cloud-Service zeichnet sich nicht nur aus der Funktionalität aus, sondern wie gut sich der Cloud Service und Cloud Service Provider in ein vom Unternehmen vordefinierten Betriebsmodell integrieren lässt.

Heute hat praktisch jeder Cloud-Provider sein eigenes Verrechnungs-Modell, sein eigens Reporting-System und seine eigenen für den Kunden nicht transparenten Betriebsprozesse. So bezahlt ein Kunde von uns beispielsweise seine privaten IaaS- und PaaS-Dienste nur, wenn diese gestartet sind. Durch gezieltes Stoppen einzelner temporär nicht benötigten Systeme lässt sich so enorm Kosten sparen.  Dass gestoppte Systeme nicht im automatisierten Patch-Zyklus mit-aktualisiert werden, hat der Kunde schmerzlich erfahren müssen, nach dem er die Systeme nach Wochen wieder in Betrieb nehmen wollte.

Wenn die interne IT-Organisation die irgendwie aggregierten Cloud-Services gemäss deren Nutzung und Leistungsverrechnung überwachen und kontrollieren muss, kann er dies ohne systematische Analyse und Werkzeuge nicht selber tun. Ohne entsprechende Werkzeuge und Transparenz wird er sich auf die Angaben des Providers verlassen müssen, was aus Sicht Corporate-Governance bedenklich ist. Besser wäre, er hat ein Multi-Cloud Betriebskonzept erstellt, welches die wesentlichen Integrationsaspekte regelt:

  • Service Katalog mit Service-Architektur und Mapping zu Service-Providern
  • Service Usage Reporting
  • Cloud Provider Koordination
  • On- und Offboarding
  • Toolset-Integration

Ein auf Multiprovider-Management ausgerichtetes Betriebskonzept ist «Service Integration and Management», SIAM. Hierzu habe ich bereits mehrfach in diesem Blog geschrieben (z.bsp. «SIAM – Das Service Integration Modell im Multiprovider Umfeld», «Herausforderung agile Service Integration und Management (SIAM) in einem Multiprovider Umfeld»  oder auch «Multiprovider Management: SIAM Toolset».

Es ist klar, dass insbesondere bei Public Cloud-Diensten kein grosser Spielraum bei SLA-Verhandlungen bestehen. Je Business-kritischer der Cloud-Service für das Unternehmen ist, desto wichtiger sind jedoch bei der Auswahl des Anbieters dessen Integrationsfähigkeit. Sollten diese nicht ausreichen, müssen kompensierende Massnahmen in Betracht gezogen werden, was letztlich mehr Koordinationsaufwand bedeutet.

Die Beherrschung der Multi-Cloud-Provider wird für die meisten Organisationen die grösste Herausforderung in Zukunft bilden. Die Rolle des Cloud Service Integrators kann auch als Dienstleistung von einem dafür spezialisierten Provider bezogen werden, wenn die eigenen Skills dazu nicht ausreichen. Es ist jedoch darauf zu achten, dass der Provider eine möglichst neutrale Rolle bei der Wahrnehmung dieser Aufgabe innehat. Er muss alle externen Provider integrieren und überwachen können. Dazu sollte ein eigens auf diese Aufgabe zugeschnittener Service Vertrag erstellt werden.

Es ist jedoch ratsam, zumindest auf strategischer und taktischer Ebene (On-/Off-Boarding von Cloud-Diensten) die Integrationsrolle intern beim Unternehmen zu halten und maximal die operativen Cloud-Orchestrierung und Cloud-Management Integrationsfunktion extern auszulagern.

2. Cloud Service Delivery Betriebsmodell

Die Phase Operation im Cloud Kontext besteht nicht bloss aus Betrieb und Support, wie das oft in klassischen IT-Organisationen verstanden wird. Mit dem Einzug der Cloud ins Unternehmen, werden Cloud-Services dem Business oder auch IT-Intern, beispielsweise der Entwicklungscrew im Subskription-Mode automatisiert zur Verfügung gestellt. Der Nutzer kann die Cloud beziehen und wieder abbestellen. Diese Bereitstellung, Nutzungsüberwachung und Abrechnung werden zentrale Aufgaben im Cloud Service Delivery Betriebsmodell sein.

a) Cloud Service Portal

Ein Unternehmen welche sich explizit für eine Cloud Strategie ausgesprochen hat, sollte die Wahl und Bestellung von Cloud-Diensten nicht einfach den Businesseinheiten oder einzelnen Mitarbeitern selbst überlassen. Vielmehr bracht es eine klare Governance und zentrale Prüfung, welche untersucht ob gewünschte Cloud-Dienste für das Unternehmen geeignet sind und ob diese den Anforderungen, insbesondere bezüglich Sicherheit, Compliance und Datenschutz genügen.

Die verbleibende interne IT-Organisation kann so die Rolle des Cloud-Brokers wahrnehmen, und für das Unternehmen und deren Businesseinheiten geeignete Cloud-Dienste evaluieren und bereitstellen.  Die Cloud-Dienste werden in einem zentralen Service Katalog zusammen mit allen anderen IT Services integriert und mit Preisen, SLA-Optionen versehen. In diesem zentralen, möglichst internen Service Portal werden neue Services integriert oder auch wieder gelöscht, wenn sie nicht mehr eingesetzt werden sollen.

Der Bezug von Cloud-Diensten soll nur über diese zentrale Portal-Funktion angeboten werden, weil nur so der Bezug von Cloud-Services im Unternehmen kontrolliert werden kann.

b) Subskription & Engagement Portal

Es braucht ein Engagement-Portal, wo der Nutzer Zugriff auf den zentralen Service Katalog oder das Service Portal hat, die für ihn auf sein Profil zugeschnittenen Cloud-Dienste zur Auswahl angeboten erhält und wo er aufgrund der SLAs und Kosten den Service abonnieren (subscribe) oder auch wieder abbestellen (unsubscribe) kann. Hier kann der Entwickler auch seine Kapazitäten hinzubestellen oder auch  wieder zurückfahren.

In seinem Portal (MyPortal) hat er die Übersicht über sämtliche abonnierten Services (SaaS, PaaS, IaaS) wie auch internen IT-Services sowie deren aktuellen Nutzungsstatus sowie aufgelaufenen Kosten.  Bei diesem personalisierten Self-Service Portal kann er dann jederzeit einen Service «subscriben» oder «un-subscriben». Er erhält damit volle Transparenz seiner Cloud-Service-Bezüge.

c) Automatisiertes Fulfillment

Die Subskription eines Service (auch Unsubscription) löst einen automatisierten Workflow aus, welcher die Bereitstellung des Cloud-Dienstes umsetzt. Das kann nun ein IaaS-, PaaS-, oder SaaS-Service sein gemäss Spezifikation im Service Portal.

Um volle Effizienz zu erhalten, sind sowohl die internen wie auch externen Cloud-Service Provider nach Möglichkeit im Workflow integriert, sodass keine manuelle Interaktion notwendig wird. Jetzt kann es durchaus sein, dass ein Cloud-Dienst, zum Beispiel PaaS nicht bloss ein Provider, sondern eine Vielzahl von zusätzlichen Diensten integriert, weil diese gemäss Architektur zusammenhängend ausgeliefert werden.

In vollautomatisierten DevOps-Organisationen mit Continous Integration und Continous Deployment können hier auch automatisch Cloud-Services aktualisiert oder Infrastruktur-Dienste automatisch integriert werden (Infrastructure as a Code).

Die Cloud-Provider müssen ihrerseits sicherstellen, dass sie die Elastizität und Skalierbarkeit im Griff haben. Die Bereitstellung oder auch das Herunterfahren von Kapazitäten gemäss Subskription -Vereinbarung ist seine zu beherrschende Herausforderung.

Entsprechend werden die Assets registriert und die Betriebsfunktionen wie Monitoring, Backup, Access-Management aktiviert. Die Service-Verträge mit den verschiedenen involvierten Service Provider werden somit auch aktiv und nachvollziehbar dokumentiert.

d) Monitoring und Chargeback

Die Cloud muss nun nicht nur bezüglich der Verfügbarkeit und Stabilität überwacht werden, sondern insbesondere deren Nutzung gemäss SLA-Vereinbarung durch die Subskription und damit zur Sammlung der Daten für die Verrechnung, respektive der Nachvollziehbarkeit der Angaben seitens der Cloud-Provider. Entsprechend werden Verrechnungen seitens der Cloud-Service Provider (Invoices) aufgeschlüsselt und gemäss Verbrauch dem individuellen Nutzer zugerechnet.

Dies soll idealerweise ohne manuelle Verarbeitung und möglichst ohne Medienbruch und Tool-Einschränkungen erfolgen.

Ohne ein geeignetes Cloud-Service-Delivery Betriebsmodell wird der Cloud-Betrieb zur unlösbaren Herkulesaufgabe. Viele Cloud-Service Provider bieten Management-Schnittstellen an – aber ein API ist noch keine Integration.

Request to Fullfill: Value Stream aus IT4IT
Request to Fullfill: Value Stream aus IT4IT

Ein Lichtblick hierzu bietet IT4IT von der Open Group. IT4IT ist ein IT-Referenz-Architektur-Modell, dass auf einem Value-Chain Konzept basiert und explizit für die Integration von automatisierten und auf Cloud- und Multiprovider-Umgebungen fokussierten IT Betriebsmodell der Zukunft ausgerichtet ist. Lesen Sie dazu auch meinen Blog: «IT4IT – Die Basis für eine Toolchain-Architektur» oder auch «Das IT-Betriebsmodell der Zukunft – Blueprint auf Basis von IT4IT».

Damit bin ich am Ende meiner Blogreihe zum «Cloud Sourcing LifeCycle» angelangt. Cloud wird und hat schon die Welt verändert, wie wir sie aus Sicht der traditionellen IT vor ein paar Jahren nicht vorstellen  konnten. Und sie wird die Unternehmen, die Smart-Cities und auch uns privat weiterhin in die digitale Transformation begleiten. Konsequentes Feedback und kontinuierliche Verbesserung in all den Cloud-Sourcing LifeCycle Phasen bilden das Rückgrat für Agilität und Effizienz. So gesehen ist diese Blog-Riehe auch nur ein Snapshot des Cloud-Zeitalters aus meiner aktuellen Erfahrung und Sichtweise. Was morgen kommt, bleibt spannend.


 

2 Kommentare zu «Cloud Sourcing LifeCycle – Part 5: Cloud Sourcing Operation»

  1. Your website looks to be interesting with very interesting subject titles however it would be very helpful to have the content in english so that it could be read without having to use a translator.

Schreiben Sie einen Kommentar zu Martin Andenmatten Kommentieren abbrechen

Ihre E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert