Diplomarbeit. Nutzung von Open Source für Integrationslösungen. in der Finanz- und Investmentbranche. Verwaltungs- und Wirtschafts-Akademie

Transkript

1 Verwaltungs- und Wirtschafts-Akademie Berufsbegleitender Studiengang zum Informatik-Betriebswirt (VWA) Diplomarbeit Nutzung von Open Source für Integrationslösungen in der Finanz- und Investmentbranche Betreuer: Sebastian Rohr Autor: Nico Richter Matrikelnummer: Anschrift: Abgabetermin:

2 Quellenhinweise Bei der großen Zahl von Quellen unterschiedlichster Art, die für diese Arbeit genutzt wurden, ist die wissenschaftliche Kurzzitierweise vereinheitlicht und etwas erweitert dargestellt. Es gibt in diesem Dokument nur drei unterschiedliche Zitierweisen: solche, die auf externe Quellen verweisen; vgl. [Autor], [Titel], [Erscheinungsjahr/Datum], [ggf. Seitenzahl], solche, die auf Inhalte innerhalb der Dokumentes verweisen; vgl. [Art des Abschnitts] [Nummer und Bezeichnung] und solche die auf Gesetzes- oder gesetzesähnliche Texte verweisen, wie BGB und die GNU GPL bspw.; vgl. 123 Abs. 1 BGB. Das dürfte die Nachvollziehbarkeit und Verweise auf das Literaturverzeichnis deutlich erleichtern. Eine Untergliederung des Literaturverzeichnisses in die verschiedenen Kategorien wie selbstständigen Veröffentlichungen, Hochschulschriften, Beiträgen in Sammelwerken, Zeitschriften und sonstigen Quellen wurde nicht vorgenommen. Alle Quellen sind alphabetisch geordnet und soweit möglich nach dem einheitlichen Schema aufgelistet: Nachname des Verfassers / der Verfasser oder Kurzbezeichnung der Organisation (ausgenommen bei Gesetzestexten), Titel der Quelle, Auflage oder Art und Version des Dokuments oder Internetadresse (mit Datum und Uhrzeit des Zugriffs), Herausgeber (unter Angabe des Sitzes der Organisation), Jahr oder bei Dokumenten und Internetquellen das vollständige Datum der letzten Änderung, evtl. zusätzliche Informationen wie ISBN. II

3 Inhaltsverzeichnis Abkürzungsverzeichnis... V Abbildungsverzeichnis... VIII Tabellenverzeichnis... VIII 1. Einleitung Motivation für den Einsatz von Open Source Software Entwicklung der Softwaretechnologie Komponentenmodelle Was ist Open Source Software? Ziele beim Einsatz von Open Source Software Open Source Software in der Finanz- und Investmentbranche Kostensenkung Unabhängigkeit von Herstellern proprietärer Software Unabhängigkeit von Releasezyklen Technisches Umfeld Analyse der Integrationslösung EAI Beschreibung der Systemlandschaft Datenintegration Prozessintegration Workflow-Steuerung (Prozessunterstützung) Architektur mit offenen Standards Java 2 Platform, Enterprise Edition (J2EE) Java Connector Architecture Specification (JCA) Java Business Integration (JBI) ServiceMix JBoss JBI-Implementierung bei der Union Investment BusinessWare-Implementierung bei der Union Investment Lastverteilung und Skalierbarkeit Hardware Beschaffung Anpassung an kundenspezifische Anforderungen SWOT-Analyse Vitria BusinessWare Open Source Software mit offenen Standards III

4 3.8 Bewertung der Analyse von Open Source mit offenen Standards Rechtliche Aspekte Lizenzierung von Open Source GNU General Public License v3 (GPL) GNU General Public License v3 im Detail GNU Lesser General Public Licence v3 (LGPL) BSD Lizenzen Apache Lizenz Wichtigste Unterschiede der Open-Source-Lizenzen Zusammenhang von Open Source Software und Urheberrecht Urheberrecht Patentrecht Vertragsrecht Gewährleistung und Haftung Basel II und MaRisk Technisch-organisatorische Ausstattung Notfallkonzepte Fazit der rechtlichen Aspekte Wirtschaftliche Betrachtung Gründe für den Einsatz von Open Source Software Total Cost of Ownership Betriebskosten Entwicklungskosten Business Case und Rentabilität Schlussbetrachtung Literaturverzeichnis... IX Beigefügte Quellen... XV Eidesstattliche Erklärung... XVII IV

5 Abkürzungsverzeichnis Abkürzung AuslInvestmG BGB BaFin BPI BPEL4WS BPM BSD CICS CORBA CRM EAI EDA EIS EJB ESB GNU GPL GNU LGPL HTML HTTP InvG IRIS J2EE Bedeutung Auslandinvestment-Gesetz (AuslInvestmG) Bürgerliches Gesetzbuch Bundesanstalt für Finanzdienstleistungsaufsicht Business Process Integration Business Process Execution Language for Web Services Business Process Management Berkeley Software Distribution Customer Information Control System Common Object Request Broker Architecture Customer Relationship Management Enterprise Application Integration Event Driven Architecture Enterprise Information System Enterprise JavaBeans Enterprise Service Bus General Public License des GNU Projektes Lesser General Public License des GNU Projektes Hypertext Markup Language Hypertext Transfer Protocol Investmentgesetz Internes Richtliniensystem der Union Investment Gruppe Java 2 Platform, Enterprise Edition V

6 JBI JCA JCP JEMS JMS JPDL JSR JTA JVM KAG KAGG KOS MaRisk MDA MDB MPL MQ OCR ORB OSS PatG ProdHaftG RDBMS SLSB SOA Java Business Integration J2EE Connector Architecture Java Community Process JBoss Enterprise Middleware Suite Java Message Service jbpm Process Definition Language Java Specification Request Java Transaction API Java Virtual Machine Kapitalanlagegesellschaft Kapitalanlagegesellschaften Konsolidierung Online Systeme Mindestanforderungen an das Risikomanagement Model Driven Architecture Message Driven Beans Mozilla Public License Message Queuing Optical Character Recognition Object Request Broker Open Source Software Patentgesetz Produkthaftungsgesetz Relational Database Management System Stateless Session Beans Serviceorientierte Architektur VI

7 SOAP SWIFT TCO TCP UML UrhG VM XML XSLT ZfA Simple Object Access Protocol Society for Worldwide Interbank Financial Telecommunication Total Cost of Ownership Transmission Control Protocol Unified Modeling Language Urheberrechtsgesetz Virtual Machine Extensible Markup Language XSL Transformation Zentrale Zulagenstelle für Altersvermögen VII

8 Abbildungsverzeichnis Abbildung 1 - Replikation mit BusinessWare... 9 Abbildung 2 - Services mit BusinessWare Abbildung 3 - Prozessunterstützung mit BusinessWare Abbildung 4 - Replikation mit offenen Standards Abbildung 5 - Services mit offenen Standards Abbildung 6 - Prozessunterstützung mit offenen Standards Abbildung 7 - Apache ServiceMix Abbildung 8 - Architektur der JBI Implementierung Abbildung 10 - Architektur der BusinessWare Implementierung Abbildung 11 - JBoss Clustering Beispielszenario Tabellenverzeichnis Tabelle 1 - SWOT-Analyse - Vitria BusinessWare Tabelle 2 - SWOT-Analyse - Open Source Software mit offenen Standards Tabelle 3 - Übersicht der wichtigsten Unterschiede der Open-Source-Lizenzen.. 37 VIII

9 1. Einleitung Open Source Software hat in den letzten Jahren eine immer größere Bedeutung gewonnen. Dies geschah nicht zuletzt durch die Entwicklung verbindlicher, so genannter offener Standards. Mittlerweile treten immer häufiger Open-Source- Lösungen in Konkurrenz zu konventionellen Lösungen. In dieser Arbeit soll die Eignung einer Integrationslösung für geschäftskritische Bereiche bei der Kapitalanlagegesellschaft Union Investment untersucht werden, die auf Open Source Software und offenen Standards basiert. Hierzu wird zunächst ein Überblick über die Entwicklung der Softwaretechnologie und den Möglichkeiten von Open Source Software gegeben, bevor die unternehmensinternen Anwendungsgebiete der Integrationslösung beschrieben werden. Daraufhin wird untersucht, inwieweit die vormals genutzte kommerzielle Lösung und die aktuell eingesetzte Open-Source-Lösung die unternehmensinternen Anforderungen erfüllen. Neben den speziellen rechtlichen Aspekten, die allgemein beim Einsatz von Open Source Software gelten, gibt es in der Finanz- und Investmentbranche besondere Regelungen, die beim Einsatz von Software zu berücksichtigen sind, unabhängig davon ob es sich um eine kommerzielle oder Open-Source-Lösung handelt. In der wirtschaftlichen Betrachtung wird auf den monetären Nutzen eingegangen, bevor in der Schlussbetrachtung die Frage beantwortet werden kann, ob die Nutzung von Open Source für diesen geschäftskritischen Bereich zweckmäßig ist. 2. Motivation für den Einsatz von Open Source Software In diesem Kapitel soll zunächst auf allgemein formulierter Ebene betrachtet werden, mit welcher Motivation Open Source Software in der Wirtschaft und Industrie eingesetzt wird. Zum besseren Verständnis wird zuvor ein kurzer historischer Überblick der Entwicklung der Softwaretechnologie aufgezeigt, beginnend in den 1970er Jahren bis hin zu den heute existierenden Integrationslösungen, bevor auf die Ziele beim Einsatz von Open Source Software eingegangen wird. 2.1 Entwicklung der Softwaretechnologie In den 1970er Jahren entstanden zahlreiche moderne Programmiersprachen, wie Cobol oder C, die zum Teil heute noch verwendet werden. Diese werden als zustandswechselorientierte oder prozedurale Konzepte bezeichnet. Damals entstand 1

10 bereits die objektorientierte Programmierung, in der Daten-, Prozedur- und Referenzaspekte in einem Konzept des Objekts vereinigt werden. Dieses Konzept fand mit der Programmiersprache C++ Mitte der 1980er seine Verbreitung. Weiterführend wurde eine Vereinigung beider Ansätze mit Java und C# verfolgt. Java verhalf dabei der objektorientierten Programmierung zum endgültigen Durchbruch. und etablierte sich mit Java 2 Platform, Enterprise Edition (J2EE) als offener und plattformunabhängiger Standard. Durch die Ausbreitung des Internets in den 1990er Jahren entstanden Auszeichungssprachen wie Hypertext Markup Language (HTML) oder Extensible Markup Language (XML) und zahlreiche Scriptsprachen, die auch serverseitig eingesetzt wurden 1. Durch verteilte Systeme wie dem Internet ist die Kommunikation unabhängiger Teilnehmer untereinander möglich. Doch nicht erst durch ein solches Netzwerk entsteht ein verteiltes System. Auch eine verteilte Anwendung mit der Menge all ihrer Prozesse, die untereinander kommunizieren, stellt ein solches System dar Komponentenmodelle Mit zunehmender Komplexität der Softwaretechnologie und dem steigenden Bedarf für verteilte Anwendungen entstanden Komponentenmodelle. Die zu definierenden Komponenten bestimmen meist die Softwarearchitektur. Die Common Object Request Broker Architecture (CORBA) ist eine hersteller- und sprachenunabhängige Spezifikation für eine objektorientierte Middleware, deren Kern der sog. Objekt-Broker (auch Objekt Request Broker, ORB) bildet. Zusammen mit den Protokoll- und Dienstspezifikationen ermöglichen CORBA-konforme Implementierungen, dass heterogene Anwendungen über deren Komponenten als Schnittstellen miteinander kommunizieren können. Die meisten CORBA- Implementierungen basieren auf Java und C++. Die mit Java und C# mitgelieferten Bibliotheken beinhalten dabei vieles, was ursprünglich als CORBA-Service definiert wurde 3. So existieren mittlerweile neben der Java Plattform mit der J2EE 1 vgl. Wikipedia.org, Geschichte der Programmiersprachen, vgl. Wikipedia.org, Verteiltes System, 2007 & Masroor, Middleware Teil 1, vgl. Wikipedia.org, CORBA,

11 Architektur und deren zahlreichen Komponenten 4 sowie die.net Plattform von Microsoft 5. Mittels dieser Modelle lassen sich serviceorientierte Architekturen (SOA) aufbauen. Mit einer SOA sollen fachliche Prozesse abgebildet werden, bei denen die einzelnen Schritte als atomare Services existieren. Die Infrastruktur orientiert sich dabei an den Geschäftsprozessen, die durch Orchestrierung (logische Aneinanderreihung) der einzelnen Services abgebildet werden. Die Services lassen sich somit in den unterschiedlichen Geschäftprozessen mehrfach verwenden. Eine SOA stellt dabei mehr ein Managementkonzept dar. Die Services werden meist als sog. Web Services implementiert, deren Kommunikation über internetbasierte Protokolle wie Hypertext Transfer Protocol (HTTP) oder Transmission Control Protocol (TCP) abgewickelt wird. Die Daten (Schnittstellen) der Services werden als XML-Artefakte über das Protokoll als Nachrichten ausgetauscht, welche das Simple Object Access Protocol (SOAP) bilden. Web Services können in Integrationslösungen wie EAI verwendet werden 6. Mit einer EAI-Lösung können unternehmensinterne, aber auch externe Geschäftsfunktionen mit unterschiedlichen heterogenen Anwendungen und Plattformen verbunden werden. Dabei werden die Methoden der Datenintegration, Anwendungsintegration und Prozessintegration angewendet. Die Geschäftsfunktionen der Anwendungen werden dabei nicht verändert, sondern mit Hilfe von Adaptern weiter abstrahiert (gekapselt) und über einen sog. Business Bus bzw. Enterprise Service Bus (ESB) miteinander verbunden. Dabei werden die Funktionen als lose gekoppelte Services über ein Regelwerk zu der relevanten Geschäftslogik (Prozess) verbunden. Durch die Kapselung der inhaltlich komplexen Funktionen werden die auszutauschenden Nachrichten weniger komplex. Diese stellen die wesentlichen Unterschiede zu reinen Schnittstellenadaptionen klassischer Middleware dar 7. EAI-Lösungen werden von Herstellern proprietärer (kommerzieller) Software angeboten, wie z.b. IBM, BEA oder Vitria. Daneben existieren auch Open-Source-Lösungen, wie ServiceMix von Apache, Java Enterprise Service Bus von Celtix oder MULE von MuleSource/CodeHaus. 4 vgl. Wikipedia.org, J2EE, vgl. Wikipedia.org,.NET, vgl. Wikipedia.org, Serviceorientierte Architektur, 2007 & Wikipedia.org, SOAP, 2007 & Wikipedia.org, Web Service, vgl. Wikipedia.org, Enterprise Application Integration,

12 2.1.2 Was ist Open Source Software? Der Begriff freie Software entstand erst Mitte der 1980er Jahre und wurde vor allem durch die Free Software Foundation geprägt, die u. a. Herausgeber der GNU General Public License (GPL) und GNU Lesser General Public License (LGPL) ist. Die Bezeichnung Open Source Software (OSS) selbst gibt es erst seit 1998, durch Gründung der Open Source Initiative und Veröffentlichung des Quellcodes des Netscape Browsers. Bei OSS wird die Frage der Nutzung auf den Anwender übertragen, die es ihm freistellt, Software nutzen, kopieren, verteilen, studieren, ändern und weiterentwickeln zu können. Man spricht vom sog. Copyleft 8. Im Unterschied zu proprietärer Software werden diese Nutzungsrechte explizit eingeräumt. Ein wesentliches Merkmal von OSS ist die kostenlose Lizenzierung und der freie Zugang zum Quellcode. Hierbei haben sich Subkategorien herausgebildet: Copyleft, beschränktes Copyleft und Non-Copyleft 9. Copyleft besagt, dass bei Weitergabe einer Software unabhängig von etwaigen Änderungen die freie und uneingeschränkte Nutzung unter der ursprünglichen Lizenz weiter bestehen muss. Die bekannteste Lizenz ist die GNU GPL. Beschränktes Copyleft orientiert sich am Copyleft, beinhaltet jedoch nicht alle Regelungen dieser Lizenzen. Beispiele sind die GNU LGPL und die Mozilla Public License (MPL). Bei Non-Copyleft-Lizenzen bestehen nicht alle Rechte des Copylefts. So ist es nicht erforderlich bei Weitergabe der Software für veränderte Teile die ursprüngliche Lizenz zu erhalten. Zu nennen sind hierbei die BSD Lizenz und Apache Lizenz 10. Neben OSS gibt es weitere Formen kostenloser und frei zugänglicher Software. Zu unterscheiden ist die Public Domain Software, Freeware, Shareware. Public Domain Software unterliegt keinem Copyright, der Quellcode ist aber nicht zwingend zugänglich. Freeware unterliegt einem Copyright und darf anderes als OSS oder Public Domain Software nicht beliebig genutzt werden. Die zunächst kostenlose Shareware zeichnet sicht durch funktionelle oder zeitliche Nutzungseinschränkungen aus. Die volle Nutzbarkeit von Shareware ist gegen eine Lizenzgebühr möglich. Diesen Formen kostenloser Software steht proprietäre Software 8 vgl. Kap. 4.1 Lizenzierung von Open Source 9 vgl. Jaeger, Open Source Software, 2006, S. 1 ff. 10 vgl. Wikipedia.org, Copyleft,

13 gegenüber, die von Unternehmen mit der Absicht erstellt wird, primär aus den Lizenzeinnahmen Gewinne zu erzielen. Die Nutzung der Software wird durch den Hersteller bestimmt, Änderungen sind sogar untersagt und der Quellcode ist nicht zugänglich Ziele beim Einsatz von Open Source Software Heute gewinnt OSS zunehmen an Bedeutung. Insbesondere bei der Nutzung im gewerblichen Umfeld bieten sich mittlerweile brauchbare Lösungen. Beispiele aus öffentlichen Institutionen zeigen sogar, dass vollständige Migrationen auf OSSbasierten Lösungen stattfinden 12. OSS hat nicht das Ziel, primäre Einnahmen durch Lizenzgebühren zu generieren. Vielmehr werden neue Absatzmöglichkeiten für die sekundären Dienstleistungen in den Vordergrund gerückt, um die nachgelagerten Leistungen wie Support vermarkten zu können. In vielen Einsatzbereichen von Software dominieren weiterhin proprietäre Lösungen, was nicht zuletzt daran liegt, dass es keine vergleichbar ausgereiften OSS- Produkte gibt. Dies soll darauf hinweisen, dass nicht einfach in jedem denkbaren Bereich OSS eingesetzt werden kann, sondern vielmehr die Nutzung von OSS von zahlreichen individuellen Bedingungen abhängig ist, die jeweils betrachtet werden müssen Open Source Software in der Finanz- und Investmentbranche In der vorliegenden Arbeit soll anhand der eingesetzten Integrationslösung EAI der Union Investment die Nutzung von OSS in der Finanz- und Investmentbranche untersucht werden. Es werden dabei sowohl die technischen und wirtschaftlichen Ziele des Unternehmens, als auch die rechtlichen Rahmenbedingungen betrachtet, die sich durch eine solche Nutzung ergeben Kostensenkung Eine Kostensenkung beim Einsatz von Software kann im Wesentlichen in zwei Bereichen erzielt werden. Dies sind zum einen die Hardwareanforderungen, das 11 vgl. Renner, Open Source Software - Einsatzpotentiale und Wirtschaftlichkeit, 2005, S vgl. Stadt München, vgl. Renner, Open Source Software - Einsatzpotentiale und Wirtschaftlichkeit, 2005, S. 10 f. 5

14 Betriebssystem selbst, systemnahe Software wie Serveranwendungen und zum anderen die Weiterentwicklung der Benutzersoftware. Im betrieblichen Umfeld sind im Allgemeinen bei einer Änderung der IT- Strategie oder für die Migration auf eine andere Software die Kosten für den Wechsel auf die neuen Serversysteme zu berücksichtigen. Diese umfassen die installierten Server, Betriebssysteme und Applikationsserver (systemnahe Software). Eine veränderte Infrastruktur kann sich positiv auf die laufenden Betriebskosten auswirken. Wartungs- und Lizenzkosten eines Herstellers entfallen bei der Nutzung von OSS vollständig oder können auf reine Wartungsaufwendungen reduziert werden, die unternehmensintern oder durch externe Dienstleister erbracht werden. Bei der Union Investment wurde bisher die EAI-Lösung BusinessWare von Vitria verwendet. Für BusinessWare ist Spezialistenwissen erforderlich, welches wenig verbreitet ist. Im Vergleich zu einer OSS-Lösung, können die Kosten für die Weiterentwicklung insbesondere dann gesenkt werden, wenn die Software offene Standards verwendet. Durch das allgemein besser verfügbare Wissen zu den offenen Standards ist eine kostengünstigere Beschaffung am Markt möglich. Zudem lassen sich Problemlösungen bei diesen Standards aufgrund des verbreiteten Wissens leichter implementieren. Bei einer Migration auf eine andere Lösung ist ein Eigenanteil für die Entwicklung zu berücksichtigen, um die Software auf die spezifischen Prozesse des Unternehmens anzupassen. Die Anpassung einer Software ist gerade bei Open Source ohne weiteres möglich, da der Quellcode frei zur Verfügung steht und bei etablierten Lösungen dokumentiert ist. Zudem ist durch Entwicklergemeinschaften (Communities) eine breite Unterstützung vorhanden. In den Entwicklergemeinschaften wird offen das Wissen zur gegenseitigen Problemlösung ausgetauscht Unabhängigkeit von Herstellern proprietärer Software Die Software BusinessWare dient als Basis für die eingesetzte Integrationslösung bei der Union Investment. Dabei werden viele individuell erstellte Adaptionen eingesetzt, um die fachlichen Prozesse bedienen zu können. Die originären Lösungen, die BusinessWare zur Verfügung stellt, werden selten wiederverwendet. Der Hersteller Vitria hält sich dabei nicht an einen offenen Standard. Für die Anpassungen ist deshalb ein hohes Maß an Spezialwissen gefragt. Auftretende Prob- 6

15 leme können kurzfristig oft nur durch Umgehungslösungen (Workarounds) gemildert werden, da eine Fehlerbehebung durch den Hersteller zeitlich stark verzögert oder gar nicht erfolgt. Durch den Einsatz von OSS kann sich das Unternehmen Unabhängigkeit von einem Hersteller verschaffen. Aktuelle Probleme können zeitnah und fallabschließend beseitigt werden. Bei der Weiterentwicklung können Lösungen erstellt werden, die sich innerhalb eines Standards bewegen und auf die unternehmenseigenen Bedürfnisse ausgerichtet sind. Lösungen zu Problemen sind für offene Standards durch etablierte Entwicklergemeinschaften meist leichter und schneller verfügbar als durch die Hersteller von proprietärer Software Unabhängigkeit von Releasezyklen Die meisten kommerziellen Hersteller haben feste Releasezyklen für ihre Weiterentwicklungen, die von den Kunden mitgeführt werden müssen, um sich vor allem weitere Unterstützungs- und Wartungsleistungen zu sichern. Bei der Union Investment sind im Verlauf der Zeit viele Eigenentwicklungen der EAI-Lösung umgesetzt worden, um vor allem den fachlichen Anforderungen gerecht zu werden. Für die Anforderungen wurden neue Komponenten ergänzt, die auf zentrale Basiskomponenten zugreifen. Dafür wurden aber auch die Basiskomponenten selbst verändert. Folglich sind die individuellen Erweiterungen eng mit der Basis der Software verknüpft. Ein Versionswechsel generiert somit kaum Vorteile für die weitere Nutzung der Software oder deren Einsatzfeldern. Vielmehr werden bei umfangreichen Releases (Major-Releases) viele Ressourcen gebunden, welche dann nicht für erforderliche fachliche Erweiterungen zur Verfügung stehen. Durch Unabhängigkeit von vorgegebenen Releasezyklen können Ressourcen und letztlich Kosten eingespart werden. Releases und deren Zyklen können selbst definiert und zu den passenden Zeitpunkten für das Unternehmen und damit planbar durchgeführt werden. 3. Technisches Umfeld Im Jahr 2000 hatte die Union Investment begonnen, eine Integrationslösung einzuführen. Damals wurde die EAI-Lösung BusinessWare von Vitria ausgewählt. Nachdem in den letzten Jahren offene Standards wie J2EE und OSS-Lösungen eine bedeutsame Reife erlangt haben, stellte sich die Frage, ob ein Wechsel der 7

16 proprietären Software auf eine OSS-Lösung möglich und sinnvoll ist. Dies musste im Vorfeld analysiert werden. 3.1 Analyse der Integrationslösung EAI Bei der Union Investment wird die EAI-Lösung für drei zentrale Anwendungsgebiete genutzt, die sich aus den bestehenden Anforderungen an die gesamte Systemlandschaft ergeben Beschreibung der Systemlandschaft Die Erbringung der Dienstleistung Depotverwaltung wird bei der Union Investment durch ein zentrales Großrechnersystem, als juristisch führendes Bestandssystem, unterstützt. Über die Integrationslösung EAI werden die Daten zahlreichen Anwendungen zur Verfügung gestellt. Änderungen aus den Anwendungen werden ebenfalls über EAI zurück an das Bestandssystem übermittelt. Die Anwendungen basieren dabei auf unterschiedlichen Technologien, hauptsächlich web- oder clientbasiert als Java- oder serverbasiert als Mainframe-Anwendungen. Es handelt sich hierbei u. a. um eine Callcenter-Anwendung, die von internen und externen Service-Einheiten für die Beauskunftung genutzt wird. Auch werden telefonische Aufträge für die Pflege von Bestandsdaten und Wertpapierorders bearbeitet. Endkunden und Banken können über ein jeweils eigenes webbasiertes Transaktionsportal Depotinformationen abrufen und Wertpapieraufträge aufgeben. Banken haben zusätzlich die Möglichkeit das Neukundengeschäft abzuwickeln. Über die verschiedenen Rechenzentralen im genossenschaftlichen Verbund werden weitere sechs Transaktionsportale bedient. In den so angebundenen Anwendungen werden über die Maskenflüsse die definierten Geschäftsprozesse abgebildet. In ähnliche Art und Weise werden ebenfalls die Aufträge aus dem Optical Character Recognition (OCR), ein Systeme zur Texterkennung, verarbeitet. Einige Anwendungen benötigen einen gewissen Teil der Daten im eigenen Datenbestand. Die Duplizierung der Daten, aus dem zentralen Großrechnersystem versorgt, findet auf Datenbankebene statt und wird zeitnah oder zeitgesteuert durchgeführt. Das betrifft vor allem die Callcenter-Anwendung. Weitere Prozesse führen Datenbestände zusammen, die für das Customer Relationship Management (CRM) inhaltlich konsolidiert werden müssen, da die einzelnen Attribute in verschiedenen Anwendungen vorliegen. 8

17 Für die Beschaffung von Fondsanteilen werden die Auftragsdaten an einen zentralen Anbieter und seiner Abwicklungsplattform übermittelt, der dann die Anteile von anderen Kapitalanlagegesellschaften ordert. Ähnliche Prozesse zum Datenaustausch bestehen auch für den einheitlichen Zahlungsverkehr im Finanzwesen und für die verschiedenen Meldungen an den Gesetzgeber Datenintegration Bei der Datenintegration werden Daten von Quellsystemen an Zielsysteme übertragen. Zum einen werden Daten unidirektional, direkt zwischen den Datenbanken übermittelt. Die Übertragung wird mit Triggermechanismen der Quelle angestoßen und anschließend zum Ziel übermittelt. Dabei werden in Abhängigkeit zu der betroffenen Anwendung, die Daten aus dem Quellesystem in das Zielsystem kopiert oder per destructiv Read (zerstörendes Lesen) verschoben. Das Verfahren destructiv Read wird z.b. bei der Übertragung von Datensätzen des zentralen Bestandssystems an das Callcenter-System angewendet. Zum anderen werden Daten asynchron bidirektional übermittelt. Im Fall der bidirektionalen Übertragung werden die Daten in Form von Nachrichten gesendet, auf die zu einem späteren Zeitpunkt (asynchron) die technische Antwort erfolgt. Die fachliche Zuordnung der Antwort zur ursprünglich gesendeten Nachricht, wird in nach gelagerten Prozessen des Quellsystems vorgenommen, was außerhalb der EAI-Lösung stattfindet. Dieses Verfahren wird z.b. bei der Übermittlung von Daten an externe Systeme wie der Zentralen Zulagenstelle für Altersvermögen (ZfA) angewendet. Dabei werden mit sog. Connectoren die Systeme miteinander verknüpft und deren Daten mittels Transformation übersetzt (Mapping). Vitria BusinessWare Source Connector Mapping(s) Target Connector Abbildung 1 - Replikation mit BusinessWare Quelle: Entory, Open Source 4 BPI, 2006 Häufig können dabei die vorgefertigten Lösungen der Software BusinessWare verwendet werden. Generell können die dafür gelieferten Modellierungswerkzeu- 9

18 ge jedoch selten genutzt werden, da sie sich im Vergleich zu anderen Werkzeugen im Arbeitseinsatz schlicht als unzureichend gezeigt haben. Zudem war bei der Anbindung an spezielle Systeme wie CICS (Customer Information Control System, Transaktionsserver für IBM Mainframe) oder SWIFT (Society for Worldwide Interbank Financial Telecommunication, auch als allgemeine Bezeichnung für den standardisierten Zahlungsverkehr zwischen Finanzinstituten verwendet) eine vollständige eigene Entwicklung erforderlich. Beim Anwendungsgebiet der Datenintegration kann allgemein auch von der sog. Hub and Spoke Architecture sprechen, welche unternehmensintern als Replikation bezeichnet wird Prozessintegration Mit der EAI-Lösung ist eine serviceorientierte Architektur umgesetzt. Die Aufrufe erfolgen über Webservices. Die Services sind atomar und über ein Regelwerk konfiguriert. Die einzelnen Aufrufe einer Geschäftslogik werden über HTTP oder Message Queuing (MQ) Adapter an komplexe Prozess-Services (Enterprise- Services) gerichtet. Diese werden innerhalb der EAI-Lösung an einzelne oder mehrere Basis-Services (Integration-Services) weiter verteilt, um z.b. Daten verschiedener Quellen abzufragen oder an verschiedene Ziele zu verteilen. Vitria BusinessWare MQ Service Adapter HTTP Service Adapter Dispatcher Order Service DE Service Depot Service Dispatcher CICS Service EAIDB Service TransDB Service CICS Connector RDBMS Connector RDBMS Connector Abbildung 2 - Services mit BusinessWare Quelle: Entory, Open Source 4 BPI, vgl. Union Investment, Import-Schnittstelle, 2003, S. 12 ff. 10

19 EAI-intern wird ein synchrones Request-Response-Verfahren angewendet. Das bedeutet, dass zu jeder Anfrage auch eine definierte Antwort geliefert wird. Für die Verteilung der ankommenden und internen Aufrufe sind Dispatcher zwischengeschaltet. Die systeminterne Kommunikation wird über eine ORB- Infrastruktur abgewickelt. Bei der Anbindung an die Quell- und Zielsysteme werden ebenfalls Connectoren verwendet. Die einzelnen Service-Modelle laufen innerhalb von BusinessWare jeweils in einer eigenen virtuellen Umgebung (virtual Machine, VM). Das erzeugt einen sehr hohen Verwaltungsaufwand des Systems, insbesondere wenn einzelne Prozesse der unterschiedlichen Service-Modelle untereinander kommunizieren 15. Auf diese Art können heterogene und verteilte Anwendungen prozessorientiert verknüpft werden. Mit der Verwendung einer EAI-Lösung als zusätzliche Service-Schicht werden Systeme und Prozesse voneinander entkoppelt, was sowohl die Abhängigkeiten als auch die Komplexität insgesamt reduziert. Durch die Strukturierung der Serviceebenen wird ein hohes Maß an Wiederverwendbarkeit geschaffen. Das ermöglicht eine wesentlich höhere Flexibilität bei der Adaption von Services für veränderte oder komplett neu abzubildende Geschäftsprozesse. Bei diesem Anwendungsgebiet wird allgemein auch von der sog. Business Process Integration (BPI) mittels SOA gesprochen, welche unternehmensintern als KOS-Services (Konsolidierung Online Systeme, Name eines Vorläuferprojektes) oder nur Services bezeichnet wird. Bei der eingesetzten Prozessintegration werden unterschiedliche Anwendungen (Benutzeroberflächen, Frontends) mit zentralen Backendprozessen über standardisierte Schnittstellen in Form von Services miteinander verbunden. Die EAI-Lösung selbst ist für die Anwendungen und das Backend transparent Workflow-Steuerung (Prozessunterstützung) Die EAI-Lösung unterstützt darüber hinaus einzelne Arbeitsschritte eines Geschäftsprozesses. Diese wird unternehmensintern als Prozessunterstützung bezeichnet. Dabei werden nicht ausschließlich Webservices verwendet. Bspw. werden bei der Anlage von Neukunden im Rahmen des Geschäftsprozesses einer Depoteröffnung 15 vgl. Union Investment, Technisches Feinkonzept für Konsolidierung Onlinesysteme KOS, 2004, S. 21 ff. 11

20 unterstützend alle Daten der einzelnen Erfassungsschritte gesammelt und auf die erforderlichen Mindestangaben fachlich geprüft. Die Zwischenergebnisse sind persistent und werden erst abschließend in den auftragsrelevanten Datenbanken gespeichert und die notwendigen Druckausgaben erzeugt. In einem weiteren unabhängigen Arbeitsschritt werden diese Daten an das bestandsführende System übermittelt. Dieser Auftragstransfer wird technisch mit ereignisgesteuerten Aktivitäten in EAI durchgeführt, welche ebenfalls persistent sind. Erst im bestandsführenden System wird der Gesamtprozess, unabhängig von Erfassung und Auftragstransfer in weiteren manuellen Schritten durch Mitarbeiter, abgeschlossen. Die Systeme sind ebenfalls über Connectoren von BusinessWare miteinander verbunden. Vitria BusinessWare Source Connector Stateful Process Model Target Connector BPO DB Abbildung 3 - Prozessunterstützung mit BusinessWare Quelle: Entory, Open Source 4 BPI, 2006 Auch hier ist wie bei der Prozessintegration der Nachteil zu nennen, dass ein hoher Verwaltungsaufwand des Systems existiert. Zudem sind die Anwendungsteile für die Prozessunterstützung äußerst komplex und erfordern einen hohen Aufwand, die unternehmensindividuellen Prozesse abzubilden. Die Prozessunterstützung bietet den Ansatz einer Workflow-Steuerung, jedoch bezieht sich dies nur auf die einzelnen Schritte eines Gesamtprozesses. Das entspricht nicht einer klassischen Workflow-Steuerung, die anwendungsübergreifend Arbeitsschritte eines Prozesses verknüpft und ergebnisabhängig steuert 16. Eine klare Abgrenzung zwischen den unterschiedlichen Kategorien einer Anwendungsintegration, der verwendeten Prozessintegration und Prozessunterstützung 16 vgl. Union Investment, Technisches Feinkonzept für Konsolidierung Onlinesysteme KOS, 2004, S. 20 ff. 12

21 ist schwer zu treffen. Vielmehr ist das individuelle Einsatzgebiet der Integrationslösung zu betrachten. Die Begriffsvielfalt und deren unterschiedliche Interpretationen werden besonders im Fall einer SOA deutlich. Dieses Konzept folgt keiner eindeutigen Definition oder Sprachregelung, so dass häufig gleiche Begriffe für unterschiedliche Kontexte verwendet werden 17. Vielmehr wird SOA aus unterschiedlichen Perspektiven unterschiedlich dargestellt und definiert Architektur mit offenen Standards Für die drei zuvor benannten Anwendungsgebiete Datenintegration, Prozessintegration und Prozessunterstützung wurde geprüft, ob eine geeignete OSS-Lösung die auf offenen Standards basiert, eingesetzt werden kann. Dabei war die maßgebliche Prämisse, ausschließlich offene Standards zu betrachten. Mit Standards ist bei Weiterentwicklung und Pflege eine gewisse Kontinuität gegeben, die bei einer nicht etablierten Lösung weniger erwartet werden kann. Bei der Replikation können die BusinessWare Connectoren durch die Java Connector Architecture (JCA) ersetzt werden. Das Mapping kann mit Hilfe von Enterprise JavaBeans (EJB) (asynchron über Message Driven Beans, MDB) erfolgen. Diese Standards werden z.b. vom JBoss J2EE Application Server unterstützt. Die erforderliche Transaktionsunterstützung ist mit Java Transaction API (JTA) gewährleistet. JBI-Container (ServiceMix) JTA Transaction Manager Connection Pool JCA 1.5 Inflow Resource Adapter EJB 3.0 Container Message Driven Bean JCA 1.5 Outbound Resource Adapter Abbildung 4 - Replikation mit offenen Standards Quelle: Entory, Open Source 4 BPI, 2006 Die vorgestellte Lösung konnte in einem Performancetest mit einem Prototyp sogar bessere Ergebnisse erzielen als die BusinessWare-Lösung. Die genannten 17 vgl. Offermann, Eine Orientierungshilfe im SOA-Labyrinth, Januar vgl. Paoli, SOA in the Financial Industry - Technology Impact in Companies' Practice,

22 Standards sind bereits heute in der Praxis weit verbreitet 19. Das Migrationsrisiko ist als gering einzuschätzen. Die Services können ebenfalls mit offenen Standards abgebildet werden. Die Adapter können für HTTP mit Servlets oder für MQ mit JCA umgesetzt werden. Die Servlets selbst sind in einem J2EE Server angesiedelt. Die Services selbst lassen sich im EJB-Container mit Stateless Session Beans (SLSB) realisieren. Für die Funktion des Dispatchers können Servlets oder EJBs und die systeminterne Kommunikation der Java Message Service (JMS) verwendet werden. Die Rolle der Connectoren kann hier ebenfalls die JCA übernehmen. J2EE Server (ServiceMix) JCA 1.5 Inflow Adapter MQ EJB3 MDB für MQ Service Servlet EJB3 (SLSB) Order Service Dispatcher EJB3 (SLSB) DE Service EJB3 (SLSB) Depot Service (Service Engine) EJB3 (SLSB) CICS Service (Service Engine) Dispatcher EJB3 (SLSB) EAIDB Service EJB3 (SLSB) TransDB Service JCA 1.5 CICS Connector JCA 1.5 RDBMS Target JCA 1.5 RDBMS Target Abbildung 5 - Services mit offenen Standards Quelle: Entory, Open Source 4 BPI, 2006 Die Realisierbarkeit konnte mit einem Prototyp nachgewiesen werden. Offene Standards sind auch für den Anwendungsfall Services weit verbreitet 20. Das Migrationsrisiko ist ebenfalls als gering einzuschätzen. In der Prozessintegration können die Connectoren mit JCA und die für den Anwendungsfall wesentliche Transaktionsunterstützung mit JTA umgesetzt werden. Bei der entscheidenden Steuerung der Abläufe erscheint jbpm Process Definition Language (JPDL) als sinnvollste Lösung. Es handelt sich hierbei um ein von JBoss entwickeltes Framework für das Business Process Management (BPM) (siehe Abbildung 6). 19 vgl. Entory, Open Source 4 BPI, 2006, S. 12 ff. 20 vgl. Entory, Open Source 4 BPI, 2006, S

23 JBI-Container (ServiceMix) JTA Transaction Manager Connection Pool JCA 1.5 Inflow Resource Adapter EJB 3.0 Container BPM Execution Engine JCA 1.5 Outbound Resource Adapter Hibernate Object Persistence DB Abbildung 6 - Prozessunterstützung mit offenen Standards Quelle: Entory, Open Source 4 BPI, 2006 Die JPDL ähnelt sehr der Funktionalität von BusinessWare und kann leicht mittels XML Stylesheet Transformation in das jbpm Format migriert werden, was mit einem Prototyp erprobt wurde. Auch kann mit und ohne Persistenz gearbeitet werden. Bisher findet JPDL allein in JBoss Verwendung, daher besteht ein Investitionsrisiko, auch wenn JBoss dieses Open-Source-Produkt stark forciert. Es ist jedoch realistisch, dass sich die JPDL als offener Standard etablieren kann, da JBoss bereits mit seinem J2EE Application Server gezeigt hat, dass sich ihre Produkte am Markt etablieren können. Derzeit stärker verbreitete offene Standards wie Business Process Execution Language for Web Services (BPEL4WS) sind als Alternative denkbar, allerdings sind bisher nicht alle Prozesse über Webservices angebunden. Zwar können mit BPEL4WS auch EJBs verwendet werden, es lassen sich aber nicht alle verwendeten Prozess-Modelle damit abbilden 21. Bei beiden Lösungsmöglichkeiten besteht ein mittleres Migrationsrisiko Java 2 Platform, Enterprise Edition (J2EE) In den vorgestellten Lösungen sind Komponenten aufgezeigt worden, die aus dem J2EE-Standard stammen und als offener Standard bezeichnet werden. Auch wenn oder gerade weil hinter der Programmiersprache Java selbst der kommerzielle Hersteller Sun steht, existiert die notwendige Kontinuität bei der Weiterentwicklung des J2EE-Standards. Die Spezifikationen der Bestandteile werden im 21 vgl. Entory, Open Source 4 BPI, 2006, S. 24 ff. 15

24 Verfahren des Java Community Process (JCP) vorgenommen, an dem neben Sun auch Firmen wie IBM und Apple sowie die Organisation Apache Software Foundation 22 beteiligt sind. Erweiterungen der Standards werden im JCP erarbeitet und in Form von Java Specification Request (JSR) und Referenzimplementierungen der Öffentlichkeit zur Verfügung gestellt 23. Bei den definierten offenen Standards ist für die Integration externer Anwendungen die JCA (im JSR-112 spezifiziert) und für die herstellerunabhängigen Integrationsplattformen die Java Business Integration (JBI, im JSR-208 spezifiziert) zu nennen. Mit JCA und JBI lässt sich ein Enterprise Service Bus (ESB) umsetzen, welcher mit der OSS-Lösung ServiceMix 24 als leichtgewichtiger Integrationsbroker für SOA mit XML und Webservices realisiert wird. Dieses stellt das Kernelement von Integrationslösungen wie EAI dar und zeigt, dass die Entwicklung von J2EE geeignete offene Standards zur Verfügung stellt, um eine EAI-Lösung umsetzen zu können. Der Trend zur Nutzung von Open Source bzw. offenen Standards wird zudem durch Produkte wie JBoss unterstützt, welche den Betrieb solcher Lösungen ermöglichen Java Connector Architecture Specification (JCA) Die JCA ermöglicht Applikationen, über einen standardisierten Container mit einem Enterprise Information System (EIS) bidirektional zu kommunizieren. Dabei kann es sich um einzelne Applikationskomponenten, Web-Komonenten, Datensysteme, Mainframesysteme oder ganze Clientanwendungen handeln. Auf der Gegenseite existieren Komponenten im EIS, die es den Applikationen ermöglichen, Funktionalität und Daten untereinander auszutauschen. Dieser Standard ermöglicht heterogenen Applikationen auf der einen Seite, mit heterogenen EAI- Lösungen auf der anderen Seite zu kommunizieren, sofern beide den J2EE- Standard unterstützen vgl. Wikipedia.org, Java Community Process, vgl. Wikipedia.org, J2EE, vgl. Kap ServiceMix 25 vgl. Kap JBoss 26 vgl. JCP, JSR-112,

25 3.2.3 Java Business Integration (JBI) Mit JBI wird ein ESB spezifiziert, der die Funktionalität einer SOA und einer Event Driven Architecture (EDA) bereitstellt. Dies wird mit dem OSS-Produkt ServiceMix des Apache Projektes als EAI-Lösung umgesetzt. Abbildung 7 - Apache ServiceMix Quelle: Apache.org, Apache ServiceMix, 2007 Daneben bestehen noch weitere OSS- und proprietäre Lösungen, die aber nicht vollständig den JBI-Standard nach JSR-208 umsetzen. Für zahlreiche unterschiedliche Applikationen besteht dabei der Bedarf, unabhängig von der verwendeten Technologie, untereinander zu kommunizieren. Die Wahl einer EAI-Lösung wurde bisher durch die Technologie eines Herstellers bestimmt. Mit der Umsetzung der JBI-Standards kann unabhängig von einer herstellerspezifischen Technologie die Kommunikation von Anwendungen über eine EAI-Lösung realisiert werden, welche die Integrationslösung wiederum interoperabel macht. Das kommt dem Ansatz einer SOA näher als bisherige proprietäre Softwarelösungen ServiceMix Apache ServiceMix ist ein Open-Source-ESB, der eine SOA mit einer EDA zur Verfügung stellt. Die EDA steuert hierbei die Kommunikation der Komponenten untereinander durch Ereignisse. ServiceMix setzt vollständig die JSR-208 um, ist 27 vgl. JCP, JSR

26 unter der Apache Lizenz erhältlich und kann in die Serverlösungen JBoss integriert werden JBoss Mit dem Namen JBoss wird meist der Applikationsserver verbunden. Dabei ist dieser nur ein Teil der JBoss Enterprise Middleware Suite (JEMS), einem Open Source Middleware Framework 29. Der JBoss Application Server ist in der Lage, direkt ServiceMix-Komponenten zu integrieren 30. Einzelne Bestandteile wie der JBoss ESB basieren auf Open-Source-Komponenten, die auch unter der Mitarbeit von JBoss entwickelt wurden. Im JBoss Framework ist ebenfalls JBoss jbpm enthalten 31. Die meisten JBoss-Produkte und davon vor allem der Application Server sind unter der LGPL erhältlich. Die Firma JBoss selbst gehört mittlerweile zu Red Hat JBI-Implementierung bei der Union Investment Die beschriebenen Bestandteile der Integrationslösung wurden auf Grundlage der Anforderungen der Union Investment in einer Zielarchitektur zusammengeführt. Für die gewünschten Erfordernisse des Unternehmens sind meisten Grundfunktionen der Basissoftware ServiceMix und JBoss bereits enthalten und können unverändert eingesetzt werden. Ein Beispiel hierfür ist das für die fachliche Ausführung von Orderaufträgen oder deren Datenübermittelung entscheidende Transaktionshandling, das für einen persistenten Nachrichtenaustausch innerhalb der EAI- Lösung sorgt. Ebenso werden die Connectoren für HTTP und MQ geliefert, welche für die Kommunikation mit bestehenden Web-Anwendungen notwendig sind. Es zeigte sich jedoch, dass Eigenentwicklungen weiterhin notwendig waren, da nicht alle individuellen Anforderungen erfüllt werden konnten. Es handelt sich um spezifische Anpassungen der bestehenden Komponenten oder um vollständige Eigenentwicklung von neuen Komponenten. Mit dem Regelwerk (Rule Engine) werden vor allem die Bedingungen der Datenflüsse definiert, damit z.b. bestimm- 28 vgl. Apache.org, Apache ServiceMix, vgl. Wikipedia.org, JBoss, vgl. Apache.org, Apache ServiceMix, vgl. Kap. 3.2 Architektur mit offenen Standards 32 vgl. Wikipedia.org, JBoss,

27 te Daten ihre korrekten Zieltabellen erreichen. Die individuellen Datenbankstrukturen müssen somit selbst abgebildet werden. Die Definitionen für Transformationen (XSLT) übersetzen die jeweiligen Eingangsdaten für die Zielsysteme. Spezielle Connectoren (RDBMS Connectoren) ermöglichen insb. die Kommunikation mit CICS-Anwendungen eines IBM Mainframe. Die CICS Komponenten selbst sind seitens IBM lizenzpflichtig und damit nicht Teil einer OSS. Process Modelling jbpm Lookup Service und weitere Tools Rule Engine Drools XSLT ServiceMix JBI Message Bus JCA Container JMS Connectors RDBMS Connector Connectors HTTP, File, FTP, JBoss AS JMS Messaging JBossMQ Transaction Handler JTA Deployment JBoss Logging, Caching, JBoss JBoss ServiceMix Eigenentwicklung Abbildung 8 - Architektur der JBI Implementierung Quelle: Entory, OSIRIS, 2007 Standards beschreiben ganz allgemein Komponenten und deren Eigenheiten. In der aktuellen Implementierung der EAI-Lösung wird durch eine konsequente Umsetzung der Standards die notwendige Flexibilität geschaffen, um einzelne Komponenten oder die komplette Basissoftware der Integrationslösung durch eine andere Software austauschen zu können, die den gewünschten Standards folgt. Da in Standards jedoch nicht beschrieben ist, in welcher Art und Weise die Implementierung konkret erfolgen soll, wird ein praktischer Wechsel einen gewissen Migrationsaufwand verursachen. Dieser dürfe jedoch wesentlich geringer ausfallen als bei einem Wechsel einer Basissoftware die nicht konsequent einem Standard folgt wie es bei BusinessWare der Fall ist, da Standards die Rahmenbedingungen definieren die ein höheres Maß der Kompatibilität zusichern. Im Gegensatz dazu, kann es im Verlauf der Produktentwicklung einer Software ohne verbindliche Standards sogar zu einem Paradigmenwechsel kommen, der z.b. die grundlegende Technologie so verändert, dass sich dies negativ auf die Kompatibilität zu eigenenentwickelten oder veränderten Komponenten auswirken kann. 19

28 3.2.7 BusinessWare-Implementierung bei der Union Investment Wird nun der Vergleich der Bestandteile der Basissoftware von der beschriebenen OSS-Lösung zu BusinessWare durchgeführt, so lässt sich feststellen, dass die grundlegende Architektur ähnlich ist und viele Anforderungen der Union Investment erfüllt sind. Ebenso waren zahlreiche individuelle Anpassungen erforderlich, um alle Anforderungen vollständig leisten zu können. Ein wesentlicher Unterschied ist jedoch bei BusinessWare, dass hier eine große Lösung eines Anbieters in einem Produkt zur Verfügung gestellt wird. Diese Lösung orientiert sich zwar an der CORBA-Spezifikation, folgt ihr jedoch nicht vollständig. In der Umsetzung ist es letztlich ein herstellerspezifisches Produkt mit allen Vor- und Nachteilen. Die enthaltenen Komponenten können nicht ausgetauscht und nur schwer oder gar nicht angepasst werden. Zudem musste die zentrale Komponente Service-Engine (XSLT) vollständig selbst entwickelt werden. Einige enthaltene Bestandteile werden nicht genutzt, wie die Connectoren für Siebel. Process Modelling Service Lookup Service und weitere Tools Rule Engine XSLT Service-, SQL-Engine BusinessWare proprietärer Message-Bus / an CORBA orientiert Connectors SWIFT, MQ-Series RMI RDBMS Connector Connectors HTTP, File, FTP, , SAP, Siebel BusinessWare integrierte Serverfunktion / spezielle Tomcat-Adaption (Web-App-Server) MessageQueuing Transaction Handler Deployment Logging, Caching, BusinessWare Eigenentwicklung Abbildung 9 - Architektur der BusinessWare Implementierung Quelle: Union Investment, Projekt OSIRIS, Lastverteilung und Skalierbarkeit Mit JBoss können Cluster aufgebaut werden, die eine Lastverteilung unterstützen. Dies dient dazu, mehrere Anfragen durch das System parallel verarbeiten zu können oder die Verarbeitungskapazität insgesamt besser skalieren zu können. Im Verlauf der Nutzungszeit kann sich die benötigte Kapazität im Mittel verändern. Durch den Aufbau eines Clusters können mehrere Systeme zu einem Verbund zusammengeschlossen werden und nach außen wie ein System erscheinen. 20

29 In einer JBoss-Installation können mehrere Laufzeitumgebungen (Java Virtual Machine, JVM) gestartet werden, sog. Nodes. In einem Node läuft nach Bedarf der gewünschte Prozess. Es ist auch möglich Partitionen zu bilden, die mehrere Nodes beinhalten, in denen die gleichen Geschäftsprozesse laufen. Die einzelnen Nodes können dabei hardwareseitig über verschiedene Server verteilt sein. Die Nodes innerhalb einer Partition kommunizieren miteinander und replizieren ihre Daten. Abbildung 10 - JBoss Clustering Beispielszenario Quelle: Entory, Open Source 4 BPI, Hardware Für den Einsatz des JBoss Application Server sind für heutige Verhältnisse relativ geringe Hardware-Voraussetzungen erforderlich. Als Java-Anwendung kann dieser auf den meisten Betriebssystemplattformen eingesetzt werden. Das bedeutet, dass gängige Betriebssysteme wie Linux verwendet werden können, was wiede- 21

30 rum den Einsatz kostengünstiger x86 Hardwareplattformen ermöglicht. Im Gegensatz dazu, erfordert die BusinessWare Software den Einsatz teurer Sun Hardwareplattformen mit dem Betriebssystem Solaris Beschaffung Die Beschaffung aller verwendeten Bestandteile wie das Linux Betriebssystem, der JBoss Application Server, die EAI-Lösung ServiceMix und die Java Laufzeitumgebung sind alle frei verfügbar und sind per Download im Internet erhältlich. Als Distribution von Linux ist Red Hat gewählt worden. Nachdem JBoss mittlerweile ebenfalls zu Red Hat gehört ist zu erwarten, dass die Produkte stärker aufeinander abgestimmt werden. Die Bereitstellung der Basiskomponenten erfolgte durch die Union Investment selbst. Die Anpassungen auf die individuellen Unternehmensbedürfnisse werden durch einen externen Dienstleister im Rahmen werksvertraglicher Regelungen durchgeführt. Das bedeutet im Wesentlichen eine direkte Vertragsbeziehung mit dem Distributor (bezogen auf die Software wie sie im ursprünglichen Zustand zur Verfügung gestellt wurde). Für alle anderen Bestandteile die durch den Dienstleister angepasst wurden, besteht eine Vertragsbeziehung mit dem Dienstleister. Diese Konstellationen ziehen verschiedene rechtliche Konsequenzen nach sich, insb. bei der Frage nach der Gewährleistung im Falle fehlerhafter Bestandteile einer Software, die ggf. wirtschaftliche Schäden verursachen können Anpassung an kundenspezifische Anforderungen Für den Einsatz einer Software in einem Unternehmen muss zunächst die Frage geklärt werden, ob die Software an die unternehmenseigenen Prozesse angepasst werden soll oder die Prozesse an die Software anzupassen sind. Für den Fall einer OSS kann durch die Verfügbarkeit des Quellcodes ohne weiteres eine Anpassung der Software erfolgen. Bei einer Integrationslösung wird es aufgrund der beschrieben Einsatzfelder unumgänglich sein, diese an die individuellen unternehmerischen und technischen Prozesse anzupassen, innerhalb der vom Hersteller und der Software und deren Technologie gegebenen Möglichkeiten. Die Union 33 vgl. Union Investment, Entscheidungsvorlage Open Source EAI, 2006, S vgl. Kap. 4.4 Vertragsrecht & Kap. 4.5 Gewährleistung und Haftung 22