Quasar Enterprise Anwendungslandschaften …agis- · Rechnungswesen (REW ) Berichtswesen ... und...

CEA v6.4

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

Dr. Jan-Peter Richter7. Juli 2009

CEA v6.4© 2008 Capgemini sd&m - All rights reserved

QUASARENTERPRISE_TEIL2_V0.1.PPT2

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



• Umsetzungsorientierte Beratung• Management komplexer IT-Projekte• Software-Engineering

– Gestaltung anspruchsvoller IT-Architekturen– Implementierung von SAP-Lösungen– Rightshore®

– Forschung & Innovation• Partnerschaftliche Arbeitsweise

Unsere Kunden sind namhafte Unternehmen aller Branchen sowieöffentliche Institutionen, deren Erfolg von anspruchsvollen Prozess-und Softwarelösungen abhängtIhr Nutzen besteht in erhöhter Wettbewerbsfähigkeit durch • Differenzierung bei unternehmenskritischen Lösungen• Effizienzverbesserung bestehender Lösungen

Unternehmensentwicklung1

Kunden

Leistungsangebot

• Prozess- und IT-Beratung• Entwicklung individueller Softwarelösungen • Implementierung und Roll-out von Standardsoftware• Systemintegration

Capgemini sd&m steht für leistungsfähige Prozess- und Software-lösungen, die die Wettbewerbsfähigkeit unserer Kunden erhöhen

Standorte

2003 2004 2005

1.475

1.035 1.120

2006

1.210

2007

1.670

2008

1 Anzahl Mitarbeiter im Geschäft inkl. Polen und zugeordnetes Team Indien

Kompetenzen

SAP Business Solutions sd&m Capgemini sd&m

1.920

Hamburg

DüsseldorfKöln/Bonn

Stuttgart

München

Zürich

Frankfurt

Nearshore

Wroclaw

Walldorf

Hannover

Farshore

Mumbai

BangaloreStandorte Capgemini sd&mWeitere Standorte der Capgemini-Gruppe

Berlin

Rightshore® ist ein registriertes Markenzeichen von Capgemini



Namhafte Kunden aller Branchen vertrauen auf unsere Leistungsfähigkeit

Umsatzverteilung in Prozent1

1

9

10

14

15

22

24

Finanzdienst-leistung

Öffentlicher Bereich

5

Telco & Medien

Energie-versorgung

Industrie &Technologie

Logistik, Handel &Transport

Automobil

SonstigeDienstleister

1 Stand: 31. Dezember 2008

AutomobilFinanzdienst-

leistungLogistik, Handel & Transport

Energie-versorgung

Öffentlicher Bereich

Telco &Medien

Industrie & Technologie

• adidas• Deutsche Bahn, Schenker• Deutsche Post• Kühne + Nagel• Tchibo

• Allianz• BayernLB• Commerzbank• DekaBank• HVB• HSH Nordbank• Münchener Rück

• BMW• Continental• Daimler• MAN• TRW• Volkswagen, Audi• Volvo

• Bayerisches Landesamt für Umwelt• Bundesagentur für Arbeit• Bundes-verwaltungsamt

• E.ON• OMV• RWE

• ABB• Cognis• EADS/Airbus• Lanxess• LyondellBasell• Siemens

• Deutsche Telekom• Nokia Siemens Networks• O2• Vodafone• ZDF



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

Wir verbinden Systeme zu integrierten Lösungen, zugeschnitten auf die jeweiligen Kundenanforderungen. Wir übernehmen das übergreifende Projekt-, Architektur-und Testmanagement und kombinieren unser fachliches Prozesswissen mit dem technischen Know-how zu Enterprise Service Bus-, CRM- und BI-Produkten.

System-integration

Unsere Stärken sind Konzeption und Entwicklung maßgeschneiderter Software-lösungen für unternehmenskritische Prozesse – in enger Zusammenarbeit mit unserem Kunden, in hoher Ergebnisqualität, budget- und termintreu.

Individuelle Software-lösungen

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.

Prozess-und IT-Beratung

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.

Implemen-tierungStandard-software



Research entwickelt unsere Software-Engineering-Kompetenzkontinuierlich weiter und stellt Projekten aufbereitetes Wissen bereit

Wir betreiben Innovationen zur systematischen Umsetzung unserer Vorstellung über die künftige Rolle der IT

Methoden• Quasar1 Enterprise• Spezifikation• Qualitätssteuerung• ePM2

Entwicklungsplattform• Projektumgebung• Komponenten auf Open-Source-Basis

• MDD3

Communities• Prozesse• Portale• Enterprise Integration• Datenbanken

Hochschul-Kooperationen• Vorlesungen• Publikationen• Projekte• Diplomarbeiten

Ausbildung• Schools für Entwickler, Architekten, Projektleiter

Innovation/Trends• Web 2.0• Produktkennzahlen• Client Architektur• SOA

1 Quasar = Qualitäts-Software-Architektur2 ePM = Effizientes und effektives Projektmanagement3 MDD = Model Driven Development4 RAIN = Rapid Innovation - globale, serviceorientierte Umgebung für die Auseinandersetzung mit der Zukunft

Projekte

Projekte

RAIN4

Techno-Vision

StudieIT- Trends

For-schungs-projekte

Hoch-schulen

Partner

Kunde

Stiftungs-lehrstuhl5

5 Stiftungslehrstuhl Global Software Engineering an der TU München im Lehrstuhl Informatik



AGENDA

• Capgemini sd&m








BACK-UP

gelungene Architekturen einzelner Anwendungen…

garantieren noch kein gutes Zusammenspiel!

Die Fortentwicklung einer grossen Anwendungslandschaft ist dieHerausforderung für das IT-Management



Anforderungen unterschiedlicher Stakeholder

• 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.

• 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.

• Anwendungslandschaften sind in der Regel historisch gewachsen. Langfristige Organisationsbedürfnisse wurden in frühen und meist auch in späteren Wachstumsphasen nicht berücksichtigt.

• 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.

• Anwendungslandschaften leisten einen Beitrag zum gesamten Unternehmenserfolg. Hierbei gilt es unterschiedliche Interessen ausgewogen zu berücksichtigen.

Gewachsene AnwendungslandschaftMegacity

Natürliches Wachstum

Historischer Kern

Kontinuierlich Funktionsfähig

• Die Anwendungslandschaft stellt eine beträchtliche Investition dar, die geschützt werden muss. Anwendungslandschaften müssen immer funktionieren.

Die Rahmenbedingungen und Herausforderungen von gewachsenenStädten und Anwendungslandschaften sind vergleichbar



Aus der Stadtentwicklung kennen wir für verschiedene Ziele unterschiedliche Instrumente der Planung

Motivation

Strategisch

Stadtentwicklungsplan Bebauungsplan Infrastrukturplan

Operativ

Raumnutzungs-strategien/räumliche Investitionssteuerung

Leitlinien für Themen-felder wie Arbeiten, Wohnen, Ver- und Entsorgung

Art der Bebauung (Wohnhaus, Büro-gebäude etc.), Vor-gaben (Höhe, Frei-flächenanteil etc.)

Auslegung von Straßen, Ver- und Entsorgungs-strukturen etc.

Flächennutzungsplan



Quasar Enterprise bietet Planungsinstrumente zur Gestaltung von Anwendungslandschaften

Motivation: Überblick über die Quasar Enterprise Roadmap

Geschäftsarchitektur

(Geschäftsservices,Geschäftsprozesse,Geschäftsobjekte,Organisation, etc)

Physische AL-Komponenten und ihre Schnittstellen

Physische Anwendungs- und Integrationsplattformen

Logische AL-Komponenten und ihre Schnittstellen

Logische Anwendungs- und Integrationsplattformen

Domänen und (Anwendungs-)Services

Technische Services

IT-StrategieGeschäftsstrategieKontextuell(warum?)

Konzep-tionell(was?)

Logisch(wie?)

Physisch(womit?)

GeschäftInformationssystem (IS) Technische Infrastruktur (TI)

IT

IST

SOLL

IDEAL

I

II Von der Geschäftsarchitektur zur Idealen Anwendungslandschaft

III Integration

IV Integrationsplattformen

II

III IV

V Evolution

V

I

Von der Strategie zur Geschäftsarchitektur



Ableitung von Archi-tekturleitlinien

1. Das Geschäft verstehen

Identifikation von Geschäftsservices


Phase

Bausteine

Bereiche

Quasar Enterprise definiert das Vorgehen von der Geschäftsarchitektur zur Anwendungslandschaft unter Verwendung methodischer Bausteine

2. Das Ideal erstellen

Identifikationvon Domänen

IDEALChristoph Kolumbus Rei sen AG ( CKR )

Leistungs -

einkauf

( LEK )

Kunden -

management

( KUM )

Ver kauf

( VER )

Leistungs -

management

( LEM )

Produktgestaltung

Pauschalr eisen

( PGP )

Produktgestaltung

Indi vidualr eisen

( PGI ) Abwicklung

( ABW )

Rechnungswesen

( REW )

Berichtswesen

( BEW )

Kerngesc

häftRessourcen

Unter-

s tützung

Kunden

-

zugang

Reisebüro

( RBÜ )

Internet

( INT )

Call Center

( CCE )

Planung

( PLA )

Reiseauftr ags -

management

( RAM )

Personalwesen

( PEW )

CKR

LEK

KUM

VER

LEM

PGP

PGI ABW

REW BEW

RBÜ INT CCE

PLA

RAM

PEW

Verfügbarkeit prüfen

Leistungenbuchen

Reiseauft ragpflegen

Kundepflegen

Angebot spreisindiv . berechnen

Individualreisebuchen

Leistungen inhaltl .empfehlen

Leistungenselektieren

Plausibilit ätprüfen

Individualreiseverkaufen

Individualreisezusammenstellen

xxxx

xxxx

xxxx

xxxx

xxxx

xxxx

ANM

VKI

PGP VKP

RAM<<AL >>

Auftrags -management

AUMA

<<AL>>

Pauschal -Preisberechnung

PPRB

<<AL >>

Indi vidualbu -chungssteuerung

IBST

<<AL >>Pauschalbu -

chungssteuerungPBST

Zu migr .

CKR

Ke rngeschäft

REK

KUM

VER

LEM

PGP

PGI ABW

REW BEW

RBÜ INT CCE

PLA

RAM

<<AL>>Reiseauftr ags -management

RAMA

<<AL >>Kunden -

managementKUMA

<<AL >>Hotel -Lager -management

HLMA

<<AL >>

Pauschal -Preisberechnung

PPRB

<<AL>>Indi vidual -

buchungsprozessIBPR

<<AL >>

Reiseportalxxxxxxxx

xxxx REPO

<<AL >>

Indi vidualr eise -Konfigurator

IRKO

<<AL >>

Rechnungswesen

REWE

<<AL>>

Pauschal -buchungsprozess

PBPR

<<AL >>

Berichtswesen

BEWE

<<AL>>Flug- Lager -management

FLMA

<<AL >>Lieferanten -management

LIMA

<< AL>>

Flug -Einkaufspr ozess

FEPR

<<AL >>

Hotel -Einkaufspr ozess

HEPR

<<AL >>

Regulierungs -prozess

REPR...

<<AL>>

Virtuelles -Lager

VILA

<<AL >>

Saison -Planung

SPLA

<<AL>>Call -Center -Buchung

xxxx

xxxx

xxxx CCBU

<<AL >>Reisebüro -buchung

xxxx

xxxx

xxxx RBBU

PEW <<AL>>

Personalwesen

PEWE

<<AL>>

Pauschalr eise -Konfigurator

PRKO

CKR

Kerngeschäft

Res sourcen

Unter-stüt zung

Kunden-

zuga ng

REK VKI

LEM

PGP

PGI ABW

REW BEW

RBÜ INT CCE

PLA

RAM

Kunde

Mittler

KUM

PEW

<<AL>>

Reiseportalxxxx

xxxx

xxxx REPO

<<AL >>Indi vidual -

buchungsprozessIBPR

<<AL >>Indi vidualr eise -Konfigurator

IRKO

<< AL >>

Virtuelles -Lager

VILA

<<AL >>Reiseauftr ags -management

RAMA

<<AL >>

Kunden -management

KUMA

<<AL >>Hotel -Lager -management

HLMA

<<AL >>Flug - Lager -management

FLMA

<< AL>>

Rechnungswesen

REWE

Kundenschnittstelle

BuchungKonfiguration

Auftrags -pflege

Kunden -pflege

Verfügbarkeits -prüfung

Leistungs -buchung

Verbindlichkeits -buchung

Legende Kopplung Schnittstel le

3

2

2

2

3

1 1

x Kopplungsstufe

3. Das Ist erheben und bewerten

Erhebung Ist-Anwendungslandschaft

Identifikation von Handlungsbedarfen für gesteuerte Evolution

IST

4. Die Soll-Architektur erstellen

SOLL

Bestimmung derRoadmap



AGENDA

• Capgemini sd&m








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

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

Hierfür ist kein neuer Begriff notwendig:

• Komponente, Schnittstelle und Operation sind bekannte und definierte Begriffe

Im weiteren Verlauf wird dieses Verständnis von SOA verwendet



Serviceorientierte Architektur ist der Ansatz zur Fortentwicklung der Anwendungslandschaft

Serviceorientierung: Brücke zwischen Geschäft und ITTyp

ische Situation

Heterogene Prozesse

Keine fachli-che Struktur der Anwen-dungen

Komplexe Anwendungs-landschaft

Vielzahl an Plattformen

Chancen durch SOA

Prozesse:Harmonisierung und Flexibilität

Struktur:Komponenten, Zuständigkeiten, Schnittstellen

Infrastruktur:Entkopplung von Anwendungen

Plattformen:Konsolidierung und Effizienz

Kernfelder einer SOA



Was ist eigentlich ein Service: Strikte Konzentration auf die Beschreibung der zu erbringenden Leistung eines Systems

Serviceorientierung: Außensicht eines Systems

System

Teilsystem 2Teilsystem 1

System

Individualreiseverkaufen

Leistungssuche,...

Service 2,Teilsystem 1


PauschalreiseverkaufenKunde

Nutzungs-vereinbarung

Außensicht SystemInnensicht System

(Detaillierung Service A)

Teilsystem 3


Geschäftsprozess

Leistungen empfehlen

Leistungen selektieren

Plausibilität prüfen

Angebotbereit-stellen




erbracht durch

verwendet

Nach Außen als Serviceaktion sichtbar

Nach Außen als Serviceaktion sichtbar



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

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 Überweisungs-formular 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)



AGENDA

• Capgemini sd&m



• Quasar Enterprise – Die Geschäftsarchitektur






Geschäft IT

1


2

Versteht der Architekt das Geschäft, beginnt er ein Idealbild der Anwendungslandschaft zu entwickeln

Ideale Anwendungslandschaft

Ideal

?



IT

Ideal

Flächen-nutzungsplan

Er strukturiert die Anwendungslandschaft in Form von Domänen


Geschäft

1


2

3

Finden von Domänen

3



Domänen bilden einen idealen Ordnungsrahmen für die Komponenten einer Anwendungslandschaft

≥3 >1.000>100Sehr groß

100-1.00030-1002-3Groß

30-10010-301-2Mittel

<30<101Klein

Anzahl AL-Kom-ponenten

Anzahl Domänen

Domänen-tiefe

Größe der AL

Es gibt grobe Erfahrungswerte für die Anzahl von Domänen und AL-Komponenten

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.



IT

Ideal

Stadt-entwicklungs-plan

Geschäft

1


2

3

Identifikation von Anwendungsservices

4

Der Architekt identifiziert Anwendungsservices und ordnet diese den Domänen zu


4



• 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.

Definition

Anwendungs-services

Serviceaktionen• Aktionen sind die Schritte bei der Ausführung eines Anwendungsservice, welche für den Servicenehmer relevant sind.

Anwendungsservices und Serviceaktionen

Anwendungsservices – der Stadtentwicklungsplan



ITGeschäft

1


2

3

Methode: Entwurf von Komponenten

5

4

Im nächsten Schritt plant der Architekt die Bebauung der Domänen mit Komponenten


Kategorien

5 6 7

Regeln: Entwurf von Komponenten

6Ref. Architektur: Kategorisierte An-wendungslandschaft

7

Ideal

Bebauungs-plan



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

Definition

Anwendungsland-schaftskomponente

AL-Komponenten

Komponenten in der AL – der Bebauungsplan



Referenzarchitektur für Anwendungslandschaften

Komponenten in der AL – der Bebauungsplan

Die Trennung der Prozesslogik von Funktions- und Bestands-komponenten ist eine der wichtigsten architektonischen Maßnahmen zur Gestaltung von Anwendungslandschaften.

• 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



IT-Architektur/AnwendungslandschaftGeschäft


Methode: Entwurf von Schnittstellen

8

Regeln: Entwurf von Schnittstellen

9

Regeln: GestaltungKopplungsarchitektur

10

Infrastrukturplan

Danach plant er Schnittstellen und Kopplungsarchitektur


1 2 3 4

Regeln

5 6 7 8 9 10

Ideal



Schnittstellen

Schnittstellen der AL – der Infrastrukturplan

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.

Definition

Schnittstellen



AGENDA

• Capgemini sd&m









Kennt der Architekt das Ideal, stellt er dies als Gegenpol den rein operativ-geschäftsgetriebenen Zielen gegenüber

Evolutionsplanung (Soll-Architektur und Roadmap)

1 2 3 4 5 6 7 8 9 10

IT-Architektur/Anwendungslandschaft

Entwicklungder Anwendungs-

landschaft

Schneller € Ideal



Als Balance zwischen diesen beiden Bedürfnissen plant er die Entwick-lung der Anwendungslandschaft


IT-Architektur / Anwendungslandschaft

„GesteuerteEvolution“

IdealeArchitektur

Schneller€

SOLL

IST

Verbesserung der operativen Geschäfts-unterstützung durch die Anwendungs-

landschaft

Verbesserte Ausrichtung der An-wendungslandschaft am strate-gischen Ideal von Geschäft und IT

Operative (und primär geschäftsgetriebene)

Entwicklung

Strategische(und primär IT-orientierte) Entwicklung

Idealer Korridorder Balance

(wird konkret über Projekte angestrebt)

1 2 3 4 5 6 7 8 9 10



IT

Hat der Architekt seine Planungsinstrumente beisammen, führt er in mehreren Schritten die Evolutionsplanung durch


1 2 3 4 5 6 7 8 9 10

Erhebung Ist-Anwendungs-landschaft

15

Erhebung der Ist-AL

15

Ist-AL

15

Bewertung Ist-Anwendungs-landschaft

16

Bewertung der Ist-AL

16

Bewertete Ist-AL/Handlungsbedarfe

16

BestimmungHauptszenarien

17

IDEAL

€

SOLL

IST

Bestimmungvon Haupt-szenarien

17

Hauptszenarien

17

BestimmungSoll-Anwen-dungslandschaft

18

Soll-AL

Bestimmung der Soll-AL

18

18

BestimmungRoadmap

19

Referenz-szenarien

20

Bestimmungder Roadmap

19

Roadmap (vom Ist zum Soll)

20

19 20



Diese Planung der Evolution führt der Architektsystematisch in mehreren Schritten durch.


IT

Erhebung der Ist-AL

15

Ist-AL


16



17

Hauptszenarien

Soll-AL


18


19


20


15



Die Ist-Erhebung konzentriert sich auf die physische IS-Architektur und setzt den Bezug zu Ideal und TI

Erhebung der Ist-Anwendungslandschaft

Domäne KategorieLogische AL-Kompo-

nente

Logische Schnittstelle

(Ideal)

Geschäfts-objekt

realisiert

hat

stellt Servicesbereit für

realisiert

verwaltet

verantwortet imp./exp.

Bezug zum Ideal

Organisations-Einheit (AM)

PhysischeAL-Kompo-

nente

Physische Schnittstelle

Schnittstellen-art

verantwortet imp./exp. ist von

Physische Kopplung

realisiert Zugriff auf

nutzt

Organisations-Einheit (IM)

Anwendungs-plattform

PhysischeHardware-plattform

Technischer Integrations-

Service

Integrations-plattform

LogischeHardware-plattform

verantwortet

läuftauf

implementiert

läuft auf

läuftauf

Kernbereich(IS Physisch)

Plattform/Strategie



Die physische AL-Komponente ist das Bindeglied zwischen der dem Ideal, der IS- und der TI-Architektur


Querschnittl. Funktionen

Produktauslieferung

Produktinfoportal

Systemkomponente BEA

Präsentation

APPPROD2 APPPROD3APPPROD1

Logischer Rechner BEA

Produktinfoportal

Produktinfoportal



Schritte

Festlegung des rele-vanten AL-Komponenten

Festlegung der relevanten Erhebungskriterien

Definition der Steckbriefe

Ausfüllen der Steckbriefe

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.

Steckbriefe sind die Basis strukturierter Interviews. Steckbriefe sollten 5 DINA4 Seiten nicht überschreiten.

Pro AL-Komponente wird für die Durchführung und Nachbereitung der Interviews ca. 1 Bearbeitertag benötigt.

Die Erhebung einer Ist-Anwendungslandschaft erfolgt sinnvoller weise in vier Schritten




Best Practices bei der 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.

• 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.




Nach der Erhebung der Ist-Anwendungslandschaft bewertet der Architekt diese

Evolutionsplanung

IT

Erhebung der Ist-AL

15

Ist-AL


16



17

Hauptszenarien

Soll-AL


18


19


20


15


16



Die Bewertung der Ist-Anwendungslandschaft erfolgt aus zwei Perspektiven

Bewertung der Ist-Anwendungslandschaft

IT-Architektur/Anwendungslandschaft

Entwicklungder Anwendungs-

landschaft

Schneller €

Bewertung der Ist-Anwendungslandschaft im Hinblick auf die operativen ( und primär geschäftsgetriebenen) Ziele und Anforderungen.

Ideal

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.



Domänenreinheit Können die physischen AL-Komponenten eindeutig einer Domäne zugeordnet werden?

Hinsichtlich der Bewertung am Ideal ergeben sich die Kriterien direkt aus den Regeln zu deren Gestaltung.


Fachliche Strukturierung

Kategorienreinheit

Abhängigkeiten gemäßKategorien

Keine zyklischen Abhängigkeiten

Enger Zusammenhalt

Datenhoheit

AngemessenerKopplungsgrad

Funktionale Redundanz

1

2

3

4

5

6

7

8

9

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.



Die Bewertungskriterien bezüglich der Plattformstrategie beziehen sich auf die Effizienz der IT


Homogenität derTechnologie Ist die Anzahl unterschiedlicher im Einsatz befindlicher Technologien sinnvoll?

Homogenität der Plattform

Homogenität der Anbieten

1

2

3

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?



Das Ergebnis einer bewerteten Ist-Anwendungslandschaft sind konkrete 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


Beispiele für Handlungsbedarfe



Aus den Handlungsbedarfen leitet der Architekt eine oder mehrereHauptszenarien ab und bestimmt die Soll-AL


IT


15

Erhebung der Ist-AL

15

Ist-AL


16


16


IDEAL

€

SOLL

IST


17

Hauptszenarien

Soll-AL


18


19



17


18



Die Bestimmung von Hauptszenarien erfolgt in drei Schritten

Bestimmung der Hauptszenarien und der Soll-Anwendungslandschaft

Alternative B

• Auswahl eines strategischen (und primär IT-getriebenen) Handlungs-bedarfs

• Ermittlung des davon betroffenen Bereichs der Anwendungslandschaft

• Ergänzung passender Maßnahmen des operativen (und primär geschäftsgetriebener) Bereichs

Alternative A

• Auswahl eines oder mehrerer opera-tiver (und primär geschäftsgetrie-bener) Handlungsbedarfe

• Ermittlung des davon betroffenen Bereichs der Anwendungslandschaft

• Ergänzung passender Maßnahmen für diesen Bereich anhand strate-gischer (und primär IT-getriebener) Handlungsbedarfe.

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



Definition

Soll-Anwendungs-landschaft

Die Soll-Anwendungslandschaft definiert ein zu erreichendes Zwischenziel, zu dem die physische Ist-Anwendungslandschaft umgebaut werden soll.

Auf Basis der Hauptszenarien entwickeln wir die Soll-Anwendungslandschaft in drei Schritten

Bestimmung der Hauptszenarien und der Soll-Anwendungslandschaft

• 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)



Schließlich bestimmt der Architekt die einzelnen Schritte und Stufen zum Soll, d.h. die Roadmap


IT


15

Erhebung der Ist-AL

15

Ist-AL


16


16



17

IDEAL

€

SOLL

IST


17

Hauptszenarien


18

Soll-AL


18

BestimmungRoadmap

19

Referenz-szenarien

20


19




Definition

RoadmapDie Roadmap ist die qualitative und quantitative Beschreibung des Wegs von der Ist-zur Soll-Anwendungslandschaft.

Die Roadmap plant die notwendigen Schritte zur Umgestaltung der Anwendungslandschaft auf

Bestimmung der Roadmap


Soll-AL

Festlegung der Schritte

Festlegung der Stufen (Risiken/Kosten)

Quantifizierung


�

�

Referenz-szenarien



Wenn das Soll eine neu zu erstellende oder zu verändernde Bestandskomponente vorsieht, sollte dieser Umbau als erstes erfolgen.

Neue Bestands-komponentenzuerst

1

Referenzszenarien der Evolutionsplanung geben Best-Practices für die zeitliche Anordnung von Schritten


AL-KomponenteA

AL-KomponenteC

??

Datenverwendung

??

AL-KomponenteB

Neu erstellt

ServiceNutzung

ServiceNutzung

Datenverwendung

Bestandskomponente Nicht kategorienreinU

Implementiert Services von der Kategorie Bestand

Abklemmen der Pflegefunktionalität

ÜbergangsweiseIntegration

Datenversorgung



Service

Nutzung

Referenzszenarien der Evolutionsplanung geben Best-Practices für die zeitliche Anordnung von Schritten


Migriere die Anwendungsservices unterstützender Geschäftsservices vor Kerngeschäftsservices

Unterstützende vor Kerngeschäfts-services

2

AL-KomponenteA

KU

Komponente mitKernfunkt.

Komponente mitunterstützenderFunktionalitätUK KU

Komponente mitgemischterFunktionalität

AL-KomponenteB

U

Verändert

2x Verändert oder neu erstellt

Neuerstellt

AL-Komponente

A~

K

Service

Nutzung



Soll

Referenzszenarien geben Schrittfolgen in unterschiedlichen Dimensionen vor, die verschränkt werden können


ReferenzszenarioBestandskompo-nenten zuerst

Referenzszenario Unterstützungs-vor Kernfunktionen

IST

Bestandskompo-nente neu

Übergangsweise Integration

U

Änderung derI-Architektur

Ideale Zentrali-sierung

Unterstützende Komp. neu

Übergangsweise Integration

IdealeTrennung

KU U

K U



Definition

Fachliche Partitionierung

Die richtige Schrittfolge ist Basis für die Bestimmung der Stufen


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.

• 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

• Bringt die Inbetriebnahme eines Schritts keinen wesentlichen Nutzen, überprüft man, inwieweit sich mehrere Schritte zu einer Stufe zusammenfassen lassen.



Die qualitative Roadmap beschreibt die durchzuführenden Schritte und Stufen vom Ist zum Soll




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




IT

1 2 3 4 5 6 7 8 9 10

Damit ist dann eine schrittweise Entwicklung einer Anwendungslandschaft möglich


15 16 17 18 19 20

Ist

Hotel-Einkaussystem(HES)

L (Datei)

D (DB#1)

Hotelleistungabfragen

VK-Preisberechnungssystem

(VPS)

D (DB#1)

Hotel-Verfügbarkeitssystem

(HVS)

Flug-Einkaufs- und Verfügbarkeitssystem

(FES)

D (DB#1)

VerfügbarkeitprüfenRessource belegen

Flugleistungabfragen

Preise abfragen

Vakanzprüfungs- und Buchungssystem

(VBS)

D (DB#1)

Kundenabfragen

Internet-Verkaufs-Client

(IVC)

Reisebüro-Verkaufs-Client(Buchungsdialoge)

(RVC)

D (DB#1)

Kontingenteübergeben

D (DB#1)

Verfügbarkeit prüfenRessource belegen

Daten-Kopier-System(DKS)

D (DB#2)

Reiseauftragabfragen

Rechnungs-erstellungssystem

(RES)

Kunden-dokumentesystem

(KDS)

Hotelleistungübergeben

Angebotabfragen

Buchen L

Hotel-Einkäufer-Laptop

(HEL)


Hotel-Regulierungssystem(HRS)


<<AL>>

<<AL>>

<<AL>>

<<AL>>

<<AL>>

<<AL>> <<AL>><<AL>>

<<AL>>

<<AL>><<AL>>

<<AL>>

Planungssystem(PLA)

<<AL>>

D (DB#1)Planungabfragen

Planungabfragen

Vom

Soll

IDEAL

Hotel-Einkaussystem(HES)

L (Datei)

D (DB#1)

HotelleistungabfragenProduktabfragen

VK-Preisberechnungs-system (VPS)

D (DB#1)

Hotel-Verfügbarkeitssystem

(HVS)

Flug-Einkaufs- und Verfügbarkeitssystem

(FES)

D (DB#1)

VerfügbarkeitprüfenRessource belegen

Flugleistungabfragen

Preise abfragen

Vakanzprüfungs- und Buchungssystem

(VBS)

D (DB#1)

Reiseportal(REPO)

Reisebüro-Verkaufs-Client(Buchungsdialoge)

(RVC)

D (DB#1)

Kontingenteübergeben

D (DB#1)

Verfügbarkeit prüfenRessource belegen

Daten-Kopier-System(DKS)

D (DB#2)


Rechnungs-erstellungssystem

(RES)

Kunden-dokumentesystem

(KDS)

Hotelleistungübergeben

Buchen

L

Hotel-Einkäufer-Laptop

(HEL)


Hotel-Regulierungssystem

(HRS)


<<AL>>

<<AL>>

<<AL>>

<<AL>>

<<AL>>

<<AL>> <<AL>><<AL>>

<<AL>>

<<AL>><<AL>>

<<AL>>

Planungssystem(PLA)

<<AL>>

D (DB#1)Planungabfragen

Planungabfragen

Individualreise-Konfigurator

(IRKO)

ProduktedefinierenPlausibilitätprüfenPreiseberechnen

<<AL>>Adapter

Kundenmanagement(KUMA)

<<AL>>

Kunde pflegenKunde abfragen

Adapter

L (ESB)

L (ESB)Virtuelles Lager

(VILA)

<<AL>>

Leistungbuchen

L (ESB)

Adapter

AdapterAdapter

xxx xxxxxxx x xxx xx xx xxxxxxxxxxxx xx xxxxxxxx x x x x c xxx xcxxxxx xxxxxx

Individualbuchungs-prozess(IBPR)

<<AL>>

Buchen

L (ESB)

Zum

Ideal

Orientiertam



AGENDA

• Capgemini sd&m









IT

Soll Referenzszenarien

1 2 3 4 5 6 7 8 9 10

Gestaltung derIntegrations-architektur

11

15 16 17 18 19 20

Hat der Architekt das Soll ermittelt, muss er Integrationsarchitektur und Integrationsplattformen ergänzen

Integration und Integrationsplattformen

11 12 13 14

Integrations-muster

12

Referenzarchi-tektur Integra-tionsplattformen

13

Auswahl vonIntegrations-plattformen

14

Referenzszenarien der Evolution (Details)

20

Integrationsarchitektur



Definition

Physische Kopplung

Die physische Kopplung ist die technische Realisierung des Zugriffs einer AL-Komponente auf die physische Schnittstelle einer zweiten AL-Kompo-nente. Dieser Zugriff geschieht unter Zuhilfenahme technischer Services, insbesondere für Kommunikation und Transformation.

Für die Integrationsarchitektur ergänzt der Architekt die Schnittstellen des Solls um Integrationsart und technische Services




Techniken für die physische Kopplung von Anwendungssystemen gibt es wie Sand am Meer


SAP RFC / Idoc

WebSphere MQ

Java RMI

CORBA / IIOP

Web Services / SOAP / HTTP

ONC (SUN) RPC

DCE

ETL

JSR 168 / Portlet

TuxedoPublish / Subscribe Middleware

Im schlimmsten Fall finden wir sie alle in einer Anwendungslandschaft!

…

…

…

FTP / Dateitransfer / File Sharing



Festlegung von Physischer Kopplung ohne systematisches Vorgehen führt ins Chaos


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 abschnitts-weise in den Anwendungen versteckt

Änderung der Geschäftsprozesse schwierig



Definition

Arten von Schnittstellen

Eine wesentliche Säule für ein systematisches Vorgehen ist die Festlegung der Kopplungsart

Wir unterscheiden drei Kopplungsarten. Diese werdenbenannt nach den Arten der physischen Schnittstellen, über die gekoppeltwird: Präsentations-, Logik- oder Datenkopplung.

Wir unterscheiden drei Arten von physischen Schnittstellen:

(1) Präsentation (P): Die technische Repräsentation einer Benutzerschnitt-stelle der AL-Komponente

(2) Logik (L): Eine funktionale Schnittstelle zum Zugriff auf in der AL-Kompo-nente gekapselte Geschäftslogik

(3) Daten (D): Ein Direktzugriff auf persistente Daten der AL-Komponente

Entsprechend ihrer Art nennen wir diese Schnitt-stellen auch Präsentations-, Logik- bzw. Datenschnittstellen.


Kopplungsarten



Technische Services der Integrationsarchitektur

Eine weitere Säule ist die Identifikation der für die physische Kopplung benötigten technischen Services

• 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

– …



Auf dieser Basis kann der Architekt die Integrationsarchitektur erstellen

Identifikation der zu realisierenden und zu ändernden AL-Komponenten auf Basis eines Abgleichs zwischen Ist und Soll

Entscheidung fällen, ob die Umsetzung von Änderungs-bedarfen über individuelle Neuentwicklung, Anpassung existierender Komponenten, Verwendung von COTS-Produkten oder durch Orchestrierung erfolgen soll

Feinschliff der Integrationsarchitektur durch Anwendung von Best-Practices zur Integration

Festlegung, welche Art der Integration für die jeweilige Aufgabe sinnvoll ist

Festlegung der benötigten technischen Services

Abgleich mit der Referenzarchitektur von Integrationsplatt-formen und Nutzungskonzepten vorhandener Integrations-plattformen

Identifikation des Integrationsumfangs

RealisierungsformKonventionell vs. Orchestrierung:

Integrationsmuster anwenden

Verbleibende Schnittstellen festlegen

Gestaltung der physischen Kopplung

Finalisieren

Methode zur Erstellung einer Integrationsarchitektur



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.

Die benötigten technischen Services sind Basis für die Auswahl der Integrationsplattform(en)




Sicht: Technische Services für die Logikintegration

Für jede Integrationsart existiert eine Sicht auf die Referenzarchitektur für Integrationsplattformen – Logik




Sicht: Technische Services für die Präsentationsintegration

Für jede Integrationsart existiert eine Sicht auf die Referenzarchitektur für Integrationsplattformen – Präsentation




Für jede Integrationsart existiert eine Sicht auf die Referenzarchitektur für Integrationsplattformen – Daten

Sicht: Technische Services für die Datenintegration




Die Referenzarchitektur bietet einen Kartengrund für Produktlandkarten




Quasar Enterprise ist der Reiseführer zur Gestaltung von Anwendungslandschaften

Quasar Enterprise


(Geschäftsservices,Geschäftsprozesse,Geschäftsobjekte,Organisation, etc)

Physische AL-Komponenten und ihre Schnittstellen

Physische Anwendungs- und Integrationsplattformen

Logische AL-Komponenten und ihre Schnittstellen

Logische Anwendungs- und Integrationsplattformen

Domänen und (Anwendungs-)Services

Technische Services

IT-StrategieGeschäftsstrategieKontextuell(warum?)

Konzep-tionell(was?)

Logisch(wie?)

Physisch(womit?)

GeschäftInformationssystem (IS) Technische Infrastruktur (TI)

IT

IST

SOLL

IDEAL

I

II Von der Geschäftsarchitektur zur Idealen Anwendungslandschaft

III Integration

IV Integrationsplattformen

II

III IV

V Evolution

V

I

Von der Strategie zur Geschäftsarchitektur



Und diesen Reiseführer gibt es auch als Buch

Quasar Enterprise

CEA v6.4

Zusammen. Für nachhaltigen Erfolg.

Quasar Enterprise Anwendungslandschaften …agis- · Rechnungswesen (REW ) Berichtswesen ... und...

Documents

Transcript of Quasar Enterprise Anwendungslandschaften …agis- · Rechnungswesen (REW ) Berichtswesen ... und...