Service Level Agreements für Softwarewartung
SLAs sollten sich nicht an dem orientieren, was möglich ist, sondern daran, was nützlich ist: Beispielsweise macht es keinen Sinn eine höhere Verfügbarkeit als nötig oder Hochverfügbarkeit außerhalb der Betriebszeiten zu vereinbaren. Andererseits bedeutet das, dass SLAs potentiell sehr herausfordernd sein können. Aber nur wenn diese Herausforderungen gemeistert werden, sind die diesbezüglichen SLAs auch nützlich. → Damit SLAs nützlich sind, müssen diese die Bedingungen schaffen, dass die Software den angestrebten Nutzen erbringen kann.
Die Nützlichkeit von SLAs sollte sich am Businessnutzen orientieren: Beispielsweise sind bei Fehlern Reaktions- und Bearbeitungszeit für das Business irrelevant. Relevant ist bei Fehlern nur die Zeit bis ein für das Business akzeptabler Workaround und schlussendlich die Fehlerbehebung in Betrieb geht. SLAs sollten also hinsichtlich Fehlerbehebungen Vereinbarungen für Workarounds und Inbetriebnahme von Fehlerbeseitigungen enthalten. → Nützliche SLAs sind Vereinbarungen über die bestmögliche Sicherstellung des Businessnutzen
SLAs müssen frühzeitig vereinbart werden: Um bestimmte Service Levels erfüllen zu können müssen erst die Rahmenbedingungen geschafft werden, damit sie auch erfüllt werden können. Dafür sind schon frühzeitig Entscheidungen zu treffen. Beispielsweise können bestimmte Verfügbarkeiten nur mit bestimmten Softwarearchitekturen sichergestellt werden. → SLAs müssen sie frühzeitig vereinbart werden, damit Rahmenbedingungen geschaffen werden, dass die SLAs auch eingehalten werden können.
SLAs sind kein Ersatz für konstruktive Zusammenarbeit: Es sollte zwischen SLAs, die die Leistungen der Software bzw. ihrer Betriebsumgebung betreffen und SLAs, die die Zusammenarbeit von Menschen betreffen, unterscheiden werden. Letztere sollten so gestaltet werden, dass die handelnden Personen miteinander gemeinsam ein Ziel verfolgen und sich nicht gegenseitig Steine in den Weg legen können. → SLAs, die die Zusammenarbeit von Menschen betreffen, sollten die konstruktive Zusammenarbeit in den Mittelpunkt stellen.
SLAs hinsichtlich Zusammenarbeit von Menschen sollten gegenseitige Unterstützung ermöglichen: Beispielsweise sind Fehlerbehebungen nur dann effizient und effektiv, wenn Rückfragen bei und Tests durch die Einmelder möglich sind. Es macht keinen Sinn SLAs nur für die Behebung des Fehlers zu vereinbaren, wenn dann mangels schneller Rückantworten oder Tests der Fehler nicht oder nicht im Sinne des Anwenders behoben wird. SLAs sollten daher nicht nur die Aufgaben einer Seite, sondern die parteienübergreifende Zusammenarbeit beschreiben. → SLAs, die die Zusammenarbeit von Menschen betreffen, sollten immer den Gesamtprozess betreffen und nicht die einzelnen Schritte.
SLAs sollten immer alle gleichzeitig gelten: Es darf nicht sein, dass die Arbeit an "wichtigeren" SLAs verhindert, dass "unwichtigere" SLAs eingehalten werden. Dementsprechend sollten beispielsweise SLAs bezüglich Verbesserungen der Eigenschaften der Software (perfektionierende Wartung) nicht gegenüber SLAs hinsichtlich Fehler in der Software vernachlässigt werden dürfen. → SLAs müssen immer alle eingehalten werden. SLAs haben keine unterschiedlichen Prioritäten.
Dementsprechend sollte es auch keine Prioritäten bei Fehlerbehebungen geben: Auch unwichtige Fehler, die die Benutzer kaum beim Arbeiten mit der Software behindern, sollten zeitnah behoben werden. Das erspart die Kategorisierung der Fehler und reduziert damit Aufwand und potentiellen Streit. Darüberhinaus führt das zu weniger Fehlerbehebungsaufwand, da eine Behebung eines Fehlers lange nach seinem Auftreten wesentlich aufwändiger ist (z.B. weil sich das Verhalten des Systems inzwischen geändert hat oder der Einmelder sich bei Rückfragen nicht mehr korrekt erinnern kann). → Fehler sollten nicht kategorisiert werden und alle im Rahmen derselben SLAs behoben werden.
SLAs betreffen nicht nur Fehler beim Betrieb der Software: Ebenso wichtig sind SLAs für alle Wartungstätigkeiten, insbesondere perfektionierende Wartung (Verbesserung von Attributen wie etwa der Software-Ergonomie, Rechenleistung oder der Wartbarkeit) und adaptive Wartung (Anpassung der Software an veränderte oder veränderliche Bedingungen der Umgebung). → SLAs auch für Wartungstätigkeiten vereinbaren
SLAs inkludieren auch Drittsysteme, außer diese sind außerhalb des Einflussbereiches: Damit wird die Problematik der SLA-Inversion behandelt, also dass Drittsysteme, von denen die Software abhängt, ein Erreichen des Service-Levels unmöglich machen. Sobald die Verwendung eines Drittsystems im Einflussbereich des Projektes ist (wie es z.B. bei Frameworks und Libraries der Fall ist) und/oder die Service Levels des Drittsystems bekannt oder beeinflussbar sind, sollten die SLAs auch die Drittsysteme inkludieren. → SLAs sollten in den meisten Fällen auch Drittsysteme inkludieren - dazu sind aber deren Service-Levels vor Vereinbarung der SLAs zu berücksichtigen.
Fazit: Die Definition und Vereinbarung von sinnvollen Service Level Agreements ist keineswegs trivial, hat aber Einfluss auf die Software und ihren Betrieb und muss daher frühzeitig und gut erfolgen.