entwurf von anwendungssystemen und entwurf von enterprise services

� WIRTSCHAFTSINFORMATIK 1 | 2008

WI – schWerpunktaufsatz

1 Einleitung

Im Laufe der Zeit haben sich insbesonde-re in Großunternehmen komplexe An-wendungssystemlandschaften entwickelt. Ihre nach wie vor steigende Komplexität behindert das IT/Business-Alignment, da bei Änderungen fachlicher Anforde-rungen oder bei Einführung von IT-Inno-vationen eine Vielzahl von Strukturen auf der jeweils „anderen Seite“ nachgeführt werden müssten – was aber nicht immer vollständig gelingt. Unabhängig davon, ob geänderte fachliche Artefakte (z. B. Pro-zesse oder Organisationsstruktur) oder geänderte technische Artefakte (z. B. Soft-ware- oder Infrastrukturkomponenten) Auslöser des Veränderungsprozesses sind,

muss immer mindestens die Anwen-dungssystemlandschaft angepasst wer-den, um die Konsistenz beider Perspekti-ven wiederherzustellen. Serviceorientierte Architekturen (SOA) zielen darauf ab, dieses Problem zu lösen bzw. zumindest in seiner Bedeutung zu reduzieren: Es wird reklamiert, dass durch eine Kapselung der IT-Funktionalitäten in Form lose gekop-pelter Komponenten viele geänderte fach-liche Anforderungen durch Re-Komposi-tion abgebildet werden können, anstatt die IT-Strukturen anpassen zu müssen (z. B. Krafzig et al. 2005, S. 6, S. 239 ff.). Die An-wendungssystemlandschaft müsste des-halb nicht bei jeder Änderung fachlicher Anforderungen angepasst werden.

Als Konsequenz der Ursprünge der SOA-Diskussion auf Implementierungse-bene sind entsprechende Methodikbeiträ-ge zwar mittlerweile zahlreich, aber meist auf technische Aspekte wie Protokolle, Messaging, Service Deployment innerhalb technischer Rahmen wie J2EE, XML oder aspektorientierter Programmierung fo-kussiert (Brown und Carpenter 2004). Ei-nige Beiträge konzentrierten sich auf un-ternehmensübergreifende Integration, ty-pischerweise in B2B-e-Business-Szenarien (z. B. Tenenbaum und Khare 2005). Nur wenige Beiträge gehen jedoch über den technischen Fokus hinaus und interpretie-ren Serviceorientierung als Hebel zur Neugestaltung komplexer Anwendungs-systemlandschaften. Die Ziele der Service-orientierung aus der Perspektive eines un-ternehmensweiten Gestaltungsansatzes sowie die Konflikte zwischen SOA-Zielen

(wie z. B. Agilität) und traditionellen Zie-len der Informationssystemgestaltung (wie z. B. Wiederverwendung) sind bis-lang kaum explizit diskutiert worden.

Ähnlich wie bei der Diskussion des En-terprise-Application-Integration-An-satzes (EAI) wird die Integrationsdiskus-sion bei Services häufig auf die Schnitt-stellenkomplexität reduziert. Fallstudien zur Anwendungssystem-Integration zei-gen, dass lose Kopplung tatsächlich die Schnittstellenkomplexität in komplexen Anwendungssystem-Architekturen redu-ziert (z. B. Hagen 2003). Jedoch führt dies nicht zwingend auch zu einer Reduktion der Abhängigkeiten zwischen den Appli-kationen. Die so gemessene Komplexität kann sogar steigen (z. B. Krafzig et al. 2005, S. 346): Neuentwickelte Services sind üblicherweise feingranularer ge-schnitten – d. h. hinsichtlich ihres Funk-tionsumfangs kleiner als traditionelle An-wendungssysteme – und ermöglichen es dadurch, durch flexible Kopplung dieser Services größere Anwendungssysteme zu erstellen. Dies kann aber in einer größeren Anzahl sowohl von Anwendungssyste-men wie auch von Schnittstellen und Ver-bindungen zwischen diesen resultieren.

Da sich Anforderungen der Fachbe-reiche meist schneller ändern, als es mög-lich ist, die Softwarekomponenten zeitnah anzupassen (Winter 2004), werden ver-schiedene Varianten der Softwarekompo-nenten erstellt, die parallel produktiv ge-nutzt werden. Wenn dabei neuentwickel-te Services auch auf ältere Servicevarian-ten zugreifen können, steigt die Komple-

Entwurf von Anwendungssystemen und Entwurf von Enterprise Services – Ähnlichkeiten und Unterschiede Die Entwurfsprinzipien konventioneller Anwendungssysteme lassen sich auch auf Enterprise Services anwenden. In den untersuchten Fällen bestätigt sich dies für Querschnitts-Enterprise-Services (z. B. zum Produktdatenmanagement) und für kanalorientierte Enterprise Services (z. B. im weborientierten Customer-Self-Service). Für Prozess-Enterprise-Services finden sich nur eingeschränkt Belege, da die ent-sprechenden Services funktional deutlich kleiner geschnitten sind als traditionelle Anwendungssysteme.

DOI 10.1007/s11576-007-0015-8

DieAutoren

Dr.JoachimSchelpProf.Dr.RobertWinter Universität St. GallenInstitut für WirtschaftsinformatikMüller-Friedberg-Strasse 89000 St. GallenSchweiz{joachim.schelp | robert.winter}@unisg.ch Eingereicht am 2007-05-02, nach ei-ner Überarbeitung angenommen am 2007-10-04 durch die Herausgeber des Schwerpunktthemas.

WIRTSCHAFTSINFORMATIK 1 | 2008 �


xität der Abhängigkeitsbeziehungen schneller, als dies in der traditionellen Softwareentwicklung der Fall war. Ser-viceorientierung kann somit zwar dazu beitragen, die Schnittstellenkomplexität zu verringern; gleichzeitig kann Service-orientierung aber gemessen an anderen Komplexitätsmaßen auch zu einer Ver-schlechterung führen.

Die Praxis versucht den aus unter-schiedlichen Änderungsrhythmen resul-tierenden Abstimmungsproblemen zwi-schen Fach- und IT-Seite dadurch zu be-gegnen, dass eine zusätzliche Abstrakti-onsschicht eingeführt wird. Bekannte Bei-spiele dafür finden sich bei Unternehmen wie der Deutschen Post (Herr et al. 2004) oder der Credit Suisse (Hagen 2003) wie auch bei SAP mit ihrer Enterprise Service Oriented Architecture (ESOA) (Heutschi et al. 2006). Gleichwohl scheint es Indika-toren dafür zu geben, dass die zuvor be-schriebenen Probleme mit der Einfüh-rung einer solchen Abstraktionsschicht alleine nicht gelöst werden können. Eine Entwurfsmethode für Services ist erfor-

derlich, die auf einem konsistenten Ver-ständnis der Unternehmensarchitektur aufbaut und die verschiedenen Ände-rungsrhythmen auf den verschiedenen Abstraktionsebenen angemessen berück-sichtigt. Als Beitrag zu einer solchen Me-thode werden in dieser Untersuchung der Entwurf von Services und der Entwurf konventioneller Anwendungssysteme mit-einander verglichen. Damit soll geprüft werden, ob die traditionellen Entwurfs-prinzipien für Anwendungssysteme ana-log auch für den Entwurf von Services gültig sind oder ob Services völlig anderen Entwurfsprinzipien folgen sollen.

Nach dieser Einleitung wird ein Unter-nehmensarchitektur-Ansatz präsentiert, in dem zwischen Softwareservices und Enterprise Services unterschieden wird. Der Schwerpunkt der Untersuchung liegt auf den Enterprise Services: Dies ist von besonderer Bedeutung für die Abstim-mung zwischen Fach- und IT-Seite (IT/Business-Alignment), da allein Enterprise Services zur Entkopplung der fachlichen und der technischen Architekturebenen

beitragen. Um die Forschungsfrage zu be-antworten, wie Enterprise Services zu ent-werfen sind, wird zunächst in Abschnitt 3 die traditionelle Gestaltung von Anwen-dungssystemen analysiert. Darauf basie-rend werden in Abschnitt 4 Hypothesen abgeleitet, wie Services analog zu entwer-fen wären. In Abschnitt 5 werden vier Fallstudien präsentiert, welche die Hypo-thesen zur Servicegestaltung weitgehend stützen. Schließlich werden in Abschnitt 6 die Ergebnisse dieser explorativen Un-tersuchung zusammengefasst und mög-liche Gründe für die gefundenen Ähnlich-keiten bzw. Unterschiede zwischen den Gestaltungsergebnissen diskutiert. Dar-auf aufbauend wird zudem der weitere Forschungsbedarf aufgezeigt.

2 UnternehmensarchitekturundEnterpriseServices

Der ANSI/IEEE-Standard 1471-2000 de-finiert Architektur als “fundamental or-ganization of a system, embodied in its

Bild 1 BSP-Matrix und STP-Matrix

UnternehmensplanungOrganisationsanalyseReview und KontrolleFinanzplanungKapitalbeschaffungForschungVorhersageDesign und EntwicklungProduktspezifikationEinkaufWarenannahmeBestandskontrolleArbeitsablaufplanungTerminierungKapazitätsauslastungMaterialbedarfsplanungFertigungGebietsmanagementVerkaufVerkaufsadministrationAuftragsbearbeitungVersandBuchhaltungKostenplanungBudgetrechnungPersonalplanungAnwerbung/FörderungEntlohnung

Funktions-cluster

Datenklasse

Plan

ung

Fina

nzm

ittel

Prod

ukte

Teile

kata

log

Stüc

klis

ten

Lief

eran

ten

Kost

en

Rohm

ater

ialb

estä

nde

Fert

igfa

brik

atbe

stän

de

Besc

häft

ige

Auf

träg

eVe

rkau

fsge

biet

e

Arb

eits

plän

e

Prod

uktio

nsvo

lum

enA

nlag

en

Offe

ne B

edar

feM

asch

inen

bela

stun

gen

Kund

en

Man

agem

ent

Bedarf

Produktion

Ver-trieb

-

Personal

Verwaltung

Schadenbearbeitung

Vertragsverwaltung

Inkasso

Ertragscontrolling

...

...

...

...

...

Funktions-cluster

Geschäftsbereich

Sach

vers

. Ein

zelk

unde

n

Einz

el-L

eben

sver

s. In

l.

Gru

ppen

-Leb

ensv

. Inl

.

Einz

el-L

eben

sv. A

usl.

Gru

ppen

-Leb

ensv

. Aus

l.

Unf

allv

ersi

cher

ung

Inl.

Unf

allv

ers.

Aus

land

...

App

l. A

Appl.B

8 WIRTSCHAFTSINFORMATIK 1 | 2008


components, their relationships to each other and the environment, and the prin-ciples governing its design and evolution” (IEEE 2000). Unternehmensarchitektur (enterprise architecture, EA) kann in An-lehnung daran verstanden werden als (1) die grundlegende Strukturierung einer Behörde oder eines Unternehmens, ent-weder allein oder zusammen mit Ge-schäftspartnern, Lieferanten und/oder Kunden (erweitertes Verständnis des Un-ternehmens), oder eines Teils davon (z. B. einer Sparte oder einer Abteilung) sowie (2) die Prinzipien, denen die Gestaltung und Weiterentwicklung folgt (Opengroup 2003).

Während EA-Modelle die Ist- oder Soll-Architektur eines Unternehmens oder ei-ner Behörde repräsentieren, enthält ein EA-Framework (Opengroup 2003):

ein oder mehrere Metamodelle zur Be-schreibung der EA ein oder mehrere Methoden für Gestal-tung und Weiterentwicklung der EA ein Vokabular der EA und ggf. Referenzmodelle, die als Vorlage oder Bauplan für die EA-Gestaltung und Weiterentwicklung verwendet werden können.

Die einzelnen Bestandteile eines EA- Frameworks sollten dabei auf unterschied-liche Unternehmen und Behörden glei-chermaßen anwendbar sein.

■

■

■■

Die obige Architekturdefinition ver-steht Komponenten als „grundlegend“. Aufgrund der großen Bandbreite rele-vanter Komponententypen kann eine Unternehmensarchitektur dennoch aus einer großen Anzahl an Artefakten be-stehen. Folglich werden in vielen EA-Frameworks unterschiedliche Architek-turebenen und -sichten unterschieden, um die Anzahl der Artefakte pro Modell zu beschränken (Schekkerman 2004; Tang et al. 2004). Wenn unterschiedliche EA-Ebenen und Sichten unterschieden werden, müssen die zugehörigen Prin-zipien für Gestaltung und Weiterent-wicklung auch die Konsistenz der Mo-delle und ihre Integrationsfähigkeit be-rücksichtigen.

Die Theorie hierarchischer Systeme (Mesarovic et al. 1970) bietet sich als kon-zeptionelle Grundlage für die konsistente Gestaltung von EA-Modellen an, die meh-rere Ebenen und Sichten umfassen. Da das Gestaltungsprinzip „IT follows business“ mittlerweile als allgemein akzeptiert an-genommen werden darf (Durst und Daum 2007, S. 24 f.; Luftman und McLean 2004, S. 97 ff.), bildet die strategische Positionie-rung des Unternehmens (bzw. der jewei-ligen Betrachtungseinheit) den Ausgangs-punkt (sog. „Was“-Fragen). Aus dieser lei-tet sich dann die Aufbau- und Ablaufor-ganisation ab (sog. „Wie“-Fragen). Die Or-

ganisationsgestaltung aus fachlicher Sicht bildet wiederum die Grundlage für eine entsprechende Gestaltung des Informati-onssystems (sog. „Womit“-Fragen) (Braun und Winter 2005). Als Konsequenz unter-scheiden die meisten EA-Frameworks die folgenden EA-Ebenen (Winter und Fi-scher 2006):

Geschäftsarchitektur: Die Geschäftsar-chitektur repräsentiert die grundsätz-liche Strukturierung des Unternehmens (oder der Behörde) aus Management-perspektive. Typische Artefakte dieser EA-Ebene sind z. B. Geschäftsnetzwerke, Leistungsbeziehungen zu Kunden und Lieferanten sowie strategische Projekte (Hedman und Kalling 2003; Weill und Vitale 2001). Prinzipien für die Gestal-tung und Weiterentwicklung der Ge-schäftsarchitektur folgen z. B. der „mar-ket based view“ (Porter 2004) oder der „resource based view“ (Prahalad und Hamel 1990). Prozessarchitektur: Die Prozessarchitek-tur repräsentiert die grundsätzliche Strukturierung der Leistungsentwick-lung, -erstellung und -erbringung inner-halb der jeweiligen Betrachtungseinheit. Typische Artefakte dieser EA-Ebene sind bspw. Geschäftsprozesse, Organisations-einheiten und Informationsflüsse (Da-venport 1993). Die auf dieser EA-Ebene anzuwendenden Prinzipien für Gestal-tung und Weiterentwicklung reflektieren Effektivität (Sicherstellung der Erstellung der auf Strategieebene spezifizierten Leis-tungen) und Effizienz (Sicherstellung von Erreichen der auf Strategieebene fest-gelegten Ziele) (Österle 1995). Integrationsarchitektur: Die Integrati-onsarchitektur repräsentiert die grund-sätzliche Strukturierung des Informati-onssystems der jeweiligen Betrachtungs-einheit. Typische Artefakte dieser EA-Ebene sind Enterprise Services, Anwen-dungssysteme und Datenflüsse. Die zur Gestaltung und Weiterentwicklung die-ser Artefakte anzuwendenden Prin-zipien folgen Zielen wie Transparenz (z. B. zur Risikominimierung, Ross et al. 2006), Agilität (z. B. durch Serviceorien-tierung, Barry 2003), Kosteneffizienz (z. B. durch Schnittstellenreduktion, Lin-thicum 2000), Konsistenz (z. B. durch Analyse der Datenkopplungen, IBM 1984) und / oder Geschwindigkeit (z. B. durch Straight-Through-Processing, Kuhlin und Thielmann 2005). Softwarearchitektur: Die Softwarearchi-tektur repräsentiert die grundsätzliche

■

■

■

■

Bild 2 Dreidimensionales Modell der Anwendungssystemlandschaft (Winter 2003)

Leistung / Organisation

Funktionalität

Informations-objekt

A

B

C

WIRTSCHAFTSINFORMATIK 1 | 2008 �


Strukturierung der Software-Artefakte. Typische Artefakte dieser EA-Ebene sind Softwarekomponenten und Datenstruk-turen. Die angewandte Informatik hat zahlreiche Prinzipien für die Gestaltung und Weiterentwicklung dieser Artefakte hervorgebracht, auf die hier nicht näher eingegangen wird. IT-Architektur: Die IT-Architektur re-präsentiert die grundsätzliche Struktu-rierung der Hardware- und Netzwerkin-frastruktur sowie der verwendeten Ba-sistechnologien. Auch für diese EA-Ebe-ne existieren bewährte Repräsentations- und Gestaltungsansätze aus der ange-wandten Informatik, auf die hier nicht näher eingegangen wird.

Serviceorientierte Konstrukte können auf mindestens zwei der EA-Ebenen identifi-ziert werden: Auf der Ebene der Software-architektur können Softwarekomponen-ten, die unter Verwendung von Web Ser-vice Standards wie SOAP, UDDI und WSDL (Tsalgatidou und Pilioura 2002) implementiert wurden, als Software Ser-vices bezeichnet werden. Software Ser-vices können dabei aus weiteren Software Services zusammengesetzt sein.

Im Unterschied dazu sind die auf der Ebene der Integrationsarchitektur positio-nierten Enterprise Services (ESs) logische Repräsentationen von IT-Funktionalitäten, die in geeigneter Weise integriert und ge-kapselt sind. Die Integration und Kapse-lung von IT-Funktionalitäten erfolgt, um1. lose Kopplung zwischen ESs sicherzu-

stellen (d. h. eng gekoppelte Funktiona-lität wird nicht über verschiedene ESs verteilt) und um

2. durch Rekomposition einer Menge be-stehender ESs so viele Varianten eines Geschäftsprozesses wie möglich unter-stützen zu können.

Die erste Anforderung unterstreicht den (logischen) Komponentencharakter der ESs, wogegen die zweite darauf gerichtet ist, Flexibilität zu unterstützen. Da ESs die Verbindung zwischen fachlich orien-tierten Artefakten (IT-unterstützbare Ak-tivitäten/Geschäftsprozesse) und IT-Arte-fakten (Softwarekomponenten, die IT Funktionalität zur Verfügung stellen) dar-stellen, sind sie auf der EA-Integrations-ebene angesiedelt. Auch ESs können aus weiteren (elementaren) ESs zusammenge-setzt sein.

Elementare ESs können durch Soft-ware Services wie auch durch konventio-nell implementierte Softwarekomponen-ten implementiert werden. Aktivitäten

■

bzw. Teile eines Geschäftsprozesses kön-nen sowohl durch ESs wie auch durch konventionelle Anwendungssysteme un-terstützt werden.

Während beim Entwurf von Software-komponenten Implementierungsziele wie Wiederverwendung, Skalierbarkeit, Per-formanz etc. verfolgt werden, verfolgt der Entwurf sowohl von Anwendungssyste-men wie auch von ESs fachliche Ziele wie Transparenz, Vereinfachung, Flexibilität und / oder Agilität. Während die systema-tische Verfolgung von Implementierungs-zielen in Form von Entwurfsmethoden des Software-Engineering hohe Reife er-reicht hat (so wird z. B. der Anwendungs-systementwurf seit den 1980er Jahren sys-tematisch erforscht, IBM 1984), ist der Entwurf von ESs möglicherweise eine neue Herausforderung.

Daher konzentriert sich dieser Beitrag auf den Entwurf von ESs. Als mögliche Grundlage für den ES-Entwurf wird zu-nächst der aktuelle Stand des Anwen-dungssystementwurfs betrachtet.

3 EntwurfvonAnwendungssystemen

Basierend auf Vorläufern in den 1960er-Jahren wird die Business-Systems-Plan-ning-Methode von IBM (BSP: IBM 1984) seit den 1980er Jahren weltweit genutzt,

um datenorientiert IT-Funktionalitäten zu gruppieren und Anwendungssystem-kandidaten auf hohem Aggregationsni-veau zu identifizieren. Eine alternative Methode zum Entwurf von Anwendungs-systemen ist in der PROMET-Systems-and-Technology-Planning-Methode der IMG vorgeschlagen worden (STP: IMG 1999). Auch hier werden in einer zweidi-mensionalen Matrix Anwendungssystem-kanndidaten identifiziert; jedoch werden im Gegensatz zu BSP die Dimensionen Organisationseinheit und Funktionsgrup-pe betrachtet. Grundlage der Gruppie-rung ist nicht die Datenkopplung, sondern Ownership-Kopplung von IT-Funktiona-litäten. Bild 1 illustriert die Ähnlichkeit dieser beiden Ansätze.

Das CONTEXT-Anwendungssystem-Architekturmodell (Penzel 2004; Spitzer 2002) verwendet mit Produktgruppe (z. B. Zahlungsverkehr, Hypothekengeschäft, Finanzanlagengeschäft), generischer Pro-zessschritt (z. B. Beratung und Vertrieb, Auftragserfassung, Auftragsabwicklung) und Infrastruktur (z. B. Applikationen, Middleware, Hardware) drei Dimensi-onen. Wählt man einen Wert in einer Di-mension, entstehen zweidimensionale Schnitte, die ein Geschäftsprozess- (für ein ausgewähltes Produkt), ein Plattform- (für einen ausgewählten Prozessschritt) oder ein Infrastrukturmodell (für eine ausgewählte Plattform) darstellen.

Bild 3 Idealisierte, generische Anwendungssystemlandschaft (Winter 2003)

Produktdatenmanagement

Partnermanagement

Funktionalität

Leistung /Organisation

Informationsobjekt

Hypotheken

Darlehen

Einlagen… … …

...

Autorisierung

WWWPortal

SB-Terminal

Callcenter

AnalytischeApplikationen



Während die Identifikation der Ge-schäftsapplikationen bei BSP an der Da-tennutzung und bei STP an der fachlich-funktionalen Zuständigkeit (Ownership) orientiert ist, erfolgt dies somit bei CON-TEXT in komplexerer Form und bezieht auch „weiche“ Faktoren mit ein.

Winter (2003) schlägt einen Ansatz vor, welcher Elemente aus BSP, STP und dem CONTEXT-Ansatz kombiniert. Er argu-mentiert, dass sowohl Datennutzung wie fachlich-funktionale Zuständigkeiten wichtig für die Identifikation von IT-Funktionalitätsgruppen sind: Die Orien-tierung an der Datenverwendung stellt si-cher, dass die Integrationskomplexität be-rücksichtigt wird. Die Orientierung an der fachlich-funktionalen Zuständigkeit stellt die notwendige Konsistenz mit der Orga-nisationsstruktur sicher. In Analogie zum CONTEXT-Ansatz kombiniert er die je-weilige Matrix von BSP und STP zu einem dreidimensionalen Modell, das aus fol-genden Dimensionen besteht:

Leistung / Organisation: Diese Dimensi-on orientiert sich an Geschäftseinheiten, Produktgruppen und / oder Marktseg-menten, die Anhaltspunkte zur Integra-tion ausgewählter IT-Funktionalitäten bieten. Wenn sich Anwendungssysteme an Leistungen oder Organisationsein-heiten orientieren, erfolgt die Integrati-on über Funktionen und Informations-objekte hinweg. Funktionalität: Die Dimension orientiert sich an mehrfachverwendbaren Funkti-onalitätsclustern. Wenn sich Anwen-dungssysteme an Funktionalitätsclus-tern orientierten, erfolgt die Integration über Organisationseinheiten / Leistun-gen und Informationsobjekte hinweg. Informationsobjekt: Diese Dimension orientiert sich an zentralen, komplexen Informationsobjekten. Wenn sich An-wendungssysteme an Informationsob-jekten orientieren, erfolgt die Integrati-on über Funktionen und Organisations-einheiten / Leistungen hinweg.

Das resultierende dreidimensionale Mo-dell wird in Bild 2 illustriert. In diesem Modell wird ein Anwendungssystem bei aggregierter Betrachtung als Quader dar-gestellt, dessen Ausmaß und Position durch die Bezüge der integrierten Funk-tionalitäten hinsichtlich der drei Dimen-sionen Leistung / Organisation, Funktio-nalität und Informationsobjekt bestimmt wird. In Bild 2 repräsentiert A ein ty-pisches Anwendungssystem, das IT-Funktionalitäten primär entlang Pro-

■

■

■

duktgruppen und / oder Organisations-einheiten integriert (z. B. Hypothekarge-schäft-Abwicklung); B repräsentiert ein typisches Anwendungssystem, das IT-Funktionalitäten und Informationsob-jekte unterschiedlicher Organisationsein-heiten bzw. Leistungsbereiche integriert (z. B. Kundendatenmanagement); C re-präsentiert schließlich ein typisches An-wendungssystem, das ein Cluster von IT-Funktionalitäten für mehrere Produkt-gruppen / Organisationseinheiten und Informationsobjekte verfügbar macht (z. B. Vertragsmanagement, Callcenter- oder E-Commerce).

Anwendungssysteme werden in der Praxis nicht immer entsprechend einer streng definierten Architektur entwickelt, d. h. ihr Entwurf folgt nicht immer kon-sequent einer definierten Menge von Ent-wurfsregeln, mit denen Überschnei-dungen wie auch Lücken vermieden wer-den und durch die ausschließlich eine einzige Integrationsrichtung befolgt wird. Über viele Jahre hat zunächst die Integra-tion entlang von Organisationseinheiten und / oder Produktgruppen dominiert und zu Anwendungssystemen des Typs A geführt. Mit der steigenden Bedeutung von Datenbanken und Management-In-formationssystemen sind später Anwen-dungssysteme häufig entlang von Infor-mationsobjekten integriert worden (Typ B). In jüngerer Zeit haben die steigende Zahl der Vertriebs- und Zugriffskanäle sowie der Wunsch nach konsistenter Ab-wicklung über alle Kanäle hinweg zur Entwicklung von Anwendungssystemen geführt, die entlang von Funktionalitäten integriert sind (Typ C). In der Praxis wer-den Anwendungssysteme des Typs A auch als vertikale Applikationen, Anwen-dungssysteme des Typs B als datenzent-rierte Applikationen und Anwendungs-systeme des Typs C als horizontale Appli-kationen bezeichnet.

Da sowohl die Datenverwendung wie auch funktional-fachliche Zuständigkei-ten in diesem Modell berücksichtigt wer-den, können enge Kopplungen entlang mehrerer Dimension visualisiert und – bei Verwendung geeigneter Metriken – auch quantifiziert werden. Weiterhin kann ge-zeigt werden, dass bestimmte Entwurfs-entscheidungen Überdeckungen vermei-den, Lücken schließen oder eine effizi-entere Integration ermöglichen können (Winter 2003).

Eine systematische Gestaltung von Anwendungssystemen zielt darauf ab,

Überdeckungen oder Lücken zu vermei-den und damit Integrationskosten zu verringern. Entsprechend den drei Inte-grationsrichtungen sollten Kernleistungs-prozesse, Stammdatenmanagement / MIS und kanalbezogene oder sonst wie spezi-fische, wieder verwendbare IT-Funktio-nalitäten durch unterschiedliche Anwen-dungssysteme implementiert werden. Die idealisierte Anwendungssystemland-schaft, die aus der konsequenten Anwen-dung dieser Entwurfsregeln resultieren würde, wird generisch in Bild 3 wieder-gegeben.

Im Vergleich zu einer historisch ge-wachsenen Anwendungssystemlandschaft führt die konsequente Orientierung an den vorgestellten Entwurfsregeln für An-wendungssysteme zu verringerten Inte-grationskosten sowie zu einer leichteren Kontrolle der Redundanzen. Leider er-zeugt die Trennung in Produktverarbei-tung/Leistungserstellung, Stammdaten-management und Kanalfunktionen / ge-meinsam genutzte Funktionen einen mas-siven Schnittstellenbedarf, der zu höheren Integrationskosten zwischen den Applika-tionen führt. Deshalb sollten möglichst viele Anwendungssysteme m:n-fähig ver-netzbar sein, d. h. über Adapter an eine Data-Warehouse-Infrastruktur, eine EAI-Integrationsinfrastruktur und / oder eine Business-Collaboration-Infrastruktur an-geschlossen sein (Winter 2003).

4 HypothesenfürdenEntwurfvonEnterpriseServices

Die Analyse des Entwurfs konventioneller Anwendungssysteme führt zur Frage, ob für ESs grundsätzlich andere Entwurfsan-sätze erforderlich sind.

Zugunsten eines grundlegend anderen Ansatzes kann argumentiert werden, dass die Orchestrierung von ESs auf Basis einer einheitlichen Plattform (z. B. SAP Net-weaver) keine Ähnlichkeiten mit der tra-ditionellen Anwendungssystemnutzung aufweist, die IT-Funktionalitäten mit den durch sie unterstützten Geschäftsprozes-sen „verdrahtet“, d. h. entsprechende Zu-ordnungen in Form der Anwendungssys-temarchitektur festschreibt.

Zugunsten eines analogen Entwurfsan-satzes kann argumentiert werden, dass ein konsequenter Entwurf von Anwendungs-systemen stets zu einer Gruppierung eng gekoppelter IT-Funktionaltäten führt und auch eine n:m-Vernetzungsfähigkeit si-

WIRTSCHAFTSINFORMATIK 1 | 2008 11


cherstellen sollte. In diesem Sinne „gut“ gestaltete Anwendungssysteme mögen gröber geschnitten sein als ESs, sollten aber ähnliche Eigenschaften haben, wie sie in diesem Beitrag auch als für ESs wich-tig angenommen werden.

Anwendungssysteme wie auch ESs sind auf der gleichen EA-Ebene, der Integrati-onsebene, angesiedelt. Zwar können Transparenz, Konsistenz und Vereinfa-chung als gemeinsame sekundäre Gestal-tungsziele für Anwendungssysteme wie auch für ESs angesehen werden. Wäh-rend aber Anwendungssysteme primär entwickelt werden, um Integration si-cherzustellen, werden ESs primär entwi-ckelt, um Flexibilität / Agilität zu ge-währleisten.

Die folgende Betrachtung orientiert sich an der Hypothese, dass sich der Ent-wurf von ESs am Entwurf konventio-neller Anwendungssysteme orientiert. Als größter Unterschied wird zunächst unterstellt, dass für ESs Gestaltungsalter-nativen anders bewertet werden als für Anwendungssysteme: Während bei letz-teren größeres Gewicht auf eine klare In-tegration (insbesondere Datenintegrati-on) gelegt wird, steht bei ersteren das Ziel im Vordergrund, unterschiedliche Ge-schäftsprozessvarianten ohne Verände-rung der IT-Funktionalitäten unterstüt-zen zu können.

Um die Validität der Hypothese zu un-tersuchen, werden im folgenden Abschnitt die Enterprise Services von vier Großun-ternehmen untersucht. Wenn die Ent-wurfsregeln für Anwendungssysteme auch für den Entwurf von ESs gelten, müssten in den analysierten Unterneh-men folgende Typen von ESs identifizier-bar sein:1. Organisations- bzw. Produktgruppen-

orientierte ESs, d. h. ESs, die IT-Funk-

tionalitäten über viele Informationsob-jekte hinweg für eine bestimmte Orga-nisationseinheit oder eine bestimmte Produktgruppe kapseln,

2. Informationszentrierte ESs, d. h. ESs, die IT-Funktionalitäten und über viele Organisationseinheiten / Produkt-gruppen hinweg für ein bestimmtes In-formationsobjekt kapseln,

3. Funktionsorientierte ESs, d. h. ESs, die bestimmte IT-Funktionalitäten über viele Organisationseinheiten / Pro-duktgruppen und über viele Informa-tionsobjekte hinweg wiederverwend-bar kapseln.

5 VierFallstudienzurAnalysevonEnterpriseServices

Mit drei der vier vorgestellten Unterneh-men wurden im Laufe der vergangenen Jahre verschiedene Forschungsvorhaben durchgeführt, die einen tiefen Einblick in die Strukturierung der jeweiligen Anwen-dungssystem- und ES-Landschaften sowie der Prozesse zu ihrer Bewirtschaftung er-lauben. Mit dem vierten Unternehmen be-standen verschiedene Kontakte, die auch in der Erhebung detaillierter Fallstudien resultierten; jedoch wurden keine gemein-samen Projekte durchgeführt. Die hier zu-sammengefassten Daten wurden über ei-nen Zeitraum von 2001 bis 2007 aus ver-schiedenen Projekten und Einzelfallstu-dien konsolidiert.

Alle skizzierten Unternehmen verfügen über langjährige Erfahrung in der Anwen-dungssystemgestaltung. Hintergrundin-formationen zu den Unternehmen sowie zu den jeweiligen Integrationsprojekten werden in Tabelle 1 aufgeführt.

Im Folgenden werden die vier Fälle im Detail vorgestellt. Insbesondere wird auf

das jeweils zugrunde liegende Servicever-ständnis sowie den Entwurfsansatz für ESs eingegangen.

5.1 fallbeschreibungenUnternehmen A ist eines der größten Erstversicherungsunternehmen in der Schweiz. Bis 2002 wurden Anwendungs-systeme für die ebenfalls getrennten Be-reiche Lebens- und Nichtleben-Versiche-rung durch getrennte IT-Teileinheiten ent-wickelt. Entsprechend entstanden im Zeit-ablauf zwei getrennte Anwendungssys-temlandschaften, die nur in geringem Umfang über eine gemeinsame Datenhal-tung verfügten. Infolge einer Umorgani-sation in den Jahren 2002/2003 wurden die Entwicklungseinheiten für die Unter-stützung der Bereiche Lebens- und Nicht-leben-Versicherung zusammengelegt und eine Integration der zuvor getrennten An-wendungssystemlandschaften begonnen. Mehr als 300 Geschäftsapplikationen auf 20 Plattformen kennzeichneten die Ge-samtlandschaft, wobei viele Redundanzen vorhanden waren. Zur Umsetzung einer unternehmensweiten, möglichst redun-danzarmen Neugestaltung wurden 30 so genannte Geschäftsdomänen identifiziert, welche sich an den Hauptgeschäftsberei-chen des Unternehmens orientieren (z. B. Schaden, Vertragsmanagement, Vertrieb etc.). Diese Domänen wurden wiederum in Sub-Domänen unterteilt. ESs dienen als „logische Schnittstelle“ zu den Domänen und Sub-Domänen.

Das Verständnis der ESs in Unterneh-men A ist vergleichbar mit der Definition in Abschnitt 2: Es handelt sich um eine lo-gische Repräsentation gruppierter IT-Funktionalitäten, wobei jeder elementare ES auf eine konkrete Softwarekomponen-te verweist, durch die er implementiert wird. Jeder ES kann eine Beziehung zu ei-

Tab.1|Unternehmensdaten

Unternehmen A Unternehmen B Unternehmen C Unternehmen D

Branche Versicherung Bank Bank Logistik

Gewinn (2006) CHF 275.000.000 CHF11.327.000.000 € N/A € 1.916.000.000

Mitarbeiter (2006) 5.800 44.871 3.873 129.922

Filialen 270 215 10.768 5489

Kunden 1.630.000 2.450.000 (2007Q1) N/A 3.000.000

Konten/Verträge 3.100.000 N/A 84.000.000 ./.

Transaktionen N/A N/A 5.900.000.000 77.124.000.000

IntegrationshintergrundZusammenlegen der Leben- und Nicht-Leben-IT-Bereiche

Steigende Komplexität der Anwendungssystemlandschaft im Zeitablauf

Zusammenlegen von Rechenzentren, zunehmendes Outsourcing

Fusion vier großer Unternehmen seit 1998



ner oder mehreren Geschäftsfunktionen haben, die wiederum in den Geschäfts-prozessen enthalten sind. Jede Geschäfts-funktion kann ihrerseits Beziehungen zu einem oder mehreren ESs aufweisen. Die EA-Ebenen in Unternehmen A sind eben-falls mit dem in Abschnitt 2 beschrie-benen EA-Framework vergleichbar (Ta-belle 2).

Unternehmen B ist eine der größten Banken in der Schweiz. Da das Unterneh-men mehrere Fusionen durchgemacht hat, wurde eine SOA-Einführung mit der Komplexität der gewachsenen Anwen-dungssystemlandschaft begründet. Die AnwendungssystemLandschaften der fu-sionierten Teileinheiten stellten auf unter-schiedliche Geschäftsprozesse oder Märk-te ab, es fand niemals eine grundlegende Integration statt. 2002 bestand die An-wendungssystemlandschaft aus über 450 größeren Host- und Client-/Server-Appli-kationen. Um dem steigenden Integrati-onsbedarf und der damit verbundenen Komplexität begegnen zu können, wurde schon in 2001 ein SOA-Zielfoto entwi-ckelt. Der erste Schritt auf dem Weg dort-hin bestand in der Kapselung der beste-henden Anwendungssystemfunktionali-täten über ESs. Neue IT-Funktionalitäten wurden seitdem von Anfang an in Form von ESs abgebildet und entsprechend im-plementiert. Um einen reibungslosen Übergang zu einer SOA zu ermöglichen, wurde die bestehende Anwendungssys-temlandschaft auf Grundlage eines als „managed evolution“ bezeichneten Pro-zesses transformiert.

Die in Abschnitt 2 vorgestellten EA-Ar-chitekturebenen können auch bei Unter-nehmen B identifiziert werden (Tabelle 2). Die Integrationsarchitektur von B umfasst sowohl ESs wie auch Anwendungssyste-me, allerdings in getrennten Architektur-sichten. ESs werden definiert, um Pro-zesse und Softwarekomponenten vonein-ander zu entkoppeln. Sie werden durch Softwarekomponenten implementiert, die über einen Integrationsbus aufgerufen werden können. Eine Definition der An-wendungssystemdomänen erfolgt zur Komplexitätsverringerung. Innerhalb der Domänen wird eine enge Kopplung an-gestrebt, zwischen den Domänen eine lo-se Kopplung. Gekapselt durch ESs, ermög-licht diese Struktur den reibungslosen Austausch vorhandener Strukturen in der bestehenden Anwendungssystemland-schaft bei Kontrolle der Nebeneffekte auf Softwarekomponenten in anderen Domä-

nen. Die erhöhte Anzahl von ESs wie die steigende ES-Wiederverwendung führte zu messbaren Kostenvorteilen während der ab 2003 durchgeführten Programme zur Effizienzsteigerung.

Unternehmen C ist ein IT-Servicean-bieter für einen großen Bankenverbund in Deutschland. Es entstand 2001 durch den Zusammenschluss vormals unabhängiger IT- Serviceanbieter. Der jüngste Zusam-menschluss trug dazu bei, dass Unterneh-men C nun der größte IT-Serviceanbieter innerhalb des Verbundes ist. Da die fusio-nierten Unternehmen alle über eigene, evolutionär gewachsene Bank-Anwen-dungssysteme verfügten, von denen kei-nes eine dominante Stellung hinsichtlich Gestaltung oder Funktionalität hatte, wurde der Aufbau eines neuen Systems beschlossen. Die Entwicklung des neuen Banksystems startete 2002 und war Ende 2005 nahezu abgeschlossen. Das neue Sys-tem ist serviceorientiert gestaltet, um die implementierten Funktionalitäten flexi-bel, aber konsistent allen Banken des Ver-bunds anbieten zu können.

Das Serviceverständnis bei Unterneh-men C weicht etwas von der Definition in Abschnitt 2 ab und damit auch von den an-deren Fällen. Geschäftsprozesse wurden in „Geschäftsobjekte“ zerlegt, die ihrerseits aus „Geschäftskomponenten“ bestehen. Die „Geschäftskomponenten“ können als äquivalent zur ES-Definition aus Ab-schnitt 2 angesehen werden. Geschäfts-komponenten werden Datenobjekten zu-geordnet; jedoch ist der Zugriff auf die Da-tenobjekte über eine dynamisch generierte Schnittstelle gekapselt (dynamische Schnittstelle), die über einen Integrations-bus aufgerufen werden kann. Da die dyna-mische Schnittstelle den Zugriff auf die Daten kapselt, beinhalten die Geschäfts-komponenten lediglich die funktionale Logik. Diese ist nicht als eigenständige Softwarekomponente implementiert, son-dern als Regelsatz auf dem Integrations-bus. Entsprechend sind die Services bei C feingranular geschnitten. Mehr als 1500 Services wurden bislang definiert, die zu Applikationen kombiniert werden kön-nen, mit denen ganze Geschäftsprozesse unterstützt werden. Wiederverwendung wird gefördert, da die Banken des Ver-bunds große Ähnlichkeiten in ihren Ge-schäftsprozessen aufweisen.

Unternehmen D ist ein großer Logistik-anbieter in Deutschland. Seit 1998 wur-den die internationalen Aktivitäten des Unternehmens stark ausgeweitet und ver-

schiedene ausländische Logistikanbieter aufgekauft. Seit 2001/2002 wurden dabei die Informationssysteme von neun euro-päischen Partnerunternehmen in eine ge-meinsame Plattform integriert. Aufgrund der Vielzahl der Einzellösungen der inter-nationalen Töchter und der resultie-renden komplexen Anwendungssystem-landschaft entschied sich D in 1999 zu einem größeren Integrationsprojekt. Wenngleich die Initiative dazu von der IT ausging, wurde im Projekt von Anfang an eine klare Orientierung an der Fachseite sichtbar, und es wurde eine explizit ser-viceorientierte Zielvorstellung erarbeitet. Seit 2001 werden funktionale Redun-danzen reduziert, indem der externe Zu-griff auf die Funktionalität innerhalb der Anwendungssystemdomänen durch Ser-vices gekapselt wurde.

Das Serviceverständnis von Unterneh-men D entspricht dabei der Definition aus Abschnitt 2: ESs werden zur Entkopplung der Geschäftsprozesse von den Software-komponenten verwendet. Sie bilden den einzigen Zugang zu IT-Funktionalitäten und Daten einer Domäne. Die Anwen-dungssystemdomänen wurden entspre-chend der Geschäftsfunktionen innerhalb der Prozessarchitektur gebildet. Entspre-chend sind die gebildeten ESs grobgranu-lar. Zudem wird eine hohe zeitliche Stabi-lität der ESs angestrebt, um Wiederver-wendung zu erleichtern und zu fördern. Das zugrunde liegende Architekturver-ständnis ist weitgehend mit den Ebenen aus Abschnitt 2 vergleichbar (Tabelle 2).

Tabelle 2 fasst die Architekturebenen und Charakteristika der ESs in den Unter-nehmen A, B, C und D zusammen. Klam-mern deuten an, dass die Konzepte zwar generell vergleichbar sind, jedoch kleinere Unterschiede in den Definitionen oder in der Zuordnung zu einer Ebene vorgefun-den wurden.

In allen Unternehmen wird der Begriff “Service” in zweierlei Form interpretiert: Zum einen referenziert er auf eine logische Sicht (die dem ES der Integrationsebene in Abschnitt 2 ent-spricht), zum anderen auf eine Implementierungssicht (die dem Softwareservice der Software-ebene ent-spricht).

5.2 analyseDie Haupthypothese aus Abschnitt 4 be-sagt, dass der Entwurf von ESs analog zum Entwurf konventioneller Anwen-dungssysteme erfolgt. Um diese Hypothe-se zu stützen, müssen



H1: Organisations-/Produktzentrierte ESs gefunden wurden, welche IT-Funk-tionalitäten und Informationsobjekte für bestimmte Organisationseinheiten und / oder Produktgruppen repräsentie-ren, H2: Informationszentrierte ESs gefun-den wurden, welche Funktionen zum In-formationszugriff über Organisations-einheiten / Produktgruppen hinweg re-präsentieren, und H3: Funktionsorientierte ESs gefunden wurden, welche bestimmte Funktionen über Organisationseinheiten / Produkt-gruppen und auch Informationsobjekte hinweg zur konsistenten Wiederverwen-dung repräsentieren.

Im Folgenden werden nach (H1) gestalte-te ESs als Prozess-ESs (PESs) bezeichnet, nach (H2) gestaltete ESs als Querschnitts-ESs (cross sectional ESs, CSESs) bezeich-net und nach (H3) gestaltete ESs als kanal-orientierte ESs (channel oriented ESs, CO-ESs) bezeichnet.

COESs finden sich in den Unternehmen B und C. Unternehmen B kapselt die Funktionalitäten der abteilungsorien-tierten Applikationen über Services als ersten Schritt zu einer SOA. Dies wird in erster Linie durchgeführt, um die gleiche Funktionalität auf verschiedenen Kanälen anbieten zu können (z. B. um den aktu-ellen Kontostand sowohl über eine Desk-top-Applikation für Mitarbeiter, an einem Geldautomaten wie auch in einer Web-Applikation für den Kunden bereitstellen zu können). Im zweiten Schritt zu einer SOA werden die COESs mit neueren Tech-nologien neu implementiert und ersetzen so die gekapselten Altsysteme. In Unter-nehmen C ermöglicht die SOA den Zu-gang zur gleichen Grundfunktionalität

■

■

■

sowohl für Mitarbeiter wie für die Kun-den. Realisiert in Form von Webservices werden sie auf der Integrationsebene durch COESs repräsentiert.

CSESs können in allen Fällen identifi-ziert werden. Sämtliche Unternehmen be-treiben Data- Warehouse-Systeme, die ein typisches Beispiel für informations-zentrierte Applikationen sind, die Abtei-lungsgrenzen überschreiten. Zusätzlich finden sich bei A und B weitere CSESs. In beiden Fällen existieren spezielle Kun-denstammdatenservices, über die ein konsolidierter Zugang zu Kundendaten bereitgestellt wird. Im Fall von Unterneh-men A existiert ein zentrales Kundenda-tenverwaltungssystem. Der Zugriff auf dieses wird durch einen Stammdatenser-vice gekapselt, so dass alle anfragenden Services bzw. Applikationen nur noch über diesen Service auf die Kunden-stammdaten zugreifen können. Neue ge-schaffene Systeme können nur noch auf den Stammdatenservice zugreifen, ein di-rekter Zugriff auf das Kundenstammda-tensystem bzw. dessen Datenbank ist nicht mehr zulässig. Ähnlich den Kun-denstammdatenservices existieren bei al-len Unternehmen explizite Produkt-stammdatenservices. Auch wenn diese Services kaum über die elementaren Schreib-Lese-Funktionen (create, read, update, delete, CRUD) auf den Daten hin-ausgehen, werden sie über alle Funkti-onen, Organisationsstrukturen und Pro-dukte hinweg verwendet, die Zugang zu den Stammdaten benötigen.

PESs sind hingegen nur schwer zu identifizieren. Nach (H1) sind PESs über Funktionen und Informationsobjekte hinweg definiert. Sie bündeln die ge-samte Funktionalität sowie alle Informa-

tionsobjekte, die bezogen auf eine Abtei-lung oder ein Produkt benötigt werden. Selbst bei Unternehmen D, das grobgra-nulare ESs definiert, sind die ESs nicht ausreichend breit hinsichtlich Funktio-nalität und Informationsobjekten ausge-prägt. Bei einer feingranularen Betrach-tung hingegen, bei der die Anforde-rungen hinsichtlich der Breite der abge-deckten Funktionalität und Informati-onsobjekte nicht so umfangreich sind, können sehr wohl PESs identifiziert wer-den: PESs bieten dann die Funktionalität eines Teilgeschäftsprozesses – entweder einzelner Schritte oder einer Schrittfolge innerhalb eines Prozesses. Insbesondere bei B und C finden sich eine Reihe von PESs, welche Funktionen und Informati-onsobjekte eines Teilgeschäftsprozesses bündeln. Beispiele hierfür sind Zinsbe-rechnungen und Limitenanfragen, die als Service realisiert worden sind. Wir er-warten, dass ein steigender Bedarf nach einer stärkeren (Beinahe-) Echtzeitunter-stützung von Prozessen zur Entwicklung breiter definierter PESs führt, die mehr Funktionalitäten umfassen und entspre-chend umfangreichere Teile eines Ge-schäftsprozesses unterstützen.

6 DiskussionundAusblick

Obwohl die Argumente, mit denen Ser-viceorientierung und insbesondere die Einführung serviceorientierter Architek-turen in den Unternehmen propagiert werden, das gegenteilige Ergebnis vermu-ten lassen, hat die Analyse der vier Fälle vielmehr gezeigt, dass

ESs stets auf der Integrationsebene defi-niert werden,

■

Tab.2|ArchitekturebenenundCharakteristikaderES-GestaltungindenbetrachtetenFällen

Unternehmen A Unternehmen B Unternehmen C Unternehmen D

EA-Ebenen aus Abschnitt 2

Strategieebene (Geschäftsarchitektur)

(Geschäftsebene) (Geschäftsarchitektur) ./. (Prozessarchitektur)

Organisationsebene (Prozessarchitektur)

Geschäftsebene Geschäftsarchitektur (Prozessarchitektur) Prozessarchitektur

Integrationsebene (Integrationsarchitektur)

SystemebeneAnwendungssystem- und Integrationsarchitektur

(Anwendungssystem-architektur)

Anwendungssystem-architektur

Softwareebene (Softwarearchitektur)

Technologie-EbeneSoftware- und Komponentenarchitektur

(Softwarearchitektur)Anwendungssystem- und Infrastrukturarchitektur

Infrastrukturebene (IT-Architektur)

Technologie-Ebene Technische Architektur (Softwarearchitektur) Infrastrukturarchitektur

ESs definiert auf welcher EA-Ebene? Integration Integration Integration Integration

Granularität der ESs Gemischt Gemischt Feingranular Grobgranular



ESs in unterschiedlicher Granularität gestaltet werden, CSESs und COESs in allen Fällen ein-deutig identifiziert werden können, aber komplette Prozesse abdeckende PESs nicht identifiziert werden können. Hin-gegen lassen sich entlang eines Prozesses funktional beschränktere ESs in den Fäl-len B und C identifizieren.

Die Hypothese, dass die Entwurfsprin-zipien von ESs den Entwurfsprinzipien konventioneller Anwendungssysteme ent-sprechen, wird deshalb durch die analy-sierten Fälle gestützt.

Wie erklärt sich jedoch diese Ähnlich-keit? Eventuell werden in den Unterneh-men einfach die Gestaltungsregeln der bis-herigen Anwendungssystementwicklung unreflektiert auch für ESs verwendet, weil bislang keine generell akzeptierten Regeln existieren, die eine abweichende ES-Gestal-tung unterstützen. Auch wenn es erste Me-thodenkomponenten für die ES-Gestal-tung vorgeschlagen wurden (z. B. Schelp und Winter 2007), fehlt ein integrierter An-satz und bleiben zahlreiche Fragen offen.

Eine andere Erklärung ist, dass ähn-liche Entwurfsziele natürlich zu ähnlichen Entwurfsergebnissen führen. Flexibilität und Einfachheit sind erstrebenswerte Ziele für die Gestaltung von Anwendungs-systemen wie auch von ESs; Flexibilität und Einfachheit werden zudem durch Komponentenorientierung und systema-tische Wiederverwendung gefördert. Folg-lich zielt die Gestaltung der ESs auf lose gekoppelte Funktionsbündel im Kleinen ab, wohingegen die Gestaltung der An-wendungssysteme auf lose gekoppelte Bündel intern eng gekoppelter Funktions-blöcke im Großen abstellt.

Möglicherweise könnte sich Wiederver-wendung als Abgrenzungskriterium zwi-schen Entwurfsverfahren für Anwen-dungssysteme und für ESs erweisen. Wie-derverwendung wird häufig als Gestal-tungsziel für ESs deklariert (z. B. Herr et al. 2004), während dies beim konventio-nellen Entwurf von Anwendungssyste-men nicht der Fall ist (IBM 1984). In SOA wird Wiederverwendung auch tatsächlich realisiert (z. B. Schwinn und Hagen 2006). Bei näherer Betrachtung der betreffenden ESs wird aber deutlich, dass es sich in ers-ter Linie um Stammdatenservices handelt, d. h. CSESs im Sinne von (H2). CSESs ent-sprechen auf höherem Granularitätsni-veau weitestgehend informationszen-trierten Anwendungssystemen (wie z. B.

■

■

■

Produktdatenmanagement, Kunden-stammdatenmanagement oder Risikoma-nagement). Solche Anwendungssysteme finden sich in der Anwendungssystem-landschaft orthogonal zu Organisation / Produktgruppen und funktionsorien-tierten Anwendungssystemen (Bild 3). Auch hier kann damit Wiederverwen-dung konstatiert werden, so dass wieder-um kein konzeptioneller Unterschied zwi-schen traditionellem Anwendungssystem-entwurf auf der einen und ES-Entwurf auf der anderen Seite sichtbar wird.

Da sich die Serviceorientierung auf den Organisations- und Integrationsebenen der Unternehmensarchitektur immer noch in einem frühen Stadium befindet, benötigen auch geeignete methodische Ansätze für den ES-Entwurf noch einige Zeit zur Reife. Es sind zunächst mehr Fall-studien erforderlich, aus deren Analyse ei-ne generelle Hypothese zum ES-Entwurf bestätigt oder falsifiziert werden kann. Benötigt werden auch quantitative Analy-sen, um Gestaltungsszenarien für ESs und Abhängigkeiten zu Kontextfaktoren oder Projektzielen identifizieren zu können. Zu einer umfassenden Methode zum ES-Ent-wurf gehören neben zu identifizierenden Gestaltungsrichtlinien dann auch bestä-tigte Referenzmodelle für ESs sowie Hin-weise, wie und vor allem in welchem Um-fang die Transformation konventioneller Anwendungssystemlandschaften zu ES-Landschaften erfolgen kann. Da jedoch zurzeit nur wenige Unternehmen über ei-ne mehrjährige Erfahrung im Aufbau und Betrieb einer SOA verfügen, werden in den kommenden Jahren weitere, zuneh-mend auch quantitative Analysen durch-zuführen sein.

LiteraturBarry, Douglas K. (2003): Web Services and Service-Oriented Architecture: Your Road Map to Emerging IT. Morgan Kaufmann, San Francisco.Braun, Christian; Winter, Robert (2005): A Compre-hensive Enterprise Architecture Metamodel and Its Implementation Using a Metamodeling Plat-form. In: Desel, Jörg; Frank, Ulrich (Hrsg.): Enterpri-se Modelling and Information Systems Architec-tures. Proceedings of the Workshop in Klagenfurt, Gesellschaft für Informatik, S. 64 – 79.Brown, George; Carpenter, Robert (2004): Success-ful Application of Service-Oriented Architecture Across the Enterprise and Beyond. In: Intel Tech-nology Journal 8 (4), S. 345 – 359.Davenport, Thomas H. (1993): Process Innovation – Reegineering Work through Information Techno-logy. Harvard Business School Press, Boston.Durst, Michael; Daum, Michael (2007): Erfolgsfak-toren serviceorientierter Architekturen. In: HMD –

Praxis der Wirtschaftsinformatik 42 (253), S. 18 – 27.Hagen, Claus (2003): Integrationsarchitektur der Credit Suisse. In: Aier, Stephan; Schönherr, Marten (Hrsg.): Enterprise Application Integration – Fle-xibilisierung komplexer Unternehmensarchitek-turen. GITO, Berlin, S. 61 – 81.Hedman, Jonas; Kalling, Thomas (2003): The busi-ness model concept: theoretical underpinnings and empirical illustrations. In: European Journal of Information Systems 12 (1), S. 49 – 59.Herr, Michael; Bath, Uwe; Koschel, Arne (2004): Im-plementation of a Service Oriented Architecture at Deutsche Post MAIL. In: Zhang, Liang-Jie; Jeckle, Mario (Hrsg.): Proceedings of Web Services – Eu-ropean Conference (ECOWS 2004). Erfurt. Sprin-ger, S. 227 – 238.Heutschi, Roger; Legner, Christiane; Österle, Hubert (2006): Serviceorientierte Architekturen – Vom Konzept zum Einsatz in der Praxis. In: Schelp, Joa-chim; Winter, Robert; Frank, Ulrich; Rieger, Bodo; Tu-rowski, Klaus (Hrsg.): Integration, Informationslo-gistik und Architektur – Proceedings der DW2006, Friedrichshafen, S. 361 – 382.IBM (1984): Business Systems Planning – Informa-tion Systems Planning Guide. GE20-0527-4, IBM, Atlanta.IEEE (2000): IEEE Recommended Practice for Archi-tectural Description of Software Intensive Systems. 1471-2000, IEEE Computer Society, New York, NY.IMG (1999): PROMET STP: Methodenhandbuch für die System System- und Technologieplanung, Re-lease 1.0. IMG AG, St. Gallen.Krafzig, Dirk; Banke, Karl; Slama, Dirk (2005): Enter-prise SOA – Service-Oriented Architecture Best Practices. Pearson, Upper Saddle River, NJ.Kuhlin, Bernd; Thielmann, Heinz (Hrsg.) (2005): The Practical Real-Time Enterprise: Facts and Perspec-tives. Springer, Berlin et al.Linthicum, David S. (2000): Enterprise Applica-tion Integration. AWL Direct Sales, Reading, Mas-sachusetts.Luftman, Jerry N.; McLean, Ephraim R. (2004): Key Issues for IT Executives. In: MIS Quarterly Executive 3 (2), S. 89 – 104.Mesarovic, M. D.; Macko, D.; Takahara, Y. (1970): The-ory of Hierarchical, Multilevel Systems. Academic Press, New York, London.Opengroup (2003): TOGAF „Enterprise Edition“ Ver-sion 8.1. The Open Group.Österle, Hubert (1995): Business in the Information Age – Heading for New Processes. Springer, New York.Penzel, Hans-Gert (2004): Architekturmanagement aus Sicht einer Großbank. In: Moormann, Jürgen; Fischer, Thomas (Hrsg.): Handbuch IT in Banken. 2. Aufl., Gabler, Wiesbaden.Porter, Michael E. (2004): Competitive Advantage: Creating and Sustaining Superior Performance. Free Press, New York.Prahalad, Coimbatore Krishnarao; Hamel, Gary (1990): The Core Competence of the Corporation. In: Harvard Business Review 68 (3), S. 79 – 91.Ross, Jeanne W.; Weill, Peter; Robertson, D. C. (2006): Enterprise Architecture as Strategy – Creating a Foundation for Business Execution. Harvard Busi-ness School Press, Boston, MA.Schekkerman, Jaap (2004): How to Survive in the Jungle of Enterprise Architecture Frameworks:



Creating or Choosing an Enterprise Architecture Framework. 2. Aufl., Trafford Publishing, Victo-ria, BC.Schelp, Joachim; Winter, Robert (2007): Towards a Methodology for Service Construction. In: Proceedings of the 40th Hawaii International Con-ference on Systems Sciences (HICSS-40). IEEE Com-puter Society, S. 64a (61 – 67).Schwinn, Alexander; Hagen, Claus (2006): Measured Integration – Metriken für die Integrationsarchi-tektur. In: Schelp, Joachim; Winter, Robert (Hrsg.): Integrationsmanagement. Springer, Berlin et al., S. 267 – 292.Spitzer, P. (2002): Gesamtarchitektur aus Sicht der HVB Group. In: Proceedings of the Third Con-ference on Innovations in the Banking Industry (CIBI 2002), Institut für Bankinformatik.Tang, Anthony; Han, Jun; Chen, Pin (2004): A Com-parative Analysis of Architecture Frameworks. SU-TIT-TR2004.01, Swinbourne University of Techno-logy, Swinbourne.Tenenbaum, Jay M.; Khare, Rohit (2005): Business Services Networks: delivering the promises of B2B. In: Proceedings of the IEEE EEE05 Interna-tional workshop on Business services networks (BSN‘05), Hong Kong, IEEE Press, S. 8 – 8.Tsalgatidou, Aphrodite; Pilioura, Thomi (2002): An Overview of Standards and Related Technology in Web Services. In: Distributed and Parallel Databa-ses, 12 (2 – 3), S. 135 – 162.Weill, Peter; Vitale, Michael R. (2001): Place to Space: Migrating to eBusiness Models. Harvard Business School Press, Boston, MA.Winter, Robert (2003): An Architecture Model for Supporting Application Integration Decisions. In: Ciborra, Claudio U.; Mercurio, Ricardo; de Mar-co, Marco; Martinez, Marcello; Carignani, Andrea (Hrsg.): Proceedings of the 11th European Con-ference on Information Systems (ECIS2003), Nap-les, Italy.Winter, Robert (2004): Architektur braucht Ma-nagement. In: Wirtschaftsinformatik 46 (4), S. 317 – 319.Winter, Robert; Fischer, Ronny (2006): Essential Lay-ers, Artifacts, and Dependencies of Enterprise Ar-chitecture. In: Hung, Patrick C. K. (Hrsg.): Procee-dings of the 10th IEEE International Enterprise Dis-tributed Object Computing Conference Work-shops (EDOCW‘06) on Trends in Enterprise Archi-tecture Research (TEAR 2006), Hong Kong, IEEE Computer Society Press, S. 30 (31 – 38).

Zusammenfassung/Abstract

Joachim schelp, robert Winter

EntwurfvonAnwendungssystemenundEntwurfvonEnterpriseServices–ÄhnlichkeitenundUnterschiede

Mit der Einführung serviceorientierter Architekturen wird angestrebt, Anwen-dungssysteme zu flexibilisieren. Im Gegensatz zum konventionellen Systement-wurf sollen vermehrt lose gekoppelte Systeme entstehen. Es stellt sich die Frage, ob sich als Ergebnis des geänderten Gestaltungsparadigmas andere Anwen-dungssystemtypen ergeben. Bei konventionellen Anwendungssystemen kön-nen drei Anwendungssystemtypen identifiziert werden, die sich in ihrer Gestal-tung entlang der Dimensionen Organisation/Produkte, Informationsobjekte und Funktionen unterscheiden. Bei der Gestaltung der Enterprise Services moderner serviceorientierter Architekturen lassen sich diese Typen ebenfalls wiederfinden, wenngleich mit Unterschieden. Während Querschnitts- und kanalorientierte Enterprise Services in ähnlichem Schnitt auftauchen wie ihre traditionellen Ge-genstücke, sind prozessorientierte Anwendungssysteme in ihrer Funktionalität deutlich umfangreicher gestaltet als die entsprechenden Enterprise Services. Der vorliegende Beitrag untersucht anhand von vier Fallstudien die Gestaltung von Enterprise Services in der Praxis und setzt sie in Beziehung zur traditionellen Ge-staltung von Anwendungssystemen und den dabei verfolgten Zielen. Angesichts der nur geringen Unterschiede werden mögliche Gründe diskutiert, welche die große Ähnlichkeit der Entwurfsergebnisse erklären.

Stichworte: Serviceorientierung, Enterprise Services, Entwurf von Enterprise Services, Entwurf von Anwendungssystemen

ApplicationDesignandEnterpriseServiceDesign–SimilaritiesandDifferences

Service oriented (re-)design aims at increasing the flexibility of application archi-tecture. In contrast to traditional application design, functionality clusters are in-tended to be coarse-grained and loosely coupled. The question is whether this new design paradigm also leads to different types of applications: In traditional application design, applications either are integrated along organizational struc-ture (process oriented), along information objects (information oriented), or ac-cording to certain reusable functionalities (functionality / channel oriented). In practice, corresponding enterprise service types can be observed. While informa-tion oriented and functionality / channel enterprise services are designed wide-ly similar to their traditional application counterparts, process oriented enter-prise services usually have higher granularity. Based on four case analyses, this paper presents design approaches, analyzes enterprise service design and com-pares enterprise service design to traditional application design. Since both de-sign paradigms seem to lead to widely similar architectures, potential reasons are discussed.

Keywords: service orientation, enterprise services, enterprise service design, application design

entwurf von anwendungssystemen und entwurf von enterprise services

Documents