Model Driven Application Integration am Beispiel der Versicherungswirtschaft 231

Transkript

1 Model Driven Application Integration am Beispiel der Versicherungswirtschaft Einleitung Die deutschen Versicherungsunternehmen müssen sich großen Herausforderungen stellen. Die Produktvielfalt und -flexibilität rückt immer mehr in den Mittelpunkt des Geschehens. Kürzere Produktlebenszyklen erhöhen den Innovationsbedarf. Dies bedeutet für eine Vielzahl von Unternehmen gewaltige Veränderungen im Bereich der IT-Infrastruktur. Es ist eine anpassungsfähige Architektur erforderlich, die der weiter wachsenden Marktdynamik gerecht wird. Die Systeme müssen flexibler und offener gestaltet werden, bei gleichzeitiger Reduzierung der Entwicklungskosten und -zeiten. Um diesen Anforderungen gerecht zu werden, müssen Unternehmen mehrgleisige Strategien verfolgen. Selbstverantwortete individuelle Softwareentwicklung wird ein wichtiger Faktor bleiben, weiterhin besteht die Notwendigkeit, Fremdsoftware in existierende Strukturen integrieren zu können. Langfristig wird der ursprüngliche Wunsch nach integrierbaren Systemen zum kritischen Erfolgsfaktor der Unternehmen. 1 Es ist allgemein bekannt, dass seit Jahren bei fast allen Versicherern im Wesentlichen vier IT-Problemlösungskomplexe im Vordergrund stehen: Die Auflösung der Komplexität der historisch gewachsenen vielschichtigen IT-Systeme mit ihren unterschiedlichen Datenstrukturen und internen Arbeitsweisen und Abläufen. Die medienbruchfreie Vernetzung dieser alten Systemlandschaften mit den diversen Kommunikationsanforderungen interner und externer Partner über das WWW. Die Einbindung unstrukturierter Wissensspeicher in die laufenden Geschäftsprozesse, um die Sachbearbeitung nicht nur quantitativ, sondern auch qualitativ zu unterstützen. Die Reduzierung der Projekt- und EDV-Wartungskosten durch den Einsatz zeitgemäßer Tools und vorgefertigter Anwendungsmodule, wodurch die entstehenden Kosten und Entwicklungszeiten gesenkt werden können. Die Lösung dieser Probleme erfordert ein ganzheitliches und umfassendes Konzept, das den Anforderungen eines unternehmensübergreifenden und 1 Vgl. GDV (2001), S. 5.

2 232 Dr. Boris Petkoff spartenunabhängigen Referenzmodells für die deutsche Versicherungswirtschaft im existierenden technischen Umfeld gerecht wird. Auf der Grundlage des fachlichen und technischen Versicherungs-Anwendungs-Architekturen- (VAA) Referenzmodells kann das heute aus historischen Gründen existierende Chaos unter den folgenden Aspekten analysiert werden: Bottom up: (EAI) Enterprise Application Integration für existierende Systeme 2 Top down: (MDA) Model Driven Architecture für neu zu implementierende Systeme 3 Der folgende Beitrag beschreibt pragmatisch beide Ansätze und bezieht sich dabei auf das erwähnte Referenzmodell für die Versicherungswirtschaft. 2 Model Driven Architecture (MDA) Was in vielen Unternehmen von IT-Architekturen verlangt wird, ist Transparenz, Nachhaltigkeit und Wiederverwendung. Die Model Driven Architecture ist die Strategie der modellgetriebenen Soft- und Hardwareentwicklung die eine klare Trennung von Abstraktionsschichten bei der Implementierung und die Nachhaltigkeit der Systeme sichert. Das Ziel der MDA ist es, die momentan oft noch herrschende Lücke zwischen Modellen (bzw. Modellierern) und Quelltext (bzw. Programmierern) zu schließen wobei die OMG durch ihre frei erhältlichen Standards die dazu notwendige Integration von verschiedensten Werkzeugen unterschiedlicher Hersteller ermöglicht, was für eine breite Akzeptanz sorgen dürfte. Um die Nachhaltigkeit der Modelle zu sichern, ist es wichtig, dass sie unabhängig von einer bestimmten Plattform erstellt werden. 4 Kernstück einer Lösung mit MDA als technologischem Ansatz ist ein UML- Metamodell. Diese Vorgehensweise, wenn sie konsequent eingesetzt und vom MDA-Tool unterstützt wird, hat neben der enormen Zeitersparnis, die durch die geringere Programmierarbeit entsteht, viele Vorteile. MDA stellt Modelle und Generatoren in den Vordergrund der Entwicklung und wird heute in Banken, Versicherungen, öffentlichen Finanzverwaltungen und anderen Bereichen eingesetzt. Die Entwicklung in MDA erfolgt in drei Hauptschritten: 2 Vgl. Linthicum (2000). 3 Vgl. Frankel (2003); Javamagazin (2003). 4 Vgl. Frankel (2003); Kleppe/Warmer/Bast (2003).

3 Model Driven Application Integration am Beispiel der Versicherungswirtschaft In UML wird ein High-Level-Modell der jeweiligen Fachdomäne entwickelt, das von der eingesetzten Implementierungs- oder Basistechnologie unabhängig ist. Dieses Modell wird Platform Independend Model (PIM) genannt. 2. Das PIM wird in ein Platform Specific Model (PSM) transformiert. Das PSM beschreibt das System im Hinblick auf eine bestimmte Implementierungstechnologie. Es benutzt die Konstrukte, die in dieser Technologie zur Verfügung stehen, etwa: EJBs,.NET, Datenbankschemata, etc. 3. Schließlich wird das PSM in Quellcode übersetzt. Da jedes PSM bereits an einer bestimmten technologischen Plattform ausgerichtet ist, ist dieser dritte Schritt in der Regel eindeutig, kann aber nie 100 % des Codes liefern. Transformation s Functional s Platform Independent Model Technology Platform Specific Model Generate Implementation Code Model Abbildung 1. Model Driven Architecture Der Vorteil von MDA ist neben dem strukturierten Neuanfang von Projekten, die Möglichkeit, Legacy-Systeme auf den state of the art zu bringen oder sie mit relativ geringem Aufwand zu ersetzen. Ist ein bestehendes System mit den Datenstrukturen und der Geschäftslogik rekonstruiert, so wird eine saubere Implementierung möglich. Eine Reihe wichtiger technischer und organisatorischer Fragen rund um MDA und generative Entwicklung sind aber noch ungeklärt: Die IT-Landschaften der Finanzdienstleister sind keine grünen Wiesen, vielmehr historisch gewachsene Landschaften, die sich durch eine Vielzahl

4 234 Dr. Boris Petkoff schlecht dokumentierter Legacy-Systeme implementiert in Assembler, COBOL, PL/1 usw. auszeichnen. Gerade im Bereich der Finanzdienstleister besteht das Problem (z. B. durch Fusionen), große Mengen an bestehenden Daten und Anwendungen in neue Systeme zu übernehmen. Der MDA-Ansatz thematisiert allerdings Daten- und Anwendungsmigration nicht. Softwarewartung: Die Erzeugung von Releases, Patches oder Updates ist oftmals wichtiger Bestandteil der laufenden Wartung von Anwendungen. Bei MDA muss oft das komplette System neu installiert werden. Modellierung klingt theoretisch gut aber der erste praktische Schritt in einer bestehenden IT-Landschaft ist die Enterprise Application Integration (EAI). 3 Enterprise Application Integration (EAI) Unternehmen setzen Informationstechnologie als Wettbewerbsvorteil ein. Das reibungslose Zusammenspiel unterschiedlicher Unternehmensanwendungen kann maßgeblich zum Erfolg oder Misserfolg eines Finanzdienstleisters beitragen. Auch die Vision eines grenzenlosen elektronischen Handels kann nur dann Wirklichkeit werden, wenn im ersten Schritt unterschiedlichste Legacy- Systeme miteinander verbunden werden können. Die Integration von Geschäftsprozessen und Anwendungen ist und bleibt daher eine der größten Herausforderungen, der sich IT-Abteilungen stellen müssen. Neben dem Transport von Daten aus der einen in die andere Lösung müssen auch betriebswirtschaftliche Anforderungen berücksichtigt werden. EAI-Lösungen bilden das Fundament für die Integration von Anwendungen. 5 Die verfügbaren EAI-Konzepte unterscheiden sich von existierenden Middleware-Produkten, Applikationsservern und Gateways aufgrund ihres größeren Leistungsumfangs. Neben dem Transport von Daten aus der einen in die andere Lösung werden auch betriebswirtschaftliche Anforderungen berücksichtigt. Applikationen, die mit anderen integriert werden müssen, können in zwei Gruppen eingeteilt werden: Standardanwendungen mit einer festgelegten API und einer unterstützten Connection Middleware 5 Vgl. Kaib (2002); Keller (2002).

5 Model Driven Application Integration am Beispiel der Versicherungswirtschaft 235 Nicht-Standardanwendungen, die eine API haben können, aber über keine gängige Connection Middleware verfügen Standardapplikationen ermöglichen leichten Zugriff durch Client-Software- Komponenten. Beispiel hierfür ist SAP R/3, das eine RPC-basierte API verwendet. Nicht-Standardanwendungen werden meist als Legacy- oder Individual-Applikationen bezeichnet. Um eine Integration dieser Anwendungen zu ermöglichen, müssen diese um eine Softwareschicht oder so genannte Wrapper erweitert werden, die eine standardisierte Schnittstelle erzeugen. 3.1 Integrationsbedingungen und -ansätze Die grundlegende Integrationsbedingung ist Konnektivität: Die zu integrierenden Anwendungen müssen miteinander verbunden werden, um Informationen auszutauschen. Es gibt grundsätzlich vier Arten, Applikationen zu verbinden: über Daten über RPC-basierte Methoden (Remote Procedure Call) über Nachrichten (Messages) über Prozessintegrationsmethoden Prozessintegration basiert generell auf erweiterten Komponentenmodellen wie Microsoft COM, CORBA oder JavaBeans. Diese Technologien verwenden als Basis selbst RPCs. Die zweite Bedingung ist die Abbildung verschiedener Applikationskontexte aufeinander. Die betriebswirtschaftlichen Anforderungen von ERP-, SCMund CRM-Systemen müssen berücksichtigt werden. EAI-Lösungen kümmern sich um den Austausch von Daten und lassen Geschäftsprozesse miteinander kommunizieren. Sie gleichen unterschiedliche Formate ab und sorgen dafür, dass die Informationen in den richtigen Anwendungen zur Verfügung stehen. Grundsätzlich existieren vier Ansätze zur Integration: Integration via föderierter Datenbanken Individuelle Integration: Dieser Ansatz fußt auf einer Individuallösung, deren in C oder C++ geschriebene APIs sich um die Konnektivität und Verarbeitungsanforderungen kümmern.

6 236 Dr. Boris Petkoff Abbildung 2. Ansätze Enterprise Application Integration Integration per Plug-and-Play: Plug-and-Play-Adapter stellen hier die Verbindung zwischen den zu integrierenden Anwendungen her. Dieser Ansatz funktioniert nur bei Standardanwendungen. Integration per Plug-and-Customize: Bei diesem Ansatz wird der Großteil der Integration durch vorgefertigte Prozess-Adapter vereinfacht. Die verwendeten Adapter können spezialisiert und modifiziert werden. Die Plugand-Customize-Lösung erlaubt auch die Integration von Nicht-Standard- Applikationen. 3.2 Integrationsinfrastruktur Der Integrationsansatz basiert in der Regel auf ERP-Lösungen, die nicht neu programmiert oder gekauft werden, sondern bereits im Unternehmen existieren. Darüber hinaus werden Daten benötigt, die ebenfalls schon vorhanden sind bzw. neu erfasst werden. Dennoch ist die Qualität und Struktur der Daten zu analysieren ebenso wie deren Meta-Daten-Beschreibung, da ohne Metadaten keine sinnvolle Integration möglich ist. Das heißt konkret, dass die vorhandenen Anwendungen besser miteinander integriert werden (EAI-Ansatz) und die auszutauschenden Daten definiert werden müssen (Meta-Data-Ansatz). Der Zwang zur verstärkten Integration konfrontiert die Unternehmen nicht nur mit sich immer schneller erneuernden Technologien, sondern auch mit einem sich rasant verändernden betriebswirtschaftlichen Umfeld. Der steigende Wettbewerb führt zur Notwendigkeit, ergänzende Prozesse (z. B. Supply