Das sollte ein SLM-Tool können

„Eine spezifische Marktevaluierung sollte immer auf der Grundlage eines individuellen Anwendungsfalles erfolgen."

Zum Abschluss der Beitragsreihe zu meiner Bachelorarbeit „Definition und Umsetzung von Service-Level-Metriken für die Applikations-Performance aus Endanwendersicht“ möchte ich noch auf das Anforderungsprofil für ein Service-Level-Management-(SLM-) Tool eingehen und Ihnen einen kurzen Marktüberblick – natürlich ohne Anspruch auf Vollständigkeit – vermitteln.

Zentrale Anforderung: Sammeln und Auswerten der definierten Metriken

Auf die Bedeutung von Kennzahlen und Metriken bin ich ja bereits im zweiten Beitrag der Beitragsserie eingegangen. Da in der Praxis die Anzahl und Vielzahl von Metriken schnell steigt, ist eine Software-Lösung erforderlich, die dieses Volumen auch bewältigt, d.h. automatisiert sammelt und auswertet.  Konkret bedeutet dies, dass die Metriken auf eine geeignete Art und Weise abgebildet und dann den definierten IT-Services zugeordnet werden. Um dann den Erfüllungsgrad der Service Level auswerten zu können, müssen Messpunkte der Services mit einem Messkonzept zuverlässig überwacht werden.

In meiner Arbeit habe ich versucht, eine Anforderungssammlung zu erstellen, die die Notwendigkeit eines integrierten Gesamtsystems verdeutlicht. An dieser Stelle nochmals herzlichen Dank an meine Kollegen bei amasol, die mir beim Erstellen des Anforderungskatalogs geholfen haben.

Als Grobschema wurden die folgenden Anforderungskategorien definiert:

  • Definition der SLM-Objekte
  • Servicekatalog und Leitungsstrukturen
  • Management von SLAs
  • Management von Dienstlieferanten
  • Management der Dienstqualität
  • Schnittstellen zu Prozessen und Datenquellen
  • Grundsätzliches Verwenden des Tools
  • Tool-Hersteller

Die einzelnen Kategorien wurden dann mit drei Prioritätsstufen gewichtet:

  • Prioritätsstufe 1: essenziell
  • Prioritätsstufe 2: erforderlich
  • Prioritätsstufe 3: optional

Die Darstellung des kompletten Anforderungskatalogs würde den Umfang dieses Beitrags sprengen, ich kann ihn aber bei Interesse gerne auf Anfrage zur Verfügung stellen.

Marktüberblick: Sammeln und Überwachen vs. Verarbeiten

Betrachtet man derzeit den Markt für SLM-Softwarelösungen, so muss generell zwischen Lösungen zum Sammeln und Überwachen der Metriken und Lösungen, die diese Metriken auch verarbeiten, unterschieden werden. Zum Messen der Applikations-Performance bietet der Markt eine Vielzahl von Produkten. Der „Peer Insights“ von Gartner in der Kategorie APM enthält allein ungefähr 25 Produkte.

Die Software-Lösungen sind dabei häufig in unterschiedliche Pakete unterteilt, die jeweils nur eine bestimmte Funktionalität abdecken. Darüber hinaus setzen die Hersteller auf verschiedene Messmethoden und -technologien. Um aber eine Gesamtlösung zu erhalten, müssen diese Einzelprodukte zu einem „Bundle“ zusammengefasst werden. Problem in der Praxis: Häufig arbeiten die Programme nur mit Systemen des gleichen Herstellers zusammen.

Auch für die Auswertung der erfassten Metriken gibt es auf dem Markt mittlerweile eine ganze Reihe von Lösungen.  Diese werden in der Regel unter der Kategorie IT-Servicemanagement (ITSM) geführt, ein direkter Vergleich dieser Lösungen istallerdings häufig nicht möglich. Der Grund: Die Lösungen sind aus einer Kombination aus Hard- und Softwareverwaltungsprogramme sowie Help-Desk-Tools entstanden und damit kaum vergleichbar. Darüber hinaus wird die Definition, was ITSM genau ist, von sehr differenzierten Begriffserklärungen und Sichtweisen beeinflusst.

Deshalb mein Tipp: Eine spezifische Marktevaluierung sollte immer auf der Grundlage eines individuellen Anwendungsfalles erfolgen.

Das SLM-Toolset der amasol AG

Als naheliegenden Anwendungsfall aus der Praxis möchte ich zum Abschluss kurz zwei SLM-Lösungen vorstellen, die bei der amasol AG im Portfolio sind und für meine Arbeit zu Einsatz kamen:

Dynatrace Managed diente als Monitoring- Lösung und zeichnete Messdaten der amasol -Anwenderaktionen durch Real User Monitoring auf. Zusätzlich wurden auch synthetische Messwerte von externen Messstationen des Herstellers einbezogen. So konnte ich die Kennzahlen „optische Vollständigkeit“ und „Verfügbarkeit“ eines amsaol-internen Service messen.

Apptio Digital Fuel ITBM wurde für die Abbildung der Metriken verwendet. Die Messdaten aus Dynatrace wurden über eine Schnittstelle an ITBM angebunden und anschließend systematisch verarbeitet und aufbereitet. Damit wurde exemplarisch die SLA-Tauglichkeit der Metriken nachgewiesen.

Falls Sie Fragen zu den hier vorgestellten Produkten haben oder weitere Informationen benötigen, stehen Ihnen meine Kollegen jederzeit gerne zur Verfügung.

Damit endet die Beitragsserie zu meiner Bachelorarbeit „Definition und Umsetzung von Service-Level-Metriken für die Applikations-Performance aus Endanwendersicht“. Ich hoffe, ich konnte Ihnen einige interessante Denkanstöße zum Thema Service Level Management vermitteln.

Wenn Sie sich mit mir über die Inhalte meiner Arbeit oder das Thema Service Level Management austauschen möchten, erreichen Sie mich unter dominik.hecker@amasol.de.

<< Zum vorherigen Beitrag: Von der Messzahl zur Beurteilung der Performance