CEA v6.4 Quasar Enterprise Anwendungslandschaften serviceorientiert gestalten – Teil 2: Gesteuerte Evolution und Integrationsarchitektur Dr. Jan-Peter Richter 7. Juli 2009
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
CEA v6.4© 2008 Capgemini sd&m - All rights reserved
QUASARENTERPRISE_TEIL2_V0.1.PPT3
• 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
CEA v6.4© 2008 Capgemini sd&m - All rights reserved
QUASARENTERPRISE_TEIL2_V0.1.PPT4
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
CEA v6.4© 2008 Capgemini sd&m - All rights reserved
QUASARENTERPRISE_TEIL2_V0.1.PPT5
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
CEA v6.4© 2008 Capgemini sd&m - All rights reserved
QUASARENTERPRISE_TEIL2_V0.1.PPT6
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
CEA v6.4© 2008 Capgemini sd&m - All rights reserved
QUASARENTERPRISE_TEIL2_V0.1.PPT7
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
CEA v6.4© 2008 Capgemini sd&m - All rights reserved
QUASARENTERPRISE_TEIL2_V0.1.PPT8
BACK-UP
gelungene Architekturen einzelner Anwendungen…
garantieren noch kein gutes Zusammenspiel!
Die Fortentwicklung einer grossen Anwendungslandschaft ist dieHerausforderung für das IT-Management
CEA v6.4© 2008 Capgemini sd&m - All rights reserved
QUASARENTERPRISE_TEIL2_V0.1.PPT9
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
CEA v6.4© 2008 Capgemini sd&m - All rights reserved
QUASARENTERPRISE_TEIL2_V0.1.PPT10
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
CEA v6.4© 2008 Capgemini sd&m - All rights reserved
QUASARENTERPRISE_TEIL2_V0.1.PPT11
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
CEA v6.4© 2008 Capgemini sd&m - All rights reserved
QUASARENTERPRISE_TEIL2_V0.1.PPT12
Ableitung von Archi-tekturleitlinien
1. Das Geschäft verstehen
Identifikation von Geschäftsservices
Geschäftsarchitektur
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
CEA v6.4© 2008 Capgemini sd&m - All rights reserved
QUASARENTERPRISE_TEIL2_V0.1.PPT13
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
CEA v6.4© 2008 Capgemini sd&m - All rights reserved
QUASARENTERPRISE_TEIL2_V0.1.PPT14
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
CEA v6.4© 2008 Capgemini sd&m - All rights reserved
QUASARENTERPRISE_TEIL2_V0.1.PPT15
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
CEA v6.4© 2008 Capgemini sd&m - All rights reserved
QUASARENTERPRISE_TEIL2_V0.1.PPT16
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
Service 1,Teilsystem 2
PauschalreiseverkaufenKunde
Nutzungs-vereinbarung
Außensicht SystemInnensicht System
(Detaillierung Service A)
Teilsystem 3
Service 1,Teilsystem 3
Geschäftsprozess
Leistungen empfehlen
Leistungen selektieren
Plausibilität prüfen
Angebotbereit-stellen
Nutzungs-vereinbarung
Nutzungs-vereinbarung
Nutzungs-vereinbarung
erbracht durch
verwendet
Nach Außen als Serviceaktion sichtbar
Nach Außen als Serviceaktion sichtbar
CEA v6.4© 2008 Capgemini sd&m - All rights reserved
QUASARENTERPRISE_TEIL2_V0.1.PPT17
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)
CEA v6.4© 2008 Capgemini sd&m - All rights reserved
QUASARENTERPRISE_TEIL2_V0.1.PPT18
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
CEA v6.4© 2008 Capgemini sd&m - All rights reserved
QUASARENTERPRISE_TEIL2_V0.1.PPT19
Geschäft IT
1
Geschäftsarchitektur
2
Versteht der Architekt das Geschäft, beginnt er ein Idealbild der Anwendungslandschaft zu entwickeln
Ideale Anwendungslandschaft
Ideal
?
CEA v6.4© 2008 Capgemini sd&m - All rights reserved
QUASARENTERPRISE_TEIL2_V0.1.PPT20
IT
Ideal
Flächen-nutzungsplan
Er strukturiert die Anwendungslandschaft in Form von Domänen
Ideale Anwendungslandschaft
Geschäft
1
Geschäftsarchitektur
2
3
Finden von Domänen
3
CEA v6.4© 2008 Capgemini sd&m - All rights reserved
QUASARENTERPRISE_TEIL2_V0.1.PPT21
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.
CEA v6.4© 2008 Capgemini sd&m - All rights reserved
QUASARENTERPRISE_TEIL2_V0.1.PPT22
IT
Ideal
Stadt-entwicklungs-plan
Geschäft
1
Geschäftsarchitektur
2
3
Identifikation von Anwendungsservices
4
Der Architekt identifiziert Anwendungsservices und ordnet diese den Domänen zu
Ideale Anwendungslandschaft
4
CEA v6.4© 2008 Capgemini sd&m - All rights reserved
QUASARENTERPRISE_TEIL2_V0.1.PPT23
• 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
CEA v6.4© 2008 Capgemini sd&m - All rights reserved
QUASARENTERPRISE_TEIL2_V0.1.PPT24
ITGeschäft
1
Geschäftsarchitektur
2
3
Methode: Entwurf von Komponenten
5
4
Im nächsten Schritt plant der Architekt die Bebauung der Domänen mit Komponenten
Ideale Anwendungslandschaft
Kategorien
5 6 7
Regeln: Entwurf von Komponenten
6Ref. Architektur: Kategorisierte An-wendungslandschaft
7
Ideal
Bebauungs-plan
CEA v6.4© 2008 Capgemini sd&m - All rights reserved
QUASARENTERPRISE_TEIL2_V0.1.PPT25
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
CEA v6.4© 2008 Capgemini sd&m - All rights reserved
QUASARENTERPRISE_TEIL2_V0.1.PPT26
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
CEA v6.4© 2008 Capgemini sd&m - All rights reserved
QUASARENTERPRISE_TEIL2_V0.1.PPT27
IT-Architektur/AnwendungslandschaftGeschäft
Geschäftsarchitektur
Methode: Entwurf von Schnittstellen
8
Regeln: Entwurf von Schnittstellen
9
Regeln: GestaltungKopplungsarchitektur
10
Infrastrukturplan
Danach plant er Schnittstellen und Kopplungsarchitektur
Ideale Anwendungslandschaft
1 2 3 4
Regeln
5 6 7 8 9 10
Ideal
CEA v6.4© 2008 Capgemini sd&m - All rights reserved
QUASARENTERPRISE_TEIL2_V0.1.PPT28
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
CEA v6.4© 2008 Capgemini sd&m - All rights reserved
QUASARENTERPRISE_TEIL2_V0.1.PPT29
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
CEA v6.4© 2008 Capgemini sd&m - All rights reserved
QUASARENTERPRISE_TEIL2_V0.1.PPT30
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
CEA v6.4© 2008 Capgemini sd&m - All rights reserved
QUASARENTERPRISE_TEIL2_V0.1.PPT31
Als Balance zwischen diesen beiden Bedürfnissen plant er die Entwick-lung der Anwendungslandschaft
Evolutionsplanung (Soll-Architektur und Roadmap)
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
CEA v6.4© 2008 Capgemini sd&m - All rights reserved
QUASARENTERPRISE_TEIL2_V0.1.PPT32
IT
Hat der Architekt seine Planungsinstrumente beisammen, führt er in mehreren Schritten die Evolutionsplanung durch
Evolutionsplanung (Soll-Architektur und Roadmap)
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
CEA v6.4© 2008 Capgemini sd&m - All rights reserved
QUASARENTERPRISE_TEIL2_V0.1.PPT33
Diese Planung der Evolution führt der Architektsystematisch in mehreren Schritten durch.
Evolutionsplanung (Soll-Architektur und Roadmap)
IT
Erhebung der Ist-AL
15
Ist-AL
Bewertung der Ist-AL
16
Bewertete Ist-AL/Handlungsbedarfe
Bestimmungvon Haupt-szenarien
17
Hauptszenarien
Soll-AL
Bestimmung der Soll-AL
18
Bestimmungder Roadmap
19
Roadmap (vom Ist zum Soll)
20
Erhebung Ist-Anwendungs-landschaft
15
CEA v6.4© 2008 Capgemini sd&m - All rights reserved
QUASARENTERPRISE_TEIL2_V0.1.PPT34
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
CEA v6.4© 2008 Capgemini sd&m - All rights reserved
QUASARENTERPRISE_TEIL2_V0.1.PPT35
Die physische AL-Komponente ist das Bindeglied zwischen der dem Ideal, der IS- und der TI-Architektur
Erhebung der Ist-Anwendungslandschaft
Querschnittl. Funktionen
Produktauslieferung
Produktinfoportal
Systemkomponente BEA
Präsentation
APPPROD2 APPPROD3APPPROD1
Logischer Rechner BEA
Produktinfoportal
Produktinfoportal
CEA v6.4© 2008 Capgemini sd&m - All rights reserved
QUASARENTERPRISE_TEIL2_V0.1.PPT36
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
Erhebung der Ist-Anwendungslandschaft
CEA v6.4© 2008 Capgemini sd&m - All rights reserved
QUASARENTERPRISE_TEIL2_V0.1.PPT37
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.
Erhebung der Ist-Anwendungslandschaft
CEA v6.4© 2008 Capgemini sd&m - All rights reserved
QUASARENTERPRISE_TEIL2_V0.1.PPT38
Nach der Erhebung der Ist-Anwendungslandschaft bewertet der Architekt diese
Evolutionsplanung
IT
Erhebung der Ist-AL
15
Ist-AL
Bewertung der Ist-AL
16
Bewertete Ist-AL/Handlungsbedarfe
Bestimmungvon Haupt-szenarien
17
Hauptszenarien
Soll-AL
Bestimmung der Soll-AL
18
Bestimmungder Roadmap
19
Roadmap (vom Ist zum Soll)
20
Erhebung Ist-Anwendungs-landschaft
15
Bewertung Ist-Anwendungs-landschaft
16
CEA v6.4© 2008 Capgemini sd&m - All rights reserved
QUASARENTERPRISE_TEIL2_V0.1.PPT39
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.
CEA v6.4© 2008 Capgemini sd&m - All rights reserved
QUASARENTERPRISE_TEIL2_V0.1.PPT41
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.
Bewertung der Ist-Anwendungslandschaft
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.
CEA v6.4© 2008 Capgemini sd&m - All rights reserved
QUASARENTERPRISE_TEIL2_V0.1.PPT42
Die Bewertungskriterien bezüglich der Plattformstrategie beziehen sich auf die Effizienz der IT
Bewertung der Ist-Anwendungslandschaft
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?
CEA v6.4© 2008 Capgemini sd&m - All rights reserved
QUASARENTERPRISE_TEIL2_V0.1.PPT43
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
Bewertung der Ist-Anwendungslandschaft
Beispiele für Handlungsbedarfe
CEA v6.4© 2008 Capgemini sd&m - All rights reserved
QUASARENTERPRISE_TEIL2_V0.1.PPT44
Aus den Handlungsbedarfen leitet der Architekt eine oder mehrereHauptszenarien ab und bestimmt die Soll-AL
Evolutionsplanung (Soll-Architektur und Roadmap)
IT
Erhebung Ist-Anwendungs-landschaft
15
Erhebung der Ist-AL
15
Ist-AL
Bewertung Ist-Anwendungs-landschaft
16
Bewertung der Ist-AL
16
Bewertete Ist-AL/Handlungsbedarfe
IDEAL
€
SOLL
IST
Bestimmungvon Haupt-szenarien
17
Hauptszenarien
Soll-AL
Bestimmung der Soll-AL
18
Bestimmungder Roadmap
19
Roadmap (vom Ist zum Soll)
BestimmungHauptszenarien
17
BestimmungSoll-Anwen-dungslandschaft
18
CEA v6.4© 2008 Capgemini sd&m - All rights reserved
QUASARENTERPRISE_TEIL2_V0.1.PPT45
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
CEA v6.4© 2008 Capgemini sd&m - All rights reserved
QUASARENTERPRISE_TEIL2_V0.1.PPT46
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)
CEA v6.4© 2008 Capgemini sd&m - All rights reserved
QUASARENTERPRISE_TEIL2_V0.1.PPT48
Schließlich bestimmt der Architekt die einzelnen Schritte und Stufen zum Soll, d.h. die Roadmap
Evolutionsplanung (Soll-Architektur und Roadmap)
IT
Erhebung Ist-Anwendungs-landschaft
15
Erhebung der Ist-AL
15
Ist-AL
Bewertung Ist-Anwendungs-landschaft
16
Bewertung der Ist-AL
16
Bewertete Ist-AL/Handlungsbedarfe
BestimmungHauptszenarien
17
IDEAL
€
SOLL
IST
Bestimmungvon Haupt-szenarien
17
Hauptszenarien
BestimmungSoll-Anwen-dungslandschaft
18
Soll-AL
Bestimmung der Soll-AL
18
BestimmungRoadmap
19
Referenz-szenarien
20
Bestimmungder Roadmap
19
Roadmap (vom Ist zum Soll)
CEA v6.4© 2008 Capgemini sd&m - All rights reserved
QUASARENTERPRISE_TEIL2_V0.1.PPT49
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
Bewertete Ist-AL/Handlungsbedarfe
Soll-AL
Festlegung der Schritte
Festlegung der Stufen (Risiken/Kosten)
Quantifizierung
Roadmap (vom Ist zum Soll)
�
�
Referenz-szenarien
CEA v6.4© 2008 Capgemini sd&m - All rights reserved
QUASARENTERPRISE_TEIL2_V0.1.PPT50
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
Bestimmung der Roadmap
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
CEA v6.4© 2008 Capgemini sd&m - All rights reserved
QUASARENTERPRISE_TEIL2_V0.1.PPT51
Service
Nutzung
Referenzszenarien der Evolutionsplanung geben Best-Practices für die zeitliche Anordnung von Schritten
Bestimmung der Roadmap
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
CEA v6.4© 2008 Capgemini sd&m - All rights reserved
QUASARENTERPRISE_TEIL2_V0.1.PPT52
Soll
Referenzszenarien geben Schrittfolgen in unterschiedlichen Dimensionen vor, die verschränkt werden können
Bestimmung der Roadmap
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
CEA v6.4© 2008 Capgemini sd&m - All rights reserved
QUASARENTERPRISE_TEIL2_V0.1.PPT53
Definition
Fachliche Partitionierung
Die richtige Schrittfolge ist Basis für die Bestimmung der Stufen
Bestimmung der Roadmap
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.
CEA v6.4© 2008 Capgemini sd&m - All rights reserved
QUASARENTERPRISE_TEIL2_V0.1.PPT54
Die qualitative Roadmap beschreibt die durchzuführenden Schritte und Stufen vom Ist zum Soll
Bestimmung der Roadmap
CEA v6.4© 2008 Capgemini sd&m - All rights reserved
QUASARENTERPRISE_TEIL2_V0.1.PPT55
Die quantitative Roadmap beschreibt Umfang und Zeitplan für die Durchführung der Aktivitäten
Bestimmung der Roadmap
CEA v6.4© 2008 Capgemini sd&m - All rights reserved
QUASARENTERPRISE_TEIL2_V0.1.PPT57
IT
1 2 3 4 5 6 7 8 9 10
Damit ist dann eine schrittweise Entwicklung einer Anwendungslandschaft möglich
Evolutionsplanung (Soll-Architektur und Roadmap)
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)
Hotelleistungabfragen
Hotel-Regulierungssystem(HRS)
Reiseauftragabfragen
<<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)
Reiseauftragabfragen
Rechnungs-erstellungssystem
(RES)
Kunden-dokumentesystem
(KDS)
Hotelleistungübergeben
Buchen
L
Hotel-Einkäufer-Laptop
(HEL)
Hotelleistungabfragen
Hotel-Regulierungssystem
(HRS)
Reiseauftragabfragen
<<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
CEA v6.4© 2008 Capgemini sd&m - All rights reserved
QUASARENTERPRISE_TEIL2_V0.1.PPT58
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
CEA v6.4© 2008 Capgemini sd&m - All rights reserved
QUASARENTERPRISE_TEIL2_V0.1.PPT59
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
CEA v6.4© 2008 Capgemini sd&m - All rights reserved
QUASARENTERPRISE_TEIL2_V0.1.PPT60
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
Integration und Integrationsplattformen
CEA v6.4© 2008 Capgemini sd&m - All rights reserved
QUASARENTERPRISE_TEIL2_V0.1.PPT62
Techniken für die physische Kopplung von Anwendungssystemen gibt es wie Sand am Meer
Integration und Integrationsplattformen
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
CEA v6.4© 2008 Capgemini sd&m - All rights reserved
QUASARENTERPRISE_TEIL2_V0.1.PPT63
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 abschnitts-weise in den Anwendungen versteckt
Änderung der Geschäftsprozesse schwierig
CEA v6.4© 2008 Capgemini sd&m - All rights reserved
QUASARENTERPRISE_TEIL2_V0.1.PPT64
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.
Integration und Integrationsplattformen
Kopplungsarten
CEA v6.4© 2008 Capgemini sd&m - All rights reserved
QUASARENTERPRISE_TEIL2_V0.1.PPT65
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
– …
CEA v6.4© 2008 Capgemini sd&m - All rights reserved
QUASARENTERPRISE_TEIL2_V0.1.PPT66
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
CEA v6.4© 2008 Capgemini sd&m - All rights reserved
QUASARENTERPRISE_TEIL2_V0.1.PPT68
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)
Integration und Integrationsplattformen
CEA v6.4© 2008 Capgemini sd&m - All rights reserved
QUASARENTERPRISE_TEIL2_V0.1.PPT70
Sicht: Technische Services für die Logikintegration
Für jede Integrationsart existiert eine Sicht auf die Referenzarchitektur für Integrationsplattformen – Logik
Integration und Integrationsplattformen
CEA v6.4© 2008 Capgemini sd&m - All rights reserved
QUASARENTERPRISE_TEIL2_V0.1.PPT71
Sicht: Technische Services für die Präsentationsintegration
Für jede Integrationsart existiert eine Sicht auf die Referenzarchitektur für Integrationsplattformen – Präsentation
Integration und Integrationsplattformen
CEA v6.4© 2008 Capgemini sd&m - All rights reserved
QUASARENTERPRISE_TEIL2_V0.1.PPT72
Für jede Integrationsart existiert eine Sicht auf die Referenzarchitektur für Integrationsplattformen – Daten
Sicht: Technische Services für die Datenintegration
Integration und Integrationsplattformen
CEA v6.4© 2008 Capgemini sd&m - All rights reserved
QUASARENTERPRISE_TEIL2_V0.1.PPT73
Die Referenzarchitektur bietet einen Kartengrund für Produktlandkarten
Integration und Integrationsplattformen
CEA v6.4© 2008 Capgemini sd&m - All rights reserved
QUASARENTERPRISE_TEIL2_V0.1.PPT75
Quasar Enterprise ist der Reiseführer zur Gestaltung von Anwendungslandschaften
Quasar Enterprise
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
CEA v6.4© 2008 Capgemini sd&m - All rights reserved
QUASARENTERPRISE_TEIL2_V0.1.PPT76
Und diesen Reiseführer gibt es auch als Buch
Quasar Enterprise
CEA v6.4
Zusammen. Für nachhaltigen Erfolg.