SOA in Kundenprojekten

SOA in Kundenprojekten

Sankt Augustin, 21.05.2014, Jewgenij Moldawski

2SOA in Kundenprojekten.pptx

Copyright © Capgemini 2013. All Rights Reserved

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 CapgeminiMit 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

http://www.facebook.com/Capgemini

http://www.linkedin.com/company/capgemini

http://www.twitter.com/capgemini

http://www.youtube.com/capgemini

http://www.slideshare.net/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

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





Wie geht es weiter?

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





Wie geht es weiter?

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


ProtokollTopologie

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





Wie geht es weiter?

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





Wie geht es weiter?

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





Wie geht es weiter?

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





Wie geht es weiter?

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

http://de.wikipedia.org/wiki/Business_Process_Modeling_Notation


Contact information


Jewgenij Moldawski

[email protected]

Capgemini Office TroisdorfMülheimer Str. 9a53840 Troisdorf

Insert contact picture

mailto:[email protected]