Dr. Seiler: Oftmals gilt es in einem ersten Schritt, eventuell vorhandene „Skepsis“ der Teams beziehungsweise Teammitglieder gegenüber „der Cloud“ abzubauen. Dieses findet sich nicht nur, aber zumindest doch gehäuft im Bereich des Betriebs von Software in der Cloud wieder, und ist zumeist in mangelnder Kenntnis ob der Möglichkeiten – und vor allem der Vereinfachungen, welche ein Betrieb in der Cloud mit sich bringt – begründet.
Eine sehr gut bewährte Strategie zum Abbau derartiger Vorbehalte gegenüber der Cloud ist das Veranstalten von sogenannten „Hackathons“, das heißt von Veranstaltung, in denen optimalerweise heterogen aufgestellte Teams versuchen, gemeinsam und in kurzer Zeit exemplarisch eine Lösung für ein gestelltes Problem zu entwickeln, und dabei auch „spielerisch“ die von der Cloud bereitgestellten Möglichkeiten zu erleben und ebenfalls auch auszuprobieren. Erfahrungsgemäß wird dem einzelnen Beteiligten so eine eventuell anfänglich vorhandene Skepsis gegenüber der auf den ersten Blick in der Tat nur sehr schwer greifbaren Cloud und den durch diese bereitgestellten Möglichkeiten genommen, es werden erste praktische Erfahrungen gesammelt und erste Fähigkeiten gewonnen, welche sich in einem zukünftigen Projektverlauf sukzessive weiter auf- und ausbauen lassen.
Cloud Computing hat sich auch in Deutschland flächendeckend durchgesetzt, dessen ungeachtet gibt es aber jede Menge Hindernisse für den Einsatz. Was sind aus Ihrer Sicht die größten technischen Hürden auf dem Weg in die Cloud?
Dr. Seiler: Die oftmals größte Hürde, welche auf dem Weg in die Cloud überwunden werden muss, ist zugleich ebenfalls meist die erste Hürde, die es zu überwinden gilt – nämlich die Analyse von in der Regel meistens bereits bestehenden Systemlandschaften. Erfahrungsgemäß sind bereits bestehende Systemlandschaften in der Regel über eine lange Zeit hinweg sukzessive gewachsen, dieser Zeitraum kann Jahre, teilweise abhängig von der Branche auch Jahrzehnte umfassen, so dass es oftmals der Fall ist, dass keine vollständigen beziehungsweise keine vollständig korrekten Dokumentationen dieser Systemlandschaften existieren. Infolgedessen ist das Zusammenspiel der einzelnen Komponenten in einem solchen System teilweise nur äußerst schwer zu erkennen, was das Übertragen einer solchen Systemlandschaft in die Cloud oftmals herausfordernd macht.
Daher ist einer der ersten – und zugleich einer der elementarsten – Schritte in einem derartigen Fall in der Regel die Analyse der bestehenden Systemlandschaft, und hierbei insbesondere die Identifikation der voneinander abhängigen Systemkomponenten. Das Ergebnis einer solchen Analyse ist dementsprechend die Dokumentation des aktuellen „Ist-Zustands“ des Systems. Sobald diese Analyse abgeschlossen ist, und der Ist-Zustand des Systems somit bekannt und dokumentiert ist, ist die häufig größte Hürde auf dem Weg in die Cloud bereits überwunden, und einer technischen Umsetzung stehen in der Regel keine signifikanten Hindernisse mehr im Weg.
Was ist Ihrer Erfahrung nach beim Weg in die Cloud auf organisatorischer Ebene zu beachten?
Dr. Seiler: Auf arbeitsorganisatorischer Ebene ist zu beachten, dass möglichst sämtliche Ebenen eines Unternehmens mit eingebunden sein sollten, um eine erfolgreiche Cloud Journey gewährleisten zu können. Offensichtlich ist es, dass für eine solche Journey Software Entwickler, Cloud Architekten und im Bereich des Software-Betriebs angesiedelte mit einzubinden und für diese zu begeistern sind. Daneben muss aber zum Beispiel eine entsprechende Strategie auch die Personalabteilung entsprechend durchdringen, damit dort bekannt ist, dass die für eine erfolgreiche Umsetzung einer solche Strategie auf dem Markt die entsprechenden Fachkräfte gewonnen werden müssen, da diese erfahrungsgemäß zu dem Zeitpunkt des Einstiegs in die Cloud Journey noch nicht im Unternehmen vorhanden sind, da sie bis dato nicht benötigt wurden.
Dieses gilt gegebenenfalls analog ebenfalls für den Einkauf eines Unternehmens, sofern ein solches die initial benötigen Ressourcen beziehungsweise Fachkräfte nicht selbst einstellen will, sondern bevorzugt auf externe Unterstützung zurückgreifen möchte. Nicht zuletzt ist es so, dass ebenfalls auf „C-Level-Executive“-Ebene ein entsprechendes Bewusstsein vorhanden sein oder geschaffen werden muss, um eventuellen intern auftretenden Widerständen zu begegnen, organisatorische „Steine“ aus dem Weg zu räumen – „das haben wir aber immer so gemacht“ ist hier ein häufig gehörter Einwand -, und sowohl eine personell als auch betriebswirtschaftlich solide Planung der Cloud Journey zu gewährleisten.
Daneben ergeben sich aufgrund der neuen Strukturen und Vorgehensweisen beziehungsweise Vorgehensmodelle, welche oftmals bei der Entwicklung in der Cloud Anwendung finden oder Anwendung finden sollten gewisse Verschiebungen bezüglich „alter“, das heißt lange Zeit vorhandener Zuständigkeiten. Beispielsweise gab es traditionell oftmals eine mehr oder minder harte Trennung zwischen der Entwicklung einer Software einerseits, und dem Betrieb dieser andererseits. Bei der Entwicklung in der Cloud wird hingegen sehr oft dem „DevOps“-Ansatz gefolgt, bei dem das Team, welches eine Software oder eine Softwarekomponente entwickelt hat, ebenfalls auch für den Betrieb dieser zuständig ist – im Englischen oftmals beschrieben als „You build it, you run it!“.
Dementsprechend sind hier dann die gegebenenfalls neuen Zuständigkeiten zu klären, eventuell auch neue Rollen – wie eben zum Beispiel genau die eines DevOps-Engineers – einzuführen, und die diese neuen Rollen besetzenden Personen für ihr potentiell neues Aufgabenspektrum zu begeistern.
[Quelle:
CloudComputing Insider]
Schreibe einen Kommentar