Aus Unternehmenssicht haben Integrationsthemen und der unternehmensweite Einsatz einer Integrationsplattform für Anwendungen weiterhin eine hohe Priorität. Folgende geschäftsrelevanten Gründe sind dafür ausschlaggebend:
• Unterstützung einer prozessorientierten, abteilungsübergreifenden Wertschöpfungskette in einem globalen und internationalen Kontext
• Realisierung von Synergien durch Firmenübernahmen (Kauf/Zusammenschluss)
• Migration von komplexen, fragilen und kostenintensiven Legacy-Anwendungslandschaften auf eine neue IT-Architektur
• Besserer Zugriff und Aufbereitung von relevanten Unternehmensinformationen
Die Bedeutung von Enterprise Application Integration hat sich dabei im Vergleich zum vergangenen Jahr kaum verändert, wie die Capgemini Studie "IT Trends 2005" zeigt. Das wesentliche Ziel ist eine flexible Integration von Anwendungssystemen und Unternehmensdaten mit Hilfe eines sicheren und steuerbaren Frameworks.
Das Thema EAI lässt sich nach heutigem Stand als Unterthema der serviceorientierten Architekturen basierend auf Webservices einordnen. Aufgrund der zunehmenden Verbreitung von serviceorientierten Architekturen wird es aber als selbstständiges Thema in einigen Jahren in den Hintergrund treten.
Darüber hinaus ist eine Ernüchterung eingetreten. Mit Hilfe einer technischen EAI-Integrationsplattform alleine lassen sich nicht notwendigerweise die erwarteten Unternehmensverbesserungen erreichen. Die unternehmensweite Integration von Anwendungen und Daten bleibt auch weiterhin eine der großen IT-Herausforderungen für die meisten Unternehmen.
Übergreifende geschäftsorientierte Sicht bei Integrationsprojekten fehlt
Die meisten IT-Entscheider können von mindestens einem EAI-Projekt berichten, das aus Geschäftssicht nicht den gewünschten Erfolg erzielt hat. Es werden hierbei zwar auch Problemfälle aus dem technischen Architekturbereich zitiert (z.B. Performance & Skalierung, Recovery von Anwendungstransaktionen), kritische Beispiele stammen aber vor allem aus dem Bereich der Schnittstelle zwischen Geschäftssicht und der IT-Sicht.
Beispiel 1: Der teure EAI Pilot
Bei dieser Vorgehensweise wird ein in einem kurzen Zeitraum (drei bis sechs Monate) durchführbares Pilotprojekt definiert, bei dem EAI ausprobiert und erste Erfahrungen gewonnen werden sollen. Typischerweise werden zwei Anwendungssysteme und eine Integration zwischen beiden als Ausgangspunkt gewählt. Basierend auf der gewählten EAI-Integrationsplattform wird die existierende Integration mit den relevanten Schnittstellen auf die Plattform portiert. Wenn man nach Beendigung des Projektes die Kosten des Piloten prüft, stellt man fest, dass sich die Einführung einer EAI-Integrationsplattform bei Extrapolation der Kosten auf die weiteren im Unternehmen vorhandenen Integrationen und Schnittstellen nicht lohnt.
Mehrere Aspekte werden hierbei außer Acht gelassen:
• Aus Kostenperspektive wird übersehen, dass sich die Kosten pro Integration nach mehreren Pilotierungen auf einem Niveau einpendeln können, das um einige Faktoren niedriger ist als beim Piloten (die Zauberworte sind hier Re-use and Integration Factory).
• Ein weiterer wichtiger Aspekt ist, dass die Einführung einer Integrationsplattform ganzheitlich angegangen werden muss (man führt ja auch nicht z.B. SAP FI pilotweise für einen einzelnen FI Prozess ein). Eine einfach berechnete Extrapolation der Ergebnisse eines EAI-Piloten, bei der nur Implementierungskosten pro Schnittstelle berücksichtigt werden, ist nicht sinnvoll. Auch die Vorteile beim Risiko-Management von Integrationsprojekten, eine bessere Transparenz und Dokumentation der Integrationslandschaft für das Aufsetzen zukünftiger EAI-Projekte und ein sicherer Betrieb durch eine einheitliche Integrationsplattform sollten berücksichtigt werden.
Beispiel 2: Die Konzern-IT macht EAI und keiner macht mit
Diese Situation tritt häufig in großen Unternehmen auf, bei denen es einen übergeordneten IT Bereich gibt, der sich um geschäftsbereichübergreifende IT Themen kümmert.
Der übergeordnete IT Bereich erhält den Auftrag eine EAI-Integrationsplattform unternehmensweit einzuführen. Es wird eine Arbeitsgruppe gebildet, die die zentrale Verantwortung für den Support der neuen Integrationsplattform erhält. Die Geschäftsbereiche verhalten sich aber sehr zurückhaltend mit einer Zustimmung zur Durchführung von Integrationsprojekten in ihrem Bereich.
Folgende Vorgehensweise kann helfen Probleme zu vermeiden:
Jedem Geschäftsbereich muss sowohl kostenmäßig als auch aus Projektrisiko-Perspektive nachgewiesen werden, dass ein EAI-Projekt langfristig dem Unternehmen und dem Geschäftsbereich nützt. Hierzu sind sowohl detaillierte Kenntnisse der Anwendungslandschaft im Geschäftsbereich als auch der assoziierten Kosten notwendig. Häufig verfügt aber die zentrale Gruppe über beides nicht. Es genügt also nicht, nur die notwendige Supportstruktur durch eine zentrale Gruppe in Leben zu rufen und zu hoffen, dass die Integrationsprojekte von allein starten.
Beispiel 3: Unternehmensbereiche setzen verschiedene EAI-Lösungen ein
Dies kann in zwei Situationen auftreten. Im ersten Fall kann es durch Eingliederung neuer Unternehmensbereiche (Kauf/Zusammenschluss) dazukommen, dass verschiedene EAI-Lösungen eingesetzt werden. In diesem Fall sollte basierend auf einer übergreifenden IT-Strategie eine Vereinheitlichung der eingesetzten EAI-Lösungen angestrebt werden.
Im zweiten Fall setzen Unternehmensbereiche untereinander unkoordiniert verschiedene EAI-Lösungen ein. In beiden Fällen gilt es, das Arbeiten und Denken in Geschäftsbereich Silos zu überwinden.
Integrationsprojekte in die Gesamt-IT-Strategie einbinden
Wie obige Beispiele zeigen, ist für den Erfolg einer Integrationsstrategie und den damit zusammenhängenden EAI-Projekten die Einbindung in die Gesamt-IT-Strategie des Unternehmens wesentlich. Diese sollte einen Horizont von drei bis zehn Jahren haben, wobei der betrachtete Zeitraum von der erwarteten Änderungsgeschwindigkeit der Geschäftsanforderungen und eingesetzter Technologien abhängt.
Folgende Fragestellungen sind erfolgskritisch für Integrationsprojekte:
• Ist eine Planung vorhanden, wie die Anwendungslandschaft des Unternehmens über einen Zeitraum von drei bis fünf Jahren angepasst wird?
• Unterstützt jemand auf Vorstandsebene die Integrationsprojekte?
• Ist die zukünftige Organisations- und Governancestruktur für die Durchführung von EAI-Projekten und den laufenden Support der EAI-Integrationsplattform definiert und genehmigt?
• Wie wird die Einbindung der Fachbereiche sichergestellt und werden tatsächlich geschäftsrelevante Probleme adressiert und gelöst.
• Wie kann sichergestellt werden, dass die Schnittstellenprogrammierung auch für weitere Schnittstellen verwendet werden kann?
• Wie wird ein inkrementelles Vorgehen bei Einführung der Integrationsplattform zum besseren Management der Risiken sichergestellt?
Abhängig von den Antworten zu obigen Fragestellungen sollte man ein EAI-Projekt kritisch überprüfen. Sind zu wenige der Erfolgsfaktoren erfüllt, kann es sinnvoll sein das Projekt nicht umzusetzen bzw. zu verschieben.
Zusammenfassend kann man einem IT-Entscheider eine Reihe von Empfehlungen mit auf den Weg geben. So sollte die eingangs zu planende "Integration Roadmap“ die Anforderungen der Geschäftsbereiche abbilden und bei den Geschäftsprozess-Integrationen anfangen.
Weiterhin ist eine Integrationsplattform in erster Linie kein technisches Problem. Dem Wunsch der eigenen IT-Mitarbeiter, die Problemstellung entsprechend umzudefinieren, muss gegengesteuert werden. Hierzu bieten sich entsprechende Change-Management-Maßnahmen in IT- und Geschäftsbereichen an. Was allerdings klar sein dürfte: Aufgrund ihres stark querschnittlichen und geschäftsbereichübergreifenden Charakters muss die Einführung einer Integrationsplattform eng mit der Gesamt-IT Strategie verzahnt sein.
Zuletzt ist der Weg zum Erfolg bei der Einführung einer Integrationsplattform eine Gratwanderung - wie bei allen großen Querschnitts-Projekten im IT-Umfeld. Deshalb sind die Positionen des Projektleiters und die des Unternehmens-Integrations-Architekten mit größter Sorgfalt zu besetzen.
Dr. Kestutis Ivinskis ist Principal IT Strategie bei Capgemini Zentraleuropa.