Lehrstuhl fr Wirtschaftsinformatik, insbesondere Informationsmanagement

Diplomarbeit
zum Thema

Entwicklung einer IT Architektur fr das Directbanking

im Fach: Wirtschaftsinformatik

Themensteller: Prof. Dr. Jochen Picht Betreuer: Frank Gulitz und Hiltrud Wolff, beide BMW Bank GmbH

Ausgabetermin: 9. Juni 2000 Abgabetermin: 8. Dezember 2000

vorgelegt von: Denny Reeh Berlepschstrae 12 81373 Mnchen

Entwicklung einer IT Architektur fr das Directbanking

Stichworte: Architekturplanung, Directbanking, Onlinebanking, Integration, Middleware, Schichtmodell, Stufenmodell, prozessgesteuerte Kommunikation Zusammenfassung: Aus der Notwendigkeit heraus, eine bestehende Finanzierungsbank zu einer Direktbank auszubauen, wie es die BMW Bank vollfhrt, ist es erforderlich, moderne Techniken im Bereich der Client/Server Technologie zu evaluieren. Gerade im Hinblick auf die Integration der Backendsysteme einer Bank und der damit verbundenen Middlewarethematik werden viele Probleme sichtbar. Ein allgemeiner Ansatz bei der Entwicklung einer IT Architektur soll systematisches Vorgehen bei der Problemanalyse ermglichen. Eine umfassende Lsung kann schlielich nur die prozessgesteuerten Kommunikation bieten.

Development of an it-architecture for directbanking

Keywords:

Planning of architecture, Directbanking, Onlinebanking, Integration, Middleware, Model of layers and tiers, process-controlled communication

Abstract: In the demand for the building of a direct bank out of a finance bank, like the BMW Bank, it required to analyze modern client/server technologies. Ess pecially the integration of the backend systems of a bank and the connected thematic of the middleware many problems are being visible. A general approach for the development of an it-architecture should make a systematic procedure for the analyze of the problem possible. A sweeping solution can be only the process-controlled communication.

- II -

Inhaltsverzeichnis
Abbildungsverzeichnis .................................................................................. IV Abkrzungsverzeichnis................................................................................... V Tabellenverzeichnis ......................................................................................VII 1 Problemstellung und Motivation............................................................. 8 1.1 1.2 1.3 1.4 2 Einfhrung .................................................................................... 8 Ist Situation der BMW Bank..................................................... 10 Umstrukturierung in der Bankenbranche ..................................... 13 Die Ziele der Arbeit..................................................................... 14

Produktvergleich deutscher Autobanken ............................................... 15 2.1 2.2 Bestandsaufnahme des Angebotes ............................................... 17 Auswertung des Produktvergleichs und der jetzigen Position der BMW Bank ................................................................................. 20

Moderne Client/Server - Architekturen................................................. 23 3.1 3.2 3.3 Client/Server: Technik der neunziger Jahre ................................. 23 Ziele der Einfhrung von Client/Server-Architekturen................. 26 Client/Server - Systeme der zweiten Generation .......................... 27 3.3.1 Internet als Integrationsplattform ................................... 28 3.3.1.1 3.3.1.2 Integration ber die CGI Schnittstelle ....... 29 Integration von Applikationen in HTML Dokumente .................................................. 30 3.3.1.3 3.3.2 Integration WWW mit Middleware ............. 32

Middleware ................................................................... 33 3.3.2.1 3.3.2.2 3.3.2.3 Arten von Middleware ................................. 34 Vorteile von Middleware ............................. 37 Integration von SAP R/3 in das WWW........ 38

3.3.3

Object Request Broker - Verteilte Objektorientierung.... 40 3.3.3.1 3.3.3.2 CORBA Architektur ................................. 40 Microsoft COM/DCOM .............................. 43

3.3.4

Enterprise Application Integration ................................. 45

- III -

Allgemeiner Ansatz eines Konzeptes einer IT-Architektur fr das Directbanking................................................................................. 49 4.1 Erweiterung des Schichtenmodells .............................................. 49 4.1.1 4.1.2 4.1.3 4.1.4 4.2 4.3 Die Prsentationsschicht ................................................ 50 Die Steuerungsschicht.................................................... 50 Die Schicht der Business Objects................................... 54 Die Datenverwaltungsschicht......................................... 54

Erweiterung des Stufenmodells ................................................... 55 Teile einer IT-Architektur fr das Directbanking ......................... 56 4.3.1 4.3.2 4.3.3 Frontends....................................................................... 57 Middleware ................................................................... 58 Backendsysteme ............................................................ 60

Ist-Situation der Architektur der BMW Bank GmbH ............................ 62 5.1 5.2 5.3 Onlinebanking Architektur Ist-Situation ................................... 62 Standardisierungsprozess bei dem Onlinebanking System ........ 65 ffnen der Extranet Lsung fr das Internet ............................. 66

Vision der prozessgesteuerten Kommunikation .................................... 68

Glossar........................................................................................................... 70 Quellenverzeichnis ........................................................................................ 76

- IV -

Abbildungsverzeichnis
Abbildung 1: Geschftsabwicklungssystem der BMW Bank.......................... 11 Abbildung 2: Kernabwicklungssystem der BMW Bank ................................. 12 Abbildung 3: schwankender produktbezogener Kundenkontakt ..................... 15 Abbildung 4: Marktwachstums-Marktreife-Portfolio des europischen Automobilmarktes ................................................................................. 17 Abbildung 5: Zusammenhang zwischen Stufen und Schichten....................... 24 Abbildung 6: Mglichkeiten der Verteilung der Applikation.......................... 25 Abbildung 7: Integration des WWW-Server mit Applikationen ber CGI ...... 29 Abbildung 8: Funktionsprinzip Java Applets im WWW................................. 31 Abbildung 9: Integration WWW mit Middleware .......................................... 32 Abbildung 10: Integration von SAP R/3 in das WWW................................... 39 Abbildung 11: CORBA Architektur nach OMG............................................. 41 Abbildung 12: Methodenaufruf im COM/DCOM Modell ........................... 44 Abbildung 13: erweitertes Schichtenmodell fr Directbanking....................... 50 Abbildung 14: erweitertes Stufenmodell fr Directbanking............................ 55 Abbildung 15: allgemeine Electronic Commerce/Directbanking Architektur .............................................................................................................. 56 Abbildung 16: Anbindung der Geschftsabwicklungssysteme an das Internet 62 Abbildung 17: Brokat Twister Software-Bus ................................................. 63

-V-

Abkrzungsverzeichnis
AG AMS API BAPI BO BOMSIG CF CGI COM CORBA CRM CSC CUI DB DBMS DCE DCOM DLL DTA DV EAI EJB ERP GUI HKK HTML HTTP IAC IDV IIOP ISAPI IT Aktiengesellschaft Antragsmanagementsystem Application Programming Interface Business Application Programming Interface Business Object Business Object Management Special Interest Group Creditfolio Common Gateway Interface Common Object Model Common Object Request Broker Architecture Customer Relationship Management Customer Service Center Character User Interface Datenbank Datenbank Management System Distributed Computing Environment Distributed Common Object Model Dynamic Link Library Datentrgeraustausch Datenverarbeitung Enterprise Application Integration Enterprise Java Bean Enterprise Ressource Planning Graphical User Interface Hndler-Kontokorrent-Konto Hypertext Markup Language Hypertext Transport Protocol Internet Application Component Individuelle Datenverarbeitung Inter ORB Protocol Internet Server Application Programmers Interface Informationstechnologie

- VI -

JDBC JVM LAN LZB MQ NSAPI OBS ODBC OLAP OLE OLTP OMA OMG ORB OS OSF PC PDA PIN RDBMS RMI RPC OLE SMS SQL TAN TCP/IP TCS TP WAP WWW XML ZFM

Java Database Connectivity Java Virtual Machine Local Area Network Landeszentralbank Message Queueing Netscape Server Application Programmers Interface Online Banking System Open Database Connectivity Online Analytical Processing Object Linking and Embedding Online Transaction Processing Object Management Architecture Object Management Group Object Request Broker Operation System Open Systems Foundation Personal Computer Personal Digital Assistant Personal Identification Number Relational Database Management System Remote Method Invocation Remote Procedure Call Object Linking and Embedding Short Message Service Structured Query Language Transaction Number Transmission Control Protocol / Internet Protocol Transmission Convergence Sublayer Transaction Processing Wireless Application Protocol World Wide Web Extensible Markup Language Zentrales Forderungsmanagement

- VII -

Tabellenverzeichnis
Tabelle 1: Vergleich der Bankprodukte deutscher Autobanken ...................... 19 Tabelle 2: Vergleich des Onlineangebots deutscher Autobanken.................... 20

-8-

1 Problemstellung und Motivation

...Wir verstndigen uns mit Handzeichen, eine Art Pantomime, die beide Indianer allmhlich verstehen. Aber die Verstndigung geht sehr langsam voran, und die meisten unserer gemeinsamen Themen sind eher aus Missverstndnissen entstanden als aus Erfolgen in der Kommunikation... Ich spielte mit dem Gedanken, nach dem Mdchen zu fragen, das ich in der Prrie gefunden habe... Angesichts unserer Verstndigungsschwierigkeiten war das Thema jedoch viel zu kompliziert, und so unterhielten wir uns so gut es ging ber das Essen... Aus Michael Blake: Der mit dem Wolf tanzt, S. 110-112.

1.1 Einfhrung
Heutige und zuknftige Anforderungen an unternehmensweite Rechnersysteme, wie Client/Server Fhigkeit, Untersttzung von Geschftsprozessen, Untersttzung von Workflow Systemen, hohe Flexibilitt bei Produktgestaltung, intuitive Benutzerfhrung oder Einsatzfhigkeit im Internet werden durch gewachsene Altanwendungen nicht oder nur mit unverhltnismig hohem Aufwand erfllt. Whrend sich beispielsweise die Software des Logistikbereiches den neuen Anforderungen angepasst hat, sind in den Banken gewachsene Lsungen weiterhin in Einsatz. Die Bankanwendungen sind in Zeiten entwickelt wurden, in denen hohe Arbeitsteiligkeit und Spartenorganisation noch Gang und Gbe waren und das Papier das Hauptarbeits- und Informationsmedium darstellte. Viele der heutigen technologischen Entwicklungen gab es nicht bzw. waren noch nicht soweit entwickelt, dass sie produktiv eingesetzt werden konnten. Die funktionalen Anforderungen an die Systemarchitektur einer Bank haben sich grundlegend gendert. Der gesamte Sektor steht erst am Anfang eines Wandels.

-9-

In Bezug auf die zentralen Anwendungssysteme der Banken werden einige Probleme immer sichtbarer und kritischer, da sie in zunehmenden Mae die Handlungsfhigkeit im IT Sektor einschrnken und enorme Kosten entstehen lassen. Hauptprobleme sind vor allem:1 ? ? Die heutigen Buchungssysteme sind fast ausschlielich mainframebasierte, monolithische Anwendungen. ? ? PC-Programme werden stand-alone eingesetzt. ? ? Vernetzte Kommunikation ist eher noch die Ausnahme. Datenaustausch zwischen den Systemen wird hufig durch Transaktionsdateien asynchron vollzogen. ? ? Der Aufwand fr funktionale und technische Erweiterungen dieser Systeme ist unverhltnismig hoch. ? ? Die Anwendungslandschaft der Banken besteht aus einer Vielzahl unterschiedlicher Systeme mit eigenstndiger, redundanter Datenhaltung. So werden bei der BMW Bank beispielsweise Kundendaten in der Datenbank des Kernsystems (Bankfolio), im Data Warehouse, im Business Partner Interface (ZKneu) und in der Datenbank des Mahnwesens (Customer Service Center) abgelegt. ? ? Die Umstellung der vorhandenen Systeme auf moderne Technologien ist aufgrund ihrer Struktur nicht nur mit extrem hohen Kosten verbunden, sondern teilweise gar nicht mglich, da u.a. ein Service rund um die Uhr angestrebt wird. ? ? Der Einsatz neuer Entwicklungstechnologien wird durch die vorhandenen Softwarearchitekturen extrem erschwert.

Vgl. Teller (1997), S. 4 ff.

- 10 -

Der Handlungsspielraum der Banken wird zudem auch durch hohe Kosten eingeschrnkt, die aus den gegebenen Grnden mit dem Umstieg auf andere Systeme verbunden sind. Zwar gibt es am Markt eine groe Anzahl interessanter Systeme, jedoch ergibt sich bezogen auf die funktionalen und technischen Merkmale ein sehr heterogenes Bild. Der Einsatz modernster IT Technologie ist nach bereinstimmender Auffassung vieler Experten einer der entscheidendsten Erfolgsfaktoren im Kreditgewerbe. In der Praxis ist die Akzeptanz neuer Technologien hufig nicht gegeben, da Altsysteme zum Investitionsschutz nicht abgelst werden knnen, oder sie fr die Ansprche der Bank mit hohen Kosten spezialisiert wurden, dass keine anderes System in Frage kommen kann. So wurden Altsysteme in der Vergangenheit aufwendig ausgebaut, bis ein schwer zu administrierendes System entstanden war. Diese Entwicklung hlt bis heute an, mit dem Effekt, dass es eine Vielzahl unterschiedliche Standards und Protokolle gibt, die in Standardanwendungen eingesetzt werden. Im Laufe der Zeit ist aus einer Standardsoftware durch viele Vernderungen Individualsoftware geworden. Eine Kommunikation zwischen diesen Systemen ist somit hochkomplex und fehleranfllig.

1.2 Ist Situation der BMW Bank

Die Systemlandschaft der BMW Bank ist im Laufe der Jahre gewachsen und besteht aus mehreren Anwendungssystemen und Datenbanken. Die Architektur lsst sich in die Bereiche Frontend, Middleware und Backend gliedern. Der Kern des System bildet das Backend. Hier luft die gesamte Administration direkt auf. Die Kommunikationswege sind unstrukturiert und die Kommunikation wird zum Teil ber asynchronen Dateiaustausch betrieben. Zudem werden Daten redundant in mehreren Datenbanken gehalten (siehe oben), was zu inkonsistenten Datenbestand fhren kann. Die Abbildung 1 macht die Situation deutlich. Aus der vernetzten und komplexen Struktur kann man ableiten, dass bei der Planung des Systems heutige Anforderungen nicht bercksichtigt wurden.

- 11 -

Abbildung 1: Geschftsabwicklungssystem der BMW Bank2

Es existieren verschiedene Mglichkeiten, auf dieses System zuzugreifen. Zum einen kann in der Bank ber ein Client der Teilsysteme zugreifen werden. Diese Mglichkeit steht dem Callcenter und den Administratoren in der BMW Bank zur Verfgung. Die zweite Mglichkeit ist ein Onlinezugriff im Extranet. Dazu wird ein Hndler der BMW AG manuell zum Zugriff freigeschalten. Der Zugriff erfolgt ber die Middleware Brokat Twister. Das Kernabwicklungssystem, als wichtigster Teil der Geschftsabwicklung, besteht aus mehreren Subsystemen. Die Abbildung 2 stellt diese schematisch dar. Es besteht zunchst einmal aus dem Business Partner Interface. Hier werden alle kunden- und hndlerbezogenen Daten gespeichert. Dazu dient es als Anlaufpunkt fr die Zuordnung von Auftrgen und der Provisionsberechnung fr die einzelnen Hndler. In logischer Reihe folgend, beim Zugriff auf das Creditfolio

interne Darstellung der BMW Bank.

- 12 -

im Kernabwicklungssystem, steht das Antragsmanagementsystem (AMS), aus dem die Daten des Antrags zur Finanzierung von Kraftfahrzeugen weitergeleitet werden.

Abbildung 2: Kernabwicklungssystem der BMW Bank3

Vom Business Partner Interface ist in anderen Fllen ein direkter Zugriff auf das Portfolio mglich. Hier werden alle Daten gespeichert und verarbeitet, die in der Bank auflaufen. Des weiteren ist eine Customer Service Center Datenbank (CSC-DB) in Betrieb. Ursprnglich war sie dazu gedacht zur einzigen Datenquelle ausgebaut zu werden. Bisher ist der Aufgabenbereich darauf beschrnkt die Mahndaten zu verwalten. In dieser Datenbank liegen alle Kreditdaten, ebenso wie im Creditfolio, und alle Bankdaten, wie im Bankfolio. Im tglichen Betrieb greift allerdings nur das Zentrale Forderungsmanagement (ZFM) auf die CSC-DB zu. Als zustzliche Transaktionsdatenbank ist die Online Datenbank im Einsatz, die alle Transaktionen aufnimmt, welche durch die Hndler der BMW AG im Extranet erfasst wurden.

interne Darstellung der BMW Bank.

- 13 -

Die BMW Bank befindet sich auf dem Weg von einer Finanzierungsbank zu einer Direktbank mit selektiver Produktauswahl. Geplant ist ein bergang vom Telefonbanking zum Onlinebanking mit einem einheitlichen Frontend fr alle Zugriffsmglichkeiten auf das System. Das kann nur mit Internettechnologien mglich sein. Ebenso werden neben den jetzt im Angebot befindlichen Produkte der Hndlerfinanzierung, Finanzierung und Leasing von Privatfahrzeugen und originre Bankprodukte weitere Produkte geplant oder stehen teilweise vor der Realisierung. Fr die Umsetzung der Plne sind einige Umstrukturierungsmanahmen in der Systemarchitektur notwendig, da das jetzige System fr zuknftige Entwicklungen nicht gewachsen sein wird. Es herrscht allerdings noch keine Einigkeit, welche Teilsysteme durch neuere ersetzt werden sollen, wegfallen oder verndert werden.

1.3 Umstrukturierung in der Bankenbranche

Die in den letzten Jahren vollzogenen Grndungen von Direktbanken (meist als Tochter einer Filialbank) wurde durch zunehmenden Kosten- und Konkurrenzdruck und der Unzufriedenheit der Kunden ber hohe Gebhren, mangelnden Service und schleppende Bearbeitung von Auftrgen begrndet.4 Eine Direktbank bietet die Mglichkeit, kostengnstig eine breite Palette an Bankprodukten anzubieten. Die Kosten werden vor allem im Filialnetz und bei den Mitarbeitern eingespart. Die Motivation einer Bank, wie die BMW Bank, die ursprnglich nur zur Investition und Finanzierung von eigenen Produkten vorgesehen war, in das Direktbankgeschft zu gehen, liegen in einem anderen Kontext. Zum einen ist fr

Vgl. Silescu (1997), S. 2 ff.

- 14 -

die BMW AG durch zunehmenden Wettbewerb ein Margeneinbruch im Kerngeschft zu spren und mit der vermehrten Entstehung von MultifranchiseHndlern hat der Kunde eine bessere Mglichkeit, Produkte zu vergleichen. Ebenso wird ein unzureichender Kundenkontakt und eine optimierungsfhige Kundenloyalisierung im Kerngeschft beklagt. Durch das direkte Angebot von Finanzprodukten und den damit verbundenen stndigen Kontakt zum Kunden, wie z.B. mittels Kontoauszug oder Umsatzbersichten, wird eine leichtere Penetration und Informationsvermittlung, auch von originren Produkten, angestrebt.

1.4 Die Ziele der Arbeit

Mit dieser Arbeit soll versucht werden, den verschiedenen, oben dargestellten Probleme in der Modernisierung der Bankenanwendungen durch Vorstellung mglicher Lsungen, bzw. Teillsungen zu begegnen. Dazu wurde ausgehend von der allgemeinen Client/Server Architektur verschiedene moderne Architekturen und Produkte, sowie dem generellen Aufbau einer Directbanking Architektur, vorgestellt und, ohne einen vollstndigen Vergleich anstreben zu wollen, versucht diese zu untersuchen. Um die Lsungen abzubilden, ist es notwendig Schnittstellen zu beschreiben, die durch Ausbildung eines Schichtenmodells entstehen. Im Teil, der auf die Situation der BMW Bank GmbH im Speziellen eingeht, soll aus der Motivation zur Vernderung heraus eine visionre Lsung dargestellt werden. Auf Techniken des Offlinebankings wurde verzichtet.

- 15 -

2 Produktvergleich deutscher Autobanken

In [...] globalisierten Mrkten mit ihren immer hnlicheren Produkten und immer kurzlebigeren Technologien entsteht ein neues Bedrfnis nach identittsstarken Marken. Markenwerte werden zu Symbolen und Zeichen der Orientierung. Das gilt natrlich ganz besonders fr den Automobilsektor, der wie kaum ein zweiter Wirtschaftszweig den Gesetzen der Globalisierung unterliegt: Noch nie war der Wettbewerb auf unseren Absatzmrkten so intensiv, noch nie war die Identitt einer Marke ein so entscheidendes Wachstumskriterium. [...].5 Wenn ein Unternehmen also eine starke Marke am Markt vertreten hat, muss es bestrebt sein, die Kunden ber das Produkt hinaus lange an das Unternehmen zu binden. Ein Fahrzeug ist ein Anlagegut und somit geht ein Kunde ein relativ hohes Risiko beim Kauf ein. Der Kunde eines Fahrzeugherstellers ist aber nur schwach an das Unternehmen gebunden. Die Abbildung 3 zeigt schematisch die Verteilung der Kundenkontakte im Laufe des Produktlebens.

Abbildung 3: schwankender produktbezogener Kundenkontakt6

Teltschik (2000).

- 16 -

Um einen Kunden strker an das Unternehmen zu binden, werden von den Anbietern von Automobilen, zustzlich zum eigentlichen Fahrzeug, weitere Produkte angeboten. Vorwiegend werden Produkte aus dem Banken- und Versicherungsbereich dargeboten, da diese verwandt mit den bisher angebotenen Finanzierungs- und Leasingprodukte sind und einen untersttzenden Charakter haben. Die Kunden einer Automobilbank werden in zwei Gruppen unterteilt. Fr Barzahlungskunden ist der Einzelpreis als wahrnehmende Informationen von Bedeutung. Bei Finanzierungskunden ist es vielmehr der Effektivzins. Um den zunehmenden Wettbewerb zwischen den Automobilherstellern entgegenzuwirken, bieten diese fr beide Kundengruppen differenzierte Bankprodukte an. Die Hersteller versprechen sich neben der hheren Kundenbindung auch eine Untersttzung der Kunden bei der Finanzierung und eine bessere Penetration der Produkte. Ziel ist es ber den Verlauf des Produktlebens einen gleichmigen und wiederkehrenden Kontakt zum Kunden zu halten. Die Angebote von Banken- und Versicherungsprodukten erfordert fr die Automobilhersteller ein Ausbau der Geschftsttigkeit auf untersttzende Gebiete. Das stellt im Vergleich zum andauernden Outsourcing Gedanken ein gegenlufigen Prozess dar, der aber, wie auch anderen Entwicklungen zum Servicegewinn fr die Kunden fhrt. Die strkere Kundenbindung bedeutet fr die Unternehmen eine bessere Mglichkeit, an Kundeninformationen und -wnsche heranzukommen. Somit kann schneller auf wechselnde Bedrfnisse von potentiellen Kunden reagiert werden und die Hndler der Automobilhersteller ein breiteren Informationsstand zur Verfgung gestellt werden, um den Abverkauf der Produkte zu untersttzen.

eigene Darstellung.

- 17 -

2.1 Bestandsaufnahme des Angebotes

Der deutsche Markt, als wichtiger Teil des europischen Binnenmarktes, ist fr Automobilhersteller besonders interessant. Zum einen leben in Deutschland 82 Millionen Menschen, die mehr als ein fnftel der gesamten europischen Bevlkerung ausmachen. Zustzlich liegt die Bevlkerungsdichte mit 230 Personen je Quadratkilometer etwas auf doppelter Hhe zum europischen Niveau.7

Abbildung 4: Marktwachstums-Marktreife-Portfolio des europischen Automobilmarktes8

Der deutsche Automobilmarkt ist, wie obige Ausfhrungen und die Abbildung 4 belegen, einer der zukunftstrchtigen in Europa. Deshalb ist die nachfolgende Untersuchung des Angebotes der Automobilbanken nur auf deutsche Banken beschrnkt. So wird Deutschland ein sehr hohes Marktwachstumspotential, relativ hohe Marktreife und groes Umsatzpotential zugesprochen, womit der deutsche Markt berdurchschnittliche attraktiv sein wird.

Vgl. Statistisches Bundesamt Deutschland.

- 18 -

Nachfolgend, in der Tabelle 1 sind die deutschen Automobilhersteller bezglich ihrer Angebote im Banken- und Versicherungsbereich aufgefhrt und verglichen. Es wird zwischen verschiedenen Produktgruppen unterschieden. Produkte rund um das Auto sind als Untersttzung der klassischen Produkte zu verstehen. Die Motivation dieser Produkte ist bereits beschrieben. Die originren Bankprodukte sind Produkte, die im klassischen Sinne nur von Filialbanken angeboten wurden. Das Angebot dieser Produkte resultiert aus dem verwandten Charakter zu den Produkten rund um das Auto. Durch gleichzeitiges Anbieten dieser beiden Produktgruppen lassen sich Synergieeffekte realisieren und eine noch strkere Kundenbindung erzielen. Ebenso ist mit zustzlichen Ertrgen aus diesem Bereich zu rechnen. Durch fast tglichen Umgang mit Kreditkarten und Girokonten wird eine hohe Identifikation mit dem Unternehmen erreicht.

BMW Bank 9

MBLF10

Opelbank 11

Porsche Financial Services12

VW Bank 13 & VW Leasing14 ? ? ?17 ?

Produkte rund um das Auto ? ?Finanzierung ? ?Leasing ? ?Zustzlicher Service fr Kommunal & Gewerbe ? ?Kfz Versicherung ? ? ? ? ? ?15 ? ? ? ?16 ? ? ? ?

? 18

nach McKinsey & Co. (1999); Marktwachstumspotential ist die gewichtete Summe von Wachstumsfaktoren, z.B. erwarteter Wachstum bis 2003, Anzahl der Kunden im Jahre 2003, Besitz von PCs im Jahre 1996, Basis der Kleinkundeneinlage 2003; Stand der Marktreife ist die ungewichtete Summe von Reifefaktoren, z.B. Penetration im Jahre 1998, Anzahl Wettbewerber, Position im Lebenszyklus. 9 Produkt- und Internetangebot http://www.bmwbank.de 10 Mercedes Benz Lease Finance; Produkt- und Internetangebot http://www.mblf.de 11 Produkt- und Internetangebot http://www.opelbank.de 12 Produkt- und Internetangebot http://www.porsche.de/financial 13 Produkt- und Internetangebot http://www.vw-bankdirect.de 14 Produkt- und Internetangebot http://www.volkswagenleasing.de 15 fr PKW, LKW und Bus 16 nur Geschftsleasing 17 nur Geschftsleasing

8 Darstellung

- 19 -

? ?Mietangebote Originre Bankprodukte ? ?Tages- & Festgeld ? ?Sparplne & -briefe ? ?Investmentfonds ? ?Kreditkarte ? ?Hypotheken-Service

? 19 ? ? ? ?20 ?

? ? ? ? ?

? ? ? ? ?

? ? ? ? ?

? ? ? ? ?

Tabelle 1: Vergleich der Bankprodukte deutscher Autobanken21

In Tabelle 2 sind die jeweiligen Produkte aufgefhrt, die im Internet abrufbar sind. Gerade im Hinblick auf Direktbanken ohne Filialnetz ist eine Verfgbarkeit im Internet anzustreben, um das Angebot jederzeit, also 24 Stunden an 7 Tagen, aufrecht zu erhalten.

BMW Bank 22

MBLF23

Opelbank 24

Porsche Financial Services25

VW Bank 26 & VW Leasing27 ? ? ? ? ?

Online-Angebote ? ?Finanzierungsrechner ? ?Leasingrechner ? ?Zinsrechner ? ?Graphische Vergleiche ? ?Versicherungskalkulation ? ? ? ? ? 29 ? ? ? ?28 ? ? ? ? ? ? ? ? ? ? ?

Angebot nur fr Mitarbeiter der BMW Group. Angebot nur fr Mitarbeiter der BMW Group. 20 BMW Card, nur fr Besitzer eines BMW-Modells und dessen Partner 21 Legende: ? im Angebot; ? nicht im Angebot 22 http://www.bmwbank.de 23 Mercedes Benz Lease Finance; http://www.mblf.de 24 http://www.opelbank.de 25 http://www.porsche.de/financial 26 http://www.vw-bankdirect.de 27 http://www.volkswagenleasing.de 28 SoftFinder (Finanzierungs- & Leasingratenbersicht) und VisiLease (interaktive Gegenberstellung von Finanzierung und Leasing) 29 Angebot nur fr Mitarbeiter der BMW Group im Intranet.
19

18

- 20 -

? ?Schufa - Kreditberprfung ? ?Persnliche Seiten ? ?Formulare Online Onlinebanking

? ? ?

? ?30 ?

? ? ?

? ? ?

? ? ?

? 31

Tabelle 2: Vergleich des Onlineangebots deutscher Autobanken32

2.2 Auswertung des Produktvergleichs und der jetzigen Position der BMW Bank
Die Angebote von Finanzierung und Leasing sind die klassischen Produkte, die zum Erwerb eines Automobils angeboten werden. Sie sind bei allen verglichenen Banken erhltlich. Eine Differenzierung findet hier nur durch zustzlichen Service und Benefit statt. Allerdings kann ein Verzichten auf bestimmte Angebote zur Unternehmenspositionierung zhlen, um sich als Spezialist und nicht als Generalist zu zeigen. Das breiteste Angebot in diesem Bereich liefert die Mercedes Benz Lease Finanz. Fr die BMW Bank wre denkbar, mit Angebote zur Kfz Versicherung und Mietangebote zustzliche Ertrge aus Provisionen zu erwirtschaften, indem diese sie allen Interessierten angeboten werden. Starke Anbieter beider Produktgruppen, mit denen die Bank kooperieren knnte, sind auf dem Markt vorhanden. Ein Produkt, vermarktet als BMW Marke, besitzt ein hohes Potential, was bereits das Angebot der Kreditkarte der BMW Bank zeigte.33 Das Angebot von klassischen Bankprodukten wird bisher von nur drei Automobilherstellern bereitgestellt. Einen umfassenden Produktmix bietet die VW

konfigurierbare Einstiegsseite; aktuelle Angebote, Speicherung von Finanzierungsund Leasingdaten, Konfiguration von PKW 31 bisher nur im Extranet fr BMW-Hndler realisiert 32 Legende: ? im Angebot; ? nicht im Angebot 33 Innerhalb weniger Monate nach Erscheinung sind mehrere zehntausend Stck ausgegeben.

30selbst

- 21 -

Bank. Die BMW Bank plant das Angebot von Investmentfonds und strebt somit ein gut ausgebautes Produktportfolio an. Der fr Direktbanken wichtige Onlineauftritt ist bei keiner verglichenen Bank durchgehend realisiert. Die VW Bank gibt ihren Kunden die Mglichkeit, Onlinebanking zu betreiben, untersttzt sie aber bei allen anderen Geschftsfelder nicht online. Im Internetangebot der Mercedes Benz Lease Finanz steht ein komplettes Spektrum an Finanzierungs- und Leasinghilfen, Versicherungskalkulation, graphische Auswertungen und weitere Services zur Verfgung. Die BMW Bank hat ebenfalls Rechner fr Finanzierungs- und Leasinggeschfte realisiert, verzichtet aber auf weitere Tools. Besonders interessant ist das Angebot von Formularen zum Abschluss von Geschften im Internet. Leider mssen diese nach dem Ausfllen ausgedruckt und der BMW Bank zu geschickt werden. Eine zuknftige Integration bringt fr den Kunden einen sprbaren Qualittsgewinn. Mit dem Ausbau des Betriebs zum Onlinebanking vom Extranet zum Internet und der Integration der Formulare in einen papierlosen Antragsprozess steht die BMW Bank im Vergleich zu den anderen deutschen Autobanken aus heutiger Sicht gut da. Das Abschlieen von Finanzierungs-, Leasing- und Versicherungsgeschften im Internet ist durch keine der betrachteten Banken realisiert. Das vorrangige Problem bei der Realisierung der Onlinegeschfte sind die Legitimation und Authentifizierung der Kunden. Mit den neuen Richtlinien der Digitalen Signatur des Bundesamtes fr Sicherheit in der Informationstechnik34 wird eine gesetzliche Untersttzung von Onlinegeschften erwartet. Nachfolgend werden dann mit Sicherheit verstrkt Angebote im WWW zu finden sein. Bankgeschfte per Internet, wie es viele Filial- und Direktbanken anbieten, wurde nur von der VW Bank angeboten. Da die BMW Bank auch Produkte in Bereich der klassischen Bankprodukte anbietet, ist es sinnvoll, diese durch On-

- 22 -

linebanking den Kunden nher zu bringen und fr eine Entlastung des Callcenters zu sorgen. Bisher ist die Onlinebanking-Software nur von Hndlern der BMW AG im Extranet der BMW Bank nutzbar. Ein Ausbau zur Internetlsung ist in der Realisationsphase. Somit strebt die BMW Bank an, ihr Gesamtpaket abzurunden und ein umfassenden Produktmix anzubieten.

34

Internetangebot www.bsi.bund.de .

- 23 -

3 Moderne Client/Server - Architekturen

3.1 Client/Server: Technik der neunziger Jahre35

Zur Ablsung der in der kommerziellen Informationsverarbeitung lange vorherrschenden Architektur aus zentralen Grorechner mit angeschlossenen dummen Terminals wurde mit Aufkommen von preiswerten Minirechnern (fr die Clients) und kostengnstigen Midrangesystemen (fr die Server) eine kooperative Informationslandschaft aus Clients und Servern mglich. Mit dieser Client/Server-Technologie soll eine schnellere Anpassung an die stark wandelnden Geschftsablufe in den Unternehmen untersttzt werden.36 Bei dieser Lsung wird die Programmausfhrung zwischen den Rechnern aufgeteilt. Allgemein ist der Begriff der Client/Server-Technologie ein berbegriff fr alles, was mit verteilter, kooperativer Informationsverarbeitung zu tun hat.37 Eine Voraussetzung dieses Ansatzes ist, dass die Systeme offenen Schnittstellen unterliegen, die durch Standards beschrieben sind.38 Somit lassen sich zur Anpassung an die wirtschaftlichen Ablufe im Unternehmen dem System flexibel weitere Clients hinzufgen und kostengnstig die Servermaschine erweitern, da im Unterschied zu den Rechnern im Mainframebereich Hard- und Softwareabhngigkeit von einem einzigen Hersteller durchbrochen wird. Zur Daten- und/oder Applikationshaltung knnen aber auch weiterhin zentrale Grorechner eingesetzt werden, um zum Einen frher gettigte Groinvestitionen nicht verfallen zu lassen und zum Anderen eine hohe Ausfall- und Datensicherheit zu erhalten.

35

Begriff geprgt von Karer/Mller. Vgl. Karer/Mller, S. VII. 37 Vgl. Ebenda, S.1. 38 Vgl. Ebenda, S. 37 ff.
36

- 24 -

Die kooperative Informationsverarbeitung ist eine notwendige Voraussetzung fr die Client/Server-Technologie, und zwar nicht nur zwischen Hardware-, sondern auch zwischen Software-Komponenten.39 Somit ist zwischen Hardware- und Softwareebenen zu unterscheiden. Die Hardware ist in mehrere physikalischen Stufen (engl. tier) gegliedert, die im Netzverbund miteinander kommunizieren. Die Softwarearchitektur besteht aus mehreren Schichten (engl. layer), die eine bestimmte Aufgabe der Anwendung bernehmen und gegenseitig Dienste fr eine direkt benachbarte Schicht anbieten. Es ist zwischen der Prsentationsschicht, Steuerungsschicht, Schicht der betriebswirtschaftlichen Logik und der Datenverwaltungsschicht zu unterscheiden. Vorteile einer Schichtung der Funktionalitt liegen vor allem in der Unabhngigkeit der Schichten, Austauschbarkeit der Implementierungen der Schichten, der Reduktion von Komplexitt und in der Standardisierung.

Abbildung 5: Zusammenhang zwischen Stufen und Schichten40

39 40

Vgl. Ebenda, S. 37 ff. Darstellung nach Plenum Institut, Michael Bauer.

- 25 -

Die Stufen der Hardware sind in Prsentationsstufe, Stufe der Bereitstellung der Applikation und der Datenhaltungsstufe zu trennen. Das Zusammenspiel zwischen Hardware- und Softwareplattformen ist in der Abbildung 5 verdeutlicht. Die Grenzen der Stufen und Schichten sind nicht zwingend. Mehrere Mglichkeiten der Verteilung der Komponenten einer Anwendung auf die Client-, bzw. Serverseite zeigt die Abbildung 6.

Abbildung 6: Mglichkeiten der Verteilung der Applikation41

Die Verarbeitung, bzw. die Prsentation auf einem Client ist durch feldweise Interaktion in einer graphischen Benutzeroberflche, einer GUI, gekennzeichnet. Im Vergleich dazu wird die Prsentation auf einem Terminal als full screen Operation bezeichnet, da immer der gesamter Bildschirminhalt zur Darstellung vom Zentralrechner, bzw. ein ausgeflltes Formular zum Zentral-

41

Darstellung nach Plenum Institut, Michael Bauer.

- 26 -

rechner versandt wird. Eine sofortige Reaktion auf eine Eingabe in einem Feld, wie sie eine GUI untersttzt, ist nicht mglich. Die GUI bernimmt somit nicht nur Aufgaben der Darstellung, sondern auch der Verarbeitung und Steuerung. Mit dem Einsatz leistungsstarker Endgerte ist es mglich, lediglich den Datenbestand zentral halten zu mssen, whrend die Verarbeitungslogik dezentral auf den Clients luft. In der Abbildung 6 wird dieser Zustand als Fat Client bezeichnet.

3.2 Ziele der Einfhrung von Client/Server-Architekturen

Als Zielsetzung der Einfhrung von Client/Server-Architekturen wurden in einer Umfrage42 besonders direkte Untersttzung der Geschftsfunktionen und das Nherbringen der Informationen zum Anwender genannt. Grnde, wie Kostenersparnisse, Entwicklungsprozess von Software beschleunigen oder Beseitigung heterogener Systemwelten wurden nur nebenbei erwhnt. Verteilte Systeme, zu denen Client/Server-Systeme zhlen, erfordern einen hheren administrativen Aufwand als zentralistische Systeme und schaffen zustzlich neue Sicherheits- und Konsistenzprobleme. Allerdings sollte der potentielle Nutzen von diesen Lsungen nicht unbetrachtet bleiben. Mit Hilfe der verteilten und integrierten Anwendungsarchitektur werden Qualittsverbesserungen der Systeme, wie Schichtenbildung, Modularisierung, Standardisierung und Interoperabilitt erst mglich. Durch die Anwendungssysteme werden relevante Informationen und bentigte Dienste unternehmensweit bereitgestellt. Zur Qualittsverbesserung der Systeme ist vor allem auch die graphische Benutzeroberflche zu zhlen. Damit wird auch die strkere Orientierung der Informatik an den Erfordernissen der Geschftsablufe deutlich.

42

Vgl. Umfrage in Computerwoche 43/1993.

- 27 -

3.3 Client/Server - Systeme der zweiten Generation

Um die oben genannten Probleme der Client/Server-Architekturen zu umgehen, setzte eine Entwicklung ein, die eine Reduzierung der Verarbeitung auf den Clients und eine Verwendung von plattformenabhngigen Standards vorsah. Ebenso ist die Verwendung einer portablen Programmiersprache zur Verteilung von Anwendungen eine Anforderung, die in diesem Zusammenhang aufkommt. Somit entstehen Anwendungen, die nicht nur auf PC's, sondern auch auf vielen anderen Endgerten einsetzbar sind. In letzter Zeit hat sich das Internet als zentrales Informationsmedium und als Antrieb des sich abzeichnenden Informationszeitalters herausgebildet. Stark hat dazu die schnell wachsende Popularitt des WWW beigetragen. Eine Abschtzung der Potentiale und Folgen ist heute eher noch spekulativ.43 Im Folgenden soll nun auf die Auswirkungen der Internettechnologien eingegangen und die Auswirkungen dieser auf die Integration dargestellt werden. Der Fokus der Betrachtung liegt auf der Kommunikation ber das World Wide Web. Der Nutzen aus der Dezentralisierung erschliet sich allerdings erst vollkommen, wenn sich die Client/Server-Architektur von einer einfachen FrontendVerarbeitung zur kooperativen Verarbeitung mit einer Aufgabenverteilung zwischen den beteiligten Rechnern entwickelt. Dabei bernehmen spezialisierte Rechner im Verbund die Aufgaben, fr die sie gut einsetzbar sind. Die Software, die diese Arbeitsteilung ermglicht, wird Middleware genannt. Neben der Basis-Middleware hat sich eine zweite Gruppe etabliert, die Integrations-Middleware.44 Dazu gehren neben Gateway-Produkten auch Information Broker, die als Enterprise Application Integration bekannt sind. Die Gateways vermitteln zwischen verschiedenen Basis-Middleware-Protokollen,

Diensten und Frameworks und sollen Programmierer von der Komplexitt ab-

43 44

Vgl. sterle/Riehm/Vogler, S. 107. Vgl. Informationweek 22/2000, S. 26 ff.

- 28 -

schirmen.45 Beispiele dieser bersetzer sind COM/CORBA Bridge oder Gateways zwischen CICS Protokolle und CORBA. Nachfolgend sind die Aspekte jeweils in einem Abschnitt dargestellt.

3.3.1 Internet als Integrationsplattform

Ursprnglich waren WWW Seiten rein statische Hypertextdokumente. Revolutioniert wurde das Netz von dem Gedanken, dynamisch Informationen anbieten zu knnen. Es wurden Schnittstellen entwickelt, die den Zugriff auf Datenbanken und Applikationen ermglichen. So knnen beispielsweise

Produktdatenbanken,

Vertriebsanwendungen,

Kundeninformationssysteme

oder andere Programme sowohl weltweit, als auch unternehmensintern ber das WWW in Echtzeit verfgbar sein. Integration erfolgt dabei auf der Prsentationsebene. Aus Sicht des Benutzers wird der WWW Browser zur integrierten Oberflche fr Internetdienste, sowie fr betriebliche Datenbanken und Applikationen. Die Idee ist das intelligente Dokument46, das logische Komponenten wie Text, Hyperlinks, Datenbankzugriffe und Applikationsfunktionalitt in einem elektronischen Dokument anordnet und dem Benutzer verfgbar macht. Fr die Realisierung der oben beschriebenen Ideen sind mehrere Integrationsanstze mglich.

45 46

Vgl. Ebenda, S. 26 ff. sterle/Riehm/Vogler, S. 116.

- 29 -

3.3.1.1 Integration ber die CGI Schnittstelle

Die derzeit sehr hufig genutzte Schnittstelle zur Einbindung von Applikationen ist das Common Gateway Interface (CGI) eines Web Servers. Die Abbildung 7 verdeutlicht die Einbindung der Schnittstelle. Hauptfunktion eines HTTP Servers ist es, den Client mit HTML Dokumenten zu bedienen. Um andere Ressourcen aufzurufen, ist ein GatewayProgramm zwischen dem Server und der Applikation bzw. Datenbank erforderlich. Der Server reicht die erforderlichen Eingabedaten ber die CGI Schnittstelle an das Gateway-Programm. Diese ist ein Standard, der genau festlegt, wie Daten an ein Gateway bzw. CGI Programm gesendet und wie Daten wieder zurckgegeben werden. Das Programm fhrt z.B. eine Datenbankanfrage durch, gibt das Ergebnis dem Server zurck, welcher Daten in Form eines HTML Dokuments an den Browser des Clients weiterreicht.

Abbildung 7: Integration des WWW-Server mit Applikationen ber CGI47

Damit ist auf einfache Weise eine global verfgbare, dreistufige Client/Server Architektur mit dem WWW Server als mittlere Ebene realisiert. Allerdings gilt CGI als ineffizient und langsam. Auerdem nimmt es keine Typberpr-

47

Vgl. Ebenda, S. 117.

- 30 -

fungen der bergebenen Daten vor und erkennt so keine Fehleingaben des Benutzers. Weiter mssen Daten stets als HTML Dokument an den Browser zurckgegeben werden, was einen zustzlichen Aufwand nach sich zieht. Da ein CGI Programm einfach nur durch Laden der Webseite gestartet werden kann, ist sehr sorgfltig darauf zu achten, dass keine Sicherheitslcke entsteht, und es sind ggf. Zugriffsbeschrnkungen zu integrieren. Ein grundlegendes Problem bei der CGI Programmierung liegt in der Natur des zustandslosen HTTP Protokolls. Eine Client/Server Interaktion ist nach einem Aufruf Antwort Zyklus beendet. Beim nchsten Aufruf ist keine Information mehr ber den vorhergehenden Vorgang vorhanden. Um eine Sequenz von Interaktionen des Benutzers durchzufhren, muss daher jedes Mal eine neue Verbindung aufgebaut und ggf. Zustandsinformationen, als verstecktes Feld im HTML Dokument oder als Cookie auf dem Client-Rechner zwischengespeichert werden. Um eine bessere Performance zu erzielen, wird eine Erweiterung des HTTP Protokolls fr Sitzungen notwendig sein. Ein Ansatzpunkt in diese Richtung ist die Integration mit CORBA. Fast alle gngigen WWW Serverprodukte bieten neben der relativ einfachen CGI Schnittstelle eine zustzliche Schnittstelle an. Die wichtigsten Beispiele sind Netscape Server API, Microsoft ISAPI oder Apache API. Mit Hilfe dieser APIs soll insbesondere eine bessere Performance und Effizienz beim Zugriff auf externe Datenbanken und Applikationen mglich sein. Entwicklungen von Anwendungen sind aber proprietr und erfordern die Kenntnis der speziellen Programmiersprache.

3.3.1.2 Integration von Applikationen in HTML Dokumente

Eine andere Form der Integration von Applikationen in das WWW sind Java Applets. Grundidee ist es, eine Applikation nicht auf dem Server zu belassen und abzuarbeiten, sondern an den Browser zur Ausfhrung zu senden. Dazu musste eine plattformenunabhngige Sprache entwickelt werden, die mittels Just-in-time Interpreter auf jedem System luft, das die Voraussetzungen da-

- 31 -

fr erfllt. Diesen Anforderungen wird Java gerecht. Java ist eine hauptschlich von Sun Microsystems entwickelte Programmiersprache, die es ermglicht, kleine Programme, sogenannte Applets, ber das WWW zu verteilen. Java basiert auf C++/Smalltalk und eignet sich fr Anwendungen in verteilten Netzen, wie das Internet. Die Abbildung 8 zeigt die Funktionsweise von Java im Internet auf.

Abbildung 8: Funktionsprinzip Java Applets im WWW48

Von einem HTML Dokument besteht ein Verweis auf ein Java Applet, das in einem Byte Code vorliegt. Greift ein Browser auf dieses Dokument zu, wird der Code in den Browser geladen, wo die Java Virtual Machine (JVM) den Byte Code in ausfhrbaren Maschinencode umsetzt. Die JVM ist Bestandteil eines Browsers, welcher Java Applets interpretieren kann. Diese ermglicht es, dass bei der Programmierung des Applets die Zielplattform, auf dem es spter eingesetzt werden soll, nicht bekannt sein muss. Das Applet wird ausgefhrt, sobald der Benutzer den entsprechenden Teil des HTML Dokuments aktiviert. Mit Applets angereicherte WWW Seiten kommen einer bisherigen Anwendung recht nahe, da eine komplette GUI fr Java zur Verfgung steht. Die Mglichkeit, Applikationen bei Bedarf zu laden, die einfache Installation und Unabhngigkeit von der Plattform und eine Integration mit Middleware aus dem Bereich der verteilten Objektorientierung erklrt, dass die Konzepte

48

Vgl. Ebenda, S. 119.

- 32 -

hinter Java einen nachhaltigen Einfluss auf die Softwareindustrie und auf Applikationsarchitekturen haben.

3.3.1.3 Integration WWW mit Middleware

Das Zugriffsverfahren ber CGI Mechanismen gilt als ineffizient und kommt einer starren Verdrahtung von HTML Dokumenten mit Applikationen gleich. Einen flexibleren und effizienteren Zugriff auf Backend Applikationen und Datenbanken sowie die Einbindung von Verteilungsdiensten wie Sicherheit und Transaktionsmanagement verspricht die Integration mittels Middleware. Im Zentrum der Diskussion steht vor allem die Einbindung von Datenbankzugriffsmiddleware und Middleware zur verteilten Objektorientierung. Prinzipiell knnen drei Anstze zur Integration unterschieden werden. Die Abbildung 9 veranschaulicht das schemenhaft.

Abbildung 9: Integration WWW mit Middleware49

49

Vgl. Ebenda, S.120.

- 33 -

Die einfachste Variante beruht auf der CGI Schnittstelle, ber den ein Middleware Client aufgerufen wird. Es handelt sich hier um eine Erweiterung der Lsung ber die CGI Schnittstelle. Durch das CGI Programm wird ein Middleware Client zur Verarbeitung aufgerufen. Der Middleware Client ruft wiederum einen Middleware Server auf und gibt die Ergebnisse wieder zurck. Im Idealfall generiert der Middleware Client zur Rckgabe bereits die entsprechendem HTML Dokumente zur Weitergabe an den Web Client. Ein weiterer Ansatz beruht auf der Integration von Middleware als eine WebServer Komponente, z.B. kann ein auf CORBA basierender ORB zur Verbindung des WWW Servers mit Applikationen dienen. Ein dritter, umfassender Ansatz setzt auf die Erweiterung oder einen Ersatz des HTTP Protokolls. Eine Standardisierung gibt es hier noch nicht. Eine Mglichkeit ist die Einbindung des IIOP Protokolls zur Kommunikation zwischen Object Request Brokern auf Basis des Internets in das HTTP Protokoll. Dabei gibt es verschiedene Varianten der Kooperation zwischen HTTP und IIOP ohne Modifikation von HTTP. Mit der Verwendung von IIOP soll eine nahtlose Integration verteilter, objektorientierter Systeme in das WWW mglich sein. Web Browser bekommen so Zugriff auf CORBA basierte Systeme, welche wiederum auf Informationen im WWW zugreifen knnen. Fr die Einbindung von Datenbankzugriffsmiddleware und fr den Bereich der verteilten Objektorientierung existieren heute viele kommerzielle Produkte. Die CGI Schnittstelle wird ihre Bedeutung fr die Integration verlieren, bzw. hat sie bereits verloren. Vielversprechend ist die Integration von Applets mit CORBA. Applets knnen Dienste von Objekten im Backend nutzen, welche wiederum auf Unternehmensdaten zugreifen.

3.3.2 Middleware
Aus der mehrschichtigen Client/Server Architektur, wie sie auch durch die Internetintegration forciert wird, entsteht die Notwendigkeit, die Softwareschichten miteinander kommunizieren zu lassen und diese zu kontrollieren. Ei-

- 34 -

ne Middleware wird, wie der Name schon darauf deuten lsst, im Zentrum einer Architektur angesiedelt. Middleware wird sowohl horizontal, wie auch vertikal in einer Architektur eingesetzt. Horizontal verbindet sie Anwendungen und Transaktionen zu einer virtuellen Anwendung ber Rechnergrenzen hinweg. Vertikal bildet Middleware eine oder mehrere Ebenen von vermittelnder Software in der Architektur zwischen Benutzer Frontends und dem Backend aus und ermglicht die Kommunikation der benachbarten Ebenen. Viele Middleware Produkte verbinden nicht nur Teile einer Architektur, sondern bieten zustzliche Services an, um eine leistungsfhiges System zusammenzubauen. So verteilt die Software Ressourcen, wie Speicher- und bertragungskapazitten und Netzverbindungen, sorgt fr Skalierbarkeit des Systems und sichert die Transaktionssicherheit.

3.3.2.1 Arten von Middleware

Die individuell entwickelten Verbindungen zwischen zwei Anwendungen zhlen zu den am lngsten existierenden Middleware Techniken. Bei dieser Verbindung sind stets Anpassungen notwendig, falls sich eine der Anwendungen ndert. Mit der neuen Generation von Middleware Software soll dieser Aufwand entfallen. Die Middleware Schnittstellen ODBC und JDBC stellen einer Anwendung eine Verbindung zu einem Datenbankserver zur Verfgung, ohne jedoch explizit auf Eigenarten der Rechnerplattform oder des Betriebssystems zugreifen zu mssen. Somit kann man Datenbanksysteme auch als Middleware bezeichnen. Als Nachfolger von ODBC wird OLE DB eingesetzt. Mit dieser Schnittstelle knnen auch unstrukturierte Datenformate, wie Bilder oder Videos verarbeitet werden. JDBC ist in Java entwickelt und ist deshalb auf allen Java untersttzten Plattformen einsetzbar. Zur Anbindung von Webseiten an Datenbanken wird es hufig eingesetzt. Eine Mglichkeit sind Java Applets, die mit dem Aufruf einer Webseite auf den Client geladen werden und dort ausgefhrt wer-

- 35 -

den. Allerdings wird beim erneuten Aufruf dieser Seite das Applet erneut bertragen. Bei einem umfangreicheren Programm ist es aus Geschwindigkeitsgrnden sinnvoller, die Programme nicht erneut zu bertragen oder diese auf dem Server abzuarbeiten. Eine Mglichkeit, das Applet nicht erneut bertragen mssen bietet die Technik der Signed Applets. Dabei wird das Applet beim erste Aufruf auf den Client heruntergeladen und zwischengespeichert. Beim erneuten Aufruf der Webseite kann anhand der Signatur des Applet berprft werden, ob es auf Serverseite verndert worden ist, oder auf dem Client manipuliert wurde. In beiden Fllen wird das Applet erneut geladen. Zur Entlastung des Endkundengertes kann ein Javaprogramm, ein sogenanntes Servlet, auf dem Server ausgefhrt werden. Durch dieser Technologie ist es nicht mehr zwingend notwendig, ein PC als Endgert einzusetzen, vielmehr knnen leistungsschwchere und kleinere Gerte, wie Mobiltelefone, Organizer oder Settop Boxen zur Anwendung kommen. Lediglich ein javakompatibler Browser wird zur Darstellung bentigt. Damit rechenintensive Ablufe auf den Servern der Electronic Commerce Anbieter ausgefhrt werden knnen ist dort eine Laufzeitumgebung notwendig. Diese wird beispielsweise als Bestandteil von Webapplicationserver, einer weiteren zentralen Middleware, bereitgestellt. Dabei ist die Hauptaufgabe wiederum die Anbindung eines beliebigen Clients an beliebige Backend-Systeme eines Unternehmen. Wie im konventionellen Geschft ist beim elektronischen Handel ein mglichst uneingeschrnkter Informationsfluss zwischen den beteiligten Anwendungssystemen, und hier zustzlich mit dem Internet, sehr wnschenswert. Medienbrche und manuelle Eingaben sind auf ein Minimum zu beschrnken. Da synchrone Kommunikation zwischen Anwendungsobjekten aufgrund verschiedenen Grnden, wie Netzwerkausfall oder lange Antwortzeiten, nicht immer gesichert werden kann, werden mit Hilfe asynchroner Kommunikationstechniken Daten ausgetauscht. Eine weitere Art von Middleware, das Message Queueing (MQ) bernimmt diese Aufgabe. Dabei werden Nachrichten zur Organisation des Arbeitsablaufes zwischen Anwendungssystemen ber unterschiedliche Plattformen und Netzwerke verschickt. Die Nachrichten werden

- 36 -

zwischengespeichert und an die Adressaten weitergeschickt, wenn beteiligte Systeme und Netzwerke wieder verfgbar sind. So ist nicht nur eine vollstndige und zuverlssige Zustellung garantiert, sondern auch eine vielfache Verschickung mglich. Die erforderliche Interaktion mit Netzwerkverbindungen und bertragungsprotokollen erfolgt ber standardisierte Schnittstellen. Zur Untersttzung der Zugriffssicherheit, der Datenintegritt und der optimierten Nutzung von Netzwerk Kapazitten, sowie zur Verbesserung der Performance werden Transaction Processing Monitore (TP Monitore) zur Verarbeitung der Transaktionen eingesetzt. Die grten Marktanteile in dieser Produktgruppe der Middleware besitzen IBM CICS (Mainframe, Unix und andere) und Bea Tuxedo (offene Systeme).50 Das Transaktionssystem prft jede Transaktion mit einem Two-Phase-Commit, ob sie vollstndig abgewickelt wurde. Wurde sie unter- oder abgebrochen, findet ein Rollback statt. Die Transaktionsmonitore arbeiten auf den unterschiedlichen Plattformen nahtlos zusammen und verteilen in Zeiten hoher Beanspruchung die Lasten automatisch auf verschiedene Systeme. Webapplicationserver bernehmen vorwiegend die Aufgabe, operative IT Systeme, mit denen Unternehmen ihr Geschft abwickeln, mit dem Internet zu verbinden. Damit knnen Inhalte automatisiert im Internet abgerufen werden. Mit sogenannten Java Server Pages lassen sich Web Inhalte dynamisch gestalten. Aus den aktuellen Geschftsdaten werden mit dieser Technologie im Moment des Aufrufens neue Webseiten generiert. Mit Hilfe eines Kundenprofils kann die Gestaltung der Seite auf den Benutzer zugeschnitten werden. Ein Webauftritt kann so stndig aktuell gehalten werden und an Kunden individuell angepasst sein. Java Server Pages werden von den oben bereits erwhnten Java Servlets erzeugt. Neben einer Laufzeitumgebung verfgt ein Webapplicationserver auch ber erforderliche Schnittstellen und Gateways, um auf vorhandene Daten und Syste-

- 37 -

me im Unternehmen zugreifen zu lassen. Neben dieser Infrastruktur dienen die Server auch als Behlter (Container) fr Anwendungskomponenten. Mit Enterprise Java Beans (EJB), in Java geschriebene Komponenten, beispielsweise lassen sich persistent Internetanwendungen betreiben, wie ein Warenkorb einer Electronic Commerce Anwendung, oder eine Kreditanwendung einer Bankanwendung. Eine bestimmte Art von EJB, die Entity Beans, werden persistent im EJB Container, einen Teil eines Applicationservers, gehalten. Dadurch wird die Zustandslosigkeit des HTTP Protokolls durchbrochen. Daneben gibt es Session Beans, die die Geschftsablufe steuern und damit die Transaktionen berwachen. Mit den Entity Beans lassen sich Geschftsregeln von Unternehmen implementieren und modularisieren. Diese Komponenten werden hufig als Business Objects bezeichnet und knnen Zugriffe auf Datenhaltungssysteme oder Altanwendungen kapseln, wodurch eine Integration einer heterogenen gewachsenen Umgebung realisiert wird.

3.3.2.2 Vorteile von Middleware

Fr die Integration von heterogenen Plattformen und Anwendungen, wie sie bei gewachsenen Architekturen vorkommen, ist der Einsatz einer Middleware zwingend notwendig. Sie bietet offene Schnittstellen fr die Interaktion der Anwendungskomponenten an und dient als Container fr Komponenten, wie EJB und COM Objekte. Mit Hilfe von Middleware lassen sich Investitionen in Altsysteme erhalten, indem die Anwendungen in Komponenten gekapselt und in einer objektorientierten Architektur eingesetzt werden. Durch die Kapselung vom Anwendungen und Systemen verringert sich der Aufwand fr Wartung und Softwarerelease Arbeiten, da beim Austausch der entsprechenden Komponenten die angrenzenden Programmteile kaum betrof-

50

Vgl. iT Management, Oktober 1997.

- 38 -

fen sind. Einen Object Request Broker, eine Middleware die verteilte Objektorientierung ermglicht, kann sogar selbst gegen einen anderen ORB ausgetauscht werden. Das wird durch implementationsbergreifenden Definitionen der Object Management Group (OMG) vorgeschrieben und jede Implementierung eines ORBs hlt sich an diese Richtlinien. Die ORBs mit der hchsten Verbreitung sind IONA Orbix, Inprise Visibroker und Bea ObjectBroker.51 Middleware von verschieden Herstellern zu kombinieren ist aufwndig. Aus diesem Grund bieten Hersteller umfangreiche Pakete um ihre Middleware an, ein Beispiel ist der schon beschriebener Webapplicationserver. Ein weiterer Trend besteht in der Aufnahme von Middleware Funktionen in Datenbanksystemen. Ein Beispiel ist die Javafhigkeit von Oracle 8i.

3.3.2.3 Integration von SAP R/3 in das WWW

Ein weiterer Weg zur Integration ist die Verwendung spezifischer, auf die zu integrierenden Applikationen abgestimmte Mechanismen. Ein Beispiel dafr ist die Lsung von SAP zur Einbindung von Internet Applikationen auf Basis ihrer Standardsoftware, dargestellt in der Abbildung 10. Kernstck des Ansatzes ist der R/3 Internet Transaction Server, der zwischen dem WWW Server und dem R/3-System gelagert ist. Dabei handelt sich um eine Technologie, die spezifisch fr SAP Internet Applikationen besondere Anforderungen fr die Realisierung von Internet Applikationen umsetzen soll. Zu seinen Aufgaben gehrt es, den zustandslosen Charakter des HTTP Protokolls abzuschirmen, Transaktionen ber das Internet auszufhren, sowie spezielle Sicherheitsanforderungen und Skalierbarkeit zu gewhrleisten. Innerhalb des R/3 Transaction Servers laufen die eigentlichen Internet Applikationen. Diese sogenannten R/3 Internet Transaction Components sind zum

51

Vgl. Plenum Institut, Michael Bauer.

- 39 -

R/3 System komplementre, transaktionsorientierte Applikationen. R/3 Internet Transaction Components benutzen die API (BAPI) Schnittstellen, um erforderliche Daten und Funktionalitten der eigentlichen R/3 Applikationen zu erhalten. Der WWW Server empfngt die Daten der Internet Applikationen vom Transaction Server ber das SAP Automation API und setzt sie in eine HTML Seite um.

Abbildung 10: Integration von SAP R/3 in das WWW52

Die Abbildung 10 zeigt noch zwei weitere Mglichkeiten der Integration von SAP Applikationen in das WWW auf. Diese sind vor allem dann erforderlich, wenn die verfgbare R/3 Transaction Components nicht die Anforderungen des Entwickelns einer Internet Applikation abdecken, wie es beispielsweise PopupFenster darstellen. Dabei stehen die Funktionalitten des Transaction Servers nicht zur Verfgung. In Variante 2 greift der WWW-Server direkt auf die BAPIs des R/3-Systems und damit auf die SAP Applikationen zu. Eine dritte, in bezug auf Performance

52

Darstellung nach Plenum Institut, Michael Bauer.

- 40 -

und Sicherheit am wenigsten geeignete Variante ist die Verwendung von Screen Scraping Technologie, um die Informationen aus den R/3 Applikationen zu beschaffen.

3.3.3 Object Request Broker - Verteilte Objektorientierung

Das Modell eines Object Request Broker (ORB) wurde von der Object Management Group definiert und standardisiert die Objekttechnologie. Man geht von einem verteilten Objektmodell aus, bei dem die Objekte auf verschiedenen logischen und physischen Verarbeitungsknoten verteilt sind. Die Objekte kommunizieren durch Nachrichtenaustausch in standardisierter Form. Der ORB ermittelt fr jede Nachricht das Zielobjekt und leitet die Nachricht weiter. So muss ein Objekt nicht den Aufenthaltsort eines anderen Objektes kennen, von dem es einen Dienst erwartet. Es entsteht eine dynamische Struktur von Objekten. CORBA und COM/DCOM stehen fr zwei Vorhaben, einen Standard fr die Systemintegration auf Basis der verteilten Objektorientierung zu etablieren. Whrend CORBA Ergebnis der Arbeiten eines breit angelegten Standardisierungsgremiums ist, steht hinter COM/DCOM der Marktfhrer fr Desktop Applikation Microsoft. Die folgenden beiden Abschnitte gehen jeweils fr CORBA und COM/DCOM auf die Zielsetzungen und die wesentlichen Architekturkomponenten ein.

3.3.3.1 CORBA Architektur

Die OMG wurde 1989 als ein Konsortium von Herstellern von Objekttechnologie gegrndet und umfasst inzwischen mehr als 600 Mitglieder. Ziel der OMG ist die Entwicklung einer Architektur fr die Integration verteilter Applikationen auf Basis der Objektorientierung. Dahinter steht die Vision, flexible

- 41 -

Client/Server Lsungen durch Integration kommerziell beziehbarer Komponenten im Sinne eines plug and play entwickeln zu knnen. In den ersten Jahren seit Grndung der OMG stand die Schaffung einer Infrastruktur fr die verteilte Objektorientierung im Vordergrund. Verteilte Objekte bzw. Komponenten sollen nach dem Client/Server Modell transparent, d.h. ber verschiedene Netzwerke, Programmiersprachen, Betriebssysteme und Applikationen hinweg, interagieren knnen. Ergebnisse dieser Anstrengungen ist eine Middleware: die Common Object Request Broker Architecture (CORBA).

Abbildung 11: CORBA Architektur nach OMG53.

Die OMG hat ihre Aktivitten mit der Object Management Architecture (OMA) abgesteckt. Neben einem Objektmodell, welches die verwendeten Konzepte und Terminologien der Objektorientierung abgrenzt, beinhaltet die OMA ein Referenzmodell mit den Komponenten Object Request Broker, Object Services, Common Facilities und Application Objects. Die Komponenten sind in der Abbildung 11 schematisch dargestellt.

53

Darstellung nach sterle/Riehm/Vogler, S. 93.

- 42 -

Ein wesentliches Prinzip der Standardisierung der OMG ist, dass sie sich auf die Spezifikation der Schnittstellen der einzelnen Komponenten beschrnkt. Die Entwicklung von Produkten liegt allein bei der Softwareindustrie. Die einzelnen Architekturkomponenten werden hier kurz erlutert. Im Zentrum der Architektur ist der CORBA Object Request Broker (ORB), der es Objekten ermglicht, Methoden in anderen, entfernten Objekten aufzurufen und die dafr erforderliche Kommunikation zwischen Client- und Serverobjekten bernimmt. Verschiedene Implementierungen von CORBA unterscheiden sich vor allem durch die verfgbaren Object Services. Object Services stellen verschiedene, grundlegende Dienste zum Bau verteilter Architekturen zur Verfgung und bilden zusammen mit dem ORB die eigentliche CORBA Middleware. Auf der Ebene der Frameworks unterscheidet die OMG horizontale und vertikale Common Facilities. Whrend die Middlewareebene lediglich fr die Interoperabilitt von verteilten Komponenten sorgt, sollen die Common Facilities die Zusammenarbeit der Komponenten auf einer applikatorischen Ebene regeln. Horizontale Common Facilities sollen Bereiche abdecken, die unabhngig vom Anwendungsgebiet einer Applikation sind. Sowohl fr das Systemmanagement als auch den Bereich des Task Management, welcher Workflow und Nachrichtenaustausch abdeckt, gibt es keine Standards bzw. sind Gegenstand der Forschung. Dies gilt auch fr die vertikalen Common Facilities, welche Frameworks fr ausgewhlte Applikationsdomnen, z.B. fr Anwendungen fr Finanzdienstleistungen, abdecken sollen. Entsprechend gibt es keine OMG Standards fr Applikationsobjekte. Die OMA setzt nicht voraus, dass die Applikationen, die ber CORBA integriert werden, objektorientiert entwickelt sein mssen. Applikationsobjekte umfassen somit Eigenentwicklungen, Standardsoftware und auch Altsysteme. Entscheidend ist, dass die Applikationen ber eine CORBA kompatible Schnittstelle ansprechbar sind. Prinzipiell kann so ein Altsystem als ein Objekt aufgefasst werden, das ber eine CORBA IDL spezifizierte Schnittstelle einen Zugriff auf ihre Transaktionen und einzelne Funktionen zulsst. Ein solches Einhllen setzt jedoch eine fundierte Kenntnis der Wirkungsweise des Altsystems voraus. So

- 43 -

ist z.B. zu vermeiden, dass durch einen Zugriff ber diese neuen Schnittstellen Plausibilittsprfungen unterlaufen werden. Die Abbildung 11 verdeutlicht, dass die Standardisierung auf der Ebene der Middleware vergleichsweise weit fortgeschritten ist. Auch sind viele kommerzielle CORBA ORB Implementierungen am Markt erhltlich, die oben bereits aufgefhrt sind. Um die Interoperabilitt der Produkte zu gewhrleisten, hat die OMG Ende 1994 Version 2 der CORBA Spezifikation verabschiedet. Die neu definierten Protokolle betreffen den Austausch zwischen ORB Implementierungen allgemein und speziell bei Einbezug des Internet sowie den Austausch eines ORB mit weiteren verteilten Umgebungen (Inter ORB Protocol). Dagegen ist auf hherer, applikatorischer Ebene noch wenig bis nichts geleistet. Typischerweise sind die Begriffe unprziser, je hher sie sind. Der Einbezug der applikatorischen Semantik in die Standardisierung ist jedoch eine Voraussetzung dafr, dass Komponenten verschiedener Hersteller miteinander kooperieren knnen. Erste Sondierungen in Richtung einer Standardisierung laufen innerhalb der OMG im Rahmen der Business Object Management Special Interest Group (BOMSIG). Business Objects sind in erster Definition Komponenten, die einen Gegenstand der Realwelt sowie dessen Verhalten modellieren. Konkrete Business Object Spezifikationen durch die OMG bestehen jedoch nicht.

3.3.3.2 Microsoft COM/DCOM

Auch hinter Microsofts proprietren COM/DCOM steht die Vision verteilter Komponenten. Ausgehend von der Dominanz im Desktop Markt strebt Microsoft mit dieser Middleware eine Ausweitung seines Einfluss auf eigentliche geschftlichen Kernapplikationen an. Durch Zusammenwirken von Standardkomponenten, verteilt auf viele Windows NT/2000 Server und Windows PCs, soll letztlich ein virtueller Grorechner entstehen.

- 44 -

Die Technologie Component Object Model (COM) ist ein Komponentenmodell fr die Windowsplattform, Distributed COM (DCOM) erweitert es fr verteilte Anwendungssoftware. Fr Server und Client Anwendungen steht mit COM ein einheitliches Modell zur Verfgung, das von jeder Programmiersprache verwendet werden kann. Ebenso lassen sich leicht Komponenten oder Sourcecode wiederverwenden. Ein entscheidender Vorteil gegenber anderen Komponentenmodellen, wie CORBA, sind Services, die bereits im Betriebssystem zur Verfgung gestellt werden und somit die Entwicklung von Anwendungen vom Grund auf erleichtern. Im Zentrum des COM Konzeptes stehen Schnittstellen und somit das Verkapselungsprinzip der Objektorientierung. Eine COM Komponente ist durch eine Gruppe von Schnittstellen definiert. Bei der Weiterentwicklung von Komponenten drfen bestehende Schnittstellen nicht entfernt werden, um keine Referenzfehler zu provozieren, oder in Schwierigkeiten mit einer Version einer Schnittstelle zu bekommen. Beim Erzeugen vom COM Objekten werden automatisch zugehrige Kontextobjekte (COM Proxy und COM Stab) ins Leben gerufen, die Eigenschaften und Methoden bndeln, welche zur Laufzeit bentigt werden. Methodenaufrufe von entfernten COM Objekten, wie in Abbildung 12 dargestellt, werden ber diese Hilfsobjekte realisiert.

Abbildung 12: Methodenaufruf im COM/DCOM Modell54

54

Darstellung nach Plenum Institut, Michael Bauer.

- 45 -

Mit dem Betriebssystem Windows 2000 gab Microsoft COM+ frei, eine Erweiterung von COM/DCOM um Dienste, die auf verteilte Internet-Anwendungen zielen. Ein Transaktionsmonitor gewhrleistet anhand eines Two-PhaseCommit Protokolls den konsistenten Zustand aller Daten. Weitere Erweiterungen in COM+ sind Object Pooling und Message Queueing. Beim Object Pooling werden mehrere Objektinstanzen fr Anwendungen bereit im Speicher gehalten, wovon man sich bessere Performance verspricht. Das Message Queueing sorgt fr eine asynchrone Kommunikation mit einer one-to-many Verteilung von Nachrichten.

3.3.4 Enterprise Application Integration

Durch globalen Wettbewerbsdruck und Ausweitung der Geschftsttigkeit auf das Internet, steigt der Druck, zugekaufte und bestehende Anwendungen, wie ERP oder CRM Systeme, miteinander zu integrieren und durchgngige Geschftsprozesse fr das Electronic Business zu schaffen.55 Der wachsende Integrationsbedarf der Unternehmen lsst einen neuen Typ von Middleware entstehen, die Systeme der Enterprise Application Integration. Anbieter dieser Systeme sahen sich dem Kundendruck ausgesetzt, umfassende integrierende Softwarelsung anzubieten und auf deren Bedrfnisse einzustellen. Vor allem sollen gewachsene und mit hohen Investitionen erstellten Legacy Systeme in die DV Landschaft eingebunden werden und Schnittstellen fr weitere, moderne Systeme offenliegen.56 Anbieter von EAI Produkten versprechen eine schnelle und pflegeleichte Integration von verschiedenen Anwendungen. Dabei werden die Systeme auf Anwendungs- und Prozessebene gekoppelt und die darunterliegende Funktionalitt fr den Anwender verborgen.57 Das heit, der Benutzer des virtuellen

55

56

Vgl. Computerwoche 30/2000, S. 9. Vgl. Ebenda, S. 9. 57 Vgl. Ebenda, S. 9.

- 46 -

Systems sprt in der Regel nicht, dass das System aus mehreren zusammengesetzt wurde. Ebenso bleiben ihm so Spezifika verschiedener Plattformen und Systeme erspart. Um die Integration zu vollziehen und Kommunikation zu ermglichen, bieten EAI Produkte Plattformdienste und Anschlusstechniken an, bernehmen Datentransformation, verfgen ber regelbasierte Maschinen, helfen bei der Workflowsteuerung und stellen Adapter und Konnektoren zur Anbindung vorhandener Anwendungen bereit. Sie dienen jedoch nicht der Implementierung von Geschftslogik.58 Nach erster Einschtzung lassen sich vier Gruppen von Servern unterscheiden.59 Der Integration Server (oder auch Integration Broker) zeichnet sich durch eine serverzentrierte, skalierbare Architektur aus. Ziel des zentralen, prozessgesteuerten Ansatzes ist es, alle Logik zur Verbindung bestehender Anwendungen im Integrationsserver zu definieren. Notwendigerweise umfasst der Server die Abbildung und Konvertierung der unterschiedlichen Datenformate und -strukturen in ein einheitliches Format. Zustzlich adressiert und verteilt er Nachrichten neu. Dieser Ansatz verspricht wenig Programmieraufwand, um die Integration zu vollziehen. Lediglich die Anbindungen an die verschiedenen Systeme und die Prozessablaufsteuerung muss bei Releasenderungen und Integrationsanpassungen berprft und variiert werden. Starke Vertreter dieser Art sind Crossworlds und Software Technologies Corp. (E-Gate), sowie die deutsche Vertreter Software AG (Entire X und Tamino), Fujitsu-Siemens (Open Seas)60 und JARDiX AG (JARDiX Integration Server). Der Message Broker, als zweiter Ansatz, verspricht durch eine dezentrale Server Architektur bessere Lastverteilung bei hoher Beanspruchung. Er wird

58 59

Vgl. Computerwoche 30/2000, S. 9. Vgl. Informationweek 22/2000, S. 26 ff. 60 Vgl. Informationweek 12/2000, S. 59 ff.

- 47 -

vor allem ntig, wenn sich die Integrationsaufgabe nicht durch einfaches Zusammenstecken der zu integrierenden Anwendungen lsen lassen. Dazu untersttzt er eine Vielzahl von untersttzten Kommunikationsmodellen, Netzwerkund Systemplattformen und Programmierschnittstellen. Die Integration der Applikationen erfolgt mittels Message Handling ber APIs der Anwendungen. ber diese Nachrichtenkanle werden Prozeduraufrufe und Datenbergaben an eine oder mehrere Anwendungen weitergegeben. Der Message Broker stellt die Verbindung zwischen den Systemen her, speichert die Nachrichten zur asynchronen Kommunikation zwischen und konvertiert, wenn ntig, die Nachrichten in das Zielformat. Ein Message Broker ist ein spezielle Middlewareart. Zu den verbreitetsten Vertretern gehren IBM MQ Serie, Microsoft MQ, Tibco Rendevous.61 Eine weitere Mglichkeit der Integration von Applikationen besteht ber die Datenbankintegration, oder auch Datenintegration. Da den Kern vieler Anwendungssysteme eine zentrale Datenbank ausmacht, wird bei dieser Methode die Integration auf der Datenebene vollzogen. Dabei wird von den Anwendungssystemen, von den Datenbanksystemen oder von speziellen Tools Import/Export Routinen ausgefhrt und so die Datenbasis verschiedener Systeme abgeglichen. Zu Problemen bei dieser Methode kann es bei der Datenintegritt kommen. Ebenso ist Fachwissen aller beteiligten Anwendungen notwendig. Vielfach handelt es sich bei EAI Produkten um klassische Middleware Produkte, die um intelligente Konnektoren erweitert wurden. Allerdings versprechen Anbieter dieser Integratoren mit erweiterten Editoren und Tools eine schneller und unkomplizierten Integrationsprozess und eine wesentlich erleichterte Anpassung bei Releasewechsel der beteiligten Anwendungen. EAI ist meist notwendig, weil ein Anbieter von betriebswirtschaftlicher Standardsoftware mit ihren Produkten nicht alle Geschftsdimensionen eines Un-

- 48 -

ternehmens abbilden knnen. Ziel ist es immer, die Informations - Wertschpfungskette durch Kollaboration, Planung, Operation und Steuerung der Prozesse zu schlieen. Die Voraussetzung fr Electronic Business ist ein prozesszentrisches und kein ERP zentrisches Denken. Durch eine Integration von Anwendungen wird dieses erreicht, denn nicht nur interne Ablufe, sondern auch Kunden und Partner ber das Internet werden in den Geschftsablauf integriert. So wird die Wertschpfungskette durch die Beseitigung von Brchen und berschneidungen in der Prozesskette geschlossen. Geschftsprozesse einfacher anpassen sowie Transaktionen durchgngig und automatisch verarbeiten zu knnen, sind Ziele, die beim Einsatz von EAI Produkten aufkommen. Allerdings ist es ein Trugschluss anzunehmen, dass komplexe Integrationsaufgaben durch ein Tool allein zulsen seien.62 Die Integration von Anwendungen ist ein beratungsintensives und hochkomplexes Gebiet. Wenig geeignet sind EAI Produkte insbesondere fr Individualsoftware oder Branchenlsungen. Der Grund liegt in der sehr speziellen Ausrichtung der Systeme. Es ist fr einen Anbieter von Integrationssoftware nicht mglich, fr alle verfgbaren Anwendungssysteme und Release geeignete Konnektoren zu entwickeln. Vielmehr wird es eine Konzentration auf echte Standardsysteme geben. Von enormer Bedeutung fr die Zukunft von EAI ist zudem die Verwendung der Extensible Markup Language (XML) in den Produkten. Dadurch ist eine Datenaustausch zwischen Systemen in standardisierter Form mglich.

61 62

Vgl. Informationweek 22/2000, S. 26 ff. Vgl. Informationweek 12/2000, S. 59 ff.

- 49 -

4 Allgemeiner Ansatz eines Konzeptes einer ITArchitektur fr das Directbanking

Eine neue Bank, die bei ihrer Neugrndung ihre Systeme homogen zusammenstellen kann, besitzt die besten Voraussetzungen, eine moderne, leistungsfhige Architektur aufzubauen. Allerdings haben Banken, die ihr Geschft bereits mehrere Jahre betreiben und den Schritt zum Directbanking gehen wollen, kaum die Mglichkeit, auf der grnen Wiese ihre Systemlandschaft aufzusetzen. Aufgrund der verschiedenen Ausgangspositionen dieser Banken, die ihre gewachsenen Architekturen zum Directbanking ausbauen, ist eine allgemeingltige Vorgehensweise zum Aufbau des Directbanking nicht auffindbar. Gerade im Hinblick auf die heterogene Systemlandschaft, die die Architektur einer Bank prgt, ist es sehr schwer, generelle Aussagen zu treffen, die ohne Bercksichtigung der jeweiligen Situation bernommen werden knnten. Fr eine neu zubildende Architektur einer in Grndung befindlichen Bank sind diese Aussagen ebenfalls relevant. Durch die Ausprgung von Schichten und Stufen in einer Architektur sind verschiedene Anstze mglich, die sich in einer Directbanking Architektur verwendet werden knnen. Nachfolgend sind Erweiterungen der allgemeinen Schichten- und Stufenmodelle dargestellt, die die Entwicklung einer Architektur fr das Directbanking erleichtern sollen.

4.1 Erweiterung des Schichtenmodells

Grundstzlich lassen sich Direktbank Architekturen, wie die meisten Client/Server Architekturen, auf das allgemeine Schichtenmodell aus Abbildung 5 (rechte Seite) abstrahieren. Die vier Schichten sind in den folgenden Abstzen kurz dargestellt.

- 50 -

4.1.1 Die Prsentationsschicht

Die Teile des Systems, die der Kunde bzw. Benutzer bedient, sind in der Prsentationsschicht zusammengefasst. Dazu sind die Applikationen zu zhlen, die auf den Frontends laufen und den Zugriff auf das System erst ermglichen. Zu den Aufgaben dieser Schicht gehren Annahme und berprfung der Nutzereingaben, Bildschirmaufbau, Ausgabe der bermittelten Daten und Ereignissteuerung, soweit diese Ereignisse das Frontend betreffen.63

4.1.2 Die Steuerungsschicht

Speziell fr Directbanking Anstze ist es sinnvoll, die Steuerungsschicht und die Schicht der Business Objects zu unterteilen, wie in Abbildung 13 schematisch dargestellt.

Abbildung 13: erweitertes Schichtenmodell fr Directbanking.64

Wie in Abbildung 13 ersichtlich, kann die Steuerungsschicht in die Schichten der Zugangssicherung, der Verteilung der Anfragen und der Integration von

63 64

Vgl. Plenum Institut, Michael Bauer. eigene Darstellung.

- 51 -

Backendsystemen aufgespalten werden. Dadurch wird eine Struktur erkenntlich, die speziell fr das Directbanking notwendig ist. Die Schicht der Zugangssicherung stellt sicher, dass nur diejenigen Benutzer eine Zugang zu dem System erhalten, die auch dazu berechtigt sind. Neben Kunden einer Bank, sind das gewerbliche Nutzer und Administratoren der Bank. Dies ist notwendig, weil keine Sicherung der Prsentationsschicht, im weltweiten Netzen, z.B. im Internet, mglich ist und sich ansonsten jeder Benutzer Zugang verschaffen kann. Konzepte der Zugangskontrolle, wie sie in lokalen Firmennetzwerken installiert sind, ist fr das Internet nicht anwendbar. Vielmehr mssen alternative Zugriffskontrollen in die Frontends integriert werden. Heute blich in der Bankenpraxis ist einer Authentifizierung mit PIN/TAN. Allerdings ist damit zu rechnen, dass mit Verabschieden der neuen Richtlinien der Digitalen Signatur des Bundesamtes fr Sicherheit in der Informationstechnik die PIN/TAN Zugangskontrolle durch die digitale Signatur in Form von Smartcards oder in anderer Weise verdrngt wird. In der Schicht der Verteilung der Requests, werden Anfragen an die zustndigen verarbeitenden Systeme weitergeleitet und dafr gesorgt, dass die beteiligte Clients ihre erwarteten Antworten bekommen. Eine Verteilung von Anfragen ist auch aus Grnden der Performance und zur Lastverteilung auf mehrere Integrationsserver oder parallele Verarbeitungssysteme ntig. Diese Anforderung stellt sicher, dass auch bei hohen Kundenzahlen jeder Benutzer des Systems mit respektablen Wartezeiten bedient werden kann. Somit ist die Leistungsfhigkeit einer Directbanking Architektur wesentlich von der Leistungsgrenze der verteilenden und verarbeitenden Middleware abhngig. Applicationserver, eine im Abschnitt 3.3.2.1 dargestellte Art von Middleware, bernehmen die Aufgaben der Verteilung und Steuerung der Anfragen. Im Hinblick auf Ausfallsicherheit und Datensicherheit ist es auch erforderlich, mehrere verarbeitenden Systeme zu bedienen, denn Daten, die beispielsweise von mehreren Datenbanken zusammengesucht werden mssen, sind deutlich

- 52 -

sicherer abgelegt, als Daten die aus einer einzigen Datenbank abgerufen werden knnen. Zur Integration der verarbeitenden Coresysteme und Altsystemen, zur Einbindung von Fremdsystemen und zur Anbindung von Datenbanksystemen sorgt die Schicht der Integration. Sie besteht meist aus einer Sammlung von Konnektoren und Schnittstellen, die in einem Middlewareprodukt enthalten sind. Alternativ kann ein Integration Server eingesetzt werden, um die Anforderungen der Integration zu erfllen. Im Bankengeschft ist sowohl synchrone, wie auch asynchrone Kommunikation mit externen Systemen notwendig. So mssen z.B. synchron Brseninformationen fr Directbrokerage stndig eingeholt werden. Asynchrone Kommunikation ist vor allem mit der Landeszentralbank notwendig, ohne die kein Bankgeschft mglich ist. Jeweils einmal am Tag wird eine sogenannte DTA Datei von der Landeszentralbank empfangen und auch wieder eines geschickt. In dieser Datei sind alle institutsbergreifenden Buchungen, wie zum Beispiel berweisungen an eine andere Bank, enthalten. Die Landeszentralbank verteilt diese Daten am folgenden Tag an die entsprechenden Empfnger. Je mehr Aufgaben eine Bank an andere Institute outsourced, desto hher sind die Anforderungen an die Integration. Die Integration interner und externen Systeme ist somit eine wesentliche Aufgabe einer Direktbank Architektur. Wie im Abschnitt 3.3.4 dargestellt, existieren mehrere Anstze der Integration von Systemen im Rahmen des Enterprise Application Integration. Fr das Directbanking sind mehrere Lsungen denkbar. Allerdings ist der Ansatz der klassischen Middleware mit Erweiterung durch Konnektoren ausreichend, um den Betrieb zu ermglichen. Die Basis dafr stellt die Leistungsfhigkeit des Coresystems dar. Soweit dieses die Anforderungen von Directbanking, mit hoher Anzahl von Transaktionen und Benutzern in der Massenverarbeitung, gerecht wird, kann es weiterhin als zentrales System zum Einsatz kommen. Ein Beispiel einer solchen Lsung wird bei der BMW Bank GmbH eingesetzt. Im Abschnitt 5.1 wird diese kurz dargestellt.

- 53 -

Eine weitergehende Mglichkeit besteht in der Einfhrung eines zentralen, leistungsfhigen Integrationsservers, der die Integrationsintelligenz beinhaltet und die Prozesse aktiv steuert. Bei dieser Form werden die Prozesse des Directbankings, wie z.B. Abrufen Konteninformationen oder Einreichen von berweisungen, mit Hilfe des Integrationsservers neu definiert und im Repository des Servers abgelegt. Er steuert die Prozesse aktiv und bindet andere Systeme ein. Allerdings ist diese Form der Integration sehr komplex und bedarf genauem Wissen ber die integrierten Systeme.65 Durch Neudefinition der Prozesse und effiziente Einbindung von weiteren Systemen kann eine Entlastung des Coresystems herbeigefhrt werden. Damit wird nicht nur eine skalierbare Architektur geschaffen, die zuknftige Ausweitungen der Transaktions- und Kundenzahlen entgegenkommt, sondern auch eine Mglichkeit, einfach weitere Systeme zu integrieren. Zu beachten ist allerdings, dass weiterhin smtliche finanzwirtschaftlichen Berechnungen auf dem Coresystem stattfinden und dieses dafr ausgebaut werden muss. Eine visionre Aussicht ist im letzten Abschnitt beschrieben und soll als Weiterentwicklung dieses Ansatzes verstanden werden. Neben den speziellen Aufgaben die in der Steuerungsschicht wahrgenommen werden, sind allgemeine Aufgaben zu lsen. Dazu zhlen Fenstersteuerung, Controlleraufgaben, Steuerung zwischen verschiedenen Business Objects, sowie die Vorgangssteuerung.66

65 66

Vgl. JARDiX Integrationsuite, White Paper, S. 7 f. Vgl. Plenum Institut, Michael Bauer.

- 54 -

4.1.3 Die Schicht der Business Objects

Allgemein ist in der Schicht der Business Objects die betriebswirtschaftliche, bzw. hier speziell die finanzwirtschaftliche, Funktionalitt hinterlegt. Sie lsst sich in zwei Teile gliedern, die Directbanking Funktionen und die betriebswirtschaftliche Funktionen im Bankencoresystem. Eine Trennung ist notwendig, um wie es ein Schichtenmodell verspricht, unabhngig von anderen Schichten Dienste anbieten und die Implementierung der Schicht austauschen zu knnen. So kann je nach Bedarf eine moderne Directbanking Applikation integriert werden, die spteren Anforderungen, z.B. an neue Frontends, gerecht wird. Die Applikation des Directbankings nimmt Funktionen auf, die notwendig sind, um die Transaktionen der Benutzer aufzunehmen und zu berprfen. Ebenso werden Benutzerdaten verwaltet und Konteninformationen zur Verfgung gestellt. Es werden hier nicht direkt finanzwirtschaftliche Verarbeitungen durchgefhrt, aber es wird dafr gesorgt, dass nur korrekte Daten innerhalb von Transaktionen an das Coresystem bertragen werden. Sie stellt somit eine Vorstufe zu den eigentlichen Berechnung dar. In der Schicht des Bankencoresystems ist vielmehr Funktionalitt hinterlegt, die zum Betrieb einer Bank notwendig ist. Hier werden finanzwirtschaftliche Berechnungen durchgefhrt, notwendige Kundenbelege erzeugt und Datenaustausch mit anderen Institutionen vorbereitet. Das Coresystem ist bei einem Ausbau einer Filialbank zur Direktbank schon seit einiger Zeit in Betrieb und ist somit das Herz der Architektur. Ohne das System wre eine Bank nicht arbeitsfhig.

4.1.4 Die Datenverwaltungsschicht

Die Objektorientierte Methodik, die in den Business Objects Einzug gehalten hat, lsst sich noch nicht in der Datenhaltung wiederfinden. Die Datenbanksysteme arbeiten meist relational, wodurch ein Methodikbruch entsteht. Die Schicht der Datenverwaltung somit meist dadurch gekennzeichnet, diesen

- 55 -

Bruch zu berbrcken. Eine andere Aufgabe besteht in der Sicherung der Datenkonsistenz und integritt, wodurch die syntaktische Datenqualitt erhalten wird.

4.2 Erweiterung des Stufenmodells

Neben einer Betrachtung des Schichtenmodell kann auch eine Erweiterung des allgemeinen Stufenmodells erfolgen, wie in Abbildung 14 visualisiert.

Abbildung 14: erweitertes Stufenmodell fr Directbanking67

Dabei spielt wiederum die Unterscheidung in Frontend, Middleware und Backend eine zentrale Rolle. Zum Frontend zhlen alle Endgerte, an denen Kunden und andere Benutzer Zugang zu dem System finden. Eine Verarbeitung findet hier nur in dem Sinne statt, dass Benutzereingaben aufgenommen und berprft werden. Zur Middleware zhlen Application- und Integrationsserver. Die Middleware ermglicht es, in der Architektur heterogene Elemente zu integrieren und ein virtuelles System entstehen zu lassen. Im Rahmen der Applicationserver wird Funktionalitt implementiert, die laufzeitkritisch ist. Auerdem die Verarbeitung auf mehrere Applicationserver und Backendsysteme verteilt, um eine gezielte und gleichmige Verarbeitungslast zu erreichen. Der Server des Bankingcoresystem ist bei einer Architektur einer Bank das Herz der Verarbeitung. Hier laufen alle Transaktion auf, die durch die Benutzer

67

eigene Darstellung.

- 56 -

an den Endgerten erzeugt wurden. Auerdem finden hier die betriebswirtschaftlichen Berechnungen statt, es wird die Kommunikation mit anderen Systeme vorbereitet und die Dokumente fr die Kunden der Bank erzeugt. Der Datenbankserver ist die Wissensbasis der Bank. Er speichert alle relevanten Daten der Benutzer, Transaktionen und andere Informationen. Im Rahmen von aufwendigen Backupstrategien ist das Datenmaterial zu sichern und nach gesetzlichen Vorschriften zum Teil mehrere Jahre aufzubewahren.

4.3 Teile einer IT-Architektur fr das Directbanking

Zusammenfassend aus den Abschnitten 4.1 und 4.2, sowie in Anlehnung an die im Abschnitt 3.1 dargestellte Stufenarchitektur, lsst sich eine IT-Architektur entwickeln, wie in der Abbildung 15 dargestellt.

Abbildung 15: allgemeine Electronic Commerce/Directbanking Architektur68

68

Darstellung nach Computerwoche 24/2000, S. 58.

- 57 -

Es lsst sich erkennen, dass eine Architektur fr das Directbanking Geschft aus mehreren Teilen besteht. Sie sind nachfolgend in die Kategorien Frontend, Middleware und Backend eingeteilt.

4.3.1 Frontends
Im klassischen Electronic Commerce, wie z.B. einem Onlineshop, wird den Kunden meist nur der Zugang ber das Internet bereitgestellt. Im Directbanking, das auch zum Electronic Commerce gehrt, sind allerdings weitere Zugangswege (Frontends) sinnvoll. Neben einem Callcenter, welches Anrufe, Faxe, Electronic Mail und Briefe der Kunden entgegennimmt und verarbeitet, ist ein Kommunikationsweg ber das Wireless Application Protocol (WAP) denkbar. Allerdings ist zu berdenken, ob ein Frontends fr die Zielgruppen, zum Beispiel Privat- oder Geschftskunden (z.B. Hndler der BMW Bank), geeignet ist anzubieten. Eine entsprechende Auswahl ist darausfolgend abzuleiten. Weitere Frontends wren z.B. Selbstbedienungs Terminals , Short Message Service (SMS) oder Settop Boxen. Fr eine Direktbank ist es fraglich, ob es ntig ist, Terminals aufzustellen. Dadurch wrde das Konzept einer Directbank durchbrochen, das laut Definition, ohne Filialen und dementsprechenden Terminals auszukommen will. Im Abschnitt 1.3 ist dies kurz erlutert. Wenn eine breitere Kundengruppe allerdings zentriert lokal auftritt, kann es Sinn machen, diesen den Zugang zu Bankgeschften durch das Aufstellen dieser Terminals zu erleichtern. Ein Beispiel ist bei der BMW Bank aufzufinden. Viele Mitarbeiter der BMW AG sind auch Kunden der BMW Bank. Als Konsequenz werden in naher Zukunft besagte SB-Terminals an stark frequentierte Orten in den Fertigungssttten aufgestellt. Die Kommunikation ber SMS ist nur fr private Kunden sinnvoll. Es bietet dem Kunden allerdings die Mglichkeit, auf einfache asynchrone Weise, Konteninformationen abzurufen. Das Auslsen von Transaktionen ber SMS ist

- 58 -

aufgrund der fehlenden Grundlage der digitalen Signatur noch nicht durchfhrbar. Vernderungen sind zu erwarten, wenn die gesetzlichen Grundlagen verabschiedet sind. Ein Zugang ber Settop Boxen ist kein echter neuer Kommunikationsweg. Diese Endgerte werden Zugang zum Internet haben und mit einen Javakompatiblen Browser ausgestattet sein. Dementsprechend werden sie auch die Onlinebanking Applikation nutzen knnen. Wenn also bereits Onlinebanking verfgbar ist, knnen ohne groen Aufwand auch Settop Boxen bedient werden. Es existiert also eine berschaubare Anzahl von Frontends, die fr Electronic Commerce, oder speziell fr das Directbanking, zu nutzen sind. Dadurch wird die Eingliederung der Frontends in die Architektur auch recht einfach. Die standardisierten Schnittstellen sind in den meisten Middlewareprodukten integriert. Somit liegt das Hauptproblem einer IT Architektur nicht in diesem Bereich.

4.3.2 Middleware
Im Gegensatz zu den Frontends, ist die Beschreibung der Middleware ein komplexes Thema. Die Middleware als Ganzes ist im wesentlich auswechselbar, begrndet durch den schichtartigen Aufbau. Mit der Betrachtung der Middleware soll die Blackbox als Solche, die in den allgemeinen Architekturmodellen zu finden ist, durchleuchtet werden. Bei der Auswahl der Middlewareprodukte ist allerdings darauf zu achten, dass die Schnittstellen, die fr die Anbindung der Frontends notwendig sind, Bestandteil dieser Software ist. Wie in Abschnitt 3.3 dargestellt, gibt es mehrere Architekturen einer Middleware. Soll eine Middleware nicht nur zur Anbindung der Backendsysteme an das Internet genutzt werden, sondern als Kommunikations- und Softwarebus dienen, ist die Auswahl auch nach diesen Gesichtspunkten zu untersuchen. Fr eine offene Architektur, in der spter weitere Elemente integriert werden knnen, ist eine CORBA Basis zu whlen. Der groen Vorteile von CORBA lie-

- 59 -

gen vor allem in der programmiersprachenunabhngigen Implementierung. So knnen Objekte angesprochen werden, die in Java, C, Visual Basic oder einer anderen Sprache codiert sind. Die einzige Voraussetzung ist, dass das Objekt ber bestimmte, spezifizierte Schnittstellen angesprochen werden kann. Auf diesem Weg lassen sich Altsysteme und Backendsysteme als CORBA Objekte kapseln. CORBA wird bei Verwendung von Java im Frontendbereich internetfhig, so dass eine einfache Internetintegration mglich ist. Andere Mglichkeiten fr eine Basis einer Middleware sind COM/DCOM und EJB. Allerdings sind bei diesen Konzepten entscheidende Nachteile gegenber CORBA, die bei einer Auswahl KO Kriterium sein sollten. Das COM/DCOM Modell ist nur auf Windowsplattformen einsetzbar. Es existieren zwar seit kurzer Zeit Adapter und Gateways auf dem Markt, die eine Untersttzung von COM/DCOM auch auf anderen Plattformen, wie UNIX oder OS/400, ermglichen, aber sind diese Produkte nicht stabil und performant genug, um im tglichen Massengeschft einsetzbar zu sein.69 Der entscheidende Nachteil bei dem EJB Modell liegt in der Untersttzung von nur einer Programmiersprache. Somit mssten alle Applikationen in Java geschrieben werden. Da Java immer noch einen Performancerckstand hinter nativen Programmiersprachen hat, ist davon abzuraten, Java fr laufzeitkritische und hardwarenahe Applikationen einzusetzen. Wie bereits in Abschnitt 4.1.2 dargestellt sind zwei Integrationslsungen im Backendbereich sinnvoll. Notwendige Schnittstellen fr den Bereich sollten, soweit sie gngigen Standards entsprechen, auch integraler Bestandteil eines Middlewareproduktes sein. Zur Integration von speziellen, nicht ber standardisierte Schnittstellen erreichbaren Systemen, knnen Integrationsserver eingesetzt oder spezielle, eigene Erweiterungen der Middleware vorgenommen werden. Das grundlegende Problem einer Architekturlsung liegt also in der Einbindung der Backendsysteme.

69

Vgl. Plenum Institut, Michael Bauer.

- 60 -

4.3.3 Backendsysteme
Die heutigen Backendsysteme einer Bank, oder eines Unternehmens im Allgemeinen, lassen sich in drei Gruppen gliedern. Zum Einen kommen ERP Systeme, wie SAP, Baan oder Peoplesoft zum Einsatz. Das sind die Coresysteme, ber die fast die gesamte Verarbeitung abluft. In einer Bank ist das Coresystem kein ERP System im bekannten Rahmen. Vielmehr wird ein System, dass die finanzwirtschaftlichen Funktionalitt integriert hat, verwendet. In der BMW Bank kommt dafr das System Portfolio der Firma Lynx zum Einsatz. Das System wird als Standardsoftware auf dem Markt angeboten. Fr die BMW Bank sind allerdings viele spezielle Vernderungen implementiert worden, so dass es heute eher zwischen Individual- und Standardsoftware steht. Die zweite Gruppe sind Datenbanken und Data Warehouse Systeme, die zur Datenspeicherung und als Informationssysteme eingesetzt werden. Dazu zhlen Retrieval- und Data Mining Systeme, sowie Kundeninformationssysteme. Diese Systeme sind besonders ausfallsicher und mssen sicherstellen, dass die Datenbasis nicht verloren geht. In der BMW Bank werden fr das Banking zwei Datenbanken eingesetzt. Eine zentrale Datenbank dient dem Coresystem als Datenbasis und nimmt alle relevanten Daten fr den Betrieb des Banking auf. Eine zweite Datenbank dient als Zwischenspeicher fr Transaktionen im Onlinebanking und enthlt redundante Daten. Zweimal tglich wird diese Onlinebanking Datenbank mit der zentralen Datenbank abgeglichen. Systeme, die bereits seit einigen Jahren zum Einsatz kommen und in eine neue Architektur wieder eingebaut werden mssen, heien Legacy-Systeme. In diese Anwendungen ist traditionelle Funktionalitt enthalten, die unternehmenskritisch ist und nur so sehr schwierig ablsen lsst. In der BMW Bank kommt das Altsystem Unisys zum Einsatz. Modulweise wird das System allerdings durch Module des neuen Systems Portfolio verdrngt. Im Abschnitt 1.2 ist die Ist Situation der BMW Bank bereits beschrieben. Wie durch die drei Gruppen skizziert, existieren mehrere verschiedene Systeme im Backendbereich eines Unternehmens, bzw. einer Bank. Bei der Integration stellt sich nun bei jedem System die Frage, wie es an die Architektur ange-

- 61 -

schlossen werden kann. Es stellen sich somit einige kleine, statt ein groes Problem. Es ist nun fr jedes System zu prfen, ber welche Schnittstellen es verfgt. Sind standardisierte Schnittstellen vorhanden, sollte die Anbindung ber die Middleware bereits implementiert sein. Anderenfalls ist zu prfen, ob die Middleware spezielle Techniken vorsieht, eine Integrationskomponente zu entwickeln. Weitere Hilfe verspricht der Einsatz von Integrationsservern, die speziell fr die Einbindung von Systemen im Einsatz sind. Auch im Backendbereich sind Bemhungen im Gange, Schnittstellen zu standardisieren. So ist es blich, das Datenbanksysteme eine SQL Schnittstelle besitzen, ber die Daten abgerufen, bzw. Daten gespeichert werden knnen. Bestimmte Funktionalitt in ERP Systemen wird in Business Objects gekapselt und bietet API Schnittstellen zum Zugriff. Leider ist bei jedem ERPSystem eine andere Schnittstellenspezifikation implementiert, so dass an dieser Stelle noch weitere Standardisierung ntig sind. Die Integration von Legacysystemen ist immer ein separat zu lsendes Problem. Neben dem Einsatz von Integrationsservern ist auch eine Kapselung als ein Objekt im CORBA, bzw. in einem anderen Softwaremodell mglich. Dieser Ansatz ist bereits in den Abschnitten 3.3.3.1 und 4.3.2 kurz dargestellt.

- 62 -

5 Ist-Situation der Architektur der BMW Bank GmbH

5.1 Onlinebanking Architektur Ist-Situation

Die Architektur der BMW Bank ist in vielen Jahren gewachsen und besteht aus mehreren Systemen, die jeweils fr bestimmte Aufgaben zustndig sind. Es ist also eine typische Architektur, wie sie in einer Bank vorkommt, die ihre Systeme fr das Directbanking ausbaut. Ein berblick ber das Geschftsabwicklungssystem ist bereits im Abschnitt 1.2 gegeben. Die Anwendung des Onlinebankings ist auf dem Coresystem aufgesetzt. Die Abbildung 16 verdeutlicht die Erweiterung.

Abbildung 16: Anbindung der Geschftsabwicklungssysteme an das Internet70

70

eigene Darstellung.

- 63 -

Um Kunden die Eingabe von Transaktionen und das Abrufen von Informationen zu ermglichen, werden in der Onlinebanking Datenbank die dazu bentigten Daten abgelegt, bzw. fr den Kunden bereitgehalten. Als Middleware wird Brokat Twister eingesetzt. Twister verfgt ber optionale Schnittstellenmodule, ber die bei Bedarf Client- und Serversysteme bedient werden knnen. Die Abbildung 17 stellt das schematisch dar.

Abbildung 17: Brokat Twister Software-Bus71 Die sogenannten Gateways ermglichen die Einbindung von Frontends in das Twister System. Fr das Directbanking besonders wichtige Vertreter sind:72 ? ? Xpresso Gateway (verschlsselte proprietre Schnittstelle) ? ? HTML Gateway ? ? SMS Gateway ? ? WAP Gateway ? ? TCP/IP Gateway.

71 72

Darstellung nach BROKAT Twister Manual - Twister 2.3 Core with Services. Vgl. BROKAT Twister 4.0 Technical Whitepaper, S. 16 ff.

- 64 -

Zur Anbindung und Integration von Backendsystemen werden sogenannte Accessoren eingesetzt. Fr Directbanking sind:73 ? ? SQL Accessor ? ? XML Accessor ? ? SMS Accessor ? ? Kordoba74 Accessor besonders interessant. Die Onlinebanking Anwendung besteht aus zwei getrennten Teilen. Zum Einen ein Java Applet, das ber das Extranet erreichbar ist, und ein Java Servlet, dass die serverseitige Verarbeitung bernimmt. Beide Teile wurden ebenfalls von Brokat entwickelt. Diese ist eine individuelle Entwicklung fr die BMW Bank, die allerdings von einem standardisierten Produkt abgeleitet und erweitert wurde. Die serverseitige Anwendung besteht wiederum aus zwei Teilen, die eigentliche Onlinebanking Applikation und die PIN/TAN Verwaltung. Bisher ist die Onlinebanking-Software im Extranet durch die Hndler der BMW AG und fr die Administratoren der BMW Bank zugnglich. Die PIN/TAN Verwaltung ist aus Sicherheitsgrnden nur im Intranet erreichbar. Zur Aufnahme der Benutzerdaten und zur Verwaltung dieser steht eine eigene Datenbank zur Verfgung. Diese Online Datenbank speichert auch die Transaktionen und hat die Umstze und Salden der Konten hinterlegt. Das Datenmodell ist ebenfalls von Brokat modelliert. Es kann in ein StandardDatenmodell und in ein BMW spezifisches Datenmodell gegliedert werden. Es wurde auch fr die Bedrfnisse der BMW Bank angepasst.

73 74

Vgl. Ebenda, S. 20 ff. Kordoba ist ein weitverbreitetes System von Siemens zur Abwicklung von Banktransaktionen.

- 65 -

Datenaustausch zwischen dem Coresystem (Bankfolio) und dem Onlinebanking System erfolgt ber MT940 und DTA Dateien, sowie ber SQL Skripts. Es erfolgt also keine synchrone Kommunikation und keine Realtime Verarbeitung. Zum Datenaustausch wird zweimal tglich eine MT940 Datei in das Onlinebanking System eingespielt. Damit werden die Kontoauszge aktualisiert. Einmal tglich werden Daten aus dem System der Hndlerfinanzierung eingespielt, Kontenlimits- und Bankleitzahlenupdates gefahren und DTA Dateien, sowie PIN und TAN Dateien erzeugt. Kontoauszge werden einmal monatlich in Papierform erzeugt und an die Kunden verschickt. Es findet also eine aktionsunabhngige Kommunikation statt, die zu bestimmten Zeitpunkten durchgefhrt wird. Somit ist auch keine synchrone Kommunikation im Onlinebereich mglich. Das Onlinebanking System ist nur im Extra- und Intranet, sowie fr das Callcenter zugnglich. Es existiert ein genau definierter, manueller Prozess des Freischaltens eines Hndlers fr das Extranet. Somit entstehen immer zustzliche administrative Aufwnde fr das manuelle Anlegen der Konten und Zugriffsvoraussetzungen. Ebenso werden bisher Antrge nur in Papierform bearbeitet. Trotz des Angebotes von Tages- und Festgeldkonten, sowie Kreditkarten, haben Privatkunden noch keinen Zugriff auf das System. Ihre Bankgeschfte sind einzig ber das Callcenter oder in Papierform durchfhrbar.

5.2 Standardisierungsprozess bei dem Onlinebanking System

Mit dem Ziel der Ablsung der Filetransfers (MT940 und DTA) durch direkten Zugriff auf die Datenbank von Bankfolio strebt die BMW Bank einer Vereinfachung des Datenaustausches an. Da somit einige der BMW spezifischen Tabellen im Online Datenmodell berflssig werden, geht man einen Schritt zur Standardisierung der Onlinebanking Software. Es wird die redundante Datenhaltung in der Datenbank des Bankfolio Systems und in der Datenbank des Onlinebanking Systems reduziert. Gleichzeitig kann mit einer qualitativ

- 66 -

hheren Supportuntersttzung von Brokat gerechnet werden, da fr den standardisierten Teil der Anwendung ein greres Supportteam ihre Erfahrungen zur Lsung von Problemen einbringen kann. Weiterhin ist mit einer besseren Massendatenverarbeitung zu rechnen. Der Grund liegt in dem Wegfall von Teilen des redundanten Datenbestandes und der Dateibertragung. Es ist ein wirkungsvoller Schritt in Richtung einer Realtime Verarbeitung im Onlinebanking.

5.3 ffnen der Extranet Lsung fr das Internet

Ein weiteres kurzfristiges Ziel der BMW Bank besteht in der ffnung der Extranet Banking Anwendung fr das Internet. Gerade im Hinblick auf das Geschft im Directbanking ist es sehr sinnvoll, den Kunden eine weitere Zugriffsmglichkeit fr ihre Geschfte zu geben. Nahezu jede Direktbank verfgt ber diese Zugriffsmglichkeit. Ebenso wird eine einheitliche Anwendung entwickelt, von der aus Kunden, Hndler, Niederlassungen und Administratoren auf das System zugreifen knnen. Zur Zeit existiert neben der Onlinebanking Software die zum Coresystem zugehrigen Clients. Diese werden unter anderem im Callcenter eingesetzt. Das Ziel ist also eine einheitliche Zugriffsmglichkeit fr alle Kunden, Hndler, Niederlassungen, Callcenter und Mitarbeiter zu schaffen den Wartungsaufwand der Clients zu reduzieren. Durch die ffnung wird mit einer sehr viel hheren Kunden- und Transaktionszahl zu rechnen sein, wodurch das System einer strkeren Belastung ausgesetzt wird. Eine stufenweise Skalierung der verarbeitenden Systeme wird eine notwendige Konsequenz sein. Um den Ansprchen der Kunden gerecht zu werden, ist ebenso eine Vernderung in den Erfassungsprozessen anzustreben. Eine manuelle Erfassung ist bei einer Grenordung von mehreren zehntau-

- 67 -

send Kunden nicht mehr sinnvoll durchzufhren. Vielmehr muss eine papierlose Antragsverarbeitung in das Onlineangebot integriert werden. Im Rahmen der ffnung fr das Internet und der Entwicklung einer einheitlichen Zugriffsoberflche im Internet/Extranet und Intranet, ist ein Umbau der Middlewaresysteme unausweichlich. Es wird eine strkere Betonung der 3-tierArchitektur, also eine strikte Teilung in Frontends, Middleware und Backend, angestrebt. Mit der stufenweisen Ablsung des Altsystems durch moderne Module fr das Portfolio System, werden zuknftigen Anforderungen an das System eingeplant. Durch konsequentes Reengineering soll im Backendbereich ein effizientes Prozessing entwickelt werden. Aufgrund der Tatsache, das jegliche Kommunikation zwischen den Frontends und den Backendsystemen, sowie zwischen den Backendsystemen selbst, ber die zentrale Middleware laufen soll, ist zuknftig darauf zu achten, dass alle bentigten Schnittstellen in der Middleware integriert werden. Momentan werden bereits eine Vielzahl von Schnittstellen und Protokollen zur Kommunikation bentigt.75 Viele der Schnittstellen sind Standards und werden in Middlewareprodukten angeboten. Allerdings wird bei der Einbindung von speziellen Systemen immer eine Eigenentwicklung im Schnittstellenbereich notwendig sein.

75

Unter anderem sind momentan folgende Schnittstellen in Verwendung: IIOP (Onlinebanking), CGI (Netscape), ODBC/JDBC (scriptgesteuertes Datenmanipulation, Administrationstools), RMI (Java), DTA (Unisys), MQ (IBM), MT940 (Onlinebanking).

- 68 -

6 Vision der prozessgesteuerten Kommunikation

Die in den vorangegangenen Abschnitten vorgestellten Umstrukturierungsarbeiten und Neuerungen sind bereits wirkungsvolle Schritte, um eine zukunftsgerechte und ausbaufhige Architektur zu schaffen. Allerdings wird mit diesen Schritten keine Vernderung der sehr starken Belastung im Backendbereich stattfinden. Die konsequente Weiterentwicklung des Gedanken aus dem Abschnitt 5.3, alle Kommunikation ber einen Middlewarebus zu leiten, mndet in einer strkeren Betonung und im Aufbau einer leistungsfhigen Middleware und dadurch der Entlastung der Geschftabwicklungssysteme im Backendbereich. Bisher wurden Transaktionen in eine redundante Datenbasis eingefgt und mittels asynchroner Kommunikation dem Coresystem bergeben. Anschlieend wurde Tausende von Transaktion im Batchbetrieb verbucht. Dadurch kam es regelmig zu sehr starker Belastung, die auch zu Behinderungen im tglichen Betrieb wurden. Eine zweckmige Lsung dieses Problems bietet die prozessgesteuerte Kommunikation ber eine steuernde Middleware. Dabei werden Transaktionen, die im Onlinebanking durch die Kunden erfasst werden, an einen Applicationserver zur weiteren Verarbeitung bergeben. Dieser Server steht somit zwischen der Onlineerfassung und der Verarbeitung durch die Backendsysteme. Durch das Erfassen der Transaktion wird ein Prozess im Applicationserver gestartet, der die Transaktion prft und im Geschftsabwicklungssystem verbucht. Es wird also eine Kommunikation zwischen dem Prozess und der Backendsystem fr jede Transaktion synchron durchgefhrt. Der entscheidende Unterschied zwischen der Verarbeitungsvariante im Batchbetrieb und prozessgesteuerten Verarbeitung liegt in der aktiven Steuerung und Kontrolle des Prozesses durch den Applicationserver. Es wird ein Teil der Verarbeitungslast der Geschftsabwicklungssysteme dadurch abgenommen. Hierzu ist es notwendig,

- 69 -

die bentigten Prozesse zentral neu zu definieren und in einem Repository abzulegen. Im Hinblick auf die stark heterogene Systemlandschaft, die in Banken vorzufinden ist, und der oben beschriebenen Notwendigkeit zur Integration von Backend- und externen Systemen in die Architektur einer Bank ist im Rahmen der prozessgesteuerten Kommunikation ein Applicationserver einzusetzen, der gleichzeitig auch Hilfestellung bei der Integration von den unterschiedlichen Systemen bietet. Im Abschnitt 3.3.4 ist im Rahmen des Enterprise Application Integration bereits diese Art der Middleware beschrieben. Es sollte ein leistungsfhiger Integrationsserver gewhlt werden, der die prozessgesteuerte Integration untersttzt und somit nachhaltig die Geschftsabwicklungssysteme entlastet.

- 70 -

Glossar
2-PhaseCommit Protokoll zur Synchronisation eines gemeinsamen Transaktionsendes zwischen transaktionssteuernden Systemen (DBMS, TP Monitor, ORB, Messageing System u.a.). Application Programming Interface (Anwendungsprogrammschnittstelle). Formal definierte Schnittstelle, ber die Anwendungsprogramme Systemdienste (Netz, Betriebssystem, DBMS, Window Manager u..) oder Dienstleistungen anderer Anwendungsprogramme aufrufen knnen. Java-Programm als plattformenunabhngigen Byte Code, das mittels HTML ber das Netz versandt wird. Es ist unabhngig vom Zielsystem und wird unter Kontrolle einer Java Virtual Machine (JVM) ausgefhrt. Es unterliegt Sicherheitsrestriktionen. (sogenannte Sandbox-Prinzip ). Software, die die Verarbeitung serverseitig steuert. Ein Application Server verbindet die Eigenschaften von WebVerarbeitung, ORB und Transaktionsmanagement und untersttzen meist Enterprise Java Beans (EJB). Bekannte Produkte sind z.B. Oracle Application Server, Websphere Application Server, Netdynamics, Weblogic Application Server Inprise Application Server. Rechnerunabhngiger Zwischencode, der aus Java Code erzeugt wird. Er wird von einem Java Laufzeitsystem (Java Virtual Machine) interpretativ abgearbeitet oder von einem Just in Time Compiler bersetzt. Der Byte Code eignet sich besonders fr Programme, die ber das Netz verschickt werden sollen (Java Applet). Common Gateway Interface. Standardisierte Schnittstelle eines Web Servers zur Aktivierung von Programmen. Diese erhalten die vom Web Browser bertragenen Parameter und liefern Web Seiten zurck. (siehe auch:

API

Applet

Application Server

Byte Code

CGI

- 71 -

ISAPI, NSAPI) COM Component Object Model. Technologie von Microsoft zum Zusammenspiel von Anwendungskomponenten unter Windows. Common Object Request Broker Architecture. Definition der OMG fr einheitliche Schnittstellen und Funktionen eines Object Request Brokers. Mit dem Standard CORBA 2 ist auch die rechnerbergreifende Interaktion zwischen unterschiedelichen ORBs definiert. (siehe: IIOP Protokoll). Architektur, in der ein Server seine Dienste vielen Clients ber ein API zur Verfgung stellt. Ursprnglich eine reine Hardware Architektur im LAN, in der die Festplatte eines Datei Servers allen Workstations im Netz als virtuelle Platte zur Verfgung gestellt wurde. Sukzessive entwickelte sich hieraus eine Software Architektur fr verteilte Systeme. Hierbei luft ein substantieller Teil einer Anwendung auf Arbeitsplatzrechnern ab, der Anwendungsdienste auf anderen Rechnern in Anspruch nimmt. Diese umfassen z.B. Datenbank-Funktionen, Mail- und Druckservices oder Verarbeitungsfunktionalitt (Applicationserver). Distributed Component Object Model. Technologie von Microsoft fr verteilte Komponenten.

CORBA

Client/Server

DCOM

Data Warehou- Ein Konzept zur Informationsbereitstellung fr dispositive se Anwendungen und IDV. Es umfasst Aufbau und Design einer Informationsbasis, Aktualisierung und Transformation der bentigten Daten aus operativen Datenbestnden oder externen Quellen und Bereitstellung von Informationen mittels Report, eines Executive Information System oder adhoc Anfragen. Downsizing Downsizing ist die Absicht, durch Verlagerung der Verarbeitung auf kleinere (kostengnstigere) Rechner einen

- 72 -

Nutzen zu gewinnen. Downsizing beinhaltet nicht automatisch eine Client/Server-Architektur; vielfach handelt es sich nur darum, bestehende Terminal-Anwendungen auf einen anderen Rechner (z.B. AS/400, UNIX Rechner) zu portieren. Einer berfhrung bestehender Anwendungen in eine Client/Server Architektur steht meist die monolithische Struktur der alten Anwendungen im Wege. Embedded SQL SQL Anweisungen, die mit der Einleitungsklausel EXEC SQL in ein Programm in einer beliebigen Programmiersprache verwendet werden. Da der Compiler der jeweiligen Programmiersprache diese Anweisungen nicht bersetzen kann, mssen sie zunchst von einem Precompiler in einen Call umgewandelt werden. Das Format des Calls und das darber angesprochene Interface-Programm ist DBMS spezifisch. Eine Firewall ist eine Kombination aus Hard- und Software, die als bergang zwischen einem als sicher angesehenen Netzwerk und der Auenwelt (z.B. dem Internet) dient. Die Kommunikation wird ber die Firewall gefhrt, um an dieser Stelle verschiedene Kontroll- und Auditmglichkeiten anzuwenden. Generalisierte Funktionalitt, die fr Anwendungen viele Funktionen abnehmen, so dass die Programme nur noch fr individuelle Ergnzungen geschrieben werden mssen. Beispiele: Dialogsteuerung, transaktionsorientierte Kommunikation zwischen PC und Host, Bereitstellung und Versorgung von Daten (persistency framework). Graphical User Interface. Unter GUI im allgemeinen Sinne wird die Benutzerschnittstelle bei hochauflsenden graphischen Bildschirmen verstanden. Voraussetzung ist ein Window Manager wie z.B. Windows, OS/2Presentation Manager oder OSF/Motif. Der Gegensatz ist CUI (Character User Interface), das auf einem Bildschirmformat mit festen Stellen (z.B. 24x80 Zeichen) und fester Zeichengren beruht. Unter GUI im engeren Sinne wird

Firewall

Framework

GUI

- 73 -

die Gestaltung und Interaktion entsprechend den Konventionen von CUA '89 verstanden. Gateway Funktionen, die die Konventionen einer Schnittstelle in die einer anderen berfhrt. Gateways gibt es z.B. fr Datenbanken, um einem Programm, das fr ein bestimmtes DBMS eingerichtet ist, den Zugriff auf ein anderes DBMS zu ermglichen, ohne dass an dem Programm nderungen vorgenommen werden mssen. Allerdings kann ein Gateway meist nur die technischen, aber nicht die funktionalen Differenzen zwischen den DB Systemen ausgleichen. Interface Definition Language. Beschreibungssprache fr die Schnittstelle der Client- und Server-Komponenten fr den RPC Compiler oder ORB. Internet Inter ORB Protokoll. Von der OMG standardisiertes Protokoll zur Kommunikation zwischen verteilten Object Request Brokern. Wird besonders wichtig bei verteilten Anwendungen im Internet, da es von Firewalls verstanden wird. Internet Server API. Schnittstelle des Internet Information Server von Microsoft, um Anwendungsprogramme, die in Form von DLLs vorliegen, zu aktivieren. ISAPI ersetzt CGI. Java Data Base Connectivity. Zugriffsschicht fr JavaProgramme, um SQL Befehle unabhngig von bestimmten DB-Systemen nutzen zu knnen. Pendant zu ODBC. Interpreter, der Programme erst vor ihrer Ausfhrung auf dem Zielsystem bersetzt. Autonomer Softwarebaustein, der ber standardisierte Schnittstellen verfgt, dass er mit anderen zu einer Anwendung zusammengebaut werden kann.

IDL

IIOP

ISAPI

JDBC

Just in TimeInterpreter Komponente

Message Queu- Start einer asynchronen Verarbeitung mit bergabe einer

- 74 -

Queueing

Nachricht. Die Nachricht wird in einer Warteschlange (Message Queue) zwischengespeichert. Generalisiertes Datenbank Gateway von Microsoft, das den Konventionen der SQL Access Group entspricht. Es wandelt SQL Anweisungen im Call Level Format in die spezifischen Formate verschiedener DB-Systeme um. Wird zunehmend durch OLE-DB ersetzt. Zugriffsschicht von Microsoft, um einen universellen Zugang zu allen Datenhaltungssystemen (RDBMS, Dateisysteme, Mails) zu schaffen. Untersttzt unstrukturierte Datenformate. Online Transaction Processing. Betriebsform von Anwendungen, bei denen viele Benutzer konkurrierend gemeinsame Datenbestnde bearbeiten knnen. Die Reservierung, Freigabe und Wiederherstellung von Daten erfolgt auf Basis von Transaktionen, die entweder vollstndig oder gar nicht abgewickelt sein drfen. Die Transaktionssicherheit wird blicherweise durch ein OLTP fhiges Datenbanksystem oder einen TP Monitor gewhrleistet. Object Management Group. Vereinigung, die sich die Standardisierung im Bereich der Objektorientierung zum Ziel gesetzt hat. Erstes Ergebnis ist die Definition einheitlicher Schnittstellen fr einen Object Request Broker.

ODBC

OLE-DB

OLTP

OMG

Object Request Steuerungssoftware, die Nachrichtenkommunikation von Broker einem Objekt an ein anderes bernimmt. Dadurch mssen die Objekte nicht mehr die Speicheradressen und Programmiersprachen das Zielobjektes kennen. Der Object Request Broker (ORB) sollte Nachrichten sowohl innerhalb eines Adressraumes als auch rechnerbergreifend versenden knnen. Die Definition einer einheitlichen Aufrufschnittstelle und Funktionalitt erfolgte durch CORBA von der OMG.

- 75 -

RDBMS

Relational Data Base Management System. Ein DBMS, das den Anforderungen des Relationenmodells von Dr. Codd entspricht. In der Praxis versteht man heute hierunter ein DBMS, das die Sprache SQL versteht. Remote Method Invocation. Javaklassen, die eine RPC Funktionalitt bieten. Dadurch knnen Javaklassen ohne besondere Schnittstellendefinition rechnerbergreifend kommunizieren. RMI verwendet IIOP als Protocoll. Remote Procedure Call. Mechanismus zur Programm Kommunikation ber Rechner. Ein RPC arbeitet nach dem Prinzip des Unterprogrammaufrufs. Er erfordert keine nderungen im Programm gegenber einem rechnerinternen Unterprogrammaufruf, da das jeweilige Partnerprogramm durch einen Stub ersetzt wird, der seinerseits das RPC Laufzeitsystem zum Transport der Parameter zwischen den Programmen aktiviert. Java Programm, das in einen Web Server eingebettet werden kann. Transaction Processing Monitor. Steuerprogramm zur transaktionsorientierten Verarbeitung auf einem Server. Ein TP Monitor umfasst Funktionen fr dynamisches Laden von Programmen, Ressource Kontrolle, Zwischenspeicherung, Datenverwaltung, Datenbank Anschluss und Inter Programm Kommunikation. Der Einsatz eines TP Monitors erhht den Durchsatz auf einem Server Rechner.

RMI

RPC

Servlet

TP-Monitor

Web Applicati- Eine Steuersoftware, die angekoppelt an einen Web Server eine Dialogverarbeitung ermglicht. onserver Web Server Software zur Bereitstellung von HTML Seiten und Interaktionen mit einem Web-Browser. Bekannte Produkte sind: Apache, Enterprise Server (Netscape), Internet Information Server (Microsoft), Go Web Server (IBM).

- 76 -

Quellenverzeichnis

Literatur

BODENDORF, F.: Wirtschaftsinformatik im Dienstleistungsbereich, Berlin, 1999. BROKAT TWISTER MANUAL - TWISTER 2.3 CORE WITH SERVICES, 1998. BROKAT TWISTER MANUAL - TWISTER 2.3 APPLICATION DEVELOPMENT, 1999. BROKAT TWISTER 4.0 TECHNICAL WHITEPAPER, STAND 15.02.2000. BULLINGER, H.-J. (HRSG.): Software-Architekturen im Unternehmen, Berlin, 1991. BUNDESAMT FR SICHERHEIT IN DER INFORMATIONSTECHNIK, Internetangebot www.bsi.bund.de, 2000. BUXMANN, P.: Standardisierung betrieblicher Informationssysteme, Wiesbaden, 1996. BMW BANK, Internetangebot, http://www.bmwbank.de, Stand Juli 2000. GUTSCHMIDT, M.: Ein Objektmodell fr ein integriertes Management von Systemdiensten mit Client/Server-Struktur, Mnchen, 1995. HANSEN, H. R.: Wirtschaftsinformatik I, Stuttgart, 1998. HANSEN, W.-R. (Hrsg.): Client-Server-Architektur, Bonn, 1994. HANTUSCH, T.; MATZKE, B., PEREZ, M.: SAP R/3 im Internet, Bonn, 1997. JARDIX INTEGRATION SUITE - WHITE PAPER, STAND 14.08.2000.

- 77 -

KARER, A.; MLLER, B.: Client/Server Technologie in der Unternehmenspraxis, Berlin, 1994. KELLER, A.: CORBA-basiertes Enterprise Management: Interoperabilitt und Managementinstrumentierung verteilter kooperativer Managementsysteme in heterogener Umgebung, Mnchen, 1999. KRCMAR, H.: Client-Server-Architekturen: Herausforderung an das Informationsmanagement, Hallbergmoos, 1993. KUPPINGER, M.: Internet- und Intranet - Sicherheit, Unterschleiheim, 1998. LANG, W.: Entwurf und Architektur betrieblicher Client/Server-

Anwendungssysteme, Berlin, 1997. MERCEDES BENZ LEASE FINANCE, Internetangebot http://www.mblf.de, Stand Juli 2000. NIEMANN, K.D.: Client/Server Architektur, Braunschweig, 1995. STERLE, H. (HRSG.): Integrierte Standardsoftware: Bd. 2 Auswahl, Einfhrung und Betrieb von Standardsoftware, Mnchen, 1990. STERLE, H.; RIEHM, R.; VOGLER, P.: Middleware Grundlagen, Produkte und Anwendungsbeispiele fr die Integration heterogene Welten, Braunschweig, 1996. OPELBANK, Internetangebot http://www.opelbank.de, Stand Juli 2000. PABRAI, U. I.: Internet & TCP/IP network security : security protocols and applications, New York, 1996. PLENUM INSTITUT; BAUER, M.: Technologie-Update fr IT-Fhrungskrfte, Wiesbaden, 2000. PORSCHE FINANCIAL SERVICES, Internetangebot http://www.porsche.de/financial, Stand Juli 2000. REARC - eArchitecting - White Paper, Stand: 02.08.2000.

- 78 -

REICH, CH.: Strategien bei der Entwicklung von Middleware fr moderne Netze, 2000, unverffentlicht. SILESCU, D.: Was bieten Direktbanken?, Mnchen, 1997. STATISTISCHES BUNDESAMT DEUTSCHLAND, Internetangebot www.statistikbund.de, 2000. TELLER, J.; RIEDINGER, M.: Anforderungen an moderne Bankanwendungen fr das Kundengeschft, Mnchen, 1997. TELTSCHIK, H.: Unternehmenskultur - Eine Standortbestimmung aus internehmerischer Sicht, Rede vom 15.05.2000. WELTER, H.: Heterogene Netze - Einfhrung in Standardarchitekturen, Protokolle, Verwaltung und Sicherheit, Mnchen, 1993. VOLKSWAGEN BANK, Internetangebot http://www.vw-bankdirect.de, Stand Juli 2000. VOLKSWAGEN LEASING, Internetangebot http://www.volkswagenleasing.de, Stand Juli 2000.

Zeitschriften

COMPUTERWOCHE 43/1993, Client-Server: DV-Chefs ndern ihre Strategien. COMPUTERWOCHE 24/2000, S. 57-74, Middleware. COMPUTERWOCHE SPEZIAL Heft 3/2000. COMPUTERWOCHE 30/2000, S. 9-57, EAI.

INFORMATIONWEEK 19/1999, Messaging: Gute Verbindungen frdern das Geschft. INFORMATIONWEEK 10/2000, Middleware: Kommunikation ohne Grenzen.

- 79 -

INFORMATIONWEEK 11/2000, Middleware: IT-Welten in Verbindung. INFORMATIONWEEK 12/2000, Middleware: Kein E-Commerce ohne ITIntegration. INFORMATIONWEEK 22/2000, Integration ist Chefsache.
IT

MANAGEMENT, Oktober 1997. Seite 17.

IX 15/2000,

Erklrung
Ich versichere hiermit, dass ich meine Diplomhausarbeit Entwicklung einer IT - Architektur fr das Directbanking selbstndig und ohne fremde Hilfe angefertigt habe, und dass ich alle von anderen Autoren wrtlich bernommenen Stellen wie auch die sich an die Gedankengnge anderer Autoren eng anlegenden Ausfhrungen meiner Arbeit besonders gekennzeichnet und alle Quellen zitiert habe.

Halle, 01.12.2000 Denny Reeh