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


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

Typischerweise haben Unternehmen heute ein zentrales Monitoring, betreut von einem zentralen Team im Operations Center. Dieses zentrale Monitoring kümmert sich um Netzwerk, Server und Datacenter. Es betrachtet jedoch nicht ganzheitlich den IT Service. Hierfür ist es notwendig, mehr in die Tiefe zu gehen und aus einem horizontalen Monitoring ein vertikales Monitoring zu machen.

Ein wichtiger Ansatz dabei ist, das Entwickler-Team einzubinden. Entwickler wissen, wie ihre Apps reagieren und wann sie gesund sind. Durch den Einsatz von Tools und Monitoring Packs versucht man, den Anforderungen gerecht zu werden. Um eine Lösung handelt es sich hierbei allerdings immer noch nicht. Üblicherweise erhöht das alles aber nur den Aufwand im zentralen Monitoring-Team, denn unterschiedliche „Mini-Monitoring-Lösungen“ wollen eingebunden sein. Erhöhte Komplexität liefert keine besseren Aussagen in Bezug auf das Monitoring.

Die zweite Möglichkeit ist, dass das zentrale Monitoring-Team versucht, die Anforderungen des Application Monitorings zu verstehen. Das Team kommt aber meist nicht weit genug und nicht tief genug im Verständnis der App, um einen größeren Wertbeitrag zum Gesundheitszustand zu liefern. Das Betreiben der Monitoring-Plattform steht also immer noch im Vordergrund und nicht das Erstellen von App-spezifischen Monitoring-Regeln.

Fazit: Keine der beiden Möglichkeiten erreicht das Ziel eines „Service Monitoring Service“ als strategische Komponente in der IT-Organisation. Die Monitoring-Lösung muss also zu einer zentralen Komponente des Service werden, im Fokus muss der Service sein und nicht ein Server, eine Netzwerkkomponente oder eine Applikation. Das horizontale Monitoring des zentralen Monitoring-Teams muss mit dem vertikalen Monitoring der Applikationsverantwortlichen verbunden werden, aus dem „entweder oder“ muss ein „und“ werden.

Das zentrale Monitoring stellt weiterhin die standardisierte Plattform zu Verfügung: Konsole, Versenden von Nachrichten bzw. Alarmen sowie das Berichtswesen. Alles das, was bisher mit Bravour erbracht wurde, bleibt. Das Application- bzw. das Service-Team kommt hinzu und liefert Informationen wie „Incidents, die nicht über Monitoring ausgelöst wurden“, „Incident-Aufkommen pro Thema“, „aufgelaufene Alarme“ oder auch “Trendanalysen aus der Incident-Datenbank“. Es sind Messkriterien zu definieren und die Ergebnisse bedürfen der Analyse. Hat das Application- bzw. das Service-Team Zielvereinbarungen für genau diese Werte, ist davon auszugehen, dass die entwickelten Regeln erheblich besser sind als die Versuche des zentralen Monitoring-Teams in der Vergangenheit. Die hier zwangsweise benutzen Annahmen müssen nicht mehr getroffen werden.

Der Schlüssel ist also eine neue Struktur, die Umverteilung von Verantwortlichkeiten, bzw. vorab die präzise Festlegung der Verantwortungsbereiche. Wer kann am besten welchen Wertbeitrag liefern, muss eine zentrale Fragestellung sein und nicht, wer ein Fachthema am längsten und traditionell betreut. Im vierten Teil der Serie wird es um diese neue und moderne Struktur gehen. Wie kommen Service Management und Application Development zusammen?

 


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