Die Zukunft des IT Service Managements im Cloud-Zeitalter (Teil 4)


Gastbeitrag von Jochen Ott, IT Service Management Architect bei Microsoft Deutschland

Im letzten Beitrag dieser Serie ging es darum, Verantwortungsbereiche zusammenzulegen und dadurch neue und moderne Strukturen zu schaffen. Warum sollte das zentrale (klassische) Monitoring aufwändig nach der Definition einer Monitoring-Regel suchen, wenn die Applikations- oder Service-Verantwortlichen die Antwort bereits haben?

Steigen wir in das Thema „neue Strukturen“ eine Ebene höher ein: Es gibt Tool-Teams in heutigen IT-Organisationen. Jedes Problem, jede Fragestellung lässt sich mit einem passenden Tool lösen – Monitoring Tools, Incident Management Tools, Desktop Management Tools, etc. Zusätzlich gibt es die Service Management-Verantwortlichen. Hier finden sich eher prozessorientierte Denkmethoden wieder. Hinzu kommen noch die technischen Teams, denen bereits fertige Tools zu viel Aufwand bedeuten. Typischerweise gelten die rein prozessfokussierten Menschen eher etwas abgekoppelt. Der Wunsch der anderen Gruppen, dass Prozesse die Tools-Enthusiasten und die Technik-Freaks verbinden können, lässt sich nicht immer verwirklichen. Die gegenseitige Befruchtung der drei Gruppen bleibt oft aus, denn es ist schwierig, sich aus dem eigenen Silo heraus zu bewegen.

Wie könnte diese gegenseitige Befruchtung aussehen? Wir müssen sicherlich einen großen Schritt voran gehen. Service Management muss lernen, wie ein Applikationsentwickler zu denken. Entwickler müssen in Zukunft Teil der Service Management Teams sein – und umgekehrt. DevOps (Modern Applications) ist für eine lange Zeit als Dev+Ops anzusehen. Prozesse, Tools, System-Integration-Code, Daten und Reporting müssen vereinigt werden, neue Analysemethoden kommen hinzu. Es entsteht ein harmonisierter, schlanker und hoch effektiver Weg zur Unterstützung der Prozesse und Ziele einer Organisation (des Business).

Das ist Modern Service Management.

Modern Service Management ist nicht in Stein gemeißelt, es wird sich bewegen, sich weiterentwickeln. Dies muss ein eingebauter Mechanismus sein, wenn die IT nicht wieder Gefahr laufen will, dem Business hinterher zu rennen. Es geht nicht um die Umsetzung, also eine Reorganisation im klassischen Sinn. Nur durch das Einrichten von neuen Gruppen und Abteilungen sowie das Umverteilen von Menschen in diese neuen Gruppen wird die notwendige Bewegung nicht entstehen. Das Team, das gemeinsam einen modernen Service betreibt, braucht auch abgestimmte Ziele, eine allen gemeine Art und Weise, mit der der Service erfolgreich angeboten werden kann – auch wenn es ein virtuelles Team sein sollte. Mitarbeiter müssen lernen umzudenken, alte Strukturen zu verlassen. Das Thema People Change Management ist einer der drei Kernbestandteile einer modernen IT-Organisation. DevOps (oder Varianten davon) und Modern Service Management bilden die beiden anderen Pfeiler.

Obwohl ich von Umdenken spreche, wird es nicht notwendig sein, alles Bewährte abzuschütteln. Ein Beispiel: Release Management wird bestehen bleiben, auch wenn Teile davon in der Welt des Modern Service Management bei DevOps angesiedelt sein werden. DevOps hat u.a. zum Ziel, eine Release Pipeline zu erstellen, Updates müssen kontinuierlich und mit deutlichem geringerem Aufwand für Testing und Deployment verteilt werden können. Der Grundgedanke des Release Management und auch die Spezialisten auf diesem Gebiet werden bleiben.

Im nächsten Beitrag möchte ich gemeinsam mit meinem Kollegen Martin Reincke tiefer in die zukünftige Welt eines „Service Monitoring Service“ einsteigen. Wird es nur noch ein Tool geben? Was müssen wir überhaupt in Zukunft überwachen? Was kommt aus anderen Bereichen (z.B. der Datenanalyse) hinzu?

 


Dieser Beitrag ist Teil einer mehrteiligen Artikelserie. Autor der Serie ist Jochen Ott, IT Service Management Architect bei Microsoft Deutschland.

Serie: Die Zukunft des IT Service Managements im Cloud-Zeitalter

Comments (0)

Skip to main content