Die Ansätze zum Formulieren und Automatisieren von SLAs und die darin enthaltenen Regeln entfallen im Wesentlichen in eine der folgenden zwei Kategorien:
Operationalisierung von Vertragsregeln in der Applikationslogik oder Datenbankschicht von SLM-Werkzeugen;
externe Darstellung mittels formalisierter Sprachen - meistens in XML-Notation.
Kategorie 1 umfasst einen in letzter Zeit stark wachsenden Markt an SLM- und BAM-Tools, die zumeist aus den bereits bestehenden Qualitäts- und Systemmanagement-Produkten der Anbieter hervorgegangen sind und auf deren Funktionalität aufsetzen. Sie setzen vordefinierte QoS-Parameter wie Erreichbarkeit oder Antwortzeit direkt im Applikationscode oder der Datenbankschicht um. Werkzeuge wie der "IBM Tivoli Service Level Advisor" (TSLA) sammeln über bestehende System-Management-Werkzeuge relevante Daten über das Systemverhalten in einem Data Warehouse. Daraus werden Berichte erzeugt oder Mitteilungen über Störungen ausgesendet. Im Rahmen der vom TSLA vorgesehenen Parametrisierung ist eine Differenzierung der Dienstleistungsvereinbarungen nach Kundengruppen (Individuum, Abteilung, Division etc.) und Service-Level Klassen (SLA Gold, SLA Silber, SLA Bronze) mit unterschiedlichen Qualitätszusicherungen möglich.
Eine getrennte Verwaltung, Pflege und Anpassung der SLAs wird jedoch nicht unterstützt. Der Ansatz ist auf einfache, festgelegte SLA-Regeln beschränkt. Die dynamischen Anpassungen der SLAs an neue Anforderungen würde eine zeit- und kostenintensive Erweiterung des Anwendungscodes oder der Datenbankmodelle erfordern, da neue Vertragsregelungen nur im Rahmen der vorgegebenen Parameter realisiert werden können. Selbst dann, wenn es Werkzeuge erlauben, Parameter auf einfache Weise anzupassen, ist dieser Ansatz nicht flexibel und mächtig genug, um mit den sich ständig verändernden Anforderungen in modernen IT-Dienste-Architekturen und Realtime Enterprises Schritt halten zu können.
Ansätze der zweiten Kategorie wie zum Beispiel die Web-Service-Level-Agreements- (WSLA-)Sprache oder WS-Agreement sind reine syntaktische Beschreibungssprachen, die eine XML-Syntax ohne eine präzise logische Semantik definieren. Sie benötigen einen prozeduralen Interpreter zur Ausführung, haben eine eingeschränkte Ausdrucksmächtigkeit zur Beschreibung komplexer Entscheidungs-, Reaktions-, und Vertragslogik in Form von Regeln auf Basis von einfacher Wahrheitslogik (Material Truth Implication beziehungsweise Boolsche Logik). Sie stellen keine dynamischen Erweiterungsmöglichkeiten in Sinne einer deklarativen Programmierung neuer Funktionalitäten zur Verfügung. Erweiterungen der Sprache erfordern eine entsprechende Anpassung des prozeduralen Interpreters. Darüber hinaus bieten sie auf Grund der fehlenden präzisen logischen Semantik, nur eingeschränkte Möglichkeiten, um die Korrektheit der SLA-Regelspezifikationen zu verifizieren und validieren und die Ergebnisse zu Laufzeit vorherzusagen und dabei Robustheit und Nachvollziehbarkeit sicherzustellen.
