Modularisierung von betrieblichen Anwendungssystemen - Prüfung der Übertragbarkeit von Ansätzen zur Dienstleistungsmodularisierung auf den Anwendungsbereich IT

Prüfung der Übertragbarkeit von Ansätzen zur Dienstleistungsmodularisierung auf den Anwendungsbereich IT

Modularisierung von betrieblichen Anwendungssystemen

Oliver Budde

Aachen, 13. Dezember 2011

2

Agenda

• Problemstellung

• Terminologie

• Methodischer Forschungsansatz

• Analogiebetrachtung zwischen Dienstleistungsmodularisierung und IT-Modularisierung

• Ausblick

3

Der Umsetzungserfolg von strategischen Maßnahmen v.a. im Bereich von Prozessflexibilisierungsmaßnahmen werden durch die IT begrenzt.

Abhängigkeitsverhältnis zwischen Geschäftsarchitektur und IT-Architektur

IT-Architektur(Womit?)

Geschäftsarchitektur(Was?)

Prozessarchitektur(Wie?)

Zunehmender Bedarf nach Prozess-flexibilität resultiert in:• Aufbrechen von funktionalen zu

prozessorientierten Organisationen

• Zunehmender Reduzierung der Wertschöpfungstiefe und damit erhöhter Koordinationsbedarf mit ex. Partnern

Zunehmende Bedeutung der IT, aber:• inadäquate 3rd Party Integration2)

• Medienbrüche-> Dateninkonsistenz2)

• Paradigma „Produktion vor Integration vor Innovation“4)

t5)

Aufwand fürErfüllung fachl. Anforderungen

Aufwand für Erfüllung Integrationsanfor-derungen

Quellen: 1) BLEICHER 2004, S.45 2) KAGERMANN ET AL. 2011

3) KINKEL ET AL. 2007, S.5

4) MERTENS, PAGEL 2011 5)DERN 2011, S. 32

Dynamisierung des Umfelds durch:• organisatorische Veränderungen

(Merger/De-Merger)• rechtlicher Rahmenbedingungen

(z.B. SOX)• radikale Innovationen (z.B.

Internet)

1970 20091999198919790%

10%20%30%40%50%

Segmentierung der Produktion3)

Ante

il B

etr

iebe

(Teiln

eh

mer)

An

pass

un

gsz

eit

1900 20041)

Benötigte Reaktionszeit

bei wachsender Komplexität

Verfügbare Reaktionszeit

bei zunehmender

Dynamik

100%

4

Die Ursache für einen derzeitig hohen Integrationsaufwand lassen sich auf Defizite bei der Beherrschung der IT-Komplexität zurückführen.

Ursachen für den hohen IntegrationsaufwandHoher Des/- Integrationsaufwand

von Anwendungsfunktionalität

Masse Dynamik

• Hohe Anzahl an Stand-Alone Lösungen

• Zunehmende Anzahl an Lieferanten für Software-Produkte1) oder Dienstleistungen für den Software-Betrieb

• Abbildung neuer Lieferantenbeziehungen durch die Integration mit Fremdsystemen

• Veränderung der Schnitt-stellendefinitionen in einem (hierarchischen) Unternehmensnetzwerk

• Heterogenität der IT-Landschaft, aufgrund gewachsener IT-Systeme (IT-Sklerose) 2)

• Kopplung der Systeme, häufig über Punkt-zu-Punkt Integration 3)

• Technologiewellen in der IT (Client-Server, Virtualisierung, SOA, Cloud-Computing)

• Veränderung der bestehenden Systeme durch Updates, Releasewechsel 4)

Anzahl IT-Systeme Umfang der Integrationsbeziehung

en

Wechselnde Integrations-beziehungen

Veränderung der Software(technologien)

Es existieren Defizite bei der Beherrschungder IT-Komplexität

Quellen: 1)ATKEARNEY 2010,S. 2

2)SCHMIDT 2009,S. 2 2) 3)AIER, SCHÖNHERR 2007, S.12

2) 4)HANSCHKE 2011

CAD ERP

LES CRM

PLMBI

MESERP

PLMBI

X © Gartner

5

Derzeitige Ansätze zur Modularisierung von Software erreichen nicht das Ziel der Komplexitätsbeherrschung aus Fachbereichssicht.

Schwierigkeiten bei der Software-Modularisierung

MMSCM

LESSRM

PSFIERP

OSDB

MOM

VertriebFuE

Kann ein Modularisierungsansatz aus dem Dienstleistungsbereich auf den Anwendungsbereich betrieblicher Anwendungssysteme übernommen werden mit dem Ziel die Integrationsaufwände zu

beherrschen und damit eine verbesserte Prozessflexibilisierung zu erreichen?

CO

Infr

a-

stru

ktu

r

Anw

end

un

gs-

syst

em

Pro

zess

• Modularisierungsansätze sind häufig technik-orientiert, z.B. Corba, Webservices

• Modulbildung erfolgt aus Softwareanbietersicht (z.B. BAPI)

Res-

sourc

en

Erg

ebn

is

Pro

zess Prozesselement A Prozesselement A

Ressourcenelement A

Ressourcenelement B

• Bei der Modularisierung von Dienstleistungen bedarf es einer integrativen Betrachtung der konstitutiven Elemente1)

Verg

leic

h d

er

Pro

ble

m-

stellu

ngDeterminieru

ng der Modulbildung

?

Fachliche und technische

Kompatibilität

Quelle: 1)IN ANLEHNUNG AN SCHUH 2008

6

Agenda

• Problemstellung

• Terminologie



• Ausblick

7

Präsentation

Es kann zwischen zwei Service-Begriffen unterschieden werden. Diese Arbeit fokussiert sich auf den technisch-orientierten Service-Begriff.

Abgrenzung und Zusammenspiel der Servicebegriffe1

1

1.1 1.x

1.1.1

1.1.2

1.1.3 1.x.21.x.1

Instandhaltung

Die

nst

leis

tung

s-A

rch

itektu

r

InspektionReparatur 1.2 ….

Pro

zess

-A

rch

itektu

r Geschäftsprozess

Teilprozess

Aktivitäten

IT-

Arc

hit

ektu

r

Service Service

VerarbeitungDatenhaltung

Technisch-orientierter

Service-Begriff

Betriebswirt-

schaftlicher orientierter

Service-Begriff

Service Service

Ebenenmodelleines betrieblichenAnwendungs-System

Quellen: 1)BUHL ET AL. 2008

8

Hardware

Betriebssystem

Middleware

Anwendung

Gegenstand der Modularisierung von betrieblichen Anwendungssystemen ist der Business Service.

Struktur eines betrieblichen Anwendungssystems(BAS)1) und Begriffseinordnung

Icon

Service-SystemFramework (SSF)

Teilprozess

Alternative zur Ausführung einer

Aktivität, die unterschiedliche

Institutionalisierungsformen aufweisen kann.2) Ein

technisch-orientierter Business Service ist ein Modul, welches Dienste über eine wohldefinierte

Schnittstellen zur Verfügung stellt.3)

Teilschritt eines Prozesses, mit dem eine Zustandsveränderung beschrieben wird.

Aktivitäten können ablauflogisch miteinander verknüpft werden und selbst als Prozess

definiert werden.2)

BusinessService

Quellen: 1)In Anlehnung an das Fachkomponentenkonzept von TUROWSKI 2003

2)VOM BROCKE 2008, S. 57FF

3)OVERHAGE, TUROWSKI 2007 4) TUROWSKI 2003, S.25

Ein Dienst ist eine Aktion eines BAS, welches die Bewältigung einer

bestimmten Menge von betrieblichen Aufgaben unterstützt.4)

Service-Anwendungs-

Framework (SAF)

Dienst ADienst BDienst C

9

Die Modularisierung von betrieblichen Anwendungssystemen kann über die Kapselung von atomaren Diensten zu Business Services erfolgen.

Skizzierung eines möglichen Prinzips für eine modulare Business Service ArchitekturModularität

Modularität ist eine Eigenschaft eines Softwaresystems, eines Sachguts oder einer Dienstleistung, das durch eine lose Kopplung und eine hohe Kohärenz seiner Komponenten oder Teildienstleistungen gekennzeichnet ist.1)

Modulare Architektur wird durch 3 Konzepte2) beschrieben

1. Festlegung der Funktionsarchitektur

2. Zuordnung von Teilfunktionen zu Funktionsträgern (physische Bauteile)

3. Beschreibung der Schnittstellen mit der physischen Komponente

Funktionsstruktur

Physische Produkt-struktur

Modulare Architektur

Architekturgestaltung

Modulare Business Service-Architektur

SAF / SSF

Quellen: 1)BALZERT 1998, S.474

2)UHLRICH1995

Übert

ragu

ng

IT-Ebene(physische Produkt-struktur)

ServiceSpezifikatio

n(anwendung

s-neutral)

Prozess(Funktions-struktur)

z.B. Auftrags-annahme

X Y

Atomarer Dienst (SW)

Business Service AktivitätAktivität(Mensch)

Legende: Fachl. KopplungTechn. Kopplung

10

Die Modularisierung von betrieblichen Anwendungssystemen kann über die Kapselung von atomaren Diensten zu Business Services erfolgen.

Skizzierung eines möglichen Prinzips für eine modulare Business Service ArchitekturModularität

Modularität ist eine Eigenschaft eines Softwaresystems, eines Sachguts oder einer Dienstleistung, das durch eine lose Kopplung und eine hohe Kohärenz seiner Komponenten oder Teildienstleistungen gekennzeichnet ist.1)

Modulare Architektur wird durch 3 Konzepte2) beschrieben

1. Festlegung der Funktionsarchitektur

2. Zuordnung von Teilfunktionen zu Funktionsträgern (physische Bauteile)

3. Beschreibung der Schnittstellen mit der physischen Komponente

Funktionsstruktur

Physische Produkt-struktur

Modulare Architektur

Architekturgestaltung

Modulare Business Service-Architektur

SAF / SSF

Quellen: 1)BALZERT 1998, S.474

2)UHLRICH1995

Übert

ragu

ng

IT-Ebene(physische Produkt-struktur)

ServiceSpezifikatio

n(anwendung

s-neutral)

Prozess(Funktions-struktur)

z.B. Auftrags-annahme

X Y

Atomarer Dienst (SW)

Business Service AktivitätAktivität(Mensch)

Legende: Fachl. KopplungTechn. Kopplung

Beantwortung der Frage: Welche atomaren Dienste sollen unter

Berücksichtigung von technischen und fachlichen Restriktionen zu

einem Business Service zusammengefasst werden?

11

Ein Business Service grenzt sich von anderen Gütertypen durch drei Eigenschaften ab.

Relevante Eigenschaften von Business Services

Imm

ate

rialit

ät4

) IT-Ausgaben (US$ Millionen6)

• Leichte Veränderlichkeit• First-Copy Cost- Effekte bei Standardsoftware• Nicht-Abnutzbarkeit• Vglw. hohe Innovationsrate, aufgrund

geringerer Entwicklungskosten als bei materiellen Gütern

Die

nst

leis

tun

gs-

last

igke

it5)

Netz

eff

ekt

e4)

• Für einen Business Services lassen sich die drei konstitutiven Merkmale von Dienstleistungen nachweisen

• Die Integration des externen Faktors erfolgt im Unterschied zur Dienstleistung automatisch1)

• Eine Simultanität von Konsumption und Produktion ist bei Services gegeben, bei IT-Komponenten allerdings nicht.2)

Potenzial Prozess Ergebnis

Bereitstellung interner

Produktions-faktoren

Automatische Integration mit dem externen

Faktor im Rahmen der

Prozessausführung

Konkretisierung der Wirkung im

Prozess

• Indirekte Netzeffekte aufgrund Komplementarität des Angebots, falls Business Services plattformabhängig von einem SAF sind (vgl. das SAP Eco-System)

• Lock-In Effekt bei Software auf der Ebene von SAF ist möglich

$0

$300

$150

37 Lieferanten (80% der Ausgaben

2.172 Lieferanten (20% der Ausgaben

Quellen: 1)HULVEJ, J. 2008, S. 35

2)OVERHAGE, S.; TUROWSKI, K. 2007, S.3FF 3) BUXMANN 2008, S.39 4)HELFERICH 2010, S.93FF

5)LÖFFLER 2011, S.20F

6)ATKEARNEY 2010,S. 2

100

Marktanteil3)

0

Kampfzone

Gewinner

Verlierert

12

Agenda

• Problemstellung

• Terminologie



• Ausblick

13

Vorgehensweise bei einer Analogiebetrachtung1)

Forschungsmethodik

Gewollte Eigenschaften und Funktionen festlegen1

Vorbilder suchen, die ähnliche Eigenschaften und Funktionen aufweisen2

Untersuchung des Systems, dass diese Eigenschaften besitzt bzw. hervorbringt3

Prüfe, ob Wirkungsweise übertragbar ist4

Quellen: 1) HABERFELLNER R., DAENZER W. F.1997, S.437

14

Agenda

• Problemstellung

• Terminologie


• Analogiebetrachtung zwischen Dienstleistungsmodularisierung und IT-Modularisierung– Gewollte Eigenschaften und Funktionen festlegen

– Vorbilder suchen, die ähnliche Eigenschaften und Funktionen aufweisen

– Untersuchung des Systems, dass diese Eigenschaften besitzt bzw. hervorbringt

– Prüfe, ob Wirkungsweise übertragbar ist

• Ausblick

15

In einer modularen Architektur sollten die Koordinationsaufwände zwischen einzelnen Systemelementen durch die Reduzierung von Abhängigkeiten beherrschbar sein.

Modularisierung als Koordinationsproblem

Als Formalziel einer Modularisierung wird nach Corsten1) die Minimierung der entscheidungsrelevanten Kosten angestrebt, wobei der Trade-Off zwischen den Kosten der Koordination und den Opportunitätskosten einer mangelnden Abstimmung der Leistungserstellungsprozesse bzw. den Services in diesem Fall auszubalancieren ist.

Zie

lA

usb

ala

nci

eru

ng d

er

Kost

en-

und

N

utz

eneff

ekte

der

Modula

risi

eru

ng

3)

Vielfalt/Granularität

Kosten/Opport-unitäts-kosten

Opportunitätskosten (als entgangener Nutzen)

Koordinationskosten

Monolithisches ERP-System

FöderiertesERP-System

Ursächlich für den Koordinationsbedarf sind (wechselseitige) Abhängigkeiten zwischen den Diensten bzw. Services. Für die Beherrschung des Koordinationsbedarfs und zur Realisierung des Modularisierungs-nutzens können drei Anforderungen an die Modulbildung gelegt werden1):1. Unabhängigkeit

Geringe Intermodulare Interdependenz und hohe intramodulare Interdependenz

2. AbgeschlossenheitUmsetzung des Geheimnisprinzips, Kapselung von Informationen

3. TransparenzFestlegung der max. Modulgröße (Granularität) in Abhängigkeit von der Informationsverarbeitungs-kapazität2)Quellen: 1) CORSTEN ET AL.

20062) PICOT, FREUDENBERG 1998, S.78

3) In Anlehnung an TUROWSKI 2003, S.84

1234

16

Business Services bedürfen einer Koordination auf verschiedenen Ebenen.1) Dieser Koordinationsbedarf resultiert in eine Abhängigkeit, die bei der Modulbildung berücksichtigt werden muss.

Relevante Koordinationsebenen für Business Services

BusinessService 1

?

BusinessService 2

1234

Schema Koordinationsebenen

1. Inhaltliche AbstimmungsebeneWelche betrieblichen Aufgaben kapselt ein Business Services im Vergleich zu anderen Business Services oder einer anderen Institutionalisierungsform (z.B. Mensch), so dass fachliche Konflikte vermieden werden können?

Quelle: 1) TUROWSKI 2003, S. 154

17



BusinessService 1

BusinessService 3

BusinessService 2

Austausch

Schema Koordinationsebenen

2. Zeitliche AbstimmungsebeneIn welcher zeitlichen Reihenfolge werden Business Services ausgeführt, welche Konsequenzen können Prozessanpassungen auf die Ausführbarkeit der Business Services besitzen?


1234


18



Business

Service 1

Business

Service 2

Service-Anwendungsframework

3. KommunikationsebeneGrundlegend für eine Kooperation ist die wechselseitige Kommunikationsfähigkeit zwischen den Aufgabenträgern. Diese ist gegeben, wenn Nachrichten von den jeweils miteinander kommunizierenden Aufgabenträgern verstanden werden (Syntax, Semantik) und durch Nachrichten die jeweils vom Sender intendierten Handlungen beim Empfänger derselben ausgelöst werden (Pragmatik)

• Syntax• Semantik• Pragmati

k

• Semantik• Pragmatik

• Semantik• Pragmatik

Syntax Syntax

Schema



Koordinationsebenen

1234


19



Schema

Business

Service 1

Business

Service 2

Service-Anwendungsframework

Koordinationsebenen

3. KommunikationsebeneGrundlegend für eine Kooperation ist die wechselseitige Kommunikationsfähigkeit zwischen den Aufgabenträgern. Diese ist gegeben, wenn Nachrichten von den jeweils miteinander kommunizierenden Aufgabenträgern verstanden werden (Syntax, Semantik) und durch Nachrichten die jeweils vom Sender intendierten Handlungen beim Empfänger derselben ausgelöst werden (Pragmatik)


4. KommunikationskanalNachrichtenaustausch als solcher erfolgt über Kommunikationskanäle (z.B. einem Enterprise-Service-Bus) und setzt auf dem Vorhandensein einer grundlegenden Kommunikationstechnik I auf. Auf dieser Ebene wird z.B. geregelt, wie ein Aufgabenträger seinen Kommunikationsbedarf anmeldet, wer den den Kommunikationsvorgang steuert oder wie Nachrichten zu verschlüsseln sind.


1234


20

Basierend auf den Erkenntnissen über die Koordinationsaufwände auf den vier Ebenen, lassen sich die Modularisierungsanforderungen für Business Services spezifizieren.

Spezifizierung der Anforderungen für Business Services

Koordinationsebenen Unabhängigkeit Abgeschlossenheit Transparenz

Inhaltliche Abstimmung

Zeitliche Abstimmung

Kommunikationskanal

Fachliche Unabhängigkeit

Technische Unabhängigkeit

StandardisierungSemantik,

Syntax,Pragmatik

Bedarfsorientierung – Überwindung des

Zielkonflikts zwischen hoher fachlicher

Wiederverwendungs-möglichkeit und

technisch-bedingten Koordinationskosten

durch Kapselung (Festlegung der richtigen

Funktions- und Schnittstellengranularität)1)

Unabhängigkeit hinsichtlichzeitlicher

Ausführungslogik

Kommunikationsebene(Syntax, Semantik,

Pragmatik)

Quelle: 1) basierend auf HEUTSCHI 2007, S.43

1234

21

Agenda

• Problemstellung

• Terminologie






• Ausblick

22

Aufgrund einer höheren Ähnlichkeit zwischen den Eigenschaften von klassischen Dienstleistungen und denen von Business Services, erfolgt die Analogiebetrachtung mit dem Dienstleistungsbereich.

Bestimmung eines relevanten Analogiebereichs

Eigenschaften von

Services

Sachgutindustrie Dienstleistungswirtschaft

Immaterialität Ein Kennzeichen der Sachgutindustrie ist die Materialität

Ein Kennzeichen von Dienstleistungen

Dienstleistungs-lastigkeit

Integrierte Produkt-Service-Systeme besitzen eine Dienstleistungs-komponente

Diese Eigenschaften erfüllen Dienstleistung per se.

Netzeffekte Im Verständnis eines typischen Singulärgutes nicht existent

Netzeffekte sind möglich und existent, stellen aber keine charakteristische Eigenschaft dar (Ausnahme z.B. Beratung)

1234

23

Aus der Vielzahl an Engineeringansätzen für Dienstleistungen wurde der vielversprechendste Ansatz von Corsten ausgewählt.

Einschränkung des Betrachtungsbereichs innerhalb des Dienstleistungsbereichs

Ansätze des Service Engineerings

• Service Blueprinting1)

• Service Design& Management Model2)

• Modular Network Design3)

• Modularisierung technischer Dienst-leistungen4)

• Konfiguration technischer Dienst-leistungen5)

• Modularisierung von Dienstleistungen6)

Explizite Modularisierungs-

ansätze

• Modular Network Design3)

• Modularisierung technischer Dienst-leistungen4)

• Konfiguration technischer Dienst-leistungen5)

• Modularisierung von Dienstleistungen6)

Foku

ssie

run

g a

uf

Mod

ula

risie

run

gsan

sätz

e

Modularisierung von Dienstleistungen6)

Exp

lizit

e

Berü

cksic

hti

gu

ng

d

er

Koord

inati

on

s-

pro

ble

mati

kQuellen: 1)SHOSTACK 1982 2) RAMASWAMY 1996 3) HOOGEWEEGEN ET AL.

19994) BURR 2002 5)HERMSEN 2002

6) CORSTEN ET AL.2006, 2007, 2008

1234

24

Agenda

• Problemstellung

• Terminologie






• Ausblick

25

Die Modularisierung bei Corsten verläuft in zwei Phasen. Nach der Ableitung einer Prozessabhängigkeitsmatrix folgt der eigentliche Modularisierungsprozess durch Anwendung von Matrizenumformulierungsoperationen.

Untersuchung des Ansatzes von Corsten

Identifikation von Interdependenzen zwischen

Teilprozessen und deren Codierung in der Prozess-

Beziehungsmatrix

Anwendung von Matrizenumformungsoperationen zur Bildung von Modulen (Partitionierung, Dekomposition

und Zusammenführung)

1234

26





Beziehungsmatrix



Bei einem Ressourcenverbund greifen mehrere Teilprozesse auf dieselben, begrenzt verfügbaren Produktions-faktoren zurück. 1)

Ressourcen-

abhängigkeitErfolgs-

abhängigkeit

Leistungs-abhängigke

itVerhaltens-abhängigke

it

Abhängigkeitstypen

Bindungsstärke0 4

Ressourcen-

abhängigkeit

1234

Quelle: 1)CORSTEN ET AL. 2006

27





Ein Leistungsverbund liegt dann vor, wenn eine Dienstleistung mehrere Teilleistungen umfasst, die durch Teilprozesse erbracht werden, und deren Teilleistungsbeiträge wechselseitig voneinander abhängig sind. 1)

Ressourcen-


abhängigkeit



it

Abhängigkeitstypen

Bindungsstärke0 4



Beziehungsmatrix

1234


28





Erfolgsverbund, die den einzelnen Teilprozessen zurechenbaren Beiträge zum monetären Erfolg einer Dienstleistung sind wechselseitig von den jeweiligen Entscheidungen über die Parameter und die Ausführung der Teilprozesse abhängig. 1)

Ressourcen-


abhängigkeit



it

Abhängigkeitstypen

Bindungsstärke0 4



Beziehungsmatrix

1234


29





Verhaltensabhängigkeiten entstehen immer dann, wenn die Festlegung der Parameter unterschiedlicher Teilprozesse, zwischen den Sachinterdepend-enzen bestehen, unterschiedlichen Entscheidungsträgern obliegt. Damit werden die Parameter eines Teilprozesses in Abhängigkeit von den Erwartungen über die Parameterwahl der anderen Teil-prozesse gewählt und vice versa.1)

Ressourcen-


abhängigkeit



it

Abhängigkeitstypen

Bindungsstärke0 4



Beziehungsmatrix

1234


30





Beziehungsmatrix

Anwendung von Matrizenumformungsoperationen zur Bildung von Modulen

• Bildung von kompakten Prozessblöcken

• Ein Block sollte nur diejenigen Elemente umfassen zwischen denen Interdependenzen existieren

• Zwischen Blöcken sollten nur einseitige Abhängigkeiten existieren

• Ursprüngliche Algorithmus von Steward1) wurde angepasst, um den Aspekt der Mehr-Dimensionalität und kardinal skalierten Abstufungen zur berücksichtigen

Partitionierung

Dekomposition

1234

Quelle: 1)STEWARD 1981

31





Beziehungsmatrix

Anwendung von Matrizenumformungsoperationen zur Bildung von Modulen

• Zerlegung von großen Prozessblöcken, so dass der Anforderung nach Transparenz entsprochen werden kann (maximale Modulgröße)

• Zerlegung kann entweder durch• eine Aufhebung (Abschwächung) der

Interdependenz oder• eine Zerschneidung der Interdependenz

und entsprechender Koordination der entstehenden Schnittstelle

erfolgen.

2 6 8

7 1 5

3 4 9

S1 S2

S3

Partitionierung

Dekomposition

1234

32

Agenda

• Problemstellung

• Terminologie






• Ausblick

33

In Bezug auf die Sachinterdependenzen lässt sich der Ansatz von Corsten auf Business Services übertragen.

Prüfung der Wirkungsweise der Prozess-Beziehungsmatrix

Fachliche Unabhängigkeit

Technische Unabhängigkeit

Standardisierung(Nachrichtenaustausch)

Zeitliche Ausführungs-logik

Unabhängigkeit Abgeschlossenheit

Sach

inte

rdependenze

nVerh

alt

ens

Inte

rdep.

Ressourcen-

abhängigkeit

Erfolgs-abhängigk

eit

Leistungs-abhängigk

eit

Verhaltens-abhängigk

eit

•Gemeinsam genutzte Business-Objekte und deren Zustandsänderung

•Geteilte Nutzung von kritischen System-ressourcen (z.B. MOM1))

•Klarheit über die Vor-und Nachbedingungen von Serviceausführungen•Business Services aus

der gleichen Domäne (z.B. CRM)

•Typ und Inhalts-kompatibilität von Daten in den Schnittstellen

•Übereinstimmende Erwartungshaltung zw. Sender und Empfänger

Nicht übertragbar, aufgrund der automatisierten Leistungsbereitstellung bei IT-basierten Business Services

1234

: 1)Message-oriented Middleware

34

Die von Corsten vorgestellten Operationen sind für eine mehrdimensionale Prozess-Beziehungsmatrix entworfen. Eine inhaltliche Modifikation wirkt sich somit nicht auf die Güte und Funktionsweise der Operationen aus.

Prüfung der Wirkungsweise der Matrizenumformungsoperationen

Granularität in Bezug auf Schnittstellen und Funktionalität (Kapselung)

Transparenz

Matr

izenu

mfo

rmung

sopera

tionen

Partionier-ung

Dekompo-sition

•Business Service Blöcke lassen sich unter Anwendung des modifizierten Verfahrens bilden, da multi-dimensionale Abhängigkeiten sowie Kardinalitäten berücksichtigt werden können.

•Die Methode der Dekomposition ist prinzipiell auf Business Services anwendbar

•Unterschiede ergeben sich hinsichtlich der Aufteilungsstrategien von Modulen, da bei Business Services eine größere Bandbreite an Handlungsoptionen existieren (z.B. Parametrisierung, Modifikation und vielfältige technische Integrationsmethoden wie Wrapper)

Modifiziertes Verfahren von Corsten eignet sich grundsätzlich für die Anwendung auf Business Services. Anpassungsbedarf ergibt sich im Detail in Bezug auf:

• Differenzierte Strategie für die Aufhebung von Interdependenzen, Unterscheidung zwischen Parametrisierung und echter Modifikation1)

• Berücksichtigung von Aufwands- und Nutzenaspekten bei der Anpassung von Schnittstellen bspw. in Bezug auf die Nutzung von Wrappern oder Anpassung des Datenmodells

Quelle: 1)VGL. GRONAU ET AL.2007, der Autor differenziert zwischen vier Anpassungsformen

1234

35

Agenda

• Problemstellung

• Terminologie






• Ausblick

36

Der Modularisierungsansatz von Corsten ist eine Strukturierungshilfe für die Identifikation von Interdependenzen von Business Services. Die Methoden zur Modulbildung können auf Business Services übertragen werden.

• Ansatz von Corsten für die Dienstleistungsmodularisierung eignet sich grundsätzlich für eine Übertragung. Dieser bedarf aber eine spezifischen Adaption in Bezug auf die Definition der Abhängigkeitsverhältnisse.

• Weiterer Forschungsbedarf– Höherer Systematisierungsgrad der Abhängigkeiten, hierbei können die Dimensionen nach Corsten,

wie gezeigt, als Suchrahmen dienen Explizite Berücksichtigung der Abhängigkeiten von der Granularität der Business Objekten als eine weitere

Dimensionen: Business-Service-Daten- Beziehungsmatrix. Differenzierung von Business Services, bspw. Bestandsservices, Funktionsservices, Prozessservices,

Interaktionsservices1)

Für die Bereitstellung von standardisierten zwischenbetrieblichen Business Services sollte eine Zuordnung der Business Services zu Referenzprozessen erfolgen. Auf diese Weise könnte eine Business Service Referenzlandkarte entstehen, anhand derer sich Best-of-Breed Anbieter bei der Vermarktung ihrer Business Services orientieren können

Modularisierungsentscheidung kann weiterhin abhängig von der Vermarktbarkeit des Business Services sein – Angebot eines Gold oder Platin Business Services aus Softwareanbietersicht

– Beherrschung des Business Service Lifecycle Managements, insbesondere Beantwortung der Frage, wann ein Business Services durch eine andere Version ersetzt werden kann.

Zusammenfassung und Ausblick

Quellen: 1)ENGELS 2008, S.163FF

37

AIER S., SCHÖNHERR M.(2007): Flexibilisierung von Organisations- und IT-Architekturen durch EAI. In: Aier S., Schönherr M. (Hrsg): Enterprise application integration. 2., durchges. Gito-Verl, Berlin: S. 1–59.12

ATKEARNEY(2010): A Blueprint to Fix IT-Complexity - A business-driven approach to managing IT applications. Studie.

BALZERT H.(1998): Lehrbuch der Software-Technik: Software-Management, Softwarequalitätssicherung, Unternehmensmodellierung. Spektrum Akad. Verl, Heidelberg,Berlin.

BLEICHER K.(2004): Das Konzept Integriertes Management. Visionen Missionen Programme. 7. Aufl. Campus-Verlag, Frankfurt am Main.

BUHL H. U., HEINRICH B., HENNEBERGER M., KRAMMER A.(2008): Service Science. WIRTSCHAFTSINFORMATIK 50. Jg. (1): S. 60.

BURR W.(2002): Service-Engineering bei technischen Dienstleistungen. Eine ökonomische Analyse der Modularisierung, Leistungstiefengestaltung und Systembündelung. Deutscher Universitäts-Verlag, Wiesbaden.

CORSTEN H., DRESCH K.-M., GÖSSINGER R.(2006): Modularisierung von Dienstleistungen. Eine koordinationsorientierte Analyse. Univ. Lehrstuhl für Produktionswirtschaft, Kaiserslautern.

CORSTEN H., DRESCH K.-M., GÖSSINGER R.(2008): Problemspezifische Modifikation der Design-Structure-Matrix im Kontext der Modularisierung von Dienstleistungen. Univ. Lehrstuhl für Produktionswiss, Kaiserslautern.

CORSTEN H., GÖSSINGER R.(2007): Modularisierung von Logistikdienstleistungen. Lehrstuhl für Produktionswirtschaft Univ, Kaiserslautern.

ENGELS G.(2008): Quasar Enterprise. Anwendungslandschaften serviceorientiert gestalten. 1. dpunkt-Verl., Heidelberg.

GRONAU N., LÄMMER A., ANDRESEN K.(2007): Entwicklung wandlungsfähiger Auftragsabwicklungssysteme. In: Gronau N., Lämmer A., Andresen K. (Hrsg): Wandlungsfähige ERP-Systeme. Entwicklung, Auswahl und Methoden;. 2. GITO-Verl., Berlin: S. 47–65.

Literatur

38

HABERFELLNER R., DAENZER W. F.(1997): Systems engineering. Methodik und Praxis. 9. Verl. Industrielle Organisation, Zürich.

HANSCHKE I.(2011): Beherrschen der IT-Komplexität mihilfe von EAM. WIRTSCHAFTSINFORMATIK & MANAGEMENT(4).

HELFERICH A.(2010): Software mass customization. 1. Eul, Lohmar, Köln, Stuttgart.

HEUTSCHI R.(2007): Serviceorientierte Architektur - Architekturprinzipien und Umsetzung in die Praxis. Springer, Berlin [u.a.].

HOOGEWEEGEN, TEUNISSEN W. J., VERVEST P. H., WAGENAAR R. W.(1999): Modular Network Design: Using Information and Communication Technology to Allocate Production Tasks in a Virtual Organization*. Decision Sciences 30. Jg. (4): S. 1073–1103.

HULVEJ J.(2008): Integrierte Entwicklung von IT-Dienstleistungen: ein Konzept auf Basis des industrie-betrieblichen Ansatzes des Simultaneous Engineering, St. Gallen.

KINKEL S., LAY G., JÄGER A.(2007): Mehr Flexibilität durch Organisation. Mitteilungen aus der Produktionsinnovationserhebung(42).

LÖFFLER C.(2011): Service-Externalisierung. Ein wettbewerbsstrategisches Konzept im Management IT-basierter Dienstleistungen. 1. Gabler Verlag, Wiesbaden, Erlangen-Nürnberg.

MERTENS, P.;PAGEL, P.(2011): Ein Best-of-Breed-Ansatz erzeugt eine nicht beherrschbare Komplexität. WIRTSCHAFTSINFORMATIK & MANAGEMENT Ausgabe Nr.: 2011-03

OVERHAGE S., TUROWSKI K.(2007): Serviceorientierte Architekturen - Konzept und methodische Herausforderungen. In: Nissen V. (Hrsg): Service-orientierte Architekturen - Chancen und Herausforderungen bei der Flexibilisierung und Integration von Unternehmensprozessen. Deutscher Universitäts-Verlag, Wiesbaden: S. 3–19.

Literatur

39

PICOT A., FREUDENBERG H.(1998): Neue organisatorische Ansätze zum Umgang mit Komplexität. In: Adam D. (Hrsg): Komplexitätsmanagement. Gabler, Wiesbaden: S. 69–85.

RAMASWAMY R.(1996): Design and management of service processes: keeping customers for life. Addison-Wesley.

SCHMIDT C.(2009): Management komplexer IT-Architekturen. Empirische Analyse am Beispiel der internationalen Finanzindustrie. Technische Univ. Diss.--Darmstadt, 2009. Gabler Verlag, Wiesbaden.

SCHUH G.(2008): Modularisierung industrieller Dienstleistungen - Potenziale, Systematik, Methoden. 11. Dienstleistungsforum, Aachen.

SHOSTACK G. L.(1982): How to design a service. European Journal of Marketing 16. Jg. (1): S. 49–63.

STEWARD D.(1981): The design structure system: A method for managing the design of complex systems. IEEE Transactions on Engineering Management(3): S. 71–74.

TUROWSKI K.(2003): Fachkomponenten. Komponentenbasierte betriebliche Anwendungssysteme. Shaker, Aachen.

ULRICH K.(1995): The role of product architecture in the manufacturing firm. Research policy 24. Jg. (3): S. 419–440.

VOM BROCKE J.(2008): Serviceorientierte Architekturen - SOA. Management und Controlling von Geschäftsprozessen. Vahlen, München.

Literatur

Prüfung der Übertragbarkeit von Ansätzen zur Dienstleistungsmodularisierung auf den Anwendungsbereich IT

Modularisierung von betrieblichen Anwendungssystemen

Oliver Budde

Aachen, 13. Dezember 2011