Lade Inhalt...

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

Bachelorarbeit 2011 56 Seiten

Informatik - Wirtschaftsinformatik

Leseprobe

Inhaltsverzeichnis

Abbildungsverzeichnis

Tabellenverzeichnis

Abkürzungsverzeichnis

1 Problemstellung

2 Wissensstand
2.1 IT-Architekturen
2.1.1 Grundlagen
2.1.1.1 IT-Architekturstufen
2.1.1.2 Integration und ihre Topologien
2.1.1.3 Enterprise Application Integration
2.1.2 Charakteristika der Ansätze
2.1.2.1 Nachrichtenorientierter Ansatz
2.1.2.2 Objektorientierter Ansatz
2.1.2.3 Komponentenorientierter Ansatz
2.1.2.4 Serviceorientierte Architektur
2.1.2.5 Ereignisgesteuerte Architektur
2.1.3 Historie der SOA-Technologien
2.1.3.1 Standards und ihre Entwicklung
2.1.3.2 Entwicklung des Angebot der SOA-Technologien
2.2 Strategisches IT-Business-Alignment
2.2.1 Alignment als Zustand
2.2.1.1 Wirkung auf Performance
2.2.1.2 Alignment Paradoxon
2.2.1.3 Messbarkeit von Alignment
2.2.2 Alignment als Prozess
2.2.2.1 Ziele und Erfolgsfaktoren
2.2.2.2 Methoden im Alignment-Prozess
2.2.2.3 Schwierigkeiten des Alignment-Prozess
2.2.3 Strategic Alignment Model

3 Auswirkungen des strategischen IT-Business-Alignment
3.1 Forschungs- und Messmodell
3.2 Daten und Vorgehen
3.3 Ergebnisse
3.3.1 Stand des Alignments in den Unternehmen
3.3.2 Stand der Gestaltung von IT-Architekturen
3.3.3 Auswirkungen des Alignments auf die Gestaltung
3.3.4 Auswirkungen des Alignments auf den Einsatz der SOA-Technologien

4 Konklusion und Diskussion
4.1 Besonderheiten
4.2 Resümee
4.3 Limitationen
4.4 Folgen für Theorie und Praxis

Literaturverzeichnis

Anhang

Abbildungsverzeichnis

Abbildung 2.1-1 Übersicht EAI vgl. Kaib(2002)

Abbildung 2.1-2 EAI-Bestandteile vgl. Kaib(2002)

Abbildung 2.1-3 Umsetzung von Architekturpatterns vgl. Gorton und Liu (2004)

Abbildung 2.1-4 Publish/Subscribe mit Hilfe einer Message-Queue vgl Curry2004

Abbildung 2.1-5 Übersicht Bestandteile einer MOM nach Masak2007

Abbildung 2.1-6 Anfrage von einem Stub an sein Skeleton-Objekt

Abbildung 2.1-7 Bestandteile einer CORBA vgl. Britton2000

Abbildung 2.1-8 Aufbau einer EJB-Architektur vgl. Monson-Haefel

Abbildung 2.1-9 Ineffizienz von Entity Beans vgl. Monson-Haefel

Abbildung 2.1-10 Übersicht der Einflüsse auf SOA-Ansatz nach Erl2008

Abbildung 2.1-11 SOA-Service vgl. Krafzig 2010

Abbildung 2.1-12 Ebenen einer SOA vgl. Krafzig2010 166 & Liebhart2007

Abbildung 2.1-13 „traditionelle“ Ereignisverarbeitung vgl. Bruns2010

Abbildung 2.1-14 automatisierte Ereignisverarbeitung vgl. Bruns2010

Abbildung 2.1-15 Aufbau einer EDA nach Bruns (2010)

Abbildung 2.1-16 Zeitstrahl der SOA-Standards

Abbildung 2.1-17 SOA-Historie XML

Abbildung 2.1-18 SOA-Historie Web Services

Abbildung 2.1-19 SOA-Historie Service Bus

Abbildung 2.1-20 SOA-Historie Registry und Repository

Abbildung 2.1-21 SOA-Historie Orchestrierung

Abbildung 2.1-22 SOA-Historie Business Activity Monitoring

Abbildung 2.1-23 SOA-Historie Rule Engines

Abbildung 2.1-24 SOA-Historie Service Component Architecture

Abbildung 2.2-1 Wirkung des Alignment nach Beimborn et al. (2006)

Abbildung 2.2-2 Wirkung des Alignment nach Kearns und Sabherwal (2006)

Abbildung 2.2-3 Strategic Alignment Model nach HendersonVenkatraman

Abbildung 2.2-4 Strategy execution Perspective

Abbildung 2.2-5 Technology transformation Perspective

Abbildung 2.2-6 Competitive potential Perspective

Abbildung 2.2-7 Service level Perspective

Abbildung 3.1-1 Forschungsmodell

Abbildung 3.3-1 Profildiagramm Strategie-Alignment vs. Verwendung von Standards

Abbildung 3.3-2 Profildiagramm Strategie-Alignment vs. Wiederverwendbarkeit

Abbildung 3.3-3 Profildiagramm Organisations-Alignment vs. Integration

Abbildung 3.3-4 Profildiagramm Organisations-Alignment vs. Heterogenität

Tabellenverzeichnis

Tabelle 2.1-1 Übersicht Topologien

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

Tabelle 3.1-1 Übersicht Aussagen für IT-Architektur

Tabelle 3.1-2 Übersicht Aussagen strategisches Alignment

Tabelle 3.1-3 Übersicht Fragen SOA-Technologien

Tabelle 3.3-1 Stand des Alignments

Tabelle 3.3-2 Gestaltung von IT-Architekturen

Tabelle 3.3-3 Übersicht Angaben zum Einsatz von SOA-Technologien

Tabelle 3.3-4 Übersicht Korrelationen (Spearmans Rho) ** α < 0,01 ; * α < 0,05

Tabelle 3.3-5 T-Test für die Mittelwertgleichheit bei strat. Alignment (Strategien)

Tabelle 3.3-6 T-Test für die Mittelwertgleichheit bei strat. Alignment (Organisationsstrukturen)

Tabelle 3.3-7 Vergleich der Kodierungen für Einsatzreichweite und Alignment

Tabelle 3.3-8 Übersicht Korrelationen (Spearmans Rho) ** α < 0,01 ; * α < 0,05

Tabelle 3.3-9 T-Test für die Mittelwertgleichheit bei strat. Alignment (Strategien)

Tabelle 3.3-10 T-Test für die Mittelwertgleichheit bei strat. Alignment (Organisationsstrukturen)

Tabelle 3.3-11 T-Test für die Mittelwertgleichheit bei taktisch-operatives Alignment

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

1 Problemstellung

Das Thema „IT-Business-Alignment“ zählt seit Jahren zu den Top-Aufgabenstellungen für die Verantwortlichen auf IT- und Fachseite. Deutlich wird dies, wenn man hierfür die jährliche Studie „Top 10 IT Management Concerns“ von Luftman und Ben-Zvi (2010) betrachtet. Hierin ist das Thema „IT and Business Alignment“ seit 2003 entwe- der auf Platz 1 oder wie auch zuletzt, aktuell für 2009, auf den zweiten Platz gesetzt worden. Wichtiger für die Unternehmen ist nur noch das Thema „Business Productivity and Cost Reduction“ aufgrund der Wirtschaftskrise gewesen. Was aber umfasst der Begriff des Alignment alles? Und worin liegt die Brisanz des Themas vor dem Hinter- grund folgender Aussage?

“But for every success story about IT, one can find a counterexample. Despite its critical role, to many companies, IT is still a necessary evil.” [HuangHu2007 S.173]

Die Ursache für diese große Streuung des Geschäftswertbeitrags der IT liegt in der Abstimmung zwischen IT und Fachbereiche [Chan2007], oder eben anders gesagt, am IT-Business-Alignment. Gerade diese Wirkung aber auch die anderen Effekte des Alignments sind seit über 30 Jahren ein wichtiges Forschungsgebiet der Wirtschaftsin- formatik. Aus dieser Forschungstradition heraus ist der heutige Stand, dass Alignment viele verschiedene Facetten aufweist, was wiederum zu einem komplexen Wirkungs- geflecht bezogen auf die Performance der Unternehmen führt. [Chan2007]

Auf der anderen Seite steht die IT-Architektur in den Unternehmen, deren Wertschät- zung und Design-Paradigmen sich in den letzten Jahren ebenfalls gewandelt haben. Der Blick auf die IT-Architektur hat sich von einem reinen „Stadtplan“ [Ross2003] der IT-Infrastruktur hin zum Rückgrat des Unternehmens („Foundation of Execution“) [Ross2006] entwickelt. Am Ende der Paradigma-Evolution steht im Moment die ser- viceorientierte Architektur (SOA), welche aber gerade in der Anfangszeit oft nur als „Buzzword“ von Beratungsfirmen und Softwareherstellern missbraucht wurde. [Kacz- marekWecel2008] Mittlerweile ist der große Hype um SOA vorüber und die Produktivi- tät der Produkte in diesem Bereich steigt, was auch der Gartner’s Hype Cycle for Emerging Technologies aus 2010 zeigt. Hierauf ist SOA nicht mehr zu finden, nach dem es das Jahr zuvor noch im „Slope of Enlightenment“ (Anstieg der Aufklärung) ver- treten war.

Worin liegt nun die Motivation diese Thematik der IT-Architektur beziehungsweise die- se zusammen mit den Wirkungsbeziehungen des Alignments aufzugreifen? Gerade das strategische Alignment war bis vor ein paar Jahren der Schwerpunkt in der Align- ment-Betrachtung. Dadurch entstanden zahlreiche Modelle wie das Strategic Align- ment Model (SAM) nach Henderson und Venkatraman (1999). Mit einem Blick auf das SAM, das versucht, die verschiedenen Möglichkeiten zur Erreichung des strategi- schen Alignments aufzuzeigen, lässt sich ebenfalls die IT-Architektur als Bestandteil finden. Es gibt zwar Untersuchung anhand des SAM unter anderem von Avison et al. (2004), jedoch widmet sich keine davon der konkreten Ausprägung der IT- Architekturen in den Unternehmen, wenn ein hohes oder niedriges Alignment vorliegt.

Mit dieser Bachelor-Thesis soll nun dieser Teilaspekt der Alignment-Forschung erar- beitet werden. Dabei richtet sich der Focus auf die Auswirkungen des IT-Business- Alignment, im speziellen des strategischen Alignments, auf die Gestaltung der IT-Architektur im Unternehmen. Hierbei wird das gemessene Ausmaß an Alignment innerhalb der Firmen mit den Eigenschaften ihrer IT-Architekturen verglichen und versucht Zusammenhänge aufzudecken.

Hierzu gliedert sich das weitere Vorgehen wie folgt: Ausgehend von der Betrachtung der Literatur zu den beiden Kernthemen IT-Architektur und IT-Business-Alignment in Kapitel 2, werden in Kapitel 3 die eigentlichen Ergebnisse der Untersuchung vorgestellt. Bevor dann in Kapitel 4 die Ergebnisse noch bewertet und den Erkenntnissen aus Kapitel 2 gegenübergestellt werden.

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 ITInfrastruktur 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 organisationa- len Konsens in den Bereichen Technologie-, Daten-und Prozessstandards [be- schreibt]. Sie liefert einen Fahrplan zur Einführung von Technologie-, Daten-und Pro- zessstandards 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 wiede- rum 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 aus- fü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 Zusammen- hang werden zunächst die Grundlagen wie das Modell der IT-Architekturstufen, In- tegration und deren Topologie sowie dem abstrakten Ansatz der Enterprise Applikati- on 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 Tech- nologien“ 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 Gesamt- architektur. 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 Anwen- dungssysteme 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 schwieri- ger, 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ächs- ten Architekturstufe „standardisierte Technologien“. Unternehmen, die sich auf dieser Stufe befinden, haben unternehmensweite verbindliche Technologiestandards festge- legt, 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 o- der Prozesse in den Unternehmen, diese basieren jetzt jedoch auf den zuvor festge- legten Technologie- und Infrastrukturstandards. Grundsätzlich ändert sich in dieser Stufe die Vorgehensweise bei der Suche nach einer Problemlösung: „Instead of defin- ing 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 un- terwerfen.

Die nächste Reifegradstufe „rationalisierte Daten“ bedeutet die Erweiterung der unter- nehmensweiten IT-Architektur um Daten- und Prozessstandards. In der Praxis werden hier abteilungsübergreifende Applikationen eingeführt, die die standardisierten Ge- schäftsprozesse des Kerngeschäfts unterstützen. Als Beispiele führt Ross (2003) die weitverbreiteten ERP-Lösungen in den Unternehmen, CRM-Systeme oder eine gene- relle 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 auf- gebrochen 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 Kern- geschäftsprozesse. Diese werden hierbei in der IT zum Beispiel in Form von vordefi- nierten und überwachten Workflows abgebildet und somit soweit wie möglich auch au- tomatisiert. 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 or- ganization.” [Ross2003 S.39] Ein Risiko ist somit die technische Herausforderung, die Legacy-Systeme im Nachhinein in die neue unternehmensweite Architektur einzubin- den. 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 be- steht zum einen aus unternehmensweiten Standards für Daten und Technologiekom- ponenten. Zum anderen tragen die Applikationen in dieser Stufe zu einer „strategi- sche[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 Unter- schiede in den einzelnen Geschäftsbereichen und Funktionseinheiten ermöglicht. Die Vorteile, die Firmen mit einer modularen Architektur haben, sind zum einen, die „Vor- hersagbarkeit 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 applica- tions.” [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 Archi- tekturen besitzen, deren Bestandteile sich auf unterschiedlichen Reifegradstufen be- finden können. Ross (2003) merkt hierzu an, dass sich in der Studie kein Unterneh- men 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 LegacySystemen. 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 wieder- herzustellen gilt, ist die betriebliche Realität, die durch die Summe der Anwendungs- systeme mit ihren Schnittstellen korrekt abgebildet werden soll. Damit soll den negati- ven 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 unterschei- den: 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 "zuneh- mender Anzahl von Verknüpfungen, zunehmender Komplexität der zu verknüpfenden Artefakt-Strukturen und zunehmender Änderungsdynamik des Gesamtsystems wer- den 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-Mechanismen verbreitet. Das bedeutet der „Sender“ schickt die Nachricht in den Bus und jede andere Anwen- dung im System, für die diese Information wichtig ist, liest sich die Nachricht aus. So- mit 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 ge- eignet. 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 Kopplung der Systemteile aufgrund der Pub- lish/Subscribe-Mechanismen.

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 „umfas- sende[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 Sys- temlandschaft, sondern unterstützt auch die operative Integration von Geschäfts- prozessen.“ [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 liegen-den Geschäftsprozesse mit einander zu verbinden. Kaib schreibt hierzu, dass „das Ziel von EAI in der durchgängig automatisierten Unterstützung von Geschäftsprozes- sen [liegt].“ [Kaib2002 S.80] Ein weiteres Ziel des EAI-Ansatzes ist die gesamte In- tegration „mit minimalen oder gar keinen Veränderungen an den existierenden An- wendungen 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 Bestand- teile eingegangen werden, wobei die rein physische Netzwerkverbindung als Grund- voraussetzung für Integration angesehen und deswegen nicht genauer betrachtet wird.

Prozessmanagement

Nachrichtenmanagement

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 Pro- tokolle 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 Kapi- tel 2.1.2.

Wenn es nicht schon mit einer Middleware abgedeckt wird, ist ein zusätzliches Nach- richtenmanagement nötig, um eine Verbindung auf semantischer Ebene mit Trans- formations- und Synchronisationsdiensten herzustellen [Kaib2002]. Transformations- dienste nehmen dabei zum Beispiel „Anpassung an unterschiedliche Datenbank- schemata“ 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 Prozessmanagement ins Spiel und bildet damit auch die Abgrenzung zu dem reinen Middleware-basierten Integrationsansatz. [Kaib2002] Hauptaufgabe des Prozessmanagements ist die Definition und Steuerung „komplexer Transaktionen basierend auf den entsprechenden 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 Automatisierung der Geschäftsprozesse und somit auch verkürzte Durchlaufzeiten. Kaib sieht, neben Definiton und Streuerung, noch eine weitere dritte grundlegende Funktion des Prozessmanagements, die Prozesskontrolle.

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 unter- scheiden sie zwischen den abstrakten Patterns und den konkreten „commercial off- the-shelf (COTS)“ Technologien, die entweder von Unternehmen angeboten werden

Architectural Patterns

Abstract

Abbildung in dieser Leseprobe nicht enthalten

Concrete COTS technologies

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 Ge- staltung einer unternehmensweiten Architektur und Anwendungsintegration entwickelt. Die Charakteristika und die Ursprünge dieser verschiedenen Ansätze sollen nun nach- folgend 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 rei- nen Middleware-Ansatz hinaus, weil diese zum Beispiel eine nachrichtenbasierte Mi- ddleware miteinschließen und zusätzlich noch weitere Aspekte auf Geschäftsprozess- ebene, wie Workflowmanagement oder Prozessautomatisierung, umfassen. Und so- mit 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 MiddlewareSchicht 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 in- formiert, 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 gekom- men. Dabei stellt vor allem die Common Object Request Broker Architecture (CORBA) einen sehr abstrakten Ansatz für eine solche objektorientierte Middleware dar. Topo- logisch gesehen ist ein Hub&Spoke-Ansatz, denn eine CORBA besitzt im Kern eben- falls 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 forma- le Spezifikation der jeweiligen Schnittstellen definiert, die die Funktionalitäten für ent- fernte 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 le- diglich eine Erweiterung des zuvor genannten Objektorientierten dar. Hierbei ist aber dennoch der Ansatz der Enterprise Java Beans (EJB) interessant, da er den Schnitt- stellengedanken, auch in Bezug auf verteilte Systeme, noch stärker versucht umzu- setzen. 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 ver- schiedene Klassen von Anwendungsfällen. Sie können entweder „remote“, also über Prozess- und Rechnergrenzen hinweg, oder innerhalb einer VM, also lokal, angespro- chen 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

[...]

Details

Seiten
56
Jahr
2011
ISBN (eBook)
9783656769279
ISBN (Buch)
9783656769286
Dateigröße
991 KB
Sprache
Deutsch
Katalognummer
v275378
Institution / Hochschule
Otto-Friedrich-Universität Bamberg – Lehrstuhl für Informationssysteme in Dienstleistungsbereichen
Note
1,7
Schlagworte
IT-Business-Alignment IT-Architektur SOA serviceorientierte Architektur IT-Strategie

Autor

Teilen

Zurück

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