Lade Inhalt...

Entwurf und Einführung service-orientierter Architekturen im Unternehmen

Seminararbeit 2010 33 Seiten

Informatik - Wirtschaftsinformatik

Leseprobe

Inhaltsverzeichnis

1 Einführung

2 Grundlagen
2.1 Grundlagen der Unternehmensarchitektur
2.1.1 Architekturentwurf
2.1.2 Softwarearchitektur
2.1.3 Unternehmensarchitektur
2.2 Grundlagen service-orientierter Architekturen
2.2.1 Service
2.2.2 Service-orientierte Architektur

3 Entwurf und Einführung service-orientierter Architekturen
3.1 Rolle des SOA-Konzepts im Unternehmen
3.2 Entwurf service-orientierter Architekturen
3.2.1 Überblick - Entwurf service-orientierter Architekturen
3.2.2 Schritt 1: Bestimmung der Ideal-Anwendungslandschaft
3.2.3 Schritt 2: Ist-Analyse der vorhandenen Anwendungslandschaft
3.2.4 Schritt 3: Bestimmung der Soll-Anwendungslandschaft
3.3 Einführung service-orientierter Architekturen im Unternehmen
3.4 Auswirkung von IT-Trends auf das SOA-Konzept

4 Diskussion
4.1 Vorteile service-orientierter Architekturen
4.2 Methodische Probleme service-orientierter Architekturen

5 Zusammenfassung und Ausblick

Abkürzungsverzeichnis

Abbildungsverzeichnis

Literaturverzeichnis

A Ebenen einer Unternehmensarchitektur

B Beziehungen zwischen Geschäftsprozessen und Services

C Merkmale des Reiseunternehmens

Einführung

„ Anwendungslandschaften stehen immer im Spannungsfeld zwischen Business und IT 1.

Software-Architekten m ü ssen deshalb konkurrierende Anforderungen bei der Gestaltung von IT-Landschaften ber ü cksichtigen um eine bestm ögliche Unterst ützung des Gesch ä fts zu erzielen. “

(Zitat aus dem Buch von Gregor Engels et al., Quasar Enterprise, 1. Auflage, Seite 7, 2008[3].)

Mit dieser Einleitung stellt der Autor Gregor Engels heraus, vor welchen Herausforderun- gen Software-Architekten bei dem Entwurf von betrieblichen Anwendungslandschaften ste- hen. Anwendungslandschaften müssen heute so gestaltet werden, dass sie agil und effizient auf veränderte geschäftliche Anforderungen des Unternehmens reagieren können.2 Im Ge- gensatz dazu sind Anwendungslandschaften jedoch meist über mehrere Jahre gewachsen, komplex und bestehen aus heterogenen Systemen, deren Pflege sich oft an der Grenze der Beherrschbarkeit befindet.3 Angesichts dieser Entwicklung fragen sich viele IT-Architekten wie sie die Kluft zwischen Business und IT überwinden und ihre IT-Architektur effizienter an die Geschäftsarchitektur anpassen können.

Nach Meinung von Fachexperten gibt das Architekturkonzept service-orientierte Architek- turen, kurz SOA, eine Antworten auf diese Fragen.4 SOA ist ein Architekturparadigma5, das die Geschäftsarchitektur eines Unternehmens als Ausgangsbasis für die Gestaltung einer Anwendungslandschaft verwendet. Dadurch sollen verteilte Systemlandschaften ska- lierbar und flexibel bleiben sowie Geschäft und IT wieder enger zusammenbringen.6

Es stellt sich jedoch die Frage, wie man service-orientierte Architekturen entwirft und diese erfolgreich in Unternehmen einführt?

Um diese Frage zu beantworten werden im Rahmen dieser Arbeit im Kapitel 2 zuerst die Begriffe Architekturentwurf, Softwarearchitektur und Unternehmensarchitektur definiert, bevor ab Abschnitt 2.2 auf service-orientierte Architekturen selbst eingegangen wird. Im Abschnitt 3.1 wird die Rolle des SOA-Konzepts im Unternehmen eingeordnet, um ab Abschnitt 3.2 auf den Entwurf und die Einführung service-orientierter Architekturen im Unternehmen näher einzugehen. Anschließend werden im Abschnitt 3.4 mögliche Auswirkungen von IT-Trends auf das SOA-Konzept thematisiert.

Im Kapitel 4 werden Erfolgsfaktoren sowie mögliche Herausforderung bei der Einführung service-orientierte Architekturen in Unternehmen diskutiert. Zum Schluss werden die wichtigsten Erkenntnisse zusammengefasst und ein kurzer Ausblick gegeben.

Kapitel 2 Grundlagen

2.1 Grundlagen der Unternehmensarchitektur

2.1.1 Architekturentwurf

Der Architekturentwurf ist nach Glinz der Prozess des Definierens von Architektur, Komponenten, Schnittstellen und anderen Charakteristika eines Software-Systems oder einer Software-Komponente.1

2.1.2 Softwarearchitektur

Die Softwarearchitektur ist das erste Ergebnis innerhalb des Architekturentwurfs. Sie ist nach dem Autor Andresen die Identifikation, Spezifizierung und Dokumentation sowohl der statischen Struktur als auch der dynamischen Interaktion eines Software-Systems, das sich aus Komponenten und Systemen zusammensetzt.2 Die Abbildung 2.1 gibt einen Überblick über die zeitliche Entwicklung der Softwarearchitektur-Paradigmen von 1960 bis 2005.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.1: Evolution der Architektur der Informationssysteme3

2.1.3 Unternehmensarchitektur

Definition

Die Unternehmensarchitektur beinhaltet alle fachlichen und technischen Architekturper- spektiven des Unternehmens. Sie stellt den Zusammenhang zwischen der Geschäfts- und IT-Architektur her und umfasst Prinzipien und Methoden um diese zu entwerfen und um- zusetzen. Nach Engels besteht die Unternehmensarchitektur aus folgenden Teilbereichen (siehe Abbildung 2.2):4

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.2: Teilbereiche der Unternehmensarchitektur5

- Geschäftsarchitektur: Die Gesch ä ftsarchitektur umfasst die Geschäftsstrategie, die Geschäftsdomänen und die Geschäftsprozesse eines Unternehmens. Die Gesch ä fts- strategie legt unter anderem fest, welche Produkte auf welchen Märkten angeboten werden sollen. Gesch ä ftsdom ä nen sind Unternehmenssegmente, die beispielsweise nach Kunden- oder Produktgruppen untergliedert werden. Gesch ä ftsprozesse beste- hen hingegen aus einer Folge von Arbeitsschritten, die zur Erreichung eines betriebs- wirtschaftlichen Ergebnisses dienen.6

- IT-Architektur: Die IT-Architektur oder Architektur der Anwendungslandschaft beinhaltet alle betrieblichen Anwendungssysteme eines Unternehmens und deren Beziehungen untereinander. Sie lässt sich in die Teilbereiche Informationssystemar- chitektur, kurz IS-Architektur, und Architektur der technischen Infrastruktur, kurz TI-Architektur aufgliedern (siehe Abbildung A.1). Die IS-Architektur beschreibt die Strukturierung der Anwendungslandschaft aus fachlicher Perspektive, während die TI-Architektur sich mit den technischen Plattformen und den Systemsoftwarekom- ponenten auseinandersetzt.7

2.2 Grundlagen service-orientierter Architekturen

Die Begriffe Service und service-orientierte Architektur bilden die Basis dieser Ausarbeitung. Aus diesem Grund werden die beiden Fachbegriffe in diesem Abschnitt erläutert, bevor im nachfolgenden Kapitel 3 auf den Entwurf und die Einführung service-orientierter Architekturen im Unternehmen selbst eingegangen wird.

2.2.1 Service

Im SOA-Kontext lässt sich ein Service nach Josuttis folgendermaßen definieren:

„ Ein Service stellt eine Leistung dar, die ein Servicegeber einem potentiellen Serviceneh- mer anbietet. Ein Service ist demnach die IT-Repr ä sentation einer in sich abgeschlossenen fachlichen Funktionalit ä t, die durch eine wohldefinierte Schnittstelle beschrieben wird. “8

Ein Service sollte dabei folgende wichtige Designprinzipien erfüllen:9

- Abgeschlossenheit: Ein Dienst sollte in sich abgeschlossen und autark sein.
- Grobgranularität: Dienste sind Abstraktionen, die Implementierungsdetails vor dem Nutzer verbergen und immer einen direkten Geschäftsbezug aufweisen müssen.
- Wiederverwendbarkeit: Die Wiederverwendbarkeit eines Dienstes sollte ange- strebt werden, sodass dieser nur einmal implementiert und von anderen Diensten verwendet werden kann.
- Komponierbarkeit: Um einen Geschäftsprozess abzubilden sollen mehrere Dienste zu einem höheren Dienst aggregiert werden können und umgekehrt kann ein Dienst in mehreren Geschäftsprozessen verwendet werden.

Weitere Anforderungen an Services sind unter Josuttis, (SOA in der Praxis, 2008), ab Seite 33 zu finden.

2.2.2 Service-orientierte Architektur

Definition

Eine service-orientierte Architektur ist nach Josuttis ein Architekturparadigma für den Umgang mit Geschäftsprozessen, die über eine große Anwendungslandschaft verteilt wer- den.10 Dabei werden vielfältige Methoden und Applikationen] als wiederverwendbare und offen zugreifbare Services repräsentiert und eine plattform- und sprachunabhängige Nut- zung ermöglicht.11

Merkmale und Funktionsweisen einer SOA

Die grundlegenden Merkmale und Funktionsweisen einer service-orientierten Architektur sind nach Melzer (siehe Abbildung 2.3):12

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.3: Merkmale einer SOA13

- Verteiltheit und lose Kopplung: Verteiltheit und lose Kopplung sind Konzep- te zur Reduzierung von Abhängigkeiten zwischen Systemen. Innerhalb von service- orientierten Architekturen können Geschäftsprozesse mithilfe lose gekoppelten Diens- ten, die über verschiedene Systeme verteilt sind, durchgeführt werden.

- Verzeichnisdienst und dynamische Bindung: Services werden von Anwendern oder anderen Services zur Laufzeit gesucht, gefunden und eingebunden. Damit ein entsprechender Service gefunden werden kann, muss dieser an einem Ver- zeichnisdienst angemeldet werden. Der Verzeichnisdienst gestattet die Suche nach einer Dienstleistung, die von der jeweiligen Anwendung gerade benötigt wird.14

- Prozessorientierung: Einzelne Dienste werden innerhalb einer SOA zu einem neu- en Dienst zusammengestellt, sodass sie die einzelnen Arbeitsschritte eines Work- flows15 abbilden. Ein komponierter Dienst ist flexibel gegenüber Veränderungen seines Ablaufs. Ändert sich der Geschäftsprozess, muss der entsprechende Dienst lediglich neu zusammengestellt werden.16

- Standards und Einfachheit: Damit eine Kommunikation zwischen Servicenehmer und Serviceanbieter stattfinden kann, müssen beide Parteien ihre Schnittstellen auf Basis offener Standards festlegen. Die dadurch resultierende Trennung von Schnitt- stelle und Implementierung führt zu einer relativ einfachen Verwendung von Services und ermöglicht eine breite Akzeptanz der Architektur.

- Sicherheit: Neben Standards und Einfachheit ist Sicherheit die dritte tragende Säu- le einer service-orientierten Architektur. Zur Akzeptanzsicherung müssen Services Sicherheitsaspekte wie Vertraulichkeit, Berechtigung, Konsistenz, sowie Glaubwür- digkeit und Verbindlichkeit erfüllen.17

Rollen und Aktionen in einer SOA

Die Abbildung 2.4 veranschaulicht die Rollen und Aktionen innerhalb einer service-orientierten Architektur:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.4: Rollen und Aktionen innerhalb einer SOA18

1. Serviceanbieter: Der Serviceanbieter stellt einen Service zur Verfügung und ver- öffentlicht diesen zur Nutzung bei einem Serviceverzeichnis.
2. Serviceverzeichnis: Das Serviceverzeichnis besitzt einen Servicekatalog, indem alle an ihm angemeldeten Serviceanbieter aufgelistet sind.
3. Servicenehmer: Der Servicenehmer durchsucht das Serviceverzeichnis zum Auf- finden eines entsprechenden Serviceanbieters. Anschließend versucht sich der Ser- vicenehmer am Serviceanbieter zu binden und dessen Dienstleistung in Anspruch zu nehmen.

Orchestrierung versus Choreographie

Eine wichtige Eigenschaft des SOA-Konzepts ist die Fähigkeit bestehende Services zu neuen Services zusammenzufassen. Diesen Prozess nennt man Komposition. Neue Geschäftsprozesse können somit aus bestehenden Services komponiert werden. Nach Masak gibt es zwei Möglichkeiten vorhandene Services zu nutzen und diese zu einem neuen Service zusammenzustellen (siehe Abbildung 2.5):19

- Orchestrierung: Bei der Orchestrierung wird ein neuer Service mithilfe eines Koor- dinators namens Orchestrator geschaffen. Der Orchestrator nimmt externe Aufrufe entgegen und delegiert diese zu den vorhandenen Services. Für die Orchestrierung können beispielsweise die Protokolle BPML20 und BPEL21 verwendet werden.
- Choreographie: Die Choreographie benötigt keinen zentralen Koordinator. Der neue Gesamtservice beruht aus einer Reihe von Interaktionen zwischen vorhande- nen (Sub)-Services. Für die Choreographie wird bei Webservices zum Beispiel das WS-CDL22 -Protokoll eingesetzt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.5: Orchestrierung versus Choreographie23

[...]


1 Information Technology (IT)

2 Vgl. Reussner, Hasselbring, (Handbuch der Software-Architektur, 2008), S. 123

3 Vgl. Reussner, Hasselbring, (Handbuch der Software-Architektur, 2008), S. 124

4 Vgl. Josuttis, (SOA in der Praxis, 2008), S. 2

5 Ein Paradigma ist ein in der Wissenschaft weitgehend anerkannte Modellvorstellung von einem bestimm- ten Gegenstand. (Vgl. Humboldt-Universität Berlin, http://www.ib.hu-berlin.de/~wumsta/infopub/ semiothes/lexicon/default/dq8.html, abgerufen am 03.07.2010)

6 Vgl. Reussner, Hasselbring, (Handbuch der Software-Architektur, 2008), S. 156

1 Vgl. Grinz, (Architekturentwurf - Einführung und Überblick, 2003), S. 2

2 Vgl. Andresen, (Komponentenbasierte Softwareentwicklung, 2004), S. 45

3 Abb. Masak, (SOA?: Serviceorientierung in Business und Software, 2009), S. 8

4 Vgl. Engels et al., (Quasar Enterprise, 2008), S. 78-79

5 Abb. Engels et. al, (Quasar Enterprise, 2008), S. 78

6 Vgl. Reussner, Hasselbring, (Handbuch der Software-Architektur, 2008), S. 125

7 Vgl. Engels et. al, (Quasar Enterprise, 2008), S. 78

8 Vgl. Josuttis, (SOA in der Praxis, 2008), S. 45

9 Vgl. Reussner, Hasselbring, (Handbuch der Software-Architektur, 2008), S. 131

10 Vgl. Josuttis, (SOA in der Praxis, 2008), S. 31

11 Vgl. Melzer, (Service-orientierte Architekturen mit Web Services, 2010), S. 13

12 Vgl. Melzer, (Service-orientierte Architekturen mit Web Services, 2010), ab S. 11

13 Abb. Melzer, (Service-orientierte Architekturen mit Web Services, 2010), ab S. 13

14 Vgl. Melzer, (Service-orientierte Architekturen mit Web Services, 2010), S. 11

15 Ein Workflow ist der IT-gestützte Teil eines Geschäftsprozesses. (Vgl. Josuttis, (SOA in der Praxis, 2008), S. 104.)

16 Vgl. Melzer, (Service-orientierte Architekturen mit Web Services, 2010), ab S. 239

17 Vgl. Melzer, (Service-orientierte Architekturen mit Web Services, 2010), ab S. 206

18 Abb. Melzer, (Service-orientierte Architekturen mit Web Services, 2010), ab S. 14

19 Vgl. Masak, (SOA?: Serviceorientierung in Business und Software, 2009), S. 104-108

20 Business Process Modeling Language (BPML)

21 Business Process Execution Language (BPEL)

22 Web Services Choreography Description Language (WS-CDL)

23 Abb. Masak, (SOA?: Serviceorientierung in Business und Software, 2009), S. 106

Details

Seiten
33
Jahr
2010
ISBN (eBook)
9783640698622
ISBN (Buch)
9783640698790
Dateigröße
2.1 MB
Sprache
Deutsch
Katalognummer
v156459
Institution / Hochschule
AKAD University, ehem. AKAD Fachhochschule Stuttgart – AKAD Fachhochschule Stuttgart
Note
1,0
Schlagworte
service-orientierte Architekturen serviceorientierter Architekturen SOA Service-orientierung Serviceorientierung Einführung Entwurf Architekturentwurf Wiederverwendbarkeit Webservice Service Servicemerkmale Einführung einer SOA Entwurf einer SOA SOA-Landschaft Unternehmen Unterehmenslandschaft Anwendungslandschaft Quasar Enterprise SOA-Referenzarchitektur SOA-Maturity Model BPMN Architekturkonzept Architekturparadigma

Autor

Teilen

Zurück

Titel: Entwurf und Einführung service-orientierter Architekturen im Unternehmen