Quasar Enterprise Anwendungslandschaften serviceorientiert gestalten Teil 2: Gesteuerte Evolution und Integrationsarchitektur

Transkript

1 Quasar Enterprise Anwendungslandschaften serviceorientiert gestalten Teil 2: Gesteuerte Evolution und Integrationsarchitektur Dr. Jan-Peter Richter 7. Juli 2009

2 AGENDA Capgemini sd&m Quasar Enterprise Motivation Quasar Enterprise Was ist Serviceorientierung Quasar Enterprise Die ideale Anwendungslandschaft Quasar Enterprise Die Gesteuerte Evolution Quasar Enterprise Die Integrationsarchitektur 2

3 Capgemini sd&m steht für leistungsfähige Prozess- und Softwarelösungen, die die Wettbewerbsfähigkeit unserer Kunden erhöhen Kunden Unsere Kunden sind namhafte Unternehmen aller Branchen sowie öffentliche Institutionen, deren Erfolg von anspruchsvollen Prozessund Softwarelösungen abhängt Ihr Nutzen besteht in erhöhter Wettbewerbsfähigkeit durch Differenzierung bei unternehmenskritischen Lösungen Effizienzverbesserung bestehender Lösungen Leistungsangebot Prozess- und IT-Beratung Entwicklung individueller Softwarelösungen Implementierung und Roll-out von Standardsoftware Systemintegration Kompetenzen Umsetzungsorientierte Beratung Management komplexer IT-Projekte Software-Engineering Gestaltung anspruchsvoller IT-Architekturen Implementierung von SAP-Lösungen Rightshore Forschung & Innovation Partnerschaftliche Arbeitsweise Rightshore ist ein registriertes Markenzeichen von Capgemini Standorte Unternehmensentwicklung Hamburg Düsseldorf Köln/Bonn Frankfurt Walldorf Stuttgart Zürich Hannover Berlin München Standorte Capgemini sd&m Weitere Standorte der Capgemini-Gruppe Nearshore Wroclaw Farshore Mumbai Bangalore SAP Business Solutions sd&m Capgemini sd&m 1 Anzahl Mitarbeiter im Geschäft inkl. Polen und zugeordnetes Team Indien 3

4 Namhafte Kunden aller Branchen vertrauen auf unsere Leistungsfähigkeit Umsatzverteilung in Prozent 1 Telco & Medien Sonstige Dienstleister Öffentlicher Bereich Automobil BMW Continental Daimler MAN TRW Volkswagen, Audi Volvo Automobil Allianz BayernLB Commerzbank DekaBank HVB HSH Nordbank Münchener Rück Energieversorgung Finanzdienstleistung adidas Deutsche Bahn, Schenker Deutsche Post Kühne + Nagel Tchibo Logistik, Handel & Transport ABB Cognis EADS/Airbus Lanxess LyondellBasell Siemens Industrie & Technologie Industrie & Technologie Logistik, Handel & Transport 22 Finanzdienstleistung E.ON OMV RWE Energieversorgung Telco & Medien Deutsche Telekom Nokia Siemens Networks O2 Vodafone ZDF Öffentlicher Bereich Bayerisches Landesamt für Umwelt Bundesagentur für Arbeit Bundesverwaltungsamt 1 Stand: 31. Dezember

5 Unsere Kunden profitieren von über 25 Jahren Erfahrung in der Entwicklung leistungsfähiger Softwarelösungen Wir wählen das optimale Vorgehen für die individuellen Anforderungen unserer Kunden Individuelle Softwarelösungen Prozessund IT-Beratung Geschäftsprozesse und Unternehmensarchitekturen effizient gestalten, Wertbeitrag und Industrialisierung der IT steigern: Wir garantieren objektive und unabhängige Beratungsergebnisse, die sich in der Praxis bewähren. Unsere Stärken sind Konzeption und Entwicklung maßgeschneiderter Softwarelösungen für unternehmenskritische Prozesse in enger Zusammenarbeit mit unserem Kunden, in hoher Ergebnisqualität, budget- und termintreu. Implementierung Standardsoftware Wir stimmen Standardsoftware und Geschäftsprozesse optimal aufeinander ab. Dabei fokussieren wir auf SAP- und Siebel-basierte Lösungen und übernehmen Verantwortung für Blueprint, Customizing und Roll-out auch international. Systemintegration Wir verbinden Systeme zu integrierten Lösungen, zugeschnitten auf die jeweiligen Kundenanforderungen. Wir übernehmen das übergreifende Projekt-, Architekturund Testmanagement und kombinieren unser fachliches Prozesswissen mit dem technischen Know-how zu Enterprise Service Bus-, CRM- und BI-Produkten. 5

6 Research entwickelt unsere Software-Engineering-Kompetenz kontinuierlich weiter und stellt Projekten aufbereitetes Wissen bereit Wir betreiben Innovationen zur systematischen Umsetzung unserer Vorstellung über die künftige Rolle der IT Projekte Studie IT- Trends Techno- Vision Ausbildung Schools für Entwickler, Architekten, Projektleiter Methoden Quasar 1 Enterprise Spezifikation Qualitätssteuerung epm 2 Kunde Partner RAIN 4 Innovation/Trends Web 2.0 Produktkennzahlen Client Architektur SOA Hochschul- Kooperationen Vorlesungen Publikationen Projekte Diplomarbeiten Communities Prozesse Portale Enterprise Integration Datenbanken Entwicklungsplattform Projektumgebung Komponenten auf Open-Source-Basis MDD 3 Forschungsprojekte Hochschulen Stiftungslehrstuhl 5 Projekte 1 Quasar = Qualitäts-Software-Architektur 2 epm = Effizientes und effektives Projektmanagement 3 MDD = Model Driven Development 4 RAIN = Rapid Innovation - globale, serviceorientierte Umgebung für die Auseinandersetzung mit der Zukunft 5 Stiftungslehrstuhl Global Software Engineering an der TU München im Lehrstuhl Informatik 6

7 AGENDA Capgemini sd&m Quasar Enterprise Motivation Quasar Enterprise Was ist Serviceorientierung Quasar Enterprise Die ideale Anwendungslandschaft Quasar Enterprise Die Gesteuerte Evolution Quasar Enterprise Die Integrationsarchitektur 7

8 Die Fortentwicklung einer grossen Anwendungslandschaft ist die Herausforderung BACK-UP für das IT-Management gelungene Architekturen einzelner Anwendungen garantieren noch kein gutes Zusammenspiel! 8

9 Die Rahmenbedingungen und Herausforderungen von gewachsenen Städten und Anwendungslandschaften sind vergleichbar Megacity Gewachsene Anwendungslandschaft Städte unterliegen in der Regel einem natürlichen Wachstum um einen historischen Kern. Dieses natürliche Wachstum orientiert sich in der Regel an gegebenen Strukturen und kurzfristigen Zielen. Natürliches Wachstum Anwendungslandschaften sind in der Regel historisch gewachsen. Langfristige Organisationsbedürfnisse wurden in frühen und meist auch in späteren Wachstumsphasen nicht berücksichtigt. Häufig stellen die natürlich gewachsenen Strukturen einer Stadt Städteplaner vor besondere Herausforderungen, wenn die Stadt die aktuellen Bedürfnisse erfüllen soll beispielsweise zu enge Straßen im Stadtkern. Städte bilden den notwendigen Lebensraum vieler Menschen und tragen entscheidend zum Bruttoinlandsprodukt eines Landes bei. Sie müssen stets funktionieren. Die Funktionsfähigkeit einer Stadt hängt von vielen Dimensionen ab. Wirtschaftliche Attraktivität und Lebensqualität müssen in einem ausgewogenen Verhältnis stehen. Historischer Kern Kontinuierlich Funktionsfähig Anforderungen unterschiedlicher Stakeholder Die in den frühen Wachstumsphasen vernachlässigten Organisationsbedürfnisse muss der IT-Architekt bei der Gestaltung von Anwendungslandschaften berücksichtigen. Die monolithischen Systeme stellen ihn häufig vor besondere Herausforderungen. Die Anwendungslandschaft stellt eine beträchtliche Investition dar, die geschützt werden muss. Anwendungslandschaften müssen immer funktionieren. Anwendungslandschaften leisten einen Beitrag zum gesamten Unternehmenserfolg. Hierbei gilt es unterschiedliche Interessen ausgewogen zu berücksichtigen. 9

10 Aus der Stadtentwicklung kennen wir für verschiedene Ziele unterschiedliche Instrumente der Planung Motivation Raumnutzungsstrategien/räumliche Investitionssteuerung Leitlinien für Themenfelder wie Arbeiten, Wohnen, Ver- und Entsorgung Art der Bebauung (Wohnhaus, Bürogebäude etc.), Vorgaben (Höhe, Freiflächenanteil etc.) Auslegung von Straßen, Ver- und Entsorgungsstrukturen etc. Flächennutzungsplan Stadtentwicklungsplan Bebauungsplan Infrastrukturplan Strategisch Operativ 10

11 Quasar Enterprise bietet Planungsinstrumente zur Gestaltung von Anwendungslandschaften Motivation: Überblick über die Quasar Enterprise Roadmap Geschäft Informationssystem (IS) IT Technische Infrastruktur (TI) IST SOLL IDEAL Kontextuell (warum?) Geschäftsstrategie IT-Strategie Konzeptionell (was?) I Geschäftsarchitektur II Domänen und (Anwendungs-) Services Technische Services Logisch (wie?) (Geschäftsservices, Geschäftsprozesse, Geschäftsobjekte, Organisation, etc) Logische AL- Komponenten und ihre Schnittstellen III Logische Anwendungs- und Integrationsplattformen IV V Physisch (womit?) Physische AL- Komponenten und ihre Schnittstellen Physische Anwendungs- und Integrationsplattformen I Von der Strategie zur Geschäftsarchitektur III Integration V Evolution II Von der Geschäftsarchitektur zur Idealen Anwendungslandschaft IV Integrationsplattformen 11

12 Christoph Kolumbus Reisen AG ( CKR ) CKR CKR PLA PLA <<AL >> Saison -Planung SPLA 3 PLA Planung ( PLA ) LEM REW Mittler LEK LEM REW Reisebüro Leistungs - einkauf ( LEK ) Leistungs - management ( LEM ) Rechnungswesen ( RBÜ ) ( REW ) PGI PGP KUM BEW Internet Produktgestaltung Indi vidualr eisen ( PGI ) Ver kauf Abwicklung ( VER ) ( ABW ) Produktgestaltung Pauschalr eisen ( PGP ) Kunden - management ( KUM ) Berichtswesen ( INT ) ( BEW ) x RBÜ INT Individualreise CCE x x verkaufen Verfügbarkeit prüfen Leistung en buchen Individualreise zusammenstellen Leistung en inhaltl. empfehlen Leistung en selektieren Plausibilit ät prüfen An gebot spreis indiv. berechnen Kunde pflegen RBÜ <<AL >> INT <<AL >> CCE Reisebüro - buchung Reiseportal x x x x x x RBBU REPO REK << AL>> Flug - Einkaufspr ozess FEPR LEM << AL>> Flug- Lager - REW management FLMA REK Leistung s - buchung <<AL >> Lieferanten - management LIMA << AL>> Virtuelles -Lager VILA <<AL >> Rechnungswesen <<AL >> Hotel -Lager - REWE <<AL >> Hotel - Einkaufspr ozess HEPR management HLMA PGI PGP <<AL>> Pauschalr eise - KUM BEW Konfigurator PRKO << AL >> Indi vidualr eise - Konfigurator IRKO PGP <<AL >> Kunden - management KUMA ANM <<AL >> Berichtswesen BEWE <<AL >> Pauschal - Preisberechnung PPRB x x x Call Center ( CCE ) Reiseauftr ags - management ( RAM ) Personal wesen ( PEW ) VER RAM PEW VER << AL>> Pauschal - Preisberechnung RAM PPRB RBÜ INT CCE << AL>> Reiseportal x x x REPO << AL >> 1 Virtuelles -Lager 1 VILA << AL >> Flug - Lager - management FLMA << AL>> Rechnungswesen REWE Verfügbarkeits - prüfung <<AL >> Hotel -Lager - management HLMA PGI PGP KUM Verbindlichkeits BEW - buchung << AL >> Indi vidualr eise - Konfigurator IRKO <<AL >> Kunden - management KUMA Kunde Kundenschnittstelle Konfiguration Kunden - pflege Legende Kopplung Schnittstel le 2 PEW VKI RAM PEW Individualreise buchen Reiseauft rag pflegen <<AL>> Call -Center - x x x << AL>> Indi vidual - buchungsprozess IBPR << AL>> Pauschal - buchungsprozess VKI PBPR Zu migr. Buchung CCBU VKP <<AL>> Reiseauftrags - management RAM RAMA <<AL>> Personal wesen PEWE 2 << AL >> Indi vidual - buchungsprozess IBPR 2 <<AL >> Reiseauftr ags - management RAMA Buchung Au ftrags - pflege x ABW <<AL >> Indi vidualbu - chungssteuerung IBST <<AL >> Pauschalbu - chungssteuerung PBST <<AL >> Auftrags - management AUMA ABW <<AL >> Regulierungs - ABW prozess REPR 3 Kopplungsstufe... Quasar Enterprise definiert das Vorgehen von der Geschäftsarchitektur zur Anwendungslandschaft unter Verwendung methodischer Bausteine Phase 1. Das Geschäft verstehen 2. Das Ideal erstellen 3. Das Ist erheben und bewerten 4. Die Soll- Architektur erstellen Bausteine Ableitung von Architekturleitlinien Identifikation von Geschäftsservices Identifikation von Domänen Erhebung Ist- Anwendungslandschaft Identifikation von Handlungsbedarfen für gesteuerte Evolution Bestimmung der Roadmap Geschäftsarchitektur IDEAL IST SOLL Kunden - zugang Ke rngeschäft Ressourcen Unterstützung Bereiche CKR Kerngeschäft Kundenzugang Kerngeschäft Ressourcen Unter-stüt zung 12

13 AGENDA Capgemini sd&m Quasar Enterprise Motivation Quasar Enterprise Was ist Serviceorientierung Quasar Enterprise Die ideale Anwendungslandschaft Quasar Enterprise Die Gesteuerte Evolution Quasar Enterprise Die Integrationsarchitektur 13

14 Serviceorientierung ist ein geeignetes Paradigma zur Gestaltung von IT- Anwendungslandschaften Serviceorientierung: Was ist das? Verständnis von SOA Variante A Konkrete Technologie (z.b. Web Services) Software Engineering Konzepte die Technologien wie z.b. Web Services zugrunde liegen Hierfür ist kein neuer Begriff notwendig: Komponente, Schnittstelle und Operation sind bekannte und definierte Begriffe Variante B: Paradigma Um zunächst das Geschäft eines Unternehmens zu strukturieren, Um dann von der geschäftlichen Unternehmensarchitektur die Architektur der IT-Anwendungslandschaft abzuleiten Im weiteren Verlauf wird dieses Verständnis von SOA verwendet 14

15 Serviceorientierte Architektur ist der Ansatz zur Fortentwicklung der Anwendungslandschaft Serviceorientierung: Brücke zwischen Geschäft und IT Heterogene Prozesse Prozesse: Harmonisierung und Flexibilität Typische Situation Keine fachliche Struktur der Anwendungen Komplexe Anwendungslandschaft Struktur: Komponenten, Zuständigkeiten, Schnittstellen Infrastruktur: Entkopplung von Anwendungen Chancen durch SOA Kernfelder einer SOA Vielzahl an Plattformen Plattformen: Konsolidierung und Effizienz 15

16 Was ist eigentlich ein Service: Strikte Konzentration auf die Beschreibung der zu erbringenden Leistung eines Systems Serviceorientierung: Außensicht eines Systems Außensicht System erbracht durch Innensicht System (Detaillierung Service A) Nutzungsvereinbarung System System Individualreise verkaufen Geschäftsprozess Leistungen selektieren Angebot bereitstellen Kunde Pauschalreise verkaufen Leistungen empfehlen Plausibilität prüfen Nutzungsvereinbarung Nach Außen als Serviceaktion sichtbar verwendet Nutzungsvereinbarung Nach Außen als Serviceaktion sichtbar Nutzungsvereinbarung Leistungssuche,... Teilsystem 1 Service 2, Teilsystem 1 Teilsystem 2 Service 1, Teilsystem 2 Teilsystem 3 Service 1, Teilsystem 3 16

17 Geschäftsservices als Bausteine der Geschäftsarchitektur bilden die ideelle Vorlage für Anwendungsservices der SOA Serviceorientierung: Geschäftsservices und Anwendungsservices Geschäftsservices... stellen eine Funktionalität dar, die eine unmittelbare geschäftliche Bedeutung hat (z.b. Überweisung eines Geldbetrages bei Banken) werden auf eine eindeutig definierte Art und Weise genutzt (z.b. per Überweisungsformular ODER per Online-Banking (aber nicht auf Zuruf)) haben klar definierte Reaktionen und Wirkungen zur Folge (z.b. Quittung, Belastung des einen Kontos und Entlastung des anderen) stehen im Kontext von vertraglichen Pflichten und Nutzen (z.b. ein überzogenes Konto wieder auszugleichen bzw. das Zielkonto tatsächlich und nach kurzer Zeit zu entlasten) werden an den Organisationsgrenzen nach außen angeboten (z.b. in einer Bankfiliale oder auch von einer Transaktionsbank oder einer entsprechenden Abteilung bankintern) Anwendungsservices der SOA... orientieren sich an den Idealvorstellungen der Geschäftsservices bilden Geschäftsservices ab, wo eine IT-Unterstützung sinnvoll ist werden von Komponenten der Anwendungslandschaft angeboten 17

18 AGENDA Capgemini sd&m Quasar Enterprise Motivation Quasar Enterprise Was ist Serviceorientierung Quasar Enterprise Die Geschäftsarchitektur Quasar Enterprise Die ideale Anwendungslandschaft Quasar Enterprise Die Gesteuerte Evolution Quasar Enterprise Die Integrationsarchitektur 18

19 Versteht der Architekt das Geschäft, beginnt er ein Idealbild der Anwendungslandschaft zu entwickeln Ideale Anwendungslandschaft 1 2 Geschäft IT Ideal Geschäftsarchitektur? 19

20 Er strukturiert die Anwendungslandschaft in Form von Domänen Ideale Anwendungslandschaft Geschäft IT Ideal Geschäftsarchitektur Flächennutzungsplan 3 Finden von Domänen 20

21 Domänen bilden einen idealen Ordnungsrahmen für die Komponenten einer Anwendungslandschaft Domänenlandkarte der Flächennutzungsplan Domänen gruppieren die Komponenten einer Anwendungslandschaft nach fachlichen Gesichtspunkten Domänen dienen der Kommunikation zwischen Fachbereichen und IT, besonders wenn es um Verantwortung geht Für den Architekten sind Domänen ein wichtiges Werkzeug für die Planung und Durchführung der Evolution von Anwendungslandschaften Der Domänenschnitt liefert dem Architekten wichtige Kriterien für das Design von AL-Komponenten, deren Schnittstellen und Kopplung Domänen sind immer am Geschäft des Unternehmens orientiert. Beispiele sind Vertrieb oder Partnermgmt. Es gibt grobe Erfahrungswerte für die Anzahl von Domänen und AL-Komponenten Größe der AL Anzahl AL-Komponenten Domänentiefe Anzahl Domänen Klein 1 <10 <30 Mittel Groß Sehr groß 3 >100 >

22 Der Architekt identifiziert Anwendungsservices und ordnet diese den Domänen zu Ideale Anwendungslandschaft Geschäft IT Ideal Geschäftsarchitektur Stadtentwicklungsplan 4 Identifikation von Anwendungsservices 22

23 Anwendungsservices und Serviceaktionen Anwendungsservices der Stadtentwicklungsplan Definition Anwendungsservices Ein Anwendungsservice beschreibt eine informationstechnische Leistung, welche ein Servicegeber gegenüber einem Servicenehmer erbringt. Der Servicegeber ist eine Anwendungslandschaft oder ein Teil derselben. Der Servicenehmer kann eine Gruppe von Personen oder ein Teil einer möglicherweise anderen Anwendungslandschaft sein. Jedem Anwendungsservice liegt ein Vertrag zu Grunde. Dieser legt die ein- und ausgehenden Informationen fest. Er beschreibt die im Rahmen des Service durchzuführenden Aktionen und ihre Reihenfolge, sofern für den Servicenehmer relevant. Des Weiteren legt er alle relevanten Randbedingungen fest. Serviceaktionen Aktionen sind die Schritte bei der Ausführung eines Anwendungsservice, welche für den Servicenehmer relevant sind. 23

24 Im nächsten Schritt plant der Architekt die Bebauung der Domänen mit Komponenten Ideale Anwendungslandschaft Geschäft IT Ideal Geschäftsarchitektur Kategorien Bebauungsplan 5 Methode: Entwurf von Komponenten 6 Regeln: Entwurf von Komponenten 7 Ref. Architektur: Kategorisierte Anwendungslandschaft 24

25 AL-Komponenten Komponenten in der AL der Bebauungsplan Definition Anwendungslandschaftskomponente Eine Anwendungslandschaftskomponente (AL-Komponente) ist eine geschlossene Einheit innerhalb einer Anwendungslandschaft mit den folgenden Eigenschaften: 1. Sie implementiert Anwendungsservices eines Unternehmens 2. Sie ist umfangreich 3. Sie hat explizite und wohldefinierte Schnittstellen für Funktionen, die sie anbietet 4. Sie hat explizite und wohldefinierte Schnittstellen für Funktionen, die sie nutzt 5. Sie kann mit anderen AL-Komponenten gekoppelt werden 25

26 Referenzarchitektur für Anwendungslandschaften Komponenten in der AL der Bebauungsplan AL-Komponenten sind eindeutig Domänen zugeordnet Die Komponenten sind eindeutig einer Kategorie zugeordnet Die Komponentenabhängigkeiten folgen einer Schichtung in dem Sinne, dass klare Aufrufbeziehungen gemäß der Kategorien Interaktion Prozess Funktion Bestand gelten Die Trennung der Prozesslogik von Funktions- und Bestandskomponenten ist eine der wichtigsten architektonischen Maßnahmen zur Gestaltung von Anwendungslandschaften. 26

27 Danach plant er Schnittstellen und Kopplungsarchitektur Ideale Anwendungslandschaft Geschäft IT-Architektur/Anwendungslandschaft Ideal Geschäftsarchitektur Regeln Infrastrukturplan 8 Methode: Entwurf von Schnittstellen 9 Regeln: Entwurf von Schnittstellen 10 Regeln: Gestaltung Kopplungsarchitektur 27

28 Schnittstellen Schnittstellen der AL der Infrastrukturplan Definition Schnittstellen Eine Schnittstelle fasst Operationen zusammen. Operationen beschreiben das Verhalten von Komponenten. Sie werden spezifiziert durch: 1. Signatur: Name der Operation, Parameter und Rückgabewerte und deren Typen, Ausnahmen 2. Semantik: Verhalten der Operation 3. Protokoll: Nutzung der Operation 4. Nichtfunktionale Eigenschaften: z.b. Performance, Verfügbarkeit, Kosten etc. 28

29 AGENDA Capgemini sd&m Quasar Enterprise Motivation Quasar Enterprise Was ist Serviceorientierung Quasar Enterprise Die Geschäftsarchitektur Quasar Enterprise Die ideale Anwendungslandschaft Quasar Enterprise Die Gesteuerte Evolution Quasar Enterprise Die Integrationsarchitektur 29

30 Kennt der Architekt das Ideal, stellt er dies als Gegenpol den rein operativgeschäftsgetriebenen Zielen gegenüber Evolutionsplanung (Soll-Architektur und Roadmap) IT-Architektur/Anwendungslandschaft Schneller Ideal Entwicklung der Anwendungslandschaft 30

31 Als Balance zwischen diesen beiden Bedürfnissen plant er die Entwicklung der Anwendungslandschaft Evolutionsplanung (Soll-Architektur und Roadmap) Operative (und primär geschäftsgetriebene) Entwicklung IT-Architektur / Anwendungslandschaft Schneller SOLL Idealer Korridor der Balance (wird konkret über Projekte angestrebt) Gesteuerte Evolution Verbesserung der operativen Geschäftsunterstützung durch die Anwendungslandschaft IST Ideale Architektur Verbesserte Ausrichtung der Anwendungslandschaft am strategischen Ideal von Geschäft und IT Strategische (und primär IT-orientierte) Entwicklung 31

32 Hat der Architekt seine Planungsinstrumente beisammen, führt er in mehreren Schritten die Evolutionsplanung durch Evolutionsplanung (Soll-Architektur und Roadmap) Ist-AL IT Bewertete Ist-AL/ Handlungsbedarfe Hauptszenarien SOLL Erhebung der Ist-AL Bewertung der Ist-AL Bestimmung von Hauptszenarien IST IDEAL Soll-AL Roadmap (vom Ist zum Soll) Bestimmung der Soll-AL Bestimmung der Roadmap 15 Erhebung Ist- Anwendungslandschaft 16 Bewertung Ist- Anwendungslandschaft 17 Bestimmung Hauptszenarien 18 Bestimmung Soll-Anwendungslandschaft 19 Bestimmung Roadmap 20 Referenzszenarien 32

33 Diese Planung der Evolution führt der Architekt systematisch in mehreren Schritten durch. Evolutionsplanung (Soll-Architektur und Roadmap) Ist-AL IT Bewertete Ist-AL/ Handlungsbedarfe Hauptszenarien 15 Erhebung der Ist-AL 16 Bewertung der Ist-AL 17 Bestimmung von Hauptszenarien Soll-AL Roadmap (vom Ist zum Soll) Bestimmung der Soll-AL Bestimmung der Roadmap 15 Erhebung Ist- Anwendungslandschaft 33

34 Die Ist-Erhebung konzentriert sich auf die physische IS-Architektur und setzt den Bezug zu Ideal und TI Erhebung der Ist-Anwendungslandschaft verantwortet imp./exp. Domäne Kategorie Bezug zum Ideal Logische AL-Komponente Geschäftsobjekt Logische Schnittstelle (Ideal) stellt Services bereit für realisiert hat verwaltet realisiert realisiert Zugriff auf Organisations- Einheit (AM) Kernbereich Physische (IS Schnittstelle Physisch) Physische AL-Komponente Schnittstellenart Physische Kopplung läuft auf verantwortet imp./exp. ist von läuft auf läuft auf nutzt Organisations- Einheit (IM) Integrationsplattform Logische Hardwareplattform Anwendungsplattform Physische Hardwareplattform Plattform/Strategie Technischer Integrations- Service verantwortet implementiert 34

35 Die physische AL-Komponente ist das Bindeglied zwischen der dem Ideal, der IS- und der TI-Architektur Erhebung der Ist-Anwendungslandschaft Produktinfoportal Produktauslieferung Querschnittl. Funktionen Produktinfoportal Präsentation Systemkomponente BEA Produktinfoportal Logischer Rechner BEA APPPROD1 APPPROD2 APPPROD3 35

36 Die Erhebung einer Ist-Anwendungslandschaft erfolgt sinnvoller weise in vier Schritten Erhebung der Ist-Anwendungslandschaft Schritte Festlegung des relevanten AL-Komponenten Festlegung der relevanten Erhebungskriterien Bei der Erhebung einer Ist-Anwendungslandschaft werden nur AL-Komponenten betrachtet, die im IT-Controlling aufgeführt werden und für die entsprechende Service-Level- Agreements mit dem Betrieb existieren. Die Erhebungskriterien sind Kontextabhängig, beispielsweise ist die Zuordnung zu Domänen im Kontext Agilität besonders interessant. Definition der Steckbriefe Steckbriefe sind die Basis strukturierter Interviews. Steckbriefe sollten 5 DINA4 Seiten nicht überschreiten. Ausfüllen der Steckbriefe Pro AL-Komponente wird für die Durchführung und Nachbereitung der Interviews ca. 1 Bearbeitertag benötigt. 36

37 Best Practices bei der Erhebung der Ist-Anwendungslandschaft Erhebung der Ist-Anwendungslandschaft Klein anfangen Im ersten Schritt sollte man nur Kurzfassungen der Steckbriefe für einige AL-Komponenten und deren Schnittstellen erfassen (beispielsweise nur die Kernerhebungsparameter für die AL-Komponenten eines Fachbereichs). Das Wichtigste zuerst Im zweiten Schritt sollte man sich auf die wichtigsten AL- Komponenten beschränken (das sind in der Regel 2/3 bis 3/4 des Erhebungsumfangs). Finalisieren Im dritten Schritt sollte man die noch ausstehenden Informationen erheben. Visualisierung nutzen Schon während der Erhebung sollte man die Ergebnisse sukzessive in Tabellen und Software-Karten festhalten. Sie sind ein wichtiges Hilfsmittel auch für die Interviews. Wartbarkeit sicherstellen Man sollte die Erhebungskriterien hinsichtlich Umfang, Darstellungsform und Pflegbarkeit so gestalten, dass Komponentenverantwortliche und Projektleiter diese zukünftig ohne großen Aufwand pflegen und nutzen können. Diese Wartbarkeit ist erfahrungsgemäß nur werkzeugunterstützt möglich. 37

38 Nach der Erhebung der Ist-Anwendungslandschaft bewertet der Architekt diese Evolutionsplanung Ist-AL IT Bewertete Ist-AL/ Handlungsbedarfe Hauptszenarien 15 Erhebung der Ist-AL 16 Bewertung der Ist-AL 17 Bestimmung von Hauptszenarien Soll-AL Roadmap (vom Ist zum Soll) Bestimmung der Soll-AL Bestimmung der Roadmap 15 Erhebung Ist- Anwendungslandschaft 16 Bewertung Ist- Anwendungslandschaft 38

39 Die Bewertung der Ist-Anwendungslandschaft erfolgt aus zwei Perspektiven Bewertung der Ist-Anwendungslandschaft Schneller IT-Architektur/Anwendungslandschaft Ideal Entwicklung der Anwendungslandschaft Bewertung der Ist-Anwendungslandschaft im Hinblick auf die operativen ( und primär geschäftsgetriebenen) Ziele und Anforderungen. Bewertung der Ist-Anwendungslandschaft im Hinblick auf die strategischen (und primär IT-getriebenen) Ziele in Form des Ideals und der Plattformstrategie quantitativ und qualitativ. 39

40 Hinsichtlich der Bewertung am Ideal ergeben sich die Kriterien direkt aus den Regeln zu deren Gestaltung. Bewertung der Ist-Anwendungslandschaft Domänenreinheit Fachliche Strukturierung Kategorienreinheit Abhängigkeiten gemäß Kategorien Keine zyklischen Abhängigkeiten Enger Zusammenhalt Datenhoheit Angemessener Kopplungsgrad Funktionale Redundanz Können die physischen AL-Komponenten eindeutig einer Domäne zugeordnet werden? Können den AL-Komponenten eindeutige fachliche Kriterien zugeordnet werden? Können den physischen AL-Komponenten eindeutige fachliche Kategorien zugeordnet werden? Funktionskomponenten sollten beispielsweise niemals Prozesskomponenten rufen. Komponenten sollten beispielsweise nicht gegenseitig voneinander abhängig sein. Zu enge Kopplung zweier physischer AL-Komponenten deutet beispielsweise auf einen falschen Komponentenschnitt hin. Es sollte stets genau eine physische AL-Komponente die Hoheit über ein Geschäftsobjekt haben, also schreibend darauf zugreifen dürfen. Je weiter die Entfernung zwischen zwei AL-Komponenten ist, desto loser sollte ihre Kopplung sein. Eine Geschäftsservice sollte stets nur durch eine physische AL-Komponente implementiert sein. 41

41 Die Bewertungskriterien bezüglich der Plattformstrategie beziehen sich auf die Effizienz der IT Bewertung der Ist-Anwendungslandschaft Homogenität der Technologie Homogenität der Plattform Homogenität der Anbieten Ist die Anzahl unterschiedlicher im Einsatz befindlicher Technologien sinnvoll? Sind die unterschiedlichen Plattformen/Plattformtypen auf ein Minimum beschränkt? Ist die Anzahl der Hersteller für die sich im Einsatz befindlichen AL-Komponenten auf ein Minimum begrenzt? 42

42 Das Ergebnis einer bewerteten Ist-Anwendungslandschaft sind konkrete Handlungsbedarfe. Bewertung der Ist-Anwendungslandschaft Beispiele für Handlungsbedarfe Operative (und primär geschäftsgetriebene) Entwicklung Verkauf von Individualreisen durch IT unterstützen Pflege und Nachhalten von Kundenbeziehungen durch IT (stärker) unterstützen Strategische (und primär IT getriebene) Entwicklung AL-Komponenten fachlich besser strukturieren, insbesondere die Domänenreinheit sicherstellen. Fachliche Redundanz auflösen Plattform vereinheitlichen, insbesondere den Host ablösen 43

43 Aus den Handlungsbedarfen leitet der Architekt eine oder mehrere Hauptszenarien ab und bestimmt die Soll-AL Evolutionsplanung (Soll-Architektur und Roadmap) Ist-AL IT Bewertete Ist-AL/ Handlungsbedarfe Hauptszenarien SOLL Erhebung der Ist-AL Bewertung der Ist-AL Bestimmung von Hauptszenarien IST IDEAL Soll-AL Roadmap (vom Ist zum Soll) 18 Bestimmung der Soll-AL 19 Bestimmung der Roadmap 15 Erhebung Ist- Anwendungslandschaft 16 Bewertung Ist- Anwendungslandschaft 17 Bestimmung Hauptszenarien 18 Bestimmung Soll-Anwendungslandschaft 44

44 Die Bestimmung von Hauptszenarien erfolgt in drei Schritten Bestimmung der Hauptszenarien und der Soll-Anwendungslandschaft Alternative A Auswahl eines oder mehrerer operativer (und primär geschäftsgetriebener) Handlungsbedarfe Ermittlung des davon betroffenen Bereichs der Anwendungslandschaft Ergänzung passender Maßnahmen für diesen Bereich anhand strategischer (und primär IT-getriebener) Handlungsbedarfe. Alternative B Auswahl eines strategischen (und primär IT-getriebenen) Handlungsbedarfs Ermittlung des davon betroffenen Bereichs der Anwendungslandschaft Ergänzung passender Maßnahmen des operativen (und primär geschäftsgetriebener) Bereichs Beispiel: Erschließung eines neuen Geschäftsfelds durch Erweiterung bestehender Systeme und Zukauf neuer Systeme Beispiel: Ablösung veralteter Hardware durch Re-Engineering der betroffenen Systeme 45

45 Auf Basis der Hauptszenarien entwickeln wir die Soll- Anwendungslandschaft in drei Schritten Bestimmung der Hauptszenarien und der Soll-Anwendungslandschaft Definition Soll-Anwendungslandschaft Die Soll-Anwendungslandschaft definiert ein zu erreichendes Zwischenziel, zu dem die physische Ist- Anwendungslandschaft umgebaut werden soll. IT-Architekturanforderungen aufnehmen oder konsolidieren Ableiten aus den IT-Zielen und den Gestaltungszielen (Top Down) Aufnahme von weiteren Architekturanforderungen (Bottom Up) Bevorzugtes Hauptszenario auswählen Quantitative Analyse auf Basis der gewichteten Anforderungen Eine qualitative Analyse komplettiert die quantitative Analyse Soll-Anwendungslandschaft entwerfen Auf Basis des ausgewählten Hauptszenarios das Zielbild desselben entwickeln (physisch) 46

46 Schließlich bestimmt der Architekt die einzelnen Schritte und Stufen zum Soll, d.h. die Roadmap Evolutionsplanung (Soll-Architektur und Roadmap) Ist-AL IT Bewertete Ist-AL/ Handlungsbedarfe Hauptszenarien SOLL Erhebung der Ist-AL Bewertung der Ist-AL Bestimmung von Hauptszenarien IST IDEAL Soll-AL Roadmap (vom Ist zum Soll) 18 Bestimmung der Soll-AL 19 Bestimmung der Roadmap 15 Erhebung Ist- Anwendungslandschaft 16 Bewertung Ist- Anwendungslandschaft 17 Bestimmung Hauptszenarien 18 Bestimmung Soll-Anwendungslandschaft 19 Bestimmung Roadmap 20 Referenzszenarien 48

47 Die Roadmap plant die notwendigen Schritte zur Umgestaltung der Anwendungslandschaft auf Bestimmung der Roadmap Definition Roadmap Die Roadmap ist die qualitative und quantitative Beschreibung des Wegs von der Istzur Soll-Anwendungslandschaft. Bewertete Ist-AL/ Handlungsbedarfe Festlegung der Schritte Referenzszenarien Festlegung der Stufen (Risiken/ Kosten) Roadmap (vom Ist zum Soll) Soll-AL Quantifizierung 49

48 Referenzszenarien der Evolutionsplanung geben Best-Practices für die zeitliche Anordnung von Schritten Bestimmung der Roadmap 1 Neue Bestandskomponenten zuerst Wenn das Soll eine neu zu erstellende oder zu verändernde Bestandskomponente vorsieht, sollte dieser Umbau als erstes erfolgen. Implementiert Services von der Kategorie Bestand AL-Komponente A Datenverwendung AL-Komponente C Abklemmen der Pflegefunktionalität Übergangsweise Integration?? Datenversorgung Service Nutzung AL-Komponente B?? Datenverwendung Service Nutzung Neu erstellt Bestandskomponente U Nicht kategorienrein 50

49 Referenzszenarien der Evolutionsplanung geben Best-Practices für die zeitliche Anordnung von Schritten Bestimmung der Roadmap 2 Unterstützende vor Kerngeschäftsservices Migriere die Anwendungsservices unterstützender Geschäftsservices vor Kerngeschäftsservices AL-Komponente A Service Nutzung AL-Komponente B KU Verändert U Neu erstellt AL-Komponente A~ Service Nutzung K 2x Verändert oder neu erstellt K Komponente mit Kernfunkt. U Komponente mit unterstützender Funktionalität KU Komponente mit gemischter Funktionalität 51

50 Referenzszenarien geben Schrittfolgen in unterschiedlichen Dimensionen vor, die verschränkt werden können Bestimmung der Roadmap Referenzszenario Unterstützungsvor Kernfunktionen Ideale Trennung K Soll U Übergangsweise Integration KU U Unterstützende Komp. neu U IST Referenzszenario Bestandskomponenten zuerst Bestandskomponente neu Übergangsweise Integration Änderung der I-Architektur Ideale Zentralisierung 52

51 Die richtige Schrittfolge ist Basis für die Bestimmung der Stufen Bestimmung der Roadmap Stufen entstehen aus der Zerlegung oder Zusammenlegung von Schritten Stufen definieren die Punkte im Umgestaltungsprozess, an denen man Änderungen in Betrieb nimmt Birgt die Inbetriebnahme eines Schritts in einer Stufe zu viele Risiken, zerlegt man den Schritt mittels fachlicher Partitionierung Definition Fachliche Partitionierung Fachliche Partitionierung ist die Zerlegung strukturell übereinstimmender Daten nach fachlichen Gesichtspunkten, so dass voneinander möglichst unabhängige Gruppierungen dieser Daten entstehen. Häufig findet man eine adäquate fachliche Partitionierung, indem man untersucht, inwieweit sich die betroffenen Geschäftsobjekte anhand von Lieferanten, Kunden-, Produkt- oder Marktgesichtspunkten in fachlich unabhängige Bereiche aufteilen lassen. Bringt die Inbetriebnahme eines Schritts keinen wesentlichen Nutzen, überprüft man, inwieweit sich mehrere Schritte zu einer Stufe zusammenfassen lassen. 53

52 Die qualitative Roadmap beschreibt die durchzuführenden Schritte und Stufen vom Ist zum Soll Bestimmung der Roadmap 54

53 Die quantitative Roadmap beschreibt Umfang und Zeitplan für die Durchführung der Aktivitäten Bestimmung der Roadmap 55

54 xxx xxxxxxx x xxx xx xx xxxxxx xxxxxx xx xxxxx xxx x x x x c xxx xcxxxxx xxxxxx Damit ist dann eine schrittweise Entwicklung einer Anwendungslandschaft möglich Evolutionsplanung (Soll-Architektur und Roadmap) IT Ist Soll Ideal <<AL>> Hotel- Einkäufer-Laptop (HEL) <<AL>> Planungssystem (PLA) <<AL>> Hotel- Einkäufer-Laptop (HEL) <<AL>> Planungssystem (PLA) Hotelleistung übergeben Planung abfragen D (DB#1) Planung abfragen Hotelleistung übergeben Planung abfragen D (DB#1) Planung abfragen L (Datei) <<AL>> Hotel-Einkaussystem (HES) D (DB#1) <<AL>> Hotel- Verfügbarkeitssystem (HVS) <<AL>> Flug-Einkaufs- und Verfügbarkeitssystem (FES) L (Datei) <<AL>> Hotel-Einkaussystem (HES) D (DB#1) <<AL>> Hotel- Verfügbarkeitssystem (HVS) <<AL>> Flug-Einkaufs- und Verfügbarkeitssystem (FES) D (DB#1) D (DB#1) D (DB#1) D (DB#1) D (DB#1) D (DB#1) Vom Angebot abfragen Hotelleistung abfragen <<AL>> Internet- Verkaufs-Client (IVC) Buchen <<AL>> Reisebüro- Verkaufs-Client (Buchungsdialoge) (RVC) <<AL>> Hotel-Regulierungssystem (HRS) Flugleistung Verfügbarkeit abfragen prüfen Kontingente Verfügbarkeit prüfen Ressource übergeben Ressource belegen belegen <<AL>> VK- Preisberechnungssystem (VPS) D (DB#1) Preise abfragen <<AL>> Vakanzprüfungs- und L Buchungssystem (VBS) D (DB#1) Kunden Reiseauftrag abfragen abfragen <<AL>> Daten-Kopier-System (DKS) D (DB#2) <<AL>> Rechnungserstellungssystem Hotelleistung Reiseauftrag (RES) abfragen abfragen Zum Adapter Hotelleistung abfragen Produkt abfragen Individualreise- IDEAL Konfigurator <<AL>> (IRKO) L (ESB) Produkte definieren Plausibilität prüfen Preise berechnen Adapter <<AL>> Reiseportal (REPO) <<AL>> Reisebüro- Verkaufs-Client (Buchungsdialoge) (RVC) <<AL>> Hotel- Regulierungssystem (HRS) Verfügbarkeit Flugleistung prüfen abfragen Kontingente Verfügbarkeit prüfen Ressource übergeben Ressource belegen belegen Adapter Adapter Adapter <<AL>> VK-Preisberechnungssystem (VPS) <<AL>> Virtuelles Lager (VILA) D (DB#1) L (ESB) Preise abfragen Leistung buchen <<AL>> <<AL>> Individualbuchungsprozess Buchen Vakanzprüfungs- und L Buchungssystem L (ESB) (IBPR) (VBS) Buchen D (DB#1) Reiseauftrag <<AL>> abfragen Kundenmanagement (KUMA) <<AL>> L (ESB) Daten-Kopier-System (DKS) Kunde pflegen Kunde abfragen D (DB#2) <<AL>> Rechnungserstellungssystem Hotelleistung (RES) Reiseauftrag abfragen abfragen Orientiert am <<AL>> Kundendokumentesystem (KDS) <<AL>> Kundendokumentesystem (KDS) 57

55 AGENDA Capgemini sd&m Quasar Enterprise Motivation Quasar Enterprise Was ist Serviceorientierung Quasar Enterprise Die Geschäftsarchitektur Quasar Enterprise Die ideale Anwendungslandschaft Quasar Enterprise Die Gesteuerte Evolution Quasar Enterprise Die Integrationsarchitektur 58

56 Hat der Architekt das Soll ermittelt, muss er Integrationsarchitektur und Integrationsplattformen ergänzen Integration und Integrationsplattformen IT Integrationsarchitektur Soll Referenzszenarien 11 Gestaltung der Integrationsarchitektur 12 Integrationsmuster 13 Referenzarchitektur Integrationsplattformen 14 Auswahl von Integrationsplattformen 20 Referenzszenari en der Evolution (Details) 59

57 Für die Integrationsarchitektur ergänzt der Architekt die Schnittstellen des Solls um Integrationsart und technische Services Integration und Integrationsplattformen Definition Physische Kopplung Die physische Kopplung ist die technische Realisierung des Zugriffs einer AL-Komponente auf die physische Schnittstelle einer zweiten AL-Komponente. Dieser Zugriff geschieht unter Zuhilfenahme technischer Services, insbesondere für Kommunikation und Transformation. 60

58 Techniken für die physische Kopplung von Anwendungssystemen gibt es wie Sand am Meer Integration und Integrationsplattformen ETL Publish / Subscribe Middleware DCE CORBA / IIOP Tuxedo SAP RFC / Idoc WebSphere MQ Web Services / SOAP / HTTP JSR 168 / Portlet FTP / Dateitransfer / File Sharing Java RMI ONC (SUN) RPC Im schlimmsten Fall finden wir sie alle in einer Anwendungslandschaft! 62

59 Festlegung von Physischer Kopplung ohne systematisches Vorgehen führt ins Chaos Integration und Integrationsplattformen Physische Kopplung wird in jedem IT- Anwendungsprojekt als isoliertes Problem angesehen Es entstehen isolierte ad-hoc Lösungen Hohe Vielfalt ist aufwändig im Betrieb Hohe Kosten Technik der Integration steht im Vordergrund Wiederverwendbarkeit nimmt ab Naive Lösungen koppeln Anwendungen eng Aufwand für spätere IT-Projekte steigt Geschäftsprozesse sind abschnittsweise in den Anwendungen versteckt Änderung der Geschäftsprozesse schwierig 63

60 Eine wesentliche Säule für ein systematisches Vorgehen ist die Festlegung der Kopplungsart Integration und Integrationsplattformen Definition Arten von Schnittstellen Wir unterscheiden drei Arten von physischen Schnittstellen: (1) Präsentation (P): Die technische Repräsentation einer Benutzerschnittstelle der AL-Komponente (2) Logik (L): Eine funktionale Schnittstelle zum Zugriff auf in der AL-Komponente gekapselte Geschäftslogik (3) Daten (D): Ein Direktzugriff auf persistente Daten der AL-Komponente Entsprechend ihrer Art nennen wir diese Schnittstellen auch Präsentations-, Logik- bzw. Datenschnittstellen. Kopplungsarten Wir unterscheiden drei Kopplungsarten. Diese werden benannt nach den Arten der physischen Schnittstellen, über die gekoppelt wird: Präsentations-, Logik- oder Datenkopplung. 64

61 Eine weitere Säule ist die Identifikation der für die physische Kopplung benötigten technischen Services Technische Services der Integrationsarchitektur Kommunikation: In welcher Form kommuniziert AL-Komponente A mit AL-Komponente B und welche technischen Services benötigen diese für die vorgesehene Kopplung? Wie findet die A den geeigneten Kommunikationspartner B (dynamische und statische Adressierung) In welcher Form werden die Daten von A nach B übertragen (Request Reply, Messaging, ) und welche Servicegüte wird benötigt Welche Dinge müssen protokolliert werden (für Fehlersuche, Nachvollziehbarkeit etc.) Transformation: Passen die Schnittstellentechnologien und Datentypen von AL-Komponente A und AL-Komponente B zusammen und welche technischen Services benötigen diese, wenn diese nicht kompatibel sind? Technische Transformation: Wo müssen technische Protokolle und technische Datendarstellungen in andere überführt werden um eine Kopplung zu ermöglichen? Fachliche Transformation: Wo müssen Strukturen und Werte übersetzt werden, um eine Kopplung zu ermöglichen Weitere technische Services: Für Orchestrierung: Konfiguration der Aufruffolge physischer Schnittstellen über technische Services um eine (höherwertige) Schnittstelle zu exportieren Für Sicherheit: Technische Services 65

62 Auf dieser Basis kann der Architekt die Integrationsarchitektur erstellen Methode zur Erstellung einer Integrationsarchitektur Identifikation des Integrationsumfangs Identifikation der zu realisierenden und zu ändernden AL- Komponenten auf Basis eines Abgleichs zwischen Ist und Soll Realisierungsform Konventionell vs. Orchestrierung: Entscheidung fällen, ob die Umsetzung von Änderungsbedarfen über individuelle Neuentwicklung, Anpassung existierender Komponenten, Verwendung von COTS- Produkten oder durch Orchestrierung erfolgen soll Integrationsmuster anwenden Feinschliff der Integrationsarchitektur durch Anwendung von Best-Practices zur Integration Verbleibende Schnittstellen festlegen Festlegung, welche Art der Integration für die jeweilige Aufgabe sinnvoll ist Gestaltung der physischen Kopplung Festlegung der benötigten technischen Services Finalisieren Abgleich mit der Referenzarchitektur von Integrationsplattformen und Nutzungskonzepten vorhandener Integrationsplattformen 66

63 Die benötigten technischen Services sind Basis für die Auswahl der Integrationsplattform(en) Integration und Integrationsplattformen Definition Referenzarchitektur Die Referenzarchitektur (reference architecture) für Integrationsplattformen legt technische Services fest, die zur Integration in Anwendungslandschaften benötigt werden, und gruppiert diese fachlich. Dies geschieht unabhängig von konkreten Produkten. 68

64 Für jede Integrationsart existiert eine Sicht auf die Referenzarchitektur für Integrationsplattformen Logik Integration und Integrationsplattformen Sicht: Technische Services für die Logikintegration 70

65 Für jede Integrationsart existiert eine Sicht auf die Referenzarchitektur für Integrationsplattformen Präsentation Integration und Integrationsplattformen Sicht: Technische Services für die Präsentationsinte gration 71

66 Für jede Integrationsart existiert eine Sicht auf die Referenzarchitektur für Integrationsplattformen Daten Integration und Integrationsplattformen Sicht: Technische Services für die Datenintegration 72

67 Die Referenzarchitektur bietet einen Kartengrund für Produktlandkarten Integration und Integrationsplattformen 73

68 Quasar Enterprise ist der Reiseführer zur Gestaltung von Anwendungslandschaften Quasar Enterprise Geschäft Informationssystem (IS) IT Technische Infrastruktur (TI) IST SOLL IDEAL Kontextuell (warum?) Geschäftsstrategie IT-Strategie Konzeptionell (was?) I Geschäftsarchitektur II Domänen und (Anwendungs-) Services Technische Services Logisch (wie?) (Geschäftsservices, Geschäftsprozesse, Geschäftsobjekte, Organisation, etc) Logische AL- Komponenten und ihre Schnittstellen III Logische Anwendungs- und Integrationsplattformen IV V Physisch (womit?) Physische AL- Komponenten und ihre Schnittstellen Physische Anwendungs- und Integrationsplattformen I Von der Strategie zur Geschäftsarchitektur III Integration V Evolution II Von der Geschäftsarchitektur zur Idealen Anwendungslandschaft IV Integrationsplattformen 75

69 Und diesen Reiseführer gibt es auch als Buch Quasar Enterprise 76

70 Zusammen. Für nachhaltigen Erfolg.