Integration von Daten, Anwendungen und Prozessen am Beispiel des Telekommunikationsunternehmens EWE...

1 Einleitung

Das Telekommunikationsgeschaft ist durchdie Verarbeitung von Massendaten beson-derer Großenordnung gepragt. Schwer-punkte bilden dabei Kunden- und Ver-tragsdaten, kaufmannische Daten,Aufzeichnungen uber die Nutzung vonDaten- und Sprachdiensten sowie Informa-tionen uber die Verfugbarkeit und Nut-zung der technischen Ressourcen, wie z. B.Belegung der Teilnehmervermittlungsstel-len. Die notwendige Spezialisierung der In-formationsverarbeitung im Bereich der Te-lekommunikation hat dazu gefuhrt, dassauf dem Softwaremarkt eine Vielzahl vonSpezialsystemen angeboten wird, aberkaum leistungsfahige, integrierte Gesamt-losungen existieren, wie dies z. B. SAP R/3fur die kaufmannische Datenverarbeitungleistet. Beispiele fur diese Spezialsystemesind:

& Customer-Relationship-Management-Systeme (CRM-Systeme),

& Billing-Systeme fur Sprach- und Inter-netdienste,

& Enterprise-Resource-Planning-Systeme(ERP-Systeme) und

& Systeme zur Verwaltung der Kabel- undNetzstruktur (KNV-Systeme).

Die wenigen verfugbaren integrierten Ge-samtlosungen decken haufig nur die Anfor-derungen von Telekommunikationsunter-nehmen in den Aufbaujahren ab undstoßen in der dynamisch wachsenden Tele-kommunikationsbranche schnell an ihreGrenzen. Obwohl die zugrunde liegendenSoftwaresysteme auf den ersten Blickdurch kurze Einfuhrungszeiten, integrierteDatenbestande, einfache Bedienbarkeit und

geringen Bedarf an Ressourcen gekenn-zeichnet sind, stehen dem auf den zweitenBlick haufig Nachteile wie begrenzte Ska-lierbarkeit und funktionale Beschran-kungen im Vergleich zu Spezialsystemengegenuber. Entscheidet sich ein Telekom-munikationsunternehmen nach Abwagungder Vor- und Nachteile fur den Einsatzvon Spezialsystemen, so stellt sich die an-spruchsvolle Aufgabe der Systemintegrati-on, die im Mittelpunkt des vorliegendenArtikels steht.

1.1 Anforderungenan die Systemintegration

Neben der Integration der von Spezialsys-temen verwalteten operativen Daten mus-sen auch anwendungsubergreifende An-forderungen berucksichtigt werden. Sofuhrt die Verteilung der Informationsver-arbeitung auf kooperierende Spezialsyste-me dazu, dass bei der Bereitstellung vonInformationen fur die Unternehmens-steuerung, z. B. durch Data-Warehouse-Systeme, Schnittstellen zu nahezu allenwichtigen Softwaresystemen benotigt wer-den.

Des Weiteren verleiht die starke Kunden-orientierung des Telekommunikations-geschafts der Geschaftsprozessoptimierungund -automatisierung besondere Bedeu-tung. Kurze Produkteinfuhrungszeiten er-fordern eine hohe Flexibilitat bei der Im-plementierung neuer und der Anpassungbestehender Geschaftsprozesse. Workflow-Management-Systeme bieten die hierfurnotwendige Flexibilitat, ermoglichen die

WIRTSCHAFTSINFORMATIK 44 (2002) 5, S. 415–423

Die Autoren

Bernd BunjesJorg FriebeRainer GotzeArne Harren

Dipl.-Inform. Bernd Bunjes,OSC – Information Management AG,Industriestraße 11,D-26121 Oldenburg,Tel. (04 41) 3 50 42 – 3 01,E-Mail: [email protected];Dr. Jorg Friebe,OSC – Information Management AG,Industriestraße 11,D-26121 Oldenburg,Tel. (04 41) 3 50 42 – 3 19,E-Mail: [email protected];Dr. Rainer Gotze,EWE TEL GmbH,Cloppenburger Straße 310,D-26133 Oldenburg,Tel. (04 41) 80 00 – 17 00,E-Mail: [email protected];Dipl.-Inform. Arne Harren,OFFIS - Oldenburger Forschungs- undEntwicklungsinstitut fur Informatik-Werkzeuge und -Systeme,Escherweg 2,D-26121 Oldenburg,Tel. (04 41) 97 22 – 1 26,E-Mail: [email protected]

Integration von Daten,Anwendungen und Prozessen amBeispiel des Telekommunikations-unternehmens EWE TEL

WI – Schwerpunktaufsatz

Steuerung der Kommunikation zwischenSpezialsystemen und unterstutzen damitdie Prozessintegration.

Der Einsatz von kooperierenden Spezial-systemen fur die Informationsverarbeitungstellt daher hohe Anforderungen an dieSystemintegration:

& Die Integration darf die Release-Fahig-keit der einzelnen Spezialsysteme nichtbehindern und die Verfugbarkeit derEinzelsysteme sowie des Gesamtsystemsnicht beeintrachtigen. Solche Anforde-rungen sprechen fur eine lose Kopplungder einzelnen Softwaresysteme. Als Fol-ge dieser losen Kopplung und einer ver-teilten sowie teilweise redundanten Da-tenverwaltung, z. B. der Kunden- undVertragsdaten in CRM- und Billing-Sys-temen, ist eine anwendungsubergreifen-de Datenkonsistenz gefordert.

& Durch die Koexistenz verschiedenerSpezialsysteme werden dem Anwendergleichartige Funktionen, z. B. Stamm-datenverwaltung oder Suchfunktiona-litat, mehrfach und in verschiedenenBenutzungsoberflachen zugemutet.Wahrend klassische Client-Anwendun-gen kaum Moglichkeiten der Integrationvon Funktionen und Benutzungsober-flachen bieten, entsteht mit dem zuneh-menden Einsatz von Internet-Technolo-gie die Forderung nach Anwendungs-integration durch Wiederverwendungvon Funktions- und Dialogobjekten.

& Die uberwiegend funktional ausgerich-teten Spezialsysteme bieten kaum In-

strumente fur die Integration der an-wendungsubergreifenden Prozesse. Dersich anbietende Einsatz von Workflow-Management-Systemen schafft jedochzusatzliche Schnittstellen und erforderteine weitreichende Integration der anden Prozessen beteiligten Anwendun-gen. Unternehmensubergreifende Ge-schaftsprozesse beinhalten dabei haufigMedienbruche, da sie meistens papier-gestutzt (z. B. Auftrage und Auftrags-bestatigungen) beginnen und enden. Umdie Auswirkungen dieser Medienbrucheauf die Prozessautomatisierung zu mini-mieren, ist ein integriertes, elektro-nisches Management der eingehendenund ausgehenden Dokumente mit An-bindung an ein Workflow-Management-System erforderlich.

Die Systemintegration in einem Telekom-munikationsunternehmen ist also durch dieEbenen Daten-, Prozess- und Anwen-dungsintegration gepragt.

1.2 Systemlandschaftbei der EWE TEL

Als Beispiel fur praktizierte Ansatze zurBewaltigung dieser drei Ebenen soll indiesem Artikel die EWE TEL, ein jungesTelekommunikationsunternehmen mit Ver-triebsschwerpunkt im Ems-Weser-Elbe-Gebiet, dienen. Das schnelle Wachstum derEWE TEL hat von Beginn an der Unter-stutzung durch eine leistungsfahige Infor-mationsverarbeitung besondere Bedeutung

verliehen. Die EWE TEL hat sich dabei furdie Integration kooperierender Spezialsys-teme entschieden. Bild 1 zeigt einen Aus-zug aus der heutigen Systemlandschaft derEWE TEL.

Im Einzelnen werden bei der EWE TELfolgende Systeme eingesetzt:

& Das ERP-System ist fur die Abwicklungder kaufmannischen Informationsver-arbeitung insbesondere der Debitoren-buchhaltung und des Zahlungsverkehrszustandig.

& Fur die Abrechnung von Sprach- undInternet-Diensten werden getrennte Bil-ling-Systeme verwendet, die hierfur er-forderliche Kunden- und Vertragsdateneigenstandig verwalten. Obwohl moder-ne Billing-Systeme heute so allgemeinausgelegt sind, dass sie bei entsprechen-der Anpassung der Komponenten furdie Vorverarbeitung der Rohdaten vonden technischen Plattformen, sog. Me-diation Devices, sowohl Sprach- als auchInternet-Dienste abrechnen konnen, bie-ten spezialisierte Internet-Billing-Syste-me eine deutlich hohere „Off-the-Shelf“-Funktionalitat und gewahrleistendamit kurzere Produkteinfuhrungszei-ten sowie eine hohere Reaktionsfahigkeitauf die Dynamik des Internet-Marktes.

& Die Verwaltung von Kundendaten er-folgt in insgesamt vier Systemen: ERP-System, CRM-System und Sprach-sowie Internet-Billing-System. Zur Lo-sung des damit verbundenen Problemsder anwendungsubergreifenden Daten-konsistenz wurde eine integrierte Kun-dendatenbank (IKDB) entwickelt. DieIKDB setzt auf einer modernen Appli-cation-Server-Technologie auf und reali-siert eine zentrale Verwaltung der Kun-dendaten sowie ihre gezielte Replikationin die angeschlossenen Systeme. DerAbgleich abrechnungsrelevanter Datenaus dem CRM-System und dem Billing-System fur Sprachdienste erfolgt ubereine leistungsfahige, eigenentwickelteMiddleware.

& Die Kabel- und Netzverwaltung ist di-rekt an das CRM-System angebunden,um die fur die Bearbeitung von Kun-denauftragen erforderlichen technischenRessourcen im direkten Zugriff zu ha-ben.

& Das CRM-System besitzt weitereSchnittstellen zu den gesetzlich durchdas Telekommunikationsgesetz (TKG)vorgeschriebenen Systemen. Dies sindzurzeit der Portierungsserver, fur die


Enterprise-Resource-Planning-System

Integrierte Kundendatenbank

Internet-Billing-System

Kabel- und Netz-verwaltungssystem

Sprach-Billing-System

Customer-Relationship-Management-

System Provisionierungs-system

Data-Warehouse-System

Workflow-

Optisches Archiv

Management-System /

Portierungs- undAuskunftsserver

Bild 1 Systemlandschaft der EWE TEL

416 Bernd Bunjes, Jorg Friebe, Rainer Gotze, Arne Harren

Verwaltung von Rufnummern, und derAuskunftsserver, der die automatisierteAuskunft fur Strafverfolgungsbehordenund Notrufstellen ermoglicht.

& Das Workflow-Management-Systemund das CRM-System besitzen eine bi-direktionale Schnittstelle, uber die voneinzelnen Geschaftsfallen gezielt zu denKundendaten und Dialogmasken desCRM-Systems verzweigt werden kann.Umgekehrt konnen uber diese Schnitt-stelle vom CRM-System aus die imWorkflow-Management-System verwal-teten Geschaftsfalle und Dokumenteeinzelner Kunden abgefragt werden.

& Die vom CRM-System verwalteten In-formationen uber die von Vertriebspart-nern abgeschlossenen Vertrage werdenvon einem Provisionierungssystem aus-gewertet, das direkten Zugriff auf dieDaten des CRM-Systems besitzt unddie berechneten Provisionen zur Aus-zahlung an das ERP-System ubergibt.

Die Systemlandschaft der EWE TEL ist al-so durch eine Kopplung von Spezialsyste-men und damit durch heterogene, verteilteInformationsbestande gepragt. In dennachfolgenden Kapiteln werden die in die-sem Umfeld angewendeten Konzepte derSystemintegration beschrieben, wobei eineGliederung anhand der drei aufeinanderaufbauenden Ebenen Daten-, Anwen-dungs- und Prozessintegration erfolgt.

2 Datenintegration

Grundlegende Techniken zur Integrationvon Informationssystemen sind auf derEbene der Datenbestande bzw. auf Basisder Schemata zugrunde liegender Daten-banken angesiedelt. Diese Basistechnikenermoglichen es, neben einer fur Anwen-dungen transparenten Einbindung externerDaten, vorhandene Zustandigkeiten furDatenpflege und -verwaltung zu erhaltensowie die Autonomie existierender An-wendungen zu wahren. In diesem Ab-schnitt wird daher naher auf die Einfuh-rung globaler Anwendungen, auf denZugriff auf externe Daten uber Import-/Export-Schemata sowie auf Replikations-ansatze eingegangen.

Als Voraussetzung fur die Integration ex-terner Datenbestande auf Basis dieser An-satze mussen Systemhersteller die Semantikder Datenschemata offen legen bzw. dendirekten Zugriff auf den Datenbestand frei-

geben. Ist dieser Zugriff nur uber spezielleApplication Programming Interfaces(APIs) moglich, so sind Ansatze, die nurauf Mechanismen beteiligter (relationaler)Datenbankmanagementsysteme (DBMS)basieren, nicht anwendbar.

2.1 Globale Anwendungen

Einen im Bereich foderierter Datenbank-systeme verbreiteten Ansatz der Dateninte-gration stellt z. B. die 5-Ebenen-Schema-Architektur [ShLa90] dar, mittels dererglobalen Anwendungen der transparenteZugriff auf einen integrierten, virtuellenGesamtdatenbestand ermoglicht wird. Die-ser Gesamtdatenbestand wird dabei durchalle an der Foderation beteiligten Kom-ponentensysteme gebildet, die fur die Ver-waltung ihres Datenbestandausschnitts zu-standig sind. Der Zugriff auf dieFoderation erfolgt bei der Architektur uberein zusatzliches, globales System, dem einintegriertes Datenschema zugrunde liegt.Strukturelle und semantische Inkompatibi-litaten, z. B. unterschiedliche Modellierun-gen und Kodierungen, zwischen beteiligtenKomponentensystemen mussen daherbeim Aufbau einer Foderation und der Bil-dung eines globalen Schemas aufgelostwerden [vgl. Conr97].

Obwohl bei der IKDB die Integration derDatenbestande aufgrund der Anforderungeiner losen Kopplung nicht wie im klassi-schen Sinne uber einen virtuellen Gesamt-datenbestand erfolgt, bildet die IKDB eine

globale Anwendung im weiteren Sinne undermoglicht dem Anwender zentralen Zu-griff auf einen integrierten Gesamtdaten-bestand, der durch das CRM-System, dasERP-System und das Internet-Billing-Sys-tem gebildet wird. Die erforderliche Da-tenintegration wird auf der Ebene derIKDB-Anwendung durchgefuhrt.

2.2 Import-/Export-Schemata

Die Integration vorhandener Informations-systeme erfolgt nicht nur aufgrund der Er-fordernis einer globalen Datensicht, wiez. B. im Falle der IKDB, sondern ist auchin der Durchsetzung einer anwendungs-ubergreifenden Datenintegritat motiviert.Wie bereits einleitend erwahnt, ist es auf-grund des Funktionsumfangs, vorhandenerSchnittstellen oder notwendiger Zertifizie-rungen im Bereich der Telekommunikationunumganglich, kooperierende Spezialsys-teme einzusetzen. Aus organisatorischerSicht ist hierbei jedes System nur fur dieVerwaltung eines Ausschnitts des Gesamt-datenbestandes zustandig, wahrend jedochauf technischer Ebene jedes System zurAusfuhrung seiner Aufgaben weitere Da-ten benotigt, fur deren Verwaltung ein an-deres System zustandig ist. So werden z. B.im Sprach-Billing-System Daten uberKunden und Vertrage benotigt, die imCRM-System verwaltet werden.

Die Integration der von verschiedenen Sys-temen benotigten, extern verwalteten Da-tenbestande kann z. B. auf Basis der in


Kernpunkte fur das Management

Die Integration von Softwaresystemen in der Informationsverarbeitung kann mindestens aufden Ebenen der Daten, Anwendungen und Prozesse betrachtet werden. Am Beispiel derheterogenen Systemlandschaft des Telekommunikationsunternehmens EWE TEL werden indiesem Artikel Konzepte der Systemintegration auf diesen Ebenen und die mit ihnen im Pra-xiseinsatz gemachten Erfahrungen vorgestellt. Im Einzelnen werden dabei die folgendenPunkte behandelt:

& Datenintegration durch Middleware,& Anwendungsintegration mit Application-Servern,& Prozessintegration mit Workflow-Management-Systemen.

Stichworte: Telekommunikationsbranche, Systemintegration, Datenintegration, Anwen-dungsintegration, Prozessintegration, Middleware-Losungen, Enterprise Application Inte-gration

Integration von Daten, Anwendungen und Prozessen 417

[HeMc85] vorgestellten Import-/Export-Schema-Architektur erfolgen. In dieser Ar-chitektur stellt jedes System Teile des eige-nen, privaten Datenbestandes in Form vonExport-Schemata anderen Systemen zurVerfugung. An den Daten interessierteSysteme integrieren benotigte Ausschnitteverfugbarer Export-Schemata in lokaleImport-Schemata, sodass sich der Daten-bestand eines jeden Systems nun aus demprivaten und dem durch Importe beschrie-benen Datenbestand zusammensetzt. An-fragen, die an Import-Schemata gestelltwerden, werden in der Architektur an dieExport-Schemata der anderen Systemeweitergeleitet. Schema- und Datenkonfliktezwischen den einzelnen Systemen mussenbei der Definition der Export- und Im-port-Schemata aufgelost werden.

Aufgrund der heterogenen Systemland-schaft und insbesondere des Einsatzes vonkooperierenden Spezialsystemen ist esnicht immer moglich, die gemaß der Im-port-/Export-Schema-Architektur beno-tigten Zusatzschemata innerhalb der Syste-me zu definieren. Des Weiteren mussenden Anwendungen die benotigten Import-Schemata bekannt sein, damit auf diese ak-tiv zugegriffen werden kann. Obwohl dieArchitektur aufgrund der aktiven Nutzungder Import-Schemata durch die Anwen-dungen eine lose Kopplung der Systeme er-moglicht, ist als Nachteil zu nennen, dassbeim Zugriff auf Import-Schemata alle be-teiligten Systeme verfugbar sein mussen.

Auf Basis von Import-/Export-Schema-Ansatzen sind zurzeit z. B. die Systemezur Provisionierung und zur Kabel- undNetzverwaltung (KNV-System) mit demCRM-System verbunden. Als Hilfsmittelkommen hierbei u. a. Datenbank-Linksund Stored Procedures zum Einsatz. Bei

der bidirektionalen Kopplung zwischenCRM-System und KNV-System wurdeinsbesondere berucksichtigt, dass nebensynchronen Zugriffen auf die Import-Sche-mata auch eine asynchrone Kommunika-tion erfolgen kann, falls das jeweilige exter-ne System nicht verfugbar ist.

2.3 Replikation

Als eine weitere Alternative zur Kopplungvon Datenbestanden und Sicherung derDatenintegritat bieten sich Replikations-ansatze an, bei denen externe Daten direktin den privaten Datenbestand des Systemsubertragen werden, in dem die Daten be-notigt werden. Vorteil dieses Ansatzes ist,dass dem System nicht bekannt sein muss,dass ein Teil des Datenbestandes aus einemanderen System stammt. Jedoch ist die Ak-tualitat dieser Daten stark implementie-rungsabhangig, wahrend bei den bisherigenAnsatzen ein Direktzugriff auf die exter-nen Daten moglich war.

Die DBMS-gestutzte Replikation wird in-nerhalb der vorhandenen Systemlandschafteingesetzt, um Daten im Portierungs- undAuskunftsserver auf Basis neuer bzw. ge-anderter CRM-Daten zu aktualisieren. DieIntegration des Sprach-Billing-Systemskonnte demgegenuber nicht auf Basis derbeteiligten DBMS erfolgen, da der Herstel-ler den Zugriff auf den privaten Daten-bestand des Sprach-Billing-Systems nuruber ein in der Interface DefinitionLanguage (IDL) der Common Object Re-quest Broker Architecture (CORBA)[OMG02] beschriebenes, objektorientier-tes API ermoglicht. Standardmechanismenauf Basis des relationalen DBMS desCRM-Systems sind hier aufgrund des Da-tenmodellbruchs nicht anwendbar.

Auf den ersten Blick bieten sich in diesemFall „Off-the-Shelf“-Integrationsplattfor-men fur die Durchfuhrung der Replikationan, da diese fur die Anbindung einer Viel-zahl von Systemen entwickelt wurden undzentral den erforderlichen Datenfluss ko-ordinieren konnen. Auf den zweiten Blickwird der Einsatz dieser Plattformen jedochdadurch erschwert, dass sie meist relationa-le DBMS als Datenquellen und -senken vo-raussetzen und zusatzliche Konnektivitatnur fur weit verbreitete Standardsoftwarewie z. B. SAP R/3, PeopleSoft oder Siebelanbieten. Fur die Integration von Spezial-systemen, z. B. dem mit CORBA-basiertenAPI ausgestatteten Sprach-Billing-System,sind sie daher nicht direkt ausgelegt, einKonnektor musste in diesem Fall neu ent-wickelt werden. Problematisch ist hierbeijedoch, dass die eingesetzten Spezialsyste-me durch ihre Hersteller weiter entwickeltwerden und somit bei einem Releasewech-sel sowohl Datenflusse als auch Konnekto-ren angepasst werden mussen.

In einem ersten Projekt wurde die Kopp-lung zwischen CRM- und Sprach-Billing-System unter Einsatz einer Enterprise-Ap-plication-Integration(EAI)-Plattform reali-siert. Dieses Gesamtsystem konnte jedochin Bezug auf Stabilitat und Performanz beider Behandlung der anfallenden Daten-mengen nicht den gewunschten Erfolgvorweisen, sodass letztendlich zugunsteneiner Eigenentwicklung der Datenreplika-tion entschieden wurde. Bei dieser Eigen-entwicklung stand u. a. die Moglichkeitzur Durchfuhrung eines vollstandigen Im-ports der benotigten CRM-Daten in dasSprach-Billing-System im Vordergrund,wodurch insbesondere Systemmigrationenund Fehlerzustande einfacher zu hand-haben sind.

Die Grundlage der Eigenentwicklung bil-det ein objektorientiertes Framework, dasu. a. Basisdienste fur den Zugriff auf rela-tionale DBMS, ein nachrichtenorientiertesVerarbeitungskonzept sowie mittels einesObject Request Broker (ORB) die Anbin-dung von CORBA-basierten Systemen er-moglicht. Alle Replikationsprozesse zwi-schen CRM- und Sprach-Billing-Systemsind aufbauend auf diesem Rahmenwerkimplementiert. Um im objektorientiertenSinne eine moglichst naturliche Einbin-dung der CRM-Datenbank zu gewahr-leisten, wurden die benotigten Ausschnitteder Datenbank in einem Objektmodell ge-kapselt. Eine �bersicht der Systemarchi-tektur ist in Bild 2 skizziert.


Sprach-Billing-SystemCRM-

Datenbank

SQL CORBAReplikations-prozesse

CRM-Kon-nektor

Billing-Kon-nektor

Status-management

Bild 2 Systemarchitektur der Replikation zwischen CRM- und Sprach-Billing-System


3 Anwendungsintegration

Neben der Integration von Schemata undDaten verschiedener Anwendungen ist je-doch auch die Integration der Anwendun-gen selbst wichtig. Ziel dabei ist einerseits,wie schon in Abschnitt 2 motiviert, die an-wendungsubergreifende Konsistenz derDaten. Andererseits wird die moglichstweitgehende Wiederverwendung und Nut-zung von vorhandener Funktionalitat ausden integrierten Systemen (funktionale In-tegration, siehe 3.2) sowie eine einheitlicheBenutzungsoberflache fur die Pflege derDaten angestrebt (Benutzungsoberflachen-integration, siehe 3.3). Als Basis fur dieSystemkopplung dient eine Integrations-plattform, welche die erforderlichen Diens-te bereitstellt und die Enterprise Editionder Java 2 Plattform (J2EE) in Verbindungmit Application-Server-Technologie nutzt(siehe 3.1). Auf den Einsatz einer kommer-ziellen Middleware wurde verzichtet, dader eingesetzte Application-Server bereitsalle benotigten Dienste bereitstellt.

3.1 Integrationsplattform

Stammdaten werden im Unternehmen zen-tral in der IKDB verwaltet. Genutzt wer-den diese jedoch auch in weiteren ange-bundenen Systemen, etwa im ERP-System,im CRM-System sowie in den beiden Bil-ling-Systemen. Die benotigten Daten wer-den in den beteiligten Systemen redundantgehalten, fuhrendes System und damit zu-standig fur die Verwaltung ist die IKDB.Die Integrationsplattform stellt Mechanis-men fur den Datenaustausch zwischen denSystemen bereit. Zur Propagierung von�nderungen und zur Konsistenzsicherungwird asynchrone Kommunikation verwen-det. Hierzu werden Standardmechanismender J2EE-Technologie, insbesondere Mes-sage Queues und Message Driven Beanseingesetzt. Die versandten Nachrichten lie-gen dabei im XML-Format vor. In derIKDB werden ferner fur die relevanten inden angebundenen Systemen verwaltetenDaten Stellvertreterobjekte gefuhrt, uberdie eine Navigation zu den verwalteten Da-ten ermoglicht wird. Hier wird das globaleDatenschema definiert, die Stellvertretersind eine Art Wrapper zur Kapselung derSchemata der Komponentensysteme. Inder IKDB erfolgt die Abbildung auf dasglobale Schema. Hierdurch wird insbeson-dere gewahrleistet, dass die Kopplung derbeteiligten Systeme lose ist und Schema-

anderungen der IKDB nicht unmittelbarzu Schemaanderungen in den angebunde-nen Systemen fuhren. Die alternativ denk-bare synchrone Kommunikation mit virtu-ellem Gesamtdatenbestand und disjunkterDatenhaltung (siehe 2.1) wurde verworfen,da hierzu zu viele bereits existierende zuintegrierende Systeme hatten geandert wer-den mussen. Eine zu enge Kopplung istnicht gewunscht, um die geforderte Auto-nomie der angebundenen Systeme nicht zugefahrden (siehe auch 2.2).

Eine Alternative zur Kopplung unabhangi-ger Anwendungen ist der Einsatz einer ge-eigneten Middleware, etwa einer EAI-Plattform [PeBe02]. Jedoch enthielten diezu Projektbeginn verfugbaren Plattformenkeine Konnektoren fur die mit der IKDBzu integrierenden Spezialsysteme, wie z. B.das Internet-Billing-System. Des Weiterensind fur diese Spezialsysteme auch auf langeSicht keine Konnektoren angekundigt. Da-her wurde entschieden, eine Individualent-wicklung auf Basis von J2EE durchzufuh-ren, da J2EE-konforme Application-Serverdie notige Integrationsfunktionalitat bereit-stellen. Dies gilt besonders, da das Internet-Billing-System und das CRM-System inJava implementiert sind bzw. werden.

3.2 Daten und Funktionen

Zur Realisierung der Verwaltung der Stell-vertreterobjekte sowie zur Nutzung vonFunktionalitat einer Anwendung aus eineranderen Anwendung heraus wird funktio-nale Integration eingesetzt. Hierzu werdenSchnittstellen in Gestalt von Session Enter-prise JavaBeans (EJBs) verwendet. Die zuintegrierenden Systeme werden hierzu aufoberster Ebene als Komponenten durchSession-EJBs gekapselt. Diese EJBs stellendie fur andere Komponenten nutzbareFunktionalitat als Methoden bereit, dieuber ihre Remote-Schnittstelle auch uberRechnergrenzen hinweg genutzt werdenkonnen. So stellt die IKDB z. B. Funktio-nalitat zur Erzeugung von Stammdatenund Recherche in diesen bereit, die von an-gebundenen Systemen genutzt werdenkann. Da die Funktionalitat typischerweisenur im jeweiligen Anwendungskontextverwendbar ist, sind die EJBs als Stateful-Session-EJBs modelliert.

Einen Sonderfall der funktionalen Integra-tion stellt die Recherche in Stammdatendar. Die IKDB bietet hierzu eine EJB-ba-sierte Schnittstelle an [Sun02c]. Kennzeich-

nend fur die Suche ist, dass Suchkriterienmoglichst flexibel zusammengestellt wer-den konnen und Ergebnismengen als Tref-ferlisten prasentiert werden. Leider ist dieSuche in operativen Systemen von geringerPerformanz, insbesondere wenn sie an Sys-teme mit großen Datenbestanden delegiertwird. Aus diesem Grund wird fur die Su-che ein allgemeiner Ansatz verfolgt, beidem die strukturierte Recherche in Daten-banktabellen durch eine Volltextsuche er-setzt wird. Wahrend zur Definition einerSuche noch eine EJB-basierte Schnittstelledie notige Flexibilitat bietet, reicht dies zurPrasentation der Trefferliste nicht aus. Dadie Trefferlisten jedoch bezuglich ihrerStruktur stets gleich aufgebaut sind, bot essich an, hierfur eine Komponente einzuset-zen, die zur Prasentation des Ergebnisseseine grafisch-interaktive Reprasentation inForm von Listen verwendet (siehe 3.3).Diese wird dann an verschiedenen Stellenin die Oberflachen der nutzenden Anwen-dungen eingeblendet.

3.3 Benutzungsoberflachen

Die funktionale Integration reicht somitnicht aus, da hierdurch zwar Funktionalitatwiederverwendet werden kann, nicht aberDialogelemente, die zur Parametrisierungbzw. Prasentation der Funktionalitat notigsind. Aus diesem Grund wird die Integra-tion der Anwendungen auch auf der Ebeneder Benutzungsoberflache durchgefuhrt.Hierzu sind mehrere Ansatze denkbar. Derklassische Weg fuhrt zur Integration vonGUI-Controls, wie sie aus den MicrosoftFoundation Classes, dem Java AWT oderSwing [Sun02a] bekannt sind. Insbesonde-re die letzten beiden Techniken lassen sichauch im Java-Applet-Umfeld nutzen. Dadie Nutzbarkeit der Anwendung uber In-ternet angestrebt wird, ist der Einsatz vonJava-Applikationen oder Java-Applets je-doch weniger geeignet. Java-Applikationenerfordern einen zusatzlichen Aufwand zurAdministration der Arbeitsplatzrechner.Java-Applets konnen, insbesondere bei derhier benotigten Funktionalitat, zu großemVolumen anwachsen und erfordern Netz-werke hoher Bandbreite. Sie stellen dahereher eine Variante fur die ausschließlicheIntranet-Nutzung dar. Aus diesen Grun-den fiel die Entscheidung auf serverseitigesJava und in HTML realisierte Benutzungs-oberflachen [Sun02b].

Neben der Suchkomponente werden Kom-ponenten zur Erfassung, Manipulation und



Prasentation von Stammdaten bereit-gestellt. Diese werden einerseits in derIKDB selbst zur Verwaltung der entspre-chenden Daten eingebettet, andererseitsstehen sie auch den angebundenen Anwen-dungen zur Verfugung. Das CRM-Systemverfugt uber ein Erfassungsformular, in derKontaktdaten uber derartige Komponen-ten erfasst werden konnen. Hierdurchmuss zur Erfassung dieser Daten nichtzwischen den Anwendungen gewechseltwerden. Stattdessen wird hierzu aus denangebundenen Systemen uber diese Kom-ponenten auf die IKDB zugegriffen. JedeManipulation der Stammdaten geschiehtsomit, wie in 3.1 gefordert, primar in derIKDB.

Doch auch auf niedriger Ebene wird durchVerwendung von Komponenten einerseitsein hoher Grad an Wiederverwendung undandererseits ein einheitliches „Look &Feel“ erreicht. Dialogelemente wie Ein-gabefelder, Schaltflachen oder Karteikartensind hierzu als GUI-Controls realisiertund stehen in einer Tag-Library zur Ver-fugung. Diese Tag-Library wird von denzu integrierenden Anwendungen zur Er-stellung einer grafischen Benutzungsober-flache basierend auf JavaServer Pages(JSP)-Technologie genutzt. Hierdurch erhaltendie anwendungseigenen Formulare und dieals Komponenten eingebundenen IKDB-Teile ein einheitliches „Look & Feel“. Furden Anwender ist nicht mehr erkennbar,wann er von einer Anwendung zur nach-sten wechselt.

Zusammenfassend lasst sich sagen, dass diefunktionale Integration basierend auf EJBsund die Benutzungsoberflachenintegrationbasierend auf JSPs mithilfe von Inline-Frames eine enge Integration vonWeb-An-wendungen ermoglicht, wenn diese imHinblick auf Integrierbarkeit entworfenwurden, d. h. insbesondere Bereitstellungvon Geschaftslogik-Schnittstellen als Ses-sion-EJBs und Oberflachenkomponentenals einbettbare JSP-Seiten oder in Form ei-ner Tag-Library. Daher sind die Benut-zungsoberflachen von CRM- und Internet-Billing-System sowie der IKDB selbstunter Beibehaltung vorhandener Funktio-nalitat, z. B. der Datenbank, und vorhan-dener Schnittstellen zu anderen Systemenauf Basis von J2EE reimplementiert wor-den.

4 Prozessintegration

Die Daten- und Anwendungsintegrationsind Basistechnologien, die auch im Rah-men der Prozessintegration eingesetzt wer-den konnen. Jedoch bedarf es zunachst ei-ner ubergeordneten Steuerungsebene, umanwendungsubergreifende Geschaftspro-zesse zu realisieren.

Die EWE TEL plante zunachst die Einfuh-rung eines elektronischen Archivs fur dieeffizientere Organisation ihrer Dokumen-tenverwaltung in der Auftragsbearbeitung.Die dort vorzufindenden Ablaufe sind au-

ßerst dokumentenintensiv, was sowohl dieKommunikation mit anderen Unterneh-mensbereichen als auch mit Externen be-trifft. Bei Letzteren ist die Verfolgung derDokumente und die Nachvollziehbarkeitder Kommunikation besonders wichtig.Bereits wahrend der Anforderungsdefini-tion stellte sich heraus, dass der Informa-tionszugriff auf Auftrage sowie deren Zu-stande wahrend der Bearbeitung amhochsten ist und sich somit die erwartetenEffizienz- und Qualitatssteigerungen erstmit der Einfuhrung einer integrierten Do-kumenten- und Workflow-Management-Losung umsetzen lassen. Das sprach nebendem fruhen Scannen fur eine elektronischeVorgangsbearbeitung [Mors97].

Im CRM-System waren ansatzweiseWorkflow-Funktionalitaten in Form vonEvent-Condition-Action-Regeln (ECA-Regeln) implementiert. Die ECA-Regelnboten jedoch nicht die gewunschte Trans-parenz uber die elektronischen Geschafts-prozesse, wie sie vergleichsweise mit gra-fisch modellierten Workflow-Definitionenerzielt werden kann. Weitere Argumentegegen die Nutzung der ECA-Regeln warendie schlechte Wartbarkeit und deren Be-schrankung auf das CRM-System. Daherist die Entwicklung einer Workflow-Man-agement-Anwendung (WMA) favorisiertworden, mit der Kontrollflusse aus denAnwendungen in eine anwendungsuberg-reifende Steuerungsebene verlagert werden.Die Workflow-Schemadaten, Workflow-Instanzdaten sowie Akteure und Aktionenwerden zentral in einem Workflow-Man-agement-System (WMS) verwaltet [JaBo97;WeGo98].

Im Mittelpunkt der Prozessintegration ste-hen die betriebswirtschaftlichen und aufden Kunden ausgerichteten Geschaftspro-zesse. Dazu gehoren das gesamte Neukun-dengeschaft sowie �nderungs-, Storungs-,Beschwerde- und Kundigungsprozesse furBestandskunden. Ziel der WMA ist dievollstandige elektronische Bearbeitung al-ler kundenorientierten Prozesse innerhalbdes Unternehmens. Die Architektur derAnwendung ist in Bild 3 skizziert.

4.1 IntegriertesDokumentenmanagement

Im Gegensatz zu den bisher vorgestelltenIntegrationsansatzen sind in dem hier vor-gestellten Anwendungsszenario zu einem


Scan-

Anwendung

Posteingang-klassifizierung u.Datenextraktion

Archiv-

system

CRM-

System

Bonitäts-

prüfung

Workflow-Engine

RDBMS

Webserver

Web-

Recherche

Workflow-

Client

(Windows)

CRM-

ClientMS Word

Druck-

archivierung

Client

Applikation

Persistenz

Bild 3 Architektur der Workflow-Management-Anwendung


nicht unerheblichen Teil unstrukturierteDaten in Form gescannter Images zu ver-arbeiten [KaMe97]. Dies ist auf die Me-dienbruche an den Unternehmensgrenzenzuruckzufuhren. Um diese zu eliminieren,wird die Integration der papiergestutztenmit der elektronischen Vorgangsbearbei-tung angestrebt. Fur die Generierung derGeschaftsvorfalle ist es erforderlich, dasBeleggut zu klassifizieren (z. B. Auftrag,Kundigung) und ggf. auch Informationenaus den einzelnen Belegen zu extrahieren,z. B. welche Produkte mit dem Auftrag be-stellt wurden. Fur diese Aufgabenstellungwurde ein Werkzeug zur Dokumenten-klassifizierung, das auf neuronalen Netzenund dem Prinzip „Learning by Example“basiert, mit dem WMS integriert. Zu dendefinierten Dokumentenklassen sind Defi-nitionen hinterlegt, die spezifizieren,welche Dokumente welche Prozesse aus-losen.

Um das Ziel der vollstandigen elektro-nischen Akte zu realisieren, muss manneben dem eingehenden auch den aus-gehenden Schriftverkehr betrachten. Alsproblematisch stellte sich die Integrationder Desktop-Anwendung Microsoft Wordmit dem Workflow-Server unter Wahrungder Revisionssicherheit heraus. Sinnvollererscheint der Einsatz eines Output-Man-agement-Systems (OMS) fur die server-basierte Dokumentengenerierung und-verteilung. Das bereits im Billing einge-setzte OMS soll daher sukzessiv proprietareDruckfunktionalitat der Spezialsystemeablosen.

4.2 Integration zwischenWMS und CRM-System

Die Grenzen zwischen Prozess- und An-wendungsintegration sind fließend, wasinsbesondere bei der Integration zwischenWMS und dem CRM-System deutlichwird. Die Integration zwischen beiden Sys-temen wurde daher auf den folgenden Ebe-nen realisiert (vgl. auch Bild 4).

& Datenintegration: Die Geschaftspro-zesse fuhren zur Laufzeit Prufungen aufdem Datenbestand des CRM-Systemsaus. Diese Prufungen sind fur das WMSin Form von Stored Procedures inner-halb der CRM-Datenbank gekapselt.Der Aufruf erfolgt uber serverbasierteJava-Programme des WMS. Ebenfallsauf Datenbankebene, jedoch in die ent-

gegengesetzte Richtung, werden Auf-tragsdaten aus dem CRM-System in dasWMS als Indexdaten repliziert.

& Anwendungsintegration (CRM-Client! Workflow-Server): Grundsatzlichwerden wie in 4.1 vorgestellt, die Ge-schaftsvorfalle uber das Werkzeug zurPosteingangsklassifizierung und Daten-extraktion generiert. In zunachst doku-mentenlosen Geschaftsvorfallen (z. B.telefonische Storungsmeldung) hat essich als effizienter herausgestellt, wah-rend des Telefonats die Storung zunachstim CRM-System zu erfassen. �ber dasvom WMS zur Verfugung gestellte Ser-ver-API werden die Geschaftsvorfalle imWMS angelegt und mit der Storungsmel-dung imCRM-System verknupft.

& Anwendungsintegration (Workflow-Server ! CRM-Server): Im ausge-wahlten WMS konnen zu den model-lierten Aktivitaten „beliebige“Applikationen hinterlegt werden. So-bald ein Geschaftsvorfall eine solche au-tomatische Aktivitat erreicht, wird diedamit verknupfte Applikation gestartet.Anhand der Ruckgabewerte kann dasWMS den weiteren Kontrollfluss be-stimmen.So erfolgt die Bonitatsprufung großten-teils automatisch. Lediglich Grenzfalle,die nicht maschinell entschieden werdenkonnen, werden uber das WMS einerhalbautomatischen Bearbeitung zu ge-fuhrt.

& Benutzungsoberflachenintegration(Workflow-Client $ CRM-Client):Aufgrund des Kontextwissens, in wel-chem Prozess und in welcher Aktivitatsich ein Geschaftsvorfall befindet, lassensich zur Definitionszeit Ruckschlusseziehen, welche Masken aus dem CRM-System erforderlich sind, um die Aktivi-tat zu bearbeiten. Diese Konfigurationenwerden fur jedes Tupel (Prozess, Aktivi-tat) in der Datenbank persistent gespei-chert. Sobald der Anwender einenWech-sel vomWMSzumCRM-System auslost,werden dem Anwender die entsprechen-den Masken vorgeschlagen. Nach erfolg-ter Auswahl wird die Maske parametri-siert mit der Kundennummer aufgerufen.Aus derCRM-AnwendungkannderAn-wender seinerseits in die vollstandigeelektronischeKundenakte springen.

Insbesondere die Kopplung technologischinnovativer WMS mit Altanwendungenkann sich als schwierig herausstellen. Inunserem konkreten Fall konnte das CRM-System nicht gezielt fur eine Transaktionaufgerufen werden. Das hat zur Folge, dassnach dem Aufruf des CRM-Systems dasWMS keine Kontrolle mehr uber die Be-nutzeraktionen hat, was zu Konsistenzver-letzungen in der WMA fuhren kann.Durch die Einschrankung der Navigations-alternativen wurde das im CRM-Systemvorhandene Konzept der modalen Dialogeum die Belange des WMS erweitert.


Aufruf von URLs des

CRM-Clients

Datenreplikation

Online-Prüfungen

Workflow-Client

Workflow-Server

CRM-Client

Geschäftsvorfall-Generierung

CRM-Datenbank

Workflow-Datenbank

Bild 4 Integration von WMS und CRM-System


5 Bewertung

Die Integration kooperierender Spezial-systeme in der Systemlandschaft der EWETEL ist gepragt durch die drei EbenenDaten-, Prozess- und Anwendungsinte-gration. Diese Ebenenunterteilung ist dieUrsache fur die unterschiedlichen Anfor-derungen an die Integrationsmethoden unddamit auch fur die in diesem Artikel be-schriebenen Ansatze:

& Datenintegration uber Middleware,& Anwendungsintegration uber Applica-

tion-Server und& Prozessintegration uber ein Workflow-

Management-System.

Die drei Integrationsmethoden haben ihrePraxistauglichkeit bei der EWE TEL be-wiesen, erfordern jedoch sowohl bei derEinfuhrung als auch im Betrieb einen hohenAufwand. Release-Wechsel und kontinuier-liche Weiterentwicklungen der integriertenSoftwaresysteme erfordern regelmaßigeAnpassungen der Integrationsverfahren.

Die als Individualentwicklung realisierteMiddleware zur Kopplung von CRM- undBilling-System hat die fur ein Telekom-munikationsunternehmen außerst sensibleSchnittstelle zwischen Kunden-/Vertrags-datenverwaltung und Abrechnungssystemstabilisiert und sich als deutlich leistungs-fahiger als ein zuvor erprobtes kommer-zielles EAI-Produkt herausgestellt. DieAnwendungsintegration der Kundendaten-verwaltung durch den Einsatz von Appli-cation-Server-Technologie ermoglicht trotzkooperierender Spezialsysteme eine zentra-le Verwaltung der Kundendaten und ge-wahrleistet die zwingend erforderliche an-wendungsubergreifende Datenkonsistenz.Die Prozessintegration mittels eines Work-flow-Management-Systems bietet die ge-forderte Flexibilitat bei der Anpassung derGeschaftsprozesse und hat sich als geeig-netes Instrument fur die unternehmenswei-te Prozesssteuerung erwiesen. Derzeit wirdan der Ausweitung der Workflow-Unter-stutzung auf externe Vertriebspartner unddamit auf unternehmensubergreifende Ge-schaftsprozesse gearbeitet.

Trotz einer positiven Bewertung des Ein-satzes der vorgestellten Integrationsmetho-den lasst die Vielzahl der Datenschnittstel-len in der Systemlandschaft der EWE TELdie Frage nach einer Ausweitung desMiddleware-Einsatzes fur die Dateninte-gration aufkommen. Die Effizienz des Ein-

satzes hangt jedoch entscheidend von derVerfugbarkeit von Konnektoren fur dieAnbindung der zu integrierenden Soft-waresysteme ab. Kommerzielle Produktebieten Standardkonnektoren jedoch haufignur fur weit verbreitete Softwaresysteme,z. B. in der hier vorgestellten Software-landschaft nur fur das ERP-System. FurSpezialsysteme wie z. B. die bei der EWETEL eingesetzten Billing- und Auskunfts-systeme sind solche Konnektoren jedochnicht verfugbar. Erschwerend kommt hin-zu, dass angebotene generische Integra-tionstechnologien, wie z. B. CORBA,J2EE und XML, selbst von etablierterStandardsoftware haufig nicht unterstutztwerden. Ohne diese Konnektoren stellenMiddleware- bzw. EAI-Produkte nicht vielmehr als Integrations-Frameworks dar. DieReduzierung des Integrationsaufwandesfallt jedoch deutlich geringer aus, wenn diefehlenden Konnektoren als Individualent-wicklung realisiert werden mussen. UnterBerucksichtigung der hohen Lizenzgebuh-ren fur leistungsfahige Produkte ergebensich berechtigte Fragen an einem weitrei-chenden Einsatz fur die Datenintegrationin der Systemlandschaft der EWE TEL.

Der Markt fur Middleware- bzw. EAI-Produkte ist zudem sehr stark in Bewe-gung. So werden sie zunehmend nichtmehr als eigenstandige Produkte, sondernin Verbindung mit Application-Servern,Transaction-Engines sowie Funktionen furdie Prozessmodellierung und -steuerungals EAI-Plattformen vermarktet. Gegen-uber fruheren Integrationsversuchen mitFokussierung auf Punkt-zu-Punkt-Verbin-dungen erheben diese Plattformen [vgl.Comp02] den Anspruch, eine zentralisierteIntegration auf Daten-, Anwendungs- undProzessebene zu bieten. Sie stellen also dieVereinigung vonMiddleware-Technologienund ihre Verknupfung mit Werkzeugen furdie Datenmodellierung, Anwendungsent-wicklung und Prozessimplementierung dar.Die Komplexitat der darunter liegendenMiddleware, Konnektoren und Daten-transformationen sollen von EAI-Plattfor-men so weit wie moglich gekapselt werden.Bei der EWE TEL kommt im Rahmen derAnwendungsintegration (Entwicklung derIKDB) ein Application-Server zum Ein-satz, der derzeit vom Hersteller zu einerEAI-Plattform weiterentwickelt wird. Diebei der EWE TEL eingesetzten Integra-tionsmethoden bieten also – bei hinrei-chender Marktetablierung von EAI-Platt-formen – die Moglichkeit einer teilweisenVereinheitlichung der Integrationsmetho-

den. Im Mittelpunkt wird dabei die Mog-lichkeit der engeren Verknupfung von Da-ten- und Anwendungsintegration stehen.Ob diese Plattformen langfristig auch eineAlternative zu Workflow-Management-Systemen mit ihrer engen Verknupfung zuroptischen Archivierung und zum Doku-mentenmanagement darstellen werden,scheint mehr als fragwurdig. Die von denPlattformen angebotenen Werkzeuge furdie Prozessmodellierung und -steuerungsind derzeit primar auf die Umsetzung derBusinesslogik fur die Datenintegration, alsoauf Prozesse fur die Verteilung der Datenzwischen den kooperierenden Systemenausgerichtet. Das Workflow-Management-und Archivsystem der EWE TEL ist dage-gen starker auf Prozess- und Dokumenten-Management ausgerichtet.

6 Zusammenfassung

Zusammenfassend kann festgestellt wer-den, dass die heute bei der EWE TEL ein-gesetzten Integrationsmethoden noch kei-ne homogene Gesamtlosung darstellen, derSoftwaremarkt fur die Anforderungen andie Systemintegration bei der EWE TELjedoch derzeit auch noch keine umfassendeIntegrationsplattform bietet. Die Weiter-entwicklung des derzeit eingesetzten Ap-plication-Servers zu einer EAI-Plattformkonnte mittelfristig eine Vereinheitlichungder Daten- und Anwendungsintegrationermoglichen, im Rahmen derer dann auchdie klassischen Schnittstellentechnologienabgelost werden konnten.

Literatur

[Conr97] Conrad, S.: Foderierte Datenbanksyste-me: Konzepte der Datenintegration. Springer,Berlin 1997.

[Comp02] EAI stellt hohe Anforderungen an dieIT. In: Computerwoche (2002) 1.

[HeMc85] Heimbigner, D.; McLeod, D.: A Feder-ated Architecture for Information Management.In: ACM Transactions on Office InformationSystems 3 (1985) 3, S. 253–278.

[JaBo97] Jablonski, S.; Bohm, M.; Schulze, W.:Workflow-Management: Entwicklung von An-wendungen und Systemen. dpunkt.verlag, Hei-delberg 1997.

[KaMe97] Kampffmeyer, U.; Merkel, B.: Grund-lagen des Dokumentenmanagements: Einsatz-gebiete, Technologien, Trends. Gabler, Wiesba-den 1997.

[Mors97] Morschheuser, S.: Integriertes Dokumen-ten- und Workflow-Management. DeutscherUniversitats-Verlag, Wiesbaden 1997.



[OMG02] Object Management Group: CORBA:Common Object Request Broker Architecture.http://www.corba.org, Abruf am 2002-03-21.

[PeBe02] Perks, C.; Beveridge, T.: Messaging is theMedium. http://www.intelligenteai.com/feature/2000929.shtml, Abruf am 2002-03-21.

[ShLa90] Sheth, A. P.; Larson, J. A.: Federated Data-base Systems for Managing Distributed, Hetero-genous, and Autonomous Databases. In: ACMComputing Surveys 22 (1990) 3, S. 183–236.

[Sun02a] Sun Microsystems, Inc: The JavaTM Plat-form: Five Years in Review. http://java.sun.com/features/2000/06/time-line.html,Abruf am 2002-03-21.

[Sun02b] Sun Microsystems, Inc: JavaServer Pa-gesTM: Dynamically Generated Web Content.http://java.sun.com/products/jsp,Abruf am 2002-03-21.

[Sun02c] Sun Microsystems, Inc: Enterprise Java-BeansTM: The Industry-Backend Server-SideComponent Architecture. http://java.sun.com/products/ejb, Abruf am 2002-03-21.

[WeGo98] Weske, M.; Goesmann, T.; Holten, R.;Striemer, R.: A Reference Model for WorkflowApplication Development Processes. Fachbe-richt Angewandte Mathematik und Informatik11/98-I, Universitat Munster 1998.


Abstract

Integration of data, applications and processes with regard to the telecommunicationcompany EWE TEL

The necessary specialisation in information processing in the telecommunication sector ledto a wide range of software systems in the relevant software market. This can be traced backby the fact that there is a lack of capable and integrated solutions. If a telecommunicationcompany comes to the decision to use specialised software systems, it has to face the sophis-ticated challenge of systems integration. This can be done at least at the levels of data, appli-cations and processes. Illustrated by examples from the heterogeneous system environmentat the telecommunication company EWE TEL, concepts for system integration and gainedexperiences are presented in this article. The following aspects are discussed in detail: inte-gration of data by means of middleware, integration of applications using application ser-ver technology, and integration of processes by employing workflow management systems.

Keywords: telecommunication industry, system integration, data integration, application in-tegration, process integration, middleware solutions, enterprise application integration


Date post:	26-Aug-2016
Category:	Documents
Upload:	arne
View:	215 times
Download:	2 times

Integration von Daten, Anwendungen und Prozessen am Beispiel des Telekommunikationsunternehmens EWE...

Documents