Untersuchung der Auswirkungen des strategischen IT-Business-Alignment auf die Gestaltung der IT-Architektur

2 Wissensstand

Ziel dieses Kapitels ist es, die Definitionen für die zwei Kernbereiche in der Forschungsfrage „IT-Architektur“ und „strategisches IT-Business-Alignment“ festzuhalten und den Stand der Forschung und der Praxis in diesen Bereichen darzulegen. Im Folgenden geht die Thesis zunächst auf die IT-Architektur und, neben den grundlegenden Definitionen und Charakteristika der verschiedenen Ansätze, auch auf die Technologie-Historie des SOA-Ansatzes ein.

2.1 IT-Architekturen

Wenn man sich mit dem Thema der IT-Architektur beschäftigt, wird deutlich, dass in der Literatur vor allem immer zwei Definitionen heran gezogen werden. Laut der Ersten von Venkatesh und Bates (2007) bezeichnet man damit „die Gestaltung der IT-Infrastruktur im Zusammenspiel mit den Geschäftsprozessfähigkeiten einer Organisation, um dem Bedarf eines Unternehmens an

- IT
- Geschäftsprozessintegration
- Geschäftsprozessstandardisierung

gerecht zu werden.“ [VenkateshBates2007] Die zweite Definition stammt von Ross (2003), die sagt, dass die IT-Architektur „die Übersichtlichkeit und den organisationalen Konsens in den Bereichen Technologie-, Daten-und Prozessstandards [beschreibt]. Sie liefert einen Fahrplan zur Einführung von Technologie-, Daten-und Prozessstandards und hilft dadurch, geschäftsstrategische Ziele zu erreichen und den Geschäftsnutzen zu maximieren.“ [Ross 2003] Ross führt in diesem Artikel auch die „Stadtplan-Metapher“ an, nach der die IT-Architektur „eine Art Stadtplan“ ist, der alle „Policies und Standards für den Entwurf von Infrastrukturtechnologien, Datenbanken und Anwendungen“ bis ins Detail enthält. Sie gibt aber auch sofort zu verstehen, dass diese Sichtweise nicht das „strategische Potenzial einer unternehmensweiten IT-Architektur“ adressiert. [vgl. Ross2003 S.32]

Ein weiterer interessanter Ansatz zur Beschreibung der IT-Architektur stammt wiederum von Ross aus dem Jahr 2006. In ihrem Buch „Enterprise architecture as strategy: Creating a foundation for business execution“ beschreibt sie die IT-Architektur als eine Art Fundament, auf dem man das Geschäft überhaupt erst und auch langfristig ausführen kann. [vgl. Ross2006 S.3 f.] Genauer definiert sie dabei die „Foundation of Execution“ als „die IT-Infrastruktur und die digitalisierten Geschäftsprozesse, die die Kernkompetenzen einer Firma automatisieren.“ [Ross2006 S.4] Dieser Fundament-Metapher zu folge bedeutet es, dass heutzutage kaum ein Unternehmen ohne eine IT-Architektur längerfristig lebensfähig ist.

Im Folgenden soll es um die Ausgestaltung der Architektur auf konzeptioneller Ebene gehen und vor allem darum, welche Ansätze in der Praxis verwendet werden, um eine unternehmensweite einheitliche IT-Architektur zu realisieren. In diesem Zusammenhang werden zunächst die Grundlagen wie das Modell der IT-Architekturstufen, Integration und deren Topologie sowie dem abstrakten Ansatz der Enterprise Applikation Integration (EAI) dargestellt. Danach sollen die verschiedenen Architekturansätze anhand ihrer Charakteristika beschrieben und miteinander verglichen werden, bevor im letzten Teil für den serviceorientierten Architekturansatz die historische Entwicklung von Standards und Marktangebot betrachtet wird.

2.1.1 Grundlagen

2.1.1.1 IT-Architekturstufen

Das Konzept der 4 Reifestufen einer unternehmensweiten IT-Architektur Kompetenz stammt aus dem MISQE-Artikel „Creating a strategic IT architecture competency: Learning in stages“ von Ross aus dem Jahr 2003. Ausgehend von der initialen Stufe „Application Silos“ kann diese Kompetenz über die zwei Stufen „standardisierte Technologien“ und „rationalisierte Daten und Prozesse“ bis hin zur letzten Architekturstufe entwickelt werden, der „modularen Architektur“. Dabei bringt jeder dieser Reifegrade bestimmte Vor- und Nachteile mit sich.

Im ersten Fall der „Application Silos“ gibt es noch keine unternehmensweite Gesamtarchitektur. Für die Firmen in dieser Stufe ist es nur wichtig, die bestmögliche Lösung auf einer bestimmten Technologieplattform für einen speziellen Bedarfsfall zu finden. [Ross2003] Dies führt in der Gesamtsicht zu einer hohen Heterogenität der Anwendungssysteme und Daten im Unternehmen. Zwar bringt diese Stufe Vorteile wie lokale Optimierung, geförderte Innovation und Messbarkeit des Nutzens [Ross2003] mit sich, jedoch überwiegen die Nachteile, die sich aus der Heterogenität ergeben. Ross bringt es hierbei auf den Punkt: „The applications become as much a burden as a blessing.“ [Ross2003 S.35] Mit zunehmender Anzahl der Applikationen wird es immer schwieriger, diese in die bestehende Landschaft einzubinden oder überhaupt Daten innerhalb des Unternehmens abteilungsübergreifend auszutauschen. Bei einem Blick auf die unüberschaubare Komplexität dürfte den IT-Verantwortlichen einiger Firmen nur Eines in den Sinn kommen: „[…] it’s a miracle our systems work.“ [Ross2003 S.35]

Der erste Schritt aus diesem „Wunder der Komplexität“ ist die Erreichung der nächsten Architekturstufe „standardisierte Technologien“. Unternehmen, die sich auf dieser Stufe befinden, haben unternehmensweite verbindliche Technologiestandards festgelegt, um die Technologiewahl von vornherein zu beschränken und die Anzahl der zu verwaltenden Systeme zu reduzieren. [Ross2003] Ziel ist es dabei vor allem, die Komplexität zu verringern und die Effizienz der Systeme zu erhöhen. In dieser Stufe bestehen zwar noch einzelne, getrennte Applikationen für die jeweiligen Aufgaben oder Prozesse in den Unternehmen, diese basieren jetzt jedoch auf den zuvor festgelegten Technologie- und Infrastrukturstandards. Grundsätzlich ändert sich in dieser Stufe die Vorgehensweise bei der Suche nach einer Problemlösung: „Instead of defining the solution and looking for the best technology, firms in this stage negotiate the best possible solution among the acceptable technology platforms.“ [Ross2003 S.36] Das Hauptproblem bei der Einführung dieser Standards sieht Ross in dem Widerstand der Fachseite, sich den „top-down“ bestimmter Restriktionen bei der Auswahl zu unterwerfen.

Die nächste Reifegradstufe „rationalisierte Daten“ bedeutet die Erweiterung der unternehmensweiten IT-Architektur um Daten- und Prozessstandards. In der Praxis werden hier abteilungsübergreifende Applikationen eingeführt, die die standardisierten Geschäftsprozesse des Kerngeschäfts unterstützen. Als Beispiele führt Ross (2003) die weitverbreiteten ERP-Lösungen in den Unternehmen, CRM-Systeme oder eine generelle Middleware im Unternehmen an. „These tools also make data available to the applications that need it.” [Ross2003 S.37] Damit werden in dieser Stufe die Silos aufgebrochen und vor allem die unnötige Redundanz von Daten behoben, die zu deren Inkonsistenz führt. Ein weiterer Vorteil dieses Reifegrades ist die Effizienz der Kerngeschäftsprozesse. Diese werden hierbei in der IT zum Beispiel in Form von vordefinierten und überwachten Workflows abgebildet und somit soweit wie möglich auch automatisiert. Andererseits gibt es aber gewisse Risiken bei der Erreichung dieser Stufe. Ross führt hierzu auf: „Extracting data from a firm’s legacy applications is a nontrivial technical challenge“ [Ross2003 S.38] und „A second risk is an implementation risk. A rationalized data architecture requires disciplined processes and a strong central organization.” [Ross2003 S.39] Ein Risiko ist somit die technische Herausforderung, die Legacy-Systeme im Nachhinein in die neue unternehmensweite Architektur einzubinden. Ein Anderes ist die organisationale Problemstellung, der sich eine IT-Architektur stellen muss. Ein Beispiel für eine solche Problemstellung ist der gesamte Prozess der Geschäftsprozessstandardisierung.

Der letzte Reifegrad ist nach Ross die „modulare Architektur“. Die IT-Architektur besteht zum einen aus unternehmensweiten Standards für Daten und Technologiekomponenten. Zum anderen tragen die Applikationen in dieser Stufe zu einer „strategische[n] Agilität“ [Ross2003 S.39] bei, weil sie nun aus wiederverwendbaren Modulen bestehen, die an die speziellen Bedürfnisse in den Abteilungen angepasst werden können. Dabei werden die globalen Standards gewahrt und gleichzeitig lokale Unterschiede in den einzelnen Geschäftsbereichen und Funktionseinheiten ermöglicht. Die Vorteile, die Firmen mit einer modularen Architektur haben, sind zum einen, die „Vorhersagbarkeit von Kernprozessen“, die die Wertschätzung durch den Kunden erhöhen. Zum anderen gewährleistet die lokale Anpassungsfähigkeit, Innovation und Rücksicht auf spezielle Kundenbedürfnisse. Das Risiko dieser letzten Ausbaustufe sieht Ross aber ebenfalls genau in diesem Punkt: „But without a solid process base, modules run the risk of also restoring the anarchy of hundreds of unmanaged applications.” [Ross2003 S.40] Dies würde somit einen Rückfall in eine Architektur mit vielen Silos bedeuten.

Abschließend sei noch gesagt, dass gerade größere Unternehmen komplexere Architekturen besitzen, deren Bestandteile sich auf unterschiedlichen Reifegradstufen befinden können. Ross (2003) merkt hierzu an, dass sich in der Studie kein Unternehmen auf der vierten Stufe befunden hat und es sogar nur wenige gibt, die nahe dran sind.

2.1.1.2 Integration und ihre Topologien

Eine der im vorangegangenen Abschnitt festgestellten Problemstellungen einer unternehmensweiten Architektur ist die Ex-post-Integration von Daten und Legacy-Systemen. Kaib (2002) zählt Integration aufgrund der nachfolgenden Feststellung zu den zentralen Begriffen in der Wirtschaftsinformatik:

„Das ‚Ganze‘, das es bei der Integration betrieblicher Anwendungssysteme wiederherzustellen gilt, ist die betriebliche Realität, die durch die Summe der Anwendungssysteme mit ihren Schnittstellen korrekt abgebildet werden soll. Damit soll den negativen Folgen der durch Arbeitsteilung und Spezialisierung herbeigeführten Funktions-, Prozess- und Abteilungsgrenzen entgegengewirkt werden.“ [Kaib2002 S.10]

Im Weiteren sieht Kaib den Grund für einen wachsenden Integrationsbedarf in „der zunehmenden Automatisierung betrieblicher Aufgaben durch Anwendungssysteme […]. Entsprechend wurden Konzepte einer integrierten Informationsverarbeitung in Unternehmen entwickelt und in zunehmendem Maße umgesetzt." [Kaib 2002 S.54] Diese Konzepte gilt es, in den folgenden Absätzen und Kapiteln genauer zu betrachten und ihre Charakteristika herauszustellen.

Grundsätzlich lässt sich die Integration von Systemen in drei Topologien unterscheiden: die einfache Punkt-zu-Punkt Integration [Kaib2002, AierWinter2009], die Hub&Spoke Integration [Kaib2002, AierWinter2009] und die Integration mit Hilfe eines Buses [Kaib2002].

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 2.1.1 Übersicht Topologien

Zunächst liegt es nahe, zwei Anwendungen über eine Punkt-zu-Punkt Verbindung miteinander zu verknüpfen, um einen akuten Integrationsbedarf zu decken. Hierfür werden für jede „Seite“ der Verbindung APIs entwickelt und bereitgestellt, so dass die andere Seite über diese auf Funktionen oder Daten zugreifen kann. Aber mit "zunehmender Anzahl von Verknüpfungen, zunehmender Komplexität der zu verknüpfenden Artefakt-Strukturen und zunehmender Änderungsdynamik des Gesamtsystems werden direkte Punkt-zu-Punkt-Zuordnungen immer ineffizienter." [AierWinter2009 S.176]

Als Lösung für dieses Komplexitätsproblem wird bei der Hub&Spoke Topologie eine zentrale Integrationsinstanz, der „Hub“ oder auch „Broker“, eingeführt. Jede Anwendung braucht dabei nur noch einen Adapter, der sie mit dem Hub verbindet. Dadurch werden die zuvor häufigen und komplexen Punkt-zu-Punkt Verbindungen durch wesentlich weniger Adapter ersetzt. [AierWinter2009] Allerdings bildet diese zentrale Instanz ein gewisses Risiko als „Bottle Neck“: Sobald diese ausfällt sind alle Systeme wieder isoliert. Aber auch ohne diesen „Worst-Case“ kann es zu Performance Problemen kommen, da der Broker zunächst den Adressaten jeder einzelnen Nachricht auslesen muss, um diese weiterschicken zu können.

Die letzte Variante für einen Integrationsansatz bildet die Bus-Topologie. Sie wird, ähnlich der Hub&Spoke Topologie, technisch ebenfalls mit Brokern umgesetzt. Hierbei ist aber der entscheidende Unterschied die Art und Weise, wie die Nachrichten oder Daten an andere Teile des Systems geschickt werden. Anstatt mit einem bestimmten Adressaten, werden die Nachrichten über Publish/Subscribe-Mechanis­men verbreitet. Das bedeutet der „Sender“ schickt die Nachricht in den Bus und jede andere Anwendung im System, für die diese Information wichtig ist, liest sich die Nachricht aus. Somit wird der Broker entlastet, indem er jede ihm bekannte Anwendung über die neue Nachricht informiert und dann darauf wartet, bis sich die relevanten Anwendungen diese Nachricht bei ihm abholen.

Nach einer abschließenden kritischen Betrachtung ist die Bus-Topologie am besten für große IT-Architekturen mit vielen einzelnen zu integrierenden Anwendungen geeignet. Hierbei braucht jede Anwendung nur den Broker zu kennen, sich bei ihm selbst zu „registrieren“ und eventuelle Nachrichten an ihn zu schicken. Das ist zwar auch schon größtenteils mit der Hub&Spoke Topologie abgedeckt, nur kommt im Fall des Buses noch die oben genannte Entlastung des Brokers hinzu. Ein weiterer Vorteil liegt zudem in der weitgehenden losen Kopp­lung der Systemteile aufgrund der Publish/Subscribe-Mechanis­men.

2.1.1.3 Enterprise Application Integration

Bei der Integration von Anwendungssystemen gibt es viele verschiedene Ansätze. Dabei bezeichnet Kaib (2002) die Enterprise Application Integration als einen „umfassende[n] Ansatz zur Anwendungsintegration innerhalb eines Unternehmens und über Unternehmensgrenzen hinweg. Dieser erlaubt nicht nur die Kommunikation zwischen verschiedenen Systemen und Anwendungen in einer heterogenen Systemlandschaft, sondern unterstützt auch die operative Integration von Geschäftsprozessen.“ [Kaib2002 S.81]

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.1.1 Übersicht EAI vgl. Kaib(2002) S.79

Wie auch in der Abbildung 2.1-1 zu sehen ist, verfolgt dieser Ansatz nicht nur die reine Daten- und Anwendungsintegration, sondern gilt es dabei auch die zugrunde liegenden Geschäftsprozesse mit einander zu verbinden. Kaib schreibt hierzu, dass „das Ziel von EAI in der durchgängig automatisierten Unterstützung von Geschäftsprozessen [liegt].“ [Kaib2002 S.80] Ein weiteres Ziel des EAI-Ansatzes ist die gesamte Integration „mit minimalen oder gar keinen Veränderungen an den existierenden Anwendungen oder Daten zu ermöglichen.“ [Kaib2002 S.81] Dafür sind spezielle Adapter für die bestehenden Softwarekomponenten notwendig, die diese mit einer zentralen Integrationsplattform verbinden.

Nach Kaib (2002) besteht eine EAI-Lösung im Grunde aus 6 Komponenten, wie es in Abbildung 2.1-2 zu sehen ist. Im Folgenden soll nun kurz auf die einzelnen Bestandteile eingegangen werden, wobei die rein physische Netzwerkverbindung als Grundvoraussetzung für Integration angesehen und deswegen nicht genauer betrachtet wird.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.1.2 EAI-Bestandteile vgl. Kaib(2002) S.100

Die Bestandteile Middleware und Adapter sind weitere Grundbausteine für eine Integrationslösung, denn nur mit deren Hilfe kann die Technologie-Heterogenität auf der Betriebssystem- und Applikationsebene überwunden werden. Gerade darin liegt die Hauptherausforderung bei den Adaptern. Da bei dem EAI-Ansatz bestehende Systeme gar nicht oder nur kaum geändert werden sollen, können die Adapter fast ausschließlich nur die bestehende API dieser Systeme nutzen. Kaib unterscheidet dabei noch in „thin adapters“, die die Funktionen der API standardisiert nach außen weitergeben, und „thick adapters“ [Kaib2002 S.101], die zusätzlich zum Beispiel noch eine „Transformation der Daten“ [Kaib2002 S.101] vornehmen.

Die Middleware-Schicht bildet zu den Adaptern den „Kleber“, der alles zusammen bringt: „Diese Softwareschicht stellt auf Basis standardisierter Schnittstellen und Protokolle Dienste für eine transparente Kommunikation verschiedener Komponenten in einem heterogenen und verteilten Umfeld zur Verfügung.“ [Kaib2002 S.102] Dabei gibt es verschiedene Arten und Ansätze, wie eine solche Middleware aufgebaut ist. Die genaue Betrachtung der einzelnen Ansätze und deren Charakteristika erfolgt im Kapitel 2.1.2.

Wenn es nicht schon mit einer Middleware abgedeckt wird, ist ein zusätzliches Nachrichtenmanagement nötig, um eine Verbindung auf semantischer Ebene mit Transformations- und Synchronisationsdiensten herzustellen [Kaib2002]. Transformationsdienste nehmen dabei zum Beispiel „Anpassung an unterschiedliche Datenbankschemata“ vor und Synchronisationsdienste werden notwendig um zum Beispiel Transaktionen, die das gesamte integrierte System betreffen, erst zu ermöglichen.

Wie auch in der Abbildung 2.1.1 zu sehen ist geht nach Kaib eine EAI-Lösung über die reine Daten- und Programmintegration hinaus und versucht auch auf der Geschäftsprozessebene eine Integration zu ermöglichen. Hierbei kommt nun die Komponente des Prozess­management ins Spiel und bildet damit auch die Abgrenzung zu dem reinen Middleware-basierten Integrationsansatz. [Kaib2002] Haupt­aufgabe des Prozessmanagements ist die Definition und Steue­rung „komplexer Transaktionen basierend auf den ent­sprechenden Geschäftsprozessen […].“ [Kaib2002 S.119] In der Praxis ist dies eher unter dem Begriff „Workflow“ oder die Komponenete betreffend „Workflow-Management“ bekannt. Hauptziel des Prozess- oder Workflow-Managements ist ein möglichst hoher Grad an Automa­ti­sie­rung der Geschäftsprozesse und somit auch verkürzte Durchlaufzeiten. Kaib sieht, neben Definiton und Streuerung, noch eine weitere dritte grundlegende Funktion des Prozessmanagements, die Prozess­kontrolle.

Die Letzte der sechs Komponenten ist die Metadatenbank und die Zusatzdienste in einer EAI-Lösung. Die Datenbank „beinhaltet Informationen über die integrierten Komponenten sowie über ihre Integrationsbeziehungen“ [Kaib2002 S.121] wie zum Beispiel die physische Verteilung der Komponenten. Als Beispiele für die Zusatzdienste führt Kaib „Funktionalitäten zum Systemmanagement und zur Sicherheit sowie Tools zur Entwicklungsunterstützung“ [Kaib2002 S.121f] auf.

Da das konkrete Produktportfolio der Anbieter von EAI-Lösungen meist von diesen theoretischen Komponenten abweicht, bieten Gorton und Liu (2004) eine Übersicht für die allgemeine praktische Umsetzung zu den EAI-Architekturpatterns. Dabei unterscheiden sie zwischen den abstrakten Patterns und den konkreten „commercial off-the-shelf (COTS)“ Technologien, die entweder von Unternehmen angeboten werden Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.1.3 Umsetzung von Architekturpatterns vgl. Gorton und Liu (2004) S.727

oder als Open Source Variante zur Verfügung stehen. Das „Mapping“ zwischen den beiden Seiten hat zur Folge, dass für eine konkrete EAI-Lösung mehrere Einzelprodukte vom Markt eingekauft oder andernfalls auf Basis von Open Source Produkten selbst entwickelt werden müssen. Die Entwicklung eines solchen Marktangebots wird am Beispiel der SOA-Technologien im Kapitel 2.1.3 betrachtet.

2.1.2 Charakteristika der Ansätze

Über die Zeit hinweg haben sich vor allem die Empfehlungen und Ansätze für die Gestaltung einer unternehmensweiten Architektur und Anwendungsintegration entwickelt. Die Charakteristika und die Ursprünge dieser verschiedenen Ansätze sollen nun nachfolgend in einer Art Zeitreihe genauer darstellt werden. Dabei kommen zunächst bis zum Komponenten-orientierten Ansatz, die eher einer Middleware zuzuordnenden Ansätze und danach ab dem SOA-Ansatz die Vorgehensmodelle, die über die reine Anwendungsintegration hinausgehen. SOA und EDA gehen deswegen über einen reinen Middleware-Ansatz hinaus, weil diese zum Beispiel eine nachrichtenbasierte Middleware miteinschließen und zusätzlich noch weitere Aspekte auf Geschäftsprozessebene, wie Workflowmanagement oder Prozessautomatisierung, umfassen. Und somit auch mehr Felder einer EAI-Lösung (vgl. Abbildung 2.1-2) abdecken.

2.1.2.1 Nachrichtenorientierter Ansatz

Der älteste Ansatz für die Integration von Anwendungssystemen ist der nachrichtenbasierte Ansatz. Hierbei werden Datenaustausch oder auch Funktionsaufrufe über einzelne Nachrichten realisiert, die von einem System (Sender) über eine Middleware-Schicht an ein anderes System (Empfänger) geschickt werden. Dieser Integrationsansatz ist topologisch bei Hub&Spoke und Bus einzuordnen. Die genaue Topologie hängt dabei von dem genutzten Kommunikationsprotokoll ab, wobei sich grundsätzlich drei verschiedene Arten unterscheiden lassen:

- Message Passing (Direkte Kommunikation zwischen Anwendungen)
- Message Queueing (Indirekte Kommunikation über eine Warteschlange)
- Publish/Subscribe (Herausgeber stellt Abonnenten Nachrichten zur Verfügung vgl. Abbildung 2.1-5)

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.1.4 Publish/Subscribe mit Hilfe einer Message-Queue vgl Curry2004 S.8

Zusätzlich kann bei den beiden letzten Protokollen noch in ein Pull- oder Push-prinzip unterschieden werden: beim Pull-Prinzip müssen die Empfänger oder Abonnenten selbst von Zeit zu Zeit über eventuelle neue Nachrichten informieren und diese vom Message Broker beziehen. Beim Push-Prinzip, werden die Empfänger vom Broker informiert, dass relevante Nachrichten für sie bereitliegen und abgeholt werden können. Bei beiden Protokollarten benötigt der Broker aufgrund von Warteschlangen (Queues), wie exemplarisch in der Abbildung 2.1-4 dargestellt, eine eigene Datenbank für die Nachrichten (vgl. Abbildung 2.1-5).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.1.5 Übersicht Bestandteile einer MOM nach Masak2007 S.152

2.1.2.2 Objektorientierter Ansatz

Mit dem Aufstieg von objektorientierten Programmiersprachen und –paradigmen ist es auch zu einem Umdenken in der Gestaltung von Unternehmensarchitekturen gekommen. Dabei stellt vor allem die Common Object Request Broker Architecture (CORBA) einen sehr abstrakten Ansatz für eine solche objektorientierte Middleware dar. Topologisch gesehen ist ein Hub&Spoke-Ansatz, denn eine CORBA besitzt im Kern ebenfalls einen Broker, den so genannten Object Request Broker (ORB). Dieser vermittelt nun, anstatt von Nachrichten, entfernte Methodenaufrufe und deren Ergebnisse. Unter Verwendung der Interface Definition Language (IDL) wird in einer CORBA eine formale Spezifikation der jeweiligen Schnittstellen definiert, die die Funktionalitäten für entfernte oder lokale Zugriffe zur Verfügung darstellen. Diese Funktionalitäten werden auf Client-Seite durch einen „Stub“ und das Gegenstück auf Server-Seite, dem „Skeleton“, implementiert und somit über das verteilte System hinweg nutzbar gemacht.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.1.6 Anfrage von einem Stub an sein Skeleton-Objekt

Die Client-Anwendung ruft aus ihrer Sicht nur die Funktion des Stub-Objekts auf und bekommt auch das Ergebnis des Aufrufs. Im Hintergrund leitet der Stub aber den Anruf über den ORB weiter an den Skeleton, die eigentliche Implementierung der Funktion auf Server-Seite (vgl. Abbildung 2.1-6).

Wie in der Abbildung 2.1-7 zu sehen ist, besteht eine CORBA im einfachsten Fall aus einem Client mit dem in IDL definierten Stub, dem ORB als Vermittler in der Mitte und der eigentlichen Implementierung auf Server-Seite mit dem Skeleton-Objekt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.1.7 Bestandteile einer CORBA vgl. Britton2000 S. 54

2.1.2.3 Komponentenorientierter Ansatz

Mit Komponenten als „größere Objekte“ stellt der komponentenorientierte Ansatz lediglich eine Erweiterung des zuvor genannten Objektorientierten dar. Hierbei ist aber dennoch der Ansatz der Enterprise Java Beans (EJB) interessant, da er den Schnittstellengedanken, auch in Bezug auf verteilte Systeme, noch stärker versucht umzusetzen. Dieser Ansatz wurde 1999 durch Sun Microsystems erstmals vorgestellt. Das Ziel war, einen einheitlichen Weg zu finden, Daten zu persistieren und zusätzlich transaktionelle Integrität und Sicherheit zu gewährleisten [Monson-Haefel2000]. Enterprise Java Beans gibt es in mehreren unterschiedlichen Ausprägungen für verschiedene Klassen von Anwendungsfällen. Sie können entweder „remote“, also über Prozess- und Rechnergrenzen hinweg, oder innerhalb einer VM, also lokal, angesprochen werden. Den Aufbau eines Aufrufs über eine Remote-Verbindung ist beispielhaft in Abbildung 2.1-9 zu sehen. Es lässt sich dabei wieder einen topologischen Hub&Spoke-Ansatz erkennen, da jeder Aufruf über den EJB-Server vermittelt wird.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.1.8 Aufbau einer EJB-Architektur vgl. Monson-Haefel2000

Bei den in Abbildung 2.1-8 dargestellten Bean-Klassen kann grundsätzlich in folgende 3 unterschieden werden:

- Entity Bean (modelliert und repräsentiert einen persistierten Datensatz des Systems)
- Session Bean (bildet Vorgang ab, den der Nutzer mit dem System durchführt)
- Message Driven Bean (Komponente, die EJB-Systeme für asynchrone Kommunikation zugänglich macht)

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.1.9 Ineffizienz von Entity Beans vgl. Monson-Haefel2000

Nach Monson-Haefel (2000) sind die Modellierung von Workflows und die damit verbundene Verwendung von Session Beans zu bevorzugen, da dadurch maßgeblich die Performance der EJB-Architektur gesteigert wird (vgl. Abbildung 2.1-9). Den Übergang zu der nachfolgenden serviceorientierten Architektur bilden die Message Driven Beans, mit welchen sich die Funktionalität neben der RMI-Methode auch per Webservice abbilden lässt.

2.1.2.4 Serviceorientierte Architektur

Der Ansatz einer serviceorientierten Architektur (SOA) ist keine revolutionäre Idee, die sozusagen aus dem Nichts entstanden ist, sondern hat sich viel mehr durch eine Art Evolution aus den bisherigen Ansätzen entwickelt. [Erl2008]. Einerseits bilden nun zuvor definierte Services gekapselte Funktionalität im Netzwerk an, sowie im CORBA-Ansatz, und andererseits werden der Serviceaufruf und dessen Ergebnisse über eine Nachrichtenbasierte Middleware abgehandelt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.1.10 Übersicht der Einflüsse auf SOA-Ansatz nach Erl2008 S.97

Erl (2008) sieht mehrere Einflüsse in der Serviceorientierung (vgl. Abbildung 2.1-10) und führt zusätzlich hierbei an: „It very much represents an evolutionary state in the history of IT in that it combines successful design elements of past approaches with new design elements that leverage conceptual and technology innovation.” [Erl2008 S.81f] Der Begriff „serviceorientierte Architektur“ wurde durch Schulte und Natis (1996) von Gartner geprägt. Zusammenfassend definieren sie eine SOA wie folgt:

„A service-oriented architecture is a style of application partitioning and targeting (placement). It assumes multiple software tiers and usually has thin clients and fat servers (i.e., little or no business logic on the client), but it is more than that. It organizes software functions into modules in a way that maximizes sharing application code and data.” [SchulteNatis1996 S.3]

Der Hauptbestandteil einer SOA ist dem Namen nach der Service. Er beinhaltet die Definitionen für die Schnittstellen auf beiden Seiten, wie es in Abbildung 2.1-11 zu sehen ist. Die Definition ist dabei hauptsächlich die explizite Beschreibung der angebotenen Funktionalität, das bedeutet mit welchen Parameter die Funktion aufgerufen werden muss oder ob und welche Antwort zurückgegeben wird. Zudem wird auch die Location, auf der der Service implementiert ist und angesprochen werden kann, und das zugrunde liegende Kommunikationsprotokoll definiert. Eine weitere Eigenschaft des SOA-Service ist die Abgeschlossenheit der Komponente, die den Service anbietet. Diese Abgeschlossenheit lässt sich auch in einer hohen Modularität innerhalb der Architektur wiederfinden. Die Gefahr in der Integration aufgrund dieses Ansatzes ist der topologische Rückfall zu einer reinen Punkt-zu-Punkt-Integration, wenn jeder Service direkt ohne eine ganzheitliche Integrationsplattform, wie zum Beispiel ein Enterprise Service Bus (ESB), angesprochen und benutzt wird.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.1.11 SOA-Service vgl. Krafzig 2010 S.165

Eine SOA lässt sich in der Gesamtsicht in verschiedene Ebenen differenzieren (vgl. Abbildung 2.1-12). Dabei lässt gerade noch die Service-Ebene noch in zwei weitere Ebenen trennen. Auf der unteren Ebene liegen die technischen Services, auch Basisservice genannt. Darüber liegen die Composite Service, die eine Verknüpfung verschiedener Basisservices als eigene Funktionalität nach außen anbieten. Da ein Basisservice natürlich von mehreren Composite Services oder direkt benutzt und aufgerufen werden kann, können somit viele Funktionalitäten wiederverwendet werden und brauchen nicht neu implementiert werden.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.1.12 Ebenen einer SOA vgl. Krafzig2010 S.166 & Liebhart2007 S.91

Wie zu Anfang dieses Abschnitts bereits gesagt stellt SOA per se nichts Neues dar. Aber den großen Durchbruch hatte der Ansatz zusammen mit vermehrter Benutzung der Webservice-Standards. Grund hierfür ist, dass SOA und Webservice sich gegenseitig komplementieren: auf der einen Seite die SOA als Designprinzip und andererseits Webservices als technische Umsetzung. [Natis2003]

In der gleichen Publikation sieht Natis (2003) auch einen „ironischen“ Zusammenhang zwischen „Event-driven Architectures“ (EDA) und der SOA. Obwohl EDA und SOA zu einem großen Teil Gegensätze darstellen, prophezeit er damals: „Ironically, Users Who Best Understand Event-Driven Architecture Will Be the Best Users of SOA“ [Natis2003 S.3]. Aus diesem Grund widmet sich die Arbeit nun noch abschließend dem ereignisgesteuerten Architektur-Ansatz.

2.1.2.5 Ereignisgesteuerte Architektur

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.1.13 „traditionelle“ Ereignisverarbeitung vgl. Bruns2010 S.24

In einer ereignisgesteuerten Architektur (EDA) rücken Ereignisse ins Zentrum der Gestaltung von Software- und gesamten Unternehmensarchitekturen. [Bruns2010] Die verschiedensten Ereignisse prägen seit jeher den Alltag in den Unternehmen. Beispielsweise kann ein neuer Kundenauftrag oder eine eingehende Rechnung als Ereignis betrachtet werden, auf die reagiert werden muss. Diese Ereignisse werden traditionell von menschlichen Aufgabenträgern mit Hilfe von Anwendungssystemen erkannt und verarbeitet. (vgl. Abbildung 2.1-13). In einer EDA ist die „Complex Event Processing“-Komponente für das Erkennen und das Reagieren auf Ereignisse oder Ereignismuster zuständig. Dafür benötigt diese aber eine explizite und deklarative Regelbasis, die festlegt, wann und wie auf die Ereignisse reagiert werden muss (vgl. Abbildung 2.1-14).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.1.14 automatisierte Ereignisverarbeitung vgl. Bruns2010 S.29

Die Bestandteile einer verteilten EDA sind exemplarisch in Abbildung 2.1-15 dargestellt. Demnach lässt sich die gesamte Architektur in Sensoren und Aktoren trennen. Die Sensoren der jeweiligen Bestandteile „beobachten“ die verschiedenen Ereigniskanäle und, sobald ein für sie relevantes Ereignis oder –muster auftritt, reagieren die Aktoren in diesen Komponenten, indem sie entweder wiederum eigene Ereignisse erzeugen, Datenbankeinträge tätigen oder Funktionen einer operativen Anwendung aufrufen. Für jede Art von Ereignissen ist dabei ein eigener „Ereignis-Monitor“ mit eigenem „Event Processing Agent“ (EPA) vorgesehen. Interessant ist auch die Komponente eines „Korrelationsserver“, der für die Erkennung und Verarbeitung von Ereignismustern sorgt. Im Gegensatz dazu steht der „Transformationsserver“, der für die „Verarbeitung von Einzelereignissen zuständig“ [Bruns2010 S.208] ist. Da die Integration dabei rein über Ereignisströme oder –kanäle realisiert wird, entspricht dies topologisch gesehen einer Bus-Integration.

Die Verbindung einer EDA und einer SOA ist nach Bruns (2010) der „[nächste konsequente] Schritt in der Weiterentwicklung einer Service-orientierten Architektur […].“ [Bruns2010 S.38] Beide Seiten würden ihren Vorteil aus dieser Verbindung ziehen. Einerseits ermöglicht „eine um Ereignisse angereicherte SOA agile, adaptive Geschäftsprozesse, die flexibel und zeitnah auf sich verändernde Chancen und Bedrohungen reagieren können.“ [Bruns2010 S.38] Auf der anderen Seite profitiert eine EDA von der organisatorischen Verankerung und der flexiblen Komponentenarchitektur einer SOA. Aufgrund Letzterer kann „EDA auf praktisch jeder funktionalen Ebene in der Architektur integriert werden.“ [Bruns2010 S.38] Mit dieser Kombination lässt sich die Orchestrierung von Service-Aufrufen durch das Erkennen und Reagieren auf Ereignisse oder –muster ersetzen. Die EDA kümmert sich dann darum, dass die entsprechenden Services angestoßen werden. [Bruns2010]

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.1.15 Aufbau einer EDA nach Bruns (2010)

2.1.3 Historie der SOA-Technologien

Zum Abschluss der Betrachtung der verschiedenen IT-Architekturen soll nun auf den aktuell meist diskutierten Ansatz, die SOA, genauer eingegangen werden. Dabei wird zunächst die Entwicklung der Standards für diesen Ansatz und danach noch das Marktangebot dieser Technologien im Zeitverlauf betrachtet. Die folgenden, hierfür relevanten Technologien wurden ebenfalls der Studie „Bedeutung der Flexibilität von IT-Architekturen für den Unternehmenserfolg“ entnommen:

- XML als einheitliches Datenaustauschformat
- Web-Services (WSDL, SOAP)
- Service Bus (z. B. ESB) oder eine andere (ganzheitliche) Integrationsplattform
- Service Registry / Repository
- Service-Orchestrierung z.B. mit BPEL
- Business Activity Monitoring (BAM) zur Überwachung und Optimierung der Geschäftsprozesse
- Rule Engines zur automatisierten Verwaltung von Geschäftsregeln
- Service Component Architecture (SCA) oder Service Data Objects (SDO)

2.1.3.1 Standards und ihre Entwicklung

Der Standard „Extensible Markup Language“ (XML) von 1998 hat seine Wurzeln in der Standard Generalized Markup Language (SGML) aus dem Jahr 1986. Auszeichnungssprachen wie XML und SGML dienen zur Anreicherung von reinen Textdokumenten um benötigte Strukturen und Semantik. Die benötigten Auszeichner werden auch „Tags“ genannt. Somit lassen sich zum Beispiel mit XML-Dokumenten Daten automatisiert maschinell einlesen, wobei der Inhalt der Datei dennoch für den menschlichen Benutzer lesbar bleibt. XML-Dokumente sollen dem Standard nach zunächst einmal wohlgeformt sein, das heißt unter anderem, dass es ausschließlich ein Wurzelelement gibt und jeder Tag auch wieder geschlossen wird. Zudem ist es für den Datenaustausch von Vorteil, wenn mittels eines XML-Schemas, zusätzlich zur Wohlgeformtheit, auch ein explizites Format definiert werden kann. Standardgemäß gilt ein XML-Dokument als gültig, wenn es wohlgeformt ist und das im Schema beschriebene Format einhält. Der XML-Standard bildet die Grundlage für alle der folgenden für SOA relevanten Standards.

Aus dem Versuch, nicht nur den Datenaustausch, sondern auch RPC‘s in einem verteilten System auf der Basis von XML zu standardisieren, entstand 1999 der Standard „Simple Object Access Protocol“ (SOAP). Aufgrund der Tatsache, dass der Standard sich nicht sehr „simple“ gestaltete, wurde die Langform im Laufe der Zeit verworfen und durch das Akronym ersetzt. Ziel des Standards ist eine einheitliche Form für die Nachrichten, die innerhalb von verteilten Systemen verschickt werden. Demnach soll durch den standardisierten Aufbau aus „Header“ und „Body“ die Verarbeitung optimiert werden, da hierbei lediglich der Header ausgelesen werden muss, um an die Metainformationen für Ziel der Nachricht oder zur Weiterverarbeitung zu gelangen. Der eigentliche Nachrichteninhalt, der Body, braucht daher beim Transport nicht ausgelesen werden und kann verschlüsselt übermittelt werden. Dies dient letztendlich auch der Systemsicherheit.

Der Standard „Web Service Description Language“ (WSDL) folgte dann kurz darauf im Jahr 2000 und dient dazu, wie der Name schon sagt, Web Service einheitlich zu beschreiben, um unter anderem eine automatisierte Verarbeitung zu ermöglichen. WSDL baut wie SOAP auf dem XML-Standard auf, was bedeutet, dass ein WSDL-Dokument in XML geschrieben ist. Eine weitere Absicht bei der Entwicklung des Standards ist neben der einheitlichen Beschreibung, wie der Service zu nutzen ist, auch die Beschreibung, wo genau sich der Service befindet und angesprochen werden kann.

Mit dem Ziel eine unabhängige Plattform zu schaffen, auf der Web Services beschrieben und über das Internet gesucht und gefunden werden können, wurde im Jahr 2000 der Standard “Universal Description, Discovery and Integration” (UDDI) eingeführt. Dabei bildet UDDI einen einheitlichen Verzeichnisdienst oder „Servicebroker“, in dem Provider ihre Web Service Beschreibungen ablegen können. Diese Beschreibungen werden in WSDL verfasst und bei Bedarf an den suchenden Nutzer übermittelt. Die Kommunikation mit dem Verzeichnis erfolgt dabei über SOAP-Nachrichten. Dieser Standard erleichtert potentiellen Servicekonsumenten die Suche und ggf. Nutzung des passenden Providers. Jedoch kündigten Ende 2005 die größten Unterstützer von UDDI, darunter IBM und Microsoft, an, die UDDI Business Registry nach nur fünf Jahren abzuschalten.^[1] Und von da an wurde dieser Standard nicht mehr weiter verfolgt und weiterentwickelt.

Die Webservice Business Process Execution Language (WS-BPEL) ist ebenfalls eine XML-basierte Sprache zur Abbildung von Geschäftsprozessen, deren einzelne Aktivitäten unter anderem durch Webservices implementiert sind. Der im Jahr 2002 von IBM, BEA Systems und Microsoft eingeführte Standard wird dabei zu so genannten Orchestrierungen von Webservices verwendet. Diese Beschreibung selbst wird ebenfalls in Form eines Webservice bereitgestellt und kann als ein solcher verwendet werden. Bis zur Version 1.1 hieß der Standard noch BPEL4WS (Business Process Execution Language for Webservices). Das OASIS WS-BPEL-Komitee beschloss aber 2004, die Spezifikation in WS-BPEL umzubenennen, um ein einheitliche Bezeichnung für alle WS-* Standards zu haben.

Die zwei Standards Service Component Architecture (SCA) und Service Data Objects (SDO) zeigen die neusten Entwicklungen im Bereich der SOA-Standards. Dabei ist SDO eine Spezifikation für ein herstellerunabhängiges Framework zum einheitlichen Datenzugriff und hat ihre Wurzeln in Veröffentlichungen des „Java Community Process“ aus 2004. Das Ziel von SDO ist es, einen einheitlichen Datenzugriff über verschiedene heterogene Datenzugriffsquellen zu ermöglichen. Dafür spezifiziert SDO ein API, über das unabhängig von der konkreten Technologie der Datenspeicherung standardisiert auf die Daten zugegriffen werden kann. Neben dieser Datenabstraktion stellt auch die SCA eine Erleichterung für den Aufbau einer SOA dar. Der Standard bietet nicht nur die Möglichkeit verschiedene Service zu kombinieren und orchestrieren, sondern auch eigene Servicekomponenten zu erstellen, die auf schon bestehende Funktionsimplementierungen zurückgreifen. Die erste Spezifikation zu der SCA wurde 2007 veröffentlicht.

Abschließend bildet die Abbildung 2.1-5 eine Zusammenfassung dieses Abschnitts, indem sie das Erstauftreten der Standards auf einem Zeitstrahl zeigt. Einzig der SOAP-Standard ist doppelt vertreten, da WSDL seit seinem ersten „Auftreten“ auf die Version 1.1 von SOAP stützt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.1.16 Zeitstrahl der SOA-Standards

2.1.3.2 Entwicklung des Angebot der SOA-Technologien

Inwiefern und vor allem seit wann diese Standards auch auf dem Markt für die Unternehmen zur Verfügung stehen soll nun Teil der folgenden Betrachtung sein. Anhand der Forrester-Studie „The Forrester Wave™: Comprehensive Integration Solutions, Q4 2010“ [Vollmer2010] wurden folgende Unternehmen identifiziert:

- Oracle
- IBM
- TIBCO
- Software AG

Gerade die ersten vier Unternehmen sind schon seit 2005 bei jeder Evaluation in diesem Bereich in der Spitzengruppe angesiedelt worden.

"Oracle, IBM, TIBCO Software, and Software AG continue to dominate the CIS market. With comprehensive offerings and solid customer references, these four vendors have led this market in the past four Forrester Wave evaluations of this category (2005, 2006, 2008, and 2010). This continued leadership highlights the emphasis that these four vendors have placed on improving their integration software solutions’ functionality.” [Vollmer2010]

Aktuell decken diese vier Unternehmen in der Spitzengruppe mit ihrer Produktpalette alle oben aufgelisteten Technologien ab. Auffällig ist dabei vor allem die Software AG, die nach Vollmer (2010) das stärkste Produktportfolio hat, was hauptsächlich mit den Zukäufen in jüngster Vergangenheit zusammenhängt. Die anschließenden Zeitstrahlen lassen für jede Technologie erkennen, welche Unternehmen eine gewisse „Vorreiterstellung“ in der Vergangenheit eingenommen haben und neue Technologien früh auf dem Markt angeboten haben. Zudem ist für jede Firma auch das entsprechende Produkt aufgeführt, mit dem die jeweilige Technologie angeboten wird. Die Werte, also wann welche Firma welche Technologie zuerst angeboten hat, wurden größtenteils aufgrund der Release-Informationen der einzelnen Produkt-Portfolios identifiziert. Einzig der komplette Datensatz zur SOA-Historie in der Firma Oracle wurde von einem Mitarbeiter der Firma bereitgestellt. Die genaue Übersicht mit den jeweiligen Quellenangaben ist im Anhang zu finden.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.1.17 SOA-Historie XML

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.1.18 SOA-Historie Web Services

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.1.19 SOA-Historie Service Bus

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.1.20 SOA-Historie Registry und Repository

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.1.21 SOA-Historie Orchestrierung

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.1.22 SOA-Historie Business Activity Monitoring

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.1.23 SOA-Historie Rule Engines

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.1.24 SOA-Historie Service Component Architecture

Zunächst einmal lässt sich sehr gut erkennen, wenn man zudem den Zeitstrahl in der Abbildung 2.1-5 aus dem vorangegangen Kapitel betrachtet, dass die Unternehmen, die bei der Entwicklung der Standards beteiligt waren, auch kurz darauf ein entsprechendes Produkt dem Markt angeboten haben. Ebenfalls stellen Service Bus und Rules Engine relativ neuere Entwicklungen dar, obwohl die zugrunde liegenden Technologien wesentlich früher bekannt und verfügbar waren. SCA ist dagegen ein gutes Beispiel dafür, dass die betrachteten Unternehmen jetzt verstärkt auf SOA setzen und deswegen den Standard aus 2007 verhältnismäßig schneller umgesetzt und dem Markt angeboten haben.

Das Kapitel abschließend werden im Folgenden die wichtigsten Kernpunkte aus der bisherigen Betrachtung der Literatur und Praxis zu IT-Architekturen noch einmal dargestellt. Die IT-Architektur ist demnach die konkrete Gestaltung der IT-Infrastruktur im Zusammenspiel mit den Geschäftsprozessfähigkeiten [VenkateshBates2007] und der dafür notwendige unternehmensweite Konsens in den Bereichen Technologie-, Daten-und Prozessstandards. [Ross 2003] In der Literatur lassen sich zudem mehrere treffende Metaphern für die IT-Architektur im Unternehmen finden. Für das Management kann sie „eine Art Stadtplan“ sein, anhand dessen ein Überblick auf die IT-Infrastruktur im Unternehmen möglich wird. Auf der anderen stellt sie auch das „Fundament“ dar, auf dem das gesamte Unternehmen „errichtet“ ist. Die von Ross (2003) vorgestellten Reifegrade einer IT-Architektur ermöglichen zudem eine Einordnung und Bewertung von Architekturen in den Unternehmen. Die Erkenntnis, dass ein höherer Reifegrad mehr Integration zum Teil erst ermöglicht oder sogar benötigt, ist der Beweggrund sich mit der Thematik der Integration weiter auseinander zu setzen. Dabei wird in die drei Topologien Punkt-zu-Punkt, Hub&Spoke und Bus unterschieden, die sich im weiteren Verlauf in den Charakteristika der Integrationsansätze wiederfinden lassen. Diesen konkreten Ansätzen wird aber zuvor der abstrakte Ansatz der EAI gegenübergestellt, der die Integration im Unternehmen in einer Art „Makro-Sicht“ beschreibt. Zum Ende des Kapitels mit der Analyse der Historie für SOA und der Erkenntnisse aus der Entwicklung der aller Architekturansätze, bleibt als Feststellung, dass die Ansätze bis hin zu einer SOA eine Evolution durchlaufen haben und diese Evolution sich auch im Marktangebot und der Entwicklung der Standards wiederfindet.

2.2 Strategisches IT-Business-Alignment

Nach dem zuvor dargestellten Grundverständnis von IT-Architekturen soll sich nun in diesem Kapitel dem IT-Business-Alignment gewidmet werden. Welchen Grund aber gibt es, sich mit IT-Business-Alignment auseinander zu setzen? "Die Forderung nach einem IT/Business Alignment ist vor allem als Reaktion auf das sog. Produktivitätsparadoxon der IT zu verstehen." [Teubner2006 S.368] Das Produktivitätsparadoxon ist dabei auf Brynjolfsson (1993) zurückzuführen, nach dem steigende Investitionen in IT scheinbar zu keinen oder sogar zu negativen Produktivitätsentwicklungen führen. Ungefähr 15 Jahre später gibt Chan (2007) mit ihrem Artikel im „Journal of Information Technology“ eine Übersicht der Antworten auf die Frage „IT alignment: what have we learned?“. Demnach gibt es in der Literatur viele Synonyme für Alignment, wie zum Beispiel „fit“, „integration“ oder „harmony“. Aber so viele Synonyme wie sich in der Literatur finden lassen, so verschieden sind auch die Sichten oder Dimension des Alignments: „In the MIS literature, several dimensions of alignment are clearly apparent: strategic/intellectual, structural, social, and cultural.” [Chan2007 S.300] Entscheidender sind aber die bereits in der Literatur identifizierten Auswirkungen des Alignments, die Teil der Betrachtung im nächsten Abschnitt sind.

Aufgrund der hohen Komplexität der gesamten Alignment-Thematik beschränkt sich diese Thesis auf die strategische Dimension des IT-Business-Alignments. Im Folgenden wird daher ausgehend von den zwei grundsätzlichen Sichten auf das Alignment als Zustand und Prozess vor allem auf das Strategic Alignment Model nach Henderson und Venkatraman (1999) eingegangen.

2.2.1 Alignment als Zustand

Eine mögliche Sicht auf das IT-Business-Alignments ist, es als einen gewissen Zustand im Unternehmen anzusehen, inwiefern die IT und die Fachseite auf einander abgestimmt und integriert sind. Letztendliches Ziel der bisherigen und aktuellen Arbeit auf diesem Gebiet ist das Aufzeigen der Auswirkung des Alignments auf die Performance des Unternehmens. Darüber hinaus kann sich durch eine strategisch „well-aligned IT“ ein ganzer Industriezweig verändern. [vgl. Chan(2007) S.307] Nach der Betrachtung der bisher aufgedeckten Wirkungen des Alignments, wird zudem im weiteren Verlauf auf das Alignment Paradoxon nach Tallon (2003) und die Probleme bei der Messung des konkreten Zustands eingegangen.

2.2.1.1 Wirkung auf Performance

Ein gemeinsamer Konsens ist dabei, dass es nicht von der speziell genutzten Technologie abhängt, ob die IT einen Wertschöpfungsbeitrag leistet oder nicht, sondern davon, wie die IT benutzt und gemanagt wird. [HuangHu2007] Auf diese Nutzung der IT und die IT-Flexibilität wirkt sich nach Beimborn et al. (2006) das Alignment positiv aus. Demnach hat ein hoher Wert an Alignment zum einen eine verstärkte Nutzung von Informationssystemen und zum anderen eine erhöhte IT-Flexibilität zur Folge. Wobei sich beide wiederum auf die Performance positiv auswirken.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.2.1 Wirkung des Alignment nach Beimborn et al. (2006)

Eine weitere indirekte Wirkung auf den Business Value hat das strategische IT-Business Alignment nach Kearns und Sabherwal (2006) über die IT-Projekte. Demnach hat ein hohes Maß an stategischem Alignment eine höhere Planungsqualität bei IT-Projekten zur Folge. Auf der anderen Seite vermindert es auch die Probleme bei der Implementierung in IT-Projekten. Da nun sich die Qualität positiv und die Implementierungsprobleme negativ auf den Business Value der IT auswirken, steigert ein hohes strategisches Alignment den Business Value.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.2.2 Wirkung des Alignment nach Kearns und Sabherwal (2006)

2.2.1.2 Alignment Paradoxon

Im Gegensatz dazu stehen die Ergebnisse von Tallon (2003), der bei seiner Untersuchung der Wirkung des Alignments auf den IT Business Value, vermeintlich auf ein Paradoxon gestoßen ist. Demnach führt die Steigerung des strategischen Alignments nur bis zu einem gewissen Punkt auch zu einer Steigerung des Business Value, danach wirkt sich eine weitere Steigerung negativ aus. Tallon erklärt sich den Grund darin, dass das strategische Alignment der Flexibilität entgegensteht, die Unternehmensstrategie an Änderungen in der Umwelt anzupassen. Die eigentliche Ursache für dieses Paradoxon könnte jedoch in dem Versuch liegen, einen direkten Zusammenhang zwischen dem strategischen Alignment und dem IT-Geschäftswert finden. Dass zwischen dem Alignment und der Performance kein einfacher und direkter, sondern ein komplexer und von der Geschäftsstrategie abhängiger Zusammenhang vorliegt, lässt sich aber bereits bei Sabherwal und Chan (2001) finden. Diesen Aspekt greifen Beimborn et al. (2006) mit ihrer Frage „What is the impact of business strategy type on IT business value creation?” bei ihrer Betrachtung der Auswirkungen des IT-Business-Alignments mit auf. Ein Ergebnis ihrer Untersuchung war die Unterstützung der Ergebnisse von Sabherwal und Chan (2001): „The importance of alignment for performance was found to be significant for prospectors and analyzers but not for defenders. Thus, an emphasis on alignment may not be beneficial for business success in the case of defenders. […] we can support this finding.” [Beimborn2006 S.593] Demnach bedeutet es, gerade für Unternehmen mit den IT-Strategietypen “Prospector“ und „Analyzer“ sollte das Thema Alignment ein wichtiger Punkt sein. Dabei gelten Unternehmen als „Prospector“, wenn sie mit ihrer IT stets auf der Suche sind mit Hilfe von neuen innovativen Technologien einen Vorsprung zu erlangen. Wohingegen die „Analyzer“-Strategie nicht sofort neue Technologien produktiv einsetzt, sondern die ersten Praxis-Tests bei den „Prospectors“ abwartet und daraufhin, im Fall von positiven Effekten, schnell folgt.

2.2.1.3 Messbarkeit von Alignment

Trotz der vermeintlichen Lösung des Alignment-Paradoxon, bräuchte es in der Praxis für die Unternehmen ein Verfahren, das den aktuellen Grad an strategischem Alignments feststellt. Chan (2007) sieht für die Unternehmen eine hohe Bedeutung der Messbarkeit, denn nur wenn das Alignment messbar ist, kann es auch besser gemanagt, wie zum Beispiel die Wirkungsweise von getroffenen Maßnahmen bewertet werden. Mehre Ansätze zur Messung, wie zum Beispiel mittels Modellen, mathematischen Berechnungen oder spezifische Fragenkataloge für Befragungen, wurden mit der Zeit entwickelt. [Chan2007] Dennoch stellen diese Methoden weniger einen praktikablen Ansatz für die Unternehmen als dar, den aktuellen Zustand einfach festzustellen.

2.2.2 Alignment als Prozess

Die gegensätzliche Sichtweise auf das IT-Business-Alignment lässt sich gut anhand eines Zitats zusammenfassen: "IT-business alignment is not a static state; it’s a continuous maturing process over the long run" [HuangHu2007 S.175] Aufgrund dessen ist neben den Auswirkungen eines gewissen Zustandes des Alignments vor allem der Weg hin zu dem gewünschten Niveau wichtiger für die Unternehmen. Nach Luftman (2003) ist es schwieriger das Alignment zwischen IT und Business aufrecht zu erhalten als beide getrennt voneinander weiter zu entwickeln. Dabei gibt es zwar keine „silver-bullet solution, but achieving alignment is possible.“ [Luftman2003 S.9] Mögliche Wege zur Erreichung von strategischen Alignment sollen nun im Folgenden aufgezeigt werden.

2.2.2.1 Ziele und Erfolgsfaktoren

Eines der wichtigsten Ziele des strategischen Alignment-Prozesses sieht Masak (2006) darin, „einen hohen Grad an architektonischem, kognitiven und temporalem Alignment für das ‚Tagesgeschäft‘ zu erreichen.“ [Masak2006 S.163] Mit architektonischem Alignment meint er dabei, die Abstimmung der IT-Architektur und IT-Prozesse mit den Geschäftsprozessen. Gerade für die praktische Umsetzung benötigen Unternehmen Regeln oder Erfolgsfaktoren, die ihnen helfen, den Alignment-Prozess so durchzuführen, dass am Ende auch das gewünschte Ergebnis steht. Hierfür haben Teo und Ang bereits 1999 eine Liste der Top 12 kritischen Erfolgsfaktoren für die Abstimmung von IT und Business Plänen mit Hilfe einer Befragung aufgestellt:

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 2.2.1 Kritische Erfolgsfaktoren für das strategische Alignment nach Teo&Ang (1999) und Chan (2007)

Wenn man dabei nur allein die obersten fünf Punkte betrachtet, sieht man, dass ein hohes strategisches Alignment in erster Linie von dem Stellenwert und dem Wissen über die IT im Unternehmen und den betriebswirtschaftlichen Kompetenzen in der IT-Führung abhängt.

2.2.2.2 Methoden im Alignment-Prozess

In der Literatur lassen sich, neben der reinen Abstimmung des IT-Plans mit dem Unternehmensplan, zwei weitere Methoden finden. Ein möglicher Weg hin zu einem hohen strategischen Alignments ist die unternehmensweite Einführung von Balanced Score Cards im Unternehmen. Dies hat nach Huang und Hu (2007) folgende vier Kernaspekte des strategischen Alignments zur Folge:

- Integrierte Planung von IT und Business
- Erhaltung effektiver Kommunikationskanäle
- Entwicklung einer starken Beziehung zwischen IT und Business
- Institutionalisierung einer Alignment-Kultur

Der Alignment-Prozess geht dabei von einer „Corporate Strategy Map“ aus. Von diesem langfristigen Geschäftsplan werden jährlich eine „Corporate Scorecard“ und daraus dann die „Scorecards“ für die einzelnen Abteilungen abgeleitet. Am Ende bestimmen die Ziele für die Abteilungen der Fachseite die Planung der IT und der „IT Department Scorecard“.

Einen anderen Weg, ein strategisches IT-Business Alignment zu erreichen, untersuchten Kearns und Sabherwal (2006) mit dem „Knowledge-Based View of Strategic Alignment“. Demnach ist das strategische Alignment das Ergebnis der Wissensintegration von IT- und Unternehmensführung. Die zwei Wege dieser Integration sind einerseits die Beteiligung der IT-Manager an der Erstellung des Geschäftsplans und andererseits die Beteiligung der Business-Manager an der strategischen IT-Planung. Vorausgesetzt aber das Top-Management hat ein substanzielles Wissen über die Funktion und Nutzen der IT im Unternehmen, wie auch schon zuvor bei den kritischen Erfolgsfaktoren nach Teo und Ang (1999) zu erkennen war.

2.2.2.3 Schwierigkeiten des Alignment-Prozess

Einen weiteren Grund für die Forschung, sich mit dem Alignment-Prozess zu beschäftigen, sind die Probleme und Hindernisse in der betrieblichen Realität, die meist einen hohen Grad an Alignment verhindern. In der Literatur lassen sich einige dieser Probleme finden. Das Problem einer fehlenden konkreten Unternehmensstrategie beschreiben Sauer und Willcocks (2002) so:

"Part of the problem is that strategy has become a moving target — it's hard to build a technology platform to support visions based on capabilities a company might have" [SauerWillcocks2002 S.41]

Es ist offensichtlich, dass ohne eine explizit formulierte Unternehmensstrategie auch keine effektive und darauf abgestimmte Planung der IT erfolgen kann. Ein weiteres Problem sehen Huang und Hu (2007) in der unterschiedlichen Kultur und Sprache zwischen IT und Business:

"In contrast to the traditional corporate vocabularies of finance, marketing, and sales, IT technical jargon and lingo do not resonate with the syntax and lexicon of the boardroom, and this culture gap between IT and business has been shown to be an impediment to aligning the IT function with the rest of the business […]. But, without an overall commitment and culture to rid it of gaps and silos, and a mechanism to deal with the inevitable shift in business and market conditions, the IT alignment process would likely be unsustainable in the long run.” [HuangHu2007 S.174f]

Folglich dessen haben alle Anstrengungen im Alignment-Process höchstens einen kurzfristigen Effekt, wenn nicht zunächst die beschriebenen Gräben zwischen den Silos überbrückt und gebrochen werden.

2.2.3 Strategic Alignment Model

Eine weitere umfassendere Sichtweise auf das strategische Alignment fassten Henderson und Venkatraman (1999) in ihrem Strategic Alignment Model (SAM) zusammen. Das gesamte Konzept basiert dabei auf einem „strategic fit“ innerhalb des Business oder der IT und der „functional integration“ [HendersonVenkatraman1999 S.474] zwischen Business und IT. Zusätzlich wird jede Seite noch in eine externe und eine interne Domäne unterschieden. Daraus ergeben sich, wie man an der Abbildung 2.2-1 erkennen kann, vier Bereiche im SAM:

- Business Strategy
- IT-Strategy
- Organizational Infrastructure and Processes
- IT Infrastructure and Processes

Die externe Domäne besteht auf Business und IT-Seite aus bestimmten Entscheidungen, wie zum Beispiel zu „make-or-buy“-Fragestellungen oder zur Frage, mit welchen Produkten ein Wettbewerbsvorteil generiert werden. Hingegen gehören Entscheidungen zu Organisations- und Prozessstrukturen oder zur Entwicklung von Mitarbeiterfähigkeiten in die interne Domäne.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.2.3 Strategic Alignment Model nach HendersonVenkatraman1999

Nach Henderson und Venkatraman (1999) ergeben sich aus dem SAM vier dominante Perspektiven auf das strategische Alignment. Wobei jeder dieser „Wege“ zu einem Alignment aller vier Bereiche führt, obwohl nur drei Bereiche einbezogen sind. Auf jede der Perspektiven wird nachfolgend näher eingegangen und welche Rollen dabei das jeweilige Management innehat.

Die erste Perspektive „Strategy execution“ geht davon aus, dass eine Business Strategie formuliert ist und aufgrund derer die Gestaltung der Organisation und der IT-Infrastruktur angepasst werden (Abbildung 2.2-4). In diesem Fall nimmt das Top Management die Rolle des „strategy formulator“ ein. Das heißt, es legt initial die Strategie fest, die das IT-Management als „strategy implementor“ mit einer effektiven und effizienten IT-Infrastruktur unterstützen soll. Henderson und Venkatraman (1999) sehen in dieser Perspektive die am meisten verbreitete und verstandene Perspektive, weil es dem klassischen hierarchischen Blick auf das strategische Management am nächsten kommt.

Die zweite Perspektive, die von einer vordefinierten Business Strategie ausgeht, ist die „Technology transformation“. Die gewählte Strategie wird durch eine entsprechende IT-Strategie und die erforderlichen Prozesse und Infrastrukturen implementiert (Abbildung 2.2-5). Dabei liegt nach Henderson und Venkatraman besonders ein Einfluss der Kernkompetenzen auf die IT-Governance und die „systemic competencies“, wie zum Beispiel die IT-Flexibilität, vor. In der Perspektive hat das Top Management eine bestimmte Vision davon, wie die IT die Business Strategie am besten unterstützen könnte. Dem IT-Management bleibt hierbei die Aufgabe des „technology architect“, der versucht im Sinne der IT-Vision eine effektive und effiziente IT-Infrastruktur zu entwerfen und zu implementieren.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.2.4 Strategy execution Perspective

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.2.5 Technology transformation Perspective

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.2.6 Competitive potential Perspective

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.2.7 Service level Perspective

Den umgekehrten Weg, beginnend bei der IT-Strategie über die Business Strategie bis in die Geschäftsprozesse, bildet die dritte Perspektive „Competitive potential“ (Abbildung 2.2-6). Hierbei werden die Ressourcen und Fähigkeiten der IT (IT-Capabilities) genutzt, um neue Produkte und Dienstleistungen auf dem Markt zu positionieren oder um neue Formen von Geschäftsbeziehungen aufzubauen. Dadurch nimmt das Top Management die Rolle des „business visionary“ ein, in der es festlegt, inwiefern die IT-Capabilities Einfluss auf die Geschäftsstrategie haben. Im Gegensatz dazu hat das IT-Management nun die Aufgabe, die Trends im Umfeld zu erkennen und dem Top Management dabei zu helfen, die Chancen und Risiken aus IT-Sicht zu verstehen.

Als Vierte und Letzte gibt es nach Henderson und Venkatraman (1999) noch die Perspektive „Service level“ des strategischen IT-Business-Alignments (Abbildung 2.2-7). Der Fokus liegt im Aufbau einer „world-class IS service organization“. [HendersonVenkatraman1999 S.479] Bedingung dafür ist aber das Verständnis des Zusammenspiels zwischen externer IT-Strategie und der internen Gestaltung der IT-Prozesse und –Infrastruktur. Die Rolle der IT-Manager ist dabei das interne „service business“ erfolgreich zu gestalten. Die Rahmenbedingung, wie Verwendung von raren Ressourcen im Unternehmen, legt das Top Management in der Rolle des „prioritzer“ fest.

Betrachtet man abschließend den Aufbau des SAM und seine Perspektiven lässt sich auch die Forschungsfrage wiedererkennen. Demnach sollen dann im Kapitel 3 Erkenntnisse gewonnen werden, wie sich die „functional integration“ zwischen IT und Fachseite auf die interne Domäne der IT und im Detail auf die IT-Architektur auswirkt.

Schließlich soll nun im folgenden Abschnitt die Erkenntnisse zu dem strategischen IT-Business-Alignment noch einmal kurz zusammengefasst und die Eckpunkte festgehalten werden. Seit Jahren ist das IT-Business-Alignment die bestimmende Problematik für die Unternehmen [Luftman2010] und gilt als eine Reaktion auf das Produktivitätsparadoxon nach Brynjolfsson (1993). Dabei gilt es für die Unternehmen gerade die vielen verschiedenen Dimensionen des Alignments, die sich in der Literatur finden lassen, zu beachten. Generell kann man bei der Sicht auf das Alignment entweder von einem Zustand oder dem Prozess der Abstimmung von IT und Business im Unternehmen sprechen. Dabei bleibt aus der Perspektive des Zustandes festzuhalten, dass das Alignment durchaus eine nachgewiesene Wirkung auf die Performance im Unternehmen hat. Jedoch ist das nur eine indirekte Wirkung, entweder über die IT-Projekte [KearnsSabherwal2006] oder über die IT-Flexibilität und der Nutzung von IS [Beimborn2006]. Zudem bestehen gerade für die Unternehme gewisse Probleme diesen Zustand des Alignments zu messen. Auf der anderen Seite kann man das IT-Business-Alignment auch als einen fortlaufenden Prozess der Abstimmung sehen. Die wichtigsten Erfolgsfaktoren des strategischen Alignments betreffen vor allem das Top Management und deren Einstellung bezüglich der IT. Darüber hinaus lassen sich in der Literatur auch Methoden und Herangehensweisen finden die den Prozess fördern, wie zum Beispiel die Einführung von Balanced Score Cards. Aber dieser Prozess ist in Praxis mit vielen Schwierigkeiten behaftet. Gerade die unterschiedlichen Auffassungen von Problemstellungen sind hierbei hinderlich. Um ein abschließendes gesamtes Bild vom strategischen Alignment zu bekommen, eignet sich vor allem die Betrachtung des Strategic Alignment Model (SAM) von Henderson und Venkatraman (1999). Dabei sind die Perspektiven auf das SAM gut geeignet, Betriebe mit unterschiedlichen Unternehmenskulturen mögliche Wege zur Erreichung des strategischen Alignments aufzuzeigen.

[...]

^[1] http://uddi.microsoft.com/about/FAQshutdown.htm (05.02.2011 aufgerufen)