Enterprise Application Integration - ein unumgänglicher Übergang EAI als Voraussetzung zum e-Business E-Business hat als Ziel die Abwicklung von Geschäftstransaktionen zwischen fremden Betrieben (B2B) und zwischen Betrieben und deren Kunden (B2C). Beide Geschäftsarten setzen voraus, daß die beiden Beteiligten die gleiche Sprache und die gleichen Begriffe verwenden. Man spricht von einer gemeinsamen Ontologie. Mittlerweile gibt es mehrere Konsortien, die darauf hinarbeiten die Kommunikationsvorgänge und -inhalte zu normieren, darunter ebXML, cXML, EDI, RosettaNet, Biztalk und andere. Im Mittelpunkt dieser Bestrebungen stehen gemeinsame Begriffskataloge oder NameSpaces wie es in XML heißt. Der Namespace oder gemeinsames Wörterbuch ist die Basis für jegliche Kommunikation. Wie sollen aber fremde Firmen miteinander Daten austauschen wenn nicht einmal die Systeme innerhalb einer Firma sich miteinander verständigen können. Jedes Anwendungssystem benutzt andere Datenbezeichner für die selben Daten und andere Funktionsnamen für die gleichen Funktionen. Würde man die neuen Web-Schnittstellen aus den bestehenden Datenbanken oder Programmen ableiten, gebe es in vielen Betrieben eine Chaos sondergleichen. Der Turm vom Babel ist ein Musterbild an Einheitlichkeit verglichen zu der Situation in vielen deutschen Unternehmen. Dennoch, ohne die Normierung der Begriffe gebe es kein Einstieg ins e-Business. Außerdem müssen Geschäftspartner und Kunden Zugriff auf Daten und Funktionen in verschiedenen Anwendungen haben, denn die Geschäftsprozesse können querbeet durch alle Anwendungen laufen. Oft kann eine Anwendung allein einen e-Auftrag nicht erledigen. Sie braucht Informationen und Dienstleistungen von anderen Anwendungen. D.h. die Anwendungen eines Unternehmens müssen miteinander reden können. Anwendung zu Anwendung Kommunikation (A2A) ist also die Vorbedingung für B2B und erst recht für B2C. Wie soll aber eine Kommunikation zwischen einem alten COBOL System und einer neuen Java Anwendung stattfinden. Bestimmt nicht auf der Bit und Byte Ebene. Es müssen normierte high level Schnittstellen zwischen allen Systeme geben, Schnittstellen, die in einer gemeinsam verständlicher Sprache verfaßt sind. Hierin liegt die Bedeutung von Enterprise Application Integration. Sie soll sämtliche IT-Anwendungen eines Unternehmens in die Lage versetzen miteinander reden zu können. Jedes Anwendungssystem soll die Möglichkeit haben auf jede Datenbank zuzugreifen auf die sie ein Zugriffsrecht hat und jede öffentliche Funktion in jeder fremden Komponente aufzurufen zu deren Nutzung sie berechtigt ist. Es dürfen keine Kommunikationsbarrieren mehr zwischen den Anwendungen geben, egal aus welcher Technologie sie stammen und in welcher Umgebung sie laufen. Es ist die Aufgabe von EAI die Mauern zwischen betriebsinternen Anwendungen abzureisen und so den Weg frei zu machen für die uneingeschränkte Kommunikation nach Außen. Die Vielfalt der IT-Landschaft Leider sind die meisten deutschen Anwenderbetriebe weit entfernt von diesem Ziel. Sie ähneln dem heiligen römischen Reich am Ausgang des Mittelalters mit vielen konkurrierenden Fürstentümer und freien Reichstädte, die nur darauf bedacht sind ihre Unabhängigkeit zu bewahren und deshalb ständig in Religionskriege miteinander verwickelt sind, wobei die Religion nur als Vorwand dient um den Machterhalt zu rechtfertigen. Das obere Management - der Kaiser - hat schon längst die Kontrolle über sein Reich und die darin streitenden Parteien verloren. Das Reich, bzw. die IT-Landschaft, ist über die Jahre immer bunter geworden. Gerade bei den großen Finanzdienstleistungsunternehmen und Behörden sieht die IT-Welt aus wie die Landkarte des heiligen römischen Reiches zur Zeit der Religionskriege - total zerstückelt. Neben den alten Hostanwendungen in den klassischen Sprachen wie Assembler, PL/I und COBOL finden sich 4GL-Anwendungen, Client/Server-Systeme in C/C++ und neuerdings auch Webanwendungen in Java oder C#. Die Daten sind gespeichert in verschiedenen Datenbanksystemarten - von hierarchisch oder netzartig bis zu relational oder objektrelational. Die Benutzeroberflächen reichen von festformatierten 3270 Masken über Windows-GUI bis hin zu gestaffelten Webseiten mit Animation und Hyperlinks. Es ist alles vorhanden, all das, was uns die IT-Technologie über die letzten dreißig Jahre beschert hat, und alles dient noch einem Zweck. Viele Anwendungsbetriebe ähneln einem Gemischtwarenladen. Die Spannweite der Software reicht von den selbst gefertigten Legacy-Anwendungen, die einzelne Funktionen erfüllen, bis zu den umfangreichen ERP-Systemen, die ganze Geschäftsbereiche abdecken. Es herrscht auf jeden Fall eine große Heterogenität Dieser Zustand ist eine natürliche Folge der technischen Evolution. Die deutschen Städte sehen nicht anders aus. Es stehen Fachwerkhäuser aus dem späten Mittelalter neben Bürgerhäuser im victoranischen Stil , Prachtgebäuden aus der Kaiserzeit, Plattengebäuden aus der Nachkriegszeit und gläsernen Hochhäusern aus der Neuzeit. Der eine wohnt im Fachwerkhaus, der andere im Hochhaus - wohnen läßt sich überall, auch in einer Gartenlaube. Und so ist es auch in der IT-Welt. Jeder Benutzer arbeitet in einer bestimmten technischen Umgebung mit einem bestimmten Systemtyp. Er hat sich dort zurechtgefunden und erfüllt seine Aufgabe schlecht oder recht. Keiner würde seine Welt gegen eine Andere austauschen auch dann nicht wenn das Andere so viel besser sein sollte, denn nichts haßt der Deutsche mehr als änderung. änderung bedroht den Besitzstand. Die freie Marktwirtschaft und erst recht die globalisierte, ungebändigte Weltwirtschaft erzwingt jedoch änderungen. Die Mitarbeiter werden gezwungen Aufgaben zu übernehmen die über die Grenzen ihrer bisherigen Welt hinausgehen und dies mit unterschiedlichen Systemtypen und technischen Mittel. Sie nehmen Querschnittsaufgaben wahr, und das heißt, in einem Moment mit dem einen System arbeiten und im nächsten Moment mit einem anderen. Sie wechseln zwischen Hosttransaktionen, PC-Office-Anwendungen und Internetkorrespondenz. Um einen Auftrag zu erledigen, müssen sie oft mehrere Anwendungssysteme und Standardwerkzeuge durchqueren und ihre Ergebnisse zusammenfassen. Ab diesem Punkt werden die holprigen übergänge von einer Umgebung zur anderen zum ernsthaften Problem. Es hallt der Ruf nach "End to End Integration". Zweck und Mittel der Enterprise Application Integration Die betrieblichen Informationssysteme, die heute im Einsatz sind, spiegeln alle Datenverarbeitungsansätze der letzten drei Epochen wider. Es gibt nichts, was es nicht gibt. Das reicht von lochkartenähnlichen Datensätzen in sequentiellen Dateien, die nach den Regeln der normierten Programmierung abgearbeitet werden, bis hin zu objektrelationalen Datenbanken, auf die über SQL- und XML-Schnittstellen zugegriffen werden kann. Dennoch, eines haben sie gemeinsam. Sie erfüllen noch einen Unternehmenszweck. Insofern sind sie alle wichtig und sie sind auch alle erhaltenswert. Dies ist auch das Ziel der Enterprise Application Integration. Die Systeme sollen bleiben wie sie sind und wo sie sind. Sie müssen nur dazu gebracht werden, miteinander zu kollaborieren. Die Systemintegrationsstrategie zielt darauf hin, neue, alte und gekaufte Anwendungen so zu integrieren, daß das Unternehmen ein Maximum an Flexibilität gegenüber änderungen in der geschäftlichen Umwelt hat und zwar ohne den inneren Zusammenhalt des Unternehmens zu verlieren. Die Mittel dazu sind Standards, Frameworks, genormte Schnittstellen sowie IDL und XML , Middlewareprodukte und Source-Transformationswerkzeuge. Workflowsteuerungsrahmen sorgen für den ordnungsgemäßen Ablauf der Geschäftstransaktionen über Systemgrenzen hinweg. Frameworks sorgen für den Zusammenhalt der eigenen Anwendungen. Die Schnittstellensprachen sorgen für den reibungslosen Datenaustausch. Die Middleware sorgt für die effiziente und sichere Verbindung der Systeme. Die Transformationswerkzeuge sorgen für die nötigen Anpassungen der alten Programme und die Schaffung deren neuen Schnittstellen. EAI ist somit der Oberbegriff für die Kollaboration aller Systeme untereinander. Allerdings setzt sie eine gewisse IT-Architektur voraus. Strukturierung der betrieblichen IT Die vertikale Struktur Die Hauptursache des Integrationsproblems liegt in der vertikalen Organisation der IT-Systeme. Sie sind in der Regel nach Sachgebieten, sprich Fürstentümer, aufgeteilt. Für jedes Sachgebiet gibt es ein eigenes Anwendungssystem. Nicht selten haben sie auch eine eigene Datenhaltung. Jedes Anwendungssystem hat eine eigene Architektur und einen eigenen Implemtierungsstil. Die Systeme sind zu unterschiedlichen Zeitpunkten unter völlig anderen Bedingungen entstanden. Sie sind die Ergebnisse einmaliger Projekte, oder sie galten als einmalige Beschaffung. Wir dürfen nicht vergessen, daß bis vor kurzem die konzernübergreifende Integration der Geschäftsprozesse keine signifikante Rolle spielte. Jede Fachabteilung hat sich als eine Insel betrachtet und war nur auf das eigene Geschäft fokusiert. Es gab sogar einen Wettbewerb unter den Fachabteilungen für die knappen IT-Ressourcen. Jede wollte ihre eigene Welt auf Kosten der anderen optimieren. In einer Pionierzeit ist so ein Wettbewerb gar nicht so übel, da es zu einer schnellen Erschließung des Gebiets führt - siehe z.B. die Besiedlung des amerikanischen Westens. Er hinterläßt aber Folgen, die für eine Integration des Ganzen hinderlich sind - so in der betrieblichen Informationstechnologie. Jetzt geht es darum, die Mauern, die zwischen den einzelnen Sachgebieten errichtet wurden, damit sie unabhängig voneinander gedeihen konnten, einzureißen und Korridore zwischen den Räumen zu schaffen. Das Ziel ist nun mehr, einen einzigen Großraum zu schaffen, in dem alle Abläufe nahtlos ineinander übergehen. Es hat schon mit der Einführung von ERP-Systemen begonnen, aber spätestens seit der Verbreitung der Webtechnologie ist das Pionierzeitalter der vertikalen IT-Organisation vorbei. Die horizontale Struktur Eine Voraussetzung für die Enterprise Application Integration ist eine horizontale IT-Architektur. In einem Leitartikel für die Communications of the ACM beschreibt Prof. Wilhelm Hasselbring ein Schichtenmodell mit drei Schichten - "business architecture layer" - "application architecture layer" - "technology architecture layer". Im "business architecture layer" sind die Geschäftsobjekte und Geschäftsprozesse samt Geschäftsregeln und Anwendungsfällen quer durch alle Geschäftsgebiete definiert und modelliert. Diese Schicht ist der sogenannte überbau der IT-Architektur. Der überbau ist die Geschäftsarchitektur mit den übergeordneten Geschäftsprozessen bzw. Workflows, die quer durch alle Anwendungssysteme hindurchlaufen. Die hier ablaufenden Geschäftsprozesse verwenden die Geschäftsobjekte, die in der darunterliegenden Applikationsarchitektur angesiedelt sind. Im "application architecture layer" sind die implementierten bzw. die zu implementierenden Anwendungssysteme samt Komponenten, Modulen, Klassen, Daten und Funktionen. Die Applikationsarchitektur ist der Unterbau der IT-Architektur. Sie umfaßt die eigentliche Geschäftsobjekte, bzw. die alten und neuen Anwendungssysteme mit deren Funktionen und Daten. Hierher gehören auch die EAI-Frameworks wie Tibco, WebSphere und Silverstream. Sie bilden den Rahmen für die eigenen Objekten die größtenteils aus den bestehenden Anwendungen gewonnen werden. Im "technology architecture layer" ist die Informations- und Kommunikationsinfrastruktur des Unternehmens. Dazu gehören die Datenbanken und Systemschnittstellen, die Oberflächenrahmen, die Kommunikationsprotokolle, die Middleware und die Rechnerarchitektur. Der Grundbau ist die Technologiearchitektur bzw. die technische Informations- und Kommunikationsinfrastruktur. Dazu gehören die Datenbanksysteme, Transaktionsmonitore und Middlewaresysteme wie CORBA, ONE und .NET. Dieses Schichtenmodell ist das Ergebnis eines Business Process Reengineering Projektes, das sich quer durch alle Sachgebiete zieht - die einzelnen Anwendungen untersucht, die Redundanzen entfernt und die Kernfunktionen herauszieht und verbindet. Oft geschieht dies im Zusammenhang mit der Einführung von ERP-Systemen wie SAP/R3. Solche fachgebietsübergreifenden IT-Lösungen bedingen eine Integration der Sachgebiete über quer laufende Geschäftsprozesse. Ein weiterer Anlaß für die Einführung einer horizontalen IT-Organisation ist moderne Middleware. Middleware-Systeme wie CORBA, DCOM, Datenbank-Gateways und Online-Transaktionsmonitore verbinden entfernte Systeme über gemeinsame Transaktionen, die quer durch mehrere Anwendungssysteme hindurchlaufen und verschiedene Datenbanken verändern. Solche langen Transaktionen sind das Pendant zu sachgebietsübergreifenden Geschäftsabläufen. Während die letzteren Geschäftsvorgänge miteinander verbinden, verknüpfen die ersten Programmfunktionen aneinander. Schließlich kommt die neue Webtechnologie dazu als treibende Kraft in Richtung Unternehmens- und Systemintegration. Im Inter- bzw. Intranet herrscht die Peer to Peer-Kommunikation. Jeder Knoten im Netz kann im Prinzip mit jedem anderen Knoten kommunizieren, d.h. ihn auffordern, eine Funktion auszuführen oder eine Information zu liefern. Insofern ist jeder Knoten ein potentieller Server, aber auch ein potentieller Client. Knoten sind die Geschäftsstellen bzw. die Komponenten und die Datenbanken. Sie müssen alle in der Lage sein, Aufträge zu empfangen und Ergebnisse zu senden und zwar über einheitlich genormte Schnittstellen. Man spricht hier von Unternehmensportalen. Hindernisse bei der Integration der IT In seinem CACM Beitrag sieht Prof. Hasselbring drei Haupthindernisse auf dem Wege zu einer horizontalen IT-Schichtenarchitektur. Sie sind - Verteilung, - Heterogenität und - Autonomie Verteilung Verteilung ist an sich kein Hindernis, wenn sie geplant und gesteuert wäre. Letztlich ist die Dezentralisierung auch ein Ziel der IT-Restrukturierung. Leider ist die Verteilung in den neuesten IT-Bereichen eher zufällig entstanden. Es wurden Systeme in diverser Umgebungen ohne Rücksicht auf Interoperabilität und Kompatibilität entwickelt. Solche "Standalone Applications" sind die Folge unkoordinierter externer Anforderungen und ungebändigter innerbetrieblicher Machenschaften. Einmalige Benutzerbedürfnisse mußten schnell befriedigt werden. Es galt, ein Anwendungsvakuum zu füllen, und die Projektverantwortlichen waren nur auf das eine Problem fokussiert. Die Einkaufspolitik der Betriebe war auch nicht gerade förderlich. Jeder Abteilungsleiter durfte selbst entscheiden, welchen Rechnertyp er wo einsetzte. Hemmungslose Hardware- und Software-Verkäufer nutzten diese Situation voll aus, um ihre Produkte zu plazieren. Hinzu kamen innerbetriebliche Machtkämpfe zwischen rivalisierenden Fachabteilungen, die dazu führten, daß IT-Projekte mißbraucht wurden, um die Individualität einzelner Geschäftsbereiche auf Kosten der anderen zu stärken. So kam es, daß im selben Unternehmen verstreute Anwendungen auf verschiedenen Rechnertypen mit inkompatiblen Betriebssystemen laufen. Heterogenität Heterogenität ist eine Folge unkontrollierter 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. Bereichsleiter und Projektleiter ließen sich von den Anbietern der IT-Produkte dazu verleiten, jeden neuen Trend auszuprobieren. Statt sich an internationale Standards zu halten und nur normierte Sprachen und Datenhaltungssysteme einzusetzten, haben sie sich in eine proprietäre Falle locken lassen, aus der sie nur mit hohen Kosten wieder heraus kommen. Neben den genormten Sprachen wie COBOL und C gibt es in vielen Unternehmen proprietäre Sprachen wie Assembler und PL/I sowie mehrere 4GL-Sprachen wie Natural, ADS, CSP und PowerBuilder. Je größer die Heterogenität, desto aufwendiger die Integration. Autonomie Autonomie ist das dritte große Hindernis. Die Autonomie der Geschäftseinheiten bzw. ihre Freiheit, eigene Geschäftsobjekte, Geschäftsregeln und Dateninhalte zu definieren, führte dazu, daß viele Daten redundant geführt 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. Unterschiedliche Algorithmen, z.B. für Zinsenberechnung oder Prämienauszahlung, bleiben ungemerkt, solange sie getrennt ausgeführt werden. Werden sie aber in einer Querschnittstransaktion vereinigt, fallen die unterschiedlichen Ergebnisse sofort auf. Das Gleiche gilt für dieselben Datenattribute in verschiedenen Datenbanken mit jeweils anderen Wertebereichen. Die Autonomie der Anwendungen fördert die Inkonsistenzen der Lösungen. Solche fachinhaltlichen Inkonsistenzen sind nicht nur ein Hindernis, sondern ein Minenfeld für die Systemintegration. Der Weg zur Enterprise Appication Integration Bestandsaufnahme der vorhandenen Systeme Der Weg hin zur Enterprise Applikation Integration beginnt zunächst mit einer Bestandaufnahme aller bestehenden Systeme. Sämtliche Anwendungsssysteme sind zu erfassen und im Bezug auf ihre · Fachliche Funktionen · Technische Komponente · Benutzeroberflächen · Systemschnittstellen und · Verwendete Datenbanken bzw. Dateien zu beschreiben. Es muß entschieden werden welche Systeme in welcher Reihenfolge zu integrieren sind. Es kann sein das es sich nicht lohnt bestimmte Systeme zu integrieren. Andere werden mit besonderer Priorität integriert. Messung der vorhandenen Systeme Um die Kosten der Applikation Integration zu kalkulieren wird es auch nötig sein in einem zweiten Schritt die Source Codes, die Schnittstellen und die Datenbankbeschreibungen zu analysieren und messen. Hier wird mit Hilfe eines Code-Auditors die 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 Komplexiätsmaße sind die Schnittstellenkomplexität, die Zugriffskomplexität und die Datenkomplexität. Die wichtigsten Qualitätsmetriken sind die Modularität, die Flexibilität, die Wiederverwendbarkeit und die Kapselierbarkeit. Diese Software-Metriken dienen dazu den Aufwand für die Integration zu schätzen und das integrationsprojekt zu planen. Nachdokumentation der vorhandenen Systeme Im dritten Schritt werden die zu integrierenden Anwendungssysteme nach dokumentiert und in einer integrierten Software Repository abgebildet. Im ersten Range geht es um die Beziehungen zwischen den Programmen und den Datenbanken, zwischen den Programmen und Schnittstellen und zwischen den Programmen unter einander. Es wird angestrebt die Architektur der vorhandenen Systeme aus deren Quelldateien abzuleiten. Falls die Systeme nach unterschiedlichen Prinzipien strukturiert sind - z.B. prozedural-orientiert und objekt-orientiert - muß ihre Darstellung auf ein gemeinsames Nenner gebracht werden, bzw. die eine Struktur wird in die Andere transformiert. Wichtig ist, daß zum Schluß eine einheitliche Systemdokumentation steht wo möglichst in UML wegen der Fortschreibungsfähigkeit. Einführung eines EAI-Frameworks Die Auswahl und Einführung eines EAI Frameworks steht im Mittelpunkt des vierten Schrittes. Das Produkt soll in die IT-Landschaft des Anwenders hineinpassen und zu den bestehenden Systeme passen. Außerdem muß es ausreichend Performance und Zuverläßigkeit anbieten. Dazu wird es nötig sein, jedes Produkt verschiedenen Tests zu unterziehen ehe die Entscheidung fällt welches Produkt die Anforderungen am besten erfüllt. Hiermit darf man nicht sparen, denn mit der Wahl des richtigen Frameworks hängt der Erfolg des Integrationsprojektes ab. Kapselung der vorhandenen Komponente Im fünften Schritt werden die Programme und Datenbanken der bestehenden Systeme hinter genormten Schnittstellen gekapselt. Die Schnittstellen könnten in IDL oder XML kodiert sein. Wichtig ist, daß sie alle einheitlich und kompatibel sind. Im Hinblick auf die e-Business Anforderungen werden XML Schnittstellen vorgezogen. Mit Hilfe von Wrapping Tools ist es möglich die Schnittstellen - Masken, Dateien und Linkage Parameter - aus den Programmen herauszuschneiden und in XML Schemen bzw. IDL Schnittstellen umzusetzen. über diese Schnittstellen wird auf die Funktionen der bestehenden Programme sowie auf die Daten der bestehenden Datenbanken zugegriffen. Diese Legacy Programme bilden die Geschäftsobjekte. Workflow-Steuerung der Geschäftsprozesse Im sechsten Schritt wird die übergeordnete Workflow Steuerung der neuen Geschäftsprozesse implementiert. Diese Steuerung bewirkt die Zuteilung der Geschäftsressourcen und die Aufrufe der Funktionen in den Geschäftsobjekte. Die Workflow-Parameter bestimmen welche Funktionen in welcher Reihenfolge aufgerufen werden. Mit dem geeigneten EAI-Rahmen ist es relativ einfach die Geschäftsprozesse zu realisieren und zu verändern. Die Steuerungsprozesse können in Standardsprachen wie Java oder C# oder in speziellen Skriptsprachen verfasst werden. Bindung der Geschäftsprozesse mit den Geschäftsobjekte Im siebten Schritt werden die EAI Schnittstellen, ob XML oder IDL oder sonstige, mit den übergeordneten Geschäftsprozeß-Steuerungskomponente sowie mit den untergeordneten Geschäftsobjekt-Komponente, bzw mit den Legacy Programmen, gelinkt damit diese miteinander Aufträge und Daten austauschen können. Dieser Link Vorgang dürfte wohl weitgehend automatisiert sein. Es ist durchaus möglich aus den alten Programmen mittels Tools XML oder IDL Schnittstellen automatisch zu generieren. Test der Systemintegration Der letzte und wohl aufwendigste Schritt ist der Integrationstest. Nicht nur müssen alle Schnittstellen gezielt in allen Variationen getestet werden. Es gilt alle Geschäftsprozesse mit allen Anwendungsfällen und allen Ausprägungen jener Anwendungsfälle zu bestätigen. Für jede Schnittstelle und für jeden Anwendungsfall werden etliche Testfälle spezifiziert, generiert, durchgeführt und validiert. Bei komplexen EAI Umgebungen wird es ohne entsprechende Testautomation nicht gehen. Hier stoßt das konventionelle Testen auf seine Grenzen. Anderseits sind EAI Systeme so komplex und so vielfältig, daß nur ein ausführlicher Test genügend Vertrauen schafft um sie produktiv einzusetzen. Der Test sollte mindestens die Hälfte der Gesamtintegrationskosten betragen. Schlußfolgerung - ein Königsweg gibt es nicht, auch nicht zur EAI Leider gibt es in der IT keine Königswege. Jeder Weg in eine neue Technologie, auch in die EAI, ist langwierig, teuer und risikoreich. Wer vom Anfang an auf Interoperabilität, Kompatibilität und Einheitlichkeit geachtet hat, wird es leichter haben. Wer seinen IT-Garten verwildern lies, wird es schwieriger haben. Auf jeden Fall darf der Aufwand für EAI nicht unterschätzt werden. Wer die Schwierigkeiten der EAI unterschätzt und leichtgläubig vorgeht wird bestraft. Wer aber systematisch vorgeht und jeden Schritt genau überlegt, kann die Risiken und Kosten vermindern und seinen Schmerz um einiges lindern. EAI ist definitiv kein Spielfeld für überflieger und Dünnbrettbohrer. Der Weg zu EAI ist zwar steil und ausgesetzt, dennoch für Anwender mit Ausdauer und der nötigen Ausrüstung durchaus begehbar.