Einflussfaktoren auf die Adoption von Complex Event Processing in Unternehmen

Inhaltsverzeichnis

Stichwortverzeichnis

Abbildungsverzeichnis

Tabellenverzeichnis

Abkürzungsverzeichnis

1 Einleitung
1.1 Problemstellung und Relevanz
1.2 Vorgehensweise

2 Begriffliche Grundlagen
2.1 Informationstechnologie im Unternehmen
2.1.1 Strategie
2.1.2 Architektur
2.1.3 Architekturmodelle
2.2 Verteilte Systeme und Middleware
2.2.1 Verteilte Systeme
2.2.2 Middleware
2.3 Enterprise Application Integration
2.3.1 Einführung
2.3.2 Enterprise Service Bus
2.3.3 EAI-Modell
2.4 Service Oriented Architecture
2.4.1 Geschäftsprozessorientierung
2.4.2 Serviceorientierung
2.4.3 Aufbau einer SOA
2.5 Complex Event Processing
2.5.1 Events und deren Eigenschaften
2.5.2 Definition und Zielsetzung
2.5.3 Eventverarbeitende Agenten
2.5.4 Eventverarbeitende Netzwerke
2.5.5 Event-Service
2.5.6 Anzeige- und Analysemöglichkeiten
2.5.7 Architektur
2.5.8 Implementationen auf dem Softwaremarkt
2.5.9 Anwendungen und Einsatzmöglichkeiten

3 Einflussfaktoren auf die Adoption von CEP
3.1 Forschungsmethodik
3.2 Grundlegende Theorien
3.2.1 Innovation Diffusion Theory
3.2.2 Technology Acceptance Model
3.2.3 Prozess der technologischen Innovation
3.2.4 Ansatz der Wissensbarrieren
3.3 Literatursynopse
3.3.1 Einflussfaktoren auf die Adoption von IT-Technologien
3.3.2 Erkenntnisse
3.4 Aufstellen der Propositionen
3.4.1 Wissensbarrieren bzgl. CEP
3.4.2 Einstellung des Unternehmens bzgl. Innovationen
3.4.3 Notwendigkeit von Geschäftsunterstützung in Echtzeit
3.4.4 Notwendigkeit von Event-Mining
3.4.5 Notwendigkeit von dynamischem Monitoring
3.4.6 Technische Kompatibilität
3.4.7 Kompatibilität bzgl. Anforderungen
3.4.8 Leichte Verwaltbarkeit
3.5 Theoretischer Bezugsrahmen

4 Fallstudien
4.1 Vorgehensweise
4.2 Fallstudie Bank A
4.2.1 Einführung
4.2.2 Adoptionsabsicht
4.2.3 Wissensbarrieren bzgl. CEP
4.2.4 Einstellung bzgl. Innovationen
4.2.5 Notwendigkeit von Geschäftsunterstützung in Echtzeit
4.2.6 Notwendigkeit von Event-Mining
4.2.7 Notwendigkeit für dynamisches Monitoring
4.2.8 Technische Kompatibilität
4.2.9 Kompatibilität bzgl. Anforderungen
4.2.10 Leichte Verwaltbarkeit
4.3 Fallstudie Bank B
4.3.1 Einführung
4.3.2 Adoptionsabsicht
4.3.3 Wissensbarrieren bzgl. CEP
4.3.4 Einstellung bzgl. Innovationen
4.3.5 Notwendigkeit für Echtzeit
4.3.6 Notwendigkeit für Event-Mining
4.3.7 Notwendigkeit für dynamisches Monitoring
4.3.8 Technische Kompatibilität
4.3.9 Kompatibilität bzgl. Anforderungen
4.3.10 Leichte Verwaltbarkeit
4.4 Fallstudie Bank C
4.4.1 Einführung
4.4.2 Adoptionsabsicht
4.4.3 Wissensbarrieren bzgl. CEP
4.4.4 Einstellung bzgl. Innovationen
4.4.5 Notwendigkeit für Echtzeit
4.4.6 Notwendigkeit für Event-Mining
4.4.7 Notwendigkeit für dynamisches Monitoring
4.4.8 Technische Kompatibilität
4.4.9 Kompatibilität bzgl. Anforderungen
4.4.10 Leichte Verwaltbarkeit
4.5 Fallstudie Bank D
4.5.1 Einführung
4.5.2 Adoptionsabsicht
4.5.3 Wissensbarrieren bzgl. CEP
4.5.4 Einstellung bzgl. Innovationen
4.5.5 Notwendigkeit für Echtzeit
4.5.6 Notwendigkeit für Event-Mining
4.5.7 Notwendigkeit für dynamisches Monitoring
4.5.8 Technische Kompatibilität
4.5.9 Kompatibilität bzgl. Anforderungen
4.5.10 Leichte Verwaltbarkeit
4.6 Fallstudie Bank E
4.6.1 Einführung
4.6.2 Adoptionsabsicht
4.6.3 Wissensbarrieren bzgl. CEP
4.6.4 Einstellung bzgl. Innovationen
4.6.5 Notwendigkeit für Echtzeit
4.6.6 Notwendigkeit für Event-Mining
4.6.7 Notwendigkeit für dynamisches Monitoring
4.6.8 Technische Kompatibilität
4.6.9 Kompatibilität bzgl. Anforderungen
4.6.10 Leichte Verwaltbarkeit
4.7 Analyse
4.7.1 Überblick
4.7.2 Wissensbarrieren bzgl. CEP (P 1)
4.7.3 Einstellung des Unternehmens bzgl. Innovationen (P 2)
4.7.4 Notwendigkeit der Geschäftsunterstützung in Echtzeit (P 3)
4.7.5 Notwendigkeit von Event-Mining (P 4)
4.7.6 Notwendigkeit von dynamischem Monitoring (P 5)
4.7.7 Technische Kompatibilität (P 6)
4.7.8 Kompatibilität bzgl. Anforderungen (P 7)
4.7.9 Leichte Verwaltbarkeit (P 8)
4.7.10 Ergebnis

5 Schlussbetrachtung
5.1 Fazit
5.2 Ausblick

Anhang

Interviewleitfaden

Literaturverzeichnis

Ehrenwörtliche Erklärung

Stichwortverzeichnis

Adoption

Unter Adoption versteht man die Assimilation einer Technologie durch ein Unternehmen, d. h. die Übernahme und Einführung dieser Technologie. Bezieht sich die Adoption auf eine innovative Technologie, so lässt sich Adoption wie folgt definieren. „Das Konzept der Adoption bezieht sich üblicherweise auf den Punkt im Innovationsprozess, an dem der Übergang davon stattfindet, dass ein Benutzer oder eine Organisation eine Innovation nicht hat, zu dem Punkt, an dem er sie hat“ (Tornatzky, Fleischer, 1990, S.178f). Als Adoption kann auch „die Entscheidung eines Nachfragers zur Übernahme einer Innovation“ bezeichnet werden. Die Adoptionstheorie analysiert dabei die Faktoren, die den Verlauf des Adoptionsprozesses beeinflussen (Weiber, 1992, S.3).

Adoption ist nicht zu verwechseln mit Diffusion, bei der die Verbreitung einer Technologie in unterschiedlichen Unternehmen untersucht wird.

Im Zusammenhang einer Adoption sind auch Einflussfaktoren auf die Adoption von Bedeutung. Unter einem Einflussfaktor versteht man einen Umstand, der die Adoption maßgeblich beeinflusst.

Complex Event Processing

Complex Event Processing (CEP) ist ein ereignisorientiertes und auf Echtzeit basierendes Informationstechnologiesystem (IT-System). In der IT auftretende Ereignisse können als
9 Events in CEP verwendet werden. Dabei werden Events mit einer niedrigen Aussagekraft von CEP miteinander verknüpft und zu Komplexen Events zusammengefasst, die eine höhere Aussagekraft besitzen. Dadurch ist es möglich, aus dem Auftreten von einzelnen Events auf größere, komplexe Zusammenhänge zu schließen. Die Komplexen Events können dann automatisierte Prozesse anstoßen oder Benutzer informieren oder alarmieren.

CEP kann in verschiedenen 9 IT-Architekturen eingesetzt werden. Es kann seine Informationen in Form von Events aus 9 Verteilten Systemen, aus über 9 Middleware verbundene Anwendungen, aber auch von einzelnen Systemen wie Feuermeldern oder RFID Chips bekommen (Rizvi et al, 2005, S.885f).

Dashboard

Unter einem Dashboard versteht man eine visuelle Anzeige der wichtigsten Informationen die benötigt werden, um eine oder mehrere Aufgaben zu erfüllen. Die Informationen sind dabei aus verschiedenen Quellen zusammengeführt und auf einer einzigen Bildschirmseite so angeordnet, dass sie auf einen Blick erfasst werden können (Few, 2004, S.2). Die Anzeigen sollten dabei sehr einfach zu erfassen sein. Dies kann mit Hilfe von Anzeigeinstrumenten wie beispielsweise Metern, Ampeln oder Tabellen geschehen. Dashboards werden im Rahmen des 9 Monitoring hauptsächlich zur Überwachung und ggf. zur Steuerung von Geschäftsprozessen verwendet.

Enterprise Application Integration

Um historisch gewachsene IT-Systeme in einer modernen IT-Architektur weiter verwenden zu können, wurde das Konzept der Enterprise Application Integration (EAI) entwickelt. „EAI verspricht einen umfassenden Ansatz für die operative Integration von Geschäftsprozessen durch die kontrollierte, flexible und rasch ausbaubare inner- oder zwischenbetriebliche Integration multipler Anwendungen“ (Kaib, 2002, S.79). Bei EAI werden Datenbankverwaltungssysteme und andere interne oder externe Ressourcen/ Systeme mit Hilfe eines 9 Enterprise Service Busses (ESB) verbunden. Dadurch kann beispielsweise ein Zugriff von einem Webportal auf diesen ESB stattfinden, ohne genaueres über die zugrunde liegenden Systeme zu wissen.

Enterprise Service Bus

Der Enterprise Service Bus (ESB) ist eine Kommunikationsverbindung mit erweiterter Funktionalität zwischen 9 Verteilten Systemen (VS) eines Unternehmens. Er ist verantwortlich für die Überwachung, Kontrolle und Übersetzung aller Nachrichten, die zwischen VS ausgetauscht werden. Die dabei benötigten Nachrichtenübertragungsprotokolle werden vom ESB zur Verfügung gestellt (Papazoglou, van den Heuvel, 2005, S.5) und basieren normalerweise auf „Offenen Standards“.

Ein ESB ist häufig Teil fortschrittlichen 9 Middleware wie 9 Enterprise Application Integration oder Teil einer 9 Service Oriented Architecture (SOA). In einer SOA bietet er eine gemeinsame Kommunikationsplattform für miteinander kommunizierende Komponenten und Anwendungen. Ein ESB ermöglicht dabei eine Anordnung von Services, um Geschäftsprozesse zusammenzufassen, die wiederum Geschäftsfunktionen des Unternehmens automatisieren (Papazoglou, van den Heuvel, 2005, S.5).

Event

Unter einem Event wird in dieser Arbeit ein Objekt verstanden, das die Aktivität eines Systems bezeichnet. Es kann unterschiedliche Attribute oder Datenkomponenten enthalten. Üblicherweise enthält ein Event den Zeitpunkt bzw. die Zeitperiode des Auftretens, den Ort des Auftretens, den Grund des Auftretens sowie die Relationen zu anderen Events (Luckham, 2002, S.88-90). Des Weiteren kann ein Event auch durchgeführte Aktivitäten und Datenwerte enthalten.

Nicht zu verwechseln ist ein Event mit einer Nachricht. Zwar wird ein Event oft wie eine Nachricht generiert, es enthält jedoch mehr Informationen (Luckham, 2002, S.90). Beispiele für ein Event aus der Unternehmenspraxis sind das versenden einer E-Mail, das Durchführen einer Überweisung, das Löschen einer Datei oder die Abfrage eines Wertes aus einem DBS.

IT-Architektur

Als IT-Architektur wird das Zusammenspiel verschiedener IT-Systeme in einem Unternehmen bezeichnet. Dabei geht es insbesondere um die Planung eines solchen Zusammenspiels und die Analyse von vorhandenen Systemen und deren Wechselwirkung. Dern (2003, S.18) definiert eine IT-Architektur als „strukturierende Abstraktion existierender oder geplanter Informationssysteme“. Dabei „schafft die Abstraktion die gemeinsame Kommunikationsplattform aller an der Gestaltung von Informationssystemen Beteiligten, um so die Planbarkeit und die Steuerbarkeit der Gestaltung realer, miteinander in Wechselwirkung stehenden Entitäten der IT eines Unternehmens zu erhöhen“ (Dern, 2003, S.18). Bei der Planung von IT-Architekturen in einem Unternehmen kann man dabei auch auf Referenzarchitekturen zurückgreifen. Dies sind idealtypische Modelle für eine Klasse von IT-Architekturen.

Middleware

Als Middleware werden Softwarekomponenten bezeichnet, die eine Kommunikation zwischen Anwendungen in 9 Verteilten Systemen ermöglichen. Dabei kann als Middleware prinzipiell alles bezeichnet werden, was zwischen einer einfachen TCP/IP Kommunikation und sehr komplexen Kommunikationsprodukten liegt. Fortschrittlichere Middleware wie
9 Enterprise Application Integration bietet jedoch zusätzliche Funktionalität wie z. B. integrierte Prozesslogik.

Middleware ist eine Kommunikationsstruktur, die unabhängig vom Betriebssystem arbeitet (Serain, 2002, S.14f). Sie ermöglicht den angebundenen Anwendungen, hersteller- und plattformunabhängig Daten auszutauschen (Kaib, 2002, S.72). In 9 IT-Architekturen stellt Middleware oft die Verbindung zwischen Ressourcen wie Datenbankverwaltungssystemen und Anwendungen dar und stellt die Schnittstellen für deren Kommunikation zur Verfügung.

Monitoring

Monitoring ist die Überwachung, Beobachtung oder Steuerung von Aktivitäten und Kennzahlen eines Unternehmens mit Hilfe von Systemen wie Balanced Scorecard oder
9 Dashboards. Der Zeitpunkt der Aktualisierung der Kennzahlen kann dabei zwischen einem Jahr und Millisekunden liegen. Die Fähigkeit eines Systems, das Augenmerk eines Benutzers auf betriebswirtschaftlich dringende und relevante Aufgaben in Echtzeit hinzuwesen, wird dabei auch als Business Activity Monitoring bezeichnet.

Service Oriented Architecture

Eine Service Oriented Architecture (SOA) ist ein technologie- und plattformunabhängiges IT-Architekturdesignkonzept. Der Schwerpunkt von SOA liegt auf der Unterstützung und Abbildung von Geschäftsprozessen.

SOA beschreibt das Konzept einer modularisierten 9 IT-Architektur, die sich durch geringe Redundanzen, einen hohen Grad an Standardisierung und eine hohe Flexibilität auszeichnet. Bei SOA werden Ressourcen und Komponenten als Services betrachtet, die miteinander kommunizieren. Diese sind unabhängig von deren Standort und bieten eine definierte Funktionalität. Außerdem sind sie wieder verwendbar, da zugrunde liegende Komponenten beliebig ausgetauscht werden können und der zugehörige Service weiterhin besteht. Dies führt zu einer hohen Flexibilität des Systems.

Verteilte Systeme

Unter Verteilten Systemen (VS) versteht man räumlich verteilte, voneinander unabhängige IT-Systeme. Die räumliche Trennung kann innerhalb eines Standortes eines Unternehmens, aber auch darüber hinaus und sogar weltweit sein. Die Systeme sind über eine Kommunikationsverbindung miteinander verknüpft. VS erscheinen einem Benutzer wie ein einzelnes, kohärentes System (Tanenbaum, van Stehen, 2003, S.18). Sollen VS in eine einheitliche 9 IT-Architektur integriert werden, sind IT-Systeme wie 9 Middleware oder
9 Enterprise Application Integration nötig.

Abbildungsverzeichnis

Abbildung 1: EAI-Modell

Abbildung 2: Verarbeitung von Events

Abbildung 3: CEP mit EPN und Event-Service

Abbildung 4: Übersicht einer CEP-Architektur

Abbildung 5: Schichtenmodell EAI und CEP

Abbildung 6: Kategorisierung des Innovationsgrades

Abbildung 7: Technology Acceptance Model

Abbildung 8: Kontext der technologischen Innovation

Abbildung 9: Theoretischer Bezugsrahmen

Tabellenverzeichnis

Tabelle 1: Transparenzen bei Verteilten Systemen und deren Vorteile

Tabelle 2: Übersicht über CEP-Produkte auf dem Markt

Tabelle 3: Ergebnisse empirischer Studien zur Adoption von IT-Technologien….

Tabelle 4: Zusammenfassung und Gegenüberstellung der Ergebnisse der Fallstudien

Tabelle 5: Übersicht über die aufgestellten Propositionen

Tabelle 6: Unterstützungsgrade der Propositionen durch die Fallstudien

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

1 Einleitung

1.1 Problemstellung und Relevanz

Flexible, standardisierte und prozessorientierte Architekturen in der Informationstechnologie (IT) stellen für immer mehr Unternehmen ein Bestandteil einer zukunftsweisenden IT-Strategie dar. Mit Konzepten wie Enterprise Application Integration (EAI), bei der unternehmensintern- und extern verteilte IT-Systeme einheitlich miteinander verbunden werden, und Service Oriented Architecture (SOA), bei der alle IT-Dienste und Funktionalitäten als Service für den Benutzer oder einen Geschäftsprozess (GP) dienen sollen, haben viele Unternehmen bereits diesen Weg eingeschlagen.

Neben diesen Konzepten rückt in Wissenschaft und Praxis seit kurzem auch das Konzept des Complex Event Processing (CEP) in den Vordergrund, eine neue IT-Technologie, mit deren Hilfe Informationen aus einem IT-System extrahiert werden, um eine Echtzeit-Bewältigung von IT-Managementaufgaben in Unternehmen erreichen zu können (Luckham, Frasca, 1998, S.1). CEP kann sowohl basierend auf einer EAI- bzw. SOA-Architektur, als auch ohne eine dieser Architekturen umgesetzt werden, und ist dadurch sehr flexibel. CEP wird bereits von einigen Unternehmen eingesetzt und könnte für viele Unternehmen einen interessanten Ansatz für ihre zukünftige IT-Strategie darstellen.

Aus wissenschaftlicher Sicht ist CEP ein sehr interessantes Konzept, da es erst vor kurzem entwickelt wurde, vorhandene Ideen und Konzepte aus der Wirtschaftinformatik aufgreift und einbindet, sowie eine mögliche Erweiterung von SOA darstellt. Die wenigen, bisher vorhandenen Arbeiten zum Thema CEP beschäftigen sich überwiegend mit Einzelanwendungen, mit der zugrunde liegenden Entscheidungstechnologie und mit dem Event Processing Netzwerk (EPN), einem Kernmodul von CEP, das mit Hilfe von Agenten die Events verarbeitet und Ausgaben produziert. Im Bereich der Anwendungs- und Einsatzmöglichkeiten sowie bei Problemstellungen bzgl. der Einführung von CEP gibt es noch großen Forschungsbedarf.

Ziel dieser Arbeit ist es aufzuzeigen, welche Faktoren die Einführung von CEP in Unternehmen fördern bzw. hemmen, ob eine Einführung von CEP empfehlenswert ist, welche Punkte ein Unternehmen bei der Einführung beachten muss und wie CEP in eine vorhandene IT-Strategie eingebunden werden kann.

Für Praktiker ist diese Arbeit mit ihren Ergebnissen relevant, da sie einen Überblick über CEP und dessen Einbindung in IT-Architekturen gibt sowie eine Unterstützung bei der Planung und Einführung von CEP in Unternehmen bietet. Der Entscheidungsfindungsprozess, ob eine CEP-Einführung im Unternehmen stattfinden soll, kann ebenso durch diese Arbeit unterstützt werden.

1.2 Vorgehensweise

In Kapitel 2 werden begriffliche Grundlagen der Arbeit eingeführt. Eine an das Unternehmen angepasste IT-Architektur stellt eine wichtige Grundvoraussetzung für die Umsetzung einer erfolgreichen IT-Strategie dar. Unterschiedliche Konzepte von IT-Architekturen wie Middleware und EAI werden vorgestellt und erläutert. Des Weiteren wird die SOA als technologie- und plattformunabhängiges IT-Architekturdesignkonzept eingeführt. CEP wird nun aus betriebswirtschaftlicher und aus technischer Sicht ausführlich erläutert und die Architektur von CEP wird dargestellt. Dabei wird auf den Begriff des Events, die Verknüpfung mehrerer Events zu „Komplexen Events“ und deren wachsende Bedeutung in Unternehmen eingegangen. Ebenso werden die einzelnen Verfahren, die CEP zur Entscheidungsfindung und Filterung verwendet, beschrieben. Schließlich werden Anwendungen und Einsatzmöglichkeiten von CEP kurz erläutert.

Nach der Erklärung der wissenschaftlichen Vorgehensweise in Kapitel 3 werden Basistheorien vorgestellt. Die Literatursynopse gibt anschließend einen Literaturüberblick über Studien, die sich mit Technologieeinführungen in Unternehmen befassen. Generelle Einflussfaktoren auf die Adoption neuer IT-Technologien werden aus der Literatur herausgearbeitet und vorgestellt. Neben diesen Einflussfaktoren werden noch spezielle Einflussfaktoren bei der CEP Adoption bestimmt. Anschließend wird ein theoretischer Bezugsrahmen bezüglich der Einflussfaktoren der Adoption von CEP aufgestellt und erläutert.

Kapitel 4 überprüft empirisch den in Kapitel 3 aufgestellten theoretischen Bezugsrahmen anhand von Fallstudien. Für diese wurden IT-Führungskräfte deutscher Banken in Interviews befragt. Das Ergebnis der Fallstudien wird bewertet und der theoretische Bezugsrahmen kritisch reflektiert.

Zukünftige Einsatzmöglichkeiten von CEP und mögliche Forschungsfragen werden in Kapitel 5 aufgezeigt und ein Fazit der Arbeit gezogen. Schließlich beendet ein genereller Ausblick auf die Zukunft von IT-Architekturen und CEP die Arbeit.

2 Begriffliche Grundlagen

Um komplexe Zusammenhänge in der IT eines Unternehmens zu verstehen und zu analysieren, ist es notwendig, grundlegende Begriffe zu definieren und sie voneinander abzugrenzen. Im Folgenden werden für das Themengebiet relevante Begriffe aus der IT definiert und erklärt.

2.1 Informationstechnologie im Unternehmen

2.1.1 Strategie

Eine Strategie, mit der Art und Richtung der Gestaltung der Informationsinfrastruktur eines Unternehmens festgelegt wird, bezeichnet man als IT-Strategie (Heinrich, Heinzl, Roithmayr, 2004, S.348). Die IT-Strategie legt dabei fest, welche Ressourcen die IT-Abteilung in Zukunft benötigt, um den Bedarf an IT einer Unternehmung zu decken. Außerdem beinhaltet sie das Design einer IT-Architektur. Die IT-Strategie wird vom IT-Management, das in vielen Unternehmen durch den „Chief Information Officer“ (CIO) repräsentiert wird, festgelegt.

Voraussetzung für eine erfolgreiche IT-Strategie ist eine Unternehmensstrategie. Die IT-Strategie in Unternehmen ist ein wichtiger Faktor zur Unterstützung der Unternehmensstrate­gie (Sauer, Willcocks, 2004, S.2). Auf Grundlage der Unternehmensstrate­gie und unter Berücksichtigung unterschiedlicher Handlungsmöglichkei­ten in der IT kann in einem Planungspro­zess eine IT-Strategie entwickelt werden (Min, Suh, Kim, 1999, S.384). Ziel einer fortschrittlichen IT-Strategie ist eine positive Wechselwirkung zwischen Unternehmensstrate­gie und IT-Strategie (Ross, 2003, S.3).

Um einen Wettbewerbsvorteil zu erringen und die Unternehmensziele zu erreichen sind strategische IT-Systeme für ein Unternehmen sehr wichtig (Min, Suh, Kim, 1999, S.374). Strategische IT-Systeme müssen einen messbaren, langfristig ausgelegten Vorteil für ein Unternehmen bringen und die Ausübung des Geschäfts positiv beeinflussen.

2.1.2 Architektur

Ein wichtiger Schritt des Planungsprozesses einer IT-Strategie ist das Festlegen einer IT-Architektur (Min, Suh, Kim, 1999, S.384-387). Dabei kann es sich auch um einen dynamischen Prozess handeln (Ross, 2003, S.3), da aufgrund sich ändernder Rahmenbedingungen in der Wirtschaft eine kontinuierliche Anpassung einer IT-Architektur notwendig ist (Ross, 2003, S.15).S

Eine Architektur wird nach Heinrich et al. (2004, S.72) in der Wirtschaftsinformatik zur rekursiven Betrachtung verschiedener konzeptioneller Ebenen eines abstrakten Modells verwendet. Als IT-Architektur bezeichnet man eine Architektur, deren Objekt die Informationsinfrastruktur des Unternehmens als Ganzes ist (Heinrich et al., 2004, S.346).

Dern (2003, S.18) definiert eine IT-Architektur als „strukturierende Abstraktion existierender oder geplanter Informationssysteme“. Dabei „schafft die Abstraktion die gemeinsame Kommunikationsplattform aller an der Gestaltung von Informationssystemen Beteiligten, um so die Planbarkeit und die Steuerbarkeit der Gestaltung realer, miteinander in Wechselwirkung stehenden Entitäten der IT eines Unternehmens zu erhöhen“ (Dern, 2003, S.18).

Zur besseren Abgrenzung teilt Dern (2003, S.18) IT-Architekturen auf in Referenzarchitekturen, die die übergreifende Struktur von mehreren IT-Architekturen und damit Gruppen von Informationssystemen beschreiben, und singulären IT-Architekturen, die sich auf ein einzelnes Subsystem beziehen. Wenn im Folgenden von IT-Architekturen gesprochen wird, dann sind damit Referenzarchitekturen gemeint.

Hauptaufgabe einer IT-Architektur ist, die IT-Schlüsselressourcen für die strategischen Unternehmensziele zur Verfügung zu stellen (Ross, 2003, S.2). IT-Architekten legen nach Sauer und Willcocks (2004, S.3) fest, welche Technologien für ein Unternehmen in Frage kommen und wie das Zusammenspiel dieser aussehen soll. Die Schwierigkeit dabei ist, die Parameter Zeit, Kosten, Qualität, Sicherheit, Flexibilität und Ausfallsicherheit zu berücksichtigen und diese in einen möglichst optimalen Zustand zu bringen.

Die Überwindung der Heterogenität von Hard- und Software in IT-Systemen hat Unternehmen in der Vergangenheit große Probleme bereitet und hohe Kosten verursacht. Die Kommunikation sowohl zwischen bestehenden Anwendungen als auch neuen Anwendungen führte in der Praxis oftmals zu Problemen (Popien, Schürmann, Weiß, 1996, S.1). Bei dem Versuch, neue Anwendungen mit bestehenden Anwendungen zu verbinden, können deshalb Integrationsprobleme auftreten.

Über die Jahre sind die IT-Systeme in vielen Unternehmen um immer neue Systeme gewachsen, deren Kompatibilität nicht immer gewährleistet werden kann. Die in den folgenden Abschnitten vorgesellten IT-Architekturmodelle stellen Lösungsansätze dar, um das Integrationsproblem zu lösen.

2.1.3 Architekturmodelle

Je nach IT-Strategie lassen sich IT-Architekturen in der Praxis in vier Stufen unterteilen (Ross, 2003, S.5). Die „Silo-Architektur“ besteht aus einer Menge von Einzelarchitekturen. Die „Standardisierte Architektur“ bietet eine unternehmensweite IT-Architektur und hat durch Standardisierung und Zentralisierung einen höheren Wirkungsgrad. Die „Rationalisierte Datenarchitektur“ standardisiert zusätzlich Daten und Prozesse. Die „Modularisierte Architektur“ schließlich bietet weltweite Standards mit einzelnen, verbundenen Komponenten (Ross, 2003, S.5).

Zum besseren Verständnis und Überblick sowie zur besseren Designmöglichkeit eines IT-Systems kann dieses durch ein IT-Architekturmodell dargestellt werden. Die üblichste Form eines IT-Architekturmodells ist das Schichtenmodell. Dabei erfolgt die Darstellung des IT-Systems in Form mehrerer, aufeinander aufbauender Teilmodelle, die als konzeptionelle Schichten bezeichnet werden. Jede Schicht stellt dabei Funktionen für die darüber liegende Schicht zur Verfügung (Heinrich et al., 2004, S.578). Je nach Komplexität des IT-Systems kann dessen Architektur in mehr oder weniger Schichten unterteilt werden. Die Funktionalität der einzelnen Schichten wird im Folgenden näher erläutert.

In einem Schichtenmodell erreicht man mittels standardisierter Schnittstellen eine Unabhängigkeit zwischen den Schichten, Flexibilität bezüglich Änderungen in einer Schicht und physikalische Trennung in Bezug auf die eingesetzte Technologie (Sloman und Kramer, 1989, S.25).

Mit den so genannten „N-Schichten-Architekturen“ lassen sich unterschiedliche Architekturvarianten von IT-Systemen beschreiben (Eberhart und Fischer, 2000, S.33f). In der Praxis verwendete Architekturen, die auf den N-Schichten-Architekturen basieren, werden nun vorgestellt.

Die früher verwendete, auch als „Mainframe-Architektur“ bekannte „1-Schichten-Architektur“, bei der die Anwendungslogik zentral auf einem Host betrieben wird und bei der Zugriffe des Benutzers über Terminals erfolgen, spielt heutzutage praktisch keine Rolle mehr (Alonso, Casati, Kuno, Machiraju, 2004, S.10f).

Bei der „2-Schichten-Architektur“ unterscheidet man zwischen der „Präsentationsschicht“ und der „Anwendungs- und Ressourcenschicht“. Diese Architektur wird auch „Client-Server-Architektur“ genannt. Die Präsentationsschicht ist für die Interaktion mit dem Benutzer verantwortlich, während die Anwendungs- und Ressourcenschicht die eigentlichen Anwendungen und Ressourcen wie Datenbankverwaltungssysteme (DBS) beinhaltet.

Bei der „3-Schichten-Architektur“ unterscheidet man zwischen Präsentationsschicht, einer Middlewareschicht mit Anwendungs- und Webservern sowie einer Ressourcenschicht mit DBS und Altanwendungen (Legacy Systeme). Die Middlewareschicht wird in Abschnitt 2.2.2 näher erläutert.

Die „4-Schichten-Architektur“ trennt gegenüber der „3-Schichten-Architektur“ die Middlewareschicht in Schichten für Anwendungs- und Webserver und erlaubt damit eine höhere Skalierbarkeit.

Die „5-Schichten-Architektur“ oder auch „Web-Architektur“ ist eine Weiterentwicklung der 3-Schichten-Architektur zur Unterstützung von E-Business-Anwendungen. Die Ressourcen­schicht wird dabei noch aufgeteilt in eine Schicht zur Organisation der Daten und eine zur Speicherung der Daten (Heinrich et al., 2004, S.709).

Die in den folgenden Abschnitten vorgestellten IT-Architekturmodelle basieren alle auf den hier beschriebenen Schichten-Architekturen.

2.2 Verteilte Systeme und Middleware

2.2.1 Verteilte Systeme

IT-Systeme befinden sich heutzutage oft nicht mehr physisch an einem Ort. Sie sind örtlich verteilt innerhalb eines Standortes eines Unternehmens, innerhalb eines Landes und auch weltweit. Sie sind miteinander über ein Netzwerk verbunden, beispielsweise einem Intranet oder über das Internet.

Tanenbaum und van Steen (2003, S.18) definieren ein Verteiltes System (VS) als „Menge voneinander unabhängiger Computer, die dem Benutzer wie ein einzelnes, kohärentes System erscheinen“. Nach Aleksy, Korthaus und Schader (2005, S.8) besteht ein VS aus einer gewissen Anzahl unabhängiger Softwarekomponenten, die auf unterschiedlichen, über ein Netzwerk verbundenen, Computern ausgeführt werden können.

Es gibt neun wichtige Charakteristika von VS (o.V., 1989, S.II/3/2f), die Sprachtransparenz als zehnte Transparenz wurde erst später hinzugefügt. Ein VS sollte möglichst viele dieser in Tabelle 1 aufgeführten Transparenzen erfüllen, um die Komplexität niedrig zu halten (Eberhart und Fischer, 2000, S.14).

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 1: Transparenzen bei Verteilten Systemen und deren Vorteile

(Quelle: in Anlehnung an o.V., 1989, S.II/3/2f und Borghoff, Schlichter, 1998, S.6-10)

2.2.2 Middleware

Beim Integrationsansatz basierend auf Middleware wird zur Lösung des Integrationsproblems eine vermittelnde Softwareschicht zwischen mehrere Systeme geschaltet (Kaib, 2002, S.72). Im IT-Architekturmodell ist diese vermittelnde Softwareschicht diejenige Schicht, welche die Präsentationsschicht mit den darunter liegenden Schichten verbindet (vgl. die 3-Schichten-Architektur in 2.1.3).

Als Middleware werden dabei Softwareprodukte bezeichnet, die eine Kommunikation zwischen Anwendungen in VS ermöglichen. Dabei kann als Middleware prinzipiell alles bezeichnet werden, was zwischen einer einfachen Kommunikation mit TCP/IP und sehr komplexen Kommunikationsprodukten liegt. Da Middleware eine Kommunikationsstruktur ist, die unabhängig vom Betriebssystem arbeitet (Serain, 2002, S.14f), ermöglicht sie den angebundenen Anwendungen, hersteller- und plattformunabhängig Daten auszutauschen (Kaib, 2002, S.72).

Transaktionsorientierte Middleware (TOM) unterstützt die Integration von Transaktionen zwischen verteilten DBS. Nachrichtenorientierte Middleware (MOM) verwendet als Modell die Weitergabe von Nachrichten zwischen Anwendungen in VS (Emmerich, 2000, S.5, S.68f).S

Das erste, standardisierte und objektorientierte Modell einer Middleware, von der es viele Implementationen auf dem Markt gibt, ist die Common Object Request Broker Architecture (CORBA) und existiert seit 1990. Ein weiteres Modell ist das Distributed Component Object Model (DCOM) (Serain, 2002, S.24) und die .NET-Plattform. Ferner gibt es die Java 2 Platform, Enterprise Edition (J2EE) mit den Enterprise Java Beans (EJB), eine „Standard Komponentenarchitektur für die Erstellung von verteilten Geschäftsanwendungen in der Programmiersprache Java“ (Denninger, Peters, 2002, S.9).

2.3 Enterprise Application Integration

2.3.1 Einführung

EAI ist ein umfassender Ansatz zur Integration von Daten und Anwendungen innerhalb eines Unternehmens und über Unternehmensgrenzen hinweg (Kaib, 2002, S.81). „Typische Aufgabe ist die Integration von selbst entwickelten Systemen mit Fremdsystemen“ (Heinrich et al., 2004, S.210). Der Einsatz von EAI beschleunigt und rationalisiert die Informationsflüsse innerhalb eines Unternehmens (Keller, 2002, S.7) und erlaubt es, GP auf VS so durchführen zu können, als ob es sich um ein System handeln würde.

Zentraler Bestandteil von EAI-Lösungen ist die darunter liegende Middleware. Das Konzept der EAI ist nicht als Gegensatz zu Middleware, sondern als eine Weiterentwicklung zu verstehen (Alonso et al., 2004, S.67). EAI geht dabei im Funktionsumfang über die klassische Middleware hinaus. Erl (2004, S.293) vergleicht die Definitionen von Middleware und EAI und kommt zu dem Schluss, dass EAI eine fortschrittlichere Integrationslösung als Middleware bietet und neuere, teilweise auf Nachrichten basierende Produkte verwendet.

2.3.2 Enterprise Service Bus

Die Einführung neuer Softwarekomponenten erfordert einen Datenaustausch mit bestehenden Systemen. Dazu werden Kommunikationskanäle zwischen den einzelnen Systemen benötigt, welche, besonders bei VS, unter Umständen komplex und schwierig zu betreiben sein können (Serain, 2002, S.45).

EAI bedient sich hier eines zentralen Kommunikationsbusses, dem „Enterprise Service Bus“ (ESB). Dieser ist verantwortlich für die Überwachung, Kontrolle und Übersetzung aller Nachrichten, die zwischen VS ausgetauscht werden (Papazoglou, van den Heuvel, 2005, S.5).

Einige Anwendungen sind nicht dafür ausgelegt, über einen ESB mit anderen Anwendungen zu kommunizieren. Für diese Anwendungen ist es notwendig, einen anwendungsspezifischen Adapter bereitzustellen, der die Kommunikation zwischen dem API der Anwendung und dem ESB bereitstellt (Papazoglou, van den Heuvel, 2005, S.16). Ein solcher Adapter wird auch als logische Kommunikationsschnittstelle bezeichnet. Die Kommunikation zwischen zwei dieser Anwendungen findet dann über die Schnittstelle(n) statt, ohne dass die Anwendungen direkten Kontakt über physikalische Adressen haben (Serain, 2002, S.148). Die Zahl der Schnittstellen ist dabei wesentlich geringer als bei VS ohne ESB (Aier, Schönherr, 2004, S.14).

2.3.3 EAI-Modell

Abbildung 1 zeigt ein vereinfachtes Modell einer auf EAI basierenden 3-Schichten-Architektur. Die Kommunikation zwischen Anwendungen findet dabei ausschließlich über den ESB als zentrales Kommunikationsmedium statt. Dabei kann beispielsweise ein Web-Client, der sich in der Präsentationsschicht befindet, eine Verbindung mit einem Web-Server herstellen, der mit einem ESB verbunden ist und sich in der Middlewareschicht befindet. Daten können dann aus einem DBS bezogen werden, das ebenfalls an den ESB angeschlossen ist und sich in der Ressourcenschicht befindet.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: EAI-Modell

(Quelle: Eigene Grafik)

2.4 Service Oriented Architecture

2.4.1 Geschäftsprozessorientierung

Eine SOA strebt eine an GP ausgerichtete IT-Architektur an. Unter Geschäftsprozessorientie­rung (GPO) versteht man eine Ausrichtung eines Unternehmens in erster Linie auf GP. Da die Unternehmensstrategie und die IT-Strategie eines Unternehmens nach 2.1.1 in Wechselwirkung stehen, muss in diesem Fall auch die IT-Strategie eine Ausrichtung auf GP zeigen. Dementsprechend weisen IT-Systeme mit GPO eine eindeutige Ausrichtung auf die Unterstützung des Ablaufgeschehens, also den dynamischen, kooperativen und zielgerichteten Anteil der GP, auf (Schulze, Böhm, 1996, S.285).

Becker und Vossen (1996, S.19) definieren einen Prozess als „inhaltlich abgeschlossene zeitliche und sachlogische Abfolge der Funktionen, die zur Bearbeitung eines betriebswirtschaftlich relevanten Objektes notwendig sind“. Einen GP definieren sie als „Untermenge der Prozesse, die die Geschäftsarten einer Unternehmung repräsentieren, sich damit aus den obersten Sachzielen ergeben und zwingend Schnittstellen zu externen Marktpartnern aufweisen“. GP sind dementsprechend ein zentraler Teil der Geschäftsstrategie und damit ausschlaggebend für den Erfolg eines Unternehmens.

2.4.2 Serviceorientierung

Die Serviceorientierung basiert auf der GPO. Bei der Serviceorientierung werden Services als fundamentales Prinzip der Anwendungsentwicklung dargestellt (Papazoglou, Georgakopoulos, 2003, S.25). GP werden dabei ggf. in kleinere funktionale Elemente aufgespalten, die als Services bezeichnet werden (Lager, 2005, S.17). Unter Services versteht man wohldefinierte Softwaremodule, die eine Funktionalität für einen Geschäftsprozess bereitstellen und die unabhängig von anderen Modulen sind (Papazoglou, van den Heuvel, 2005, S.1).

Jeder dieser Services stellt dabei je nach Granularität die Funktionalität für einen GP oder für Teile eines GP zu Verfügung. Im Finanzbereich beispielsweise gibt es Services wie „Kundenstammdaten holen“, „Kreditwürdigkeit prüfen“, „SCHUFA-Anfrage durchführen“ oder „Kunde löschen“. Diese Services werden einmal bereitgestellt und können dann im Unternehmen von allen Abteilungen verwendet werden.

Die Realisierung eines Service muss strikt von seiner Beschreibung getrennt sein. Werden dann einzelne Komponenten ausgetauscht, so besteht der zugehörige Service weiterhin. Durch die Aneinanderreihung von Services erhält man einen modularen Ansatz, durch den man wesentlich mehr Flexibilität bekommt (Lager, 2005, S.17).

Web Services sind spezielle Services, die ein wichtiges Element einer SOA darstellen, da sie die Integration von Services von anderen Anbietern erlauben. Sie sind geschlossene, modularisierte Anwendungen, deren Kommunikation über offene, internetorientierte und standardisierte Schnittstellen abläuft (o.V., 2001, S.1). Zu Bedenken ist hierbei jedoch, dass durch sog. Service Level Agreements (SLA) die dauerhafte Bereitstellung des Service gewährleistet sein muss.

2.4.3 Aufbau einer SOA

Eine SOA ist das Konzept einer IT-Architektur, der das Prinzip der GPO zugrunde liegt. Sie unterstützt die Ausrichtung der Unternehmens- und IT-Strategie auf GP. SOA stellt dabei zwar nur ein allgemeines Modell dar, es existieren jedoch Standards, die für die Implementierung einer SOA verwendet werden können.

SOA stellt den auf Standards basierenden Bezugsrahmen, in dem Services entstehen, angewandt und verändert werden, zur Verfügung. Ziel dabei ist es, eine flexible IT-Architektur zu erhalten um schneller auf veränderte Anforderungen durch veränderte GP eingehen zu können (TKnoor, Rist, Krill, 2005, S.23T). Diese Services werden dann zu Anwendungen zusammengefügt, um Standardisierung und Interoperabilität zu erreichen (Lager, 2005, S.17).

Das Rückgrat einer SOA ist der ESB, der die nötige Funktionalität bietet. Die Services kommunizieren miteinander über den ESB. Dieser bietet neben den aus EAI bekannten Diensten noch die Möglichkeit, Web Services zu integrieren, unterstützt diverse Transportprotokolle und liefert einen Mehrwert für SOA-Anwendungen. Die wichtigste Fähigkeit eines ESB ist dabei, die Kommunikation zwischen einzelnen Services zu gewährleisten. Er steuert die Transportprotokolle und wandelt sie wenn nötig um (Papazoglou, van den Heuvel, 2005, S.8).

Die Fähigkeiten, die ein ESB in einer SOA bietet, sind selbst serviceorientiert. Sie sind innerhalb des ESB in einzelnen Service-Containern verteilt (Chappell, 2005), was ein leichtes Hinzufügen neuer Komponenten erlaubt und ein hohes Maß an Flexibilität bietet.

Auch Ressourcen und einzelne Komponenten werden bei SOA als Services betrachtet, auf die unabhängig vom Standort zugegriffen werden kann. Sie bieten eine definierte Funktionalität und sind wieder verwendbar. Um die Unabhängigkeit und Portabilität zu unterstützen, werden Daten bei einem Service oft mit Hilfe von XML formatiert (Erl, 2004, S.48f).

SOA soll genau wie VS die in Tabelle 1 genannten Transparenzen erfüllen. Da die Realisierung eines Services strikt von seiner Beschreibung getrennt sein muss, gibt es Standards zur Kommunikation. Bei Web Services ist dies beispielsweise die Web Service Definition Language (WSDL) (Erl, 2004, S.66).

2.5 Complex Event Processing

2.5.1 Events und deren Eigenschaften

Das Konzept von Events ist elementar für das Verständnis von CEP. Unter einem Event versteht man ein Objekt, das die Aktivität eines Systems bezeichnet. Es kann unterschiedliche Attribute oder Datenkomponenten enthalten. Üblicherweise enthält ein Event den Zeitpunkt bzw. die Zeitperiode des Auftretens, den Ort des Auftretens, den Grund des Auftretens und die Relationen zu anderen Events (Luckham, 2002, S.88-90). Des Weiteren kann ein Event durchgeführte Aktivitäten und Datenwerte enthalten und wird mit einer eindeutigen Identifikationsnummer versehen (Luckham, Vera, 1995, S.719). Nicht zu verwechseln ist ein Event mit einer Nachricht. Zwar wird ein Event oft wie eine Nachricht generiert, es enthält jedoch mehr Informationen (Luckham, 2002, S.90).

Im Folgenden werden nun grundlegende Eigenschaften von Events beschrieben.

Zeit ist eine elementare Eigenschaft von Events. Jedes Event erhält zum Zeitpunkt der Erzeugung eine Zeitmarke. Handelt es sich um ein Event, das über eine Zeitperiode auftritt, dann wird diese durch mehrere Zeitmarken beschrieben. Mit Zeitmarken ist es möglich, zeitliche Beziehungen zwischen Events herzustellen (Luckham, 2002, S.90-98).

Eine wichtige Eigenschaft eines Events ist, wer dieses verursacht hat und aus welchem Grund. Unter dem Begriff der Kausalität versteht man den Zusammenhang zwischen Ursache eines Events und dessen Wirkung. Beispielsweise verursacht Event A unter bestimmten Bedingungen Event B. Auch die Unabhängigkeit zweier Events ist eine typische Kausalität. Kausalität lässt sich noch unterscheiden in horizontale und vertikale Kausalität. Der Begriff der horizontalen Kausalität sagt aus, dass ein Event ein anderes verursacht hat und beide Events sich auf derselben konzeptuellen Ebene (Abstraktionsstufe) befinden (Luckham, 2002, S.10). Die vertikalen Kausalität hingegen beschreibt den Zusammenhang zwischen Events, bei denen sich ein Event, das ein anderes auslöst, auf einer tieferen konzeptuellen Ebene befindet (Luckham, 2002, S.15). Dies ist beispielsweise bei mehrschichtigen IT-Systemen, die im Abschnitt 2.1.3 eingeführt wurden, der Fall.

Events können aus den unterschiedlichsten Quellen stammen. Die können beispielsweise Quellen wie DBS, Einzelanwendungen, Betriebssysteme, ERP-Systeme, Feuermelder, Log-Dateien, RFID-Chips oder Sonden sein.

Einzelne Events haben oft für sich genommen keine Aussagekraft. Mehrere logisch zusammenhängende Events werden deshalb bei CEP zu einem neuen, so genannten „Komplexen Event“ zusammengefügt. Dies findet in dem Prozess des Event-Mining statt (Perrochon et al., 1999b, S.474-478) und wird als Aggregation bezeichnet. Die Aggregation eines Events zeigt auf, welche Events das zu betrachtende Event ausgelöst haben. Voraussetzung für ein Komplexes Event ist demnach das Auftreten von Events (Luckham, 2002, S.XV). Ein Komplexes Event besitzt eine hohe Aussagekraft für den Empfänger.

Ein Beispiel dafür ist das Erkennen von Phishing, einer Form des Trickbetruges im Onlinebanking. Ziel ist das Festsstellen einer unerlaubten Kontonutzung zu einem Zeitpunkt, an dem noch Eingriffsmöglichkeiten, z. B. das Sperren eines Kontos oder das Stoppen einer Transaktion, vorhanden sind. Treten einzelne Indikatoren, also einzelne Events wie beispielsweise eine Passwortänderung und eine Abbuchung des maximal möglichen Betrages bei demselben Konto innerhalb von 10 Minuten auf, so wird ein Komplexes Event „Phishing-Verdacht“ erzeugt. Sobald dieses Komplexe Event auftritt, wird die Transaktion gestoppt und ein Sachbearbeiter informiert. So wurde aus in diesem Kontext für sich genommen nicht aussagekräftigen Events ein Komplexes Event aggregiert, das eine hohe Aussagekraft besitzt.

2.5.2 Definition und Zielsetzung

Die Idee des CEP ging aus der Arbeit des Rapide™ Projekts der Stanford University hervor. Diese hat die gleichnamige, objektorientierte Prototyp-Sprache für die Definition und Modellierung von IT-Architekturen in VS entwickelt. Rapide™ erlaubt die Simulation und Verhaltenanalyse von IT-Architekturen während des Entwicklungsprozesses (Luckham et al., 1995, S.336). Diese wurde so weiterentwickelt, dass sie als Beschreibungs-Sprache für CEP verwendet werden kann.

CEP bezeichnet eine neue Technologie, die auf dem Konzept der Events basiert, das in Abschnitt 2.5.1 erläutert wurde. Alle im Unternehmen auftretenden für GP relevanten Ereignisse und Prozesszustände werden bei CEP als Events betrachtet und so weiterverarbeitet, dass daraus bedeutsame und aussagekräftige Events entstehen, die weiterverwendet werden können.

Events werden von CEP zum Zeitpunkt des Auftretens bearbeitet und daher können dem Benutzer neue Events sofort präsentiert werden. Verzögerungen treten dabei nur durch mangelnde Geschwindigkeit der Netzinfrastruktur auf (Perrochon et al., 2000, S.415f).

Unter CEP im engeren Sinne wird lediglich das Softwaremodul zur Verarbeitung von Events in Datenströmen verstanden. Synonym hierzu wird in der Literatur und Praxis der Begriff des „Event Stream Processing (ESP)“ verwendet. In dieser Arbeit wird der Begriff von CEP weiter gefasst und auch als IT-Architektur gesehen, die im Verbund mit anderen Technologien operiert. Das Kernmodul von CEP wird in den folgenden Unterabschnitten ausführlich beschrieben.

CEP arbeitet in Echtzeit und liefert Informationen für Benutzer zur Bewältigung von Management-Aufgaben. Des Weiteren liefert es Status-, Fehler- und Alarmmeldungen in Echtzeit, wobei die Informationen je nach Informationswunsch aus VS herausgezogen werden (Luckham, Frasca, 1998, S.1). CEP bietet neben schneller Reaktionsfähigkeit auch die Möglichkeit, die Suchstrategie der internen Logik zur Laufzeit zu ändern (Perrochon, 1999a, S.9).

Die Fähigkeit eines Systems, das Augenmerk eines Benutzers in Echtzeit auf betriebswirtschaftliche dringende und relevante Aufgaben zu richten, wird auch als Business Activity Monitoring (BAM) bezeichnet. BAM ist eine Technologie, die automatisiert eine Echtzeitüberwachung der Geschäftsaktivitäten eines Unternehmens bietet. Diese basiert auf stets aktuellen Daten (Van Hasselt, 2004, S.15). CEP bietet eine gute Möglichkeit, BAM zu realisieren, bietet jedoch darüber hinaus gehende Fähigkeiten.

Je nach Aufgabenbereich benötigen Mitarbeiter unterschiedliche Informationen. Bei CEP existieren dafür unterschiedliche, personalisierte Sichten für Benutzer. Jede Sicht behandelt dabei einen Problembereich. Sie sind gesteuert durch Events und können als GUI dargestellt werden. Ebenso kann ein Benutzer durch sie neue Events anstoßen. Sichten sind leicht anpassbar (Luckham, 2002, S.54-59).

2.5.3 Eventverarbeitende Agenten

Zur Verarbeitung von Events verwendet CEP Agenten. Unter einem Agent versteht man eine autonome Softwareeinheit, die in der Lage ist, eine Aufgabe in Zusammenarbeit mit anderen, möglicherweise verteilten, Agenten auszuführen (Tanenbaum, van Steen, 2003, S.210). Agenten führen dabei eigenständige Aktionen durch, für die kein externer Benutzer oder Agent notwendig ist, und können auch Elemente einer KI enthalten (Jennings, Wooldridge, 1998, S.4). CEP verwendet Agenten, um Events zu überwachen und weiterzuverarbeiten. Sie dienen als Werkzeug zur Entscheidungsfindung und werden als Event Processing Agents (EPA) – Eventverarbeitende Agenten – bezeichnet.

Ein EPA ist ein Objekt, das Eventmuster entdecken kann (Luckham, 2002, S.175-177). Ein Eventmuster bezeichnet einen Zustand im System, der gesucht wird. Eventmuster definieren eine Menge an Events anhand deren Kausalität, Zeit, Datenparameter oder Kontext (Luckham, 2002, S.114). Eventmuster werden von Benutzern oder automatisiert erstellt.

Für das Auffinden von Eventmustern ist eine Eventmustersprache notwendig. Ein Beispiel dafür ist die in Abschnitt 2.5.1 erwähnte Rapide™-Event Processing Language (EPL). Momentan gibt es keine einheitliche und standardisierte EPL, die meisten Hersteller verwenden daher eigene EPLs. Wird ein Eventmuster entdeckt, existieren Entscheidungsregeln, die die nächsten Schritte festlegen (Luckham, 2002, S.114-116).

Perrochon et al. (1999b, S.475) haben diese EPAs in Event-Lieferanten („event supplier“), Event-Verarbeiter („event processors“) und Event‑Abnehmer („event consumers“) unterteilt.

Die Event-Lieferanten können ihren Input durch sog. „Lauscher“ bekommen, die Nachrichten von externen, zu überwachenden Systemen, durch das Lesen von Log‑Dateien oder durch andere Quellen erhalten. Event-Lieferanten können auch ohne externen Input im CEP-System selber Events produzieren. Für unterschiedliche externe Systeme gibt es dabei unterschiedliche Event-Lieferanten. So gibt es Adapter, die Events oder Pakete aus einer Middlewareschicht in CEP-Events umwandeln. Adapter können auch direkt an eine Anwendung angeschlossen sein und Anwendungsdaten in CEP-Events transferieren.

Der zweite Typ von EPA sind Event-Verarbeiter. Diese kann man unterteilen in Filter, Abbilder („mapper“) und Beschränker („constraints“). Filter suchen aus der Gesamtheit der Events diejenigen Events aus, die dem Eventmuster entsprechen. Abbilder führen die Aggregation von Events mit passenden Eventmustern zu Komplexen Events durch. Beschränker geben bei bestimmten Eventmustern Warnungen aus, wie z. B. bei Zugriffsverletzun­gen oder Systemausfällen. Die Regeln der Event-Verarbeiter basieren hauptsächlich auf logischen Operatoren. So verwenden die Beschränker Ausdrücke wie „immer“ oder „nie“ (Luckham, 2002, S.177ff).

Event-Abnehmer benachrichtigen den Benutzer über signifikante Aktivitäten. Dies kann beispielsweise durch GUIs, textbasiert oder durch E-Mails erfolgen. Event-Abnehmer können nicht nur Benutzer informieren, sondern auch eigenständig Prozesse anstoßen.

Abbildung 2 zeigt exemplarisch die Arbeit der Agenten. Der Event-Produzent stellt Events aus der Gesamtheit der verfügbaren Events für die folgenden Agenten zur Verfügung. Der Filter sucht aus den Events die relevanten Events heraus. Der Abbilder wartet auf das Auftreten von speziellen Events anhand festgelegter Eventmuster und aggregiert diese zu einem Komplexen Event. Der Beschränker erstellt immer, wenn das Komplexe Event A auftritt, das Komplexe Event B. Der Event-Abnehmer schließlich stößt eine Aktion an, beispielsweise eine E-Mail an einen Benutzer.

Neben diesen spezifischen CEP-Agenten können auch Agenten für spezielle Aufgaben verwendet werden (Luckhan, 2002, S.204f).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2: Verarbeitung von Events

(Quelle: Eigene Grafik)

2.5.4 Eventverarbeitende Netzwerke

Das EPN – das Eventverarbeitende Netzwerk – ist das System, in dem EPAs Events anhand von den in 2.5.3 genannten Regeln sammeln und über verschiede konzeptionelle Ebenen weiterreichen (Perrochon et al., 2000, S.2). Das Netzwerk von EPAs ist auf mehrere Ebenen aufgeteilt. Die Events werden dabei von diesen EPAs mit Hilfe des Event-Mining durchsucht, auf deren Idee EPNs basieren. Die Komplexen Events werden an den jeweils nächsten Agenten eine Ebene höher im Netwerk weitergegeben.

EPNs werden durch einen Event-Service unterstützt, der in 2.5.5 näher erläutert wird. Der Ablauf eines EPNs ist in Abbildung 3 zu sehen. Dort sind auch die Zugriffe der EPAs auf den Event-Service dargestellt.

Die Bearbeitung der Events im EPN und die Ausgabe an einen Benutzer laufen in Echtzeit ab (Perrochon et al., 1999b, S.476).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3: CEP mit EPN und Event-Service

(Quelle: in Anlehnung an Perrochon, Kasriel, Luckham, 2000, S.416)

Die Topologie des EPNs ist dynamisch, d. h. es kann sich zur Laufzeit ändern. Agenten können also zu jeder Zeit hinzugefügt oder entfernt werden (Perrochon et al., 2000, S.413).

CEP kann statt mit einem EPN alternativ auch mit einer Entscheidungsmaschine betrieben werden. Dies ist ein besonderer EPA, der alle Entscheidungsregeln für eine CEP Anwendung enthält. Die Entscheidung für ein EPN oder eine Entscheidungsmaschine hängt vom Zielsystem und der konkreten CEP Anwendung ab (Luckham, 2002, S.208-211).

2.5.5 Event-Service

Intern stellt ein Event-Service die Ressourcen für CEP und speziell für ein EPN zur Verfügung. Es handelt sich dabei um Ressourcen wie ein Event-Repository, ein Event-Schema-Repository, EPA-Vorlagen sowie eine Konsumentenkartei (TPerrochon, 2000, S.415).T

Die Event-Repositories, spezielle Datenablagen für Events und Event-Schemata, verwenden Event-DBS. Hier werden alle CEP-Events persistent gespeichert. Die EPAs können dann darauf zugreifen und sich so sowohl aktueller als auch historischer Events bedienen. Wenn EPAs Events oder Komplexe Events erzeugen, speichern sie diese ebenfalls in einem Event-Repository. Repositories sind DBS, die mit zusätzlicher Logik versehen wurden (Mihaeli und Etzion, 2004, S.1). Bei einem Event-Repository handelt es sich häufig um ein Repository, das sich im Speicher oder Cache befindet und dadurch sehr schnell die Events bereitstellt.

Außerdem bietet der Event-Service noch Vorlagen für EPAs. Diese sind anpassbar und ermöglichen, auch zur Laufzeit, eine leichte Erstellung und Aktivierung neuer EPAs (Perrochon et al., 2000, S.415f). Vorlagen werden üblicherweise entweder von einem CEP-Hersteller oder von der IT-Abteilung eines Unternehmens für häufig verwendete Agenten bereitgestellt.

Die Konsumentenkartei beinhaltet eine Registrierung der Event-Abnehmer, d. h. es wird gespeichert, welcher Abnehmer an welchem Komplexen Event interessiert ist (Perrochon et al., 2000, S.415f). So findet der Event-Abnehmer zu jedem Zeitpunkt die Benutzer (oder andere Empfänger), die über ein Event benachrichtigt werden sollen.

Die Kommunikationsbeziehungen zwischen den CEP-Agenten und dem Event Service sind in Abbildung 3 zu sehen.

Im Gegensatz zu Eventmustern definieren Eventschemata das Format der Events, das durch den Event-Service verschickt wird (Perrochon et al., 2000, S.416). Schemata definieren dabei, welche Art von Informationen vorhanden sein muss und welches Format diese Informationen haben müssen.

2.5.6 Anzeige- und Analysemöglichkeiten

CEP-Produkte bieten sowohl eigene Analyse- und Anzeigemodule als auch die Möglichkeit, dies durch externe Module erledigen zu lassen. Eine direkte Benachrichtigung eines Benutzers kann z. B. mittels E-Mail erfolgen, Nachrichten und Übersichten können in GUIs dargestellt werden.

CEP bietet optimale Voraussetzungen zur Unterstützung von Monitoringwerkzeugen, wie sie auch bei BAM zu finden sind. Monitoring ist die Überwachung, Beobachtung oder Steuerung von Aktivitäten und Kennzahlen eines Unternehmens. Für viele Unternehmen ist eine solche übersichtliche Anzeige aller für eine Aufgabe relevanten Informationen auf genau einer Bildschirmseite wichtig. Durch Verknüpfungen kann man ggf. dann Informationen aus einzelnen Bereichen genauer betrachten. Solche Anzeigen sind z. B. Dashboards, die häufig in Webportalen angezeigt werden. Unter einem Dashboard versteht man eine visuelle Anzeige der wichtigsten Informationen die benötigt werden, um eine oder mehrere Aufgaben zu erfüllen. Die Informationen sind dabei aus verschiedenen Quellen zusammengeführt und auf einer einzigen Bildschirmseite so angeordnet, dass sie auf einen Blick erfasst werden können (Few, 2004, S.2). Anzeigeinstrumente innerhalb eines Dashboards können Tabellen, Meter, Ampeln oder sonstige Anzeigeinstrumente sein.

Betriebswirtschaftlich gesehen ist CEP damit die „Zusammenfassung aller im Unternehmen vorliegenden Informationen zu einer umfassenden Balanced Scorecard (BSC) mit Key Performance Indicators (KPIs) und Dashboards, die den Zielgruppen vom Unternehmensmanagement bis hin zum Sachbearbeiter-Level alle entscheidungsrelevanten Daten in einem modernen Portal zur Verfügung stellt“ (Nußdorfer, 2005).

CEP stellt unterschiedliche Werkzeuge zur Verfügung, die dem Benutzer Eingriffsmöglichkeiten in das System bieten. Auf der einen Seite gibt es Werkzeuge, um zur Laufzeit Agenten bzw. deren verwendete Eventmuster zu verändern, erweitern oder hinzuzufügen. Auf der anderen Seite gibt es Analysewerkzeuge, mit Hilfe deren man vom System gelieferte Ergebnisse analysieren sowie Zusatzaufgaben erfüllen kann. Auf Details dieser Analyseprogramme wird in dieser Arbeit nicht eingegangen.

Ein Beispiel eines CEP-Analysewerkzeuges ist „Causal History Tracking“ (CHT) (Luckham, 2002, S.353-355). Dabei kann ein Benutzer Schritt für Schritt nachvollziehen, wie ein Komplexes Event zu Stande kam. Zeigt beispielsweise ein Manometer, das den Druck in einem Leitungssystem überwacht, einen abfallenden Druck an, wird eine Warnung ausgegeben. Um jedoch die Ursache des Druckabfalls zu ermitteln, kann CHT mit Hilfe vieler einzelner Informationen über das Leitungssystem detailliert nachverfolgen, an welcher genauen Stelle die Ursache des Druckabfalls war, also beispielsweise ein Leck an einer weit vom Manometer entfernten Stelle. Mit CHT können so im Nachhinein Ursachen für Probleme in Prozessen gefunden werden und es kann ggf. eine Optimierung der Prozesse stattfinden.

2.5.7 Architektur

Eine Übersicht über eine mögliche CEP-Architektur ist in Abbildung 4 zu sehen. Für jeden Benutzer oder Prozess, der mit CEP verknüpft ist, sind Event-Abnehmer vorhanden. Dabei sind zum einen Ressourcen über einen ESB mit CEP verbunden und zum anderen allein stehende Anwendungen ohne einen ESB direkt mit CEP verbunden. Um Events aus verschiedenen Systemen mit CEP kompatibel zu machen, sind Adapter vorgeschaltet, die als Softwareschnittstelle dienen.

[...]