1 / 37

Migrationsvermeidung durch Anwendungsintegration

Dr. Robert Merkel 6. Juli 2000. Migrationsvermeidung durch Anwendungsintegration. Integration heterogener Systeme anstatt Migration Anforderungen an die in die Schnittstellenarchitektur zu integrierenden Systeme Strategisches Szenario zur Migrationsvermeidung durch EAI

denver
Download Presentation

Migrationsvermeidung durch Anwendungsintegration

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Dr. Robert Merkel 6. Juli 2000 Migrationsvermeidung durchAnwendungsintegration Integration heterogener Systeme anstatt Migration Anforderungen an die in die Schnittstellenarchitektur zu integrierenden Systeme Strategisches Szenario zur Migrationsvermeidung durch EAI Mikroarchitekturen und Lösungsmuster für EAI Stand: 27.06.2000 10:30 / Folie: 1 Dr. Robert Merkel

  2. Banken Industrie Telecom Versicherungen SoftlabBusiness Integrator Enterprise CustomerApplication& RelationshipIntegration Management Softlab Business Integrator Stand: 27.06.2000 10:30 / Folie: 2 Dr. Robert Merkel

  3. Überblick und Einleitung • Warum Migration vermeiden • Risiken bei Migrationsvorhaben • Handlungsdruck der Versicherungsunternehmen • Paradigmenwechsel der Versicherungswirtschaft beim Einsatz von DV -> IT -> Y2K/Euro -> IV • Was kann man tun ? - Alternativen • Was muß man tun ? - Voraussetzungen Stand: 27.06.2000 10:30 / Folie: 3 Dr. Robert Merkel

  4. Entscheidungsvorbereitung • IST-Analyse des Informationshaushaltes des VU • Data-Warehouse-Ansatz als Analyse-Methode • Data-Warehouse dispositiv und operativ • Beschreibung des dynamischen Verhaltens • Definition der Facharchitektur • Rahmenbedingungen für die Facharchitektur • Facharchitektur: Beispiel eines Sequenz-Diagrammes zum Use-Case „Vorgang bewerten“ • Facharchitektur: Beispiel eines Objektmodell-Diagrammes zu den Geschäftsobjekten Provision • Facharchitektur: Analyse der fachlich relevanten Teile der Anwendungssysteme • Testkonzept zur Prozeßabsicherung Stand: 27.06.2000 10:30 / Folie: 4 Dr. Robert Merkel

  5. Entscheidung für Migration oder Integration • Bewertung der Legacy-Systeme • Auswahl der zu integrierenden Legacy-Systemebzw. deren Teile • Fortschreibung der Facharchitektur • Beschreibung der Migrationsfachlichkeit • Konsequenzen für das Migrationsvorgehenund Fazit Stand: 27.06.2000 10:30 / Folie: 5 Dr. Robert Merkel

  6. Warum Migration vermeiden?Fahrt mit großem Schiff durch Eisberggebiet Als sich die Nachricht verbreitete, daß die Titanic in der Nacht zum 15. April 1912 in den eisigen Fluten des Nordatlantiks versunken war und 1495 Menschen mit in den Tod gerissen hatte, schickte die deutsche Kaiserin ein Telegramm an einen deutschen Kapitän und bat um Informationen, wie es zu diesem Unglück kommen konnte. Risiko! Stand: 27.06.2000 10:30 / Folie: 6 Dr. Robert Merkel

  7. Risiken bei MigrationsvorhabenQualität der Eisberge • Bandbreite des Problems:Migration von Daten, Fachlichkeit, Anwendungen • Unvergleichlichkeit des Vorhabens:Fehlende Erfahrung und Standardvorgehen • Größenordnung des Vorhabens:Langdauernde und tiefgreifende Beeinträchtigung entscheidender Teile des operativen Geschäfts • Unvollständiger Überblick über Ist-Zustand:Datenqualität, Vernetzung und Seiteneffekte • Konkurrierende oder unklare Zielvorstellungen:Systemtechnik, Anwendungslandschaft, Facharchitektur • Fehlende Mitarbeiterqualifikation Photo: Captain of the S.S. Mackay Bennett Stand: 27.06.2000 10:30 / Folie: 7 Dr. Robert Merkel

  8. Handlungsdruck der Versicherungsunternehmen Gründe für eine Fahrt durch Eisberggebiet • Schutz der bisherigen Investitionen im Rahmen desArchitektur- und Plattform-Managements • Strukturinversion im Zugriff auf operative und dispositive Systeme (Anforderung aus Privat-, Gewerbekundengeschäft) • Produkt- und Dienstleistungsintegration bzw. -innovation(Spartenübergreifend, Cross-Selling) • Überwindung von Medienbrüchen und Systemgrenzen innerhalb des VU und zu dessen Geschäftspartner (B-to-B) • Sichern der zukünftigen strategischen Wettbewerbsfähigkeit durch “enabeling technology” für Internet und virtuelle Unternehmensführung • Migration ist kein explizites Unternehmensziel ! Stand: 27.06.2000 10:30 / Folie: 8 Dr. Robert Merkel

  9. Paradigmenwechsel der Versicherungswirtschaft beim Einsatz von DV -> IT -> Y2K/Euro -> IV Datenverarbeitung • Rationalisierung • Arbeitsteilung • Prüfungssicherheit • Massenverarbeitung Informationstechnologie • Vertriebsunterstützung • Verkaufsunterstützung • Produkt-Qualität • Service-Qualität Jahr 2000 / Euro • Großprojekte • Architekturlastigkeit • Massiver Technologieeinsatz • IT ist das Geschäft Informationsverarbeitung • Bestandsübernahmen • Strukturinversionen • Neue Dienstleistungen • Online-Verarbeitung • Geringere Fertigungstiefe Stand: 01.07.2000 10:30 / Folie: 9 Dr. Robert Merkel

  10. Was kann man tun ? - AlternativenMöglicher Umgang mit Schiff und Eisbergen • Versicherungsunternehmen vom Luxus-Linerzum Eisbrecher umbauen • Neue Systeme • Großes Projekt • Harter Umstellungstermin • Hafenbecken nicht verlassen • Koexistenz von Alt und Neu • Eisberge erhitzen, bis sie schmelzen • Modernisierung der existierenden Systeme • Eisberge geschickt umfahren • Anwendungsintegration Eisbrecher FS Polarstern Stand: 27.06.2000 10:30 / Folie: 10 Dr. Robert Merkel

  11. Was muß man tun ? - VoraussetzungenEisberge kennenlernen ! • Initialisieren eines VU-Prozesses(zielgerichtet, umfassend, zyklisch, auf allen Ebenen, in allen Bereichen) • Herstellen einer vollständigenInformationslage(Ist-Situation, Potentiale, erreichbare bzw. zu erreichende Ziele, Rahmen- bedingungen) • Beschreibung von Szenarien unter Einsatz eines professionellen Projekt-Managements (Informationen, Ressourcen, Risiken, Änderungen, Reserven, Qualität, Test, Notfällen, Optionen) Stand: 27.06.2000 10:30 / Folie: 11 Dr. Robert Merkel

  12. Anwendungsdatenmodell Vertragsverwaltung Partneranwendungen Zentral- und Service-Systeme(Provision, Buchhaltung, ...) Kooperationspartner(Rückversicherung, Assistance, Makler, ...) Prozeßdatenmodell Workflowparametrisierungt Vernetzung Produktdatenmodell (Attribute der Geschäftsobjekte der Produktdefinition) Schlüsselung bzw. Parametrisierung(Merkmale der Klassifikation) Rollen zu Partner und Subjekt Produktinanspruchnahme Struktur (Komposition) Kalkulation und Prüfungen Prozesse und Kontexte Schnittstellen und Text IST-Analyse des Informationshaushaltes des VU Stand: 04.07.2000 23:30 / Folie: 12 Dr. Robert Merkel

  13. Informationslogistik Information erfassen Information verarbeiten Information bereitstellen Information bewahren Information übernehmen Information darstellen Data Warehouse Datenqualität Datenintegration Analyse von Unternehmensdaten Fachliche Indizierung der Unternehmensdaten Data-Warehouse-Ansatz als Analyse-Methode Zitat von Manfred Soeffky: die Sichtweise der Mitarbeiter von IT-Abteilungen ist völlig verschieden von denender Fachabteilungen undder verschiedenen Managementebenen Stand: 27.06.2000 10:30 / Folie: 13 Dr. Robert Merkel

  14. Data-Warehouse dispositiv und operativ • Leisten der fachlichen Arbeit dispositivmit den Instrumenten des Data-Warehouse-Ansatzes • Erstellen des Metadatenmodells • Grundlage für die Facharchitektur • Umsetzen und Nutzen der Ergebnisse in den operativen Systemen durch Anwendungsintegration • Leistungsstarke Adapter zwischen operativen Systemenund Data-Warehouse zur Datenversorgung • Ergebnissen der Data-Warehouse-Systemenverfügbar für operative Systeme Stand: 27.06.2000 10:30 / Folie: 14 Dr. Robert Merkel

  15. Beschreibung des dynamischen Verhaltens • Informationsfluß, Eigentümerschaft von Daten • Fachliche Abläufe und Prozesse • Verantwortlichkeit für Bearbeitung und Ergebnis • Geschäftspläne, -Regeln, Prüfungen und Berechnungsvorschriften • Produkte, Druckstücke, Dialoge • Zusammenarbeit und Vereinbarungen mit anderen Unternehmen  Inhalte der Facharchitektur des VU Stand: 27.06.2000 10:30 / Folie: 15 Dr. Robert Merkel

  16. Definition der Facharchitektur • Die Facharchitektur beschreibt den Aufbau und das Zusammenwirken von Geschäftsobjekten (z.B. Vertrag, Police, Partner) und Geschäftsprozessen (z.B. Neuzugang, Beitragsfreistellung), die durch IT-Systeme unterstützt werden können • Sie ist spezifisch für das Kerngeschäft der organisatorischen Einheit, die das IT-System verantwortet. Beispiele für organisatorische Einheiten können Abteilungen, das Versicherungsunternehmen selbst oder ein Konzern sein • Die Facharchitektur beschreibt im Gegensatz zur Systemarchitektur keine technischen Implementierungsdetails Stand: 27.06.2000 10:30 / Folie: 16 Dr. Robert Merkel

  17. Rahmenbedingungen für die Facharchitektur • Gesetzliche Regelungen (z.B. Meldepflichten) • Branchenstandards (GDV-Satzformat) • Verbände (z.B. Schadennetz des GDV, Rückläufer Doppelkarten, Verbandsstatistik) • Geschäftspartner (Datenaustausch) • Zum Einsatz kommende Kaufkomponenten(Outsourcing-Lösungen, SAP) • Technische Infrastruktur bzw. Systemarchitektur • Organisatorische Festlegungen Stand: 27.06.2000 10:30 / Folie: 17 Dr. Robert Merkel

  18. Facharchitektur: Beispiel eines Sequenz-Diagrammes zum Use-Case „Vorgang bewerten“ • textuelle Beschreibung des Ablaufes • graphische Beschreibung des Zusammenwirkens dervom Geschäftsprozeß betroffenen Geschäftsobjekte (Arbeitsstand aus der VAA-Arbeit zum Thema Provision) Stand: 27.06.2000 10:30 / Folie: 18 Dr. Robert Merkel

  19. Facharchitektur: Beispiel eines Objektmodell-Diagrammes zu den Geschäftsobjekten Provision • Beschreibung der wichtigsten Geschäftsobjekte(Vertrag, Partner, Rolle, Produkt) • Graphische Beschreibung der Vernetzung der Geschäftsobjekte (Arbeitsstand aus der VAA-Arbeit zum Thema Provision) Stand: 27.06.2000 10:30 / Folie: 19 Dr. Robert Merkel

  20. Facharchitektur: Analyse der fachlich relevanten Teile der Anwendungssysteme • Teile des IT-Systems (Schichten, Module, Komponenten) • fachlicher Leistungsumfang bzw. Funktionalität(Lasten- / Pflichtenheft) • Eigentümerschaft von Daten (Geschäftsobjekte bzw. deren Teile) • Protokoll (Methoden) der bereitgestellten Services • Verwendungsnachsweis der von anderen Modulen bezogenen Services und der darin referenzierten Objekt-Netze und komplexen Methoden • Schnittstellen des IT-Systems • Semantik der mit anderen auszutauschenden Daten (Geschäftsobjekte oder deren Teile) Stand: 27.06.2000 10:30 / Folie: 20 Dr. Robert Merkel

  21. Regressionstest Tests für Dialoganwendungen Massentest Testen, Testen, Testen ... Definition der Qualität der Anwendungssysteme über die Testerfüllung Mechanische Wieder-holbarkeit der Tests zur Verifikation der Funktions-erfüllung Fachliche Abnahme über Testfälle entsprechender Qualität Testkonzept zur Prozeßabsicherung Stand: 01.07.2000 10:30 / Folie: 21 Dr. Robert Merkel

  22. Bewertung der Legacy-Systeme Kategorisierung der Legacy-Systeme bezüglich deren • Zerlegbarkeit in separat nutzbare Komponenten • Weiternutzung unter wirtschaftlichen Aspekten • Wiederbeschaffungskosten bezüglich der fachlich weiterhin relevanten Funktionalität • Eignung für zukünftige Anforderungen (siehe Folie: Handlungsdruck bzw. Vorgabe durch strategische Ausrichtung des Versicherungsunternehmens) • Integrierbarkeit der Legacy-Systeme oder Teile dieser in die Ziel-Anwendungslandschaft Stand: 27.06.2000 10:30 / Folie:22 Dr. Robert Merkel

  23. Auswahl der zu integrierenden Legacy-Systeme bzw. deren Teile • Vergleich gegen • „Standard-Software“ • Outsourcing-Lösungen • Individual-Entwicklung • Check gegen Alleinstellungsmerkmale bzgl. des Kerngeschäfts des Versicherungsunternehmens • Abschätzung der Integrationskosten in spezifischenSzenarien (diese unterscheiden sich hauptsächlich im fachlichen Umfang der angestrebten Lösungen) • Abgleich mit Zeithorizont der IV-Strategie Stand: 27.06.2000 10:30 / Folie: 23 Dr. Robert Merkel

  24. Fortschreibung der Facharchitektur • Wiederzuverwendene Legacy-Systeme bzw. deren Teile stellen Rahmenbedingung für Facharchitektur dar • Identifikation der fachlichen Lücke durch Ausplanung von System(-teil) en und neue Herausforderungen • „Puzzle“-Spiel „Standard“-Software, Outsourcing, Individualentwicklung zum Schließen der fachlichen Lücke • Beschreibung des Ergänzungsbedarfs der wiederzuverwendenden Systemteile • Beschreibung der fachlichen Zielfunktionalität der Schnittstellenadapter zwischen den Systemteilen • Möglicherweise ist das Vorgehen zyklisch  Bewertung  Auswahl Stand: 04.07.2000 23:30 / Folie: 24 Dr. Robert Merkel

  25. Beschreibung der Migrationsfachlichkeit Vollwertige Geschäftsvorfälle anlegen für • Migration • Remigration • Replikation • Datenbereitstellung • Dialogintegration • ... im allgemeinen Prozesse über Grenzen zwischen Alt und Neu hinweg Stand: 27.06.2000 10:30 / Folie: 25 Dr. Robert Merkel

  26. Konsequenzen für das Migrationsvorgehen • Komplettes Instrumentarium für das lifecycle-orientierte Plattform-Management liegt vor • Migration ist in das Tagesgeschäft integriert • Wahlweise Nutzung von alten wie neuen Systemen wird zur souveränen Entscheidung des Anwenders Fazit: Natürlich ist eine Migration nicht wirklich vermieden worden, aber vielleicht viel von dem, was sie sonst so schmerzhaft macht (siehe Eisberge) Stand: 27.06.2000 10:30 / Folie: 26 Dr. Robert Merkel

  27. Anhang und Beispiele • Begriffsklärung des Vortragstitels • Migration Vereinte: Ein Beispiel für die fachliche Herausforderung einer Migration • Einsatz eines Produktservers: Ein Beispiel für das VU-übergreifende Produktmanagement • Enterprise Application Integration,Ausgewählte Folien (Quelle: Andreas Schlüter MITC) Stand: 01.07.2000 19:00 / Folie: 27 Dr. Robert Merkel

  28. Begriffsklärung des Vortragstitels • Migration [lat. >(Aus)wanderung<, zu migrare>wandern<, >wegziehen<] die, -/-en,1) Biologie: einedauerhafte Abwanderung (Emigration) oder dauer-hafte Einwanderung (Immigration) einzelner bis vie-ler Individuen (Migranten) aus einer Population in ei-ne andere Population der gleichen Art. .........................................................................Einen Sonderfall der M.bildet die -> Invasion 1). • Migrationsvermeidung [Bedeutung in diesem Vortrag]Daten- und Anwendungsteile in ihrem originären Lebensraum (=Systemumgebung) belassen • Anwendungsintegration Gegenstand dieser Ausarbeitung Stand: 01.07.2000 19:00 / Folie: 28 Dr. Robert Merkel

  29. Beitrag der Softlab GmbH: Fachliche Feinanalyse =ohne detaillierte Vorgaben Lösungen finden und zur Entscheidung bringen Erstellung Fachkonzepte Erstellung Testkonzepte + fachlicher Test Einführung Organisatorische Unterstützung Übertragung des Risikenbestandes - Anpassungen in KOMPASS - Anpassungen in ELAN - Anpassungen der Schnittstellen (Realisierung erfolgt durch DVZ-Allianz) Migration Vereinte: Ein Beispiel für die fachliche Herausforderung einer Migration Übertragung RB, Schnittstellen, verbundene Systeme Kraft-Betrieb ELAN Kraft-Betrieb KOMPASS Stand: 01.07.2000 19:00 / Folie: 29 Dr. Robert Merkel

  30. Phase 1: Produktanalyse z.B. über ACCESS oder EXCEL (Prototyp) Produktstruktur Produktausprägungen Produktschalter in den Schnittstellensystemen Keine Darstellung von prozeduralen Abläufen und komplexen Prüfungen Darstellung der Kalkulation (z.B. LV-Mathematik, Rundungen) Phase 2: Modellierung der Schnittstellen zu den Produktbereitstellungs-systemen / Abbildungen von der Produktdefinition in die Zieltabellen und -Systeme für Produktdatenimport in die Produktdefinition und Produktdatenexport in die Produktbereitstellungssysteme Phase 3: Implementation einer systemgestützten Produktdefinition Einsatz eines Produktservers: Ein Beispiel für das VU-übergreifende Produktmanagement Trennung Produktdefinition von Produktbereitstellung Stand: 01.07.2000 19:00 / Folie: 30 Dr. Robert Merkel

  31. Andreas Schlüter 14. Juni 2000 Ausgewählte Folien zur Enterprise Application Integration Stand: 14.06.2000 11:20 / Folie: 31 Andreas Schlüter

  32. EAI EAI u.v.a Das EAI-Universum:Was aber ist EAI? ERP e-Business BPR Middle-ware Kundenorien-tierung Prozess-orien-tierung CRM MessagesRequests InternetIntranet Archi-tektur Daten- Replikation JavaJ2EE Daten-banken Standards Normen Kompo-nenten EAI-Tools Stand: 14.06.2000 11:20 / Folie: 32 Andreas Schlüter

  33. e-Business Kundenorientierung Strategie Enterprise Application Integration Business-Synergien Prozeßoptimierung IT- Lösung Der Umsetzung integrativer Geschäftsstrategienist eins gemeinsam: EAI EAI (Enterprise Application Integration) ist der Prozeß, der die konsequente Ausrichtung der IT-Systeme auf integrative Geschäftsstrategien ermöglicht. Stand: 14.06.2000 11:20 / Folie: 33 Andreas Schlüter

  34. EAI-Schichten 13: 8 Application Presentation Session 7 Transport 6 Network 5 Data Link 4 Physical 3 2 1 EAI gestaltet die Layers 8 bis 13 über dem OSI-Schichtenmodell Enterprise Application Integration Technische Integration Stand: 14.06.2000 11:20 / Folie: 34 Andreas Schlüter

  35. Supply Chain Enterprise Application Integration Business Processes 13 Business Semantics 12 Application Semantics 11 Interface Syntax 10 Integration Middleware 9 OSI-Schichten 8 Technische Integration 7: 1 EAI gestaltet die Layers 8 bis 13 über dem OSI-Schichtenmodell Stand: 14.06.2000 11:20 / Folie: 35 Andreas Schlüter

  36. Integrationslogik Interaktionsmechanismen Transportmechanismus Netzwerkschicht (TCP/IP) Architektur von EAI-Lösungen Konfiguration (Deployment) Entwicklungs-werkzeuge Administrations-werkzeuge Dienste Dienste Adapter Adapter Dienste Dienste Stand: 14.06.2000 11:20 / Folie: 39 Andreas Schlüter

  37. Unterstützung durch Softlab • Technologieberatung • Unterstützung der Produktauswahl • Architekturdefinition • Beratung zu Produkten (Crossworlds, ActiveWorks, WebLogic, TUXEDO etc.) • Vorgehensberatung • Beratung zu Projektdefinition und -planung • Gestaltung des Entwicklungsprozesses • Analyse der Informationsstruktur und Integrationsmuster • Definition von Entwurfsrichtlinien • Durchführung • Realisierung von Prototypen und Pilottransaktionen • Entwicklung von Adaptern • Umsetzung der Integrationslogik • Vollständige Durchführung von Integrationsvorhaben bei Softlab Stand: 14.06.2000 11:20 / Folie: 40 Andreas Schlüter

More Related