Bestandsführungssysteme und Architekturmanagement

Transkript

1 Bestandsführungssysteme und Architekturmanagement Wolfgang Keller, Plattform-Management, Generali Office Service & Consulting AG, Wien 1

2 Überblick Herausforderungen des Architekturmanagements Was muss gemanaged werden? Rolle der Bestandsführungsführungssysteme gestern, heute und in Zukunft Best Practices für das Management von Veränderungsprozessen Zusammenfassung 2

3 Hinweise Die Dateien zu diesem Vortrag finden Sie nach dem Vortrag auf Folien mit einem Punkt sind Backup-Folien Weiteres Material zu Themen des Vortrages finden Sie auf 3

4 Eine von vielen Definitionen zum Thema Softwarearchitektur The software architecture of a program or computing system is the structure or structures of the system, which comprise software components, the externally visible properties of those components, and the relationships among them. Bass, Clements, and Kazman. Software Architecture in Practice, Addison-Wesley 1997 Warum wir uns dafür Interessieren? 4

5 Herausforderungen Architekturmanagement Wie gestalte ich die Software-Anwendungslandschaft eines großen Finanzdienstleisters? so dass möglichst alle existenten Anforderungen erfüllt werden neue Anforderungen schnell erfüllt werden können man offen ist für neue Produkte und Vertriebswege in einer Gruppe möglichst geringe Kosten und möglichst hohe Synergien entstehen... 5

6 Herausforderung Räumliche Verteilung / Synergie EINE Informatik tätig in Österreich Niederlande Ungarn,Tschechische Republik, Polen, Slowakei, Slowenien, Rumänien 6

7 Herausforderung Menge der Software... Durch Durch welche welche markanten markanten Eckwerte Eckwerte kann kann das das Projekt Projekt beschrieben beschrieben werden? werden? Projektgröße FP Nur Phoenix Leben Wahrscheinlichkeit des Scheiterns 60% Aber 50% es gibt auch noch 40% Sach, KFZ, K/U 30% Außendienst-PCs 20% Call Center Internet-Vertriebswege 10% 0% Projektgröße 7 in Function Points

8 Herausforderung: Ende 1999 Permanente Generali / Lloyd Umstrukturierung werden an Beobachtung: AMB Gruppe assoziiert Man wird mit der nächsten Umstrukturierung in der Gruppe konfrontiert, bevor A man die letzte Zusammenlegung verdaut hat der DV Systeme IU und Generali Generali Triest kauft sich bei AMB Gruppe ein

9 Gewachsene Erkenntnis: Man hat immer ein Portfolio alt/neu Architekturen - eine Hilfe bei Unternehmenszusammenführungen 9

10 Portfolio nach Zusammenlegung DV von IU und Generali ergibt Generali IU Phoenix 10

11 Herausforderung Neue Vertriebswege, Internet Außendienst-Laptops Papier Back-Office 11

12 Herausforderung Neue Vertriebswege, Internet Web Dialog Gateway- Gateway- Server Server Makler Makler Makler Makler Middleware Laptops Call-Center Back-Office 12

13 Heterogenität: Vorhande Varianten der Anw. Arch. POSS Plattform AdiPlus Plattform Finas Plattform Außendienst Ist- Ist- Systeme Ist- Systeme Ist- Systeme Systeme Phoenix Fat Client SLS Host/Java Innendienst 13

14 Rolle der Bestandsführungssysteme Das vorne gezeigte ist nicht alles Der Wandel geht weiter Multi Channel Architektur was ist das? Der One-Stop Financial Supermarket Die Rolle der heutigen Bestandssysteme in dieser Umgebung 14

15 Multi Channel Architektur Was ist das? Außendienst One Face to the Customer Web Interface Call Center Mein Finanzdienstleister sonstige Backend-Systeme 15

16 Multi Channel Architektur Was ist Der das? Kunde bestimmt den Kanal über den er mit uns Kontakt aufnimmt Channels Außendienst Web Interface Call Center sonstige One Face to the Customer Mein Finanzdienstleister Backend-Systeme 16

17 Multi Channel Architektur Was ist das? Channels Wie es gemacht wird muß den Kunden nicht interessieren Außendienst Web Interface Call Center sonstige Backend-Systeme 17

18 Der One-Stop Financial Supermarket Allfinanzidee haben viele: Der Kunde soll bei uns Girokonto haben, Bausparen, Versicherungen abschließen. Frage ist nur: Wie implementiert man Sie Idee: Produkte kommen nicht von einem Hersteller, sondern von mehr als einem Hersteller. 18

19 Der One-Stop Financial Supermarket Web Interface Call Center Interface Außendienst- Interface weitere... Dialogführung, Integration, Middleware Girokonto- Maschine Online Trading Maschine Sachversicherungs- Maschine weitere... 19

20 Der One-Stop Financial Supermarket Multiple Sales Channels Middleware Product Factories 20

21 Die Rolle der heutigen Bestandssysteme in dieser Umgebung Sie sind Product Factories für die Integration in vielen Umgebungen Sie müssen headless, also ohne Oberfläche verwendbar sein Die Schnittstellen müssen sauber definiert sein Keine klassischen Transaktionen Sondern sinnvolle Services für unbekannte Aufrufer (stateless) Am besten mit XML Definition 21

22 Lösungsansätze Wie geht man damit um? 22

23 Sportarten... Management der Architektur für die Product Factories des Kerngeschäftes Hauptthema Management von Mergers Zum Nachlesen vorhanden Management der Integration anderer Product Factories Siehe auch Enterprise Application Integration EAI 23

24 Lösungsansätze Kerngeschäft Überblick Architektur mit Architekturebenen Facharchitektur Anwendungs- und Systemarchitektur Anwendungsportfolio-Management (APM) Überblicks-APM Detailuntersuchung Middleware-Strategie 24

25 Architekturebenen Unternehmensmodell Prov Leist Analysemodelle Facharchitektur Vertra Anwendungsarchitektur Prod Metamodell Topologie Systemarchitektur 25

26 Beschreibungsgegenstand der Architekturebenen unterschiedlich Facharchitektur Fachliche Topologie, Geschäftssysteme optional Aufteilung dieser in Komponenten Modellierung dieser als (fachliche) Analyseobjektmodelle + fachliche Architekturpatterns Anwendungsarchitektur Unterteilung in Schichten, fachliche Komponenten und technische Definition von Kommunikation zwischen diesen + Architektur- und Designpatterns Systemarchitektur Abbildung der Anwendungsarchitektur auf Rechnersysteme (Rechner, Betriebssysteme, DBs) und Kommunikationsprotokolle 26

27 Facharchitektur vergleichbar mit... Unternehmensdatenmodell früher einheitliches Referenzmodell für alle Anwendungen wird zum Objektmodell ein reines Objektmodell muß aber in fachliche Systeme gegliedert werden die in Komponenten unterteilt werden müssen und dann ist man erst auf der Ebene einzelner Klassen Komplexität der rund Elemente muß beherrschbar sein - und es werden noch mehr werden 27

28 Beispiel: Architekturprinzipien in Phoenix flexible flexible to to organizational organizational changes changes strong strong competitive competitive position position field field and and company company independent independent solutions solutions optimal optimal quality-/effort quality-/effort ration ration ReUse, ReUse, Make Make & Buy Buy computer computer assistance assistance distributed distributed and and flexible flexible minimize minimize technical technical risks risks business business process process orientation orientation product product orientation orientation model model driven driven software software development development object object orientation orientation client/server client/server standards standards and and open open systems systems 28

29 Hierarchie in der Facharchitektur Geschäftssysteme (GS) Anwendungssysteme Produkt, Vertrag,... Servicesysteme Dokument, Akt/Archiv, Berechtigung Subsysteme (SubSys) untergliedern die GS in handhabbare Einheiten mit einem definierten Interface und definierten Verantwortlichkeiten (Responsibilities) Fachliche Klassen kleinste Einheit der Facharchitektur 29

30 Facharchitektur: Anwendungssysteme GSProvisionsleistung GSVermittlervertrag GSProvisionsspezifikation GSVersicherungsvertrag GSKonto GSEreignis GSVersicherungsleistung GSAdresse GSVersicherungsprodukt GSPartner GSObjekt 30

31 Bezug der Facharchitektur zu VAA Große Ähnlichkeit zu VAA und anderen, vergleichbaren Modellen Unterschiede zu VAA in Details Systemschnitte ähnlich Objektmodelle statt Freitext Produkt- und Geschäftsprozeßorietierung konsistenter 31

32 Beispiel: Struktur des GS Adresse Gebietsbaustein Gebiet-zu-Gebiet Beziehung Kurse Adresse Die hier modellierte Spezialisierungsebene ist nur exemplarisch dargestellt. Die für ein konkretes Unternehmen relevantegebietsstruktur muß an die benötigten Informationsstrukturen angpaßt werden. Elementargebiet Gebiet Währungen elektronisches Gebiet politischegebiet andereverzeichnisse TelefonVerzeichnis geographisches Gebiet Postleitzahlenverzeichnis StrassenUndOrtsVerzeichnis GSAdresse <<Ableitung>>( ) Adresse ermitteln( ) Gebiet ermitteln( ) abfragbare Attribute ermitteln( ) Attributwerte ermitteln( ) <<Prüfung>>( ) Gebietsprüfung( ) GPAdresse Adresse anlegen( ) Adresse bearbeiten( ) Gebiet anlegen( ) Gebiet bearbeiten( ) Gebiet suchen( ) Straße Ort Land GS Adresse Strukturdarstellung Seite 3.S Staat 32

33 Facharchitektur: Weitere Detailebenen Aktivitäten der GS (Schnittstelle Workflow) Klassenbeschreibbungen mit unterschiedlichem Komplettierungsgrad der Attribute Interaktionsdiagramme und Zustandsübergangsdiagramme für fachliche Objekte 33

34 Anwendungsarchitektur Oberste Ebene: 3-Schichten-Architektur Darunter Schichten und Servicesysteme näher spezifiziert Und Interaktion geregelt über Hinweise auf die Anwendung von Patterns zum Beispiel MVC, Publisher/Subsscrriber, Singleton etc. Das mal n für Back-Office, Außendienst-Laptops, Internet, Makler, Call-Center... 34

35 Oberste Ebene: 3-Schichten- Architektur Benutzungsschnittstelle Geschäftslogik Daten-Management Präsentation Dialog-Kontrolle Prozeß Anwendungskern Datenzugriff Datenbank Allgemeine Dienste 35

36 Eine Ebene tiefer Beispiel: Persistence Service Business Model Business Model Business Model Business Model Persistency Services TOPLink DZS CICS DB2 (Host MVS) DB2/2 36

37 Noch eine Ebene tiefer Beispiel: Persistence Service Klassenmodelle in diese Detailebene gehen wir hier nicht mehr... 37

38 Systemarchitektur: Ausschnitt Phoenix... Eine von mehreren OS/2 OS/2 MVS PHX WF Client Smalltalk OPCA Batch 3GL Workflow Smalltalk GUI- Builder Smalltalk Smalltalk, 3GL Middleware CICS-Family Smalltalk 3GL Geschäftslogik Kommunikation Distribution 3GL 3GL DB2/2 DB2 Datenverwaltung Client Server Host 38

39 Zusammenfassung Architekturen Wir haben... EINE Facharchitektur (Owner PFM, Facharchitektur) die Ist-Systeme weichen davon ab - Differenzen werden/wurden in APM (Anwendungsportfoliomanagement) beschrieben Referenzmodell für alles - nicht nur für Phoenix! Für die Neuentwicklung eine Anwendungsarchitektur mit Varianten (Owner PFM, Anwendungsarchitektur) Abweichungen müssen sehr gut durch Requirements begründet sein Einkauf ist Grund für Abweichungen Bei Eigenentwicklung werden Abweichungen oft versucht - bisher nicht gelungen :-) EINE Systemarchitektur, vorgegeben durch das VEGIS- Netz und seine Komponenten (HW, SW) (Owner IT) diese ist allerdings heterogen (Bsp: CICS, IMS, MQ) 39

40 Offenes Problem.. Der Schrank wird erheblich größer Außendienst- Frontoffice- Systeme Bestands- (Backoffice-) Systeme 40

41 Offenes Problem.. Browser SAP GUI Smalltalk Anwendung 3270 Ihre heterogenen Lösungen werden mit der Integration der alten Monolithen verglichen. Obwohl Sie schneller und billiger produzieren 41

42 Multichannel, Reuse & Zeit Projekte so schneiden, heißt oft, wenig Reuse zu haben. Man ist aber Frontends schnell - nur leider teuer Backends 42

43 Multichannel, Reuse & Zeit Frontends Projekte so zu schneiden bringt vielleicht mehr Reuse im Frontend-Bereich - bringt aber Gefahr von Kommunikationsproblemen => riskant Backends 43

44 Tendenz: Widersprüche steigen Zeit Kosten 44 Qualität

45 APM Anwendungsportfolio-Management 45

46 APM: Anwendungsportfolio- Management Anwendungsportfolio: fachlich und technisch analysieren & bewerten Start bestehende(s) bzw. erneuerte(s) System(e) zyklischer Prozeß Operationen: entwickeln, kaufen, wiederverwenden System(e) integrieren 46

47 APM-Methodik Portfoliodimensionen definieren und Anwendungen erfassen Anwendungen fachlich bewerten und Portfolio "säubern" Anwendungen technisch bewerten und Soll-Portfolio festlegen Migration planen 47

48 Rolle der Facharchitektur Die Facharchitektur ist der fachliche Bebauungsplan Sie zeigt die groben Komponenten Sie zeigt die Konstruktionsprinzipien (Stückliste...) sie listet Funktionalität auf Ebene der Nennung von Funktionen Sie spezifiziert sie aber nicht im Detail aus sie dient als Grundlage für APM-Mappings zur Beurteilungs von Ist-Systemen, Neusystemen, Zukauf-Systemen Facharchitektur ist nicht statisch mit jedem Mapping wird sie besser, weil nachgezogen Lebendes Objekt, keine tote Materie 48

49 Rolle der Facharchitektur Die Wertkette darf nicht gebrochen werden Various Infrastructure Helper Processes Party Subsystem Insured Objects Subsystem Payments Subsystem... other... Subsystems Core Processes Product Development & Definition Subsystem Policies Subsystem Claims Subsystem Sales & Marketing Subsystem Customer Service Subsystem 49

50 EAI und Middleware-Strategie Wie kommunizieren die heterogenen Systeme? 50

51 a typical sales line for EAI products 51

52 a typical sales line for EAI products hub and spoke app 1 app 2 app 3 app n. Hub app 4 app.. app 6 app 5 52

53 why the sales line is only half the truth remember multi channel clients servers web interface call center interface sales force interface dialogs, integration, middleware clear direction bank account machine online trading machine property insurance machine others... others... 53

54 and in the hub sales story.. no direction 54

55 choosing an architecture not that trivial... a client a client a client XML Clip MQ series as a transport facility XML interface layer host boundary software server 1 software server 2 software server 3 software server 4 55

56 challenge #1 interface normalizations a client a client a client XML Clip old host interfaces are not there to give you an easy time accessing them substantial coding effort needs to be put into improving interfaces... MQ series as a transport facility XML interface layer host boundary software server 1 software server 2 software server 3 software server 4 56

57 typical cost situation.. typical cost situation for EAI 20% 80% Tool Interfaces 57

58 Middleware-Strategie KISS: Keep it stupid simple... Marktanteile (Quelle Gartner, vereinfacht) CICS, MQ EAI CORBA Rest 58

59 Zusammenfassung... Volle Homogenität Chaos Gute Lösungen Sanfte Migrationen Pragmatismus 59

60 Zusammenfassung... Facharchitektur Verfügbare Anwendungen Middleware Strategie APM Zielportfolio Technische Abbildung Migrationsprojekt 60 Neues Portfolio

61 Muster für das Management von Fusionsprozessen Keep the Data-Toss the Code Early Decision Clear Vision Application Map One Infrastructure Application Architecture Siehe Artikel: A Few Patterns for Managing Large Application Portfolios 61

62 Muster für das Management von Fusionsprozessen Keeper of the Flame [AOC00] should have Clear Vision is collection of Archetype [AOC00] One Application Wins facilitates facilitates Early Decision One Infrastructure facilitates often leads to may use Stepping Stone [Dew99] leads to Keep the Data Toss the Code may use Application Architecture The Bridge to the New Town [Kel00] Application Map Is derived from patterns in this paper Patterns in other papers Needs to be written 62

63 Credits: Wichtige Beiträge lieferten und liefern Harry Fräser, Gertrude Rabl (Generali) Bernhard Anzeletti, Rudolf Lewandowski (Generali) Robert Aldrup, Martin Friedrichsen, Rüdiger Lang (agens) Und viele viele mehr... 63

64 Was machen wir mit Corba, Components, VAA,... 64

65 Was machen wir mit.. CORBA Siehe Marktanteile und KISS Components Wir sehen die großen Blöcke der Facharchitektur als Komponenten Aspect Oriented Programming zeigt: Lego Block Idee wird schwer funktionieren (Beispiel Produktserver) VAA Verwenden wir als wertvollen Input für unsere Facharchitektur 65