JFS 2003 EAI mit Pragmatismus und State-Of-The-Art Technologien Vorgehensweise, Lösungen und Erfahrungen bei der IT- Integration der Allianz Dresdner Asset

JFS 2003

EAI mit Pragmatismus und State-Of-The-Art Technologien

Vorgehensweise, Lösungen und Erfahrungen bei der IT- Integration der Allianz Dresdner Asset Managament Deutschland (ADAM Germany)

JFS 2003 – 2

Agenda

Vorstellung

Systemlandschaft des dit im Wandel

EAI in ADAM

• Überblick, Begriff und Ziele

• ADAM Lösungen

Typische Fallen & wie man sie umgeht

Ein Beispiel für eine umgangene Falle

Kontakt & Fragen

JFS 2003 – 3

Vorstellungdit & Allianz Dresdner Asset Management

JFS 2003 – 4

Vorstellung - Die Referentin

Dipl.-Inf. Med. Alrun Wigand

Teamleiterin des Architecture Team der ADAM, EAI & Systemarchitektur, Softwarearchitektur &-entwicklung

ADAM Architecture Team:

Seit Januar 2001

Querschnittsteam

EAI, System- und Softwarearchitektur

JFS 2003 – 5

System-Landschaft des dit im Wandel

Anfang 2001

Insellösungen für einzelne Fachbereiche

Vielfältige Technologien (Powerbuilder, C/C++, Informix, Host/Cobol, VBA, ...)

Mitte 2003

Fachbereiche weitgehend IT-unterstützt

Neue Eigenentwicklungen idR. in Java, ABER

Zugekaufte Standardsoftware!

JFS 2003 – 6

EAI in ADAM 2003 (ein Ausschnitt)

Front Office

(Order Erfassung)

Trading (Aktien)

(Order Ausführung)

Middle Office

(Order Prüfung, Settlement)

Back Office 1

(Order Verbuchung)

Back Office 2

(Order Verbuchung)

Message Hub

(allg. Nachrichten Service)

Fax Email SWIFT (privates Netz für Interbanken-Kommunikation)

Authentifizierung

Autorisierung

Benutzerverwaltung

Andere

Handelssysteme

(Order Ausführung)

B2* Systeme

(diverse)

Separate Systeme EAI MiddlewareZentrale ServicesRichtung der

Kommunikation

Komplettes Order Straight Through Processing (Kern-Geschäftsprozeß)

JFS 2003 – 7

EAI-Begriff in ADAM

Herstellung effizienter (dh. meist automatisierter) Interaktion zwischen technisch isolierten IT-Systemen

Ebenen der Interaktion:

• Technologie (APIs, Protokolle)

• Syntax (Daten, Formate)

• Semantik (Informationen, Terminologie)

• Workflow (Abläufe)

JFS 2003 – 8

EAI Zielstellungen

Kosteneffizienz durch

• Effiziente IT-Unterstützung der Integration auf den Ebenen, wo sinnvoll

• Synergien durch Wiederverwendung / Vermeidung von Redundanzen (auf allen Ebenen)

Flexibler Workflow (Vital!)

Übersichtlichkeit der Schnittstellenlandschaft

Sicherheit der Datenübertragung (sowohl bzgl. Security als auch bzgl. Vermeidung von Datenverlust)

JFS 2003 – 9

Auswahl geeigneter Middleware und EAI Produkte: Asynchron:

• Message Oriented Middleware (diverse Anbieter)

• Lose Kopplung der Systeme Flexibler Workflow möglich! erhöht (bei richtigem Einsatz) Stabilität des

Gesamtsystems

Synchron:

• Direkte Interaktion

• Technologien: Sockets, RMI, COM, Corba, HTTP, SOAP (Web Services) ...

Zugriff auf Middleware vereinheitlicht durch geeignetes EAI-Framework

ADAM Lösungen: EAI Technologie 1

JFS 2003 – 10

Asynchron Umfangreicher Markt:

• „Komplettsysteme“, die ein EAI-Framework mitliefern

• reine Messaging Systeme Entscheidung für Java Message Service (JMS), da

• Die Vielzahl der (neuen) Systeme in Java

• Standard reduziert Anbieterabhängigkeit

• Guaranteed Delivery => Daten kommen sicher an

• Einfaches API

• Java hat generell hohes „Integrationspotential“


JFS 2003 – 11

Synchron

Entscheidung für SOAP Webservices, da

Standard

Toolkits für sehr viele Plattformen erhältlich, die sonst nur sehr schwer zu integrieren wären

Zusammenführung von EAI/Intranet und B2*/Internet (Verkleinerung Technologie-Zoo)

Mittlerweile gute Investitionssicherheit (.net)


JFS 2003 – 12

ADAM Lösungen: EAI Technologie 3.5

Verwendung von Web Services

Vorhandene Systeme / Legacy: Wrappen von APIs

Client/Server Kommunikation (wenn Client-Technologie variieren kann)

Organisationsinterne Services (vermeidet Redundanzen!)

Externe Services (B2*)

Achtung:

Performance, Security, ...

Empfohlen: Prototyping (Durchstich)

JFS 2003 – 13

EAI-Framework www.openadaptor.org


Synergien durch Mitarbeit im Opensource Process (z.B. Fehlerbehandlung)

eigene wiederverwendbare SW-Komponenten (EAI, GUI, ...)

Codegenerierung für Business ObjektePragmatischer, kostenorientierter Ansatz!!!

Properties

Sink

0..n

PipeSource

JMS, Files, JDBC,

MQSeries, ETX, Sockets, RMI, Local, ...

JMS, Files, JDBC,

MQSeries, ETX, Sockets, RMI, Local, ...

1..n 1..n

Logging Monitoring

Errorhandling

JFS 2003 – 14

Die Middleware an sich integriert Systeme nur technologisch

Organisationsweite Standards auf verschiedenen Ebenen:

• Syntax: XML

• weitgehend Systemunabhängigkeit

• Gute Toolunterstützung f. Verarbeitung/Transformation

• Semantik: Vereinheitlichung der internen Terminologie und Formate durch einheitliche Business Objekte (z.B. „Order“, „OrderPackage“, „OrderStatus“)

= „Zentrales Repository“

• von/nach extern auch andere Finance Standards (SWIFT, FIX)

ADAM Lösungen: Syntax und Semantik

JFS 2003 – 15

Verschiedene Anbieter von Workflow-Engines

• In EAI-Komplettpaketen oder standalone

ADAM hat hier eine rein organisatorische Lösung:

Querschnittsfunktionen:

• Betreuung der zentralen Business Objects im „Repository“

• Fachliche Betreuung und Dokumentation der übergreifenden Systemarchitektur (u.a. des „Repositories“)

Etablierter Kommunikationsprozess zwischen den betroffenen Abteilungen bei Änderungen des Workflows

ADAM Lösungen: Workflow

JFS 2003 – 16

Verlust der Flexibilität und Kosteneffizienz durch proprietäre Lsg.

• Meist durch Kauf, seltener durch Eigenentwicklung

• Lösung: Standards bevorzugen Zu komplexe Lösungen für einfache Probleme

• Verlust der Übersichtlichkeit und Effizienz

• Lösung: „As simple as possible“ - Ansatz Wildwuchsgefahr, dadurch Verlust der

Übersichtlichkeit

• Lösung: Zentralisierung und Standardisierung

• Vorsicht: Nicht übertreiben, da sonst negativer Effekt!!! „Was nicht paßt, wird passend gemacht.“ – Standards

einfordern um jeden Preis

• schwer nachvollziehbare, teure, unwartbare Lösungen

• Lösung: von Fall zu Fall entscheiden

Typische Fallen

JFS 2003 – 17

„As simple as possible“ - Ansatz 1Business Object „Repository“

Oft gescheitert wg. „Repository-Effekt“:Hohe Initialkosten (Entwicklung)Komplizierter Businessprozess,

Unübersichtlichkeit durch Komplexität => geringe Akzeptanz

Kosten der Pflege decken selten den Nutzen der Verwendung

Anforderungen in ADAM:Definition systemübergreifender Business ObjectsPflege durch BusinessanalystenZentrale Verfügbarkeit, übersichtliche, gut lesbare

Darstellung, VersionierungGenerierung von Code für wiederkehrende

Anwendungsfälle

JFS 2003 – 18

„As simple as possible“ - Ansatz 2Business Object „Repository“

Definition systemübergreifender Business Objects

Zentrale Verfügbarkeit

Versionierung

Pflege durch Businessanalysten

Übersichtliche, gut lesbare Darstellung

Generierung von Code für wiederkehrende Anwendungsfälle

Excel Frontend +

VBA mit MSXML

XML Definition XSLT

Java mit xerces &, xalan

Javacode

Zentrales Versions- und Konfigura-tionsma-nagement

JFS 2003 – 19

Kontakt

Zu den Themen ...• Enterprise Application Integration –

erfolgreiche Strategien• Erfahrungen mit Web Services• Zentrales Usermanagement• Messaging (MOM, XML, SWIFT, FIX, Email...)• XML Business Object Repository & Codege-

nerierung

... erreichen Sie mich unter:

Alrun Wigand, [email protected] dit Deutscher Investment Trust

IT Trading & Applied Technologies Mainzer Landstrasse 11-13

D-60329 Frankfurt am Main, Germany

...visit dit http://www.dit.de

JFS 2003

Noch Fragen?

Documents

JFS 2003 EAI mit Pragmatismus und State-Of-The-Art Technologien Vorgehensweise, Lösungen und Erfahrungen bei der IT- Integration der Allianz Dresdner Asset