Diskussion:Enterprise Application Integration

Ich finde die Einleitung nicht passend. EAI ist keine Plattform sondern eine Methodik in der mit Hilfe von Software und Architekturkonzepten heterogene System/Applikationen integriert werden, d.h. EAI hat als Ziel beliebige Systeme zu integrieren und die Geschäftsprozesse systemübergreifend zu ermöglichen, so dass die heterogenen Systeme für den Benutzer wie ein System erscheinen.

"Methode"

Ich stimme zu, dass "Plattform" nicht der richtige Begriff ist. Allerdings halte ich "Methode" auch für fragwürdig (siehe Definition). Besser erklärt finde ich den Abstraktionsansatz von EAI durch den Begriff "Paradigma".

MfG Alex Cruise

Hersteller

Ist die WP ein Gelbeseitenableger? Es macht zudem keinen Sinn, Firmennamen einzustellen, diese zu verlinken, obwohl nie einer die Artikel schreiben dürfte--Zaungast 14:05, 13. Dez 2005 (CET)

Mehrzahl

Eigentlich ist der Plural von Adapter Adapter. Soll Adaptoren "enterprisey" sein? (nicht signierter Beitrag von 84.146.67.34 (Diskussion) )

Danke für den Hinweis, hab’s korrigiert. --jpp ?! 09:23, 3. Jan. 2007 (CET)

ERP

ERP heisst "Enterprise Resource Planing" und bedeutet die Abbildung betriebswirtschaftlicher Abläufe durch ein Softwarepaket. Bekanntestes Beispiel dafür ist in Deutschland SAP, in den USA unter anderem Siebel und Oracle. Hier werden Geschäftsabläufe, also die Geschäftslogik, doch bereits modelliert. EAI macht das selbe noch einmal. Klar warum, dann kann man dem Kunden für eine Leistung, die längst von einem anderen erbracht wurde, noch einmal das Geld aus der Tasche ziehen. Gute Geschäftsidee, die Softwarebranche lernt von den Unternehmensberatern, die Dummheit und den Größenwahn von Wirtschaftsbossen zu nutzen. Ich würde für den Müll eher den Namen Meta-ERP vorschlagen, der hätte wenigstens etwas mit einem einigermassen vernünftigen Ziel zu tun. Aber darauf kommt es in der Branche nun wirklich nicht an. Ich weiss, das klingt alles ein wenig zynisch und verbittert. Thomas118 22:38, 15. Mär. 2007 (CET)

EAI hat die Aufgabe Anwendungen mit einander zu verbinden, die urspruenglich nicht dafuer gedacht waren miteinander zu kommunizieren. Das EAI hat dabei die Aufgabe auf Protokoll und Logischer Ebene zu vermitteln. Klar ist aber auch, dass eine Integration mit nichten so einfach ist, wie es die Marketingslides suggerieren. Warum aber jemand damit ein ERP nachbauen moechte, dass er bereits besitzt, kann ich nur schwer nachvollziehen. -- sparti 22:52, 15. Mär. 2007 (CET)

Es geht doch gar nicht darum, ob jemand etwas will, sondern ob jemandem etwas aufgeschwatzt wird. Wenn Applikationen, die nicht dafür gedacht sind, miteinander kommunizieren, muss das vermittelnde Programm sehr viel über deren Logik wissen. Und wenn diese Applikationen nun Auswirkungen auf den Geschäftsprozess haben, gehören die relevanten Daten nun einmal in ein ERP-System. Wenn solche Systeme Lücken haben - Datawarehousing gehört z.B. nicht in den Bereich ERP - dann soll man diese benennen und mit einem spezifischen Produkt schliessen. Jeder der so ein Produkt entwickelt, achtet doch schon während der Konzeptionsphase darauf, daß sich sein Werk in bestehende Softwarelandschaften integrieren lässt. Daß es mit anderen Softwarepaketen kommunizieren kann und nach aussen Schnittstellen anbietet, die die Kommunikation ermöglichen. Z.B. macht ein Online Shop, der nicht in die bestehenden Unternehmensabläufe eingebunden wird, wenig Sinn. EAI gibt es in gewissem Sinn also längst. EAI als Produkt zu vermarkten, ist für mich daher schlicht und ergreifend ein Marketing Gag. Was mich an der ganzen Diskussion auch stört, ist die Vermischung zwischen betriebwirtschaflichen und informationstechnischen begriffen. Middleware und Bus sind Begriffe aus der Informatik und haben in BWL erst einmal nichts zu suchen. Wie zwischen Anwendungen Daten hin und her geschaufelt werden, ist für einen Manager erst einmal egal, Hauptsache es sind die richtigen Daten. Ich glaube nicht, daß Begriffe wie Business Bus viel zum Verständnis beitragen. Viel eher tragen sie zur Verbreitung von Halbwissen bei. Thomas118 22:15, 16. Mär. 2007 (CET)

Hallo Thomas,

ich kann prinzipiell Deine Kritik nachvollziehen. Auch wenn ich Dir in eignen Punkten widersprechen möchte.

Wichtig ist aber, dass die Wikipedia weder eine Marketingplatform ist, noch ein Forum für enttäuschte Kunden.

Die Enzyklopädie sollte ohne jede Wertung(!), den Begriff EAI erläutern. Also wenn Du jetzt Deine Erfahrungen hier einbringen möchtest, was ich glaube, durchaus interessant sein könnte, dann solltest Du Deine Kritikpunkte nochmal mit etwas Abstand von Deinem Ärger formulieren.

Hier nochmal kurz, die Punkte, in denen ich Dir nicht zustimme.

1. Alle Produkte sollten eine Schnittstelle nach außen anbieten: Ja, das wäre schön, ist aber leider eher selten der Fall. Selbst wenn Schnittstellen vorhanden sind, sind sie oft nicht passend oder verwenden ein proprietäres Protokoll.

2. Es werden betriebswirtschaftliche und IT Begriffe vermischt: Also EAI ist zunächstmal ein technischer Begriff, mit dem Hauptanwendungsgebiet im Wirtschaftsbereich. Daher resultiert zwangsläufig eine Vermischung der Fachworte. Der Begriff bleibt aber für mich ein Begriff der Informatik.

3. Ein Begriff wie Business Bus dient dem Halbwissen: Also es gibt eine Technologie, die diesen Namen verwendet und diese Technologie wird oft in einem ESB verwendet - das ist ein Fakt. Die Wikipedia sollte diesen dabei korrekt erläutern. Wenn das nicht der Fall ist, dann sollte der Artikel ESB verbessert werden.

4. Ein Produkt sollte so gebaut sein, dass es alle Komponenten enthält, die es benötigt: Naja, das ist bei den meisten Kunden sehr schwierig, da jeder eine andere Vorstellung davon hat, was dazu gehört. Außerdem gibt es Kunden, die haben bereits Systeme im Einsatz, die zwar nicht mehr ausreichend sind, die aber auch nicht ersetzt werden können. Hier kann ein EAI helfen, fehlende Funktionen über andere Produkte zu integrieren.

Ok, ich würde mich über eine konstruktive Mitarbeit hier freuen. So wie ich es gerade einschätze, kannst Du uns was über die Grenzen des EAI erzählen.

Viele Gruesse -- sparti 23:34, 16. Mär. 2007 (CET)

Hallo Sparti,

erst mal danke für deine sachliche Erwiderung. Ich bin allerdings nicht, wie du angedeutet hast, ein enttäuschter Kunde, sondern ein desillusionierter Softwareentwickler, der sich in seinem Berufsleben schon viel mit der Integration verschiedener Applikationen auseinandersetzen musste. Die meisten davon waren aus dem technischen Bereich. Einige aber auch aus der betriebswirtschaftlichen Sparte. Daher weiss ich, wie schwer es sein kann, verschiedene Anwendungen zum "Reden" miteinander zu bringen. Daher habe ich auch viel Erfahrung mit klassischen Middleware Produkten wie Corba und Applikationsservern. Allerdings nicht mit EAI als Produkt. Deswegen kann ich zwar auf Ungereimheiten aufmerksam machen, die mir auffallen, mehr aber auch nicht. Nun zu einigen Kritikpunkten:

1. Hub and Spoke oder Bus-Architektur: Wenn ich richtig verstanden habe, sollen dabei die einzelnen Applikationen nicht mehr direkt miteinander kommunizieren, sondern über den Hub oder den Business-Bus. Der Business-Bus müsste dann also sämtliche Arten von Daten, die für die Kommunikation verwendet werden, kennen. Die Adapter würden dann für die Umwandlung von dem Datenformat der einzelnen Anwendungen in dasjenige des Business-Buses und umgekehrt sorgen. Wenn der Business-Bus ein Standardprodukt sein soll, kann ich mir das einfach nicht vorstellen. Oder habe ich dabei etwas falsch verstanden ? Wenn ja, könnte ich mir folgende Alternativerkärung vorstellen:

2. Der individuelle "Business-Bus": Der Business-Bus, der von einem bestimmten Unternehmen eingesetzt wird, ist Individualsoftware, die für einen bestimmten Bedarf an EAI massgescheidert wurde. Dabei wurden Standardprodukte wie Websphere oder Weblogic, beides um Workflow Komponenten angereicherte Applikationsserver, verwendet. Der Business-Bus kennt dabei nur diejenigen Arten von Daten, die für die Kommunikation zwischen den Anwendungen wirklich gebraucht werden. Welche von beiden Erklärungen stimmt nun ? Oder ist es ganz anders ?

3. Link zu OSGI: OSGI erleichtert die Installation von Java Komponenten auf einem Embedded System ein klein wenig. Wie es zu EAI beitragen soll, ist mir nicht ganz klar. Im Fall von OSGI kann ich übrigens persönliche Erfahrungen einbringen.

PS: Daß es mit der Antwort so lange gedauert hat, lag daran, daß ich erst "abkühlen" musste. :)

Viele Grüsse Thomas118 21:20, 2. Apr. 2007 (CEST)

Hallo Thomas,

die Idee von EAI entspricht ziemlich genau dem Vorschlag 1.

In der Tat muessen alle Daten in ein sogenanntes Integrationsmodell transformiert werden. Wichtig dabei ist aber, dass das Modell vom Datenintegrator festgelegt wird. Es liegt als in der Hand des Anwenderes das Modell so festzulegen, dass es maechtig genug ist, die Daten aller beteiligten Applikationen transportieren zu koennen.

Ein gaengiger Ansatz ist dabei, ein XML-Schema zu definieren, dass allen Anforderungen gerecht wird. Alle Daten werden dann in XML umgewandelt, konform zum Integrations Schema.

Tja, jetzt muss man also nur noch das passende Schema finden und die Daten geeignet transformieren. Ist doch ganz einfach, oder? :)

Gruss -- sparti 19:56, 3. Apr. 2007 (CEST)

Hallo Sparti,

wenn das so ist, habe ich auch schon einmal EAI betrieben, nur wurde das nicht so genannt. Das mit dem Integrationsmodell sollte auf jeden Fall in dem Artikel auftauchen, es würde das Verständnis sehr erleichtern. Im Grunde hatten wir das Ganze schon einmal mit Corba. Alle Applkationen in einem System werden mit IDL Schnittstellen ausgestattet - Stichwort "Legacy Wrapping". Andere Applikationen dürfen nur genau diese Schnittstellen benutzen. Man könnte die Menge aller Corba IDL's auch als Integrationsmodell bezeichnen. Bei EAI wird nun Corba durch XML-Schema ersetzt.

Gruß Thomas118 21:00, 4. Apr. 2007 (CEST)

Enterprise Service Bus

In der Definition ("Auf dem verbindenden Business Bus (Enterprise Service Bus),...") klingt es so, als wäre der ESB ein Teil der EAI. Die Techniken im Business Bus sind zwar ähnlich zu dennen des ESB, aber letztendlich handelt es sich bei EAI und ESB um konkurierende, gleichwertige Lösungen zur Systemintegration. Die Formulierung, dass der ESB ein Teil von EAI ist, ist sicher nicht zutreffend.

Eine Enterprise Application Integration integriert Enterprise Applications miteinander. Sie spezifiziert die Schnittstellen zur Benutzung von Bestandteilen der jeweiligen Enterprise Applications und stellt als Technologie den EAI broker zur Verfügung damit die EA via Schnittstellen miteinander interagieren können.

Meines Erachtens ist die Applikationsebene die Basisebene für die Serviceebene. D.h. während auf der EAI-Schicht EA miteinander kommunizieren, beginnt auf der Service Ebene die Serviceorientierte Architektur, in der Services miteinander kommunizieren. Die eingesetzte Technologie ist hier der Enterprise_Service_Bus. Einzig ein kleiner Hinweis aus dem Artikel zu SOA brachte mich auf eine weiterführende Idee: ""Analog zur Netzwerkinfrastruktur (OSI 7 Schichten Modell Layer 2+3: Sicherungsschicht+Vermittlungsschicht) erlaubt es, dass Hosts im Netzwerk gefunden werden können, da sie logisch via IP adressiert werden. Hosts bauen aber zueinander Verbindungen (Netzwerksockets) auf (OSI 7 Schichten Modell Layer 4:Transportschicht) z.B. via TCP. EA würde ich an ein Host anlehnen und Services an Sockets. Es ist aber möglich Services zu abstrahieren, das bedeutet die Programmlogik zu kapseln und als einigenständige Micro EA zu betreiben. Deswegen ist eine Trennung per Definition nur zwischen EAI Broker von ESB möglich. (Wobei Broker durch den WebSphere Message Broker von IBM geprägt ist.) --Tivi (Diskussion) 11:42, 8. Aug. 2012 (CEST)

Unterschied ESB - Business Bus

Und wo wir gerade dabei sind, siehe Diskussion:Business Bus. --Siehe-auch-Löscher 08:26, 30. Jan. 2011 (CET)

Einheitliche Schreibweise: mit Bindestrich

Wie ist es zu verstehen, dass der Artikel durch eine Bezeichnung mit Bindestrich eingeleitet wird, jedoch der direkte Aufruf ohne Bindestrich erfolgt? Ich plädiere daher dafür, den Aufruf ebenfalls mit Bindestrich zu tätigen in analoger Weise, wie es bei Customer-Relationship-Management und Enterprise-Resource-Planning der Fall ist. Wenn keine Gründe dagegen sprechen, werde ich das "rename" nach dem 12.4.2012 durchführen. tzeh (Diskussion) 14:26, 5. Apr. 2012 (CEST)

Ich habe in meiner 10 jährigen Berufserfahrung in diesem Umfeld den Begriff noch nie! mit Bindestrich gesehen. Ich bin deutlich dagegen. Es sollte eher die Einleitung im Artikel angepasst werden. --Visionmaster2 (Diskussion) 23:27, 11. Apr. 2012 (CEST

Sprachwirklichkeit schlägt Systematik (zumindest hier bei Wikipedia). Daher greife ich den Vorschlag von Visionmaster2 auf und streiche die Bindestriche in der einleitenden Bezeichnung, um wenigstens einheitlich mit dem Aufruf des Artikels zu sein. tzeh (Diskussion) 10:24, 12. Apr. 2012 (CEST)

Abgrenzung zu SOA

"EAI kann als Vorgänger der Serviceorientierten Architektur (SOA) verstanden werden." Das ist nicht korrekt, aber keine Sorge, in der Literatur wird sich im Bezug auf EAI meistens verhauen. Zur Erläuterung: EAI = Enterprise Application Integration = Integration von Applikationen auf Unternehmensebene SOA = Service-oriented Architecture = Architekturparadigma zur Umsetzung von EAI EAI ist nicht der Vorgänger von SOA, da EAI keine Architektur sondern eine Methodik ist. SOA kann vielmehr als Untermenge von EAI betrachtet werden, da SOA das Konzept für eine Integration von Anwendungen im Enterprise-Umfeld darstellt. Oft wird EAI mit der Middleware gleichgesetzt, die diese Idee lediglich umsetzt. Das ist wie wenn man UML mit einem x-beliebigen UML-Tool gleichsetzt, hierbei findet genauso ein Wechsel der Abstraktionsebenen statt.

Worauf du hinauswolltest war vermutlich die damalige Umsetzung von EAI in Form einer Hub & Spoke - Architektur. (nicht signierter Beitrag von 217.6.52.178 (Diskussion) 13:25, 23. Okt. 2012 (CEST))