Analyse und Klassifizierung von Problemsituationen bei der Einführung einer Service-orientierten Architektur (SOA)

Inhaltsverzeichnis

Abkürzungsverzeichnis

Abbildungsverzeichnis

Tabellenverzeichnis

1. Einleitung
1.1 Problemstellung
1.2 Ziel der Arbeit
1.3 Vorgehensweise und Aufbau der Arbeit

2. Theoretische Grundlagen der Service-orientierten Architektur
2.1 Evolution der Service-orientierten Architektur
2.2 Begriffsdefinitionen
2.2.1 Service
2.2.2 Geschäftsprozess
2.2.3 Softwarearchitektur
2.2.4 Unternehmensarchitektur
2.2.5 Service-orientierte Architektur
2.3 Begriffsabgrenzungen
2.3.1 Enterprise Application Integration
2.3.2 Web Service
2.3.3 Event Driven Architecture
2.3.4 Model Driven Architecture
2.4 Gestaltungsprinzipien einer Service-orientierten Architektur
2.4.1 Geschäftsprozessorientierung
2.4.2 Lose Kopplung
2.4.3 Wiederverwendbarkeit
2.4.4 Flexibilität
2.4.5 Technologie- bzw. Plattformunabhängigkeit
2.4.6 Einfachheit
2.4.7 Verborgene Logik
2.4.8 Verwendung offener Standards
2.5 Komponenten einer Service-orientierten Architektur
2.5.1 Application-Frontend
2.5.2 Service
2.5.3 Service-Repository
2.5.4 Service-Bus
2.5.5 Business Process Management System

3. Methoden zur Exploration des Expertenwissens
3.1 Zum Verhältnis qualitativer und quantitativer Forschung
3.2 Formen des Interviews
3.2.1 Abgrenzung des qualitativen vom quantitativen Interview
3.2.2 Das Experteninterview
3.3 Bestimmung der Auswahlmenge
3.3.1 Güte der Auswahlmenge
3.3.2 Identifizierung von Experten
3.4 Datengewinnung
3.5 Transkription
3.6 Qualitative Inhaltsanalyse
3.6.1 Abgrenzung zur quantitativen Inhaltsanalyse
3.6.2 Qualitative Inhaltsanalyse nach Mayring
3.6.3 Zusammenfassende Inhaltsanalyse
3.7 Gütekriterien
3.8 Kritische Würdigung der Forschungsmethode

4. Auswertung und Analyse der Forschungsergebnisse
4.1 Anwendung der Forschungsmethode
4.2 Identifizierung der genannten Problemsituationen
4.3 Klassifizierung der identifizierten Problemsituationen
4.3.1 Unzureichendes Change-Management
4.3.2 Mangelnder Fokus auf globale Zusammenhänge
4.3.3 Personelle Herausforderungen
4.3.4 Mangelnde Transparenz der Wirtschaftlichkeit
4.3.5 Ungeeignetes Service-Design
4.3.6 Limitationen neuer Technologien
4.3.7 Technologieabhängigkeiten
4.3.8 Komplexes Security-Identity-Management
4.3.9 Inkonsistenz der Daten
4.4 Schlussbetrachtungen
4.4.1 Klassifikationsschema
4.4.2 Implikationen zum Einführungsprozess einer Service-orientierten Architektur
4.4.2.1 Strategisches Investment vs. Transparenz des wirtschaftlichen Nutzens
4.4.2.2 SOA-konformes Change-Management
4.4.2.3 SOA-Governance
4.4.3 Vorbereitung einer quantitativen Hypothesenüberprüfung
4.4.4 Ausblick

5. Fazit

Literaturverzeichnis

Anhang
Anhang A: Interpretationsregeln nach Mayring
Anhang B: E-Mail zur Terminvereinbarung eines Telefoninterviews
Anhang C: Interviewleitfaden
Anhang D: Transkriptionen der Interviews
Anhang E: Einzelauswertung der Interviews
Anhang F: Gesamtauswertung der Problemsituationen
Anhang G: Gesamtauswertung der Einschätzung von SOA
Anhang H: Gesamtauswertung des Potenzials von SOA

Erklärung

Lebenslauf

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

Abbildungsverzeichnis

Abb. 2-1: Bestandteile der Unternehmensarchitektur

Abb. 2-2: Bestandteile eines Services

Abb. 2-3: Service-Repository, Serviceanbieter und Servicenehmer

Abb. 4-1: Klassifizierung der Problemsituationen

Abb. 4-2: SOA-Governance-Modell

Abb. 4-3: Beispiel zur Formulierung eines Items

Tabellenverzeichnis

Tab. 2-1: Schwerpunkte in untersuchten SOA-Definitionen

Tab. 2-2: Gestaltungsprinzipien untersuchter Quellen

Tab. 4-1: Hindergrundinformationen zu den Experten

Tab. 4-2: Aufbereitung der Interviews

Tab. 4-3: Identifizierte Problemsituationen

1. Einleitung

Service-orientierte Architekturen (SOA) werden zurzeit in der Fachpresse und von Experten stark diskutiert.^[1] Der Begriff wurde Mitte der neunziger Jahre geprägt,^[2] und beschreibt ein auf Services ausgerichtetes Architekturkonzept.^[3] Von einigen Experten wird SOA als logischer Evolutionsschritt im Kontext der Softwarearchitekturen bezeichnet,^[4] von anderen hingegen als „alter Wein in neuen Schläuchen“^[5]. Konsens besteht jedoch weitgehend darin, dass mit SOA zum ersten Mal ein Softwarearchitekturkonzept diskutiert wird, welches nicht, wie die konventionellen Architekturkonzepte, stark technologieorientiert ist und von den entsprechenden IT-Abteilungen motiviert wird, sondern in stärkerem Maße fachliche Aspekte reflektiert und sich an den Anforderungen der Geschäftsmodelle eines Unternehmens orientiert.^[6]

1.1 Problemstellung

In der Literatur findet sich eine Vielzahl von Beiträgen und Publikationen zum Themengebiet der SOA sowie einige unterschiedliche Definitionen.^[7] Jedoch ist kaum eine umfassende Abhandlung oder Darstellung von potenziellen Problemsituationen bei der Einführung einer SOA erschienen. Problemsituationen vor oder während der Einführung einer SOA, die spät oder gar nicht identifiziert werden, können negative Folgeerscheinungen verursachen.^[8] Diese unerwünschten Folgen können Zeitverzögerungen und erhöhte Ausgaben sein, welche die Einhaltung des Projektplans und der Budgetierung und somit auch den erfolgreichen Abschluss einer SOA-Einführung gefährden. Daher ist es wünschenswert, potenzielle Problemsituationen möglichst frühzeitig identifizieren zu können, um diese bestenfalls zu vermeiden oder rechtzeitig geeignete Maßnahmen zu ergreifen.

Eine Analyse und Klassifizierung von potenziellen Problemsituationen bei der Einführung einer SOA kann helfen, die oben genannten negativen Folgen zu vermeiden und somit den erfolgreichen Abschluss einer SOA-Einführung sicherzustellen.

Wie eingangs erwähnt, sind bisher kaum umfassende Abhandlungen zu Problemsituationen bei der Einführung einer SOA in der Literatur dargestellt worden; vereinzelt werden jedoch einige Aspekte aufgegriffen. So setzt sich Barry vornehmlich mit Herausforderungen im Bereich Change-Management auseinander.^[9] Marks und Bell geben Handlungsempfehlungen zu Serviceidentifizierung, -analyse und -design und greifen in diesem Zusammenhang die Problematik der Festlegung einer geeigneten Granularität^[10] der Services auf.^[11] Krafzig, Banke und Slama geben einen kurzen Überblick über die Herausforderungen der einzelnen Rollen in einem Unternehmen.^[12] Kurz vor Fertigstellung dieser Arbeit erschien ein Artikel von Durst und Daum über Erfolgsfaktoren von SOA in der Fachzeitschrift „HMD – Praxis der Wirtschaftsinformatik“.^[13] Die in diesem Artikel dargestellten Erfolgsfaktoren korrespondieren zum Teil mit den Problemsituationen, die im Rahmen der Studie zu dieser Arbeit identifiziert wurden. In erster Linie wird dadurch das Interesse an der Forschungsfrage bestätigt, da in der Fachwelt ein Bedarf zur Identifizierung und Klassifizierung von Problemsituation bzw. zur Nennung geeigneter Erfolgsfaktoren bei der Einführung einer SOA besteht.

1.2 Ziel der Arbeit

Das Ziel der Arbeit ist die Analyse und Klassifizierung potenzieller Problemsituationen bei der Einführung einer SOA. Zur Erreichung des Hauptziels werden im Verlauf dieser Arbeit Teilziele erarbeitet.

Ein Teilziel ist die Aufbereitung einer geeigneten Forschungsmethode zur Exploration des Expertenwissens. Mithilfe dieser Forschungsmethode sollen Problemsituationen identifiziert werden, die im Rahmen der anschließenden Diskussion analysiert und klassifizieret werden. Resultierend aus den klassifizierten Problemsituationen sollen Implikationen zum Einführungsprozess einer SOA abgeleitet werden. Darüber hinaus sollen vorbereitende Überlegungen zur Durchführung einer quantitativen Hypothesenüberprüfung der Ergebnisse getroffen werden.

1.3 Vorgehensweise und Aufbau der Arbeit

Die vorliegende Arbeit ist in fünf Kapitel untergliedert. In diesem Kapitel werden die Motivation, die Problemstellung sowie Zielsetzung und Vorgehensweise erläutert. Die theoretischen Grundlagen zum Themengebiet der SOA werden in Kapitel 2 vorgestellt und erarbeitet. In der Literatur findet sich eine Vielzahl von Definitionen, die hier teilweise vergleichend gegenübergestellt werden, um schließlich eine für diese Arbeit gültige Definition anzubieten, die somit als gemeinsame Verständnisgrundlage dient.

Zudem erfolgt eine Begriffsabgrenzung gegenüber verwandten Begriffen wie Enterprise Application Integration, Web Services, Event Driven Architecture und Model Driven Architecture. Darüber hinaus werden die grundlegenden Gestaltungsprinzipien und Komponenten einer SOA beschrieben.

In Kapitel 3 werden Methoden der Datenerhebung und Auswertungstechniken zur Exploration von Expertenwissen vorgestellt, um eine für den Forschungsanspruch dieser Arbeit geeignete Methode abzuleiten. Die Anwendung der Methode dient der Exploration des Expertenwissens zur Identifizierung von Problemsituationen.

Kapitel 4 setzt sich mit der Auswertung und Analyse der Expertenaussagen anhand der schriftlich protokollierten Interviews auseinander. Dazu werden die identifizierten Problemsituationen erläutert und diskutiert, um diese in ein Klassifikationsschema einordnen zu können. Soweit möglich werden die von den Experten genannten Problemsituationen mit Literatur belegt. Darauf aufbauend werden Implikationen zum Einführungsprozess einer SOA abgeleitet und vorbereitende Überlegungen für eine quantitative Hypothesenüberprüfung getroffen. Das Kapitel schließt mit einem Ausblick zum Potenzial von SOA als nachhaltiges Architekturkonzept.

Im abschließenden Kapitel 5 – dem Fazit – werden die Ergebnisse und die Zielerreichung anhand der Zielsetzung reflektiert.

2. Theoretische Grundlagen der Service-orientierten Architektur

In diesem Kapitel werden die zentralen Begriffe der SOA erläutert und wesentliche Aspekte dieses Architekturkonzepts diskutiert.

Zunächst wird in Kapitel 2.1 die Evolution der SOA kurz dargestellt. In Kapitel 2.2 erfolgt die Definition der Grundbegriffe, die im direkten Zusammenhang mit SOA stehen. Die Abgrenzung der SOA zu anderen Architekturkonzepten wird in Kapitel 2.3 vorgenommen. Kapitel 2.4 beschäftigt sich mit den Gestaltungsprinzipien und in Kapitel 2.5 werden die Basiskomponenten der SOA vorgestellt.

2.1 Evolution der Service-orientierten Architektur

Historisch betrachtet sind seit Beginn der elektronischen Datenverarbeitung Innovationszyklen zu beobachten.^[14],^[15] Angefangen bei der Assemblerprogrammierung, vollzog sich aufgrund gestiegener Anforderungen und damit einhergehender Komplexität, die mit der Assemblerprogrammierung nur schwierig zu beherrschen ist, ein Innovationssprung zu den prozeduralen Programmiersprachen. Auch diese stießen aufgrund der weiter gestiegenen Komplexität bald an ihre Grenzen, so dass das objektorientierte Programmierparadigma in vielen Bereichen Verbreitung fand. Dostal u. a. sehen die Evolutionszyklen der Programmierparadigmen nicht als grundlegend neue Konzepte an, sondern vielmehr als eine weitere „Abstraktionsstufe […], um immer komplexere Szenarien beherrschen zu können.“^[16] So wie die Objektorientierung die prozedurale Programmierung abstrahiert und diese wiederum die Assemblerprogrammierung, stellt nun im vorerst letzten Schritt die SOA ein höheres Abstraktionsniveau gegenüber der Objektorientierung dar.

Krafzig, Banke und Slama begründen die Evolution der SOA durch den Versuch, die Agilität und Effizienz im Unternehmen zu steigern, indem die heterogenen Systemlandschaften durch unternehmensweite Standards homogenisiert werden.^[17] Sie greifen dabei zwei Standardisierungsbemühungen heraus.

Zum einen kamen in den frühen achtziger Jahren die relationalen Datenbankkonzepte auf.^[18] Mit ihnen zog eine Welle der so genannten Enterprise Data Model (EDM)-Projekte einher, mit der Hoffnung, ein unternehmensweites Datenmodell für alle Unternehmensbereiche beschreiben zu können. Die Projekte scheiterten meistens aus machtpolitischen Gründen zwischen verschiedenen Abteilungen, die ihre eigenen Interessen durchsetzen wollten, oder aufgrund der technischen Komplexität des Projektvorhabens. So sind heutzutage in den Unternehmen unterschiedliche Datenbanksysteme mit teilweise redundanter Datenhaltung vorzufinden.

Zum anderen wurde in den neunziger Jahren ein weiterer Versuch unternommen, die heterogene Anwendungslandschaft in den Unternehmen zu homogenisieren. Diesmal sollten unternehmensweite Middleware^[19] -Standards den Erfolg versprechen. In diesem Zusammenhang erreichte der Enterprise Software-Bus seine Popularität. Die Hoffnung bestand darin, durch den Einsatz eines technologieunabhängigen, unternehmensweiten Kommunikationsstandards für Softwaremodule das Problem der Anwendungsintegration endgültig gelöst zu haben. Jedoch scheiterte auch dieser Versuch mit dem Resultat, nicht nur weiterhin eine heterogene Anwendungslandschaft, sondern nun auch eine heterogene Middlewareschicht zu haben, da häufig nur lokale Point-to-Point^[20] -Integrationen vorgenommen wurden, ohne einen globalen Software-Bus einzuführen.

Letztendlich führten beide Ansätze zur Homogenisierung der Systemlandschaften nicht zum erhofften Erfolg. Hinzu kommt, dass sich in den letzten Jahren die Rahmenbedingungen des IT-Managements im Unternehmen geändert haben, so dass Anforderungen der Kunden und dynamische Änderungen des Unternehmensumfelds eine höhere Flexibilität sowie eine Reduzierung von Time-to-Market^[21] verlangen.^[22] Diese Markt- und Kundenorientierung zwingen das IT-Management, neue Integrationskonzepte zu entwerfen, Prozesse zu überdenken und neue Strukturen zu etablieren. Serviceorientierung ist das geforderte Paradigma, mit dem zum einen ein Integrationsansatz zur Homogenisierung der Systemlandschaft zur Verfügung stehen soll und zum anderen flexibler auf Marktveränderungen reagiert werden kann.

2.2 Begriffsdefinitionen

Der zentrale Begriff dieser Arbeit setzt sich aus drei Teilen zusammen: Service^[23], Orientierung und Architektur. Zunächst wird ein gemeinsames Verständnis dieser Begriffe geschaffen, um als Grundlage für eine Annäherung an den zusammengesetzten Begriff der SOA zu dienen. Dabei ist zunächst festzuhalten, dass der Begriff Orientierung in zweierlei Hinsicht zu verstehen ist. Zum einen als Umschreibung einer Architektur, die sich in hohem Maße an Services orientiert, und zum anderen als Implikation dieser Serviceorientierung die mit dieser Architektur zu erzielende Geschäftsprozessorientierung.

2.2.1 Service

Im Mittelpunkt einer SOA stehen Services.^[24] Services sind aufrufbare, in sich abgeschlossene Einheiten bzw. Module mit bestimmter Funktionalität, die über den Austausch bestimmter Nachrichten von einem Servicenehmer^[25] in Anspruch genommen werden können.^[26] Um diesen Austausch zu ermöglichen, verfügen diese Services über wohldefinierte Schnittstellen. Die Schnittstelle enthält eine Beschreibung des Services, definiert den Zugang sowie die Struktur des Aufrufs und der Antwort. In Kapitel 2.5.2 wird eine umfassendere und detaillierte Beschreibung vorgenommen, die den Service als Komponente des SOA-Basismodells spezifiziert.

2.2.2 Geschäftsprozess

Bevor der Begriff Geschäftsprozess (engl. business process) definiert wird, erfolgt zunächst die Definition des Prozessbegriffs im Allgemeinen. „Ein Prozess ist die Erzeugung, Veränderung, kurz Überführung eines Objektes […] durch Aktivitäten von Menschen oder Maschinen in Raum und Zeit mit einem vorgegebenen Ziel.“^[27] Übertragen auf Organisationen und Unternehmen wird unter einem Geschäftsprozess^[28] eine „Folge logisch zusammenhängender Aktivitäten zur Erstellung einer Leistung oder Veränderung eines Objektes [verstanden]. Das Ziel des betriebswirtschaftlichen Geschäftsprozesses ist Wertsteigerung und Wertschöpfung.“^[29] Geschäftsprozesse verfolgen demnach ein klar definiertes unternehmerisches Ziel. Die einzelnen Aktivitäten können sowohl sequenziell als auch parallel angeordnet sein.^[30]

2.2.3 Softwarearchitektur

Die in dem Begriff Softwarearchitektur enthaltenen Komponenten werden wie folgt definiert:

„Software ist der Sammelbegriff für (Computer-)Programme^[31] im Allgemeinen. Man unterscheidet Systemsoftware, Entwicklungssoftware und Anwendungssoftware.“^[32]

„Eine Architektur beschreibt die logische und physikalische Anordnung der Bausteine eines komplexen Systems, sowie die Beziehung zwischen diesen Bausteinen.“^[33] Somit beschreibt eine Architektur nicht nur eine statische Struktur, sondern auch die Beziehungen zwischen den strukturgebenden Komponenten.^[34]

Die Literatur bietet unterschiedliche Definitionen einer Softwarearchitektur.^[35] Um ein gemeinsames Verständnis zu schaffen, werden drei Definitionen vorgestellt, um aus den Gemeinsamkeiten eine resultierende Definition abzuleiten.

(1) Bass, Clements und Kazman definieren eine Softwarearchitektur folgendermaßen: Die Softwarearchitektur eines Programms oder Softwaresystems ist die Struktur des Systems, welche die Softwarekomponenten, das nach außen sichtbare Verhalten (Eigenschaften) dieser Komponenten und ihre Beziehungen zueinander beinhaltet.^[36]
(2) Krafzig, Banke und Slama verstehen unter einer Softwarearchitektur eine Zusammenstellung von Angaben (engl. statements), die Softwarekomponenten beschreiben und die Funktionalität des Systems diesen Komponenten zuweist. Dabei beschreibt diese die technische Struktur, Randbedingungen und Eigenschaften der Komponenten sowie die Infrastruktur zwischen diesen. Die Architektur ist ein Entwurf (engl. blueprint) für das System und impliziert daher einen Plan zur Erstellung auf höherem Abstraktionsniveau.^[37]
(3) Hansen und Neumann liefern folgende Definition: „Die Softwarearchitektur beschreibt die Struktur und die Interaktionsbeziehungen zwischen den verschiedenen Hauptkomponenten^[38] eines Systems auf einem relativ grobgranularen Niveau.“^[39]

In allen Definitionen wird die Sichtweise hervorgehoben, dass Softwarearchitekturen aus Komponenten bestehen, die in einer Beziehung zueinander stehen und interagieren. Bass, Clements und Kazman beschreiben, dass die Komponenten ein bestimmtes, auch nach außen sichtbares Verhalten aufweisen. Nach der Auffassung von Hansen und Neumann beschreibt die Softwarearchitektur das System auf einem grobgranularen Niveau. Diese Sichtweise ist konform mit der von Krafzig, Banke und Slama zum Ausdruck gebrachten Implikation, dass aus der Architektur ein Konstruktionsplan auf einem höheren Abstraktionsniveau abgeleitet werden kann.

Aus diesen Überlegungen resultierend wird eine für diese Arbeit geltende Definition abgeleitet, welche die wesentlichen Aspekte reflektiert.

Eine Softwarearchitektur beschreibt die Struktur eines Systems, welches aus Softwarekomponenten besteht, die in Beziehung zueinander stehen. Jeder Softwarekomponente wird dabei eine konkrete Funktionalität zugewiesen, und sie ist durch ihr nach außen sichtbares Verhalten charakterisiert. Eine Softwarearchitektur hat zudem Entwurfscharakter und beschreibt die Strukturen auf einem höheren Abstraktionsniveau.

2.2.4 Unternehmensarchitektur

„Unter einer Unternehmensarchitektur wird erweiternd das Zusammenwirken organisatorischer, technischer und psychosozialer Aspekte bei der Planung und Entwicklung betrieblicher soziotechnischer Informationssysteme verstanden.“^[40] Die Unternehmensarchitektur berücksichtigt dabei sowohl die organisatorische als auch die technische Dimension. Die Beziehungen dieser beiden Dimensionen zur Unternehmensarchitektur sind in Abb. 2-1 dargestellt.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 2-1: Bestandteile der Unternehmensarchitektur^[41]

Die Organisationsarchitektur reflektiert die nichttechnischen Komponenten einer Unternehmensarchitektur.^[42] Entsprechend zum instrumentellen Organisationsbegriff, der zwischen Aufbau- und Ablauforganisation unterscheidet, wird hier zwischen Organisationsstruktur und Geschäftsprozessen unterschieden. Die IT-Architektur hingegen beinhaltet alle technischen Komponenten. Aier und Dogan betrachten in diesem Zusammenhang die technischen Informationssysteme mit ihrer eigenen Informationssystemarchitektur und sehen diese als Teil der IT-Architektur. Sie weisen aber auch darauf hin, dass die Begriffe in der Literatur häufig unterschiedlich in Abhängigkeit der fachlichen Herkunft des Autors definiert werden.^[43] In diesem Zusammenhang soll hier unter IT-Architektur die Systemarchitektur und unter Informationssystemarchitektur die Softwarearchitektur ergänzt um die soziotechnische Komponente verstanden werden.^[44]

2.2.5 Service-orientierte Architektur

In der zweiten Hälfte der neunziger Jahre wurde der Begriff SOA geprägt.^[45] In der Literatur werden unterschiedliche Definitionen des Begriffes vorgestellt, die je nach Sichtweise des Autors verschiedene Aspekte beleuchten, so dass entweder eher die technischen Ausprägungen oder der integrative Ansatz mit der fachlichen Orientierung in den Vordergrund treten.^[46]

Zunächst werden einige Definitionen aus der Literatur vorgestellt, um diese anschließend zu diskutieren und Gemeinsamkeiten hervorzuheben. Anhand der Diskussion wird eine für diese Arbeit geltende Definition abgeleitet.

(1) Dostal, Jeckle, Melzer und Zengler definieren eine SOA wie folgt: „Unter einer SOA versteht man eine Systemarchitektur, die vielfältige, verschiedene und eventuell inkompatible Methoden oder Applikationen als wiederverwendbare und offen zugreifbare Dienste repräsentiert und dadurch eine plattform- und sprachenunabhängige Nutzung und Wiederverwendung ermöglicht.“^[47]
(2) Erl versteht unter einer SOA: „An SOA is a design model with a deeply rooted concept of encapsulating application logic within services that interact via a common protocol.”^[48]
(3) Krafzig, Banke und Slama liefern folgende Definition einer SOA: „A Service-Oriented Architecture is a software architecture that is based on the key concepts of an application frontend, service, service repository and service bus. A service consists of a contract, one or more interfaces and an implementation.”^[49]
(4) Marks und Bell vertreten folgende Sichtweise einer SOA: „SOA is a conceptual business architecture where business functionality, or application logic, is made available to SOA users, or consumers, as shared, reusable services on an IT network. ‚Services’ in an SOA are modules of business or application functionality with exposed interfaces that are invoked by messages from service consumers”^[50]
(5) Newcomer und Lomow definieren eine SOA wie folgt: „A service-oriented architecture is a style of design that guides all aspects of creating and using business services throughout their lifecycle (from conception to retirement). An SOA is also a way to define and provision an IT infrastructure to allow different applications to exchange data and participate in business processes, regardless of the operating systems or programming languages underlying those applications“^[51]
(6) Die Standardisierungsinstitution OASIS definiert SOA folgendermaßen: „Service Oriented Architecture is a paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains. It provides a uniform means to offer, discover, interact with and use capabilities to produce desired effects consistent with measurable preconditions and expectations.”^[52]

Die oben genannten Definitionen setzen zum Teil unterschiedliche Schwerpunkte. Tab. 2-1 gibt einen Überblick der von den einzelnen Autoren gesetzten Schwerpunkte. Konsens besteht darin, dass eine SOA um Services als fundamentales Gerüst zentriert ist. Zudem wird SOA von den meisten Autoren (Dostal, Krafzig, Marks, Newcomer) als Software- bzw. Systemarchitektur betrachtet. Erl sieht in der SOA ein Designmodell. Marks bestätigt diese Sichtweise und spricht in diesem Zusammenhang von einer „conceptual business architecture“. Dostal und Marks heben die Wiederverwendbarkeit der Services hervor. Die Plattformunabhängigkeit wird von Newcomer und Dostal gefordert. Zudem wird die Interaktion und Kommunikation über Schnittstellen von den meisten Autoren (Erl, Krafzig, Marks, Newcomer) als zentrales Merkmal einer SOA gesehen, die mithilfe einer gemeinsamen Kommunikationsinfrastruktur (Erl, Krafzig, Marks) realisiert werden sollen. Erl und Marks legen ihren Fokus auf die in den Services gekapselte Anwendungs- und Geschäftslogik und drücken damit implizit die dadurch fachlich geprägte Geschäftsprozessorientierung aus. In diesem Zusammenhang hebt Newcomer die Partizipation der Applikationen an den Geschäftsprozessen hervor. Die Sichtweise, dass SOA sowohl als fachlich getriebener Ansatz als auch als technologieorientiertes Konzept gesehen wird, wurde – in Vorwegnahme der Auswertung der Studie in Kapitel 4 – von den an dieser Studie teilnehmenden Experten bestätigt.^[53] Die Verantwortung und die treibende Kraft liegen nach ihrer Meinung auf der fachlichen Seite. Die Technik nimmt in diesem Zusammenhang eine unterstützende Rolle ein.^[54]

Die in den Definitionen genannten Schwerpunkte implizieren zum Teil Gestaltungsprinzipien einer SOA, die in Kapitel 2.3 in detaillierter Form diskutiert werden.

Abbildung in dieser Leseprobe nicht enthalten

Tab. 2-1: Schwerpunkte in untersuchten SOA-Definitionen

Resultierend aus dieser Gegenüberstellung wird eine Definition abgeleitet, welche die zentralen Schwerpunkte der genannten Definitionen reflektiert und im weiteren Verlauf dieser Arbeit als Grundlage dient.

Eine SOA ist eine Softwarearchitektur mit fachlicher Orientierung. Dabei ist die Geschäftslogik in wiederverwendbaren, verteilten und lose gekoppelten Services gekapselt. Die in einem Service implementierte Funktionalität wird über ihre Schnittstelle plattformunabhängig auf einer gemeinsamen Kommunikationsinfrastruktur bereitgestellt.

2.3 Begriffsabgrenzungen

In der Literatur werden einige Begriffe, die dem Themenkreis der Softwarearchitekturen angehören, genannt und dargestellt. Häufig ist eine klare Abgrenzung zum Begriff der SOA nicht auf den ersten Blick ersichtlich. So wird bspw. in einigen Abhandlungen in der Literatur der Eindruck erweckt, dass Web Services mit SOA gleichzusetzen sind. In diesem Abschnitt soll daher der Begriff der SOA von anderen Architekturkonzepten abgegrenzt werden. Darüber hinaus stellt SOA nicht nur ein Architekturkonzept dar, sondern kann zudem auch als Integrationsansatz betrachtet werden.^[55] Daher wird zunächst die Abgrenzung zwischen SOA und Enterprise Application Integration (EAI) vorgenommen.

2.3.1 Enterprise Application Integration

Unter dem Begriff Enterprise Application Integration „werden Ansätze zur Schaffung einer einheitlichen Anwendungsarchitektur unter Einbezug von heterogenen Systemen“^[56] verstanden. Linthicum konkretisiert diesen Ansatz und betrachtet EAI als Reaktion auf die über Jahrzehnte gewachsenen monolithischen und autonomen Applikationen, die jeweils meist nur einen konkreten Zweck für eine überschaubare Anzahl von Endbenutzern erfüllen, aber in ihrer Gesamtheit eine heterogene Mischung unterschiedlicher Plattformen und Entwicklungsansätze darstellen.^[57] EAI fordert die uneingeschränkte, gemeinsame Nutzung und Integration von Daten und Geschäftsfunktionen zwischen sämtlichen miteinander verbundenen Anwendungen und Datenquellen eines Unternehmens. Über Jahrzehnte wurden Systeme entwickelt, ohne eine hinreichende, ganzheitliche Strategie zu haben, diese Systeme in die unternehmensweite Anwendungslandschaft zu integrieren. Hier setzt EAI an und erhebt den Anspruch, die heterogenen Anwendungslandschaften auflösen zu können.

Beim Vergleich der Zielvorgabe des EAI-Ansatzes mit dem Anspruch einer SOA stellt sich die Frage, wo die Unterschiede zwischen diesen beiden Ansätzen liegen. Tatsächlich werden häufig SOA und Anwendungsintegration synonym verwendet.^[58] Jedoch wird bei genauerer Betrachtung der beiden Definitionen und Anhebung auf ein höheres Abstraktionsniveau deutlich, dass beide Konzepte unterschiedliche Schwerpunkte setzen.^[59]

Bei SOA werden die Anwendungsfunktionalitäten als Services integriert.^[60] Der EAI-Ansatz verfolgt das Ziel einer direkten Application-to-Application^[61] -Verbindung mittels komplexer Middlewarelogik. Hingegen ist bei SOA die Middleware weniger stark ausgeprägt, da diese hier lediglich die Funktion zur Vermittlung zwischen einem Servicenehmer und einem passenden Servicegeber^[62] einnimmt. Die Kommunikation und der Datentransfer werden nach Herstellung der Verbindung ohne Zuhilfenahme einer Middlewareschicht direkt zwischen Servicenehmer und -geber realisiert.

Zudem ist bei EAI-Systemen die höchste Stufe der Integration – die Prozessintegration, die ein wesentliches Gestaltungsprinzip einer SOA darstellt – bisher nur schwierig zu realisieren.^[63] Bei etwas unschärferer Betrachtung kann allerdings jede Anwendungsintegration mit SOA realisiert werden, so dass SOA das umfassendere Konzept gegenüber EAI darstellt und verschiedentlich als Evolutionsschritt von EAI angesehen wird.^[64] Gallas wiederum betrachtet „Web Services^[65] als Basis für ein EAI-Framework“^[66], da sich diese sowohl für B2B-Integration^[67] als auch für unternehmensinterne EAI anbietet.“^[68]

2.3.2 Web Service

Wenn SOA als abstraktes Modell verstanden werden kann, so stellen Web Services eine mögliche Umsetzung des SOA-Konzepts dar.^[69]

(1) Das W3C-Konsortium schlägt folgende Definition eines Web Services vor: „A Web service is a software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machine-processable format (specifically WSDL^[70] ). Other systems interact with the Web service in a manner prescribed by its description using SOAP^[71] -messages, typically conveyed using http^[72] with an XML^[73] serialization in conjunction with other Web-related standards.”^[74]
(2) Eine etwas kürzere Definition wird von Woods und Mattern angeboten: „Web services are self-contained and self-describing application functionalities that can be processed through open Internet standards.”^[75]

Bei beiden Definitionen wird der wesentliche Aspekt eines Web Services hervorgehoben, dass die Kommunikation und Interaktion auf offenen Internetprotokollen und -standards basieren. Die grundlegenden Basiskonzepte, die dazu benötigt werden, sind die Schnittstellen, die mithilfe des WSDL-Standards beschrieben werden, der Datenaustausch, der mit SOAP realisiert wird, und das Service-Repository, das dem UDDI^[76] -Standard folgt.^[77]

Im Vergleich zur Definition einer SOA werden also konkrete Technologiestandards vorgegeben, die sich weitgehend an Internetprotokollen orientieren. Dennoch sind die Analogien zwischen SOA und Web Services erkennbar, die in erster Linie im strukturellen Aufbau ersichtlich werden.

Ausgehend von diesen Vorüberlegungen und Definitionen zeichnen sich Web Services durch folgende Merkmale aus:^[78]

- Kommunikation mit Web Services basiert auf Nachrichtenaustausch.
- Web Services stellen Metadaten zur Verfügung, um die Struktur der ausgetauschten Nachrichten zu beschreiben.
- Web Services sind unabhängige, in sich abgeschlossene, gekapselte Anwendungen, die eine genau definierte Aufgabe erfüllen.
- Web Services können sowohl von menschlichen Benutzern, von Web-Anwendungen und anderen Web Services genutzt werden.
- Die Standards WSDL, SOAP und UDDI bilden das Fundament der Web Service-Architektur.

Im Wesentlichen werden Web Services eingesetzt, um ein Kommunikationsframework zu errichten, und stellen somit eine webbasierte Implementierung einer SOA dar.^[79]

2.3.3 Event Driven Architecture

Event Driven Architecture (EDA) stellt ein weiteres Architekturkonzept dar, das häufig in Verbindung mit SOA gebracht wird.^[80] Obwohl EDA sich fundamental von SOA unterscheidet, schließen sich beide nicht aus, sondern können sich wechselseitig ergänzen. SOA basiert auf einer Nehmer-Geberbeziehung, d. h. ein Servicenehmer nimmt eine konkrete Funktionalität eines bestimmten Services in Anspruch. Bei einer EDA ist ein solcher Servicenehmer nicht explizit vorhanden. Stattdessen reagiert ein nach EDA konzipiertes System auf ein bestimmtes Ereignis innerhalb des Systems oder auch aus dem Umfeld des Systems mit einer entsprechenden Antwort.^[81] Die Antwort auf ein Ereignis muss nicht zwangsläufig das Ausführen einer Softwarekomponente sein, sondern kann eine Aktionskette oder weitere Ereignisse auslösen, eine Alarmmeldung herbeiführen oder Aufgaben an bestimmte Mitarbeiter delegieren.^[82]

Der wesentliche Unterschied zwischen SOA und EDA liegt folglich in der Art und Weise, wie eine konkrete Funktionalität ausgelöst wird. Bei EDA ist es das mehr oder minder willkürliche Auftreten eines Ereignisses. Hingegen ist es bei SOA die gezielte Anfrage eines Servicekonsumenten für einen konkreten Service. Letztendlich kann aber eine SOA um eine Ereignisbehandlung ergänzt werden, so dass auch hier auf Ereignisse reagiert werden kann. EDA kann also eine sinnvolle Ergänzung einer SOA darstellen.

2.3.4 Model Driven Architecture

Das Konzept der Model Driven Architecture (MDA) stellt einen methodischen Ansatz zur Entwicklung von Software dar, in der die Spezifikation der Software unabhängig von ihrer technischen Umsetzung beschrieben wird, und sich somit auf einem höheren Abstraktionsniveau befindet.^[83]

MDA umfasst mehrere Spezifikationen und Methoden, die von der Object Management Group (OMG) standardisiert werden.^[84] Dabei werden Standards zur Spezifikationen von plattformunabhängigen Modellen (engl. Platform Independent Model) und plattformspezifischen Modellen (engl. Platform Specific Model) unterschieden:

- PIM (Platform Independent Model): Modellierung der Strukturen und der Funktionalität ohne Implementierungsdetails auf hohem Abstraktionsniveau
- PSM (Platform Specific Model): Erweiterung des PIM durch Anreicherung von plattformspezifischen Details zur Unterstützung einer konkreten Implementierung von Softwarekomponenten

Der MDA-Ansatz zur Softwareentwicklung vollzieht dabei eine Annäherung von einer höher gelegenen abstrahierenden zu einer implementierungsnahen Modellierung.^[85] Durch die Beschreibung von Modellen auf einer höheren Abstraktionsebene wird eine klare Trennung von fachlichen und technischen Aspekten erzielt. Diese abstraktere, technologieunabhängige Beschreibung mit eindeutigen Modellierungssprachen – bspw. UML^[86] – bewirkt eine verbesserte Handhabung des Technologiewandels und fördert eine bessere Wartbarkeit durch Trennung der Verantwortlichkeiten.

Folgende Ziele werden mit dem MDA-Ansatz verfolgt:^[87]

- Konservierung der Fachlichkeit: In den Unternehmen ist das Wissen über die Geschäftsprozesse häufig nur implizit vorhanden. Durch Modellierung der zugrunde liegenden Prozesse soll dieses Wissen expliziert werden.

- Portierbarkeit: Durch Abstraktion von konkreten Technologien wird ein späterer Releasezyklus oder Wechsel auf komplett neue Zielplattformen erleichtert.

- Systemintegration und Interoperabilität: Verwendung von offenen Standards verringert Herstellerabhängigkeiten und erleichtert die Entwicklung von Schnittstellen.

- Effiziente Softwareentwicklung: Aufgrund der Werkzeugunterstützung und der damit verbundenen Automatisierung der Anwendungsentwicklung wird eine Effizienzsteigerung erzielt.

- Domänen-Orientierung: Durch Modellierung werden technische Aspekte abstrahiert, so dass der Fokus auf das fachliche Domänenwissen gelegt werden kann.

Der Architekturbegriff ist hier jedoch weniger im engeren Sinne einer Softwarearchitektur zu verstehen, sondern ist weiter gefasst und zielt vielmehr auf die erforderliche Infrastruktur zur Umsetzung des MDA-Ansatzes ab. Dabei umfasst er sowohl den unterliegenden Softwareentwicklungsprozess als auch die unterstützenden Werkzeuge.^[88] Hier liegt der wesentliche Unterschied zum SOA-Ansatz. SOA bietet in erster Linie keine Infrastruktur zur Softwareentwicklung, sondern stellt ein Architekturkonzept mit integrativem Charakter und strategischem Potenzial dar. Zudem vollzieht der MDA-Ansatz einen Lebenszyklus mit abnehmendem Abstraktionsniveau. Hierdurch reflektiert MDA vielmehr ein Phasenmodell als ein Architekturkonzept. Jedoch kann MDA mit diesem Ansatz der Modelltransformation – von der abstrakteren zur konkreteren Modellierung – in Kombination mit SOA dazu beitragen, zunächst fachliche, plattformunabhängige Services zu definieren und mit der daran anschließenden Modelltransformation, welche technologische Aspekte berücksichtigt, diese fachlichen Services technisch umzusetzen.^[89]

2.4 Gestaltungsprinzipien einer Service-orientierten Architektur

Die in Kapitel 2.2 vorgestellten Definitionen haben bereits einige Gestaltungsprinzipien impliziert. In der Literatur werden weitere Gestaltungsprinzipien genannt und diskutiert. Unterschiedliche Autoren stellen dabei verschiedene Prinzipien in den Vordergrund, die wiederum zum Teil auf unterschiedlichem Abstraktionsniveau und Detaillierungsgrad diskutiert werden. Dies führt dazu, dass es teilweise zu Überschneidungen kommt, weil Begriffe nicht trennscharf verwendet werden. In diesem Kapitel werden die zentralen Gestaltungsprinzipien vorgestellt. Tab. 2-2 gibt einen Überblick der von einigen ausgewählten Autoren genannten Gestaltungsprinzipien.

Abbildung in dieser Leseprobe nicht enthalten

Tab. 2-2: Gestaltungsprinzipien untersuchter Quellen

2.4.1 Geschäftsprozessorientierung

In stärkerem Maße als andere Softwarearchitekturkonzepte zielt SOA auf eine starke fachliche Ausprägung der Komponenten und die damit einhergehende Orientierung an den Geschäftsprozessen eines Unternehmens ab.^[90] Geschäftsprozesse werden dabei durch Kombination von Services abgebildet, die im Kontext einer SOA bereitgestellt werden. In jedem Service ist eine konkrete, fachliche Funktionalität gekapselt, die über eine Schnittstelle potenziellen Servicenehmern verfügbar gemacht wird.

Die Forderung der Geschäftsprozessorientierung ist grundlegend für die Gestaltung einer SOA und setzt ein umfassendes Verständnis der organisatorischen Prozesse voraus.^[91]

2.4.2 Lose Kopplung

Die Forderung nach der losen Kopplung der Services ist ein weiteres wichtiges Gestaltungsmerkmal einer SOA.^[92] Die Kopplungsintensität reflektiert den Grad der Abhängigkeit zwischen zwei Objekten.^[93] Lose Kopplung bedeutet folglich, dass keine Abhängigkeiten zwischen kommunizierenden SOA-Artefakten^[94] bestehen. Das bedeutet, dass ein Servicenehmer keine Informationen über die innere Struktur, den Speicherort, die Implementierungsdetails oder die Systemplattform des Servicegebers benötigt.^[95] Die Services werden von anderen Services oder auch Applikationen mithilfe des Service-Repository^[96] identifiziert und dynamisch eingebunden. Die Einbindung findet zur Laufzeit statt und wird wieder gelöst, sobald die Applikation beendet ist oder der Service nicht mehr benötigt wird.^[97] Die Funktionalität und die innere Struktur eines Services können somit geändert werden, ohne dass aufrufende Services davon betroffen sind. Für einen aufrufenden Service ist nur die Schnittstellenbeschreibung als Teil des Service-Contracts^[98] der potenziellen Serviceanbieter relevant, um aus diesen den passenden Service mit der geforderten Funktionalität zu identifizieren.

2.4.3 Wiederverwendbarkeit

Der Nutzen der SOA liegt vor allem in der Wiederverwendbarkeit einzelner bereits existierender Services.^[99] Diese müssen nicht neu implementiert werden, wenn an anderer Stelle im Unternehmen auf gleiche Funktionalität, die in einem Service gekapselt ist, zurückgegriffen werden kann. Neben der Reduktion von komplexen, kaum zu kontrollierenden Redundanzen liegt der Vorteil in der Verschlankung des Codes. Es können in der Praxis bewährte und hinreichend getestete Softwarekomponenten wiederverwendet werden. Zudem werden Entwicklungskosten für neue Softwarekomponenten und Wartungskosten für redundante Services gespart.

Wiederverwendbarkeit setzt voraus, dass Services von konkreten Systemplattformen und von den Geschäftsprozessen, in denen diese eingebunden sind, entkoppelt sind.^[100] Dazu ist abstrahierende Konzeption der Services erforderlich. Zudem müssen Services über eine adäquate Servicebeschreibung verfügen, die eine Wiederverwendung erst ermöglicht.

2.4.4 Flexibilität

Unternehmen befinden sich in einer sich ständig verändernden Umgebung.^[101] Märkte zeichnen sich durch eine hohe Dynamik aus, gesetzliche Rahmenbedingungen ändern sich fortlaufend, neue Wettbewerber treten in Märkte ein, bereits bestehende Konkurrenten entwickeln neue Strategien, neue Technologiestandards kommen auf und setzen sich durch. Unternehmen müssen sich kontinuierlich auf diese wechselnden Anforderungen und Umwelteinflüsse einstellen, um wettbewerbsfähig zu bleiben. Dies setzt eine hohe Flexibilität in den organisatorischen Strukturen des Unternehmens voraus, die sich letztlich auch in der Softwarearchitektur wiederfinden muss.^[102] Unter Flexibilität wird im Allgemeinen die Fähigkeit verstanden, mit möglichst geringem Aufwand auf Veränderungen der Anforderungen oder des Umfeldes reagieren zu können.^[103] SOA soll dieser Herausforderung Rechnung tragen, eine hohe Flexibilität in der Softwarearchitektur, aber auch in der Organisationsarchitektur gewährleisten und eine Reduzierung von Time-to-Market bewirken zu können.^[104] Die Konfiguration der Komponenten in der Architektur darf daher nicht statisch sein.^[105] Bei veränderten Anforderungen müssen Komponenten flexibel, einfach und schnell konfiguriert oder neue Komponenten adaptiert werden können. Zu jedem Zeitpunkt muss gewährleistet sein, dass Funktionalität hinzugefügt oder modifiziert werden kann, ohne dass lokale Änderungen das Gesamtsystem beeinträchtigen. Flexibilität setzt daher lose Kopplung der Services voraus.

2.4.5 Technologie- bzw. Plattformunabhängigkeit

Die Trennung der fachlichen Anforderungen zur Erfüllung der Geschäftstätigkeit von der unterstützenden Technologie ist eine weitere Gestaltungsvorgabe, die von einer SOA zu erfüllen ist.^[106] Architekturkonzepte durchlaufen einen weitaus längeren Lebenszyklus als die relativ kurzen Innovationszyklen der zugrunde liegenden Technologieplattformen.^[107] Daher ist eine Architektur zu konzipieren, die mehr als einen Generationswechsel der installierten Technologie überdauert. Die Konzeption und Entwicklung der fachlichen Funktionalität ist losgelöst von der technologischen Implementierung vorzunehmen.^[108] Dies beinhaltet auch die Vermeidung von Abhängigkeiten zu bestimmten Produkten oder Herstellern. Servicenehmer und Servicegeber können prinzipiell auf unterschiedlichen Systemen laufen, dabei sollte die Interaktion zwischen diesen nicht durch technologische Spezifikationen behindert werden.

2.4.6 Einfachheit

Die Forderung nach Einfachheit zielt darauf ab, eine Architektur zu entwerfen, die eine möglichst effiziente Kommunikation zwischen Architekten, Entwicklern und Verantwortlichen aus den Fachabteilungen ermöglicht.^[109] In der Regel sind mehrere Personen mit individuellen Interessen und teilweise divergierenden Anforderungen an der Spezifikation und Konstruktion der Anwendungen im Unternehmen beteiligt. Hier gilt es, eine möglichst leicht verständliche Kommunikationsplattform zu schaffen, die wenig komplexe, interpretationsbedürftige Komponenten beinhaltet. Alle involvierten Personen müssen ein gemeinsames Verständnis für die Architektur aufbringen, welches ihre jeweilige Betrachtungsweise reflektiert.^[110] Ein Systemintegrator wird bspw. andere Fragestellungen mit einer Architektur assoziieren als ein Prozessmodellierer.

2.4.7 Verborgene Logik

Services folgen^[111] dem Black-Box-Ansatz, d. h. deren innere Geschäftslogik und Struktur ist außerhalb des Services verborgen.^[112] Der einzige für die Außenwelt sichtbare Teil eines Services ist die Servicebeschreibung des Service-Contracts.^[113] Realisiert wird dies durch die Trennung von Serviceschnittstelle und -implementierung. Die innere Logik eines Services ist für serviceaufrufende Instanzen irrelevant, da diese lediglich die Funktionalität erwarten, die im Service-Contract beschrieben wird und über die Serviceschnittstelle adressiert werden kann. Grundsätzlich gibt es keine Beschränkungen des Umfangs der in einem Service gekapselten Funktionalität. Ein Service kann daher für genau eine einfache, konkrete Aufgabe konzipiert werden oder eine komplexere Funktionalität eines umfassenden Aufgabenbereichs umfassen.

2.4.8 Verwendung offener Standards

Die Verwendung von offenen Standards ist essenziell, da Servicenutzer unter Umständen mit ihnen nicht bekannten Servicegebern kommunizieren müssen. Daher sind die Serviceschnittstellen mit offenen Standards zu realisieren.^[114]

Dies erhöht zum einen die Austauschbarkeit von Services und mindert Herstellerabhängigkeiten. Zum anderen wird sichergestellt, dass ein Service einer möglichst breiten Basis von potenziellen Servicenehmern zur Verfügung steht und im gleichen Zug einem Servicenehmer die Möglichkeit geboten wird, alternative Servicegeber in Anspruch zu nehmen. Am Markt ist eine zunehmende Verbreitung offener Standards zu verzeichnen.^[115]

2.5 Komponenten einer Service-orientierten Architektur

Gemäß der Definition einer SOA nach Krafzig, Banke und Slama, die bereits in Kapitel 2.2 vorgestellt wurde, besteht eine SOA aus Application-Frontends, Services, Service-Repository und Service-Bus.^[116] Diese Komponenten bilden das grundlegende Gerüst einer SOA. An dieser Stelle wird jedoch eine Erweiterung des Basiskonzepts um ein Business Process Management System (BPMS) vorgeschlagen, da nach der Auffassung des Autors dieser Arbeit zum Betreiben und Managen einer SOA ein solches System zur Orchestrierung^[117] von Services erforderlich ist.

2.5.1 Application-Frontend

Die Application-Frontends^[118] stellen den aktiven, für den Endbenutzer wahrnehmbaren Teil einer SOA dar und bilden somit die nach außen sichtbare Schnittstelle des Systems.^[119] Im Vergleich zu den Services, die oft mehrere Jahre unverändert bleiben, vollziehen Application-Frontends wesentlich kürze Lebenszyklen. Durch Application-Frontends werden sämtliche Aktivitäten in der unternehmensweiten Systemlandschaft initiiert und kontrolliert. Ergebnisse werden direkt an die Application-Frontends zurückgeliefert. Grundsätzlich können Application-Frontends als graphische Benutzeroberfläche zur Interaktion mit Benutzern, als stapelverarbeitende Programme (engl. batch program), als langlebige, zyklische Prozesse oder als ereignisgesteuerte Prozesse realisiert werden. Application-Frontends weisen dabei Verantwortlichkeiten entlang eines Geschäftsprozesses einem oder mehreren Services zu.

2.5.2 Service

Im Kontext einer SOA ist jeder Service durch eine unverwechselbare, fachlich funktionale Bedeutung gekennzeichnet, die in seiner inneren Struktur gekapselt ist. Ein Service besteht aus verschiedenen Teilen: Service-Contract, Serviceimplementierung und Serviceschnittstellen.^[120] Die Serviceimplementierung lässt sich weiter unterteilen in Geschäftslogik und Daten.

(1) Service-Contract:

Jeder Service muss über einen wohldefinierten Service-Contract verfügen, der die Funktionalität eines Service von seiner technischen Implementierung separiert.^[121] Der Service-Contract repräsentiert somit die Funktionalität nach außen in einer standardisierten Form, indem er die internen und technischen Details kapselt.^[122] Zudem spezifiziert der Service-Contract den Zweck, die Funktionalität, die Art des Datenaustauschs und die Voraussetzungen zur Nutzung eines Services.^[123] Die Spezifikation kann dabei formlos, meist aber durch eine formale Schnittstellenbeschreibungssprache basierend auf IDL^[124] oder WSDL erfolgen. Darüber hinaus können auch Metadaten, ausführliche Semantik^[125] zur Funktionalität und zu Parametern, Policies^[126] oder XML-Schemata enthalten sein, die nicht auf einer formalen Schnittstellenbeschreibungssprache basieren. Der Service-Contract umfasst eine Reihe von Vereinbarungen, die getroffen und von potenziellen Servicenutzern akzeptiert werden müssen, um eine erfolgreiche Kommunikation zu gewährleisten.^[127]

(2) Serviceschnittstellen:

Eine grundlegende Forderung an einen Service ist die Trennung zwischen Implementierung und seiner Schnittstelle, die durch den Service-Contract beschrieben wird. Dies bedeutet, dass die Funktionalität eines Services gekapselt ist und über seine Schnittstelle von Servicenutzern über das Netzwerk adressiert werden kann.^[128] Als Schnittstelle wird hier die technische Spezifikation verstanden, wobei die Beschreibung dieser Schnittstelle Teil des Service-Contracts ist. Ein Service kann mehrere Schnittstellen haben.

(3) Serviceimplementierung:

Die Serviceimplementierung stellt die technische Realisierung des Service-Contracts dar und somit die beschriebene Funktionalität mit den dazugehörigen Daten bereit.^[129] Die Serviceimplementierung kann mehrere Bestandteile, wie Programme, Konfigurationsdaten und Datenbanken umfassen.

Die Geschäftslogik ist Teil der Serviceimplementierung, die in einem Service gekapselt ist und von potenziellen Servicenehmern durch die Serviceschnittstellen angefordert werden kann.

Zudem kann ein Service Daten bereitstellen oder die Anbindung an eine Datenbank realisieren, in diesem Fall handelt es sich um einen datenzentrierten Service.

Zusammenfassend sind die einzelnen Elemente eines Services in Abb. 2-2 dargestellt.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 2-2: Bestandteile eines Services^[130]

2.5.3 Service-Repository

Ein Service-Repository^[131] stellt sicher, dass angefragte Services aufgefunden werden können und hält Informationen zur Verwendung dieser Services bereit, insbesondere dann, wenn diese Services außerhalb der funktionalen Reichweite des Projekts liegen, welches den Service generiert hat.^[132],^[133] Der Großteil der erforderlichen Informationen ist Bestandteil der Service-Contracts, jedoch werden im Service-Repository zusätzliche Informationen bereitgestellt. Dazu zählen:

- Beschreibung der Services und Operationen mithilfe von WSDL oder XML
- Angaben über den physischen Speicherort und technische Spezifikationen
- Eigentümer der Services und Beschreibung der Verantwortlichkeiten
- Zugriffsrechte und -kontrolle sowie Nutzungsbedingungen
- Angaben zur Performance und Skalierbarkeit der angebotenen Services, inklusive Antwortzeitverhalten und Durchsatzbeschränkungen (SLA^[134] )

Zum Aufbau einer SOA ist ein Service-Repository nicht zwingend erforderlich.^[135] Für den langfristigen Betrieb und die Nutzung einer SOA wird ein Service-Repository jedoch dringend empfohlen. Im seltenen Fall, wenn nur wenige Services vorhanden sind und das Projekt überschaubar ist, kann auf den Einsatz eines Service-Repositories verzichtet werden. In der Realität besteht jedoch die Herausforderung darin, mehrere parallel laufende Projekte, wechselnde Teams und eine Vielzahl von Services koordinieren zu müssen. Dann ist ein zentrales Service-Repository zwingend erforderlich.

Abb. 2-3 verdeutlicht die Vermittlung zwischen Serviceanbieter und -nehmer. Der Serviceanbieter muss zunächst seine Servicebeschreibung im Service-Repository veröffentlichen. Erst danach kann ein Servicenehmer, der eine konkrete Funktionalität fordert, den Verweis auf einen entsprechenden Serviceanbieter erhalten. Nachdem zwischen Serviceanbieter und -nehmer der Service-Contract vereinbart wurde, erfolgt die Nutzung und die eigentliche Interaktion zwischen Serviceanbieter und -nehmer.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 2-3: Service-Repository, Serviceanbieter und Servicenehmer^[136]

2.5.4 Service-Bus

Die Aufgabe des Service-Bus besteht darin, alle Application-Frontends und Services einer SOA miteinander zu verbinden.^[137] Die Services müssen dabei nicht notwendigerweise auf einer einzigen gemeinsamen Technologieplattform basieren, sondern können auf verschiedenen Produkten oder Systemplattformen laufen. Dadurch differenziert sich der Service-Bus von einem Software Bus im Kontext von EAI, da ein Service-Bus unterschiedliche Technologien beherrschen muss.

Folgende Merkmale charakterisieren einen Service-Bus:

- Konnektivität: Bereitstellung einer gemeinsamen Kommunikationsplattform für alle Services und Application-Frontends innerhalb der SOA.
- Heterogenität der Technologien: In der Realität zeichnen sich Unternehmen durch heterogene Technologien aus. Daher muss der Service-Bus alle SOA-Artefakte, die auf unterschiedlichen Programmiersprachen, Betriebssystemen und Laufzeitumgebungen basieren, miteinander verbinden können. Zudem müssen unterschiedliche Middlewaresysteme und Kommunikationsprotokolle, die sich im Laufe der Zeit im Unternehmen etabliert haben, unterstützt werden.
- Heterogenität der Kommunikationskonzepte: Analog zur Heterogenität der Technologien, muss der Service-Bus unterschiedliche Kommunikationskonzepte, wie synchrone und asynchrone Kommunikation, beherrschen.
- Technische ‚Services’: Zudem muss der Service-Bus auch technische Services zur Überwachung und Nachrichtenermittelung bereitstellen.

2.5.5 Business Process Management System

„Das Ganze ist mehr als die Summe seiner Teile.“ ^[138]

Ein Business Process Management System (BPMS) ist nicht Bestandteil des Basisgerüsts einer SOA nach Krafzig, Banke und Slama, doch empfiehlt sich aus Sicht des Autors dieser Arbeit die Unterstützung des Business Process Management (BPM) mithilfe eines BPMS, um den erfolgreichen Einsatz einer SOA zu gewährleisten und die Prinzipien einer SOA zu erfüllen.

BPM umfasst die Identifizierung, Modellierung, Entwicklung und Organisation von Geschäftsprozessen einer Organisation, die sowohl Softwaresysteme als auch die Interaktion mit Anwendern beinhalten.^[139] Im Kontext der SOA werden dabei Services so angeordnet, dass diese in ihrem Zusammenwirken einen Geschäftsprozess abbilden.^[140] BPMS hat eine lange Historie: in den Anfängen meist als Workflow-Systeme bezeichnet, die in erster Linie von Mitarbeitern begleitet^[141] wurden, haben sie sich zu modernen Web Services Orchestrierungs- und Choreographie-Systemen entwickelt.^[142]

Die Ziele von BPM sind:

- Reduzierung der Diskrepanz zwischen Geschäftsanforderungen und IT-Systemen, indem Anwender Geschäftsprozesse modellieren und die IT-Abteilung die notwendige Infrastruktur zur Verfügung stellt, um diese Geschäftsprozesse auszuführen und zu kontrollieren.
- Erhöhung der Mitarbeiterproduktivität und Reduzierung der laufenden Kosten durch automatisierte und rationalisierte Geschäftsprozesse.
- Erhöhung der Unternehmensflexibilität, indem Prozesslogik von anderen Geschäftregeln getrennt wird und mit einer einfachen Darstellung von Geschäftsprozessen entsprechend modifiziert werden kann. Dies führt dazu, dass Unternehmen schneller auf Marktveränderungen reagieren und einen Wettbewerbsvorteil erzielen können.
- Reduzierung der Entwicklungskosten, indem graphische Programmierwerkzeugen verwendet werden, mit denen schnell IT-Systeme erstellt oder geändert werden können.

Für die Umsetzung dieser Ziele wird ein BPMS benötigt. Die meisten BPMS beinhalten zumindest die Prozessmodellierungsfunktion, welche es ermöglicht, den Prozess graphisch darzustellen, in dem die Knoten bestimmte Aufgaben abbilden und die Verbindungslinien Kontroll- oder Datenflüsse darstellen. Neben der Prozessmodellierungsfunktion sollte ein BPMS mindestens noch folgende Funktionen abdecken: Prozessausführung und Prozessüberwachung.

3. Methoden zur Exploration des Expertenwissens

Im Zentrum dieser Arbeit steht die Exploration^[143] des Expertenwissens zur Identifizierung und Klassifizierung von Problemsituationen bei der Einführung einer SOA. In diesem Kapitel werden die grundlegenden Methoden der qualitativen Datenerhebung und -auswertung vorgestellt und an einigen Stellen von der quantitativen Forschungsmethodik abgegrenzt. Darauf aufbauend wird eine für den Forschungsanspruch dieser Arbeit geeignete qualitative Forschungsmethode erarbeitet, die sich im Wesentlichen an der qualitativen Inhaltsanalyse nach Mayring orientiert.

3.1 Zum Verhältnis qualitativer und quantitativer Forschung

Die im Rahmen dieser Arbeit verwendeten Methoden und Techniken zur Datenerhebung und Exploration des Expertenwissens sind der Sozialforschung entlehnt. Grundsätzlich unterscheidet die Sozialforschung quantitative und qualitative Forschungsmethoden, die sich sowohl methodisch als auch nach der Eignung für einen konkreten Forschungsbereich und nach dem Wissenschaftsverständnis unterscheiden.^[144] Ein wesentliches Unterscheidungskriterium ist die Art und die Verwendung des Datenmaterials. Während in der quantitativen Forschung typische Quantifizierungen von betrachteten Realitätsausschnitten in statistische Auswertungen münden, operiert die qualitative Forschung mit „Verbalisierungen der Erfahrungswirklichkeit“^[145], die interpretiert und analysiert werden. Qualitative Forschungsmethoden eignen sich daher besonders zur Exploration und Durchdringung von wissenschaftlich noch wenig strukturierten Gegenstandsbereichen mit dem Ziel des Erkenntnisgewinns.^[146] Quantitative Forschungsmethoden versuchen hingegen, durch theoretische Modelle einen konkreten Realitätsausschnitt abzubilden und daraus Hypothesen – Vermutungen über Zusammenhänge – abzuleiten, die operationalisiert und an empirischen Zusammenhängen überprüft werden können.^[147] In der quantitativen Forschung liegt folglich der Fokus auf dem deduktiven Erklärungsmodell und beschränkt sich meist auf die Überprüfung von Theorien und Hypothesen, die im Vorfeld generiert wurden.^[148] Im Gegensatz zur qualitativen Forschung, bei der die Bildung von Theorien und Hypothesen im Vordergrund steht, die sich induktiv aus dem Untersuchungsfeld ergeben.

3.2 Formen des Interviews

In der Literatur der Sozialforschung werden unterschiedliche Interviewformen beschrieben und diskutiert.^[149] Bezeichnungen werden häufig nicht einheitlich verwendet.

Zur Differenzierung der unterschiedlichen Interviewformen bieten sich jedoch folgende Dimensionen an, die eine Klassifizierung der Interviewformen erlauben.^[150] In den Klammern sind jeweils die möglichen Merkmalausprägungen aufgeführt.

- Intention bzw. Funktion des Interviews (ermittelnd, vermittelnd)
- Standardisierungsgrad (strukturiert, halbstrukturiert, unstrukturiert)
- Anzahl der Befragten (Einzelinterview, Gruppeninterview)
- Form der Kommunikation (schriftlich, (fern-)mündlich)
- Stil der Kommunikation bzw. Autoritätsanspruch des Interviewers (weich, neutral, hart)
- Art der Fragen (geschlossen, offen)

Die Merkmalausprägungen der einzelnen Dimensionen können kombinatorisch auftreten, so dass die Gesamtheit der Ausprägungen eine bestimmte Interviewform typisiert. Aufgrund der vielen Kombinationsmöglichkeiten der Dimensionsmerkmale werden in der Literatur entsprechend unterschiedliche Interviewformen diskutiert.^[151] Der aus der Kombination der Merkmalausprägungen resultierende Interviewtyp ist dann entweder für quantitative, qualitative oder beide Forschungsmethoden geeignet.

Im Folgenden wird die qualitative von der quantitativen Interviewform abgegrenzt, um anschließend die für die Studie dieser Arbeit geeignete Form des qualitativen Interviews vorzustellen.

3.2.1 Abgrenzung des qualitativen vom quantitativen Interview

Die Hauptunterscheidungskriterien zwischen qualitativen und quantitativen Interviews liegen in den Ausprägungen der Dimensionen: Standardisierungsgrad und Art der Fragen.

Quantitative Interviews sind durch ein strukturiertes und planmäßiges Vorgehen mit geschlossenen Fragen charakterisiert.^[152] Die Befragten werden dazu animiert, eine Reihe von vorgegebenen, standardisierten Fragen zu beantworten. Das Hauptaugenmerk liegt dabei auf der Vergleichbarkeit und Standardisierbarkeit der erhobenen Daten.

Beim qualitativen Interview hingegen wird lediglich ein Rahmen vorgegeben.^[153] Der Interviewer hat gegebenenfalls einen halbstrukturierten Leitfaden zur Hand, in dem weder die Reihenfolge noch eine konkrete Formulierung der Fragen vorgegeben ist. Die Art der Fragen ist somit offen und offeriert dadurch dem Befragten den größtmöglichen Gestaltungsfreiraum für seine Antworten. Dies scheint zweckmäßig zur Exploration von unbekannten Sachverhalten aus dem Erfahrungsbereich des Befragten. Im folgenden Abschnitt wird eine besondere Form des Leitfadeninterviews erläutert – das Experteninterview.

3.2.2 Das Experteninterview

Das Experteninterview stellt eine Spezialform des Leitfadeninterviews dar.^[154] Im Vordergrund steht dabei weniger die Person selbst, sondern vielmehr fungiert der Befragte in seiner Eigenschaft als Experte in seinem konkreten Problem- oder Forschungsfeld. Die Bezeichnung des Experten wird jemandem zugesprochen, „der auf einem begrenzten Gebiet über klares und abrufbares Wissen“^[155] oder über spezielle Fähigkeiten verfügt.^[156] Das Interview schränkt demnach den Befragten auf seine Funktion als Experte in einem klar abgrenzbaren Ausschnitt der Realität mit direktem Bezug zum Forschungsgegenstand ein. Der Leitfaden eignet sich besonders als Instrumentarium bei Experteninterviews, weil er zum einen eine Steuerungsfunktion einnimmt, um unergiebige und weniger relevante Themen auszublenden und um auf typisierende und zur Forschungsfrage bezogene Inhalte zu fokussieren. Zum anderen ermöglicht die Offenheit des Leitfadens dem Experten möglichst frei, seine Meinungen und Einstellungen zum Thema zu äußern. Dabei besteht jedoch die Gefahr, dass der Experte „sein Wissen in einem Vortrag referiert“^[157] und den Fokus auf die eigentliche Forschungsfrage verliert. In diesem Fall liegt es in der Verantwortung des Interviewers, das zentrale Thema anhand des Leitfadens wieder aufzugreifen.

3.3 Bestimmung der Auswahlmenge

Neben der Festlegung geeigneter Methoden zur Datenerhebung und zur Datenauswertung ist auch die Auswahl einer geeigneten Stichprobe bzw. die Bestimmung einer Auswahlmenge von großer Bedeutung. Repräsentativität und Generalisierbarkeit sind die geforderten Paradigmen. Grundsätzlich werden auch hier quantitative und qualitative Ansätze unterschieden.

Bei der quantitativen Forschung stehen Fragestellungen der statistischen Zufallsverteilung von Anteils- und Mittelwerten einer Population im Vordergrund, d. h. vor allem die Repräsentativität einer Stichprobe gegenüber ihrer Grundgesamtheit ist entscheidend.^[158] Durch geeignete Wahl und Größe der Stichprobe im Verhältnis zur Grundgesamtheit sollen Verzerrungen nach Möglichkeit minimiert werden.

Hingegen stehen bei der qualitativen Methodologie andere Zielsetzungen im Vordergrund.^[159] Ausgerichtet an dem zur Theorienbildung durchgeführten Prozess der Datengewinnung sind Umfang und Merkmal des Forschungsgegenstandes am Anfang der Forschung weitestgehend unbekannt. Die Stichproben werden nach festgelegten Kriterien zweckentsprechend bestimmt und weniger nach statischen Zufallverteilungsfunktionen im klassischen Sinne gezogen. Daher ist auch der Begriff der Stichprobe, der nach dem klassischen Verständnis eine Zufallsverteilung suggeriert, nicht ganz zutreffend und sollte im Kontext der qualitativen Methodologie durch den Begriff „Auswahleinheiten“ oder „Auswahlmengen“ substituiert werden.^[160] In Abhängigkeit der Existenz von wichtigen Aspekten zur Theorienbildung kann die Auswahlmenge fortlaufend erweitert und angepasst werden.^[161] Dies fördert zum einen die notwendige Flexibilität des Forschungsprozesses, zum anderen können so adäquate Hypothesen generiert und ein umfassenderes Kategoriensystem aufgebaut werden.^[162]

3.3.1 Güte der Auswahlmenge

Unabhängig davon, ob es sich um quantitative oder qualitative Forschung handelt, ist für die Güte der Stichprobe bzw. der Auswahlmenge ausschlaggebend, dass für den Forschungsgegenstand relevante Fälle aus dem Untersuchungsumfeld in die Studie einbezogen werden. Somit ist das Einbeziehen von relevanten Fällen und das Ausschließen von irrelevanten Fällen das zentrale Gütekriterium.

Wie eingangs erwähnt, wird dies bei der quantitativen Forschung durch Ziehung von Zufallsstichproben mit geeignetem Umfang erreicht. Dadurch soll gewährleistet werden, dass durch die statistische Zufallsverteilung der Stichprobe diese hinsichtlich unbekannter Merkmale unverzerrt bleibt.

Diese Herangehensweise ist bei der qualitativen Forschung jedoch ungeeignet, da hier gerade die bedeutungstragenden und typisierenden Personen, Situationen oder institutionellen Felder untersucht werden sollen, die für das Forschungsproblem eine hohe Relevanz haben.^[163] Kennzeichnend für die qualitative Forschung ist zudem, dass sich die Analyse nur anhand einer relativ kleinen Auswahlmenge im Vergleich zur Stichprobe bei der quantitativen Forschung realisieren lässt. Denn „bei einer zufälligen Ziehung der Fälle würden hier die zufälligen Stichprobenfehler, die bei großen Samples kaum ins Gewicht fallen, zu folgenschweren Verzerrungen führen.“^[164] Qualitative Forschung zielt demnach nicht auf die quantitative Ausprägung bestimmter Merkmale und die statistische Repräsentativität ab, sondern fordert eine inhaltliche Repräsentation typischer Fälle, die durch eine angemessene und relevante Zusammensetzung der Auswahlmenge erfüllt werden soll. Dabei muss die Auswahlmenge nicht im vollen Umfang vorher festgelegt werden, sondern kann iterativ durch Hinzuziehen weiterer Fälle ergänzt werden, bis sich eine theoretische Sättigung einstellt, die sich dadurch äußert, dass kein oder nur ein unwesentlicher Erkenntnisgewinn erzielt werden kann.^[165]

3.3.2 Identifizierung von Experten

Die Identifizierung als Experte in einem konkreten Fachgebiet ist im Allgemeinen hinreichend erbracht, wenn eine gewisse Anerkennung in der Fachwelt vorhanden ist. Eine solche Anerkennung kann sich in unterschiedlicher Weise äußern, bspw. an der Teilnahme an bestimmten Fachgremien und Konferenzen oder Publikationen von anerkannten Aufsätzen, Artikeln oder Standard- und Referenzwerken.

Ferner sollte der Experte über einen aktuellen Kenntnisstand und präsentes und damit abrufbares Wissen des Forschungsgegenstandes verfügen. Gerade im Hinblick auf die Dynamik in der fortschreitenden Entwicklung der Informationstechnologie ist die Forderung nach aktuellem Kenntnisstand zwingend erforderlich. Zudem wird Praxiserfahrung mit direktem Bezug zum Forschungsgegenstand vorausgesetzt.

3.4 Datengewinnung

Im Gegensatz zur schriftlichen Befragung in Form von Fragebögen, bei denen Datenerhebung und Datenerfassung zusammenfallen, wird bei qualitativen Interviews zwischen diesen beiden aufeinander folgenden Schritten unterschieden.^[166]

Datenerhebung beschreibt den Prozess der Anwendung des Erhebungsinstrumentes – hier die Durchführung der Experteninterviews. Die Durchführung der Interviews und das Stellen der Fragen gemäß dem Leitfaden reichen jedoch nicht aus, vielmehr müssen die Aussagen des Befragten in nachhaltiger Form festgehalten werden, um die daran anschließende Auswertung und Analyse zu ermöglichen.

Folglich setzt die objektive Auswertung und Analyse eine adäquate und nachhaltige Datenerfassung voraus. Denn ohne adäquate Datenerfassung besteht die Gefahr, „dass der datenerhebende Forscher subjektiv-selektiv wahrnimmt und nicht alle Informationen im Gedächtnis behält“^[167] und somit eine Nachprüfbarkeit kaum möglich ist. Eine nachhaltige Datenerfassung ist daher unverzichtbar für qualitative Interviews.^[168] Als Medium der Datenerfassung von Interviews empfiehlt sich eine akustische Aufzeichnung des Gesprächsverlaufs.

3.5 Transkription

Im vorherigen Kapitel wurde die Notwendigkeit diskutiert, dass neben der eigentlichen Datenerhebung aus Gründen der Nachprüfbarkeit und zur Vermeidung der subjektiv-selektiven Wahrnehmung eine adäquate Datenerfassung vorzunehmen ist. Die Gesprächaufzeichnung stellt noch keine geeignete auswertbare Form dar, so dass eine Transkription^[169] des Gesprochenen als vorbereitende Maßnahme für weitere Analyseschritte erforderlich ist.^[170]

Neben dem Protokollieren der verbalen Gesprächsinhalte müssen Regeln zur Behandlung von nonverbalen Gesprächsbestandteilen festgelegt werden. Nonverbale Gesprächsbestandteile sind kürzere und längere Pausen, Lachen, Räuspern oder sonstige Gesprächsbrüche. Bei soziologischen Forschungsfragen können nonverbale und „parasprachliche Elemente“^[171] aufschlussreiche und relevante Informationen enthalten, die in anschließenden Analysen und Interpretationen berücksichtigt werden können. Auch Stimmlage, Intonation oder Lautstärke können Emotionen reflektieren und das Gesagte untermauern, Ironie, Zynismus und Unsicherheit erkennen lassen oder Lügen entlarven.

Am Ende muss zudem sichergestellt werden, dass entsprechend der getroffenen Vereinbarung Namen und Angaben zu Personen anonymisiert werden.

3.6 Qualitative Inhaltsanalyse

Den Kern der Auswertung stellt die qualitative Inhaltanalyse dar. Bevor jedoch die eigentliche Methode zur qualitativen Inhaltsanalyse erläutert wird, soll kurz eine Abgrenzung zur quantitativen Inhaltsanalyse vorgenommen werden.

3.6.1 Abgrenzung zur quantitativen Inhaltsanalyse

Analog zur Unterscheidung von qualitativen und quantitativen Interviewtechniken wird zwischen qualitativer und quantitativer Inhaltsanalyse unterschieden.

Bei der quantitativen Inhaltsanalyse wird eine Zuordnung von konkreten Textpassagen zu ausgewählten, übergreifenden Kategorien (Bedeutungseinheiten) angestrebt.^[172] Die Anzahl der Textpassagen, die einer bestimmten Kategorie zugeordnet werden können, kennzeichnet die Eigenschaften des Textes. Das Ergebnis liefert eine Häufigkeitsverteilung, die mit geeigneten statistischen Verfahren aufbereitet und mit Hypothesentests überprüft werden können, um die Intensität bestimmter Merkmalausprägungen des Textes bewerten zu können.

Die qualitative Inhaltsanalyse zielt im Gegensatz zur quantitativen Inhaltsanalyse nicht auf eine Auszählung und Zuordnung von einzelnen Textpassagen zu Kategorien ab, sondern hier sollen einzelne Textpassagen qualitativ analysiert und inhaltlich interpretiert werden.^[173] Folglich differenziert sich die qualitative Inhaltsanalyse von der quantitativen formal dadurch, dass keine Quantifizierung vorgenommen wird. Im Fokus der Analyse stehen Verbalisierungen der Erfahrungsrealität des Befragten. In Teilbereichen können aber auch bei der qualitativen Inhaltsanalyse Quantifizierungen vorgenommen werden, „um den Grad der Übereinstimmung unterschiedlicher Deutungen zu messen.“^[174] Bei genauer Betrachtung stellt somit die qualitative Inhaltsanalyse mit ihren Analyse- und Interpretationstechniken eine umfangreichere Auswertungsmethodik als die quantitative Methode dar.^[175]

3.6.2 Qualitative Inhaltsanalyse nach Mayring

Die qualitative Inhaltsanalyse nach Mayring scheint für den Forschungsgegenstand dieser Arbeit geeignet zu sein, weil das Hauptziel in der Bildung eines Kategoriensystems liegt und das inhaltsanalytische Ablaufmodell strukturiert ist.^[176] Darüber hinaus ist dieses Verfahren auf die manifestierten Kommunikationsinhalte fokussiert und weniger auf latente, stark interpretationsbedürftige Gesprächselemente.^[177] Dies bedeutet, dass ausschließlich die Aussagen des Befragten untersucht werden, die dieser bewusst und explizit von sich gegeben hat. Dieser Ansatz entspricht somit dem Forschungsanspruch dieser Arbeit.

[...]

^[1] Vgl. z. B. Reinheimer, u. a. /SOA/ 7 sowie Gallas /Servic Life Cycle/ 235.

^[2] Vgl. Natis /SOA Scenario/ 2.

^[3] Weiterführende Definitionen werden in Kapitel 2. Theoretische Grundlagen der Service-orientierten Architektur diskutiert.

^[4] Vgl. z. B. Stantchev, Malek /SOA/ 251-252 sowie Cearley, Fenn, Plummer /Five hottest IT Topics/ 3.

^[5] Oey u. a. /SOA/ 201.

^[6] Vgl. z. B. Cearley, Fenn, Plummer /Five Hottest IT-Topics/ 3-4.

^[7] Siehe Kapitel 2. Theoretische Grundlagen der Service-orientierten Architektur.

^[8] Vgl. zu diesem und dem folgenden Satz Erl /SOA Concepts/ 362.

^[9] Vgl. Barry /Web Services and SOA/ 100-105.

^[10] Unter Granularität wird der Funktionsumfang eines Services verstanden. Vgl. Marks, Bell /SOA/ 109.

^[11] Vgl. Marks, Bell /SOA/ 99-149.

^[12] Vgl. Krafzig, Banke, Slama /Enterprise SOA/ 251-255.

^[13] Vgl. Durst, Daum /Erfolgsfaktoren SOA/ 18-26.

^[14] An dieser Stelle soll keine umfassende Abhandlung der Entwicklungsgeschichte der elektronischen Datenverarbeitung dargelegt werden, sondern der Weg, der die SOA begründet, lediglich kurz dargestellt werden. Der interessierte Leser sei an die einschlägige Literatur verwiesen. Vgl. z. B. Stahlknecht, Hasenkamp /Wirtschaftsinformatik/ 508-521.

^[15] Vgl. zu diesem Absatz Dostal u. a. /SOA mit Web Services/ 2.

^[16] Dostal u. a. /SOA mit Web Services/ 2.

^[17] Vgl. zu diesem Absatz Krafzig, Banke, Slama /Enterprise SOA/ 7-9.

^[18] Vgl. Krafzig, Banke, Slama /Enterprise SOA/ 7-8 sowie Zarnekow, Hochstein, Brenner /IT-Management/ 3.

^[19] Middleware ist grundlegend jede Art von Software, welche die Kommunikation zwischen zwei oder mehreren Softwaresystemen ermöglicht. Vgl. Linthicum /EAI/ 120.

^[20] Auf eine deutsche Übersetzung des Begriffs „Point-to-Point“ wird im Kontext dieser Arbeit verzichtet. Die wörtliche Übersetzung ist „Punkt-zu-Punkt“.

^[21] Auf eine deutsche Übersetzung des Begriffs „Time-to-Market“ wird im Kontext dieser Arbeit verzichtet. Der Ausdruck kann mit „Zeitspanne bis zur Marktreife (eines Produktes oder Dienstleistung)“ übersetzt werden.

^[22] Vgl. Zarnekow, Hochstein, Brenner /IT-Management/ 3-4.

^[23] Auf eine deutsche Übersetzung dieses zentralen Begriffs „Service“ wird im Kontext dieser Arbeit verzichtet. Die wörtliche Übersetzung ist „Dienst“.

^[24] Vgl. Marks, Bell /SOA/ 2.

^[25] Im Folgenden werden die Begriffe Servicenehmer, Servicekonsument und Servicenutzer synonym verwendet.

^[26] Vgl. zu diesem und dem folgenden Satz Woods, Mattern /Enterprise SOA/ 323, Marks, Bell /SOA/ 34 sowie Barry /Web Service and SOA/ 19.

^[27] Wagner, Schwarzenbacher /Unternehmensprozesse/ 19.

^[28] Geschäftsprozess und Unternehmensprozess werden in dieser Arbeit synonym verwendet.

^[29] Wagner, Schwarzenbacher /Unternehmensprozesse/ 19 sowie ähnliche Darstellung in Hansen, Neumann /Wirtschaftsinformatik/ 245.

^[30] Vgl. Hansen, Neumann /Wirtschaftsinformatik/ 245.

^[31] Ein Programm ist eine vollständige Anweisung oder Verarbeitungsvorschrift zur Lösung einer Aufgabe an einem Rechner. Vgl. hierzu Stahlknecht, Hasenkamp /Wirtschaftsinformatik/ 25 sowie Hansen, Neumann /Wirtschaftsinformatik/ 12.

^[32] Hansen, Neumann /Wirtschaftsinformatik/ 150. Ergänzend zu der Definition von Hansen und Neumann fügt Helmut Balzert /Grundlagen der Informatik/ 30, „zugehörige Informationen und notwendige Dokumentation“ zum Softwarebegriff hinzu.

^[33] Hansen, Neumann /Wirtschaftsinformatik/ 131.

^[34] Dustdar, Gall, Hauswirth /Software-Architekturen/ 42.

^[35] Ferner führen Bass, Clements, Kazman eine Diskussion zur Abgrenzung zwischen den Begriffen Software- und Systemarchitektur und halten fest, dass es einen Unterschied gibt. Systemarchitekturen beschreiben neben den Softwarekomponenten auch die physikalischen Eigenschaften der Hardware und der Kommunikationsinfrastruktur. Dass in der Literatur überwiegend Softwarearchitektur im Mittelpunkt steht, begründen sie dadurch, da hier die Entscheidungsfreiheit des Softwarearchitekten in der Wahl der geeigneten Softwarekomponenten bestünde und darin der kritische Erfolgsfaktor läge. Nichtsdestotrotz würden beim Entwurf einer Softwarearchitektur auch hardwarebezogene Aspekte berücksichtigt werden müssen. Vgl. Bass, Clements, Kazman /Software Architecture/ 34.

^[36] Deutsche Übersetzung der Definition von Bass, Clements, Kazman /Software Architecture/ 3, 21.

^[37] Deutsche Übersetzung der Definition von Krafzig, Banke, Slama/ Enterprise SOA/ 56.

^[38] Hansen und Neumann verstehen unter Hauptkomponenten bspw. ein relationales Datenbanksystem, ein Sicherheitssubsystem oder eine Kommunikationsinfrastruktur. Vgl. Hansen, Neumann /Wirtschaftsinformatik/ 254.

^[39] Hansen, Neumann /Wirtschaftsinformatik/ 254.

^[40] Gronau /Informationssystemarchitekturen/ 45.

^[41] Vgl. zu dieser Abbildung Aier, Dogan /Unternehmensarchitekturen/ 81.

^[42] Vgl. zu diesem Absatz Aier, Dogan /Unternehmensarchitekturen/ 81-82.

^[43] Vgl. Aier, Dogan /Unternehmensarchitekturen/ 81-82.

^[44] Siehe zur Diskussion zur Unterscheidung zwischen System- und Softwarearchitektur Kapitel 2.2.3 Softwarearchitektur sowie die entsprechende Fußnote.

^[45] Vgl. z. B. Oey u. a. /SOA/ 201 sowie Natis /SOA/ 23.

^[46] Vgl. z. B. Woods, Mattern /Enterprise SOA/ 101-102.

^[47] Dostal u. a. /SOA mit Web Services/ 11.

^[48] Erl /SOA Field Guide/ 51.

^[49] Krafzig, Banke, Slama /Enterprise SOA/ 57.

^[50] Marks, Bell /SOA/ 1, 34.

^[51] Newcomer, Lomow /SOA with Web Services/ 13.

^[52] MacKenzie u. a. /OASIS Reference Model/ 8, 29.

^[53] Vgl. zu diesem und dem folgenden Satz [1].25-26, [2].5-6, [3].7-8,10-15, [4].5-6, [5].4-5, [6].5-10,20-22, [7].4-5,8,14-18, [8].34. Diese Schreibweise ist die in dieser Arbeit verwendete Zitierweise der Interviews. Beispiel: [3].7-8,10-15 ist zu lesen als Interview Nr. 3 Zeilen 7-8 und 10-15. In Kapitel 4.1 wird diese Zitierweise noch einmal formal vorgestellt.

^[54] Vgl. [3].14-15, [7].13-14.

^[55] Vgl. Gallas, Schönherr /Service Management/ 228.

^[56] Stahlknecht, Hasenkamp /Wirtschaftsinformatik/ 328.

^[57] Vgl. zu diesem und dem folgenden Satz Linthicum /EAI/ 3.

^[58] Vgl. Gallas, Schönherr /Service Management/ 228.

^[59] Vgl. Gallas /Enterprise Service Integration/ 204.

^[60] Vgl. zu diesem Absatz Gallas, Schönherr /Service Management/ 227.

^[61] Auf eine deutsche Übersetzung des Begriffs „Application-to-Application“ wird im Kontext dieser Arbeit verzichtet. Gemeint ist die direkte Verbindung zwischen zwei Anwendungen.

^[62] Im Folgenden werden die Begriffe Servicegeber und Serviceanbieter synonym verwendet.

^[63] Vgl. Gallas /Enterprise Service Integration/ 195.

^[64] Vgl. Stantchev, Malek /SOA/ 251-252.

^[65] Siehe Kapitel 2.3.2 Web Service.

^[66] Gallas /Enterprise Service Integration/ 200.

^[67] B2B-Integration (Business-to-Business-Integration) meint eine unternehmensübergreifende Integration zwischen mindestens zwei Unternehmen.

^[68] Gallas /Enterprise Service Integration/ 200.

^[69] Vgl. Dostal u. a. /SOA mit Web Services/ 4, 8, 26.

^[70] WSDL (Web Services Description Language) ist ein XML-basierter Standard zur Schnittstellenbeschreibung von Web Services. Vgl. z. B. Bieberstein u. a. /SOA/ 217.

^[71] SOAP (Simple Object Access Protocol) ist ein vom W3C-Konsortium gepflegtes, XML-basiertes Nachrichtenformat zur Verschlüsselung von Nachrichten zwischen Web Servicegeber und -nehmer. Vgl. z. B. Bieberstein u. a. /SOA/ 215.

^[72] http (Hypertext Transfer Protocol) ist ein Kommunikationsprotokoll zur Übertragung von Daten und Nachrichten in Netzwerken. Vgl. z. B. Bieberstein u. a. /SOA/ 208.

^[73] XML (Extensible Markup Language) ist ein vom W3C-definierter Standard zur Beschreibung von anwendungsspezifischen Datenstrukturen zum Aufbau von XML-Dokumenten. Vgl. z. B. Hansen, Neumann /Wirtschaftsinformatik/ 1043.

^[74] W3C /Glossary/ ohne Seitenangabe.

^[75] Woods, Mattern /Enterprise SOA/ 322.

^[76] UDDI (Universal Description, Discovery and Integration) ist ein Standard zur Realisierung eines plattformunabhängigen, XML-basierten Service-Repositories zur Veröffentlichung und zum Auffinden von netzwerkbasierten Softwarekomponenten und Services. Vgl. z. B. Newcomer /Understanding Web Services/ 16 sowie Bieberstein u. a. /SOA/ 216.

^[77] Vgl. Dostal u. a. /SOA mit Web Services/ 27 sowie Bieberstein /SOA/ 215-217.

^[78] Vgl. Newcomer /Web Services/ 45-46.

^[79] Vgl. Erl /SOA Field Guide/ 51.

^[80] Vgl. zu diesem Absatz Woods, Mattern /Enterprise SOA/ 26, 109.

^[81] Vgl. zu diesem Absatz Woods, Mattern /Enterprise SOA/ 109.

^[82] Vgl. Woods, Mattern /Enterprise SOA/ 128 sowie Singh, Huhns /Service-Oriented Computing / 66-67.

^[83] Vgl. Gruhn, Pieper, Röttgers /MDA/ 21-22 sowie Gallas /Enterprise Service Integration/ 190-91.

^[84] Vgl. Krafzig, Banke, Slama /Enterprise SOA/ 167.

^[85] Vgl. Gruhn, Pieper, Röttgers /MDA/ 21-32, Gallas /Enterprise Service Integration/ 190-191 sowie Krafzig, Banke, Slama /Enterprise SOA/ 167.

^[86] UML (Unified Modeling Language) ist eine standardisierte Modellierungssprache und liefert eine Notation zur grafischen Darstellung objektorientierter Konzepte. Dazu gehören bspw. Klassendiagramme, Objektdiagramme oder Sequenzdiagramme. Vgl. Balzert /Grundlagen der Informatik/ 135.

^[87] Vgl. zu diesem Absatz Gruhn, Pieper, Röttgers /MDA/ 21-22.

^[88] Vgl. Gruhn, Pieper, Röttgers /MDA/ 21.

^[89] Vgl. Kraftzig, Banke, Slama /Enterprise SOA/ 167-168.

^[90] Vgl. Oey u. a. /SOA/ 212.

^[91] Vgl. Oey u. a. /SOA/ 212.

^[92] Vgl. Dostal u. a. /SOA mit Web Services/ 9 sowie Newcomer, Lomow /SOA with Web Services/ 75-76.

^[93] Vgl. zu diesem und dem folgenden Satz Reinheimer u. a. /SOA/ 10.

^[94] Der Begriff SOA-Artefakt subsumiert Serviceanbieter und Servicenehmer.

^[95] Vgl. Singh, Huhns /Service-Oriented Architecture/ 76 sowie Vgl. Woods, Mattern /Enterprise SOA/ 111.

^[96] Siehe Kapitel 2.5.3 Service-Repository.

^[97] Vgl. zu diesem und dem folgenden Satz Natis, Schulte /Introduction to SOA/ 2.

^[98] Siehe Kapitel 2.5.2 Service.

^[99] Vgl. zu diesem Absatz Krafzig, Banke, Slama /Enterprise SOA/ S. 242, 244-245.

^[100] Vgl. Newcomer, Lomow /SOA with Web Services/ 89.

^[101] Vgl. zu diesem Absatz Krafzig, Banke, Slama /Enterprise SOA/ 6.

^[102] Vgl. zu diesem und dem folgenden Satz Marks, Bell /SOA/ 17-21.

^[103] Vgl. zu diesem Absatz Oey u. a. /SOA/ 213.

^[104] Vgl. Zhang, Tanniru /Trade-Offs in SOA/ 2265.

^[105] Vgl. Singh, Huhns /Service-Oriented Architectur/ 77.

^[106] Vgl. zu diesem Absatz Krafzig, Banke, Slama /Enterprise SOA/ 7.

^[107] Vgl. z. B. Gronau /Informationssystemarchitekturen/ 43.

^[108] Vgl. z. B. Marks, Bell /SOA/ 121, 123, 127-129.

^[109] Vgl. Krafzig, Banke, Slama /Enterprise SOA/ 6.

^[110] Vgl. Krafzig, Banke, Slama /Enterprise SOA/ 6.

^[111] Übersetzung des englischen Begriffes „Hidden Logic“.

^[112] Vgl. zu diesem Absatz Erl /SOA Concepts/ 291, 298-299.

^[113] Siehe Kapitel 2.5 Komponenten einer Service-orientierten Architektur.

^[114] Vgl. zu diesem Absatz Newcomer, Lomow /SOA with Services/ 77-78 sowie Dostal u. a. /SOA mit Web Services/ 9.

^[115] Vgl. Newcomer, Lomow /SOA with Web Services/ 77-78.

^[116] Vgl. Krafzig, Banke, Slama /Enterprise SOA/ 56-57.

^[117] Siehe Kapitel 2.5.5 Business Process Management System.

^[118] Auf eine deutsche Übersetzung des Begriffs „Application-Frontend“ wird im Kontext dieser Arbeit verzichtet.

^[119] Vgl. zu diesem Abatz Krafzig, Banke, Slama /Enterprise SOA/ 57-59.

^[120] Vgl. Krafzig, Banke, Slama /Enterprise SOA/ 59-60.

^[121] Vgl. Newcomer, Lomow /SOA with Web Services/ 109.

^[122] Vgl. Marks, Bell /SOA/ 40.

^[123] Vgl. zu diesem Absatz Krafzig, Banke, Slama /Enterprise SOA/ 59-60.

^[124] IDL (Interface Definition Language) ist eine plattform- und programmiersprachenunabhängige Schnittstellenbeschreibungssprache, die in CORBA-Umgebungen eingesetzt wird, um Operationen zu deklarieren und Schnittstellen zu definieren. Vgl. Nghiem /IT Web Services/ 296.

„CORBA (Common Object Request Broker Architecture) ist ein Standard zur Entwicklung objektorientierter Anwendungen in verteilten und heterogenen Systemen.“, Hansen, Neumann /Wirtschaftsinformatik/ 168.

^[125] Die Semantik ordnet den zulässigen Aussagen einer Sprache eine konkrete Bedeutung zu. Die Menge aller zulässigen Aussagen einer Sprache ist die Syntax dieser Sprache. Vgl. Hansen, Neumann /Wirtschaftsinformatik/ 942 sowie Stahlknecht, Hasenkamp /Wirtschaftsinformatik/ 284.

^[126] Polices können Regeln, Nutzungsbedingungen und Präferenzen beinhalten. Vgl. Erl /SOA Concepts/ 136.

^[127] Vgl. Erl /SOA Concepts/ 137.

^[128] Vgl. zu diesem und dem folgenden Satz Krafzig, Banke, Slama /Enterprise SOA/ 60.

^[129] Vgl. zu diesem Absatz Krafzig, Banke, Slama /Enterprise SOA/60.

^[130] Vgl. zu einer ähnlichen Abbildung Krafzig, Banke, Slama /Enterprise SOA/ 59.

^[131] Auf eine deutsche Übersetzung des Begriffs „Service-Repository“ wird im Kontext dieser Arbeit verzichtet. In der deutschsprachigen Literatur ist häufig die Bezeichnung „(Dienst)-Verzeichnis“ im Zusammenhang mit SOA zu finden. Vgl. z. B. Dostal u. a. /SOA mit Web Services/ 12-16.

^[132] Vgl. zu diesem Absatz Krafzig, Banke, Slama /Enterprise SOA/ 60-64.

^[133] Andere Autoren unterscheiden zwischen Service-Registry und Service-Repository. Danach speichert ein Service-Registry Informationen über ein Objekt – also den Service – und nicht das Objekt selbst. Das Service-Repository hingegen ist der physische Speicherort des Objekts. D. h. die Lokalisierung eines Service wird über ein Service-Registry realisiert, welches auf dem Service-Repository aufsetzt. Vgl. McGovern u. a. /Enterprise SOA/ 154 und Oey u. a. /SOA/ 209-210.

^[134] SLA (Service Level Agreement) bezeichnet die Vereinbarung zwischen Servicegeber und Servicenehmer zur Einhaltung und Zusicherung der in dieser Vereinbarung festgelegten Servicequalität. Die Servicequalität wird u. a. bestimmt durch Verfügbarkeit, Durchsatz, Zuverlässigkeit, Antwortzeitverhalten, Sicherheit und Integrität. Vgl. Bieberstein u. a. /SOA/ 213.

^[135] Vgl. zu diesem Absatz Krafzig, Banke, Slama /Enterprise SOA/ 61.

^[136] Vgl. zu dieser Abbildung Dostal u. a. /SOA mit Web Services/ 12 sowie ähnlichen Darstellungen in Barry /Web Services and SOA/ 23 und Erl /SOA Concepts/ 75.

^[137] Vgl. zu diesem Absatz Krafzig, Banke, Slama /Enterprise SOA/ 64-65.

^[138] Dieser Satz wird Aristoteles (384-322 vor Chr.) zugeschrieben.

^[139] Vgl. zu diesem Absatz Newcomer, Lomow /SOA with Web Services/ 221-223.

^[140] Vgl. Dostal u. a. /SOA mit Web Services/ 197.

^[141] Im angelsächsischen Raum hat sich die Bezeichnung „People Driven Worklow“ etabliert.

^[142] Orchestrierung und Choreographie werden häufig synonym verwendet, obwohl diese Begriffe – streng genommen – zu unterscheiden sind. Choreographie wird meist im Zusammenhang mit erweiterten Business-to-Business Interaktionen verwendet; vgl. Newcomer, Lomow /SOA with Web Services/ 221, 245-247. Dostal u. a. /SOA mit Web Services/ 202 differenzieren in ähnlicher Weise wie folgt: „Eine Orchestrierung beschreibt die ausführbaren Aspekte eines Geschäftsprozesses aus der Sicht eines Prozesses“, hingegen beschreibt „eine Choreographie […] die Aufgaben und das Zusammenspiel mehrerer Prozesse unter dem Aspekt der Zusammenarbeit.“

^[143] Exploration als Verb: Explorieren (lat.: explorare) bedeutet, Sachverhalte zu erkunden, zu erforschen oder ausfindig zu machen. Vgl. z. B. Bortz, Döring /Forschungsmethoden/ 352.

^[144] Vgl. Bortz, Döring /Forschungsmethoden/ 296.

^[145] Bortz, Döring /Forschungsmethoden/ 296.

^[146] Vgl. Lamnek /Qualitative Sozialforschung/ 90.

^[147] Vgl. Mayer /Interview/ 27.

^[148] Vgl zu diesem und dem folgenden Satz Lamnek /Qualitative Sozialforschung/ 128, 249-250.

^[149] Vgl. zu diesem und dem folgenden Satz z. B. Lamnek /Qualitative Sozialforschung/ 356-384.

^[150] Vgl. Lamnek /Qualitative Sozialforschung/ 331. Eine ähnliche Differenzierung bietet Bortz, Döring /Foschungsmethoden/ 238.

^[151] An dieser Stelle wird auf eine weitergehende Erläuterung der Interviewformen verzichtet. Der interessierte Leser sei auf Lamnek /Qualitative Sozialforschung/ 356-384 und Bortz, Döring /Forschungsmethoden/ 237-246 verwiesen.

^[152] Vgl. zu diesem Absatz Lamnek /Qualitative Sozialforschung/ 725.

^[153] Vgl. zu diesem Absatz Lamnek /Qualitative Sozialforschung/ 725.

^[154] Vgl. zu diesem Absatz Mayer /Interview/ 37 sowie Flick /Qualitative Sozialforschung/ 139-140.

^[155] Mayer /Interview/ 40.

^[156] Im Kontext dieser Arbeit soll unter einem Experten demnach jemand verstanden werden, der auf dem abgrenzbaren Gebiet der SOA über abrufbares (explizites) und umfassenden Wissen verfügt.

^[157] Flick /Qualitative Sozialforschung/ 140.

^[158] Vgl. zu diesem und dem folgenden Satz Lamnek /Qualitative Sozialforschung/ 187-188.

^[159] Vgl. zu diesem Absatz Lamnek /Qualitative Sozialforschung/ 187-188.

^[160] In Anlehnung an Lamnek /Qualitative Sozialforschung/ 188.

^[161] Diese Strategie zur systematischen Auswahl der Untersuchungseinheiten wird in der Literatur als „Theoretical Sampling“ bezeichnet und kann im Deutschen mit „gezielte Auswahl(-strategie)“ übersetzt werden. Vgl. z. B. Lamnek /Qualitative Sozialforschung/ 191, 732 sowie Mayer /Interview/ 38.

^[162] Vgl. Lamnek /Qualitative Sozialforschung/ 189.

^[163] Vgl. Lamnek /Qualitative Sozialforschung/ 189.

^[164] Lamnek /Sozialforschung/ 189.

^[165] Vgl. Lamnek /Qualitative Sozialforschung/ 193.

^[166] Vgl. zu diesem Absatz Lamnek /Qualitative Sozialforschung/ 193.

^[167] Lamnek /Qualitative Sozialforschung/ 387.

^[168] Vgl. Lamnek /Qualitative Sozialforschung/ 387-389.

^[169] Transkription (lat.: transcriptio) bedeutet die (schriftliche) Übertragung, das Umschreiben: a) lautgerechte Übertragung in eine andere Schrift; b) fonetische Umschrift. Vgl. Dudenredaktion /Fremdwörterbuch/ 1051. In der Sozialwissenschaft wird darunter das Übertragen eines Interviews in eine auswertbare, schriftlich fixierte Form verstanden.

^[170] Vgl. zu diesem Absatz Lamnek /Qualitative Sozialforschung/ 403, Mayring /Qualitative Sozialfoschng/ 89-94 sowie Bortz, Döring /Forschungsmethoden/ 311-312.

^[171] Meuser, Nagel /Experteninterviews/ 456.

^[172] Vgl. Bortz, Döring /Forschungsmethoden/ 149.

^[173] Vgl. Bortz, Döring /Forschungsmethoden/ 149.

^[174] Botz, Döring /Forschungsmethoden/ 296.

^[175] Vgl. Lamnek /Qualitative Sozialforschung/ 506.

^[176] Siehe Anhang A: Interpretationsregeln nach Mayring.

^[177] Vgl. zu diesem und dem folgenden Satz Lamnek /Qualitative Sozialforschung/ 513.