SOA in Kundenprojekten

SOA in
Kundenprojekten
Sankt Augustin,
21.05.2014,
Jewgenij Moldawski

Copyright © Capgemini 2013. All Rights Reserved
2SOA in Kundenprojekten.pptx
Agenda
 Anwendungslandschaften großer Unternehmen
 Enterprise Application Integration
 SOA: Domänen, Services und Operationen
 SOA: Beispiele aus Projekten
 Wie geht es weiter?
 Fragen Fragen

www.capgemini.com
Über Capgemini
Mit rund 120.000 Mitarbeitern in 40 Ländern ist Capgemini einer
der weltweit führenden Anbieter von Management- und IT-
Beratung, Technologie-Services sowie Outsourcing-Dienst-
leistungen. Im Jahr 2011 betrug der Umsatz der Capgemini-
Gruppe 9,7 Milliarden Euro.
Gemeinsam mit seinen Kunden erstellt Capgemini Geschäfts- wie
auch Technologielösungen, die passgenau auf die individuellen
Anforderungen zugeschnitten sind. Auf der Grundlage seines
weltweiten Liefermodells Rightshore® zeichnet sich Capgemini
als multinationale Organisation durch seine besondere Art der
Zusammenarbeit aus – die Collaborative Business ExperienceTM.
Rightshore® ist eine eingetragene Marke von Capgemini
Die in der Präsentation enthaltenen Informationen sind Eigentum.
Copyright © 2013 Capgemini. Alle Rechte vorbehalten.
Kurzvorstellung Capgemini

Über mich
• Jahrgang 1971
• Studierte Informatik an der Nationalen Technischen Universität in Kiew, Ukraine
• Seit 1997 bei Capgemini, ehemals sd&m.
• Kunden Telko, Krankenversicherung, Logistik, Bundesbehörden
• Aufgaben: technisches Design, Implementierung, Wartung, generell technische Themen
• Schwerpunkte: Datenbaken, Performancetuning, Server-Programmierung, Java, SOA
• https://www.xing.com/profile/Jewgenij_Moldawski

Allgemeines zum Vortrag
• Dieser Vortrag basiert auf meiner persönlichen Erfahrung aus den großen Software-
Projekten, an denen ich mit gearbeitet hatte
• Ich versuche, die wichtigen Begriffe so zu verwenden, wie sie in Büchern und im Web
verwendet werden.
• Alle Beispiele sind real, ich habe sie allerdings „anonymisiert“
• Ich habe mich bei den Grafiken an die BMPN-Notation gehalten [BPMN], und die
Grafiken mit Microsoft Office Visio und einer BPMN-Vorlage erstellt.
• Ich bitte Sie, Fragen direkt zu stellen. Ich werde sie dann entweder sofort oder am Ende
beantworten. Auch gerne im später per Mail

Dieser Vortrag auf Slide Share

Agenda
 Fragen Fragen

Komplexe Anwendungslandschaften heute
 Große und mittlere Unternahmen betreiben seit Jahren große Anzahl der EDV-
Anwendungen. Dabei sind 3-stellige Anwendungszahlen keine Seltenheit.
 Diese Anwendungen wurden meistens seit Jahrzenten weiterentwickelt:
• Sie verwenden verschiedene Techniken
• Sie wurden in den unterschiedlichen „EDV-Zeitaltern“ entwickelt
• Sie werden unterschiedlich gut gewartet und haben verschiedene Wartungszyklen
• Sie laufen auf verschiedenen Plattformen
 Die meisten Anwendungen kommunizieren mit den internen Anwendern, untereinander,
mit den externen Anwendern (B2C) und externen Anwendungen (B2B).

Komplexe Anwendungslandschaften heute

Frühere Sicht auf eine typische Anwendungslandschaft
Bei meinen älteren Kundenprojekten, dann stand immer die Anwendung im
Mittelpunkt

Frühere Sicht auf eine typische Anwendungslandschaft
 Der Kunde hat mehrere Anwendungen, die sein Business unterstützen.
 Der Ablauf jeder einzelnen Anwendung wird entweder durch den Benutzer oder durch
die Hintergrundprozesse (Batches) bestimmt.
 Anwendungen tauschen untereinander Daten aus. Das Client/Server war damals das
gängige Model, um diesen Austausch zu beschreiben
 Dabei kommen verschiedene Protokolle FTP, HTTP, (schon) SOAP … und Datenformate
ASCII, (schon) XML, HTML usw. zum Einsatz.
 Jede Anwendung hat:
• Eine zuständige Fachabteilung
• Ein Entwicklerteam (oder auch nicht)
• Einen Support
• usw.

Agenda
 Fragen Fragen

EAI: ein Schritt in Richtung SOA
 Viele Kunden haben festgestellt, dass die IT-Anwendungen und vor allem ihre
Vernetzung, das Business inzwischen nicht nur unterstützen, sondern auch bestimmen.
Diese Erkenntnis förderte eine verstärkte Vernetzung einzelner Anwendungen.
 Um dabei nicht die Kommunikation für jedes Anwendungspaar neu zu regeln, wurde das
Bus-Konzept angewandt, was das wesentlich Bestandteil der EAI darstellt:
• Die Anwendungen tauchen Nachrichten mit Hilfe einer zentralen Komponente (Bus)
aus.
• Jede Anwendung ist durch spezifische Adapter mit dem Bus verbunden.
 Alle große SW-Hersteller haben Busse und Adapter für Standardanwendungen
angeboten. Einige unserer Kunden haben jedoch auch eigene Implementierungen
eingesetzt.
 Wichtig: bei den EAI-Konzepten bleiben die Anwendungen weiterhin im Mittelpunkt.

EAI: ein wichtiger Schritt in die Richtung SOA
So könnte die früher erwähnte Anwendungslandschaft aussehen!

EAI: Der Bus
 Sorgt für die Adressierung und für den Transport der Daten zwischen den Anwendungen
 Unterstützt verschiedene Kommunikationsarten
 Transformiert die Datenformate (z.B XML->ASCII)
 Unterstützt die Bus-Adapter
 Bietet Transaktion-Services (mit Unterstützung durch die teilnehmende Anwendungen):
z.B. wird die Übertragung allen oder keinem Adressaten bestätigt.
 Bietet Infrastruktur-Services an, wie Monitoring, Archivierung usw.
 Der Bus kann reell oder virtuell sein -> später

EAI: Kommunikationsarten
 In den Zeiten vor der EAI war die Kommunikation zwischen den Anwendungen eine
Nebenerscheinung, die irgendwie sinnvoll stattfinden sollte.
 EAI stellt die Kommunikation an sich stärker in den Fokus. Ein wichtiger Aspekt dabei
sind die Kommunikationsarten.
 Die gängige Kommunikationsarten kann man beschreiben durch:
• ihre Topologie: Wie viele Sender/Empfänger sind an einer Kommunikation beteiligt
• ihr Protokoll: Wer fängt an, gibt es immer einer Antwort, eine Empfangsbestätigung
usw.
• ihr Modus: synchron oder asynchron

EAI: Wichtige (aber nicht alle!) Komminikationsarten
Protokoll
Topologie
Requst-
Response
Fire-and-Forget oder One-Way Pub/Sub
Point-to-Point Beispiel? FILO schickt Umsätze des letzten
Monats zum ARCHIV
Beispiel?
Point-to-Multipoint Beispiel? Beispiel Beispiel?
Hausaufgabe! Ergänzt bitte fehlende Beispiele. Tipp: Denkt dabei an bekannte
Internet-Dienste sowie an die Social Media.
 Wichtige Protokolle:
 Request/Response
 One-Way
 Pub/Sub
 Wichtige Topologien:
 Point-to-Point
 Point-to-Multipoint
 Zusammen mit Modi synchron und
asynchron ergibt es rein rechnerisch:
 3x2x2=12 Kommunikationsarten
 Nicht alle von Ihnen sind allerdings
sinnvoll.
Die Lösungen bitte per Mail an mich. Die erste Lösung wird mit einem kleinen
Geschenk prämiert!

EAI: eine einfache Austauschdatei als ESB

EAI: Bus-Adapter
 Die Bus-Adapter vermitteln entweder zwischen den Anwendungen und dem Bus (reeler
Bus) oder direkt zwischen den Anwendungen (virtueller Bus). Der virtuelle Bus ist
vollständig durch die Adapter implementiert, ein reeller Bus hat außerdem eigene
Prozesse.
 Sie sorgen für die passende Protokolle und Datenformate
 Sie unterstützen verschiedene Kommunikationsarten
 Ausgereifte EAI-Produkte bringen viele fertige Adapter für Standard-Anwendungen wie
SAP, Oracle, usw. oder für Datenquellen wie ODBC, SQL Net, XLS, usw. mit.
 Für die Anbindung der älteren bzw. individuellen Anwendungen stehen Toolkits zur
Verfügung.

Was ist nun SOA?
 Fachliche Konzepte (Domänen, Services, Geschäftsprozesse)
 Technische Konzepte (ESB, Service Registry, EAI)
 Management Konzepte (SLAs, unternehmensweite Einführung, Konflikte)
 Produkte und Werkzeuge
Im Fokus der Betrachtung steht der Service

Agenda
 Fragen Fragen

Warum SOA?
Warum SOA?

SOA: Serviceorientierte Architektur

Service: der Mittelpunkt einer SOA
 Ein Service beschreibt eine DV-Funktion aus fachlicher Sicht, z.B.
„Rechnungsverwaltung“
 Ein gut konzipierter Service ist ein eindeutig: es gibt z.B. keine zweite
„Rechnungsverwaltung“.
 Ein Service ist verschiedenen fachlichen Abläufen verwendbar, z.B. kann sowohl ein
Online-Portal, als auch CRM die „Rechnungsverwaltung“ nutzen.
 Ein Service wird von mindestens einer, oft aber mehreren Anwendung, (genannt Service
Provider) implementiert. Es können mehrere Service Provider für einen Service, z. B. für
„Rechnungsverwaltung“ geben.
 Ein Service wird von anderen Anwendungen (genannt Service Consumer) genutzt
 Ein Service bietet mehrere Service Operationen

Service Domäne: Organisationsklammer für Services
 ... entspricht oft einer Organisationseinheit (z.B. einer Fachabteilung)
 … „besitzt“ bestimmte Datenarten, z. B. Kundenstammdaten. Sie ähnelt dabei der
Domäne im etwas altmodischen Konzept des „Enterprise Data Model“
 … bietet mehrere Services an, die fachlich zusammengehören, z.B. kann die Domäne
„Kunden“ die Services „Kundenkarten“ und „CRM“ anbieten
 … stellt im Bezug auf diese Datenarten und Services ein „Single Point of Truth“ dar:
Anwendungen müssen entsprechende Datenarten (in unserem Beispiel
Kundenstammdaten) über die Services dieser Domäne beziehen oder zumindest
dagegen abgleichen. Die Festlegung der Single Points of Truth birgt oft ein großes
Konfliktpotential und muss deswegen sorgsam durchgeführt werden.

Domäne: Organisationsklammer
 Die Formen der dicken Pfeile stellen die Kommunikationsarten dar

SOA: Service Registry
 Das Service Registry ist die zentrale Komponente einer SOA
 Das Service Registry:
• sorgt für sogen. lose Kopplung der Services. Es ist zwar möglich ein SOA ohne
Service Registry zu haben, wenn man auf lose Kopplung verzichten wil
• speichert Informationen über Services
• registriert Service Providers
• stellt find und lookup Operationen bereit
 Ähnlich wie DNS ist das Service Registry ist ein absoluter „Single Point Of Failure“ und
muss daher gegen Ausfälle und gegen Angriffe geschützt werden.
 Meistens ist das Service Registry redundant ausgelegt.

SOA: Service Registry, Beispiel

SOA: Übersicht wichtiger Begriffe

SOA: Wie komme ich zu einem Service?
 Bei der SOA spricht man nicht mehr über Anwendungs- sondern über die Service-
Landschaften.
 Ein Aufbau der Service-Landschaft erfolgt selten auf der „grünen Wiese“: meistens hat
der Kunde schon Anwendungen im Betrieb und möchte eine Service-Landschaft
„einziehen“.
 Folgende Varianten sind oft anzutreffen:
• bestehende Anwendung = ein Service = Service Provider
• bestehende Anwendung = ein Service Provider = mehrere Services (häufiger Fall)
• mehrere bestehende Anwendungen (oder Services) = ein Service (BPM-Ansatz)
• erweiterte Anwendung -> neuer Service

SOA: Eine Anwendung -> mehrere Services
 Oft implementiert eine Anwendung einen „lesenden“ und einen „schreibenden“ Service:
 Vorteile: diese Servicearten haben oft jeweils verschiedene Anforderungen an Sicherheit,
Performanz, generell an NFA. So lassen sich diese Unterschiede schon auf der Service-
Ebene definieren.

SOA: Komposition mehrerer Anwendungen
 Ein Service wird von einer „zwischen“-Anwendung implementiert, die je nach Daten (hier:
Produkt) auf verschiedene Anwendungen weiterleitet.
 Vorteil: Der Aufruf ist für den Service Consumer unabhängig vom Produkt->
Wiederverwendbarkeit.
 Ein BPM - Ansatz

SOA: Kombination bestehender Services
 Ein Service wird von einer „zwischen“-Anwendung implementiert, die bestehenden
Services um eine fachliche Logik (hierWarteschleife) erweitert.
 Vorteil: Die Services müssen nicht geändert werden.
 Nachteil: Die Fachlichkeit wird „fremd“ implementiert: die Zwischenanwendung muss das
Statusmodel des Auftrags kennen.
 Ebenso ein BPM - Ansatz

Hauptakteure: Service Provider und Consumer
 Der Schritt find entfällt oft, da die Services des Unternehmens den Service-Consumern
bekannt sind.

SOA: Service Provider und Consumer
 Der Service Provider:
• verbindet sich mit ESB durch den bind-Aufruf
• wird nicht direkt sondern unter der Vermittlung des ESB aufgerufen: call
• Verschiedene Service Provider können verschiedene SLAs erfüllen.
 Der Service Consumer:
• sucht den passenden Service durch den find-Aufruf
• verbindet sich über ESB mit einem passenden Service Provider durch den bind-Aufruf.
• ruft den Service auf, nicht direkt den Service Provider ->lose Kopplung
 Das Service Registry:
• ist in diesem Beispiel auch ein (technischer) Service
• stellt die lookup Service Operation zur Verfügung

SOA: Was wurde versprochen?
 Den Fachabteilungen in den Unternehmen:
• Guten Überblick über bestehende Services
• Wiederverwendbare Services
• Konzentration auf die Entwicklung fachlich motivierter Services, statt schwer zu
überblickenden Anwendungen.
• Schnellere Entwicklung neuer Services aus bestehenden (BPM).
• Eine bessere Kontrolle über Services, während bei Anwendungen andere „fachfremde“
mitreden und es außerdem enge Rahmenbedingungen gibt
• Einen „festen“ Platz (Domäne) in der Service-Landschaft.
• Services als eine „Sprache“ für den Austausch zwischen den Fachabteilungen
• Lösung des Wiederspruchs „Stabile Anwendungen vs. Flexible Prozesse“
 und…

SOA: Was wurde versprochen?
 Der IT-Abteilung:
• Neues modernes Konzept, neue Werkzeuge
• Bessere Wartbarkeit und die SLA-Kontrolle durch die lose Kopplung
 Dem gesamten Unternehmen Kostenreduzierung durch z.B.
– Wiederverwendung eigener Services
– Nutzung der Fremdservices,
– Verwendung des standard ESB

SOA: Schwierigkeiten in der Praxis beachten
 Fachabteilungen:
• Fremden Services wird oft misstraut
• Die Änderungswünsche anderer Domänen werden nicht schnell genug berücksichtigt,
weil z.B. Fachbereiche um Budgets streiten.
• Durch Reorganisationen des Unternehmens entfernt sich die Realität von der Service-
Landschaft
 IT-Abteilung:
• ESB könnte zu einem weiteren „Single Point of Failure“ werden.
 Management:
• Wenn die SOA-“Supporter“ nicht mehr aktiv sind, kann SOA schnell zu einem reinen
Kostenfaktor degradiert werden.
• SOA kann Konflikte aufzeigen. Z.B. stellt sich heraus, dass es zwei Service Provider
mit einer fast gleichen Funktion existieren: wer soll überleben?

Agenda
 Fragen Fragen

Beispiel: Service = Anwendung
 Ein neuer Service „Bankverbindung“ muss entwickelt werden. Dieser Service muss eine
Bankverbindung überprüfen und ggf. den Banknamen ermitteln können.
 Es existiert bereits eine Anwendung, die folgende Funktionen hat und intern nutzt:
• Überprüfung der BLZ
• Überprüfung der Kontonummer
• Ermittlung des Banknamen
 Das Team, das diese Anwendung betreut, wurde beauftragt, sie als Service anzubieten.
Im Ergebnis bildet der Service diese Anwendung nach: die entworfenen Service
Operationen entsprechen den Anwendungsfunktionen.

 Die Benutzung des Services ist jedoch unbequem, da die Service Consumer immer alle
drei Service Operationen nach einander aufrufen müssen und diese Aufrufe durch eine
Geschäftslogik zu verbinden.
 Nach ersten Erfahrungen stellt sich heraus, dass der Service zwar alle notwendigen
Informationen liefert, aber zu „feingranular“ ist: alle Service Consumer wünschen sich
eine Service Operation, die sowohl die Prüfung als auch die Ermittlung des Banknamen
durchführt.
 Da der Service Provider auch in diesem Fall nicht geändert werden darf, werden die
bereits bestehenden Service Operationen zu einer neuen Operation „Bankverbindung
validieren “ zusammen gefügt *.
* Diese Lösung wurde am Ende doch aus organisatorischen Gründen verworfen.

Beispiel: „Durchschleuser“
 Für die Domäne „Versand“ muss ein Service „Tracking & Tracing“ erstellt werden, der
den aktuellen Standort einer Sendung ermittelt. Die Daten können aus den öffentlichen
Webservices im Internet ermittelt werden, die Paketdienste anbieten.
 Dabei müssen unterschiedliche Datenformate zusammen geführt werden
 In der Domäne „Versand“ gibt es bisher keine Anwendung, die so erweitert werden kann,
dass sie diesen Service implementieren könnte. Eine Entwicklung der neuen Anwendung
ist zu teuer.
 Der Service Provider AUFTAKT aus einer anderen Domäne kann bereits auf
Webservices zugreifen und wird um die Implementierung des Dienstes „Tracking &
Tracing“ erweitert.
 Nachteil: für die Logik ist nun „fremde“ Domäne zuständig!

 Besser ist eine Implementierung in eigener Domäne bspw. mit Hilfe eines BPM-Tools .
Voraussetzung: ESB ermöglicht allen Domänen Zugriff auf Webservices

Beispiel: ein zu „schlauer“ Service Provider
 Für die Domäne „Filiale“ muss der Service „Verkauf am Schalter“ konzipiert und
implementiert werden. Unter anderem müssen daraus Aufträge für die Produktion erstellt
werden.
 Die Geschäftslogik besteht ursprünglich darin, dass je nach gekauftem Produkt entweder
neue Aufträge erstellt werden oder laufende „Daueraufträge“ ergänzt werden.
 Für die Erstellung der Aufträge wird der Service „Verwaltung“ der Domäne „Aufträge“ um
diese Geschäftslogik erweitert.
 Nachteil: Die Geschäftslogik erwies sich doch als komplexer, da nicht nur das Produkt,
sondern auch die gekaufte Menge eine Rolle spielt. Dies ist den Zuständigen der
Domäne „Aufträge“ bis zur Implementierung nicht bekannt. Der Service Provider
AUFTAKT muss noch einmal entsprechend geändert werden. Die Zuständigen für die
Domäne „Filialen“ müssen beteiligt werden

 Besser ist auch hier eine Implementierung in eigener Domäne.
 Vgl mit „Service=Anwendung“

Beispiel: Zeit-Cache
 Die Services der Domäne „Kunde“ fallen oft technisch bedingt aus. Um diese Ausfälle zu
überbrücken hat der Service Provider FILO ein Kunden-Cache eingerichtet.
 Fällt der „Kunden“-Service aus, so prüft FILO, ob die notwendigen Kundendaten im
Cache nicht älter als N Stunden sind und nutzt sie dann.
 Nachteil: ist N niedrig, so ist die Wahrscheinlichkeit, die notwendigen Daten im Cache zu
treffen gering, ist N hingegen hoch, so steigt die Wahrscheinlichkeit, auf inzwischen
veränderten Daten zu stoßen.
 Bessere Lösung: Nutzung der pub/sub-Operation „Kunde geändert“. Dadurch kann der
Service Provider FILO den Cache genau dann aktualisieren, wenn sich die Kundendaten
geändert haben.

 Besser ist hier eine Nutzung der pub/sub-Notification.
 Deswegen wichtig, das pub/sub vom ESB unterstützt ist.

Beispiele: Zusammenfassende Tipps
 Folgende Punkte sollte beim Implementieren der Services beachtet werden:
1. Implementiere immer nur die Logik, die zu Deiner Domäne gehört
2. Mache die Services genau möglichst „schlau“, wie es dem Punk 1 nicht wiederspricht
3. Verwende immer die passende Kommunikationsarten, wähle einen ESB, die diese
Kommunikationsarten anbietet, programmiere sie nicht nach.

Eine Service Operation ist:
 Fachlich motiviert:
• Auftrag anlegen
• Kunden suchen
• Bestellung abrechnen
• Aber nicht: Kunden-Cache leeren
 Grobgranular („schlau“), z.B.:
• Auftragspreis berechnen
• Aber nicht: MwSt für den Auftrag ermitteln
 Zustandsunabhängig
• Auftrag ändern
• Aber nicht: letzten Auftrag ändern
 Idempotent (wiederholbar)

Beispiel Idempotenz:
 Ist-Situation:
• Der Service Provider der Operation „Auftrag anlegen“ ist manchmal unzuverlässig.
• Es gibt keine Erfolgs-/Fehlerbestätigung (Fire-And-Forget).
 Anforderung:
• Eine neuer Service Operation „Auftrag erteilen“ soll für die Anlage eines Auftrages
garantieren. Eine Erweiterung des bestehenden Service Providers ist aus
verschiedenen Gründen nicht möglich.
 Lösung:
• Es wird ein neuer Service „Produktion“ implementiert, der mit Hilfe eines Retry-
Mechanismus die temporären Ausfälle kompensiert.

 Lösung im Detail:
• Der Service Provider ruft die Service Operation „Auftrag anlegen“ auf.
• Da mit einem Ergebnis nicht (zuverlässig) gerechnet werden kann, fragt der Service
Provider den Service „Auftragsinformation“ ab, ob der Auftrag schon angelegt wurde
• Falls der Auftrag nach 5 min. noch nicht angelegt wurde, wird die Anlage noch einmal
versucht usw.
 Voraussetzungen für diese Lösung
• Der die Service Operation „ Auftrag anlegen“ soll maximal einen Auftrag anlegen, wenn
sie mehrmals mit gleichen Parametern aufgerufen wird.
• Insbesondere soll dies auch gelten, wenn mehrere Aufrufe sich überlappen, denn die
Auftragsanlage kann bei komplexen Aufträgen länger als 5 min dauern.
• Diese Eigenschaften der Service Operation werden unter dem Begriff Idempotenz
zusammen gefasst.

Idempotenz: Allgemeines
 Der Kunstbegriff Idempotenz bezeichnet in unserem Beispiel eine Eigenschaft einer
Service Operation, dass ihre mehrfache Aufrufe (mit gleichen Parametern) nicht mehr als
eine Änderung am System produzieren, in unserem Beispiel nicht mehr als ein neuer
Auftrag.
 Manchmal findet man andere Definition, z.B., dass: „Ergebnisse aller Aufrufe ab dem
zweiten sollen identisch sein“. Oder wird einfach Idempotenz gefordert.
 Deswegen…

Idempotenz: In der Praxis
 … muss die Forderung der Idempotenz einer Service Operation immer konkretisiert
werden! Was ist in jedem konkreten fall gemeint?
 Glücklicherweise wird die Idempotenz in der Praxis weniger streng interpretiert, z.B:
• es dürfen keine doppelten Daten entstehen und/oder
• es dürfen keine Nummernlücken entstehen und oder
• der Auftragsstatus darf sich in der Response nicht ändern usw.

Agenda
 Fragen Fragen

SOA: Was ist der Schlüssel zum Erfolg und die
Schwachstellen?
 Der Hauptschlüssel zum Erfolg einer SOA sind die fachlichen Konzepte: je besser die
Domäne und Services die Realität eines Unternehmens abbilden, desto mehr Nutzen
wird man daraus ziehen können. Beispielsweise soll eine Fachabteilung für ein Service
zuständig sein.
 Der nächste Schlüssel ist das Management: da SOA große Teile des Unternehmens
betrifft, treten oft Konflikte zwischen den Beteiligten auf, wer z.B. soll für ein Service
zuständig sein? Das Management hat die Aufgabe, diese Konflikte konstruktiv zu lösen
und nicht SOA an sich in Frage zu stellen.
 Ein weiterer Schlüssel ist die Technik: ein ESB, dass alle Kommunikationsarten
unterstützt, lädt zum Ausbau der SOA ein. Andersrum werden ein instabiler ESB oder
eine langsame Service Registry, als Vorwand gegen die SOA aufgeführt.

Was kommt als Nächstes?
 EAI, SOA und BPM waren zu jeweils ihren Zeiten eindeutige Trends, sogar Hypes.
 Inzwischen sind entsprechende Konzepte und Tools ausgereift und bei den
Unternehmen als selbstverständlich angesehen, auch schon old-fashioned.
 Interessanterweise wird der Begriff „SOA“ trotzdem bei vielen Unternehmen inzwischen
nicht gern verwendet. Über die Gründe kann man lange diskutieren. Möglicherweise hat
es mit den Anfangsschwierigkeiten und hohen Kosten bei Starts der SOA-Projekte zu
tun. Man spricht aktuell lieber über Business Process Management, was SOA-Konzepte
integriert.
* Nach Gartner

Agenda
 Fragen Fragen

Danke für Ihre Aufmerksamkeit!

Literatur
 Beinhauer, W. u.a.: SOA für agile Unternehmen, Düsseldorf, Symposien Publishing
GmbH, 2008
 BPMN, http://de.wikipedia.org/wiki/Business_Process_Modeling_Notation
 Hype-Zyklus, http://de.wikipedia.org/wiki/Hype-Zyklus

Contact information
Jewgenij
Moldawski
yevgen.moldawski@capgemini.com
Capgemini Office Troisdorf
Mülheimer Str. 9a
53840 Troisdorf
Insert
contact
picture

SOA in Kundenprojekten

Recomendados

Recomendados

Mais conteúdo relacionado

Semelhante a SOA in Kundenprojekten

Semelhante a SOA in Kundenprojekten (20)

SOA in Kundenprojekten