Devops

IT as a Service – Die 5 Service Design Regeln für 2015

Das neue Jahr hat bereits begonnen und eh man sich versieht, steckt man bereits wieder mitten im Alltag und lässt sich durch die operative Hektik treiben. Bevor man jedoch wieder völlig abtaucht, tun diese ruhigen Tage zu Beginn eines Jahres immer auch gut, voraus zu blicken. Das Wort „Veränderung“ mag man schon gar nicht mehr hören – es kommt eh wie es muss. Die Frage ist bloss, ob man sie ignorieren will oder sich und das Unternehmen darauf ausrichtet.

 

Papst-Besuch 2005-2013

Papst-Besuch 2005-2013

Was auf uns zukommt, ist enorm (Sehen Sie dazu die Prognosen von Gartner für 2015 und danach). Wenn vor ein paar Jahren noch über die Veränderungen für IT-Organisationen über die Mobilität und die Cloud-Dienste gerätselt wurde, steht man heute vor vollendeten Tatsachen. Das Business nutzt diese Dienste mit oder ohne die eigene IT-Organisation. Das digitale Business-Zeitalter ist aus den Kinderschuhen raus. Die neuen Technologien ermöglichen auch völlig neue Geschäftsmodelle, welche von den traditionellen Markt-Beherrschern noch allzu oft belächelt wird. Das hat auch Nokia als Weltmarktführer im Mobilemarkt gemacht, als Apple im 2007 sein erstes iPhone lancierte (The Great Disruption: The Story of Nokia and Apple).

Man bezeichnet dies als „Disruptive Innovation“. Mit „Internet-of-Things“ können heute Lösungen realisiert werden, welche noch vor ein paar Jahren undenkbar waren. Beispielsweise ist der Zahlungsverkehr als klare Domäne der Banken nun massiv unter Druck geraten (Lesen Sie dazu den Beitrag von CapGemini vom Oktober 2014: Disruptive Innovation In Payments – Who Will Win In The Brave New World?. Es gibt noch viele Banken, welche diese neuen Trends belächeln und noch nicht einmal eine Auswirkungs-Studie für die eigenen Geschäftsprozesse gestartet haben.

Time-to-Market wird für die meisten Unternehmen ein absolutes Killerkriterium werden. Da mag man als alter IT-Hase vielleicht auch nur müde lächeln, da dies schon immer so gesehen wurde: Qualität braucht Zeit – mit Druck erhält zwangsläufig schlechtere Produkte. Nun ist man aber mit solch einem Tempo konfrontiert, dass traditionelle Projekt- und Entwicklungsmethoden einfach nicht mehr Schritt halten können. Es kann sich glücklich schätzen, welcher dieser Herausforderung heute noch nicht ausgesetzt sieht. Ihm bleibt vielleicht etwas mehr Zeit, sich darauf auszurichten. IT-Organisationen müssen sich aber darauf einstellen, Lösungen und Wege zu finden, schnell agieren zu können und trotzdem hohe Qualität zu produzieren.

Der Service Design wird für Unternehmen eine der zentralen Schlüsselrolle spielen und massgeblich Einfluss darauf haben, ob ihre Businessprozesse mit den Anforderungen der Zukunft standhalten können. Die IT muss dabei als umfassende Service-Leistung erbracht werden. IT as a Service (ITaaS) ist dabei nicht ein neues Cloud-Modell, sondern bezeichnet das business-orientierte Betriebsmodell, wie IT ganzheitlich als Dienstleistung erbracht werden soll. Der Fokus liegt auf schnelle und sichere Bereitstellung von Services an das Business – unabhängig wer alles daran beteiligt ist und von woher Leistungen bezogen werden.

Im Folgenden habe ich 5 Service Design Regeln für 2015 zusammengestellt, welche IT-Organisationen helfen sollen, sich auf die spannende Zukunft vorzubereiten:

1. Devops als Basis für kontinuierliches Service Deployment

Devops

Devops

Zwischen Entwicklung und Betrieb von Services besteht heute allzu oft noch ein sehr grosser Graben. Schnelle Einführungen und stabiler Betrieb sind nicht unbedingt kongruente Ziele (Sehen Sie dazu unser Beitrag dazu: Change? oder Projekt? oder was?). Das Release Management wird heute in vielen Organisationen zu einer Herkulesaufgabe mit zeitaufwendigen Entwicklungs-, Test- und Produktionsabnahmeverfahren.

Devops ist eine neue Methode, welche exakt hier ansetzt (Siehe dazu unseren Beitrag: ITIL® oder Devops, oder was?). Letztlich ist es ein interdisziplinäres Zusammenarbeiten zwischen Entwicklungs- und Betriebsverantwortlichen. Die Test- und Release-Verfahren müssen vereinfacht, standardisiert und automatisiert werden, um die Transformation von der Entwicklung in die Produktion zu beschleunigen.

Für das Design von neuen Services bedeutet dies, dass nicht nur die Lösung im Design betrachtet werden muss, sondern insbesondere auch in die Automatisierung der Releases investiert werden. Das Design der Releases muss so ausgestaltet werden, dass häufiges und kontinuierliches Deployment möglich wird.

Das heisst jetzt nicht, dass alles sofort umgestellt werden muss. Es empfiehlt sich aber, bei einem grösseren Vorhaben dies gleich als Pilot zu testen, um Erfahrungen intern sammeln zu können.

2. Agilität in Service Entwicklung

Agile SW Entwicklung

Agile SW Entwicklung

Das klassische Wasserfall-Konzept bei Service-Projekten funktioniert heute schlicht nicht mehr, um die Dynamik der Business-Anforderungen zeitgerecht in mehrwert-generierende Services umsetzen zu können. Vielfach ist das Bild der neuen Lösung zu Beginn des Projekts für das Business noch gar nicht klar und trotzdem muss gestartet werden können. Anforderungen können sich auch laufend wieder verändern. Was kümmert mich die Projektidee und die Vorstudie von gestern…

Das Business braucht einen IT-Partner, welcher ihn dabei nicht ständig mit Verträgen (SLAs, Projektbrief etc.) festnagelt um dann bei jeder Änderung der Anforderungen mit neuen Zeit- und Budgetplänen zu nerven. Die IT-Organisation muss auch hier Lösungen finden, um Service-Entwicklungen in der Dynamik des Business vorantreiben und umsetzen zu können. Agilität durch die SCRUM-Methode in der Software-Entwicklung ist dabei bereits in verschiedenen Unternehmen heute bereits umgesetzt worden (Lesen Sie dazu unseren Beitrag: Agiles Projekt-Management mit Scrum – Das Erfolgsrezept hinter Google, Apple & Co).

Anforderungen werden laufend in ein Backlog aufgenommen und mit abgestimmter Priorität im Rahmen von Sprints umgesetzt. Automatisierung von Releases und kontinuierliches Deployment in die Produktion sind dabei Voraussetzungen für Stabilität und Sicherheit.

 

3. Design für die Integration von Cloud-Services

Cloud Computing

Cloud Computing

Der CIO ist dafür verantwortlich, dass durch die Investitionen in die IT ein positiver Return für das Unternehmen erwirtschaftet werden kann. Die Betrachtung, dass letztlich das Business entscheiden muss, was rentabel ist und was nicht, greift heute vielfach zu kurz. Der CIO muss die Leistungen, welche zur Erbringung der Services notwendig sind, aus betriebswirtschaftlicher Sicht besser hinterfragen. Wo kann die interne IT sich noch differenzieren und wo bietet der Markt heute bessere und kostenoptimalere Lösungen. Welche Bereiche kann ich heute einfacher aus der Cloud beziehen und wo lässt sich eine Eigenentwicklung rechtfertigen.

Es mag wohl immer noch viele berechtigte Gründe geben, aus Sicherheitsgründen auf Cloud-Dienste für Regulations- und Nachweispflichtige Transaktions-Daten verzichten zu müssen. Die Sicherheitstechnologien werden aber zunehmend so stark, dass nicht nur Infrastrukturen sondern vermehrt auch ganze Applikationen und Services sicherer in der Cloud betrieben werden können als lokal. Siehe dazu den Artikel: Six cloud security predictions for 2015. Die Integration solcher Lösungen aus der Steckdose in die bestehende Service-Landschaft zu sogenannten Hybrid-Lösungen wird immer mehr zum Normallfall werden.

Bei der Entwicklung von neuen Services sollen die Vorteile von Cloud-Services direkt in die Lösung mit designt werden:

  • Self Service: Nicht nur die eigentliche Lösung soll designt werden, sondern auch, wie der Service aufgerufen wird.
  • On Demand: Design einer automatischen Provisionierung, damit der Service per Mausklick automatisch aufgeschaltet werden kann
  • Elastische Kapazität: Ressourcen elastisch hinzufügen und auch wieder loswerden verlangt eine Architektur, welche es ermöglich horizontal über mehrere Datacenter skalieren zu können
  • Hohe Verfügbarkeit und Verlässlichkeit der Services: der Service muss so designt werden, dass er überwacht werden kann und dass ein nahtloser Failover möglich wird.
  • Zahlung nur für Leistungen, welche auch tatsächlich genutzt werden: Entsprechende Metriken müssen für den Service designt werden.

4. Design des Betriebs- und Supportmodells

In einem Umfeld, in welchem mehr und mehr Leistungen von extern eingekauft und via Sourcing- oder Cloud-Modellen bezogen werden, ist das Betriebs- und Supportmodell eine zentrale Herausforderung. Gibt es noch eine zentrale Support-Anlaufstelle? Wer überwacht die Störungsbehebung, wenn mehrere Lieferanten involviert sind? Wie sind die Zuständigkeit und das Meldewesen organisiert?

In einem hybriden Betriebsumfeld sind die Zusammenarbeit und die Koordination ein wesentlicher Erfolgsfaktor. Lesen Sie dazu unsere Blog Beiträge: IT Transformation and the “Target Operating Model” Approach und Cloud Services and the definition of a Target Operating Model.

Zum Design eines neuen Services gehört auch die klare Regelung des Betriebskonzepts sowie der Support-Organisation. Das ist mit dem Übergeben der Lösung an den Betrieb nicht mehr gewährleistet. Vielmehr muss sich gerade der Service Design um die Planung und Konzeption der Gesamtlösung kümmern, damit es im Betrieb nicht zu Konflikten und gegenseitiger Schuldzuweisung zwischen den Akteuren kommt. Der folgende Blog-Beitrag bringt es auf den Punkt: Service Design Package – die unbefleckte Perle von ITIL®.

5. Design der Cloud- & Sourcing Regeln

Schon über 90% der Unternehmen beziehen Cloud-Services auf die eine oder andere Art. Jedoch bloss ein Drittel davon hat eine klare Cloud- und Sourcing-Strategie, geschweige denn klare Governance-Regeln innerhalb der Organisation. Wenn die Verträge unterschrieben sind, wird es schwierig, sich im Nachhinein über Rollen und Verantwortlichkeiten zu streiten. Auch wenn man heute noch sehr skeptisch gegenüber den neuen Service-Liefermethoden stehen mag, so lohnt sich eine klare und mit der Geschäftsführung abgestimmte Positionierung sehr. Es gibt gute Gründe für den sicheren Weg in die Cloud.

Mit der Auslagerung von geschäftsrelevanten Funktionen zu einem Outsourcing-Partner oder in die Cloud, werden die Verantwortlichkeiten der ordnungsmässigen Abwicklung nicht automatisch mit ausgelagert. Sie bleibt beim Unternehmen und stellt dieses vor einer schwierigen Herausforderung: wie kann ich sicherstellen, dass mein Service Provider die Kontrollen einhält, dass die Funktionstrennung gewahrt wird und dass die Zugriffe auf Daten geschützt bleiben? Lesen Sie dazu den letzten Blogbeitrag: Vertrauen ist gut, Kontrolle ist besser: ISAE 3402.

Das Arbeitsumfeld in der IT-Organisation wird sich verändern und bekommt neue Facetten, welche in den heutigen Berufsbildern noch nicht genügend ausgeprägt sind. Um den Mitarbeitern jedoch eine Perspektive aufzeigen zu können, sollte diese Veränderung thematisiert und die Mitarbeiter dazu gewonnen werden. Wie sich die Rolle des Service Owners verändert, können Sie hier lesen.

Diese 5 Service Design Regeln sollen helfen, sich schrittweise auf das vorzubereiten, was eh kommt. Ob dies nun radikal kommt oder gradual umgestellt wird, wird das Business aufzeigen. Ich bin überzeugt, dass mit den Disruptive Innvoationen keine sanfte Migration in die neue Technologien mehr möglich sind. Die Hemmschwelle, alte Technologien und Applikationen einfach über Bord zu werfen, wird mit zunehmender Komplexität sinken. Die Herausforderungen werden wohl auf der Datenebene auftreten. Folgende Fragen sollten jedoch bei jedem Service Design in Zukunft beantwortet werden:

  • Sollen wir den Service selber bereitstellen?
    • Haben wir gerechtfertigtes Potential für die Differenzierung?
    • Geht es darum, die Gesamtkosten zu senken?
    • Gibt es Sicherheits- oder Regulatorische Hemmnisse?
  • Ist ein hybrides Service Modell angemessen?
    • Offerieren wir für das Business eine Kombination von eigenen und eingekauften Services und sind wir transparent?
  • Welchen Mehrwert kann die IT-Organisation als Service-Broker liefern?
    • Supplier-Management
    • Architektur, Integration und Configuration Management
  • Was ist das Support-Modell?
    • Was ist der Umfang des Supports, welchen die IT leisten soll? Was ist der Umfang der Lieferanten?
    • Wie ist die Kommunikation geregelt?
    • Wie erhalten wir Visibilität im Incident Lifecycle?

Ich wünsche Ihnen einen ganz tollen Start im Jahr 2015 und hoffe, dass all Ihre Vorhaben erfolgreich umgesetzt werden können. Nehmen Sie das Steuer in die eigenen Hände und schreiben damit die Erfolgsgeschichte in ihrem Unternehmen mit.


 

1 Comment
  • markus yaldu

    11. März 2015 at 14:29 Antworten

    Sehr guter Artikel , besonders der Part Agilität in der Service Entwicklung bringt es auf den Punkt.

Post a Comment