The Spoken Word

In einer flexiblen Systemarchitektur, die nach service-orientierten Gesichtspunkten aufgesetzt ist, stellt die Überwachung eine besondere Herausforderung dar.Durch die sowohl technische wie auch fachliche Überwachung lassen sich während des Betriebs Trendlinien für die operative Gestaltung ableiten, aber auch Geschäftschancen ableiten.

Unter technischem Monitoring kann man dabei die folgenden Aktivitäten zusammenfassen:

• Überwachung des Systemzustands von deployten Komponenten (gestartet, gestoppt, etc.)
• Überwachen der Randsysteme (Zustand von DB-Tabellen, die ausgelesen werden, etc., Nachrichtenmengen in Queues)
• Überprüfung mögl. vereinbarter Service-Level-Agreements mit dem Ziel eines Frühwarnsystems

Unter fachlichem Monitoring kann man hingegen die folgenden Aktivitäten zusammenfassen:

• Überwachung des Auftragseingangs/Std.
• Überwachung von Auswirkungen durch fachl. getriebene Werbekampagnen
• Messung der Wartezeiten von Anrufern in Call-Centern

Dabei lassen sich viele Aufgabenstellungen im Umfeld BAM auf wenige, sehr gleichartige Prinzipien zusammenfassen:

• Bewertung von Daten anhand konfigurierter Kritierien
• Messung von Zeit, Anzahl, abgeleiteten Werten (z.B. Durchsatz)
• Eskalation bei Überschreitung von Schwellwerten (Trend-Breaks, etc.)

Wie konkret die einzelnen Aufgaben konkret realisiert werden, ist eigentlich gleich - von Bedeutung ist, dass diese gleichartig sind und damit auf die gleiche Art und Weise realisiert werden können.

Implementiert man abstrakte/generische Komponenten, die diese Aufgaben erledigen, meistens auf Basis von XML, erhält man eine investitionssichernde Applikation, die auch späteren Änderungen standhalten kann.

Eine mögliche Architektur für eine solche Komponente kann wie folgt aussehen:

• Erstellung von Adaptern für die einzelnen Zielsysteme. Diese greifen auf die Randsysteme zu und extrahieren die relevanten Daten. Diese liegen entweder in einem allg. Format vor, dass für die BAM Komponente allgemeingültig ist, oder in einem applikationsspezifischen Format auf Basis von XML. Sofern man für ein applikationsspezifisches Format votiert, hat das den Vorteil, das weniger Anpassungen an den betroffenen Randsystemen erforderlich sind. Dafür muss die Integration dann “vor” der BAM Komponente erfolgen.
• Erstellung einer Vorverarbeitung. Diese extrahiert die für den Trigger relevanten Informationen und stellt diese der BAM Komponente in kanonischer Form bereit. Kanonisch bedeutet, dass alle relevanten Informationen wie eindeutige Zuordnungs-ID, relevante Zeitstempel, etc. vorhanden sind
• Erstellung einer Integration. Diese nimmt die extrahierten, kanonischen Daten entgegen und integriert diese zu einer Gesamtsicht. Dabei bleiben alle Daten erhalten, werden aber für Zugriffe zur Verfügung gestellt. Diese Komponente ist ebenfalls in der Lage, Anfragen bzw. Bewertungsqueries zu beantworten, hinsichtlich der Anzahl von Datensätzen zu einem Schlüssel, Zeitstempel, Mittelwerte/Durchsätze. Durch die Verwendung einer zentralen Komponente, die alle Daten verwaltet, können Erweiteurngen in Bezug auf neue Abfragen/Operationen einfach (z.B. über eine Plugin-Architektur) hinzugefügt werden.

Das Hauptaugenmerk liegt sicherlich auf der BAM Komponente selber. Diese muss in der Lage sein, Konfigurationen einzulesen und diese zu verarbeiten. In diesen Konfigurationen wird für jeden Schlüssel hinterlegt, welche Operationen aufgerufen werden und welche Schwellwerte, welche Aktionen auslösen.

Durch diese nicht-monolithische Architektur wird sichergestellt, dass es keinen development-lock-in gibt, sondern kontinuierliche Erweiterbarkeit sichergestellt ist.

Die BAM Kompenten kann dabei über diverse Wege selber Statistiken bereitstellen (Hit/Miss Ratio, Trends, etc.), die Aussagen über die Intensität und den “Erfolg” der implementierten Regeln geben.

Die Aktionen, die eine BAM Komponente ausführen kann, sollte wiederum in Form von Plugins vorhanden sein. Dadurch ist maximale Flexibilität gewährleistet und jede Aktion für sich kann über das kanonische Datenmodell alle relevanten Informationen abgreifen.

Die Implementierung kann beispielsweise auf Basis eines ESB erfolgen, indem über eine Registry die vorhandenen Plugins registriert werden (je nach Kategorie (Aktion, Operation)). Die BAM Komponente kann über die Registry dynamisch abfragen, welche Operationen zu Verfügung stehen und damit autonom entscheiden, welche Trigger überhaupt aktiviert werden. Diese wiederum greifen über das zentrale Datenmodell auf die Faktenbasis zu und lösen über ihre Ergebnisse ggf. Aktionen in der BAM Komponente aus.

Über diese enge aber trotzdem loose Verzahnung von einzelnen Komponente lässt sich Flexiblität und schnelle Änderbarkeit zentral und verteilt realisieren - eine service-orientierte Architektur auf Basis (eventuell) eines ESB.

Im Rahmen dieser kurzen Ausführungen habe ich vorgestellt, wie auf Basis eines konkreten Geschäftsnutzens eine service-orientierte Architektur verwendet werden kann, um dynamisches Business Activity Monitoring zu implementieren. Als Standardarchitektur kann dabei ein Enterprise-Service Bus eingesetzt werden, der das kanonische Aufrufen von Komponenten ermöglicht und sicherstellt. Im Rahmen einer service-orientierten Architektur kann somit eine “SOA in Klein” etabliert werden, die genau die benötigten Anforderungen umsetzt.

Mit dem Schlagwort „Business Activity Monitoring“ wird ein relativ aktuelles Buzzword umschrieben, hinter dem sich die fachliche Überwachung von technisch umgesetzten Prozessen versteckt. Die Idee dabei ist, dass in einer flexiblen IT-Welt unterschiedliche Ereignisse dynamisch eintreten können und diese oft erst relativ weit hinten auf einem Zeitstrahl erkannt werden können. Oftmals werden die Informationen eines Unternehmens in einem Data-Warehouse zusammengefasst. Auf diesem Datenbestand können dann Analysen und Berichte aufgesetzt werden. Das ist für viele Daten soweit okay, allerdings bietet es auch das Problem, dass Daten niemals zeitnah zur Verfügung stehen.

Da Busienss Activity Monitoring setzt aber direkt auf Ebene der Datenströme auf und kann dadurch sehr viel zeitnäher informieren. Dabei werden durch die Fachbereiche „interessante“ Kriterien definiert, die eine Aktivität beschreiben – Bestellungen, Orderaufgaben, Bearbeitungsstati. Während nun all diese Aktionen zu Reaktionen innerhalb der IT-Welt führen, greift die/eine BAM-Komponente die unterschiedlichen Datenströme ab und bewertet sie anhand der vorgegebenen Kriterien.

Als Reaktion kann durch so eine Komponente beispielsweise bewertet werden, wie lange eine Orderausführung benötigt, an welcher Stelle im Prozess Verzögerungen aufgetreten sind und wie sich diese entlang des gesamten Ausführungsprozesses verteilen. Alternativ kann auch im „Livebetrieb“ der Erfolg von Werbemaßnahmen bewertet werden, da erkennbar ist, für welche Produkte Bestellungen eingehen. Insofern sind mannigfaltige, sehr zeitnah ausführbare, Analysen möglich. Die Historisierung kann dabei entweder auch innerhalb der Plattform, oder in einem Data-Warehouse erfolgen.

Die Integration von BAM in eine bestehende Plattform kann dabei ganz unterschiedliche Ausmaße annehmen. Verwendet man als Rückgrat einen ESB (=Enterprise Service Bus) bzw. ein entsprechendes Konzept, so kann die Integration sehr transparent erfolgen, da Produkte wie beispielsweise Apache ServiceMix die Möglichkeit bieten, die gesamte Kommunikation innerhalb des Buses abzugreifen und vor-/nachzuverarbeiten. Findet eine SOA Einsatz, die auf einen ESB verzichtet, so kann ein Interceptor-Pattern angewendet werden, um einen BAM-Layer einzuziehen. Die Änderungen sind dabei ebenfalls eher gering, können aber zu einer weitreichenden Datenbasis führen, die durch die Änderung an einer zentralen Stelle in der Architektur hervorgerufen wird.

Egal, welchen Ansatz für die Integration gewählt wird, ein auf jeden Fall wichtiger Punkt ist die Performance der Plattform. Da diese Auswertung on-top auf die bestehende Plattform aufgezogen wird, ist es notwendig, diesen Layer so schlank wie möglich zu halten, um die Gesamtperformance nur minimal zu beeinflußen. Daher sollte hier, egal wie die konkrete Lösung aussieht, lediglich ein Store-and-forward Prinzip Verwendung finden. Die empfangenen Nachrichten sollen gespeichert bzw. an ein Messaging-System oder anderweitigen persistenten Speicher übergeben werden und die Verarbeitung soll sofort weiterlaufen. Eine tatsächliche Echtzeit-Verarbeitung ist für dieses Konstrukt nur in wenigen Fällen sinnvoll (in denen es keine zeitlichen Restriktionen gibt) und aus diesem Grunde sollte jeder Eingriff minimal-invasiv (medizinisch gesprochen) vorgenommen werden.