2.3 SLM im Anwendungsszenario der DTS

In diesem Abschnitt wird nun die Frage behandelt, ob ein den Anforderungen der Service-Level-Agreements entsprechende Management-Architektur bei der DeTeSystem existiert, und wenn nicht, welche zusätzlichen Anforderungen erfüllt werden müssen.
Im Mittelpunkt der Betrachtung steht die zu erbringende und zu überwachende IT-Serviceleistung, wie z.B. Verfügbarkeiten, Antwortzeiten oder Transaktionszeiten aus dem Blickpunkt des Dienstnehmers, in unserem Anwendungsszenario also des Händlers. Nur so wird eine objektive Beurteilung von Leistungen möglich, wie sie heute schon in SLAs vereinbart, aufgrund von server-orientierten Ansätzen wie z.B. mittels Sitescope jedoch oftmals nur unzureichend oder in Näherung belegbar sind.
Wie in Abbildung 2.2 zu sehen ist, stellt sich die Situation derzeit so dar: Die DeTeSystem verfügt über Management-Applikationen in ihren SMCs (bzw. im SRZ) und in der ISA. Für die Überwachung von Service-Level-Parametern ist insbesondere eine in der ISA platzierte und mit Sitescope ausgestattete Testfiliale verantwortlich. Durch eine genaue Betrachtung der Architektur läßt sich schnell herausfinden, daß die hier gemessenen Werte nicht auf die Händlerlokationen übertragbar sind. Vielmehr können sie im besten Fall eine Annäherung an die dort gegebene Situation darstellen. Auch können Polling-Mechanismen in die Händlerlokationen kein realistisches Bild darstellen, da sie nur Momentaufnahmen sind und komplexe IT-Leistungen nicht messen können. Zudem sind sie finanziell auch nicht tragbar, da jedesmal eine ISDN-Verbindung aufgebaut werden muß.
Alle Händler sind über ein Weitverkehrsnetz an das VPN des Fahrzeugherstellers angebunden, das nicht dem direkten Zugriff der DeTeSystem unterliegt. Somit sind Störungen wie z.B. Überlastung der PoPs, Ausfälle von Routern o.ä. nicht auszuschließen. Zudem erhöhen sich z.B. Zugriffs- und Antwortzeiten der Dienste der Internet-Service-Area durch die Übertragung via T-InterConnect.
Im Rahmen dieser Arbeit ist eine Managementarchitektur mit Hilfe des JDMK zu entwickeln, die eine Überwachung und Dokumentation der relevanten Dienstgüteparameter in den Händlerlokationen ermöglicht.
Dazu müssen zwei Szenarien unterschieden werden:

1.

Standverbindung zwischen Händlerlokation und PoP des Weitverkehrsnetzes

2.

Wählverbindung zwischen Händlerlokation und PoP des Weitverkehrsnetzes

In beiden Szenarien ist es notwendig, Managementsoftware auf der Händlerseite zu installieren, da nur so netzwerkrelevante Daten von End-to-End Kommunikationsbeziehungen gemessen werden können. Auf diese Weise kann die unzureichende Messung der oben erwähnten Sitescope-Testfiliale sinnvoll ergänzt werden.
Dies hat neben der eben beschriebenen Notwendigkeit auch viele Vorteile. Einige sind im folgenden aufgeführt:

• Entlastung der zentralen Management-Applikationen
• Geringere Belastung des Netzes und des Managers durch Filterfunktionalität
• Weniger Netzlast in der Nähe der Management-Applikation durch Dezentralisierung der Pollingmechanismen
• Warnmeldung bei drohender Abweichung ermöglicht zeitgerechte Reaktion (proaktives Management)

Im folgenden werden die zentrale Anforderungen an eine Agenten-Architektur im Anwendungsszenario vertieft dargelegt und abschließend klassifiziert.