SOA bei PostFinance. Harald Aust. serviceorientiert

Größe: px

Ab Seite anzeigen:

Download "SOA bei PostFinance. Harald Aust. austh@postfinance.ch. serviceorientiert"

Friederike Schmitz
vor 8 Jahren
Abrufe

1 serviceorientiert

2 Wer oder was ist PostFinance? PostFinance ist der Finanzdienstleister im Konzern der Schweizerischen Post. Unsere Schwerpunkte liegen in den Bereichen Zahlen (Gelbes Konto) Sparen (Gelbes Deposito-Konto) Anlegen (Gelbe Fonds, Fonds von Drittanbietern) Vorsorgen (Gelbe Lebensversicherungen) Finanzieren (Gelbe Hypotheken) 2

Unsere Schwerpunkte liegen in den Bereichen Zahlen (Gelbes Konto) Sparen (Gelbes

3 ... ein paar Zahlen 2,88 Mio. 60% 795 Mio Konten Marktanteil im CH-Zahlungsverkehr Transaktionen pro Jahr Mitarbeiter (Personaleinheiten) Postfilialen Beratungscenter 44,2 Mrd. CHF 986 Mio. CHF 287 Mio. CHF Bilanzsumme Geschäftsertrag Betriebsergebnis (alle Zahlen 2004) 3

Jahr Mitarbeiter (Personaleinheiten) Postfilialen Beratungscenter 44,2

4 IT-Situation PostFinance Heterogene Applikationslandschaft rund 140 Applikationen Heterogene Technologielandschaft VMS, Solaris, Tru64, Windows, Linux,... OSF/DCE, CORBA, J2EE,.NET,... Ada, C, C++, PL/SQL, Java,... Einbindung zugekaufter Systeme Anbindung externer Systeme Datenkonversion Entkoppelung 4

Windows, Linux,... OSF/DCE, CORBA, J2EE,.NET,... Ada, C, C++, PL/SQL, Java,.

5 Exkurs: Lose Kopplung PostFinance Definition von loser Kopplung: Statische lose Kopplung: Zwei Services sind statisch lose gekoppelt, wenn sie unabhängig voneinander entwickelt werden können. Dynamische lose Kopplung: Zwei Services sind dynamisch lose gekoppelt, wenn sie unabhängig voneinander ausgeführt werden können. 5

6 Ausgangsbild: Monolithische Applikationen GUI-Ebene Implementierungs- Ebene 6

7 Analyse Vorteil: kein grosser Aufwand für Architektur Nachteile: Wildwuchs und Unübersichtlichkeit gleiche Funktionalität mehrfach vorhanden (Ineffizienz) gleiche Daten mehrfach vorhanden (Gefahr von Inkonsistenz) Geschäft und Geschäftsprozesse nicht sichtbar das Business muss in Applikationen denken, nicht in Geschäftsprozessen 7

gleiche Daten mehrfach vorhanden (Gefahr von Inkonsistenz) Geschäft und

8 Vision Vom Fokus auf die Applikation zum Fokus auf das Geschäft Ausrichtung an Prozessen und Anforderungen des Geschäfts statt an Prozessen und Anforderungen der Applikationen Einfachheit und Übersichtlichkeit Durchgängigkeit und Nachvollziehbarkeit Gemeinsame Sprache zwischen Geschäft und Informatik IT follows Business 8

9 Zielbild: Geschäftskomponenten Idee: Modellierung des Geschäfts, nicht der Applikation ca. 200 Geschäftskomponenten für wesentliche Geschäftsfunktionalität (Konto, Kunde, Vertrag,...) Zerlegung der Applikationen in Komponenten Kontinuität von Geschäftskomponenten-Modell bis zur implementierten Komponente Geschäftsprozesse explizit sichtbar 9

200 Geschäftskomponenten für wesentliche Geschäftsfunktionalität (Konto, Kunde,

10 Zielbild: Geschäftskomponenten Prozess-Ebene (GUI-Ebene) Implementierungs- Ebene Modellierungs- Ebene 10

11 Geschäftskomponenten: Analyse Vorteile: Idealer Ansatz, wenn man bei Null anfängt und die gesamte Applikationslandschaft selbst realisiert Erlaubt sehr sauberen Durchgang von Geschäft zu Implementierung und damit einfache Wartbarkeit Code-Generierung möglich Nachteile: Zerlegen der bestehenden Applikationen und Neuzusammensetzen zu Geschäftskomponenten sehr aufwendig Laufender Betrieb darf nicht gestört werden Zugekaufte Applikationen passen nie in das Modell 11

einfache Wartbarkeit Code-Generierung möglich Nachteile: Zerlegen der bestehenden Applikationen und

12 Services: Der logische (Zwischen-)Schritt Idee: Keine tatsächliche Zerlegung bestehender Applikationen, sondern Vorsetzen einer Service-Fassade Integrations-Geschäftskomponenten oder virtuelle Komponenten (jetzt: Services) Neuimplementierung evtl. als Komponente, aber nicht zwingend 12

Service-Fassade Integrations-Geschäftskomponenten oder virtuelle

13 Services Prozess-Ebene (GUI-Ebene) Implementierungs- Ebene 13

14 Services: Analyse Vorteile: Keine komplette Neuimplementierung erforderlich Migration kann graduell erfolgen Einbezug zugekaufter Applikationen möglich Aber: Noch zu komplex und aufwendig für Migration (140 Applikationen!) Benötigt: Strukturierungsmittel, um Migrationsplanung und -durchführung zu erleichtern 14

Aber: Noch zu komplex und aufwendig für Migration (140 Applikationen!

15 Quartiere Idee: Gruppierung von thematisch verwandten Applikationen oder Applikationsteilen Quartiere Kriterien für Quartierbildung: logische Zusammengehörigkeit (alles, was für einen bestimmten Geschäftsprozess benötigt wird, ist in einem Quartier) Abhängigkeiten unter den Applikationen Implementierungsgesichtspunkte (zugekaufte Applikationen sind i.a. nicht teilbar) 15

bestimmten Geschäftsprozess benötigt wird, ist in einem Quartier) Abhängigkeiten unter den

16 Quartiere? Intra-Quartier- Kommunikation Implementierungs- Ebene? 16

17 Quartiere: Analyse Vorteile: Überführung der Komplexität einer großen in mehrere kleine Applikationslandschaften Nachteil: Erhöhung der Gesamtkomplexität Verzicht auf das (unrealistische) globale Optimum zugunsten einer Menge (realistischer) lokaler Optima 17

Erhöhung der Gesamtkomplexität Verzicht auf das (unrealistische)

18 Gatekeeper Idee: Abschottung der Quartiere nach aussen jeder Serviceaufruf geht durch den Gatekeeper Mapping von Service-Aufrufen auf Applikationen Namensanpassungen intern - extern Technologieanpassungen intern - extern Datentransformationen intern - extern realisiert PF-weite Security und bildet diese auf applikationsspezifische Security ab Gatekeeper sorgt für statische lose Kopplung 18

Technologieanpassungen intern - extern Datentransformationen intern - extern realisiert PF-weite

19 Gatekeeper Inter-Quartier- Kommunikation Gatekeeper Intra-Quartier- Kommunikation Implementierungs- Ebene 19

20 Die Gatekeeper SOA Referenzarchitektur Inter-Quartier- Kommunikation Gatekeeper Intra-Quartier- Kommunikation Implementierungs- Ebene 20

21 Umsetzung der SOA-Referenzarchitektur Definition der Quartiere (ca. 25) Festlegen von technologieunabhängigen Standardprotokollen zwischen Quartieren (SOAP synchron, JMS/eGate asynchron) Definition von Services zwischen Quartieren Keine Migration um der Migration willen! Implementierung im Rahmen von anderen Vorhaben Nach und nach: Definition und Implementierung von Services innerhalb von Quartieren Frage: Wer pflegt und betreibt nach der Einführung was? 21

22 Pflege und Betrieb : bisher Applikation A1 Applikation A2 Transformationen EAI Transformationen Applikation B1 Applikation B2 Applikationsteam A1 Applikationsteam A2 EAI-Team Applikationsteam B2 Applikationsteam B1 22

23 Pflege und Betrieb : neu Quartier A Quartier B Applikation A1 Applikation A2 Intra-Quartier- Kommunikation GatekeeperA Transformationen EAI Transformationen GatekeeperB Transformationen Intra-Quartier- Kommunikation Applikation B1 Applikation B2 Applikationsteam A1 Applikationsteam A2?? EAI-Team???? Applikationsteam B2 Applikationsteam B1 23

24 Betriebsorganisation Gatekeeper: Ansätze Abwägung: Konzentration fachliches Know-how klare Zuständigkeit für Geschäftsfunktionalität eindeutiger Ansprechpartner für das Business einfachere Kommunikation, besonders im Krisenfall Betrieb als (Geschäfts-)Applikation Konzentration technisches Know-how Ausnutzen von Synergien bessere Auslastung der Mitarbeiter tendenziell kostengünstiger Betrieb als zentrale Infrastruktur 24

25 Betriebsorganisation Gatekeeper: Kriterien 1. Geschätzter Arbeitsaufwand für Produktionssicherung und Weiterentwicklung: hoch: Know-how-Aufbau im Applikationsteam tief: Synergienutzung durch zentrale Infrastruktur 2. Kritikalität des Quartiers: hoch: Ansiedlung im Business-Bereich tief: Kostenvorteil durch Zentralisierung 25

26 Betriebsorganisation Gatekeeper: Kriterien hoch Betrieb durch Applikationsteam Geschätzter Wartungsaufwand niedrig Betrieb als Infrastruktur niedrig Kritikalität hoch 26

27 Zusammenfassung: Von der Applikation zum Geschäft: Geschäftskomponenten SOA: der logische (Zwischen-)Schritt Quartiere: lose gekoppelte Strukturierung Gatekeeper: Separierung der Quartiere voneinander Applikationen, Service-Fassaden, Geschäftskomponenten Intra-Quartier-Kommunikation Inter-Quartier-Kommunikation Zweistufige SOA Umsetzung von außen nach innen Organisatorische Umsetzung von SOA nicht trivial 27

28 Vielen Dank! 28

Ähnliche Dokumente

Java Enterprise Architekturen Willkommen in der Realität

Java Enterprise Architekturen Willkommen in der Realität Ralf Degner (Ralf.Degner@tk-online.de), Dr. Frank Griffel (Dr.Frank.Griffel@tk-online.de) Techniker Krankenkasse Häufig werden Mehrschichtarchitekturen