Aktuelle Themen wie Supply-Chain-Management (SCM), E-Procurement, Online-Marktplätze oder Vendor Managed Inventory (VMI) lassen das scheinbar antiquierte Konzept von EDI in den Hintergrund treten oder suggerieren, dass EDI durch diese neuen E-Business-Strategien hinfällig wird. Auch das Schlagwort Enterprise Application Integration (EAI) wird derzeit als Nachfolger für EDI und als E-Business-Enabler gefeiert. Es zeigt sich jedoch, dass moderne Management-Strategien nur durch eine Synthese von EDI- und EAI-Konzepten realisierbar sind. Hinter EDI verbirgt sich der unternehmensübergreifende Austausch von strukturierten Geschäftsdokumenten zwischen Rechneranwendungen unter Nutzung von Datenformat-Standards und Kommunikationswegen. Dabei ist das Ziel der integrierte und damit interventionslose Datenaustausch zwischen betriebswirtschaftlichen Anwendungen mehrerer Unternehmen. Zentraler Bestandteil ist die Konvertierung von standard- in anwendungsspezifische Formate und umgekehrt. Die Zielsetzung von EDI unterscheidet sich von der des EAI-Konzepts nur geringfügig. Auch EAI sorgt für den integrierten Datenaustausch zwischen betriebswirtschaftlichen Anwendungen. Die Konvertierung der Daten erfolgt jedoch zwischen verschiedenen anwendungsspezifischen Formaten, die im Unternehmen eingesetzt werden. Der elektronische Datenaustausch verläuft also nur innerhalb der Unternehmensgrenze und meist ohne Verwendung von Datenformat-Standards. Unterschiede zwischen EDI und EAI Die Unterschiede zwischen EDI und EAI können somit anhand von zwei Faktoren - verwendetes Datenformat und Kommunikationsrichtung - festgemacht werden. EDI ist also per Definition für den zwischenbetrieblichen und EAI für den innerbetrieblichen Datenaustausch zwischen betriebswirtschaftlichen Anwendungen gedacht. EDI nutzt dazu Standard-Datenformate wie Edifact, VDA, Swift, XML oder Odette, während beim EAI-Konzept die Daten meist im proprietären Format der Anwendungen bleiben. Ein Kunde bestellt auf dem Online-Marktplatz des Unternehmens zehn PCs. Die Marktplatz-Lösung, etwa von Commerce One, löst dabei folgende Prozesse aus: Die Bestellung des Kunden wird im xCBL-Datenformat vom EAI-System in das Datenformat der ERP-Applikation (SAP R/3, Sage KHK oder Oracle Applications) umgesetzt. Ferner können die Bestelldaten via EAI in das Format eines Data Warehouse und einer CRM-Software umgewandelt werden. Dabei unterscheiden sich die Konvertierungsvorgänge sowohl auf syntaktischer als auch auf semantischer Ebene. Da die PCs auftragsbezogen gefertigt werden und die zur Produktion notwendigen Teile wie Soundkarten nicht vorrätig sind, wird durch die eingesetzte ERP-Lösung eine weitere Bestellung generiert. Das EDI-System transferiert diese in ein Standardformat und verschickt sie an das Partnerunternehmen. Kauft der Lieferant die bestellten PCs jedoch selbst nur hinzu, so kann direkt aus dem Online-Marktplatz ein Auftrag generiert, durch das EDI-System konvertiert und an das Partnerunternehmen übermittelt werden. Gemeinsame Plattform Aufgrund der unterschiedlichen Kommunikationsrichtung erfolgt der Datenaustausch innerbetrieblich über API-Schnittstellen und zwischenbetrieblich über die Protokolle SMTP, X.400, FTP oder OFTP. Über welche Netze die Daten zwischenbetrieblich transferiert werden, ist dabei unerheblich. Es handelt sich auch hier um EDI, egal ob die Kommunikation per SMTP beziehungsweise FTP über das Internet oder in geschlossenen Netzen (X.400, OFTP) erfolgt. Dabei sprechen die geringen Transferkosten für das Internet, das hohe Sicherheitsniveau aber für einen Austausch über geschlossene Netze oder Value Added Networks (VANs). So kann im Gegensatz zu geschlossenen Netzwerken oder VANs beim Datenversand via Internet weder eine Zustellbestätigung noch eine rasche Übertragung der Daten garantiert werden. Die im vorangegangenen Beispiel aufgezeigten konzeptionellen Gemeinsamkeiten der EDI- und EAI-Systeme führen konsequenterweise zu einer Verschmelzung und fordern den Einsatz einer Datenintegrations- und Kommunikationsplattform. Diese Plattform wird sowohl für den internen als auch externen Datenaustausch eingesetzt. Sie integriert alle notwendigen Module:

Kommunikations-Connectoren (Protokolle oder APIs),

Syntax-Checker zur Überprüfung von standard- und anwendungsspezifischen Datenformaten,

Any-to-Any-Konverter zur Umsetzung in das Zieldatenformat,

Message-Routing zur Steuerung der Datenaustauschprozesse,