Eine flexible, schnelle und bedarfsabhängige Bereitstellung von IT-Dienstleistungen entwickelt sich zu einem wettbewerbskritischen Faktor. Dafür sorgen veränderte IT-Infrastrukturen, wie sie durch neue Middleware-Produkte, Storage Area Networks oder Grid-Netzwerke angeboten werden. Auch die künftigen Informationstechnologien wie Service-Oriented Computing (SOC) auf der Basis von Service Oriented-Architectures (SOAs), Service Component Architectures (SCAs) und Event Driven Architectures (EDAs) tragen dazu bei. Die dabei entstehende "Dienst-Lieferkette" (Service Supply Chain oder Business Services Network) aus Endkunden, Applikationsanbietern und verschiedenen externen IT-Dienstleistern führt zu einem komplizierten Beziehungsgeflecht mit unterschiedlichen Leistungsanforderungen für die einzelnen IT-Dienste.

Die von Lieferketten bekannten Probleme

Dabei können Probleme auftreten, wie sie aus herkömmlichen Lieferketten bekannt sind: zum Beispiel der "Bullwhip"-Effekt, bei dem sich kleinere Störungen schnell entlang der gesamten Kette aufschaukeln und bis zu deren Stillstand führen können. Deshalb ist es von zentraler Bedeutung, die IT-Leistungen in verlässlicher Form und der vereinbarten Qualität zu erhalten. Das gilt insbesondere, wenn das Kerngeschäft direkt von den bezogenen Leistungen abhängt. Zu diesem Zweck werden Dienstgüteverträge, so genannte Service-Level-Agreements (SLAs), abgeschlossen. Software-Anbieter und IT-Dienstleister stehen vor der Aufgabe, eine Vielzahl individuell vereinbarter SLAs mit unterschiedlichen Leistungs- und Qualitätszusicherungen (Service-Levels) verwalten und überwachen zu müssen, um ein effizientes und automatisiertes IT Service Level Management (IT-SLM) und Business Activity Monitoring (BAM) zu ermöglichen.

Das IT-SLM gilt auf Grund seiner operationellen, strategischen und organisatorischen Auswirkungen als einer der zentralen Prozesse in der IT-Infrastruktur- Library (Itil) sowie dem BS15000-ISO-Standard für das IT-Service-Managements (ITSM). IT- und Business-Service-Management-Werkzeuge mit umfangreichen Visualisierungsmöglichkeiten (zum Beispiel Service Dashboards oder auch BAM Enterprise Cockpits) von Herstellern wie BMC, CA, Hewlett-Packard oder IBM entwickelten sich in letzter Zeit zu einem rasch wachsenden Markt. Das Hauptproblem derzeitiger Werkzeuge ist die fehlende Ausdrucksmächtigkeit und die starre Implementierung von SLA-Vertragsregeln, komplexen Ereignismustern (Complex Event Patterns) und Metriken, die sich lediglich über vordefinierte Parameter mit Schwellwerten im Rahmen der Anwendungslogik der SLM-Werkzeuge steuern lassen. Die dynamische und flexible Operationalisierung neuer individueller SLA-Regeln und Vertragsmodelle erfordert zumeist eine zeit- und kostenintensive Reimplementierung der Anwendungslogik und der dazugehörigen Datenbankmodelle. Sie ist in der Praxis kaum möglich.

Bestehende Ansätze für die SLA-Automatisierung

Die Ansätze zum Formulieren und Automatisieren von SLAs und die darin enthaltenen Regeln entfallen im Wesentlichen auf eine der folgenden zwei Kategorien:

1. Operationalisierung von Vertragsregeln in der Applikationslogik oder Datenbankschicht von SLM-Werkzeugen.

2. 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 System-Management-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ürden 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.

Den Sprachen fehlt die Ausdruckskraft

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 im 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 aufgrund der fehlenden präzisen logischen Semantik nur eingeschränkte Möglichkeiten, um die Korrektheit der SLA-Regelspezifikationen zu verifizieren und validieren, die Ergebnisse zur Laufzeit vorherzusagen und dabei Robustheit und Nachvollziehbarkeit sicherzustellen.

Die Vorteile der logischen Programmierung

Automatisierte Vertragsregeln können auf verschiedene Weise repräsentiert werden, zum Beispiel als "If-then" -Konstrukte in prozeduralen Programmiersprachen wie Java oder C++ (inklusive Kontrollfluss), Entscheidungstabellen/-bäume, Wahrheitswert-Konstrukte basierend auf allgemeiner Implikation und Boolscher Logik, Implikationen mit Restriktionen (etwa OCL), Trigger und Effektoren (etwa SQL-Trigger) oder Ansätze basierend auf Untermengen der Prädikatenlogik (First Order Logic) wie die logische Programmierung (LP). Die wesentlichen Vorteile der logischen Programmierung liegen in der kompakten deklarativen Darstellung von SLA-Regeln und der automatischen Regelverkettung und Ausführung mittels generischer LP-Regelmaschinen. Bestehende Regelbasen lassen sich damit einfach erweitern und von der Bürde einer extensiven Implementierung des Kontrollflusses, wie in der prozeduralen Programmierung, befreien.

Darüber hinaus stellt die logische Semantik sicher, dass die produzierten Ergebnisse korrekt und nachvollziehbar sind. Regelbasierende Systeme wurden in den letzten zwei Jahrzehnten intensiv in der deklarativen Programmierung und in Expertensystemen untersucht. In letzteren setzten Unternehmen, die von einem sich schnell verändernden Geschäftsfeld herausgefordert wurden, solche Systeme für das externe Formalisieren und Ausführen von Geschäftsregeln ein. So konnten sie langsame und teure IT-Änderungszyklen beschleunigen. So genannte Geschäftsregel-Management-Systeme (Business Rules Management Systems = BRMS) erlauben es, Geschäftsregeln getrennt von der Anwendung in möglicherweise dezentralen Modulen zu verwalten und zu pflegen. Diese lassen sich zur Laufzeit in die eigentliche Anwendung integrieren.

Wer sie nutzt, setzt das deklarative Prinzip der "Trennung der Belange" (Separation of Concerns Principle) um, das bereits erfolgreich in vielen anderen Gebieten der Softwareentwicklung angewandt wurde. Die grundlegende Idee ist, dass Benutzer Regeln verwenden, um auf einfache Weise auszudrücken, was sie wollen. Die Verantwortung, diese Wünsche zu interpretieren und zu entscheiden, wie das Problem zu lösen ist, wird der generischen Regelmaschine übertragen. Frühe Stadien der Geschäftsregelmaschinen (Business Rule Engines = BREs), die ihre Wurzeln in der Künstlichen Intelligenz (KI) und in logischen Inferenzsystemen haben, waren komplex, teuer und nicht sehr benutzerfreundlich. Die aktuelle Generation der Regelmaschinen und regelbasierenden Technologie ist brauchbarer und reifer für den industriellen Einsatz.

Complex Event Processing erlaubt Echtzeitreaktionen

Ähnlich wie der regelbasierende Ansatz lässt sich auch die komplexe Ereignisverarbeitung (Complex Event Processing = CEP) als aufstrebende Technik bezeichnen. Sie erlaubt es, komplexe relevante Ereignisse und Situationen aus einer Vielzahl operationeller Ereignisse (Event Cloud) oder einem oder mehreren Ereignissströmen zu entdecken. Damit ist eine (nahezu) Echtzeitreaktion auf Zustandsveränderungen möglich. CEP bildet somit einen wesentlichen Baustein für reaktive, ereignisgesteuerte Regeln im Realtime-SLM und BAM. CEP-Nachrichten oder atomare Ereignisdaten werden korreliert, aggregiert, analysiert und ausgewertet. Die neu generierten komplexen Ereignisinformationen dienen als Basis für weitere regelbasierende Entscheidungen und Reaktionen. Dabei arbeiten komplexe Ereigniskorelations-Maschinen (Event Correlations Engines) und Regelmaschinen eng zusammen oder werden sogar integriert.

Regel- und ereignisbasierende Technologien können zum Einsatz kommen, um Vertragsregeln in SLAs getrennt von der Anwendungslogik verwalten und dadurch flexibel erweitern, überwachen und ausführen zu können. Im Projekt Rule-Based Service-Level-Agreement (RBSLA) wurde ein entsprechendes Konzept zur einfachen Anwendung regelbasierender Technologien für die SLA-Repräsentation entwickelt. Ebenfalls entstand ein Softwaresystem zum effizienten Verwalten und Überwachen großer Mengen an Vertragsregeln aus beispielsweise Allgemeinen Geschäftsbedingungen, SLAs für Kunden(gruppen) oder auch Nutzungslizenzverträgen. Die wesentlichen Vorteile des vorgeschlagenen Konzepts sind:

Vertragsregeln werden getrennt von der Service-Management-Anwendung verwaltet und vereinfachen dadurch Pflege und Wartung;

kompakte Darstellung und automatische Verkettung von Vertragsregeln durch automatisierte Deduktion. Ein großer Teil der Anwendungslogik des SLA-Managements kann dadurch über generische Standardsoftwarekomponenten aus der logischen Regelprogrammierung realisiert werden;

automatische Reaktion auf eintretende Ereignisse (Complex Event Processing) durch reaktive Regeln;

automatisches Verifizieren, Validieren und Erkennen von Widersprüchen in den Vertragsregeln und Auflösung von Regelkonflikten durch die verwendete formale Logik;

Einbindung domänenspezifischer Begriffe aus Vertragsvokabularen über externe Ontologien.

Zur Architektur des implementierten RBSLA-Systems gehört die Open-Source-Regelmaschine Prova, eine ausdrucksstarke, effiziente und verteilte (Semantic)-Web-Inferenzregelmaschine. Sie dient als Ausführungsumgebung für die als logische Programme formalisierten Vertragsregeln. Die Regeln werden auf Basis des ContractLog-Wissensrepräsentations-Frameworks in der Prova-Ausführungssprache umgesetzt und in die interne Wissensbasis der Regelmaschine als modulare, möglicherweise im Web verteilte Regelbasen geladen. Die plattformunabhängige deklarative RBSLA-XML-Mark-Up Sprache wird für die Serialisierung der Regeln und den Regelaustausch verwendet.

Eine Benutzeroberfläche, der Contract Manager, wurde prototypisch für die Erstellung und Pflege der in RBSLA spezifizierten Verträge sowie deren Verwaltung in RBSLA-Projekten entwickelt. Die Projekte sind dabei entweder persistent in der Contract Base gespeichert oder werden extern als verteilte Projekte über das Web geladen. Das Repository beinhaltet typische, von Experten in natürlicher Sprache vorformulierte Regel-Templates und Domänen-spezifische Objekte, Metriken oder Vertragsvokabulare (Ontologien). Sie können auf einfache Weise zur Erstellung von SLA-Spezifikationen wiederverwendet werden.