Weitere ähnliche Inhalte
Mehr von Matthias Furrer (6)
Oracle Fusion Middleware als Best of Breed Basis
- 1. Integration
Architecture
BASEL BERN LAUSANNE ZÜRICH DÜSSELDORF FRANKFURT A.M. FREIBURG I.BR. HAMBURG MÜNCHEN STUTTGART WIEN
2012 © Trivadis
Oracle Fusion
Middleware als Best of
Breed Basis
Daniel Liebhart und Matthias Furrer
BDS
TechEvent September 2012
September 2012
1
- 2. Introduction
• Matthias Furrer
2012 © Trivadis
2
Long-standing experience in SOA and ERP Area
Architect, Consultant, Lead-Developer and Project Manager
SOA Certified Professional
Oracle SOA Blackbelt Consultant
Trainer with Trivadis Oracle Middleware und SOA
Reviewer of Technical Publications
More than 20 years of software development experience
Contact: matthias.furrer@trivadis.com
September 2012
- 3. 2012 © Trivadis
Agenda
Teil I: Die Konzeption
Die Ausganglage Vorgehen
Beispiele (leicht abgeändert ☺)
IT-Landscaping: Vom Prozess zur Architektur
Die Middleware als Basis
Teil II: Die Umsetzung
SOA 2.0 und die Varianten
Anwendungs-Integration über Messaging
SOA Integration Blueprint
Mapping und Einsatz von FMW Komponenten
3
September 2012
- 4. Ausgangslage: Typische Situationen beim Kunden
Beispiele aus der Praxis:
Beispiel 1: Die IT-Landschaft ist nicht für neue Geschäftsfelder vernünftig
2012 © Trivadis
4
aufgestellt
Beispiel 2: Drei unterschiedliche Fullfillment Plattformen dreier Firmen sollen zu
einem funktionierenden Ganzen zusammengefügt werden
Beispiel 3: Die Anforderungen des Business an das wichtigste System können
nicht in gewünschter Zeit umgesetzt werden
Gründe: Veraltete Systeme, neue Geschäftsmodelle, Redundante Systeme
Die Fragestellung des Kunden: Was tun?
September 2012
- 5. Vorgehen: Was in einer ersten Phase zu tun ist
Ordnung schaffen, Lösungsvarianten als Enscheidungsgrundlage liefern!
1. IST Situation analysieren: Bestehende Prozesse, Systemlandschaft und
2012 © Trivadis
5
Informationsflüsse analysieren und dokumentieren
2. SOLL Vorgaben erfassen: Soll Prozesse und zentrale Geschäftsobjekte
erfassen
3. Lösungsvarianten erarbeiten: Big Picture Umsetzungsvarianten erarbeiten
Grundsatz: Alle Beteiligten müssen ein klares Verständnis er IST Situation, der
SOLL Vorgaben und der zur Verfügung stehenden Lösungsvarianten haben.
September 2012
- 6. Beispiele: IST Situation analysieren - Systemlandschaft
Verträge
2012 © Trivadis
6
Enterprise Integration
ERP Archiv Network Management GIS
System
Data Exchange HUB
Gebäude,
Besitzer
Netzwerk
Layer 1
Netzwerk
Layer 0
Billing System Rollout Management Service Management
Incidents,
Cases
Order Management
Fulfillment
Netzwerk
Layer 2
Rechnungen
CRM
Kunden
Network (Element)
Managment
Gebäude,
Ausbau-
Status
Data Exchange
September 2012
- 7. Beispiele: IST Situation analysieren - Systemlandschaft
Backoffice Behörden System Online Systeme
Systeme
2012 © Trivadis
7
EInträge
Produktion
Weisse Seiten
Files Eingänge
DB Redaktionssystem
Auskunfsystem
Online
Spezialauskünfte
DB
Generierung
Aufkunftsdaten
Online DB
Produktion Finanzen / Human
Ressources
Adressverkauf
September 2012
- 8. Beispiele: IST Situation analysieren - Systemlandschaft
2012 © Trivadis
8
Kundenkarten,
Rubriken, Orte
Produktion Gelbe
Seiten
Lichtsatzdaten
Makuscript Redaktionssystem
Mobiles
Salessystem
Services
DB
Archiving
Finanzen / Human
Ressources
Web Portale Online Systeme
Externe
Produktions-
Systeme
GIS Client
September 2012
- 9. Beispiele: IST Situation analysieren - Schnittstellen
Lieferungen Data Loader
Stammdaten GEO Daten
Targeting Ads
Binary URL
Medien Inhalte
2012 © Trivadis
9
Firma 1
Einträge
Produkte
Firma 3 Firma 2
Ad ID
Kundenkarten
Platzierung
Context Ads Schaltdaten Interaktion Kunde Interaktion Prod. # Produkte
September 2012
- 10. Beispiele: SOLL Vorgaben erfassen - Prozesse
RollOut Fulfillment Projektgeschäft Assurance
2012 © Trivadis
Management-Prozesse
Geschäfts-Prozesse
Marketing- und Sales-Prozesse
Unterstützungs-Prozesse
10
Organisations-entwicklung
Strategiedefinition
Finanz-management
Portfolio-management
Projektportfolio-management
Produkt-management
Channel
Management
Marketing
Aquisition Wholesale
and Enterprise
Aquisition
Serviceprovider
Customer Relationship
Management
Billing
Vertrags-management
Entwicklung ICT
Knowledge-management
Beschaffung
September 2012
- 11. Beispiele: Lösungsvarianten erarbeiten – One Size fits all!
2012 © Trivadis
11
Ein einziges Gesamtsystem
Fulfillment Services
Finanz-
Management
Services
Beschaffung
Services
Aquisition Services
Billing Services
Projektgeschäft
Services
Produkt-
Management
Services
RollOut Services
Vertrags-
Management
Services
Management-
Services
Marketing Services
Channel
Management
Services
Zentrale
Entitäten
(Kunde /
Rechnung /
etc.)
Andere
Entitäten
Datenaustausch
September 2012
- 12. Beispiele: Lösungsvarianten erarbeiten – Individual!
2012 © Trivadis
12
Fulfillment Services
Datenaustausch
Finanz-
Management
Services
Beschaffung
Services
Channel
Management
Services
Billing Services
Projektgeschäft
Services
Produkt-
Management
Services
RollOut Services
Vertrags-
Management
Services
Marketing Services Aquisition Services
Management-
Services
Zentrale
Entitäten
(Kunde /
Rechnung /
etc.)
Automatisierte
Prozesse
Geschäftsregeln Sicherheit
Andere
Entitäten
September 2012
- 13. Beispiele: Lösungsvarianten erarbeiten – Best of Breed!
2012 © Trivadis
13
COTS Produkt 1
Fulfillment Services
Datenaustausch
COTS Produkt 2
Finanz-
Management
Services
Beschaffung
Services
Channel
Management
Services
Billing Services
Projektgeschäft
Services
Produkt-
Management
Services
RollOut Services
Vertrags-
Management
Services
Marketing Services Aquisition Services
Management-
Services
Zentrale
Entitäten
(Kunde /
Rechnung /
etc.)
Automatisierte
Prozesse
Geschäftsregeln Sicherheit
Andere
Entitäten
Daten
Prozesse
Datenaustausch-
Prozesse
Daten
Prozesse
September 2012
- 14. IT-Landscaping: Die Grundidee
Die Basis: Der Zuordnung von IT-Systemen oder IT-Funktionen zu den
2012 © Trivadis
14
zentralen Geschäftsobjekten und zu den wichtigen Geschäftsprozessen
Die Elemente:
Erfassung und allgemeine Beschreibung der zentralen Geschäftsobjekte wie
beispielsweise der Kunde, der Auftrag, das Produkt oder auch die Rechnung
und die Organisationseinheit
Abbildung der Geschäftsobjekte auf die verschiedenen IT-Systeme mit einer
CRUD-Matrix
Erfassung Geschäftsprozesse auf oberster Ebene
Abbildung der unterstützenden Systeme als Sammlung von Services für den
jeweiligen Geschäftsprozess
September 2012
- 15. IT-Landscaping: Vom Prozess zur Architektur
Finanz-
Management
Vertrags- Fulfillment Projektgeschäft
Management
2012 © Trivadis
15
RollOut Beschaffung
Hauptprozesse
Supportprozesse
RollOut Services Beschaffung
IT-Funktionen zur
Unterstützung des
Zentralen
Kundenprozesses
IT-Funktionen zur
Unterstützung der
Supportprozesse
Services
Management-
Services
Aquisition Services
Billing Services
Produkt-
Management
Services
Projektgeschäft
Fulfillment Services Services
Vertrags-
Management
Services
Finanz-
Management
Services
Marketing Services
Channel
Management
Services
Zentrale
Entitäten
(Kunde /
Rechnung /
etc.)
Automatisierte
Prozesse
Geschäftsregeln
Datenaustausch
Sicherheit
Andere
Entitäten
Übergreifende IT-Funktionen (Basis-System)
Management
Aquisition
Billing
Produkt-
Management
Marketing
Channel
Management
Prozesse
Unterstützende
IT-Services (als IT-Funktionen)
Basis Service
Basis Service
Basis Service
Basis Service
September 2012
- 16. IT-Landscaping: Von der Anforderung zur Umsetzung
2012 © Trivadis
16
IT-Funktionen zur Unterstützung der Haupt- und Support-Prozesse
RollOut Services
Basis Service Basis Service Basis Service Basis Service
Übergreifende IT-Funktionen
(Basis-System)
Beschaffung
Services
Management-
Services
Channel
Management
Services
Finanz-
Management
Services
Projektgeschäft
Services
Produkt-
Management
Services
Fulfillment Services
Billing Services
Vertrags-
Management
Services
Marketing Services
Aquisition Services
Automatisierte
Prozesse
Zentrale
Entitäten
(Kunde /
Rechnung /
etc.)
Geschäftsregeln
Datenaustausch
Sicherheit
Andere
Entitäten
Architektur
Requirements
User Stories
Zuordnung Bau
September 2012
- 17. Die Middleware als Basis: Geschäftsobjekte zentral
Die gemeinsame Basis einer Anwendungslandschaft sind die
systemübergreifend auszutauschenden Informationsobjekte
Ob individuell entwickelte Services oder Standardprodukte – alle
verwendet diese Basis – die Daten werde über eine Middleware
ausgetauscht
Und ausserdem:
Abteilungsübergreifende Geschäftsprozesse und Geschäftsregeln werden
über die Middleware realisiert
2012 © Trivadis
17
September 2012
- 18. SOA 2.0
EDA und SOA – Ein Widerspruch ?
Definitionen
• EDA – Event Driven Architecture: «An event driven architecture is extremely loosely coupled and well
distributed. The event Itself doesn’t know about the consequences of its cause»
Quelle: Wikipedia
• SOA – Service Oriented Architecture: «SOA represents an open, agile, extensible, federated,
composable architecture comprised of autonomous, QoS-capable, vendor diverse, interoperable,
discoverable, and potentially reusable services. SOA can provide an abstraction of business logic and
technology.»
Quelle: Erl, Thomas, About the Principles.
SOA 2.0
• Event Driven SOA: «Event-driven SOA is a form of service-oriented architecture (SOA), combining the
intelligence and proactiveness of event-driven architecture with the organizational capabilities found in
service offerings.
SOA 2.0 evolves the implications SOA and EDA architectures provide to a richer, more robust level by
leveraging previously unknown causal relationships to form a new event pattern»
Quelle: Wikipedia
2011 © Trivadis
safd
September 2012
18
- 19. Point-To-Point vs. Messaging
Ab wann entsteht ein Nutzen ?
Anzahl notwendiger Interfaces
• Point-To-Point : n * (n-1)
• Bus-Architektur oder Hub-Spoke: n * 2
Point-To-Point : Messaging :
App 1 App 2
App 3
2011 © Trivadis
App 4
App 1 App 2
App 3
Messaging
App 4
safd
September 2012
19
- 20. Integrationsarchitektur
High Level View – Schematische Sicht
• Komplette Entkoppelung zwischen Sender und Empfänger der Ereignisse
• Asynchrones Messaging für geschäftskritische Transaktionen (publish/subscribe) zur zuverlässigen
Zustellung der Nachrichten
2011 © Trivadis
safd
September 2012
20
- 21. Anwendungs-Integration über Messaging
Design Grundsätze und Nutzen
Funktionen / Building Blocks
• Jede Anwendung (CRM, Legacy, Konfigurator) hat je einen Outbound-Adapter und einen Inbound
Adapter. Alternativ kann es auch je einen Adapter pro jeweilige Business-Entität geben.
• Die Kommunikationen findet ausschliesslich über ein gemeinsames (kanonisches Format statt)
• Abhängig vom Typ der zu verarbeitenden Entität und Ziel der Nachricht, können beim Inbound-Adapter
auch Human Workflow Komponenten – zum Beispiel Vervollständigung der Informationen oder Approval-
Prozesse) involviert sein.
Gründe für Design Entscheid
Vermeidung von redundanten Entwicklungen – «Wiederverwendbare Schnittstellen».
Dynamische Integration und Reaktionsfähigkeit (Agilität)
Garantierte Zustellung und Verarbeitung über Queues und Middleware
Weitgehende Unabhängigkeit von Integrationsfähigkeit der Sender- und Empfängerapplikationen durch
Einsatz von Middleware mit entsprechenden Technologieadaptern
2011 © Trivadis
safd
September 2012
21
- 22. High Level Integration View
Interaktion zwischen Inbound und Outbound Adaptern
• Entkoppelung der Inbound und Outbound-Adapter ermöglicht Wiederverwendung der Adapter
und Nachrichtenzustellung an ggf. mehrere Consumer, bzw. Verarbeitung von Nachrichten von
unterschiedlichen Producern
2011 © Trivadis
safd
September 2012
22
- 23. Adapter Anatomy
Beispiel: Inbound / Outbound Adapter mit OSB und BPEL
• Wiederverwendbare Adapter und Datenmappings durch Einsatz von kanonischem Schema
• Abstrahierung des Entitätenmodells der beteiligten Systeme
2011 © Trivadis
safd
September 2012
23
- 24. Anwendungsübergreifender Datenaustausch als Prozess oder
via Messaging ?
Messaging
Erweiterbarkeit um neue Systeme ohne Auswirkungen auf
bestehende Integrationen durch komplette Entkoppelung
Keine Wechselwirkungen bei Ausfall eines Empfängersystems
- Asynchrones Pattern: Feedback an Nachrichten-Ersteller nicht
unmittelbar – oder nur mit grösserem Aufwand - möglich
- Abhängigkeiten bei der Zustellung und übergreifende Transaktionen
können nicht über alle Event Channels abgebildet werden
Prozess
Synchrone Steuerung: Reihenfolge der Zustellung, Abhängigkeiten
und anwendungsübergreifende Transaktionen können abgebildet
werden
BPM: Modellierung und Nachvollziehbarkeit über
Tracking/Monitoring möglich
- Erweiterungen oder Modifikationen mit Auswirkungen auf den
2011 © Trivadis
gesamten Ablauf
- Störungen bei der Zustellung haben Auswirkungen auf
nachfolgenden Prozessschritte
App 1 App 2
App 3
Message Broker
App 4
App 1
App 2
App 3
safd
September 2012
24
- 26. Key-Überlegungen in einem SOA Projekt
SOA Reference Architecture und SOA Governance
• «Right-Sizing» SOA ist ein kritischer Erfolgsfaktor für den Erfolg
• SOA ist eine mittelfristig ausgerichtete Strategie, die immer durch die
Definition von konkreten Geschäftszielen motiviert und definiert sein sollte
2011 © Trivadis
Source: Oracle
safd
September 2012
26
- 27. Thank you. Trivadis AG
BASEL BERN LAUSANNE ZÜRICH DÜSSELDORF FRANKFURT A.M. FREIBURG I.BR. HAMBURG MÜNCHEN STUTTGART WIEN
2012 © Trivadis
Daniel Liebhart Matthias Furrer
Europa-Strasse 5
CH-8152 Glattbrugg
www.trivadis.com
September 2012
27