Granularität von Services - Eine ökonomische Analyse

Transkript

1 Granularität von Services - Eine ökonoische Analyse Die Autoren Dr. Alexander Kraer 1 Prof. Dr. Bernd Heinrich 2 Dr. Matthias Henneberger 3 Dr. Florian Lautenbacher 4 Autorenadressen 1 Kernkopetenzzentru Finanz- und Inforationsanageent Prof. Dr. Hans Ulrich Buhl Universität Augsburg Augsburg Deutschland alexander.kraer@wiwi.uni-augsburg.de 2 Institut für Wirtschaftsinforatik, Produktion und Logistik Universität Innsbruck 62 Innsbruck Österreich bernd.heinrich@uibk.ac.at 3 Sieens IT Solutions and Services Richard-Strauss-Straße München Deutschland atthias.henneberger@sieens.co 4 SysTec-CAx GbH Agnes-Pockels-Bogen München Deutschland florian.lautenbacher@systec-cax.de 1

2 Granularität von Services - Eine ökonoische Analyse Zusaenfassung Serviceorientierte Architekturen werden für die Gestaltung von Anwendungs- und Unternehensarchitekturen intensiv diskutiert. Dennoch wurde die Frage nach einer adäquaten Granularität von Services unter ökonoischen Aspekten bisher kau erforscht. Je feiner die Granularität von Services zur Realisierung der Funktionen eines Prozesses gewählt wird, desto größer ist die Anzahl der notwendigen Services. Dadurch steigt der Kopositionsaufwand. Sehr grobgranulare Services hingegen besitzen den Nachteil, dass ihr Realisierungsaufwand höher ist und die Chance zur Mehrfachverwendung (bspw. in verschiedenen Prozessen) sinkt. I Beitrag wird daher ein Modell entwickelt, das die Entscheidung bezüglich der Granularität von Services unter ökonoischen Aspekten unterstützt und auf diese Weise bestehende Freiheitsgrade nutzt, die eine rein fachlich orientierte Festlegung der Granularität noch offenlässt. Das Entscheidungsodell wird a Fallbeispiel einer Bank deonstriert, u die Anwendbarkeit und den praktischen Nutzen zu veranschaulichen. Stichworte Serviceorientierte Architektur; Granularität; Metriken; Ökonoische Bewertung Granularity of Services - An econoic analysis Abstract Service-oriented architectures are widely discussed as a design principle for application and enterprise architectures. Nevertheless, an adequate granularity of services fro an econoical perspective has not yet been researched sufficiently. The finer the granularity to realize the functions of a process, the higher is the nuber of services and the ore effort has to be spent to copose the. In contrast, very course-grained services bear the disadvantages of higher ipleentation costs and lower reuse potential (e.g. in different processes). The decision odel proposed in this paper is to deterine an adequate granularity of services fro an econoical perspective. In this way degrees of freedo, which often exist for the choice of granularity after a doain analysis, can be used. We deonstrate the decision odel in the context of a financial services provider in order to illustrate its applicability and practical benefits. Keywords Service-oriented architecture; granularity; etrics; value-based software engineering Vorspann Die Wahl einer adäquaten Granularität von Services stellt auch ein ökonoisches Proble dar. Eine größere Anzahl an Services zur Realisierung der Funktionen eines Prozesses und dait feingranulare Services versprechen nicht nur einen geringeren Entwicklungs- und Pflegeaufwand sondern auch eine höhere Mehrfachverwendung der Services. Gleichzeitig steigt jedoch der Aufwand für die Koposition der (vielen) Services. I Beitrag wird diese Granularitätsfragestellung aufgegriffen. Hierzu werden zunächst drei verschiedene Metriken zur Granularitätsessung und danach ein ökonoisches Modell zur Optiierung der Servicegranularität vorgestellt. Dait werden bestehende Ansätze erweitert, die eine rein fachlich orientierte Festlegung der Granularität fokussieren. Die Analyse eines Praxisbeispiels verdeutlicht, dass ein ökonoisches Optiierungspotenzial bei der Realisierung einer Servicelandschaft vorhanden ist. 2

3 1 Problestellung Obwohl Serviceorientierte Architekturen (SOA) bereits seit gerauer Zeit diskutiert werden, ist die Frage nach einer adäquaten Granularität von Services unter ökonoischen Aspekten noch nicht zufriedenstellend beantwortet. Zwar wird oftals gefordert, dass Services grobgranularer als Objekte oder als Koponenten sein sollen und gleichzeitig unter fachlichen Gesichtspunkten zu gestalten sind (Henning 27; Krafzig et al. 25; Richter et al. 25). Jedoch bieten derartige Aussagen einen großen Gestaltungsspielrau. Dies ist insofern kritisch, da die Bedeutung der Granularitätsfrage in vielen Beiträgen ausdrücklich betont (siehe obige Quellen) und gar als Gretchenfrage bezeichnet wird (Melzer et al. 27, S. 33). Die Vor- und Nachteile grob- bzw. feingranularer Services lassen sich dabei grundsätzlich wie folgt abwägen (vgl. Aier 26; Erl 25, S. 557; Melzer et al. 27, S. 33): Je feingranularer, desto größer ist die Anzahl der Services bspw. zur Realisierung von Funktionen eines Prozesses und desto aufwändiger wird es, die (Vielzahl der) Services zur Prozessausführung zu koponieren. Grobgranulare Services besitzen dagegen den Nachteil, dass das Potenzial auf Mehrfachverwendung bspw. in verschiedenen Prozessen sinkt (vgl. auch Joachi et al. 211, S. 45). Dies birgt die Gefahr von Redundanz und einer hohen Variantenanzahl, da ehrere Services u. U. gleiche oder ähnliche Funktionen realisieren. Obwohl Services dann ier noch durch ihre Plattforunabhängigkeit, Verwendung von Standards, lose Kopplung etc. charakterisiert sind (Buhl et al. 28; Papazoglou 23; Papazoglou et al. 26), verschwindet ein entscheidender Vorteil: Wenn i Extrefall Services eine ähnliche (grobe) Granularität aufweisen wie onolithische Anwendungssystee, geht der (propagierte) Vorteil der ehrfachen Verwendung odularer Softwareartefakte und deren einfache Koposition zu neuen oder geänderten Prozessen verloren. Bislang wird in der Literatur die Frage nach der Servicegranularität priär aus fachlicher Sicht diskutiert (z. B. Albani et al. 28; Fiege 29; Winkler 27; Winter 23). Diese Frage stellt jedoch auch ein ökonoisches Proble dar: Wie granular sind Services zu entwickeln, dait der Aufwand für die Entwicklung, Koposition und Pflege der Services inial ist? Grundlage für eine solche ökonoische Betrachtung ist es, geeignete Metriken zu entwickeln, u Granularität zunächst überhaupt nachvollziehbar essen zu können. Zu beiden Punkten will die Arbeit einen Beitrag liefern. Sie folgt dait der wachsenden Erkenntnis, dass ökonoische Aspekte stärker als bisher für die Syste- und Servicegestaltung zu berücksichtigen sind (vgl. Value-based Software-Engineering; bspw. Biffl et al. 25). Die Arbeit gliedert sich wie folgt: In Abschnitt 2 werden Arbeiten diskutiert, die sich it der Identifikation und Gestaltung von Services (und Koponenten) auf Basis fachlicher Kriterien befassen. Diese fachlichen Vorgaben bilden dabei den Ausgangspunkt für die weitere ökonoische Betrachtung. In Abschnitt 3 werden für die Messung der Granularität verschiedene 3

4 Metriken definiert. Diese sind Voraussetzung, u nachvollziehbare Aussagen wie Realisierung durch fein- oder grobgranulare Services überhaupt treffen zu können. Danach wird ein Modell entwickelt, das die Entscheidung über die Granularität von Services unter ökonoischen Kriterien unterstützt. Dieses Modell bzw. seine Anwendbarkeit wird in Abschnitt 4 a Fallbeispiel einer Bank deonstriert. Abschnitt 5 fasst die wesentlichen Ergebnisse zusaen, würdigt diese kritisch und gibt einen Ausblick auf den zukünftigen Forschungsbedarf. 2 Einordnung in die Literatur In der Literatur lassen sich eine Reihe von Arbeiten zur Identifikation und Gestaltung von Services insbesondere anhand fachlicher Kriterien finden. Dabei können Services als (Software-)Artefakte einer Systelandschaft verstanden werden, die Funktionen kapseln (Schelp und Winter 28, S. 6) und sich durch Eigenschaften wie Modularität und lose Kopplung sowie definierte Schnittstellen auszeichnen (Krafzig et al. 25, S. 59; zu den Eigenschaften von Services vgl. bspw. Buhl et al. 28, S. 62; Erl 25, S. 37,). Häufig wird eine Unterscheidung zwischen technischen und fachlichen Services getroffen, wobei letztere koponierbare Funktionen eines Geschäftsprozesses realisieren und eist als Business oder Enterprise Services bezeichnet werden (vgl. Melzer 27, S. 32; Schelp und Winter 28, S. 7). Wir beschränken uns i Folgenden auf Letztere, da sich gerade hier die Frage nach einer Mehrfachverwendung in unterschiedlichen Prozessen - und dait die Frage nach der richtigen Granularität - stellt. Unter Granularität verstehen wir dabei zunächst, in Anlehnung an die Literatur, die Anzahl bzw. den Ufang der durch einen Service realisierten Funktionen (Erl 27; Galster und Bucherer 28, S. 4; Thoas et al. 21, S. 366). Bspw. schreiben Papazoglou und van den Heuvel (26, S. 423): Service granularity refers to the scope of functionality exposed by a service. Nach Boerner und Goeken (29) beschreibt Granularität ebenso den funktionalen Ufang eines Service. Diese kurze Diskussion des Granularitätsbegriffs wird in Abschnitt 3.2 nochals it der Messung der Granularität anhand von Metriken aufgenoen. Für unsere Untersuchung sind neben Arbeiten, die sich originär it der Identifikation und Gestaltung von Services befassen, auch Arbeiten zur Identifikation von Koponenten relevant (für einen Vergleich von Ansätzen zur Koponentenidentifikation vgl. Birkeier und Overhage 29 sowie zur Serviceidentifikation vgl. Birkeier et al. 28). Tabelle 1 stellt ausgewählte Beiträge beider Bereiche dar und greift hierfür in Teilen auf die Klassifikation nach Birkeier und Overhage (29) sowie Birkeier et al. (28) zurück. Danach werden zunächst die Arbeiten zur Koponentenidentifikation sowie anschließend diejenigen zur Serviceidentifikation diskutiert. 4

5 Tabelle 1: Ausgewählte Ansätze zur Identifikation von Koponenten und Services Autoren Zielsetzung Vorgehen Gegenstand Definition von Granularität Vorgaben zur Festlegung der Granularität von Koponenten bzw. Services Fokus Werkzeugunterstützung Art der Validierung Aier 26 Identifikation von Services als Gruppierung zusaengehöriger Eleente einer Unternehensarchitektur Autoatisiertes Clustering- Verfahren analysiert Beziehungen zwischen den Eleenten einer Ereignisgesteuerten Prozesskette Services Anzahl der durch einen Service realisierten Funktionen (iplizit) Granularität abhängig von der Paraeterwahl des Clustering- Verfahrens (keine Optiierung) Fachlich Ja Fiktives Fallbeispiel Albani et al. 28 Identifikation von Geschäftskoponenten, die fachlich zusaengehören Verfeinerung von Doänenodellen zu Koponenten unter Zuhilfenahe von Heuristiken (Top Down) Koponenten Keine explizite Definition von Granularität Präferenzen zu Dekopositions- und Gruppierungsregeln Fachlich Ja Reales Fallbeispiel Arsanjani et al. 28 Entwicklung einer Serviceorientierten Architektur unter Berücksichtigung des kopletten Lebenszyklus von Services Top Down-Analyse der Doäne sowie von Geschäftszielen (Fokus) bei zusätzlicher Botto Up- Analyse existierender Systee Services Keine explizite Definition von Granularität Keine Vorgaben Fachlich Nein Darstellung von Fallbeispielen und Beschreibung gesaelter Best Practices Beverungen et al. 28 Fiege 29 Her et al. 28 Ki und Chang 24 Identifikation von Services auf Basis von Geschäftsprozessen anhand eines Vorgehensodells Modellierung einer Serviceorientierten Architektur it Hilfe von Axioatic Design unter der Wahrung der Architekturziele lose Kopplung, hohe Autonoie und ausgewogene Granularität Identifikation von Services ausgehend von Anwendungsfällen Identifikation von Koponenten unter Berücksichtigung von Kohäsion und Kopplung Dekoposition von Geschäftsprozessen unter Berücksichtigung von Sichtbarkeitsaspekten bzgl. Geschäftspartner (Top Down) Axioatic Design: Strukturiertes Top Down-Vorgehen it de Ausgangspunkt Geschäftsprozesse 5-stufiges Vorgehen zur Ableitung von Servicespezifikationen aus Anwendungsfällen und Geschäftsprozessen Clustering-Verfahren auf Basis von Anwendungsfalldiagraen (Botto Up) Services Services Services Koponenten Keine explizite Definition von Granularität Granularität beschreibt den Ufang und die Art der Funktionen. Die funktionale Koplexität wird dabei anhand der Sue der Datenflüsse der Operationen eines Service geessen. Keine explizite Definition von Granularität Anzahl der realisierten Anwendungsfälle (iplizit) Unterscheidung in Prozessund Basisservices, aber keine detaillierten Vorgaben Dekopositionsregeln und Modellierungsrichtlinien Granularität wird bereits für Anwendungsfälle bestit. Sind diese wiederu in andere Anwendungsfälle inkludiert, wird ein Subprozess und daraufhin ein so genannter Coposite-Service identifiziert. Granularität abhängig von der Paraeterwahl des Clustering- Verfahrens (keine Optiierung) Fachlich Nein Reales Fallbeispiel Fachlich Nein Drei reale Fallbeispiele bei Unternehen Fachlich Nein Fallbeispiel Fachlich, z. T. Technisch Nein Keine (nur Diskussion und Bewertung i Vergleich zu anderen Ansätzen) 5

6 Lee et al. 21 Offerann 28 Wang et al. 26 Identifikation von Koponenten unter Berücksichtigung von Kohäsion und Kopplung Konzeption betrieblicher Software it einer Serviceorientierten Architektur Identifikation von Koponenten unter besonderer Berücksichtigung der Stabilität des Geschäftsodells Clustering-Verfahren auf der Basis von Klassendiagraen (Botto Up) Top Down-Analyse des Unternehens konsolidiert it Botto Up-Analyse von Bestandssysteen Verfahren aufbauend auf de sogenannten Feature Tree, der die Features (einer Doäne) und deren Abhängigkeit darstellt und nach deren Stabilität differenziert Koponenten Services Koponenten Anzahl der Klassen (iplizit) Keine explizite Definition von Granularität Anzahl bereitgestellter Features / Funktionen oder ipleentierter Entitäten Granularität abhängig von der Kohäsion und Kopplung der Klassen und der Paraeterwahl des Clustering-Verfahrens Keine Vorgaben Optiierung der Granularität auf Basis des Feature Tree Fachlich / Technisch Fachlich Fachlich und Ökonoisch (siehe auch Wang et al. 25) Nein, nur Clustering- Algorithus Ja (aber nur zur Serviceodellierung, nicht zur Granularitätsoptiierung) Als "Future Work" deklariert Reales Fallbeispiel Reales Fallbeispiel und Laborexperient Qualitativer Vergleich it anderen Identifikationsansätzen und Veranschaulichung dieses Vergleichs an eine kleinen Beispiel Winkler 27 Identifikation von Services unter Berücksichtigung von Mehrfachverwendung Funktionale Analyse durch schrittweise Zerlegung von Aktionen in Aktivitätsdiagraen (Top Down) Services Orientiert an den Ebenen der Zerlegung (iplizit) Dekopositionsregeln Fachlich Nein Reales Fallbeispiel Winter 23; Schelp und Winter 28 Identifikation von Services, die fachlich zusaengehören Analyse der Beziehungen zwischen Datenobjekten und Funktionen und deren Gruppierung anhand einer Matrix, ehrdiensional Services Funktionsufang eines Service (iplizit) Dekopositions- und Gruppierungsregeln Fachlich Nein Reale Fallbeispiele it vier Unternehen 6

7 Arbeiten zur Koponentenidentifikation Albani et al. (28) identifizieren in ihre Ansatz Business Coponent Identification (Geschäfts-)Koponenten auf der Basis von Inforationsobjekten und Prozessodellen sowie den Beziehungen zwischen beiden. Mit Hilfe eines Clustering-Verfahrens wird eine Partitionierung von Koponenten autoatisiert vorgenoen, wobei Präferenzen geäußert werden können. Diese sind i Ansatz ebenso berücksichtigt, wie die Art und Häufigkeit der Beziehungen zwischen Inforationsobjekten und Aktionen des Prozessodells. Dabei werden ebenfalls die Ziele einer hohen Kohäsion und niedrigen Kopplung bei der Koponentenidentifikation berücksichtigt. Daneben wird i Koponentenbereich auch von anderen Clustering-Ansätzen die Granularitätsfragestellung als explizites Entwurfsziel verfolgt (vgl. Ki und Chang 24; Lee et al. 21). Diese basieren auf atheatisch-statistischen Verfahren, welche die Kohäsion bzw. Kopplung einzelner Eleente eines Systes - oft Klassen i Sinne der Objektorientierung - bspw. anhand der Anzahl wechselseitiger Beziehungen essen und daraus lose gekoppelte Cluster ableiten, die jeweils eine hohe Kohäsion besitzen. Diese Cluster bilden anschließend den Vorschlag für die Koponenten. Denach werden je nach Paraeterwahl für das Clustering-Verfahren Koponenten unterschiedlicher Granularität identifiziert. Auf die konkrete Wahl der Paraeter, insbesondere unter ökonoischen Aspekten, wird in den genannten Beiträgen nicht eingegangen. Wang et al. (26) entwickeln ihren Ansatz STCIM (Stability Based Coponent Identification Method) it der Zielsetzung, Koponenten priär unter Berücksichtigung der unterschiedlichen Stabilität (von Teilen) des Geschäftsodells zu identifizieren. Stabilität als Größe wird dabei als der Ufang und die Anzahl von geschäftsbezogenen Änderungen definiert, d. h. je weniger Änderungen vorliegen, desto stabiler sind die Teile des Geschäftsodells und desto weniger üssen die zugeordneten Koponenten angepasst werden. Stabilität wird denach als Indikator für die Gestaltung grobgranularer Koponenten gesehen und vice versa (bspw. Wang et al. 26, S. 2). U diese Zielsetzung zu erreichen, definieren Wang et al. (26) zunächst eine Baustruktur (so genannter Feature Tree ), die das Ergebnis einer fachlichen Analyse der Doäne widerspiegelt. Diese Baustruktur enthält neben den Features (i Sinne von Funktionen) auch deren Beziehungen. D. h. Features werden schrittweise verfeinert, u die verschiedenen Ebenen des Baues zu definieren. In Abhängigkeit davon, auf welcher Ebene des Baues eine Koponente realisiert wird, ergeben sich Koponenten unterschiedlicher Granularität. Daneben sind speziell die von Wang et al. (26, S. 6) explizit diskutierten ökonoischen Größen Kopositions- bzw. Änderungsaufwand interessant. So wird angeführt, dass je grobgranularer Koponenten sind, desto geringer ist deren Kopositionsaufwand und vice 7

8 versa. Dagegen steigt der Änderungsaufwand, je grobgranularer Koponenten sind und vice versa. Beides wird jedoch ausschließlich arguentativ festgestellt, da der exakte funktionale Zusaenhang zur Berechnung, bspw. des Kopositionsaufwands, nicht definiert oder ausgeführt wird. Interessanterweise werden auch die Aufwandsgrößen i eigenen Ansatz STCIM nicht weiter betrachtet. Darüber hinaus wird in Wang et al. (25, S. 231) ein Optiierungskalkül für die Identifikation und Gestaltung von Koponenten vorgestellt. Hier werden verschiedene Zielgrößen für eine Koponente c definiert, wie bspw. Reusability (Variable R(c)), Reuse Cost (RC(c)) oder Reuse efficiency (RE(c)) und deren jeweilige Zielvorschrift (Miniierung oder Maxiierung). Diese Zielgrößen werden danach in einer einzigen Zielfunktion integriert, welche über die Menge aller Koponenten c zu axiieren ist. Jedoch wird leider auch in (Wang et al. 25, S. 231) - analog zu oben - für die einzelnen Zielgrößen kein funktionaler Zusaenhang zu deren Berechnung definiert. Insofern ist nicht nachvollziehbar, welche Eigenschaften und Bestandteile das ökonoische Kalkül besitzt bzw. wie es für die Koponentenidentifikation genau zu nutzen ist. Daneben ist ebenso anzuerken, dass die Zielgrößen über unterschiedliche Maßeinheiten verfügen. Bspw. dürfte die Zielgröße Reuse Cost (RC(c)) eine Geldeinheit als Maßeinheit besitzen, wohingegen Größen wie Cohesion(c) oder Coupling(c) als seantische Nähe (ohne Maßeinheitsangabe) definiert sind. Inwiefern die Verknüpfung der einzelnen Zielgrößen in der dargestellten Zielfunktion zu eine interpretierbaren Gesatergebnis führt wird daher nicht klar. Arbeiten zur Serviceidentifikation I Gegensatz zu einzelnen Ansätzen der Koponentenidentifikation zeigt die Tabelle 1, dass die Serviceidentifikation bisher fast ausschließlich fachlich diskutiert wird, wobei Regeln zur Festlegung der Granularität nur zu Teil explizit angegeben werden. Aier (26) schlägt bspw. einen Clustering-Algorithus zur fachlich orientierten Modularisierung einer Anwendungssystelandschaft vor. Dait soll u. a. auch die Servicegranularität bestit werden. Winter (23) lehnt sich an den Business Systes Planning-Ansatz von IBM (1984) an und schlägt drei Diensionen zur Strukturierung von Anwendungssystelandschaften vor (Funktion, Inforationsobjekt, Leistung/Organisation), was in Nachfolgearbeiten (vgl. Schelp und Winter 28) auch auf die Serviceidentifikation übertragen wird. I Rahen des SOMA-Ansatzes (Service-Oriented Modeling Architecture) von IBM (Arsanjani et al. 28) wie auch bei Offerann (28) erfolgt die Identifikation und Gestaltung von Services sowohl Botto Up, ausgehend von bestehenden Anwendungen oder Koponenten, als auch Top Down, z. B. ausgehend von Prozessodellen oder Geschäftszielen. Winkler (27) zerlegt hingegen Aktivitätsdiagrae in ehreren iterativen Schritten in atoare Basisaktionen oder -funktionen, u zu entscheiden, welche davon einzeln oder integriert in 8

9 eine Service realisiert werden sollen. Dait ähnelt dieser Ansatz de Vorgehen von Her et al. (28), die ebenfalls aus Prozessodellen und Anwendungsfällen durch iterative Verfeinerung Services identifizieren. Beverungen et al. (28) berücksichtigen zusätzlich, ob ein Prozessschritt auch für Geschäftspartner sichtbar sein soll, u Services zu identifizieren. Fiege (29) überträgt das sogenannte Axioatic Design, eine aus der industriellen Produktion staenden Verfahren, auf die Serviceidentifikation. I Sinne eines Top Down- Verfahrens werden ögliche Lösungen zur Erfüllung der vorab festgelegten Anforderungen durch Zuordnung und Dekoposition in For von Entwurfsatrizen abgebildet. Die dort dargestellten Beziehungen zwischen funktionalen Anforderungen und Designparaetern sollen die Identifikation und Gestaltung von Services unter der Präisse loser Kopplung, hoher Autonoie und ausgewogener Granularität eröglichen. Bei vielen der oben diskutierten Ansätze bestehen nach ihrer Anwendung i. d. R. noch Freiheitsgrade für die Serviceidentifikation. Je nachde wie stark bspw. Aktivitätsdiagrae verfeinert oder Funktionen zerlegt werden, können Services unterschiedlicher Granularität entstehen. Hier knüpft die vorliegende Arbeit it der Frage an, wie diese noch vorhandenen Freiheitsgrade bei der Servicegranularität unter ökonoischen Aspekten zu nutzen sind. Insofern werden die obigen, fachlich orientierten Arbeiten erweitert. Dies entspricht eine zweistufigen Vorgehen: 1. Die Anwendung eines fachlich orientierten Ansatzes zur Serviceidentifikation führt zu jeweils alternativen Servicekandidaten (i Sinne von Freiheitsgraden), die sich i Ufang der realisierten Funktionen unterscheiden. 2. Basierend auf der Erittlung von Entwicklungs- und Pflegeaufwand und unter Berücksichtigung des Potenzials auf Mehrfachverwendung wird eine ökonoische Optiierung durchgeführt, welche die vorhandenen Freiheitsgrade der fachlichen Serviceidentifikation nutzt. Teilweise sehen Ansätze zur Modellierung von SOA bereits explizit einen Schritt zur Konsolidierung öglicher Servicekandidaten vor (bspw. Offerann 28, S. 467), der u eine ökonoische Bewertung erweitert werden kann. Eine derartige ökonoische Betrachtung bietet jedoch bisher keiner der untersuchten Ansätze. Dies gilt auch für den Koponentenbereich. Obwohl insbesondere der Arbeit von Wang et al. (25) bereits einzelne Aufwandsgrößen und ein Kalkül zugrunde liegen, sind diese Ausführungen zur Beantwortung der Frage der Servicegranularität nur begrenzt geeignet, da ökonoische Zielgrößen und Zusaenhänge (wie hängt bspw. der Aufwand zur Servicerealisierung vo Funktionsufang ab?) nicht behandelt oder konkretisiert werden. I Folgenden wird daher ein Ansatz vorgestellt, der dies berücksichtigt. 9

10 3 Granularität von Services - Eine ökonoische Analyse Die Definition des Funktionalitäts- und Servicegraphs in Abschnitt 3.1 bildet den Ausgangspunkt für die danach vorgestellten Granularitätsetriken und die ökonoische Betrachtung i Abschnitt Funktionalitäts- und Servicegraph (FSG) Einige der obigen Ansätze schlagen zur Serviceidentifikation eine Aggregation oder Disaggregation von Funktionalitäten unter fachlichen Aspekten vor (i Weiteren wird der Begriff der Funktionalität äquivalent zu de der Funktion verwendet). Dabei stellt sich die Frage, wie das Ergebnis dieser Analyse für unsere Zwecke geeignet abzubilden ist. I Folgenden wird ein Graph - der FSG - zur Repräsentation der Ergebnisse definiert. Analog zu einigen fachlichen Ansätzen soll der FSG die Disaggregationsbeziehungen zwischen Funktionalitäten repräsentieren. Der Betrachtungsgegenstand Service bedarf jedoch - i Vergleich bspw. zu Wang et al. (26) - u. a. folgender Erweiterung: 1. U eine Mehrfachverwendung von Funktionalitäten darstellen zu können, verwenden wir einen gerichteten, azyklischen Graphen anstatt eines Baues. Bei Wang et al. (26, S. 4) ist der Feature Tree dagegen analog zu den Eigenschaften eines Baues dadurch gekennzeichnet, dass eine Sohnfunktionalität einschränkend nur eine Elternfunktionalität besitzen darf. 2. Services können zur Durchführung unterschiedlicher Prozesse koponiert werden. Dazu uss der Graph ehrere Quellknoten (Funktionalitäten ohne eingehende Kanten) enthalten können, die als Prozesse zu interpretieren sind. Bei Wang et al. (26, S. 4) besitzt der Feature Tree einschränkend nur eine Wurzel, d. h. ehrere Prozesse sind nicht als Wurzelknoten darstellbar. Die Annahen und Definitionen für den FSG lauten denach wie folgt: (A1) Der FSG ist ein gerichteter, azyklischer Graph G=(N, E) it den Funktionalitäten M it M N als Knoten sowie den Disaggregationsbeziehungen ( i, j ) E zwischen den Funktionalitäten i und j als gerichtete Kanten. Die Disaggregation einer Funktionalität i in die Funktionalitäten j,, j+n erfolgt disjunkt und vollständig. Eine gerichtete Kante ( i, j ) bedeutet Funktionalität j ist Teil der Funktionalität i. I FSG sind alle Funktionalitäten und Disaggregationsbeziehungen der betrachteten fachlichen Doäne abgebildet. Jeder Quellknoten des FSG, d. h. ein Knoten ohne eingehende Kanten, wird als Prozess bezeichnet (it P als Menge aller Prozesse, P M). Jede Senke des FSG, d. h. ein Knoten ohne ausgehende Kanten, wird als Basisfunktionalität bezeichnet (it B als Menge aller Basisfunktionalitäten, B M). Die inneren Knoten des Graphen, also Funktionalitäten, die we- 1

11 der Prozesse noch Basisfunktionalitäten sind, werden vorausgehende Funktionalitäten genannt. V M ist die Menge aller vorausgehenden Funktionalitäten. Zude wird eine offene Folge von Knoten und Kanten, (, 1 ),, ( n-1, n ), n als Weg w(, n ) bezeichnet, it de Anfangsknoten und de Endknoten n. Ist der Anfangsknoten eines Weges ein Prozess (d. h. P) und der Endknoten eine Basisfunktionalität (d. h. n B), so entspricht dies eine Gesatweg. Die Länge d(, n ) eines Weges w(, n ) ist i azyklischen FSG definiert als die Anzahl der zugehörigen Kanten des Weges w. Die Disaggregationsbeziehungen zwischen Funktionalitäten und dait die Wege lassen sich anhand einer Adjazenzatrix I MM : M x M darstellen, wobei I 1 genau dann gilt, wenn ( i, j ) E existiert. Ansonsten gilt I. i, j i, j I FSG soll auch das Ergebnis des späteren ökonoischen Entscheidungsodells dargestellt werden, d. h. welche Funktionalitäten konkret it eine Service zu realisieren sind: (A2) Jeder Service s i S it S N wird genau einer Funktionalität j V B durch eine gerichtete Kante (s i, j ) E zugeordnet. Ein Service s i realisiert die Funktionalität j vollständig, d. h. auch alle Funktionalitäten k, für die es einen Weg w( j, k ) gibt und bietet genau diese Funktionalität über seine Schnittstelle an. Eine Funktionalität j für die gilt $ (s i, j ) E heißt realisierte Funktionalität. Zur Mehrfachrealisierung einer Funktionalität kot es dann, wenn eine Funktionalität direkt oder über vorausgehende Funktionalitäten durch verschiedene Services realisiert wird. Die Matrix I SM : S x M repräsentiert die Servicezuordnung, wobei I 1 genau dann gilt, wenn (s i, j ) E it s i S und j V B. Ansonsten gilt I. s i, j s i, j Die obigen Ausführungen sind in Abbildung 1 anhand eines einfachen Beispiels veranschaulicht. Als Ergebnis einer fachlichen Analyse liegt hier die Disaggregation zweier Prozesse und 1 in die Funktionalitäten 1 und 4 bzw. 11 vor usw. Die Funktionalität 9 wird dabei in beiden Prozessen benötigt. Eine ögliche Realisierung der Funktionalitäten durch die Services s 1 bis s 5 ist ebenfalls dargestellt. Der Service s 3 realisiert bspw. die Funktionalität 6 direkt und dait auch die Basisfunktionalitäten 8 und 9. Da Service s 5 über die Funktionalität 11 ebenfalls 9 realisiert, wird 9 i Beispiel zweifach ugesetzt. 11

12 Abbildung 1: Funktionalitäts- und Servicegraph (FSG) i Beispiel 3.2 Granularitätsetriken Bestehende Ansätze treffen zwar Aussagen zur Granularität - wie bspw. grob- vs. feingranulare Services - und z. T. ergibt sich das jeweilige Begriffsverständnis iplizit aus de Kontext, nur wenige definieren jedoch diesen Begriff explizit oder foral (vgl. Tabelle 1). I Folgenden stellen wir daher drei Granularitätsetriken vor, die unterschiedliche Sichtweisen operationalisieren und diskutieren jeweilige Vor- und Nachteile. Mit Hilfe derartiger Metriken soll die Granularität verschiedener Services geessen und dait verglichen werden können. Für die Metrikberechnung kann dabei auf den FSG zurückgegriffen werden. Ausgangspunkt ist ein Service s i, der eine Funktionalität j realisiert und dessen Granularität zu bestien ist. Tiefenaß Zuerst wird ein Tiefenaß vorgestellt. Es gibt grundsätzlich an, an welcher Position sich eine realisierte Funktionalität (Service) auf eine (Gesat)Weg i FSG befindet. Eine einfache Angabe der Weglänge vo Prozess zur realisierten Funktionalität reicht jedoch nicht aus. Dies hat zwei Gründe: Erstens ist dieser Wert wenig aussagekräftig, wenn die Längen der Gesatwege i FSG stark unterschiedlich sind. So könnte für zwei Services die gleiche Granularität berechnet werden, obwohl der eine Service eine Basisfunktionalität realisiert, während der andere Service eine vorausgehende Funktionalität it vielen nachfolgenden Funktionalitäten realisiert. Zweitens ist die Angabe einer Weglänge bei eine Graph - anstatt eines Baus - nicht eindeutig, wenn eine Funktionalität in ehreren Wegen enthalten ist. Beides otiviert die Entwicklung folgender Metrik als Operationalisierung des Tiefenaßes: 12

13 Grundlage der Metrik ist die Weglänge vo Prozess bis zur realisierten Funktionalität i Verhältnis zur Gesatweglänge. Für eine realisierte Funktionalität j, die Teil eines Gesatweges w( p, n ) ist, wird so der Wert d( p, ) j 1 zw = berechnet. I Zähler als ax[ 1, d( p, n) 1] auch i Nenner ist eins abzuziehen, da die Weglänge jeweils ausgehend vo Prozess p P berechnet wird. Der Wertebereich von z w ist auf das Intervall [; 1] noriert. So führt die Realisierung einer Basisfunktionalität (axial feingranular) zu Wert eins, während der Wert null bei einer Realisierung der direkt de Prozess p nachfolgenden Funktionalität resultiert (axial grobgranular). Der Wert Z W wird für alle Wege berechnet, in denen die realisierte Funktionalität j enthalten ist. Über diese Werte wird anschließend das arithetische Mittel gebildet. Sei W die Menge aller Wege w, die j enthalten, so gilt für die Tiefenetrik: g T s i ww z W w Die Metrik behält dabei die Norierung auf den Wertebereich [; 1]. Breiten- und Tiefenaß Das Tiefenaß besitzt u. a. dann Nachteile, falls eine realisierte Funktionalität viele direkte und indirekt nachfolgende Funktionalitäten besitzt. Hier liefert das Breiten- und Tiefenaß aussagekräftige Werte. Ein Service ist denach uso grobgranularer, je ehr Funktionalitäten er insgesat (direkt und indirekt) realisiert. Maxial feingranular ist der Service hingegen wieder, wenn er eine Basisfunktionalität realisiert. Grundlage dieser Metrik ist die Anzahl n der durch einen Service direkt oder indirekt reali- j sierten Funktionalitäten. Dieser Wert wird durch n a geteilt, it a als direkt de Prozess nachfolgende Funktionalität, und von eins subtrahiert: n 1 j z w 1. Analog zu ax(1; n 1) Tiefenaß ist der Wertebereich auf [; 1] noriert. Wird eine Basisfunktionalität direkt durch einen Service realisiert, ergibt sich ein Wert von eins (wegen n 1 ). I Falle der Realisierung einer direkt de Prozess nachfolgenden Funktionalität entsprechen sich die Werte j a ( n n ). Daraus resultiert z w gleich null (außer bei einer Basisfunktionalität). Die Norierung auf [; 1] ist zugleich auch ein Vorteil gegenüber den Metriken von Wang et al. (26, S. 5-6), bezogen auf Features und die dort definierte Baustruktur, sowie gegenüber Haesen et al. (28) und deren Default Functionality Granularity, da hier jeweils eine Metrik ohne Norierung vorgeschlagen wird. Diese fehlende Norierung schränkt den Vergleich der Metrikwerte verschiedener Services ein. j a 13

14 Falls eine Funktionalität j wiederu Bestandteil ehrerer Wege ausgehend von verschiedenen Quellknoten p oder vorangehenden Funktionalitäten a ist, kann - analog zu oben - das arithetische Mittel g BT über die Werte dieser Wege gebildet werden. Beide bisherigen Maße sind zwar - bspw. i Vergleich zur Messung bei Wang et al. (26) - bereits aussagekräftiger. Sie stützen sich jedoch rein auf die Anzahl der Funktionalitäten. D. h., auch wenn zwei Services nach den beiden obigen Maßen eine identische Granularität aufweisen, können sie sich dennoch anhand des zu realisierenden Funktionalitätsufangs und bspw. des dait verbundenen Entwicklungsaufwands wesentlich unterscheiden. Letzteres wird nicht transparent, was zu eine dritten Maß führt. Größenaß Die Frage, wie der Ufang von Funktionalitäten geessen bzw. ex ante vor Realisierung geschätzt werden kann, wird in der Literatur bspw. i Bereich der Aufwandsschätzung untersucht. Hier werden Maßeinheiten wie Lines of Code (LOC) oder Function Points genutzt. LOC werden i COCOMO-Ansatz, eine Verfahren zur Aufwandsschätzung von Softwareentwicklungsprojekten, verwendet und geben an, wie viele Zeilen Quellcode für ein Progra ggf. geschrieben werden üssen (vgl. Boeh et al. 2, Wehrann und Gull 26). In COCOMO gehen zur Berechnung der erforderlichen Personenonate die LOC der einzelnen zu ipleentierenden Softwarebestandteile ein, die it Aufwandsultiplikatoren, Skalenfaktoren sowie einzelnen Kalibrierungsfaktoren verrechnet werden. Zur Erittlung der LOC können entweder historische Daten aus anderen Projekten, Expertenschätzungen oder algorithische Verfahren Verwendung finden. Aufwandsfaktoren werden danach ultiplikativ und Skalenfaktoren exponentiell it den zugehörigen LOC verrechnet. I später dargestellten Fallbeispiel wurden LOC gewählt, wobei auch andere Maßeinheiten sowohl in der Metrik als auch i Entscheidungsodell verwendbar sind. Voraussetzung für das Größenaß ist die Angabe des Ufangs func size j (bspw. in LOC) für eine Basisfunktionalität j. Der Ufang vorausgehender Funktionalitäten ergibt sich dann jeweils aus de Ufang der nachfolgenden Funktionalitäten (disjunkte und vollständige Disaggregation geäß (A1)) zuzüglich des Ufangs der Kopositionslogik cop size j (vgl. dazu auch Erl 27). Letztere enthält u. a. Inforation für die Steuerung, die Integration und den Aufruf nachfolgender Funktionalitäten. Der Ufang size j einer Funktionalität j ergibt sich dait zu: size j size cop j size func j M i1 I j, i size i falls B falls V j j Auch hier ist wiederu eine Norierung öglich. Für eine realisierte Funktionalität j, die Teil eines Gesatweges w( p, n ) it p, ( p, a ),, ( n-1, n ), n ist, resultiert 14

15 size j zw 1. Gilt j = a, d. h. eine direkt de Prozess p nachfolgende Funktionalität size a a wird realisiert, dann ist z W für diese axial grobgranulare Servicerealisierung null. Bei Realisierung einer Basisfunktionalität wird der Wert z W größer. Man erhält einen Wertebereich für z W von [; 1[. Ist eine Funktionalität j wiederu Bestandteil ehrerer Wege, kann - analog zu oben - das arithetische Mittel g G über die Werte dieser Wege gebildet werden. In Ergänzung zu den beiden ersten Maßen können die Aussagen des Größenaßes vor alle dann einen Mehrwert liefern, wenn sich die Ufänge der einzelnen Funktionalitäten stark unterscheiden. Tabelle 2 fasst die Metriken zusaen: Tabelle 2 Granularitätsetriken Maß Beschreibung und Definition Eignung / Einschränkungen für den Einsatz Verdeutlichung der Idee der konkreten Metrik (Beispiele) Tiefenaß Metrik isst die Granularität eines Service (realisierte Funktionalität) anhand seiner Position i FSG: Weglänge vo Prozess bis zur realisierten Funktionalität i Verhältnis zur Gesatweglänge 1. Die Metrik bezieht sich auf die Wege i FSG und führt dann zu gut interpretierbaren Ergebnissen, falls zwei oder ehrere realisierte Funktionalitäten die (annähernd) gleiche Anzahl direkt und indirekt nachfolgender Funktionalitäten besitzen. 2. Sind Funktionalitäten hinsichtlich ihres Ufangs (bspw. LOC) stark unterschiedlich, so ist die Metrik wenig aussagekräftig. Aufgrund verschieden langer Gesatwege ist der Service s 2 it g T (s 2 )=,39 nach der Metrik für das Tiefenaß grobgranularer als der Service s 1 it g T (s 1 )=1. Ein bloßer Vergleich der Anzahl vorausgehender Funktionalitäten würde hier die gleiche Granularität ausweisen. Breitenund Tiefenaß Metrik isst die Granularität eines Service anhand der Anzahl direkt und indirekt nachfolgender Funktionalitäten 1. Metrik führt zu gut interpretierbaren Ergebnissen, falls Servicerealisierungen verglichen werden, die sich in der Anzahl direkter und indirekter Nachfolgefunktionalitäten unterscheiden. 2. Sind Funktionalitäten hinsichtlich ihres Ufangs (bspw. LOC) stark unterschiedlich, so ist die Metrik wiederu wenig aussagekräftig. Hier sind die beiden Services nach der Tiefenetrik (g T ) noch nahezu gleich granular. Jedoch zeigen sich nach der Metrik für das Breiten- und Tiefenaß nachvollziehbare Unterschiede it g BT (s 1 )=1/6 vs. g BT (s 2 )=1/3. D. h. s 1 ist i Vergleich zu s 2 wesentlich grobgranularer. Größenaß Metrik isst die Granularität eines Service anhand seines Ufangs (bspw. geessen in LOC) 1. Metrik weist die Unterschiede i Ufang einzelner Funktionalitäten i FSG aus. 2. Metrik betrachtet nicht die Disaggregationsbeziehungen i FSG. 3. Metrik ist insbesondere dann geeignet, wenn die Granularität als Indikator für den Realisierungsaufwand - hier ausgedrückt in LOC - eines Service genutzt wird. Die Services s 1 und s 2 sind zwar nach den beiden oberen Metriken gleichgranular. Besitzen die realisierten Funktionalitäten 1 bzw. 4 jedoch einen unterschiedlichen Ufang, so wird dies erst it der Metrik für das Größenaß transparent. Die vorgestellten Maße systeatisieren verschiedene (oftals iplizite) Verständnisse des Begriffs Granularität in der Literatur. So werden bspw. durch Winkler (27) i Rahen ihrer 15

16 funktionalen Zerlegung ähnlich eine Tiefenaß die Dekopositionsbeziehungen ausgewertet. Das de Breiten- und Tiefenaß zugrunde liegende Verständnis findet sich ähnlich bspw. bei Aier (26) und Fiege (29), wobei letztere explizit neben der Anzahl an Funktionen (Breiten- und Tiefenaß) auch den Abstraktionsgrad der Services (ähnlich zu Tiefenaß) diskutieren. Clustering-Verfahren in der Koponentenorientierung, die Eleente wie bspw. Klassen zu Koponenten aggregieren, legen eine ipleentierungsnahe Granularitätsdefinition ähnlich de Größenaß nahe, auch wenn dies i. d. R. nicht expliziert wird. Anhand obiger Maße lässt sich aber nicht nur die Granularität einzelner Services essen. Aggregiert an vielehr die Granularität der Services i gesaten FSG, so lässt sich ein Metrikwert für ganze Servicelandschaften angeben (vgl. dazu auch das in Abschnitt 4 vorgestellte Softwarewerkzeug). Insofern können auch verschiedene Gesatlösungen des ökonoischen Entscheidungsodells hinsichtlich der Servicegranularität analysiert bzw. verglichen werden. D. h. die Metrikwerte dienen i Weiteren nicht als Modellinput. Vielehr soll der resultierende Modelloutput hinsichtlich seiner Granularität bewertet werden (ist z. B. eine Lösung fein- oder grobgranular?). 3.3 Ökonoisches Entscheidungsodell U zur Forschungsfrage beizutragen, wie granular Services unter ökonoischen Aspekten definiert werden sollen, gilt es die dafür relevanten Aufwandsgrößen zu identifizieren. Wir beschränken uns dabei bewusst auf die Aufwandsseite, da nach erfolgter fachlicher Analyse die Funktionalitäten (die zu Erträgen führen sollen) feststehen und i FSG abgebildet sind. Darauf basierend geht es daru, die vorhandenen Freiheitsgrade der fachlichen Analyse für eine Aufwandsiniierung zu nutzen. Entscheidungsrelevant ist hier zu einen der Aufwand für die Realisierung eines Service. Mit zunehende Ufang eines Service und der dadurch höheren Koplexität der Realisierung steigt dieser Aufwand i. d. R. überproportional an, bspw. aufgrund von Seiteneffekten und Änderungen a Quellcode anderer Artefakte. Auch das Testen wird bei zunehende Serviceufang aufwändiger. Zu anderen ist der Aufwand für die Servicekoposition ittels Sprachen wie WS-BPEL in die Entscheidung einzubeziehen. Hier fließt bspw. der Aufwand für das Suchen und Einbinden einzelner Services, der Erstellungsaufwand einer WS- BPEL-Datei oder die Vorbereitung des späteren Betriebs der Koposition ein. Schließlich gilt es auch denjenigen Wartungs- und Pflegeaufwand zu berücksichtigen, der durch die Wahl der Servicegranularität beeinflusst wird, bspw. falls eine Funktionalität in ehreren Services redundant realisiert wird und soit ehrfacher Wartungs- und Pflegeaufwand anfällt. Nicht relevant für die hier betrachtete Entscheidung ist dagegen der Einalaufwand für die Einrichtung einer serviceorientierten Infrastruktur, da dieser Aufwand unabhängig von der Wahl der Servicegranularität ist: Hierunter fällt das Einarbeiten in Servicestandards, das Auf- 16

17 setzen und Installieren der Infrastruktur (z. B. Engine, Verzeichnisdienst-Server, Enterprise Service Bus) sowie die Installation und das Einarbeiten in die Entwicklungsugebung u. ä. Zielfunktion Das Entscheidungsproble kann denach wie folgt beschrieben werden: Es soll eine zulässige Lösung für die Zuordnung von Services zu Funktionalitäten (repräsentiert durch die Matrix I SM ) gefunden werden (zu Kriteriu der Zulässigkeit s. u.), welche die gesaten Aufwände für die Realisierung C R, die Koposition C K und für Wartung und Pflege C P iniiert: I in! Z ( I ) C ( I ) C ( I ) C SM R SM K SM I Folgenden werden die einzelnen Aufwandsgrößen beschrieben. Aufwand für die Servicerealisierung Ausgangspunkt für die Schätzung des Realisierungsaufwands eines Service ist - wie oben dargestellt - priär der Ufang der zu ipleentierenden Funktionalität. Folgende Annahe wird getroffen: (A3) Für einen Service s i entsteht ein Realisierungsaufwand c R (s i ), der vo Ufang der zu realisierenden Funktionalität size j - geessen z. B. in LOC - abhängig ist. Dabei wird angenoen, dass bspw. pro LOC ein Aufwandsatz c var notwendig ist und der Aufwand it steigende Ufang (aus Koplexitätsgründen) überproportional zunit (Exponent b > 1). Daneben kann zur Servicerealisierung auch ein vo Ufang unabhängiger Aufwand c fix auftreten (z. B. Deployent-Aufwand, wie Bekanntachung des Service i Dienstverzeichnis). Die Paraeter c var und b können dabei bspw. als Linear- und Skalierungsfaktoren ähnlich zu COCOMO-Ansatz interpretiert werden. Basierend auf (A3) ergibt sich der Realisierungsaufwand eines Service s i zu: M b cr( si ) I s, ( c fix cvar ( size ) ) it : cvar, c fix, b 1 i j j j1 Zude ist darauf hinzuweisen, dass für unterschiedliche Servicetypen bspw. die Werte der Paraeter c var und b auch variiert werden können. Aus Darstellungsgründen haben wir jedoch bei obigen Ter für den Realisierungsaufwand c R (s i ) auf eine dafür notwendige, weitere Indexierung der Paraeter verzichtet. Das später vorgestellte prototypische Softwarewerkzeug erlaubt eine solche Definition verschiedener Paraeter. Der gesate Realisierungsaufwand einer Servicelandschaft ergibt sich soit als Sue über den Realisierungsaufwand aller Services: C R I SM S i1 c ( s ) R Aufwand für die Servicekoposition i P SM 17

18 Wird ein Prozess it vielen feingranularen Services anstatt it wenigen grobgranularen Services realisiert (Granularitätsverständnis nach de Größenaß), so steigt der Kopositionsaufwand. Ausgangspunkt für seine Erittlung - hier auf Ebene der Prozesse dargestellt - ist der bereits definierte Ufang der Kopositionslogik: (A4) Der Aufwand c K für die Servicekoposition eines Prozesses ist vo Ufang der Kopositionslogik abhängig, die nicht durch einen Service bereits realisiert ist (wiederu bei eine Aufwandsatz cop c var ). Dabei wird angenoen, dass der Aufwand it steigende Ufang der Kopositionslogik (höhere Koplexität) überproportional zunit (Exponent f > 1). Die Annahe (A4) lässt sich leicht it Hilfe der Abbildung 1 verdeutlichen: Zur Realisierung des Prozesses sind die Services s 1, s 2, s 3 und s 4 zu koponieren. Zude ist bei der Kopositionslogik die Funktionalität 4 und dait nicht von eine Service realisiert wird) sowie cop size 4 (da die Kopositionslogik von 4 cop size für den Prozess selbst zu berücksichtigen. Der Kopositionsaufwand für einen Prozess p P ergibt sich dait allgeein zu: c cop f cop size cop( I, ) it : c, f 1 cop ( p ) cvar SM p var K p Dabei können die Werte der Paraeter cop c var und f aufgrund der unterschiedlichen Verfahren und Sprachen für die Entwicklung von Services bzw. für deren Koposition von den Werten der Paraeter c var und b abweichen. Mit Hilfe von cop I SM, ) wird anhand der Wege von ( p Prozess p zu den Basisfunktionalitäten diejenigen vorausgehenden Funktionalitäten erittelt, die nicht bereits durch einen Service realisiert wurden (wie 4 i Beispiel). Der gesate Kopositionsaufwand ergibt sich wiederu als Sue über den Kopositionsaufwand der einzelnen Prozesse. Wartungs- und Pflegeaufwand durch Mehrfachrealisierung Daneben ist auch derjenige Wartungs- und Pflegeaufwand entscheidungsrelevant, der explizit durch die Wahl der Servicegranularität entsteht bzw. verieden werden kann. Wird eine ehrfach benötigte Funktionalität auch ehrfach realisiert, ist bei einer Änderung der Funktionalität jede Servicerealisierung anzupassen. Selbst wenn dies der Grundidee einer SOA eigentlich widerspricht, wäre eine Vernachlässigung dieses Falls unrealistisch. Insofern wird vorgeschlagen, den zusätzlichen Wartungs- und Pflegeaufwand von der Anzahl und de Ufang der ehrfachen Realisierung einer Funktionalität abhängig zu achen. Grund hierfür ist, dass it zunehender Anzahl und zunehende Ufang einer anzupassenden Funktionalität auch it steigende Wartungs- und Pflegeaufwand (wegen Koplexität) zu rechnen ist (vgl. Keller 27): 18

19 (A5) Durch jede ehrfache, redundante Realisierung einer Funktionalität entsteht zusätzlicher Wartungs- und Pflegeaufwand, der it steigende Ufang dieser Funktionalität überproportional zunit. Analog zu oben, wird hier ein Satz pen var > für den variablen Aufwand und ein Exponent h > 1 verwendet. Basierend auf (A5) wird erittelt, wie oft eine Funktionalität i direkt und indirekt ittels Services realisiert ist. In Abbildung 1 ist die Anzahl der Realisierungen der Funktionalität 9 it r 2 9 anzugeben. Der Wartungs- und Pflegeaufwand c p für eine Funktionalität i ergibt sich dann zu: h c ( ) ax[( r 1),] pen var ( size ) it : pen var p i i i, h 1 Die ax-funktion stellt hier sicher, dass nur ehrfach realisierte Funktionalitäten einbezogen werden. Der gesate Wartungs- und Pflegeaufwand C P durch Mehrfachrealisierung ist wieder über die Sue der Aufwände c p ( i ) aller Funktionalitäten zu berechnen. Wahl der Servicegranularität unter ökonoischen Aspekten Anhand des FSG und der obigen Zielfunktion lässt sich nunehr die Servicegranularität unter ökonoischen Aspekten optiieren. Dabei sind die Grundzusaenhänge berücksichtigt: Je feingranularer ein Service (bspw. nach de Größenaß), desto eher kann dieser ehrfach verwendet werden, ohne dass die durch den Service realisierten Funktionalitäten ehrfach ipleentiert werden üssen. Dies senkt ceteris paribus den Realisierungsaufwand. Abbildung 1 zeigt ein Beispiel: Die Funktionalität 9 wird in zwei Prozessen benötigt, ist aber nicht direkt realisiert. Der Ufang dieser Funktionalität geht soit in die Berechnung von zwei vorausgehenden realisierten Funktionalitäten ein (hier 6 und 11 ). Der Realisierungsaufwand fällt also zweial (für die Services s 3 und s 5 ) an, wohingegen bei einer direkten Realisierung der Aufwand für 9 nur einal anfallen würde. Darüber hinaus geht eine Mehrfachrealisierung auch it eine erhöhten Wartungs- und Pflegeaufwand einher. Andererseits entsteht bei feingranularen Services höherer Kopositionsaufwand. Die Erittlung der optialen Lösung ist nicht trivial. Es gilt die Adjazenzatrix I SM derart zu besetzen, dass die Lösung erstens zulässig ist und zweitens den Gesataufwand laut obiger Zielfunktion iniiert. U die Lösung it de inialen Gesataufwand zu eritteln, ist ein Verfahren realisiert, das beginnend it den Basisfunktionalitäten schrittweise diesen Services zuordnet. Danach werden sukzessive nicht ehr die Basisfunktionalitäten it Services realisiert, sondern den vorausgehenden Funktionalitäten jeweils Services zugeordnet. Für die jeweiligen Lösungen ist zugleich ier die Zulässigkeit zu prüfen. Eine Zuordnung von Services zu Funktionalitäten i FSG ist genau dann zulässig, wenn es öglich ist, alle Prozesse it den zugeordneten Services zu koponieren und dait zu realisieren. D. h. konkret, dass jeder ögliche Gesatweg w(, n ) i FSG indestens eine direkt realisierte Funktionalität enthalten uss. Dies entspricht de Zulässigkeitskriteriu und ist hinrei- 19

20 chend, da eine vorausgehende Funktionalität direkt oder indirekt ier auch die über die Disaggregationsbeziehungen referenzierten Basisfunktionalitäten (Adjazenzatrix I MM ) uschließt. Ist eine Lösung nicht zulässig, ist indestens eine Basisfunktionalität n œ B eines Gesatweges für den Prozess p œ P nicht verfügbar. Dait wäre der Prozess p nicht ausführbar. Diese Bedingungen für die Zulässigkeit einer Lösung wurden foral definiert (siehe Anhang 1) und i Werkzeug ipleentiert. Abschließend wird aus allen zulässigen Lösungen diejenige selektiert, deren Realisierung zu inialen Gesataufwand führt. Neben der Berechnung der Lösung sind auch die Konfigurationsgrößen für die Aufwandsfunktionen zu eritteln. Hier kann eine Orientierung an bekannten Schätzverfahren aus der Softwareentwicklung erfolgen. Bspw. wird i COCOMO-Ansatz der Aufwand anhand der BSF Forel PM A EM size geschätzt, wobei A und EM Linearfaktoren und B und SF Skalierungsfaktoren sind. Ihre Werte sind projekt- sowie unternehensspezifisch zu bestien. Bereits von Tansey und Stroulia (27) wird COCOMO auch bei Servicerealisierungen verwendet: Sie verdeutlichen die grundsätzliche Anwendbarkeit, verweisen jedoch auch darauf, dass für die Bestiung einzelner Faktoren oftals noch nicht auf eine ufangreiche (unternehensübergreifende) Datenbasis zurückgegriffen werden kann. Hier ist an - wie auch das nachfolgende Fallbeispiel zeigt - auf unternehensinterne Schätzungen angewiesen. Dennoch sind Grundannahen, wie bspw. der konvexe Verlauf der Aufwandsfunktionen sinnvoll. U die Folgen einer Unschärfe der Schätzungen zu analysieren, wurde i entwickelten Softwarewerkzeug eine Sensitivitätsanalyse integriert, welche die Analyse der Robustheit der Ergebnisse unterstützt. 4 Prototypische Usetzung und Fallbeispiel I Folgenden ist die Usetzung des Entscheidungsodells in eine Softwarewerkzeug dargestellt. Danach wird das Fallbeispiel einer Bank diskutiert. 4.1 Prototypische Realisierung Das vorgestellte Modell wurde in For eines Plug-in für das Open-Source-Fraework Eclipse ugesetzt. Die Ipleentierung erfolgte in Java und basiert auf de Eclipse Modeling Fraework. Die grafischen Ein- und Ausgaben wurden ittels des Graphical Editing Fraework realisiert. Für die Erstellung des FSG steht ein grafischer Editor zur Verfügung, wobei die Funktionalitäten aus einer seitlichen Palette (vgl. rechter Teil in Abbildung 3) in den Arbeitsbereich gezogen und deren Paraeter (z. B. Bezeichner und Ufang der Funktionalität) eingegeben werden. Zude sind die Funktionalitäten it gerichteten Kanten i azyklischen FSG einzubinden. Eine weitere Maske eröglicht nicht nur die Eingabe der Paraeter der Aufwandsfunktionen. Vielehr können diese Funktionen bspw. auch unternehensindividuell verändert werden (u bspw. Function Points anstatt LOC zu verwenden). 2