Begriff Integration

5 Juli, 2009 - 18:38

Der Begriff "Integration" wird häufig im IT und betriebswirtschaftlichen Umfeld ohne eine genaue Definition und Reflektion verwendet. In diesem Artikel gebe ich einen Überblick, welch vielfältige Feststellungen sich allein bei Betrachtung des Begriffs Integration machen lassen. Das lässt auch erkennen, warum die Integration nicht einfach zu bewerkstelligen ist, sondern eine große Herausforderung sowohl für IT als auch für Betriebswirtschaft darstellt.

Oberflächlich betrachtet, könnte man Integration als das Verknüpfen oder Zusammenführen von verschiedenen Systemen definieren. Bei dieser Definition bleibt allerdings unerwähnt, dass man den Begriff Integration sowohl als Charakterisierung eines Zustands (z.B. 2 Systeme sind integriert oder eben nicht) als auch einen Prozess zur Herstellung einer entsprechenden Verknüpfung begreifen kann. Sprachlich richtig wäre, wenn im zweiten Fall nicht von Integration gesprochen würde, sondern von Integrierung [1]. Allerdings tut dies niemand in der Praxis, denn sonst müsste man von einem Integrierungsprojekt und nicht einem Integrationsprojekt sprechen.

Betrachtet man Integration als einen Zustand, kann man diverse Fragestellungen bzw. Dimensionen aufspannen. So ist zum Beispiel zu klären, ob 2 Systeme lediglich verknüpft werden sollen oder ob eine vollständige Vereinigung stattfinden soll. Hierbei wird der Integrationsumfang (oder Reichweite) definiert. In der Praxis muss zum Beispiel abgewogen werden, ob zum Beispiel eine zugekaufte Firma vollständig in die eigenen Geschäftsprozesse integriert werden soll oder ob man die Firma als möglichst eigenständigen Teil mit eigenen Geschäftsprozessen weiterführen will. Auch in IT Projekten muss definiert werden, ob ein neues IT System auch die Aufgaben eines alten IT Systems vollständig übernehmen soll (also eine Vereinigung) oder ob das Altsystem weiterbetrieben wird und lediglich eine punktuelle Verknüpfung mit dem neuen IT System stattfindet.

Der Integrationsfokus legt fest, welche Elemente eines Systems integriert werden sollen. So ist es zum Beispiel denkbar, dass man bei der Zusammenführung von 2 Firmen zunächst lediglich die unterstützenden Prozesse wie die Lohnbuchhaltung oder das Rechnungswesen integriert, nicht aber die wertschöpfenden Kernprozesse. Systeme können auf unterschiedlichen Abstraktionsniveaus betrachtet werden. Entsprechend muss festgelegt werden, ob eine horizontale oder vertikale Integration angestrebt wird. 

Versteht man Integration als Prozess, muss man zum Beispiel das Vorgehen, das angestrebte Ziel, die notwendigen Werkzeuge und Hilfsmittel sowie die Verantwortlichkeiten klären. Es sollte auch untersucht werden, ob eine Automatisierung des Integrationsprozesses möglich ist.

Dieser kurze Überblick zeigt, dass die Integration von Systemen eine komplexe Problematik ist. Dies dürfte einer der Gründe dafür sein, dass die gerade im IT Bereich zur Verfügung stehenden Technologien nicht ausgereift sind oder lediglich Teilaspekte abdecken. Auch wenn es mit den verfügbaren Technologien wie Enterprise Service Bus, Workflow Engines (z.B. BPEL, XPDL) und Application Servers (z.B. J2EE, .NET) vielleicht gelingt die technischen Aspekte zu meistern, wird häufig übersehen, dass auch IT Systeme so genannte soziotechnische Systeme sind, die in ein menschliches Umfeld eingebettet sind. Dieser Kontext bewirkt, dass eine rein technische Integration fehlschlagen wird, wenn nicht gleichzeitig auch an einer fachlichen Integration gearbeitet wird. In diesem Sinne erscheint es logisch, Integrationstechnologien (z.B. SOA) mit einer fachlichen Methodik (z.B. BPM) zu verknüpfen. Die Beschreibung und Untersuchung der dabei auftretenden Herausforderungen ist Ziel dieser Seite!

[1] Maik Thränert: Integration-Engineering - Grundlagen, Vorgehen und Fallstudien. Leipziger Beiträge zur Informatik Band XV, 2009, ISBN 978-3-941608-02-3; Zusammenfassung


Kommentare

Hi Sebastian,
mit dem Ansprechen der Relevanz der fachlichen Integration sprichst du meiner Ansicht nach einen sehr wichtigen Punkt an. Denn häufig ist festzustellen, dass eine technische Integration zwar oft eine Herausforderung darstellt, aber i.d.R. lösbar ist. System A bietet die Schnittstellen xy, ist in der Sprache yz programmiert, die Datenbank enthält folgende Tables, etc.
Bie einer fachlichen Integration steht man teilweise sogar vor dem Problem, dass Prozesse z.B. gelebt werden, aber keiner sie so richtig kennt: Eben Ghost Prozesse.
Ich glaub, dass auch die Wichtigkeit der fachlichen Integration ein Grund ist, wieso viele SOA Projekte fehlschlagen. Viele Firmen sehen SOA immer noch nur als reines technisches Integrationsthema. Dadurch erhält man dann zwar integrierte Systeme, aber eben nur rein technisch. Ein langfristiger Nutzen lässt sich dadurch oft nicht ziehen.
Stimmst du mir da zu?

Gruß
Jens

Hallo Jens,
genau, du sprichst hier die Problematik an, dass SOA von vielen Middleware Anbietern lediglich als rein technisches Produkt verkauft wurde. Das war für die Middleware auch eine logische Vertriebsstrategie, denn so konnten sie die bereits vorhandenen EAI Produkte, die in den 90er auf den Markt kamen, durch einfaches Rebranding neu auflegen.
Die Ursachen für das Problem liegen nicht nur bei den Herstellern, denn auch die Kunden hätten besser hinterfragen müssen. Es gibt keinen Grund, warum man eine naive Herstelleraussage wie "Kaufen sie diese Technologie und es wird alles effizienter" nicht hinterfragt.
Gruß,
Sebastian