Das Wichtigste zuerst: Die Vorstellung, dass eine SOA-Lösung per Zusammenfügen von herstellerfremden Funktionsbausteinen aufgebaut werden könnte, ist eine Illusion. Der Aufwand, der nötig ist, um die Heterogenität zu überwinden, ist in vielen Fällen zu groß für einen langfristig wirtschaftlichen Betrieb solcher Plattformen. (Siehe auch: "Was bleibt vom Hype?")

Die SOA-Architektur lässt sich mit Hilfe von Technologie-Sets, "SOA-Stacks" genannt, vollständig abbilden. Aber worum handelt es sich dabei eigentlich? Um installierbare Werkzeuge zur Anwendungsintegration, um Prozessmodellierungs-Tools mit Programmierschnittstellen oder doch eher um einen gedanklichen Architekturansatz zur Verknüpfung von Prozessmodellen mit realen Anwendungskomponenten? Die Unterscheidung fällt oft schwer.

Die erste Ebene der Integration

Viele Anbieter nennen den Enterprise Service Bus (ESB) als erste Integrationsebene für die unterschiedlichen Geschäftsapplikationen. Er soll die Interaktion der Anwendungsfunktionen in den bestehenden Systemen ermöglichen. Doch hier beginnt bereits das Problem mit der Heterogenität.

Betrachten wir einmal eine typische Situation - den Einsatz eines CRM- und eines ERP-Systems unterschiedlicher Anbieter bei einem Produktionsunternehmen: Die Funktionen zur Erfassung eines neuen Kunden sind sowohl im CRM- als auch im ERP-System abgebildet, aber auf unterschiedliche Weise. Das CRM-System verlangt Informationen über die Ansprechpartner des Kunden, das ERP-System Daten für die Debitorenbuchhaltung. Auch das Datenmodell ist nicht einheitlich ausgeprägt. Im CRM-System wird der Kunde zunächst im Stammdatenobjekt "Interessent" verwaltet; erst bei Auftragserteilung wird er zum "Kunden". Das Datenbankfeld für die Kundennummer ist im CRM-System ein numerisches Feld mit der Bezeichung "Cust-No", im ERP-System ist es alphanumerisch und heißt "Kd-Nr". Das CRM-System ist in einem .NET-Framework implementiert, das ERP-System auf RPG-Basis realisiert.