Heterogenität ist eine Folge der unkontrollierten Verteilung. Dort, wo IT-Projekte ohne Abstimmung untereinander aufgesetzt wurden, konnte jedes Projekt eine andere IT-Technologie anwenden. Es entstand ein Wildwuchs an Entwicklungsumgebungen, Programmiersprachen und Datenbanksystemen.
Die Autonomie der Geschäftseinheiten, beziehungsweise ihre Freiheit, eigene Geschäftsobjekte, Geschäftsregeln und Dateninhalte zu definieren, führte dazu, dass viele Daten redundant gehalten werden und viele Geschäftsregeln widersprüchlich sind. Innerhalb der einen Anwendung mag alles stimmig und redundanzfrei sein, aber im Zusammenspiel mit anderen Anwendungen kommen Namenskollisionen und Regelunverträglichkeiten vor.
Bestandsaufnahme der Systeme
Der Weg hin zur Enterprise Applikation Integration beginnt deshalb zunächst mit einer Bestandsaufnahme aller vorhandener Systeme. Sämtliche Anwendungssysteme sind zu erfassen und in Bezug auf ihre fachlichen Funktionen, technischen Komponenten, Benutzeroberflächen, System-Schnittstellen und verwendeten Datenbanken beziehungsweise Dateien zu beschreiben. Es muss entschieden werden, welche Systeme in welcher Reihenfolge zu integrieren sind.
Um die EAI-Kosten zu kalkulieren, wird es auch nötig sein, in einem zweiten Schritt die Sourcecodes, die Schnittstellen und die Datenbank-Beschreibungen zu analysieren. Hier werden mit Hilfe eines Code-Auditors Quantität, Qualität und Komplexität der Systeme gemessen. Die wichtigsten Größenmaße sind die Code-Zeilen, Anweisungen, Schnittstellen, Module, Dateien, Datenbanken, Datenattribute, Data-Points und Function-Points. Die wichtigsten Komplexitätsmaße sind die Schnittstellen-, die Zugriffs- und die Datenkomplexität. In der Qualitätsmetrik tauchen Aspekte wie Modularität, Flexibilität, Wiederverwendbarkeit und Kapselung auf. Diese Softwaremetriken dienen dazu, den Aufwand für die Integration einzuschätzen und das Integrationsprojekt zu planen.
Im dritten Schritt werden die zu integrierenden Anwendungssysteme nachdokumentiert und in einem gemeinsamen Software-Repository abgebildet. In erster Linie geht es dabei um die Beziehungen zwischen den Programmen und den Datenbanken, zwischen den Programmen und Schnittstellen sowie zwischen den Programmen untereinander. Es wird angestrebt, die Architektur der vorhandenen Systeme aus deren Quelldateien abzuleiten. Falls die Systeme nach unterschiedlichen Prinzipien strukturiert sind, zum Beispiel prozedural- oder objektorientiert, muss ihre Darstellung auf einen gemeinsamen Nenner gebracht beziehungsweise die eine Struktur in die andere transformiert werden. Wichtig ist, dass zum Schluss eine einheitliche Systemdokumentation steht - möglichst in der UML.