EDI

Hier gibt es wiederum zwei Möglichkeiten, wie die Realisierung von statten gehen kann. Unterschieden wird zwischen Inhouse in Eigenregie und Inhouse mit Dienstleistung.

SaaS wird neumodisch auch Cloud Computing genannt. Hier wird die Installation selbst aus-
gelagert. Ein Anbieter stellt also Hardware und Infrastruktur zur Verfügung und kümmert sich um die Pflege, wie z.B. das Einspielen von Updates. Alles bedienen und die Prozesse aufsetzen können Sie selbst über das Internet.

Nicht nur der Betrieb des Systems und die Administration, sondern im Prinzip die gesamte Arbeit wird ausgelagert. Ein Dienstleister betreibt die SW in seinem Rechenzentrum, bindet Ihre Geschäftspartner an und setzt Konvertierungen und weitere Prozesse auf. Sie schicken ihm nur noch Daten für Ihre Partner ins System und bekommen von ihm deren Daten zugesandt.

Zu EDI gehört auch die Kommunikation – hier haben wir zwei Varianten. Sie können Daten über das ganz normale Internet schicken oder über ein sogenanntes VAN, ein Value Added Network, das neben der reinen Datenübertragung noch ein paar zusätzliche Leistungsmerkmale hat, wie zum Beispiel sichere Übertragungen.

Vorteile:

• Alle Ihre Systeme, z.B. Datenbanken, SAP oder was auch immer, sind direkt im Zugriff und das EDI-System kann seine volle Leistung ausspielen.
• Wenn das Programm dazu fähig ist, kann es auch gleich die EAI-Aufgaben mit erledigen, denn dafür ist der vorgenannte Punkt natürlich unverzichtbar.
• Sie haben alles komplett unter Ihrer Kontrolle, es verlassen nur die Daten Ihr Netz, die auch für die Außenwelt bestimmt sind.
• Sie haben einmalig in den Kauf des Systems zu investieren und dann meist eine überschaubare, aber immer gleichbleibende Supportgebühr zu entrichten. Das ändert sich nicht mehr, auch wenn Ihr Datenvolumen massiv steigt.

Nachteile:

• Sie müssen Hardware und Infrastruktur bereitstellen und haben natürlich auch einen gewissen Administrationsaufwand. Letzteres hängt allerdings davon ab, welche Dienstleistung Sie sich evtl. noch dazukaufen.
• Die erste Investition ist ein etwas größerer Batzen.

Wo die Software installiert ist, ist aber nur die eine Seite der Medaille. Die andere ist, wer dann mit dem System arbeitet und Ihre Prozesse umsetzt. Daher kann man grob zwei Varianten unterscheiden, wobei die Übergänge natürlich fließend sind.

Hier haben Sie alles in der Hand. Die Installation macht wahrscheinlich noch der Hersteller oder ein Dienstleister, aber die tägliche Arbeit erledigen Ihre Mitarbeiter. Das heißt, Ihre IT-Truppe (in etwas größeren Unternehmen gibt es meist auch ein eigenes EDI-Team) konfiguriert die Kommunikation mit den Partnern, baut sämtliche Arbeitsprozesse, Konvertierungen, Workflows usw. auf und bindet natürlich auch die internen Systeme an. Der Support des Herstellers sollte hier natürlich Gewehr bei Fuß stehen, aber primär ist das Ihr Job.

Das klingt erst mal nach viel Arbeit (ist es auch), zahlt sich aber andererseits aus. Denn was Sie selbst machen, kennen und verstehen Sie hinterher auch. Wenn dann irgendwelche Änderungen zu machen sind, können Sie diese schnell umsetzen, anstatt erst einem Dienstleister umständlich zu erklären, was Sie brauchen, und dann zu warten, bis er Zeit dafür hat.

Änderungen in Verfahren (zum Beispiel der Umstieg auf eine neuere Version einer EDIFACT-Nachricht) haben ja eine gewisse Vorlaufzeit, da ist das vielleicht nicht so schlimm. Aber was ist, wenn Freitagnachmittag Ihr Lieferant anruft und Ihnen sagt, dass sich in zwei Stunden IP und Name seines FTP-Servers ändern, auf den Sie immer Ihre Bestellungen schicken? Irgendjemand aus Ihrer IT-Truppe wird noch im Hause sein und die Änderungen machen können, ein Dienstleister macht vielleicht Freitag früher Schluss oder ist so eingedeckt, dass er erst Mitte nächster Woche dazu kommt.

Auch Erweiterungen der Software – soweit diese das zulässt – können Sie in Eigenregie vornehmen. Vorausgesetzt, Sie haben die passenden Leute dafür. Aber Vorsicht an diesem Punkt: Jeder Hersteller wird, auch, wenn er Ihnen die Schnittstellen (alias API) zur Verfügung stellt, jegliche Verantwortung für Codes ablehnen, den Sie selbst geschrieben oder zumindest ins System eingebracht haben. Aber hätten Sie ganz ohne Standardsoftware alles selbst geschrieben, wäre es ja auch nicht anders.

Was in diesem Szenario auf jeden Fall nötig ist, ist eine ausführliche Schulung Ihrer Mitarbeiter. Das fängt bei Administration, Datensicherung und Logging an, geht natürlich über die tägliche Bedienung, Aufsetzen von Prozessen und Kommunikation, bis hin eben zur API für eigene Erweiterungen (falls vorhanden und für Sie interessant). Und da eine Schulung meist nur die grundlegendsten Dinge und einen kleinen Teil der unzähligen Funktionen eines so komplexen Systems vermitteln kann (und davon wiederum nur ein Teil hängen bleibt), ist gerade in einem solchen Fall ein zuverlässiger, schneller und hilfsbereiter Support auf Herstellerseite unabdingbar. Erkundigen Sie sich also im Vorfeld über das Unternehmen und den Ruf, den sein Support genießt. Nebenbei sollte auch eine ausführliche Dokumentation verfügbar sein, denn ein Blick ins Handbuch geht meist schneller als die Mail an den Support.

Achten Sie übrigens darauf, dass Sie das Rad nicht jedes Mal neu erfinden. Sowohl Anbindungen von Standard-Kommunikationswegen (von AS2 bis X.400) wie auch die Handhabung der üblichen Datenformate (EDIFACT, Fortras, VDA, …) sollten vom System durch einfache Masken und bereits fertige Strukturdefinitionen unterstützt werden.

Vorteile dieser Lösung (zusätzlich zum allgemeinen „inhouse“-Teil):

• Sie wissen genau, was in Ihrem System abläuft, da Sie selbst alles aufgesetzt haben.
• Entsprechend schnell können Sie Änderungen vornehmen.
  Auf Fehler und Probleme kann sofort reagiert werden.
• Updates können Sie auch mal am Wochenende einspielen, wenn das System kurz ausfallen darf (und ein Dienstleister höchstens gegen Extra-Gebühr verfügbar wäre).
• Ihre internen Daten kommen nie in fremde Hände. Besonders wichtig ist das z.B. im Gesundheitswesen (streng vertrauliche Patientendaten) oder auch bei Banken und Versicherungen.
• Erweiterungen, falls vom System erlaubt, sind schnell möglich.
• Ihre Mitarbeiter wissen, wie der Hase läuft. Sie kennen die Prozesse in
• Ihrem Unternehmen und müssen so nicht alles erst umständlich einem Dienstleister erklären.

Nachteile:

• Um das System wirklich bedienen und administrieren zu können, brauchen Ihre Mitarbeiter eine ausführliche Schulung. Und danach einige Zeit, bis sie genug Erfahrungen gesammelt haben, um wirklich sattelfest zu sein.
• Sie sind dementsprechend auf guten und schnellen Support angewiesen.
• Sie benötigen die personellen Ressourcen, um das System zu administrieren und zu bedienen.

Alles läuft bei Ihnen vor Ort, aber der SW-Hersteller (oder ein unabhängiger Dienstleister) setzt für Sie die verschiedenen Anbindungen auf. Sie monitoren das Ganze, und bei Problemen oder Änderungswünschen kommt wieder der Dienstleister ins Spiel.
Was kann man denn so alles von einem Dienstleister machen lassen?

• Administration mit Einspielen von Updates und Bugfixes
• Einrichten der Kommunikation mit den Partnern
• Anbinden der anderen Systeme (ERP, DB, …) im Haus
• Aufsetzen von Konvertierungen zwischen Datenformaten
• Abbilden der gesamten EDI-Prozesse
• Monitoring des laufenden Betriebs und Reaktion auf Fehler

Wie viel Dienstleistung Sie in Anspruch nehmen und was Sie doch lieber selbst in der Hand behalten, können Sie natürlich im Einzelnen entscheiden. Hier schildern wir mal das Extrem, dass alles ausgelagert wird. Wobei das spätestens beim Monitoring an eine kritische Grenze stößt, denn zumindest das sollte bei einem Inhouse-System in Ihrer Hand bleiben. Auch für einen Dienstleister dürfte es schwierig werden, X Kundensysteme ständig zu überwachen, die womöglich über die halbe Welt verstreut sind.
Was Sie sich hier ganz klar sparen können, ist eine ausführliche Schulung. Sie sollten zwar trotz Allem über die grundsätzliche Funktionsweise Ihres Systems Bescheid wissen, da man seine geschäftskritischen Daten wohl nur sehr ungern einer Black Box anvertraut, aber detailliertes Wissen über Konfiguration, Administration und Abbildung der Prozesse ist in diesem Fall nicht nötig. Wenn Sie etwas brauchen, einen neuen Partner anbinden wollen, mit einem neuen Datenformat konfrontiert werden oder ähnliches, dann beauftragen Sie den Dienstleister damit. Der hat Spezialisten, die den ganzen Tag nichts anderes machen und sich in allen Ecken der Software bestens auskennen.

Womit er sich allerdings nicht auskennt, ist exakt Ihr Betrieb. EDI ist kein Feld für 08/15-Lösungen, selbst zwei oberflächlich betrachtet identische Prozesse können bei verschiedenen Unternehmen vollkommen unterschiedlich aussehen. Als Beispiel nehmen wir eine simple Datenkonvertierung von Lieferabruf-Daten aus dem Format VDA 4905 in ein EDIFACT DELFOR. Schon das VDA-Datenformat bietet so einige Freiheitsgrade, da nicht alle im Format möglichen Angaben auch tatsächlich verpflichtend gemacht werden müssen. Das EDIFACT-Format ist da noch „einen Tick“ umfangreicher.

Sie sehen auf Seite 30 rechts zum Beispiel in der Segmentgruppe 2 (SG2) ein NAD-Segment, NAD steht für „Name and address“. Ein weiteres solches Segment sehen Sie in der SG7, die unterhalb der SG6 liegt, in der es um Vorgehensanweisungen (Processing instructions) geht. Und was man hier nicht sieht: Noch weiter in den Tiefen der Struktur kommt das
NAD noch einmal vor, auf Ebene der einzelnen Positionen. Es gibt also nicht die Umsetzung schlechthin von VDA4905 in DELFOR, sondern eine ganze Palette von Möglichkeiten.

Genau hier haben Sie dem Dienstleister gegenüber einen gewaltigen Wissensvorsprung: Sie wissen, welches der vielen, im DELFOR vorkommenden, NAD-Segmente in Ihrem speziellen Fall genutzt werden soll. Oder Sie können diese Information zumindest direkt bei Ihrem Partner, für den die Daten bestimmt sind, erfragen. Hinzu kommt: Im VDA-Format gibt es gerade einmal die Kundennummern von Lieferant und Kunde, detaillierte Adressinformationen kommen hier gar nicht vor. Sie wissen aber, ob es reicht, einfach ebenfalls Kunden- und Lieferantennummer einzutragen, wie sie im VDA stehen, ob man sie von einem Nummernkreis auf einen anderen (ILN) umsetzen muss oder ob auch die gesamten Adressangaben benötigt werden. Und noch viel wichtiger: Sie wissen, aus welchem Ihrer Systeme Sie diese Informationen bekommen können und auf welchem Wege.

Das alles können Sie natürlich dem Dienstleister, der für Sie die Konvertierung aufsetzt, mitteilen. Es verursacht aber zusätzlichen Kommunikationsaufwand, der erfahrungsgemäß in ein ausgiebiges Frage-Antwort-Spiel ausartet. Bei komplexen Prozessen, die die Gegebenheiten in Ihrem Unternehmen berücksichtigen müssen, wird das Ganze noch viel spaßiger.

Was Administration, Anbindung von Systemen und Kommunikation angeht, sieht es ähnlich zweigeteilt aus. Einerseits hat natürlich der Hersteller der Software oder ein spezialisierter Dienstleister die größte Erfahrung nicht nur mit seinem System, sondern auch bezüglich des Zusammenspiels bestimmter Fremdsysteme (z.B. Datenbanken). Andererseits sind doch wieder Sie es, die erst die nötigen Informationen zusammenstellen und ihm weiterreichen müssen, damit er das Ganze dann umsetzt. Mal salopp gesagt: Bis dahin haben Sie’s auch schon selbst erledigt.

Vorteile:

• Sie müssen nicht im eigenen Hause tiefergehendes Wissen über die
• Funktionsweise des Systems aufbauen.
• Konvertierungen und andere Prozesse profitieren von der Erfahrung des
• Dienstleisters im Umgang mit der Software.
• Sie sparen sich personellen Aufwand.

Nachteile:

• Hoher Kommunikationsaufwand für jede neue Anbindung, jeden neuen Prozess und jede Änderung
• Sie müssen immer noch einen Teil der Arbeit machen, um den Dienstleister mit den nötigen Informationen zu versorgen.
• Der Dienstleister kann nicht immer sofort reagieren, Sie sind auf seine Resourcen angewiesen.
• Evtl. müssen Sie dem Dienstleister Informationen geben, die Sie eigentlich lieber im Hause behalten möchten.

Zusammenfassung:
Wenn das System schon bei Ihnen im Hause steht, sollten Sie es nutzen, indem Sie volle Kontrolle über alles behalten. Sicher können Sie einige Arbeiten an einen Dienstleister auslagern, was den anfänglichen Schulungsaufwand reduziert und schneller zu guten Ergebnissen führen kann. Erwarten Sie aber nicht, dem Dienstleister nur ein paar Stichworte zu geben und dann entspannt auf das Ergebnis warten zu können. Sie können Arbeitszeit Ihrer Mitarbeiter einsparen, aber ganz ohne geht es nicht.

Irgendwo in einem Rechenzentrum (RZ), theoretisch am anderen Ende der Welt, ist das EDI-System installiert. Der Rechenzentrums-Betreiber sorgt dafür, dass das System hochverfügbar ist, erledigt Datensicherungen, spielt Updates und Bugfixes ein und stellt natürlich die gesamte Kommunikations-Infrastruktur bereit. Sie nutzen das Ganze von Ihrem Betrieb aus über das Internet, den Browser oder einen speziellen Client. Sie können Kommunikationskanäle einrichten, sowohl vom RZ zu Ihren Partnern als auch zu Ihnen selbst, denn die Daten müssen ja auch von Ihren Systemen in das EDI-System im RZ und zurückkommen. Auch Datenkonvertierungen und Prozessketten bilden Sie so ab, wie Sie es eben brauchen, das liegt alles in Ihrer Hand. Und natürlich überwachen Sie auch selbst, ob alles sauber läuft. So weit, so gut. Sie sparen sich also eigene Hardware und Infrastruktur, und auch die ganze Systemadministration ist Sache des Betreibers.

Da nicht bei Ihnen installiert wird, bezahlen Sie auch nicht gleich ein ganzes System, sondern nur die Nutzung. Es gibt verschiedene Modelle, pro aktiver Schnittstelle, pro Anzahl der Nachrichten/Konvertierungen oder Datenvolumen oder oder oder. Das spart natürlich hohe Anfangsinvestitionen.

Allerdings stößt das Konzept schnell an seine Grenzen, wenn die Anforderungen über reine Formatkonvertierung und Kommunikation hinausgehen. Wenn Sie z.B. auch Daten anreichern müssen, vielleicht zu einer Kundennummer auch Namen und Adressdaten beschaffen, wird die Sache kompliziert. Denn solche Daten liegen nun mal auf den Datenbanken und anderen Systemen in Ihrem eigenen Netz und nicht beim RZ-Betreiber. Hier kann man natürlich eine VPN-Strecke aufbauen, über die vom Rechenzentrum aus auf Ihr Netz zugegriffen werden kann, aber abgesehen von Sicherheitsbedenken kostet so etwas doch ganz schön Performance. Außerdem ist es eine zusätzliche Schwachstelle, denn während das RZ vielleicht Hochverfügbarkeit garantiert, kann die VPN-Strecke schnell mal z.B. wegen DSL-Problemen o.ä. zusammenbrechen.

Wenn Sie reine EDI-Prozesse einfachen Aufbaus haben, nur Datentransport und -Konvertierung, ist SaaS durchaus eine Option. Einfache Anreicherungen und Umsetzungen (z.B. von Länderkürzeln) lassen sich eventuell noch über kleine Dateien etc. abfackeln. Wird aber eine engere Anbindung an Ihre restliche IT-Landschaft benötigt, stellen Sie sich mit dieser Variante schnell selbst ein Bein. Soll dasselbe System auch Aufgaben aus dem EAI oder ETL-Bereich erledigen, kommt sowieso nur eine Inhouse-Lösung in Frage.

Vorteile:

• Sie benötigen weder Hardware noch Infrastruktur (außer Internet-Anbindung).
• Ein Rechenzentrum kann eine ganz andere Verfügbarkeit gewährleisten.
• Die rein administrativen Aufgaben wie z.B. Updates kümmern Sie nicht.
• Es fallen keine hohen Anfangsinvestitionen an.

Nachteile:

• Sie sind von der Zuverlässigkeit des Betreibers abhängig.
  Der Rest Ihrer IT-Landschaft ist gar nicht oder nur mit „Klimmzügen“ zu erreichen.
• Dadurch besteht keine Chance, mit demselben System auch EAI- oder ETL-Themen abzudecken.
• Unternehmenswichtige Daten und Prozesse befinden sich in fremder Hand.
• Je nach Intensität der Nutzung und Abrechnungsmodell können die laufenden Kosten schnell teurer werden, als es eine Inhouse-Lösung gewesen wäre.

m Moment nur auf Druck Ihrer Geschäftspartner überhaupt das Thema EDI angehen und nicht mehr als eine Handvoll einfache Anbindungen zu erledigen sind, ist SaaS eine verlockende Sache. Wenn aber abzusehen ist, dass sich das ganze Thema in den nächsten Jahren ausweiten wird (und da werden Sie wahrscheinlich kaum drum herumkommen), dann suchen Sie doch nach einem Anbieter, der Ihnen beides ermöglicht!
Sie fangen mit SaaS (oder gar EDIaaS) an, und wenn die Zeit für eine Inhouse-Installation gekommen ist, ziehen die Schnittstellen einfach zu Ihnen um. Wenn es dieselbe Software ist, sollte sich so ein Umzug nicht wirklich schwierig gestalten.

Vorteile:

• Keine eigene Hardware und Infrastruktur erforderlich, stattdessen Ausfallsicherheit eines Rechenzentrums
• Der Dienstleister bietet meist eine große Palette von möglichen Kommunikationswegen an.
• Erfahrung und Routine des Dienstleisters im Umgang mit Software und Datenformaten
• Es fallen keine hohen Anfangsinvestitionen an.
• Vergleichsweise wenig eigener Arbeitsaufwand

Nachteile:

• Keinerlei Kontrolle über geschäftskritische Daten und Vorgänge
• Vollständige Abhängigkeit vom Dienstleister (Vertrauenswürdigkeit, personelle Resourcen etc.)
• Der Rest Ihrer IT-Landschaft ist gar nicht oder nur mit „Klimmzügen“ zu erreichen.
• Dadurch keine Chance, mit dem selben System auch EAI- oder ETL-Themen abzudecken.
• Je nach Intensität der Nutzung und Abrechnungsmodelle können die laufenden Kosten schnell teurer werden, als es eine Inhouse-Lösung gewesen wäre.

Noch mehr als bei SaaS gilt hier also, dass sich EDIaaS nur für wenige, sehr einfache EDI-Szenarien eignet. Wenn es nennenswert komplexer wird, taugt diese Lösung nicht mehr. Und hier noch stärker als bei SaaS sind Sie nicht mehr Herr über Ihre eigenen Daten und für Ihr Geschäft lebenswichtigen Vorgänge. Auch hier der Tip: Wenn Sie auf diesem Wege in das Thema EDI einsteigen wollen, halten Sie sich durch kluge Wahl des Anbieters die Möglichkeit offen, später auf eine Variante mit mehr Möglichkeiten (und mehr Kontrolle) umzusteigen, ohne wieder alles komplett neu aufsetzen zu müssen.

Das klingt im ersten Moment wunderbar, ist aber eben nur der Idealfall. Dazu müssen wirklich alle Kommunikationspartner an dasselbe VAN angebunden sein. In der Praxis eher unwahrscheinlich. Natürlich kann es sein, dass das VAN auch die Kommunikation nach „draußen“ anbietet, aber in dem Moment ist man dann schon wieder im normalen Internet, wo zumindest Vorteil 2 nicht mehr gegeben ist. Das Konfigurieren der diversen Kommunikationskanäle sollte sich mit anständiger EDI-Software nicht als besonders schwer erweisen, da sind wir inzwischen weiter als noch vor ein paar Jahren.

Abgesehen davon, dass es kein Netz gibt, das nicht gehackt werden kann, sind inzwischen gerade für die gesicherte Übertragung von Daten reichlich allgemein verfügbare Standards entwickelt worden. Ob HTTPS, FTPS, SFTP/SCP oder AS2, überall wird verschlüsselt. Bei AS2 gibt es gleich mehrere Ecken, an denen mit Verschlüsselung und Signatur der Daten gearbeitet werden kann. Und eine Empfangsbestätigung ist da auch Pflicht. Dieser Pluspunkt hat sich, wenn man aktuelle Übertragungstechniken verwendet, längst erledigt.

Die Vorteile, die solche VANs früher also unbestreitbar hatten, haben sich mit der Entwicklung des Internet inzwischen weitgehend erledigt. Der Nachteil aber ist geblieben:
Es kostet zusätzliches Geld. Ob nun monatliche/jährliche Gebühr oder (womöglich obendrauf) Kosten pro versendeter oder empfangener Datei, Sie zahlen noch mal extra für eine Leistung, die Sie eigentlich auch anders abdecken können.

Wie gesagt, wir sprechen hier von dem Fall, dass die zusätzlich bei EDI anfallenden Arbeiten wie Konvertierung, Abgleich, Anreicherung etc. bereits von einem speziellen System abgedeckt werden. Wenn Sie nur einfaches EDIaaS benötigen, mag das Angebot eines  entsprechenden VANs ausreichen (wobei eine Beschränkung nur auf angebundene
Kommunikationspartner heute wohl kaum noch hinnehmbar wäre …).

Wenn man das so genau sagen könnte …
Tja, was ist denn nun so ein ESB? Die einen bezeichnen ihre Software als ESB, andere eine bestimmte Infrastruktur, die sie in ihrem Unternehmen (oder ihrer Abteilung) aufgebaut haben, wieder andere sehen darin ein Architekturkonzept oder eine bestimmte Technologie. Alles ausgesprochen schwammig. Erfunden wurde der Begriff wohl, um diverse, bereits bestehende Softwareprodukte und ihre Arbeitsweise mit einem (mehr oder minder) griffigen Ausdruck zu fassen. Aber das hilft uns nicht weiter. Was also tut so ein ESB?

Alles Kommunikation
Der ESB dient der Kommunikation zwischen verschiedenen Systemen, ohne dabei großartig Logik abzubilden. Das unterscheidet ihn von EAI und EDI. Er beherrscht zwar die Sprachen (also Datenformate und Schnittstellen) aller angebundenen Systeme, und kann Informationen von einem System zum anderen leiten, aber das war’s auch schon, wenn man sich wirklich auf die Aufgaben eines „echten“ ESB beschränkt.

Ein System kann ihm also eine CSV-Datei in die Hand drücken, die er an ein anderes System weiterreicht und nebenbei auch noch in – beispielsweise – ein XML-Format umsetzt, das dieses Zielsystem versteht. Jegliche Business-Logik ist ihm aber fremd. Sinnvoll ist das, um die Kommunikation zwischen verschiedenen Systemen zu vereinfachen. Man muss nicht jedem System einzeln beibringen, wie es mit n anderen Systemen zu kommunizieren hat
(inklusive Umbau der Datenformate), sondern regelt das zentral über Adapter am ESB. So braucht der ESB nur einmal zu wissen, wie er ein CSV- in ein bestimmtes XML-Format umsetzt, ganz egal, wie viele Systeme dann über diese Formate kommunizieren wollen.

Das klingt alles sehr nach dem, was auch schon bei EAI beschrieben wurde. Und tatsächlich kann man die Arbeit eines ESB als Teil der Aufgaben der EAI betrachten. Nur, dass EAI eben auch Logik und Zusammenhänge in den Geschäftsprozessen abbildet und umsetzt, während der ESB eigentlich nur die Übersetzung und den Transport übernimmt. Da das ganze Thema wirklich ausgesprochen schwammig ist – und einige Experten sogar bezweifeln, dass dieser Begriff überhaupt seine Daseinsberechtigung hat, halten wir uns einfach nicht länger damit auf.