Measuring Client-Vendor Distance in Global Outsourceing Relationships: A Conceptual Model

2009, Wirtschaftsinformatik

Business Services: Konzepte, Technologien, Anwendungen 9. Internationale Tagung Wirtschaftsinformatik Band 1 books@ocg.at BAND 246 Wissenschaftliches Redaktionskomitee o.Univ.Prof.Dr.G.Chroust o.Univ.Prof.Dr.G.Haring Univ.Prof.Dr.G.Kotsis Univ.Doz.Dr.V.Risak Dr. N. Rozsenich o.Univ.Prof.Dr.P.Zinterhof Hans Robert Hansen, Dimitris Karagiannis, Hans-Georg Fill (Hrsg.) Business Services: Konzepte, Technologien, Anwendungen 9. Internationale Tagung Wirtschaftsinformatik Wien, 25. – 27. Februar 2009 Band 1 © Österreichische Computer Gesellschaft 2009 © Österreichische Computer Gesellschaft 1010 Wien, Wollzeile 1-3 Komitee für Öffentlichkeitsarbeit www.ocg.at Druck: Druckerei Riegelnik 1080 Wien, Piaristengasse 19 ISBN 978-3-85403-246-5 Österreichische Computer Gesellschaft, Band 1 VORWORT Die alle zwei Jahre veranstaltete Internationale Tagung Wirtschaftsinformatik ist die größte Fachtagung für Wirtschaftsinformatik im europäischen Raum. Expertinnen und Experten aus Wissenschaft und Praxis diskutieren bei dieser Veranstaltung innovative Ansätze zur Gestaltung betrieblicher Informationssysteme und die dadurch bewirkte Transformation von Geschäftsprozessen, Unternehmen und Märkten. Dabei werden diesmal unter dem Generalthema „Business Services: Konzepte, Technologien, Anwendungen“ zwei aktuelle Entwicklungstendenzen aufgegriffen. Erstens der Trend zu serviceorientierten Architekturen, für die derzeit die wissenschaftliche Gemeinschaft neue Konzepte und Ansätze erforscht und bis zur Einsatzreife bringt. Bei Serviceorientierung handelt es sich um eine Form einer verteilten Informationsarchitektur, deren Fokus auf der Ankündigung, dem Auffinden und dem dynamischen Aufrufen von hoch stehenden, anwendungsnahen und in sich abgeschlossenen Diensten liegt. Ziel ist meist auch eine lose Kopplung von Anwendungssystemen und damit eine Steigerung der Flexibilität. Die Konzepte und Technologien bei der Entwicklung und Umsetzung von Business Services bilden den ersten Tagungsschwerpunkt. Zweitens besteht ein Trend zur Dienstleistungsgesellschaft, der sich auch in den IT-Investitionen, dem IT-Einsatz und den Tätigkeitsfeldern von IT-Fachkräften niederschlägt. Diese Aspekte werden im Bereich Anwendungen berücksichtigt, der nach Branchen gegliedert ist. Wie interessant und vielfältig diese Thematik ist, zeigt sich unter anderem in den rund 640 eingereichten Beiträgen, von denen die besten 160 im Rahmen eines sorgfältigen Begutachtungsverfahrens ausgewählt wurden. Pro anonymisierten Beitrag wurden mindestens drei Gutachten eingeholt, insgesamt wurden mehr als 1.800 Gutachten von über 400 Fachexperten erstellt. Als Neuerung der WI 2009 werden die einzelnen Themengebiete jeweils durch einen eingeladenen Kurzvortrag eines Praktikers („Praxisdialog“) ergänzt. Für diese Kurzvorträge bestand ebenfalls die Möglichkeit der Einreichung eines Beitrags, jedoch ohne das wissenschaftliche Begutachtungsverfahren durchlaufen zu müssen. Damit soll die Wichtigkeit des Zusammenspiels von Theorie und Praxis in der Wirtschaftsinformatik unterstrichen werden - von der einen Seite als Lieferant von Anforderungen, aktuellen Problemstellungen und der Bewertung entworfener Konzepte, von der anderen Seite in Form von anwendbaren Konzepten und adäquaten Lösungen. Für das Gelingen der Tagung möchten wir uns bei den zahlreichen beteiligten Personen bedanken. Insbesondere danken wir den AutorInnen für die Einreichung der vielen hochwertigen Beiträge, die den Kern des wissenschaftlichen Programms darstellen. Des Weiteren möchten wir den Leitungsgremien und den Programmkomitees der Tracks danken, die es durch die Bereitstellung ihrer Fachexpertise ermöglicht haben, die besten Beiträge auszuwählen und so die wissenschaftliche Qualität zu sichern. 5 Bedanken möchten wir uns auch bei unseren Sponsoren, die mit ihrer großzügigen finanziellen Unterstützung einen wesentlichen Beitrag für die Durchführung der Tagung geleistet haben. Schließlich danken wir den zahlreichen in die Vorbereitung der Tagung involvierten MitarbeiterInnen, ins-besondere Herrn Eugen Mühlvenzl und Frau Elisabeth Maier-Gabriel von der Österreichischen Computergesellschaft sowie den wissenschaftlichen MitarbeiterInnen und StudienassistentInnen des Instituts für BWL und Wirtschaftsinformatik der Wirtschaftsuniversität Wien und des Instituts für Knowledge and Business Engineering der Universität Wien, namentlich stellvertretend für alle Daniela Schremser, Elisabeth Fuchs, Xiulian Benesch, Maria Madlberger und Rony Flatscher. Wir wünschen allen LeserInnen viel Freude bei der Lektüre. Wien, im Dezember 2008 Hans Robert Hansen, Dimitris Karagiannis, Hans-Georg Fill 6 INHALTSVERZEICHNIS HAUPTVORTRÄGE Die Transformation des Unternehmens in der vernetzten Gesellschaft Peter Zencke....................................................................................................................................... 17 Delivering Business Value with Modeling and Service Orientation: The Lean, Green Business Richard Mark Soley ........................................................................................................................... 18 Service Oriented Architectures - A Paradigm Change for Banking Infrastructures Hermann-Josef Lamberti ................................................................................................................... 19 KONZEPTE IS-Strategien Leitungsgremium: Karl Kurbel, Friedrich Roithmayr, August-Wilhelm Scheer A Framework for Strategic Positioning in IT Management Benjamin Müller, Frederik Ahlemann, Gerold Riempp ..................................................................... 25 Measuring Client-Vendor Distance in Global Outsourcing Relationships: A Conceptual Model Katharina Vogt, Robert Gregory, Roman Beck ................................................................................. 35 The (Lacking) Business Perspective on SOA - Critical Themes in SOA Research Goetz Viering, Christine Legner, Frederik Ahlemann ....................................................................... 45 Geschäftsmodelle für Business Services Leitungsgremium: Stefan Klein, Hubert Österle, Yves Pigneur Business Models for E-Government – The BMeG Method Gertraud Peinel, Matthias Jarke, Thomas Rose ................................................................................ 57 Do Web Services Foster Specialization? – An Analysis of Web Service Directories Christine Legner ................................................................................................................................ 67 Geschäftsmodelle für organisationsübergreifende Business Services im E-Government Isabel Mischler, Till Janner, Christoph Schroth, Beat Schmid ......................................................... 77 7 IS-Architekturen Leitungsgremium: Ulrich Frank, Heinrich C. Mayr, Robert Winter Modellgetriebene Entwicklung von serviceorientierten Architekturen Rainer Bernhard, Bernd U. Jahn ....................................................................................................... 89 Empirische Validierung von Integrationstypen am Beispiel unternehmensübergreifender Integration Stephan Aier, Bettina Gleichauf, Christian Riege, Jan Saat ............................................................. 99 Situative Methodenkonstruktion für die Projektbewertung aus Unternehmensarchitekturperspektive Stephan Aier, Christian Riege, Marten Schönherr, Udo Bub .......................................................... 109 Serviceorientierte Integration medizinischer Geräte - Eine State-of-the-Art-Analyse Christian Mauro, Ali Sunyaev, Jan Marco Leimeister, Helmut Krcmar ......................................... 119 Ein allgemeiner Ansatz zur Ableitung von Abhängigkeitsanalysen auf Unternehmensarchitekturmodellen Stephan Kurpjuweit, Stephan Aier ................................................................................................... 129 Serviceorientierte Softwarearchitekturen Leitungsgremium: Andreas Oberweis, Steffen Staab, Uwe Zdun COSMA - Ein integrierter Ansatz für das Management von Service Level Agreements bei Composite Services André Ludwig ................................................................................................................................... 141 Wiedergewinnung neuer Web Services aus vorhandenen Altsystemen Harry M. Sneed ................................................................................................................................ 151 Identity Management in Business Process Modelling: A Model-driven Approach Heiko Klarl, Christian Wolff, Christian Emig ................................................................................. 161 Model-driven Development of Serviceoriented Business Application Systems Stefan Kätker, Susanne Patig ........................................................................................................... 171 Vorgehensmodelle zur Entwicklung Serviceorientierter Softwaresysteme Oliver Thomas, Katrina Leyking, Michael Scheid ........................................................................... 181 Geschäftsprozessmanagement Leitungsgremium: Rony Flatscher, Peter Loos, Markus Nüttgens, Michael Rosemann Fallstudie zum Einsatz agiler, prozessorientierter Methoden in der Chipindustrie Mirjam Minor, Daniel Schmalen, Andreas Koldehoff ..................................................................... 193 Reducing the Variations in Intra- and Interorganizational Business Process Modeling – An Empirical Evaluation Dominic Breuker, Daniel Pfeiffer, Jörg Becker ............................................................................... 203 8 Tuplespace-based Infrastructure for Decentralized Enactment of BPEL Processes Daniel Wutke, Daniel Martin, Frank Leymann ............................................................................... 213 Auswirkungen der Serviceorientierung auf das Business Engineering: Eine metamodellbasierte Analyse Frank Höning, Volker Bach, Hubert Österle ................................................................................... 223 Verbesserung der Wirksamkeit des SOA-Design durch Referenzmodelle Oliver Holschke, Olga Levina, Jannis Rake, Philipp Offermann .................................................... 233 Process Mining zur Steuerung von Call Center-Prozessen Frank Bensberg, André Coners ....................................................................................................... 243 Wertorientiertes Prozessmanagement: State-of-the-Art und zukünftiger Forschungsbedarf Jan vom Brocke, Christian Sonnenberg, Alexander Simons ............................................................ 253 Collaborative Services / Services für die Kooperation Leitungsgremium: Norbert Gronau, Michael Koch, Gerhard Schwabe, Volker Wulf Presence Signalling in Unified Communication Systems – A Framework for Customisation in Context Kai Riemer, Stefan Klein .................................................................................................................. 265 Supporting Research Collaboration - On the Needs of Virtual Research Teams Jens-Henrik Söldner, Jörg Haller, Angelika C. Bullinger, Kathrin M. Möslein ............................. 275 Non-optimized Temporal Structures as a Failure Factor in Virtual Teams Felix Köbler, Marilyn Tremaine, Jan Marco Leimeister, Helmut Krcmar...................................... 285 Content-based Community Detection in Social Corpora Annette Bobrik, Matthias Trier ........................................................................................................ 295 Mine, Yours…Ours? Designing for Principal-Agent Collaboration in Interactive Value Creation Jasminko Novak ............................................................................................................................... 305 eCollaboration and Productivity Katarina Stanoevska-Slabeva .......................................................................................................... 315 Services für Risiko- und Compliancemanagement Leitungsgremium: Günter Müller, Stephanie Teufel, A Min Tjoa Integrated Information Security Risk Management - Merging Business and Process Focused Approaches Sebastian Sowa, Lampros Tsinas, Hanno Lenz, Roland Gabriel .................................................... 327 9 Eine risikobasierte Methode für Implementierung und Betrieb von GMP-konformer IT-Infrastruktur am Beispiel User- und Identity Management Peter Brandstetter, Barbara Ginda, Stefan Tautscher .................................................................... 337 Continuous Compliance Monitoring in ERP Systems - A Method for Identifying Segregation of Duties Conflicts Patrick Wolf, Nick Gehrke ............................................................................................................... 347 A Risk Based Approach for Selecting Services in Business Process Execution Stefan Sackmann, Lutz Lowis, Kai Kittel ......................................................................................... 357 Integration of an IT-Risk Management / Risk Assessment Framework with Operational Processes Louis Marinos, Lutz Kirchner, Stefan Junginger............................................................................. 367 Internal Controls Scripting Language (ICSL): Grundzüge einer Instruktionssprache für Interne Kontrollen Tom Beiler, Markus Böhm ............................................................................................................... 377 Wertschöpfungsnetzwerke Leitungsgremium: Helmut Krcmar, Susanne Leist, Maria Madlberger IT-gestützte Wertschöpfungspartnerschaften zur Integration von Produktion und Dienstleistung im Maschinen- und Anlagenbau Philipp Walter, Nadine Blinn, Michael Schlicker, Oliver Thomas .................................................. 389 Vertical Integration and Information Sharing - An Empirical Investigation in the German Apparel Industry Christoph Goebel, Hanna Krasnova, Henning Syllwasschy, Oliver Günther ................................. 399 Webservices für die Verrechnung in Wertschöpfungsnetzwerken auf Basis vollständiger Finanzpläne Jörg Becker, Ralf Knackstedt, Martin Matzner ............................................................................... 409 Science of Services / Wissenschaftstheorie Leitungsgremium: Werner Esswein, Klaus Tochtermann, Stephan Zelewski Dokumentation und Fortschrittsbestimmung von Methoden zur Gestaltung soziotechnischer Systeme am Beispiel einer Methode zum Service Engineering Stephan Aier, Christian Fischer ...................................................................................................... 421 Moden in der Wirtschaftsinformatik – Wissenschaftstheoretische und wissenschaftspraktische Überlegungen zu einer von Hypes geprägten Disziplin Hanno Schauer, Carola Schauer ..................................................................................................... 431 Towards a Research Method for Theory-driven Design Research Andreas Gehlert, Michael Schermann, Klaus Pohl, Helmut Krcmar .............................................. 441 10 Beurteilungskriterien internationaler Fachzeitschriften im Umfeld der Wirtschaftsinformatik Karl Kurbel, Ilja Krybus, Ivo Stankov ............................................................................................. 451 Rechtsfragen, geistiges Eigentum Leitungsgremium: Walter Blocher, Ulrich Hasenkamp, Andreas Wiebe Auswirkungen externer Kontrollmechanismen auf die Gestaltung und Implementierung von ERP-Systemen Axel Winkelmann, Malte Stockmann, Jörg Becker .......................................................................... 463 Die Auswirkungen von sozialen Motiven auf die Rechts- und Haftungssituation am Beispiel offener Netze Reto Mantz ....................................................................................................................................... 473 Grenzen der datenschutzrechtlichen Verantwortlichkeit in einer Welt des „Ubiquitous Computing“ Jürgen Müller................................................................................................................................... 483 Filesharing und Tauschbörsen: Die Haftung des Anschlussinhabers (auf Unterlassung) unter dem Gesichtspunkt der Störerhaftung - Ein Lösungsvorschlag zwischen Rechtsprechung und Realität Jan Morgenstern .............................................................................................................................. 493 Performance & Monitoring, IT-Controlling Leitungsgremium: Ulrike Baumöl, Walter Brenner, Günter Haring Produktionsplanung und –steuerung der IT-Service-Provisionierung Nico Ebert, Alexander Vogedes, Falk Uebernickel ......................................................................... 505 Controlling im Wissensmanagement - Konzeption eines allgemeinen Ansatzes zur Erfolgsbewertung im Wissensmanagement Franz Lehner, Nadine Amende, Stephan Wildner, Nicolas Haas .................................................... 515 Leistungsorientierte Steuerung der Informationsversorgung im Rahmen der Qualitätssicherung in Dienstleistungsnetzwerken Reinhard Jung, Martina Meschke .................................................................................................... 525 Vorgehensmodell zur Entwicklung von Reifegradmodellen Ralf Knackstedt, Jens Pöppelbuß, Jörg Becker ............................................................................... 535 Determining the Impact of Business Strategies Using Principles from Goal-oriented Measurement Victor Basili, Jens Heidrich, Mikael Lindvall, Jürgen Münch, Carolyn Seaman, Myrna Regardie, Adam Trendowicz............................................................................................................................. 545 Benefits Management - A Literature Review and Elements of a Research Agenda Jessica Braun, Frederik Ahlemann, Gerold Riempp ....................................................................... 555 11 Software als Service Leitungsgremium: Peter Buxmann, Roland Holten, Wolfgang König, Dirk Stelzer Welche Treiber lassen SaaS auch in Großunternehmen zum Erfolg werden? Eine empirische Analyse der SaaS-Adoption auf Basis der Transaktionskostentheorie Alexander Benlian, Thomas Hess .................................................................................................... 567 Prüfkriterien für Geschäftsmodelle im Kontext von Software as a Service Matthias Biggeleben, Harald Kolbe, Markus Schäfermeyer, Helena Vranesic .............................. 577 Organisationskonzepte für Business Services Leitungsgremium: Arnold Picot, Rudolf Vetschera, Christof Weinhardt Data Governance: Organisationskonzept für das konzernweite Datenqualitätsmanagement Kristin Weber, Boris Otto, Hubert Österle ...................................................................................... 589 Strategic Behavior in Service Networks under Price and Service Level Competition Clemens van Dinther, Benjamin Blau, Tobias Conte ...................................................................... 599 Quality of Service Delivery: Economic Effects of Multi-Homing and Content Delivery Networks Thorsten Hau, Jochen Wulf, Rüdiger Zarnekow, Walter Brenner ................................................... 609 TECHNOLOGIEN Mobile Systeme Leitungsgremium: J. Felix Hampe, Gabriele Kotsis, Franz Lehner, Klaus Turowski Ein mobiles Spiel wird zum Eventmarketinginstrument Christoph Göth, Raphael Joss, Gerhard Schwabe .......................................................................... 621 Service-based Interactive Workflows for Mobile Environments Sonja Zaplata, Dirk Bade, Ante Vilenica ......................................................................................... 631 An Interactive Remote Visualization System for Mobile Application Access Marcus Hoffmann, Jörn Kohlhammer ............................................................................................. 641 Klassifikation und Implementierung von Location Based Airport Services zur situierten Unterstützung von Passagierprozessen an Flughäfen Stefan Hausmann ............................................................................................................................. 651 12 Semantische Informationssysteme Leitungsgremium: Dieter Fensel, Knut Hinkelmann, Rudi Studer A Model-driven Approach to enable Access Control for Ontologies Willy Chen, Heiner Stuckenschmidt ................................................................................................. 663 Management von Modellbeziehungen mit semantischen Wikis Michael Fellmann, Oliver Thomas .................................................................................................. 673 Process-oriented Semantic Business Modeling Ivan Markovic, Florian Hasibether, Sukesh Jain, Nenad Stojanovic .............................................. 683 IT-Infrastruktur für Business Services Leitungsgremium: Stefan Eicker, Torsten Eymann, Stefan Koch, Erich Schikuta Zielorientierte Datenmodellierung für ITIL-basierte inter-organisationale Configuration Management Databases Wolfgang Hommel, Silvia Knittl ...................................................................................................... 695 Konzeptionelle Metamodelle von IT-Governance-Referenzmodellen als Basis der Kombination und Integration in einer Multi-Modell-Umgebung Stefanie Alter, Matthias Goeken ...................................................................................................... 705 Softwareentwicklungsmethoden Leitungsgremium: Georg Herzwurm, Matthias Jarke, Gertrude Kappel, Frank Leymann Adjustment Strategies for Managing Unanticipated Changes in Software Development Processes Katja Andresen, Norbert Gronau..................................................................................................... 717 Requirements Engineering for Hybrid Products as Bundles of Hardware, Software and Service Elements – A Literature Review Marina Berkovich, Sebastian Esch, Jan Marco Leimeister, Helmut Krcmar.................................. 727 Reengineering Deprecated Component Frameworks: A Case Study of the Microsoft Foundation Classes Robert Neumann, Sebastian Günther, Niko Zenker ......................................................................... 737 Agenten-, Multiagententechnologien Leitungsgremium: Stefan Kirn, Winfried Lamersdorf, Jörg Müller Cooperation Mechanisms for Monitoring Agents in Service-oriented Architectures André Miede, Jean-Baptiste Behuet, Nicolas Repp, Julian Eckert, Ralf Steinmetz ......................... 749 Georeferenzierung in der Logistik Michael Schuele, Paul Karaenke, Achim Klein ............................................................................... 759 13 From a Research to an Industry-Strength Agent Platform: JADEX V2 Alexander Pokahr, Lars Braubach .................................................................................................. 769 RFID und Ubiquituous Services Leitungsgremium: Alois Ferscha, Elgar Fleisch, Kai Rannenberg RFID In Reverse Logistics – Research Framework and Roadmap Lars Thoroe, Adam Melski, Matthias Schumann ............................................................................. 781 Sicherheit Leitungsgremium: Claudia Eckert, Günther Pernul, Gerald Quirchmayr Collaborative Penetration Testing Severin Winkler, Christian Proschinger .......................................................................................... 793 Automating Periodic Role-Checks - A Tool-based Approach Ludwig Fuchs, Christian Müller ...................................................................................................... 803 ANWENDUNGEN Innovationsmanagement und Produktentwicklung Leitungsgremium: Nikolaus Franke, Oliver Günther, Kathrin Möslein, Frank Piller Fachliches Innovationsmanagement als strategischer Erfolgsfaktor in der IT-Beratung und Systemintegration Sean Eikenberg, Stephan Melzer, Ulrike Lechner ........................................................................... 815 Service Innovation with Information Markets Stephan Stathel, Clemens van Dinther, Anton Schönfeld ................................................................ 825 Embedded Open Toolkits for User Innovation: Postponing new Product Development Decisions into the Customer Domain Uwe Gross, David Antons ................................................................................................................ 835 Semantische Kunden-Feature-Objekte in erweiterten Digitalen Produktmodellen Heiner Lasi, Hans-Georg Kemper ................................................................................................... 841 Zum Einsatz von Social Networking Services im Unternehmen Alexander Richter, Michael Koch .................................................................................................... 851 From Idea Management Systems to Interactive Innovation Management Systems: Designing for Interaction and Knowledge Exchange Bastian Bansemir, Anne-Katrin Neyer............................................................................................. 861 AUTORENVERZEICHNIS ................................................................................... 871 14 HAUPTVORTRÄGE DIE TRANSFORMATION DES UNTERNEHMENS IN DER VERNETZTEN GESELLSCHAFT Peter Zencke1 Die Transformation der Wirtschaft in ein Netzwerk von spezialisierten, kollaborativen Unternehmen ist in vollem Gange. Dies gilt für große, mittlere und kleine Unternehmen. Informationstechnologie ist dabei ein wesentlicher Treiber der Veränderung. Die Leistungsfähigkeit der IT-„Rohstoﬀe“ Rechenleistung, Speicherplatz sowie Bandbreite und Dichte von Netzwerken nimmt weiterhin exponentiell zu – während die Preise pro Ressourceneinheit in gleichem Maße fallen. Durch diese Entwicklung haben sich ganz neue Möglichkeiten für den Einsatz und die Verwendung von Software ergeben. Die wachsende Bandbreite des Internets macht es beispielsweise möglich, dass selbst integrierte betriebswirtschaftliche Software-Lösungen in bisher nicht möglichen Volumina als Services über das Internet bereit-gestellt und konsumiert werden können. Die Transformation der Wirtschaft verändert das Unternehmen als Ganzes: Die Zusammenarbeit der Menschen und den Ablauf der Geschäftsprozesse in den Systemen und Maschinen. Ob kreativer Designprozess oder hochautomatisierter Abwicklungsprozess, Aufgabe betrieblicher Informationssysteme wird es sein, die Transformation und Vernetzung ganzheitlich zu unterstützen und voranzutreiben. 1 Mitglied des Vorstandes und Leiter des Unternehmensbereichs Research and Breakthrough Innovation der SAP AG 17 DELIVERING BUSINESS VALUE WITH MODELING AND SERVICE ORIENTATION: THE LEAN, GREEN BUSINESS Richard Mark Soley1 It seems that Service Oriented Architecture (SOA), Green Computing and Business Process Management (BPM) are to be this year‘s hot buzzwords, rather than well-de ned, meaningful and valuable parts of the business landscape. Before the terms fade away completely, perhaps we should agree what‘s valuable about the move to BPM & SOA and how they support our business strategy, including both bottom lines (pro t and environmental impact). Implementing that strategy, to lean our processes and green our processes, will require an approach to architecture & design of the business that outlasts today‘s buzzwords – Model Driven Architecture (MDA). The SOA Consortium is making great strides in de ning SOA to be a valuable business strategy for business agility; meanwhile the BPM Roundtable Forum approaches Business Process Management from the standpoint of improving and optimizing business processes for both bottom lines. The Object Management Group (OMG) is making headway on modeling standards (based on the MDA Initiative) for services, and maturity models to help organizations optimize their business processes both along green (GCMM) and lean (BPMM) lines. Dr. Soley will give an overview of the OMG‘s MDA eﬀorts in business modeling to support business capabilities, as well as the eﬀorts of OMG‘s SOA Consortium and BPM Roundtable to lead the way to successful, lean, green processes. 1 Chief Executive Officer Object Management Group, Inc. (OMG) 18 SERVICE ORIENTED ARCHITECTURES - A PARADIGM CHANGE FOR BANKING INFRASTRUCTURES Hermann-Josef Lamberti1 Modernes Bankgeschäft ist ohne den Einsatz von Technologie undenkbar. In sich schnell verändernden Märkten ist Flexibilität ein wesentlicher Erfolgsfaktor. Nur so können steigende Volumina und neue Kundenanforderungen zeitnah bedient werden. Vor diesem Hintergrund folgt die Deutsche Bank dem SOA-Ansatz mit dem Ziel einer „Service Oriented Organization“. Auf diese Weise wird Komplexität reduziert und die Flexibilität gewonnen, die vorhandene Bank-IT schnell und kostengünstig an neue Bedürfnisse anzupassen. Dabei werden interne Teams an inhaltlichen Kompetenzen ausgerichtet und unterstützen unterschiedliche Geschäftsbereiche. Das Ziel ist größtmögliche Flexibilität, so dass benötigte Komponenten bei Bedarf in Echtzeit ein- und ausgeschaltet werden können. 1 Mitglied des Vorstandes und Chief Operating Officer der Deutsche Bank AG 19 WISSENSCHAFTLICHE BEITRÄGE IS-STRATEGIEN Informationssysteme (IS) ermöglichen innovative Geschäftskonzepte und Geschäftsmodelle, aber sie begrenzen auch Handlungsoptionen und Entwicklungsmöglichkeiten. Ob ein Unternehmen seine Visionen in eine Strategie und Operationen umsetzen kann, hängt nicht zuletzt davon ab, ob seine Informationssysteme dies unterstützen. Die IS-Strategie ist somit von zentraler Bedeutung. Die Serviceorientierung spielt heute eine wichtige Rolle, erstens aufgrund der Transformation zahlreicher Unternehmen vom Produkt- zum Servicegeschäft, das ohne IS-Unterstützung nicht denkbar ist, zweitens aufgrund serviceorientierter IS-Architekturen, die flexibel anpassbare Systeme erlauben, und drittens in Form des Wandels auf dem Markt für IS-Dienstleistungen. Wurden früher IS betriebsintern oder von heimischen Softwarefirmen entwickelt, bieten ITDienstleister in Indien oder Osteuropa zunehmend nicht nur die Erstellung, sondern auch den Betrieb von IS und die Abwicklung ganzer Geschäftsprozesse an. Leitungsgremium: Karl Kurbel, Europa-Universität Viadrina Frankfurt (Oder) (Federführender) Friedrich Roithmayr, Johannes Kepler Universität Linz August-Wilhelm Scheer, Universität des Saarlandes Programmkomitee: Wolfgang Mathera, SAP Business School Vienna Hubert Österle, Universität St. Gallen Bodo Rieger, Universität Osnabrück Susanne Robra-Bissantz, Technische Universität Braunschweig Detlef Schoder, Universität zu Köln Herman Sikora, Raiffeisen Rechenzentrum Rolf Wigand, University of Arkansas A FRAMEWORK FOR STRATEGIC POSITIONING IN IT MANAGEMENT Benjamin Müller, Frederik Ahlemann, Gerold Riempp1 Abstract Today IT executives need to define their IT strategy and align it with the overall corporate strategy. However, research offers them little advice with respect to determining the strategic position of their IT departments as a basis for strategic planning. Based on a review of concepts from general management, this paper proposes a framework for strategic positioning in IT management. The authors analyzed the general management literature. Additionally they observed three companies’ approaches to strategic positioning as a basis to building and refining their framework. The results suggest that strategic positioning is both a necessary and valuable task for IT managers. This strategic positioning should be based on a frame of reference that structures and integrates elements of benchmarking, competitive, and contextual analysis. 1. Introduction Contemporary CIOs face significant challenges such as the availability of new IS architectures (i.e., SOA) and their impact [13], an ongoing trend towards outsourcing [5], and the separation of demand and supply [17]. This forces IT departments to focus on servicing business units and to adopt market-oriented structures of sourcing and delivery [50]. A central challenge in this new environment is the alignment between IT and business [28]. Therefore, IT departments today are strongly involved in the planning and execution of their companies’ business strategy [33, 37, 47]. While strategic planning covers the question of “where do we want to be”, translating these strategic goals into action programs for the IT department requires them to also know where they are today (current position). While IT benchmarking can help [48], it seems insufficient to resolve the issue of positioning because it normally does not capture the strategic context of a company. Since strategic positioning is not new, we transfer concepts from general management into IT management (ITM). This has the potential of increasing the alignment, since IT and business are now talking the same “strategic language”. This research effort will lead to understanding the process and benefits of positioning IT departments strategically within corporations and beyond. In this paper, as a first step towards an understanding of strategic positioning in ITM (SPITM), we analyze SPITM’s fundamental elements and their relations. This serves as a basis for deriving a framework for SPITM and an according assessment. We have chosen this approach to allow both science and practice to reuse the model-inherent knowledge of such a framework [18, 40]. Following Gregor [19], we thus provide a theory for analyzing the phenomenon of SPITM. 1 Institute of Research on Information Systems, European Business School, Rheingaustraße 1, 65375 Oestrich Winkel 25 The next section introduces a review of the literature dealing with strategic positioning, both in general management and ITM. After deducing a set of typical elements that are used for strategic positioning in general management, we test this set by means of case study research in three SPITM cases. The results are used for the construction of our final framework. The paper concludes by discussing future research opportunities and its limitations. 2. Foundations In their effort to position themselves strategically, IT departments are confronted with the same competitive forces that drive businesses in general. In general management, methods of formal planning for the purpose of strategic positioning (SP) are well established [e.g. 4]. We propose the transfer of elements of such SP methods to ITM. Based on a review of literature, this chapter will briefly highlight these elements and show how they constitute SPITM. 2.1. Frame of Reference Hopfenbeck describes the entire approach of strategic management as a frame of reference itself [22]. In this capacity, it is described as supporting executives in the identification of challenges as well as in the formulation of appropriate responses. Based on this, the approach to structure general management has already been established in the literature [9, 39]. The rationale for the use of frames of reference (FoR) in this domain is their ability to explicate decision-makers’ shared perception of the relevant fields of action and decision-making [38]. Various authors have proposed FoRs for ITM. Earl [16] separates ITM into information technology, information systems, and information management, while others look at ITM as a departmental strategy [8] or differentiate between offerings and resources needed for their production [31]. A comprehensive approach is done by Riempp et al. [38], who integrate the current state-of-the-art research with their own empirical work. They extend the above arguments by highlighting the importance of an FoR to make ITM both measurable and comparable. To summarize, there are three main arguments for using an FoR in the context of SPITM: (1) the ability to structure ITM to ensure completeness and shared perception, (2) making the underlying activities both measureable and comparable by capturing their contents and relations, and (3) the need for a reference point to integrate SP activities, especially the processes and results, with ITM. 2.2. Benchmarking To assess the strategic position of an IT department, data needs to be gathered about its structure and its environment. Mintzberg and Lampel [29] describe this as the positioning school, rooted in the works of authors like Hatten and Schendel [20] and “popularized” by Porter [34]. Market forces influencing an enterprise [35] and their influence on strategy formulation [14] need to be considered. While these competitive forces drive businesses, they are also a source of information. In this context, benchmarking [36] is a technique that is in use for almost 70 years. A vast body of knowledge has evolved around benchmarking [12, 6, 1, 44]. Today, benchmarking is also used in ITM [21] and has established itself in this domain [2]. So far, it has mainly focused on products and services – mainly based on cost and other quantitative measures – and has only shifted towards processes in recent years. Benchmarking for strategy has not yet been fully embraced within IT [11]. However, recent efforts point in this direction [32]. We suggest that SP in ITM needs to capture both qualitative and quantitative external information. Based on benchmarking’s potential to generate rich sets of such data, also in strategic settings, it is the tool of choice in this context. However, a strategic approach to external benchmarking requires sufficient internal anchorage in order to fully support SP. For this purpose, internal data, both quantitative and qualitative, needs to be captured and structured using the same FoR in order to be comparable to the external data from the peer group. 26 2.3. Competitive Analysis However, the interpretation of benchmarking data needs additional background. One source for this is the analysis of the environment of a company or, as in our case, the IT department. Since the work of Porter [35], the concept of competitive analysis has been widely accepted [22, 42], particularly in the context of strategy development [7, 10]. The concept of competitiveness is broadened by Wöhe and Döring [49], who point out that customers and suppliers also need to be taken into account, along with a company’s regulatory environment. Many authors have shown how IT and IS affect the competitive environment of companies [e.g. 8], but contemporary IT departments themselves require competitive analysis to account for their own drivers of competitive pressure. Zarnekow et al. [50] suggest that the modern value chain of IT departments is heavily reliant on suppliers. In this context, suppliers can become competitors, attracting demand from customers. This is especially true when an internal IT department starts to make its products and services available beyond the organization. Such an offering also calls for an analysis of customers in order to tailor products to their needs and changing requirements. To ensure that these perspectives are adequately taken into account in the strategic planning process of an IT department, they need to be integrated into an assessment of the strategic position. 2.4. Contextual Analysis While the external perspective constitutes an important set of information, general management has realized that external opportunities and threats need to be considered as well. Some authors include core competencies [49]. This concept, known as SWOT analysis and is mainly attributed to the work of Andrews [3], aims at a fit between the internal and external factors as a requirement for strategy formulation [29]. This perspective is widely accepted in the literature [22, 42]. Transferring this concept to ITM, the sections above already introduced the external perspective. To complete the set of relevant information, internal factors need to be taken into account. Building on general management, positioning in ITM has to take into account the profile of the IT department. Exemplary aspects are the role of the IT department in the company (e.g. minimize cost), its strengths and weaknesses (e.g. competent people), and the alignment with corporate strategy [47]. The importance of these aspects for SPITM is based on the need to interpret the data generated through benchmarking and the knowledge of the competitive environment on the basis of current capabilities and aims. The ability to correctly relate all this information to each other, in turn, is realized by employing a common FoR. 3. Methodology To analyze SPITM, we first reviewed the literature, following a concept-centric approach [45], which focused on established SP concepts in general management that are relevant to positioning an IT department. We then conducted three case studies to gain insights into which of the concepts in the literature are applied in SPITM practice. We also gathered the case participants’ input on the relevance and viability of the various concepts and studied their contribution to the overall SP process. The reason for choosing a case study approach is its ability to capture rich details, even in such complex domains as IT management and IT assessment [27]. In the cases, variation has been emphasized over replication to ensure the capture of different settings in which to observe the SP process. If any of the concepts identified during our literature review were used in practice, we documented their use. If an element was not used, we analyzed alternative approaches. At the end of each case, we conducted a workshop with IT managers in order to gain deeper insight into the reasons for the presence or absence of certain concepts. All materials were documented2) and analysis of the qualitative data was conducted following Schmidt 2 Details about the cases and their analysis are available from the authors on request. 27 [41]. Based thereon, we developed a SPITM framework that aggregates the concepts found in literature and practice. This framework not only lists the patterns, but also looks at the relations between them. Such an approach of classifying specific characteristics by summarizing commonalities found in discrete observations is in line with our aim of constructing a theory for analyzing the phenomenon of SPITM [19]. 4. Field Work In our case studies, we partnered with IT departments (ITD) that had expressed interest in SP. These companies either had contact to us via a benchmarking study we conducted in the past or joint project work. The sample thus represents a convenience sample. We participated in the ITDs’ strategic planning efforts and observed their SP activities. The following sections briefly introduce the host companies and highlight our main findings. 4.1. Case Studies Our first case study was the ITD of a large real estate company that is part of a large European trust and has also started serving external customers. The CIO and his directors for projects and operations faced the need to demonstrate IT’s contribution to the company’s goal achievement. In the assessment of the ITD’s strategic position, we observed an initial approach to SP that was based solely on benchmarking. At a later stage, they realized that additional information was needed to correctly interpret the data from benchmarking. This led to the adoption of an FoR and the introduction of elements of competitive analysis. At this stage, the approach did not yet include contextual factors; the need to do so was uncovered by the analysis of the data (e.g. the analysis of the IT project management processes). While the benchmark and competitive analysis revealed that the company was in an unfavorable position, the project success rate outperformed that of peers. Accounting for the capabilities of the experienced project managers, which had not been taken into account because they were not being documented, explained this contradiction. The project allowed the ITD to position itself differently and integrate these results into its strategic planning. Our second case study was the ITD of an international bank with offices in several countries. It is owned by a large automobile manufacturer. In a project to redefine the strategy of the whole bank, the ITD also went through the process of developing its new strategy. The bank chose balanced scorecards and strategy maps as tools for the strategy development and implementation. In the first phase of the overall project, the ITD sought to assess its current strategic position in the form of workshops with discussions among IT managers, guided by external consultants. Since the results remained too vague, the next step was the use of an FoR introduced by the consultants as well as the consideration of existing benchmarking data, both of which brought more objectivity and result orientation into the SP process. The contextual perspective emerged in the subsequent exchange with the project teams of other departments and the CEO’s office. As a result of this phase, the ITD clarified its current strategic position and formulated the desired future characteristics of its position in the bank. This was a direct input for the next phase of the project. We conducted our third case study in the ITD of an Austrian utility company. We observed an assessment and SP through conversations with project team members and analysis of project documentation. The assessment and positioning was a component of a project aiming at reorganizing the ITD. This was made necessary through internal requirements (based on an employee survey) as well as external pressure based on perceived high costs. The latter led the ITD to the adoption of an FoR for a service-oriented organization. The analysis of the status quo was conducted as part of a benchmarking initiative. Besides gathering data in the structures imposed by the FoR, the derivation of target values to achieve a competitive cost level was a motivation for pursuing a benchmarking approach. This introduced elements of a competitive analysis. The contextual element was integrated via document analysis and interviews. The project 28 was successfully concluded and the new ITD organizational structure of the ITD implemented. Results of the SP proved to be valuable in attaining buy-in from the business units of the company. 4.2. Interpretation of Case Studies When integrating the empirical observations and comparing them to the relevant general management literature, the following conclusions can be drawn towards a framework for SPITM: • All the cases relied on a FoR to structure and integrate their activities. It was also used to assign responsibilities and to check for completeness. This is in line with the literature (section 2.1.). • Benchmarking initiatives were part of all three cases. While one project (case 1) started off with benchmarking results, the others integrated benchmarking in later phases. Regardless of this, all the executives involved regarded comparable data as an essential aspect for SP. • All cases paid particular attention to external factors to account for their role in SP. • While one case (case 1) initially excluded a contextual analysis, the need to interpret the data and information generated in the positioning project proved the importance of these considerations. The other projects included capabilities among other factors. The elements derived from the literature review proved suitable to capture the strategic position of an ITD. We neither observed additional behavior that could not be described by means of the elements introduced in chapter 2, nor did we experience a case in which an element was systematically excluded from SP. Even though some elements were initially not considered (cases 1 and 2), the need to reintegrate them at a later point in the project illustrated their importance. 5. Framework for Strategic Positioning in IT Management Building on these findings, our proposed framework consists of five elements, as outlined in figure 1. The elements correspond to the patterns we have identified in our preceding literature review and empirical observations. The subsequent discussion presents each framework element by defining it, explaining its relationships to other elements, and relating it to the cases introduced above. 5.1. The suggested Framework The basis for SPITM is the usage of a FoR. It facilitates structuring all other elements, ensuring that data and information from these separate views on an ITD’s strategic position can be integrated. It is also needed to ensure the ability to conduct an SP in a distributed manner, i.e. to assign aspects to different roles and reintegrate them later. The core element for the SP is benchmarking. It is an established approach for generating data needed for comparison. For interpretation, the benchmarking needs to be extended by contextual and competitive analysis. These will help to correctly interpret the benchmarking. They are also partially dependent on benchmarking as a source of data. Aggregating all the information will ultimately constitute the strategic position of an ITD. Figure 1. Framework for strategic positioning in IT management While the structure of our framework is derived from the literature and the cases discussed above, the general structure of the approach can also be linked to general management. The strategic issue 29 analysis [23] aims at identifying, analyzing, and resolving strategic issues by methods centered around the classical SWOT elements. La Roche [26] proposes a flow chart that illustrates how competitive and contextual factors help establish strategic positioning. This position is the basis for the development of strategic alternatives and strategic decisions. Based on our analysis, positioning in ITDs is currently approached with a similar logic, despite the existence of other approaches in general management [26]. While scarce, there are also examples in IS literature. Kovacevic and Majluf [25] suggest a six-staged approach to ITM. They point to firm strategy, external analysis, and internal scrutiny as the basis for formulation and assessment of IT/IS strategy. However, they do not specify a data source for the planning approach and do account less for contextual factors. To further illustrate our framework, the following sections will elaborate on its elements and their interrelations, discuss exemplary approaches present in theory or practice, and establish quality criteria. Each section concludes by relating the element to observations we made during our cases. 5.2. Frame of Reference (FoR) Much work has been done in the field of providing a structure to the processes of ITM. However, most of this work focuses on the process of strategic planning, not on the general structure and contents of IT/IS strategy itself [43]. However, in the context of SP, this structure is needed as a core element of positioning efforts for reasons of inter-temporal and inter-subject comparability. SP can only provide insights into the current state and the changes of an ITD if it is based on a stable structure across entities and time. To date the work on such a general structure of ITM has been limited (section 2.1.). Moreover, reviewing the literature has shown that most of the approaches currently used to structure ITM are based on theoretical reasoning. Only Riempp et al. [38] tested their suggested FoR by means of three design science evaluation cycles. Based on the analysis of this element in the literature as well as from interviews and observations made during our case studies, we are suggesting a set of quality criteria for an FoR: (1) adequacy to and coverage of the realm of ITM, (2) reflection of real-world organizational structures as well as established disciplines and roles, (3) completeness of elements and ease of use to facilitate communication, (4) depiction of relevant fields of action and decision-making and their interrelation, (5) reflection of the market-oriented transition of IT departments, (6) acceptance by IT managers, (7) suitability to assess and compare ITM across several companies, and (8) suitability to assess and compare ITM across several time periods. Looking at the cases, we acknowledge that an academic framework is not the only one that can be used. As long as they fulfill the quality criteria suggested above, other approaches can also be used. 5.3. Benchmarking Drew [15] divides a benchmarking initiative into five phases. The first, the definition of what needs to be benchmarked in the context of SPITM is outlined by the FoR. It serves as a general guideline for the identification of required units of analysis and can be used to structure the competitive analysis. For each element of the FoR, relative key performance indicators (KPIs) and metrics are defined and applied for the own organization and those of the peer group. Useful qualitative information may be collected to support this benchmarking process, too. According to our research, benchmarking can be successfully implemented provided the following have been done: (1) meaningful metrics have been defined for all elements of the FoR, (2) the FoR and the metrics are accepted by the IT executives as well as the peer group, and (3) the benchmarking is properly implemented, in the sense that a peer group of comparable organizations has been found and that it consists of a sufficiently large number of participants. The analysis and interpretation of the data, Drew’s forth phase, is one of the most important steps. Our cases have shown that even though the immediate comparison of external and internal KPIs based on benchmarking may appear promising, their assessment does not allow for final 30 conclusions about the general performance of an ITD; this is only possible when the findings are interpreted in the light of additional contextual information, which helps explain why specific KPIs are what they are. This is why our framework includes an external and internal view. 5.4. Competitive Analysis Many ITDs and their business counterparts coordinate the delivery of IT through market-like interfaces. Thus, contractual arrangements reach the same level of detail, controlling mechanisms are comparable to those used for external service providers, and service prices need to be competitive. Since the business gains transparency about service scope, quality, and prices, an ITD needs to differentiate itself from external providers (e.g. providing better IT support due to higher process competence). Neither service quality nor service prices can be judged on their own. In order to come up with a valid assessment of an ITD’s performance, an external perspective is necessary. A possible way to integrate a competitive perspective into SP is a SWOT analysis. This needs to consider the opportunities and threats, along with the general factors determining the competitive environment. These include e.g. an analysis of the portfolio of products and services compared to competitors’ portfolios and customer needs or the price and quality levels of products and services. The literature suggests limiting such an analysis to ten factors [22]. To reduce the extent and the complexity of a competitive analysis, the selection of appropriate aspects to consider should be guided by the following criteria: (1) does the analysis cover all relevant aspects derived from current IT strategy, (2) can the required information be captured at a sufficiently reliable level, (3) which additional information is needed to interpret external, relative measures, (4) are legal requirements and regulations taken into account, (5) what are sources of change in the relevant environment, and (6) are the sources of information and data accessible. Looking at our cases, a major factor requiring elements of competitive analysis in SPITM is product and service costs. Even in companies in which IT is regarded as strategically important (e.g. case 2), the ITD needed to demonstrate competitive cost structures to justify internal production. 5.5. Contextual Analysis The investigation of relevant contextual factors requires extensive data gathering mainly targeting the ITD’s strengths and weaknesses. This will mostly involve document analysis and interviews. Documents of relevance are e.g. strategy documents or enterprise architecture models. Interviews may grasp factors that are not codified, e.g. cultural factors or plans that have not been documented. The aim of this analysis is to look at factors that help understanding how the ITD fits to its internal context. These factors may differ in nature and are strongly company-specific. However, during our research, we encountered a number of factor groups that appear to play an important role when analyzing an ITD’s position: (1) Strategic factors include information about past and present IT strategies or strategic planning and steering processes at the levels of the department and the organization. (2) Financial factors cover budgeting and investment decisions and information concerning decision-making and approval processes. (3) Regulatory factors play an increasingly important role. As a part of the contextual analysis, this aspect focuses on what operational implications regulations have for the organization. (4) Human resources factors influence the sphere for strategic action, e.g. when qualification levels of the workforce directly impacts the type of technologies that may be applied in the organization, or when competencies of the people working in an ITD are a central determinant for its success. Finally, (5) transitional factors are relevant for understanding an ITD’s strategic position. Ongoing business transformations, reorganization initiatives, or mergers and acquisitions may significantly impact all levels of the IT value chain – processes, applications and infrastructure. This element of SP is also structured using the same FoR. It serves as a general guideline for data gathering and analysis, assuring completeness and coherence. 31 From our research (e.g. case 1), we conclude that an adequate inside view has been constructed when all significant findings from the outside view can be explained using contextual factors and a consensus has been established that the contextual factors properly explain the ITD’s position. 5.6. Strategic Positioning (SP) When benchmarking, competitive analysis, and contextual analysis are at hand, the final step towards SP is the reintegration of the data and information generated towards a comprehensive and consistent profile of an ITD – its strategic position. While not being defined explicitly in general management literature, our literature study and empirical work produced a set of relevant aspects that an SP should cover. These are depicted in table 2 along with some examples. Table 2. Exemplary aspects of the strategic position of IT departments Examples Aspect cost minimizer, business enabler, innovator Role business monarchy, IT monarchy, federal, … Governance (e.g. following Weill and Ross [46]) central, local, within business units, shared Organization services; also cost vs. profit center Budgeting process top-down, bottom-up, joint, … with business units, ITD, split budgets, … Budget allocation department exclusively serving the company, Competitors or own company also serving third parties, … market structure highly standardized and codified, artesian, … Processes strong outsourcing, selective outsourcing, … Supply strategy Derived from elements contextual analysis contextual analysis, competitive analysis, benchmarking benchmarking, contextual analysis Cases 1, 2, 3 1, 2, 3 contextual analysis contextual analysis contextual analysis, competitive analysis benchmarking, contextual analysis benchmarking, contextual analysis 1, 2, 3 2, 3 1, 3 2, 3 1, 3 1 SP will have to take into account the ITD’s role. Many decisions in ITM need to be framed with respect to the ITD’s perceived or intended role. If, as in case 1, the department wants to position itself as a business enabler, the KPIs related to cost have a different meaning compared to the role of a cost minimizer. Similar logic applies to the governance aspects of an organization. These examples, along with the aspects presented in table 2, illustrate the interdependency of the aspects of SPITM, and illustrate the need for a multifaceted approach to SPITM, as introduced above. The contribution of benchmarking as well as the contextual and competitive analyses is integrated along the lines defined by the underlying FoR. Particularly the contrasting of the results of the benchmarking with the additional information gathered in the competitive and contextual analysis is a core activity in this step. Looking at established approaches for strategy development and formulation [22, 23, 26, 30], the strategic planning process can use the results from SP as a starting point for the development of an IT strategy and the derivation of action. With respect to our cases, all the companies used the result of the SP as a basis to formulate some kind of action program. While two companies (cases 1 and 2) decided to use the positioning project as a basis for strategic planning as a whole, the third company used the SP to conduct several important projects that supported their current IT strategy. In all cases, feedback from IT staff indicates that SP helped them in three ways: (1) being more conscious of their own position, (2) being able to improve alignment with the business units serviced, and (3) being able to ensure that operations, projects, and management decisions within IT actually fit the current IT strategy. 6. Limitations, Future Research, and Summary To correctly interpret the results of our work, some limitations need to be taken into account. Firstly, the use of case study research requires the presence of the researcher in the field. Consequently, the researcher might influence the behavior of the subject s/he wants to observe. We tried to take the necessary precautions [24] to minimize the adverse impact of this limitation. Secondly, for reasons of feasibility we had to constrain our research to a convenience sample. 32 Whilst acknowledging the higher generalizability of results based on theoretical sampling, we feel that accessibility of the companies that allowed us access to their confidential planning process outweighed this limitation. Thirdly, additional research has to be carried investigating what aspects need to be considered within the elements of the model introduced in this paper. While our work provides insights into SPITM, we also see opportunities for further research. One is the analysis of profiles that ITDs exhibit when being positioned according to the framework. Particular emphasis should be placed on the investigation of archetypal strategic positions, e.g. cost minimize vs. business enabler. This has the potential to integrate with the research on alignment [47]. Another area of research is the development of a method for SPITM. The research we have presented has introduced a framework of elements that such a method would need to cover. These opportunities can use our work as a point of departure. In structuring the elements needed to analyze the current strategic position of an ITD, we contribute to the understanding of this domain and the development of methods that are applicable in practice. The ability to conduct a proper positioning of an ITD is an integral part of integrating the processes and practices of ITM with general management. With this ability, ITDs will be able to improve their alignment with corporate strategy and hence further increase their value contribution to the business. Bibliography [1] AHMED, P.K., and RAFIQ, M., Integrated Benchmarking: A Holistic Examination of Select Techniques for Benchmarking Analysis, in: Benchmarking for Quality Management & Technology, 5, 3 (1998), pp. 225-242. [2] ALSHAWI, S., IRANI, Z., and BALDWIN, L., Benchmarking: Information and Communication Technologies, in: Benchmarking, 10, 4 (2003), pp. 312-324. [3] ANDREWS, K.R., The Concept of Corporate Strategy, Homewood, IL, USA 1971. [4] ARMSTRONG, J.S., The Value of Formal Planning for Strategic Decisions: Review of Empirical Research, in: Strategic Management Journal, 13, 3 (1982), pp. 197-211. [5] BALDWIN, L.P., IRANI, Z., and LOVE, P.E.D., Outsourcing Information Systems: Drawing Lessons from a Banking Case Study, in: European Journal of Information Systems, 10, 1 (2001), pp. 15-24. [6] BHUTTA, K.S., and HUQ, F., Benchmarking - Best Practices: An Integrated Approach, in: Benchmarking, 6, 3 (1999), pp. 254-268. [7] BLOODGOOD, J.M., and BAUERSCHMIDT, A., Competitive Analysis: Do Managers Accurately Compare Their Firms to Competitors?, in: Journal of Managerial Issues, 14, 4 (2002), p. 418. [8] BODDY, D., BOONSTRA, A., and KENNEDY, G., Managing Information Systems: An Organisational Perspective, Harlow, UK et al. 2005. [9] CHAKRAVARTHY, B., A New Strategy Framework for Coping with Turbulence, in: Sloan Management Review, 38, 2 (1997), pp. 69-82. [10] COBURN, M.M., GREENWOOD, D.J., and MATTEO, M.R., Supporting Strategy with Competitive Analysis, in: Research Technology Management, 45, 5 (2002), pp. 43-47. [11] CRAGG, P.B., Benchmarking Information Technology Practices in Small Firms, in: European Journal of Information Systems, 11, 4 (2002), pp. 267-282. [12] DATTAKUMAR, R., and JAGADEESH, R., A Review of Literature on Benchmarking, in: Benchmarking, 10, 3 (2003), pp. 176-209. [13] DEMIRKAN, H., and GOUL, M., Amcis 2006 Panel Summary: Towards the Service Oriented Enterprise Vision: Bridging Industry and Academics, in: Communications of AIS, 2006, 18 (2006), pp. 546-556. [14] DEPPERU, D., and GNAN, L., The Role of the Competitive Context in the Business Strategy-Formulation Process, in: International Studies of Management & Organization, 36, 3 (2006), pp. 110-130. [15] DREW, S.A.W., From Knowledge to Action: The Impact of Benchmarking on Organizational Performance, in: Long Range Planning, 30, 3 (1997), pp. 427-441. [16] EARL, M.J., Management Strategies for Information Technology, London, UK 1989. [17] EARL, M.J., and SAMPLER, J.L., Market Management to Transform the IT Organization, in: Sloan Management Review, 39, 4 (1998), pp. 9-17. [18] FETTKE, P., and LOOS, P., Classification of Reference Models: A Methodology and Its Application, in: Information Systems and E-Business Management, 1, 1 (2003), pp. 35-53. [19] GREGOR, S., The Nature of Theory in Information Systems, in: MIS Quarterly, 30, 3 (2006), pp. 611-642. [20] HATTEN, K.J., and SCHENDEL, D.E., Heterogeneity within an Industry: Firm Conduct in the U.S. Brewing Industry, 1952-71, in: Journal of Industrial Economics, 26, 2 (1977), pp. 97-113. 33 [21] HEIB, R., DANEVA, M., and SCHEER, A.-W., Benchmarking as a Controlling Tool in Information Management, in: Proceedings of the IFIP TC5 WG5.7 international workshop on modeling techniques for business process re-engineering and benchmarking, Bordeaux, France (1997), pp. 298 - 309. [22] HOPFENBECK, W., Allgemeine Betriebswirtschafts- Und Managementlehre, Landsberg/Lech, Germany 1998. [23] KING, W.R., Using Strategic Issue Analysis, in: Long Range Planning, 15, 4 (1982), pp. 45-49. [24] KLEIN, H.K., and MYERS, M.D., A Set of Principles for Conducting and Evaluating Interpretive Field Studies in Information Systems, in: MIS Quarterly, 23, 1 (1999), pp. 67-93. [25] KOVACEVIC, A., and MAJLUF, N., Six Stages of IT Strategic Management, in: Sloan Management Review, 34, 4 (1993), pp. 77-87. [26] LA ROCHE, U., Von Der Kunst, Mit Der "Richtigen" Produkt-Markt-Strategie-Methode Zu Planen, in: io Management Zeitschrift, 56, 3 (1987), pp. 135-139. [27] LEE, A., A Set of Principles for Conducting and Evaluating Interpretive Field Studies in Information Systems, in: MIS Quarterly, 23, 1 (1999), p. xvii. [28] LUFTMAN, J., and KEMPAIAH, R., An Update on Business-IT Alignment: "A Line" Has Been Drawn, in: MIS Quarterly Executive, 6, 3 (2007), pp. 165-177. [29] MINTZBERG, H., and LAMPEL, J., Reflecting on the Strategy Process, in: Sloan Management Review, 40, 3 (1999), pp. 21-30. [30] MINTZBERG, H., LAMPEL, J., QUINN, J.B., and GHOSHAL, S., The Strategy Process, Upper Saddle River, NJ, USA 2003. [31] MOCKER, M., and TEUBNER, A., Towards a Comprehensive Model of Information Strategy, in: Proceedings of the 13th European Conference on Information Systems, Regensburg, Germany (2005), pp. 747-760. [32] MÜLLER, B., AHLEMANN, F., and RIEMPP, G., IT-Benchmarking, in: is report, 11, 1+2 (2007), pp. 44-48. [33] OH, W., and PINSONNEAULT, A., On the Assessment of the Strategic Value of Information Technologies: Conceptual and Analytical Approaches, in: MIS Quarterly, 31, 2 (2007), pp. 239-265. [34] PORTER, M.E., Competitive Strategy, New York, NY, USA 1980. [35] PORTER, M.E., How Competitive Forces Shape Strategy, in: McKinsey Quarterly (1980), pp. 34-50. [36] PRYOR, L.S., Benchmarking: A Self-Improvement Strategy, in: The Journal of Business Strategy, 10, 6 (1989), pp. 28-32. [37] RATHNAM, R.G., JUSTIN, J., and WEN, H.J., Alignment of Business Strategy and IT Strategy: A Case Study of a Fortune 50 Financial Services Company, in: The Journal of Computer Information Systems, 45, 2 (2004), pp. 18. [38] RIEMPP, G., MÜLLER, B., and AHLEMANN, F., Towards a Framework to Structure and Assess Strategic IT/IS Management, in: Proceedings of the 16th European Conference on Information Systems, Galway, Ireland (2008). [39] RÜEGG-STÜRM, J., Das Neue St. Galler Management-Modell, Bern, Switzerland et al. 2003. [40] SCHEER, A.-W., and NÜTTGENS, M., ARIS Architecture and Reference Models for Business Process Management, in: Aalst, W.M.P.V.D., Desel, J., and Oberweis, A., (eds.), Business Process Management Berlin, Heidelberg 2000, pp. 376-389. [41] SCHMIDT, C., Analyse Von Leitfadeninterviews, in: Flick, U., Von Kardorff, E., and Steinke, I., (eds.), Qualitative Forschung: Ein Handbuch, Reinbeck 2003, pp. 447-456. [42] STEINMANN, H., SCHREYÖGG, G., and KOCH, J., Management. Grundlagen Der Unternehmensführung, Wiesbaden, Germany 2005. [43] TEO, T.S.H., and ANG, J.S.K., How Useful Are Strategic Plans for Information Systems?, in: Behaviour & Information Technology, 19, 4 (2000), pp. 275-282. [44] WATSON, G.H., Strategic Benchmarking: How to Rate Your Company’s Performance against the World’s Best, New York, NY, USA 1993. [45] WEBSTER, J., and WATSON, R.T., Analyzing the Past to Prepare for the Future: Writing a Literature Review, in: MIS Quarterly, 26, 2 (2002), pp. xiii-xxiii. [46] WEILL, P., and ROSS, J.W., IT Governance: How Top Performers Manage IT Decision Rights for Superior Results, Boston, MA, USA 2004. [47] WEISS, J.W., THOROGOOD, A., and CLARK, K.D., Three IT-Business Alignment Profiles: Technical Resource, Business Enabler, and Strategic Weapon, in: Communications of the Association for Information Systems, 2006, 18 (2006), pp. 676-691. [48] WILLCOCKS, L., and LESTER, S., Beyond the IT Productivity Paradox, in: European Management Journal, 14, 3 (1996), pp. 279-290. [49] WÖHE, G., and DÖRING, U., Einführung in Die Allgemeine Betriebswirtschaftslehre, Munich, Germany 2002. [50] ZARNEKOW, R., BRENNER, W., and PILGRAM, U., Integriertes Informationsmanagement: Strategien Und Lösungen Für Das Management Von IT-Dienstleistungen, Berlin 2007. 34 MEASURING CLIENT-VENDOR DISTANCE IN GLOBAL OUTSOURCING RELATIONSHIPS: A CONCEPTUAL MODEL Katharina Vogt, Robert Gregory, Roman Beck1 Abstract The objective of this paper is to develop a conceptual model for client-vendor distance in global IS outsourcing relationships as previous research on this issue is scarce. A multi-dimensional construct is deductively developed deploying the theory of psychic distance as a theoretical lens. A key finding is that client-vendor distance in global IS outsourcing relationships is constituted by several characteristics that go beyond language barriers, geographical distance, and cultural distance. Thus, the paper lays the grounds for the development of a theory-based measurement model of client-vendor distance in IS. Furthermore, subtle differences exist between near- and offshoring arrangements concerning the relevance and strength of individual dimensions. 1. Introduction The increasing amount of information systems and global services outsourcing is an apparent trend that is expected to continue in the foreseeable future [23]. The worldwide market for global IT outsourcing services is growing at a fast pace: IDC estimates that expenditures for IT offshoring will increase 14.4 percent on average in the USA and 16.5 percent in Western Europe until 2009 [20]. This is not surprising, considering the associated benefits of cost advantages that client firms can achieve due to significant differences in labor costs between Western countries and offshore locations in Middle and Eastern Europe and Asia [25]. However, these cost advantages do not materialize easily: global outsourcing relating to “inter-country outsourcing” in terms of offshore (including nearshore) outsourcing, is accompanied by unique challenges that can offset the expected benefits [23]. Offshore-specific risks result primarily from client-vendor distance, encompassing not only the geographic dimension but several others such as cultural, economic, and political dimensions [10]. Numerous studies have identified different dimensions of IS clientvendor distance in offshore projects, including managerial issues how to overcome the problems resulting from them [10; 24]. While previous research has enhanced our understanding of individual dimensions of client-vendor distance in IS offshoring, few attempts have been made to create an overall construct that captures the most salient dimensions for both nearshore and offshore client-vendor distance in IS. Moreover, there is still a lack of understanding as to what extent client-vendor distance differs in near- and offshore arrangements [6; 23]. Thus, more research is needed to depict the defining dimensions and characteristics of client-vendor distance in 1 E-Finance Lab & Institute of Information Systems, Johann Wolfgang Goethe University, Grüneburgplatz 1, 60323 Frankfurt am Main, Germany 35 global IS outsourcing relationships. Hence, the goal of this research is the development of a concept explaining client-vendor distance in near- and offshore IS outsourcing relationships. For this purpose, and because the existing literature in IS on this issue is scarce, the literature stream on ‘psychic distance’ is used as a theoretical lens for the conceptualization process. The concept of psychic distance originates from international trade research [2] and is based on the assumption that there is a psychic distance between countries in a trade relationship that can hinder effective intercountry collaboration [9]. Our goal is to adapt this construct from international trade and business research to the IS domain and identify those dimensions that fit with existing research in IS to create a model of client-vendor distance in global IS outsourcing relationships. Moreover, our goal is to gain a deeper understanding of the differences between client-vendor distance in IS nearshoring and offshoring. In summary, our main research question is: “What constitutes the distance between client and vendor in global IS outsourcing relationships?” The remainder of this research paper is structured as follows. In the next section we will provide the theoretical foundation for studying this research question. In section three we will develop a theoretically grounded conceptual model which specifies the dimensions of client-vendor distance in global IS outsourcing relationships and discuss the near- and offshore-specific characteristics of clientvendor distance. Section four is pointing out the limitations as well as opportunities for further research. The paper ends with theoretical and practical contributions alike. 2. Theoretical Foundations 2.1. Offshoring and Nearshoring of Information Systems and Services Prior research on global IS outsourcing has pointed to the challenge of geographic distance between client and vendor, including primarily time zone differences [8; 13; 30]. Some studies have also looked at language barriers, the most frequently mentioned problem is the lack of English skills of the service provider’s staff [8; 30; 37]. A further dimension of client-vendor distance concerns the cross-cultural differences: numerous studies have analyzed cultural barriers in global IS outsourcing projects, while the predominant research has focused on culture differences on a national level [8; 18; 24; 27; 30]. However, more recently attempts have also been made in IS to study culture at the individual level of analysis [17; 36]. Other issues of client-vendor distance in global IS outsourcing have also been mentioned, including differences in institutions, market structures, economies, politics, and intellectual property regulations [30; 31]. While the overwhelming amount of previous research in IS has not made a clear distinction between different types of IS offshoring, there are calls for further research to depict the subtle differences between offshoring and nearshoring, among others [23]. In particular, research on IS nearshoring is gaining momentum [6]. However, there is very little literature on this special form of global outsourcing. This becomes especially apparent when looking for a definition of nearshore outsourcing. Despite its increasing consideration in the clients sourcing strategies [6], there is still a lack of a sophisticated understanding of this outsourcing option. In contrast to the various offshoring definitions which can be synthesized to “a form of outsourcing performed outside the client organization’s home country” [23], often but not always associated with another continent [26], up to now nearshore outsourcing is primarily defined through its differentiation from offshoring in terms of spatial distance: whereas any location outside the client’s home country can be called an offshore location, nearshore locations are mainly associated with geographical proximity to the client’s home country [1; 6; 10]. In summary, research in the areas of global IS outsourcing, as well as globally distributed IS outsourcing teams, provide a large number of studies addressing different dimensions of client-vendor distance in global IS outsourcing relationships. However, there is no consensus upon a common framework capturing the defining dimensions and 36 characteristics of client-vendor distance. The following section provides a literature review of psychic distance research in international trade, marketing, and business that will be used subsequently as a theoretical lens for the conceptualization. 2.2. Research on Psychic Distance in International Trade, Marketing, and Business The roots of psychic distance date back to Beckerman (1956) who argued that international trade is not only influenced by economic distance, but is also exposed to a “special problem […] by the existence of ‘psychic’ distance” [2]. This argument has been picked up by a group of Scandinavian researchers adopting the concept of psychic distance for their research of the firms’ internationalization process [21; 22]. In the meantime, psychic distance has evolved to be a central concept in the international business literature [35] and has been applied mainly to explain international market selection [15]. Even though some of these studies have put psychic distance on a par with cultural distance [29; 33], there exists a significant conceptual difference between the two concepts. While cultural distance reflects dissimilarities in cultural values among countries and therefore needs to be applied at the country level of analysis, psychic distance is based on the individual sensitivity to dissimilarities between countries and therefore focuses on the individual level of analysis [35]. Moreover, several researchers have identified cultural distance as one out of several dimensions of psychic distance [4; 11; 14; 15; 34]. This view is also supported by the findings of an empirical study examining the impact of psychic distance on organizational performance where only an operationalization of psychic distance using both cultural and business differences contributed to the significantly relevant explanation of organizational performance [14]. Furthermore, recent research results suggest that factors such as local skill levels, social and political stability, host government policy, as well as previous experience with the respective country may have been underrated hitherto with regards to their impact on the individual’s perception of psychic distance [9]. Last but not least, the classification of cultural distance as a dimension of psychic distance is consistent with the suggestion of several researchers to examine culture not only at the country level of analysis but at the individual level [16; 19], since the psychic distance concepts allows for a measurement of cultural differences as perceived by individuals [35]. As any form of global outsourcing can be understood as a form of international trade [3], we are convinced that the application of the psychic distance concept to the IS outsourcing domain is legitimate. Moreover, the ‘psychic distance paradox’ [28] makes the application of the concept to the IS domain interesting for a further reason. The ‘psychic distance paradox’ refers to the risk that the assumption of little psychic distance between the home and the foreign country could lead to the underestimation of actual differences and as a consequence could prevent managers from sharpening their awareness in this regard [28]. As nearshore outsourcing is often being associated with cultural proximity [6], relating to an assumed small psychic distance [35], according to the psychic distance paradox there is definitely a risk of mispricing the “cost for covering distance” [2]. 2.3. Psychic Distance – Definitions and Operationalizations The theoretical concept of psychic distance is based on the assumption of a perceived psychic gap between two countries arising from multifaceted dimensions such as language, culture, religion, education, political systems, business practices, level of development, time zone, laws, and others [4; 9; 12; 34]. However, despite its comprehensive use, no consistent definition of psychic distance has yet emerged throughout the international business literature [9]. Early definitions address the importance of knowing foreign markets, e.g. referred to as “flows of information”[22] or “a firm's degree of uncertainty” [28] and define psychic distance as the “factors preventing or disturbing the flows of information” [22]. More recently, researchers highlight the implications of cultural and 37 other differences for the companies’ international market selection: according to them, psychic distance results from the “perception of both cultural and business differences” [14], leading to a feeling of distance between the home and the foreign country [9; 14; 15]. Whereas Child et al. [9] enhanced the concept by differentiating between distance creating, distance compressing, and distance bridging factors, Sousa and Bradley’s [35] understanding of psychic distance emphasized the individual’s perspective. According to the variety of definitions, the available operationalizations of psychic distance differ [29]. Table 1 gives a brief overview over the main operationalizations within the last years. Table 1: Operationalizations of psychic distance Sousa and Bradley (2005) Dow and Karunaratna (2006) Cultural values, beliefs, attitudes, and traditions Culture Language Language Social ties (Cultural and language similarities, sport preferences) Geographic distance (incl. temporal and climatic differences) Climatic conditions Time zones Geographic ties (not mentioned) (not mentioned) Political systems Political ties Economic differences Level of economic and technological development (not mentioned) Industrial / economic development Development (not mentioned) Level of education, Education level (not mentioned) Differences in market structure Level of literacy and education (not mentioned) (not mentioned) (not mentioned) Commercial ties (not mentioned) (not mentioned) (not mentioned) Colonial links Historic ties Evans and Mavondo (2002) Cultural distance Language differences (not mentioned) Legal & political differences Child et al. (2002) Culture (incl. differences in language) Brewer (2007) The following dimensions have been mentioned in the respective operationalization only. Differences in business practice Purchasing power of customers Lifestyles Consumer preferences Religions Information ties Most of the above presented operationalizations of psychic distance feature the differences between the home and the foreign countries [4; 9; 14; 34]. Brewer’s [4] operationalization of psychic distance however is based on the understanding of psychic distance “as factors preventing or disturbing the flows of information between firm and market” and thus sharpens the understanding of psychic distance through emphasizing the development of knowledge about foreign country markets [4]. He argues that – instead of perceived similarities or dissimilarities – especially the managers’ familiarity with foreign markets is shaping the concept of psychic distance [4]. We adopt his operationalization for our research due to the knowledge-intensive nature of global IS outsourcing. 38 3. Model Development 3.1. Characterizing Dimensions of Client-Vendor Distance in Global IS Outsourcing Relationships In order to construct a model of client-vendor distance in global IS outsourcing relationships, we use Dibbern et al.’s [10] conceptualization of offshore-specific client-vendor distance as a starting point. Concentrating on the interaction between client and vendor, the researchers selected geographic and culture distance as well as language barriers to be the most salient factors creating client-vendor distance [10]. We intend to broaden this view based on numerous results from international trade research indicating that a couple of other factors may also contribute significantly to the perceived distance between client and vendor [4; 11; 14; 15; 34]. Thus, we enhance the existing concept of client-vendor distance by additional categories based on the theoretical concept of psychic distance. As already outlined before we therefore adopt the operationalization of Brewer [4]. In order to identify the characterizing dimensions of client-vendor distance, we map the client-vendor distance measures that have been indentified from the near- and offshore outsourcing literature to the national psychic distance elements defined by Brewer [4]. In the process, we find the factors described in the domain literature to be mostly congruent with the operationalization of psychic distance. Thus, we use the psychic distance elements as the foundation for our model. However, taking into account the particularities of the global IS outsourcing domain and building upon prior research in IS, we need to conduct the following adjustments in the sense of modifying existing elements as well as adding a new dimension . An overview on the mapping results including the modifications is presented in table 2. Table 2: Mapping of psychic distance elements with characteristics identified from the global IS dimension Psychic distance Dimensions of client-vendor distance from offshore outsourcing literature Dimensions of client-vendor distance from nearshore outsourcing literature Commercial ties [6] Market dimension [26] Market dimension [1; 26] Political ties [6] Political / economic dimension [10] Legal dimension [10; 26; 30; 31] Political / economic dimension [1; 6; 26] Legal dimension [30] Historic dimension [1; 6] Historic ties [6] Geographic ties [6] Geographic dimension [7; 8; 10; 30] Temporal dimension [7; 10; 30; 31] Social ties [6] Information ties [6] Cultural dimension [10; 18; 24; 30; 31] Language dimension [10; 30; 37] ./. Geographic dimension [1; 6]; Temporal dimension [1; 6; 30] Accessibility dimension [1] Cultural dimension [1; 6; 26; 30] Language dimension [1; 6; 26; 30] ./. Development [6] Infrastructure dimension [10; 30; 31] Infrastructure dimension [1; 30] Level of education [9; 12; 34] Personnel dimension [26; 31] Personnel dimension [1; 26] First, we disaggregate the element ‘social ties’ which is reflected through the indicators cultural and language similarities as well as sport preferences and adopt the view of the global IS outsourcing literature where the cultural and the language dimension are commonly treated as two discrete dimensions. We do not include the indicator sport preferences because in contrast to cultural and language differences, this factor is not presumed to have a big impact on IS business client-vendor relationships. With regards to the element ‘geographic ties’, we add the temporal dimension 39 (different time zones) as these two characteristics are commonly used to represent the spatial distance in global outsourcing arrangements. The same holds for the element ‘political ties’ which we complement with a legal dimension, thereby acknowledging the role of legal issues in global IS outsourcing. To our knowledge, ‘information ties’ referring to the availability of secondary information on the foreign country as well as to immigration numbers have not been used as a measure for client-vendor distance in the global IS outsourcing literature so far. Moreover, this factor has not been part of any of the other operationalizations. However, resuming Brewer’s [4] knowledge-centric understanding of psychic distance, we consider information ties to be relevant for client-vendor distance in global IS outsourcing relationships based on the assumption that a broad information base enables managers to more easily learn about a foreign country and thus decreases the managers’ psychic distance to this country. As the availability of well-educated resources has been emphasized to be a key success factor for offshore outsourcing [26], we finally argue to additionally include the dimension „level of education“ being cited by several studies elaborating on psychic distance [9; 12; 34]. Based on the mapping results described above, we create a model of client-vendor distance in global IS outsourcing relationships suggesting that client-vendor distance in global IS outsourcing relationships is constituted by several characteristics that go beyond language barriers, geographical distance, and cultural distance. An overview of the dimensions definitions is presented in Table 3. Table 3: Client-Vendor-Distance – Definition of Constituting Factors Client-Vendor Distance Dimensions Definition Commercial dimension The commercial dimension refers to existing commercial relationships such as “imports and exports of both goods and services” [4]. Political dimension The political dimension refers to “close political relationships” [4]. Historic dimension The historic dimension refers to former colonial relationships as well shared wars [4]. Geographic dimension Temporal dimension Cultural dimension Language dimension Information dimension Development dimension Educational dimension The geographic dimension refers to the actual “geographic distance between countries” [4]. The temporal dimension refers to the time zone differences between client and vendor [12]. The cultural dimension refers to cultural differences between client and vendor [4]. The language dimension refers to language preferences in terms of national language, business language, or alphabet [4]. The information dimension refers to the availability of secondary information on the foreign country [4]. The development dimension refers to the “level of development of the foreign country” [4]. The educational dimension refers to “differences in education levels among countries” [12]. 3.2. Comparing Client-Vendor Distance in Off- and Nearshore Outsourcing Relationships If we now compare nearshoring with offshoring, the main differences between these two forms of global outsourcing are the level of geographic distance and time zones differences [9; 37]. Therefore, client firms in a nearshore arrangement have lower communication and coordination costs than client firms in an offshore arrangement [26]. Furthermore, based on the assumption of 40 cultural and linguistic proximity [6; 30], less misunderstandings might occur [26]. Both nearshore and offshore outsourcing are associated with lower wage costs [5]. However, the wage level in nearshore locations is claimed to be higher [30].This might partly be justified through a competitive educational system. In Middle and Eastern Europe for instance, the number as well as the quality of university graduates equals to Western Europe as well as to the US [26]. Thus, well-educated personnel is available but costly; the lower wage costs of India can only be realized in a nearshore arrangement when turning towards so called “emerging nearshore destinations” [30]. However, in contrast to established emerging nearshore locations often lack appropriate professional experience [30], as they are just evolving to become a well-developed market for IS outsourcing services [26]. The historical dimension referring to past linkages such as colonial relationships has only been found in the nearshore related literature. One explanation could be, that in nearshore arrangements a however natured historic relationship can be taken as granted as nearshore destinations are typically neighboring countries of the clients’ home country. However, we assume that there are other kinds of historical linkages which are directly related to the geographical proximity. The exploration of these potential linkages is subject to future research. Resuming the discussion above, client-vendor distance-related issues not only arise in offshore but also in nearshore arrangements. However, our analysis shows that the importance of the constituting factors of this distance differ in comparison to offshore outsourcing [30]. As of today, academic literature on nearshore outsourcing is scarce: only few scientific publications explicitly cover the nearshore phenomenon. Moreover, publications on offshore outsourcing do often not state the host country [23] so that the identification of potential nearshore outsourcing projects is difficult. This lack of empirical and non-empirical data on nearshore outsourcing needs to be addressed in future research. Further ideas for further research activities will be discussed in the subsequent section. 4. Limitations and Further Research There are several limitations to be taken into account. First and foremost, it should be recognized that the client-vendor distance model depicted above has been deductively derived from the existing literature. No empirical data was at our disposal in order to challenge and, if applicable, complement the concept. Thus, the findings may miss dimensions that are influencing client-vendor distance in practice but are not captured in the scientific literature yet. Second, it should be kept in mind that we based our analysis on a scarce literature basis with regards to the nearshore phenomenon. In reference to the study’s limitations, several opportunities for future research become apparent. First, as our work has been conceptual so far, we consider qualitative interviews to be an interesting research opportunity in order to further explore today’s model. Moreover, it would be promising to conduct a quantitative study to empirically validate the theoretical model as well as to evaluate the relative importance of the individual concepts of client-vendor distance and their interplay. Furthermore, we would like to encourage researchers to contrast client versus vendor perspectives in the process, as client-vendor distance in interorganizational exchange relationships is not necessarily symmetric in nature [32]. For example, an Indian vendor already having several customers from Germany might perceive a smaller psychic distance as a German client starting his first offshore project with an Indian vendor. Implications for future research emerge also from the previous discussion on nearshore outsourcing which is slightly different from offshore outsourcing. Thus, further research is needed to study more in detail the difference between client-vendor distance in nearshoring as opposed to offshoring arrangements. In this context it would be also interesting to evaluate the specifics of client-vendor distance in outsourcing relationships comprising only one country. 41 5. Conclusion This paper is the first attempt to develop a comprehensive concept of client-vendor distance in global IS outsourcing relationships. Prior work mainly discussed the well-known challenges resulting from geographic and time zone differences, cultural distance and language barriers. By applying a theoretical lens from international trade literature (i.e. psychic distance), we are able to offer a broader view on the most salient dimensions for both nearshore and offshore client-vendor distance. By doing so, we lay the grounds for the development of a theory-based measurement model of client-vendor distance in IS. The main theoretical contribution of this paper is the deductive development of a model for client-vendor distance in near- and offshore arrangements increasing our understanding of psychic distance in interorganizational exchange relationships in general and in global IS outsourcing relationships more specifically. Furthermore, we enhance the domain literature through the introduction of a new theoretical concept, i.e. the psychic distance concept from international trade research. The paper also offers some practical contributions: based on the depicted multifaceted client-vendor distance in global IS outsourcing relationships, managers can learn to increase their familiarity with vendors from foreign countries also beyond intercultural training programs. For instance, studying secondary information on the foreign country will increase the knowledge on the host country and concurrently might decrease the feeling of distance. Furthermore, the identified dimensions of client-vendor distance can be taken into account in the course of the vendor selection process. From a vendor perspective, especially (emerging) nearshore destinations would probably be well advised to develop their unique selling points based on the knowledge of distance-creating characteristics identified above. This could then result in nearshore-specific application scenarios deploying the phenomenon’s as well as the country’s individual strengths. 6. References [1] ABBOTT, P.; JONES, M., Everywhere and Nowhere: Nearshore Software Development in the Context of Globalisation, in: 2nd International Conference on Management of Globally Distributed Work 2007 [2] BECKERMAN, W., Distance and the Pattern of Intra-European Trade, in: Review of Economics and Statistics. 38 (1956) 1, pp. 31-40. [3] BHAGWATI, J. N.; PANAGARIYA, A.; SRINIVASAN, T. N., The Muddle over Outsourcing, in: Journal of Economic Perspectives. 18 (2004) 4, pp. 93-114. [4] BREWER, P. A., Operationalizing Psychic Distance: A Revised Approach, in: Journal of International Marketing. 15 (2007) 1, pp. 44-66. [5] CARMEL, E.; ABBOTT, P., Configurations of Global Software Development: Offshore versus Nearshore, in: Proceedings of the 2006 international workshop on Global software development for the practitioner, Shanghai, China 2006 [6] CARMEL, E.; ABBOTT, P., Why "Nearshore" Means that Distance Matters, in: Communications of the ACM. 50 (2007) 10, pp. 40-46. [7] CARMEL, E.; AGARWAL, R., Tactical Approaches for Alleviating Distance in Global Software Development, in: IEEE Software. 18 (2001) 2, pp. 22-29. [8] CARMEL, E.; AGARWAL, R., The Maturation of Offshore Sourcing of Information Technology Work, in: MIS Quarterly Executive. 1 (2002) 2, pp. 65-78. [9] CHILD, J.; NG, S. H.; WONG, C., Psychic Distance and Internationalization, in: International Studies of Management and Organization. 32 (2002) 1, pp. 36-56. 42 [10] DIBBERN, J.; WINKLER, J.; HEINZL, A., Explaining Variations in Client Extra Costs Between Software Projects Offshored to India, in: MIS Quarterly. 32 (2008) 2, pp. 333-366. [11] DOW, D., A Note on Psychological Distance and Export Market Selection, in: Journal of International Marketing. 8 (2000) 1, pp. 51-64. [12] DOW, D.; KARUNARATNA, A., Developing a Multidimensional Instrument to Measure Psychic Distance Stimuli, in: Journal of International Business Studies. 37 (2006) 5, pp. 578-602. [13] ESPINOSA, J. A.; DELONE, W.; LEE, G., Global Boundaries, Task Processes and IS Project Success: A Field Study, in: Information Technology & People. 19 (2006) 4, pp. 345-370. [14] EVANS, J.; MAVONDO, F. T., Psychic Distance and Organizational Performance: An Empirical Examination of International Retailing Operations, in: Journal of International Business Studies. 3 (2002) 33, pp. 515-532. [15] EVANS, J.; MAVONDO, F. T.; BRIDSON, K., Psychic Distance: Antecedents, Retail Strategy Implications, and Performance Outcomes, in: Journal of International Marketing. 16 (2008) 2, pp. 32-63. [16] FORD, D. P.; CONNELLY, C. E.; MEISTER, D. B., Information Systems Research and Hofstede's Culture's Consequences: An Uneasy and Incomplete Partnership, in: IEEE Transactions on Engineering Management. 50 (2003) 1, pp. 8-25. [17] GREGORY, R.; PRIFLING, M.; BECK, R., Managing Cross-Cultural Dynamics in IT Offshore Outsourcing Relationships: The Role of Cultural Intelligence in: Second Global Sourcing Workshop, Val d'Isere, France 2008 [18] HEEKS, R.; KRISHNA, S.; NICHOLSON, B.; SAHAY, S., Synching or Sinking: Global Software Outsourcing Relationships, in: IEEE Software. 18 (2001) 2, pp. 54-60. [19] HONG, Y.-Y.; CHIU, C.-Y., Toward a Paradigm Shift: From Cross-Cultural Differences in Social Cognition to Social-Cognitive Mediation of Cultural Differences, in: Social Cognition. 19 (2001) 3, pp. 181-196. [20] IDC, Titel, in: City 2006. [21] JOHANSON, J.; VAHLNE, J.-E., The Internationalization Process of the Firm—A Model of Knowledge Development and Increasing Foreign Market Commitments, in: Journal of International Business Studies. 8 (1977) 1, pp. 23-32. [22] JOHANSON, J.; WIEDERSHEIMPAUL, F., Internationalization of Firm - 4 Swedish Cases in: Journal of Management Studies. 12 (1975) 3, pp. 305-322. [23] KING, W. R.; TORKZADEH, G., Information Systems Offshoring: Research Status and Issues, in: MIS Quarterly. 32 (2008) 2, pp. 205-225. [24] KRISHNA, S.; SAHAY, S.; WALSHAM, G., Managing Cross-Cultural Issues in Global Software Development, in: Communications of the ACM. 47 (2004) 4, pp. 62-66. [25] MEYER, T., India's Specialization in IT Exports: Offshoring Can't Defy Gravity, in: Deutsche Bank Research. (2007) pp. 1-26 (available online at http://www.dbresearch.com/PROD/DBR_INTERNET_ENPROD/PROD0000000000217530.pdf). [26] MEYER, T.; STOBBE, A., Welche "Standorte" wählen deutsche Unternehmen?, in: Wirtschaftsinformatik. 49 (2007) Sonderheft, pp. 81-89. [27] NICHOLSON, B.; SAHAY, S., Some Political and Cultural Issues in the Globalisation of Software Development: Case Experience from Britain and India, in: Information and Organization. 11 (2001) 1, pp. 25-43. [28] OGRADY, S.; LANE, H. W., The Psychic Distance Paradox, in: Journal of International Business Studies. 27 (1996) 2, pp. 309-333. 43 [29] OJALA, A.; TYRVAINEN, P., Market Entry and Priority of Small and Medium-Sized Enterprises in the Software Industry: An Empirical Analysis of Cultural Distance, Geographic Distance, and Market Size, in: Journal of International Marketing. 15 (2007) 3, pp. 123-149. [30] RAO, M. T., Key Issues for Global IT Sourcing: Country and Individual Factors, in: Information Systems Management. 21 (2004) 3, pp. 16-21. [31] ROTTMAN, J.; LACITY, M. C., Twenty Practices for Offshore Outsourcing, in: MIS Quarterly Executive. 3 (2004) 3, pp. 117-130. [32] SHENKAR, O., Cultural Distance Revisited: Towards a More Rigorous Conceptualization and Measurement of Cultural Differences, in: Journal of International Business Studies. 32 (2001) 3, pp. 519-535. [33] SHOHAM, A.; ALBAUM, G. S., Reducing the Impact of Barriers to Exporting: A Managerial Perspective, in: Journal of International Marketing. 3 (1995) 4, pp. 85-105. [34] SOUSA, C. M. P.; BRADLEY, F., Global Markets: Does Psychic Distance Matter?, in: Journal of Strategic Marketing. 13 (2005) 1, pp. 43-59. [35] SOUSA, C. M. P.; BRADLEY, F., Cultural Distance and Psychic Distance: Two Peas in a Pod?, in: Journal of International Marketing. 14 (2006) 1, pp. 49-70. [36] SRITE, M.; KARAHANNA, E., The Role of Espoused National Cultural in Technology Acceptance, in: MIS Quarterly. 30 (2006) 3, pp. 679-704. [37] ZATOLYUK, S.; ALLGOOD, B., Evaluating a Country for Offshore Outsourcing: Software Development Providers in the Ukraine, in: Information Systems Management. 21 (2004) 3, pp. 28-33. 44 THE (LACKING) BUSINESS PERSPECTIVE ON SOA – CRITICAL THEMES IN SOA RESEARCH Goetz Viering, Christine Legner, Frederik Ahlemann1 Abstract Service-oriented architecture (SOA) has gained much popularity lately, in both practice and academia. Since SOA concepts and technology are maturing, companies have started to engage in projects that will fundamentally transform IS landscapes over the next decade. While the growing body of SOA research is mostly technology-oriented, the IS community needs to investigate the strategic, organizational, and managerial issues associated with SOA implementation. This paper profiles SOA and Web services research since 2000 with a focus on practices, adoption, and impact. Drawing on a sample of 175 papers in academic journals and conference proceedings, we establish transparency of the current state of research. Our analysis finds that the science base for SOA research from an IS perspective is still under construction thereby reflecting the novelty of the underlying technologies. We conclude that business aspects remain underserved and derive a number of recommendations for the IS community on how to proceed with SOA research. 1. Introduction Since the term service-oriented architecture was originally coined by Gartner analysts in 1996 [32], it has gained much popularity in both practice and academia. Owing to the hype around Web service technologies and the subsequent announcements of software vendors, such as SAP, IBM, and others to incorporate Web services and SOA in their product suites, the service-oriented paradigm has been revitalized in the early 2000s. In the meantime, researchers have started to explore how loosely coupled services can be combined and rearranged in order to flexibly support the needs of end-users within and across organizations. They have come up with a large variety of SOA scenarios and prototypes. At the same time, a scientific discourse has been initiated, resulting in debates among renowned researchers [9, 26, 45, 47], literature reviews [23, 28, 36] or propositions for research agendas [36]. This discourse contributes to defining the service-oriented paradigm and analyzing its specificities compared to prior concepts, notably software components or object orientation. While our scientific understanding of SOA is improving and technology is maturing, a more detailed analysis of the management-related questions associated with SOA design, adoption, and impact in practice is still lacking. Taking into consideration that 63% of all North-American, European, and Asian-Pacific companies are already using SOA, or will start using it by the end of 2008 [17], there is a need for an academic discussion on the manifold strategic, organizational and managerial issues related to it. Given the sheer volume of SOA research, it seemed obvious that a sur1 Institute of Research on Information Systems, European Business School, D-65375 Oestrich-Winkel. 45 veying of the literature could assist in identifying and aggregating the different perspectives in this field of research. Drawing on a sample of 175 articles in peer-reviewed journals and conference proceedings, this article investigates the current state of research. To this aim, we use a research framework that is based on generic IS research questions and focuses on SOA adoption, practices, and impact. Our analysis delineates several areas that remain underserved and that offer researchers the opportunity to contribute to the development of the field of SOA research. Consequently, we aim at establishing a science base for future research. The paper is organized as followed: part 2 provides an overview of the methodology and the framework of analysis. This is followed by the results section of the literature review. From the discussion of the results, we derive several areas that remain underserved. Finally, a summary and conclusion is provided that also discusses the limitations of this study. 2. Framework of Analysis and Methodology 2.1 The SOA Discourse: Framework of Analysis Through a literature review, the exposure of theoretical foundations in an emerging issue like the field of SOA can be tackled and areas where research is needed are uncovered [49]. Recognizing the suggestions of Webster & Watson [49] and Fettke [11], a literature review framework is helpful in guiding the literature analysis. We develop such a framework of analysis (c.f. Figure 1) by deriving four general SOA research questions based on Gregor’s taxonomy of theory types in IS [14]: • What are the characteristics of the SOA paradigm? This research question aims at analyzing and describing the phenomena of interest. In addition to their definitions, the fundamental constructs (artifacts) that characterize SOA as an architectural paradigm and their relationships are of particular relevance. The what is question often results in Theory for Analyzing (Type I) according to the taxonomy suggested by Gregor [14]. It is seen as the most basic type of theory as it provides the realist ontology required for further research. • How – and to what extent – are SOA concepts adopted in practice? There are many IS innovations that – due to technical, cultural or economic factors – have not made their way to broader implementation in practice. In this regard, it is of interest for researchers to analyze adoption and diffusion of SOA concepts in and between organizations. This will ultimately lead to insights into adoption patterns and the factors that determine successful SOA implementations. It will also explain the emerging web services offerings and market mechanisms. Answering this research question requires researchers to conduct empirical studies and to collect observations from the field. It typically results in Theories for Explaining (type II) [14]. • How to design, implement, and manage SOAs? This research question aims at specifying how organizations should apply the SOA concept, and might be most valuable from the practitioner’s point of view. It is associated with a constructivist type of research or design science, resulting in frameworks, reference models, methods, and management practices. Gregor [14] classifies this type of theory as Theory for Design and Action. • What is the organizational impact of SOA? While most computer scientists agree that the service-oriented paradigm has clear benefits in terms of technical quality attributes, it has been difficult to economically justify SOA. Researchers consequently need to come up with approaches and methodologies for describing and measuring the impact of SOA. Given the multiple facets of SOA, technical as well as economic and strategic impacts of SOA concepts need to be considered. Consequently, research will most likely produce Theories for Explaining and Predicting [14], with testable propositions and causal explanations. 46 Figure 1: Framework of Analysis 2.2 Literature Selection Process As the basis of our literature review, we relied on the AIS Meta Ranking [38] which has a wide acceptance among researchers as an international journal meta-ranking which combines different scientific approaches. A set of key words (“SOA”, “service-oriented”, “web services”, “component-based”, “CORBA”, and “architecture”) was used in a first step to identify journals, which were further investigated. Following Webster and Watson’s suggestion [49], we then checked the journals’ tables of content from January 1990 to December 2007 in order to identify articles on SOA and web services. Since our focus is on SOA adoption, practices and impact in organizations, we excluded articles from the computer science domain that solely focus on the technical concepts that underlie SOA. For this paper, only articles containing the term SOA and/or web service in the title or abstract were taken into account. Articles that appeared in 2008 and papers from selected IS conferences were also included in the analysis. Since our analysis was targeted at reviewing the current state of research, we did not include publications that are not peer-reviewed, such as monographies. 2.3 Review and Classification Process During the review and classification process, we analyzed and coded the selected publications by focusing on the following three aspects: the general publication data, including sub-codes for the year of publication, the publication type (conference or journal), and the primary focus (SOA or web services). Then, the research methodology where we relied on the taxonomy developed by Wilde and Hess [50]. In order to cover literature reviews, we added literature analysis which has been suggested by Palvia et al. [35]. Classification of the research methodology and the general publication data was performed “top-down” [42] by one author and checked by another author. In the third step, we analyzed and coded the content according to the framework of analysis presented in section 2.1. We developed the coding scheme for the content using Weber’s eight necessary steps of Creating and Testing a Coding Scheme [48]. For the assignment to one of the four key research questions, classification was based on the stated research objectives of the paper. For Weber’s first necessary step, we defined the recording unit as the sentence. Next, we identified categories by using an initial open test coding [12] on a sample of 28 randomly selected articles. The results of this initial phase were discussed among the authors and classified to one of the four research questions of the reference frame resulting in the first sub-codes. Then, two rounds of axial coding [46] were performed by two authors in a step-wise manner on the complete set of data. If none of the initial codes were suitable, new sub-codes were added. In the third step, we tested for inter-rater reliability by comparing the results of the two rounds. Differing views between the two coders were discussed until agreement was reached. All resulting categories were critically as- 47 sessed and singular cases were selectively reassigned to a different key research question. In a third iteration, each paper was assigned to a final category. In some cases, multiple research objectives were pursued, which led to the assignment of a secondary classification. The derivation of research opportunities was based on a careful comparison of our framework’s analysis dimensions with the literature found. 3. Results 3.1 Overview From the tables of contents of 37 journals that we checked, we identified 175 articles within the scope of our analysis. Approximately two thirds of all articles refer rather to the specific technology of Web services (#112) than to SOA (#63). Only a small portion was covering both key words (#9). However, as the run of the curve of the following graph indicates, increasingly more scientific papers about SOA than about Web services are being published for the last 2 years. We interpret this as an indicator that the research community found consensus on the distinction of the two terms. Furthermore, we see a constant increase of publications in this research topic while press releases in mid-2007 claimed that the SOA hype is over [29]. Publications seem to reflect the increase of research objects from the field as SOA diffuses among companies. In addition, a very active scientific debate has started with special issues in high ranked journals, such Wirtschaftsinformatik (1/2008). 45 40 35 30 25 20 15 10 5 0 Web Services SOA Sum 2000 2001 2002 2003 2004 2005 2006 2007 2008 Figure 2: SOA and Web Services Publications by Year of Publication 3.2 Content Classification On the level of the four research questions, most articles proposed suggestions on how to design, implement, and manage SOAs (#86/49%) followed by papers analyzing the adoption (#37/21%) and investigating the phenomena of SOA and Web services (#31/18%). With 11%, only a minor portion of the publications analyze the impact of SOA and Web services in practice. The analysis of the sub-codes identified during the review and classification process, provides us with some further insights into the current state of research: With regard to the first research question “What are the characteristics of the SOA paradigm?”, the majority of the papers (#18/10%) investigate the primary SOA and Web services artifacts and discuss standards. This category is followed by 10 papers (6%) that aim at defining SOA or Web services or contribute to aggregating various definitions. The sub-category SOA Products relates to presentations and critical evaluations of SOA suites of vendors. We identified only few papers which describe products from three large software vendors namely IBM [10], Microsoft [40] and SAP [53]. Publications on the second area of research (“How are SOA and web services adopted in practice?”) comprise case descriptions which are either teaching cases [13] or case documentations of SOA implementations in practice. Besides case descriptions (#13/7%), the sub-category Assimilation / Adoption is most prominent with also 13% of all publications. For the third research question (“How to design, implement, and manage 48 SOAs?”), the analysis clearly illustrates that it has attracted the most interest from the research community (#86/49%). Together, the following four sub-categories represent 91% of all the papers in this area of research: Publications that suggest enhancements of SOA and Web services concepts are the topic of 29 papers (17%), while 23 papers (13%) investigate domain-specific architecture designs. 14 papers (8%) provide suggestions and practices for service management, and 12 publications suggest methods for implementing SOA or designing services. The smallest fraction of papers focuses on the fourth research question “What is the economic impact of SOA and web services?” With ten papers, the largest sub-category in this field (#10/6%) comprises publications investigating the benefits of web services and SOA. The second largest category includes six papers that are focusing on methodologies to measure the impact and the actual impact measurement (#6/3%). Frequencies (primary classification) # % 1. SOA Concepts: What are the characteristics of the SOA paradigm? 31 18% Artifacts and Standards 18 10% Definitions 10 6% Products 3 2% 2. SOA Adoption: How are SOA and web services adopted in practice? 37 21% Cases 13 7% Assimilation / Adoption 13 7% Success and Influence Factors 3 2% IT Infrastructure 2 1% Service Management 3 2% Web Service Offerings and Markets 3 2% 3. SOA Practices: How to design, implement, and manage SOAs? 86 49% Architecture Design with SOA/WS (Enhancements and Extensions) 29 17% Architecture Design with SOA/WS (Domain Specific) 23 13% Implementation Methods 12 7% Organization and Governance 4 2% Reference Models 4 2% Service Management 14 8% 4. SOA Impact: What is the organizational impact of SOA? 19 11% Benefits 10 6% Impact Measurement / Methodologies 6 3% IT Infrastructure 1 1% ROI 2 1% not assignable 2 1% Total 175 100% Table 1: Content Classification according to the Framework of Analysis Content Classification according to the Areas of SOA Research Frequencies (incl. multiple classifications) # % 38 18% 22 11% 11 5% 5 2% 50 24% 17 8% 21 10% 3 1% 3 1% 3 1% 3 1% 92 45% 29 14% 26 13% 14 7% 5 2% 4 2% 14 7% 24 12% 15 7% 6 3% 1 0% 2 1% 2 1% 206 100% 3.3 Analysis of Research Methods Our analysis reveals that all methods from Wilde and Hess’s spectrum of IS research methods [50] were classified at least once, except ethnography and Grounded Theory. The undisputed majority of researchers are using a conceptual-deductive research method (#75/43%), thus relying upon the authors’ experience, observation, or thought, followed by papers arguing deductively (#32/18%). Case studies were the preferred choice for empirical analysis (#24/14%). Large-scale empirical studies using surveys or qualitative and quantitative cross-section analysis were scarce. It is important to note that a combination of several methods was frequently applied. As an example, concep- 49 tual models were tested by the means of Prototypes, Laboratory and Field Experiments, consequently following a design science approach [18] with evaluation cycles. Frequencies (primary classification) # % 2 1% 32 18% 24 14% 8 5% 75 43% 4 2% 10 6% 0 0% Research Methodology Frequencies (multiple classifications) # 2 32 26 9 77 19 10 18 Action Research Argumentative Deductive Research Case Study Formal Deductive Research Conceptional Deductive Research Laboratory / Field Experiment Literature Analysis Prototyping Qualitative/ Quantitative Cross- Sectional Analy9 5% 11 sis Reference Modeling 6 3% 6 Simulation 1 1% 3 not assignable 4 2% 4 Total 175 100% 217 Table 2: Classification according to Research Methods Employed % 1% 15% 12% 4% 35% 9% 5% 8% 5% 3% 1% 2% 100% 4. Discussion of Findings – Current State of Research and Research Challenges 4.1 SOA Concepts: What are the Characteristics of the SOA Paradigm? Most authors refer to the core Web services standards http, XML, SOAP, and WSDL and the W3C architecture when defining Web services [21]. While there is consensus on Web services definitions, the understanding of SOA is still under discussion. Several authors take a “historical” perspective and argue that SOA extends well-known concepts, notably software componentization and object-orientation [4, 44, 45]. At the same time, services are said to differ from components or objects, e.g. in terms of granularity and interface-orientation [7]. An increasing number of publications refer to SOA as an architectural style, which builds on services as key artifacts [2, 8, 20, 25, 33]. However, opinions differ more widely when it comes to the design principles that characterize SOA as an architectural style. The key challenge here is the lack of consistency between authors with respect to terminology, emphasis, and the levels of abstraction used to organize the design principles. Furthermore, most publications do not relate SOA to prior (enterprise) architecture conceptualizations. Among the early attempts is the architecture model by Legner and Heutschi [27], which extends an existing enterprise architecture model by specifying SOA artifacts at the IS architecture layer. In order to cover the business perspective, future research needs to explore how SOA alters prior enterprise architecture conceptualizations and architecture frameworks. Given the versatility of the SOA concept, it is recommended that future research complements the generic SOA definitions with taxonomies and typologies that characterize service and SOA designs. 4.2 SOA Adoption: How are SOA and Web Services Adopted in Practice? To date, SOA adoption in practice has mainly been studied based on case studies from real-world implementations. Some industries, notably the financial sector, are much more present in these studies than others [1, 2]. While case studies allow researchers to gain valuable insights into SOA adoption, their findings still lack a broader empirical validation. A small group of researchers has started to investigate factors that influence SOA and Web services implementation success [1], while others explores SOA adoption by means of the diffusion of innovation theory. Xu et al. [51] 50 and Haines [16] derive models for measuring the assimilation of SOA from prevailing innovations theories. The studies of SOA adoption are complemented by research on emerging third-party service offerings and market opportunities for service providers. Initial work has been performed with regard to classifying the evolving Web service offerings and their business and pricing models [34]. Given the early stage of research, multiple research opportunities exist. Case study research needs to be complemented by conceptual frameworks that build on prior IS theories. In view of the versatility of the service-oriented paradigm and the differences between industries, it is necessary to particularly investigate the contingencies that exist with regard to SOA adoption. Ideally, this research would identify SOA adoption patterns and success factors. With regard to the market for Web services, there is a need to further explore the specificities compared to other markets of digital goods. 4.3 SOA Practices: How to Design, Implement, and Manage SOAs? Our literature review indicates a concentration of research in this area. Most authors emphasize that Web service standards and SOA frameworks do not yet fully address real-world requirements. As demonstrated by our analysis, a tremendous effort has been undertaken to explore and enhance the design of SOAs and Web services environments, resulting in two types of research contributions: (1) conceptual approaches for extending and enhancing the existing architecture models, and (2) the design of SOAs and Web services environments for specific domains. The first type of research contributions comprises various conceptualizations to enable dynamic Web services composition in order to flexibly support business processes within and across organizations. Among the suggested concepts are Web-services based workflows [5, 24], matching mechanisms [22], and context-aware Web services [30]. Additionally, a very active research community develops semantic descriptions of standard Web services with the help of WSDL-S, ontologies, etc. [3, 41, 52]. With a different focus, the second stream of research comes up with reference architectures or architecture designs for specific domains. Our analysis finds that e-Commerce, supply chain management, knowledge and document management as well as ubiquitous and mobile computing are amongst the most popular domains for SOA implementations. However, a key challenge for future research consists in the analysis of differences and commonalities and the assessment of different SOA and service designs. This calls for a debate on how the quality of SOA designs can be assessed and measured. Consequently, a necessity for widely accepted criteria for the business design of services and reference scenarios arises, as in the case of the Semantic Web Contest, which might provide a valuable input to this debate. With regard to the future design of SOA, the emerging discipline of service engineering offers a number of research opportunities. First, design principles and methodologies for service design need to be further enhanced and validated in order to cover functional as well as non-functional aspects. Second, researchers need to come up with service design proposals for specific domains. While most of the existing research still focuses on the design of SOA-based information systems, many scholars emphasize that SOA imposes major challenges for IT departments that have traditionally been organized around applications. So far, this aspect is being addressed by research on service life-cycle methodologies [37] or visualization tools for service management [6]. Hence, an interesting opportunity for research relates to the implications of the service-oriented paradigm for the strategic IT management in organizations, in terms of roles and governance. 4.4 SOA Impact: What is the Organizational Impact of SOA and Web services? The existing work on SOA impact can be categorized in two streams of research: The first one aims at explaining SOA impact by developing models that explain the business impact of SOA. As an example, Huang integrated web services with competitive strategies using a balanced scorecard approach [19], whereas Müller et al. [31] suggest causal links between SOA design principles and SOA benefits. The second stream of research identifies SOA benefits. This comprises visionary papers [15] as well as or studies of benefits in specific scenarios, for example customer relationship management [43] or small and medium-sized enterprises [39]. From the literature review, two main 51 limitations in the current state of research were identified: first, there is still no model for analyzing the economic rationale for SOA based on prior IS theories. In this regard, the current debate on SOA’s business impact fails to pick up on earlier IS research on the effectiveness and value of IS. Second, the existing studies have investigated SOA benefits based on single or multiple case studies. They have identified a great variety of benefits of SOA implementations that range from infrastructure to operational, organizational, and strategic benefits. However, their findings have neither been systematically consolidated into a framework nor validated by means of a broader empirical basis. Future SOA research needs to apply and extend prior IS theories and systematically study how SOA improves the capabilities of an organization which in turn creates business value. Field of Research 1. SOA Concept: What are the characteristics of the SOA paradigm? State of Discussion • SOA as architectural style characterized by artifacts and design principles • Web services as the promising SOA implementation technology • SOA case studies • Innovation theory for explaining SOA adoption • Extensions and enhancements of SOA (process composition, semantics, …) • SOA design for specific domains • Service life-cycle management Future Research Challenges • SOA in the context of enterprise architectures • SOA and service taxonomies / classifications 2. SOA Adoption: • Conceptual models explaining SOA adopHow are SOA and web tion services adopted? • Success factors based on empirical studies 3. SOA Practice: • Assessment criteria for SOA/service design How to design, imple• Domain-specific reference architectures ment, and manage SOAs? • Methodologies for service engineering • SOA in the context of strategic IT management 4. SOA Impact: • Exploration of SOA benefits based on • Benefit frameworks covering strategic, What is the organizational case studies operational and technical dimensions impact of SOA? • Several lines of argumentation for • Models explaining the economic rationale explaining SOA business impact for SOA based on prior IS theories Table 3: SOA Research – Status and Future Research Challenges 5. Summary and Conclusions This paper profiles the existing SOA and Web services research based on four generic research questions. Our analysis of 175 publications has shown that SOA and Web services research has significantly developed since 2000. Nevertheless, the literature analysis also illustrates the early stage of research in this field, since most publications focus on either enhancing SOA and Web service concepts or exploring their adoption in practice. Interestingly, few publications address the remaining two fundamental research questions, namely the characteristics of the SOA paradigm and the organizational impact of SOA. However, “analytic theory is necessary for the development of all the other types of theory” [14]. This need for clarifying the fundamental definitions related to our phenomena of interest might also explain the difficulties in further exploring its adoption as well as assessing the quality of SOA and service designs. Most importantly, we conclude that business aspects are still underserved by SOA research. This generates future research opportunities related to the four research questions: in order to better understand and describe the role of SOA in organizations, IS researchers need to relate SOA to the broader context of the enterprise architecture. With regard to SOA adoption, the existing case study research has to be complemented by conceptual frameworks that build on prior IS theories for explaining SOA adoption and success factors. The future design of SOAs calls for more research in the field of service engineering, covering non-functional aspects as well as domain-specific business logic. From the perspective of strategic IT management, more research is needed to explore the implications of SOA, particularly related to roles and governance. In order to further understand the impact of SOA, researchers need to further investigate how SOA investments improve a firm’s capabilities and thereby create business value. While our study provides interesting insights into the current state of SOA research, it is 52 important to mention the limitations: First, the focus of our literature analysis has been peerreviewed journal and selected conference publications. While this ensures the quality of the publications, it excludes valuable contributions that have been presented at workshops or are currently in the review process for journal publication. Second, we limited our scope to SOA and Web services, thereby excluding predecessors of SOA, notably CORBA. Third, the field of SOA and Web services is extremely dynamic with a strong increase in publications over the last three years. Consequently, our research presents a mere snapshot of the SOA field. References [1] ANDERSON, D., HOWELL-BARBER, H., HILL, J., JAVED, N., LAWLER, J., and ZHENG, L., A Study of Web Services Projects in the Financial Services Industry, in: Information Systems Management, 22, 1 (2005), pp. 66-76. [2] BASKERVILLE, R., CAVALLARI, M., HJORT-MADSEN, K., PRIES-HEJE, J., SORRENTINO, M., and VIRILI:, F., Extensible Architectures: The Strategic Value of Service-Oriented Architecture in Banking, European Conference on Information Systems 2005, 2005. [3] BELL, DAVID, CESARE, SERGIO, IACOVELLI, NICOLA, LYCETT, MARK, MERICO, and ANTONIO, A framework for deriving semantic web services, in: Information Systems Frontiers, 9, 1 (2007), pp. 69-84. [4] BIRMAN, K.P., Like it or not, web services are distributed objects, in: Communications of the ACM, 47, 12 (2004), pp. 60-62. [5] BUHLER, P.A., and VIDAL, J.M., Towards Adaptive Workflow Enactment Using Multiagent Systems, in: Information Technology and Management, 6, 1 (2005), pp. 61-87. [6] DE PAUW, W., LEI, M., PRING, E., VILLARD, L., ARNOLD, M., and MORAR, J.F., Web Services Navigator: Visualizing the execution of Web Services, in: IBM Systems Journal, 44, 4 (2005), pp. 821-845. [7] ELFATATRY, A., Dealing with change: components versus services, in: Communications of the ACM, 50, 8 (2007), pp. 35-39. [8] ERL, T., Service-oriented Architecture. Concepts, Technology, and Design, Upper Saddle River 2005. [9] EYMANN, T., and WINTER, R., SOA – Ein neues Paradigma der Gestaltung verteilter Informationssysteme? , in: Wirtschaftsinformatik, 50, 1 (2008), p. 70. [10] FARRELL, J.A., and KREGER, H., Web services management approaches, in: IBM Systems Journal, 41, 2 (2002), p. 212. [11] FETTKE, P., State-of-the-Art des State-of-the-Art: Eine Untersuchung der Forschungsmethode „Review“ innerhalb der Wirtschaftsinformatik, in: Wirtschaftsinformatik, 48, 4 (2006), pp. 257-266. [12] GLASER, B.G., Theoretical sensitivity. Advances in the methodology of Grounded Theory, Mill Valley 1978. [13] GLASER, J.P., Too Far Ahead of the IT Curve?, in: Harvard Business Review, 7/8 (2007), pp. 29-39. [14] GREGOR, S., The Nature of Theory in Information Systems, in: MIS Quarterly, 30, 3 (2006), pp. 611-642. [15] HAGEL III, J., and BROWN, J.S., Your Next IT Strategy, in: Harvard Business Review, 79, 9 (2001), pp. 105113. [16] HAINES, M., Levels of Web Service Adoption: From Technical Solution to Business Opportunity, Americas Conference on Information Systems 2003 2003. [17] HEFFNER, R., SOA Adoption: Budgets Don't Matter Much, Forrester Research, 2008. [18] HEVNER, A.R., MARCH, S.T., PARK, J., and RAM, S., Design Science in Information Systems Research, (2004). [19] HUANG, C.D., and QING, H., INTEGRATING WEB SERVICES WITH COMPETITIVE STRATEGIES: THE BALANCED SCORECARD APPROACH, in: Communications of AIS, 2004, 13 (2004), pp. 57-80. [20] HUHNS, M.N., and SINGH, M.P., Service-oriented Computing: Key Concepts and Principles, in: IEEE Internet Computing, 9, 1 (2005), pp. 75-81. [21] HÜNDLING, J., and WESKE, M., Web Services: Foundation and Composition, in: Electronic Markets, 13, 2 (2003), p. 108. [22] JUHNYOUNG, L., and PARK, M.S., INTEGRATION AND COMPOSITION OF WEB SERVICE-BASED BUSINESS PROCESSES, in: Journal of Computer Information Systems, 44, 1 (2003), pp. 82-92. [23] KACZMAREK, T., and WĘCEL, K., Hype over Service Oriented Architecture Continues, in: Wirtschaftsinformatik, 50, 1 (2008), pp. 52-58. [24] KHALAF, R., KELLER, A., and LEYMANN, F., Business processes for Web Services: Principles and applications, in: IBM Systems Journal, 45, 2 (2006), pp. 425-446. [25] KRAFZIG, D., BANKE, K., and SLAMA, D., Enterprise SOA, 2004. [26] LAARTZ, J., SOA revolutioniert das Management in: Wirtschaftsinformatik, 50, 1 (2008). [27] LEGNER, C., and HEUTSCHI, R., SOA Adoption in Practice - Findings from Early SOA Implementations, European Conference on Information Systems 2007, Universtity of St. Gallen, 2007. 53 [28] LEYKING, K., DREIFUS, F., and LOOS, P., Serviceorientierte Architekturen, in: Wirtschaftsinformatik, 49, 5 (2007), pp. 394-402. [29] LIEBHART, D., SOA nach dem Hype, manage it, ap Verlag GmbH, 2007, pp. 74-77. [30] MAAMAR, Z., BENSLIMANE, D., and NARENDRA, N.C., What can context do for web services?, in: Communications of the ACM, 49, 12 (2006), pp. 98-103. [31] MÜLLER, B., VIERING, G., AHLEMANN, F., and RIEMPP, G., Towards Understanding the Sources of the Economic Potential of Service-Oriented Architecture: Findings from the Automotive and Banking Industry, European Conference on Information Systems 2007, Universtity of St. Gallen, 2007. [32] NATIS, Y., Service-Oriented Architecture Scenario, Stamford 2003. [33] NEWCOMER, E., and LOMOW, G., Understanding SOA with Web Services, Maryland 2004. [34] NÜTTGENS, M., and DIRIK, I., Geschäftsmodelle für dienstebasierte Informationssysteme – Ein strategischer Ansatz zur Vermarktung von Webservices, in: Wirtschaftsinformatik, 50, 1 (2008), pp. 31-38. [35] PALVIA, P., LEARY, D., EN, M., VISHAL, M., PRAVEEN, P., and SALAM, A.F., Research Methodologies in MIS: An Update, in: Communications of the Association for Information Systems, 2004, 14 (2004), pp. 526-542. [36] PAPAZOGLOU, M.P., TRAVERSO, P., SCHAHRAM, D., LEYMANN, F., and KRÄMER, B.J., ServiceOriented Computing: A Research Roadmap, Dagstuhl Seminar Proceedings 2006 Internationales Begegnungs- und Forschungszentrum für Informatik (IBFI), 2006. [37] PAPAZOGLOU, M.P., and VAN DEN HEUVEL, W.-J., Life Cycle Methodology, in: Communications of the ACM, 50, 10 (2007), pp. 79-85. [38] RAINER JR., R.K., and MILLER, M.D., Examining differences across journal rankings, in: Communications of the ACM, 48, 2 (2005), pp. 91-94. [39] RAY, A.W., and RAY, J.J., Strategic benefits to SMEs from third party web services: An action research analysis, in: The Journal of Strategic Information Systems, 15, 4 (2006), pp. 273-291. [40] ROBB, D., At Your Service: .NET Redefines the Way Systems Interact, in: Information Strategy: The Executive's Journal, 19, 1 (2002), p. 13. [41] SAYAH, J.Y., and ZHANG, L.-J., On-demand business collaboration enablement with web services, in: Decision Support Systems, 40, 1 (2005), pp. 107-127. [42] SCHMIDT, C., "Am Material": Auswertungstechniken für Leitfadeninterviews, in: Friebertshäuser, B., and Prengel, A., (eds.), Handbuch Qualitative Forschungsmethoden in der Erziehungswissenschaft, Weinheim 1997, pp. 544-568. [43] SHAH, J.R., and MURTAZA, M.B., EFFECTIVE CUSTOMER RELATIONSHIP MANAGEMENT THROUGH WEB SERVICES, in: Journal of Computer Information Systems, 46, 1 (2005), pp. 98-109. [44] SIEDERSLEBEN, J., SOA revisited: Komponentenorientierung bei Systemlandschaften, in: Wirtschaftsinformatik, 49, Sonderheft (2007), pp. 110-117. [45] SINZ, E.J., SOA und die bewährten methodischen Grundlagen der Entwicklung betrieblicher IT-Systeme in: Wirtschaftsinformatik, 50, 1 (2008), pp. 70-72. [46] STRAUSS, A., and CORBIN, J., Grounded Theory in Practice, Thousand Oaks 1997. [47] STREIBICH, K.-H., Der Paradigmenwechsel ist in vollem Gange in: Wirtschaftsinformatik, 50, 1 (2008), pp. 7374. [48] WEBER, R.P., Basic Content Analysis, London 1990. [49] WEBSTER, J., and WATSON, R.T., Analyzing the Past to Prepare for the Future: Writing a Literature Review, in: MIS Quarterly, 26, 2 (2002), pp. xiii-xxiii. [50] WILDE, T., and HESS, T., Forschungsmethoden der Wirtschaftsinformatik - Eine empirische Untersuchung, in: Wirtschaftsinformatik, 49, 4 (2007), pp. 280-287. [51] XU, H., SHARMA, S.K., and HACKNEY, R., Web services innovation research: Towards a dual-core model, in: International Journal of Information Management, 25, 4 (2005), pp. 321-334. [52] YE, C., LINA, Z., and DONGSONG, Z., Ontology-Supported Web Service Composition: An Approach to Service-Oriented Knowledge Management in Corporate Financial Services, in: Journal of Database Management, 17, 1 (2006), p. 67. [53] ZENCKE, P., and EICHIN, R., SAP Business ByDesign – Die neue Mittelstandslösung der SAP, in: Wirtschaftsinformatik, 50, 1 (2008), pp. 47-51. 54 GESCHÄFTSMODELLE FÜR BUSINESS SERVICES Das World Wide Web (WWW) hat zur Entwicklung einer Vielzahl spezialisierter Dienste geführt. Während einige dieser Dienste auf spezifische Anforderungen des WWW ausgerichtet sind (z.B. Suchdienste, Online Community Dienste), haben andere das Dienstleistungsspektrum im Umfeld des klassischen (offline) Geschäfts erweitert. Der Track betrachtet Dienstleistungsinnovation aus der Perspektive von Geschäftsmodellen: Was sind die spezifischen Leistungsversprechen, wie kann ein Netzwerk von Dienstleistungsanbietern konfiguriert werden und wie können Erträge erzielt werden? Darüber hinaus sollen Anforderungen an die Gestaltung, Innovation und Konfiguration von Dienstleistungen sowie die Verbindung zwischen Online- und Offline-Angeboten erörtert werden. Leitungsgremium: Stefan Klein, Westfälische Wilhelms-Universität Münster (Federführender) Hubert Österle, Universität St. Gallen Yves Pigneur, Universität Lausanne Programmkomitee: Philipp Bensel, Technische Universität Berlin Eric Dubois, Centre de Recherche Public Henri Tudor, Luxembourg Jaap Gordijn, Free University Amsterdam Claudia Loebbecke, Universität Köln Carolin Löffler, Universität Erlangen Thomas Mörsdorf, T-Online, Darmstadt Alexander Osterwalder, Arvetica, Genf Gertraud Peinel, Fraunhofer FIT Esko Penttinen, Helsinki School of Economics Alexander Schwinn, eBay GmbH, Kleinmachnow Frederic Thiesse, Universität St. Gallen Nadine Vehring, Universität Münster Maria Wimmer, Universität Koblenz BUSINESS MODELS FOR EGOVERNMENT THE BMeG METHOD Gertraud Peinel1, Matthias Jarke, Thomas Rose2 Abstract So far, business models have been investigated in the context of eCommerce focusing on economic issues but they do not consider the viewpoints of authorities embarking on public private partnerships for citizen services. This paper describes our modelling method BMeG that is dedicated to the planning of business models for eGovernment services. BMeG allows one to model options of value chains with various perspectives including advantages and disadvantages with impacts on policies. BMeG depicts the added value of potential partnerships and thus supports authorities to decide on alliances for public private partnerships or other financing models for eGovernment services. 1. Introduction Public sector information furnishes a valuable information resource for many businesses. Thus, the design of value chains across different stakeholders capitalizing on public sector information is an interesting business issue. Apart from overcoming data exchange deficiencies, the question arises of how to set-up a business collaboration between the private as well as the public sector. Our initial experience is based on a project for the dissemination of air quality information in the context of European air quality portals (APNEE [1]). Here, environmental agencies wanted to provide better services to citizens by timely delivering air quality information also on mobile phones (via SMS) to reach the citizen anywhere and anytime whenever certain emission values change for the worse. Such a service certainly targets people suffering from asthma, but could also inform the unaware general public about hazardous episodes in order to have an influence on their behaviour (e.g., they are going by bus instead of using the car due to smog warnings). The question is: should a public actor implement and operate such a kind of service alone, or might this also be an attractive business opportunity for a private stakeholder? But, how to generate tangible as well as intangible benefits and revenues for all partners in such a value chain, or in other words, how to design a sustainable business model? Citizens and businesses ask for public services available at all times and all places. This calls for a provision of services by different access channels, i.e., Internet, mobile and fixed phone, voice server and the like („one-stop services and seamless government“ [2]). Such demand for innovations from public authorities (innovation pull) fosters the utilisation of new technologies, which in turn enables new transaction patterns between public administrations and the citizen (technology push). However, public coffers are almost empty. Hence, authorities hesitate to invest in solutions 1 2 Fraunhofer FIT, PRO, Schloß Birlinghoven, 53754 Sankt Augustin, Germany RWTH Aachen, Lehrstuhl Informatik V, Ahornstr. 55, 52056 Aachen, Germany 57 with an uncertain acceptance and impact and therefore most authorities tend to focus on the most visible mean, i.e., Internet services. But, attractive eGovernment essentially calls for push services, which notify actively about news and changes. This can be done by email, fax, but especially fast and efficient by short message services (SMS) taking into account the current spread of mobile phones in the world. Unfortunately, SMS causes additional costs compared to the Internet since the sending of messages must be reimbursed to the telecommunication provider. Moreover, such implementations are often tailored to one specific telecommunication provider and seldom shared with other departments. Cost and effort savings are therefore not generated [3]. On the other hand, commercial information service providers are searching for new content and services to improve their position in competition. Taking into account the market value of public sector information (68,5 billion Euro already in the year 2000 [4]) and the technical capabilities of commercial information service providers, public authorities should open their repositories and cooperate with the private sector, instead of acting as lone fighters and hindering the development of market-driven services [5]. Therefore, public private partnerships should be investigated in the course of planning eGovernment services [6]. Such partnerships can be conceptualised as value chains describing the roles and relationships of cooperating organisations, the exchange of goods, information and money between these partners and the main advantages for each party, which is in fact the definition of business models according to [7]. It is clear that this concept also applies to the domain of eGovernment, since public authorities are also offering products and services to citizens (G2C) and business (G2B). Once such cooperations are modelled, contributions of single stakeholders to multilateral value chains become explicit. In addition, it can be described, which services can be delegated to other partners, whether this provides benefits or disadvantages for what partners in the value chain, and what impact this could have on policies of those partners. Modelling such value chains makes it therefore possible to plan these partnerships and to select the most promising one based on an analysis according to the win-win-situation of partners. One important point is, that for public authorities the benefits of participation in such value chains might not be purely economic, targeting financial revenues, but might serve political or legal reasons [8]. This comprises, for example, policies like “highest possible reach”, “fast information transfer”, or “compliance with rules and regulations”; in contrast to commercial policies like “increase of shareholder value” or “market penetration”. A pure concentration on monetary goals is therefore not sufficient for authorities. Unfortunately, the few existing modelling approaches of such value chains focus on commercial market players and their business relationships or internal interactions between departments of companies [9], [10]. In the following chapter we introduce our BMeG modelling method, which supports the design of different variants of value chains for eGovernment services. Section 3 covers an application example to demonstrate how BMeG can be applied, while section 4 discusses BMeG with respect to related work and research in this area. An outlook and summary finalises this paper. 2. Business models for eGovernment - BMeG We use in this paper the term business model according to [7] as model of the roles and relationships of an organisation, its customers and suppliers, as well as the flows of goods, information and money between these parties and the main benefits for those involved. According to this, a business model consists at least of roles, relationships, organisations, flows of goods, and benefits. We developed the BMeG method showing how these concepts have been abstracted, framed by a modelling procedure and supported by a graphical editor. Partners in BMeG value chains have object exchanges, which must not be mutually dependent. Financing options and costs can be modelled with the exchange of monetary objects, and the concept “policy” in particular pinpoints to legal regulations, the mission of an authority as well as the business policy of a company. The as58 signments of advantages and disadvantages per partner allows one to represent arguments for participation by having a bearing on ruling policies. The BMeG editor has been designed as tool support for capturing the know-how and rationale of related business models. It makes it possible to model and maintain different variants of value chains, also for reasons of transparency. BMeG has been validated in a number of large European application projects concerning, e.g., air quality monitoring, city governance, and emergency management. The BMeG model Our modelling method BMeG, Business Models for eGovernment, comprises a conceptual model, a modelling approach, and a specific tool specifically designed for a domain-oriented capture and presentation of the most important aspects for this special breed of offerings. Value Chain 1 consists of 1 consists of Organisation is consists of 2..N 1..N 1 Object Exchange 1 1..N Partner from 1 1..N 1 to 0..1 has 1..N 0..N has 1 Object 0..N plays 0..N relates to has 1..N 0..N Policy 0..N Disadvantage 1 0..N has impact on Advantage Role offers/ performs 0..N 0..N has impact on offers/ performs 0..N 0..N Service 0..N Figure 1: BMeG Model in ER Notation The BMeG model is based on the following propositions: • An eGovernment service can be operated in different variants of value chains with at least two different partners (commercial or public) and object exchanges between these partners (the end customer, the citizen, is also seen as partner). Public private partnership (PPP) partners are complementary according their tasks in such a value chain [11]. This is realised in BMeG through the concepts of roles and services. • Each partner in a value chain has advantages and disadvantages (arguments) in its role. These arguments have respective positive or negative impacts on the policies*) of partners. By assessing the advantages and disadvantages, the service designer can predict whether a value chain can bring a win-win-situation to all participants, i.e., the advantages outbalance the disadvantages. Such value chains might work when implemented, while others might fail in the long term. • Also, different possible financing options of eGovernment services (i.e., funding, sponsoring, advertisements, payment, hosting, shared operation) can be modelled (by means of different object exchanges between partners). • Financial aspects like spreadsheet calculations of the amount of exchange values are not emphasised; monetary values could be charged among partners, but do not necessarily have to be. *) The term policies does not relate to pure governmental context, but describes in general "a high-level overall plan embracing the general goals and acceptable procedures" [12]. 59 Even for commercial partners an exact assessment of the profit of a business could be difficult, since a participation in eGovernment projects could be also valued as strategic method for marketing or support of other business services. Therefore, no quid pro quo is required in BMeG though it can be modelled if required in specific cases. • Particularly, investments for public services might not be reimbursed monetarily, because public authorities often follow legal obligations and eGovernment perspectives by serving citizens. The return value for the authority would be the successful impact of such a service, e.g., more citizens are informed. • This also leads to the BMeG design rule that not each value transfer results in a return value. A return value can also come from a different partner in the value chain, or from no one. Figure 1 depicts this BMeG model in entity relationship notation. In a nutshell, BMeG value chains consist of at least two cooperating partners exchanging at least one object of value. Each partner carries exactly one role while offering one or more services. Services can be assigned to roles or partners depending on level of detail and assignment of organisations to roles. Each partner has policies and arguments for participation, i.e., advantages and disadvantages with impact on own policies or on policies of other organisations. An object exchange is an attributed relation between two partners exchanging arbitrary value objects. These objects can be described in more detail (labels, financial values, etc.). Policies Policies Policies Policies + - 6) NachNachAdvanteile teile tage NachDisNachteile advanteile tage NachDisNachteile advanteile tage NachNachAdvanteile teile tage Modelling Process Objects Authority Role1 Authorities NachDisNachteile advanteile tage NachNachAdvanteile teile tage Role2 NachDisNachteile advanteile tage Objects Objects P1 NachNachAdvanteile teile tage P2 End Customer Role3 Role4 5) Aggregated Roles 4) Partner 3) Roles 2) Services 1) Value Chain? End Customer Figure 2: BMeG Modelling Approach The BMeG modelling approach is defined as follows. Assume an authority plans to implement an eGovernment service. The questions arises, whether to provide the service by themselves or to take other partners on board to share efforts and risks. But which partners could have advantages to join such an endeavour? The steps to model a possible value chain with BMeG are shown in Figure 2. Pre-work should be the definition of policies of the modelling authority (might already be done in previous modelling projects). 60 1) Clear definition of the service, then identification and structuring of single activities that can be executed independently as services; 2) Deduction of roles offering these activities, possible merging of roles (if need be, also later supplement or further merging); 3) Negotiation with potential partners to identify possible object exchanges and financing options, and also to find out their motives and thus policies; Then, definition of organisations as possible partners; 4) Aggregation of roles according the partners selected; 5) Definition of object exchanges between these partners; 6) Definition of the advantages and disadvantages for the modelling authority, definition of partner policies and their arguments for participation. Derivation of possible cross influences (arguments of one partner have influence on policy of another partner). By reiterating these steps different value chain options with same or different partners can be created, with equal or different financing options. Then, analysis can commence, i.e., comparison of advantages and disadvantages per partner and value chain, and an estimation whether win-winsituation can be reached in one of these options. All these steps are not meant to be done strictly sequentially, but refinements due to further classifications are possible. Note that external investors or public funding can also be modelled by financial roles. This is especially expedient to record their funding goals and sponsoring demands. The BMeG editor The BMeG editor supports the modelling of value chains and exchange relationships, and makes effective use of a graphical folder concept to deal with abstraction within highly complex models. Figure 3 presents the BMeG Editor. The left frames show 1) project and variant trees for selection, and 2) objects stored in a database (organisations, roles, policies and services). They can be edited in the tree data structure and dragged to the central graph panel (in the middle). The right frames are designated for overview and orientation purposes. They show an overview image for zooming and orientation, and below a properties table for each selected node or edge in the graph panel. The central graph panel is organised in tabs, representing the variants of value chains. Above each graph panel a toolbar is located allowing typical graph functions like zooming and panning as well as grouping and layout functions of the editor. Project Selection Variants Overview Organisations Properties of Nodes and Edges Roles Policies Services Figure 3: The BMeG Editor The graph panel with nodes and edges serves as main modelling frame and provides graph specific functions like zooming, panning, etc. Entities of the BMeG model like organisations, roles, policies and services are dragged from the left lower frame to the graph panel and dropped. Object exchanges are modelled with directed and attributed edges between roles or organisations. The attributed icon can be arbitrarily labelled. 61 Assignments like “organisation has advantage” or “organisation has policy” are not represented by means of directed edges, but by placement in common folders; this saves edges and thus fosters readability and clarity of (larger) models. Also, it allows one to model the sharing of policies, advantages, and disadvantages between organisations by just placing them in the same folder. Organisations as well as advantages, disadvantages, services, and policies can also be grouped in folders, which can be opened and closed depending on the current detail of interest of the modeller. All objects can be placed freely on the panel. Moving them causes all attached folders and edges to follow their motion. Layout functions allow to re-arrange all icons according to graph layout algorithms (currently hierarchical, organic, or orthogonal layout), which prevents that the modeller gets lost in too large, complex models. Service Folder Role Folder Partner Advantage Disadvantage Object exchanges Policies Folder Folder Disadvantages Advantages Folder Policies Figure 4: Modelling with the BMeG editor As presented in figure 4, a graph panel holds the model of a variant of a value chain. It is visualised by icons (for object nodes), folders, or edges: Object nodes: Partner Advantage Disadvantage Policy Folder nodes: Partner (optional) Role Services Advantages Disadvantages Policies Edges: Object exchange (attributed with labelled icon) Relations „Advantage or disadvantage has impact on policy“ (optional with label) (other relationships by directed edges are also possible) 3. Application example The BMeG method has been initially applied in the context of the EC funded project APNEE (Air Pollution Network for Early Warning and Information Exchange in Europe) [13]. Project APNEE evaluated the potential of raising money with information services revolving around environmental data; or at least to create a win-win-situation between public and private partners when operating the service. The project implemented ubiquitous information services available on mobile phones (WAP, SMS, MMS), PDA, street panels, voice servers, and Internet. These services are operated in public private partnerships while each partnership creates dedicated value for the end user, i.e., the 62 citizen as customer. The following figure shows an example of such a partnership: the APNEE value chain of Germany. Partners have been UMEG (Center for Environment Measurement, Environmental Data Collection and Equipment Security), t-info (former the directory portal of German telecom), t-mobile (German mobile telecommunication provider), and the citizen as end customer. Figure 5: Application of BMeG to project APNEE-TU (example value chain in Germany) The example in figure 5 shows the following BMeG instantiation: • Partner UMEG as environmental authority delivers its measured and quality approved air quality data to partner t-info for further processing and final delivery to the customer – the citizen. As role specific services it has to provide the data and an air quality index (AQI). UMEG’s policy is to spare resources, to be innovative, to implement regulations and to reach most citizens with this information. Its advantages for participation in this value chain are the innovative spread of information by mobile phone, that it spares resources since it does not have to implement the service itself, and that it gets paid by t-info for data delivery. • t-info as directory service picks up the data, bundles it with other data like weather and pollen news, and geo-references it on a map for Internet access. It also provides the polished data to tmobile for selling it as bundled service on their WAP portal. t-info’s advantage is that they get new and qualified data for offering, but they have to pay for the data supply, and only a niche market might want to access the service via t-mobile and pay for it. The BMeG model shows clearly, that the advantages of this value chain lied on the side of the authority, but the disadvantages on side of the commercial partner t-info. And in fact, this partnership broke, when t-info changed its policy of being a search directory syndicating sources from the market to being a search engine working on in-house sources like address data. If the authority had supported the partnership with financial reimbursement or by signing over the commercial use of the data, the niche argument as well as the payment argument might have been equalized. Then, the partnership might have been survived as side service even the business policy had changed. 63 Project APNEE showed also that such partnerships strongly depend on local conditions [13]. This means, that value chains for eGovernment highly vary based on content, country and region, and thus cultural acceptance, market situation and more also differ. That is why the question arose of how to implement these different value chains that are “profitable” for different stakeholders while by the same time serve citizen needs. 4. Discussion When talking about business models and value chains, business process modelling approaches emerge as possible solution for modelling and editing since business process modelling approaches are also covering the modelling of cooperations of enterprises in value chains (see, e.g., [14]). But business process modelling and business modelling serve different objectives [15]. Although we found two explicit business modelling methods, we argue that their concentration on monetary values in the frame of eCommerce is not sufficient for our domain, but tangible and intangible benefits are the main decision points. Only the requirements engineering method i* accompanies us a short way by employing the concept of goals as modelling paradigm [16]. This has been broadened by us to represent policies, and by introducing arguments pro and con that impact these policies respectively. Among the few existing modelling proposals for business models, the e3value method describes a value proposition using a conceptual value model that shows how actors create, distribute, and consume objects of economic value [10]. The ontology can represent a network of actors that jointly offer a complex product or service consisting of separate products and services [19]. e3value introduced the terms actors and value objects, which are also used in BMeG. Also, the initial visualization in BMeG was inspired by the e3value editor, but the version presented here goes significantly beyond it. In BMeG, no counter value is required from a cooperating partner, since we argue that values can also come back from a different partner, or not at all, because the overall functioning of the chain (e.g., the impact on the citizen) might be the whole return for the authority. Economic calculations about expenses and return is thus less emphasized than in e3value, but can be easily included when needed. Thorough financial analysis might be added to BMeG, but it is well known that the assessment of investment and fulfilment of public policies is often hard to assess [20]. e3value does not support concepts like policies, advantages and disadvantages. Differences between value chains can thus not be evaluated apart from financial flows. We argue that this is not sufficient for the decision making of authorities for public private partnerships. The BMO (Business Model Ontology) methodology [21] describes the business model of an enterprise in an UML-like style, presenting a “conceptualization and formalization into elements, relationships, vocabulary and semantics of the essential subjects in the e-business model domain” [9]. As in e3value, the main aim is the modelling of commercial partnerships in an extensive and detailed way. Due to this detailedness it serves more for describing an existing business than planning a new, fictive one. BMO also considers actors like BMeG and e3value, but the main concentration is on the activities. In BMeG, activities are represented by the concept of services, but their definition is not the key of the model. Currently, BMO is missing tool support such as an instantiation editor. This is a main component in BMeG, since authorities should try out several options and compare the visible results for a final decision about which choice to take. It is unclear, how different variants of value chains can be compared in BMO. The i* methodology supports the modelling of complex strategic relationships between actors of organisations. “Actors depend on each other for goals to be achieved, tasks to be performed, and resources to be furnished. Networks of strategic dependencies can be analyzed for opportunities and vulnerabilities. Means-ends reasoning is used to help explore alternatives” [16]. This modelling method is used for goal modelling in the requirements engineering phase of software system development processes. Goals generally describe objectives that a software or system should achieve 64 through cooperation of actors in the intended software and in the environment [22]. Through this closeness to BMeG concepts, it is possible to model value chains with i*, but (i) soft goals do not represent the overall policies of authorities, whereas in our approach soft goals result from policies; (ii) i* goals are “satisfied” by tasks, but value chains may fulfil policies by their general impact; (iii) missing in the i* model is the grouping of actors offering together a service, but with different policies/goals; (iv) i* possesses entities which are not required for business models like agents, positions or links; (v) the existing tools for i* models do not show easily which advantages or disadvantages different models have. Nevertheless, i* is the only methodology which is at a similar level of strategic abstraction from specific processes we require for the BMeG setting. And it can thus be seen as an important precursor of our, more domain-specific approach. 5. Outlook and summary So far, eGovernment services have not been studied in a conceptual manner with policies and strategic advantages and disadvantages. BMeG strives to make such strategic alliances of private and public partners transparent in order to assess their sustainability. Public private partnership have been mostly investigated for construction and development as well as for infrastructure projects, but rarely for IT-based eGovernment services. Moreover, taking into account the revenues possible due to public sector information, such public private partnerships will provide benefits for authorities, businesses, and citizens and thus offer completely new ways of service provisions. BMeG supports authorities and private partners to plan and select alliances by modelling variants of value chains, deriving advantages and disadvantages of partners involved, and thus assessing which partnership could be operated sustainable. Participation arguments and impacts on policies have been accented by BMeG, rather than emphasising monetary equivalences of value exchanges. The BMeG model, methodology, and tool has been validated in a number of large-scale European projects. The approach has been essential to develop and evaluate different dissemination channels and business models for the dissemination of air quality information in five different European countries in APNEE [13], whereas BMeG helped four European regions to compare their very different strategic approaches on how to deal with typical problems currently facing city and rural governance in the Use-Me.GOV project [23]. The availability of a focussed, domain-specific solution, dedicated to eGovernment issues proved to be a key success factor in all of these case studies rather than just considering process modelling issues or purely commercial approaches. BMeG is currently applied to the case of large-scale regional emergency management in an ongoing project. Here, BMeG uncovers more tactical and strategic considerations for the provision of services while considering resource limitations. 65 6. Literature [1] BØHLER, T., KARATZAS, K., PEINEL, G., ROSE, T., and SAN JOSE, R., Providing multi-modal access to environmental data—customizable information services for disseminating urban air quality information in APNEE. Computers, Environment and Urban Systems, 2002. 26(1): p. 39-61. [2] WASSENAAR, A. E-governmental value chain models - E-government from a business (modelling) perspective. in 11th International Workshop on Database and Expert Systems Applications. 2000. [3] HILL, H., Electronic Government - Strategie zur Modernisierung von Staat und Verwaltung, in Aus Politik und Zeitgeschichte (B 39-40/2002), 2002, Bundeszentrale für politische Bildung. [4] EUROPEAN COMMISSION, Commercial exploitation of Europe’s public sector information, PIRA International Ltd., 2000. [5] WEISS, P., Borders in Cyberspace: Conflicting Public Sector Information Policies and their Economic Impacts, 2002, U. S. Department of Commerce, National Oceanic and Atmospheric Administration, National Weather Service. [6] SCHOLL, H.J., Electronic Government: Make or Buy? LECTURE NOTES IN COMPUTER SCIENCE, 2003: p. 220-227. [7] BOUWMAN, H. The Sense and Nonsense of Business Models. in International Workshop on Business Models. 2002. Lausanne. [8] STAHL, B.C., The Ethical Problem of Framing e-Government in Terms of e-Commerce. The Electronic Journal of e-Government, 2005. 3(2): p. pp. 77-86. [9] OSTERWALDER, A. and PIGNEUR, Y. An e-Business Model Ontology for the Creation of New Management Software Tools and IS Requirement Engineering. in CAiSE'2002 Doctoral Consortium. 2002. Toronto. [10] GORDIJN, J., e3value in a Nutshell, in International workshop on e-business modeling2002: HEC Business School, Lausanne. [11] MEDIAKOMM, Betreibermodelle für kommunale Portale im Internet, Analysen - Konzeptionen - Lösungen, 2001. [12] MERRIAM WEBSTER. Online Dictionary. http://www.merriam-webster.com/dictionary/policy. [13] PEINEL, G. and ROSE, T. Dissemination of Air Quality Information: Lessons Learnt in European Field Trials. in EnviroInfo 2004. 2004. Geneva, Switzerland. [14] HOFER, A., ADAM, O., ZANG, S., and SCHEER, A.W., Architektur zur Prozessinnovation in Wertschöpfungsnetzwerken. Veröffentlichungen des Instituts für Wirtschaftsinformatik, ed: Prof. Dr. Dr. h.c. mult. August-Wilhelm Scheer, 2003. [15] GORDIJN, J., AKKERMANS, J.M., and VAN VLIET, J.C. Business modelling is not process modelling. in Conceptual Modeling for E-Business and the Web. 2000. [16] YU, E. Strategic Modelling for Enterprise Integration. in 14th World Congress of International Federation of Automatic Control (IFAC’99). 1999. Beijing, China: Pergamon, Elsevier Science. [17] SCHEER, A.-W. and THOMAS, O., Geschäftsprozessmodellierung mit der ereignisgesteuerten Prozesskette. Das Wirtschaftsstudium 34 (2005), Nr. 8-9, 2005: p. p. 1069-1078. [18] WEIGAND, H., JOHANNSSON, P., ANDERSSON, B., BERGHOLTZ, M., EDIRISURIYA, A., and ILAYPERUMA, T., On the Notion of Value Object, in 18th International Conference on Advances in Information Systems Engineering - CAiSE 2006, E. Dubois and K. Pohl, Editors. 2006, Springer-Verlag Berlin Heidelberg: Luxembourg. p. 321-335. [19] GORDIJN, J. and AKKERMANS, H., Designing and Evaluating E-Business Models. IEEE Intelligent Systems, 2001. 16(4): p. 11-17. [20] WOLF, P. and KRCMAR, H., Wirtschaftlichkeit von elektronischen Bürgerservices - Ergebnisse zweier Fallstudien, in Stiftungsreihe 71, A.S. Stiftung, 2006: Stuttgart. [21] OSTERWALDER, A., The Business Model Ontology - A Proposition in a Design Science Approach, Ecole des Hautes Etudes Commerciales, Université de Lausanne, 2004. [22] YU, E., Agent-Oriented Modelling: Software versus the World. Agent-Oriented Software Engineering II: Second International Workshop, AOSE 2001, Montreal, Canada, May 29, 2001: Revised Papers and Invited Contributions, 2002. [23] PEINEL, G., MOORE OLMSTEAD, P., and ROSE, T. Enabling viable m-Government. in the IST-Africa 2006 Conference. 2006. Pretoria, South Africa. 66 DO WEB SERVICES FOSTER SPECIALIZATION? AN ANALYSIS OF WEB SERVICE DIRECTORIES Christine Legner1 Abstract Web service technologies are expected to foster the creation of networks of specialists which expose their digital services over the internet for the dynamic discovery of services by other organizations. Although the idea of a global Web service directory, which was considered a key enabler of e-commerce in the dot.com era, has failed with the shutdown of the Universal Business Registry in 2006, the vision of an open market for Web services has regained popularity lately in the context of the SOA and Web 2.0 concepts. Given these latest developments, the interesting question is whether there is empirical evidence of an emerging market for Web services. Based on a longitudinal study of Web services directories, this paper aims at analyzing the evolving offering and market structure of B2B Web services. The study suggests that commercial Web services which enable companies to out-task discrete, repetitive tasks to specialized service providers continue to be relatively scarce. However, Web services specialists emerge in specific domains, such as compliance, online validation and alerting. In addition, Web services directories are extending their scope beyond service discovery and evolve into either ‘real’ electronic marketplaces or infomediaries. 1. Introduction The increasing capabilities of information technology are widely acknowledged as causing fundamental changes in organizational and industry structures [2, 3]. Since the emergence of the Web services paradigm, many scholars have argued that the wide acceptance of open Web service standards will dramatically reduce interaction costs within and across organizations and generate greater operational flexibility [4-6]. Web services are expected to promote the unbundling of functions and activities within and across organizations and to foster the creation of networks of specialists [7, 8]. For businesses, this vision implies the dynamic discovery of services in a global electronic marketplace and an increased level of outsourcing of single tasks (also denoted as ‘outtasking’) to specialist service providers [9, 10]. Although most industry experts recognize the potential of Web services [11], the idea of a global Web service directory, which was considered a key enabler of e-commerce in the dot.com era, has failed with the shutdown of the Universal Business Registry in 2006. However, the vision of a global Web services market has regained popularity lately: First, large software vendors are re-architecting their software platforms to reflect the paradigm of a service-oriented architecture (SOA). These efforts are complemented by the establishment of service catalogs, e.g. the IBM SOA Business Catalog or SAP’s Enterprise Services 1 Institute of Research on Information Systems, European Business School, D-65375 Oestrich-Winkel. 67 Repository. Second, Web 2.0 technologies are gaining popularity. Among them are mashups, i.e. composite web applications which are built reusing content from third parties via a public API. Last but not least, a very active research community is exploring the semantic Web. They argue that it will be much easier to locate providers of particular services and establish (semi-)automated cooperation with them if semantics are explicitly added to Web service descriptions [12]. In the context of B2B networks, the interesting question is whether Web service technologies generate more specialization and lead to commercial offerings of reusable Web services. Hence, this paper investigates the market for B2B Web services supporting discrete, repetitive tasks and may be sourced from specialist service providers in order to benefit from economies of scale. A thorough review of the existing Web services directories seems to be valuable in order to extract insights into the global market for specialized Web services. Based on a longitudinal study, this paper aims at answering the following the following questions: • Is there practical evidence that Web service technologies foster specialization, thus resulting in an increased offering of B2B Web services by providers? • What is the role of Web services directories in facilitating the Web services market? This paper is organized as follows: The next section outlines the research approach and process. In order to derive the theoretical propositions that guide our analysis, section 3 reviews Web services literature and relates it to the existing body of research from IS and economic theory. Section 4 summarizes key findings of our study related to the Web services offering and the market structure. The paper concludes with a summary and an outlook on the evolving market for Web services. 2. Research Approach Our research process consisted of two stages: Fist, we reviewed the existing body of research and developed theoretical propositions on the evolving market for Web services and the increasing specialization. For this purpose, we related concepts from the more technically oriented Web services research to prior studies which have investigated the impact of information technology on organizational coordination [2, 3]. In a second step, we collected data related to Web services offerings and the market structure, which we confronted to our theoretical propositions. Since empirical data related to the Web services market and the transaction volumes is not publicly available, our study relies on data that a team of researchers has collected over the last 5 years. Since 2002, this team has been observing all major Web services registries and directories, among them the Universal Business Registry as well as a dozen commercial directories and registries (c.f. Table 1). In view of our research objectives, five Web services directories were selected for a detailed analysis of their Web service offering and the overall structure of the market. The following selection criteria were applied: (1) The Web services directories represent different levels of sophistication, i.e. from simple Web services listings to more advanced trading platforms; (2) due to their Web services offering they are expected to be the major players, and (3) all of them have survived the shakeout phase in 2006. Thus, our analysis focuses on the following directories which account for two thirds of the commercial Web services which are traded using intermediaries: • e-Sigma.com was launched in 2003 with the mission “to provide a secure and standardsbased platform for the global discovery, consumption and management of Web Servicebased business processes”. Today, e-Sigma.com operates a comprehensive Web service directory for publishing, searching and testing Web services. • RemoteMethods started in 1999 as a Web development directory. Today, the company operates a Web service directory which comprises service descriptions and pricing information as well as rating and review mechanisms. 68 • • StrikeIron, located in Raleigh, North Carolina, was founded in 2003 and operates two directories, a global Web service directory as well as a marketplace. The company offers a broad range of services including Web service hosting, monitoring and commercialization. StrikeIron has teamed up with systems integrators and content providers. X-Methods provides a flat listing of services from individuals and organizations. In addition to the browser interface, it offers programmatic interfaces to the registry. Name and Link Universal Business Registry (UBR) Inactive BindingPoint Inactive eSigma.com www.esigma.com RemoteMethods www.remote-methods.com StrikeIron www.strikeiron.com WebServiceList www.webservicelist.com WebserviceX.NET www.webservicex.net Table 1: Overview of Web services directories Operated by Status (October 2007) IBM, Microsoft, NTT Active: 2002 – 2006 Com, SAP Discontinued in January 2006 with more than 50,000 entries (‘the objective of the UDDI project was reached”) Acclaim IT Solutions Active: N/A – 2006 Ltd. Discontinued in 2006 with >4000 services [1] (‘market too slow to adopt Web services‘) eSigma Active: 2003 – today 159 Web services InfoGenius Inc. Active: 1999 – today Started as Web development directory; 337 Web services StrikeIron Active: 2002 – today 618 Web services in Global Directory; 74 Web services in StrikeIron Marketplace IT Netix, Inc. Active: N/A – today 483 Web services Generic Objects Active: N/A – today Technologies Ltd. 71 Web services In order to test our propositions, we counted and analyzed the Web services entries in the selected Web service directories. A first analysis was performed in October 2005 and provided an overview of the Web services offering and the market characteristics. The analysis was repeated and enhanced two years later. Since most directories publish Web services in multiple categories, particular attention has been given to data cleansing in this second analysis. Most importantly, we have eliminated duplicates and created a list with unique service entries for every Web service directory. These entries have been categorized according to the following dimensions: • Functional scope of the Web services: Ten categories have been defined in order to reflect the functional scope, from data-oriented to application-oriented and technical functionality. • Price model: Web services have been classified according to the price model that is applied. • Service provider: Service providers comprise specialized Web service providers, organizations offering complementary Web services to their product/service offering and individuals. • Besides the categorization of the service entries, we investigated the functions provided by the Web service directory using the taxonomy described in the next section. 3. Research Propositions 3.1. Web Services and Specialization From a technical perspective, Web services represent interfaces which provide stable, reusable software functionality [4, 15]. In order to ensure interoperability across platforms, they build on a set of standards [4, 16]: (1) the Extended Markup Language (XML) for defining messages, (2) the Simple Object Access Protocol (SOAP) for transmitting messages, (3) the Web Services Description Language (WSDL) for describing interfaces and (4) the Universal Description, Discovery and 69 Integration (UDDI) protocol for publishing metadata about Web services. Whereas the technical research stream is mostly concerned with enhancing Web services concepts architectures [4, 5, 17], the business literature focuses on the emerging Web service-based business applications and their economic potential. Many business experts argue that Web services – in combination with a service-oriented architecture – will allow companies to replace their proprietary information system landscape with an open, modular architecture [8, 18]. Hence, companies will increasingly leverage shared services, i.e. centrally managed, one-to-many services, and rely on the capabilities of third parties for managing their information system resources [6]. Whereas Web services may be used as mere integration technology, shared services rely on more coarse-grained Web services which are sufficiently generic to allow their reuse in several processes and/or by several users [17, 19]. Proposition 1: With the increasing maturity of Web services technologies, the offering of coarsegrained Web services which provide reusable business-level functionality will increase. Transaction cost theory postulates that the falling interaction costs promote the unbundling of functions and activities within and across organizations [2], and Brynjolfsson et al. [3] demonstrate that advances in IT lead to smaller firm size. In the context of Web services, it has been argued that companies encapsulate their business expertise as Web services and make it available throughout the entire value network, thus stimulating the external integration with their business partners [11]. If Web services are to dramatically reduce interaction costs and to encapsulate electronic support of non-strategic transactions [13], they are likely to increase the level of external sourcing. Sanders et al. [13] and Keen and McDonald [14] denote this particular form of outsourcing as out-tasking given that a specific task is assigned to an outside supplier. By out-tasking to external service providers, companies will benefit from scale efficiencies due to specialization [9]. Proposition 2: Due to the falling transaction costs, specialist service providers will be able to realize scale efficiencies in repetitive tasks and establish a commercial offering of B2B Web services. 3.2. The Role of Web Service Directories From the very beginning, Web services have been associated with the idea of online service discovery [4]. This is manifested by the integral role that directories storing service descriptions play in a Web services architecture [15]. Directories allow service providers to register new services and service consumers to search for and locate services. In a centralized approach, they are hosted and managed by a trusted entity. In the early days of the dot.com era, Web services registries were considered the key technology for facilitating global e-commerce. Hence, the publication of the first version of the UDDI specifications in 2000 inspired the launch of several Web services directories and registries. Since directories establish many-to-many interactions between organizations that publish Web services and organizations which consume Web services, Web services ecosystems show typical characteristics of an electronic market. Similar to a physical marketplace, an electronic market represents a social arrangement which allows buyers and sellers to carry out a voluntary exchange of goods or services. It serves three main functions, namely to match buyers and sellers, to facilitate transactions and to provide the institutional infrastructure for business [20, 21]. Proposition 3: Web service directories assume typical functions of an electronic market which facilitates voluntary exchanges of digital services between Web service publishers and consumers. Given the fact that, of the 1520 electronic marketplaces that were identified in 2000 [22], only a minority survived the subsequent shakeout phase, IS research has intensively investigated the particular role and evolution of electronic markets. Whereas early e-business research mostly emphasized their role in online matchmaking between supply and demand [23], a more differentiated view has developed over the past years (c.f. Table 2). Some authors argue that marketplaces in the B2B 70 space are evolving into so-called exchanges or e-hubs which facilitate supply chain collaboration within a vertical industry [22, 24, 25]. Other scholars observe the emergence of so-called infomediaries or cybermediaries [26-28], like Autobuytel or Expedia, which reduce information asymmetries for consumers. Since the concept of infomediation has also been applied to the B2B space with a very broad view of information-based services [29], the borderline between the different concepts is blurred. Table 2 summarizes the characteristics and roles played by online intermediaries according to prior IS research and will serve as a basis for analyzing the role of Web service directories: Based on the taxonomy developed by Barnes & Hinton [31], informational, transactional, logistical, assurance and customization functions can be distinguished. In addition, we explicitly include matching [23, 24] and additional collaboration, integration and standardization functions. Table 2 visualizes the differences between the original concept of electronic marketplaces, the more collaboration-focused B2B exchanges and the cyber- or infomediaries. Reflecting the evolution of electronic markets, it can be concluded that basic informational services, namely e-catalogs, will most likely not provide a sustainable value proposition [32]. In order to attract the critical mass of Web service consumers and publishers, it might be expected that Web services intermediaries assume additional functions related to matchmaking and facilitation of transactions. Proposition 4: Informational services, notably service discovery, will not provide a sustainable value proposition for Web service directories on the medium and long term. Table 2: Characteristics and roles played by different type of online intermediaries 4. Findings 4.1. Characteristics of Web Services Offering With 500 to 700 service entries which are provided by more than 100 service providers, XMethods and StrikeIron Global Directory offer the largest number of Web services entries Table 3). Interestingly, their attractiveness is decreasing, as they have been shrinking over the last two years. Even though eSigma.com, RemoteMethods and StrikeIron’s Marketplace are significantly smaller in terms of the number of entries, they seem to be gradually expanding their service offering and have experienced at least moderate growth lately. 71 Table 3: Overview of Web services offering e-Sigma Remote StrikeIron StrikeIron Methods Global Direct. Marketplace Number of Web services (own data collection) October 2005 N/A N/A N/A 50 (N/A) (246)* (1779)* (155)* October 2007 192 337 618 74 (259)* (344)* (1037)* (218)* Trend N/A +40% -42% +41% Number of Web services according to [1] January 2006 N/A 322 N/A 207 Web services offering (as of October 2007 / own data collection) Address, Location & 17.76% 34.88% 2.41% 11.47% Identity Verification Business & Finance 45.95% 25.87% 37.51% 56.42% Communications 10.04% 6.10% 14.08% 0.92% Consumer 6.95% 0.00% 0.39% 1.83% Government 2.70% 0.00% 1.83% 0.92% IT Services 0.00% 0.00% 17.16% 0.46% Media 2.32% 2.62% 0.00% 0.00% Miscellaneous 0.00% 9.30% 1.54% 3.21% Utilities 11.20% 7.85% 8.68% 1.83% Value & Manipulation 3.09% 13.37% 16.39% 22.94% Price model (as of October 2007 / own data collection) Chargeable WS (%) 80.7% 41.2% 17.0% 100% Functions provided by Web service directory (as of October 2007 / own data collection) Informational Service deService deService deDetailed serscription incl. scription incl. scription; vice descripquality reportquality reporttion incl. qualiing; ing; reviews, ty reporting; rating; Matching Search; Search; Basic search; Basic search; Price discovery Price discovPrice discovery; ery; Customization N/A N/A N/A N/A Transactions N/A Monitoring N/A Settlement (subscription); Monitoring; Testing Assurance N/A N/A N/A Commercial agreements Logistical N/A N/A N/A N/A Collaboration N/A N/A N/A N/A Integration RSS; UDDI N/A N/A Marketplace API; Excel integration Standardization WSDL; UDDI WSDL WSDL WSDL X-Methods 555 509 -8% 490 26.7% Short service description; N/A N/A Testing N/A N/A N/A RSS; SOAP interface; WSInspection; DISCO; UDDI WSDL; SOAP; UDDI * Depending on the realization of the directory, Web services and providers are only displayed according to predefined categories. The resulting numbers may include duplicates due to multiple categorizations. Although Web services intermediaries claim to provide business-level services, the detailed analysis reveals that many services are extremely fine granular and data-centric. Many Web services offerings still comprise simple transformation and conversion services, e.g. SMS services, the transformation of simple text files in XML format or currency converters. However, Web service providers address specific business requirements and realize small chunks of business logic for 72 specific scenarios. Among them are validation and verification services which enhance postal address, e-mail or phone information and may be useful in marketing campaigns, credit checking or death index services which can be easily integrated in ordering applications and facilitate real-time fraud detection. The growing number of services in the category ‘Address, Location & Identity Verification’ as well as ‘Business & Finance’ underpins this trend. Another emerging focus area of service offerings is regulatory compliance, with the Patriot Act compliance service, safety and product recall services as examples. In addition, services are increasingly customized as notification services that send out alerts as a reaction to specified events. Interestingly, the Web services directories which experienced growth over the last two years have a slightly higher portion of business-level services, i.e. services in the categories ‘Address, Location & Identity Verification’ and ‘Business Services’, while the other Web services directories comprise more technical or utility services. Thus, proposition 1 can only partly be confirmed. By analyzing price models and service providers, our study identifies three different business models with regard to proposition 2: • Type 1 – Web services as core competency: This business model comprises chargeable Web services provided by professional service providers. Table 3 depicts some prominent examples of these emerging service specialists which offer services in the field of address, location and identity verification as well as business services. Pricing models are either transaction-based or subscription-based (monthly or yearly). Prices range from <0.01$ per invocation (one-time purchase), to monthly and yearly fees of more than USD 10,000 (subscriptions with either limited or unlimited number of invocations). Type 1 Web services account for 35% of the total number of Web services in this study. • Type 2 – Complementary Web services: In this case, companies offer complementary Web services to their business partners. Prominent examples include logistics service providers, e.g. UPS or Fedex, which offer Web services for direct access to their online tracking systems, or e-shops, e.g. Amazon.com, which expose e-commerce functions as Web service. The services are offered free of charge and represent the smallest group in this analysis. • Type 3 – “Gadget” Web services: This type of Web service is offered free of charge mostly by individuals, often students or software developers. Type 3 Web services account for around 50% of the Web services listed in the five directories. Our analysis confirms proposition 2 given that a number of service providers specialize in the provisioning of digital services and have been able to establish a Type 1 business model. With exception of the StrikeIron Marketplace and e-Sigma, which exclusively focus on Type 1 Web services, Web service directories address all three types of business models. 4.2. Web Services Directories As of today, most Web services directories limit their scope to decreasing the search costs of buyers looking for a particular Web services offering which suits their requirements. As depicted in Table 3, they provide a service catalog with some enhanced trial functionality. However, the level of detail and the reliability of the service description varies widely. Whereas XMethods and RemoteMethods provide short descriptions and link to the service provider for detailed information, the StrikeIron Marketplace and e-Sigma.com deliver a comprehensive documentation including detailed feature lists and example data documentation. With the exception of XMethods, each directory provides one or more means to search for Web services. Despite the fact that private UDDI registries allow for advanced categorization and identification schemes, the investigated Web services intermediaries use rather simplistic search and categorization mechanisms. Searching functionality is reduced to keyword search and simple category browsing with very basic predefined 73 categories. Unlike in other electronic markets, we were not able to observe increasing personalization and customization of the Web services offerings. Most interestingly and in contrast to the paradigm of an electronic market, not all intermediaries support matching and notably price discovery. Of the ‘pure’ directories, only RemoteMethods and e-Sigma.com announce the price of a Web service. The StrikeIron Marketplace offers a harmonized subscription model for Web services from different providers, in which subscribers pay either a monthly or annual fee to gain access to and invoke Web services. This fee is based upon the number of actual invocations (from a few hundreds to several millions) the client uses. With regard to the settlement, a decentralized approach prevails and transactions are directly settled between providers and consumers. The StrikeIron Marketplace is the only directory which facilitates B2B transactions between Web service providers and consumers. It establishes the contractual agreement between buying and selling parties as well as the processing of credit card payments and the related payment monitoring and accounting with service providers. All service invocations and replies are resolved through the platform. It provides authentication and authorization against a consumer’s subscription and then forwards the request to the service provider. In addition, it offers availability monitoring and usage metering. StrikeIron additionally supports systems integration at the Web service consumer’s end by offering pre-defined authentication mechanisms and out-of-the box integration. Using the StrikeIron Marketplace API, software vendors are able to embed service invocations in their applications. As an example, the Salesforce.com administrator can call StrikeIron’s US Address Verification Service to correct and enhance customer address information. Besides browser access, some directories support the discovery of services by programmatic interfaces: XMethods provides the most advanced options with SOAP interfaces, RSS feeds, WS-Inspection, DISCO documents and a UDDI Private Registry interface. Given the brief service descriptions and the limited support for price discovery and settlement, it is questionable whether all Web service directories satisfy the requirements of B2B users and are able to facilitate the voluntary exchanges of digital services between Web service publishers and consumers. This particularly applies to XMethods where service descriptions are outdated and incomplete and many links are broken. Whereas proposition 3 only holds for the more advanced Web services directories (e-Sigma.com, StrikeIron Marketplace, RemoteMethods), our analysis confirms proposition 4: Directories with a broader portfolio of services experience growth whereas directories which only provide a service catalog are stagnating. 5. Conclusions and Outlook In this study, we investigated whether there is practical evidence that Web service technologies foster specialization, thus resulting in an increased offering of B2B Web services by specialist service providers. Despite the great enthusiasm about Web services and its revitalization in the context of Web 2.0, we found that the commercialization of B2B Web services faces a rather slow evolution. With a total amount of several 100s Web services, there is only weak empirical evidence that Web services technologies have generated significant market opportunities for Web service providers so far. Recently, we have been able to observe an increasing ‘professionalization’ with a number of commercial Web services specialists, such as Dun & Bradstreet, ServiceObjects or Xignite, that have entered the market and continue to expand. In view of this development, it might be argued that the Web services market has still not reached maturity and that a number of factors might foster market take-off in the near future. On the one hand, businesses have started implementing service-oriented architectures and are better prepared to adopt Web services today than they were in 2002. On the other hand, our study suggests that Web service providers in the area of compliance, online validation and alerting are setting up Type 1 business models. Due to the increasing availability of digital content and real-time information, more services of this type are to be expected. 74 From the growth rates of the different Web services directories we conclude that service discovery, i.e. the provisioning of a service catalog, does not provide a sustainable value proposition for Web service intermediaries. From our study, we conclude that the role of intermediaries is evolving and that the existing players have taken different evolution paths: Whereas at the one extreme XMethods provides a flat listing of Web services targeted at the large technical community and in particular the many individual software developers, e-Sigma.com, StrikeIron and RemoteMethods are focussing on business users and the commercial Web services market. RemoteMethods positions itself as ‘the source for finding reliable Web Service Providers (WSP)’, i.e. a neutral platform providing review and rating mechanisms as well as price and service transparency, and thereby evolves into a typical infomediary. e-Sigma provides a comprehensive self-service discovery and publication platform with a focus on facilitating standard-based process collaboration. It might evolve into an exchange at a later stage. StrikeIron has established a transaction-based remuneration model as so-called Web Services Marketplace and assumes the role of an electronic market. For Web service consumers, StrikeIron acts as a single point of contact, which facilitates transactions with multiple service providers and provides a reliable institutional infrastructure for conducting business. In order to develop its Web services offering and to increase its attractiveness as a sales channel, StrikeIron supports service providers with co-marketing efforts, flexible pricing mechanisms, billing and account management. Intermediaries will have a role to play in facilitating interactions with a wider spectrum of trusted service providers, as long as the market is fragmented. However, disintermediation is also a possible scenario, if the specialist Web services providers evolve into a handful of well-known ‘brands’ and establish their own online sales channels. The results from the present research cannot be interpreted without taking the study’s limitations into account. Most importantly, our empirical base has been restricted to open Web services directories and Web services that are publicly accessible. Whereas our study focuses on the Web services directories which have been established around 2002, it does not consider the emerging service catalogs which have been built by software vendors and a number of newer service registries, such ProgrammableWeb.com and Mashable.com, that introduce newer Web 2.0 styles services. It should be also noted that the focus of our study is strictly on Web services (as defined by the use of the core Web service standards). Consequently, we have not addressed the more general theme of digital services (which some authors also denote as Web services). With regard to related work, only two other empirical studies related to the Web services market exist to our knowledge: van den Heuvel and Smits [1] analyze the structure of the Web service market in comparison to software components. Bachlecher, Siorpaes, Fensel and Toma [33] review the existing approaches toward Web service discovery based on an analysis of Web services directories and Web services search engines. While focusing on the role of Web service directories, both studies do not provide any details on the commercialization of Web services and the structure of the Web service offering. In a recent publication, Nüttgens and Dirik [34] identify business models for Web services based on a multiple-case study research design. Their findings confirm the results from our study, notably the three business models outlined in section 4. 6. References [1] J.-W. van den Heuvel and M. Smits, "Transformation of the Software Component and Web Services Market", presented at eMergence, Proceedings of the 20th Bled eConference, 2007. [2] T. W. Malone, J. Yates, and R. I. Benjamin, "Electronic Markets and Electronic Hierarchies", Communications of the ACM, 30 (6), pp. 484-497, 1987. [3] E. Brynjolfsson, T. W. Malone, V. Gurbaxani, and A. Kambil, "Does Information Technology Lead to Smaller Firms?" Management Science, 40 (12), pp. 1628-1644, 1994. 75 [4] G. Alonso, F. Casati, H. Kuno, and V. Machiraju, Web Services: Concepts, Architectures and Applications. Springer, Berlin, 2003. [5] M. P. Papazoglou and D. Georgakopoulos, "Service-Oriented Computing", Communications Of The ACM, 46 (10), pp. 25-28, 2003. [6] J. Hagel III and J. S. Brown, "Your Next IT Strategy", Harvard Business Review, 79 (October), pp. 105-113, 2001. [7] J. Hagel III and M. Singer, "Unbundling the corporation", Harvard Business Review (March/April), pp. 133-141, 1999. [8] A. Ismail, S. Patil, and S. Saigal, "When computers learn to talk: A Web services primer", The McKinsey Quarterly, Special Edition: Risk and Resilience (2), pp. 70-77, 2002. [9] J. vom Brocke and M. A. Lindner, "Service Portfolio Measurement — A Framework for Evaluating the Financial Consequences of Out-tasking Decisions", presented at Proceedings of the 2nd international Conference on Service Oriented Computing, 2004. [10] H. Österle and C. Reichmayr, "Out-tasking mit WebServices", in Service Engineering - Entwicklung und Gestaltung innovativer Dienstleistungen, H.-J. Bullinger and A.-W. Scheer, Eds. Springer, Berlin, 2003, pp. 565-589. [11] E. M. Daniel and A. White, "The future of inter-organisational system linkages: findings of an international Delphi study", European Journal of Information Systems, 14 (2), pp. 188-203, 2005. [12] J. de Bruijn, D. Fensel, U. Keller, and R. Lara, "Using the Web Service Modeling Ontology to Enable Semantic E-Business", Communications of the ACM, 48 (12), pp. 43-47, 2005. [13] N. R. Sanders, A. Locke, C. B. Moore, and C. W. Autry, "A Multidimensional Framework for Understanding Outsourcing Arrangements", Journal of Supply Chain Management, 43 (4), pp. 3-15, 2007. [14] P. G. W. Keen and M. Mc Donald, The e-Process Edge: Creating Customer Value and Business Wealth in the Internet Era. McGraw-Hill, Berkeley, 2000. [15] W3C, "Web Services Architecture", W3C, last accessed 26.06.2004, http:// www.w3.org/TR72004/NOTE-wsarch-20040211/, 2004. [16] K. Umapathy and S. Purao, "A theoretical investigation of the emerging standards for web services", Information Systems Frontier, 9 (1), pp. 119-134, 2007. [17] T. Erl, Service-Oriented Architecture. Prentice Hall, New York, 2005. [18] C. Legner and R. Heutschi, "SOA Adoption in Practice - Findings from Early SOA Implementations", presented at Proceedings of the 15th European Conference on Information Systems, St. Gallen, Switzerland, 2007. [19] E. Newcomer and G. Lomow, Understanding SOA with Web Services. Addison-Wesley, Maryland, 2004. [20] J. Y. Bakos, "The Emerging Role of Electronic Marketplaces on the Internet", Communications of the ACM, 41 (8), pp. 35-42, 1998. [21] G. M. Giaglis, S. Klein, and R. M. O'Keefe, "The role of intermediaries in electronic marketplaces: developing a contingency model", Information Systems Journal, 12 (3), pp. 231-246, 2002. [22] G. S. Day, A. J. Fein, and G. Ruppensberger, "Shakeouts in Digital Markets: Lessons from B2B Exchanges", California Management Review, 45 (2), pp. 131-150, 2003. [23] J. Y. Bakos, "A Strategic Analysis of Electronic Marketplaces", MIS Quarterly, 15 (3), pp. 295-310, 1991. [24] S. Kaplan and M. Sawhney, "E-Hubs: The New B2B Marketplaces", Harvard Business Review, 78 (3), pp. 97103, 2000. [25] E. Christiaanse, "Performance Benefits Through Integration Hubs", Communication of the ACM, 48 (4), pp. 95100, 2005. [26] J.-Y. Son, S. S. Kim, and F. J. Riggins, "Consumer Adoption of Net-Enabled Infomediaries: Theoretical Explanations and Empricial Test", Journal of the Association for Information Systems, 7 (7), pp. 473-508, 2006. [27] H. K. Bhargava and V. Choudhary, "Economics of an Information Intermediary with Aggregation Benefits", Information Systems Research, 15 (1), pp. 22-36, 2004. [28] M. Sarkar, B. Butler, and C. Steinfield, "Cybermediaries in Electronic Marketspace: Toward Theory Building", Journal of Business Research, 41 (3), pp. 215-221, 1998. [29] A. Ordanini and A. Pol, "Infomediation and Competitive Advantage in B2b Digital Marketplaces", European Management Journal, 19 (3), pp. 276-285, 2001. [30] E. Christiaanse and J. Rodon, "A Multilevel Analysis of eHub Adoption and Consequences", Electronic Markets, 15 (4), pp. 355-364, 2005. [31] D. Barnes and M. Hinton, "Developing a framework to analyse the roles and relationships of online intermediaries", International Journal of Information Management, 27 (3), pp. 63-74, 2007. [32] E. M. Daniel, A. White, and J. Ward, "Exploring the role of third parties in inter-organisational web service adoption", Journal of Enterprise Information Management, 17 (5), pp. 351-360, 2004. [33] D. Bachlechner, K. Siorpaes, D. Fensel, and J. Toma, "Web Service Discovery - A Reality Check", Digital Enterprise Research Institute (DERI), Galway, Innsbruck, Seoul, Stanford 2006. [34] M. Nüttgens and I. Dirik, "Geschäftsmodelle für dienstebasierte Informationssysteme – Ein strategischer Ansatz zur Vermarktung von Webservices", Wirtschaftsinformatik, 50 (1), pp. 31-38, 2008. 76 GESCHÄFTSMODELLE FÜR ORGANISATIONSÜBERGREIFENDE BUSINESS SERVICES IM E-GOVERNMENT Isabel Mischler, Till Janner, Christoph Schroth, Beat Schmid1 Kurzfassung Die durchgängige Abwicklung elektronischer Geschäftsprozesse über Unternehmensgrenzen hinweg hat zuletzt insbesondere im privatwirtschaftlichen Sektor erhebliche Fortschritte gemacht. Die Umsetzung von E-Government Bereich konnte mit diesem schnellen Wandel bislang nicht mithalten. Für einen erfolgreichen Einsatz moderner E-Government Architekturen reicht jedoch deren blosse technische Implementierung, insbesondere in föderalistisch organisierten Staaten, nicht aus. Die Entwicklung und Bewertung von Geschäftsmodellen für diese neuartigen Plattformen ist ebenso wichtig, um Akzeptanz und weite Verbreitung sicherzustellen. In dem vorliegenden Beitrag wird daher ein Geschäftsmodellframework für organisationsübergreifende EGovernment Business Services entwickelt. Dieses wird anhand der HERA Referenzarchitektur im Kontext der Schweiz in verschiedenen Optionen instanziiert und bewertet. 1. Relevanz organisationsübergreifender Business Services in der öffentlichen Verwaltung Organisationen operieren heute vielfältig über ihre eigenen Grenzen hinweg: Serviceorientierte Architekturen erleichtern die Integration von Informationssystemen (vgl. [15]), im Web2.0 generieren Kunden für Unternehmen Ideen (vgl. [32]) und Unternehmen entwickeln Produkte zusammen mit Partnern in komplexen Innovationsnetzwerken [31]. Um dieser neuen Realität gerecht zu werden, müssen auch E-Government Lösungen organisationsübergreifend konzipiert und umgesetzt werden. In der Schweiz, wie auch in den meisten anderen europäischen Ländern, haben praktisch alle Verwaltungen durch den Einsatz von Informations- und Kommunikationstechnologie (IKT) versucht, ihre Effizienz zu steigern [8]. In dem gleichen Ausmass, wie der private Sektor durch den Einfluss neuer Technologien umgestaltet wird, unterliegen auch die öffentlichen Verwaltungen diesem Wandel und stehen vielfältigen Herausforderungen gegenüber. So stellen Becker et. al. in [1] einen Trend zu wachsender Individualisierung fest, der wiederum zu höheren Ansprüchen der verschiedenen Anspruchsgruppen an die Dienstleistungen der Verwaltungen führt. Diese erhöhten Ansprüche an eine moderne, dienstleistungsorientierte und effiziente Verwaltung, die ihre Dienste auch mit Hilfe von IKT erbringt, resultieren auch aus dem immensen technologischen Fortschritt im privatwirtschaftlichen Sektor in den vergangenen Jahren [12]. Bislang jedoch konnte der Bereich 1 University of St. Gallen, Institute for Media and Communication Management, CH-9000 St. Gallen 77 der öffentlichen Verwaltung nicht in gleichem Maße mit der technologischen Entwicklung im privatwirtschaftlichen Bereich schritthalten. Als weitere Motivation für die Modernisierung der Verwaltungen geben Becker et. al. an, dass durch den zunehmenden Standortwettbewerb (national und international) “ein effizientes und effektives staatliches Handeln sowie die Unterstützung unternehmerischer Aktivitäten in einer Region oder in einem Land durch den Staat mehr und mehr zu einem entscheidenden Standortfaktor”[1] werden. Die Gestaltung eines attraktiven Standortes mit interoperablen Systemen bedingt, dass gemeinsame Standards verwendet werden [21]. Nur wenn eine E-Government Plattform an bestehende Initiativen anknüpft, wird sichergestellt, dass vergangene und zukünftige Investitionen nicht umsonst getätigt wurden bzw. werden. Dies gilt insbesondere für die Schweiz mit ihrem hohen Grad an Dezentralisierung und der grossen Heterogenität der bereits vorhandenen Systeme. Hier setzt das HERA (Helvetic E-Government Reference Architecture, [14]) Projekt an. Ziel dieses Projektes ist es, eine generische E-Government Referenzarchitektur zu entwickeln. Diese soll helfen auf eine einfache Weise neue organisationsübergreifende E-Government Applikationen einzuführen. Die Architektur baut auf bestehenden Standards der Schweizerischen Standardisierungsgesellschaft eCH auf und basiert auf dem Konzept des zukünftigen Event-Bus Schweiz. Durch HERA soll es gelingen, sowohl die Effektivität, wie auch die Effizienz in der öffentlichen Verwaltung zu steigern. Dieser Artikel gibt einen Überblick über die relevanten Initiativen im E-Government in der Schweiz und zeigt, wie sich HERA in dieses System einpasst und auf welchen Prinzipien die Plattform basiert. Im Zentrum der Arbeit werden mögliche Geschäftsmodelle für organisationsübergreifendes E-Government aufgezeigt und am Beispiel der HERA Architektur angewendet. Dabei ergeben sich die drei Optionen "Lizenzgeschäft mit Support", "Lizenzgeschäft ohne Support" und "Software as a Service". Eine Bewertung der Geschäftsmodelle aus Sicht der beteiligten Akteure wird in der anschliessenden Diskussion anhand des Ansatzes des Total Cost of Ownership vorgenommen. Dieser Ansatz soll die Akzeptanz und die Verbreitung unternehmensübergreifender E-Government Dienstleistungen erhöhen und den beteiligten Akteuren als Entscheidungsgrundlage dienen. 2. Rahmenbedingungen – Standardisierung, Architekturinitiativen und das HERA Projekt In diesem Teil sollen zum einen die relevanten Rahmenbedingungen des E-Governments in der Schweiz aufgezeigt und zum anderen ein kurzer Überblick über das HERA Projekt gegeben werden. Die Schweizer E-Government Landschaft ist durch einige besondere Rahmenbedingungen gekennzeichnet. Dies sind zum einen die politischen/organisatorischen Rahmenbedingungen. Hier sind insbesondere der Verein eCH und die föderale Aufbauweise des Schweizerischen Staates zu nennen. Der Verein eCH [9] hat sich zum Ziel gesetzt Standardisierungen im E-Government in der Schweiz voranzutreiben [10]. Weiter sind technische Rahmenbedingungen zu beachten. In Industrie und öffentlicher Verwaltung aktuell vorherrschende technologische Grundlagen und Konzepte sind zum Beispiel serviceorientierte Architekturen (SOA) (vgl. z.B [19], [24]) und eventgetriebene Architekturen (EDA) (vgl. [7]). In Bezug auf E-Government gibt es zudem auch wichtige Initiativen, die es zu beachten gilt. Dies ist zum einen der Event-Bus Schweiz als generelles Architekturprinzip [23] und zum anderen die SEDEX-Plattform, ein Teilbus des EventBus Schweiz. Die SEDEX-Plattform vereinfacht die Kommunikation zwischen den amtlichen Personen-registern [3] und stellt erstmals eine Plattform für den organisationsübergreifenden Austausch von elektronischen Dokumenten in der Schweiz zur Verfügung. Der Event-Bus Schweiz ist als konzeptuelles übergeordnetes Rahmenwerk für die zukünftige E-Government Infrastruktur in 78 der Schweiz zu verstehen, das verschiedene entstehende Datenaustauschplattformen (Teilbusse) integriert und zu einem interoperablen Gesamtsystem vereint [23]. Den genannten relevanten Rahmenbedingungen wurde bei der Konzeption der HERA-Plattform Rechnung getragen, so dass eine nahtlose Integration in die bestehende E-Government Landschaft sichergestellt wird. Abbildung 1 zeigt die Einbettung der HERA-Plattform in die Schweizer EGovernment Landschaft. Es wird deutlich, dass der HERA-Bus als Teilbus des Event-Bus Schweiz zu verstehen ist und somit die Möglichkeit besteht, mit den angeschlossenen Teilbussen, also z.B. mit SEDEX, zu kommunizieren. Abbildung 1: Einordnung der Referenzarchitektur in den Kontext des Event-Bus Schweiz (i.A.a [29]) Das HERA Projekt hat neben Integration und Anbindung an bestehende Systeme vor allem zwei Ziele. Zum einen wird ein generisches Framework für prozessorientiertes E-Government entwickelt. Dadurch wird es zukünftigen Entwicklern möglich sein, in Anlehnung an die Referenzarchitektur kostengünstig neue Applikationen zu entwickeln. Zudem verwendet das Framework einen modellbasierten Ansatz, der erlaubt, dass die meisten Bestandteile einer neuen Applikation modellbasiert eingeführt werden können (d.h. ohne, oder nur mit geringfügigem Programmieraufwand). Zum anderen soll im Projekt eine prototypische Implementation eines E-Government Szenarios, der elektronischen Gewinnsteuer für juristische Personen in der Schweiz, vorgenommen werden, um die Praxistauglichkeit des HERA Ansatzes nachzuweisen. Die webbasierte HERA-Plattform ermöglich den Prozessbeteiligten den elektronischen Austausch von Dokumenten und führt auf Basis von flexibel kombinierbaren Interaktionspattern durch den nur schwach strukturierten Prozess, so dass eine möglichst grosse Flexibilität und Agilität gewährleistet wird. Die HERAPlattform richtet ihr Hauptaugenmerk auf die organisationsübergreifenden Prozesse, allerdings ist zukünftig auch eine Unterstützung der internen Prozesse einer Organisation denkbar. Neben dem sicheren Austausch von Dokumenten und der Integration in die künftige E-Government Landschaft der Schweiz bietet HERA, wenn erforderlich, auch fachliche Mehrwertdienste, wie z.B. Vollständigkeitsprüfung und Fristenverwaltung an. Für detailliertere und zum Teil mehr auf technische Aspekte eingehende Darstellungen der HERA Architektur wird u.a. auf [6], [28] und [29] verwiesen. 3. Ein Geschäftsmodellframework für organisationsübergreifendes EGovernment Im Folgenden soll ein Geschäftsmodell für organisationsübergreifendes E-Government beschrieben werden. Dafür sollen in einem ersten Schritt die in dieser Arbeit synonym verwendeten Begriffe 79 "Geschäftsmodell“ und „Business Model" für den weiteren Gebrauch definiert werden. Darauf aufbauend wird das Geschäftsmodellframework von Stanoevska/ Högg beschriebenen und auf die spezifische Situation im E-Government angepasst. Mahadevan definiert Business Model Begriff wie folgt: "A business model is a unique blend of three streams that are critical to the business. These include the value stream for the business partners and the buyers, the revenue stream and the logistical stream. The value stream identifies the value proposition for the buyers, sellers and the market makers and portals in an Internet context. The revenue stream is a plan for assuring revenue generation for the business. The logistical stream addresses various issues related to the design of the supply chain for the business [20]." Mahadevan legt den Schwerpunkt also auf die Verbindungen zwischen den für ein bestimmtes Geschäft wichtigen Akteuren. Knyphausen-Aufsess und Meinhardt hingegen betonen die Komponenten, die hinter einem Geschäftsmodell stehen: "Geschäftsmodelle bestehen aus drei Elementen: (1) Produkt-/Markt-Kombination, (2) Durchführung und Konfiguration von Wertschöpfungsaktivitäten und (3) Ertragsmechanik."[33] Die wesentlichen Charakteristika der vorgenannten Definitionen finden in der wohl meistgenannten Definition für Business Model von Timmers ihre Synthese: "…an architecture for the products, services and information flows, including a description of various business actors and their roles, a description of the potential benefits for the various business actors, and a description of the sources of revenues. [30]" Diese Definition bildet auch die Grundlage des im Folgenden dargestellten MCM Geschäftsmodellframeworks [16]. Das MCM Geschäftsmodellframework zeigt die generischen Komponenten der in der Literatur enthaltenen Business Models. Das Framework wurde nach einer Tiefenanalyse der bestehenden Literatur erarbeitet [16]. Eine Übersicht über die von Stanoevska/Högg verwendeten Elemente gibt Abbildung 2. Abbildung 2: MCM Geschäftsmodellframework (i.A.a. [16]) Das Geschäftsmodellframework von Stanoevska/Högg ist in erster Linie auf Unternehmen in der Privatwirtschaft ausgerichtet, durch die generische Natur seiner Komponenten jedoch auch in anderen Kontexten einsetzbar. Im Folgenden wird das Framework kurz allgemein vorgestellt (i.A.a [16]) und dabei gleichzeitig auf die spezifische Situation im e-Government Markt eingegangen. Societal environment: Diese Komponente beschreibt alle Einflüsse, die von aussen auf das Business Model einwirken. Dies können rechtliche, ethische oder auch wettbewerbliche Einflussgrössen sein [16]. Im Kontext des E-Governments in der Schweiz sind in diesem Zusammenhang vor allem die rechtlichen Aspekte zu beachten. Wie Müller schreibt, benutzt jede Behörde andere Reglemente, Gesetze und Formulare [21]. Aber auch soziale Aspekte spielen eine grosse Rolle. Johanssen und Herz schreiben, dass E-Government Lösungen in der Zukunft neben der Technik vor allem am Nutzer ausgerichtet werden sollen[18]. Features of the specific medium: Diese Komponente zeigt die verschiedenen Möglichkeiten der Transaktion und Interaktion über ein bestimmtes Medium auf [16]. Abbildung 3 gibt einen 80 Überblick über die Interaktionspartner und deren Beziehungen im organisationsübergreifenden EGovernment. Unterschieden wird einerseits zwischen internem E-Government, das die elektronischen Beziehungen der Verwaltungen untereinender umfasst (Government-toGovernment, G2G), und externem E-Government. Das externe E-Government wird wiederum in zwei Bereiche aufgeteilt und umfasst die Beziehungen der Verwaltungen zu den natürlichen Personen (dem Bürger) (Government-to-Citizen, G2C), sowie die Beziehungen der Verwaltungen zu den juristischen Personen (den Unternehmen) (Government-to-Business, G2B). Abbildung 3: Interaktionsbeziehungen im E-Government (erweiterte Darstellung i.A.a. [2]) Potential customers: Dieser Teil umfasst alle Aspekte der Zielgruppe und der Kunden sowie die erwartete Wertschöpfung [16]. Gemäss den in Abbildung 3 aufgezeigten Interaktionsbeziehungen sind mögliche Nutzer und Kunden von E-Government Business Services öffentliche Verwaltungen, natürliche und juristische Personen. Value chain: Diese Komponente umfasst die direkt involvierten Parteien in der Produktion und dem Vertrieb der angebotenen Produkte und Dienstleistungen. Auch die gegenseitige Beziehung unter den involvierten Parteien gehört zu dieser Komponente [16]. E-Government Lösungen werden entweder von externen IKT-Dienstleistern oder von der öffentlichen Verwaltung selber in deren Informatikbereichen entwickelt und betrieben. Castellano et al. schreiben, dass durch einen serviceorientierten Ansatz die ganze Wertkette in kleinere, modulare Einheiten zerlegt werden könne, wodurch die Flexibilität im gesamten Prozess gesteigert wird [4]. Features of the specific product: Dieser Teil beinhaltet das Design des Produkts und die Art, wie der Kunde das Produkt oder die Dienstleistung erlebt. Ebenfalls Teil dieser Komponente ist die Beschreibung des Nutzens und wie der Kunde eventuell dazu beitragen kann [16]. Schedler formuliert vier Kriterien, damit ein umfassendes E-Government gewährleistet werden kann. Neben dem ansprechenden, auf klare Benutzerführung ausgerichteten Design und der Integration der externen mit den internen Prozessen mit dem Intranet als Voraussetzung, gehören dazu auch zwei Kriterien, die in die Komponente "Features of the specific product" gehören. Zum einen ist dies ein breites Spektrum an angebotenen Leistungen und zum anderen dass der Kundennutzen im Vordergrund des ganzen Denkens stehen soll [27]. Financial flow: In diesem Teil wird das Ertragsmodell des Business Models beschrieben, d.h., es wird gezeigt, welche Elemente der Wertkette zum finanziellen Erfolg beitragen [16]. Die finanziellen Mittel können im organisationsübergreifenden E-Government Kontext zwischen privaten IKT-Dienstleistern und öffentlichen Verwaltungen fliessen. Weiter sind Kapitalflüsse zwischen den öffentlichen Verwaltungen und den Anwendern von E-Government Lösungen denkbar. Verschiedene Erlösmodelle für den Betrieb von service-orientiert realisierten EGovernment Lösungen werden in Kapitel 4 am Beispiel der HERA Architektur diskutiert. 81 Flow of goods and services: Diese Komponente identifiziert im Unternehmen und in der Wertkette alle Prozesse, die nötig sind, um das Produkt oder die Dienstleistung zu erstellen [16]. Schedler schreibt, dass E-Government neue Möglichkeiten schaffe, "um die Entscheidungsfindung, Leistungserstellung und die Abgabe der Leistungen an die Kundinnen und Kunden zu vereinfachen, zu optimieren" [27]. 4. Fallstudie: Geschäftsmodelloptionen für die HERA-Architektur Aufbauend auf dem Geschäftsmodellframework von Stanoevska/Högg und dessen Instanziierung für organisationsübergreifendes E-Government sind drei allgemeine Optionen für ein Business Model für Anwendungen, die auf der zuvor vorgestellten HERA Architektur aufbauen, denkbar. Im Folgenden werden die Modelle „Lizenzgeschäft mit Support“, „Lizenzgeschäft ohne Support“ und „Software as a Service“ kurz anhand der Dimensionen des E-Government Geschäftsmodellframework beschrieben. Der Schwerpunkt liegt dabei auf der Option Software as a Service. 4.1. Option 1: Software as a Service Die Geschäftsmodelloption Software as a Service (SaaS) beschreibt den Fall der Bereitstellung der kompletten Anwendungsfunktionalität, die auf Basis der HERA Infrastruktur realisiert wird, als Dienstleistung, die über das Internet bezogen werden kann [13]. Im Gegensatz zur klassischen Software wird bei SaaS die gesamte Infrastruktur von einem Provider zur Verfügung gestellt und betrieben [5]. Die Komponenten des Geschäftsmodellframework gestalten sich für diese Option wie folgt: Societal Environment: Das Umfeld für ein E-Government Geschäftsmodell ist in der Schweiz durch einige Besonderheiten geprägt. Es sind dies der föderalistische Staatsaufbau mit zum Teil sehr kleinen autonomen Verwaltungseinheiten [17], der daraus resultierende erhöhte Koordinations- und Steuerbedarf [17], das häufige Fehlen von gesetzlichen Grundlagen [22] und die vermehrte Bereitschaft von kleineren staatlichen Einheiten zur Kooperation. Wenn eine EGovernment Lösung erarbeitet wird, sind diese Besonderheiten sowie das generelle gesellschaftliche Umfeld zu beachten. Besonders dem föderalistischen Aufbau des Staatswesens mit den sehr kleinen autonomen Einheiten kann durch Software as a Service entsprochen werden, da u.a. Mehraufwände für die Installation und Betrieb von Anwendungen jeweils vor Ort entfallen. Features of the specific medium: Der webbasierte Zugriff auf die HERA-Plattform ermöglicht den elektronischen Transfer von Dokumenten zwischen den Prozessbeteiligten und führt durch den Prozess, der nur grob strukturiert ist und ein hohes Mass an Flexibilität zulässt. HERA fokussiert primär auf die organisationsübergreifenden Prozessanteile, erlaubt aber auch die Unterstützung der internen Prozesse. HERA führt Buch über den Prozessablauf, also wer wann welche Dokumente an wen geschickt hat und mit welchem Bearbeitungsauftrag. Soweit möglich überprüft HERA das elektronische Dossier auf Vollständigkeit und Konsistenz, bevor es an den nächsten Prozesspartner weitergeleitet wird. Value Chain: Der IKT-Dienstleister übernimmt sowohl die Entwicklung, wie auch den Vertrieb der HERA-Plattform. Angeboten werden die zur Verfügung gestellten Dienste bei SaaS direkt über das Internet [13]. Die Kunden erhalten die Möglichkeit sehr einfach, zeitunabhängig und direkt über das Internet die Dienste in Anspruch zu nehmen. Potential customers: Mögliche Kunden dieses Geschäftsmodells sind Gemeinden, Kantone und der Bund, also öffentliche Verwaltungen auf allen Ebenen, sowie die juristischen und natürlichen Personen, die in die jeweilige organisationsübergreifende Zusammenarbeit eingebunden sind. Features of the specific product: Da die HERA-Plattform in diesem Zusammenhang zugleich Medium und Produkt ist, kann auf den Punkt "Features of the specific medium" verwiesen werden. 82 Financial flow: Für den Betrieb der HERA-Plattform nach dem SaaS Modell sind verschiedene Erlösmodelle denkbar. Eine erste Variante ist die Ausgestaltung der Lizenzgebühren als eine periodische, fixe Rate. Alternativ zu festen Beträgen sind auch volumenbasierte Gebühren möglich. Bei der Abrechnung nach Transaktion kann entweder pro Interaktion zwischen zwei Akteuren oder pro Geschäftsvorfall abgerechnet werden. Die Abrechnung nach Interaktionen zwischen Benutzern der Plattform birgt jedoch die Gefahr, dass die Anwender die Plattform umgehen. Deshalb ist die Abrechnung nach Geschäftsvorfall (zum Beispiel pro abgewickelter Steuererklärung) innerhalb der volumenbasierten Abrechnung für die HERA-Plattform am geeignetsten. Zusätzlich zur volumenbasierten Rate kann auch ein fixer Bestandteil für den allgemeinen Betrieb sinnvoll sein. Flow of goods and services: Der HERA-Provider stellt die Plattform direkt über das Internet zur Verfügung. Er übernimmt die gesamte Entwicklung, Updates und den Service und bietet den öffentlichen Verwaltungen so eine umfassende Lösung aus einer Hand an. Wenn Updates gemacht werden, können diese lokal im Rechenzentrum des Providers eingespeist werden. Die öffentlichen Verwaltungen brauchen keine lokalen Server. Für den Provider hat dieses Modell den Vorteil, dass die volle Kontrolle bei ihm liegt, was besonders im Fall von Fehlern oder anderen Betriebsstörungen von grossem Nutzen sein kann. 4.2. Option 2: Lizenzgeschäft mit Support Bei diesem Modell wird wieder von dem HERA-Provider die allgemeine technische Plattform entwickelt. Diese Plattform und deren Dienste werden jedoch nun nicht mehr über das Internet bereitgestellt, sondern als Softwareprodukt an die öffentlichen Verwaltungen verkauft. Diese betreiben die Plattform dann auf eigener Hardware. Beweggründe könnten z.B. erhöhte Sicherheitsanforderungen in bestimmten Bereichen der öffentlichen Verwaltung sein, wenn rein interne Abläufe unterstützt werden sollen, oder wenn bereits umfangreiche Hardware für den Betrieb zur Verfügung steht, die ausgenutzt werden soll. Anfallende Kosten beinhalten sowohl Kosten für die Lizenzierung der HERA Plattform als auch Kosten für die weitere Entwicklung, Support und das Einspielen von Updates durch den HERA-Provider angeboten. Hauptvorteil dieser Lösung ist das erhöhte Vertrauen und die potentiell leichtere Erfüllbarkeit von Sicherheitsanforderungen auf Seiten der öffentlichen Verwaltung. Nachteile ergeben sich auf der Kostenseite. Da kostenpflichtige Beratungsdienstleistungen für Support und Updates sowie mögliche Weiterentwicklungen bei dem HERA-Provider in Anspruch genommen werden müssen und diese aufgrund der vielen verteilten Installationen insgesamt aufwändiger für den Provider zu bewerkstelligen sind als im Modell SaaS, können hier keine so grossen Skaleneffekte realisiert werden. 4.3. Option 3: Lizenzgeschäft ohne Support Entsprechend dem vorher beschriebenen Lizenzgeschäft mit Support, wird beim Lizenzgeschäft ohne Support die HERA-Plattform von dem HERA Provider entwickelt und als Softwareprodukt an die öffentlichen Verwaltungen für eine Lizenzgebühr verkauft. Allerdings übernehmen staatliche Informatikstellen in diesem Modell den Support selber, nachdem diese durch den HERA Provider entsprechend geschult wurden. Der HERA Provider kann weiterhin eine "Notfallhotline" für die Informatikstellen der Verwaltungen zur Verfügung stellen. Auch Updates für die Basisplattform können weiterhin vom HERA-Provider entwickelt werden. Im Fall von HERA im E-Government der Schweiz könnten z.B. grössere Kantone dieses Modell wählen, die umfangreiche Informatikabteilungen und damit entsprechendes Know-how aufgebaut haben um ihre spezifischen Anforderungen abzudecken. Es ist denkbar dieses Business Model mit dem vorher vorgestellten zu kombinieren. Das heisst, dass der HERA Provider am Anfang den Support übernehmen würde und 83 mit der Zeit, wenn die öffentliche Verwaltung mit dem Betrieb der Plattform Erfahrung sammeln konnte, diese den Betrieb selber übernimmt. 4.4. Bewertung und Vergleich der Geschäftsmodelloptionen Die vorgestellten möglichen Geschäftsmodelloptionen sollten aus zwei Perspektiven bewertet werden. Zum einen muss das Angebot einer serviceorientierten Architektur für den Anbieter gegenüber einer klassischen Anwendung Vorteile bieten. Diese Vorteile resultieren vor allem durch die modulare Aufbauweise von SOA, wodurch bei Entwicklung, Betrieb und Wartung durch die Wiederverwendbarkeit Skaleneffekte erzielt werden können [26]. Andererseits muss der Einsatz von SOA auch für die Kunden, die öffentliche Verwaltungen, lohnenswert sein. Die Vorteile ergeben sich vor allem durch Kosteneinsparungen im administrativen Bereich und durch die einfachere Anbindbarkeit an externe und bestehende Systeme. Abbildung 4 zeigt die zwei Perspektiven in der Übersicht. Abbildung 4: Übersicht der zu bewertenden Perspektiven (eigene Darstellung) Damit sich eine öffentliche Verwaltung für eines der drei vorgestellten Modelle entscheiden kann, braucht sie eine akkurate Entscheidungsgrundlage. Diese kann durch das Total Cost of Ownership (TCO) Konzept geschaffen werden. TCO ist ein Beschaffungsinstrument, das hilft, die gesamten Kosten einer Anschaffung zu berücksichtigen [11]. Ein Vorteil des TCO Ansatzes besteht darin, dass auch Nebenkosten und interne Kosten berücksichtigt werden, die bei einfachen Preisüberlegungen oft vergessen gehen [11]. Erfolgskritisch bei der Anwendung des TCO Konzeptes sind die Rechnungslegungs- und Kostendaten, welche für eine TCO Analyse bereitgestellt werden müssen [11]. Konkret geht es für die öffentliche Verwaltung darum, alle Kosten abzuwägen, die eine bestimmte Option mit sich bringt. Die Gesamtkosten können Kosten für Hard- und Software, Personalaufwand, Wartungsaufwand, Schulungsaufwand und andere Aufwände enthalten. Die Gebühren für die Plattform stehen dabei den genannten internen Kosten gegenüber, d.h. je höher die Gebühr für die Plattform, desto mehr Leistungen sind darin enthalten und desto weniger sonstige Aufwände verursacht die Plattform. Eine öffentliche Verwaltung muss also alle internen Kosten ermitteln und diese den Gebühren für die verschiedenen Optionen gegenüberstellen. Je kostenintensiver die internen Ressourcen sind, desto eher lohnt sich die Modelloption "Software as a Service". Kann aber eine öffentliche Verwaltung auf bestehenden Ressourcen aufbauen, die wenig Grenzkosten verursachen, so eignet sich möglicherweise die Option "Lizenzgeschäft ohne Support". Dies impliziert auch, dass für kleinere Kantone und Gemeinden, die nicht über die entsprechenden Ressourcen verfügen, wobei vor allem das Informatikpersonal von Bedeutung sein wird, eher "Software as a Service" eingesetzt wird. Neben dem finanziellen Aspekt, der durch eine genaue TCO Analyse abgestützt wird, spielen auch die Präferenzen und das Sicherheitsdenken der öffentlichen Verwaltung eine wichtige Rolle. So kann es sein, dass gewisse Stellen es vorziehen, wenn sie die Hardware (z.B. die Server) lokal bei sich betreiben und dabei gleichzeitig höhere Kosten in Kauf nehmen. 84 Ebenso wie für die öffentliche Verwaltung, die ihren Investitionsentscheid durch den TCO Ansatz unterstützt, sind die drei Optionen auch für den Betreiber von unterschiedlicher Rentabilität. So ist es wahrscheinlich, dass die Option "Software as a Service" durch Skaleneffekte ab einer bestimmten Anzahl Abnehmer für den Provider am wirtschaftlichsten ist. Nussdorfer und Martin schreiben, dass die Bedeutung von SaaS darin liege "dass sich Spezialisten darauf konzentrieren können, bestimmte Services mit hohem Wiederverwendungsgrad und großer Marktbedeutung zu entwickeln und anzubieten [25]". Dennoch soll der Provider nicht auf die beiden anderen Optionen im Angebot verzichten, denn staatliche Verwaltungen werden keine E-Government Lösung wählen, die ihnen nicht voll und ganz entspricht. Die Kundenzufriedenheit soll aber oberstes Gebot sein, denn die Plattform kann nur von Netzwerkeffekten profitieren, wenn möglichst viele Verwaltungen daran angebunden sind. 5. Diskussion und Ausblick Neben den technischen Fragen, muss im E-Government auch die Frage des Betriebs der Lösungen und Plattformen gestellt werden. Dazu braucht es die Entwicklung und Bewertung von Geschäftsmodellen, die aufzeigen: wer E-Government Anwendungen betreiben sollte, welches Erlösmodell dahinter steht und wer für die Weiterentwicklung und Wartung zuständig sein soll. Nur wenn technische Innovationen richtig vermarktet und betrieben werden, steigt deren Akzeptanz und Reichweite und die E-Government Landschaft kann als Ganzes davon profitieren. Hierfür wurde in diesem Beitrag ein Geschäftsmodellframework beschrieben und an den Bedingungen des E-Government in der Schweiz angepasst. Das Modell zeigt die Aspekte, die durchdacht und beschrieben werden müssen, wenn ein Unternehmen organisationsübergreifende E-Government Services anbieten will. Anhand der kurz vorgestellten HERA Plattform wurden drei Optionen für den Betrieb und die Erlösoptionen organisationsübergreifender E-Government Dienste aufgezeigt. Dabei hat sich herausgestellt, dass gerade in einem föderalistischen Land wie der Schweiz eine Vorgehensweise, unabdingbar ist, die Modularität und Dezentralität unterstützt. Das heisst, dass Plattformen flexibel und interoperabel ausgestaltet und den staatlichen Verwaltungsstellen und deren Präferenzen entsprochen werden muss. Software as a Service bietet sich an, wenn kleine öffentliche Verwaltung eine E-Government Lösung suchen, sowie die umfangreichen Sicherheitsbedürfnisse im EGovernment abgedeckt werden können. Die eher an klassische Betreibermodelle angelehnten weiteren vorgestellten Optionen Lizenzmodell mit/ ohne Support sind in diesem Kontext ebenfalls denkbar, vor allem bei grösseren Kunden der öffentlichen Verwaltung mit vorhandenen und entsprechend ausgebildeten Informatikabteilungen. Die weiteren Arbeiten im HERA Projekt umfassen neben Umsetzung und Betrieb des Prototypen der technischen Plattform auch die detaillierte Ausarbeitung von Businessplänen aus Perspektive der verschiedenen Projektpartner. Es wird interessant sein zu beobachten, inwiefern es den öffentlichen Verwaltungen gelingen wird, im Bereich elektronische Geschäftsabwicklung mit der Privatwirtschaft gleichzuziehen und welche Betreibermodelle sich am Markt durchsetzen werden. 6. Literaturangaben [1] BECKER, J.; ALGERMISSEN, L.; NIEHAVES, B., Prozessmodellierung als Grundlage des E-Government. In: Proceedings of the Wirtschaftsinformatik 2003. Medien - Märkte - Mobilität. Dresden. 2003. S. 859 - 879. [2] BRÜCHER, H., U. GISLER, M. E-Government – von den Grundlagen zur Anwendung. In: HMD Praxis der Wirtschaftsinformatik, Heft 226, August 2002, S. 5–19. [3] BUNDESAMT FÜR STATISTIK., Spezifikation der Plattform SEcure Data EXchange Sedex. Gefunden am 25. Jun. 2008 unter http://www.bfs.admin.ch/bfs/portal/de/index/news/00/00/sedex/02.html 85 [4] CASTELLANO, M., PASTORE, N., ARCIERI, F., SUMMO, V. & BELLONE DE GRECIS, G., An eGovernment Cooperative Framework for Government Agencies. In: Proceedings of the 38th Hawaii International Conference on System Sciences, 2005. [5] CHOUDHARY, V., Software as a Service: Implications for Investment in Software Development. In Proceedings of the 40th Annual Hawaii international Conference on System Sciences (HICSS), 2007 [6] COLLM A., HRISTOVA, R., JANNER, T., REIMER, U., RITSCH, R., & SCHROTH, C., HERA: A Serviceoriented Approach to Cross-organisational E-Government Processes. eGov Präsenz, 3, 2008 [7] DHEAP, V. & WARD, P.A.S., Event-driven response architecture for event-based computing. In Proceedings of the CASCON 2005, Toranto, Ontario, Canada, October 17 - 20, 2005 [8] DIDISHEIM, J.-J., Bund Kantone und Gemeinden müssen kooperieren. In: Meyer, H. (Hrsg.): Netzguide EGovernment, Basel, 2003., S.16-17 [9] eCH. eGovernment Standards. Gefunden am 4. Juli unter www.ech.ch [10] eCH., Verein eCH. Gefunden am 25. Jun. 2008 unter http://www.ech.ch [11] ELLRAM, L.M., Total Cost of Ownership. An Analysis Approach for Purchasing, International Journal of Physical Distribution & Logistics Management, 25-8, 1995 [12] FEDOROWICZ, J., GOGAN, J. L., u. WILLIAMS, C. B., The E-Government Collaboration Challenge: Lessons from Five Case Studies, IBM Center for the Business of Government, Washington, D.C., 2006. [13] HALLEK, S., SaaS-Geschäftsmodelle im Web 2.0. In Grob, L.G. & Vossen G. (Hrsg.); Entwicklungen im Web 2.0 aus technischer, ökonomischer und sozialer Sicht, Münster: Institut für Wirtschaftsinformatik, 2007, S.73-84. [14] HELVETIC E-GOVERNMENT REFERENCE ARCHITECTURE., Prozessorientiertes, organisationsübergreifendes E-Government. Gefunden am 4. Juli unter www.hera-projekt.ch [15] HEUTSCHI, R., LEGNER, C. & ÖSTERLE, H., Serviceorientierte-Architekturen: Vom Konzept zum Einsatz in der Praxis. In: Schelp, J.; Winter, R.; Ulrich, F.; Rieger, B. & Turowski, K. (Hrsg.): DW 2006 - Integration, Informationslogistik und Architektur, Lecture Notes in Informatics (LNI) - Proceedings, Volume P-90. Bonn: Köllen Verlag, 2006 [16] HOEGG, R., MARTIGNONI, R., MECKEL, M., & STANOEVSKA-SLABEVA, K., Overview of business models for Web 2.0 communities, St.Gallen, Institute for Media and Communications-Management, 2006 [17] ISB., E-Government Strategie Schweiz, Bern, Eidgenössisches Finanzdepartement, 2007. [18] JOHANSSEN, P. & HERZ, P., eGovernment 2006. Von der technikgetriebenen zur nutzergetriebenen Verwaltungsreform, Neuwied, 2005 [19] LEGNER, C. & HEUTSCHI, R., SOA Adoption in Practice - Findings from Early SOA Implementations. In: Proceedings of the 15th European Conference on Information Systems (ECIS 2007), St.Gallen [20] MAHADEVAN, B., Business Models for Internet-Based E-Commerce. An Anatomy. In: California Management Review, Bd. 42(4), S.55-69 (2000). [21] MÜLLER, W., eCH - eine Initiative zur Förderung von Standards für E-Government in der Schweiz. Gefunden am 19. Jun. 2008 unter http://www.isb.admin.ch [22] MÜLLER, W. eGovCH - Die eGovernment Architektur Schweiz, Bern, Informatikstrategieorgan Bund (ISB), 2005. [23] MÜLLER, W., Event Bus Schweiz. Konzept und Architektur. Bern, Informatikstrategieorgan Bund (ISB), 2006. [24] NEWCOMER, E. AND LOMOW, G., Understanding SOA with Web Services. Addison-Wesley, Maryland, 2004. [25] NUSSDORFER, R. & MARTIN, W., BPM - Business Process Management: Änderung des Entwicklungsparadigmas, iBonD White Paper Vol. 3, www.soa-forum.net; München, 2007 [26] OEY, K. J., Nutzen und Kosten von serviceorientierten Architekturen, Dissertation, Uni-Köln, http://kups.ub.unikoeln.de/volltexte/2007/2043/, 2006 [27] SCHEDLER, K., eGovernment und neue Servicequalität der Verwaltung? In: Gisler, M. &Spahni, D., eGovernment - Eine Standortbestimmung,Verlag Paul Haupt Bern, 2000. [28] SCHROTH, C., HERA Architecture: Enabling Seamless Cross-Organizational Collaboration for Swiss Public Administration, In: Tagungsband des Internationales Rechtsinformatik Symposion, 2008. [29] SCHROTH, C., A Reference Model for Seamless Cross-Organizational Collaboration in the Public Sector. In: Multikonferenz Wirtschaftsinformatik 2008 (M. Bichler, et. al.), Munich, Germany, S. 377-388, (2008). [30] TIMMERS, P., Business Models for electronic markets. In: Journal on Electronic Markets. Bd. 8(2), S. 3-8 (1998). [31] VOIGT, K.-I. & WETTENGL, S., Innovationskooperationen im Zeitwettbewerb. Gefunden am 19. Jun. 2008 unter http://wettengl.info/60_Veroeffentlichungen/VoWe1999.pdf [32] VON HIPPEL, E., Innovation by user communities. Learning from Open-Source Software. In: MIT Sloan Management Review. Bd. 42(4), S. 82-86 (2001). [33] ZU KNYPHAUSEN-AUFSESS, D. & MEINHARDT, Y., Revisiting Strategy: Ein Ansatz zur Systematisierung von Geschäftsmodellen. . In: Bieger, T, Bickhoff, N., Caspers, R., zu Knyphausen-Aufsess, D. & Reding, K., (Hrsg.): Zukünftige Geschäftsmodelle. Konzept und Anwendung in der Netzökonomie, Heidelberg, 2002., S.63-89 86 IS-ARCHITEKTUREN Mit der Komplexität betrieblicher Informationssysteme wachsen auch kontinuierlich die Anforderungen an die Veränderbarkeit von Geschäftsmodellen, Geschäftsprozessen und schließlich Softwaresystemen. Aktuelle Ansätze zur Gestaltung von IS-Architekturen, wie etwa die Serviceorientierung, schaffen zusätzliche Herausforderungen auf allen Architekturebenen. Der Track IS-Architekturen adressiert das gesamte Spektrum der Gestaltung und des Managements der komplexen Abhängigkeiten über alle Architektur-Ebenen hinweg: Von der Strategie und Organisation bis zur Software und IT-Infrastruktur. Leitungsgremium: Ulrich Frank, Universität Duisburg-Essen Heinrich C. Mayr, Alpen-Adria-Universität Klagenfurt Robert Winter, Universität St. Gallen (Federführender) Programmkomitee: Frederik Ahlemann, European Business School Stephan Aier, Universität St. Gallen Jörg Becker, Universität Münster Johann Eder, Alpen-Adria-Universität Klagenfurt Matthias Goeken, Frankfurt School of Finance & Management Helmut Krcmar, Technische Universität München Christine Legner, European Business School Susanne Leist, Universität Regensburg Herrmann Maier, Alpen-Adria-Universität Klagenfurt Günther Müller Luschnat, Cirquent GmbH Sven Overhage, Universität Augsburg Michael Rohloff, Universität Potsdam Joachim Schelp, Universität St. Gallen Marten Schönherr, Deutsche Telekom T-Labs Petra Schubert, Universität Koblenz-Landau Elmar Sinz, Universität Bamberg Claudia Steinberger, Alpen-Adria-Universität Klagenfurt Stefan Strecker, Universität Duisburg-Essen Oliver Thomas, Deutsches Forschungszentrum für Künstliche Intelligenz GmbH Jan vom Brocke, Hochschule Liechtenstein Jürgen Uhl, IBM Global Business MODELLGETRIEBENE ENTWICKLUNG VON SERVICEORIENTIERTEN ARCHITEKTUREN Rainer Bernhard1, Bernd U. Jahn2 Kurzfassung Die Analyse von Geschäftsprozessen gilt als wichtige Voraussetzung für die Entwicklung einer serviceorientierten Architektur. Der Übergang vom Geschäftsprozess zum Entwurf von Diensten und deren Orchestrierung in Workflows stellt auf Grund der unterschiedlichen Zielsetzungen der jeweiligen Betrachtungsebenen eine große Herausforderung dar. Um diese semantische Lücke zwischen der fachlichen und softwaretechnischen Ebene zu schließen, muss eine durchgängige Modellierung über mehrere Abstraktionsebenen hinweg durchgeführt werden. Der in diesem Artikel beschriebene modellgetriebene Ansatz, der auf dem semantischen Objektmodell beruht, soll diese Durchgängigkeit gewährleisten. 1. Einleitung Nach den technologiegetriebenen Diskussionen über serviceorientierte Architekturen (SOA) der vergangenen Jahre befassen sich immer mehr Autoren mit dem gesamten Entwicklungsprozess einer SOA ([2], [4], [16] und [17]). Die Methoden stützen sich dabei auf die Konzepte und Werkzeuge der modellgetriebenen Softwareentwicklung (Model Driven Software Development, MDSD). Durch die Unterteilung des Modellsystems in verschiedene Teilmodellsysteme trägt die MDSD zur Komplexitätsbewältigung bei und gewährleistet die durchgängige Modellierung über alle Abstraktionsebenen hinweg. Dieser Artikel stellt einen modellgetriebenen Ansatz für die durchgängige Analyse und das Design serviceorientierter Architekturen vor. Der Ansatz integriert dazu etablierte geschäfts- und objektorientierte Modellierungsansätze mit serviceorientierten Konzepten. SOA bauen auf die Erfahrungen mehrerer Jahrzehnte der Softwareentwicklung auf [9, S. 13 - 25] und stützen sich dabei auf bewährte Konzepte aus der objektorientierten Programmierung, der Komponentenorientierung, sowie der Entwicklung von verteilten Systemen. Diese Konzepte stellen einen geeigneten Ausgangspunkt für die Analyse und den Entwurf serviceorientierter Architekturen dar. Deshalb wird die objekt- und geschäftsprozessorientierte SOM-Methodik [7], die durch ihre formalen Modelleigenschaften und durch die Integration der Modelle über Sichten und Ebenen hinweg eine durchgängige Modellierung betrieblicher Systeme gewährleistet, als Grundlage für diese Arbeit verwendet. Als Notation für die Verhaltenssicht einer SOA kommt die Business Process Modeling Notation (BPMN) zum Einsatz. Die Struktursicht wird mit der Unified Modeling 1 Siemens AG Industry Sector, Lina-Ammon-Str. 9, D-90471 Nürnberg Bamberg, Feldkirchenstr. 21, D-96045 Bamberg 2 Otto-Friedrich-Universität 89 Language (UML) modelliert. Die Dienste werden als Web Services implementiert und mit der Business Process Execution Language (BPEL) orchestriert. Nach einer kurzen Einführung in die MDSD und SOM-Methodik stellt Kapitel 3 die verschiedenen Modellebenen und deren Beziehungen zueinander vor. Die Modellbildung wird in Kapitel 4 mit Hilfe eines Fallbeispiels demonstriert. Der Artikel schließt mit einem Verweis auf vergleichbare Ansätze und einer Zusammenfassung der Ergebnisse. 2. Grundlagen Ein zentrales Hilfsmittel zur Komplexitätsbewältigung bei der Softwareentwicklung stellt das Prinzip der Abstraktion und Strukturierung dar [11, S. 263]. Modelle folgen diesem Prinzip: Durch zielgerichtete Abbildung realer Sachverhalte enthalten Modelle lediglich die zur Zielerreichung notwendigen Merkmale des realen Systems. Darüber hinaus werden Modelle auch als Kommunikationsmittel zwischen Auftraggeber und Auftragnehmer, innerhalb des Entwicklungsteams oder zu Dokumentationszwecken eingesetzt. Die modellgetriebene Softwareentwicklung als spezieller Ansatz erweitert die Modellnutzung: Neben reinen Dokumentations- und Kommunikationsaufgaben werden Modelle im gesamten Entwicklungsprozess zum Generieren von Programmcode, Testen sowie für das Deployment von Anwendungssystemen eingesetzt [8, S. 1f]. Die Object Management Group (OMG) hat in diesem Zusammenhang durch die Veröffentlichung zahlreicher Standards wie der Unified Modeling Language (UML) oder der Meta Object Facility (MOF) einen großen Anteil an der Verbreitung des modellgetriebenen Entwicklungsansatzes. Seit 2001 arbeitet die OMG zudem an der Model Driven Architecture (MDA), einem Rahmenwerk, das diese Standards zu einer modellgetriebenen Entwicklungsmethodik zusammenführt. Grundlage für den in dieser Arbeit vorgestellten Ansatz ist die modellgetriebene SOM-Methodik für die Modellierung betrieblicher Systeme ([6] und [7]). Diese setzt sich aus dem objekt- und geschäftsprozessorientierten Modellierungsansatz SOM (Semantisches Objektmodell), der SOMUnternehmensarchitektur und dem SOM-Vorgehensmodell (V-Modell) zusammen. Die Unternehmensarchitektur unterscheidet drei Modellebenen (vgl. [7, S. 192f.]): Der Unternehmensplan spezifiziert die Aufgaben- und Aufgabenträgerebene (A- und AT-Ebene) des betrieblichen Systems aus der Außenperspektive. Die Modellierung stützt sich hierbei auf die Metapher einer globalen Unternehmensaufgabe. Das Geschäftsprozessmodell (GP-Modell) spezifiziert die A-Ebene des betrieblichen Systems aus Innenperspektive und beschreibt das Lösungsverfahren für die im Unternehmensplan definierte globale Unternehmensaufgabe. Die Modellbildung beruht auf der Metapher eines verteilten Systems. Das Ressourcenmodell spezifiziert die AT-Ebene des betrieblichen Systems aus Innenperspektive. Als Aufgabenträger für die Durchführung der Aufgaben stehen Personal, Anwendungssysteme (AwS) sowie Anlagen und Maschinen zur Verfügung. Als zugrunde gelegte Metapher dient der Systemtyp eines sozio-technischen Systems: Mensch und Maschine führen betriebliche Aufgaben nach dem Partner-Partner-Modell durch. Gemäß V-Modell [7, S. 195f.] werden die drei Ebenen von oben nach unten durchlaufen. In zwei Sichten werden auf jeder Ebene die Systemmerkmale Struktur und Verhalten erfasst. Innerhalb jeder Ebene müssen die Sichten aufeinander abgestimmt werden. Die Modelle der verschiedenen Ebenen müssen miteinander korrespondieren (vgl. Abbildung 1), sodass ein konsistentes Modellsystem entsteht. Ausgangspunkt der Modellierung ist der Unternehmensplan, der Diskurswelt und Umwelt voneinander abgrenzt, sowie die zugehörigen Leistungsbeziehungen definiert. Die Diskurswelt bezeichnet dabei den relevanten Ausschnitt der betrieblichen Realität. Aufgabenziele, Strategien und Rahmenbedingungen für die Umsetzung der Leistungsbeziehungen sind im Zielsystem zu definieren, welches ebenfalls Bestandteil des Unternehmensplans ist. Die Struktursicht des Geschäftsprozessmodells wird im Interaktionsschema (IAS) modelliert. Die im Unternehmensplan 90 identifizierten Diskurswelt- und Umweltobjekte stellen betriebliche Objekte im IAS dar. Transaktionen verbinden betriebliche Objekte und repräsentieren die zugehörigen Leistungsbeziehungen aus dem Unternehmensplan. Das Vorgangs-Ereignis-Schema (VES) beschreibt die korrespondierende Verhaltenssicht in Form eines ereignisgesteuerten Ablaufs von Aufgaben. Die Detaillierung des Modells erfolgt durch sukzessive Zerlegung des initialen Geschäftsprozessmodells. Anwendungssysteme repräsentieren maschinelle Aufgabenträger zur Durchführung automatisierter (Teil-) Aufgaben von Geschäftsprozessen. Die Spezifikation der AwS erfolgt mit Hilfe des konzeptuellen Objektschemas (KOS) und des Vorgangsobjektschemas (VOS). Abbildung 1: SOM-Unternehmensarchitektur und V-Modell [7, S. 193 und 195] Die fachliche Spezifikation von AwS der SOM-Methodik im KOS und VOS bildet den Ausgangspunkt für den softwaretechnischen Entwurf [6, S. 219]. Amberg [1] und Malischewski [12] haben ein mit der SOM-Methodik abgestimmtes Softwarearchitekturmodell konzipiert (vgl. linke Hälfte von Abbildung 2), das die vollständige Übernahme der Modellierungsergebnisse in den softwaretechnischen Entwurf ermöglicht: Das konzeptuelle Objektschema (KOS) besteht aus einer Menge von konzeptuellen Objekttypen (KOT), die miteinander in Beziehung stehen. Durch die Modellierung von Daten und Funktionen in Form von KOTs stellt das KOS eine objektorientierte Erweiterung der konzeptuellen Datenmodellierung dar [6, S. 212]. Das Vorgangsobjektschema (VOS) beinhaltet eine Menge von Vorgangsobjekttypen (VOT), die miteinander in Beziehung stehen, und gemeinsam die zweite Sicht der Spezifikation bilden. Ein VOT beschreibt das Lösungsverfahren für die Durchführung einer Aufgabe, die auch als Vorgang bezeichnet wird und aus einer Folge von Aktionen besteht. Automatisierbare Aktionen können durch Operatoren eines KOTs realisiert werden. Dadurch lässt sich das Lösungsverfahren einer Aufgabe als eine Abfolge von Methodenaufrufen auf KOTs spezifizieren. Damit ein betriebliches AwS auch mit Menschen (Mensch-Computer-Kommunikation, MCK) und anderen AwS (Computer-Computer-Kommunikation, CCK) interagieren kann, sind geeignete Schnittstellen zu definieren. Diese Schnittstellen werden im Interface-Objektschema (IOS) einheitlich beschrieben. Jede Schnittstelle wird als Interface-Objekttyp (IOT) spezifiziert und kann anschließend im Lösungsverfahren eines VOT verwendet werden. Einerseits kann ein Vorgang Nachrichten an IOTs senden, um die weitere Verarbeitung durch einen Menschen oder ein AwS auszulösen. Andererseits wird die Durchführung von betrieblichen Aufgaben durch eingehende Nachrichten von IOTs ausgelöst. KOS, VOS und IOS definieren die fachliche Funktionalität des AwS. Diese Funktionalität stützt sich auf eine anwendungsneutrale technische Funktionalität, die im technischen Objektschema (TOS) beschrieben wird. Das TOS stellt eine einheitliche Basismaschine für das AwS zur Verfügung und baut wiederum auf anderen Basismaschinen auf, wie z.B. Datenbanksystemen oder Klassenbibliotheken. Das TOS wird in dieser Arbeit nicht weiter betrachtet. 91 Abbildung 2: SOM-Softwarearchitekturmodell und Serviceorientierte Architektur (in Anlehnung an [12]) Zwischen dem SOM-Softwarearchitekturmodell und dem Ebenenmodell einer SOA ([2], vgl. auch [4], [10] und [14]) existieren strukturelle Ähnlichkeiten (siehe Abbildung 2): Basisdienste der Schicht 3 verwalten betriebliche Entitäten und stellen Operationen zur Manipulation dieser Entitäten zur Verfügung. Diese betrieblichen Entitäten mit ihren Attributen und Operationen finden sich auch in der SOM-Architektur als KOTs wieder. Schnittstellen zur Kommunikation mit AwS oder Menschen werden als Schnittstellen im IOS bzw. als Basisdienste spezifiziert. Objekte für die Vorgangssteuerung haben ihre Entsprechung in den Prozessdiensten einer SOA. Neben diesen strukturellen Ähnlichkeiten gewährleistet die SOM-Methodik eine durchgängige Modellierung betrieblicher Systeme. Damit bildet die SOM-Methodik eine naheliegende Grundlage für die Ableitung von Diensten und deren Orchestrierung in Form von Workflow-Schemata. 3. Modellgetriebene Entwicklung von serviceorientierten Architekturen Dieser Beitrag konzentriert sich auf die Analyse und das Design der Basis- und Prozessdienste, sowie der Schnittstellen für die Benutzerinteraktion. Sie abstrahiert also von der konkreten Implementierung der Dienste, sowie der technischen Infrastruktur, wie dem Enterprise Service Bus. Kern der Arbeit ist ein Architekturmodell, bestehend aus verschiedenen Abstraktionsebenen und Sichten, die durch Beziehungsmetamodelle miteinander verbunden sind. Grundlage des Architekturmodells bildet die SOM-Unternehmensarchitektur und das korrespondierende Softwarearchitekturmodell von Amberg und Malischewski. Das GP-Modell beschreibt die Aufgabenebene des betrieblichen Systems. Die betrieblichen Aufgaben werden im verhaltensorientierten VES und im strukturorientierten IAS spezifiziert. Serviceorientierte AwS – als Aufgabenträger für die Durchführung der betrieblichen Aufgaben – wird im KOS, IOS und VOS erfasst. Die zwei strukturorientierten Sichten für die Modellierung von Entitäten (KOS) und für die Schnittstellen zur Kommunikation mit Mensch und Maschine (IOS) werden in UML-Notation modelliert. Durch Stereotypen oder Profile kann die Notation für die Spezifikation von Diensten ertüchtigt werden. Im KOS lassen sich dadurch die Basisdienste für den Zugriff auf Entitäten (EntitätenDienste) spezifizieren. Im IOS können Dienste für die Benutzerinteraktion und für die Kommunikation mit anderen AwS (Schnittstellen-Dienste) erfasst werden. BPMN-Workflows, deren einzelne Aktivitäten aus den im IOS und KOS definierten Entitäten- und Schnittstellen-Diensten bestehen, spezifizieren die Ablaufsicht der Vorgänge (VOS). Durch die klare Trennung zwischen Aufgabenund Aufgabenträgerebene berücksichtigt das Architekturmodell insbesondere die Unterschiede zwischen einem Geschäftsprozess und dessen Automatisierung durch Workflows [vgl. 15]. Ein mit dem Architekturmodell abgestimmtes Vorgehen leitet den Modellierer durch die verschiedenen Ebenen und Sichten des Entwicklungsprozesses. Für die Modellierung komplexer realer Problemstellungen wird der Modellierer zudem durch ein geeignetes Entwicklungswerkzeug unterstützt. Dieses Kapitel beschreibt die einzelnen Ebenen und den Entwicklungsprozess über die Ebenen hinweg (vgl. Abbildung 3). 92 Abbildung 3: Modellarchitektur Ebene 1 – Unternehmensplan: Der SOM-Unternehmensplan ist Teil der Anforderungsanalyse und bildet die oberste Ebene der Modellarchitektur. Auf dieser Ebene wird die globale Unternehmensaufgabe durch das Objekt- und Zielsystem verbal beschrieben. Ebene 2 – Geschäftsprozess-Modell: Mit dem GP-Modell beginnt die Spezifikation der Innenperspektive des betrieblichen Systems. Als Fortsetzung der Anforderungsanalyse wird das Lösungsverfahren für die globale Unternehmensaufgabe im IAS und VES beschrieben. Das initiale GP-Modell wird anschließend gemäß den Zerlegungsregeln für Objekte und Transaktionen [6, S. 196] sukzessive zerlegt. Ebene 3 – Fachliche Spezifikation der Aufgabenträger aus Außensicht: Ausgehend vom GPModell, beginnt die fachliche Spezifikation der (teil-)automatisierbaren AT im VOS, KOS und IOS. In der Außensicht werden das Aufgabenobjekt, die Ziele und die Ereignisse für die Durchführung der einzelnen betrieblichen Aufgaben festgelegt. Dabei abstrahiert der Modellierer auf dieser Ebene von technischen Aspekten und konzentriert sich auf die fachlichen Anforderungen an die zu entwickelnde SOA. Aus der Verhaltenssicht des GP-Modells wird der BPMN-Workflow abgeleitet, der den Ablauf zwischen den Vorgängen definiert Gleichzeitig können aus der Struktur- und Verhaltenssicht des GP-Modells die initialen, fachlichen Entitäten abgeleitet und in einem UMLKlassendiagramm spezifiziert werden. Mehrere Entitäten werden anschließend zu Entitäts-Diensten zusammengefasst. Neben Entitäten können sich bereits aus dem BPMN-Workflow heraus weitere Dienste der SOA ergeben. Jedem Vorgang, der an einer nicht-automatisierbaren Transaktion beteiligt ist, muss eine Schnittstelle für die Mensch-Computer-Kommunikation zur Verfügung gestellt werden. Hingegen sind Anforderungen an Schnittstellen für die Computer-Computer-Kommunikation (z. B. Adapter) auf der fachlichen Ebene noch nicht zu berücksichtigen, da sie sich erst aus den einzusetzenden Technologien ergeben. Ebene 4 – Fachliche Spezifikation der Aufgabenträger aus Innensicht: Die identifizierten Vorgänge der Ebene 3 werden auf Ebene 4 aus der Innensicht betrachtet. Das Lösungsverfahren eines Vorgangs besteht aus einer Navigation über Entitäten-Diensten und Diensten für die Benutzer- und Systeminteraktion (Schnittstellen-Dienste). Durch Betrachtung der Innensicht eines Vorgangs werden neue Anforderungen an Entitäten- und Schnittstellen-Dienste aufgedeckt. Ergebnis der Ebene sind somit BPMN-Workflows für jeden Vorgang sowie detaillierte UML-Klassendiagramme für die Entitäten- und Schnittstellen-Dienste. Ein- und ausgehende Transaktionen aus der Außensicht 93 eines Vorgangs bilden die Start- und End-Ereignisse des BPMN-Workflows aus der Innensicht. Initial enthält das Modell darüber hinaus lediglich Aktivitäten, die Nachrichten von anderen Vorgängen empfangen oder an diese senden. Diese eingehenden und ausgehenden Nachrichten bilden somit den Kontext, in dem der Modellierer das Lösungsverfahren spezifizieren kann. Der abgeleitete BPMN-Workflow wird anschließend derart überarbeitet, dass ein lückenloser Kontrollfluss zwischen den einzelnen Aktivitäten entsteht. Dabei werden neue identifizierte Aktivitäten in Form von Diensten (Schnittstellen oder Entitäts-Dienste) im KOS und IOS ergänzt. Ebene 5 – Softwaretechnische Spezifikation der Aufgabenträger aus Außensicht: Die Umsetzung der fachlichen Anforderungen durch eine serviceorientierte Architektur beginnt auf Ebene 5. Für den Entwurf werden die Modellierungsergebnisse der Ebene 3 um softwaretechnische Aspekte erweitert. Die betrieblichen Objekte sind unabhängig voneinander und kooperieren im Hinblick auf gemeinsame Zielerreichung [6, S. 187f]. Für die Kooperation betrieblicher Objekte und deren Vorgänge legt der softwaretechnische Entwurf aus Außensicht das Protokoll für den Nachrichtenaustausch fest. Das Protokoll ist für die beteiligten Objekte bindend und ermöglicht dadurch eine dezentrale Koordination. Diese Form nichthierarchischer Steuerung wird auch als Choreographie bezeichnet. Zunächst werden die Dienste des IOS und KOS typisiert. Anschließend müssen die Implementierungsartefakte (siehe Ebene 7 zur Generierung der XSD und WSDL-Dateien) der Dienste generiert werden, so dass diese bei der Überarbeitung des BPMN-Workflows verwendet werden können. Den einzelnen Vorgängen des BPMN-Workflow werden die generierten Schnittstellenbeschreibungen zugeordnet, so dass die Nachrichtenbeziehungen zwischen den Vorgängen eindeutig festgelegt sind. Alle nichtautomatisierbaren Vorgänge müssen in diesem Schritt aus dem Workflow entfernt werden. Für diese Transaktionen übernehmen Dienste für die Mensch-ComputerInteraktion den Austausch der Nachrichten. Auch automatisierbare Transaktionen, die nicht als Web-Service implementiert werden, müssen durch Adapterdienste ersetzt werden, die die Anbindung anderer Systeme ermöglichen. Da sich aus der Überarbeitung des BPMN-Workflows wiederum Anforderungen an die Entitäten- und Schnittstellendienste ergeben können, sind die Ebenen 5 bis 7 in einem iterativen Entwicklungsprozess zu durchlaufen. Ebene 6 – Softwaretechnische Spezifikation der Aufgabenträger aus Innensicht: Das fachliche Modell der Innensicht (Ebene 4) bildet die Grundlage für diese Ebene. Zunächst werden die Nachrichten, die in der softwaretechnischen Außensicht bereits typisiert wurden, in den BPMN-Workflow aus Ebene 4 integriert. Der Modellierer kann nun mit der Typisierung und Erweiterung des fachlichen Modells fortfahren, so dass eine geeignete Basis für die Generierung von BPEL-Workflows möglich ist. So müssen z. B. PartnerLinkTypes und PartnerLinks definiert, Web-ServiceOperationen den Aktivitäten zugeordnet, Kompensationsaktivitäten erstellt und alternative Kontrollflüsse für die Ausnahmebehandlung spezifiziert werden. Ebene 7 – Implementierung: Die Datenbasis der serviceorientierten Architektur leitet sich aus dem KOS ab und wird durch ein XML-Schema definiert. Web-Services beschreiben die Entitäten- und Schnittstellen-Dienste. Aus der Ablaufsicht können BPEL-Workflows generiert werden. Zunächst wird aus dem BPMN-Workflow der softwaretechnischen Außensicht die Schnittstellenbeschreibung des BPEL-Workflows gewonnen. Dadurch verbirgt sich in den einzelnen BPEL-Workflows implizit die in der softwaretechnischen Außensicht definierte Choreographie zwischen den betrieblichen Objekten. Explizit kann die Choreographie aber auch durch geeignete Standards, wie z. B. der Web-Service Choreography Description Language (WSCDL), erfasst werden. Aus der softwaretechnischen Innensicht kann schließlich der eigentliche BPEL-Prozess generiert werden, der die Schnittstellenbeschreibung implementiert. Das abgeleitete XML-Schema, die Web-Service Beschreibungen und BPEL-Workflows sind das Ergebnis der Modellbildung. Aufbauend auf diesen 94 Artefakten muss die Implementierung der Web-Services durch Komponenten erfolgen. Entwurf und Realisierung dieser Komponenten sind jedoch nicht Bestandteile dieser Arbeit. 4. Erläuterndes Beispiel Mit Hilfe eines erläuternden Beispiels soll die Modellbildung über alle Ebenen und Sichten hinweg demonstriert werden. Grundlage ist ein produzierendes Unternehmen, wie z. B. die Siemens AG, das Waren von seinen Lieferanten bezieht, Produkte fertigt und diese an Kunden distribuiert. In diesem Kapitel soll der vereinfachte Geschäftsprozess Warenbereitstellung (siehe Abbildung 4) durch eine serviceorientierte Architektur automatisiert werden. Ebene 1: Die Diskurswelt umfasst den Aufgabenbereich Warenbereitstellung eines Produktionsunternehmens. Dabei sind bei Lieferanten Waren zu beziehen, zu lagern und für die weitere Verarbeitung bereitzustellen. Sachziel der Beschaffung ist die Bereitstellung der Waren, als Formalziel wird die Kostenminimierung durch optimierte Lager- und Beschaffungskosten verfolgt. Ebene 2: Der Geschäftsprozess Warenbereitstellung besteht aus den betrieblichen Objekten Einkauf, Lager und Lieferant. Die Koordination der betrieblichen Objekte erfolgt über die Transaktionen Bestellung, Annahmeanweisung, Warenlieferung und Annahmemeldung, deren zeitlicher Ablauf im VES spezifiziert wird. Ebene 3: Die Verhaltenssicht lässt sich direkt in einen BPMN-Workflow übertragen. Der Eingang einer Bestellanforderung löst den Workflow aus. Parallel zur Ablaufsicht wurde das initiale KOS abgeleitet und überarbeitet. Die Abbildung zeigt einen Ausschnitt des KOS, bestehend aus verschiedenen Entitäten, die zu den Diensten Lieferantenverwaltung, Produktverwaltung und Beschaffungsverwaltung zusammengefasst wurden. Da der Wareneingang in diesem Beispiel eine nichtautomatisierbare Transaktion ist, wurde ein entsprechender Schnittstellendienst für die Erfassung der Waren durch den Menschen spezifiziert (MCK_Lieferschein_Eingabe). Ebene 4: Nachdem die Außensicht die Nachrichten- und Ereignisbeziehungen zwischen den betrieblichen Aufgaben festlegt, wird in der Innensicht das Lösungsverfahren der einzelnen Vorgänge als eigenständiges Ablaufdiagramm modelliert. Start- (Eingang der Bestellanforderung) und Endereignis (Auslösen der Annahmeanweisung) des Vorgangs sende Bestellung (Bestellung>) sowie die gleichnamige Aktivität ergeben sich direkt aus den Beziehungen des Vorgangs. Darüber hinaus wurde der Workflow um weitere Aktivitäten ergänzt, die auf die Operatoren des Entitäten-Dienstes Beschaffungsverwaltung zurückgreifen. Ebene 5: Ausgangspunkt der softwaretechnischen Spezifikation bildet die Detaillierung des KOS und IOS. Erst die strenge Typisierung der Attribute und Parameter ermöglicht die Generierung des XML-Schemas und der zugehörigen Web-Services. Das fachliche VOS aus Außensicht wird als initiales Modell übernommen und anschließend derart überarbeitet, dass es sich als Ableitungsbasis für die Choreographie der beteiligten Vorgänge eignet. Da es sich im Wesentlichen um Typisierungen von Variablen sowie die Zuweisung von Operatoren handelt, sind diese Änderungen in der Abbildung nicht sichtbar. Nach der Überarbeitung enthält es ausschließlich Nachrichtenflüsse, die mit Hilfe von Web-Services ausgetauscht werden. Da die Bestellung an den Lieferanten per EDI übertragen wird, ist ein Schnittstellendienst für die Kommunikation mit einem externen AwS notwendig (CCK_Sende_Bestellung). 95 Abbildung 4: Geschäftsprozess Warenbereitstellung Ebene 6: Das initiale Modell dieser Ebene basiert auf der fachlichen Spezifikation der Innensicht, deren Nachrichten- und Ereignisbeziehungen um die softwaretechnischen Details der Ebene 5 erweitert wurden. Darüber hinaus beinhaltet das Diagramm einen alternativen Kontrollfluss für die Ausnahmebehandlung beim Erstellen einer Bestellung. Um einen derartigen Fehler behandeln zu können, wurde ein neuer Schnittstellendienst für die Kommunikation mit dem Einkäufer modelliert (MCK_Fehlermeldung). 96 Ebene 7: Die Abbildung zeigt eine Übersicht der aus den Ebenen 5 und 6 generierten Artefakte der SOA. Auf Basis der Schnittstellendefinitionen kann mit dem Entwurf und der Implementierung der Komponenten fortgefahren werden. 5. Zusammenfassung und verwandte Arbeiten Die Konstruktion von serviceorientierten Architekturen beginnt mit der Analyse und Modellierung der Geschäftsprozesse eines betrieblichen Systems. Die Überführung der Geschäftsprozessmodelle in technische Workflows und zugehörige Basisdienste ist jedoch auf Grund unterschiedlicher Zielsetzungen der Modelle nicht einfach. Durch Zerlegung des Modellsystems in mehrere Abstraktionsebenen kann die semantische Lücke zwischen Aufgaben- und Aufgabenträgerebene in kleinen Schritten überwunden werden. In dieser Arbeit wurde deshalb ein modellgetriebener Ansatz vorgestellt, der den Entwurf einer SOA in sieben Teilmodellsysteme gliedert und die Übergänge zwischen den Ebenen durch Beziehungsmetamodelle definiert. Die Beziehungsmetamodelle bestehen aus eindeutigen Ableitungsregeln [4, S. 57ff], die eine automatisierte Transformation zwischen den Ebenen erlauben. Die Regeln gewährleisten auch die Konsistenz zwischen den Modellebenen, sodass der Modellierer sich auf die Überarbeitung und Detaillierung der abgeleiteten Modelle konzentrieren kann. Die automatisierbare Transformation sowie weitere Automatisierungspotentiale wurden mittels eines vertikalen Prototyps untersucht. Dieser stützt sich auf MDA-Standards für die Definition der Metamodelle und die Modell-zu-Modell-Transformationen3. Der Prototyp wurde für das in dieser Arbeit vorgestellte Fallbeispiel eingesetzt, sodass eine vollautomatisierte Transformation der Modelle und die Generierung der Artefakte möglich waren. Einen dieser Arbeit sehr verwandten Ansatz haben Thomas et al. [16] vorgeschlagen, deren Architekturmodell die Gestaltungs-, die Konfigurations- und die Ausführungsebene unterscheidet: Ausgehend von der Systemabgrenzung und Geschäftsprozessmodellierung (Gestaltungsebene) erfolgt die fachliche und softwaretechnische Konfiguration auf den Ebenen 3 bis 6 (Konfigurationsebene) und schließlich die Spezifikation der ausführbaren BPEL-Workflows auf Ebene 7 (Ausführungsebene). Einen wesentlich umfangreicheren Entwicklungsprozess hat IBM aufbauend auf dem Rational Unified Process definiert [17]. Obwohl sich diese Methode über alle Phasen der Softwareentwicklung erstreckt, liegen ihre Schwerpunkte in der Entwurfs- und Implementierungsphase. Durch die strukturierte Vorgehensweise über mehrere Ebenen und Sichten hinweg, systematisiert der in dieser Arbeit vorgestellte Ansatz diese frühen Phasen und kann als Ausgangsbasis für einen derartigen Entwicklungsprozess verwendet werden. Ein weiterer Ansatz für den Entwurf von serviceorientierten Architekturen basiert auf der von Scheer konzipierten Architektur integrierter Informationssysteme (ARIS) [13]. Aus den mit der ARIS-Methode analysierten Geschäftsprozessen werden die Anforderungen an die technische Infrastruktur abgeleitet und anschließend in 10 Schritten in eine SOA umgesetzt [9]. Die von IDS Scheer entwickelte Methode konzentriert sich wie dieser Artikel auf die frühen Phasen des Entwicklungsprozesses und basiert ebenfalls auf einem geschäftsprozessorientierten Ansatz. Im Gegensatz zu dem in dieser Arbeit und dem von Thomas et al. vorgeschlagenen Architekturmodell erfolgt die Konfiguration der SOA aber direkt in den EPKs. Eine klare Trennung zwischen Geschäftsprozessebene und Workflow-Ebene bzw. zwischen fachlichen und technischen Anforderungen ist dabei nicht gewährleistet. Der hier vorgestellte Ansatz integriert verschiedene Modellierungsansätze und Standards in einem Architekturmodell für die modellgetriebene Entwicklung einer SOA. Das Architekturmodell ist offen gestaltet, so dass sich in zusätzlichen Sichten weitere Aspekte einer SOA erfassen lassen. Mit Hilfe von Patterns könnte darüber hinaus heuristisches Entwurfswissen integriert werden. Denn letztlich können Modelle, Methoden und Vorgehensweisen nur einen Beitrag zur durchgängigen 3 Der Prototyp wurde mit Hilfe des Eclipse Modeling Frameworks (EMF) und der Atlas Trasformation Language (ATL) implementiert. Siehe [4, S. 74ff] für eine Vorstellung des Prototypen. 97 Entwicklung einer SOA leisten und den Modellierer bei der Komplexitätsbewältigung unterstützen. Die Qualität des zu konstruierenden Systems hängt immer noch in entscheidendem Maße von der Erfahrung und dem Wissen der beteiligten Entwickler ab. 6. Literaturangaben [1] AMBERG, M., Konzeption eines Software-Architekturmodells für die objektorientierte Entwicklung betrieblicher Anwendungssysteme, Dissertation an der Otto-Friedrich-Universität Bamberg, 1993. [2] ARSANJANI, A., Serviceoriented modeling and architecture - How to identify, specify, and realize services for your SOA. In: IBM Developerworks, http://www.ibm.com/developerworks/library/ws-soa-design1 (Letzter Aufruf: 2008-11-14), 2004. [3] ARSANJANI, A., ZHANG, L.-J., ELLIS, M., ALLAM, A. und CHANNABASAVAIAH, K., Design an SOA solution using a reference architecture In: IBM Developerworks, http://www-128.ibm.com/developerworks/library/ararchtemp/index.html (Letzter Aufruf: 2008-11-14), 2007. [4] BERNHARD, R., Modellgetriebene Entwicklung von service-orientierten Architekturen auf Basis der SOMMethodik, Diplomarbeit an der Otto-Friedrich-Universität Bamberg, 2008. [5] ERL, T., Serviceoriented architecture : concepts, technology, and design, Prentice Hall, München 2005. [6] FERSTL, O. K. und SINZ, E. J., Objektmodellierung betrieblicher Informationssysteme im Semantischen Objektmodell (SOM). In: WIRTSCHAFTSINFORMATIK 32(6), S. 566-581, 1990. [7] FERSTL, O. K. und SINZ, E. J., Grundlagen der Wirtschaftsinformatik, 6. Auflage, Oldenbourg, München 2008. [8] FRANCE, R. und RUMPE, B., Model-driven Development of Complex Software: A Research Roadmap. In: FOSE '07: 2007 Future of Software Engineering, S. 37 – 54, IEEE Computer Society, Washington, DC, USA, 2007. [9] KLÜCKMANN, J., In 10 Schritten zur Business-Driven SOA, http://www.idsscheer.com/set/82/ARIS_Expert_Paper_-_10_Steps_to_SOA_Klueckmann_2007-03_en.pdf (Letzter Aufruf: 2008-1114), 2007. [10] KRAFZIG, D., BANKE, K. und SLAMA, D., Enterprise SOA : serviceoriented architecture best practices, Prentice Hall, NJ 2005. [11] KURBEL, K., STRUNZ, H., Handbuch der Wirtschaftsinformatik, Poeschel, Stuttgart, 1990. [12] MALISCHEWSKI, C., Generierung von Spezifikationen betrieblicher Anwendungssysteme auf der Basis von Geschäftsprozeßmodellen, Shaker, Aachen 1997. [13] SCHEER, A.-W., Architektur integrierter Informationssysteme - Grundlage der Unternehmensmodellierung, Springer, Berlin 1992. [14] SIEDERSLEBEN, J., SOA revisited: Komponentenorientierung bei Systemlandschaften. In: WIRTSCHAFTSINFORMATIK Sonderheft 2007, S. 110-117, 2007. [15] SINZ, E. J., SOA und die bewährten methodischen Grundlagen der Entwicklung betrieblicher IT-Systeme. In: WIRTSCHAFTSINFORMATIK 50(1), S. 70-72, 2008. [16] THOMAS, O., LEYKING, K., DREIFUS, F., FELLMANN, M., Serviceorientierte Architekturen: Gestaltung, Konfiguration und Ausführung von Geschäftsprozessen. In: Loos, P. (Hrsg.): Veröffentlichungen des Instituts für Wirtschaftsinformatik, Nr. 189, Saarbrücken : Universität des Saarlandes, 2007. [17] WAHLI, U., ACKERMAN, L., DI BARI, A. und HODGKINSON, G., Building SOA Solutions Using the Rational SDP, IBM Redbooks Publication, IBM International Technical Support Organization 2007. 98 EMPIRISCHE VALIDIERUNG VON INTEGRATIONSTYPEN AM BEISPIEL UNTERNEHMENSÜBERGREIFENDER INTEGRATION Stephan Aier, Bettina Gleichauf, Christian Riege, Jan Saat1 Kurzfassung Integration ist eines der vielschichtigsten Themen der Wirtschaftsinformatik. Es adressiert so unterschiedliche Herausforderungen wie die Geschäftsprozessintegration, die Integration von Applikationen oder die gegenseitige Ausrichtung von fachlichen und informationstechnischen Strukturen. Für eine adäquate methodische Unterstützung von Integrationsprojekten müssen diese Projekte geeignet kategorisiert werden. Aufgrund der Vielschichtigkeit möglicher Projektkategorisierungen erscheint es sinnvoll, fundamentale Integrationstypen zu definieren und methodisch zu unterstützen. In diesem Beitrag wird eine vorgeschlagene metamodellbasierte Taxonomie fundamentaler Integrationstypen empirisch überprüft. 1. Einleitung Integration wird oft als das Ur- und Hauptthema der Wirtschaftsinformatik angesehen [23, 29]. Mergers & Acquisitions [15], Enterprise Application Integration (EAI) [13], Datenintegration [10], unternehmensübergreifende B2B-Prozessintegration [3] oder die Integration von fachlichen Strukturen und deren informationstechnische Unterstützung im Rahmen des Business/IT Alignment [19] sind nur einige Beispiele für die sehr unterschiedlichen Erscheinungsformen von Integrationsprojekten. In einer phänomenologischen Betrachtung lassen sich daraus beispielsweise Integrationsdimensionen wie Integrationsform (verschmelzende vs. verknüpfende Integration), Integrationsreichweite (bereichsweite, unternehmensweite vs. unternehmensübergreifende Integration), Integrationsobjekt (Daten-, Funktions- vs. Prozessintegration) oder Integrationsrichtung (vertikale vs. horizontale Integration) unterscheiden [11, 21]. Eine solche phänomenologische Betrachtung bleibt jedoch immer unvollständig und eignet sich darum nur unzureichend, eine handhabbare Anzahl fundamentaler Integrationstypen zu definieren und sie methodisch zu unterstützen. Die Identifikation von abgrenzbaren Integrationstypen ist jedoch von Bedeutung, da es auf Grund der Heterogenität von Integrationsprojekten keine „one-size-fits-all“-Methode gibt, sondern im Sinne des Situational Method Engineering [2, 9, 16, 28] jeweils geeigneter situativer Methoden bedarf. Die fundamentalen Integrationstypen können die Basis für Methodenfragmente bilden, aus welchen situative Methoden erstellt werden können. Winter [31] hat darum vorgeschlagen, Integrationstypen nicht phänomenologisch, sondern auf Basis abstrakter Zusammenhänge in Unternehmensarchitektur-Metamodellen zu definieren. Ziel dieses Beitrags ist es, anhand verschiedener Integrationsauf1 Universität St. Gallen, Müller-Friedberg-Strasse 8, CH-9000 St. Gallen 99 gaben die vorgeschlagenen Integrationstypen am Beispiel der unternehmensübergreifenden Integration empirisch zu überprüfen. Im Folgenden werden dazu bestehende Arbeiten im Bereich Integration analysiert, um daraus die hier adressierte Forschungslücke abzuleiten und die von Winter vorgeschlagenen Integrationstypen vorzustellen (Abschnitt 2). Anschließend werden in Abschnitt 3 das Vorgehen sowie die Befunde der empirischen Untersuchung vorgestellt. Abschnitt 4 diskutiert die Ergebnisse der Untersuchung sowie die sich daraus ergebenden Implikationen. In Abschnitt 5 erfolgen eine Zusammenfassung sowie der Ausblick auf den weiteren Forschungsbedarf. 2. Theoretische Grundlagen In diesem Abschnitt wird ein Überblick über das vielschichtige Verständnis von Integration in der Wirtschaftsinformatik gegeben. Dabei werden insbesondere die in der Literatur vorgeschlagenen Merkmale zur Strukturierung von Integrationsaufgaben vorgestellt. Anschließend wird eine metamodellbasierte Perspektive zur Bildung von Integrationstypen diskutiert. 2.1. Merkmalsbasierte Differenzierung von Integration Einige Autoren diskutieren unter Integration primär Konstruktionsaufgaben, die inner- oder überbetriebliche Geschäftsprozesse durch Kopplungsmechanismen der Anwendungssysteme der beteiligten Unternehmen unterstützen [13, 18, 24]. Hierbei steht die Verbindung von Applikationen mittels Kopplungsmechanismen, insbesondere verschiedener Arten von Enterprise Application Integration (EAI)-Mechanismen und Middleware, im Fokus. Auch erwähnt werden Integrationsaufgaben in anderen Bereichen wie z. B. der Geschäftsprozessgestaltung [3, 25]. In der Organisationslehre wird in diesem Zusammenhang die Aufgaben- und Prozessintegration diskutiert, d. h. die Zusammenfassung getrennter Arbeitsschritte, so dass Verantwortlichkeiten dediziert gestaltet werden können [5]. Im Zusammenhang mit der strategischen Ausrichtung einer Unternehmung wird der Integrationsbegriff im Kontext mit der überbetrieblichen, elektronischen Kooperation als Enabler für neue Geschäftsmodelle verwendet [12, 22]. Rosemann [23] unterscheidet als Aufgaben der Integration Verbinden und Vereinen. Wie diese Aufgaben weiter strukturiert werden können, wird in der Literatur primär merkmalsbasiert analysiert. Integrationsmerkmale können nach Linß und Mertens in Integrationsgegenstand (Daten, Funktionen, Programme, Prozesse, Methoden), Integrationsrichtung (vertikal, horizontal) und Integrationsreichweite (innerbetrieblich, zwischenbetrieblich) unterschieden werden [17, 21]. Mertens [21] führt weiterhin den Automationsgrad (Vollautomation, Teilautomation) an. Jung beschreibt darüber hinaus weitere Integrationsmerkmale, wie etwa den Transaktionstyp (lesend, lesend und schreibend etc.) oder die Materialisierung (virtuell, materiell) [11]. Zur Strukturierung der Integrationsaufgaben existieren verschiedene Ordnungshilfen zu oben beschriebenen Integrationsmerkmalen. So wird verschiedenen Anwendungsbereichen von Integrationsaufgaben durch die Einführung von Integrationsperspektiven (technisch/betriebswirtschaftlich) [11] bzw. Integrationssichten (Prozess-, Desktop- und Systemintegration) [29] Rechnung getragen. Einen Ansatz zur Unterscheidung von Datenintegrationsarchitekturtypen mit einem Ordnungsrahmen liefert Jung. Hierbei werden Integrationsarchitekturen merkmalbasiert, mithilfe eines morphologischen Kastens differenziert [11]. 100 2.2. Metamodellbasierte Differenzierung von Integration Die Konstruktion problemadäquater, situativer Methoden für die Durchführung von Integrationsprojekten erfordert eine grundlegende Kenntnis über die Struktur der zu bewältigenden Integrationsaufgaben. Bisherige Ansätze zur Beschreibung und Abgrenzung der Integrationsaufgaben erfolgen jedoch ausschließlich merkmalsbasiert. Eine derartige, phänomenologische Betrachtung von Integration beinhaltet immer bereits relevante Kontingenzfaktoren, wie etwa die Unternehmensgröße (bei Middleware- und EAI-Diskussionen) oder Faktoren der Unternehmenskultur (bei zwischenbetrieblicher Integration). Darum können grundlegende Integrationstypen auf diese Weise nicht sicher bestimmt werden. Um diesem Defizit zu begegnen, schlägt Winter [31] eine abstraktere Betrachtung von Integrationstypen vor. Hierbei werden mögliche Integrationsoperationen auf einem Metamodell der Unternehmensarchitektur analysiert. Ein solches Metamodell beschreibt die Artefakttypen und deren Beziehungen in einer Unternehmensarchitektur und kann als Strukturierungshilfe für Integrationsaufgaben herangezogen werden. Die Instanziierung der Artefakttypen in einem Unternehmensarchitekturmodell stellt die Basis für die systematische Transformation (etwa durch Integration) der Unternehmensarchitektur dar [1, 32]. Abbildung 1 gibt einen Überblick über die metamodellbasierte Unterscheidung fundamentaler Integrationstypen nach Winter [31], die nachfolgend weiter beschrieben werden. Artefakttyp A Artefakttyp A Artefakttyp B Artefakttyp B IntegrationsArtefakttyp Integrationstyp: Ableitung Integrationstyp: Alignment Artefakttyp A Artefakttyp A Artefakttyp B Artefakttyp A neu Integrationstyp:Bindung Legende: Integrationstyp:Vereinigung Modifikation durch Integration Abbildung 1: Fundamentale Integrationstypen nach Winter [31] Der Integrationstyp Alignment beschreibt das gegenseitige aneinander Ausrichten unterschiedlicher und sich unabhängig voneinander verändernder Artefakttypen. Das klassische Alignment-Beispiel ist das gegenseitige aneinander Ausrichten fachlicher Strukturen, wie Geschäftsprozessen, und der korrespondierenden IT-Architektur. Um eine lose Kopplung zu unterstützen werden AlignmentArtefakte gebildet. Hierdurch wird es möglich, dass lokale Änderungen nicht unmittelbar Auswirkung auf alle verbundenen Artefakte haben [6, 30]. Ein Beispiel für Alignment-Artefakttypen sind fachliche Services zur Verknüpfung von fachlichen Aktivitäten und IT-Funktionalitäten. Der zweite Integrationstyp in Abbildung 1 stellt die Integration als Ableitung von Artefakttypen im Metamodell dar. Artefakte eines Typs A werden aus den Artefakten eines Typs B abgeleitet, d. h. ihre Gestaltung beruht zu einem großen Teil auf Vorgaben, welche innerhalb eines anderen Artefakttyps gegeben sind. Die Ableitung der Aufbauorganisation aus der Ablauforganisation [5] oder 101 die Ableitung der Softwarearchitektur aus der Datenarchitektur [27] sind Beispiele für diesen Integrationstyp. Der dritte in Abbildung 1 vorgestellte Integrationstyp wird als Bindung bezeichnet. Werden verschiedene Instanzen des gleichen Artefakttyps miteinander gekoppelt, so entsteht im Metamodell eine rekursive Beziehung. Derartige Relationen entstehen etwa bei der Verbindung von Softwarekomponenten über Middleware oder EAI-Tools, die wiederum selbst Softwarekomponenten sind [18, 23, 24]. Der vierte vorgeschlagene fundamentale Integrationstyp wird als Vereinigung charakterisiert. Integration im Sinne von Vereinigung liegt dann vor, wenn das Metamodell nach der Durchführung von Integrationsprojekten weniger Artefakttypen aufweist als zuvor, z. B. wenn zwei (oder mehr) Artefakttypen zu einem verschmelzen [23]. Dies ist etwa bei Unternehmensübernahmen und Migrationsprojekten der Fall. Um Integrationsprojekte besser differenzieren und verstehen zu können und die zielgerichtete Konstruktion von Integrationsmethoden zu ermöglichen, werden die vorgeschlagenen fundamentalen Integrationstypen im Folgenden empirisch analysiert. Es existiert eine Vielzahl von Situationen, in denen sich die oben genannten Integrationstypen teilweise oder vollständig wiederfinden. Beispielhaft seien die Einführung von Standardsoftware, Outsourcing und Unternehmensinterne Reorganisation genannt. Die nachfolgend vorgestellte Untersuchung konzentriert sich auf die unternehmensübergreifenden Integration. Es zählt zu den ersten in der Wirtschaftsinformatik diskutierten Problemen [20] und ist durch seinen umfassenden Charakter noch immer hoch aktuell [26]. Unternehmensübergreifende Integration kann alle Architekturebenen und Artefakttypen der beteiligten Unternehmen betreffen. Beispielhafte Ausprägungen unternehmensübergreifender Integration sind Prozessintegration, etwa im Fall von Outsourcing oder die gemeinsame Nutzung von Applikationen durch verschiedene Organisationen. Die in diesem Zusammenhang anfallenden Integrationsaufgaben liefern somit eine breite Basis für die Untersuchung von Integrationstypen. 3. Empirische Analyse von Integrationsaufgaben Im Folgenden wird eine empirische Analyse vorgestellt, die auf Basis eines Fragebogens verschiedene Integrationsaufgaben bezüglich eines zugrunde liegenden latenten Zusammenhangs untersucht. Zunächst werden der Fragebogen sowie die durchgeführte Umfrage beschrieben. Anschließend wird mit Hilfe einer Faktorenanalyse der zugrunde liegende Zusammenhang expliziert. 3.1. Eigenschaften des Datensatzes Die empirische Analyse beruht auf einem Datensatz, welcher mittels Fragebogen im Rahmen einer 2008 durchgeführten Fachtagung zum Schwerpunkt Integration und Architektur erhoben wurde. Teilnehmende dieser Veranstaltung waren insbesondere Fach- und Führungskräfte aus den Bereichen Integrations- und Architekturmanagement. Der Fragebogen führt verschiedene Integrationsaufgaben an und fragt deren Relevanz in Bezug auf unternehmensübergreifende Integration ab. Dabei wird die Relevanz anhand einer 5-stufigen Likert-Skala erfasst. Im Vorfeld konnte der Fragebogen durch Experteninterviews sowie einen Pre-Test hinsichtlich seiner Verständlichkeit und Vollständigkeit geprüft werden. Insgesamt stehen 127 vollständig und konsistent ausgefüllte Fragebögen für die Analyse zur Verfügung. Die Zusammensetzung aus hauptsächlich deutschsprachigen Teilnehmern schränkt die Interpretation insofern nicht ein, als dass in erster Linie Einschätzungen von Großunternehmen (32% mit mehr als 5.000 Mitarbeitenden, sowie zusätzlich 28% mit mehr als 1.000 Mitarbeitenden) vorliegen, deren Integrationsprojekte ebenso international ausge102 richtet sind. Neben demografischen Angaben zum Unternehmenskontext wurde auch der Kenntnisstand der Teilnehmenden abgefragt. Hierbei gaben 79% der Befragten an, über mindestens fortgeschrittene Kenntnisse zur Thematik Integration zu verfügen. 3.2. Durchführung der Faktorenanalyse Um, wie in Abschnitt 2 vorgeschlagen, einen metamodellbasierten Zusammenhang zwischen verschiedenen Integrationsaufgaben zu identifizieren wird eine Faktorenanalyse durchgeführt. Die Faktorenanalyse extrahiert dafür eine geringe Anzahl wechselseitig unabhängiger Faktoren aus einer Vielzahl von Variablen. Sie unterstellt, dass es möglich ist, für eine Vielzahl von Variablen eines Datensatzes wenige gemeinsame Einflussgrößen (Faktoren) zu ermitteln. Mit Hilfe dieser Faktoren kann der Datensatz in komprimierter Form beschrieben werden. Ein Datensatz ist grundsätzlich geeignet für die Durchführung einer Faktorenanalyse, wenn er folgende Gütekriterien erfüllt: Zum einen wird das Kaiser-Meyer-Olkin-Kriterium (KMO), welches die Zusammengehörigkeit zwischen den Variablen ausdrückt, mit einem Wert größer 0,6 empfohlen [14]. Das KMO liegt in diesem Fall bei 0,841 und charakterisiert den Datensatz als „meritorious“ („verdienstvoll“). Ein weiteres Kriterium wird von der Anti-Image-Kovarianz abgeleitet. Diese Maßzahl bestimmt den Teil der Varianz, welcher nicht durch die verbleibenden Variablen im Datensatz erklärt wird. Nach Dziuban und Shirkey [4] sollte der Anteil nicht-diagonaler Elemente in der Anti-Image-KovarianzMatrix, welche ungleich Null sind, unter einem Anteil von 25% liegen. Dieser Wert beläuft sich im vorliegenden Datensatz auf 21,33% und bestätigt damit insgesamt die Eignung des Datensatzes für eine Faktorenanalyse. Basis für die Faktorenanalyse ist im vorliegenden Fall ein reduzierter Datensatz von 15 Variablen. Nicht berücksichtigt wurden Variablen, die im Fragebogen die Funktion von Kontrollfragen erfüllten. Mit Hilfe der Technik der Hauptkomponentenanalyse wurden vier Faktoren extrahiert, welche in Summe 61,44% der Varianz des gesamten Datensatzes erklären. Die resultierende Komponentenmatrix wurde mittels Varimax-Methode mit Kaiser-Normalisierung rotiert, um eine geeignete Interpretation der Ergebnisse zu unterstützen. In Tabelle 1 werden die analysierten Variablen (Items) bezüglich ihrer Ladung auf die extrahierten Faktoren dargestellt. Tabelle 1: Faktorladungen der ausgewählten 15 Items Item 1.1 Item 1.2 Item 1.3 Item 1.4 Item 2.1 Item 2.2 Item 2.3 Item 3.1 Item 3.2 Item 3.3 Item 3.4 Item 4.1 Item 4.2 Item 4.3 Item 4.4 Faktor 1 0,488 0,589 0,723 0,790 0,117 0,341 0,170 0,014 0,246 0,045 0,167 0,015 0,331 0,251 0,046 Faktor 2 0,347 0,252 0,122 0,139 0,784 0,684 0,705 0,147 0,024 0,363 -0,051 0,319 0,272 0,027 0,013 103 Faktor 3 -0,022 0,191 0,099 0,162 0,124 -0,064 0,259 0,690 0,797 0,590 0,629 0,322 0,133 0,235 0,196 Faktor 4 0,353 0,229 0,207 -0,038 0,161 0,047 0,090 0,170 0,088 0,206 0,331 0,677 0,665 0,810 0,836 Die Zuteilung einer Variablen zu einem Faktor erfolgt unter Berücksichtigung ihrer jeweiligen Faktorladungen. Eine Faktorladung spiegelt dabei die Korrelation zwischen der Variable und den extrahierten Faktoren wider. Eine Variable wird einem Faktor zugeordnet, wenn die Faktorladung den maximalen Wert für diese Variable repräsentiert und im Betrag den Wert 0,5 übersteigt [8]. Eine Ausnahme für diese Regel liegt bei Item 1.1 vor. Hier erfolgt die Zuordnung zu Faktor 1 auf Basis des höchsten Wertes der Faktorladungen. Um die Reliabilität der identifizierten Faktoren zu bestimmen wurde zusätzlich Cronbach’s Alpha als Maßzahl für die interne Konsistenz der Variablen eines Faktors berechnet. Es wird unterstellt, dass die Variablen eines Faktors ein gemeinsames latentes Konstrukt beschreiben, und aus diesem Grund stark miteinander korrelieren. Ein Wert größer als 0,7 gilt allgemein als hinreichend für die positive Beurteilung der Reliabilität [7]. Die Werte für diese Maßzahl betragen im vorliegenden Fall 0,8 (Faktor 1), 0,728 (Faktor 2), 0,739 (Faktor 3) sowie 0,871 (Faktor 4), sodass die interne Konsistenz der Faktoren im Ergebnis als hinreichend gut bewertet werden kann. 4. Ergebnisse der empirischen Analyse und ihre Implikationen Im Folgenden wird die Zuordnung von Integrationsaufgaben zu den jeweiligen Faktoren erläutert sowie eine Interpretation der extrahierten Faktoren vorgenommen. Im Anschluss wird aufgezeigt, inwiefern diese Faktoren den dargestellten fundamentalen Integrationstypen aus Abschnitt 2 entsprechen. 4.1. Interpretation der extrahierten Einflussfaktoren Für die im Fragebogen abgefragten Integrationsaufgaben können vier grundlegende Einflussfaktoren identifiziert werden. Insgesamt laden vier Variablen auf Faktor 1, wie in Tabelle 1 dargestellt. Tabelle 2: Variablen, die auf Faktor 1 laden Item 1.1 Die Integrationsaufgabe umfasst die Definition von Geschäftsfähigkeiten, um strategische Ziele und Geschäftsprozesse aneinander auszurichten. Item 1.2 Im Rahmen der Integrationsaufgabe werden Domänen definiert, um z. B. die Aufbauorganisation und die Anwendungssysteme zu verbinden. Item 1.3 Die Integrationsaufgabe umfasst das Alignment von fachlichen Funktionsblöcken und ITSystemen. Item 1.4 Im Rahmen der Integrationsaufgabe werden fachlichen Services gebildet, um Anwendungssysteme und Geschäftsentwicklung abzustimmen. Die zugeordneten Aufgaben beinhalten jeweils die Erstellung eines zusätzlichen Artefakttyps im Rahmen der Integration. So ist z. B. die Integration von fachlichen Funktionsblöcken und ITSystemen durch die Definition und wechselseitige Verankerung des zusätzlichen konzeptionellen Konstruktes der Applikation möglich. Ebenso kann die Verknüpfung von Geschäftsprozessen und strategischen Zielstellungen einer Organisation mit der Einführung eines weiteren konzeptionellen Konstruktes „Geschäftsfähigkeit“ umgesetzt werden. Ausschlaggebend ist für diesen Faktor die wechselseitig unabhängige Entwicklung und Bewirtschaftung der zu integrierenden Artefakte in einer Organisation, sodass eine Integration nicht mit Hilfe einer direkten Verknüpfung zwischen den Artefakttypen erfolgen sollte. Die drei Integrationsaufgaben, wie sie Faktor 2 abbildet (Tabelle 3), betonen insbesondere ein gerichtetes Verständnis von Integration. 104 Tabelle 3: Variablen, die auf Faktor 2 laden Item 2.1 Die Integrationsaufgabe umfasst die Ableitung von strategischen Kennzahlen aus den strategischen Zielen. Item 2.2 Bei der Integrationsaufgabe wird die Prozessgestaltung auf Basis des vorhandenen Leistungs- und Zielsystem durchgeführt. Item 2.3 Die Integrationsaufgabe beinhaltet die Definition einer Aufbauorganisation unter Berücksichtigung der Ablauforganisation. So wird z. B. die Prozessgestaltung derart durchgeführt, dass in erster Linie Vorgaben und Anforderungen aus dem Leistungs- und Zielsystem einer Organisation zu berücksichtigten sind. Analog richtet sich die Gestaltung der Aufbauorganisation maßgeblich nach den Vorgaben, welche die Ablauforganisation definiert. Charakteristisch für Faktor 2 ist somit die einseitige Abhängigkeit der zu integrierenden Artefakttypen: Bei der Integration leiten sich die Eigenschaften eines Artefakttyps direkt aus den Vorgaben des führenden Artefakttyps ab. Tabelle 4: Variablen, die auf Faktor 3 laden Item 3.1 Bei der Integrationsaufgabe werden Geschäftsprozesse über ein Workflowmanagementsystem verknüpft. Item 3.2 Die Integrationsaufgabe umfasst die Einführung einer Middleware, um Anwendungssysteme miteinander zu verbinden. Item 3.3 Die Integrationsaufgabe beinhaltet die Verbindung von analytischen und operativen Systemen über ein Data Warehouse. Item 3.4 Die Integrationsaufgabe umfasst die Einführung von Softwarekomponenten, die Softwaremodule zusammenfassen. Tabelle 4 zeigt die vier Variablen, die auf Faktor 3 laden. Dieser Faktor umfasst Integrationsaufgaben, die den Zweck verfolgen, den Schnittstellenwildwuchs bspw. innerhalb einer Anwendungslandschaft oder einer Prozesslandschaft zu minimieren. Charakteristisch für die Integration ist dabei, dass die Kopplung zwischen z. B. analytischen und operativen Systemen, welche als m:nSchnittstelle realisiert ist, durch eine n:1-Kopplung der Systeme abgelöst wird. Es wird somit die Komplexität bei der Verknüpfung von Artefakten gleichen Typs adressiert und z. B. durch Einführung von Bus-Konzepten eine Entflechtung und effizientere Schnittstellenwartung erzielt. Tabelle 5: Variablen, die auf Faktor 4 laden Item 4.1 Im Rahmen der Integrationsaufgabe erfolgt die Zusammenlegung von verschiedenen Organisationsbereichen. Item 4.2 Die Integrationsaufgabe beinhaltet die Konsolidierung von Geschäftsprozessen. Item 4.3 Die Integrationsaufgabe beinhaltet die Zusammenführung von Anwendungssystemen. Item 4.4 Die Integrationsaufgabe umfasst die Konsolidierung der IT-Infrastruktur. Die vier Integrationsaufgaben, die mit Hilfe von Faktor 4 gemeinsam erklärt werden können, beschreiben stets eine Vereinigung von Artefakttypen (Tabelle 5). Im Zuge eines Integrationsprojektes werden beispielsweise Kundenstämme zusammengelegt oder IT-Landschaften konsolidiert. Faktor 4 umfasst aber auch die Konsolidierung von systemnahen Entitäten, wie z. B. Anwendungssystemen oder der gesamten IT-Infrastruktur. Im Gegensatz zu den bereits beschriebenen Faktoren werden bei den Integrationsaufgaben dieses Faktors keine neuen Verbindungen oder Objekte geschaffen, sondern vorhandene Objekte miteinander vereint. 105 4.2 Zuordnung zu fundamentalen Integrationstypen In Abschnitt 2 wurde ein Ansatz zur Unterscheidung fundamentaler Integrationstypen vorgestellt, der auf der jeweiligen Integrationsoperation im Metamodell basiert. Zwischen den in der empirischen Analyse identifizierten Faktoren und den vorgeschlagenen Integrationstypen lässt sich unter Berücksichtigung der jeweils zugehörigen Integrationsaufgaben ein Zusammenhang erkennen, der im Folgenden beschrieben und interpretiert wird (Tabelle 6). Tabelle 6: Zuordnung der Faktoren zu metamodellbasierten Integrationstypen Faktor Faktor 1 Faktor 2 Faktor 3 Faktor 4 Integrationstyp Alignment Ableitung Bindung Vereinigung Faktor 1 beschreibt Integrationsaufgaben, die eine gegenseitige Ausrichtung verschiedener Artefakttypen beinhalten, welche autonomen Änderungen unterworfen sind. Auf Basis eines Metamodells empfiehlt sich hierfür die Einführung zusätzlicher Alignment-Artefakte, um die originären Artefakttypen aneinander auszurichten, ohne ihre unabhängige Entwicklung zu beeinflussen. Faktor 1 beschreibt somit ein Alignment unterschiedlicher Metamodellobjekte und kann dem in Abschnitt 2 vorgestellten Integrationstyp Alignment zugeordnet werden. Charakteristisch für Faktor 2 ist die einseitige Abhängigkeit der zu integrierenden Artefakttypen. Auf Basis des zugrunde gelegten Metamodellverständnisses wird eine solche direkte, gerichtete Verknüpfung zwischen zwei Artefakttypen durch eine neue Verbindung oder Referenz auf einen anderen Artefakttyp realisiert. Eine derartige Modellierungsvorschrift für die Integrationsaufgabe entspricht der Grundaussage des nach Winter vorgestellten Integrationstyp Ableitung. Bezogen auf die Abbildung in einem Metamodell steht bei Faktor 3 die Verknüpfung zwischen Instanzen eines Artefakttyps im Vordergrund. Dies erfolgt entweder durch eine Punkt-zu-Punkt-Verbindung oder durch eine effizientere Huband-Spoke Architektur und wird durch eine rekursive Beziehung von Metamodell-Elementen abgebildet. Der metamodellbasierte Integrationstyp Bindung beschreibt diese Abbildungsvorschrift und kann durch diesen Faktor erklärt werden. Mit Faktor 4 werden Integrationsaufgaben gemeinsam erklärt, die eine Reduktion von Artefakttypen im Metamodell bedingen: Durch die Verschmelzung von zwei verschiedenen Artefakttypen entsteht ein neuer Typ. Faktor 4 beschreibt somit die Grundidee des Integrationstyps Vereinigung, der diese Metamodelländerungen vorsieht. 5. Zusammenfassung und weiterer Forschungsbedarf Im vorliegenden Beitrag wurde eine empirische Analyse mit dem Ziel durchgeführt, die metamodellbasierte Definition grundlegender Integrationstypen anhand von Integrationsaufgaben empirisch zu überprüfen. Mit Hilfe der Faktorenanalyse konnte gezeigt werden, dass sich das Verständnis zu unterschiedlichen Integrationsaufgaben vor dem Hintergrund unternehmensübergreifender Integration durch vier latente Konstrukte beschreiben lässt. Eine Interpretation der jeweils beschriebenen Integrationsaufgaben erlaubt es, diese Konstrukte den in Abschnitt 2 beschriebenen Grundaussagen der vorgeschlagenen Integrationstypen zuzuordnen. Es kann jeweils eine unterschiedliche Integrationsoperation im Metamodell als Kriterium zur Abgrenzung von Integrationsaufgaben und damit zur differenzierten Beschreibung von Integration herangezogen werden. Dabei bleibt zu berücksichtigen, dass im Beitrag gewonnene Erkenntnisse zur metamodellbasierten Definition von Integrationstypen zunächst auf die Situation der unternehmensübergreifenden Integration beschränkt sind. Inwiefern sich die genannten Integrationstypen ähnlich deutlich auch in anderen Situationen wiederfinden, ist Gegenstand weiterer Untersuchungen. 106 Die fundamentalen Integrationstypen können dazu beitragen, die Heterogenität von Integrationsprojekten zu erfassen und zu strukturieren. Somit kann die Entwicklung situativer Methoden für das Integrationsmanagement ebenfalls strukturiert erfolgen. Der Anspruch auf Fundamentalität der vorgestellten Integrationstypen und der damit verbundenen Unabhängigkeit von nicht endlich bestimmbaren merkmalbasierten Ausprägungen des Phänomens Integration muss einer kritischen Prüfung unterzogen werden, da das verwendete Metamodell die exakte Übertragbarkeit der Integrationstypen einschränkt. Wird ein grundsätzlich anderes Metamodell zugrunde gelegt, so ist es u. U. notwendig, die gewählte Abbildungsvorschrift für eine Typisierung zu modifizieren. Für eine wissenschaftliche Auseinandersetzung stellt dies erste Implikationen für die Konstruktion von Methoden dar. Mit Bezug auf eine situative Methodenkonstruktion ist es notwendig, neben fundamentalen Integrationstypen auch die relevanten Kontextfaktoren, z. B. fundamental unterschiedliche, explizite oder implizite Metamodelle, im Rahmen von Integrationsprojekten zu erfassen. Für die Übertragbarkeit der Ergebnisse in die Praxis ist zu überprüfen, ob die Unterscheidung von Integration als Projektaufgabe gegenüber Integration als Daueraufgabe einen Einfluss auf die Abgrenzung der Integrationstypen und deren Anwendung in Integrationsmethoden hat. Um den Einsatz in der Praxis zu ermöglichen, ist die Definition und praktische Evaluation der Methodenfragmente und schließlich auch der Methoden auf Basis der Integrationstypen notwendig. 6. Literatur [1] AIER, S., RIEGE, C., WINTER, R., Unternehmensarchitektur - Literaturüberblick und Stand der Praxis, in: Wirtschaftsinformatik, 50 (4), 2008, S. 292-304. [2] BUCHER, T., KLESSE, M., KURPJUWEIT, S., WINTER, R.: Situational Method Engineering - On the Differentiation of "Context" and "Project Type", in: Ralyté, J., Brinkkemper, S., Henderson-Sellers, B. (Hrsg.): Proceedings of the IFIP WG8.1 Working Conference on Situational Method Engineering - Fundamentals and Experiences (ME07), Vol. 244, Springer, Boston 2007, S. 33-48. [3] DIETRICH, J., Nutzung von Modellierungssprachen und -methodologien standardisierter B2B-Architekturen für die Integration unternehmensinterner Geschäftsprozesse, Berlin 2008. [4] DZIUBAN, C. D., SHIRKEY, E. C., When is a Correlation Matrix Appropriate for Factor Analysis?, in: Psychological Bulletin, 81 (6), 1974, S. 358-361. [5] GAITANIDES, M., Prozessorganisation - Entwicklung, Ansätze und Programme des Managements von Geschäftsprozessen, 2. Auflage, München 2007. [6] GLASSMAN, R. B., Persistence and loose coupling in living systems, in: Behavioral Science, 18 (2), 1973, S. 8398. [7] HAIR JR., J. F., BLACK, B., BABIN, B., Multivariate Data Analysis, 6. Auflage, Australia et al. 2006. [8] HÄRDLE, W., SIMAR, L., Applied Multivariate Statistical Analysis, Berlin 2003. [9] HARMSEN, A. F., BRINKKEMPER, S., OEI, H.: Situational Method Engineering for Information System Project Approaches, in: Verrijn-Stuart, A.A., Olle, T.W. (Hrsg.): Proceedings of the IFIP 8.1 Working Conference on Methods and Associated Tools for the Information Systems Life Cycle, North-Holland, Amsterdam 1994, S. 169-194. [10] HEINE, P., Unternehmensweite Datenintegration, Stuttgart, Leipzig 1999. [11] JUNG, R., Architekturen zur Datenintegration. Gestaltungsempfehlungen auf der Basis fachkonzeptueller Anforderungen, Wiesbaden 2006. [12] KAGERMANN, H., ÖSTERLE, H., Geschäftsmodelle 2010 - Wie CEOs Unternehmen transformieren, Frankfurt 2006. [13] KAIB, M., Enterprise Application Integration - Grundlagen, Integrationsprodukte, Anwendungsbeispiele, Wiesbaden 2002. [14] KAISER, H. F., RICE, J., Little Jiffy, Mark Iv, in: Educational and Psychological Measurement, 34 (1), 1974, S. 111-117. 107 [15] KROMER, G., STUCKY, W., Die Integration von Informationsverarbeitungsressourcen im Rahmen von Mergers & Acquisitions, in: Wirtschaftsinformatik, 44 (6), 2002, S. 523-533. [16] KUMAR, K., WELKE, R. J., Methodology Engineering - A Proposal for Situation-specific Methodology Construction, in: Cotterman, W., Senn, J.A. (Hrsg.): Challenges and Strategies for Research in Systems Development, New York 1992, S. 257-269. [17] LINß, H., Integrationsabhängige Nutzeffekte der Informationsverarbeitung: Vorgehensmodell und empirische Ergebnisse, Wiesbaden 1995. [18] LINTHICUM, D. S., B2B Application Integration: e-Business-Enable Your Enterprise, Boston 2001. [19] LUFTMAN, J. N., MCLEAN, E. R., Key Issues for IT Executives, in: MIS Quarterly Executive, 3 (2), 2004, S. 89-104. [20] MERTENS, P., Die zwischenbetriebliche Kooperation und Integration bei der automatisierten Datenverarbeitung, Meisenheim am Glan 1966. [21] MERTENS, P., Integrierte Informationsverarbeitung 1, 16. Auflage, Wiesbaden 2007. [22] PICOT, A., REICHWALD, R., WIGAND, R. T., Die grenzenlose Unternehmung: Information, Organisation und Management, 5. Auflage, Wiesbaden 2003. [23] ROSEMANN, M., Gegenstand und Aufgaben des Integrationsmanagements, in: Scheer, A.W., Rosemann, M., Schütte, R. (Hrsg.): Integrationsmanagement, Münster 1999, S. 5-18. [24] SCHISSLER, M., MANTEL, S., FERSTL, O. K., SINZ, E. J., Kopplungsarchitekturen zur überbetrieblichen Integration von Anwendungssystemen und ihre Realisierung mit SAP/R3, in: Wirtschaftsinformatik, 44 (5), 2002, S. 459-468. [25] SCHISSLER, M., ZELLER, T., MANTEL, S., Überbetriebliche Integration von Anwendungssystemen: Klassifikation von Integrationsproblemen und -lösungen, in: Bartmann, D., Mertens, P., Sinz, E.J. (Hrsg.): Überbetriebliche Integration von Anwendungssystemen - FORWIN-Tagung 2004, Aachen 2004, S. 1-20. [26] SPERLING, S., Konzeption einer Methode zum Integrationsmanagement bei Unternehmenszusammenschlüssen auf der Basis von multiperspektivischen Unternehmensmodellen, Berlin 2007. [27] STAHL, T., VÖLTER, M., Modellgetriebene Softwareentwicklung. Techniken, Engineering, Management, 1. Auflage, Heidelberg 2005. [28] VAN SLOOTEN, K., HODES, B.: Characterizing IS Development Projects, in: Brinkkemper, S., Lytinnen, K., Welke, R.J. (Hrsg.): Proceedings of the IFIP TC8, WG8.1/8.2 Working Conference on Method Engineering, Springer, Berlin et al. 1996, S. 29-44. [29] VOGLER, P., Prozess- und Systemintegration - Evolutionäre Weiterentwicklung bestehender Informationssysteme mit Hilfe von Enterprise Application Integration, Wiesbaden 2006. [30] WEICK, K. E., Educational Organizations as Loosely Coupled Systems, in: Administrative Science Quarterly, 21 (1), 1976, S. 1-19. [31] WINTER, R.: Metamodellbasierte Taxonomie von Integrationsprojekten, Institut für Wirtschaftsinformatik, Universität St. Gallen, St. Gallen 2008. [32] WINTER, R., BUCHER, T., FISCHER, R., KURPJUWEIT, S., Analysis and Application Scenarios of Enterprise Architecture - An Exploratory Study, in: Journal of Enterprise Architecture, 3 (3), 2007, S. 33-43. 108 SITUATIVE METHODENKONSTRUKTION FÜR DIE PROJEKTBEWERTUNG AUS UNTERNEHMENSARCHITEKTURPERSPEKTIVE Stephan Aier, Christian Riege1, Marten Schönherr, Udo Bub2 Kurzfassung Unternehmensarchitekturmodelle können neben der reinen Dokumentation in sehr unterschiedlichen Anwendungsszenarien für verschiedene Stakeholder nutzenstiftend angewendet werden. Diese Modelle sind oft die einzige Quelle einer umfassenden aber hinreichend groben Dokumentation der Zusammenhänge in einem Unternehmen angefangen von der strategischen Positionierung bis zur technischen Infrastruktur. In diesem Beitrag werden am Beispiel der Innovationsprojekte der Deutschen Telekom Laboratories empirisch Projekttypen und jeweils geeignete Bewertungsaktivitäten basierend auf Analysen der Unternehmensarchitektur entwickelt. Diese Ergebnisse sind die Grundlage für die Entwicklung einer situativen Methode zur Projektbewertung auf Basis der Unternehmensarchitektur. 1. Herausforderungen bei Innovationsprojekten im Telekommunikationssektor Der Begriff Unternehmensarchitektur findet in der Wissenschaft sowie in der Praxis eine hohe Verbreitung und Akzeptanz [15, 19, 24]. Im Allgemeinen wird an dieser Stelle die Modellierung und Gestaltung der Unternehmensarchitektur diskutiert. Darüber hinaus können Unternehmensarchitekturmodelle in weiteren Szenarien [16] für eine breite Gruppe von Stakeholdern [14] Nutzen stiften. Dieser Beitrag untersucht am Beispiel der Deutschen Telekom Laboratories (T-Labs), wie Unternehmensarchitekturmodelle für die Bewertung von Innovationsprojekten genutzt werden können. Die T-Labs bündeln einen Großteil der Investitionen in Forschung und Innovation der Deutschen Telekom. Die Ergebnisse dieser Innovationsprojekte sollen sich an relevanten Produkten für die Deutsche Telekom orientieren. Der Prozess zur Filterung von Ideen und die Entscheidungsfindung, ob Ideen in Innovationsprojekte überführt werden, werden über drei so genannte Gates abgebildet, in denen schrittweise Aspekte wie Machbarkeit, Budget, Konsortialpartner und Zeitdauer detailliert werden. Die zu erwartenden Projektergebnisse werden mit den Stakeholdern aus den Geschäftseinheiten der Deutschen Telekom abgestimmt. Nach drei Jahren und mehr als 100 Innovationsprojekten wird zurzeit der Innovationsprozess bei den T-Labs kritisch überprüft. Vor allem wird dabei die Produktnähe in Form nicht-funktionaler Eigenschaften der Projektergebnisse betrachtet. Für die 1 Universität 2 Deutsche St. Gallen, Müller-Friedberg-Strasse 8, CH-9000 St. Gallen Telekom Laboratories, Ernst-Reuter-Platz 7, D-10587 Berlin 109 Überführung von Innovationen in Produkte ist es notwendig, die Anforderungen des anvisierten Produktumfeldes zu erfassen, in die Entwicklung einzubeziehen und begleitend zu prüfen [8]. Auf dieser Grundlage formulieren wir folgende Forschungsfrage: Wie kann die Bewertung von Innovationsprojekten methodisch unterstützt und dabei explizit die Heterogenität eines Projektportofolios sowie die Breite nicht-funktionaler Bewertungsaspekte berücksichtigt werden. Die Anforderung, ein heterogenes Projektportfolio insbesondere hinsichtlich nicht-funktionaler Eigenschaften, wie Produktrelevanz im Konzern zu bewerten, wird adressiert, indem die Unternehmensarchitektur als Bewertungsgrundlage vorgeschlagen wird. Es ist dabei nicht zweckmäßig, für jedes Innovationsprojekt Detailanforderungen über alle Ebenen einer Unternehmensarchitektur hinweg zu erheben, sondern entsprechend der Projekteigenschaften eine dedizierte Auswahl an Anforderungen zu nutzen. Entsprechend wird das Konzept der situativen Methodenkonstruktion herangezogen, um situationsbezogen die Bewertung unterschiedlicher Innovationsprojekte entlang der Unternehmensarchitektur zu ermöglichen. Dazu führt Kapitel 2 in die konzeptionellen Grundlagen zur situativen Methodenkonstruktion sowie zur Unternehmensarchitektur als Grundlage einer ganzheitlichen Bewertung ein. Kapitel 3 schlägt eine Segmentierung des Projektportfolios der T-Labs vor. Darüber hinaus werden für die identifizierten Projekttypen relevante Bewertungen aus der Perspektive der Unternehmensarchitektur vorgestellt und zu einem Vorgehensmodell im Sinne der situativen Methode verknüpft. Kapitel 4 beschreibt die Lerneffekte und zeigt den weiteren Forschungsbedarf auf. 2. Konzeptionelle Grundlagen Im Folgenden wird zunächst in das hier zugrunde liegende Verständnis der Unternehmensarchitektur eingeführt. Darauf aufbauend wird das Konzept der situativen Methodenkonstruktion vorgestellt und sein Nutzen in diesem Beitrag dargelegt. 2.1. Unternehmensarchitekturmodell als Bewertungsperspektive Gemäß ANSI/IEEE Std 1471-2000 ist Architektur definiert als ”the fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution” [11]. Die Unternehmensarchitektur stellt die fundamentale Strukturierung einer Organisation dar. Dahinter steht die Idee, die wichtigsten Gestaltungsobjekte eines Unternehmens und deren Beziehungen in Form von Modellen abzubilden. Die Modellbildung verfolgt das Ziel, auf einer aggregierten Ebene die gegenseitigen Abhängigkeiten der Gestaltungsobjekte eines Unternehmens zu beschreiben. Die Bandbreite der Gestaltungsobjekte reicht dabei von strategischen Aspekten, wie sie sich in der Positionierung zu Kunden, Lieferanten und Mitbewerbern widerspiegelt, über Gestaltungsobjekte der Aufbau- und Ablauforganisation bis hin zu Elementen der Daten- und Softwarearchitektur sowie der technischen Infrastruktur [23]. Aufbauend auf der Dokumentation der Strukturen einer Unternehmung, können Unternehmensarchitekturmodelle nach Niemann [16] in sehr unterschiedlichen Szenarien genutzt werden, in denen die wechselseitigen Abhängigkeiten der Gestaltungsobjekte von Bedeutung sind [22]. Ein mögliches Szenario ist die Bewertung und Steuerung von Innovationsprojekten [2]. Werden Ergebnisse von Innovationsprojekten in eine Produktivumgebung überführt, so tangiert dies i. d. R. eine Vielzahl von Gestaltungsobjekten. Die Unternehmensarchitektur ist oft die einzige, konsistente Dokumentation der betroffenen Gestaltungsobjekte sowie deren Abhängigkeiten. Sie stellt somit ein geeignetes Informationsverzeichnis dar welches sich als Basis für die Projektbewertung eignet. Auf dieser Basis können bereits im Projektverlauf nicht-funktionale Aspekte (z. B. Zielarchitekturkonformität) geprüft werden oder Impact-Analysen für alle betroffenen Architekturebenen durchgeführt werden. Aus diesen Analysen können dann weitere notwendige Initiativen außerhalb des Projektes (z. B. Erstellung notwendiger Infrastrukturen) sowie innerhalb des Projektes (z. B. Auswahl 110 von fachlichen oder technischen Standards für die Kompatibilität mit der Zielarchitektur) abgeleitet werden. Während bestehende Arbeiten vor allem auf die Bewertung der Unternehmensarchitektur selbst [12, 21] oder ausschließlich auf die IT-Architektur [18] fokussieren, widmen sich vor allem Foorthuis und Brinkkemper [9] der Beziehung zwischen Projektarchitekturen und der Unternehmensarchitektur. Sie gehen dabei nicht auf die Bewertung von Projekten ein, stellen jedoch auch fest, dass unterschiedliche Projekttypen eine differenzierte Betrachtung benötigen. 2.2. Situative Methoden zur Berücksichtigung unterschiedlicher Projekttypen In ihrer Eigenschaft als Informationsverzeichnis bilden Unternehmensarchitekturmodelle sehr breite Zusammenhänge ab und können darum für die methodisch gestützte Bewertung sehr unterschiedlicher Innovationsprojekte genutzt werden. In diesem Kontext kann es jedoch keine „onesize-fits-all“-Methode geben, welche alle denkbaren Ausprägungen von Projekteigenschaften gesamthaft abzudecken vermag. Abhängig vom jeweiligen Innovationsprojekt bedarf es einer spezifisch adaptierten Methode. Ansätze wie dieser werden unter dem Begriff der situativen Methodenkonstruktion diskutiert [4, 6, 10, 13, 20]. Wesentliche Bestandteile einer situativen Methode sind dabei eine Menge an Aktivitäten, sowie ein Vorgehensmodell, welches die Aktivitäten in sachlogische und zeitliche Ablauffolge setzt [6]. Unter Berücksichtigung des Gestaltungsgegenstandes Unternehmensarchitektur stellt die Methode die systematische Anleitung zur Analyse und Transformation der Unternehmensarchitektur oder Teile derselben dar. Die Anpassbarkeit bezüglich unterschiedlicher Projekteigenschaften wird realisiert, indem die Relevanz einzelner Aktivitäten für bestimmte Situationen angeführt wird. Für die Beschreibung einer Situation werden Projekttypen unterschieden und zusätzlich in ihren jeweiligen Kontexten beschrieben [6]. Ein Projekttyp konstituiert sich durch eine Reihe gleicher oder ähnlicher Eigenschaften der diesem Typ zugeordneten Projekte. Eine situative Methode kann dann für eine spezifische Situation, und damit für einen Projekttyp adaptiert werden. Die Erfahrungen aus der Methodenanwendung sowie aus der Methodenkonstruktion sollten nach dem Projekt reflektiert und für die spätere Nutzung dokumentiert werden [4]. Bucher et al. weisen darauf hin, dass nicht nur Projekttypen die effektive und effiziente Anwendung einer Methode wesentlich beeinflussen, sondern auch nicht beeinflussbare Kontingenzfaktoren zu berücksichtigen sind. Während es ähnliche Ansätze im Business Process Management [7] oder in der prozessorientierten Informationslogistik [5] gibt, existieren keine Arbeiten zur Situativität in der Bewertung und Steuerung von Innovationsprojekten. 3. Konstruktion der Methode Der vorgeschlagene Prozess für die situative Methodenkonstruktion unterscheidet grundlegend drei Phasen [4]: (a) Beschreibung des Projektes, (b) Definition der Methodenfragmente und (c) Konstruktion der situativen Methode. Im folgenden Abschnitt wird dieser Prozess für die Teilbereiche (a) Identifikation der Projekttypen (Kapitel 3.1), (b) Herleitung der Aktivitäten (Kapitel 3.2) und (c) Verknüpfung der Aktivitäten in einem Vorgehensmodell (Kapitel 3.3) am Beispiel der Innovationsprojekte der T-Labs umgesetzt. Im Ergebnis stehen damit exemplarische Aktivitäten zur Bewertung sowie ein situatives Vorgehensmodell, als wesentliche Bestandteile einer situativen Methode zur Bewertung von Innovationsprojekten, zur Verfügung. 3.1. Identifikation der Projekttypen durch Klassifikation des T-Labs Projektportfolios Die Beschreibung eines Innovationsprojektes erfolgt anhand von Eigenschaften, welche für die folgende Bewertung aus Unternehmensarchitekturperspektive relevant sind. Dazu ist es zunächst notwendig, das Projektportfolio unter Berücksichtigung dieser Eigenschaften zu segmentieren. Die Gruppenbildung ermöglicht es, gemäß ihrer Eigenschaften, homogene Projekte zusammenzufassen, 111 und die methodische Unterstützung einer Projektbewertung aus Unternehmensarchitekturperspektive auf diese Gruppen und ihre Besonderheiten hin auszurichten. In einem ersten Schritt wurden dazu 116 Innovationsprojekte aus dem Projektportfolio der T-Labs anhand der in Tabelle 1 angeführten Eigenschaften erfasst. Dies beinhaltet sowohl laufende Projekte, deren Angaben sich aus den Projektplänen ergeben, als auch abgeschlossene Projekte, für welche das nachgelagerte Projektcontrolling die entsprechenden Daten zur Verfügung stellt. Tabelle 1. Raster zur Projektbeschreibung Projektmerkmal Beschreibung Projektlaufzeit Gemäß Projektantrag veranschlagte Gesamtdauer bis zu einer Produktisierung Projektbudget Gemäß Projektantrag das Gesamtbudget des (Pb) Projektes in TSD EUR Umfang des Angabe wie viele Partner bei der ProjektdurchKonsortiums führung involviert sind Förderstatus Kennzeichnung ob das Projekt im Rahmen öffentlicher Förderprogramme (BMBF, EU) unterstützt wird Umfang der Anzahl der Konzerneinheiten, für welche das Zielgruppe Projekt verwertbare Ergebnisse generieren soll Zielgruppe im Kennzeichnung, welche Konzerneinheit(en) die Konzern Projektergebnisse verwenden soll(en) Ergebnistyp Angabe, welche Lieferobjekte das Projekt im Endergebnis hauptsächlich bereitstellen wird Softwareanteil Kennzeichnung, ob bei der Projektdurchführung in nennenswertem Umfang Software implementiert wird. Ausprägung der Projektmerkmale Angabe in Monaten Pb <= 250 250 < Pb <= 750 Pb > 750 Anzahl Projekt wird öffentlich gefördert Projekt wird nicht öffentlich gefördert Anzahl 0 bis 5 (0 bedeutet, dass keine Angaben hinterlegt sind) T-Com T-Online T-Systems T-Mobile T-Labs Wissensaufbau Konzept/Studie Projekt umfasst Softwareimplementierung Prototyp Projekt umfasst keine nennenswerte Softwareimplementierung Ziel der Erfassung war es, eine hohe Anzahl an Projekten abzudecken, und damit generalisierbare Aussagen über Zusammenhänge zwischen Projekteigenschaften zu gewinnen, die sich auf zukünftige Projekte übertragen lassen. Die Auswahl der Eigenschaften orientiert sich in erster Linie an der Verfügbarkeit notwendiger Daten für einen großen Teil des T-Labs Projektportfolios. In einem zweiten Schritt wurde auf Basis dieses Datensatzes eine Clusteranalyse durchgeführt. Sie hat zum Ziel, in einer heterogenen Gesamtheit von Objekten, Teilmengen zu identifizieren, welche eine möglichst homogene Eigenschaftsstruktur aufweisen. Diese Segmentierung erlaubt es, eine handhabbare Anzahl von Innovationsprojekttypen zu differenzieren, für die eine adaptierbare Bewertungsmethode konstruiert werden kann. Als Clusterverfahren wurde der Two-step Algorithmus gewählt. Er unterstützt die Gruppierung von Objekten, welche sowohl mit kategorial als auch mit metrisch skalierten Variablen beschrieben sind [3]. In einem zweistufigen Vorgehen erfolgt zunächst initial eine Gruppenbildung anhand der dichtesten Merkmalsverbindungen. Im zweiten Schritt werden die Clusteranzahl und die Zuordnung von Objekten zu Clustern mittels hierarchischer Clusteranalyse unter Beachtung der maximalen Änderung des Abstandes zwischen zwei Clustern verfeinert. Im Ergebnis wurden vier Cluster gebildet. Ihre Merkmale bezüglich der zugrunde liegenden Eigenschaften sind in Tabelle 2 dargestellt. Die identifizierten Cluster repräsentieren vier grundlegende Typen von Innovationsprojekten der TLabs. Die in Cluster 1 berücksichtigten Innovationsprojekte zeichnen sich durch eine vergleichsweise lange Projektdauer aus. Hier ist im Projektverlauf besonderes Augenmerk auf die nachhaltige Konformität des Projektgegenstandes mit der Zielarchitektur zu legen. Die hohe Anzahl an Konsortialpartnern bei Projekten in diesem Cluster schränkt die Einflussnahme auf die Projektdurchführung ein, d. h. die Erstellung von Teilergebnissen kann u. U. von der Bereitstellung von Teiler- 112 gebnissen durch Dritte abhängen. Die Tatsache, dass ein Projekt im Cluster i. d. R. mehrere Zieldivisionen im Konzern besitzt, erhöht das Risiko von Zielkonflikten, da die strategische Ausrichtung unter den Divisionen divergieren kann. Dies muss bei der Bewertung der Konformität mit einer Zielarchitektur gesondert adressiert werden. Unter Berücksichtigung der genannten Eigenschaften repräsentieren die Projekte in Cluster 1 den Projekttyp „Strategy Implementation“. Tabelle 2. Klassifikation von Projekttypen Clustereigenschaften Projektlaufzeit in m ( x ) Umfang der Zielgruppe ( x ) Umfang des Konsortiums ( x ) Projektbudget in TSD EUR Clusteranteile in % der Stichprobe Förderstatus Ergebnistyp: Konzept/Studie Ergebnistyp: Wissensaufbau Ergebnistyp: Prototyp Softwareanteil Cluster 1 (n=33) Cluster 2 (n=23) 21,3 10,6 1,8 1,7 5,0 50% > 750 40,5 53,2 0,0 55,0 51,7 1,2 68% < 250 2,7 37,1 10,4 0,0 0,0 Cluster 3 (n=42) 12,3 1,2 Cluster 4 (n=18) 20,4 1,5 2,1 55% < 250 3,3 750 > 50% > 250 40,5 9,7 62,7 0,0 18,3 16,2 0,0 26,9 45,0 30,0 Sum 100,0 100,0 100,0 100,0 100,0 In Cluster 2 finden sich Projekte mit einer relativ kurzen Laufzeit. Annahmen, welche zu Projektbeginn über die strategische bzw. taktische Ausgestaltung einer Zielumgebung, z. B. der Produktpalette, getroffen wurden, unterliegen i. d. R. keinen Modifikationen während der Projektdurchführung. Die Bündelung von Interessen, hervorgerufen durch mehrere Zieleinheiten im Konzern muss dennoch adressiert werden. Entlastet wird die Projektdurchführung durch eine geringe Anzahl an Konsortialpartnern. Die geringe Quote an öffentlich geförderten Projekten tangiert die Bewertung insofern, als dass Auflagen für zusätzliche Dokumentationspflichten sowie festgeschriebene Meilensteine für Projekte in diesem Cluster von untergeordneter Bedeutung sind. Da im Cluster 2 keine technische Realisation bzw. Softwareimplementierung im Vordergrund steht, kann sich eine Bewertung auf nicht-technische Aspekte konzentrieren. Cluster 2 umfasst somit Projekte, welche den Projekttyp „Proof-of-Concept“ verkörpern. Cluster 3 umfasst Projekte, welche im Allgemeinen eine einzige Zieleinheit im Konzern besitzen. Dementsprechend fokussiert muss die Prüfung auf Konformität mit dieser Zielumgebung erfolgen. Der vergleichsweise hohe Anteil an öffentlich geförderten Projekten bedeutet für dieses Cluster, dass oftmals bereits Vorgaben existieren, wann und wogegen der Projektgegenstand bewertet werden soll. Diese Vorgaben sind zu berücksichtigen bzw. in den eigenen Bewertungsansatz zu integrieren, in dem z. B. die Bewertungszeitpunkte koordiniert werden und damit u. a. die Datenerfassung ressourcenschonend erfolgt. Der Ergebnistyp Wissensaufbau ist dominierend für die Projekte des Clusters. Für die Bewertung bedeutet dies, dass im Gegensatz zu einer intendierten konkreten Produktentwicklung, hier Wiederverwendung und Modularisierung von Wissen für zukünftige Projekte ermöglicht werden soll und dementsprechend Dokumentation und Anreicherung der Wissensbasis zum Projektgegenstand geprüft werden muss. Die im Cluster 3 beschriebenen Projekte werden daher zum Projekttyp „External Co-Funded Basic Research“ zusammengefasst. Projekte in Cluster 4 sind wiederum durch eine lange Laufzeit gekennzeichnet, grenzen sich aber von Cluster 1 ab, da sie für eine vergleichsweise abgegrenzte Zieleinheit im Konzern und im Rahmen eines kleineren Konsortiums durchgeführt werden. Neben den Implikationen für die Bewertung, welche sich aus Projektlaufzeit und Größe des Konsortiums ergeben, muss hier zusätzlich berücksichtigt werden, dass es sich in der Mehrzahl um industriefinanzierte Projekte handelt. Die 113 Volatilität der Zielumgebung aus Sicht der Geschäftsarchitektur führt auch gerade für Projekte mit stark innovativem Charakter zur Notwendigkeit, die Annahmen aus dem Projektantrag mit der aktuellen Situation abzugleichen. Neben der Geschäftsarchitektur spielt auch die Weiterentwicklung der technischen Zielinfrastruktur eine bedeutende Rolle. Die Erstellung von Prototypen bedingt z. B., dass neben Anforderungen an die Software- und Datenarchitektur für die Abbildung eines neuen Produktes auch bei einer Überführung in ein Produkt benötigte Netzwerkressourcen antizipiert werden. Die im Cluster vereinten Projekte werden als „Co-Ordinated Applied Research“ bezeichnet. 3.2. Ableitung von Bewertungsdimensionen und -analysen Wie in Abschnitt 2.1 beschrieben, strukturiert ein Unternehmensarchitekturmodell Gestaltungsobjekte und die Zusammenhänge zwischen diesen Gestaltungsobjekten. Als Bewertungsgrundlage wird an dieser Stelle der Zielzustand für die Unternehmensarchitektur herangezogen. Er repräsentiert damit die Annahmen über die Zielumgebung, über alle relevanten Architekturebenen hinweg für ein zu bewertendes Innovationsprojekt. Dieser Ansatz fußt dabei auf Arbeiten, die eine ähnliche Unterscheidung der Zielarchitektur einer Umgebung im Unterschied zur spezifischen Projektarchitektur treffen [9]. Darüber hinaus unterstützt dieses Vorgehen die Modularisierung der Bewertung. Es sind eine Vielzahl von Analysen auf Basis der Unternehmensarchitektur definiert, die jeweils unterschiedliche Ziele der Architekturgestaltung unterstützen [16, 17, 22]. Diese Analysen operationalisieren die Projektbewertung, in dem sie u. a. Abhängigkeiten zwischen Gestaltungsobjekten aufzeigen sowie Auswirkungen eines Projektes auf die Zielumgebung transparent darstellen. Ebenso ist es möglich, die Konformität des Projektes sowohl bezüglich bestimmter Standards als auch gegen eine Zielumgebung zu prüfen. Ebenfalls werden fachliche Aspekte berücksichtigt, in dem z. B. der Umsetzungsgrad aufsichtsrechtlicher und gesetzlicher Anforderungen bewertet und dokumentiert wird. Abbildung 1 stellt die Bewertungsdimensionen aus Sicht einer generischen Unternehmensarchitektur dar. Die Dimensionen für die Bewertung aus Perspektive der Unternehmensarchitektur werden dabei durch die einzelnen Architekturebenen repräsentiert (vgl. für Ebenen der Unternehmensarchitektur [1, 23]). Abbildung 1 zeigt darüber hinaus jeweils relevante Gestaltungsobjekte und führt exemplarisch ausgewählte Beispielanalysen für einzelne Architekturebenen an. Analysetyp Abhängigkeits- und Auswirkungsanalyse Gestaltungsobjekte Abdeckungsanalyse Strategieebene Produkte, Marktsegmente, Geschäftspartner, Strat. Projekte Organisations- Integrationsebene ebene Geschäftsprozesse, Geschäftsfkt., Rollen, Org.Einheiten Konformitätsanalyse Wirtschaftlichkeitsanalyse 4 7 1 9 2 5 Domänen, Applikationen, fachliche Services 10 SoftwareInfrastrukturund ebene Datenebene Softwarekomponenten, Funktionshierarchien 8 3 Plattformen, Hardware- und Netzwerkkomponenten 6 Abbildung 1. Analysen auf Basis der Unternehmensarchitektur, in Anlehnung an [17] 114 Es ist sowohl möglich, Zusammenhänge zwischen Gestaltungsobjekten auf einer Ebene darzustellen, als auch ebenenübergreifende Zusammenhänge in die Bewertung zu integrieren. Folgende Beispielanalysen veranschaulichen diese Breite: 1. Ist die informationstechnische Abbildung des Produktes in einer Zielumgebung mittels Reorganisation von Services möglich? 2. Wie stellt sich die Reife der Organisation bezüglich des Marktzugangs und des Mitarbeiterprofils dar, um das Projektergebnis in ein Produkt zu überführen? 3. Setzt die Implementierung auf bestehende Infrastrukturkomponenten der Zielumgebung auf? Welche Optionen zur Wiederverwendung von Plattformen, Netzwerkkomponenten erlaubt die zugrunde liegende Softwarearchitektur? 4. Unterstützt das zu entwickelnde Produkt/Projekt die strategische Ausrichtung der Zielkonzerneinheit(en)? 5. Können in den Produktionsprozessen bestehende fachliche Fähigkeiten verwendet werden oder müssen neue Kompetenzen aufgebaut werden? 6. Ist die für die Implementierung erforderliche Infrastruktur/Plattform in der erforderlichen Reife vorhanden/getestet? Genügt sie den Anforderungen der Zielkonzerneinheit an einen Branchenstandard? 7. Sind für die Überführung des Projektergebnisses in ein Produkt notwendige Prozesse/organisatorische Einheiten konsistent im gewünschten Geschäftsprozessmodell abzubilden? Wo ist ggf. ein Reengineering mit welchem Aufwand notwendig? 8. Sind zur Produktenwicklung notwendige Modifikationen an Software- bzw. Datenarchitektur unter Berücksichtigung der Projektlaufzeit durchführbar? 9. Ergibt sich ein positiver Business Case, wenn in der Produktion auf bestehende Mitarbeiterressourcen/Vertriebskanäle zurückgegriffen werden kann? 10. Erhöht der geplante Ausbau der Netzinfrastruktur auf Basis von Projektergebnissen den Kundennutzen? Die angeführten Beispielanalysen demonstrieren ein breites Spektrum für die Bewertung von Innovationsprojekten. Im Sinne einer situativen Methodenkonstruktion ist dabei nicht jede mögliche Analyse sinnvoll auf jeden Projektgegenstand zu übertragen. Die Segmentierung von Projekten in Abschnitt 3.1 zeigt, dass bereits auf Basis grundlegender Eigenschaften verschiedene Projekttypen existieren. So ist z. B. die projektbegleitende Kontrolle der Strategiekonformität weniger relevant für Projekte aus dem Cluster 2, da deren angesetzte durchschnittliche Laufzeit einen Strategiewechsel im Projektverlauf kaum wahrscheinlich macht. Ein weiteres Beispiel für eine situative Nutzung von Bewertungsanalysen stellt die Bewertung anhand standardkonformer Infrastrukturelemente dar. Hier sind in erster Linie Projekte aus den Clustern 1 und 4 zu berücksichtigen, während Projektergebnisse aus den Clustern 2 und 3 mehrheitlich konzeptioneller Natur sind und eher die grundsätzliche Reife einer Organisation berücksichtigen sollen. 3.3. Einbettung der Bewertung in ein Vorgehensmodell Innovationsprozesse zeichnen sich nicht nur durch Freiheitsgrade beim Forschungsgegenstand aus, sondern auch durch eine vergleichsweise geringere Belastung bei der Projektadministration [8]. Um diesem Charakter gerecht zu werden, muss zusätzlicher administrativer Aufwand, welcher die Bewertung von einzelnen Projekten verursacht, minimal gehalten werden. Aus diesem Grund wird angestrebt, die Bewertung innerhalb bestehender Innovationsprozesse zu verankern. In dem sich Aktivitäten zur Bewertung in etablierte Prozessmodelle einfügen, kann ebenso sichergestellt werden, dass die notwendige Akzeptanz bei den Nutzenden gegeben ist und zukünftige Prozessveränderungen berücksichtigt werden. Es gilt im Rahmen der hier festgeschriebenen Aktivitäten den Bewertungsansatz aus Unternehmensarchitekturperspektive so zu verankern, dass erstens Zeitpunk- 115 te und zweitens relevante Dimensionen für eine Bewertung definiert werden. In Anlehnung an Abbildung 1 ist für jede Bewertungsdimension eine Checkliste in Form konkreter Bewertungsfragen definiert, welche für das jeweilige Projekt zu dokumentieren sind. Abbildung 2 zeigt vereinfacht den Innovationsprozess der T-Labs, wie ihn jedes Projekt durchläuft. Gate 4 Projektbewertung aus Unternehmensarchitektur perspektive Gate 1 Idea Proposal Gate 2 Project Scheme Kick-off Gate 3 Project Plan Produktisierung in Konzerneinheit(en) … P&I internal R&D Panel Innovation Board Milestone 1 Milestone n Transfer Project Innovation Board t Abbildung 2. Innovationsprozess der T-Labs Die Projektbewertung setzt dabei nach der endgültigen Projektfreigabe durch das Innovation Board an, da erst zu diesem Zeitpunkt zusätzlicher Aufwand für die Durchführung der Methode zur Bewertung sinnvoll ist. Außerdem soll gewährleistet werden, dass neben dem etablierten Projektauswahlprozess, auch nach der Freigabe die Konformität mit der Zielumgebung besteht. Tabelle 3 stellt die Aktivitäten dar, wie sie im Rahmen der Methodenkonstruktion definiert wurden. Die Auswahl der Aktivitäten leitet sich aus dem dargestellten Verständnis zur Unternehmensarchitektur ab und integriert Anforderungen des bestehenden Innovationsprozesses. Neben einer Beschreibung wird für die jeweilige Aktivität das resultierende Ergebnis dargestellt sowie die notwendigen Vorbedingungen für ihre Ausführung angegeben. Die Kennzeichnung der Relevanz für die identifizierten grundlegenden Projekttypen der T-Labs adressiert die situative Adaption der Methode, indem einzelne Aktivitäten als relevant für einen Projekttyp charakterisiert sind. Tabelle 3. Vorgehensmodell, Relevanz einzelner Aktivitäten für die identifizierten Projekttypen ID Beschreibung der Aktivität Ergebnisse der Aktivität Vorbe- Projekttypen/ Aktivität dingung Cluster A1 A2 A3 A4 A5 A6 A7 A8 A9 Im Rahmen der Meilensteine im Projektplan wird Projekt-individuell festgelegt, wann eine Bewertung durchgeführt wird Abstimmung mit externen Bewertungsvorgaben Festlegung der Bewertungsdimension, z. B. anhand der Projekttypisierung Bewertung/Analysen mit Bezug zur Strategieebene Bewertung/Analysen mit Bezug zur Organisationsebene Dokumentierte(r) Zeitpunkt(e) einer Bewertung Dokumentierte Berichtspflicht gegenüber Dritten Bewertungsdimension(en) für das Projekt Dokumentierte Strategiekonformität, z. B. mit Zieleinheit im Konzern Dokumentierte Geschäftsprozesskonformität, z. B. Konsistenz bezogen auf das Geschäftsprozessmodell Bewertung/Analysen mit Bezug zur InDokumentation des Business/ITtegrationsebene Alignment Bewertung/Analysen mit Bezug zur Dokumentation Konformität, Software/Datenebene Änderungsbedarfe Softwarearchitektur Bewertung/Analysen mit Bezug zur InDokumentation Plattformverfügbarfrastrukturebene keit, z. B. bzgl. Standardkonformität Ableitung von Steuerungsmaßnahmen auf Entscheid über Ressourcenzuteilung Basis der Bewertungsergebnisse oder Projektaussetzung 116 Freigabe CL1, CL2, CL3, CL4 A1 CL1, CL3 A1, A2 A3 CL1, CL2, CL3, CL4 CL1, CL4 A3 CL1, CL2 A3 CL1, CL2, CL3, CL4 CL1, CL3, CL4 CL1, CL4 A3 A3 A4-A8 CL1, CL2, CL3, CL4 Die Aktivitäten orientieren sich dabei u. a. an den beschriebenen Ebenen einer Unternehmensarchitektur und sind somit jeweils Anknüpfungspunkt für die in Abbildung 1 exemplarisch angeführten Analysen zur Bewertung von Projekten. Auf Basis der dokumentierten Projektbewertung und unter Berücksichtigung spezieller Projekttypen werden verschiedene Steuerungsmaßnahmen vorgeschlagen. Diese dienen dazu, eventuelle Fehlentwicklungen im Projekt zu kompensieren, indem z. B. erneut die Zieleinheit im Konzern um eine Stellungnahme zu ihrer zukünftigen Plattformstrategie gebeten wird. Darüber hinaus ist es möglich, Bewertungsergebnisse zu nutzen, um einem Projekt zusätzliche Ressourcen zuzuteilen, insbesondere für den Fall, dass die Einschätzung für eine Produktrelevanz zu knapp bemessen war und nun deutlich früher mit einer möglichen Umsetzung als Produkt zu rechnen ist. Wichtig ist an dieser Stelle, dass die Bewertung aus Unternehmensarchitekturperspektive alle weiteren relevanten Einflussfaktoren für ein solches Projekt geprüft hat. 4. Diskussion und weiterer Forschungsbedarf Der Beitrag zeigt, wie das Konzept situativer Methodenkonstruktion genutzt werden kann, um die Bewertung von Innovationsprojekten unter besonderer Berücksichtigung der Unternehmensarchitekturperspektive durchzuführen. Im Rahmen des vorgeschlagenen Prozesses zur Konstruktion situativer Methoden [4] wurde das Projektportfolio der T-Labs in vier grundlegende Projekttypen segmentiert. Darüber hinaus wurden auf Basis eines Unternehmensarchitekturmodells verschiedene Bewertungsanalysen abgeleitet, welche als Aktivitäten im Rahmen eines Vorgehensmodells den Projekttypen zugeordnet wurden. Die Zuordnung gibt Auskunft zur situativen Adaptierbarkeit der Methode, in dem die Relevanz bestimmter Aktivitäten für einzelne Projekttypen beurteilt wurde. Wichtiger Bestandteil der gegenwärtigen Arbeit ist die Instanziierung der vorgeschlagenen Aktivitäten im Rahmen einer aktuell durchgeführten Projektbewertung. Dies ist notwendig, um einerseits die Adaptierbarkeit einzelner Aktivitäten für die vorgeschlagenen Projekttypen zu bestätigen und andererseits die grundsätzliche Güte der Projektklassifikation zu ermitteln. Weiterer Forschungsbedarf ergibt sich z. B. dann, wenn sich die Segmentierung als zu grobgranular erweist, um für einen relevanten Ausschnitt des T-Labs Projektportfolios Nutzen stiftend zu sein. Darüber hinaus sind weitere Elemente, wie z. B. das Rollenmodell für eine situative Methode zu dokumentieren. Weiterhin ist es möglich, die Methodenbausteine (ohne die spezifischen Projekttypen) so generisch zu gestalten, dass sie für eine breite Menge von Forschungs- und Entwicklungsprojekten anwendbar sind. Andererseits ließen sich durch die Betrachtung branchenspezifischer Referenzarchitekturmodelle, z. B. eTOM im Telekommunikationssektor, Innovationsprojekte präziser bewerten und standardisierte Steuerungsmaßnahmen ableiten. Zusammenfassend zeigt der Beitrag, wie die Bewertung unterschiedlicher Projekttypen im Kontext nicht-funktionaler Anforderungen aus Unternehmensarchitekturperspektive unterstützt werden kann. Die segmentierten Projekttypen dienen dazu, ein Vorgehensmodell für die Bewertung so zu strukturieren, dass abgestimmt auf den Projekttyp relevante Analysen auf Basis der Unternehmensarchitektur ausgewählt werden können. Um die Tragfähigkeit des vorgestellten Ansatzes zu prüfen, wird in einem nächsten Schritt ein Ausschnitt des Projektportfolios analysiert. 5. Literatur [1] AIER, S., RIEGE, C., WINTER, R., Unternehmensarchitektur – Literaturüberblick und Stand der Praxis, in: Wirtschaftsinformatik, 50 (4), 2008, S. 292-304. [2] ARNOLD, H. M., DUNAJ, M.: Enterprise Architecture and Modularization in Telco R&D as a Response to an Environment of Technological Uncertainty: Proceedings ICIN 2007. [3] BACHER, J., WENZIG, K., VOGLER, M.: SPSS TwoStep Clustering - A First Evaluation: Proceedings of Sixth International Conference on Logic and Methodology, Amsterdam 2004. 117 [4] BAUMÖL, U.: Strategic Agility through Situational Method Construction, in: Reichwald, R., Huff, A.S. (Hrsg.): Proceedings of the European Academy of Management Annual Conference 2005. [5] BUCHER, T., DINTER, B.: Process Orientation of Information Logistics - An Empirical Analysis to Assess Benefits, Design Factors, and Realization Approaches, in: Sprague Jr., R.H. (Hrsg.): Proceedings of the Forty-First Annual Hawaii International Conference on System Sciences (HICSS-41), IEEE Computer Society, Los Alamitos 2008. [6] BUCHER, T., KLESSE, M., KURPJUWEIT, S., WINTER, R.: Situational Method Engineering - On the Differentiation of "Context" and "Project Type", in: Ralyté, J., Brinkkemper, S., Henderson-Sellers, B. (Hrsg.): Proceedings of the IFIP WG8.1 Working Conference on Situational Method Engineering - Fundamentals and Experiences (ME07), Vol. 244, Springer, Boston 2007, S. 33-48. [7] BUCHER, T., WINTER, R., Classification of Business Process Management Approaches - An Exploratory Analysis, in: BIT - Banking and Information Technology, 7 (3), 2006, S. 9-20. [8] COOPER, R. G., Best practices in product innovation what distinguishes top performers, Ancaster, ON 2003. [9] FOORTHUIS, R. M., BRINKKEMPER, S.: A Framework for Project Architecture in the Context of Enterprise Architecture, in: Lankhorst, M.M., Johnson, P. (Hrsg.): Proceedings of the Second Workshop on Trends in Enterprise Architecture Research (TEAR 2007), June 6 2007, St. Gallen, Switzerland, Via Nova Architectura 2007, S. 51-60. [10] HARMSEN, A. F., BRINKKEMPER, S., OEI, H.: Situational Method Engineering for Information System Project Approaches, in: Verrijn-Stuart, A.A., Olle, T.W. (Hrsg.): Proceedings of the IFIP 8.1 Working Conference on Methods and Associated Tools for the Information Systems Life Cycle, North-Holland, Amsterdam 1994, S. 169-194. [11] IEEE: IEEE Recommended Practice for Architectural Description of Software Intensive Systems (IEEE Std 14712000), IEEE Computer Society, New York, NY 2000. [12] JOHNSON, P., LAGERSTRÖM, R., NÄRMAN, P., SIMONSSON, M.: Extended Influence Diagrams for Enterprise Architecture Analysis: Proceedings,Tenth IEEE International 2006, EDOC Enterprise Computing, IEEE Computer Society, Los Alamitos, California, USA, et al. 2006, S. 3-12. [13] KUMAR, K., WELKE, R. J., Methodology Engineering - A Proposal for Situation-specific Methodology Construction, in: Cotterman, W., Senn, J.A. (Hrsg.): Challenges and Strategies for Research in Systems Development, New York 1992, S. 257-269. [14] KURPJUWEIT, S., WINTER, R.: Viewpoint-based Meta Model Engineering, in: Reichert, M., Strecker, S., Turowski, K. (Hrsg.): Enterprise Modelling and Information Systems Architectures - Concepts and Applications, Proceedings of the 2nd Int'l Workshop EMISA 2007, Vol. P-119, Gesellschaft für Informatik, Köllen, Bonn 2007, S. 143161. [15] MERTENS, P., Diskussionsrunde zum Thema „Unternehmensarchitekturen in der Praxis“, in: Wirtschaftsinformatik, 46 (4), 2004, S. 315. [16] NIEMANN, K. D., Von der Unternehmensarchitektur zur IT-Governance: Leitfaden für effizientes und effektives IT-Management, (Edition CIO). Auflage 2005. [17] RIEGE, C., STUTZ, M., WINTER, R., Geschäftsanalyse im Kontext der Unternehmensarchitektur, in: Hmd Praxis Der Wirtschaftsinformatik, 43 (262), 2008 [18] SIMONSSON, M., LINDSTRÖM, Å., JOHNSON, P., NORDSTRÖM, L., GRUNDBÄCK, L., WIJNBLADH, O.: Scenario-Based Evaluation of Enterprise Architecture - A Top-Down Approach for CIO Decision-Making: Proceedings of the International Conference on Enterprise Information Systems 2006, S. 130-137. [19] SINZ, E. J., Unternehmensarchitekturen in der Praxis – Architekturdesign am Reißbrett vs. situationsbedingte Realisierung von Informationssystemen, in: Wirtschaftsinformatik, 46 (4), 2004, S. 315-316. [20] VAN SLOOTEN, K., HODES, B.: Characterizing IS Development Projects, in: Brinkkemper, S., Lytinnen, K., Welke, R.J. (Hrsg.): Proceedings of the IFIP TC8, WG8.1/8.2 Working Conference on Method Engineering, Springer, Berlin et al. 1996, S. 29-44. [21] VASCONCELOS, A., SOUSA, P., TRIBOLET, J., Information System Architecture Metrics: an Enterprise Engineering Evaluation Approach, in: The Electronic Journal Information Systems Evaluation (EJISE), 10 (1), 2007, S. 91122. [22] WINTER, R., BUCHER, T., FISCHER, R., KURPJUWEIT, S., Analysis and Application Scenarios of Enterprise Architecture - An Exploratory Study, in: Journal of Enterprise Architecture, 3 (3), 2007, S. 33-43. [23] WINTER, R., FISCHER, R., Essential Layers, Artifacts, and Dependencies of Enterprise Architecture, in: Journal of Enterprise Architecture, 3 (2), 2007, S. 7-18. [24] WÖBKING, F., Unternehmensarchitekturen in der Praxis - Architekturdesign am Reißbrett vs. situationsbedingte Realisierung von Informationssystemen, in: Wirtschaftsinformatik, 46 (4), 2004, S. 319-320. 118 SERVICEORIENTIERTE INTEGRATION MEDIZINISCHER GERÄTE – EINE STATE OF THE ART ANALYSE Christian Mauro, Ali Sunyaev1, Jan Marco Leimeister2, Helmut Krcmar1 Kurzfassung Geräte sind ein wesentlicher Bestandteil medizinischer Behandlungsprozesse. Für eine optimale IT-Unterstützung der Behandlung ist daher die Prozessintegration und die Interoperabilität dieser Geräte erforderlich. Der Ansatz der serviceorientierten Geräteintegration versucht, diesen Anforderungen gerecht zu werden. Anhand eines Szenarios führt der vorliegende Beitrag in dieses noch junge Gebiet ein und gibt den State of the Art anhand einer Analyse existierender Literatur wieder. Berücksichtigt werden dabei Entwicklungen aus anderen Domänen wie z. B. der industriellen Automatisierung. Eine Reihe von Forschungslücken auf Anforderungsebene, technischer Ebene und Methodikebene werden identifiziert. 1. Einleitung Die Basis jeder serviceorientierten Architektur sind Services, die eine bestimmte Geschäftsfunktionalität zur Verfügung stellen [23]. Einzelne Services werden wiederum orchestriert, um einen bestimmten Geschäftsprozess abzubilden. Dabei werden Services in der Regel als Softwarekomponente angesehen. Insbesondere im medizinischen Bereich sind jedoch auch Geräte wesentlicher Bestandteil von (Behandlungs-)Prozessen. Für eine konsequente Umsetzung von serviceorientierten Architekturen in Krankenhäusern ist daher die serviceorientierte Integration medizinischer Geräte notwendig. Das folgende fiktive Szenario soll die Potentiale einer solchen Integration im Krankenhaus anschaulich verdeutlichen: Herr Müller sucht mit Beschwerden die Ambulanz eines Krankenhauses auf. Aufgrund der erstellten Diagnose muss Herr Müller stationär aufgenommen und operiert werden. Der auf der Diagnose basierende Behandlungspfad sieht vor der Operation die Durchführung einer Magnetresonanztomographie (MRT) vor. Für die MRT-Untersuchung und Operation benötigte Geräte sind serviceorientiert in die IT-Architektur des Krankenhauses eingebunden. Dadurch können freie Geräte automatisch gesucht und reserviert werden. Eine manuelle Buchung der Ressourcen und damit verbundene Zeitaufwände sind daher nicht mehr notwendig. Auch Reinigungs- oder Wartungsarbeiten an den Geräten können auf diese Weise dynamischer koordiniert werden. Die MRT-Bilder sind 1 Technische Universität München, Lehrstuhl für Wirtschaftsinformatik, Boltzmannstr. 3, D-85748 Garching b. München, Germany 2 Universität Kassel, Fachbereich Wirtschaftsinformatik, Nora-Platiel-Str. 4, D-34127 Kassel, Germany 119 direkt im Anschluss an die Untersuchung im KIS an der entsprechenden Stelle des Behandlungspfades eingeordnet und einsehbar. Diese Zuordnung ermöglicht in Verbindung mit der visuellen Darstellung des Behandlungspfades ein schnelles Auffinden benötigter Informationen. In den Tagen vor der Operation werden regelmäßig wichtige Daten wie z. B. die Temperatur oder der Blutdruck erfasst. Manche Werte werden dabei von einer Schwester manuell erfasst und in einen PDA eingegeben, andere Werte werden direkt durch medizinische Geräte erfasst. An diesen Datenquellen können eine Reihe von Komponenten angemeldet sein. Dadurch werden die erhobenen Daten direkt in die medizinische Dokumentation aufgenommen und stehen unmittelbar nach Erfassung zur Verfügung. Darüber hinaus ist eine Komponente angemeldet, die medizinische Studien verwaltet. Die Datenerhebung für Studien kann somit in Echtzeit und ohne Medienbrüche erfolgen. Auch ist eine Monitoring-Komponente umgesetzt, die die erhobenen Daten im Gesamtkontext analysiert und z. B. feststellt, dass die geplante OP aufgrund des aktuellen Zustands von Herrn Müller nicht durchgeführt werden kann, weil das Risiko von Komplikationen zu groß wäre. Vorab reservierte Ressourcen werden automatisch freigegeben und dynamisch neu zugeordnet. Nachdem das System festgestellt hat, dass sich der Zustand von Herrn Müller wieder gebessert hat, wird die OP-Planung inkl. Reservierung aller Ressourcen neu angestoßen. Auch die während der OP und alle weiteren bis zur Entlassung von Herrn Müller erfassten Daten werden wiederum direkt in die Dokumentation sowie ggf. weitere Anwendungen integriert. Das Ziel serviceorientierter Geräteintegration ist es, die Realisierung solcher Szenarien zu ermöglichen und somit einen großen Schritt in Richtung der Vision „Seamless Healthcare“ zu gehen, bei der vertikal und horizontal durchgängige Prozesse, Daten und Informationstechnologie subsumiert werden [29]. Insbesondere soll die Entwicklung neuer Funktionalitäten, bei denen medizinische Geräte involviert sind, somit schneller und einfacher möglich sein. Zusätzlich soll die Implementierung unabhängig von bestimmten Gerätetypen oder –Herstellern sein, um die Wiederverwendbarkeit der entwickelten Services sicherzustellen. Das bedeutet, dass bspw. bei einem Gerätewechsel maximal eine Adapterkomponente, nicht aber die komplette Anwendung angepasst werden muss. Ziel des vorliegenden Beitrags ist die Identifizierung von Forschungslücken im Bereich der serviceorientierten Integration medizinischer Geräte. Dazu führen wir in die Thematik ein und beschreiben bzw. definieren grundlegende Begriffe sowie das theoretische Konzept der serviceorientierten Geräteintegration. Anschließend geben wir den State of the Art anhand einer Literaturanalyse wieder. Betrachtet werden dabei nicht nur Quellen aus dem medizinischen Bereich, so dass auch bereits existierende Lösungen aus anderen Domänen berücksichtigt werden können. Anhand der Analyse werden die Forschungslücken identifiziert und kategorisiert. Der Beitrag endet mit einer Zusammenfassung und einem Ausblick auf zukünftige Forschung. 2. Begriffliche Grundlagen 2.1. Medizinische Geräte Der Begriff des „Medizinisches Geräts“ ist nicht eindeutig definiert und wird je nach Kontext anders ausgelegt. In der EU-Richtlinie 93/42/EWG über Medizinprodukte (Medizinproduktrichtlinie) wird lediglich der Begriff des „Medizinischen Produkts“ spezifiziert, der weitreichend definiert ist und insbesondere auch nicht-technische Produkte beinhaltet. Darüber hinaus wird in DIN EN 60601 der Begriff des „medizinischen elektrischen Geräts“ umfassend definiert. Für eine bessere Verständlichkeit soll im Kontext dieses Beitrags folgende Definition gelten: Medizinisches Gerät: Medizinprodukt mit IT-Schnittstelle 120 Die IT-Schnittstelle kann dabei beliebiger Ausprägung sein (analog/digital, standardisiert/proprietär, etc.), z. B. eine serielle RS-232 Schnittstelle oder eine Netzwerkschnittstelle. Gemäß Artikel 9 der Richtlinie 93/42/EWG werden medizinische Produkte in die Klassen I, IIa, IIb und III eingestuft, welche potentielle Risiken der Produkte berücksichtigen. Die Einstufungsregelungen sind in Anhang IX der Richtlinie definiert. Je nach Klasse sind andere Anforderungen definiert, wobei Klasse III die kritischsten Produkte beinhaltet, so dass entsprechend strenge Regelungen für die Konformitätsbewertung gelten. Die Klassifizierung ist für die Thematik der serviceorientierten Integration medizinischer Geräte insofern interessant, als dass die Richtlinie in Anhang IX, Abschnitt II, Punkt 2.3 festlegt, dass „Software, die ein Produkt steuert oder dessen Anwendung beeinflusst, automatisch derselben Klasse zugerechnet wird wie das Produkt“. Für eine serviceorientierte Lösungsarchitektur ist daher zu prüfen, welche Softwarekomponenten spezielle rechtliche Anforderungen erfüllen müssen. 2.2. Interoperabilität im Kontext von medizinischen Geräten Der Begriff der Interoperabilität [14] [33] lässt sich zergliedern in • • • technische Interoperabilität (Verkabelung, Netzwerkprotokolle, etc.), syntaktische Interoperabilität (einheitliche Syntax z. B. bei elektronischen Rezepten) und semantische Interoperabilität (gleiches Verständnis von Daten, z. B. bei ICD3-kodierten Diagnosen). Im Kontext von medizinischen Geräten nach der Definition von Abschnitt 2.1, bezieht sich die technische Interoperabilität auf die IT-Schnittstelle, z. B. eine Netzwerkschnittstelle mit TCP/IPÜbertragungsprotokoll. Die syntaktische Interoperabilität ermöglicht den Austausch von Daten, z. B. durch das Vorhandensein eines einheitlichen Datenformats. Erst die semantische Interoperabilität ermöglicht den Austausch von interpretierbaren Informationen (für die Abgrenzung der Begriffe Daten und Information vgl. [24]) und damit Kommunikation [27]. Die potentiellen Vorteile interoperabler medizinischer Geräte sind vielfältig, z. B. eine bessere Behandlungsqualität, optimierte Workflows, Möglichkeiten zur Geräte-Fernwartung, etc. [25]. Daher überrascht es nicht, dass Initiativen wie z. B. IHE (Integrating the Healthcare Enterprise) versuchen, die Standardisierung auf allen Interoperabilitätsebenen voranzutreiben. Dennoch stellt sich die aktuelle Situation wie folgt dar: „Interoperability is an almost non-existent feature of medical devices.” [25] 2.3. Serviceorientierte Geräteintegration Die Idee der serviceorientierten Geräteintegration ist es, ein Gerät als Service zu kapseln, analog zu Enterprise Services einer serviceorientierten Architektur (SOA) [6], s. Abbildung 1. Ein Enterprise Service ist eine Softwarekomponente, die eine Business-Funktionalität auf hoher semantischer Ebene zur Verfügung stellt und deren Schnittstelle in standardisierter Form (z. B. mittels der Webservice Description Language – WSDL) spezifiziert ist [23]. Hohe semantische Ebene bedeutet in diesem Zusammenhang insbesondere, dass ein Service soweit selbstbeschreibend ist, dass er von anderen Komponenten dynamisch und lose gekoppelt verwendet werden kann und zudem ein gemeinsames Verständnis über die ausgetauschten Daten vorliegt. Beispielsweise könnte ein Enterprise Service eine Funktionalität zum Erstellen einer Rechnung anbieten. Ein Device Service hinge3 International Classification of Diseases 121 gen könnte z. B. in der medizinischen Domäne eine Funktionalität anbieten, die den aktuellen Blutdruck eines Patienten zurückgibt. Darauf aufbauend können höherwertige Business Services implementiert werden, die z. B. ein Patienten Monitoring umsetzen. Abbildung 1: Device Service (in Anlehnung an [6]) Der Vorteil des serviceorientierten Ansatzes ist, dass bei der Implementierung einer Funktionalität, die einen Device Service aufruft, die herstellerspezifische Schnittstelle des Geräts nicht bekannt sein muss. Diese wurde durch die serviceorientierte Integration bereits gekapselt. Der Aufruf des Device Services erfolgt durch ein standardisiertes Protokoll (z. B. SOAP) auf hoher semantischer Ebene (z. B. „getBloodPressure“). Dadurch wird es ermöglicht, die IT-Unterstützung für medizinische Prozesse auch auf Geräte zu erweitern. Auch institutionsübergreifende Szenarien sind denkbar. Zudem müssen Anwendungen, die ein bestimmtes Gerät nutzen, nach einem Gerätewechsel (anderer Hersteller oder anderes Modell) nicht angepasst werden. Lediglich die Komponente, die das Gerät integriert, muss ggf. modifiziert und bei Bedarf erweitert werden, wenn das Gerät neue Funktionalitäten anbietet. Die vorherige Service-Schnittstelle kann jedoch unverändert bzw. abwärtskompatibel bleiben. Ein weiterer Vorteil der Kapselung als Service ist, dass einem Gerät Funktionalitäten hinzugefügt werden können, die es ursprünglich nicht besitzt. Beispielsweise könnte eine Funktion „getLocation“ angeboten werden, die den aktuellen Standort des Geräts zurück gibt. Die Implementierung der Funktion könnte dabei auf ein separates Tracking&TracingSystem zurückgreifen. Das Erkennen und Bewerten solcher Nutzenpotentiale ist ein wesentlicher Beitrag, den die Wissenschaft in diesem Forschungsgebiet leisten muss. Das vorgestellte Konzept ist domänenunabhängig und auf hohem Abstraktionsgrad beschrieben. Direkte Rückschlüsse auf eine konkrete technische Umsetzung sind nicht möglich. Es ist daher zu analysieren, welche Anforderungen an eine Lösung zur serviceorientierten Integration medizinischer Geräte gestellt werden müssen, um Szenarien wie aus Abschnitt 1 realisieren zu können. Darauf aufbauend können potentielle Lösungsmöglichkeiten erarbeitet werden, welche die Anforderungen umsetzen. Dies hat im Sinne von [12] unter Berücksichtigung vorhandenen Wissens zu erfolgen. 3. Literaturanalyse Das Ziel der folgenden Literaturanalyse ist die Feststellung des Wissensstandes hinsichtlich Anforderungsanalyse und Lösungskonzepten zur Umsetzung der serviceorientierten Integration medizinischer Geräte. Die Auswahl der Literatur erfolgte in Anlehnung an Empfehlungen von Webster und Watson [34]. Es wurde eine Keywordsuche in den wichtigsten Journals und Konferenzen in den Bereichen Wirtschaftsinformatik, Informatik, Wirtschaftswissenschaften, Medizinische Informatik und Medizin durchgeführt. Zusätzliche Literatur stammte aus bereits bekannten Quellen bzw. Projekten. Insgesamt wurden 26 relevante Quellen identifiziert. Arbeiten aus niedrig gerankten Jour122 nals bzw. Konferenzen sowie uns nicht bekannte Projekte, die noch keine Beiträge veröffentlicht haben, bleiben daher weitgehend unberücksichtigt. Die Autoren beschränken sich auf eine Präsentation des State of the Art sowie der Forschungslücken. Der Fokus liegt dabei auf dem Bereich Krankenhaus, da im niedergelassenen Bereich serviceorientierte Architekturen überdimensioniert erscheinen bzw. die Wahrscheinlichkeit zeitnaher technischer Realisierungen in Deutschland als sehr gering einzuschätzen ist. Ähnliche Fragestellungen können sich jedoch im Bereich Telemedizin sowie in institutionsübergreifenden Szenarien ergeben. 3.1. Schwerpunkte Insbesondere Publikationen aus gleichen oder verwandten Projekten überschneiden sich inhaltlich, fokussieren aber jeweils unterschiedliche Aspekte. Tabelle 1 stellt die Themenschwerpunkte aller identifizierten Quellen in der Übersicht dar (absteigend sortiert nach Häufigkeit). Aus den Anwendungsszenarien und Architekturbeschreibungen lassen sich verschiedene Integrationskonzepte und Integrationstechnologien extrahieren. Diese sind Thema der Abschnitte 3.2 und 3.3. Die Ergebnisse der weiteren Schwerpunkte lassen sich aufgrund der geringen Anzahl an Quellen bzw. der Verschiedenartigkeit der Konzepte nicht zu einem Konsens zusammenführen, werden aber bei der Identifizierung der Forschungslücken in Abschnitt 3.4 berücksichtigt. Tabelle 1: Themenschwerpunkte Themenschwerpunkt Proof of Concept / Anwendungsszenario Architekturbeschreibung Orchestrierung / Prozess Management DPWS (Devices Profile for Web Services) Prozessoptimierung Semantik-Technologien / Context-Awareness Technologieanalyse Interface Design Quality of Service Simulation Quellen [32], [7], [5], [15], [16], [28], [4] [6], [21], [30], [3] [2], [18], [13], [20] [19], [36], [35] [9], [31] [11], [1] [3], [17] [10] [8] [22] 3.2. Integrationskonzepte Die Mehrzahl der gefundenen Quellen ist technisch geprägt. Die Frage nach möglichen technischen Integrationsformen wird daher sehr umfangreich behandelt. Im Wesentlichen lassen sich drei Konzepte identifizieren, um die Funktionalität eines Gerätes als Service zu exportieren. Diese sind in Abbildung 2 darstellt. Bei der direkten Integration wird der Service durch das Gerät zur Verfügung gestellt. Dazu ist es notwendig, dass das Gerät über eine Netzwerkschnittstelle verfügt. Zudem muss die Möglichkeit bestehen, entsprechende Softwarekomponenten (z. B. DPWS4, s. Abschnitt 3.3) auf dem Gerät zu installieren. Eine Vielzahl der gefundenen Quellen verwirklicht die Geräteintegration auf diese Weise, beispielhaft sei [3] erwähnt. Ist die Möglichkeit der direkten Integration nicht möglich, da z. B. nur eine RS-232 Schnittstelle vorhanden ist, kann ein programmierbarer Adapter eingesetzt werden, der an die proprietäre Schnittstelle angeschlossen wird und den Service bereitstellt. Dies wurde z. B. in [9] mit Hilfe eines XPORT-Adapters umgesetzt. Eine weitere Möglichkeit ergibt sich, wenn Geräte an einen Server angeschlossen werden, auf dem die zugehörigen Gerätetreiber und zudem ein Web Application Server für die Bereitstellung der Services installiert sind. Diese Möglichkeit wurde u. a. in [32] umgesetzt. 4 Devices Profile for Web Services 123 Direkte Integration Adapter-Integration Abbildung 2: Integrationskonzepte (eigene Darstellung) Server-Integration 3.3. Integrationstechnologien Zur Umsetzung der im vorherigen Kapitel vorgestellten Integrationskonzepte werden in den Beiträgen folgende Technologien verwendet: OSGi, UPnP5, DPWS, Webservices und gSOAP. Desweiteren werden HAVi6 und JINI als weitere mögliche Technologien genannt, aber zugunsten anderer Technologien nicht eingesetzt. Eine Zuordnung der Technologien zu den Quellen findet sich in Tabelle 2. Dabei ist anzumerken, dass die Technologien nicht disjunkt sind. DPWS basiert sowohl auf UPnP als auch auf Webservice-Technologien und macht je nach Implementierung zudem Gebrauch von gSOAP. Quellen, die DPWS verwenden, werden jedoch in der Tabelle nicht zusätzlich bei UPnP und gSOAP gelistet, um die Abgrenzung darstellen zu können. Zudem ist es möglich, dass verschiedene Technologien in Kombination auftreten, z. B. UPnP und OSGi. In der Tabelle erfolgt die Zuordnung in solchen Fällen anhand der (für die jeweilige Lösungsarchitektur) dominierenden Technologie. Die Tabelle dient lediglich der übersichtlichen Darstellung der verwendeten Technologien. Eine Aussage über die Güte einer Technologie kann aus der Anzahl der zugehörigen Quellen nicht abgeleitet werden. Tabelle 2: Integrationstechnologien Technologie OSGi UPnP DPWS Webservice gSOAP Quellen [7], [11] [17], [2], [10], [1] [5], [8], [15], [16], [18], [28], [3], [4], [19], [21], [31], [36], [35], [30], [22], [13] [32], [20] [9] 3.4. Identifizierte Forschungslücken In Tabelle 3 finden sich zusammenfassend die identifizierten Forschungslücken auf Anforderungsebene, technischer Ebene und Methodikebene. Diese werden in den nächsten Abschnitten erläutert. Dabei besteht zwischen den Ebenen eine starke Abhängigkeit. Insbesondere hängen sowohl die technische als auch die Methodikebene von den Anforderungen ab. Beispielsweise zieht die vernachlässigte Betrachtung der Sicherheit auf Anforderungsebene auch neue Fragestellungen auf technischer Ebene nach sich. Da eine umfassende Anforderungsermittlung im Kontext der serviceorientierten Integration medizinischer Geräte in der Literatur nicht gefunden werden konnte, können zukünftig insb. im Bereich der technischen und Methodikebene neue Fragestellungen entstehen, die mit dem Wissensstand der vorliegenden Arbeit nicht identifiziert werden konnten. 5 6 Universal Plug and Play Home Audio Video Interoperability 124 Tabelle 3: Identifizierte Forschungslücken Ebene Anforderungsebene Technische Ebene Methodikebene Forschungslücken Gesetzliche Anforderungen Lokalität / Mobilität Geräte als Ressource Sicherheit Kriterienkatalog Integrationskonzepte/-Technologien Performanz Prozesssteuerung Sicherheitsmechanismen Service-Granularität Quality of Service Servicebeschreibung Prozessmodellierung 3.4.1. Anforderungsebene Bei bisherigen Arbeiten blieben die Besonderheiten der serviceorientierten Integration medizinischer Geräte weitgehend unberücksichtigt. Nach Meinung der Autoren sind dies gesetzliche Anforderungen, Lokalität/Mobilität, Geräte als Ressource und Sicherheit. Da Fehlfunktionen bei medizinischen Geräten lebensbedrohliche Folgen nach sich ziehen können, werden durch den Gesetzgeber entsprechende Anforderungen vorgegeben. Diese manifestieren sich in Deutschland im Medizinproduktegesetz und den zugehörigen Verordnungen, die die EU-Richtlinien 90/385/EWG, 93/42/EWG und 98/79/EG umsetzen. Die daraus resultierenden Anforderungen an eine Integrationslösung müssen zwingend erhoben und umgesetzt werden. Dieser Aspekt wurde in der gefundenen Literatur bisher nicht aufgegriffen. Bzgl. der allgemeinen Sicherheitsanforderungen ist zudem darauf zu achten, dass zum einen die Patientendaten geschützt werden und zum anderen, dass nur autorisierte Zugriffe auf die Geräte erfolgen können. Im Krankenhaus kann dies z. B. durch Verwendung von elektronischen Arztausweisen (wie dem Heilberufsausweis in Deutschland) oder multifunktionalen Betriebsausweisen erfolgen [26]. Eine Besonderheit von Geräte-Services ist im Gegensatz zu reinen Software-Services die Lokalität bzw. Mobilität. Bei einem Software-Service ist es unerheblich, an welchem Ort sich der Server befindet, auf dem der Service ausgeführt wird, solange die zugehörigen SLAs und Sicherheitsanforderungen eingehalten werden. Auch kann ein Service für eine bessere Lastverteilung auf mehreren Servern gleichzeitig implementiert sein. Die Wahl des Servers erfolgt zur Laufzeit. Bei GeräteServices verhält sich dies anders. In der Regel müssen bei Ausführung des Services der Patient sowie ggf. auch der Arzt anwesend und je nach Gerät korrekt positioniert sein. Die Ausführung eines Geräte-Services bezieht sich daher immer auf ein bestimmtes Gerät zu einem bestimmten Zeitpunkt in Zusammenhang mit einem bestimmten Patienten. Insbesondere bei medizinischen Geräten, die den Gesundheitszustand eines Patienten negativ beeinflussen können, ist unbedingt zu verhindern, dass ein Gerät mit dem Kontext eines falschen Patienten initialisiert wird. Verstärkt wird dieser Umstand durch die Mobilität mancher Geräte. Im Gegensatz zu [20] ist hierbei für die Prozesssteuerung aber nicht nur die Lokalität, sondern der Gesamtkontext (Lokalität, Patient mit Zustand und Behandlungsstand sowie ggf. Arzt) relevant. Ansätze hierzu sind in [11] und [1] zu finden. Eine weitere Besonderheit ist, dass ein medizinisches Gerät eine Ressource ist. Diese kann bestimmte Zustände annehmen, wie z. B. reserviert, in Betrieb, frei, defekt, in Wartung, etc. Dies hat direkte Auswirkungen auf die zugehörigen Services. Unter diesem Aspekt ist auch die Lokalität erneut ein wichtiger Aspekt. Zum einen ist das Auffinden eines benötigten mobilen Geräts eine wichtige Funktionalität, die berücksichtigt werden sollte, und zum anderen ist bei der Reservierung einer Ressource darauf zu achten, dass möglichst die nächstgelegene Ressource gewählt wird, um 125 die Laufwege für Personal und Patient kurz zu halten. Durch die serviceorientierte Integration der Geräte kann das Ressourcenmanagement somit dynamischer und flexibler gestaltet werden. 3.4.2. Technische Ebene Auf der technischen Ebene bleibt unklar, welche der in Abschnitt 3.2 und 3.3 vorgestellten Integrationskonzepte bzw. –Technologien in welchem Kontext am geeignetsten sind. Beispielhaft sei hierbei der Aspekt der Performance genannt, die je nach Konzept bzw. Technologie stark variieren könnte. Im Kontext medizinischer Geräte könnte die Wahl der Integrationsform zudem Auswirkungen auf die Tragweite der Geräte-Zertifizierung haben. So wäre z. B. denkbar, dass direkte Integration eine Neu-Zertifizierung des Gerätes nach sich ziehen würde, während dies bei den beiden anderen Optionen nicht nötig ist. Anzustreben ist daher ein Kriterienkatalog als Hilfestellung zur Auswahl des Integrationskonzeptes für die verschiedensten Kategorien medizinischer Geräte. 3.4.3. Methodikebene Im Bereich der serviceorientierten Architekturen gibt es eine Vielzahl an methodischen Fragestellungen, z. B. die Ableitung von Services aus Geschäftsprozessen oder die serviceorientierte Modellierung. Im Kontext der serviceorientierten Geräteintegration ist zu klären, inwiefern vorhandene Methoden auf Geräte-Services übertragen werden können. Ein Aspekt hierbei ist die ServiceGranularität und damit die Problemstellung, ob jede Funktionalität eines Gerätes einzeln als Service zur Verfügung gestellt werden sollte oder ob diese bereits als höherwertigere Services gekapselt werden. Auch ist unklar, ob vorhandene Methoden und Mechanismen zur Beschreibung und Sicherstellung des Quality of Service im Kontext medizinischer Geräte ausreichend sind. [8] greift diese Thematik auf, allerdings im Kontext von Multimedia-Anwendungen. Durch die Betrachtung von Geräten als Ressource ergeben sich zudem neue Herausforderungen im Bereich der Servicebeschreibung und der Prozessmodellierung. Es ist zu prüfen, ob existierende Methoden zur Servicebeschreibung ausreichen, um Aspekte wie z. B. mögliche Gerätezustände, Lokalität, Lebensdauer, etc. abzubilden. Hinsichtlich der Prozessmodellierung ist der Umstand neu, dass (im Gegensatz zu Software-Services) Geräte-Services für eine exklusive Nutzung reserviert werden müssen. Hierbei wird die Wahl des Services nicht automatisiert vorgenommen, der Benutzer muss in der Regel manuell das konkrete Gerät auswählen, das am Prozess beteiligt sein soll. Bei stationären Geräten kann diese Auswahl auch automatisiert erfolgen, wenn einem Arbeitsplatz ein bestimmtes Gerät fest zugeordnet ist oder das örtlich nächst gelegene Gerät gewählt werden soll. Alternativ sind RFID-Szenarien denkbar, so dass das Gerät den Patienten und seinen Kontext erkennt. Diese Besonderheiten werden in den Beiträgen, die Orchestrierung und Prozess Management thematisieren ([2], [18], [13], [20]), nur ungenügend adressiert. 4. Zusammenfassung und Ausblick Anhand einer Literaturanalyse wurde gezeigt, dass insbesondere im medizinischen Kontext die serviceorientierte Integration von Geräten noch kaum erforscht ist. In anderen Domänen, wie z. B. der industriellen Automatisierung, ist die Forschung bereits weiter fortgeschritten, jedoch gelten viele der identifizierten Forschungslücken auch für diese Bereiche. Zudem ist genau zu prüfen, inwiefern Konzepte, die nicht speziell für die medizinische Domäne entwickelt wurden, übertragbar sind. Voraussetzung dafür ist eine umfassende Anforderungsanalyse, die aber in existierenden Beiträgen nicht gefunden werden konnte. Die Erstellung einer solchen Anforderungsanalyse ist daher nach der Zusammenstellung des State of the Art der nächste logische Schritt und Basis für unsere weitere Forschung in diesem Gebiet. 126 5. Literaturverzeichnis [1] ALI, S.; KIEFER, S., Semantic Medical Devices Space: An Infrastructure for the Interoperability of Ambient Intelligent Medical Devices, Ioannina - Epirus, Greece: 2006. [2] BOBEK, A. et al., Enabling workflow in UPnP networks, Industrial Informatics, 2005. INDIN '05. 2005 3rd IEEE International Conference on, 2005, S. 166-171. [3] BOHN, H.; BOBEK, A; GOLATOWSKI, F., SIRENA - Service Infrastructure for Real-time Embedded Networked Devices: A service oriented framework for different domains, Networking, International Conference on Systems and International Conference on Mobile Communications and Learning Technologies, 2006. ICN/ICONS/MCL 2006. International Conference on, 2006, S. 43. [4] CACHAPA, D. et al., An approach for integrating real and virtual production automation devices applying the service-oriented architecture paradigm, Emerging Technologies & Factory Automation, 2007. ETFA. IEEE Conference on, 2007, S. 309-314. [5] COLOMBO, A. et al., Service-oriented architectures for collaborative automation, Industrial Electronics Society, 2005. IECON 2005. 31st Annual Conference of IEEE, 2005, S. 6 pp. [6] DEUGD, S. D. et al., SODA: Service Oriented Device Architecture, in: IEEE Pervasive Computing, vol. 5, 2006, S. 94-96, c3. [7] DITZE, M. et al., Service-based access to distributed embedded devices through the open service gateway, Industrial Informatics, 2004. INDIN '04. 2004 2nd IEEE International Conference on, 2004, S. 493-498. [8] DITZE, M. et al., Quality of Service and Proactive Content Replication in UPnP based A/V Environments, Innsbruck: 2005, S. 729-734. [9] GILART-IGLESIAS, V. et al., Normalization of Industrial Machinery with Embedded Devices and SOA, Emerging Technologies and Factory Automation, 2006. ETFA '06. IEEE Conference on, 2006, S. 173-180. [10] GLASCHICK, R.;. OESTERDIECKHOFF, B.; LOESER, C., Service oriented interface design for embedded devices, Emerging Technologies and Factory Automation, 2005. ETFA 2005. 10th IEEE Conference on, 2005, S. 8 pp. [11] GOUVAS, P.; BOURAS, T.; MENTZAS, G., An OSGi-Based Semantic Service-Oriented Device Architecture, 2007. [12] HEVNER, A. R. et al., Design Science in Information Systems Research, in: MIS Quarterly, vol. 28, 2004. [13] ILLNER, S. et al., Model-based management of embedded service systems-an applied approach, Advanced Information Networking and Applications, 2006. AINA 2006. 20th International Conference on, 2006, S. 5 pp. [14] JÄHN, K.; ECKHARD, N., e-Health, Springer, Berlin, 2004. [15] JAMMES, F.; SMIT, H., Service-oriented paradigms in industrial automation, Industrial Informatics, IEEE Transactions on, vol. 1, 2005, S. 62-70. [16] JAMMES, F.; SMIT, H., Service-oriented architectures for devices - the SIRENA view,” Industrial Informatics, 2005. INDIN '05. 2005 3rd IEEE International Conference on, 2005, S. 140-147. [17] JAMMES, F. et al., Intelligent device networking in industrial automation, Industrial Informatics, 2004. INDIN '04. 2004 2nd IEEE International Conference on, 2004, S. 449-456. [18] JAMMES, F. et al., Orchestration of service-oriented manufacturing processes,” Emerging Technologies and Factory Automation, 2005. ETFA 2005. 10th IEEE Conference on, 2005, S. 8 pp. [19] JAMMES, F.; MENSCH, A.; SMIT, H., Service-Oriented Device Communications Using the Devices Profile for Web services, Advanced Information Networking and Applications Workshops, 2007, AINAW '07. 21st International Conference on, 2007, S. 947-955. 127 [20] KAMNENG, M. L. M. et al., Prozessintegration mobiler Landmaschinen mittels automatisch erzeugter BPELProzesse, in: Wirtschaftsinformatik, vol. 49, 2007, S. 289-294. [21] KARNOUSKOS, S. et al., Integration of SOA-ready networked embedded devices in enterprise systems via a cross-layered web service infrastructure, Emerging Technologies & Factory Automation, 2007. ETFA. IEEE Conference on, 2007, S. 293-300. [22] KARNOUSKOS, S.; TARIQ, M. M. J., An Agent-Based Simulation of SOA-Ready Devices, Computer Modeling and Simulation, 2008. UKSIM 2008. Tenth International Conference on, 2008, S. 330-335. [23] KRAFZIG, D.; BANKE, K.; SLAMA, D., Enterprise SOA: Service Oriented Architecture Best Practices, Prentice Hall International, 2004. [24] KRCMAR, H., Informationsmanagement, Springer, Berlin, 2004. [25] LESH, K. et al., Medical Device Interoperability-Assessing the Environment, High Confidence Medical Devices, Software, and Systems and Medical Device Plug-and-Play Interoperability, 2007. HCMDSS-MDPnP. Joint Workshop on, 2007, S. 3-12. [26] MAURO, C. et al., A Proposed Solution for Managing Doctor’s Smart Cards in Hospitals Using a Single Sign-On Central Architecture, Proceedings of the Hawaii International Conference on System Sciences (HICSS 41), Big Island, Hawaii: 2008. [27] MERRIAM-WEBSTER, “Merriam-Webster's Medical Dictionary”; http://dictionary.reference.com/browse/communication. [28] OESTERDIECKHOFF, B. et al., Integrative approach of Web services and universal plug and play within an AV scenario, Industrial Informatics, 2005. INDIN '05. 2005 3rd IEEE International Conference on, 2005, S. 123-128. [29] SCHWEIGER, A. et al., Toward Seamless Healthcare with Software Agents, in: Communications of the Association for Information Systems, vol. 19, 2007, S. 692-709. [30] DE SOUZA, L. M. S. et al., SOCRADES: A Web Service based Shop Floor Integration Infrastructure, 2008. [31] SPIESS, P.; KARNOUSKOS, S., Maximizing the Business Value of Networked Embedded Systems through Process-Level Integration into Enterprise Software, Pervasive Computing and Applications, 2007. ICPCA 2007. 2nd International Conference on, 2007, S. 536-541. [32] STRÄHLE, M. et al., Towards a Service-Oriented Architecture for Interconnecting Medical Devices and Applications, High Confidence Medical Devices, Software, and Systems and Medical Device Plug-and-Play Interoperability, 2007. HCMDSS-MDPnP. Joint Workshop on, 2007, S. 153-155. [33] SUNYAEV, A. et al., Integrationsarchitekturen für das Krankenhaus - Status quo und Zukunftsperspektiven, in: Information Management & Consulting, vol. 21, 2006, S. 28-35. [34] WEBSTER, J.; WATSON, R. T., Analyzing the Past to Prepare for the Future: Writing a Literature Review, in: MIS Quarterly, vol. 26, 2002. [35] ZEEB, E. et al., Lessons learned from implementing the Devices Profile for Web Services, Digital EcoSystems and Technologies Conference, 2007. DEST '07. Inaugural IEEE-IES, 2007, S. 229-232. [36] ZEEB, E. et al., Service-Oriented Architectures for Embedded Systems Using Devices Profile for Web Services, Advanced Information Networking and Applications Workshops, 2007, AINAW '07. 21st International Conference on, 2007, S. 956-963. 128 EIN ALLGEMEINER ANSATZ ZUR ABLEITUNG VON ABHÄNGIGKEITSANALYSEN AUF UNTERNEHMENSARCHITEKTURMODELLEN Stephan Kurpjuweit, Stephan Aier1 Kurzfassung Der Nutzen von Unternehmensarchitekturmodellen liegt unter anderem in der Bereitstellung bedarfsgerechter Abhängigkeitsanalysen. Die praktische Herausforderung besteht darin, beliebige Analysen auf Instanzen von vorab nicht vollständig bekannten, unternehmensspezifischen Architekturmetamodellen durchführen zu können. Der Beitrag entwirft darum eine allgemeine und formale Lösung dieses Problems, welche sich für die Implementierung in Unternehmensarchitekturmanagement-Werkzeugen eignet. 1. Einleitung Nach ANSI/IEEE Std 1471-2000 ist Architektur definiert als ”the fundamental organization of a system, embodied in its components, their relationships to each other and the environment” [8]. Die Unternehmensarchitektur ist die fundamentale Strukturierung einer Organisation (Unternehmen, öffentliche Institution etc.) und bildet die Gestaltungsobjekte der Organisation und deren Beziehungen in Modellen ab. Die Bandbreite der Gestaltungsobjekte reicht dabei von der Strategie, über die Aufbau- und Ablauforganisation bis hin zu Elementen der Daten- und Softwarearchitektur sowie der technischen Infrastruktur [3, 13]. Aufbauend auf der Dokumentation der Strukturen einer Organisation können Unternehmensarchitekturmodelle nach [10] in sehr unterschiedlichen Szenarien (z. B. Produkteinführung, IT-Konsolidierung, Mergers&Acquisitions) genutzt werden, in denen die wechselseitigen Abhängigkeiten der Gestaltungsobjekte von Bedeutung sind. Typische Fragen in diesem Zusammenhang sind: „Welche Produkte werden durch welche Prozesse unter Zuhilfenahme welcher Applikationen erstellt?“, „Welche Dienstleistungen sind betroffen bei Ausfall eines Serverclusters“ oder „Wie ist der Beitrag einzelner Geschäftseinheiten oder Geschäftsprozesse zu den Unternehmenszielen?“. Zur Beantwortung dieser Fragen werden die betreffenden Gestaltungsobjekte gefiltert, in Beziehung gesetzt und übersichtlich z. B. als Matrix dargestellt [2]. Die praktische Herausforderung besteht dann darin, genau die Abhängigkeitsanalysen zur Verfügung zu stellen, die für die Stakeholder den größten Nutzen erzeugen. Die Erfahrung aus Praxisprojekten zeigt jedoch drei Dinge: (1) Statt starrer Standardauswertungen wünschen sich die Stakeholder flexible „Navigationsfunktionalitäten“ zur interaktiven Erschließung der strukturellen Zusam1 Universität St. Gallen, Müller-Friedberg-Strasse 8, CH-9000 St. Gallen 129 menhänge in der Unternehmensarchitektur. (2) Nicht für jede Situation respektive jede Organisation kann das gleiche Metamodell verwendet werden. (3) Existierende Ansätze und Werkzeuge zur Modellierung und Analyse der Unternehmensarchitektur basieren auf mehr oder weniger starren Metamodellstrukturen. Komplexere Abhängigkeitsanalysen sind auf dieser Struktur meist „fest verdrahtet“ und können nur sehr begrenzt und mit hohem Aufwand angepasst werden. Dies führt zu der Anforderung an zukünftige Werkzeuge, flexible Abhängigkeitsanalysen generisch auf Basis eines flexiblen Metamodells zu unterstützen. Dabei sind eine Reihe von Herausforderungen, wie inkonsistente Semantiken von Hierarchien unterschiedlicher Gestaltungsobjekte, verschiedene Formen der Abhängigkeiten oder transitive Abhängigkeiten über eine Vielzahl von Gestaltungsobjekten hinweg, zu berücksichtigen. Das Ziel dieses Beitrags ist es, basierend auf bestehenden relationalen Ansätzen eine allgemeine formale Lösung für die Ableitung von Abhängigkeitsanalysen zu entwickeln. Die Formalisierung unserer Lösung ist dabei notwendig, um sie eindeutig zu spezifizieren und in entsprechenden Werkzeugen implementieren zu können. Der Ansatz geht dabei von möglichst wenigen Grundannahmen aus, um die Anwendbarkeit mit möglichst vielen Ansätzen zur Modellierung der Unternehmensarchitektur sicherzustellen (Abschnitt 2). Wir beschränken uns in der Darstellung auf zweidimensionale Abhängigkeitsanalysen, welche die Abhängigkeiten zwischen je zwei Typen von Gestaltungsobjekten analysieren und die Basis darstellen für komplexere Abhängigkeitsanalysen (Abschnitt 3). Dabei berücksichtigen wir Anforderungen, die sich in Praxisfallstudien [1] als relevant herausgestellt haben: reflexive Beziehungsklassen (Abschnitt 4), hierarchische Verfeinerung (Abschnitt 5) sowie die aggregierte Betrachtung von Abhängigkeiten (Abschnitt 6). Die Effektivität der Lösung soll durch Praxisbeispiele belegt werden. 2. Metamodell Dem Ansatz liegt folgende Annahme zugrunde: Unternehmensarchitekturen werden als Modelle in einer Modellierungssprache beschrieben. Ein Metamodell ist ein Modell einer Modellierungssprache [6, 9, 12]. Es spezifiziert die verfügbaren Arten von Gestaltungsobjekten, die Beziehungen zwischen den Gestaltungsobjekten sowie Konsistenzbedingungen für die Verwendung von Gestaltungsobjekten und Beziehungen [11]. In Anlehnung an [5] definieren wir ein Metamodell (M) als ein 3-Tupel: M = (C , T , R) , wobei gilt: • C ist eine Menge von Gestaltungsklassen (kurz: Klassen). • T ist eine Menge von Beziehungstypen (kurz: Typen). Für jeden Typ t ∈ T existiert ein Umkehrtyp t −1 ∈ T mit (t −1 ) −1 = t . • R ⊆ C × C × T ist eine Menge von Beziehungsklassen zwischen Gestaltungsklassen. Ein Element (c1 , c2 , t ) ∈ R ist dabei eine Beziehungsklasse des Typs t zwischen den Klassen c1 und c 2 . Die Granularität der Beziehungstypen ist beliebig: In den Extremfällen existiert in dem Metamodell nur ein Typ für alle Beziehungsklassen oder ein eigener Typ für jede Beziehungsklasse. [5] enthält ein Beispiel mit einem relativ feingranularen System an Beziehungstypen. In all unseren Praxisfallstudien waren die in Tabelle 1 dargestellten drei Beziehungstypen Assoziation, Aggregation und Generalisierung mit ihren jeweiligen Umkehrtypen ausreichend, wobei Assoziationen aussagekräftige Namen erhielten. 130 Tabelle 1: Beziehungstypen t ∈T Assoziation Aggregation Generalisierung t −1 ∈ T Assoziation Teil-Ganzes-Beziehung Ganzes-Teil-Beziehung Generalisierung Spezialisierung Assoziation Ganzes-Teil-Beziehung Teil-Ganzes-Beziehung Spezialisierung Generalisierung 3. Zweidimensionale Abhängigkeitsanalysen (2dA) Zahlreiche Strukturfragen zur Analyse der Unternehmensarchitektur sind vom Typ „Wie ist der Zusammenhang zwischen den Instanzen der Gestaltungsklassen a und b ?“ (z. B. „Durch welche Applikationen werden die einzelnen Geschäftsprozesse unterstützt?“). Im einfachsten Fall sind die beiden Klassen a, b ∈ C im Metamodell direkt durch eine Beziehungsklasse r verbunden. In diesem Fall kann eine 2dA unmittelbar aus den Instanzen der Beziehungsklasse r abgeleitet und beispielsweise als Matrix dargestellt werden (siehe Abbildung 1). b1 b2 a1 X X a2 X a b1 b2 b3 b4 a1 a2 a3 r b a (a) Metamodell r a3 b3 b4 X X X X b (c) zweidimensionale Abhängigkeitsanalyse (als Matrix) (b) Modell Abbildung 1: Beispiel einer einfachen zweidimensionalen Abhängigkeitsanalyse Sind zwei Klassen c1 , c 2 ∈ C nicht direkt durch eine Beziehungsklasse verbunden, muss eine transitive Beziehungsklasse aus den Beziehungsklassen des Metamodells abgeleitet werden. [5] hat hierzu Vorarbeiten geleistet, die in diesem Abschnitt aufgezeigt und erweitert werden. Wir definieren zunächst einen Kompositionsoperator für Beziehungstypen ⊗ : T * × T * → T * . Nachdem die Komposition zweier Beziehungstypen t1 , t 2 ∈ T einen Beziehungstyp t3 ∉ T ergeben kann, der nicht in dem Metamodell verwendet wird, definiert T * eine Erweiterung von T um alle Beziehungstypen, die bei der Komposition von Beziehungstypen aus T * resultieren können. Tabelle 2 spezifiziert einen einfachen Kompositionsoperator für das Typsystem aus Tabelle 1, welches wir um den Typ „undefiniert“ ergänzen. Es besteht die Möglichkeit, den Kompositionsoperator zu detaillieren (z. B. indem die Kombination aus Aggregation und Generalisierung zu einer Beziehung des Typs „Verfeinerung“ komponiert wird.). Tabelle 2: Kompositionsoperator für Beziehungstypen t1 Assoziation * Teil-Ganzes-Beziehung Ganzes-Teil-Beziehung Generalisierung Spezialisierung t2 * Assoziation Teil-Ganzes-Beziehung Ganzes-Teil-Beziehung Generalisierung Spezialisierung sonst t1 ⊗ t 2 Assoziation Assoziation Teil-Ganzes-Beziehung Ganzes-Teil-Beziehung Generalisierung Spezialisierung undefiniert Legende: „*“ steht als Platzhalter für alle Typen, „sonst“ steht als Platzhalter für alle nicht aufgeführten Paarungen 131 Wir definieren rekursiv die Mengen der 2-Schritt Beziehungsklassen R 2 , der n-Schritt Beziehungsklassen R n und die transitive Hülle R * der Menge der Beziehungsklassen2: 1a) ∀c1 , c2 , c3 ∈ C∀t1 , t 2 ∈ T : (c1 ≠ c2 ) ∧ (c2 ≠ c3 ) ∧ (c1 , c2 , t1 ) ∈ R ∧ (c2 , c3 , t 2 ) ∈ R ⇒ (c1 , c3 , t1 ⊗ t 2 ) ∈ R 2 1b) ∀c1 , c2 , c3 ∈ C∀t1 , t 2 ∈ T : (c1 ≠ c2 ) ∧ (c2 ≠ c3 ) ∧ (c1 , c2 , t1 ) ∈ R ∧ (c3 , c2 , t 2 ) ∈ R ⇒ (c1 , c3 , t1 ⊗ t 2−1 ) ∈ R 2 2a) ∀c1 , cn−1 , c n ∈ C∀t1 , t 2 ∈ T * : (c1 ≠ cn−1 ) ∧ (cn−1 ≠ cn ) ∧ (c1 , cn−1 , t1 ) ∈ R n−1 ∧ (cn−1 , cn , t 2 ) ∈ R ⇒ (c1 , cn , t1 ⊗ t 2 ) ∈ R n 2b) ∀c1 , cn−1 , c n ∈ C∀t1 , t 2 ∈ T * : (c1 ≠ cn−1 ) ∧ (cn−1 ≠ cn ) ∧ (c1 , cn−1 , t1 ) ∈ R n−1 ∧ (cn , cn−1 , t 2 ) ∈ R ⇒ (c1 , c n , t1 ⊗ t 2−1 ) ∈ R n ∞ 3) R* = U R n n =1 Damit die Definitionen von R 2 , R n und R * eindeutig sind, muss der Kompositionsoperator ⊗ assoziativ sein, d. h. ∀t1 , t 2 , t3 ∈ T * : (t1 ⊗ t 2 ) × t3 = t1 ⊗ (t 2 × t3 ) (B1). Abbildung 2 veranschaulicht die Ableitung von 2-Schritt Beziehungsklassen und die Notwendigkeit der Formel (1b)3: Da die Beziehungsklassen gerichtet sind, wird in dem dargestellten Beispiel durch Formel (1a) keine transitive Beziehungsklasse zwischen c1 und c3 abgeleitet, obwohl eine 2dA zwischen diesen Klassen möglich ist. Formel (2b) begründet sich mit dem gleichen Argument. Für den Kompositionsoperator ergibt sich als weitere Bedingung: ∀t1 , t 2 ∈ T * : (t 2 ⊗ t1−1 ) = (t1 ⊗ t 2−1 ) −1 (B2). Die Bedingungen (B1) und (B2) können für das in den Tabellen 1 und 2 spezifizierte Typsystem einfach durch Wertetabellen nachgewiesen werden. c2 t1 c1 t2 t1 ⊗ t2-1 t2 ⊗ t1-1 c3 Abbildung 2: Ableitung von 2-Schritt Beziehungsklassen Auf Basis des Kompositionsoperators für Beziehungstypen kann nun der Kompositionsoperator für Beziehungsklassen: ⊗ R : R * × R * → R * definiert werden. Der Projektionsoperator π i ergibt dabei das i-te Element jedes Tupels in R * : ⎧ (π 1(r1 ),π 2(r2 ),π 3(r1 ) ⊗π 3(r2 )), falls π 1(r2 ) =π 2(r1 ) ∧π 1(r1 ) ≠π 2(r1 ) ∧π 1(r2 ) ≠π 2(r2 ) ⎪ 4) r1 ⊗ R r2 = ⎨(π 1(r1 ),π 1(r2 ),π 3(r1 ) ⊗π 3(r2 ) −1 ), falls π 2(r2 ) =π 2(r1 ) ∧π 1(r1 ) ≠π 2(r1 ) ∧π 1(r2 ) ≠π 2(r2 ) ⎪ undefiniert sonst ⎩ c ∈ C , t ∈ T * (d. h. Beziehungs2 klassen einer Gestaltungsklasse zu sich selbst) aufgrund ihrer speziellen Semantik aus den Definitionen von R , R n und R * aus. Sie werden in Abschnitt X gesondert behandelt. 2 Als Ergänzung zu [5] schließen wir reflexive Kanten der Form (c, c, t ) ∈ R für ein 3 Die Formeln (1b) und (2b) sind eine weitere Ergänzung zu [5]. Durch diese Formeln begründet sich auch das Konzept der Umkehrtypen in der Definition des Metamodells. 132 Die bisherige Betrachtung fand auf der Ebene des Metamodells statt. Zur Ableitung einer Abhängigkeitsanalyse muss jedoch die Modellebene betrachtet werden. Wiederum in Anlehnung an [5] definieren wir: Ein Modell (A) ist definiert als ein 4-Tupel A = ( E , T *, Q, Fc ) mit: • E ist eine Menge von Gestaltungsobjekten (Instanzen von Gestaltungsklassen, kurz: Objekte). • T * ist eine Menge von Beziehungstypen. (Dabei handelt es sich um die Beziehungstypen aus dem Metamodell.) • Q ⊆ E × E × T * Ist eine Menge von Beziehungen zwischen den Gestaltungsobjekten. • Fc : E → C ist eine Funktion, die jedes Gestaltungsobjekt einer Gestaltungsklasse zuordnet. Ec = {e ∈ E | Fc (e) = c} ist die Menge aller Objekte der Klasse c ∈ C . Ein Modell A = ( E , T *, Q, Fc ) entspricht einem Metamodell M = (C , T , R ) genau dann, wenn ∀t ∈ T *∀e1 , e2 ∈ E : (e1 , e2 , t ) ∈ Q ⇒ ( Fc (e1 ), Fc (e2 ), t ) ∈ R . Analog zum Metamodell lässt sich die transitive Hülle Q * der Menge der Beziehungen rekursiv über 2-Schritt Beziehungen Q 2 und nSchritt Beziehungen Q n definieren. Aus Platzgründen wird nur die Formel für Q 2 angegeben, Q n ergibt sich analog zu den Formel 2a und b. 5a) ∀e1 , e2 , e3 ∈ E∀t1 , t 2 ∈ T * : (e1 ≠ e2 ) ∧ (e2 ≠ e3 ) ∧ (e1 , e2 , t1 ) ∈ Q ∧ (e2 , e3 , t 2 ) ∈ Q ⇒ (e1 , e3 , t1 ⊗ t 2 ) ∈ Q 2 5b) ∀e1 , e2 , e3 ∈ E∀t1 , t 2 ∈ T * : (e1 ≠ e2 ) ∧ (e2 ≠ e3 ) ∧ (e1 , e2 , t1 ) ∈ Q ∧ (e3 , e2 , t 2 ) ∈ Q ⇒ (e1 , e3 , t1 ⊗ t 2−1 ) ∈ Q 2 ∞ 6) Q * = U Q n n =1 Zwei Objekte e1 ,e 2 ∈ E stehen dann miteinander über eine Beziehung des Typs t ∈ T in Beziehung, wenn gilt: (e1 , e2 , t ) ∈ Q * . Analog zu dem Kompositionsoperator für Beziehungsklassen (Formel 6) lässt sich der Kompositionsoperator für Beziehungen ⊗ Q : Q * × Q * → Q * definieren. Im Folgenden bezeichne Qc1 ,c2 = {(e1 , e2 , t ) ∈ Q * | e1 ∈ Ec1 ∧ e1 ∈ Ec2 } die Menge aller Beziehungen zwischen Objekten der Klasse c1 ∈ C und c 2 ∈ C . Soll eine 2dA abgeleitet werden, um den Zusammenhang zwischen den Objekten zweier Klassen c1 , c 2 ∈ C darzustellen, kann hierzu jede (direkte oder abgeleitete) Beziehungsklasse aus der Menge Rc1 ,c2 ⊆ R * herangezogen werden: Rc1 ,c2 = {r ∈ R * | (π 1 (r ) = c1 ∧ π 2 ( r ) = c2 ) ∨ (π 1 (r ) = c2 ∧ π 2 (r ) = c1 ))} Die einzelnen Beziehungsklassen in Rc1 ,c2 unterscheiden sich im Typ und/oder der Richtung. Im Fall Rc1 ,c2 = ∅ kann keine 2dA zwischen den Klassen c1 und c 2 abgeleitet werden. Im Fall Rc1 ,c2 > 1 stehen mehrere Beziehungsklassen unterschiedlichen Typs und/oder Richtung zur Verfügung, welche alternativ zur Ableitung einer 2dA herangezogen werden können. Auch lässt sich für jede Klasse c1 die Menge Cc1 ⊆ C aller Klassen angeben, die überhaupt zur Ableitung einer 2dA in Frage kommen: Rc1c2 ≠ ∅ ⇒ c2 ∈ Cc1 . Beachte, dass die Granularität der Beziehungstypen 133 und die Definition des Kompositionsoperators ⊗ potentiellen Einfluss auf die Anzahl der Typen und auf die Mächtigkeit der Menge Rc1 ,c2 haben. 4. Reflexive Beziehungsklassen In der bisherigen Betrachtung wurden reflexive Kanten im Metamodell, d. h. Beziehungsklassen einer Gestaltungsklasse zu sich selbst mit (c, c, t ) ∈ R für c ∈ C , t ∈ T * , ausgeklammert. Beispiele für reflexive Beziehungsklassen sind die Assoziationen kommuniziert mit zwischen Objekten der Kasse Organisationseinheit oder ist vernetzt mit zwischen Objekten der Klasse Server. e21 c1 r1 c2 r3 e24 e12 c1 r1 (a) Metamodell e31 e32 e26 r3 e25 r2 c3 e23 e22 e11 e27 e28 e29 c2 r2 c3 (b) Modell Abbildung 3: Reflexive Beziehungsklasse im Kontext Abbildung 3 zeigt Beziehungen von und zu Objekten einer Klasse c 2 mit einer reflexiven Beziehungsklasse r3 . Für eine Klasse c ∈ C bezeichne Qc = {(e1 , e2 , t ) ∈ Q * | e1 ∈ Ec ∧ e2 ∈ Ec } die Menge aller Beziehungen zwischen Objekten der Klasse c , die definitionsgemäß Beziehungen reflexiver Beziehungsklassen sind. Bei der Ableitung der komponierten Beziehungen zwischen Objekten der Klassen c1 und c3 gibt es, in Abhängigkeit von der Semantik der reflexiven Beziehungsklasse r3 , verschiedene Möglichkeiten. Beispielsweise ist denkbar, dass zwei Objekte e1 ∈ Ec1 und e3 ∈ Ec3 dann über eine komponierte Beziehung (e1 , e3 , t1 ⊗ t 2 ) ∈ Qc1c3 verbunden sind, wenn es ein Objekt e2 ∈ Ec2 gibt mit (e1 , e2 , t1 ) ∈ Qc1c2 und (e2 , e3 , t 2 ) ∈ Qc2c3 für t1 , t 2 ∈ T * (direkte Verbindung). In Abbildung 3 ist dies beispielsweise für die Objekte e11 und e31 der Fall, welche über das Objekt e21 in Beziehung stehen. Dies entspricht der Semantik des in Abschnitt 3 eingeführten Kompositionsoperators ⊗ Q . Eine weitere Möglichkeit ist, dass e1 und e3 über die transitive Hülle der Beziehungen aus Qc2 verbunden sind (d. h. es gilt (e1 , e3 , t1 ⊗t 3 ⊗t 2 ) ∈ Q13 , wenn es Objekte e21 , e22 ∈ Ec2 gibt mit (e1 , e21 , t1 ) ∈ Qc1c2 und (e22 , e3 , t 2 ) ∈ Qc2c3 und (e21 , e22 , t 3 ) ∈ Qc+2 für t1 , t 2 , t 3 ∈ T * ) (transitive Verbindung). In Abbildung 3 ist dies beispielsweise für die Objekte e12 und e31 der Fall, welche über die Objekte e24 , e22 und e21 in Beziehung stehen. Dies kann auch so interpretiert werden, dass die Beziehung zwischen e12 und e24 implizit auch zwischen e12 und e22 sowie zwischen e12 und e21 gilt. Neben der direkten Verbindung und der transitiven Verbindung sind weitere kontextspezifische Semantiken für reflexive Beziehungsklassen und deren Zusammenwirken denkbar, insbesondere wenn eine Klasse mehrere reflexive Beziehungsklassen (z. B. vom Typ Generalisierung und Aggregation) besitzt. Als allgemeiner Ansatz zur Spezifikation verschiedener Semantiken reflexiver Beziehungsklassen lassen sich Funktionen der Form ext c1c2 : Ec1 × Ec2 × T * → Pot ( E c1 × E c2 × T * ) angeben, die eine Beziehung zwischen Objekten der Klassen c1 , c2 ∈ C expandieren. Pot(X) bezeichne dabei die Potenzmenge, also die Menge aller Teilmengen, der Menge X . Die Expansion 134 einer Beziehung bedeutet, dass weitere Beziehungen erzeugt werden, die aufgrund der expliziten Beziehung implizit gelten. Nun kann die Gesamtmenge aller expandierten Beziehungen Q exp wie folgt berechnet werden: Qcexp = 1c2 U exp q∈Qc1c 2 c1c2 (q) und Q exp = UQ c1 ,c2 ∈C exp c1c2 Wobei die Funktionen extc1c2 für je zwei Klassen c1 , c2 ∈ C die gewünschte Semantik der reflexiven Beziehungsklassen repräsentieren muss. Die Komposition der Beziehungen und die Berechnung * der transitiven Hülle Q exp der expandierten Beziehungen kann zu Q * mit Hilfe des in Abschnitt 3 eingeführten Kompositionsoperators ⊗ Q durchgeführt werden. 5. Hierarchische Verfeinerung Eine häufige Verwendung reflexiver Beziehungsklassen bei der Modellierung von Unternehmensarchitekturen ist die hierarchische Verfeinerung von Gestaltungsobjekten. Beispielsweise haben sich in den Praxisfallstudien reflexive Beziehungsklassen der Beziehungstypen „Aggregation“ (z. B. zur Zerlegung eines Geschäftsprozesses in Teilprozesse oder von Softwarekomponenten in Subkomponenten) und „Generalisierung“ (z. B. zur Zusammenfassung mehrere Produkte zu einer Produktlinie) als wichtiges Modellierungsvokabular herausgestellt. In diesem Abschnitt wird daher untersucht, wie die Expansionsfunktion exp für hierarchische Verfeinerungsbeziehungen zu definieren ist. Wir nehmen hierzu an, dass die Gestaltungsobjekte Ec1 einer Klasse c1 in einer Verfeinerungsbeziehung stehen, die durch eine Relation auf P ⊆ Ec1 × Ec1 beschrieben ist: (e1 , e2 ) ∈ P bedeutet, dass e1 eine Verfeinerung (z. B. eine Spezialisierung oder Teil ein Zerlegung) von e2 ist. Die Verfeinerungsrelation kann aus den Beziehungen aus Qc1 abgeleitet werden, im einfachsten Fall durch P = {(π 1 (q), π 2 (q)) | q ∈ Qc1 } . Durch die Verfeinerungsbeziehung soll ausgedrückt werden, dass ein Objekt e durch ein oder mehrere untergeordnete Objekte verfeinert wird und/oder ein oder mehrere übergeordnete Objekte verfeinert. Nicht erlaubt ist, dass ein Objekt eine Verfeinerung von sich selbst ist, weshalb der durch die Verfeinerungsrelation aufgespannte Graph kreisfrei (nicht zu verwechseln mit zykelfrei) sein muss. Der in Abbildung 3 dargestellte Verfeinerungsbaum der Beziehungen aus Qc2 erfüllt diese Bedingung. In Anlehnung an [4] definieren wir für ein Objekt e ∈ E die Verfeinerungsrelation Pe↓ , welche alle e untergeordneten Objekte auf e abbildet: Pe↓ = P + ran {e} . P + ist dabei die transitive Hülle von P , die im Wertebereich auf die Menge {e} eingeschränkt wird ( ran ). Der Definitionsbereich Ee↓ = dom( Pe↓ ) beinhaltet alle e untergeordneten Objekte. Analog definieren wir die Verfeinerungsrelation Pe↑ , welche e auf alle e übergeordneten Objekte abbildet: Pe↑ = P + dom {e} . Der Wer- tebereich Ee↑ = ran( Pe↑ ) beinhaltet alle e übergeordneten Objekte. In Abbildung 3 gilt beispielsweise Pe23 ↓ = {e26 , e28 , e27 , e29 } und Pe27 ↑ = {e26 , e23 , e21} . Gegeben seien zwei Gestaltungsklassen c1 und c 2 und zwei Gestaltungsobjekte e1 ∈ c1 und e2 ∈ c2 , für die jeweils sowohl übergeordnete als auch untergeordnete Objekte existieren. e1 und e2 stehen weiterhin miteinander in Beziehung, d. h. es existiert ein q ∈ Qc1c2 mit q = (e1 , e2 , t ) für ein t ∈ T * . Die Fallstudienbeispiele zeigen, dass eine Be- 135 ziehung von bzw. zu einem Gestaltungsobjekt e , das sich in einer hierarchischen Verfeinerungsbeziehung befindet, mit unterschiedlicher Semantik belegt sein kann (Gültigkeitstypen): (1) Die Beziehung gilt ausschließlich für das Objekt e . Es wird keine Aussage getroffen bezüglich übergeordneter und untergeordneter Objekte. (Beispiel: Beziehung hat Entwicklungsverantwortung für eines IT-Zulieferers zu Softwarekomponenten.) (2) Die Beziehung gilt implizit auch für alle untergeordneten Objekte. (Beispiel: Beziehung ist verantwortlich für zwischen Organisationseinheiten und Geschäftsprozessen, wenn die Organisationseinheit auch stets verantwortlich für alle Teilprozesse ist.) (3) Die Beziehung gilt implizit auch für alle übergeordneten Objekte. (Beispiel: Beziehung wird genutzt in zwischen Applikationen und Geschäftsprozessen. Wird eine Applikation in einem Teilprozess genutzt, wird diese definitionsgemäß auch in dem übergeordneten Prozess genutzt.) (4) Die Beziehung gilt implizit auch für alle übergeordneten und untergeordneten Objekte. Bei der Definition der Expansionsfunktion ext c1c2 : Ec1 × Ec2 × T * → Pot ( Ec1 × Ec2 × T * ) müssen diese unterschiedlichen Semantiken berücksichtigt werden. Für eine Beziehung q ∈ Qc1c2 gilt sowohl für das Ausgangsobjekt e1 als auch für das Zielobjekt e2 je einer der vier Gültigkeitstypen, wodurch sich 16 Erweiterungsfunktionen ergeben: ext c1c2 − − , ext c1c2 ↑− , ext c1c2 ↓− , extc1c2 b− , ext c1c2 −↑ , ext c1c2 ↑↑ , ext c1c2 ↓↑ , extc1c2 b↑ , ext c1c2 −↓ , ext c1c2 ↑↓ , ext c1c2 ↓↓ , extc1c2 b↓ , extc1c2 −b , extc1c2 ↑b , extc1c2 ↓b , extc1c2 bb . Der erste Pfeil gibt für die Verfeinerungsbeziehung des Ausgangsobjekts an, ob die Beziehung nur für das Ausgangsobjekt ( − ), implizit für alle übergeordneten Objekte ( ↑ ), alle untergeordneten Objekte ( ↓ ) oder beides gilt ( b ). Der zweite Pfeil gibt dies entsprechend für die Verfeinerungsbeziehung des Zielobjekts an. Zwei der Funktionen sind exemplarisch wie folgt definiert; alle übrigen Funktionen lassen sich analog definieren: ext c1c2 ↑− ((e1 , e2 , t )) = Ee1↑ × {e2 } × {t} und extc1c2 bb ((e1 , e2 , t )) = Ee1↑ ∪ Ee1↓ × Ee 2↑ ∪ Ee 2↓ × {t} 6. Aggregierte Betrachtung von Beziehungen Oft sind die Strukturen komplex, die sich durch Beziehungen zwischen Objekten von hierarchisch verfeinerbaren Gestaltungsklassen ergeben. Zur Komplexitätsreduktion kann es in Abhängigkeitsanalysen sinnvoll sein, die unteren Verfeinerungsebenen auszublenden. Die Beziehungen der ausgeblendeten Gestaltungsobjekte werden dann zwischen den übergeordneten Objekten aggregiert betrachtet. Abbildung 4 zeigt hierfür ein Beispiel: Zwei Gestaltungsobjekte e1 ∈ c1 und e2 ∈ c2 sind hierarchisch verfeinert. Die Verfeinerungen der Objekte stehen auf dritter Verfeinerungsebene miteinander in Beziehung („X“). Jedes „X“ entspricht einen Element q ∈ Qc1c2 . In Abbildung 4 sind dies z. B. die Beziehungen {(e112 , e23 ), (e113 , e222 ), (e111 , e221 ), (e122 , e221 ), (e121 , e211 )} . Diese Beziehungen können auch aggregiert auf den Ebenen 2 („XX“) und 1 („XXX“) betrachtet werden. Abbildung 4 veranschaulicht weiterhin, wie das Ausblenden der unteren Verfeinerungsebenen Abhängigkeitsanalysen kompakter und übersichtlicher werden lässt. Die Diskussion mit Stakeholdern in den Praxisfallstudien zeigte, dass das beliebige Ein- und Ausblenden von Verfeinerungsebenen und Teilbäumen in Matrixdarstellungen als wichtige Navigationsoperation zur Erschließung der strukturellen Zusammenhänge der Unternehmensarchitektur eingeschätzt wird. Diese aggregierten Beziehungen werden durch eine sogenannte „Lifting“-Transformation ( ↑ ) erzeugt, die im Folgenden in Anlehnung an [4] und [7] eingeführt wird. Die Verfeinerungsrelation Pc1 ⊆ Ec1 × Ec1 beschreibe wieder die Verfeinerungsbeziehung zwischen den Gestaltungsobjekten 136 der Klasse c1 . Dafür stellen wir die zusätzlichen Bedingungen, dass die Relation funktional ist (d. h. für jedes ea existiert höchstens ein eb mit ea Pc1 eb ) und azyklisch, so dass die Verfeinerungsrelation einen Baum ergibt wie in Abbildung 4. O. B. d. A. sollen in der Hierarchie (z. B. in der Matrixdarstellung) alle dem Objekt e ∈ Ee1 ↓ untergeordneten Objekte ausgeblendet werden (z. B. Objekt e11 in Abbildung 4). e1 e12 e221 e222 XX e11 X X XX e211 e212 XX e2 e22 X XX e21 X XX e12 XX XX XXX X e21 e2 e1 e121 e122 e23 e23 e111 e112 e113 e22 e11 XX XXX Abbildung 4: Aggregierte Betrachtung von Beziehungen (Verfeinerungsebenen 3 und 2) in einer Matrix-Darstellung D. h. nur die Objekte Ee = Ee1 ↓ − Ee ↓ sollen berücksichtigt werden4 (z. B. {e1 , e11 , e12 , e121 , e122 } ). Der darzustellende Verfeinerungsbaum wird durch die Verfeinerungsrelation Pe = Pc1 Ee beschrieben. Dies ist die Teilmenge der Verfeinerungsrelation Pc1 , in der jedoch alle Tupel nur Elemente von Ee enthalten (z. B. {(e11 , e1 ), (e12 , e1 ), (e121 , e12 ), (e121 , e12 )} ). In der Relation Qe c ⊆ Ee × Ec 2 × T * werden nun alle e untergeordneten Objekte durch e ersetzt. Hierzu definieren 2 wir zunächst I e als identische Abbildung auf Ee . Die Relation Pe = Pc+1 ran {e} , d. h. die transitive Hülle der Verfeinerungsrelation Pc1 eingeschränkt auf alle Tupel mit dem Wertebereich (range) e , bildet weiterhin alle e untergeordneten Objekte auf e ab (z. B. {(e111 , e11 ), (e112 , e11 ), (e113 , e11 )} ). Die Relation M e = I e ∪ Pe bildet dann alle e untergeordneten Objekte auf e und alle anderen Objekte auf sich selbst ab ( {(e111 , e11 ), (e112 , e11 ), (e113 , e11 ), (e1 , e1 ), (e11 , e11 ), (e12 , e12 ), (e121 , e121 ), (e122 , e122 )} ). Die Relation qe ist dann definiert durch qe = M e−1 o q , wofür die Kurzschreibweise mit dem Lifting-Operator verwendet werden kann: qe = q ↑ dom M e . Für die Relationen aus dem Beispiel ergibt sich: {(e11 , e23 ), (e11 , e222 ), (e11 , e221 ), (e122 , e221 ), (e121 , e211 )} (vgl. Pfeile in Abbildung 4). Diese Ausführungen betrachteten die Seite des Deinitionsbereichs (domain) der Beziehung q . Analog kann die Lifting-Operation auf dem Wertebereich der Relation durchgeführt werden. In diesem Fall gilt: q ↑ ran M e = q o M e . 4 Der Operator − steht an dieser Stelle für die (asymmetrische) Differenz zwischen Mengen. 137 7. Zusammenfassung und Ausblick In diesem Beitrag wurde ausgehend von dem Bedarf, für beliebige Unternehmensarchitekturmodelle flexible Analysen ableiten zu können, ein allgemeiner formaler Lösungsansatz für zweidimensionale Abhängigkeitsanalysen auf Unternehmensarchitekturmodellen vorgestellt. In einem ersten Schritt wird hier das mathematische Fundament für Abhängigkeitsanalysen auf Unternehmensarchitekturmodellen beschrieben, das in nachfolgenden Arbeiten wie folgt erweitert und überprüft werden kann: 1) Betrachtung mehrdimensionaler Abhängigkeiten: Auch mehrdimensionale Abhängigkeiten können betrachtet werden, beispielsweise indem in den Zellen einer Matrixdarstellung weitere Informationen dargestellt werden. Dies entspricht einer verschränkten Ausführung zweidimensionaler Abhängigkeitsanalysen. 2) Betrachtung weiterer Darstellungsformen und Manipulationsmechanismen: Neben den Matrixanalysen können weitere Visualisierung wie z. B. Dependency-Diagramme, Landscape-Maps oder Wiring-Diagramme abgeleitet werden. Darüber hinaus können verschiedene Manipulationsoperationen für die verschiedenen Darstellungsformen spezifiziert werden, um beispielsweise Bestandteile der Ergebnisse ein- und auszublenden oder Darstellungsformen ineinander zu überführen. 3) Prototypische Werkzeugumsetzung: Das Ziel der hier beschriebenen Arbeit ist es, die Grundlage zu legen für flexiblere Softwarewerkzeuge. Im Rahmen eines Proof-of-Concept sollte der Ansatz daher prototypisch umgesetzt werden. 8. Referenzen [1] AIER, S., KURPJUWEIT, S., RIEGE, C., SAAT, J.: Stakeholderorientierte Dokumentation und Analyse der Unternehmensarchitektur, in: Hegering, H.-G., Lehmann, A., Ohlbach, H.J., Scheideler, C. (eds.): Proceedings of INFORMATIK 2008: Beherrschbare Systeme – dank Informatik, Vol. LNI P-134, Band 2. GI/Köllen, Bonn 2008, S. 559–565 [2] AIER, S., KURPJUWEIT, S., SCHMITZ, O., SCHULZ, J., THOMAS, A., WINTER, R.: An Engineering Approach to Enterprise Architecture Design and its Application at a Financial Service Provider: Proceedings Modellierung betrieblicher Informationssysteme (MobIS 2008). GI/Köllen, Bonn 2008, noch nicht erschienen. [3] AIER, S., RIEGE, C., WINTER, R.: Unternehmensarchitektur - Literaturüberblick und Stand der Praxis, in: Wirtschaftsinformatik, Vol. 50, 2008, S. 292-304 [4] BRIL, R., FEIJS, L., GLAS, A., KRIKHAAR, R., WINTER, T.: Hiding Expressed Using Relation Algebra with Multi-Relations Oblique Lifting and Lowering for Unbalanced Systems: Proceedings of the Conference on Software Maintenance and Reengineering. IEEE Computer Society 2000 [5] VAN BUUREN, R., JONKERS, H., IACOB, M.-E., STRATING, P.: Composition of Relations in Enterprise Architecture Models: ICGT 2004, S. 39–53 [6] FAVRE, J.-M.: Foundations of Meta-Pyramids: Languages vs. Metamodels – Episode II: Story of Thotus the Baboon1, in: Bezivin, J., Heckel, R. (eds.), Dagstuhl 2005 [7] FEIJS, L.M.G., VAN OMMERING, R.C.: Relation partition algebra \— mathematical aspects of uses and part-of relations, in: Sci. Comput. Program., Vol. 33, 1999, S. 163-212 [8] IEEE: IEEE Recommended Practice for Architectural Description of Software Intensive Systems (IEEE Std 14712000). IEEE Computer Society, New York, NY 2000 [9] KÜHNE, T.: Matters of (meta-) modeling, in: Software and Systems Modeling, Vol. 5, 2006, S. 369-385 [10] NIEMANN, K.D.: Von der Unternehmensarchitektur zur IT-Governance: Leitfaden für effizientes und effektives IT-Management. Vieweg 2005 [11] SINZ, E.J.: Architektur von Informationssystemen, in: Rechenberg, P., Pomberger, G. (eds.): InformatikHandbuch. Hanser, München, Wien 1999 S. 1035-1046 [12] STRAHRINGER, S.: Ein sprachbasierter Metamodellbegriff und seine Verallgemeinerung durch das Konzept des Metaisierungsprinzips, in: Pohl, K., Schürr, A., Vossen, G. (eds.): 1998, S. 15-20 [13] WINTER, R., FISCHER, R.: Essential Layers, Artifacts, and Dependencies of Enterprise Architecture, in: Journal of Enterprise Architecture, Vol. 3, 2007, S. 7-18 138 SERVICEORIENTIERTE SOFTWAREARCHITEKTUREN Ziel serviceorientierter Softwarearchitekturen ist es, die Informationstechnologie im Unternehmen schneller und besser an die Anforderungen moderner Geschäftsprozesse anpassen zu können als das bisher möglich ist. Idee dabei ist, die Ausführung von Geschäftsprozessen flexibel durch entsprechende Softwaredienste zu unterstützen, die miteinander kombiniert werden können, um über passend standardisierte Schnittstellen zu kooperieren. Bevor sich das Paradigma serviceorientierter Softwarearchitekturen in der Praxis breit durchsetzen kann, sind allerdings noch verschiedene Probleme zu lösen. Dazu gehören beispielsweise Fragen zur Sicherheit und Zuverlässigkeit, zum effi zienten Finden von Services, zur Architekturbewertung sowie zur Einbindung von vorhandenen Altsystemen. Dieser Track möchte einen Überblick über aktuelle Forschungsarbeiten in diesem Gebiet geben, mit einem Fokus im Bereich der Modellierung und Realisierung von serviceorientierten Architekturen. Besonders relevant sind für die Diskussion in diesem Track bereits vorliegende Erfahrungen mit dem Einsatz serviceorientierter Architekturen in der betrieblichen Praxis. Leitungsgremium: Andreas Oberweis, Universität Karlsruhe (TH) (Federführender) Steffen Staab, Universität Koblenz Uwe Zdun, Technische Universität Wien Programmkomitee: Witold Abramowicz, Universität Poznan Jörg Bartholdt, Siemens AG Schahram Dustdar, Technische Universität Wien Frank Leymann, Universität Stuttgart Nikola Milanovic, Technische Universität Berlin Ralf Reussner, Universität Karlsruhe / FZI Karlsruhe York Sure, SAP Research Mathias Weske, HPI Potsdam COSMA – EIN INTEGRIERTER ANSATZ FÜR DAS MANAGEMENT VON SERVICE LEVEL AGREEMENTS BEI COMPOSITE SERVICES André Ludwig1 Kurzfassung Die Service-Bereitstellung in Service-Oriented Computing Umgebungen wird durch Service Level Agreements (SLA) beschrieben. Aktuelle SLA-Management-Ansätze konzentrieren sich auf bilaterale Service-Provider-/-Requester-Konstellationen, gehen jedoch nicht auf SLA-ManagementAnforderungen von Composite Service Providern ein. Diese betreffen das SLA-Management mit Providern von Atomic Services, mit Requestern von Composite Services und deren Abstimmung aufeinander. Ein Composite SLA Management Ansatz muss den Anteil von (Atomic) SLAs beim SLA-Management von (Composite) SLAs berücksichtigen. Der COSMA-Ansatz erlaubt ein integriertes Management von Atomic und Composite SLAs während deren gesamten Lebenszyklus. Er ermöglicht die Abbildung der Abhängigkeiten und Beziehungen zwischen unterschiedlichen SLAs und damit eine Kontrolle, Steuerung und Optimierung der SLA-Management-Aktivitäten. 1. Einleitung Service-Oriented Computing (SOC) beschreibt einen relativ neuen Ansatz für die Gestaltung von verteilten, unternehmensübergreifenden Informationssystemen. Mit SOC lassen sich Funktionalitäten von Informationssystemen als autonome, in sich geschlossene, Plattformunabhängige Services abstrahieren, welche aufgrund ihrer Geschlossenheit wiederum in komplexe zusammengesetzte Services integriert werden können. Man unterscheidet dabei konzeptionell in Atomic Services zur Abstraktion einer bestimmten Funktionalität und Composite Services, welche entsprechend einem Prozessfluss aus Atomic Services gebildet werden können. Eine Vision, die sich mit dem Gestaltungsansatz von SOC verbindet, ist die Etablierung einer global verfügbaren Infrastruktur, eines Service-Marktes für die Bereitstellung und Nachfrage von Services [12][6]. Diese Infrastruktur wird es Anbietern von Services (Service Provider) erlauben, zahlreiche Services in unterschiedlichen Service-Implementierungen mit individuellen ServiceEigenschaften einer Vielzahl von unterschiedlichen Service-Nachfragern (Service Requester) anzubieten, welche diese Service-Implementierungen zur Laufzeit (on-demand) an die nutzenden Anwendungen binden (dynamisches Binden). 1 Universität Leipzig, Germany 141 Die Entstehung von Service-Märkten auf der Basis von SOC wird zur Etablierung des Geschäftsmodells des Composite Service Providers (CSP) führen [2][5]. Ein CSP fragt Atomic Services von externen Service Providern nach und bietet die durch einen bestimmten Prozessfluss verbundenen Atomic Services als in sich geschlossene Composite Services eigenen Kunden im Service-Markt an. Das heißt, ein CSP agiert als unabhängige Geschäftseinheit, die eigenen Interessen folgt, Profitabilität und durch zuverlässige Service-Bereitstellung Kundenzufriedenheit sicherstellen muss. Die Definition, Steuerung und Kontrolle der Service-Bereitstellung kann durch Dienstgüteverträge, sogenannte Service Level Agreements (SLA), umgesetzt werden. SLAs bieten eine formale Beschreibung des ausgetauschten Services und definieren die Rechte und Pflichten der involvierten Parteien. Aktuelle SLA-Management-Ansätze für SOC-Umgebungen wie WSLA [8], WSAgreement [3] oder WSOL [13] stellen umfangreiche SLA-Sprachformalisierungen und SLAManagement-Ausführungsumgebungen zur Verfügungen. Sie konzentrieren sich dabei jedoch auf bilaterale Service Requester-/Service Provider-Konstellationen und vernachlässigen die SLAManagement-Anforderungen von Composite Service Providern. Diese Anforderungen betreffen zum einen das SLA-Management mit Anbietern atomarer Service, das SLA-Management mit Nachfragern von Composite Services und zum anderen die Abstimmung beider SLA-ManagementAktivitäten aufeinander. Ein SLA-Management-Ansatz für Composite Services muss den Anteil extern bezogener Services – formalisiert in deren (Atomic) SLAs (ASLA) – beim SLA-Management der Composite Services – formalisiert in deren (Composite) SLAs (CSLA) – berücksichtigen. Mit einer zunehmenden Anzahl von verfügbaren Service-Implementierungen, ServiceKonfigurationen und Service-Anforderungen und den daraus resultierenden unterschiedlichsten Composite Service-Implementierungen erfordert (nahezu) jeder durch einen Composite Service Provider bereitgestellte Composite Service eine spezifische Anzahl von SLA-Dokumenten und ein individuelles Management dieser SLAs. Aufgrund des dynamischen Bindens und des dynamischen Bereitstellens von Services in Service-Märkten muss auch das Composite SLA-Management dynamisch zur Laufzeit und damit automatisch realisiert werden. Die manuelle Ausführung von SLA-Management-Aktivitäten, z.B. die Verhandlung und Erstellung von SLAs oder das Monitoring und die Evaluierung von SLAs, ist für das SLA-Management in Service-Märkten nicht ausreichend. In diesem Beitrag wird ein neuer, integrierter Ansatz für das automatische Management von SLAs in Composite Services während ihres gesamten Lebenszyklus vorgestellt. Dieser Ansatz ist mit dem Akronym COSMA (COmposite Sla MAnagement) abgekürzt. COSMA ermöglicht die Abbildung von Beziehungen und Abhängigkeiten zwischen SLAs in Composite Services und erlaubt damit die zentrale Kontrolle, Steuerung und Optimierung der Composite SLA-Management-Aktivitäten bei einem CSP. Der Beitrag ist wie folgt strukturiert: Abschnitt 2 präsentiert die grundlegende Idee des COSMA-Ansatzes und stellt die konstitutiven Elemente von COSMA vor. Abschnitt 3 gibt einen kurzen Einblick in ein Anwendungsbeispiel und den COSMA Demonstrator und Abschnitt 4 fasst den Beitrag zusammen und gibt einen Ausblick in weitere Forschungsschritte. 2. Composite SLA Management-Ansatz (COSMA) Die grundlegende Idee des COSMA-Ansatzes ist die Integration aller in einen Composite Service involvierten SLA-Dokumente in ein Composite SLA Management Document. Dieses Composite SLA Management Document, welches im weiteren als COSMAdoc bezeichnet wird, beinhaltet die vertraglichen Informationen, gekapselt in SLA-Dokumenten, und zusätzlich alle SLA142 Management-Daten insbesondere zur Abbildung der Beziehungen und Abhängigkeiten zwischen einzelnen SLA-Dokument-Elementen. Auf der Basis Composite Service-spezifischer COSMAdoc-Instanzen kann der Beitrag von Atomic SLAs am Composite SLA abgebildet und nachvollzogen werden. Das SLA-Management-System eines CSP kann auf dieser Basis seine SLA-Management-Aktivitäten kontrollieren, steuern und optimieren. Dies betrifft insbesondere kompositionsweite SLA-Verhandlungen und kompositionsweite SLA-Monitorings und -Evaluierungen. Der COSMA-Ansatz besteht aus den folgenden Teilen: − COSMAdoc stellt ein generisches Informationsmodell für die Integration von vertraglichen Daten und SLA-Management-Daten zur Verfügung. COSMAdoc erweitert dabei ein bestehendes SLA-Informationsmodell und stellt Elemente für die Abbildung von Beziehungen und Abhängigkeiten zwischen SLA-Elementen zur Verfügung. − COSMAframe beschreibt ein konzeptionelles Rahmenwerk (Framework) für das dynamische Management von Composite SLAs. Das Rahmenwerk beschreibt dabei die generischen Komponenten sowie deren Nutzung von COSMAdoc-Instanzen zur Umsetzung der SLA-Lebenszyklus-Management-Aktivitäten. − COSMAlife stellt eine Sammlung von Mechanismen und Protokollen zur Verfügung, die definieren, wie die Komponenten von COSMAframe die Managementaktivitäten des SLA Lebenszyklus (Lifecycle) auf Basis von COSMAdoc-Instanzen umsetzen. COSMAframe, COSMAdoc und COSMAlife sind in die vorhandene Service Provisioning Infrastruktur des CSP eingebettet (z.B. SOA-Plattform, Enterprise Service Bus). Diese wird im Folgenden als Operation and Management System (OMS) bezeichnet. Das OMS stellt zahlreiche weitere Funktionen, beispielsweise zur Registrierung von Services, zur Interaktion mit Service Requestern und Providern und zur Administration, zur Verfügung. Weiterhin stellt das OMS Komponenten zur automatischen Erstellung von Composite Service-Orchestrierungsskripts (Service Composer), zur automatischen, Agenten-basierten Verhandlung von SLAs (Negotiation Engine) oder zur automatischen Ausführung und Kontrolle von Services (Service Enactment & Monitoring Engine) zur Verfügung2. 2.1 Informationsmodell COSMAdoc Das generische Informationsmodell COSMAdoc stellt das informationelle Herz des COSMAAnsatzes dar. Es kapselt die vertraglichen Informationen der involvierten SLAs und deren SLAManagement-Informationen in einer zentralen Einheit. Dabei wird für jeden involvierten Atomic Service ein SLA-Dokument (ASLA) und zusätzlich für den Composite Service ein SLA-Dokument (CSLA) erstellt. Zusätzlich werden die Beziehungen und Abhängigkeiten zwischen Elementen dieser SLA-Dokumente in COSMAdoc gespeichert. Für jeden durch einen CSP bereitgestellten Composite Service wird eine spezifische Instanz von COSMAdoc erzeugt und an den bereitgestellten Service gebunden. Die COSMAdoc-Instanz wird für alle in COSMAlife definierten Aktivitäten durch die COSMAframe-Komponenten verwendet. Auf der Basis der spezifischen, in der COSMAdoc-Instanz gespeicherten Beziehungen und Abhängigkeiten können die Komponenten von COSMAframe beispielsweise kompositionsweite SLA-Verhandlungen und Überprüfungen der SLA-Einhaltung durchführen. Aufgrund der Zusammenführung von SLA- und SLA-Management2 Die innerhalb des „Adaptive Services Grid“ (ASG) Projekts entwickelte ASG-Plattform stellt prototypische Implementierungen der vorgestellten Komponenten des OMS zur Verfügung. Weitere Informationen sind auf der Projekt-Website verfügbar [4]. 143 Informationen in einem zentralen Dokument stellt eine COSMAdoc-Instanz ein zentrales Managementwerkzeug für einen CSP dar, welches CSP-intern zur Kontrolle, Steuerung und Optimierung der SLA-Management-Aktivitäten genutzt wird. Die eingebetteten SLA-Dokumente enthalten dabei ausschließlich vertragliche Daten, die den jeweils beteiligten Vertragsparteien zugänglich gemacht werden können. Abbildung 1: Struktur des COSMAdoc-Informationsmodells COSMAdoc besteht aus sechs Kernelementen (vgl. Abbildung 1). Alle Kernelemente sind selbständige Teile, die teilweise über Referenzen miteinander verbunden sind. Die Elemente erfüllen die folgenden Aufgaben: − Header: Der Header einer COSMAdoc-Instanz dient zur Definition von Kontextinformationen und Parametern. Beispielsweise lassen sich der Besitzer der Instanz, eine Versionsnummer oder Beschreibung definieren. Zusätzlich können die in der COSMAdoc-Instanz verwendeten semantischen Modelle referenziert werden. − ServiceComposition: Das Element ServiceComposition erlaubt die Speicherung des dem Composite Service zugrunde liegenden Orchestrierungsskripts (z.B. in WS-BPEL [11]). Das 144 − − − − Orchestrierungsskript dient nicht nur der Ausführung des Composite Service, sondern bestimmt maßgeblich die Beziehungen zwischen ASLA und CSLA Elementen. SlaSetAssembly: In SlaSetAssembly werden Sla-Elemente zur Repräsentation von ASLAs und CSLA gespeichert. Dabei werden ausschließlich vertragliche Informationen in SlaElementen gespeichert. Die Struktur jedes Sla-Elements basiert auf dem dreiteiligen SLAModell der WS-Agreement Spezifikation [3]. Die vom Open-Grid-Forum (OGF) erarbeitete Spezifikation bietet eine umfangreiche Grundlage zur Formalisierung von bilateralen Verträgen zwischen Vertragspartien. Das COSMAdoc SLA-Modell erweitert das WSAgreement SLA-Modell um MonitoringTerms zur Definition der Monitoring-Konfiguration (vgl. z.B. Ausführungen in [8]), NegotiationTerms zur Speicherung des zugrunde liegenden Verhandlungsprotokolls und FinancialTerms zur strukturierten Speicherung von finanziellen Aspekten des SLA (z.B. Verrechnungsmodelle und -entgelte, Sanktionen und Boni). SlaSetUsageValidation: Der Bereich SlaSetUsageValidation ermöglicht die Kontrolle und Restriktion der Verwendung von Sla-Element-Teilen der SlaSetAssembly. Beispielweise lassen sich Teile von Sla-Elementen als obligatorisch, optional oder verhandelbar deklarieren. Weiterhin können Formatrestriktionen, z.B. bestimmte Datumsformate oder Nachkommastellen, zugewiesen werden. Restriktionen, welche die Verwendung einschränken, lassen sich als immer geltende (default) und bei Erfüllung einer bestimmten Bedingung geltend (conditional) definieren. Zur Identifizierung der Sla-Element-Teile werden Pointer verwendet (z.B. durch Anwendung der Syntax von XPath [14]). SlaSetDataValidation: Während die SlaSetUsageValidation die Verwendung von SlaElementen kontrolliert, können mit dem Bereich SlaSetDataValidation die Daten der beinhalteten Sla-Elemente kontrolliert werden. Durch Prädikate lassen sich Teile von SlaElementen in ihren zulässigen Maximal-/Minimalwerten, Wertebereichen oder auf feste Werte beschränken. Da insbesondere die Daten von CSLA-Elementen von Daten der ASLA-Elemente abhängen, lassen sich die Prädikate der SlaSetDataValidation an Aggregationsformeln knüpfen, welche die Daten der Sla-Elemente unterschiedlicher SLAs über Algorithmen miteinander verbinden. Durch die Verknüpfung von Prädikaten mit Aggregationsformeln kann gewissermaßen eine Querverbindung zwischen SLA-Elementen unterschiedlicher Sla‘s dargestellt werden. Die Verwendung von Aggregationsformeln ist dennoch nicht auf das Zusammenführen von ASLA- und CSLA-Elementen beschränkt, sondern lässt sich auch auf Zusammenhänge zwischen ASLA-Elementen anwenden. Abbildung 2 veranschaulicht die Zuweisung von Aggregationsformeln aus dm Bereich der AggregationFormulas über Prädikate der SlaSetDataValidation an Teilen von SlaElementen (z.B. an Service Level Objectives in GuaranteeTerms). Ähnlich wie bei SlaSetUsageValidation lassen sich auch im Bereich SlaSetDataValidation Prädikate als default oder conditional definieren. AggregationFormulas: Im Bereich der AggregationFormulas werden die Beziehungen und Abhängigkeiten zwischen Elementen unterschiedlicher SLAs in Form von Aggregationsformeln (Formula) gespeichert. Die Aggregationsformeln können unterschiedlichste mathematische Operatoren verwenden und referenzieren die verwendeten Terme (Teile von Sla-Elementen aus dem Bereich der SlaSetAssembly) durch Pointer (z.B. unter Verwendung der XPath Syntax [14]). Aggregationsformeln werden dabei für GuaranteeTerms, FinancialTerms und MonitoringTerms (Teile des COSMAdoc SLAModells) gespeichert. Die Aggregationsformeln und deren Komplexität hängen im Wesentlichen von zwei Faktoren ab: der Struktur des Orchestrierungsskripts und der Art und Anzahl der in den SLAs verwendeten SLA-Parametern (z.B. Verfügbarkeit, Antwortzeit, Verrechnungsentgelt). Zur Erzeugung der Aggregationsformeln müssen 145 zunächst die unter Umständen komplexen, geschachtelten Orchestrierungsskripte in ihre atomaren Kompositionsmuster (z.B. Sequenz, Schleife, Parallel Split) zerlegt werden und anschließend Aggregationsformeln für verschiedene SLA-Parameter erstellt werden. Etablierte Ansätze, die bei der Erzeugung von Aggregationsformeln Verwendung finden können, stellen beispielsweise [7] und [15] dar. Abbildung 2: Zuweisung von Aggregationsformeln über Prädikate an SLA Elementen Die Kernelemente von COSMAdoc bilden eine feste Struktur und erlauben die Definition eines generischen COSMAdoc-Templates. Dieses Template ist erweiterbar und kann an unterschiedliche Anwendungsbereiche angepasst werden. Für unterschiedliche von einem CSP angebotene Composite Services werden individuelle Dokumentinstanzen des COSMAdoc-Templates gebildet. 2.2 Konzeptionelles Rahmenwerk COSMAframe COSMAframe stellt ein konzeptionelles Rahmenwerk dar, welches die generischen Komponenten, die für ein automatisches Verarbeiten von COSMAdoc-Instanzen, z.B. SLA-Erstellung und -Verhandlung oder SLA-Monitoring und -Evaluierung notwendig sind, definiert. COSMAframe ist als abstrakte Lösung zu interpretieren, in der die Komponenten in ihrem grundlegenden Verhalten und ihren generischen Schnittstellen beschrieben werden. COSMAframe ist kein Implementierungsrahmenwerk und kein Rahmenwerk, welches feste Programmierschnittstellen und Datenobjekte beschreibt, sondern ist notwendigerweise zu erweitern und anzupassen. COSMAframe besteht aus den folgenden generischen Komponenten (vgl. Abbildung 3): − COSMA Manager: Der COSMA Manager stellt die zentrale Steuerungs- und Verwaltungskomponente in COSMAframe dar, die alle anderen Komponenten entsprechend der notwendigen Management-Aktivitäten im SLA-Lebenszyklus triggert. Die Komponente bietet einen zentralen Port für externe Komponenten und stellt eine Validierungsschnittstelle bereit, welche die SlaSetUsageValidation und SlaSetDataValidation Prädikate in COSMAdoc-Instanzen auswertet und damit beispielsweise durch Verhandlungsmaschinen (Negotiation Engines) nutzbar macht. − COSMAdoc Creator: Die Komponente COSMAdoc Creator ist für die kompositionsspezifische Erzeugung von COSMAdoc-Instanzen verantwortlich. Auf der Basis eines durch einen Service Composer erstellten Orchestrierungsskripts modularisiert die Komponente die Komposition und baut die COSMAdoc-Instanz aus dem generischen COSMAdoc Template auf. − COSMAdoc Integrator: Die kompositionsspezifische COSMAdoc-Instanz wird im COSMAdoc Integrator um weitere Elemente ergänzt. Der COSMAdoc Integrator fügt 146 zunächst sämtlich SLA-Elemente, wie Servicequalitäts-Parameter und deren Metriken, finanzielle Parameter wie Entgelt-/Sanktionen-/Bonus-Verrechnungsmodelle und die Monitoring- und Verhandlungskonfigurationen ein. Anschließend werden alle direkt ableitbaren SlaSetUsageValidation- und SlaSetDataValidation-Prädikate erstellt und zusammen mit den dazugehörigen Aggregationsformeln in die COSMAdoc-Instanz eingebettet. Zum Teil werden dazu Konfigurationen verwendet, welche in einer Datenbank hinterlegt sind. − COSMAdoc Repository: Die erstellten und integrierten COSMAdoc-Instanzen werden im COSMAdoc Repository gespeichert. Das Repository ist für alle internen COSMAdocInstanzen erreichbar. − COSMAdoc Validator and Violation Detector: Zur Validierung und Erkennung von Verletzungen der in einen Composite Service involvierten SLAs wird die Komponente COSMAdoc Validator and Violation Detector verwendet. Die Komponente vergleicht Monitoring-Messergebnisse zur Laufzeit mit in den ASLAs verwendeten Service Level Objectives (Mindest-Service Levels). Auf dieser Basis und unter Hinzuziehung der gespeicherten Aggregationsformeln wird ermittelt, ob Verletzungen bei ASLAs zur Verletzung der CSLA führen. Es wird damit dokumentiert, welcher Atomic Service für eine Verletzung der CSLA verantwortlich ist. Die Komponente erstellt auf dieser Basis Vorschläge zur Behandlung der Verletzung, z.B. Forderung von Sanktionen durch die Verursacher bzw. Zahlung von Sanktion an den Nachfrager des Composite Service, und stellt diese Vorschläge dem COSMA Manager zur Verfügung. OMS <<component>> Service Composer ServiceComposition Deductive Database Negotiation Engine DDBQuery Negotiation Service Enactment and Monitoring Engine ServiceEnactment ServiceMonitoring OMS COSMAframe <<component>> <<component>> COSMA Manager COSMAdoc Creator <<component>> COSMAdoc Repository COSMAHandler <<component>> <<component>> COSMAdoc Integrator COSMAdoc Validator and Violation Detector Abbildung 3: COSMAframe Komponentenüberblick sowie externe Komponenten Die Komponenten von COSMAframe nutzen eine Reihe externer Komponenten. Dazu zählen beispielsweise ein Service Composer zur automatischen Erstellung von generischen Orchestrierungsskripten zur Laufzeit, eine Negotiation Engine zur automatischen Verhandlung von SLAs durch autonome Verhandlungsagenten, eine Service Enactment and Monitoring Engine zur schrittweisen Ausführung und zum Monitoring der Atomic und Composite Services. Diese Komponenten zählen nicht zu COSMAframe und es muss auf existierende Ansätze und Prototypen zurückgegriffen werden (vgl. z.B. prototypische Komponentenimplementierungen im Adaptive Services Grid Projekt [4]). 147 2.3 Mechanismen zum Management des Composite SLA Lebenszyklus COSMAlife COSMAlife stellt einen integrierten Satz von Mechanismen für das Management des SLALebenszyklus bereit. Dabei fokussiert COSMAlife insbesondere die für einen CSP besonders relevanten Phasen: SLA-Erstellung und -Verhandlung und SLA-Monitoring und -Evaluierung. Die Phase des Durchsetzens von SLA-Festlegungen durch die Service-Bereitstellungsinfrastruktur (SLA Provisioning & Fulfilment) ist für das Grundmodell des CSP irrelevant, da er ausschließlich externe Atomic Services integriert. Weitere Phasen des SLA-Lebenszyklus wie SLA-Terminierung und -Erklärung werden in diesem Beitrag nicht näher betrachtet. Generell kann das Management von SLAs als zyklischer Prozess mit iterativen Managementschritten charakterisiert werden. Das heißt, die SLA-Lebenszyklus-ManagementAktivitäten müssen für jeden durch den CSP bereitgestellten Composite Service parallel ausgeführt werden. Der aktuelle Status innerhalb des SLA-Lebenszyklus wird durch die in COSMAdoc enthaltenen StateTerms gespeichert. Aus Platzgründen soll an dieser Stelle auf nähere Ausführungen zu COSMAlife verzichtet werden. COSMAlife Protokolle zur Verhandlung von SLAs in Composite Services werden in [9] vorgestellt. 3. Anwendungsszenario und Demonstrator Zur Illustration der Anwendung des COSMA-Ansatzes und seiner konstitutiven Teile COSMAdoc, COSMAframe und COSMAlife wurde ein Anwendungsszenario entwickelt, welches auf einem mit Partnern aus Industrie und Wissenschaft entwickelten Anwendungsszenario aus dem Adaptive Services Grid EU-Projekt aufbaut [10]. Das Szenario beschreibt einen Internet Service Provider (ISP), der als CSP unterschiedliche, Kunden-individuell zusammengesetzte Services im Bereich Webspace-Provisioning anbietet. Zu den bezogenen Atomic Services zählen Services zur Registrierung von Domain Names, zur Abwicklung von Kreditkartenzahlungen oder zum Setup des Webspace Hostings. Der angebotene Composite Service fasst diese Atomic Services entsprechend einem Orchestrierungsskript zusammen und wird unterschiedlichen Service Requestern angeboten. Im Anwendungsszenario wird gezeigt, wie der ISP eine auf COSMA basierende Composite SLA Management-Lösung zur Realisierung der SLA-Management-Aktivitäten nutzt. Zusätzlich wurde ein Demonstrator entwickelt, der die Protokolle und Mechanismen von COSMAlife umsetzt, individuelle COSMAdoc-Instanzen erzeugt und zum SLA-Management verwendet und damit eine stabile Grundlage zur explorativen weiteren Untersuchung des COSMAAnsatzes bietet. Mit dem Demonstrator und den hinterlegten Testfällen können Experimente und eine schrittweise Überprüfung der kompositionsweiten SLA-Verhandlungen bzw. -Monitorings durchgeführt werden. Sowohl das Anwendungsszenario als auch der Demonstrator sind als repräsentative Umsetzungen des COSMA-Ansatzes zu verstehen und in keiner Weise auf diese beschränkt. Abbildung 4 gibt einen Überblick über das Anwendungsszenario, den verwendeten Composite Service und zeigt einen Screenshot des COSMA-Demonstrators. 148 Abbildung 4: Übersicht Anwendungsszenario, Composite Service und COSMA-Demonstrator 4. Zusammenfassung und Ausblick Das Thema Composite SLA Management in SOC-Umgebungen ist ein relativ junges Forschungsthema und insbesondere durch die hohe Dynamik in SOC-Umgebungen und der damit verbundenen Anforderung zur Automatisierung charakterisiert. COSMA stellt einen neuen Ansatz für das automatische Management von SLAs bei Composite Services bereit und ermöglicht einem CSP damit seine SLA-Management-Aktivitäten automatisch zu kontrollieren, zu steuern und zu optimieren. Dies betrifft die Maximierung der Profitabilität, indem SLA-Datenrestriktionen als Basis für SLA-Verhandlungen und Berechnungen von finanziellen Aspekten verwendet werden können (Minimierung der Kosten für bezogene Services und Maximierung des Composite Service Verkaufspreises). Weiterhin kann über die Kontrolle der SLA-Daten der Qualitätsbeitrag von Atomic Services zu Composite Services abgebildet und damit zusicherbare Servicequalität definiert werden (Minimierung von notwendigen Servicequalitätsanforderungen zu Atomic Services bei gleichzeitiger Erreichung der geforderten Servicequalität für Composite Services). COSMA stellt einen konzeptionellen Ansatz dar, der entsprechend individuellen Anforderungen und domänenspezifischen Besonderheiten angepasst und erweitert werden muss. Untersuchungen von COSMA mit weiteren Anwendungsszenarien und einer größeren Anzahl von Services in unterschiedlichen Service-Implementierungen wird zu weiteren Erkenntnissen und Anpassungen des Ansatzes führen. Darin ist auch eine Ausweitung von COSMAlife auf die Phase SLATerminierung und Voraussage von Verletzungen einbegriffen. Nach der Terminierung von SLAs in COSMAdoc-Instanzen sollte das Service-Verhalten in dynamischen Service Profilen (vgl. z.B. DSP-Ansatz aus [1]) gespeichert und bei der Erzeugung von Daten- und Verwendungsrestriktionen (SlaSetDataValidation bzw. SlaSetUsageValidation) einbezogen werden. Dadurch lässt sich der Prozess der SLA-Verhandlungen iterativ verbessern und zusätzlich unterschiedliche SLALebenszyklen miteinander verbinden. 149 Quellen [1] ABRAMOWICZ, W., KACZMAREK, M., KOWALKIEWICZ, M., ZYSKOWSKI, D., Architecture for Service Profiling. In: Proceedings of the Services Computing Workshops SCW'06, Chicago 2006, S. 121-130. [2] ALONSO, G., CASATI, F., KUNO, H., MACHIRAJU, V., Web services: concepts, architectures and applications. Springer, Berlin, New York 2004. [3] ANDRIEUX, A., CZAJKOWSKI, K., DAN, A., KEAHEY, K., LUDWIG, H., NAKATA, T., PRUYNE, J., ROFRANO, J., TUECKE, S., XU, M., Web Service Agreement Specification (WS-Agreement). http://www.gridforum.org/documents/GFD.107.pdf, letzter Zugriff am 04.06.2008. [4] ASG: Integrated Project Adaptive Services Grid, ASG Projekt-Website: http://www.asg-platform.org, letzter Zugriff am 13.06.2008. [5] BENATALLAH, B., DUMAS, M., MAARMAR, Z., Definition and Execution of Composite Web Services: The SELF-SERV Project. In: Data Engineering Bulletin, 25 (2002) 4, S. 1-6. [6] HEUSER, L., The Internet of Services. http://www.fit.qut.edu.au/industry/corporateevents/docs/ 22Oct07_ProfessorHeuser_SAPResearch.pdf, letzter Zugriff am 02.03.2008. [7] JAEGER, M.C., ROJEC-GOLDMANN, G., MUEHL, G., QoS aggregation for Web service composition using workflow patterns. In: Proceedings of the The 8th International IEEE Enterprise Distributed Object Computing Conference (EDOC 2004), Monterey 2004, S. 149-159. [8] KELLER, A., LUDWIG, H., The WSLA Framework: Specifying and Monitoring Service Level Agreements for Web Services. In: Journal of Network and Systems Management, Special Issue on E-Business Management, 11 (2003) 1, S. 57-81. [9] LUDWIG, A. FRANCZYK, B., Managing Dynamics of Composite Service Level Agreements with COSMA. Akzeptiert zur Publikation bei 5th International Conference on Fuzzy Systems and Knowledge Discovery (FSKD 2008), Jinan, China, 18.-20.10.2008. [10] MOMOTKO, M., GAJEWSKI, M., LUDWIG, A., KOWALCZYK, R., KOWALKIEWICZ, M., ZHANG, J.Y., Towards adaptive management of QoS-aware service compositions. In: Multiagent and Grid Systems, 3 (2007) 3, S. 299-312. [11] OASIS: Organization for the Advancement of Structured Information Standards, Web Services Business Process Execution Language Version 2.0 (WS-BPEL). http://docs.oasis-open.org/wsbpel/2.0/OS/wsbpel-v2.0-OS.html, letzter Zugriff am 23.11.2007. [12] PAPAZOGLOU, M.P., Web Services: Principles and Technology. Prentice Hall, Essex 2007. [13] TOSIC, V., PATEL, K., PAGUREK, B., WSOL - Web Service Offerings Language In: Proceedings of the International Workshop on Web Services, E-Business, and the Semantic Web (WES2002), Toronto 2002, S. 5767. [14] W3C: World Wide Web Consortium, XML Path Language (XPath). http://www.w3.org/TR/xpath, letzter Zugriff am 26.11.2007. [15] ZENG, L., BENATALLAH, B., NGU, A.H.H., DUMAS, M., KALAGNANAM, J., CHANG, H., QoS-Aware Middleware for Web Services Composition. In: IEEE Transactions on Software Engineering, 30 (2004) 5, S. 311327. 150 WIEDERGEWINNUNG VON WEB SERVICES AUS VORHANDENEN ALTSYSTEMEN Harry M. Sneed1 Kurzfassung Dieser Beitrag beschreibt einen Werkzeugkasten für die Ableitung von Web Services aus bestehenden COBOL Programmen auf dem IBM Mainframe. Das erste Werkzeug - COBAudit – dient dazu potentielle Web Services zu identifizieren. Das zweite Werkzeug -COBStrip – markiert den Programmpfad zum gewünschten Ergebnis und kommentiert den Rest des Codes aus. Das dritte Werkzeug - COBWrap – kapselt den ausgewählten Codebaustein und transformiert ihn in eine ausführbare Komponente. Das vierte Werkzeug – COBLink – verbindet die gekapselte Komponente mit dem Web über eine WSDL Schnittstelle. Die Werkzeuge werden zurzeit an einem großen Bausparsystem mit 12 Millionen COBOL Anweisungen erprobt. Der Beitrag beschreibt den Stand dieser Arbeit relativ zum allgemeinen State of the Art auf dem Gebiet. 1. Migration zur Service-orientierten Architektur Konventionelle Anwendungssysteme sind bekanntlich sehr starr und es dauert viel zu lange sie zu verändern. Es kann Monate dauern bis ein Änderungsantrag genehmigt, umgesetzt und getestet wird. Größere Änderungen wie die Baseler Vereinbarungen für das Kreditgeschäft können sogar Jahre dauern. Alte Software ist schwer zu verstehen und noch schwieriger zu verändern ohne unerwünschte Seiteneffekte. Sie hat sich über die Zeit erhärtet. Sie aufzubrechen um neue Funktionen einzuschieben verursacht einen unverhältnismäßig hohen Aufwand. Anderseits verlangt unsere schnelllebige Zeit ständige Anpassungen mit schnellen Reaktionszeiten. Service-orientierte Architekturen versprechen eine größere Flexibilität der Geschäftsprozesse und eine rasche Umsetzung von Änderungen zu der Software. Die einzelnen Softwarebausteine werden als allgemein gültige Web Services bereitgestellt. Es obliegt den Prozessverantwortlichen, sie beliebig in ihren Prozessen einzubauen. Er kann auch die Web Services ohne weiteres austauschen können. Heute benutzt er Web Service A, morgen Web Service B. Zwischen den bereits verwendeten Web Services kann er neue Web Services jederzeit einschieben. Seine Geschäftsprozesse kann er selber gestalten. Er trägt die Verantwortung für den jeweiligen Gesamtprozess. Die IT muss nur garantieren, dass die Web Services das leisten, was in deren Spezifikation versprochen ist. Die wichtigste Voraussetzung für eine service-orientierte Architektur ist das Vorhandensein ausreichender Web Services. Wenn wir davon ausgehen, dass ein Web Service eine feine Granularität haben sollte, um in möglichst viele Geschäftsprozesse hineinzupassen, wird ein Web 1 Universität Regensburg, Germany, Institut für Wirtschaftsinformatik Lehrstuhl-I Prof. Pernul 151 Service in etwa einem Modul mit maximal 500 Anweisungen entsprechen. Demnach wird ein einziger betriebswirtschaftlicher Prozess wie die Genehmigung eines Kredits eine Menge von 10 bis 50 Web Services benötigen. Eine ganze Applikation, wie z.B. das Kreditwesen, wird mehrere hundert Web Services in Anspruch nehmen. Die Frage stellt sich, woher sollen die vielen Web Services herkommen. Dieser Autor hat schon in einer früheren Veröffentlichung darauf hingewiesen: • man kann sie kaufen • man kann sie mieten • man kann sie übernehmen • man kann sie entwickeln • man kann sie wiederaufbereiten. Das Kaufen heißt, sie als Standard Softwaresteine von einem Anbieter zu kaufen und bei sich auf der eigenen Anlage zu installieren. Das Mieten heißt sie auf einer fremden Plattform nach Bedarf zu verwenden – „Software on Demand“, bzw. „Software as a Service“. Das Übernehmen heißt, sie von der Open Source Gemeinde zu übernehmen, anzupassen und in der eigenen Umgebung einzusetzen. Entwickeln heißt, sie selber nach den eigenen Anforderungen zu spezifizieren, zu implementieren und auszutesten. Die Wiederaufbereitung bedeutet letztlich, dass sie aus den vorhandenen Altsystemen entnommen und entsprechend aufbereitet werden. Alle fünf Alternativen haben Vor- und Nachteile, auf die hier nicht weiter eingegangen wird. Sie wurden in früheren Veröffentlichungen ausführlich diskutiert. In diesem Beitrag geht es ausschließlich um das fünfte Alternativ – die Gewinnung aus der Altsoftware. Hier wird ein Weg aufgezeichnet wie man Codebausteine in vier Schritten aus dem bestehenden Source Code herausnimmt und in ausführbare Web Services verwandelt. Ob dies das beste Alternative zur Gewinnung von Web Services ist, bleibt dahingestellt. Auf jeden Fall ist es schnell und relativ preiswert. 2. Zum Stand der Altsysteme Gegenwärtig haben viele Anwenderbetriebe der ersten Stunde mit den Systemen, die sie damals mühevoll entwickelt haben, zu kämpfen. Sie kommen davon nicht ohne weiters los. Im Laufe der Jahre sind diese Systeme gemäß den Gesetzen der Softwareevolution immer größer und komplexer geworden [1]. Angesichts ihrer aktuellen Größe und Komplexität, ist es ist kaum möglich sie zu ersetzen. Zum einen, wäre es viel zu teuer, zum anderen weis keiner genau was in ihnen steckt. Das Wissen der Vergangenheit liegt in dem Code begraben. Auch eine Migration ist fragwürdig, ob es sich lohnt die Altsoftware auf eine neue Hardware Plattform oder in eine andere Sprache zu versetzen. Die Komplexität wird dadurch nicht weniger, die Qualität nicht besser. Das migrierte System bleibt ein schwarzer Kasten. Haben Systeme einmal die Million Codezeilen Grenze überschritten, ist es kaum noch möglich sie ohne eine erhebliche Investition zu erneuern. Der Anwender sitzt in der so genannten Legacy Falle. Um, z.B. ein Bausparsystem mit 12 Millionen Codezeilen und 8 Millionen Anweisungen neu zu entwickeln würde es nach der COCOMO-II Methode 1.175 Personenjahre, nach der Function-Point Methode 1.668 Personenjahre und nach der Data-Point Methode 1.233 Personenjahre kosten. Allein um das System mit einer jährlichen Änderungsrate von 7% zu erhalten, werden circa 80 Personen pro Jahr benötigt. Sogar eine Sanierung würde in der Größenordnung von 60 Personenjahren kosten. Gleichzeitig gehen die Einnahmen durch das Bauspargeschäft zurück, d.h. der Anwender ist gezwungen zu sparen. Obwohl seit Jahren darüber geredet wird, gibt es in Deutschland immer noch keine Standardsoftware für die Bausparbranche. Ergo gibt es wenig Hoffnung, weder auf eine Neuentwicklung, noch auf eine Sanierung, noch auf die Ablösung durch ein Standardprodukt. Was bleibt ist die Migration in eine Service-orientierte Architektur. Wenn es 152 gelingt die Web Services automatisch aus der Altsoftware zu gewinnen, könnte diese Alternativ unter der 40 Personenjahre Grenze bleiben, wobei der Hauptanteil davon für den Test wäre. Anderseits nimmt der Wettbewerb ständig zu. Der Markt der Finanzdienstleistungen wird immer härter umkämpft. Um bestehen zu können, muss ein Anbieter sowohl den Vertretern im Außendienst als auch den Kunden Zugriff auf die zentralen Datenbestände über das Internet gewähren. Vertreter und Kunden sollten in der Lage sein, verschiedene Sparmodelle durchzurechnen. Dazu brauchen sie einzelne, überschaubare Web Services. Außerdem wird verlangt die Geschäftsprozesse flexibler zu gestalten und im Hinblick auf Personalreduktion zu optimieren. Weder das eine noch das andere Ziel kann ohne den erleichterten Zugang zur Funktionalität der bestehenden Applikationssoftware erreicht werden. Es gebe daher zwei gute Gründe für eine service-orientierte Architektur, die Funktionen innerhalb der Altsysteme zugänglich macht. Der erste Grund ist der Internetanschluss für die Online Transaktionen auf dem Mainframe. Der zweite Grund ist die Möglichkeit bisherige Transaktionen als Schritte in die neu gestalteten Geschäftsprozesse einzubauen. Anderseits, darf der Übergang zur neuen Architektur die Kontinuität der laufenden Produktion nicht gefährden. Die Altsysteme müssen ununterbrochen ihren Dienst weiter leisten. Die Anforderung, eine neue ServiceArchitektur mit der bestehenden Fachlichkeit zu schaffen und die Einschränkungen dies mit möglichst wenig Kosten und ohne den laufenden Betrieb zu stören, stellt die Reengineering Technologie vor einer großen Herausforderung [2]. 3. Virtuelle Migration Der Begriff „Migration“ wird normalerweise benutzt um die Versetzung eines Systems in eine andere Umgebung, bzw. die Übertragung der Daten in eine andere Art Datenbank oder die Übersetzung der Programme in eine andere Programmiersprache, zu bezeichnen [3]. Eigentlich trifft diese Definition hier nicht ganz zu, denn die Software bleibt in derselben Sprache und in derselben Umgebung in der sie bisher war. Nichts ändert sich außer den Schnittstellen zu der Software. Folglich handelt es sich weniger um eine herkömmliche Migration als viel mehr um eine Integration, bzw. um eine virtuelle Migration [4]. Die bestehenden IMS Transaktionen auf dem Mainframe werden in eine neue service-orientierte Architektur integriert. Statt mit den Endanwendern direkt über feste MFS Masken auf 3270 Terminals zu kommunizieren, kommunizieren sie mit den Web Clienten der Geschäftsprozesse indirekt über WSDL Schnittstellen. Sie werden zu Knoten in einem unternehmensweiten Netz von Web Services [5]. 4. Stand der Forschung auf dem Gebiet der Web Service Mining Dieses Projekt ist nicht das Erste dieser Art. Forschung auf dem Gebiet der Web Service Mining findet schon seit Jahren statt, allerdings ohne all zu viele praktische Ergebnisse. Mit „Mining“ ist die Gewinnung der Services aus der bestehenden Codemasse gemeint. Die Vision einer Serviceorientierten Architektur ist für die überlasteten Anwender mit ihren veralteten Legacysysteme so etwas wie eine Fata Morgana. Sie verspricht Ihnen die Befreiung von den Fesseln ihrer Softwaretechnischen Vergangenheit. Kommerzielle Produktanbieter und Service-Dienstleister nähren dieser Hoffnung mit neuen verheißungsvollen Produkten und Services [6]. Dennoch um in den Genuss jener Produkte und Services zu kommen, müssen die Anwender erst den funktionalen Inhalt bereitstellen. Es liegt nahe, diese Funktionalität aus den bestehenden Anwendungen zu entnehmen. Das haben Forscher der Software-Reengineering Gemeinde bald erkannt und einige haben schon 2004 begonnen, Methoden und Werkzeuge zu entwickeln mit deren Hilfe die Funktionalität alter Programme sich wiederaufbereiten lässt. Die ersten Forschungsprojekte für diesen Zweck 153 begannen gleichzeitig an den Universitäten Benevento und Bari in Italien, Durham in G.B. sowie Victoria und Waterloo in Kanada im Jahre 2005. Das amerikanische Software Engineering Institute hat auch damit begonnen, diese Möglichkeit der Softwarewiedergewinnung zu erforschen. Die Ergebnisse der Forschung sind auf den WCRE, der ICSM und der CSMR Konferenzen vorgestellt worden. Das RCOST Institut in Benevento hatte schon 2002 ein Projekt zur Kapselung alter COBOL Systeme in einer Webanwendung für die Gemendeverwaltung der Campania durchgeführt [7]. Forscher an der Universität Victoria haben sich spezialisiert auf die Migration von Altsysteme in Web Anwendungen. Diese Forschung wurde inzwischen auf die Migration zu einer serviceorientierten Architektur ausgedehnt [8]. Die SEI hat eine Forschungsgemeinde mit eigner Website zu diesem Zweck gegründet [9]. Dieser Autor hat über seine ersten Forschungsergebnisse im Jahre 2006 auf der CSMR in Bari berichtet [10]. Es mangelt also nicht an Forschung auf diesem Gebiet. Was fehlt, ist eine echte industrielle Anwendung. Das vorliegende Projekt ist ein erster Schritt in diese Richtung. 5. Ziele des Pilotprojektes Wie mit allen Migrations- und Integrationsprojekten, die Neugrund betreten, wurde auch hier ein Pilotprojekt vorgesehen. Pilotprojekte werden durchgeführt um neue Technologien zu testen und daraus Erfahrungswerte zu sammeln, mit deren Hilfe das IT Management Entscheidungen treffen kann. Zum einen, ist noch offen, ob das Unternehmen überhaupt in Richtung Service-orientierte Architektur gehen sollte. Diese Entscheidung hängt davon, ob genügend billige Web Services zur Verfügung stehen. In dem fraglichen Unternehmen kommt weder eine Neuentwicklung noch Standardsoftware in Frage. Eine Neuentwicklung wäre zu teuer und Standardsoftware ist nicht vorhanden. Open Source Services decken nur einen kleinen Teil der erforderlichen Services ab. Also bleibt nur das Alternativ, die Services aus der bestehenden Software zu übernehmen. Die Frage ist nur wie. Der Anwender könnte die bestehenden Online-Programme so kapseln wie sie sind. Man brauchte nur die IMS Masken durch Webseiten zu ersetzen, aber das ergibt keine Web Services sondern nur gekapselte Transaktionen. Die einzige Möglichkeit echte Web Services aus der bestehenden Software zu bekommen ist sie herauszuschneiden. Dies ist jedoch ein gewagtes Unterfangen und musste erprobt werden. Daher das Pilotprojekt. Die Ziele des Pilotprojektes sind wie folgt: 1) die Größe, Komplexität und Qualität der IMS/COBOL Programme zu messen, um den Umfang der Kapselungsarbeit abschätzen zu können. 2) die potentielle Wiederverwendung der Programme als Web Services zu messen. 3) die Möglichkeit zu prüfen, Codescheiben herauszuschneiden, um als Web Services wieder zu verwenden. 4) den Beweis zu liefern, dass es möglich ist ausgewählte Programmscheiben zu kapseln ohne die ganze IMS-TP Transaktion zu kapseln. 5) den Zugriff auf die gekapselten Web Services über Websphere zu testen. 5.1. Messung der Kandidaten-Programme Das erste Ziel war die Messung der vorhandenen Software bezüglich ihrer Größe, Komplexität und Qualität. Alle 7,297 COBOL Programme wurden mit dem Werkzeug COBAudit gemessen. Die Größenmessungen waren unter anderem die Anzahl Codezeilen, die Anzahl Anweisungen, die Anzahl Datengruppen, die Anzahl Datenelemente, die Anzahl Dateien, die Anzahl Datenbanktabellen, die Anzahl Datenbankzugriffe, die Anzahl Entscheidungsknoten, die Anzahl 154 Unterprogramme und die Anzahl Unterprogrammaufrufe. Insgesamt wurden 56 Code-Quantitäten gezählt. Die Programmkomplexität wurde im Bezug auf acht Komplexitätsmetriken gemessen, die Datenkomplexität von Chapin, die Datenflusskomplexität von Elshof, die Datenzugriffskomplexität von Card, die Schnittstellenkomplexität von Henry, die Steuerflusskomplexität von McCabe, die Entscheidungskomplexität von McClure, die Verzweigungskomplexität von Sneed, die Sprachkomplexität von Halstead. Diese Komplexitätsmaße sind in früheren Beiträgen des Autors veröffentlicht worden [11]. Es genügt hier darauf hinzuweisen, dass die Programmkomplexität als Koeffizient auf der rationalen Skala von 0 bis 1 ausgedruckt wird, mit 0,5 als mittlere Komplexität. Eine Komplexitätsnote über 0,6 zeigt, dass ein Programm übermäßig komplex ist. Eine Note unter 0,4 lässt schließen, dass die Komplexität kein Problem ist. 0 bis 0,4 steht für niedrige Komplexität, 0,4 bis 0,6 mittlere Komplexität, 0,6 bis 0,8 hohe Komplexität und über 0,8 bedeutet der Code sei nicht veränderbar. Die Programmqualität wurde im Bezug auf die Modularität, die Portabilität, die Wiederverwendbarkeit, die Konvertibilität, die Flexibilität, die Testbarkeit, die Konformität und die Wartbarkeit gemessen. Auch diese Metriken sind in der Literatur mehrfach beschrieben worden. Von besonderer Bedeutung für die Wiederverwendung als Web Service sind die Qualitätsmerkmale Modularität, Wiederverwendbarkeit und Flexibilität. Modularität versteht sich als hohe Kohäsion und niedrige Kopplung. Je weniger Verbindungen ein Codebaustein zu anderen Bausteinen hat, desto leichter ist es sie herauszuschneiden. Die Wiederverwendung ist eine Frage der Unabhängigkeit von den anderen Bausteinen sowie von der technischen Umgebung. Wiederverwendbare Bausteine haben keine IO Operationen, keine Datenbankzugriffe und keine Aufrufe fremder Bausteine. Flexibilität ist schließlich die Unabhängigkeit von fachlichen Daten. Der Code sollte von eingebauten Daten – hard coded Data – frei sein damit sie mit beliebigen Daten verwendbar ist [12] Die Messung des Codes sollte zeigen welche Programme sich als Web Services gut eignen und welche sich dafür gar nicht eignen. Sie soll auch darüber Aufschluß geben, was es kosten würde die Programme zu kapseln. Die Kapselungskosten werden vor allem von der Kapselungsfähigkeit bestimmt. Diese sei wiederum eine Frage der Modularität, der Wiederverwendbarkeit und der Flexibilität. 5.2. Bewertung der Wiederverwendbarkeit Nachdem der Source Code gemessen worden ist, ist es möglich zu bewerten ob und zu welchem Grade sich der Code wieder verwenden lässt. Im alten Code liegt sehr viel Redundanz. Er enthält auch viele Operationen die mit dem Aufbau der Benutzeroberfläche oder mit der Bedienung systeminterner Schnittstellen beschäftigt sind. Dieser Code ist in einer Web Service überflüssig, bzw. er wird durch anderen Code ersetzt. Je mehr dieser Code mit dem fachlichen Code verflochten ist, desto schwieriger ist es, den fachlichen Code davon zu trennen, d.h. der fachliche Teil des Codes sollte möglichst wenig Verbindungen zu dem anderen Code haben. Das Gleiche trifft für die Verbindungen zu fremden Modulen zu. Ein wiederverwendbarer Baustein soll weder auf globale Daten zugreifen noch fremde Funktionen benutzen. Anhand der Metrik, ist es möglich zu erkennen ob ein Programm zur Wiederverwendung geeignet ist oder nicht. Insofern als es aus überschaubaren, abgeschlossenen Codebausteinen besteht, die von außen angesteuert werden, können diese Bausteine in einem anderen Zusammenhang wieder verwendet werden. Falls das Programm einen einzigen Eingang mit einer begrenzten Anzahl 155 Parameter hat, lässt sich das Programm als ganzes wieder verwenden. Besonders wichtig für Online-Programme ist, dass ein Programm nur eine Maske bearbeitet. Diese eine Maske kann durch eine Webschnittstelle ersetzt werden. Wenn mehrere Masken der Reihe nach verarbeitet werden, sind auch mehrere synchrone Webschnittstellen erforderlich. Das eine Web Service muss vor dem nächsten beendet sein. Dies steht wiederum im Widerspruch zur Asynchronität von Web Services. Daher die Notwendigkeit die Benutzeroberflächen von einander zu entkoppeln. Durch die Bewertung der Wiederverwendbarkeit werden die Programme in drei Klassen geteilt – Programme, die grundsätzlich nicht wieder zu verwenden sind, Programme, die leicht wieder zu verwenden sind und Programme die nur nach einer Refaktorierung wieder zu verwenden sind. Falls ein signifikanter Anteil der Programme zur ersten Kategorie gehört, lohnt es sich nicht das Projekt weiter zu betreiben. In diesem Falle gab es genüg Programme in der zweiten und dritten Klasse. Allerdings müssten einige Programme refaktoriert werden und dass bedeutete ein zusätzlicher Aufwand. Nach der Refaktorierung mussten sie in der alten Umgebung wieder getestet werden um sicher zu stellen, dass die Veränderung keine Fehler verursacht hat. (siehe Abbildung 1) Reusabilty potentieller Web Services sollte > 75% sein. Kapselungsfähigkeit = 1 [ Anzahl externer Abhängigkeiten ______________________________ Anzahl Anweisungen ] Externer Abhängigkeiten = externe Daten + externe Verbindungen SYSTEM Fremde Module PROGRAMM Globale Daten Zahl der externen Verbindungen MODUL Interne Prozedur aufrufe Fremde Daten Prozeduren Zahl der externen Daten Zahl der Anweisungen Abbildung 1: Bewertung der Kapselunsfähigkeit 5.3. Code Stripping Code-Stripping ist eine Testtechnik zur Isolierung einzelner Pfade durch ein Programm damit jeder Pfad allein für sich getestet werden kann. Der eine Pfad bleibt, der Rest des Codes wird aus kommentiert. Es wird so viele Versionen eines Programmes generiert, als es zu testende Pfade hat. Diese Technik ist aus dem ESPRIT Trust Projekt hervorgegangen, dessen Aufgabe es war den Test von Realtime-Embedded Software zu messen. Da man den Code nicht instrumentieren konnte, war es erforderlich ein Pfad nach dem anderen zu testen, unabhängig von den anderen. Ein Pfad ist hier zu verstehen als ein einmaliger Weg vom Eingang bis zum Ausgang durch den Code. Er besteht aus einer endlichen Anzahl aufeinander folgender Anweisungen, wobei einige Anweisungen mehrfach wiederholt werden können. Das Code Stripping wurde automatisch mit Hilfe eines Werkzeuges bewerkstelligt. Das Werkzeug musste nur einen Startpunkt und einen Endepunkt mitgeteilt bekommen. Vom Startpunkt aus verfolgte er jeden Ablaufpfad durch den Code bis zum Ausgang, markierte die Anweisungen auf dem Pfad und blendete die anderen Anweisungen aus. Auf dieser Weise war es möglich jeder Pfad getrennt für sich zu testen. [13] 156 Im Zusammenhang mit der Kapselung von Code, wird Code-Stripping eingesetzt um Codestreifen heraus zu schneiden. Jede Codestreife ist ein Pfad, der zu einem bestimmten fachlichen Ergebnis führt. Diese Codestreifen bilden potentielle Web Services. Im alten prozeduralen Code wie auch im neuen object-orientierten Code sind die Anweisungen zur Implementierung der Geschäftsregel miteinander verwoben. Es kann vorkommen, dass eine Anweisungsgruppe, bzw ein Codeblock oder eine Methode, in mehreren Pfaden vorkommt. Mit Rücksicht auf die Flexibilität der Geschäftsprozesse ist es aber wichtig, dass ein Web Service einer einzigen Geschäftsregel entspricht. Deshalb müssen die Pfade einzeln auseinander genommen werden. Der Bediener des Werkzeuges muss für jeden Stripping Lauf das gewünschte Ergebnis identifizieren. Danach verfolgt das Werkzeug den Pfad vom Endergebnis zurück zum Ausgangspunkt und blendet den Rest des Codes aus. Was bleibt ist der Code für das Web Service. Dies wird für jede Geschäftsregel wiederholt. Am Ende gibt es mehrere Versionen des bisherigen Programms – eine für jede Geschäftsregel [14]. Dies führt zwar zu einer Vielzahl winziger Services, bietet aber ein Maximum an Flexibilität. Zur Feststellung ob dies wirklich machbar ist, war es notwendig einige Beispielprogramme zu nehmen und sie durch das Stripping Automat – COBStrip - zu senden. COBStrip erfordert eine menschliche Interaktion. Der Benutzer muss jene Ausgabedaten identifizieren, die zur Response einer Web Service gehören. Zu diesem Zweck werden alle Programmausgaben in einer Liste angezeigt. Bei Online-Programmen befinden sich jene Ausgaben normalerweise in den Datenstrukturen der Masken. Hier handelte es sich um die Message Format Service Masken in IMS-DC. Die Ergebnisdaten von Batchprogrammen liegen in den Berichten und den Ausgabedateien. Durch die Methode des Data-Slicing identifiziert das Tool alle Anweisungen, die zu den erwünschten Ergebnissen führen. Der Rest der Anweisungen wird auskommentiert. Was bleibt ist ein Rumpfprogramm bestehend aus den durchgelaufenden Anweisungen und den von diesen Anweisungen verwendeten Daten. In der Regel enthält ein solches Rumpfprogramm weniger als 20% des ursprünglichen Programmes. D.h. die potentiellen Web Services sind immer nur Teilprogramme. (siehe Abbildung 2) z.B. Kriterien der Bonitätseinstufung (Alter, Anstellung, Gehalt, u.s.w.) Prozess Parameter betroffene Daten Der W eg zum Ergebnis = Pfadausdruck Programm Ergebnis = Verarbeitungsregel (Parameter); Verarbeitungsregel = Umsetzung (Pfadausdruck); Pfadausdruck = [< Bedingungen >]n; betroffenes Programm betroffene Prozedur Prozedur z.B. If festangestellt Pfadausdruck Bedingung A Bedingung B n z.B. If Alter < 60 betroffene Anweisungen Verarbeit ungs regel Ergebnis z.B. Bonitätsstufe = Gut Abbildung 2: Pfadauswahl 5.4. Kapselung der Codestreifen Nachdem die Programmstreifen als eigene, einzelne Programme vorliegen und erfolgreich compiliert sind, kommt es darauf an, sie hinter einer WSDL Schnittstelle zu kapseln. Dafür sind zwei weitere Werkzeuge erforderlich – COBWrap und COBLink. 157 COBWrap verarbeitet die Programmstreifen, um die Bildschirmein- und ausgaben mit Aufrufen zu Methoden in den Wrapper-Modulen zu ersetzen. Außerdem werden die Argumente und Ergebnisse in einen Parameterdatenbereich verlagert. Im Falle von IMS, werden die Eingabemasken über einen Aufruf zum TP-Monitor empfangen. CALL ’DLITCOB’ USING PARAM-NR, IO-PCB, INPUT-MAP Ein ähnlicher Aufruf bewirkt das Senden der Ausgabemaske an den Endterminal. CALL ‘COBTDLI’ USING PARAM-NR, IO-PCB, OUTPUT-MAP COBWrap ersetzt diese originalen Aufrufe durch Aufrufe zum Wrapper-Modul. CALL ‘WSDL2COB’ USING PARAM-NR, XML-PCB, INPUT-MAP CALL ‘COBTWSDL’ USING PARAM-NR, XML-PCB, OUTPUT-MAP Die Daten in dem Parameterbereich werden an den Wrapper-Modul übergeben. Unter CICS sind die Anwenderprogramme Unterprogramme, die Daten in einem Kommunikationsbereich mit dem übergeordneten TP-Monitor austauscht. Im Falle von IMS ist es gerade umgekehrt. Das Anwendungsprogramm ist das Hauptprogramm, der TP-Monitor das Unterprogramm. Es ist deshalb einfacher IMS-Programme zu kapseln. Die Aufrufslogik bleibt unverändert. Nur die Namen und Parameter werden ausgewechselt. Der Autor hat schon über ein ähnliches Kapselungsprojekt bei den deutschen Sparkassen berichtet, bei dem diese Kappselungstechnik bereits erfolgreich verwendet wurde [15]. Bei jenem Projekt ging es um die Kapselung von Assemblerprogrammen und zwar ohne Werkzeug. Hier konnten die COBOL Programme mit Hilfe eines Werkzeuges automatisch gekapselt werden. Eine Kapselung dauert nur Sekunden. (siehe Abbildung 3) Input Map Online IMS-DC Program Output Map RECEIVE MAP. .......................... <Processing>...... from Terminal ........... SEND MAP COBWRAP to Terminal T ransformation W eb Service Request W SDL Input Message from Client * RECEIVE MAP. ENTRY USING MSG MO VE MSG TO DATA ..................................... <Processing> ..................................... MO VE DATA TO MSG RETURN W eb Service Response New Web Service W SDL Output Message to Client Abbildung 3: Programmkapselung 5.5. Einbindung der gekapselten Teilprogramme Der letzte Schritt auf dem Wege zu den Web Services ist die Einbindung der gekapselten Teilprogramme in die SOA Umgebung. Dies ist die Aufgabe des Werkzeuges COBLink. COBLink produziert zwei Wrapper-Module für jedes Teilprogramm – einen für die Umsetzung der Web Service Requests und einen für die Umsetzung der Web Service Responses. Die Eingabe dazu ist der Source-Code des Teilprogramms. Daraus entnimmt das Tool welche Parameter zu welchen Schnittstellen gehören. In einem Durchlauf wird ein WSDL Schema für die Eingabeparameter und den dazu gehörigen Wrapper - WSDL2COB - erzeugt. Im anderen Durchlauf wird ein WSDL Schema für die Ausgabeparameter und den dazu gehörigen Wrapper - COB2WSDL - generiert. 158 Beide Module erben von einer vordefinierten Schablone. Der erste Modul empfängt ein Web Service Request, übersetzt die XML Datentypen in entsprechenden COBOL Datentypen und überträgt sie an das COBOL Programm. Der zweite Modul übersetzt die COBOL Datentypen in entsprechenden WSDL Typen, überträgt sie in die Response und sendet die Response zurück an den Sender. (siehe Abbildung 4) External Interface Message Qeueing Component (WSDL) Data Conversion Component IO Simulation Component Internal Interface (COBOL) Abbildung 4: Aufbau des Wrappers Die vier Ergebnisse von COBLink sind die zwei WSDL Schemen – einen Request Schema und einen Response Schema – plus die beiden COBOL Wrapper-Module, die mit dem Web Service Programm zusammengelinkt werden. Das Web Service Programm wird von dem Websphere Scheduler gestartet sobald ein Service-Request in der Warteschlange auftaucht. Es ruft dann den Wrapper-Modul auf, der das Request als Datenstrom aus der Warteschlange liest und an das aufrufende Service-Programm überträgt. Wenn es fertig ist ruft das Service-Programm den Wrapper-Modul auf, um seine Ergebnisse als Response in die Warteschlange zu schreiben. Das Service-Programm übergibt dann die Steuerung zurück an Websphere. Auch diese Technik des Datenaustausches zwischen Web-Server und Web-Clients ist in einer früheren Veröffentlichung beschrieben worden [16]. Im Falle des Pilotprojektes wurde dieser letzte Schritt auf dem PC-Arbeitsplatz similiert, da eine entsprechende Hostumgebung noch nicht aufgebaut war. Es ginge nur darum das Proof of Concept zu liefern und dazu genügte es die Lauffähigkeit der gekapselten Teilprogramme auf dem PC zu demonstrieren. Natürlich sollte später die gekapselten Programme auch auf dem Host getestet werden. 6. Zusammenfassung Das Pilotprojekt für die Wiederaufbereitung alter COBOL Programme als Web Services hat bestätigt, dass es technisch möglich ist Codescheiben aus dem alten Code heraus schneiden. Diese Scheiben lassen sich auch kapseln und als Web Services in eine Service Architektur einbinden. Dennoch bleibt dieser Ansatz umstritten. Es bleiben viele offene Fragen. Eine Frage ist die der Kosten. Die Erstellung der Web Services ist zwar weitestgehend automatisiert und dadurch mit wenig Aufwand verbunden, aber es bleibt noch der Test. Bei jeder Codetransformation treten Seiteneffekte auf. Diese können wiederum zum Fehlverhalten führen. Ob ein Service sich wirklich wie erwartet verhält, wird man erst wissen wenn alle potentiellen Nutzungsarten getestet worden sind. Der Testaufwand ist hoch, aber dies gilt allgemein für Web Services. Erst muss der Service allein für sich und dann im Zusammenhang mit beispielhaften Geschäftsprozessen getestet werden. Eine weitere Frage ist die der Eignung der aus dem alten Code herausgenommenen Services. Werden sie wirklich zu den Anforderungen der neuen Geschäftsprozesse passen? Wenn nicht wäre 159 die ganze Arbeit umsonst gewesen. Diese Frage wird immer auftreten wenn die Services erstmals ohne Bezug zu bestimmten Prozessen entstanden sind. Da hier die Prozesse noch fehlen, kann keiner wissen ob die bereitgestellten Services passen werden oder nicht. Es weiteres Problem ist die feine Granularität der wieder gewonnenen Services. Ein Web Service hier entspricht einem einzigen Ergebnis – einem Wert oder einer Gruppe logisch zusammengehöriger Werte. So ist die Ermittlung einer Postleitzahl ein eigenständiger Service. Für einen einzigen Geschäftsprozess wird der Prozessverantwortlicher mehrere Hundert Services aufrufen müssen. Ob er dann noch den Überblick behält ist fraglich. Schließlich stellt sich die Frage der Wartung und –Weiterentwicklung. Da der Code in der gleichen alten Sprache mit der gleichen Qualität bleibt wird die Wartung nicht einfacher. Im Gegenteil, der Source-Code ist durch die Zerschneidung und Kapselung noch komplexer geworden und es werden noch COBOL Programmierer gebraucht um sie zu pflegen. Der Anwenderbetrieb trägt allein die Last der Erhaltung. Langfristig werden die Wartungskosten steigen. Es könnte gut sein, dass der Anwender es nach wenigen Jahren bereut, die Web Services nicht gleich neu gemacht zu haben, statt die Last der Vergangenheit mit sich in die Zukunft zu schleppen. Literaturhinweise [1] Lehman, M.: “On Understanding Laws, Evolution and Conservation in the Program Life Cycle”, Journal of Systems and Software, Vol. 1, No. 3, 1980, p. 213 [2] Seacord, R./Plakosh, D./Lewis, G.: Modernizing Legacy Systems, Addison-Wesley, Reading, 2003, p. 120 [3] Horowitz, E.: “Migrating Software to the World Wide Web”, IEEE Software, May 1998, p. 18 [4] Canfora, G./Fasolino, H./ Frattolillo, G.: “Migrating Interactive Legacy System to Web Services”, Proc. of CSMR2006, IEEE Computer Society Press, Bari, March 2006, p. 23 [5] Krafzig,D./Banke,K./Schama, D.:Enterprise SOA, Coad Series, Prentice-Hall,Upper Saddle River, N.J., 2004, p. 6 [6] Aversano, L./Canfora, G./deLucia, A.: “Migrating Legacy System to the Web”, in Proc. of CSMR-2001, IEEE Computer Society Press, Lisabon, March 2001, p. 148 [7] Bodhuin, T./Guardabascio, E./Tortorella, M.: “Migrating COBOL Systems to the WEB”, WCRE-2002, IEEE Computer Society Press, Richmond, Nov. 2002, p. 329 [8] Tilley, S./ Distante, D./ Huang, S.: ”Web Site Evolution via Transaction Reengineering”, Proc. of WSE 2004, Chicago, Sept. 2004, p. 31 [9] Kontogiannis, K./ Lewis, G. Smith, D.: “ A Research Agenda for Service-Oriented Maintenance” Workshop Proceedings of CSMR-2007, Amsterdam, 2007, p. 100 [10] Sneed, H.: ”Integrating legacy Software into a Service oriented Architecture”, in Proc. of CSMR-2006, IEEE Computer Society Press, Bari, March 2006, p. 3 [11] Sneed, H. “Understanding Software through Numbers”, Journal of Software Maintenance, Vol. 7, No. 6, Nov. 1995, p. 405 [12] Sneed, H.: “Measuring Reusability of Legacy Software” in Software Process, Vol. 4, Issue 1, March, 1998, p. 43 [13] Puhr, P./Sneed, H.: “Code Stripping as a means of instrumenting embedded systems” in EU ESPRIT Project 1258 – Report-1258-3, Liverpool, 1989 [14] Bichler,M./Kwei-Jay, L.: „Service oriented Computing“ IEEE Computer, March, 2006, p. 99 [15] Sneed,H., Majnar, R.: „“A Case Study in Software Wrapping“, Proc. of Int. Conference on Software Maintenance, IEEE Computer Society Press, Washington, D.C. Nov. 1998, p. 86-.93 [16] Sneed, H.: “Wrapping Legacy COBOL Programs behind an XML Interface”, Proc. Of WCRE-2001, IEEE Computer Society Press, Stuttgart, Oct. 2001, p. 189 160 IDENTITY MANAGEMENT IN BUSINESS PROCESS MODELLING: A MODEL-DRIVEN APPROACH Heiko Klarl1,2, Christian Wolff1, Christian Emig3 Abstract The modelling of business processes is widely used in enterprises. Though this is very common, requirements for identity management and access control are often collected separately in documents or requirement tools. Due to the business-driven background of access control, this kind of requirement should be collected at the business site's business process model. This work introduces a meta-model for modelling access control requirements at the business process level. It combines the model and its requirements, reducing the risk of inconsistencies caused by process changes. A model-driven development process utilises the enriched models for generating policies for different identity management products. 1. Introduction The success of the internet, the ongoing globalisation and resulting needs for faster communication and interaction with business partners as well as the implementation of new law and business regulations like Basel II or Sarbanes-Oxley Act [6] lead to a demand for new solutions. Serviceoriented architecture (SOA) tries to cope with those needs: The service-oriented architecture paradigm often uses the modelling of business processes, which is widely used and supported by a variety of well established notations [20, 32, 34] and tools. Despite these facts, (non-functional) requirements which are strongly related to the business process are commonly not integrated in its model. A lot of non-functional requirements arise in the area of identity management (IdM) [1], where access control is an important part. Currently, these IdM-related requirements are often “specified” in a non-formalised manner as unstructured text by the business department. If these specifications are not complete and cannot be understood by the IT security department, a complicated and error prone coordination process between both departments arises [cf. 7]. At this time, the application owner – namely the business department – loses its “requirement sovereignty”. Therefore it is highly dependent on the support of another department in formulating their own IdM requirements. Such a separation of the business process model and its related IdM requirements may easily result in inconsistencies if changes are not adapted immediately in all specification documents. In the following, we suggest a solution for this problem by enriching the business process model with a specification of IdM requirements. The model is used as the origin of a model-driven software development approach to generate concrete access control policies for 1 Media Computing, University of Regensburg, Germany 2 iC Consult GmbH, Keltenring 14, 82041 Oberhaching, Germany 3 Cooperation & Management, University of Karlsruhe (TH), Germany 161 service-oriented architectures. This work is based on a cooperation project between iC Consult GmbH, an independent service provider in the area of identity management, the department of Media Computing at the University of Regensburg and the research group Cooperation and Management at the University of Karlsruhe. The paper is organised as follows: Section 1 gives a short introduction to identity management and its relation to business process management. In section 2, we introduce our UML2 Profile for IdM as well as the Web Services Access Control Markup Language (WSACML), an access control meta-model for service-oriented architecture. Based on both specifications, a model-driven policy development process is described. The application to a real business scenario from the banking domain is shown in section 3. Section 4 discusses related work, and section 5 concludes the paper. 1.1. Main Aspects of Identity Management With the increasing complexity of the IT landscape in enterprises and the penetration of nearly all critical business processes by information technology, identity management is a key factor and one of the main building blocks of IT security [13]. IdM comprises authentication of identities, the authorisation of resource access as well as the logging of all events relevant for auditing requirements. These three pillars of IdM are embedded in several processes in order to mitigate its complexity. Policies containing permissions build the base for access control decisions [27]. They state whether an authenticated subject is allowed to access or interact with an object or a resource within the IT system. In the scope of regulations (e.g. the Sarbanes-Oxley-Act or Basel II), the requirements for the administration and documentation of access permissions and policies lead to a demand for sophisticated IdM solutions. A reference architecture for such a solution is shown in [3]; [17] describes an architecture for IdM in federated environments. 1.2. Identity Management and Business Process Modelling The importance of business processes models became obvious with the idea of business process reengineering [15] in the 90ies and with the upcoming of the service-oriented architecture paradigm [36]. The nearly arbitrary combination of single sub-processes or loosely coupled services to business processes in the sense of service-orientation is only possible on the base of meaningful and executable models. This enables enterprises to cope with market challenges and new business regulations in a flexible and agile way [36]. The focus lies on the optimal support of the business process whereas the IT plays a supporting role in the background. The modelling of business processes can be done in different notations like Event-driven Process Chains (EPC) [20], the Business Process Modeling Notation (BPMN) [32] or the behaviour diagrams of the Unified Modeling Language (UML) [34]. The short lifecycle of business processes and their opening to other businesses in the context of B2B-scenarios requires a constant adoption of IdM requirements in order to reach and guarantee high security standards [21]: On the one hand, functional specifications regarding identities, roles and permissions are constantly changing, on the other hand, changing specifications of the organisational layer, e.g. for supporting privacy or avoiding corruption play an increasing role in enterprise security. In order to meet these demands, traditionally hard coded security mechanisms are replaced by dynamic policies which are changeable at runtime. Closing the gap between specification of IdM requirements in documents and requirement management tools and the business process' model is still not done, resulting in different complementing specifications [11, 16, 25, 37]. The coupling of the business process' models and its security requirements will ensure a consistent state over all changes – functional ones as well as 162 those affecting security issues. The management of security relevant aspects will be tied stronger to the business process' development, avoiding inconsistencies in its protection. The business department should be supplied with tools not only for modelling their processes, but also for integrating their IdM requirements in those models. 2. Modelling and Transforming IdM Requirements within Business Processes In order to cope with the problems described above and to force the coupling of business process and its security requirements, we propose the modelling of requirements in business process models. A model-driven approach that generates concrete security policies based on the models will be introduced in the following sections. 2.1. The Development Process and its Relation to Model-driven Architecture The development process typically starts with defining the business process in the business department. Preparatory steps like use-case analyses or textual specifications etc. are not in the focus of this paper: Our contribution starts with the business process already modelled and we see this point as the computational independent model (CIM) in the sense of OMGs' Model-driven Architecture (MDA) [31]. In this view, the CIM contains all information of the business process – enriched with security specifications based on the UML2 profile for IdM. A semi-automatic transformation process with possible manual additions leads to the platform independent model (PIM), containing only security specifications at a platform neutral level. A meta-model for this has been presented as WSACML in [8]. Its generic design does not include any (security) product specific elements, so that the last transformation step can create platform specific code (PSC) for different platforms like CA SiteMinder or IBM Tivoli Access Manager. 2.2. Securing a Business Process by the UML2 Profile for Identity Management The business department should be able to define its own or compliance-driven IdM requirements, using their specific domain knowledge in business process modelling. This enables a fully modeldriven software development process, starting with the modelling of IdM requirements in the business department and resulting in security policies for a specific software system. We utilise UML behaviour diagrams, especially activity diagrams, used for modelling data- and control flows as well as workflows [4, 35]. UML itself is based on a meta-model supported by a variety of tools and known and accepted in enterprises. The UML profile mechanism offers a lightweight approach to extend this meta-model. This can be done by adding new elements for special domains without losing UML’s tool support. Stereotypes do not change the meta-model but extend and specify existing UML meta-classes for special use-cases. New elements are named and can immediately be used as the profiles' elements. Constraints are used in order to restrict elements in their behaviour, and can be expressed in prose, (pseudo-) programming languages or in dedicated languages like OCL (Object Constraint Language) [33]. Constraints must not be in conflict with inherited constraints of the meta-class. Tagged values are key-value-pairs, enriching stereotypes with additional information. UMLs' syntax and semantic is not touched by UML profile extensions. The UML2 profile for IdM supports the modelling of access control policies within activity diagrams. In case of a business process it offers the possibility to represent its behaviour as well as its constraints for accessing certain actions. The model of the UML2 profile for IdM is shown in Figure 1. The element «IdMAction» extends the UMLs' activity diagram element «action», indicating that this must be secured by the IdM infrastructure. It contains the attributes complianceClassifier and securityClassifier providing the possibility to classify the element 163 according to its compliance and security guidelines. Those are defined at the enterprise architectural level. The container element «Policy» links single «Permission» elements in a disjunctive manner; this allows the reuse of «Permission» elements in different «Policy» elements or policies. «Policy» owns the same classification attributes as «IdMAction». In order to avoid conflicts due to contradicting policies as well as to reduce complexity at the business process level, only one policy may be assigned to an «IdMAction». «Permission» elements encapsulate one or more «Assertion» elements for covering one access control situation. The element «Assertion» contains the positive access control statement, allowing access on resources. This means that every access authorisation has to be defined in a dedicated permission. An «Assertion» element aggregates «SubjectAttribute», «ObjectAttribute», «EnvironmentAttribute», «InputParameter» and «Constant». <<metaclass>> Action <<stereotype>> IdMAction [Action] <<metaclass>> ActivityNode 1 1 -complianceClassifier -securityClassifier <<stereotype>> Policy [ActivityNode] <<metaclass>> ActivityPartition 1 -complianceClassifier -securityClassifier 1 <<metaclass>> ActivityGroup 1 1 <<stereotype>> IdMActivityGroup [ActivityGroup] 1 <<stereotype>> IdMRole [ActivityPartition] 1..* 1 * <<stereotype>> DraftedPermission 1..* <<stereotype>> Permission * -Comment 1..* * 1..* <<stereotype>> Assertion 1 * <<stereotype>> SubjectAttribute * <<stereotype>> ObjectAttribute * <<stereotype>> EnvironmentAttribute * <<stereotype>> InputParameter * <<stereotype>> Constant Figure 1: The UML2 Profile for Identity Management The object being accessed is described by the «ObjectAttribute». A sophisticated enterprise architecture with well-defined business objects types supports the selection of relevant object attributes tremendously. «EnvironmentAttribute» contains metadata such as time, date and the systems conditions whereas «InputParameter» specifies input data. For comparing attributes with specific values, «Constant» is used. In case the business department was not able to to properly define an adequate policy with these modelling concepts, a «DraftedPermission» contains access control statements without formalisation, i.e. descriptions of the desired behaviour in prose. These drafts must be refined by business security analysts resulting in a valid set of «Permission» and «Policy» elements. «IdMRole» extends the concept of activity partitions in order to assign business roles to «IdMAction» elements. The same pieces of information can also be covered by utilising «SubjectAttribute» to describe the business role of the accessing subject – which reduces the visual complexity in case of dozens of roles involved in a business process. We consider the description 164 of roles not in the classical role-based access control (RBAC) [10] manner but define a business role as a set of subjects attributes as described in [42]. «IdMActivityGroup» allows grouping of elements for assigning a «Policy» or «DraftedPermission» only once to a set of elements. An overview regarding the elements' constraints defined in the meta-model is given in [22]. 2.3. WSACML – An Access Control Meta-model for Web Service-Oriented Architecture Looking at the mass and complexity of the existing and upcoming specifications in the web service security area like WS-Security, WS-Trust, SAML, eXtensible Access Control Markup Language (XACML) or the Liberty Alliance’s stack proposal [12, 30], it is comprehensible that software developers often neglect the web service security part. Additionally, state-of-the-art IdM suites are not yet prepared for web service-oriented architectures and their accompanying standards [29]. At the same time application servers often do not yet support necessary combinations of relevant IdM standards. This is why currently existing web services in most cases have little or no security features. In [8] we have introduced WSACML, an access control meta-model for web serviceoriented architectures which is utilised as meta-model for the platform independent model (PIM). It eases its use, as complexity like in XACML is reduced. WSACML describes policies at the PIM level, which means that they are specified with detailed technical resource descriptions etc. but platform specific details and notations for security products are not covered. This is done by a last transformation shown in detail in [9]. 2.4. From the Business Process to Concrete Security Policies – The Transformation Process CIM PIM PSM/PSC UML2 Profile for IdM [22] WSACML [8] Product Policies [9] Figure 2: Overview of Model-driven Policy Development In order to create security policies for a certain IdM product, we have implemented a prototypical model-driven transformation process with two transformations (cf. Figure 2). To ease the implementation process we utilise a XML-based transformation approach. We generate XML schema definitions (XSDs) based on the meta-models for the CIM and PIM introduced in the previous sections and use them as a template for valid policy information. We start with a business process that has already been modelled and which has been annotated with security policies and extract security-specific information to a XML file (cf. Listing 1). In a second step a Java-based application parses this XML-file structured according to the rules of our XSD and transforms the elements according to the mapping rules shown in Table 1. Then it checks the compliance with constraints described in [22]. During the transformation process a manual enrichment has to be done by a business security analyst. This analyst should be able to provide additional information for a fine tuning of the security requirements for the platform independent model. 165 UML2 Profile for IdM WSACML IdMAction Manually resolved to service description and mapped to ServiceOperationBinding IdMRole Builds some parts of the SubjectAttribute IdMActivityGroup Assignment of the same policy to all IdMActions in this area Policy Policy DraftedPermission Empty Policy containing comments, which must be refined by a business security analyst. Permission Rule Assertion Assertion *Attribute *Attribute The * stands for all attributes shown in the meta-model of the UML2 profile for IdM (cf. Figure 1) Table 1: Mapping rules for the UML2 Profile for IdM to WSACML The first transformation process results in a WSACML policy shown in Listing 2. Utilising the transformation described in [9], the generation of platform specific code (PSC) comes into play: WSACML policies are transformed into security policies for a certain product. This requires knowledge on the policy-model of the specific security software product. Further information will be provided in [9]. Currently, our transformer tool supports the generation of CA SiteMinder policies. A support for IBM Tivoli Access Manager is under development at the moment. <SecureBusinessProcess> <idmAction complianceClassifier="1" securityClassifier="2" name="Override Scoring Exception"> <policyLink policyName="Override Scoring Policy" /> </idmAction> <policy name="Override Scoring Policy"> <permissionLink permissionName="ScoringPermission"/> </policy> <permission name="ScoringPermission"> <assertion assertionFunction="equal"> <subjectAttribute value="roleName" /> <constant value="AM in chief " /> </assertion> <assertion assertionFunction="equal"> <objectAttribute value="exception.type" /> <constant value="warning" /> </assertion> <assertion assertionFunction="less-than"> <objectAttribute value="exception.score" /> <constant value="4" /> </assertion> </permission> </SecureBusinessProcess> <PolicyContainer> <policy name="Override Scoring Exception" ruleSelectionAlgorithm="--TODO--" serviceOperationBinding ="--TODO--Override Scoring Exception"> <ruleref>ScoringPermission</ruleref> </policy> <rule name="ScoringPermission"> <assertion assertionFunction="equal"> <subjectAttribute value="roleName" /> <constant value="AM in chief" />" /> </assertion> <assertion assertionFunction="equal"> <objectAttribute value="exception.type" /> <constant value="warning" /> </assertion> <assertion assertionFunction="lessthan"> <objectAttribute value="exception.score" /> <constant value="4" /> </assertion> </rule> </PolicyContainer> Listing 1: UML2 Profile for IdM (XML representation) Listing 2: WSACML 3. Example: Securing a Banking Process In the banking area business processes are changing often, caused by a very dynamic and customerdriven market environment. As a typical example we choose the opening process for a current account. As the presentation of the complete process might well go beyond the scope of this paper, we show only sections of the process as this should be enough to get an idea of how our method is applied to secure the business process. Figure 3 shows the business process model with security166 related information added. After a general contract has been created by an account manager the opening of a current account is checked. When the application for a current account is formally correct, a credit rating service is called, followed by a scoring by another service. These actions are secured by the Check Account Opening Policy. The policy limits the roles that are allowed to execute those actions to the role 'Account manager' and it may have some contextual restrictions like 'Opening a current account is allowed only at the office times from 7am to 7pm'. If there are no exceptions, the current account will be created; otherwise the opening is delegated to the clerk's supervisor who may override some kind of exceptions (exception score lower than four). This is represented by the Override Scoring Policy shown in Listing 1 which limits the executing role to ‘Account manager (AM) in chief’ and the exception level lower to four. <<IdMActivityGroup>> <<IdMAction>> Create General Contract <<IdMAction>> Check Account Opening <<IdMAction>> Call Credit Rating Service <<IdMAction>> Call Scoring Service <<Policy>> Check Account Opening Policy <<DraftedPermission>> Override Scoring Policy <<IdMAction>> Override Scoring Exception Figure 2: Secured Business Process Model for Opening a Current Account 4. Related Work Concerning the integration of requirements in models, many papers have been published recently. The state of the art can be divided into two major parts: On the one hand high level models for usage at business departments, on the other hand IT-centric models like UML class diagrams that are enriched by annotations and requirements. In the area of models for usage at the business site [23] extends the UML activity diagram enabling a modelling of business and performance goals for use with concepts like balanced score card. An extension for the UML activity diagram to model event-driven process chains (EPC) is shown in [24]. In both papers UML is extended via its profile mechanism. In the area of information security a meta-model for descriptive collection of requirements is shown in [37, 38]. It is applied to the UML activity diagram via an UML profile as well as to BPMNs' meta-model. Stereotypes like SecurityAuditing or SecurityRequirement are introduced for usage in the business process model in order to visualise requirements for auditing or the core security requirements like authentication, authorisation and non-repudiation. Nevertheless, most of this work remains at a descriptive level. The stereotypes introduced are just simple annotations comparable with classified comments. In [39] Rodríguez et al. propose the generation of use case views out of business process models which are examined for security requirements. As in their previous work [37, 38], there are no possibilities to specify requirements directly in the business process model and the proposed approach can be only used to find security problems at a high level view. Round trip engineering is missing, so that results found in the use case diagrams can not be added to the processes' model. In [40] another solution for modelling security goals in BPMN is introduced: A generic security model captures the relations between basic entities like objects, attributes, interactions and effects. The model includes views on the enterprise architectural space which allows connecting elements 167 from different perspectives. However, it lacks a relationship with the model-driven approach as well as definitions of how policies can be formulated, stored and administrated. In their previous work ([41]) Wolter et al. have proposed an extension of the BPMN for including authorisation constraints which are strongly focused on a separation of duties (SoD). Utilising XSLT transformations, the XML representation of the enriched business process is used for generating XACML policies. However, they do not discuss the modelling of complex access control scenarios. In contrast to our work, their target model is XACML – this is basically a good idea as it is a standard – but as the application of XACML policies in standard access control products is only partly possible, it would be better to generate concrete policies for certain products. In the area of workflow security, some further work has been published. In [14] a UML based approach for applying security requirements to the Web Service Choreography Description Language (WS-CDL) is proposed. A UML model of the workflow is enriched with security artefacts and could be translated to XML code files that comply with web services standards. As this enrichment is done on a technical level, the procedure will not be viable for the typical business department. Bertino et al. present in [2] how Web Services Business Process Execution Language (WS-BPEL) is enriched by authorisation constraints and authorisation information for access control. They introduce the Business Process Constraint Language (BPCL) which allows formulating the authorisation constraints. A WS-BPEL engine has been extended to be able to interpret these access control constraints. BPCL is limited to users, roles and activities. Attributebased access control which we propose as the optimum for service-oriented architecture is not supported. Due to its technical focus, it is not adequate for use at a business department. Patterns for securing web services are proposed in [18]. The so called idioms were applied to orchestrated services and contain technical solutions and templates for predefined threat scenarios. They cover non-functional requirements but only at the orchestration level. An explicit possibility for modelling access control policies or IdM requirements is not given. Looking at IT-centric research, in [19] an UML profile called UMLsec for modelling safety critical systems is shown. It supports the enrichment of UML class models with security relevant information. Its focus is to support software developers who already are knowledgeable in the security area. The recording of access control policies, especially at the business departments' level is not covered. An UML-based modelling notation combined with a notation for specifying access control models is shown in [26]. This approach is also placed rather late in the software development process, as the requirements are modelled at the class diagrams' level. In [5], Breu et al. propose a model-based development of access policies combining a predicative language (OCL) with XACML as an access policy standard. Access permissions can be specified for methods and method categories at a technical level. A Java-based tool allows the generation of XACML policies. Like other approaches mentioned before, the technical focus of this approach will most likely prevent its application in the context of business departments. Neubauer et al. cover in [28] aspects of secure business processes and its administration. The roadmap of a secure business process is shown in its different stages regarding the inclusion of security aspects. At the second stage he describes the security enriched business process as a base for workflow systems. Looking at related work, there is on the one hand a very strong focus on business aspects with no possibilities of integrating security requirements. On the other hand the modelling of security requirements is possible on a deeper, workflow or technical level. These solutions often require specialised knowledge of modelling and the architectural aspects of software systems as well as a wide and detailed knowledge on security solutions. Altogether, a gap between modelled business processes at the business departments’ site and documents and tools containing the business process' security specifications remains. 168 5. Conclusion In this paper, we propose a model-driven development process for the creation of access control policies in the context of service-oriented architectures. The development starts with the business process model at the business departments' level, where computational independent process models are enriched with elements for specifying requirements for identity management. Transformation processes translate the model to concrete security policies for different commercial products. The novel aspect of this approach is the direct application of IdM requirements specifications to business process specifications. Thus, the model-driven generation of access control policies can be supported. There is no need for document-based requirement specifications, because all requirements are captured in the business process model where the domain knowledge is available – in the business department. This work lays the fundament by proposing how access control policies can be specified in business processes. Future work will be done on improving the graphical modelling of the business process and its security requirements. The business department will be supported by easy to handle tools, with optimised usability for modelling security enriched business processes. The modelling process will be complemented by utilising policy and business objects repositories to benefit from (re)using existing data. Another aspect being worked on will be the checking of secured business process models for being in compliance with the enterprise’s security standards or law regulations. 6. References [1] H. Bagheri and S.-H. Mirian-Hosseinabadi. Injecting security as aspectable NFR into software architectture. In Proc. 14th Asia-Pacific Software Engineering Conf., pages 310–317. IEEE Computer Society, 2007. [2] E. Bertino, J. Crampton, and F. Paci. Access Control and Authorization Constraints for WS-BPEL. In IEEE Int’l Conf. on Web Services, pages 275–284. IEEE Computer Society, 2006. [3] D. Blum. Identity Management. Technical report, Burton Group, Nov. 2005. [4] M. Born, E. Holz, and O. Kath. Softwareentwicklung mit UML 2. Addison-Wesley, München, 2004. [5] R. Breu, G. Popp, and M. Alam. Model based development of access policies. International Journal on Software Tools for Technology Transfer, 9(5–6):457–470, Oct. 2007. [6] M. Burling. The key to compliance. Database-and-Network-Journal, 35(3):17–18, 2005. [7] S. Cormack, A. Cater-Steel, J. H. Nord, and G. D. Nord. Resolving the troubled IT-business relationship from a cultural perspective. In Proc. 12th Australasian Conf. on Information Systems, Australia, Dec. 2001. [8] C. Emig, F. Brandt, S. Abeck, J. Biermann, and H. Klarl. An Access Control Metamodel for Web ServiceOriented Architecture. In Proc. Int’l Conf. Software Engineering Advances. IEEE Computer Society, Aug. 2007. [9] C. Emig, S. Kreuzer, S. Abeck, J. Biermann, and H. Klarl. Model-Driven Development of Access Control Policies for Web Services, In IASTED Int’l. Conf. on Software Engineering and Applications, Florida, 2008 [10] D. F. Ferraiolo, R. Sandhu, S. Gavrila, D. R. Kuhn, and R. Chandramouli. Proposed NIST standard for role-based access control. ACM Transactions on Information and System Security, 4(3):224–274, Aug. 2001. [11] D. Firesmith. Engineering Security Requirements. Journal of Object Technology, 2(1):53–68, 2003. [12] C. Gutiérrez, E. Fernández-Medina, and M. Piattini. A Survey of Web Services Security. In Computational Science and Its Applications - ICCSA 2004, volume 3043 of LNCS, pages 968–977. Springer, Apr. 2004. [13] S. Götzfried. Identity Management. Untersuchungen zum Einsatz von Identity Management-Systemen in Unternehmen und Organisationen. Master’s thesis, Univ. Regensburg, Informationswissenschaft, 2007. [14] M. Hafner and R. Breu. Realizing Model Driven Security for Inter-organizational Workflows with WSCDL and UML 2.0. In Model Driven Engineering Languages and Systems, volume 3713 of LNCS, pages 39–53. Springer, 2005. [15] M. Hammer. Reengineering work: don´t automate, obliterate. Harvard Business Review, 68(4):104–112, 1990. [16] G. Herrmann and G. Pernul. Viewing business-process security from different perspectives. International Journal of Electronic Commerce, 3(3):89–103, 1999. 169 [17] W. Hommel. Architektur- und Werkzeugkonzepte für föderiertes Identitäts-Management. PhD thesis, Fakultät für Mathematik, Informatik und Statistik der Ludwig-Maximilians-Universität München, 2007. [18] T. Imamura and M. Tatsubori. Patterns for Securing Web Services Messaging. In OPSLA Workshop on Web Services and Service Oriented Architecture Best Practice and Patterns, 2003. [19] J. Juerjens. Secure Systems Development with UML. Springer, 2005. [20] G. Keller, M. Nüttgens, and A.-W. Scheer. Semantische Prozessmodellierung auf der Grundlage Ereignisgesteuerter Prozessketten (EPK), volume 89. Universität des Saarlandes, Jan. 1992. [21] H. Klarl. Modellgetriebene, mustergestützte Sicherheit in serviceorientierten Architekturen. InformatikSpektrum, 30(3):175–177, June 2007. [22] H. Klarl, C. Wolff, and C. Emig. Abbildung von Zugriffskontrollaussagen in Geschäftsprozessmodellen. In Modellierung 2008 – Verhaltensmodellierung: Best Practices und neue Erkenntnisse, Berlin, Mar. 2008. [23] B. Korherr and B. List. Extending the UML 2 Activity Diagram with Business Process Goals and Performance Measures and the Mapping to BPEL. In Advances in Conceptual Modeling - Theory and Practice, volume 4231 of LNCS, pages 7–18. Springer, 2006. [24] B. Korherr and B. List. A UML 2 Profile for Event Driven Process Chains. In Research and Practical Issues of Enterprise Information Systems, volume 205 of IFIP International Federation for Information Processing, pages 161–172. Springer, 2006. [25] M. N. Kreeger and I. Duncan. Engineering secure software by modelling privacy and security requirements. In 39th Int’l Carnahan Conf. on Security Technology, pages 37–40, Oct. 2005. [26] T. Lodderstedt, D. A. Basin, and J. Doser. SecureUML: A UML-Based Modeling Language for ModelDriven Security. The Unified Modeling Language, volume 2460 of LNCS, pages 426–441. Springer, 2002. [27] A. Matheus. How to Declare Access Control Policies for XML Structured Information Objects using OASIS’ eXtensible Access Control Markup Language (XACML). In Proc. 38th Annual Hawaii Int’l Conf. on System Sciences, page 168a. IEEE Computer Society, 2005. [28] T. Neubauer, M. Klemen, and S. Biffl. Secure Business Process Management: A Roadmap. In Proc. First Int’l Conf. on Availability, Reliability and Security, pages 457 – 464. IEEE Computer Society, Apr. 2006. [29] M. Neuenschwander. Enterprise Identity Management Market 2006–2007. Burton Group, Nov. 2006. [30] H. R. M. Nezhad, B. Benatallah, F. Casati, and F. Toumani. Web Services Interoperability Specifications. Computer, 39(5):24–32, 2006. [31] Object Management Group, Inc. Model Driven Architecture (MDA). http://www.omg.org/cgibin/apps/doc?ormsc/01-07-01.pdf, July 2001. [32] Object Management Group, Inc. Business Process Modeling Notation (BPMN) Specification. http://www.bpmn.org/Documents/OMG Final Adopted BPMN 1-0 Spec 06-02-01.pdf, 2006. [33] Object Management Group, Inc. Object Constraint Language – Version 2.0. http://www.omg.org/technology/documents/formal/ocl.htm, May 2006. [34] Object Management Group, Inc. Unified Modeling Language: Infrastructure – Version 2.1.1. http://www.omg.org/docs/formal/07-02-06.pdf, Feb. 2007. [35] Object Management Group, Inc. Unified Modeling Language: Superstructure – Version 2.1.1. http://www.omg.org/docs/formal/07-02-05.pdf, Feb. 2007. [36] J.-P. Richter, H. Haller, and P. Schrey. Serviceorientierte Architektur. Informatik-Spektrum, 28(5):413–416, Oct. 2005. [37] A. Rodríguez, E. Fernández-Medina, and M. Piattini. Security Requirement with a UML 2.0 Profile. In Proc. First Int’l Conf. on Availability, Reliability and Security, pages 670–677. IEEE Computer Society, 2006. [38] A. Rodríguez, E. Fernández-Medina, and M. Piattini. A BPMN Extension for the Modeling of Security Requirements in Business Processes. IEICE-Transactions on Info and Systems, E90-D(4):745–752, 2007. [39] A. Rodríguez, E. Fernández-Medina, and M. Piattini. Towards CIM to PIM Transformation: From Secure Business Processes Defined in BPMN to Use-Cases. In Business Process Management, volume 4714 of LNCS, pages 408–415. Springer, Sept. 2007. [40] C. Wolter, M. Menzel, and C. Meinel. Modelling Security Goals in Business Processes. In Modellierung 2008, volume P-127 of LNI, pages 201–216, Bonn, Germany, Mar. 2008. Köllen. [41] C. Wolter, A. Schaad, and C. Meinel. Deriving XACML Policies from Business Process Models. In Web Information Systems Engineering, volume 4832 of LNCS, pages 142–153. Springer, 2007. [42] E. Yuan and J. Tong. Attributed based access control (ABAC) for Web services. In Proc. IEEE Int’l Conf. on Web Services. IEEE Computer Society, July 2005. All web references were checked on 28th July 2008. 170 MODEL-DRIVEN DEVELOPMENT OF SERVICEORIENTED BUSINESS APPLICATION SYSTEMS Stefan Kätker1, Susanne Patig2 Abstract The industrial development of real-world business applications that are based on service-oriented architecture (SOA) is subject to technological and organizational requirements. The paper describes an approach that tackles these requirements by ideas from model-driven development (MDD). The approach consists of a metamodel accompanied by modeling guidelines, a governance process ensuring that these guidelines are kept, and a modeling tool to support model creation and governance process. The successful application of the presented approach during the development of SAP’s Business byDesign solution shows that the benefits of MDD in software industry lie beyond code generation and outweigh modeling effort. 1. Motivation Application systems rely on service-oriented architecture (SOA) in three ways: 1) as a composite application for a particular purpose by integrating or extending existing SOA-based systems, 2) by being a priori and completely designed based on SOA principles or 3) by ex post providing services as external interfaces to their existing, evolved implementation. The second and third SOA usage types are perfect starting points for the first one. This paper introduces a methodology that supports the ‘SOA by Design’ development of application systems in a large, international project setting. The approach is called the eSOA Modeling Methodology and was developed by SAP AG. To tackle the organizational and technological requirements of the development context (see Section 2), ideas from model-driven development were used. Model-driven development (MDD) is characterized by a tight coupling between the descriptions of a software system (models) and the system’s implementation [7]: Software development starts from a set of models representing distinct views on software architecture [5]. These abstract models are successively transformed into platform-specific ones – with source code at the end. The benefits of applying MDD in software industry do not only stem from code generation, but also from the models that constitute an easy to understand lingua franca among the development teams [13]. The eSOA Modeling Methodology consists of a metamodel, a governance process and a tool environment; all of this is explained in Section 3 and related to the state of the art in Section 4. The approach has been applied in the development of the application system ‘SAP Business byDesign’ – SAP’s ERP solution for small and medium enterprises, which was designed and implemented by 1 2 SAP AG, AP Engineering - Process Modeling, Dietmar-Hopp-Allee 16, D-69190 Walldorf, Germany. University of Bern, IWI, Engehaldenstrasse 8, CH-3012 Bern, Switzerland. 171 strictly following SOA. The experience gained in this process is used to evaluate the methodology (Section 5); some critical points are shown. 2. Requirements of the Software Development Process In the development process of the SAP ‚Business byDesign’ application system, the following three groups of requirements had to be considered: 1) Large-scale commercial software development often involves huge, decentralized teams. For example, more than 800 people from 3 continents participated in the development of SAP ‘Business byDesign’. Managing such a project requires clear boundaries between the development teams. Moreover, a common language for all developers is needed. 2) The development of a (functionally and technologically) new software system requires methodological support for the whole software lifecycle including requirements engineering, system design, system implementation, deployment and maintenance. Model-driven development satisfies these requirements, given that the models exactly match the implementation. This can be guaranteed by either source code generation form models or organizational means. 3) As a technological innovation, the new software system should be based on service-oriented architecture, which means that the software system provides its functionality by interacting 3 (software ) services. Services reside on the implementation level, i.e., they are (software2) components that completely encapsulate the implementation of some functionality [16]. From the outside, only the description of this functionality (the interface) is visible. Interfaces group the operations offered by the service and the operation signatures (input and output parameters and their respective types). During the development of a SOA-based application system, the rather unstructured functional requirements of varying granularity must be broken down into welldefined and consistently structured components and interfaces. These requirements are satisfied by the eSOA Modeling Methodology as follows: 1. Metamodel (see Section 3.1) and content creation guidelines (see Section 3.2) The metamodel contains all artifacts (metaclasses; see Section 3.1.1) to describe the serviceoriented architecture of a (business) application system, i.e., the software components, their interfaces and their relationships to other components and to the system environment. The metamodel is accompanied by content creation guidelines for the identification, design and implementation of metaclass instances. The various views on software architecture [5] are realized by arranging the metaclasses into several model types (see Section 3.1.2). 2. Governance process (see Section 3.2): To ensure that the modeled content is consistent and complies with the guidelines, a central governance process is required. All models and entities have to pass a review before implementation. The governance process also covers changes during the development cycle. Software changes without subsequent model changes and governance approval are not allowed. 3. Modeling tool environment (see Section 3.3): Metamodel and content creation must be supported by a tool environment that implements all metaclasses and model types of the eSOA Modeling Methodology. The modeling tools create the eSOA repository for the modeled contents and include facilities to generate proxy code. 3 We skip this term in the following - for brevity and since it is clear from the context. 172 3. eSOA Modeling Methodology 3.1. Metamodel 3.1.1. eSOA Metaclasses SAP ‘Business byDesign’ relies on an enriched form of SOA called Enterprise SOA (eSOA, for short) [16], where the business functionality (business scope) of an application system is completely and solely exposed via services. The services are provided by business objects and process components. Business objects are the metaclasses with the finest granularity; they structure the functionality of an application system. A Business Object (BO) is a set of entities with common characteristics and behavior that represents well-defined business semantics [12], [16]. The functionality of business objects can be accessed via services. Typical business objects are, e.g., ‚sales order’ and ‚customer invoice’ (see Section 3.1.2). Each business object belongs to exactly one process component (see Fig. 1). Process components group business objects and are the building blocks for business processes. A Process Component (PC), for example, ‚Sales Order Processing’ (see Fig. 3 in Section 3.1.2), is a modular, context independent, reusable software package that exposes its functionality (which may span several database transactions) as (compound) services. Process components are collected into deployment units (see Fig. 1). A Deployment Unit (DU) is a piece of software – like ‚Customer Relationship Management’ – that can be operated independently on a separate physical system. Usually, deployment units are jointly shipped. They are decoupled from each other via enterprise services and process agents (see below). Logical Units of Work are not created across deployment units. The exposed services are abstractly described by service operations. A service operation is a specification of a function (e.g., ‚create sales order’) with a set of message types assigned as its signature. Semantically related service operations are combined into service interfaces (SI) that specify the functionality offered (inbound SI) or used (outbound SI) by process components (see Section 3.1.2, Fig. 3). Depending on the interacting partners, it is distinguished between A2A and B2B service interfaces, intended for the communication between applications of one business partner (A2A) or between systems at several business partners (B2B), respectively. Process Agents (PA) are pieces of software responsible for the interaction between process components and across deployment units. They relate the sending (outbound PA) or receiving (inbound PA) of XML messages to changes of the involved business objects (e.g., status update, creation or deletion of BO instances) and, hence, intermediate between business objects and service interfaces (see Fig. 1). Fig. 3 in Section 3.1.2 provides an example for the use of process agents. At the finest level, business objects are structured into (BO) nodes. A business object node represents a semantically related group of elements that can be treated as a part of the business object. For example, the business object ‘sales order’ may comprise the nodes ‘sales order item’, ‘price calculation’ and ‘delivery terms’. Business object nodes are typed by data types. Fig. 1 shows the abstract syntax (i.e., the constructs and their allowed connections [8], [7]) of the eSOA metamodel metaclasses as an UML class diagram. This abstract syntax is accompanied by eSOA Content Creation Guidelines (see Section 3.2) for the identification, design and implementation of metaclass instances. The concrete syntax of the metaclasses, i.e., their notation [8], [7], is defined by the eSOA model types, which are described in the next section. 173 Deployment Unit 1..* Inbound Compound Service Interface 1..* 1..* 1 1..* Inbound 1..* 1 Process Agent leads to Process Component 1..* Business Object changes 1..* 1..* 1..* 0..1 Outbound Process Agent 1 1..* triggers uses 1..* 1 Outbound Compound Service Interface 1 Business Object Node * 1..* Data Type * 1..* 1..* Inbound Operation 1..* * 1 1..3 Message Type 1..3 1 Outbound Operation Fig. 1. Abstract Syntax of the Main eSOA Metamodel Artifacts. 3.1.2. eSOA Model Types This section explains the main eSOA model types. According to ANSI/IEEE [2], they cover the structural (PC Models, BO Models), behavioral (Integration Scenario Models, PC Interaction Models) and context (Integration Scenario Models) viewpoints on software architecture. The model types are illustrated by the scenario „Sell from stock”, which describes the fulfillment of a sales order for material from stock (Fig. 2 to Fig. 4). Fig. 2. Sample Integration Scenario Model for ’Sell from stock‘ (© SAP AG). 174 Integration Scenario Models (see Fig. 2) are the first ones created. They spring from the functional requirements and describe the realization of a business process by eSOA. An integration scenario consists of deployment units, process components and the necessary interactions among them. It is distinguished between direct interactions by local function calls, service interactions that amount to message exchange via the SAP Exchange Infrastructure (XI), and other interactions – executed by, e.g., remote function calls. All types of interactions are represented by arrows. Process components that do not belong to SAP ‘Business byDesign’ are also depicted. For example (see Fig. 2), the processing of sales orders is a typical task of customer relationship management and often the result of a sales quote. Each placed sales order corresponds to a purchase order at the customer. Thus, the DU ‚Customer Relationship Management’ consists of two PC (‚Sales Quote Processing’ and ‚Sales Order Processing’) that directly interact, whereas messages with the customer’s systems must be exchanged via service interactions. Service interaction is also necessary to transfer the sales order’s data to invoicing, as the PC ‚Customer Invoice Processing’ belongs to another DU. Each PC is described by a Process Component Model (see Fig. 3). This model type shows the business objects and process agents belonging to some PC, its service interfaces and all process components using the inbound service interfaces. Process Component Models do not represent process flow logic, but architecture relevant ‘uses’ and ‘realized by’ relationships. Service interfaces placed above or below (to the right of) a BO group asynchronous (synchronous) interactions. Fig. 3. Sample Process Component Model (© SAP AG). Fig. 3 shows the Process Component Model of the PC ‚Sales Order Processing’ from Fig. 2. The operations to create, change or cancel instances of the BO ‚Sales Order’ are grouped into the same 175 service interface since they can be asynchronously invoked by the same PC ‚Purchase Order Processing at Customer’. A process agent (a technical artifact) connects the SI to the BO. The Process Component Interaction Model (see Fig. 4) can be seen as an extended view on the information contained in Process Component Models: It shows the service choreography and the messages exchanged between exactly two process components for a specific business goal and the involved business objects, process agents, interfaces, operations and message types. This model type is only generated for service interactions. Fig. 4 shows the corresponding service interaction between the PC ‚Customer Invoice Processing’ and the PC ‚Sales Order Processing’, which exchange special message types for customer invoices (request and issued confirmation). Fig. 4. Sample Process Component Interaction Model (© SAP AG). 3.2. Content Creation and Governance Process There is no central ‘modeling department’ within SAP AG; instead, the modeling (called content creation in the following) is a task of the developers. Decentralized content creation is facilitated by the eSOA Content Creation Guidelines that accompany the eSOA metamodel as well as centralized methodology coaching: The subject matter experts in the development teams are assisted by eSOA Modeling Methodology experts, who help them in applying the content creation guidelines. The content creation guidelines control the identification, design and implementation of metaclass instances and models; a few examples are given in the following: The identification of metaclass instances puts the eSOA metaclass definitions into particular content entities. For example, business objects are defined according to industry standards, e.g., the ones for B2B communication from RosettaNet [11], or industry best practices. The formation of process components follows an outside-in business view: In general, a process component represents the software realizing a business process that is typically executed in one department. A deployment unit is a collection of process components and corresponds to the smallest unit of software distribution. Deployment units are determined by thinking about customer’s deployment scenarios (e.g., central accounting, lineof-balance-oriented production and regionally distributed sales) and business process outsourcing. Service interactions and the message types exchanged are organized in patterns (e.g. ‚notification’, ‚information distribution’, ‚query response’), which are strictly derived from the transaction patterns of the UN/CEFACT modeling methodology [14]. Design issues covered by the content creation guidelines include, for example, naming rules, the determination of identifiers, modeling restrictions (e.g., a BO node data type must be either a global data type or a data type composed out of global and aggregated data types) and technical 176 restrictions (e.g., multi-valued attributes are not allowed for BO nodes). The content creation guidelines also provide code skeletons for the implementation of the metaclasses. Finally, the PIC (Process Integration Content) governance process is SAP’s central approval and quality assurance procedure for the modeled eSOA contents. Its tasks consist in 1) checking the conformance of the models to the eSOA content creation guidelines, 2) approving exceptions from these guidelines, 3) assuring identical semantics as well as reuse of the modeled entities across development teams and throughout SAP ‘Business byDesign’ and 4) managing model changes. Thus, the process increases the consistency of the modeled contents. In detail, the PIC governance process comprises several phases (see Fig. 5). PIC0 focuses on the definition of process integration aspects, i.e., the service orchestration between components: First, the functional requirements are structured into business objects, process components and deployment units by applying the eSOA content creation guidelines. PIC01 approves cut, semantics (i.e., appropriate definition) and naming of the identified entities. Then, the constituents of the Integration Scenarios Models (process components and their interactions) are defined and confirmed by PIC02. Thirdly, each interaction between process components is detailed by Process Component Models and Process Component Interaction Models (PIC03). The phases PIC1 to PIC3 are concerned with data modeling: Business objects, their nodes and data types as well as service signatures are defined. Fig. 5 relates the PIC governance process to the process of modeling. Fig. 5. SAP Process Integration Content (PIC) Governance Process. Only those modeled entities that have passed the PIC governance process are released for implementation and listed in the eSOA Repository (ESR), a central directory of all elements that embody eSOA [16]. For business objects and service interfaces, proxy coding is generated (see Fig. 5). If either subsequent functional requirements or unforeseen implementation issues call for deviations from the modeled entities, first, the affected models have to be adjusted. Then, the PIC governance process must be passed anew (now as a change process), before implementation can be started. 177 3.3. Modeling Tool Environment To efficiently realize MDD in large software development projects, an appropriate tool environment is important. Not only modeling must be supported, but also the governance process. Therefore, key features of such a tool environment include: Close integration with the eSOA repository, high usability and specific adaptation to the modeling methodology to make modeling efficient, status management for the models and their entities to track the approval status in the governance process, versioning and release management like for source code. Reports should check automatically if abstract syntax and content creation guidelines have been kept. These checks ensure consistency and quality of the modeled contents. Owing to the development cooperation between SAP and IDS Scheer, the ARIS tool [1] was used to implement the eSOA Modeling Methodology. The close integration with SAP’s eSOA Repository as well as the flexible reporting and configuration capabilities of ARIS proved to be very useful. However, ARIS provides only the tool basis to implement the eSOA Modeling Methodology (see Fig. 6); the ARIS modeling methodology featuring event-driven process chains is not a part of the eSOA Modeling Methodology. Fig 6. A Process Component Interaction Model in the ARIS Modeling Tool. 4. Relationship of the eSOA Metamodel to Standards Although the eSOA Modeling Methodology was invented to support the development of a company-specific form of SOA, the resulting service-oriented application systems will probably be integrated in landscapes of heterogeneous software systems. For that reason, conformance to standards is important. Especially standards for the description of software architectures (ANSI/ IEEE 1471-2000 [2]), general modeling standards (UML [8]) and standards related to (web) services (WSDL [15], SCA [10]) must be kept. Process modeling standards like the Business Process Modeling Notation (BPMN [6]), event-driven process chains (EPC [1]) or UML activity diagrams [8] are, however, not relevant, since software architecture, which the eSOA Modeling Methodology describes, is only concerned with structural aspects of software systems and general interaction possibilities (as opposed to particular interactions) [5]. In fact, the eSOA metamodel can largely be expressed as an UML profile. By accepting loss of some internal information, eSOA models can also be transformed into a SCA-compliant representation. More detailed descriptions of these mappings can be found in [4]. The main advantage of our approach is the precise mapping from the eSOA models to SAP’s application architecture. 178 The eSOA definitions of service interfaces and operations agree with the standard Web Service Description Language (WSDL) 2.0. This conformance is relevant to external invocations of the services provided by SAP ‘Business byDesign’. WSDL 2.0 characterizes services by interfaces that contain at least one operation; the signature of an operation consists of messages [15]. The transformation from WSDL to proxy code is straightforward. 5. Evaluation of the eSOA Modeling Methodology The eSOA Modeling Methodology was applied during the development of the service-oriented application system SAP ‘Business byDesign’: The functional requirements were decomposed into business objects and services and aggregated to process components and deployment units before actual coding started. Table 1 shows the according numbers of eSOA entities. Table 1. Numbers and Usage of Models (March 2008) Model Type Name Integration Scenario Models PC Models Counts 28 115 Model Constituents DU PC BO PA 20 130 373 622 X X X X O 651 MT 579 Model Usage beyond Documentation Derivation of end-user test cases Generation of PC Interaction Models, Consistency Checks PC Interaction Models X X X X X Activation of a service interaction 211 during configuration generates entries in SAP XI BO Models X Derivation of operation 373 signatures; Generation of provider classes, interfaces and proxies Abbreviations: BO: Business object, DU: Deployment unit, MT: Message type, O: Operation, PA: Process agent, PC: Process component, X: Model type uses metaclass instances X The creation of the models causes effort. The effort shows up in the numbers of models and their entities (see Table 1) and in the phases of the governance process (see Fig. 5) that must be passed before implementation and in case of changes. Although this effort is significant, our experience is that it pays off through the usage of the models over the whole software lifecycle (see Table 1): The eSOA metamodel provides clear guidance and a common language to formalize the gathered functional requirements in a way that immediately leads to a service-oriented system design. System specification is structured according to the eSOA metaclasses and model types (for example, specifications are written per process component or integration scenario); development teams are formed around process components and deployment units. In implementing the system, provider classes, interfaces and proxies have been automatically generated from the Business Object Models in the eSOA Repository. End-user test cases are derived from Integration Scenario Models; tests related to data and message types can also be generated. In order to derive the technical configuration of a particular customer system during deployment, Process Component Integration Models are used to automatically create interaction-specific configuration entries for enterprise service interactions in SAP’s Exchange Infrastructure (XI). Software maintenance requires deep knowledge of the system and its integration; the service and support teams gain this knowledge form the modeled content. Finally, the common language coined by the eSOA metamodel drives development efficiency throughout the entire software lifecycle. Two critical points of the eSOA Modeling Methodology can be identified; the first one is the governance process. Though it is mandatory for quality assurance, it should not be overstated. Governance must balance out rigid quality checks and room for innovation and exceptions. The PIC 179 governance process was refined several times to ensure that it does not become the bottleneck of development efficiency, but still guarantees consistent content of high quality. Secondly, the eSOA Modeling Methodology is architecture-driven. The created models are not well suited to explain business experts how business processes are realized. Experience showed that even in developing composite applications more business context is required to manage service integration. This can be achieved by combining service interaction and process flow as proposed by BPMN and the related execution language BPEL. Therefore, our future research is directed to extending the eSOA Modeling Methodology by a BPMN-based process flow description. 6. Conclusion This paper has presented an approach for the model-driven development of SOA-based business application systems in a huge industrial setting. In domains other than business applications, both metamodel and content creation guidelines of the eSOA Modeling Methodology must be adapted. The eSOA Modeling Methodology belongs to the development paradigm of SAP’s ‘Business byDesign’ application system. As a result, the complete functional content of ‘Business byDesign’ is described by models with a one-to-one correspondence to source code. The models form an easy to understand common language across various functional and organizational areas. In a project involving more than 800 developers, such a language raises development productivity The modeled content opens up opportunities to design and document other aspects of the software system as well, such as configuration constraints, process flow and end-user interfaces. All this can only be realized if metamodel, content creation guidelines, governance process and modeling tool are treated as a single, integrated topic, as done by the eSOA Modeling Methodology. 7. References [1] IDS Scheer, ARIS Software, http://www.ids-scheer.com/en/aris. [2] IEEE, IEEE Recommended Practice for Architectural Description of Software-Intensive Systems. IEEE Std 14712000. Recognized as an American National Standard (ANSI), Approved 2000-09-21. [3] JOHNSTON, S.K., UML 2.0 Profile for Software Services, http://www.ibm.com/ developerworks/ [4] KÄTKER, S., PATIG, S., Model-Driven Development for Service-Oriented Software Systems. Preprint No. 208, Institut für Wirtschaftsinformatik der Universität Bern, Bern, 2008. [5] KRUCHTEN, P.B., The 4+1 View Model of Architecture, in: IEEE Software Vol. 12, No. 6 (1995). [6] OMG, Business Process Modeling Notation, Version 1.1, formal/2008-01-17 http://www.bpmn.org/ [7] OMG, Model-driven Architecture, Guide Version 1.0.1, omg/2003-06-01, http://www.omg.org/ [8] OMG, Unified Modeling Language: Superstructure, Version 2.1.2, formal/2007-11-02, http://www.omg.org/ [10] OSOA, Service Component Architecture Assembly Model V1.00, http://www.osoa.org/ [11] RosettaNet: http://www.rosettanet.org/ [12] SEUBERT, M., Business Objects und objektorientiertes Prozeßdesign (in German), in: Becker, J., Rosemann, M., Schütte, R. (Hrsg.), Entwicklungsstand und Entwicklungsperspektiven der Referenzmodellierung, S. 46-64. Arbeitsbericht Nr. 52, Universität Münster, Institut für Wirtschaftsinformatik 1997. [13] STARON, M., Adopting Model Driven Software Development in Industry – A Case Study at Two Companies, in: Nierstrasz, O. et al. (Hrsg.), MoDELS 2006, LNCS Vol. 4199, pp. 57 – 72. Springer, Berlin 2006. [14] UN/CEFACT, UMM User Guide; http://www.unece.org/cefact/umm/umm_index.htm. [15] W3C, Web Services Description Language (WSDL) Version 2.0, Part 1: Core Language. http://www.w3.org/ [16] WOODS, D., MATTERN, T., Enterprise SOA – Design IT for Business Innovation, O’Reilly, Beijing 2006. In dieser Publikation wird auf Produkte der SAP AG Bezug genommen. SAP, R/3, xApps, xApp, SAP NetWeaver, Duet, PartnerEdge, ByDesign, SAP Business ByDesign und weitere im Text erwähnte SAP-Produkte und -Dienstleistungen sind Marken oder eingetragene Marken der SAP AG in Deutschland und anderen Ländern weltweit. Business Objects und das Business-Objects-Logo, BusinessObjects, Crystal Reports, Crystal Decisions, Web Intelligence, Xcelsius und andere im Text erwähnte Business-Objects-Produkte und -Dienstleistungen sind Marken oder eingetragene Marken der Business Objects S. A. in den USA und anderen Ländern weltweit. Business Objects ist ein Unternehmen der SAP. Die SAP AG ist weder Autor noch Herausgeber dieser Publikation und ist für deren Inhalt nicht verantwortlich. Der SAP-Konzern übernimmt keinerlei Haftung oder Garantie für Fehler oder Unvollständigkeiten in dieser Publikation. 180 VORGEHENSMODELLE ZUR ENTWICKLUNG SERVICEORIENTIERTER SOFTWARESYSTEME Oliver Thomas, Katrina Leyking, Michael Scheid1 Kurzfassung Bei der Entwicklung von Softwaresystemen auf Basis eines serviceorientierten Architekturparadigmas stellt sich die Frage, welches Vorgehensmodell zur Projektabwicklung herangezogen werden kann. In der Literatur werden unterschiedliche Vorgehensmodelle zur serviceorientierten Softwareentwicklung vorgeschlagen. Aus diesen werden 17 Modelle ausgewählt, charakterisiert sowie mit Hilfe eines allgemeinen Rahmens klassifiziert und verglichen. Dabei werden sowohl generelle Merkmale von Vorgehensmodellen als auch SOA-spezifische Vorgehensmerkmale herangezogen. 1. Einleitung Führende Anbieter von IT-Lösungen sehen in der Serviceorientierten Architektur (SOA) das Paradigma der Zukunft. Mit diesem Management- und Systemarchitekturkonzept scheint es erstmalig möglich, die Modellierung betriebswirtschaftlich relevanter Abläufe mit deren physischer Ausführung über eine Softwareplattform zu verbinden [7; 20; 31; 33; 43]. Gartner prognostiziert, dass bis 2010 rund 65 Prozent der großen Unternehmen über 35 Prozent ihrer Anwendungsportfolios auf einer SOA-Architektur aufbauen werden [24]. Bei aller Euphorie ist zu beachten, dass in der Serviceorientierung nicht ein Softwareprodukt im Mittelpunkt steht, sondern eine langfristige, strategische Neuausrichtung der unternehmensweiten IT. Die entsprechenden Veränderungsprozesse sind durch eine hohe Komplexität gekennzeichnet. Zur Handhabbarmachung dieser Komplexität werden in der Literatur verschiedene serviceorientierte Vorgehensmodelle vorgeschlagen. Trotz der Vielfalt an bestehenden SOA-Vorgehensmodellen existieren in der Literatur kaum Untersuchungen, die den Nachweis und die Dokumentation der Vorgehensmodelle im State-of-the-Art zum Gegenstand haben. Ebenso mangelt es darauf aufbauend an Arbeiten zur Behandlung der Frage, welche SOAVorgehensmodelle in welchen Anwendungssituationen zu nutzen sind. In Anlehnung an vergleichende Übersichten über Vorgehensmodelle des Software Engineering [2], komponentenorientierte Vorgehensmodelle [10] und objektorientierte Vorgehensmodelle [30] sowie Vorarbeiten zur Katalogisierung von Vorgehensmodellen [11] soll daher in diesem Beitrag ein vergleichender Überblick über ausgewählte Vorgehensmodelle zur serviceorientierten Entwicklung von Softwaresystemen gegeben werden. Dabei sollen sowohl generelle Merkmale von Vorgehensmodellen herangezogen werden als auch Aspekte, die im Hinblick auf die serviceorientierte Systementwicklung eine besondere Rolle spielen. Die einzelnen SOA-Vorgehensmodelle sollen nicht im Detail vorgestellt werden, zu ihrer ausführlichen Herleitung und Beschreibung wird auf die Originalquellen verwiesen. Der Vergleich der serviceorientierten Vorgehensmodelle ist systematisch und wird auf Basis eines einheitlichen Vergleichsrahmens durchgeführt. 1 Institut für Wirtschaftsinformatik im DFKI, Universität des Saarlandes, Stuhlsatzenhausweg 3, 66123 Saarbrücken. 181 2. Neue Anforderungen an Vorgehensmodelle durch SOA Vorgehensmodelle des Software Engineering beruhen auf der Idee des Software-Lifecycle und werden als ein Rahmenkonzept verstanden, dem jede Softwareentwicklung folgen soll [für einen Überblick vgl. 2, Kap. II 3.3]. Sie dienen der zeitlichen, logischen Strukturierung der durchzuführenden Aktivitäten innerhalb der Entwicklungs- und Einsatzphasen von Informationssystemen, der Zuordnung von Mitarbeitern zu diesen Aktivitäten sowie der Beschreibung der zu erzielenden Ergebnisse. Durch SOA soll es möglich werden, Anwendungssysteme flexibel aus eigenständigen Teilsystemen (Services) zusammenstellen zu können [20; 23]. Anwendungssysteme sollen nicht als Gesamtsysteme im Unternehmen vorgehalten werden, vielmehr sollen benötigte Dienste bedarfsgerecht über das Internet bezogen und unternehmensindividuell konfiguriert werden [12, S. 78 f.; 21, S. 33]. Die Ziele einer SOA-Entwicklung unterscheiden sich somit von denjenigen „traditioneller“ Softwareprojekte. Die daraus resultierenden Herausforderungen sind bei der Auswahl von Vorgehensmodellen für eine SOA-Entwicklung zu berücksichtigen. In dieser Untersuchung müssen die Vorgehensmodelle folgenden im Rahmen einer Literaturrecherche identifizierten Kriterien – im Sinne SOA-spezifischer Gestaltungsprinzipien – gerecht werden: • • • • Modularisierung: SOA basieren auf einer Dekomposition bestehender Anwendungssysteme in funktional gekapselte Services [9, S. 290; 20, S. 242; 27, S. 42]. Dabei sind eine Kohäsion von Funktionalitäten und eine Autonomie unterstützender Services anzustreben. Einhergehend ist das Prinzip der losen Kopplung zu beachten, das auf eine Unabhängigkeit bei gleichzeitiger schnittstellenbasierter Interoperabilität der Services untereinander abzielt [6, S. 9; 45, S. 157]. Abstraktion: Eine serviceorientierte Softwaregestaltung basiert auf einer Trennung von Schnittstelle und Implementierung, wodurch dem Softwarenutzer ein abstrakter Systemzugang gewährt wird und Codierungsdetails verborgen bleiben. Durch das Information-Hiding-Prinzip [35, S. 1056] wird eine plattformneutrale Servicebeschreibung realisiert, die die Servicenutzung unabhängig von der programmiertechnischen Ausgestaltung des in Anspruch nehmenden Systems macht. Die Auswahl der technischen Softwarelösung kann zur Laufzeit erfolgen. Ausgewogene Granularität: Bei SOA ist ergänzend das richtige Maß an fein- und grobgranularen Services zu finden [9, S. 299; 20, S. 242; 37, S. 127]. Die Granularität gibt Auskunft über Art und Umfang der Funktionalität, die durch ein Modul bereitgestellt wird. Sind Services grobgranular gestaltet, kann deren Wiederverwendung beeinträchtigt werden. Feingranulare Services können zu Ineffizienzen führen und einen fachaufgabenorientierten Einsatz gefährden. Prozessorientierung: Die Komposition von Services zu inner- und überbetrieblichen Geschäftsprozessen stellt einen zentralen Bestandteil einer SOA-Entwicklung dar. Sie steht in der Tradition der Konfiguration von Workflow-Management-Systemen und macht sich die Prinzipien des „Programming-in-the-large“ [5] zunutze. Die Prozessgestaltung kann dabei als Bindeglied zwischen dem Organisationssystem und dem Anwendungssystem betrachtet werden. Sie stellt ein durchgängiges „Business/IT Alignment“ [14] in Aussicht, welches Vorraussetzung für die Zielsetzung flexibler und wiederverwendbarer Services ist. Traditionelle Vorgehensmodelle des Software Engineering schenken diesen SOA-spezifischen Kriterien nicht immer Beachtung, was die Notwendigkeit serviceorientierter Vorgehensmodelle begründet. Allerdings sind in der Literatur auch serviceorientierte Vorgehensmodelle zu finden, die gleichsam wesentliche Charakteristiken einer SOA unberücksichtigt lassen. So gibt bspw. die Architectural und Organization Roadmap von Krafzig et al. [20] keine Empfehlungen für die Erzielung ausgewogener Granularität und abstrakter Serviceschnittstellen. Demgegenüber sieht das Konzept von Overhage, Turowski [32] keine explizite Modularisierung vor. Tsai [41] spricht in seinem Ansatz zwar von einer Servicekomposition zur Laufzeit, berücksichtigt aber keine prozessorientierte Serviceorchestrierung. Die im Rahmen einer Literaturrecherche identifizierten serviceorientierten Vorgehensmodelle, die den genannten Kriterien genügten, sind in Tabelle 1 zusammengestellt. 182 Tabelle 1: Vorgehensmodelle zur Entwicklung serviceorientierter Softwaresysteme Quelle Vorgehensmodell [1] Service-oriented Modeling and Architecture Method [3] Creating Serviceoriented Architectures [4] Service-Oriented Analysis and Design Activities [13] Enterpise-SOARoadmap-Methodik [15] Creating of a Service Architecture [16] Procedure Model for Service Identification [19] Process Models for business-oriented Service Identification and Clustering [22] Procedure Model for a SOA-Based Integration of Enterprise Systems [25] Service Oriented System Engineering [26] Vorgehensmodell zur Umsetzung von SOA-Systemen [28] Business-driven SOA Development [29] [34] [36] [17; 39] [40] [44] Seven Steps to a Service-Oriented Evolution Service-oriented Design and Development Methodology SOAEntwicklungsprozess Vorgehensmodell zur Entwicklung von Geschäftsservicen Modellbasierte Gestaltung serviceorientierter Architekturen Service Identification and Packaging in Service Oriented Reengineering Charakterisierung Arsanjani (IBM) beschreibt den schematischen Aufbau einer SOA. Darauf aufbauend erfolgt die Erläuterung des Vorgehensmodells, bestehend aus den Hauptphasen „Identification“, „Specification“ und „Realisation“, die in die Subphasen „Service Identification“, „Service Classification or Categorization“, „Subsystem Analysis“ „Component Specification“, „Service Allocation“ und „Service Realisation“ segmentiert werden. Das Modell baut auf denselben konzeptionellen Grundlagen auf wie das Vorgehensmodell von Mitra. Barry & Associates, Inc. stellen ein fünfstufiges Vorgehensmodell für die Konzeption einer web-service-basierten SOA vor, das aus den Stufen „Experiment with Web Services“, „Adapt Existing Systems to Use Web Services“, „Remove Intersystem Dependencies“, „Establish an Internal SOA“ sowie „Establish an Internal SOA to include External Services“ besteht. Der Schwerpunkt liegt auf den technischen Aspekten, die mit SOA und der Realisation durch Web Services verbunden sind. Bieberstein (IBM) stellt vier Phasen vor, die im Rahmen eines serviceorientierten Analyse- und Designprozesses durchzuführen sind: „Service Identification“, „Service Categorisation“, „Service Specification“ und „Service Realisation“. Neben Arsanjani und Mitra, ist dies der dritte in dieser Arbeit vorgestellte Autor, der für IBM tätig ist. Hack und Lindemann stellen die von SAP entwickelte Roadmap-Methodik vor. Sie besteht aus den Phasen „Strategische Rahmenbedingungen“, „Transparenz zur Geschäfts- und IT-Landschaft“, „Potenzialanalyse“, „Design“ und „Roadmap-Definition“, die weiter segmentiert sind. Ein Alleinstellungsmerkmal liegt in der Schwerpunktlegung auf organisatorische und strategische Fragestellungen im Vorfeld der SOA-Entwicklung. Der Ansatz von Jones und Morris, der als OASIS-Draft publiziert wurde, hat die Beschreibung eines „Service Discovery Approaches“ zum Ziel und orientiert sich an einer fortschreitenden Top-Down-Analyse ausgehend von einer Betrachtung des Geschäftsumfelds. Die vollständige Definition und die Implementierung der Services liegen außerhalb des Beitragsfokus. Dieses an der Universität Münster entwickelte Vorgehensmodell befasst sich vornehmlich mit der Serviceidentifikation. Es besteht aus den Hauptphasen „Preparation“, „Service Design“ und „Service Categorisation“. Im Rahmen einer Geschäftsprozessanalyse erfolgt im Gegensatz zu anderen Vorgehensmodellen eine Differenzierung zwischen manuellen, semiautomatischen und automatischen Funktionen. Kohlmann (Universität Leipzig) beschreibt ein Vorgehensmodell für Serviceidentifikation und Serviceclustering, welches in die Phasen „Preparation“, „Analysis“, „Verfication“ und „Detailing“ untergliedert ist. In die Konstruktion dieses Vorgehensmodells sind die Erkenntnisse einer zuvor durchgeführten Analyse bereits existierender Vorgehensmodelle eingeflossen. Dieser Ansatz von sd&m beschreibt ein Vorgehensmodell für eine SOA-basierte Integration von Anwendungssystemen. Es besteht aus den Hauptphasen „Task based decomposition of systems“, „Preparation of the integration and mapping of redundant functions“ , „Detection and assignment of services to code fragment“ und „Orchestration of web services“. Gleichzeitig wird das Vorgehensmodell anhand der Integration eines ERP-Systems und eines Content-Management-Systems beispielhaft angewendet. Masak, der als Consultant und Autor tätig ist, nimmt eine modelltechnische Dreiteilung in Geschäftsmodell, Servicemodell und Implementierungsmodell vor. Der Konstruktionsprozess wird in die Phasen „Discover“, „Selection“, „Rating“, „Assembling“, „Execution“, „Monitoring“, „Accounting“ und „Disintegration“ unterteilt. Mathas (Siemens) führt ein Vorgehensmodell für SOA ein, das aus den Phasen „Betrachtungen zur Systemauslegung“, „Prozessanalyse“, „Funktionsanalyse“, „Systemdesign“, „Systementwicklung“, „Systemeinführung“, „Systembetrieb“ und „Wartung“ sowie „Anpassungen und Updates“ besteht, wobei er für jede Phase eine rollenspezifische Zuordnung vornimmt. Mitra (IBM) beschreibt ein Vorgehensmodell, das die Phasen „Business Component/Analysis“, „Service Identification“, „Service Spezification“, „Component Identification“, „Component Specification“, „Service Realisation Decision“ und „SOA Implementation“ umfasst. Neben einer anwenderorientierten business-getriebenen Ableitung der Services, wird eine gleichzeitige service-provider-orientierte Analyse bestehender Systeme vorgeschlagen. Nadhan (EDS Consulting Group) definiert sieben Phasen, die im Rahmen eines SOA-Entwicklungsprozesses zu durchlaufen sind: „Identify“, „Locate“, „Group“, „Package“, „Orchestrate“, „Route“ und „Govern“. Dabei legt er einen Schwerpunkt auf die technischen Aspekte einer SOA-Entwicklung. Das an der an der Universität Tilburg (NED) entwickelte Modell für das Design und die Entwicklung von Services besteht aus den Schritten „Planning“, „Analysis“, „Service Design“, „Service Construction“, „Service Test“, „Service Execution“ sowie „Service Management and Monitoring“. Die Vorgehensbeschreibung beinhaltet im Gegensatz zu anderen untersuchten Modellen, eine detaillierte Erläuterung zur BPEL-basierten Umsetzung von Services. Pingel (brick_AT_work GmbH) beschreibt einen aus den Schritten „Spezifikation“, „Analyse“, „Design“ sowie „Realisierung“ und „Tests“ bestehenden Ansatz für die SOA-Entwicklung. Die Schritte sind dabei in weitere Subphasen untergliedert. Über den gesamten Entwicklungsprozess wird UML zur Modellerstellung eingesetzt. Das von der IDS Scheer AG entwickelte Vorgehensmodell umfasst insgesamt zehn Phasen. Es beschreibt einen modellgetriebenen Ansatz, der verstärkt auf die betriebswirtschaftlich relevanten Aspekte einer SOA fokussiert ist. Zudem wird für die Prozessschritte eine Zuständigkeitsverteilung für die Rollen „Business Analyst“, „Process Engineer“ und „Software Engineer“ vorgenommen. Der an der Universität des Saarlandes in Zusammenarbeit mit der SAP entwickelte Ansatz ist modellgetrieben. Die SOA-Entwicklung erfolgt dabei anhand eines dreistufigen Ordnungsrahmens, bestehend aus den Phasen „Prozessgestaltung“, „Prozesskonfiguration“ und „Prozessausführung“ und verfolgt speziell das Ziel, die Lücke zwischen der konzeptionellen Modellierung und der serviceorientierten IT-Unterstützung zu schließen. Das am Software Technology Research Laboratory in Leicester (ENG) entwickelte Vorgehensmodell dient der Überführung und Integration bestehender Softwarekomponenten in serviceorientierte Informationssysteme. Die Hauptphase der „Service Identificaton“ ist dabei untergliedert in „Service identifcation in problem domain“, „Service identification in a legacy system“ sowie „Matching legacy functionalities to business functions in logical services“. Die zweite Hauptphase „Service Packaging“ ist die in die Subphasen „Legacy code refinement“, „New functional development“, „Service interface and description development“, „Transport mechanism integration“, „Connector development“ und „Service complexity reduction“ segmentiert. 183 3. Ein Vergleichsrahmen für serviceorientierte Vorgehensmodelle Methodische Vorüberlegungen Um die wesentlichen Aspekte zur Charakterisierung von SOA-Vorgehensmodellen herauszuarbeiten, wird eine Klassifikation entworfen. Allgemein liegt eine Klassifikation vor, wenn ein Untersuchungsgegenstand nach einem bestimmten Merkmal und dessen Ausprägungen gegliedert wird [8, S. 10 ff.; 18, S. 142]. Zu einer solchen Klassifikation können durchaus mehrere Einteilungen nach jeweils anderen Kriterien gehören, ohne dass sich dadurch am Charakter einer klassifikatorischen Ordnung grundsätzlich etwas ändert. Die Kriterien stehen isoliert neben- oder hintereinander, wobei eine Verknüpfung der verschiedenen Einteilungskriterien nicht vorgenommen wird [18, S. 142]. Das in dieser Untersuchung verwendete Klassifikationssystem für SOA-Vorgehensmodelle besteht aus 31 Merkmalen (vgl. Tabelle 2). Um die Übersichtlichkeit des Klassifikationssystems zu wahren, sind die Merkmale zu fünf Merkmalsklassen zusammengefasst worden. Diese Klassen berücksichtigen einerseits, dass SOA-Vorgehensmodelle nicht nur entwickelt, sondern auch angewendet werden. Andererseits wird zwischen dem Vorgehen zur Vorgehensmodellkonstruktion (Konstruktionsprozess) und dessen Resultat (Konstruktionsergebnis) getrennt. Die Klassifikation orientiert sich ergänzend an den wesentlichen in der Literatur zu Vorgehensmodellen aufgeführten generellen Strukturmerkmalen und -ausprägungen [11], die um SOA-spezifische Aspekte erweitert sind. Konstruktionsprozess und -ergebnisbezogene Merkmale Die in dieser Klasse enthaltenen Merkmale charakterisierenden den mit der Entwicklung eines Vorgehensmodells verbundenen Konstruktionsprozess und dessen Konstruktionsergebnis. Herkunft, Erkenntnisweg und Repräsentationsform sind im Sinne ihres in der Wissenschaft geläufigen Gebrauchs zu verstehen. Nach dem Interaktionsgrad, also dem Grad des wechselseitigen aufeinander Einwirkens der beteiligten Akteure und/oder Systeme, sind Vorgehensmodelle dahingehend zu unterscheiden, ob sie individuell, kooperativ (arbeitsteilig) oder kollaborativ (gemeinsam bearbeitend) erstellt werden. Diese Unterscheidung adressiert das in der Literatur diskutierte „Glaubwürdigkeitsproblem“ vieler individuell entwickelter Referenzmodelle. Die Hierarchisierungsstufe gibt an, ob sich die Phasen eines Vorgehensmodells in weitere Subphasen unterteilen. Das Merkmal Individualität legt fest, ob der Ersteller eines Vorgehensmodells dieses als Referenzmodell für eine Klasse von Anwendungsfällen betrachtet oder ob es im Rahmen eines fallspezifischen, individuellen SOA-Entwicklungsprojekts entstanden ist. Merkmale mit Bezug zu SOA-Entwicklungszielen Diese Merkmalsklasse dient dazu, die Ziele und Zwecke, für welche ein SOA-Vorgehensmodell entwickelt wurde, näher zu charakterisieren. Das Merkmal Perspektive beschreibt die potenzielle Zielgruppe eines Vorgehensmodells. Dabei erfolgt eine Dreiteilung in die Ausprägungen Serviceanbieter, -broker und -anwender. In Abhängigkeit zu entwickelnden Informationssystems können Vorgehensmodelle danach unterschieden werden, ob sie eher die Anwendungs- oder die Organisationssystemkomponente im Sinne eines Informationssubsystems betrachten. Darüber hinaus sind für Vorgehensmodelle zwei unterschiedliche Schwerpunkte in Bezug auf den Verwendungszweck zu differenzieren. Vorgehensmodelle, die auf Business Engineering ausgelegt sind, fokussieren die flexible Anpassung von Geschäftsprozessen an sich ständig verändernde wirtschaftliche Anforderungen. Im Gegensatz dazu liegt das Hauptaugenmerk von software-engineering-orientierten Vorgehensmodellen auf der Gestaltung des Zusammenspiels zwischen den Geschäftsprozessen und der sie unterstützenden Anwendungssysteme. Da für die Entwicklung von SOA mehrere technische Optionen bestehen, sind Vorgehensmodelle dahingehend zu unterscheiden, ob sie in Bezug auf ihre technologische Ausrichtung unabhängig oder gebunden (z. B. an den Web-Service-TechnologyStack) sind. Ein weiteres Merkmal trifft eine Aussage darüber, ob ein Vorgehensmodell einen konkreten Produktbezug aufweist. Insbesondere aus der Praxis stammende Vorgehensmodelle sind 184 häufig auf konkrete Softwareprodukte (z. B. Modellierungswerkzeuge oder Entwicklungsumgebungen) ausgerichtet. Die Merkmale Organisations- und Aufgabenbezug beschreiben die verschiedenen Projektgrenzen, für die ein Vorgehensmodell auslegt sein kann. Es ist zu unterscheiden, ob ein Vorgehensmodell nur organisationsinterne SOA berücksichtigt, oder ob es zusätzlich die Entwicklung von unternehmensübergreifenden SOA unterstützt. Analog kann ein Vorgehensmodell dazu dienen, lediglich eine einzelne Aufgabe innerhalb eines Unternehmens als SOA abzubilden, oder es kann zur Entwicklung einer SOA dienen, die einen kompletten Unternehmensteilbereich abdeckt. SOA-unspezifische Vorgehensmerkmale Diese Merkmalsklasse umfasst generelle Eigenschaften, mit denen sich Vorgehensmodelle charakterisieren lassen. Die Anwendungsdömane eines Vorgehensmodells kann entweder spezifisch oder neutral ausgeprägt sein. Domänenneutrale Vorgehensmodelle sind auf beliebige Entwicklungsszenarien anwendbar, während domänenspezifische Modelle nur auf eine Klasse von Anwendungsfällen (z. B. Branche) passen. Das Merkmal Vorgehenssteuerung beschreibt die verschiedenen Arten der Prozesssteuerung für Vorgehensmodelle. Ein Vorgehensmodell ist aktivitätsorientiert, wenn es eine festgelegte Abfolge von Aktivitäten beschreibt. Es ist ergebnisorientiert, wenn sein Schwerpunkt auf der phasenübergreifenden Transformation der zu erzielenden Ergebnisse liegt. Ein entscheidungsorientiertes Vorgehensmodell definiert Bedingungen, die in Abhängigkeit ihres Eintretens die Art und die Reihenfolge der durchzuführenden Aktivitäten bestimmen. Das Merkmal Problemlösung orientiert sich in seinen Ausprägungen iterativ, inkrementell und rekursiv an den korrespondierenden Vorgehensmodellbeschreibungen aus dem Bereich des Software Engineering [11]. Die Phasenanordnung eines Vorgehensmodells kann entweder streng sukzessiv aufgebaut sein, d. h. mit einer neuen Phase kann erst dann begonnen werden, wenn die vorangehende Phase abgeschlossen ist, aber auch mehrere parallel auszuführende Phasen aufweisen. Die Merkmale Sprachempfehlung, Methodenempfehlung und Werkzeugunterstützung treffen Aussagen über Instrumente, denen sich das Vorgehensmodell bedient. Das Spektrum von Sprachempfehlungen reicht vom UML-Aktivitätsdiagramm über die EPK bis hin zu BPMN oder BPEL. Als Empfehlung für eine homogene Gesamtmethode kommen beispielsweise ARIS oder UML in Frage. Damit einhergehend kann zusätzlich eine Werkzeugempfehlung für einzelne Phasen oder den Gesamtprozess ausgesprochen werden. Die Ergebnisse der einzelnen Phasen werden i. d. R. in einer Ergebnisdokumentation festgehalten, deren Gestaltung textuell oder grafisch (modellorientiert) erfolgen kann. SOA-spezifische Vorgehensmerkmale Neben den zuvor beschriebenen, generellen Charakteristika, die auf Vorgehensmodelle anwendbar sind, existiert darüber hinaus eine Reihe SOA-spezifischer Merkmale. So ist im Rahmen einer SOA-Entwicklung zu Beginn i. d. R. eine Projektinitialisierung durchzuführen, um einen Anforderungskatalog zu definieren. Als Gegenstand der Initialisierung kommen dabei entweder eine Geschäftsprozessanalyse, die Untersuchung eines bereits existierenden Anwendungssystems oder eine abstrakte Betrachtung der Unternehmensstrategie, aus der sich konkrete Anforderungen ableiten lassen, in Frage. Eine SOA-Einführung kann analog zu den im Software Engineering bestehenden Optionen durch eine Aneinanderreihung einzelner Teilprojekte oder durch einen „Big-Bang“ erfolgen. Im ersteren Fall ist die Migrationsstrategie evolutionär, im letzteren Fall revolutionär. Die Entwicklungsstrategie eines SOA-Vorgehensmodells lässt sich analog zum Software Engineering in die Ausprägungen top-down, middle-out und bottum-up untergliedern. Die Funktionen, die innerhalb eines Geschäftsprozesses auftreten, sind nach ihrer potenziellen IT-Unterstützung in automatisch, semiautomatisiert und manuell zu differenzieren. Das Merkmal Automatisierungsgrad gibt an, welche der entsprechenden Servicearten ein Vorgehensmodell berücksichtigt. Zu einem Zeitpunkt, zu dem bereits die Anforderungen und die erforderliche Funktionalität für ein Projekt festgelegt wurden, ist zu entscheiden, welche Services mit welchem Funktionsumfang diese Anforderungen abdecken sollen. Grundsätzlich bestehen zwei Möglichkeiten zur Durchführung dieser Service- 185 identifikation. Eine fachliche Serviceidentifikation leitet die erforderlichen Services aus den zuvor erkannten Funktionen der Geschäftsprozesse ab, eine technische Serviceidentifikation erfolgt durch eine Überführung der Funktionalität von Komponenten bereits existierender Anwendungssysteme in Services. Darüber hinaus können SOA-Vorgehensmodelle als Merkmal die konkrete Darstellung eines Konstruktionsprozesses für die technische Serviceentwicklung enthalten, die eine detaillierte Beschreibung für die Entwicklung einzelner Services umfasst. Neben der Identifikation von Services ist ein Abgleich zwischen den identifizierten und den real verfügbaren Services vorzunehmen. Das Ziel eines SOA-Alignment-Prozesses liegt darin, evtl. bestehende Abweichungen zwischen den identifizierten und den real verfügbaren Services zu beseitigen. Dies kann durch eine direkte Zuordnung von identifizierten Services zu realen Services erfolgen. Für business-getriebene Vorgehensmodelle besteht darüber hinaus die Möglichkeit einer indirekten Zuordnung. Dabei werden die Geschäftsprozessmodelle in einem Zwischenschritt zu technisch-fachlichen Anwendungsmodellen transformiert, anschließend erfolgt eine Zuordnung zu den real existierenden Services. Ein Beispiel für einen indirekten Transformationsprozess ist die Überführung von EPK- in BPMN-Modelle [40]. Zu einem nachgelagerten Zeitpunkt einer SOA-Einführung ist eine Auswahlentscheidung zwischen den infrage kommenden Services zu treffen. SOA-Vorgehensmodelle können für die Serviceselektion eine Entscheidungsunterstützung auf zwei Arten zur Verfügung stellen: anhand von Qualityof-Service-Merkmalen [38] oder alternativ anhand wirtschaftlicher Gütekriterien [42]. Um aus einzelnen Services eine Applikation erstellen zu können, müssen diese zusammengefügt werden. Diesen Vorgang bezeichnet man auch als Servicekomposition. Grundsätzlich bestehen für die Komposition zwei grundlegende Strategien. Zum einen können die Services prozessorientiert gesteuert werden. Für den Fall, dass unternehmensübergreifende Applikationen implementiert werden sollen, ist eine Koordination zwischen den Anwendungssystemen der beteiligten Partner zu gewährleisten (Service-Choreographie). Alternativ zur Prozessorientierung lassen sich Services auch zu funktionsorientierten Komponenten aggregieren. In diesem Fall werden nur die Schnittstellen dieser Komponenten über eine Orchestrierung gesteuert, während innerhalb der Komponenten z. B. objektorientierte Techniken verwendet werden. In Bezug auf ihre Anwendung sind SOA dadurch gekennzeichnet, dass in den meisten Fällen bereits zur Buildtime einer SOA definiert wird, welche Services zur Runtime aufzurufen sind. SOA erlauben es allerdings auch, die Entscheidung darüber, welche Services aufzurufen sind, in die Runtime zu verschieben. Der Entscheidungsprozess dieses „dynamic binding“ kann entweder ereignisgesteuert oder manuell ablaufen. Vorgehensmodelle lassen sich insofern unterscheiden, ob sie diese verschiedenen Arten einer Servicesteuerung berücksichtigen. 4. Anwendung des Vergleichsrahmens In Tabelle 2 sind die ausgewählten Vorgehensmodelle in den hergeleiteten Merkmalen und Merkmalsausprägungen vergleichend gegenübergestellt. Es ist erkennbar, dass die serviceorientierten Vorgehensmodelle eine große Vielfalt von Anwendungsszenarien bedienen. Diese inhaltliche Heterogenität erschwert ihren Vergleich. Das Spektrum reicht von der einfachen Serviceidentifikation auf Basis bestehender Softwarelandschaften [29], der Erarbeitung fachlich orientierter Servicearchitekturen [15], der serviceorientierten Integration zweier Softwaresysteme [22] über die unternehmensweite Einführung von SOA [13] bis hin zu Reorganisationsprojekten auf Basis von SOA sowie der Entwicklung serviceorientierter Softwaresysteme [44]. Die Breite des Spektrums verdeutlicht, dass über die Entwicklungsprozesse für serviceorientierte Architekturen bislang kein Konsens herrscht. Daher wird in dieser Untersuchung bewusst auf eine terminologische Eingrenzung der Vorgehensmodelle zugunsten einer kriterienbasierten Auswahl verzichtet. Während frühe Vorgehensmodelle zur serviceorientierten Systementwicklung an der technischen Realisierung ausgerichtet sind [3; 29], betonen neuere Ansätze die Relevanz betriebswirtschaftlichfachlicher Aspekte für den Entwicklungsprozess [34; 44]. Beispielhaft sei die Diskussion um eine 186 Entscheidungsunterstützung bei der Auswahl von Web Services aufgegriffen, die sich häufig an der Dienstgüte (Quality of Service), einem eher technisch ausgerichteten Kriterium, orientiert [38]. Fragen der wirtschaftlichen Nutzung von SOA werden erst im neueren Schrifttum berücksichtigt [42]. Tabelle 2: Klassifikation serviceorientierter Vorgehensmodelle Klasse Merkmal Konstruktionsprozess Herkunft Erkenntnisweg Merkmalsausprägung [1] [3] [4] [13] [15] [16] Wissenschaft — — — — ( ) ( ) Konstruktionsergebnis Hierarchisierung Individualität Perspektive — [25] [26] [28] [29] — — — — — — — — Kooperativ — — — — — — — — — — — — — — — — — — — — — — — [39] — ( ) [40] — — — — — [44] — — — — [36] — — — — [34] — Induktiv Kollaborativ Repräsentationsform [22] — Deduktiv Individuell Interaktionsgrad — Praxis [19] — — — — — — — — — — — — — — — — — ( ) ( ) — ( ) — — — — Textuelles Modell Grafisches Modell Hierarchisiert Nicht Hierarchisiert — — Spezifisches Modell — — — Serviceanbieter ( ) — ( ) Servicebroker — — — — — — — — — — — — — — — — — — — — — — — — — ( ) ( ) ( ) ( ) ( ) ( ) ( ) — — — — — — — — — — — — — — — — — — — ( ) — — — Referenzmodell — Serviceanwender SOA-Entwicklungsziel Informationssubsystem Verwendungszweck Technologische Ausrichtung Produktbezug Organisationsbezug Aufgabenbezug Anwendungsdömane Organisationssystem — Anwendungssystem Business Engineering ( ) Software Engineering Unabhängig — — — — Gebunden — — — — — — — — — — — — — — — — — — O Organisationsintern ( ) — — — — — — — — — — — — — — — — — — ( ) — — — — — — — — — — — O Aufgabenbereich O — Einzelaufgabe Domänenspezifisch — — — ( ) — — — Organisationsübergreifend — — — Produktunabhängig Produktabhängig — — — — — — — — — O — — — — — — Domänenneutral ( ) Aktivitätsorientiert SOA-unspezifische Vorgehensmerkmale Vorgehenssteuerung Ergebnisorientiert — — — Entscheidungsorientiert — — — — — — — — — — — — — — — — — — — — — — — — — — — — — Rekursiv Problemlösung Iterativ — Methodenempfehlung Parallel — — — — — — — — — — — — SOA-spezifische Vorgehensmerkmale Ergebnisdokumentation Gegenstand der Initialisierung Homogen — Singulär — — — Pluralistisch — — — Phasenbezogen — — — Durchgängig SOAEntwicklungsstrategie — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — Grafisch O — — — — — Top-Down — Middle-Out — — — — — — — — — — — — — O O O O O O — — — — — — — — — — — — — — — — — — — 187 — — — — — — O — — — — — — — O O O O — — — — — — — — — — — — O — — Evolutionär — — — — Anwendungssystem — — — O Geschäftsprozess Revolutionär — — Textuell Unternehmensstrategie SOAMigrationsstrategie — — Heterogen Keine Werkzeugunterstützung — Sukzessiv Keine Sprachempfehlung ( ) — — Inkrementell Phasenanordnung — — ( ) — — — — — — O O O O — O O O O — — — — — — — — — — Klasse Merkmal Merkmalsausprägung [1] [3] Manuell — — Semiautomatisiert — — [4] Bottom-Up Automatisierungsgrad Serviceidentifikation Technische Serviceentwicklung SOAAlignmentProzess Servicesteuerung — — — — [16] [19] [22] [25] [26] [28] [29] [34] O O — — — — — — O O — — — — — — O O — Fachlich — Technisch — — — — Berücksichtigt — O — O Nichtberücksichtigt — Keiner — — — O — — Direkt Indirekt — — — Quality of Service — — Wirtschaftlichkeit — — Prozessorientiert Servicekomposition [15] Automatisiert Keine Serviceselektion [13] O O — — O ( ) — — O — O O O O O O O O — O O O O — O O — — — — — — — — — — — — — — — — — O O O — — — — — — O O O Choreographie O O O O O O O — O Komponentenorientiert — — O O — O — O — — — Manuell O — O O O O — — O — Vordefiniert O O O O Eventorientiert O O O O — Legende: 9 Merkmal erfüllt, – Merkmal nicht erfüllt, (9) Merkmal teilweise erfüllt, — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — O — O — O O O — — — — O — — — — — O — — — — — O — O — — O O — — — O O [44] — O — — — O O [40] — Orchestrierung — [39] — — — [36] O O O Merkmal nicht zu beurteilen Eine Mehrheit von dreizehn Vorgehensmodellen sieht eine direkte [z. B. 36] oder indirekte [z. B. 40] Überführung fachlicher Serviceanforderungen des Organisationssystems in die serviceorientierte Umsetzung des Anwendungssystems vor. Jedoch bleibt die umgekehrte Rückführung von technischen Anforderungen in die Fachbeschreibungen von nahezu allen Vorgehensmodellen unberücksichtigt. In der Folge fehlt es insgesamt an wechselseitigen Synchronisationstechniken, die für eine Integration von Organisations- und Anwendungssystemen erforderlich sind. Gleichwohl bei SOA i. d. R. drei Stakeholder zu unterscheiden sind, bleiben in vielen Vorgehensmodellen Perspektiven auf die serviceorientierte Systementwicklung unberücksichtigt. Die vorliegenden Empfehlungen nehmen fast ausnahmslos die Rolle der Service-Konsumenten, d. h. der anwendenden Organisation, ein und lassen die Sichtweise der Service-Anbieter und -Broker außen vor. Dies steht im Widerspruch dazu, dass Softwareprojekte i. d. R. nicht von den Konsumenten der zu entwickelnden Anwendungssysteme durchgeführt werden. Für die erfolgreiche Abwicklung eines Softwareprojekts sind zudem Erfahrung und Fachwissen vorauszusetzen. Nicht jeder ServiceKonsument, der eine SOA-Einführung beabsichtigt, verfügt zwangsläufig über ein ausreichendes Maß an erforderlichem Fachwissen. In diesem Zusammenhang ist in Zukunft eine Veränderung de Fokus von reinen Anwendermodellen hin zu anbieterorientierten Vorgehensmodellen zu fordern. Nur wenige Vorgehensmodelle berücksichtigen organisationsübergreifende Geschäftsszenarien für die Anwendung einer SOA. Dabei verspricht die Serviceorientierung gerade für kollaborative Geschäftsprozesse größere Flexibilität und Integration. Gleichwohl gehen nur drei Vorgehensmodelle [26; 28; 34] explizit auf die Möglichkeit ein, unternehmensübergreifende Prozesse durch die Choreographie von Services abzubilden. Die übrigen Modelle beschränken sich auf eine unternehmensinterne Serviceorchestrierung bzw. nehmen keine Unterscheidung vor. Auffällig ist weiterhin, dass über die Hälfte der untersuchten Vorgehensmodelle die Frage nach einer Migrationsstrategie vernachlässigt und keine Aussage darüber trifft, wie die zu entwickelnde SOA in die bestehende Anwendungslandschaft eingebunden werden kann. In der Praxis ist diese Problematik der Integration jedoch immer aufzulösen. Für die weitere Gestaltung von Vorgehensmodellen ist die Einbindung einer Migrationsstrategie als obligatorischer Bestandteil zu fordern. 188 Darüber hinaus zeigt sich, dass eine Reihe von Vorgehensmodellen eine technische Serviceidentifikation durch die Analyse der bestehenden Anwendungssysteme vorsieht. Für die Implementierung ist dabei eine Transformation von Fragmenten der Altsysteme in Services vorgesehen. Eine solche Vorgehensweise ist nur für Serviceprovider und nicht für Serviceanwender praktikabel, da die anwendenden Organisationen in der Regel fremdbezogene, betriebliche Standardsoftware einsetzen, für die ihnen i. d. R. die erforderlichen Softwarelizenzen fehlen. Aus der Perspektive des Prozessmanagements ist zu beachten, dass nur die wenigsten Geschäftsprozesse durchgängig mit softwaregestützten Services zu automatisieren sind. Manuelle Tätigkeiten und eine Mensch-Maschine-Interaktion werden vor dem Hintergrund der zunehmenden Bedeutung von Dienstleistungs- und Wissensarbeit auch zukünftig eine bedeutende Rolle bei der serviceorientierten Systementwicklung spielen. Lediglich drei der untersuchten Vorgehensmodelle beziehen entsprechende Überlegungen mit ein [4; 16; 36]. 5. Konklusion und Ausblick Insgesamt kann das Profil der serviceorientierten Vorgehensmodelle kaum zufrieden stellen. Trotz des breiten Spektrums der Modelle offenbart die Analyse einen Rückstand des State-of-the-Art gegenüber den Potenzialen, die gemeinhin mit einer serviceorientierten Systemgestaltung verbunden werden. Dementsprechend liefert die in diesem Beitrag durchgeführte Untersuchung erstmalig eine umfassende Bewertung von SOA-Vorgehensmodellen und zeigt Verbesserungspotenziale für das Vorgehen in serviceorientierten Implementierungsprojekten auf. Der entwickelte Vergleichsrahmen bietet eine Vielzahl an SOA-spezifischen und -unspezifischen Merkmalen und ermöglicht die kritische Würdigung neu konstruierter serviceorientierter Vorgehensmodelle. Die insb. im Rahmen der Merkmalsklassifikation gewonnenen Erkenntnisse können in einem konkreten SOA-Einführungsprojekt als Entscheidungsunterstützung für die Auswahl eines Vorgehens herangezogen werden. Darüber hinaus lassen sich funktionale Anforderungen an eine IT-Unterstützung für die Einführung von SOA ableiten. Aufgrund der flexiblen Struktur kann der Vergleichsrahmen zukünftig jederzeit erweitert und um relevante Merkmale für einen spezifischen Untersuchungskontext ergänzt werden. Eine mögliche Erweiterung des Vergleichsrahmens wäre die Evaluation der Vorgehensmodelle in ihrem praktischen Einsatz im Rahmen von Anwenderbewertungen. 6. Literatur [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] Arsanjani, A.: Service-oriented modeling and architecture. Markham, Canada : IBM, 2004 Balzert, H.: Lehrbuch der Software-Technik : Software-Entwicklung. 2. Aufl. Heidelberg : Spektrum, 2001 Barry, D. K.: Web services and service-oriented architectures. Amsterdam : Morgan Kaufmann, 2003 Bieberstein, N.: Service-oriented architecture (SOA) compass. Upper Saddle River, NJ : IBM Press, 2006 DeRemer, F.; Kron, H.: Programming-in-the large versus programming-in-the-small. In: Proceedings of the international conference on Reliable software. Los Angeles, CA : ACM, 1975, S. 114 –121 Dostal, W.; Jeckle, M.; Melzer, I.; Zengler, B.: Service-orientierte Architekturen mit Web Services: Konzepte – Standards – Praxis. Heidelberg : Elsevier, 2005 Dustdar, S.; Krämer, B. J.: Introduction to special issue on service oriented computing (SOC). In: ACM Transactions on the Web 2 (2008), Nr. 2, S. 1–2 Engelien, G.: Der Begriff der Klassifikation. Hamburg : Buske, 1971 Erl, T.: Service-oriented architecture. Upper Saddle River : Prentice Hall PTR, 2006 Fettke, P.; Intorsureanu, I.; Loos, P.: Komponentenorientierte Vorgehensmodelle im Vergleich. In: Turowski, K. (Hrsg.): 4. Workshop Komponentenorientierte betriebliche Anwendungssysteme. Augsburg, 2002, S. 19– 43 Filß, C. et al.: Rahmen zur Auswahl von Vorgehensmodellen. In: Petrasch, R. et al. (Hrsg.): 12. Workshop der Fachgruppe WI-VM der GI. Aachen : Shaker, 2005, S. 183–227 Fremantle, P.; Weerawarana, S.; Khalaf, R.: Enterprise services. In: Communications of the ACM 45 (2002), Nr. 10, S. 77–82 Hack, S.; Lindemann, M. A.: Enterprise SOA einführen. Bonn : Galileo Press, 2007 Henderson, J. C.; Venkatraman, N.: Strategic Alignment: Leveraging Information Technology for Transforming Organisations. In: IBM Systems Journal 32 (1993), Nr. 1, S. 272–284 Jones, S.; Morris, M.: A Methodology for Service Architectures. London : Capgemini, 2005 189 [16] [17] [18] [19] [20] [21] [22] [23] [24] [25] [26] [27] [28] [29] [30] [31] [32] [33] [34] [35] [36] [37] [38] [39] [40] [41] [42] [43] [44] [45] Klose, K.; Knackstedt, R.; Beverungen, D.: Identification of Services – A Stakeholder-Based Approach to SOA Development and its Application in the Area of Production Planning. In: Österle, H. et al. (Hrsg.): Proceedings of the 15th European Conference on Information Systems, St. Gallen, Juni 2007, S. 1802–1814 Klückmann, J.: 10 Steps to Business-Driven SOA. Saarbrücken : IDS Scheer AG, 2007 Knoblich, H.: Die typologische Methode in der Betriebswirtschaftslehre. In: Wirtschaftswissenschaftliches Studium 1 (1972), Nr. 4, S. 141–147 Kohlmann, F.: Service Identification and Design – A Hybrid Approach in Decomposed Financial Value Chains. In: Reichert, M.; Strecker, S.; Turowski, K. (Hrsg.): Proceedings of the 2nd International Workshop on Enterprise Modelling and Information Systems Architectures, St. Goar, Germany, October 2007, S. 205–218 Krafzig, D.; Banke, K.; Slama, D.: Enterprise SOA. 5. print. Upper Saddle River : Prentice Hall PTR, 2006 Kreger, H.: Fulfilling the Web Services Promise. In: Communications of the ACM 46 (2003), Nr. 6, S. 29–34 Lämmer, A.; Eggert, S.; Gronau, N.: A Procedure Model for a SOA-based Integration of Enterprise systems. In: International Journal of Enterprise Information Systems 4 (2008), Nr. 2, S. 1–12 Leymann, F.: Web services: Distributed applications without limits. In: Weikum, G.; Schöning, H.; Rahm, E. (Hrsg.): BTW 2003, Datenbanksysteme für Business, Technologie und Web, Tagungsband der 10. BTWKonferenz, 26.–28. Februar 2003, Leipzig. Leipzig : Springer, 2003, S. 2–23 Malinverno, P.: Service-Oriented Architecture Craves Governance. Stamford, CT : Gartner Research, 2006 Masak, D.: SOA?: Serviceorientierung in Business und Software. Berlin : Springer, 2007 Mathas, C.: SOA intern: Praxiswissen zu serviceorientierten IT-Systemen. München : Hanser, 2008 McGovern, J.; Tyagi, S.; Stevens, M.; Mathew, S.: Java web services architecture. San Francisco : Kaufmann, 2003 Mitra, T.: Business-driven development. IBM : Markham, Canada, 2005 Nadhan, E. G.: Seven Steps to a Service-Oriented Evolution. In: Business Integration Journal (January) (2004), S. 41– 44 Noack, J.; Schienmann, B.: Objektorientierte Vorgehensmodelle im Vergleich. In: Informatik-Spektrum 22 (1999), Nr. 3, S. 166–180 Nüttgens, M.; Iskender, D.: Geschäftsmodelle für dienstebasierte Informationssysteme – Ein strategischer Ansatz zur Vermarktung von Webservices. In: Wirtschaftsinformatik 50 (2008), Nr. 1, S. 31–38 Overhage, S.; Turowski, K.: Serviceorientierte Architekturen – Konzept und methodische Herausforderung. In: Nissen, V.; Petsch, M.; Schorcht, H. (Hrsg.): Service-orientierte Architekturen – Chancen und Herausforderungen bei der Flexibilisierung und Integration von Unternehmensprozessen. Wiesbaden : DUV, 2007, S. 3–17 Papazoglou, M. P.; Traverso, P.; Dustdar, S.; Leymann, F.: Service-Oriented Computing: A Research Roadmap. In: International Journal of Cooperative Information Systems 17 (2008), Nr. 2, S. 223–255 Papazoglou, M. P.; van den Heuvel, W.-J.: Service-oriented design and development methodology. In: International Journal Web Engineering and Technology 2 (2006), Nr. 4, S. 412– 442 Parnas, D. L.: On the criteria to be used in decomposing systems into modules. In: Communications of the ACM 15 (1972), Nr. 12, S. 1053–1058 Pingel, D.: Der SOA-Entwicklungsprozess. In: Starke, G.; Tilkov, S. (Hrsg.): SOA-Expertenwissen: Methoden, Konzepte und Praxis serviceorientierter Architekturen. Heidelberg : dpunkt, 2007, S. 187–200 Sametinger, J.: Software engineering with reusable components. Berlin : Springer, 1997 Spahn, M.; Berbner, R.; Heckmann, O.; Steinmetz, R.: Ein heuristisches Optimierungsverfahren zur dienstgütebasierten Komposition von Web-Service-Workflows. In: Steinmetz, R. (Hrsg.): Technical Report, Multimedia Communications Lab, Nr. KOM-TR-2006-02, TU Darmstadt, 2006 Stein, S.; Ivanov, K.: Vorgehensmodell zur Entwicklung von Geschäftsservicen. In: Fähnrich, K.-P.; Thränert, M. (Hrsg.): Integration Engineering – Motivation, Begriffe, Methoden und Anwendungsfälle, Leipziger Beiträge zur Informatik VI. Leipzig : Eigenverlag Leipziger Informatik-Verbund, 2007 Thomas, O.; Leyking, K.; Dreifus, F.: Prozessmodellierung im Kontext serviceorientierter Architekturen. In: HMD – Praxis der Wirtschaftsinformatik 43 (2007), Nr. 253, S. 37– 46 Tsai, W. T.: Service-Oriented System Engineering: A New Paradigm. In: Service-Oriented System Engineering, 2005 (SOSE 2005) : IEEE International Workshop, 20–21 Oct. 2005 ; Proceedings. IEEE, 2005, S. 3–6 vom Brocke, J.: Serviceorientierte Architekturen – SOA. München : Vahlen, 2008 Woods, D.; Mattern, T.: Enterprise SOA: designing IT for business innovation. Beijing : O‘Reilly, 2006 Zhang, Z.; Liu, R.; Yang, H.: Service Identification and Packaging in Service Oriented Reengineering. In: Chu, W. C. et al. (Hrsg.): Proceedings of the 17th International Conference on Software Engineering and Knowledge Engineering (SEKE‘2005), Taipei, Taiwan, Republic of China, July 14 –16, 2005. Tapei, 2008, S. 620–625 Zhu, H.: Software design methodology. Amsterdam : Elsevier, 2005 190 GESCHÄFTSPROZESSMANAGEMENT Das prozessorientierte Paradigma wandelt sich zunehmend von einem funktionalen hin zu einem dienstebasierten Verständnis. Dieses ist durch einen stärkeren Grad an Flexibilisierung, Koordination und sozialer Interaktion geprägt. Neue stategische Konzepte wie Web 2.0, Empfehlungsmarketing oder Leistungsbündelung und -virtualisierung erfordern eine Weiterentwicklung prozessorientierter Methoden und Werkzeuge. Geschäftsprozessmodelle fungieren hierbei als Bindeglied zwischen Strategie und IT-gestützter Implementierung. Ziel des Tracks ist es, Konzepte und Fallstudien aus praxisnahen und anwendungsbezogenen Forschungsarbeiten unter ökonomischen, organisatorischen und IT-technischen Aspekten zu thematisieren. Es werden Beiträge erbeten, die in angemessener Form der Interdisziplinarität des Themas Rechnung tragen. Neben trackspezifi schen Fragestellungen sind insbesondere auch Beiträge mit Bezug zur thematischen Ausrichtung der Gesamttagung erwünscht. Leitungsgremium: Rony Flatscher, Wirtschaftsuniversität Wien Peter Loos, Universität des Saarlandes und IWi im DFKI Markus Nüttgens, Universität Hamburg (Federführender) Michael Rosemann, Queensland University of Technology Programmkomitee: Christian Brelage, SAP Research Jörg Desel, Katholische Universität Eichstätt Ingolstadt Andreas Gadatsch, Fachhochschule Bonn-Rhein-Sieg Helge Heß, IDS Scheer Peter Küng, Credit Suisse Peter Rittgen, Universität Boras Frank Rump, Fachhochschule Oldenburg/Ostfriesland/Wilhelmshaven (Emden) Jan vom Brocke, Hochschule Liechtenstein Michael zur Muehlen, Stevens Institute of Technology FALLSTUDIE ZUM EINSATZ AGILER, PROZESSORIENTIERTER METHODEN IN DER CHIPINDUSTRIE Mirjam Minor, Daniel Schmalen1, Andreas Koldehoff2 Kurzfassung Der vorliegende Beitrag befasst sich mit einer Fallstudie zum Einsatz Agiler WorkflowTechnologie in der Chipindustrie. Im Zentrum der Untersuchung stehen die eigens entwickelten agilen, prozessorientierten Methoden, die wichtiger Bestandteil dieser Technologie sind3. In der Fallstudie wurde eine prototypische Implementierung eines Agilen Workflow-Management-Systems verwendet. Dieser Pilot wurde in einem realen Chipentwicklungsprojekt in der Firma Silicon Image angewandt. Die Ergebnisse wurden von einem gemischten Team aus Chip-Experten und Workflow-Experten bewertet. Dabei wurden IT-technische, ökonomische und organisatorische Aspekte betrachtet. Die beiden Hauptziele der Studie waren, branchenspezifische Erkenntnisse über die Anwendbarkeit der Agilen Workflow-Technologie zu gewinnen und Hinweise zur Gestaltung von neuen Methoden und Tools für Agile Workflows zu bekommen. Die guten Resultate der Fallstudie lassen darauf hoffen, dass Agile Workflow-Technologie ein wichtiger Baustein für ein serviceorientiertes Geschäftsprozessmanagement werden könnte. 1. Einführung 1975 sagte Gordon Moore eine „Verdopplung der Transistoren je Chip alle 18 Monate“ [zitiert nach 3, S.23] voraus. Seitdem bestätigt der Markt dieses Moore’sche Gesetz mit bemerkenswerter Genauigkeit. Mit der steigenden Anzahl an Transistoren und Komponenten, die auf einem Chip integriert werden, steigt auch die Komplexität der Entwicklungsprozesse und damit der Aufwand für eine systematische Qualitätssicherung. Trotz der steigenden Komplexität muss die Chipentwicklung unter sehr engen zeitlichen Rahmenbedingungen geschehen, um am Markt Chancen auf Erfolg zu haben. Projektverzögerungen bergen die Gefahr, den gesamten Markt zu verlieren. Kann ein konkurrierendes Unternehmen ein Chipdesign oder fabrizierte Chips mit neuen Funktionalitäten schneller liefern, wird es sehr schwierig, für die eigenen Entwürfe und Produkte noch Kunden zu finden. Folglich ist es ein entscheidender Erfolgsfaktor für die Firmen, die Balance zwischen Qualität und schneller Marktreife zu halten. Prozessorientierte Methoden und Tools sind 1 Universität Trier, Wirtschaftsinformatik II, D-54286 Trier Silicon Image GmbH, Garbsener Landstr. 10, D-30419 Hannover 3 Die Autoren verwenden einen Technologie-Begriff, der sowohl die Technik (Tools, Standards, etc.) als auch die Methoden und deren Anwendung einschließt (vgl. [1, S. 653]). 2 193 in der Chipindustrie auf dem Vormarsch4. Die Methoden und Tools tragen durch die systematische Unterstützung der Chip-Entwicklungsprozesse dazu bei, den entscheidenden Zeitvorsprung zu schaffen und gleichzeitig die Qualität durch lückenlose Verifikation und Validierung der Designs zu sichern. Wichtige Grundlage hierfür ist die Spezifikation und Einhaltung eines Design Flows, der die Entwicklungsprozesse Schritt für Schritt beschreibt. Dies wird in einigen Firmen bereits betrieben und gewinnt zunehmend an Bedeutung. Als technische Mittel zur Spezifikation von Design Flows werden vorwiegend Texteditoren oder graphische Tools wie Microsoft Visio eingesetzt. Der hohe Automatisierungsgrad der Einzelschritte in der Chipentwicklung, zum Beispiel bei der Synthese eines Chiplayouts aus einer Beschreibung in HDL (hardware description logic), spricht für eine stärkere Formalisierung der Prozesse mit Orientierung am Service-Gedanken und am Workflow-Paradigma. Heutige Workflow-Technologie fokussiert darauf, Geschäftsprozesse durch automatische Unterstützung zügig abzuwickeln. Auf den ersten Blick sind bereits käufliche Lösungen, die Services mit Geschäftsprozessmanagement integrieren, für Electronic Design Automation (EDA) anwendbar, so zum Beispiel Microsoft Biztalk Server [4], IBM WebSphere Business Services Fabric [2] oder SAP NetWeaver [10]. Design Flows können damit in Standards wie Web Services Business Process Execution Language WS-BPEL [9] oder Business Process Modeling Notation BPMN [8] spezifiziert werden. Automatisierte Einzelaufgaben im Prozess können durch Services erbracht werden. Die Integration nichtautomatisierter Aufgaben („human tasks“) ist derzeit Gegenstand der Forschung, wird jedoch bald realisiert sein [12]. Wie die Unternehmenspraxis aber gezeigt hat, reicht die Flexibilität der verfügbaren, kommerziellen Lösungen für die Anforderungen der Chipindustrie nicht aus: „Eine WorkflowTechnologie, die sich nicht an Veränderungen anpasst, könnten wir nicht einsetzen“, konstatiert ein Chipexperte von Silicon Image GmbH [S. Rackow, persönliches Interview, 25. Oktober 2006]. Damit ist nicht der bloße Austausch einzelner Services und Tools im Sinne einer NeuOrchestrierung gemeint, sondern echte, strukturelle Anpassungen der Entwicklungsprozesse zur Laufzeit, wie sie die zunehmende Flexibilisierung der Chipindustrie erfordert. Dies kann zum Beispiel die Parallelisierung ursprünglich sequentieller Entwicklungs-Aufgaben sein, um die laufende Entwicklung durch den Einsatz von freischaffenden Mitarbeitern ad hoc zu beschleunigen. Agile Workflow-Technologie [14,7] widmet sich der automatischen Unterstützung von Prozessen, die einen hohen Grad an Agilität aufweisen, das heißt, die – geplant oder ad hoc – strukturelle Anpassungen zur Laufzeit erfahren. Um exemplarisch zu überprüfen, ob eine Weiterentwicklung prozessorientierter Methoden und Werkzeuge zu agiler Workflow-Technologie in der Chipentwicklung nutzbringend einsetzbar ist, wurde die vorliegende Fallstudie unter Verwendung einer eigenen, prototypischen Implementierung durchgeführt und die Ergebnisse durch ein gemischtes Team von Chipentwicklern und Workflow-Experten bewertet. Die Potenziale für intra- und interorganisationale Geschäftsprozesse in der Chipindustrie wurden durch die Chipexperten abgeschätzt. Des Weiteren ist die Fallstudie Bestandteil eines inkrementellen Entwicklungsansatzes für neue Workflow-Technologie. Die Erkenntnisse aus der Fallstudie dienen der Gestaltung der Methoden und Werkzeuge für agile Workflows. Dies gilt nicht primär der branchenspezifischen Weiterentwicklung agiler Workflow-Technologie für die Chipindustrie als vielmehr einem domänenübergreifenden Ansatz, der eine erste Evidenz aus den Ergebnissen der Fallstudie bezieht. 4 Die Autoren konnten sich bei den Chipentwicklern AMD, Cadence, Infineon und Silicon Image persönlich von der heutigen Unternehmenspraxis überzeugen. Diese Kooperation wurde vom Bundesministerium für Bildung und Forschung (BMBF) im Rahmen des URANOS-Projekts von Juli 2005 bis Juni 2008 unter Nr. 01M3075 gefördert. 194 Diese Evidenz wird unter ökonomischen, organisatorischen und IT-technischen Aspekten gewonnen. Im Folgenden wird in Kapitel 2 kurz der verwendete Ansatz zur Modellierung agiler Workflows skizziert, der in der Literatur [7] im Detail beschrieben ist. In Kapitel 3 werden Aufbau, Durchführung und Bewertung der Fallstudie vorgestellt. Schließlich gibt Kapitel 4 eine Zusammenfassung und einen Ausblick auf das weitere Vorgehen. 2. Methoden zur Modellierung agiler Workflows Workflows sind „die Automatisierung eines Geschäftsprozesses im Ganzen oder in Teilen, wodurch Dokumente, Informationen oder Aufgaben in einer durch Regeln festgelegten Abfolge von einem Bearbeiter zu einem nächsten gereicht werden können“ [15, eigene Übersetzung]. Ein WorkflowManagement-System „definiert, erzeugt und verwaltet die Abarbeitung von Workflows mit Hilfe von Software …, die die Prozessdefinition interpretieren, mit den Workflow-Teilnehmern interagieren und gegebenenfalls Tools und Anwendungen aufrufen kann“ [15, eigene Übersetzung]. Agile Workflows sind Workflows, die zur Laufzeit strukturelle Änderungen erfahren. Unser Ansatz für agile Workflows betrachtet sowohl spontane Änderungen („ad hoc changes“) als auch geplante Modellierungsvorgänge („late modeling“). Abbildung 1: Ausschnitt einer Workflow-Definition für die Chipentwicklung. Abbildung 1 zeigt einen Ausschnitt aus unserem prototypischen Modellierungswerkzeug. Dort ist ein Teil eines UML Aktivitäts-Diagrammes zu sehen [11], das eine Workflow-Definition für die Chipentwicklung graphisch darstellt. Die Workflow-Definition fungiert als Vorlage für WorkflowInstanzen, die ein konkretes Chipentwicklungs-Projekt unterstützen. In dem Workflow-Ausschnitt in Abbildung 1 folgen nach den Aktivitäten für die Projektplanung („Project planning“) und die Spezifikation der Kundenanforderungen („Customer requirement specification“) dann die Aktivitäten zur Entwicklung der einzelnen Chipbausteine („design units“) parallel zu der Integration dieser Bausteine auf oberster Ebene des Entwicklungsprojekts („Top-level project execution“). Ein „Placeholder Task“ ist ein Platzhalter für einen Sub-Workflow, das heißt eine Referenz auf eine andere Workflow-Instanz. Das Gabel-Symbol steht für die Bündelung mehrerer Aktivitäten in einer Gruppe, z.B. in der Gruppe „Design flow“. Da ein Design Flow mehrere tausend Aktivitäten beinhalten kann, ist diese hierarchische Darstellungsweise unumgänglich. 195 Abbildung 2: Ausschnitt der laufenden Workflow-Instanz für das Beispielprojekt MARVIN, die von der Workflow-Definition in Abbildung 1 abgeleitet und erweitert wurde. Die Bezeichnung „Dummy design unit“ in Abbildung 1 deutet schon an, dass es sich um ein Beispiel für einen geplanten Modellierungsvorgang handelt. Abbildung 2 zeigt die Ergebnisse der Nachmodellierung an der Workflow-Instanz für das Beispiel-Chipentwicklungsprojekt MARVIN (Megapixel Camera Interface DesignObjectTM, siehe auch Kapitel 3). Erst bei Ausführung der Aktivität „Project planning“ wird festgelegt, aus welchen Bausteinen der Chip tatsächlich bestehen soll. Folglich kann auch erst dann die weitere Struktur des Workflows modelliert werden. In MARVIN geschieht dies durch Einführung von acht Sub-Workflows für die Design units, die alle von derselben Workflow-Definition für Design units abgeleitet werden. Typische, spontane Änderungen sind zum Beispiel Änderungen der Reihenfolge von Aktivitäten oder das Einfügen zusätzlicher Aktivitäten zur Laufzeit. Die Sprache zur Modellierung agiler Workflows ist in unserem Ansatz bewusst einfach gehalten. Sie orientiert sich an den Workflow-Pattern von van der Aalst et al. [13] mit den fünf grundlegenden Kontrollfluss-Elementen Sequenz, AND-split, AND-join, XOR-split, XOR-join und mit Schleifen. Die Schleifen sind strukturierte Zyklen mit genau einem Eintrittspunkt, nämlich dem Kontrollfluss-Element Loop-join, und genau einem Austrittspunkt, nämlich dem KontrollflussElement Loop-split. Diese weit verbreiteten Sprachkonzepte wurden um zwei eigene KontrollflussElemente ergänzt, die der Agilität der Workflows Rechnung tragen: den Stoppschildern und den oben bereits beschriebenen Platzhaltern für Sub-Workflows. Stoppschilder ermöglichen Modellierungsarbeiten an einer (großen) Workflow-Instanz, während die Abarbeitung der Instanz an anderen Stellen weiterlaufen kann. Sie halten den Kontrollfluss an einer einzelnen Stelle des 196 Workflows auf, hinter der dann unbehelligt modelliert werden kann. Detailliertere Angaben zur Modellierungssprache und zur prototypischen Implementierung des Workflow-ManagementSystems finden sich in der Literatur [7,6]. 3. Aufbau, Durchführung und Ergebnisse der Fallstudie Die Anwendung der im vorigen Kapitel beschriebenen agilen Workflow-Technologie auf ein echtes Chipentwicklungsprojekt war Gegenstand einer Fallstudie beim Chiphersteller Silicon Image. Dabei wurden folgende Punkte untersucht: − − − − − Mächtigkeit und Flexibilität der Modellierungssprache Nutzeffekte für den Koordinationsaufwand im Chipentwicklungsprojekt Integration in die bestehenden Geschäftsprozesse der Firma Nutzeffekte für das Qualitätsmanagement Nutzeffekte für die intra- und interorganisationalen Geschäftsprozesse. Die Untersuchung der Modellierungssprache bildete den IT-technischen Aspekt der Studie. Sie untergliederte sich einerseits in die Frage, ob die Sprachkonzepte ausreichend mächtig waren, um ein reales Chipentwicklungsprojekt abbilden zu können. Andererseits spielte die Flexibilität des Ansatzes eine große Rolle, nämlich die Frage ob alle auftretenden Änderungswünsche durch die vorgesehenen Methoden zur Modifikation von laufenden Workflows abgedeckt werden konnten. Beim ökonomischen Aspekt der Studie war vor allem eine potenzielle Senkung des Koordinationsaufwands mit Hilfe der agilen Workflow-Technologie von Interesse. Bei den letzten drei Punkten, nämlich bei der Integration in die Geschäftsprozesse der Firma und bei den Nutzeffekten für Qualitätsmanagement und Geschäftsprozesse wurden vor allem die organisatorischen Potenziale der Agilen Workflow-Technologie beleuchtet. Das Chipentwicklungsprojekt, das im Mittelpunkt der Fallstudie stand, gehört zu einem langjährig erfolgreichen Produkt der Firma Silicon Image namens MARVIN (Megapixel Camera Interface DesignObjectTM ). Dabei handelt es sich um eine Kameraschnittstelle für Video- und Bilddaten mit einer Auflösung von bis zu 12,6 Megapixeln. Die Chips, die nach diesem Design fabriziert werden, werden in hohen Stückzahlen zum Beispiel für Mobiltelefone verkauft. Es sind mehrere Varianten des Chipdesigns mit unterschiedlichen Auflösungen auf dem Markt (MARVIN-3MP, MARVIN5MP, MARVIN-12MP). Die Chipentwickler von Silicon Image bekommen immer wieder die Aufgabe, MARVIN an neue Auflösungen anzupassen. Neben den höheren Auflösungen für leistungsfähigere Produkte werden auch oft niedrigere Auflösungen gewünscht, um die Produkte preiswerter oder kleiner zu machen. Die Fallstudie wurde im Rahmen eines solchen, typischen Anpassungsprojekts mit einer Dauer von etwa zwölf Monaten durchgeführt. Fünf Chipentwickler arbeiteten mit einem Teil ihrer Arbeitszeit am Projekt, so dass ein Gesamtaufwand von etwa drei Personal-Monaten für die MARVIN-Anpassung entstand. Für den ersten Untersuchungsgegenstand der Fallstudie, die Modellierungssprache, wurde der ursprünglich geplante Design Flow für die MARVIN-Anpassung sowie die strukturellen Änderungen des Design Flows während der Ausführung der Entwicklungsarbeiten mit dem Workflow-Management-System modelliert und ausgeführt. Es traten während der Laufzeit des Projekts sieben Änderungsgesuche („change requests“) auf. Beispielsweise stellte sich während eines Durchlaufs der Validierungs-Software heraus, dass eine Nachschlagetabelle („look-up table“) zu klein konzipiert worden war. Die vom Kunden bereitgestellten Testdaten benötigten eine größere Tabelle als vorgesehen. Die Validierung geschieht normalerweise erst relativ spät im 197 Design Flow, nämlich wenn für jede Design Unit Ergebnisse erster Probesynthesen5 vorliegen. Änderungen zu diesem späten Zeitpunkt sind meist problematisch. Im vorliegenden Fall mussten die noch laufenden Entwicklungsarbeiten zur Verfeinerung einzelner Design Units mit der angestrebten Vergrößerung der besagten Tabelle in Einklang gebracht werden. Die Koordination der zusätzlichen und der alten Aufgaben wurde mit Hilfe der agilen Workflow-Technologie bewerkstelligt. Dies beinhaltete natürlich auch strukturelle Veränderungen am laufenden Design Flow. In ganz ähnlicher Weise wurde für die Berücksichtigung der sechs anderen change requests gesorgt. Nach Ablauf des Beispiel-Projekts wurden in einem Fragebogen Antworten auf die ökonomischen und organisatorischen Fragen der Fallstudie erhoben. 100 90 80 70 60 50 40 30 20 10 0 1 2 3 4 Change-Request-Nr. 5 Abdeckung durch Sprache in % Abdeckung durch System in % 6 7 Abbildung 3: Anpassbarkeit der Workflows bei Change Requests. Die Ergebnisse des praktischen Teils der Fallstudie waren die Folgenden: Die Mächtigkeit der Modellierungssprache war geeignet um den initialen Design Flow von MARVIN abzubilden. Die Flexibilität der Modellierungssprache war mit leichten Einschränkungen ausreichend, um den Design Flow in Folge von change requests strukturell anzupassen. Abbildung 3 zeigt, dass in zwei von sieben Fällen die Modellierungssprache zwar geeignete Konzepte enthielt, um die Design Flows mit hundertprozentiger Abdeckung des change requests anzupassen, es aber leichte Probleme mit der prototypischen Implementierung gab. Bei Change Request 6 hatte das grafische Modellierungstool Schwierigkeiten, die zweite Iteration einer loop-Schleife korrekt darzustellen, so dass sie nicht wie gewünscht modifiziert werden konnte. Bei Change Request 7 trat ein Modellierungsfehler in der Workflow-Definition zu Tage: Eine fehlende Loop-Schleife führte dazu, dass ein Teil des Workflows kopiert werden musste statt dass er einfach in einer zweiten 5 Mit Synthese bezeichnet man die Transformation einer logischen Beschreibung eines Chipdesigns in eine strukturelle Beschreibung, zum Beispiel in ein sogenanntes Chiplayout, in dem schon die Platzierung von Gattern spezifiziert ist. 198 Schleifeniteration wiederholt werden konnte. Dies stellte sich als umständliche Aufgabe heraus, da das Modellierungstool das Kopieren und Einfügen noch nicht unterstützt. Keiner der sieben Change Requests hätte mit den kommerziellen Workflow-Systemen, die in der Einleitung erwähnt wurden, behandelt werden können. Die Ergebnisse der Expertenbefragung im Anschluss an den praktischen Teil der Fallstudie waren zusammengefasst die Folgenden: − Modellierungssprache: Die Experten bestätigten die grundsätzliche Eignung der Modellierungssprache und der prototypischen Implementierung des WorkflowManagement-Systems für die Unterstützung von Design Flows. Sie kritisierten allerdings die Unausgereiftheit der Implementierung bezüglich unerwarteter Loop-Schleifen. Diese Kritik ist im Einklang mit der Beobachtung im praktischen Teil, dass das System noch keine Unterstützung von Kopieren und Einfügen bietet. Das nachträgliche Einfügen von LoopSchleifen in die Vergangenheit ist nicht erstrebenswert, da dies die ansonsten streng beachtete Grundregel verletzen würde, dass die Vergangenheit nicht modifiziert werden darf. Dies würde zwar nur ein Einfügen eines zusätzlichen Kontrollfluss-Elementes (Loopjoin) in die Vergangenheit bedeuten und inhaltlich nichts verändern, könnte aber zu Diskussionen über den Einsatz des Systems zu Zwecken der Dokumentation für das Qualitätsmanagement führen. Eine benutzerfreundliche Kopierunterstützung scheint derzeit eine bessere Lösung zu bieten. − Koordinationsaufwand: Die Experten schätzten den Aufwand für Koordination der Aktivitäten in Chipentwicklungsprojekten auf durchschnittlich 10 bis 20 % der insgesamt aufgebrachten Arbeitszeit. Einsparpotenzial durch agile Workflow-Technologie wurde vor allem für große Teams mit über fünfzig Mitarbeitern und für die Einarbeitung neuer Mitarbeiter gesehen. Davon verspricht man sich eine erhöhte Produktivität. − Integration in Geschäftsprozesse: Die Integration der Agilen Workflow-Technologie in die Geschäftsprozesse der Firma wurde als mittelgut bewertet. Die Planungsprozesse wurden positiv hervorgehoben. − Qualitätsmanagement: Es wurde ein positiver Einfluss von Agiler Workflow-Technologie auf das Qualitätsmanagement erwartet. − Intra- und interorganisationale Geschäftsprozesse: Es wurden keine Veränderungen der bestehenden intraorganisationalen Prozesse durch die Einführung Agiler WorkflowTechnologie erwartet. Als Begründung wurde unter anderem angeführt, dass die Prozesse schon sehr optimal sind. Für die interorganisationalen Prozesse wurden Verbesserungen bei der Abstimmung mit anderen Firmen erwartet. Zum Beispiel übernehmen langjährige Kunden oft einen Teil der Entwicklungsarbeiten. In solchen Fällen wird eine Stärkung der Kundenbindung durch die Agile Workflow-Technologie und damit eine verbesserte Marktposition erwartet. Insgesamt hat die Expertenbefragung mit kleineren Abstrichen also eine positive Bewertung der Agilen Workflow-Technologie erbracht. Die Chipexperten sahen einige potentielle Nutzeffekte, bewerteten die technische Umsetzung aber noch als zu unreif, um die sehr dynamischen Entwicklungsprozesse problemlos damit unterstützen zu können. 4. Zusammenfassung und weiteres Vorgehen In der vorliegenden Fallstudie wurde die Anwendung Agiler Workflow-Technologie auf ein Chipentwicklungsprojekt der Firma Silicon Image untersucht. Agile Workflow-Technologie ist eine Weiterentwicklung herkömmlicher Workflow-Technologie, die Änderungen der Workflows zur Laufzeit erlaubt. Die Fallstudie erbrachte ein positives Beispiel für die Frage der 199 branchenspezifischen Anwendbarkeit von Agiler Workflow-Technologie in der Chipindustrie. Außerdem wurden wertvolle Hinweise für die Gestaltung neuer Methoden und Tools der Agilen Workflow-Technologie gewonnen. Um dem Ziel eines branchenübergreifenden Ansatzes näher zu kommen, ist im weiteren Vorgehen eine Anwendung der Agilen Workflow-Technologie auch in anderen Branchen und Domänen vorgesehen. Daneben ist geplant, die Integration der agilen Technologie mit dem BPEL Standard weiter zu betreiben, um ein serviceorientiertes Geschäftsprozessmanagement durch Agile Workflow-Technologie breiter zu unterstützen [5]. Außerdem soll der Ansatz um neue Methoden und Tools zur Wiederverwendung von Prozesswissen erweitert werden. Erste Ideen dazu sind in der Literatur [7] bereits formuliert. Unsere Vision für die Zukunft ist eine automatische Wiederverwendung von Prozesswissen, so dass die Anpassung von Workflow-Instanzen auf der Basis von Erfahrungswissen weitgehend automatisiert werden kann. Die guten Ergebnisse der Fallstudie sind ein wichtiger Schritt auf dem Weg zu einer kommerziellen Entwicklung eines agilen Workflow-Management-Systems mit den oben beschriebenen Konzepten und Methoden. Die Betrachtung IT-technischer, ökonomischer und organisatorischer Aspekte in der Studie liefert einen Beitrag zur Wirtschaftsinformatik als Mittlerin zwischen IT und Management. 5. Danksagung Die Autoren danken den Chipexperten Marko Höpken, Frank Recoullé und Stefan Pipereit (alle Silicon Image) ganz herzlich für die Unterstützung bei dieser Forschungsarbeit. Auch dem Bundesministerium für Bildung und Forschung (BMBF) gilt der Dank der Autoren für die Förderung des URANOS-Projekts unter der Nr. 01M3075. 6. Literatur [1] HEINRICH, L., HEINZL, A., & ROITHMAYR, F., Wirtschaftsinformatik-Lexikon, 7., vollständig überarbeitete und erweiterte Auflage, R. Oldenbourg Verlag, München, Wien, 2004. [2] IBM, WebSphere Business Services Fabric, 2008, http://www-306.ibm.com/software/integration/wbsf/, Stand: 12. November 2008. [3] JANSEN, D., Einführung, in: D. Jansen (Hrsg.), Handbuch der Electronic Design Automation, Carl Hanser Verlag, München, 2001. [4] MICROSOFT, Microsoft Biztalk Server Roadmap, 2008, http://www.microsoft.com/biztalk/en/us/roadmap.aspx, Stand: 12. November 2008. [5] MINOR, M., SCHMALEN, D., & BERGMANN R., XML-based Representation of Agile Workflows, in: M. Bichler, T. Hess, H. Krcmar, U. Lechner, F. Matthes, A. Picot, B. Speitkamp, & P. Wolf (Hrsg.), Multikonferenz Wirtschaftsinformatik 2008, pp 439-440, 2008, GITO-Verlag Berlin. [6] MINOR, M., SCHMALEN, D., WEIDLICH, J., & KOLDEHOFF, A., Introspection into an agile workflow engine for long-term processes, in: Proceedings of WETICE 2008, im Druck. [7] MINOR, M., TARTAKOVSKI, A., SCHMALEN, D., & BERGMANN, R., Agile Workflow Technology and Case-Based Change Reuse for Long-Term Processes, International Journal of Intelligent Information Technologies, 4(1), pp.80-98, 2008. 200 [8] Object Management Group, Business Process Modeling Notation http://www.bpmn.org/Documents/BPMN%201-1%20Specification.pdf, Stand: 28. Juli 2008. V1.1, 2008, [9] Organization for the Advancement of Structured Information Standards, Web Services Business Process Execution Language Version 2.0 Standard, 2007, http://docs.oasis-open.org/wsbpel/2.0/OS/wsbpel-v2.0-OS.pdf, Stand: 28. Juli 2008. [10] SAP, SAP Netweaver: Ideen sofort in die Tat http://www.sap.com/germany/plattform/netweaver/index.epx, Stand: 12. November 2008. umsetzen, 2008, [11] STÖRRLE, H., UML 2 für Studenten, Pearson Studium Verlag, München, 2005. [12] UNGER, T., & BAUER, T., Towards a Standardized Task Management, in: M. Bichler, T. Hess, H. Krcmar, U. Lechner, F. Matthes, A. Picot, B. Speitkamp, & P. Wolf (Hrsg.), Multikonferenz Wirtschaftsinformatik 2008, pp. 443444, 2008, GITO-Verlag Berlin. [13] VAN DER AALST, W. M. P.; TER HOFSTEDE, A. H. M.; KIEPUSZEWSKI, B.; BARROS, A. P.: Workflow patterns, Distributed and Parallel Databases, 14, 2003, pp. 5 – 51. [14] WEBER, B., & WILD, W, Towards the agile management of business processes. in: K. D. Althoff, A. Dengel, R. Bergmann, M. Nick, & T. Roth-Berghofer (Eds.), Professional knowledge management, Third Biennial Conference, WM 2005, Kaiserslautern, Germany, Revised Selected Papers, LNCS 3782, Springer, 2005, pp. 409-419. [15] WORKFLOW MANAGEMENT COALITION, Glossary http://www.wfmc.org/standards/docs/TC-1011_term_glossary_v3.pdf, Stand: 23. Mai 2007. 201 & Terminology. REDUCING THE VARIATIONS IN INTRA- AND INTERORGANIZATIONAL BUSINESS PROCESS MODELING – AN EMPIRICAL EVALUATION Dominic Breuker, Daniel Pfeiffer, Jörg Becker1 Abstract The objective of this paper is to evaluate the semantic building block-based approach as a means for intra- and interorganizational business process modeling. It is described whether and why the semantic building block-based approach reduces the variations in distributed modeling projects in comparison to traditional modeling approaches. Our argumentation is grounded on the assumption that the specification of a service-oriented architecture (SOA) requires a detailed understanding of the intra- and interorganizational business processes. In order to enable the collaboration of services the underlying process structure must be explicated. In a laboratory experiment the variations of distributed process modeling in the traditional and the building block-based approach have been compared. It could be shown that the semantic building block-based approach leads to considerably fewer variations and, thus, to a more consistent view on the intra- and interorganizational process landscape. 1. Introduction The implementation of a service-oriented architecture (SOA) requires in-depth knowledge about the underlying business processes. The identification of appropriate services and the collaboration of these services within an organization and across organizational borders presuppose a detailed process documentation. In order to collect this process information it is not sufficient to acquire single, independent processes. Rather, it is necessary to create clarity about the process landscape of an organization and its environment [3]. Therefore, modeling projects in a SOA-context are distributed with respect to personnel, location as well as time and can involve multiple organizations. Traditional business process modeling languages and methods disregard important aspects of intraand interorganizational business process modeling. Languages such as Event Driven Process Chains (EPC), Business Process Modeling Notation (BPMN), or IDEF3 do not explicitly address the issues of distributed, cross-organizational process modeling. Variations such as a deviating terminology, a varying grade of abstraction, or a different understanding of the scope of a process are not considered in the languages. The semantic building block-based approach has been 1 European Research Center for Information Systems, Leonardo-Campus 3; 48149 Münster, Germany. 203 developed to collect a large number of processes in different organizations [15]. It has been designed to minimize the variations that can occur when multiple modelers are involved. The objective of this paper is to provide empirical evidence that the semantic building block-based approach considerably reduces the variations of distributed business process modeling. The rationale behind this behavior is explained and empirically tested in a laboratory experiment. The paper proceeds as follows: In the next section the different variations within and between business process models are described that can emerge in distributed modeling projects. In the following section of this paper the fundamental characteristics of the semantic building block-based approach are discussed. The specific structure of this approach is confronted with the properties of traditional modeling languages. Subsequently, the semantic building block-based approach is evaluated in a laboratory experiment. The distributed modeling conflicts that can emerge in the building block-based approach are compared to the traditional approach. The paper closes with a short summary of the main results and an outlook to future research. 2. Variations in Intra- and Interorganizational Business Process Modeling The comparability of business process models (BPM) is an important quality criterion. In order to improve the operational efficiency of a company or public administration, BPMs are employed to suit the organizational structure to the process flow. The business processes of an organization or a value network must be analyzed in whole to get a coherent overview on the interactions between individual factors. For instance, an analysis might include questions such as: Does the process comply with the quality regulations of the organization? Are there any substantial weaknesses in the process? Is a service in two different organizations performed by the same process? How much money could be saved through the introduction of a Document Management System? As the answer to these questions usually leads to high costs, the effort needed to conduct it must be reduced. This can be achieved by creating comparable BPMs, i.e. models with a relatively small number of variations. A real world phenomenon can be represented through BPMs in many different ways. BPMs are constructed by using two different languages. The first one is the modeling language. Its meaning is at least semi-formally specified, which makes this part of a process model unambiguous. The other component of a BPM consists of a domain language. It is used to make statements about real world phenomena. In order to create a BPM, both languages must be applied together. Domain languages are owned by a linguistic community that decides on the meaning of its statements by shared conventions, which have been established implicitly by using the language. Because of the ambiguity of such natural languages it is possible to express the same meaning by different combinations of constructs and domain statements. Variations in BPMs arise from both, differing perceptions of reality and from the process of explicating this perception. A variation is a semantic or syntactic deviation between different BPMs which refer to the same or a similar real world phenomenon. They can be due to two different reasons [20]. • Variations due to varying mental representations: The mental representations of two model creators are most likely not exactly the same. This means the model creators perceive or structure real world phenomena differently. Likewise, they can, consciously or unconsciously, consider deviating aspects of the phenomenon as relevant. This can lead to BPMs at diverse levels of abstraction. Likewise, in these models the sequence of activities can vary or the model elements can be annotated with a different number of details. 204 • Variations due to the explication: Even when the model creators share “the same” mental representation variations can arise. These variations result from a different explication of the mental representations. Domain and modeling languages offer certain degrees of freedom to express a given fact. Model creators can utilize this freedom in diverse ways. For example, different domain statements can be chosen to express a specific aspect of the mental representation. Similarly, a model creator may have the choice between multiple constructs to describe a given fact. Thus even with an equivalent mental representation, different BPMs with corresponding conflicts can emerge. Deviations between models have been investigated empirically especially in the context of structural models. UML Class Diagrams have been analyzed in multiple modeling experiments [e.g., 9]. Other empirical studies have focused mainly on the advantages of specific constructs in comparison to alternative forms of representation, such as entity types and attributes [18], properties of relations [6], optional properties [5], or whole-part relations [19]. There are only a very few empirical studies that refer to variations in process models. Mendling et al. [12], for example, have analyzed the SAP Reference Model to identify errors and inconsistencies. Gruhn and Laue [8] have investigated the role of OR-connectors in EPC models. Beneath these empirical studies, conflicts between models have theoretically been discussed in the database schema matching and integration literature [e.g., 1], in publications about metamodeling [e.g., 16], and ontology engineering [7]. In this paper we draw upon Pfeiffer [15] who has derived a comprehensive theoretical analysis of the variations in the context of business process modeling. This encompasses type variations, occurring when two model elements of different types have the same meaning, synonym variations, occurring when the labels of two model elements with the same meaning differ, homonym variations, occurring when two model elements with different meaning have the same label, abstraction conflicts, occurring when model elements in two different model have a deviating level of abstraction, control flow variations, occurring when the number of control flows of two corresponding model elements differ, annotation variations, occurring when corresponding model elements in two different models have a different number of annotated model elements, order variations, occurring when the order of two model elements is permuted between two BPM, and separation variations, occurring when a model element has no corresponding model element in the second model with the same, a more specific or a more general meaning. 3. Traditional and Semantic Building Block-based Process Modeling The application of traditional business process modeling languages leads to business process models that are hard to compare. Every model created with a traditional language can include many of the variations described in the previous section of this paper. For instance, an EPC basically consist of events and functions, whose semantics are essentially defined by the domain statement the modeler assigns to it [10]. Only by applying various rules and modeling conventions, comparability between the BPMs can be achieved. The creation as well as the implementation of such regulations within a specific modeling project involves significant efforts. By using a business process modeling language which belongs to the semantic building blockbased approach, the comparability of the resulting business process models can be significantly improved. These semantic building block-based languages (SBBL) achieve this advantage by avoiding the conflicts that occur when traditional modeling languages are used [14]. The semantic building block-based approach guides the modeler through the modeling process and restricts him in his decisions. By decreasing the choices a model creator can make during the model construction, the comparability of the BPMs can be increased [15]. 205 The main modeling construct of the language class SBBL is the so called process building block (PBB). PBBs limit the degree of freedom within the process of model creation. Unlike traditional business process modeling languages the SBBLs employ PBB as their most important modeling constructs. Every PBB represents one or more reoccurring activities from a particular domain [11]. The difference between a PBB and a modeling construct from a traditional language is that the PBB already incorporates a domain statement. Modelers do not create and assign a domain statement to a construct, they can only choose from a given set of PBBs and, thereby, from a given pool of statements. Thus, the PBB are semantically specified and have a defined level of abstraction [17]. If additional information is needed, the PBB can be further described by a predefined set of attributes. Concerning their semantics, the PBB are unambiguously and mutually exclusively defined. To specify the constructs of a SBBL, a domain ontology is used. Every PBB stands for a set of elements taken from this ontology. Hence, the meaning of a PBB is explicitly defined. With the aid of the ontology, it is possible to ensure that no element of a SBBL contains semantics already covered by another element of this language. Given a real world phenomenon, there exists only a single possibility to represent it in a SBBL-based language. In ideal, every construct would be derived from the domain ontology, but from a practical perspective it is often necessary to include at least some constructs from other languages. For instance, this could be a construct to split up and join the control flow. Imagine that the ontology element ‘encash/receive a payment’ has been incorporated into a SBBL as a PBB. Also its corresponding attribute, ‘Information System’, is taken from the domain ontology. This encompasses not only the attributes themselves, but also their possible values. In the given example, the attribute ‘Information System’ may have only three allowed values: ‘Open Office’, ‘MS Office’ and ‘MS Money’. The available labels for the PBB, which specify the domain task more detailed, are defined in the same manner. For the PBB ‘encash/receive a payment’, the labels ’encash/receive a cash payment’, ‘encash/receive a credit card payment’, and ‘encash/receive a money transfer’ might be allowed. Languages from the class SBBL either avoid or at least decrease the previously described variations between BPMs. By using the semantic building block-based approach, some types of variations between models can be fully eliminated. Other variations can still occur, but their frequency can be significantly reduced. In the following the impact of the language class SBBL is discussed with regard to the five variation types considered: • Synonym variations: Because of the fact that the constructs of languages from the class SBBL are derived from an ontology, they offer a controlled vocabulary to the modeler. Synonyms can be detected in the ontology, which makes it possible to eliminate them in advance of the model creation. Hence, as long as the modeler can only choose from the given vocabulary of a SBBL, no synonym variations can occur. • Type variations: During the language construction, it is ensured that no semantically overlapping modeling constructs are included in the SBBL. If every PBB and every attribute of the language is semantically disjoint, it can be proven that no type variation can occur [14]. For every observable real world phenomenon only one single constructs exists which is able to represent it within the language. Therefore, every modeler who wants to describe the phenomenon is forced to use same construct. • Abstraction variations: The type in combination with the label defines the semantics of a PBB. Because every PBB is semantically disjoint from the others, every modeler has to choose the same PBB to express a specific matter. Thus, the number of possible choices for the selection of domain statements and, thereby, also the number of abstraction variations is 206 reduced. To completely avoid them, a specific level of the ontology has to be defined from which all the domain statements of a model have to originate. • Separation variations: This type of variation cannot be entirely removed from models created with the language class SBBL. Nevertheless, it can be at least reduced because during model construction the modeler is guided by the ontology-based PBBs he can choose from. With the meaning of the PBBs in mind, he focuses on the semantics covered by them. Therefore, the models better fit to each other concerning the semantics they express. • Order variations: Just like the separation variations, this type of variation cannot be completely avoided. In traditional modeling languages, it is hardly feasible to make any statements about the correct order of specific elements on the basis of their type. In contrast to that, the semantic building block-based approach allows to define heuristic order rules based upon the predefined semantics of the PBBs. For example, it is reasonable that the activity ‘approve’ always follows the activity ‘perform a formal verification’. The creation of languages from the class SBBL can only be accomplished successfully with a specific domain in mind. In order to be able to express every real world phenomenon by using a modeling language of this type, it is necessary to restrict the application to a specific domain. Otherwise, no appropriate ontology can be created due to the complexity of the real world. Hence, languages from the class SBBL are domain specific languages. A well documented example for such a language is the PICTURE-language, which is specifically designed for public administrations [2]. It consists of 24 PBB and over 50 attributes. The PBBs in PICTURE can only be connected in a sequential form. For an in-depth description of the language, we refer to [2]. A detailed analysis of the expressiveness can be found in [4]. 4. Evaluation of Semantic Building Block-based Process Modeling The hypothesis to evaluate is that modeling with a semantic building block-based language results in a smaller number of variation compared to traditional modeling languages. In order to do this, an empirical evaluation was conducted. EPC was chosen as an example of a traditional modeling language, PICTURE as an example for a domain specific one. Within a laboratory experiment, twelve graduate students from the University of Muenster were asked to create an EPC and a PICTURE model independently from each other based on a given case description taken from the domain of public administrations. This case description was used to examine the variability between BPMs in both languages. This experimental setup simulates the process of distributed modeling and facilitates the validity of the analysis for two reasons. Firstly, all participants are modeling the same situation, which eliminates the case description as a source of variability. Secondly, every participant creates both an EPC and a PICTURE model. Thus, all variations resulting from a different understanding of the case description or from deviating opinions about the adequate degree of detail or abstraction influence the modeling process of both languages in the same way. The remaining variations can be fully explained by the process of explicating the mental representations of a participant in the form of a process model. The analysis has been carried out in two steps: • Automated analysis: In the first step, both EPC and PICTURE models are tested for similarity with an automated comparison algorithm [21]. This algorithm has been designed to quantify the similarity of the process flow as well as to detect and resolve problems resulting from the ambiguities of natural languages. The applicability of the algorithm has been demonstrated empirically by using the SAP Reference Model. 207 • Manual analysis: The second step is, in contrast to the first one, conducted manually to reconfirm the results from the automated comparison. In order to do this, the authors analyzed the BPMs from both groups to find and quantify variations from the types described above. If a high degree of similarity between the two models is found in the automatic analysis then a small number of variations can be expected in the manual analysis. The automated analysis of the models only provides a percentage value of similarity. Because the analysis is conducted manually in the second step, the nature of the variations can be explored in more detail. 4.1. Characteristics of the Automated Analysis The comparison algorithm which has been used to determine the degree of similarity between the BPMs can be used for both PICTURE and EPC models in the same way. This is ensured by the fact that the models themselves are not used for the similarity calculation. Instead, the result is computed by using what is called a causal footprint. A casual footprint can be derived from the BPM. It is a directed graph whose vertices represent the various activities in the process. Vertices are connected by arcs whenever the corresponding activities of the vertices are always performed either before or after one another. In the first case, the arc is called a look-back-link, in the second case it is a look-ahead-link [22]. If, for example, there is an arc connecting the vertices A and B, this means that, depending on the type of the arc, activity A is either always performed before activity B or after it. In order to finally execute the comparison, the causal footprints of the models must be transformed into vectors. Their similarity is then determined by the deviation of their directions. For more details concerning the transformation, we refer to [21]. The comparison algorithm is able to identify ambiguities of natural languages within the labels of the model elements. To calculate the similarity of BPMs, common elements must be identified. Therefore, equivalent vertices need to be identified in order to compare two footprints. Natural languages allow expressing the same real-world concepts in different ways. This hampers the automatic identification of similar or equivalent activities. In order to deal with this problem, the comparison algorithm uses the lexical database WordNet, which allows to detect synonyms [13]. With the aid of this information, the semantic similarity of activities can be computed. Comparing the similarity score of an activity and of all elements connected to it, it is possible to map equivalent activities of different process models [21]. The comparison algorithm determines the similarity of process models regarding their content and their respective process flow. The causal footprint consists of both the vertices representing activities themselves and look-ahead as well as look-back-links, which stand for the procedural relations of the activities. Therefore, the comparison does not only consider the similarity regarding the content, but also takes the process flow into account. 4.2. Results of the Automated Analysis 12 BPMs from each group were compared pair-wise with each other. This resulted in a total of 66 comparisons for each group. Within the group of the EPC models, an average similarity of 0.54% has been measured. The maximum similarity was 4.02%, the minimum was 0%. This means that the comparison algorithm perceived the BPMs as being totally different. In contrast, the PICTURE 208 models achieved an average similarity of 43.75%. Some comparisons resulted in a value of 100%, which means that the models were identical. Other PICTURE models scored lower values as well. The minimum value was 13.99%. Detailed results are described in Figure 1. In this diagram the average similarities of the individual BPMs compared to all other models are depicted. Figure 1-I presents the similarity values for the PICTURE and the EPC group on a single scale, Figure 1-II uses separate scales instead. Figure 1: Average similarity degrees for PICTURE and EPC models 4.3. Characteristics of the Manual Analysis Detailed statements about the nature and the degree of variability between BPMs can only be given manually. A framework, which classifies possible variations between process models into different categories, was introduced in Section 2. To identify these variations in process models, a semantic analysis of BPMs is necessary. Thus, a specific meaning needs to be assigned to every model element according to the modeler’s intention. By this means, an ontology which describes the whole semantic of the case description has been developed. Thereafter, it was possible to assign statements of this ontology to every model element. The intended meaning had to be carefully explored by the authors. With the resulting assignments, the basis for the identification of variations was established. When variations are identified they need to be counted in compliance with strict rules to assure a reasonable quantification of the variability. With the previously given definitions, variations can easily be identified. But the definition alone was not sufficient to generate a meaningful result. A set of rules for quantifying the identified variations had to be developed. They allowed for a consistent and uniform measurement. For example, rules were designed to prevent counting some variations multiple times. Different types of variations were not weighted, because there was no information about the extent to which an individual type of variation influences the comparability of BPMs. With the given experimental setup, a reasonable measurement of homonym, control flow, and annotation variations was not possible. All models were created on the basis of the same case description. This makes the measurement of homonym variations difficult, because they occur when different concepts are expressed by the same terms. This usually happens in complex systems of different BPMs, however, not within a single case. Annotation conflicts were not measureable because no attributes were used within the EPC and only a fixed set of attributes within the PICTURE models. The PICTURE as well as the EPC language has strict rules concerning the 209 incoming and outgoing control flows. In fact, only the AND, OR, and XOR operators from the EPC language allow for deviating numbers of control flows. Hence, no control flow variations were detectable during the analysis. 4.4. Results of the manual analysis Within the variation analysis an average of 31.93 variations between EPC models were identified. An average of 12.59 of these variations were synonym variations, 5.95 were abstraction variations, 10.70 were separation variations, 2.15 were type variations, and 0.53 were order variations. The group of the PICTURE models scored an average value of 4.59 variations. It consists of 0.63 synonym variations, 0.83 abstraction variations, 1.77 separation variations, and 1.32 type variations. Order variations were not fount between PICTURE models. A comparison of the results can be found in Figure 2. Figure 2: Numbers of variations for PICTURE and EPC according to the different variation types 4.5. Discussion of the results The results of the automated similarity calculation are confirmed and further detailed by the manual analysis. While the automatic analysis can hardly find any commonalities between EPC models, it provides very good results for PICTURE models. In compliance with these results, the manual analysis shows a significantly higher number of variations of any kind for EPC models compared to PICTURE models. These results support assumption that the automated analysis is correct and further specify the results by categorizing the variations. The semantics of BPMs that contain natural language elements cannot be captured automatically. The use of ontology-based labels for the PBBs in PICTURE actually results in a massive reduction of synonym variations compared to EPC. Although the algorithm used is build to detect synonyms, the low similarity degrees for EPC models imply that it fails to do so in most of the cases. The avoidance of many synonym variations by PICTURE in parallel with the high similarity degrees indicates that synonym variations cannot be resolved automatically. The degree of detail and abstraction are fixed when using a SBBL-based modeling language. The limitation of the number of choices a modeler can make within the modeling project when he is 210 using a SBBL in fact increased the comparability of the created models. A significant decrease of abstraction and separation variations in the manual analysis supports this conclusion. It remains to be demonstrated that the expressiveness of a SBBL is sufficient. The increased comparability of models created with a SBBL leads to a decreasing expressiveness because of the predefined semantics of the PBBs. It is possible that the modeler is that limited in his decisions that he is not able to represent all relevant real world facts by using the PBBs. Hence, the creation of a SBBL is very time consuming and error prone. This analysis only shows that the language class SBBL produces models with a higher degree of comparability, but it does not take the expressiveness of the models into account. 5. Conclusion The starting point of this paper was the insight that service-oriented thinking presupposes detailed knowledge about the business processes of an organization and its environment. We identified business process modeling as a way to explicate the relevant process knowledge. However, traditional business process modeling languages only provide little support for distributed modeling scenarios. The objective of this paper was to evaluate the semantic building block-based approach for the purpose of interorganizational business process modeling, in particular with respect to semantic variations within and between BPMs. In a laboratory experiment that simulated a distributed modeling project the potential advantages of the language class SBBL have been analyzed. Both an automated and a manual approach were chosen to compare the performance of the two languages EPC and PICTURE. The results of the analysis demonstrate that the type of the language has a strong influence on the number of variations in the resulting BPMs. PICTURE as an example of the language class SBBL considerably decreased the number of variations and, thereby, improved the quality of the corresponding BPMs. However, the number of variations is only one component of the evaluation of the semantic building block-based approach. Furthermore, it is necessary to assess the efficiency and the effectiveness of the resulting languages. Efficiency means that a SBBL-based modeling language is able to acquire a specified number of processes at minimal cost. Effectiveness requires that a language of the class SBBL is expressiveness enough to describe the relevant phenomena of the domain at hand. In other words, effectiveness makes sure that the modeling language can indeed be successfully applied in a given domain. An empirical analysis of these two aspects is open to further research. Acknowledgements The work published in this paper is partly funded by the European Commission through the STREP PICTURE. It does not represent the view of European Commission or the PICTURE consortium and the authors are solely responsible for the paper's content. References [1] BATINI, C., LENZERINI, M., NAVATHE, S. B., A comparative analysis of methodologies for database schema integration. ACM Computing Surveys Vol. 18 (1986), pp. 323-364. [2] BECKER, J., ALGERMISSEN, L., FALK, T., Prozessorientierte Verwaltungsmodernisierung. Springer, Berlin 2007. [3] BECKER, J., ALGERMISSEN, L., FALK, T., PFEIFFER, D., FUCHS, P., Model based identification and measurement of reorganization potential in public administrations: the PICTURE-approach. In: Proceedings of the 10th Pacific Asia Conference on Information Systems (PACIS 2006), 2006, pp. 860-875. 211 [4] BECKER, J., ALGERMISSEN, L., PFEIFFER, D., RÄCKERS, M., Local, participative process modelling: the PICTURE-approach. In: Proceedings of the 1st International Workshop on Management of Business Processes in Government (BPMGOV 2007) at the 5th International Conference on Business Process Management (BPM 2007), 2007, pp. 33-48. [5] BODART, F., PATEL, A., SIM, M., WEBER, R., Should optional properties be used in conceptual modelling: a theory and three empirical tests. Information Systems Research Vol. 12 (2001), pp. 384-405. [6] BURTON-JONES, A., MESO, P., How good are these UML diagrams: an empirical test of the Wand and Weber good decomposition model. In: Proceedings of the 23rd International Conference on Information Systems (ICIS 2002), 2002, pp. 101-114. [7] DAVIS, I., GREEN, P., MILTON, S., ROSEMANN, M., Using meta models for the comparison of ontologies. In: Proceedings of the 8th International Workshop on Evaluation of Modeling Methods in Systems Analysis and Design (EMMSAD 2003) at the 15th International Conference on Advanced Information Systems Engineering (CAiSE 2003), 2003, pp. 1-10. [8] GRUHN, V., LAUE, R., What business process modelers can learn from programmers. Science of Computer Programming Vol. 65 (2007), pp. 4-13. [9] HADAR, I., SOFFER, P., Variations in conceptual modeling: classification and ontological analysis. Journal of the Association for Information Systems Vol. 7 (2006), pp. 568-592. [10] KELLGER, G., NÜTTGENS, M., SCHEER, A.-W., Semantische Prozessmodellierung auf der Grundlage "Ereignisgesteuerter Prozessketten (EPK)". Veröffentlichungen des Instituts für Wirtschaftsinformatik Vol. 89 (1992) [11] LANG, K., GLUNDE, J., BODENDORF, F., A framework for reusable reference process building blocks. ACM SIGGROUP Bulletin Vol. 18 (1997), pp. 68-70. [12] MENDLING, J., MOSER, M., NEUMANN, G., VERBEEK, H. M. W., VAN DONGEN, B. F., VAN DER AALST, W. M. P., Faulty EPCs in the SAP reference model. In: Proceedings of the 4th International Conference Business Process Management (BPM 2006), 2006, pp. 451-457. [13] MILLER, G. A., WordNet: a lexical database for English. Communications of the ACM Vol. 38 (1995), pp. 3941. [14] PFEIFFER, D., Constructing comparable conceptual models with domain specific languages. In: Proceedings of the 15th European Conference on Information Systems (ECIS 2007), 2007, pp. 876-888. [15] PFEIFFER, D., Semantic business process analysis - building block-based construction of automatically analyzable business process models Westfälische Wilhelms-Universität Münster 2008 [16] ROSEMANN, M., ZUR MÜHLEN, M., Evaluation of workflow management systems: a meta model approach. The Australian Journal of Information Systems Vol. 6 (1998), pp. 103-116. [17] RUPPRECHT, C., FUNFFINGER, M., KNUBLAUCH, H., ROSE, T., Capture and dissemination of experience about the construction of engineering processes. In: Proceedings of the 12th International Conference on Advanced Information Systems Engineering (CAiSE 2000), 2000, pp. 294-308. [18] SHANKS, G., NUREDINI, J., TOBIN, D., MOODY, D. L., WEBER, R., Representing things and properties in conceptual modelling: an empirical evaluation. In: Proceedings of the 11th European Conference on Information Systems (ECIS 2003), 2003, pp. 1-17. [19] SHANKS, G., TANSLEY, E., NUREDINI, J., TOBIN, D., WEBER, R., Representing part-whole relationships in conceptual modeling: an empirical evaluation. In: Proceedings of the 23rd International Conference on Information Systems (ICIS 2002), 2002, pp. 89-100. [20] SOFFER, P., HADAR, I., Applying ontology-based rules to conceptual modeling: a reflection on modeling decision making. European Journal of Information Systems Vol. 16 (2007), pp. 599-611. [21] VAN DONGEN, B. F., DIJKMAN, R., MENDLING, J., Measuring similarity between business process models. In: Proceedings of the 20th International Conference on Advanced Information Systems Engineering (CAiSE 2008), 2008 [22] VAN DONGEN, B. F., MENDLING, J., VAN DER AALST, W. M. P., Structural Patterns for Soundness of Business Process Models. In: Proceedings of the Proceedings of the 10th IEEE International Enterprise Distributed Object Computing Conference (EDOC'06), 2006, pp. 116-128. 212 TUPLESPACE-BASED INFRASTRUCTURE FOR DECENTRALIZED ENACTMENT OF BPEL PROCESSES Daniel Wutke, Daniel Martin, Frank Leymann1 Abstract Business processes in WS-BPEL are a manifestation of the two-level-programming paradigm where remote-accessible Web services are composed to potentially complex orchestrations. WSBPEL processes are executed by Workflow Management Systems that navigate through the process' activities and interact with the orchestrated services. While Web service technology enables interactions with remote services, process navigation is typically done in a centralized manner. Especially in scenarios of complex interactions between multiple distributed process participants, this way of process enactment has several drawbacks. In this paper, we outline those drawbacks and propose an alternative approach to execution of BPEL processes in a distributed, decentralized manner. 1. Introduction The Service Oriented Architecture (SOA) [1] is an approach to integrating enterprise applications in a flexible and loosely coupled manner. SOA is built on the notion of services, which are realizations of self-contained business functions and provide a service requester with an abstract view on business functions. An important aspect of SOA is service composition, in this context also referred to as service orchestration. The Web Service Business Process Execution Language (WS-BPEL or BPEL for short) [4] is the de-facto standard for describing workflow-like orchestrations of Web services. Following the twolevel-programming paradigm [5], compound services, i.e. business functions, are composed to new composite applications which then again can be exposed as services to facilitate further composition. BPEL offers a range of activities comprising (i) activities for defining process control flow (e.g. sequence, flow, switch, while), (ii) activities describing interaction with Web services (e.g. invoke, receive, pick, …), and (iii) activities that provide the necessary glue between activities (e.g. assign). In addition, BPEL defines the concept of variables for storing process-internal data such as intermediate processing results on a per-instance basis. To enable process execution, a BPEL process model, once created, is deployed to a Workflow Management System (WfMS); in case of BPEL, the WfMS exposes the process to potential users after process deployment through a Web service interface. Triggered by incoming user requests that match the conditions defined in the process model, processes are instantiated and their execution is started which comprises continuous 1 Institute of Architecture of Application Systems, University of Stuttgart, Germany 213 evaluation of process control flow and execution of activity implementations. Process execution in BPEL is control-flow driven; process control flow is defined through so-called structured activities which, similar to control constructs known from other programming languages, define the order of activity execution or the flow of the program. As of today, process control flow is typically evaluated by the navigator component of a centralized WfMS. The term centralized refers to the workflow engine conceptually being regarded as one single entity. Note that while it is possible to provide an implementation of a WfMS that can be distributed among a number of nodes in a clustered environment [6], the general assumption still is that the clustered nodes operate within the same administrative domain, for instance the same department of an enterprise. During evaluation of process control flow, the navigator component of the WfMS decides based on the current state of a process instance which BPEL activities are to be executed next and starts their execution. This navigation process continues until process instance execution is completed. While structured activities define the order in which activities are executed basic activities reflect pieces of application code that are to be evaluated during process execution; two classes of basic activities can be distinguished according to whether they involve interaction with WfMS-external applications or not. Activities such as assign or wait are provided by the WfMS itself, hence their execution does not require any interaction with WfMS-external entities. Interaction activities, which interact with the actual compound application logic (i.e. the “business functions”) orchestrated by the process such as invoke and receive, trigger an interaction of the WfMS with WfMS-external applications. Since, in case of BPEL, these applications are Web services [2, 3] which can be invoked remotely using potentially various network transport protocols ( enabled through the mechanism of Web service bindings ), BPEL allows for distributed application logic. Hence one can say that the current way of executing BPEL processes relies on centralized (i.e. local) execution of process control flow and distributed application logic through the use of Web service technology. While the aforementioned way of executing BPEL processes is appropriate for a wide range of scenarios, it has severe drawbacks in other scenarios. These are discussed in Section 2 where we motivate our work through an example scenario and a discussion of the benefits resulting from decentralized execution of process control flow. In Section 3, we introduce the proposed approach to decentralized execution of BPEL processes and outline the process model and the system architecture; this comprises a description of (i) the functional building blocks of the system and (ii) how they interact in order to facilitate decentralized process execution. In addition, the supported spectrum of distributed process execution is presented and discussed in detail. Section 4 provides an overview of related work in the area of distributed workflow management systems, process fragmentation and process outsourcing. Section 5 concludes the paper and gives directions for further research. 2. Motivation for Decentralized BPEL Navigation In Figure 1, a common business process scenario is presented. Process participant P1 provides the depicted process model to users through a regular, centralized BPEL engine which is responsible for evaluating process control flow (depicted as drawn through arcs) that defines the order in which the activities (depicted as black filled circles 1,…,6) are executed. Process instance data is stored in variables a and b. Variable access is depicted through dashed arcs; for the examples presented in the paper no distinction is made between read- and write access. Activities 2, 4 and 5 are interaction activities (e.g. invoke activities) that involve remote communication with WfMSexternal Web service implementations provided by process participant P2. Note that the output value a of interaction activity 2 is used as input for interaction activity 4. Suppose that remote Web service interactions between P1 and P2 are relatively expensive due to e.g. low communication channel bandwidth and high latency and suppose furthermore that the data contained in variable a 214 is rather large in size. If the process is executed as depicted in Figure 1 (i.e. following the established model of BPEL process execution through centralized process navigation), each invoke activity results in one remote interaction between P1 and P2. This in turn requires shipping the result of the Web service interaction with P2 through activity 2 back to the process engine at P1 and subsequently passing the same received value again back to P2 as part of the Web service interaction through activity 4. Abbildung 1: Centralized Process Execution Clearly, the traditional BPEL model of centralized process execution and distributed Web service business logic is sub-optimal in the presented scenario, since it requires (i) a high number of remote interactions which might have an impact of the performance of process execution due to e.g. high latency of the communication channel and (ii) unnecessary shipping of potentially large amounts of data between P1 and P2. Abbildung 2: Decentralized Process Execution In Figure 2, the same process model and Web services are presented; however, in this scenario, the execution of the BPEL process itself is split among P1 and P2 by moving the execution of the orchestration of activity implementations 2, 4 and 5 along with variable a from P1 to P2. As a result, after activity 1 has completed successfully, process control flow is passed to activity 2 which is provided by P2. Activities 2, 4, and 5 are then executed by P2, including the involved interactions with the WfMS-external Web services and the WfMS-internal storage of the process instance data in variable a. Since this interaction is done directly at the side of P2 (e.g. within the same local network), impact of communication between WfMS and service on service invocation time is reduced. Note that since there are no additional inter-dependencies between activity 3 and 215 activities 2, 4, 5, activity 3 can run at P1 independently of P2; furthermore, the need for shipping the data of a between P2 and P1 is removed. Once execution of activity 5 has finished, process control flow is passed back from P2 to P1. When both 3 and 5 have completed their execution successfully, the condition for the execution of activity 6 is fulfilled and process execution continues at P1. While the aforementioned example scenario focuses on the performance increase resulting from shifting evaluation of process control flow as close to the actual compound business functions that are orchestrated by the respective process, other reasons can be decision drivers for this approach as well. Process models might be fragmented among a number of participants, for instance different departments of the same company for organizational reasons, or even different companies for the reasons of process outsourcing [7]. 3. System Model and Architecture To counteract the aforementioned drawbacks that result from the traditional model of centralized execution of BPEL process control flow and distributed business functions in form of Web services, we proposed another approach to execution of BPEL processes that allows for arbitrary distribution of process control flow execution among the participants of a process [8]. As discussed in Section 2, the basic goal of the approach is to shift coordination logic (i.e. the evaluation of process control flow) as close to the orchestrated application logic as reasonable. This is achieved through a token passing and sharing technique over remotely accessible, shared and distributed tuplespaces. Tuplespaces have their origin in the Linda coordination language, defined by [9] as a parallel programming extension for traditional programming languages (e.g. C, Prolog) for the purpose of separating coordination logic from program logic. The Linda concept is built on the notion of a tuplespace. A user interacts with the tuplespace by storing and retrieving tuples (i.e. an ordered list of typed fields) via a simple interface: tuples can be (i) stored (using the out operation), (ii) retrieved destructively (in) and (iii) retrieved non-destructively (rd). Tuples are retrieved using a template mechanism, e.g. by providing values of a subset of the typed fields of the tuple to be read (associative addressing). Matching tuples are selected non-deterministically. Also, concurrent destructive reads are non-deterministic, i.e. the receiver of the tuple is chosen randomly. With respect to the degree and dimensions of decoupling they provide, Tuplespaces are conceptually similar to e.g. message-oriented middleware (see [10, 11,12] for comparisons of both technologies). Abbildung 3: Process navigation through token passing The overall approach to BPEL process navigation is depicted in Figure 2. Control flow is represented as control flow (CF) tokens (C1, C2, C3). CF tokens are encoded as tuples and communicated between the activities the process is composed of (depicted as boxes 1, 2, 3, 4) by storing them to and retrieving them from remote-accessible tuplespaces (depicted as circles); note that the term “activity” does not only refer to the Web services that the process orchestrates but also to activities whose implementations are provided by a WfMS itself, e.g. the assign activity. CF 216 tokens comprise information such as identifiers of the process model and process instance the CF token belongs to and the control flow link that the token represents. Negative process control flow, i.e. errors occurring during activity executions, is propagated between activities through so-called dead path (DP) tokens that are analogous to CF tokens in structure. DP tokens are necessary to facilitate dead path elimination [4]. A more detailed description of the Petri net-based process model is available in [8,25]. Activity implementations are realized as tuplespace clients waiting for their starting condition being fulfilled; in the remainder of the paper, activity implementations are also referred to as activity clients. The starting condition of an activity is expressed by the activity client through (i) templates describing the CF or DP tokens produced by its predecessor activity (or activities in case of activities that join multiple concurrent execution paths) and (ii) identifiers of the tuplespaces the corresponding tokens are to be consumed from. In Figure 2, CF token consumption operations are depicted as incoming arcs of an activity implementation. Note that these consumption operations are always synchronizing, i.e. they block until all input tokens are available and can be consumed by the respective activity client. Once the starting condition of an activity client is fulfilled, the CF or DP tokens are destructively consumed by the respective activity client and the corresponding application logic of the activity is executed. For activity executions most activity implementations require access to process instance data, i.e. variables; in the proposed model, process instance data is represented as a certain token type, called DATA token, that associates a certain variable of an instance of a particular process model with a value. If necessary, process instance data is consumed non-destructively or updated by the activity client during its execution (depicted as dashed incoming arcs of an activity client). Once the execution of a client’s application logic has finished, corresponding CF, DP or DATA tokens are produced (in case of CF and DP) or updated (in case of DATA) depending on success or failure of activity execution; the produced tokens are stored in the tuplespace(s) the subsequent activity clients monitor for control flow tokens (depicted as outgoing arcs of activity clients). As one can see from the aforementioned high-level description of the proposed model, tuplespaces are used as buffers for any kind of data that is communicated between the entities participating in process execution; this comprises both tuples representing process control flow (communicated via token passing) and tuples representing process instance data (communicated via token sharing). A number of reasons motivate choosing the tuplespaces as communication paradigm and platform underlying the presented approach; these are outlined in the following. Tuplespaces have a clearly defined interface that is characterized by a number of unique features not found in alternative communication middleware such as e.g. messaging technology [13]. This interface supports operations for destructive consumption of tuples, necessary for consumption of control flow tokens, and operations for non-destructive consumption of data tuples. Furthermore, tuplespaces can be associated with Uniform Resource Identifiers (URI) [14] for unique identification of tuplespaces. Using a naming service, a URI can be mapped to a Uniform Resource Locator (URL) [15] which reflects the physical address of the machine that provides the tuplespace. The location transparency provided by tuplespaces allows clients interacting over a tuplespace to use the same communication primitives no matter whether interactions involve a remote communication with clients e.g. residing on different machines or only local interactions with clients residing on the same physical machine. Moreover, the mechanism of associative addressing enables clients to describe both their starting conditions and data access using the same language and conceptual model. In addition associative addressing frees tuplespaces from being bound to any inherent ordering of data exchanged (c.f. FIFO- or priority-based ordering of messages in messageoriented middleware systems) which facilitates e.g. co-locating DATA and CF or DP tokens within 217 the same tuplespace without preventing themselves from being consumed. Finally, tuplespaces ensure synchronized access to the tuples that are contained in a tuplespace; effectively freeing clients from any direct client-to-client interaction. Given a system as described above, where process control flow and process instance data is communicated between process participants through remote-accessible tuplespaces, a wide spectrum of scenarios for decentralized process execution (i.e. decentralized evaluation of process control flow) can be supported using one and the same process navigation technique but different deployments of activity clients and tuplespaces; this is elaborated in the following. Abbildung 4: Centralized Process On one side of the spectrum, as presented in the scenario depicted in Figure 4, a process is deployed on one single WfMS and executed using the token-passing technique outlined above. Activity clients 1,…,5 are depicted as black filled circles. Tuplespaces are depicted as smaller, unfilled circles. In this scenario all tuplespaces used for communicating control flow tokens between activity clients reside on the same physical machine. Note that for the sake of clarity access to process instance data has been omitted from the scenario descriptions and each control flow link uses one single tuplespace for communicating the corresponding control flow tokens representing that link; under the assumption that the tokens (i.e. tuples) are self-contained in the sense that they provide all the information necessary to identify a particular control link within a certain instance of a certain process model, it is however possible collate multiple tuplespaces into one single tuplespace. Since in this deployment scenario all activity implementations and tuplespaces reside on the same machine, the tuplespace interface as defined above can be used efficiently using only local interactions. Abbildung 5: Fully decentralized process The other side of the spectrum of decentralized process execution supported by the proposed approach is depicted in Figure 5. Here the same process has been split into five fragments with each fragment containing one activity client and each of those being deployed on a different machine. In general, a process fragment refers to a part of the overall process, i.e. a subset of activities and process variables. The scenario furthermore presents two possible deployment scenarios for the tuplespaces used for communicating process control flow and instance data. The communication carried out between activity 1 and 3, for instance, is conducted over a tuplespace that is located in between the two activity clients and neither resides on the same machine as activity client 1 nor 218 activity client 3. The interaction between activities 1 and 2, in contrast, is conducted over a tuplespace that resides at the partner providing activity client 2, hence interactions initiated by 1 (e.g. writing of positive or negative control flow tokens) are remote interactions and interactions initiated by 2 (e.g. waiting for the availability of control flow tokens and their destructive consumption) are local interactions. Obviously, fully decentralized evaluation of process control flow as presented in Figure 5 introduces a huge amount of potentially unnecessary remote communication since each activity execution involves at least one remote interaction for the next navigation step (two in case of the tuplespace not residing on the side of either sender or receiver), so this is typically not desired. As presented in the motivating scenario (Section 2), it is often rather desired to combine multiple activity implementations into the same segment, based on the structure of the process model or the deployment of the orchestrated services. Abbildung 6: Process fragments (partially decentralized) The way how this can be achieved is presented in Figure 6. In this case, the process is split among two participants: Activity clients 1, 2, 5 are provided by the left process participant and activity clients 3 and 4 are provided by the right participant. Similar to the deployment scenario presented in Figure 4, communication and coordination among activities 1, 2, 5 and 3, 4 (i.e. the intrafragment communication) is achieved using local communication, while communication between 1, 3 and 4, 5 is carried out over through remote communication. Note that similar to the description in Section 3 the same tuplespace communication paradigm and primitives are used for (i) intrafragment communication to trigger execution of subsequent activity implementations within the same fragment and to facilitate fragment-local variable access and (ii) for inter-fragment communication to pass control flow to an activity or a set of activities located in an adjacent process fragment or facilitate remote access to process instance variables. As a summary, the spectrum of process distribution supported by the proposed method of decentralized execution of BPEL process control flow ranges from the most centralized scenario with all activity clients of a process residing on the same physical machine and both process control flow as well as process instance data tokens being exchanged over one tuplespace residing on the very same machine to processes where each activity client of a process and each tuplespace is provided on another physical machine. 3.1. Structure of Activity Clients As described above, the infrastructure that allows for execution of processes following the proposed approach for distributed execution of BPEL processes comprises two entities: activity clients and tuplespaces. In Figure 7, the logical view upon an implementation of an activity client is depicted. An activity client comprises coordination logic, which defines the conditions under which a particular activity implementation can be executed and the client’s computation logic that defines the actual application logic of the activity implementation. In tuplespace-based applications, the 219 coordination logic is generally provided by a template. A template allows defining constraints on the structure and values of a tuple through a mechanism known as query by example [16]. Abbildung 7: Logical View of activtiy implementations As part of the runtime infrastructure, a parameterizable implementation of each BPEL activity’s application logic is provided. In case of e.g. the BPEL assign activity, this comprises the consumption of the input variables, the application of the assign expression and the update of the value of the output variable. Activity clients are parameterizable through external configuration data in such a way, that the URIs of the tuplespaces containing inbound and outbound control flow tokens and data tuples and corresponding templates describing the tuples to be consumed can be defined. Since activity clients will typically be deployed on a number of different physical machines, remote configuration (i.e. parameterization) of activity clients must be supported. For facilitating efficient communication between activity clients deployed on one physical machine for intra-segment communication as well as remote communication between activity clients deployed on different machines for inter-segment communication, two communication protocols for the interaction between activity clients and the provided tuplespace are supported. 4. Related Work In [18], a motivation for distributed execution of workflows is presented and a description of the abstract components which form a distributed workflow application and their relations is presented. In addition, the authors provide an overview of existing distributed WfMS. In [19], the authors introduce a workflow management system architecture for supporting large-scale distributed applications, called Mentor, which is based on TP monitors and object request brokers. Decentralized workflow execution in Mentor is achieved by partitioning a workflow based on activity and state charts into a set of sub-workflows which are then enacted by a number of distributed workflow engines that are synchronized using Mentor; hence, in this approach, the minimal unit of fragmentation is a (sub-) process and not an individual activity as in the approach presented in this paper. In [20], AdeptDistribution, a similar approach to workflow partitioning and decentralized execution is presented that supports dynamic assignment of workflow partitions to so-called execution servers. Another approach to enacting workflows in a mobile, pervasive environment which relies on passing control flow between distributed BPEL engines is presented in [21]. However, no insight is given as to which extend this approach supports BPEL’s advanced features such as fault- and compensation-handling and dead path elimination. In [22], the distributed workflow engine OSIRIS is presented which is based on the concept of a hyperdatabase. The hyper-database is a distributed peer-to-peer database system that offers a number of global services with ACID transactional semantics and is realized by a hyper-database layer on each node participating in the process execution. A distributed publish-subscribe infrastructure is used for keeping data relevant for process instance execution on participating nodes in sync. In [7], an approach to fragmenting BPEL process for the purpose of business process outsourcing is presented which involves (i) a local BPEL workflow engine at each partner participating in the workflow execution and (ii) a centralized coordinator in between partners that is necessary for supporting certain BPEL constructs such as scopes and while loops split across multiple partners. A 220 BPEL process model is manually split by a user in a number of fragments and a corresponding BPEL process (along with necessary deployment information) is created for each fragment. Exchange of process instance data and passing control flow between fragments is realized by introducing additional invoke and receive activities in each process fragments, for sending (i.e. pushing) a message containing instance data to be passed to another fragment on one side and receiving potentially multiple messages containing instance data from different partners (through so-called receiving flows) on the other side. While this method retains standards-compliance by reusing existing Web service standards (e.g. WS-Coordination) it requires a centralized coordinator in cases where loops or scopes are split among partners. In addition, since process instance data is communicated between process participants through a push mechanism, complex data flow analysis is required on the sender’s side to determine the data that needs to be communicated. In [23], a cost model and algorithm for automatically splitting BPEL processes among a number of participating BPEL workflow engines is presented that is based on program dependence graphs. Similar work focused on more dynamic, mobile scenarios is presented in [24]. 5. Conclusions and Future Work In the paper we have presented an infrastructure and conceptual model for decentralized, distributed execution of business processes in BPEL that allows for arbitrarily distributed evaluation of process control flow. We have motivated the need for distributed evaluation of process control flow through an introductory example. The supported spectrum of process distributed has been discussed and the basic building blocks of the system architecture have been described. In contrast to existing models and techniques the approach as proposed in the paper allows for arbitrarily fragmented processes while using the same mechanisms (but different transport protocols) for evaluation of process control flow at the side of one process participant and between process participants. A tuplespace prototype that provides the necessary functionality for communicating process control flow between local activity clients has been implemented. While the broad spectrum of process fragmentation supported by the proposed system, allows for a wide range of optimizations depending on a user’s requirements, it requires the definition of an corresponding algorithm for automatic creation of those fragments. The definition of such an algorithm, based on process models, infrastructure descriptions and user requirements and the extension of the current prototype to support decentralized process deployment is considered future work. 6. References [1] KRAFZIG, D., BANKE, K., SLAMA, D.: Enterprise SOA. Service Oriented Architecture Best Practices. Prentice Hall International (December 2004) [2] WEERAWARANA, S., CURBERA, F., LEYMANN, F., STOREY, T., FERGUSON, D.F.: Web Services Platform Architecture: SOAP, WSDL, WS-Policy, WS-Addressing, WS-BPEL, WS-Reliable Messaging and More. Prentice Hall PTR Upper Saddle River, NJ, USA (2005) [3] ALONSO, G., CASATI, F., KUNO, H., MACHIRAJU, V.: Web Services: Concepts, Architectures and Applications. Springer Verlag (2004) [4] ARKIN, A., ET AL.: WS-BPEL: Web Services Business Process Execution Language Version 2.0. OASIS Open, January (2007) [5] LEYMANN, F.: Web Services: Distributed Applications without Limits, in: Business, Technology and Web, Leipzig (2003) [6] LEYMANN, F., ROLLER, D.: Production Workflow: Concepts and Techniques. Prentice Hall PTR Upper Saddle River, NJ, USA (1999) [7] KHALAF, R., LEYMANN, F.: Role-based Decomposition of Business Processes Using BPEL, in: International Conference of Web Services, ICWS 770–780 [8] WUTKE, D., MARTIN, D., LEYMANN, F.: Model and infrastructure for decentralized workflow enactment, in: 23rd ACM Symposium on Applied Computing (SAC2008) (2008) 221 [9] GELERNTER, D.: Generative Communication in Linda, in: ACM Transactions on Programming Languages and Systems 7(1) (1985) 80–112 [10] LEYMANN, F.: Space-based Computing and Semantics: A Web Service Purist’s Point-Of-View (2006) [11] FENSEL, D., EVA KÜHN, LEYMANN, F., TOLKSDORF, R.: Queues Are Spaces - Yet Still Both Are Not The Same? (2007), http://www.spacebasedcomputing.org/fileadmin/files/SBC-QueuesAreSpaces_20070511.pdf [12] MARTIN, D., WUTKE, D., SCHEIBLER, T., LEYMANN, F.: An EAI Pattern-based Comparison of Spaces and Messaging. In: EDOC ’07: Proceedings of the 11th IEEE International Enterprise Distributed Object Computing Conference, Washington, DC, USA, IEEE Computer Society (2007) 511 [13] BLAKELY, B., HARRIS, H., RHYS, L.: Messaging and Queueing Using the MQI: Concepts & Analysis, Design & Development. McGraw-Hill (1995) [14] BERNERS-LEE, T., FIELDING, R., MASINTER, L.: RFC 3986: Uniform Resource Identifier (URI): Generic Syntax. The Internet Society (2005) [15] BERNERS-LEE, T., MASINTER, L., MCCAHILL, M.: RFC 1738: Uniform Resource Locator (URL). The Internet Society (1994) [16] ZLOOF, M.: Query-by-Example: A Data Base Language, in: IBM Systems Journal 16(4) (1977) 324–343 [17] CLARK, J., DEROSE, S.: XML Path Language (XPath). W3C Recommendation (November 1999) [18] JABLONSKI, S., SCHAMBURGER, R., HAHN, C., HORN, S., LAY, R., NEEB, J., SCHLUNDT, M.: A comprehensive investigation of distribution in the context of workflow management, in: International Conference on Parallel and Distributed Systems ICPADS, Kyongju City, Korea (2001) [19] MUTH, P., WODTKE, D., WEISSENFELS, J., DITTRICH, A., WEIKUM, G.: From Centralized Workflow Specification to Distributed Workflow Execution, in: Journal of Intelligent Information Systems 10(2) (1998) 159–184 [20] BAUER, T., DADAM, P.: Efficient Distributed Workflow Management Based on Variable Server Assignments, in: International Conference on Advanced Information Systems Engineering (CAiSE’00), Stockholm (2000) 94–109 [21] MONTAGUT, F., MOLVA, R.: Enabling Pervasive Execution of Workflows, in: 1st IEEE International Conference on Collaborative Computing: Networking, Applications and Worksharing, CollaborateCom (2005) [22] SCHULER, C., WEBER, R., SCHULDT, H., SCHEK, H.J.: Scalable Peer-to-Peer Process Management - The OSIRIS Approach, in: IEEE International Conference on Web Services 2004 26–34 [23] NANDA, M.G., CHANDRA, S., SARKAR, V.: Decentralizing Execution of Composite Web Services, in: 19th Annual ACM SIGPLAN Conference on Object-Oriented Programming, Systems, Languages, and Applications (2004) 170–187 [24] BARESI, L., MAURINO, A., MODAFFERI, S.: Workflow Partitioning in Mobile Information Systems, in: IFIP TC8 Working Conference on Mobile Information Systems, Oslo, Norway (2004) 93–106 [25] MARTIN, D. , WUTKE, D., LEYMANN, F.: A Novel Approach to Decentralized Workflow Enactment. 12th IEEE International EDOC Conference, Munich, Germany (2008) 222 AUSWIRKUNGEN DER SERVICEORIENTIERUNG AUF DAS BUSINESS ENGINEERING: EINE METAMODELLBASIERTE ANALYSE Frank Höning1, Volker Bach1,2, Hubert Österle1 Kurzfassung Serviceorientierung ist ein weit verbreitetes Schlagwort. Auf Strategieebene sorgt sie für eine Differenzierung von den Wettbewerbern. Als Architekturparadigma für Informationssysteme ermöglicht sie eine höhere Wiederverwendbarkeit und flexiblere Integration von Geschäftsapplikationen. Beide Sichtweisen sind nicht isoliert zu betrachten, da viele von Geschäftsapplikationen bereitgestellte Services das Potenzial haben, zum Differenzierungsmerkmal in Beziehungen zu den Geschäftspartnern zu werden. Der Beitrag analysiert, in welchen Teilen bewährte Methoden des Business Engineering eine serviceorientierte Ausrichtung auf strategischer und systemtechnischer Ebene bereits unterstützen und wo Erweiterungen erforderlich sind. Dazu grenzt er die kontextspezifischen Begriffsinhalte der Serviceorientierung ab und definiert ein daran angepasstes Metamodell einer Business Engineering Methode. 1. Einleitung Unternehmen des Informationszeitalters richten ihr Produkt- und Serviceportfolio am Kundenprozess aus. Dabei stellen insbesondere die Serviceleistungen entlang des Geschäftsbeziehungszyklus ein Differenzierungsmerkmal im Wettbewerb dar [1]. Diese sind die Antwort der Unternehmen auf die sich ständig ändernden Kundenbedürfnisse in hart umkämpften und gesättigten Märkten [2]. Aus der Notwendigkeit, das Geschäftsmodell permanent den Marktveränderungen anzupassen, resultieren hohe Anforderungen an die Wandlungsfähigkeit der Informationssysteme. Serviceorientierte Architekturen (SOA) sollen dies ermöglichen und die schnellere und wirtschaftlichere Umsetzung von Innovationen des Geschäftsmodells im Informationssystem sicherstellen [3]. Die serviceorientierte Ausrichtung eines Unternehmens ist aus sozio-ökonomischen und technischen Gesichtspunkten zu komplex, als dass sie ohne methodische Unterstützung bestritten werden könnte. Zur Transformation von Unternehmen verfügt die Wirtschaftsinformatik über bewährte und sehr umfangreiche Methoden wie das Semantische Objektmodell (SOM) von Ferstl & Sinz [4], die Multiper- 1 2 Universität St. Gallen, CH-9000 St. Gallen, Müller-Friedberg-Strasse 8. SAP AG, D-61690 Walldorf, Dietmar-Hopp-Allee 16. 223 spektivische Unternehmensmodellierung (MEMO) nach Frank [5], die Architektur integrierter Informationssysteme (ARIS) von Scheer [6] und den St. Galler Ansatz des Business Engineering (BE) nach Österle [7]. Daneben existieren konsolidierte Methoden wie etwa die „Core Business Engineering“(CBE)-Methode [8]. Diese ist durch eine Kombination aus Aktions- und Fallstudienforschung sowie Deduktion entwickelt worden und bildet die Schnittmenge aus einer Reihe von Spezialmethoden. Sie liefert ein methodisches Grundgerüst, welches in jedem Transformationsprojekt über die Gestaltungsebenen Strategie, Prozesse und Systeme anwendbar ist. Eine derartige schlanke Methode für die Unternehmenstransformation reduziert die Einarbeitungszeit des Methodenanwenders und erhöht die Anwendungswahrscheinlichkeit der Methode. Doch deckt dieser Methodenkern eine serviceorientierte Neuausrichtung eines Unternehmens bereits ausreichend ab oder bedarf es dafür einer (ebenfalls schlanken) Erweiterung? Hierauf eine Antwort zu geben, ist Ziel des Beitrags. Der zugrunde liegende Forschungsprozess orientiert sich an den Prinzipien des Design Science Research [9]. Dieses Paradigma strebt nach Erkenntnisgewinn durch Schaffen (Develop/Build) und Evaluieren (Justify/Evaluate) von IT-Lösungen in Form von Modellen, Methoden oder Systemen. Der vorliegende Beitrag konzentriert sich auf die Phase des Schaffens und erweitert eine bestehende BEMethode um Aspekte der Serviceorientierung auf strategischer und systemtechnischer Ebene. Dementsprechend stellt Abschnitt 2 die CBE-Methode und die ihr zugrunde liegenden Prinzipien der Methodenkonstruktion vor. Der Fokus liegt auf dem Core Business Metamodell (CBM), welches den Ordnungsrahmen für eine mögliche Erweiterung darstellt. Voraussetzung für die Einordnung der Serviceorientierung in die Begriffswelt des BE ist die präzise Abgrenzung der Begriffsinhalte auf strategischer und systemtechnischer Ebene. Dazu dient die Analyse zahlreicher Definitionen aus der Literatur (Punkt 3). Ausgehend von einem konsolidierten Verständnis der Serviceorientierung überprüft Punkt 4 den methodischen Abdeckungsgrad einer serviceorientierten Ausrichtung durch die CBE-Methode. Eine Zusammenfassung und ausblickende Bemerkungen schliessen den Beitrag (Punkt 5). Die Evaluation und Weiterentwicklung des in diesem Beitrag vorgeschlagenen Artefakts zur methodischen Unterstützung einer serviceorientierten Ausrichtung ist in zukünftigen Arbeiten vorzunehmen. 2. „Core Business Engineering“-Methode Business Engineering (BE) bezeichnet „die methoden- und modellbasierte Konstruktionslehre für Unternehmen des Informationszeitalters“ auf unterschiedlichen Ebenen (Strategie, Prozesse, Systeme) [10]. Ziel des BE ist es, „innovative Geschäftslösungen so professionell wie Flugzeuge oder Fertigungsanlagen zu entwickeln“ [11]. Unterstützung beim Transformationsprozess bieten die eingangs erwähnten bewährten Methoden des BE. Neben diesen Methoden hat auch jedes Beratungshaus seine eigene Projektmethodik entwickelt und schliesslich existieren in grösseren Unternehmen Projekthandbücher, die den Transformationsprozess systematisieren sollen. Dies verdeutlicht, dass sich die ursprüngliche Idee einer Standardisierung von Projektmethoden nicht nachhaltig durchgesetzt hat. Vielmehr wird in der betrieblichen Praxis eine Kombination aus verschiedenen Methodiken eingesetzt [12]. Inkompatible Methodenbaukästen erfordern jedoch eine hohe Einarbeitungszeit der Projektbeteiligten, setzen eine gute Methodenkenntnis voraus und führen nicht selten zu unangemessen hohen Dokumentationsaufwänden. Ein realistischer Weg zur methodischen Arbeit in einer grösseren Zahl von Transformationsprojekten ist daher in der Definition einer auf das Wesentliche reduzierten CBE-Methode zu sehen [8]. 224 2.1. Methoden-Struktur Grundlage für die Konstruktion der CBE-Methode bildet das Methoden-Engineering, also der ingenieurwissenschaftliche Prozess des Entwurfs und der Anpassung von Methoden, Techniken und Werkzeugen für die Entwicklung von Informationssystemen [13]. Dem Methoden-Engineering entsprechend, besteht die CBE-Methode aus den Komponenten Metamodell, Vorgehensmodell, Ergebnisdokumenten, Techniken und Rollen [14]: Das Vorgehensmodell strukturiert die Aktivitäten eines Transformationsvorhabens in einer zeitlichen und sachlogischen Reihenfolge. Rollen bündeln die Menge an Aktivitäten aus Sicht eines Aufgabenträgers. Ergebnisdokumente halten den Gestaltungsentwurf fest. Aktivitäten verwenden Ergebnisse vorangehender Aktivitäten als Input und erzeugen oder verändern ihrerseits Ergebnisse. In den einzelnen Ergebnisdokumenten werden die Gestaltungsobjekte der Methode anhand ihrer Attribute beschrieben. Das Metamodell ist das konzeptionelle Datenmodell der Ergebnisse. Es bringt den Aspekt der Ergebnisorientierung einer Methode zum Ausdruck [15] und bildet das Fundament der Methodenentwicklung. Es definiert die Konstruktionsregeln für den Entwurf von Modellsystemen, indem es die verfügbaren Arten von Gestaltungsobjekten, die Arten von Beziehungen zwischen den Objekten, die Regeln für die Verknüpfung von Objekten sowie deren Semantik spezifiziert [16]. Techniken liefern detaillierte Handlungsanweisungen im Rahmen eines methodischen Vorgehens. Sie dienen als Anleitung zur Erstellung der Ergebnisse. Situative Überlegungen, wie sie der Contingency Approach fordert, fanden bei der Methodenentwicklung keine Berücksichtigung. Diese verlangen eine Adaption der Methoden je nach Projekt, Problemstellung und Umweltparameter [17]. Da es sich aber bei der CBE-Methode um ein methodisches Grundgerüst für alle Projekttypen handelt, wurden diese Aspekte nicht betrachtet. 2.2. Metamodell Das Metamodell der CBE-Methode, das CBM, ist das Ergebnis einer Analyse mehrerer Methoden und Fallstudien. Um einfach und überschaubar zu bleiben, enthält es lediglich diejenigen Objekte, die typischerweise in BE-Projekten analysiert, entworfen und dokumentiert werden. Abbildung 1 zeigt das als UML-Klassendiagramm dokumentierte Metamodell. Es beinhaltet Gestaltungsobjekte (UML-Klassen) sowie die Beziehungen (UML-Beziehungstypen Generalisierung, Aggregation und Assoziation) zwischen diesen [18]. Bestandteil des ursprünglichen CBM sind die nicht fett umrandeten Gestaltungsobjekte: Im Mittelpunkt der Betrachtungen steht ein Unternehmen, welches als spezielles Element einer Organisation modelliert ist und im Markt agiert (Sicht Strategie). Die Tätigkeiten der Marktbearbeitung werden in einem oder mehreren Geschäftsfeldern konkretisiert. Geschäftsfelder lassen sich durch die adressierten Kundensegmente, den geographischen Standort der Kunden, die Marktleistungen der Unternehmung, mit Hilfe derer die Kundenbedürfnisse befriedigt werden, sowie durch die Kooperationskanäle zum Informations- und Warenaustausch definieren. Der Kooperationskanal ist zwingende Voraussetzung für eine Geschäftsbeziehung mit den Geschäftspartnern. Eine Geschäftsbeziehung konkretisiert die Interaktion zwischen Organisationen. Innerhalb dieser nehmen die Geschäftspartner bestimmte Rollen (Geschäftspartnerrolle) ein, wie etwa Kunde, Lieferant oder Mitbewerber. Der Bereich Führung / Zielsystem steuert die Aufbau- und Ablauforganisation. Dazu werden Ziele festgelegt, die sich hierarchisch verfeinern lassen. Zur Operationalisierung der Ziele müssen Erfolgsfaktoren bestimmt und daraus Kennzahlen / Führungsgrössen mit definiertem Zielwert zur Messung der Zielerreichung abgeleitet werden. Durch den Vergleich der so ermittelten Ist-Werte mit den definierten 225 Zielen (Soll-Werte) können geeignete Massnahmen abgeleitet werden, um die Erreichung der übergeordneten strategischen Unternehmensziele sicherzustellen. Abbildung 1: Core Business Metamodell und seine Erweiterung 226 Im Mittelpunkt der Ablauforganisation stehen die Geschäftsprozesse mit ihren Aufgaben. Geschäftsprozesse dienen der Erzeugung von (Prozess-)Leistungen, die als Input in weitere Geschäftsprozesse eingehen oder als Teil von Marktleistungen eine Verwertung im Markt erfahren. Bei der Leistungserstellung führen Aufgaben an den Geschäfts-(informations-)objekten Aktivitäten durch. Um die Geschäftsprozesse ausführen zu können, sind die Mitarbeiter den Stellen als kleinste Organisationseinheit zuzuordnen sowie die zur Aufgabenerfüllung benötigten Rollen zu definieren (Sicht Aufbauorganisation). Die Basis innovativer Geschäftsmodelle ist ein Informationssystem, welches aus den zwei Teilbereichen Applikationen sowie Informationstechnik-Komponenten besteht. Erstere beschreiben die Anwendungssoftware zur Unterstützung der Geschäftsprozesse. Moderne Anwendungssysteme bestehen im Regelfall aus den drei Schichten Benutzerschnittstelle, Applikationsfunktionen bzw. GeschäftslogikKomponenten und Datenbehälter bzw. Datenhaltungskomponenten [19]. Die einzelnen Applikationen benötigen Informationstechnik-Komponenten als Betriebsinfrastruktur. Hierzu zählen Applikationsplattform(-Komponenten), Hardware- und Netzwerkkomponenten. 3. Serviceorientierung im Kontext von Geschäftsstrategie und Informationssystem Wie bereits eingangs verdeutlicht, wird der Begriff der Serviceorientierung in mehreren Kontexten der betriebswirtschaftlichen Forschung und Praxis genutzt, jedoch jeweils mit einem eigenen Begriffsverständnis. Insbesondere in Transformationsprojekten, die eine Durchgängigkeit von der Geschäftsstrategie bis zum Informationssystem erfordern, sind klarere Begriffsabgrenzungen notwendig, um eine reibungslose Kommunikation über mehrere Kontexte hinweg sicherzustellen. Hierzu führt Tabelle 1 eine Reihe von Definitionen im Kontext von (Geschäfts-)Strategie und (Informations-)System an. Die auf Strategieebene überwiegenden deutschen Definitionen verwenden oft den Begriff „Dienstleistung“ statt „Service“. Während hier wissenschaftliche Quellen dominieren, werden auf Systemebene zusätzlich Standardisierungsgremien, Analysten und Anbieter von serviceorientierter Unternehmenssoftware einbezogen. Tabelle 1: Definitionen der Begriffe Dienstleistung / Service und SOA Definitionen im Kontext „Geschäftsstrategie“ Bei Dienstleistungen handelt es sich entweder um eine körperliche oder geistige Tätigkeit, durch die im wirtschaftlichen Sinne ein Bedürfnis befriedigt wird, ohne dass dabei ein Sachgut hergestellt wird [20]. Dienstleistungen sind immaterielle Leistungen, die ein Anbieter einem Nachfrager gewähren kann, und die keine Übertragung von Eigentum an irgendeiner Sache zur Folge hat. Die Erstellung einer Dienstleistung kann mit einem realen materiellen Produkt verbunden sein oder nicht [21]. Die Dienstleistung ist ein Realgut mit immateriellem Charakter. Der Dienstleistungsanbieter erzeugt durch die Kombination interner Potenzialfaktoren eine Leistungsbereitschaft. Der Dienstleistungsnachfrager bringt sich selbst (als Person) oder sein Objekt in den Dienstleistungsprozess ein, in dem der externe Faktor mit der Leistungsbereitschaft (Leistungspotenz) kombiniert wird. Es entsteht die Dienstleistung als immaterielles Gut [22]. Dienstleistungen sind Leistungen im Zusammenhang mit der Bereitstellung oder dem Einsatz von Potenzialfaktoren. Diese werden während der Erstellung der Dienstleistung miteinander kombiniert. Ziel ist es, an externen Faktoren, nämlich dem Kunden oder seinem Objekt, eine nutzenstiftende Wirkung zu erzielen. Dienstleistungen können dabei selbstständig sein oder eine produktbegleitende Leistung [23]. 227 Definitionen im Kontext „Geschäftsstrategie“ (Forts.) Dienstleistungen sind selbstständige, marktfähige Leistungen, die mit der Bereitstellung und/oder dem Einsatz von Leistungsfähigkeiten verbunden sind (Potenzialorientierung). Interne und externe Faktoren werden im Rahmen des Leistungserstellungsprozesses kombiniert (Prozessorientierung). Die Faktorkombination des Dienstleistungsanbieters wird mit dem Ziel eingesetzt, an den externen Faktoren – Menschen oder deren Objekte – nutzenstiftende Wirkungen zu erzielen (Ergebnisorientierung) [24]. Definitionen im Kontext „Informationssystem“ [SOA:] The policies, practices, frameworks that enable application functionality to be provided and consumed as sets of services published at a granularity relevant to the service consumer. Services can be invoked, published and discovered, and are abstracted away from the implementation using a single, standards-based form of interface [25]. A SOA is an enterprise-scale IT architecture for linking resources on demand. In a SOA, resources are made available to participants in a value net, enterprise, line of business (typically spanning multiple applications within an enterprise or across multiple enterprises). It consists of a set of business-aligned IT services that collectively fulfill an organization’s business processes and goals. A service is a software resource (discoverable) with an externalized service description. This service description is available for searching, binding, and invocation by a service consumer. The service provider realizes the service description implementation and also delivers the quality of service requirements to the service consumer [26]. Service-Oriented Architecture (SOA) refers to an application software topology according to which business logic of the applications is separated from its user interaction logic and encapsulated in one or multiple software components (services), exposed to programmatic access via well defined formal interfaces. Each service provides its functionality to the rest of the system as a well-defined interface described in a formal markup language and the communication between services is platform and language independent [27]. Domains provide their data and functionality by stable defined interfaces, called “services”. As the main concept of SOA, a service encapsulates in our understanding a defined unit of business logic, which is reusable. It hides its implementation and can be invoked by a service consumer. Semantics, syntax and quality of service – on basis of the business logic they represent – are the main elements that describe a service [28]. SOA is a software architecture that starts with an interface definition and builds the entire application topology as a topology of interfaces, interface implementations and interface calls. […] SOA is a relationship of services and service consumers, both software modules large enough to represent a complete business function. Services are software modules that are accessed by name via an interface, typically in a requestreply mode [29]. Enterprise services are a standards-based way of encapsulating enterprise functionality and exposing it as a reusable business service that can be combined with other services to meet new requirements. Enterprise services, defined by SAP and its partners and customers, can be assembled together to compose new applications or enable new business processes. Enterprise services are implemented as web services, meaning that their interfaces are defined using WSDL files and that they support other commonly used standards for web services [30]. Aus den Definitionen in Tabelle 1 ergibt sich folgendes konsolidierte Begriffsverständnis: Im Kontext der Geschäftsstrategie handelt es sich bei einem Service / einer Dienstleistung um eine immaterielle Leistung – im Gegensatz zu einem Produkt als materieller Leistung. Eine Dienstleistung kann mit einem Produkt verbunden sein, ist jedoch auch selbstständig vermarktbar. Sie besteht aus einer oder mehreren immateriellen Leistungsbestandteilen (Potenzialfaktoren). Ziel einer Dienstleistung ist es, die Anforderungen der Kunden entlang des Geschäftsbeziehungszyklus komplett zu befriedigen. Im Kontext des Informationssystems sind Services nach bestimmten Regeln gestaltete Komponenten einer serviceorientierten Architektur (SOA). Dabei handelt es sich um abstrakte Softwareelemente, welche die in den Applikationen vorhandenen Daten und Funktionen nach den Anforderungen systemübergreifender Prozesse strukturieren und kapseln. Servicespezifikationen sorgen für die technische 228 und fachliche Dokumentation der durch den Service gekapselten Leistung. Diese sollten eine möglichst vollständige, widerspruchsfreie und eindeutige Beschreibung der Aussensicht eines Services für die Servicebenutzer geben. Die Servicespezifikationen werden in einem Serviceverzeichnis veröffentlicht („published“), in welchem potenzielle Servicenutzer manuell oder automatisiert nach Diensten suchen können. Bei der fachlichen Gruppierung der zusammengehörigen Daten und Funktionen und deren Kapselung nach aussen helfen Applikationsdomänen. Zwischen den Dienstleistungen auf Strategie- und den Services auf Systemebene lassen sich somit einige Gemeinsamkeiten feststellen. Beide bestehen aus einer oder mehreren Komponenten (Potenzialfaktoren, Daten, Funktionen) und offerieren eine immaterielle Leistung. Ziel ist die Erfüllung der Anforderungen der Leistungsempfänger, bei denen es sich entweder um Prozesse von Kunden, Mitbewerbern und Lieferanten oder um systemübergreifende (interne) Prozesse handelt. Anhand der erarbeiteten Begriffsverständnisse wird im Folgenden der methodische Abdeckungsgrad einer Serviceorientierung durch die CBE-Methode überprüft. Als Ordnungsrahmen für die Analyse dient das CBM, das sich nicht nur für die Einordnung der Begriffsinhalte in das Vokabular einer Unternehmenstransformation, sondern auch für eine strukturierte Analyse des methodischen Abdeckungsgrades eignet. 4. Serviceorientierung im Core Business Metamodell Anhand der erarbeiteten Begriffsverständnisse werden die im CBM modellierten Entitätstypen und deren Beziehungen zueinander analysiert und darauf geprüft, ob sich durch diese eine Serviceorientierung abbilden lässt. Reichen die vorhandenen Entitätstypen und Beziehungen nicht aus, sind Erweiterungen am CBM vorzunehmen. Die CBE-Methode definiert dazu Erweiterungsregeln (s. Tabelle 2), welche die syntaktische Konsistenz der Erweiterungen sicherstellen [8]. Tabelle 2: Erweiterungsregeln Nr. 1 2 3 4 5 6 7 8 Bezeichnung Hinzufügen eines Gestaltungsobjekts Hinzufügen einer Assoziationsbeziehung Spezialisierung eines Gestaltungsobjekts (durch eine Generalisierungs-Beziehung) Beschreibung der Detailstruktur eines Gestaltungsobjekts (durch Aggregationsbeziehungen zu neuen Detail-Gestaltungsobjekten) Beschreibung der Detailstruktur einer Assoziations- oder Aggregationsbeziehung (durch Hinzufügen von Gestaltungsobjekten oder Assoziationsklassen) Hinzufügen eines Aggregationsobjekts Verschiebung von Assoziationsbeziehungen auf eine niedrigere Aggregationsebene Verschiebung von Assoziationsbeziehungen auf eine höhere Aggregationsebene Wie bereits festgestellt wurde, handelt es sich bei Services im Kontext der Geschäftsstrategie um Leistungen, die durch die Kombination von Potenzialfaktoren entstehen und lose oder gekoppelt mit dem materiellen Produkt zur Unterstützung der Aufgaben des Kundenprozesses angeboten werden. Materielle Leistungen für den Kunden sind im CBM als Marktleistung beschrieben. Marktleistungen setzen sich aus Vor- bzw. Teilleistungen zusammen und werden über den Kooperationskanal mit den Geschäftspartnern (Kunde, Mitbewerber, Lieferant) ausgetauscht. Dieses Begriffsverständnis lässt sich auch auf immaterielle Leistungen – im Sinne von Dienstleistungen bzw. Services – übertragen und ist nicht auf die Erstellung einer Sachleistung beschränkt. Somit lassen sich mit dem Begriff der Marktleistung sowohl Sach- als auch Dienstleistungen zur Befriedigung der Kundenbedürfnisse abbilden. 229 Um dem vorliegenden Kontext einer materiellen und immateriellen Wertschöpfung mehr Ausdruck zu verleihen, werden die beiden Termini als Spezialisierung einer Marktleistung modelliert (Regel 3). Abbildung 1 zeigt die Erweiterung des Metamodells (fett umrandet dargestellt). Im Kontext des Informationssystems umfasst das CBM die Applikationen zur Geschäftsprozessunterstützung, welche aus den drei logischen Schichten Applikationsfunktion, Benutzerschnittstelle und Datenbehälter bestehen. Applikationen können über Schnittstellen miteinander verbunden sein. Um dem serviceorientierten Entwurfsparadigma im Kontext des Informationssystems gerecht zu werden, wird das CBM gemäss der Begriffsdefinition aus Abschnitt 3 erweitert. In einem ersten Schritt werden die neu benötigten Gestaltungsobjekte identifiziert. Gemäss der Begriffsdefinition handelt es sich um die Architekturkomponenten Service, Servicespezifikation, Applikationsdomäne und Serviceverzeichnis (Regel 1). In einem nächsten Schritt sind die identifizierten Gestaltungsobjekte in das CBM einzubinden. Als Strukturierungshilfe, welche Integrationsbeziehungen zwischen Applikationen als Services auszuprägen sind und welche nicht, dienen Applikationsdomänen [28]. Diese gruppieren fachlich zusammengehörige Applikationen bzw. Funktionen und Daten aus logischer Sicht und werden deshalb als Aggregationsobjekt (Regel 6) in das CBM aufgenommen. Die Beschreibung der durch den Service angebotenen Leistung erfolgt durch die Servicespezifikation. Wie bereits erwähnt, besteht diese aus einer fachlichen und einer technischen Beschreibung (Regel 4). Die fachliche Servicespezifikation beschreibt einen Service auf verschiedenen Ebenen. Hierzu zählen die Verhaltensebene (Vor- / Nachbedingungen etc.), die Abstimmungsebene (Dialogsequenzen, Synchronisationserfordernisse etc.), die Aufgabenebene (Beschreibung in geschäftlicher Terminologie), die Qualitätsebene (Sicherheitskontext, Durchsatz etc.) und die Vermarktungsebene (Domäne, Nutzungskonditionen etc.) [3]. Daneben umfasst die Servicespezifikation auch einen technischen Teil, die Beschreibung der Schnittstellen. Darunter ist ein Schnittstellenkontrakt zu verstehen, der funktionale und technische Eigenschaften des Services dokumentiert. Er enthält Angaben zu den Serviceoperationen, Ein- und Ausgabedatenstrukturen, unterstützten Netzwerkprotokollen, verwendeten Nachrichtenformaten sowie zur Service-Adresse [3]. Auf diese Weise entsteht eine Schnittstellenschicht, die Kommunikationsstandards wie etwa HTTP, XML, SOAP und WSDL verwendet [26]. Implementiert werden technische Serviceschnittstellen durch Applikations-(Software-)Komponenten, was durch eine Assoziationsbeziehungen zwischen den beiden Entitätstypen zum Ausdruck kommt (Regel 2). Als Nachschlagewerk für die Servicenutzer dient das Serviceverzeichnis, in welchem die Serviceanbieter ihre Servicespezifikationen veröffentlichen. Als zentrales Inhaltsverzeichnis der Servicespezifikationen wird es als Aggregationsobjekt in das CBM eingebunden (Regel 6). Services erbringen durch die Kapselung von Daten und Funktionen bestimmte Leistungen für den Servicenutzer. Aus Sicht des Nutzers unterstützt ein Service eine oder mehrere Aktivitäten eines Geschäftsprozesses. Dies bildet die Assoziationsbeziehung „nutzt“ zwischen den Gestaltungsobjekten Aktivität und Service ab (Regel 2). Aus Anbietersicht ist ein Service das Ergebnis eines – im Normalfall automatisch ablaufenden – Prozesses, sei es ein komplexer Service, der bspw. vom Prozess „Gehaltsabrechnung“ erstellt wird, oder ein elementarer Service des Prozesses „Bereitstellung Kundendaten“. Somit stellt das Gestaltungsobjekt Service eine Spezialisierung der Prozessleistung dar (Regel 3). Da sich Marktleistungen zur Befriedigung der Kundenbedürfnisse bzw. des Kundenprozesses aus einer oder mehreren Prozessleistungen zusammensetzen, kann ein Service als Teil einer Marktleistung angesehen werden, sofern der Leistungsempfänger ein Prozess ausserhalb des Unternehmens ist. Als Kooperationskanal kann dabei bspw. ein Portal dienen. Es bündelt unternehmensinterne und externe Leistungen für spezifische Prozesse bestimmter Benutzerrollen (z. B. Kunden, Lieferanten, Mitarbeiter) [31]. Dabei greifen Portale auf Services zu, die Leistungen zur Unterstützung des Kundenprozesses er- 230 bringen. Auf diese Weise kommt einem zunächst auf Systemebene angesiedelten Service schliesslich auch eine strategische Bedeutung im Sinne einer Dienstleistung zu. 5. Zusammenfassung und Ausblick Unternehmen des Informationszeitalters richten ihr Produkt-Service-Portfolio am Kundenprozess aus, wobei insbesondere die Dienstleistungen Wettbewerbsvorteile generieren. Die permanente Neuausrichtung des Geschäftsmodells erfordert eine schnelle Wandelbarkeit der Informationssysteme. Das SOAParadigma bietet hierzu einen vielversprechenden Ansatz. Für die systematische Unternehmenstransformation existiert eine Reihe von Methoden. Inwieweit diese Methoden eine Serviceorientierung auf strategischer und systemtechnischer Ebene unterstützen, untersuchte der vorliegende Beitrag exemplarisch an der „Core Business Engineering“-Methode. Voraussetzung für diese Analyse war eine präzise Klärung der Begriffsinhalte. Basierend auf dem erarbeiteten Begriffsverständnis zeigte sich, dass im Kontext der Geschäftsstrategie die Dichotomie von Produkt und Dienstleistung mit dem Gestaltungsobjekt Marktleistung aufgehoben wird. Im Kontext des Informationssystems wurde deutlich, dass die bisherige Sicht für die Abbildung einer serviceorientierten Integration nicht ausreicht. Die Folge war die konsistente Erweiterung des CBM um die Gestaltungsobjekte Applikationsdomäne, Service, Servicespezifikation und technische Serviceschnittstelle. Nach diesem Beitrag zur Einordnung der Serviceorientierung in das Vokabular des BE können zukünftige Forschungsarbeiten auf dieser metamodellbasierten Einordnung aufbauen und die anderen konstituierenden Merkmale einer Methode anpassen. Denn nur, wenn die Serviceorientierung in allen Methodenkomponenten Eingang gefunden hat, lassen sich die in diesem Beitrag fokussierten Transformationsprojekte systematisch angehen. Bei der Adaption der weiteren Methodenelemente sind folgende Überlegungen zu beachten: • Aktivitäten und Rollen: Serviceorientierung erfordert die kontinuierlichen Weiterentwicklung und Verbesserung der Services [32]. Diese Anforderung kann nicht mehr nur im Rahmen des zeitlich befristeten Transformationsprojektes erfüllt werden. Daher sind Aktivitäten und Rollen aus der Projekt-Methode zu desintegrieren und in der permanenten Organisation zu institutionalisieren. Im strategischen Kontext können dies Entwicklungsprozesse für Dienstleistungen sein [33], im System-Kontext SOA-Governance-Prozesse [34]. • Techniken und Ergebnisdokumente: Für die Erstellung der Dienstleistungen bzw. Services müssen konkrete Handlungs- und Modellierungshilfen entwickelt werden. Auf Strategieebene zählen hierzu bspw. Markt- und Kundenanalysen oder Anleitungen zur Festlegung der Verrechnungsstrategie [33]. Auf Systemebene sind insbesondere die mit dem SOA-Paradigma verbundenen Designprinzipien – wie etwa Schnittstellenorientierung, Interoperabilität, Autonomie / Modularität sowie Bedarfsorientierung [3] – zu beachten. Sämtliche Anpassungen und Erweiterungen werden dabei das wesentliche Charakteristikum des vorgestellten Metamodells reflektieren müssen: Die Durchgängigkeit vom elementaren Service, der eine einzelne Aktivität eines Geschäftsprozesses unterstützt, über den eine Prozessleistung darstellenden (und aus anderen Services zusammengesetzten) Service bis hin zu dessen Vermarktung im strategischen Kontext (im Sinne einer elektronischen Dienstleistung). Literaturverzeichnis [1] Sawhney, M., Balasubramanian, S., Krishnan, V., Creating Growth with Services, in: MIT Sloan Management Review, 45, 2004, Nr. 2, S. 34-43. 231 [2] Schäppi, B., Andreasen, M. M., Kirchgeorg, M., Radermacher , F.-J., Handbuch Produktentwicklung, Hanser, München 2005. [3] Heutschi, R., Serviceorientierte Architektur - Architekturmodell und Umsetzung in der Praxis, Dissertation, Universität St. Gallen, Difo, Bamberg 2007. [4] Ferstl, O. K., Sinz, E. J., Der Ansatz des Semantischen Objektmodells (SOM) zur Modellierung von Geschäftsprozessen, in: Wirtschaftsinformatik, 37, 1995, Nr. 3, S. 209-220. [5] Frank, U., Multiperspektivische Unternehmensmodellierung: Theoretischer Hintergrund und Entwurf einer objektorientierten Entwicklungsumgebung, Oldenbourg, München 1994. [6] Scheer, A.-W., ARIS - Vom Geschäftsprozess zum Anwendungssystem, 3. Aufl., Springer, Berlin 1998. [7] Österle, H., Business Engineering: Prozess- und Systementwicklung, 2. Aufl., Springer, Berlin 1995. [8] Höning, F., Core Business Engineering, Dissertation (in Arbeit), Universität St. Gallen, St. Gallen 2008. [9] Hevner, A. R., March, S. T., Park, J., Ram, S., Design Science in Information Systems Research, in: MIS Quarterly, 28, 2004, Nr. 1, S. 75-105. [10] Österle, H., Winter, R., Business Engineering, in: Österle, H., Winter, R. (Hrsg.), Business Engineering - Auf dem Weg zum Unternehmen des Informationszeitalters, 2. Aufl., Springer, Berlin 2003, S. 4-20. [11] Österle, H., Blessing, D., Ansätze des Business Engineering, in: HMD, 42, 2005, Nr. 241, S. 7-17. [12] Hess, T., Schuller, D., Business Process Reengineering als nachhaltiger Trend? Eine Analyse der Praxis in deutschen Großunternehmen nach einer Dekade, in: Schmalenbachs Zeitschrift für betriebswirtschaftliche Forschung (zfbf), 57, 2005, Nr. 5, S. 355-373. [13] Brinkkemper, S., Method Engineering - Engineering of Information Systems Development Methods and Tools, in: Information and Software Technology, 38, 1996, Nr. 4, S. 275-280. [14] Gutzwiller, T., Das CC RIM-Referenzmodell für den Entwurf von betrieblichen, transaktionsorientierten Informationssystemen, Physica, Heidelberg 1994. [15] Kettinger, W. J., Teng, J. T. C., Guha, S., Business Process Change: A Study of Methodologies, Techniques, and Tools, in: MIS Quarterly, 21, 1997, Nr. 1, S. 55-80. [16] Ferstl, O. K., Sinz, E. J., Grundlagen der Wirtschaftsinformatik, 4. Aufl., Oldenbourg, München 2001. [17] Bucher, T., Klesse, M., Kurpjuweit, S., Winter, R., Situational Method Engineering - On the Differentiation of "Context" and "Project Type", IFIP WG8.1 Working Conference on Situational Method Engineering - Fundamentals and Experiences (ME07), Geneva, Springer, 244, 2007, S. 33-48. [18] Oestereich, B., Objektorientierte Softwareentwicklung - Analyse und Design mit der Unified Modeling Language, 5. Aufl., Oldenbourg, München 2001. [19] Alonso, G., Casati, F., Kuno, H., Machiraju, V., Web Services: Concepts, Architectures and Applications, Springer, Berlin 2003. [20] Koschnick, W. J., Enzyklopädisches Wörterbuch Marketing Band 1 Teil 2, Saur, München 1994. [21] Kotler, P., Armstrong, G., Saunders, J., Wong, V., Grundlagen des Marketing, 4. Aufl., Pearson, München 2007. [22] Nebl, T., Produktionswirtschaft, 6. Aufl., Oldenbourg, München 2007. [23] Ramme, I., Betriebswirtschaft der Dienstleistungen - Handbuch für Studium und Praxis, in: Pepels, W. (Hrsg.), nwb, Herne 2002, S. 3-22. [24] Bruhn, M., Qualitätsmanagement für Dienstleistungen: Grundlagen, Konzepte, Methoden, Springer, Berlin 2006. [25] Sprott, D., Wilkes, L., Understanding SOA, in: CBDi Journal, 2003, September, S. 4-14. [26] W3C, Web Services Description Working Group, http://www.w3.org/2002/ws/desc/, 10.07.2008. [27] Gioldasis, N., Moumoutzis, N., Kazasis, F., Pappas, N., Christodoulakis, S., A Service Oriented Architecture for Managing Operational Strategies, ICWS-Europe 2003, LNCS 2853, Springer, 2003, S. 11-23. [28] Herr, M., Bath, U., Koschel, A., Implementation of a Service Oriented Architecture at Deutsche Post MAIL, European Conference on Web Services, Erfurt, 2004, S. 227-238. [29] Natis, Y., Service-Oriented Architecture Scenario, Gartner, Inc., Stamford 2003. [30] SAP AG, Enterprise Service, https://www.sdn.sap.com/irj/sdn/wiki?path=/display/ESpackages/Process%2bComponents, 24.07.2008. [31] Puschmann, T., Prozessportale - Architektur zur Vernetzung mit Kunden und Lieferanten, Springer, Berlin 2004. [32] Thomas, O., Walter, P., Loos, P., Product-Service System, in: Wirtschaftinformatik, 3, 2008, S. 208-219. [33] Meiren, T., Barth, T., Service Engineering in Unternehmen umsetzen: Leitfaden fur die Entwicklung von Dienstleistungen, Fraunhofer IRB Verlag, Stuttgart 2002. [34] Erl, T., SOA: Principles of service design, Prentice Hall, Upper Saddle River, NJ 2007. 232 VERBESSERUNG DER WIRKSAMKEIT DES SOA-DESIGN DURCH REFERENZMODELLE Oliver Holschke, Olga Levina, Jannis Rake, Philipp Offermann1 Kurzfassung Dieser Beitrag untersucht die Anwendung von industriespezifischen Referenzmodellen im Entwurfsprozess für Serviceorientierte Architekturen (SOA). Während sowohl Methoden der Modellwiederverwendung, als auch verschiedene Qualitätsframeworks für die Bewertung von Referenzmodellen vorgeschlagen wurden, sind Untersuchungen, die einen konkreten Ansatz der Modellwiederverwendung im SOA-Entwurf vorstellen und mittels Qualitätskriterien evaluieren, nicht bekannt. Wir schlagen ein erweitertes Qualitätsmodell für die Evaluierung der Referenzmodellanwendung im SOA-Entwurf vor und wenden es auf eine existierende Methode an, deren integrativer Bestandteil die Wiederverwendung von Referenzmodellen ist. Es wurde ein Laborexperiment durchgeführt, welches qualitative und zeitliche Vorteile des Referenzmodelleinsatzes zeigt. 1. Einführung In liberalisierten Märkten sehen sich Dienstleistungsunternehmen steigenden Kundenanforderungen gegenüber und einem stärkeren Wettbewerb ausgesetzt. Weitere Herausforderungen sind die Notwendigkeit der schnellen Bereitstellung von Diensten (z.B. mobile Dienste, Internetdienste), der Bedarf an abteilungsübergreifenden, wiederverwendbaren Funktionalitäten und Redundanzreduktion, weitreichende Prozessautomatisierung und steigende Integrationsaktivitäten. Ein Architekturansatz, der diesen Anforderungen an ein flexibles Unternehmen gerecht wird, ist die Serviceorientierte Architektur (SOA) [9], [3], [6]. Sie basiert auf der Interaktion von autonomen und interoperablen Services, die auf allen Anwendungssystemschichten – Geschäftsprozess, Präsentation, Geschäftslogik, Datenhaltung – existieren. Für die Service-Interaktionen innerhalb der Unternehmensarchitektur ist eine intensive Organisation – sowohl IT- als auch fachseitig – notwendig, die die verteilten Verantwortlichkeiten und Kommunikationsprozesse und die Verwaltung der Menge an Metadaten umsetzen kann. Dies stellt hohe Anforderungen an die Planung und den Entwurf einer SOA [6]. Da Unternehmen nie unabhängig von spezifischen Kontexten existieren, hat es immer wieder Bemühungen gegeben, das Wissen um branchenbedingte Artefakte, wie funktionale Domänen, Geschäftsprozesse, Informationsobjekte, Organisationsformen usw. in industriespezifischen konzeptuellen Modellen zu konsolidieren; die wiederverwendungsorientierte Anwendung solcher Referenzmodelle soll den 1 Fachgebiet Systemanalyse und EDV, Technische Universität Berlin, Franklinstr. 28-29, 10587 Berlin, Deutschland. 233 Entwurf und die Entwicklung von Unternehmensarchitekturen und ihrer Anwendungssysteme effizienter und effektiver gestalten [13]. Die systematische Anwendung eines Referenzmodells könnte auch den Entwicklungsprozess für eine SOA positiv beeinflussen. Aus der Forscherperspektive und für Unternehmen stellt dies eine wichtige Fragestellung dar. Während einige methodische Ansätze der Referenzmodellanwendung, als auch verschiedene Qualitätsframeworks für die Bewertung von Referenzmodellen vorgeschlagen wurden, sind empirische Befunde über den tatsächlichen Erfolg der Referenzmodellanwendung im Entwurfsprozess für Unternehmensarchitektur und -systeme nur unzureichend vorhanden. In diesem Beitrag wird ein Evaluationsmodell vorgestellt, das aus der ökonomischen Perspektive heraus genau diesen Nutzen der Referenzmodellanwendung erklärt. Es berücksichtigt dabei den Nutzen des Referenzmodelleinsatzes im SOA-Entwurfsprozess gemessen an Effizienz- und Effektivitätskriterien, die Kosten, die mit der Erstellung und Anwendung von Referenzmodellen verbunden sind [5] und stellt sowohl Kosten als auch Nutzen Gestaltungsansätzen gegenüber, die nicht auf Referenzmodelle zurückgreifen. Ein Novum in unserem Evaluationsmodell ist die Berücksichtigung von zukünftigen Gestaltungsaufgaben, d.h. die für Unternehmensarchitektur und IT-Systeme zu modellierenden Anforderungen, als statistisch verteilte Größe. Diese Anforderungen können in unterschiedlichem Maß in den Referenzmodellen repräsentiert sein: eine stärkere „Nähe“ der Anforderungen zu den Referenzmodellen erleichtert den Entwurf; inhaltlich entfernte Anforderungen dagegen führen zu hohen Kosten durch die Adaption des Referenzmodells [14]. Die Annahme der Verteilung dieser Anforderungen kann die Beurteilung der Vorteilhaftigkeit des Referenzmodelleinsatzes zusätzlich unterstützen. Wir wenden unser Evaluationsmodell auf ein existierendes Framework, d.h. eine Methode inklusive Werkzeugunterstützung, an, das im Rahmen des Forschungsprojekts PrOSeRO (ProcessOriented Service Repository and Ontology) in Kooperation von Technische Universität Berlin, Germany, Ben Gurion University, Beer-Sheva, Israel und Deutsche Telekom Laboratories entwickelt wurde und explizit die Wiederverwendung von Referenzmodellen im SOAEntwurfsprozess einbezieht. Dazu wurde ein Laborexperiment durchgeführt, wobei ein realer Geschäftsprozess eines international tätigen Telekommunikationsunternehmens für SOA zu gestalten war. Die experimentellen Gruppen haben das bereitgestellte Framework mit bzw. ohne Nutzung eines industriespezifischen Referenzmodells angewandt, um den Vergleich zu ermöglichen. Im Experiment haben wir festgestellt, dass die Anwendung des Referenzmodells im SOA-Entwurf in der Tat zu qualitativ besseren Anwendungsmodellen und verkürzten Modellierungszeiten führt. Der Rest der Arbeit gliedert sich wie folgt: zunächst beschreiben wir das im Forschungsprojekt entstandene Framework für den referenzmodellgestützten Entwurf von SOA und erläutern die übergreifende Methode, die Entwurfsartefakte und die Wiederverwendungsprozesse der Referenzmodellanwendung. Wir stellen anschließend unser Evaluationsmodell vor, mit dem wir das Framework bewerten. Dann beschreiben wir die angewandte Forschungsmethode und den Aufbau, die Durchführung und die Ergebnisse des Laborexperiments. Abschließend diskutieren wir die Limitationen der Untersuchung und geben einen Ausblick auf zukünftige Forschungsaktivitäten. 2. Referenzmodelle beim SOA-Entwurf: Einordnung in Stand der Forschung Im Rahmen des Forschungsprojekts PrOSeRO wurde in Zusammenarbeit von Technische Universität Berlin, Germany, Ben Gurion University, Beer-Sheva, Israel und den Deutsche Telekom AG Laboratories ein prototypisches Framework entwickelt, das sowohl die explizite Referenzmodellanwendung in den Entwurfsprozess einbezieht als auch eine integrierte Werkzeugunterstützung bereitstellt. Es unterstützt die Modellierung und Realisierung von 234 Geschäftsprozessen nach dem Architekturprinzip der SOA in allen Phasen der Entwicklung, d.h. von der referenzmodellbasierten Modellierung von Geschäftsprozessen und Datenobjekten über das Auffinden und Einbinden der richtigen Services bis zur Orchestrierung, Ausführung und RuntimeÜberwachung. Die Möglichkeit des expliziten Rückgriffs auf existierende Designmodelle (wie Geschäftsprozess- und Informationsmodelle) in neuen SOA-Projekten stellt ein integrales Merkmal des Frameworks dar. Die Wiederverwendung von solchen industriespezifischen Referenzmodellen soll zu reduzierten Entwicklungszeiten und qualitativ besseren Modellierungsartefakten führen [5]. In [2], [11] und [12] wurden Techniken der Referenzmodellwiederverwendung vorgestellt. In [14] wurde ein Referenzmodell-Managementsystem für Business Engineering entwickelt, welches auf der Wiederverwendung von Geschäftsprozessmodellen basiert. Ein ähnliches Framework für Workflow Model Reuse wurde von [16] vorgestellt. Gestaltungsansätze für Infrastrukturen für die Wiederverwendung von konzeptuellen Modellen werden in [15] beschrieben. Die oben genannten Ansätze beziehen sich jedoch selten auf die systematische Wiederverwendung von konzeptuellen Modellen in konkreten Entwurfsprozessen, sondern vielmehr auf Modelle höherer Abstraktionsgrade zur ganzheitlichen Betrachtung von Unternehmen. Bis auf wenige Ausnahmen sind die Ansätze im Allgemeinen nicht für die konkrete Gestaltung von Unternehmens- und Softwarearchitekturen spezifiziert. Für SOA im speziellen gilt dies ebenfalls. Zudem wird die Werkzeugunterstützung kaum berücksichtigt (mit Ausnahme von [14]). Bezüglich der Referenzmodellwiederverwendung existieren in den genannten Arbeiten keine Fallstudien, was die Beurteilung unter realen Bedingungen in Unternehmen erschwert. Unser Framework integriert diese bisher isoliert betrachteten Aspekte für die referenzmodellbasierte, methodisch und werkzeugtechnisch unterstützte SOA-Entwicklung. 3. Modellierungsmethode und –werkzeug Die referenzmodellgestützte Gestaltung von SOA stellt ein integriertes methodisches Vorgehen für die Konstruktion von speziellen konzeptuellen Modellen dar. Aufgrund der ausgeprägten Geschäftsprozessorientierung von SOA werden ausspezifizierte Geschäftsprozess- und Datenmodelle benötigt, um adäquate Services ableiten zu können. Ein Überblick der von uns entwickelten Methode, die den Wiederverwendungsaspekt von Referenzmodellen im Hinblick auf das Design für SOA besonders unterstützt, ist in Abbildung 1 dargestellt. Die von uns fokussierte Phase der Referenzmodellwiederverwendung ist darin unschattiert hervorgehoben. Die Methode umfasst im Wesentlichen sieben Phasen: 1. Modellerstellung, 2. Modellsuche, 3. Modelladaption, 4. Modellvalidierung, 5. Service-zu-Aktivität-Matching, 6. Mediatorgenerierung und 7. Orchestierung Jede dieser Phasen wird durch ein integriertes Tool-Set unterstützt. Dieses umfasst ein Modellierungstool, das als Eclipse-Plug-In realisiert ist. Das Modellierungstool stellt Techniken zur Wiederverwendung von Geschäftsprozess- und Datenmodellen bereit, die in einem separat entwickelten Repository abgelegt sind. Folgend wird auf die einzelnen Phasen näher eingegangen. In der Modellerstellungsphase werden Geschäftsprozessmodelle und zugehörige Informationsmodelle erstellt und im Repository abgespeichert. Die Erstellung der Modelle kann im Rahmen von Projekten erfolgen; die Modellerstellung kann aber prinzipiell auch unabhängig von konkreten Projekten und als Entwicklung von „Best Practices“ vorgenommen werden. Mit wachsendem Repository und zunehmender Projekterfahrung ist zu erwarten, dass die Modellerstellung vermehrt durch Modellsuche und Adaption existierender Modelle (Phasen 2 und 3) erfolgen wird. Ein hoher Aufwand entsteht bei der initialen Erstellung von Prozessmodellen, die ein industriespezifisches Referenzmodell und seine Einteilung in Prozessgruppen weiter detaillieren und spezifizieren. Durch zunehmende Wiederverwendung sinkt dieser Aufwand. 235 Abbildung 1. Methode für das referenzmodellgestützte Prozessdesign und mögliche Reuse-Mechanismen. Um im Repository suchen zu können stehen prinzipiell zwei Ansätze in der Phase Modellsuche zur Verfügung: 1) Spezifikation und 2) Navigation. Bei der Spezifikation beschreibt der Anwender Merkmale und Merkmalsausprägungen. In unserer Methode sind die Referenzmodelle mit KontextTags versehen. Eine spezifizierte Anfrage wird mit diesen Tags abgeglichen und die entsprechenden Modellkandidaten werden dem Anwender als bestmögliche Modelle für die Aufgabe angezeigt. Der Kontextfilter filtert Datenobjekte und Aktivitäten heraus, die nicht relevant für die Modellierungsaufgabe sind. Gefilterte Datenelemente können jedoch nachträglich immer wieder in das Modell übernommen werden. Somit ist die für den Anwender notwendige Variabilität ausreichend gegeben. Bei der Navigation wird der Anwender durch die verfügbaren Modelle über verschiedene Schichten geführt. Dies kann auf einer sehr grobgranularen Ebene begonnen werden, von der aus man sich auf tiefer gelegene und detaillierte Modellebenen begeben kann. Am Ende dieser Phase ist ein spezifisches Modell identifiziert und selektiert. In der Phase der Modelladaption bedient man sich verschiedener Techniken, mit denen man die Wiederverwendung von konzeptuellen Modellen unterstützen kann: Analogy Construction, Aggregation, Konfiguration, Spezialisierung, Instanziierung, Restriktion, Assembly und Adoption [1, 2, 12]. Anzumerken ist, dass in der Literatur „Reuse Process“ und „Reuse Mechanism“ synonym für Wiederverwendungstechnik verwendet werden. In unserem Framework werden die Wiederverwendungstechniken Adoption, Analogie-Konstruktion, Restriktion und Spezialisierung unterstützt. Wir haben uns für diese Techniken entschieden, da diese einerseits die notwendige Variabilität bieten, die spezifische Anpassungen in der Unternehmensrealität meist erfordern, und andererseits akzeptable Aufwände für die Vorbereitung darstellen [2]. Bei der Adoption wird das selektierte Referenzmodell übernommen wie es ist ohne weitere Adaption. Bei der Analogiekonstruktion orientiert sich ein Modellierer an einem Referenzmodell und kann bestimmte Merkmale übernehmen. Diese Technik besitzt keine bestimmte Konstruktionsbeziehung zwischen Referenzmodell und Anwendungsmodell und genießt daher viele Freiheitsgrade. Bei der Restriktion müssen die Modellelementtypen, die zugelassen oder ausgelassen werden, spezifiziert werden. Abhängig von der Perspektive des Anwenders können dann Modellelemente automatisch entfernt werden. Bei der Spezialisierung werden Merkmale des Referenzmodells an das Anwendungsmodell vererbt, die dann vom Modellierer je nach Anwendungsfall frei modifiziert werden können. Am Ende der Adaptionsphase ist ein anforderungsgerechtes Geschäftsprozess- und Informationsmodell spezifiziert. In der Phase der Modellvalidierung wird das spezifizierte Modell auf eventuelle Fehler bzw. Inkonsistenzen geprüft. Das validierte Geschäftsprozess- und Datenmodell geht dann in die Phase des Matchings von Services zu Aktivitäten über. Das Matching basiert auf einem semantischen und syntaktischen Abgleich zwischen Aktivitätsnamen, Ein- und Ausgabeparametern und Vor- und Nachbedingungen der Konstrukte des Geschäftsprozessmodells einerseits und der verfügbaren Services andererseits. Die Services werden in einem Repository verwaltet. Aufgrund von möglichen Abweichungen zwischen Ein- bzw. Ausgabeparametern aufeinanderfolgender Services sind entsprechende Mediatoren zu erstellen, die die Datenfelder richtig aufeinander abbilden. Dies erfolgt in der Phase der Mediatorengenerierung. Sobald die für den Geschäftsprozess notwendigen Services identifiziert und Mediatoren generiert sind, kann die Orchestrierung erstellt werden. 236 Ergebnisse der gesamten Methode sind die Artefakte, die für die Ausführung von Geschäftsprozessen auf Basis von Services in SOA erforderlich sind. Dies sind Geschäftsprozessmodelle formuliert in der Business Process Modeling Notation (BPMN), Datenmodelle für den Informationsfluss auf Basis der Core Components Technical Specification (CCTS) repräsentiert als XML Schema Definition (XSD), Mediatoren dargestellt als XSL Transformationen und Orchestrierungsspezifikationen notiert in der Business Process Execution Language (BPEL). 4. Evaluationsmodell für referenzmodellgestütztes SOA-Design Bisher sind nur wenige Evaluierungsmethoden für die Vorteilhaftigkeit der Referenzmodellierung vorgestellt worden, darunter der multi-perspektivische Ansatz von [4] und das linguistikbasierte Vergleichsframework von [10]. Allerdings adressieren diese nicht umfassend genug die spezifischen Eigenschaften von Referenzmodellen [5]. Auch stehen die empirischen Untersuchungen bezüglich der Qualitätsziele und erhofften Verbesserungen durch den Referenzmodelleinsatz noch aus. Um die Vorteilhaftigkeit der Referenzmodellanwendung (bzw. Nicht-Anwendung) in der SOA-Gestaltung zu bewerten, entwickeln wir ein Evaluationsmodell, welches sowohl die Qualität der Konstruktionsergebnisse als auch Kosten und Nutzen beider Alternativen bewertet. Dies soll die Beurteilung von Effektivität und Effizienz der Methoden ermöglichen. 4.1. Bewertung der Qualität von Konstruktionsergebnissen Die Bewertung der Artefakt-Qualität bezieht sich in unserem Evaluationsmodell darauf, wie effektiv das Ergebnis einer Methode ist, die Referenzmodelle wiederverwendet. Sie basiert auf der Vorarbeit von [8], welche ein Framework zur Evaluierung von konzeptuellen Modellen entwickelt haben. Dieses Framework basiert auf drei verschiedenen Qualitätskategorien: • • • Syntaktische Qualität: Je höher die Konformität mit den Regeln (z.B. Sprache) des Modells, desto höher ist die syntaktische Qualität Semantische Qualität: Je ähnlicher das Modell der Anwendungsdomäne und somit den Nutzeranforderungen genügt, desto höher ist die semantische Qualität Pragmatische Qualität: Je verständlicher das Modell für die Zielgruppe ist, desto höher ist die pragmatische Qualität 4.2. Kosten-Nutzen-Modell für die Wiederverwendung von Modellen Im Vergleich zu bestehenden Kosten-Nutzen-Modellen bezieht sich das folgende Modell speziell auf die Kosten der Wiederverwendung von Geschäftsprozess- und Datenmodellen. Sowohl die Erkenntnisse aus dem relativ nahen Bereich des Software-Reuse als auch die Überlegungen zur ökonomischen Perspektive von [5] flossen in die Konstruktion des Modells ein. Eine KostenNutzen-Analyse in diesem Bereich betrachtet zwei Aspekte: • • Die Kosten für die Nutzung von wiederverwendbaren Geschäftsprozess- und Datenmodellen gegenüber den Kosten für die Modellierung ohne Referenzmodelle und der aus den Kosten abgeleitete Nutzen und die Beurteilung der Vorteilhaftigkeit der verschiedenen Ansätze als eine Differenz zwischen diesen beiden Nutzen. 237 4.3. Bestandteile des Kosten-Nutzen-Modells Das Kostenmodell beinhaltet zwei Teile, zum einen die Kosten für die Modellierung ohne Wiederverwendung als auch die Kosten für die Modellierung mit Wiederverwendung. Abgeleitet aus den vorherrschenden Elementen aus [7] definiert unser Modell die folgenden Variablen: • • • • • COM: Kosten für die klassische Modellierung ohne Wiederverwendung CC: Kosten für die initiale Konstruktion eines Referenzmodells N: Anzahl der Wiederverwendungen des Referenzmodells Δ(M,RM): Abstand zwischen Ist-Modell und Referenzmodell CA(Δ(M,RM)): Anpassungskosten für das Referenzmodell in Abhängigkeit vom Abstand. Aus den so definierten Variables lässt sich eine Kostenfunktion für die Wiederverwendung von Modellen aufstellen. Diese steht in Abhängigkeit vom Abstand Δ zwischen dem zu modellierenden Modell und dem Referenzmodell. Dabei kann man davon ausgehen, dass mit einem höheren Abstand die Kosten für die Anpassung des Referenzmodells steigen. Die Kosten CRM für die Erstellung eines Modells unter Wiederverwendung ergeben sich also zu: C CRM = C + C A (Δ( M , RM )) (1) N Dabei ist davon auszugehen, dass sobald Δ > 0 ist, das Referenzmodell nicht einfach übernommen sondern angepasst werden muss, was zu den bereits erwähnten Anpassungskosten CA führt. Die Kosten COM für die klassische Modellierung sind unabhängig von Δ und bleiben somit konstant. Dies ist damit zu erklären, dass eine Modellierung „from scratch“ stattfindet und genau die Bedürfnisse des zu erstellenden Modells erfüllen kann. Als Maßeinheit für die Kosten der Modellierung wird zunächst die Zeit t verwendet, welche den Aufwand darstellt das Modell neu zu erstellen bzw. ein bestehendes Referenzmodell anzupassen. Der Abstand Δ zwischen realem Ist-Modell und Referenzmodell liegt im Intervall [0,1]. Im Falle von Δ = 0 stimmt das Referenzmodell exakt mit dem zu erstellenden Modell überein und es fallen keine Anpassungskosten an. Im Falle von Δ = 1 gibt es keine Übereinstimmung zwischen beiden und das Modell muss vollständig neu erstellt werden. Im letzteren Fall würden die Anpassungskosten CA(Δ = 1) den Kosten COM für die klassische Modellierung ohne Wiederverwendung entsprechen. Zu beachten ist hier jedoch, dass die anteiligen Kosten CC/n der initialen Erstellung des Referenzmodells weiterhin betrachtet werden müssen. Wir leiten das Nutzenmodell von den Erstellungskosten C ab und formulieren die einfache Nutzenfunktion U(C) = - C + d. Dies bedeutet, dass niedrigere Erstellungskosten einen höheren Nutzen darstellen. Die Nutzenfunktion gilt für beide Kostenfunktionen COM und CRM. Die Konstante d stellt einen beliebigen Verschiebungsfaktor dar. Es folgt, dass wenn COM = CRM, dann auch UOM = URM. Eine einfache Entscheidungsregel, um zu sagen ob der Wiederverwendungsansatz vorteilhaft ist, lautet: Wenn URM > UOM, dann verwende den Modellwiederverwendungsansatz, ansonsten entwerfe „from scratch“ (siehe Abbildung 2 links). 4.4. Verteilung der Abstände zwischen Modellierungsaufgabe und Referenzmodell In dem vorgestellten Kostenmodell wurde bis jetzt nur von einem zu erstellenden Modell ausgegangen. Wir erweitern diesen Gedanken, indem wir verschiedene zukünftige Modellierungsaufgaben zulassen, was durch die horizontale Skalierung Δ(M,RM) ausgedrückt wird. D.h., dass das Δ zwischen Referenzmodell und vorliegender Modellierungsaufgabe im Rahmen verschiedener Szenarien und Projekte unterschiedliche Ausprägungen haben kann. Um 238 eine valide Aussage über den tatsächlichen Nutzen von der Wiederverwendung von Modellen treffen zu können, muss diesen Unterschieden des Δ Rechnung getragen werden. Wir gehen vereinfachend von einer Normalverteilung um den Mittelwert von Δ aus. Wir stellen die Vermutung an, dass wenn Modellierungsanforderungen nicht zu stark von den verfügbaren Referenzmodellen abweichen, dann ist die Wiederverwendung vorteilhaft und lässt sich durch unser Modell erklären. Weiterhin werden die Gesamtkosten CGOM der Modellierung ohne Wiederverwendung durch die Summe über die Einzelkosten aller Projekte N beschrieben: N G COM = ∑i =1 COM i (2) Analog werden auch die Gesamtkosten für die Modellierung mit Wiederverwendung bestimmt. Allerdings kommt auch hier zum Tragen, dass die initialen Kosten der zur Konstruktion der Referenzprozesse nur einmal anfallen: N G CRM = CC + ∑i =1 C Ai (Δ( M , RM )) (3) Eine zusammenfassende Darstellung des Kosten-Nutzen-Modells ist in Abbildung 2 zu sehen. Der Mittelwert von Δ kann in unterschiedlichen Unternehmen und verschiedenen Industrien variieren. Durch die Analyse einer größeren Anzahl an Prozessen in einem Unternehmen und/oder einer Industrie kann dieser abgeschätzt werden und somit als Basis für die Beurteilung der Vorteilhaftigkeit der Wiederverwendung dienen. Befinden sich eine Großzahl der Projekte im Bereich eines geringen Δ, ist davon auszugehen, dass die Wiederverwendung von Referenzmodellen vorteilhaft ist. Abbildung 2: Kosten und Nutzen der Referenzmodellwiederverwendung und Verteilung der Anforderungen. 5. Laborexperiment: Vergleich der Ergebnisse des SOA-Entwurfs mit und ohne Anwendung des Referenzmodells Wir haben ein Laborexperiment durchgeführt, in dem unser Evaluationsmodell angewendet wurde, um die Vorteilhaftigkeit des referenzmodellgestützten Entwurfsprozesses gegenüber einem „from scratch“-Ansatz für SOA zu bestimmen. 5.1. Forschungsdesign und Aufgabe Es haben 10 Testpersonen, die einen Informatik-affinen Hintergrund besitzen, an dem Experiment teilgenommen. Sie haben stellvertretend die Rolle von Business Analysten eingenommen. Die Teilnehmer wurden per Zufall zwei verschiedenen Treatment-Gruppen (A und B) zugeteilt. Durch diese Randomisierung sollten personenbezogene Störvariablen (wie z.B. besondere Klugheit oder branchenspezifisches Wissen) neutralisiert werden. Den Gruppen wurde jeweils ihre anzuwendende Vorgehensweise im Detail erläutert: Gruppe A sollte explizit auf die durch ein industrielles Referenzmodell bereitgestellten Prozess- und Informationsmodelle zurückgreifen, um Geschäftsprozesse für eine SOA zu entwerfen. Gruppe B dagegen stand das Referenzmodell nicht zur Verfügung – die Mitglieder konnten sich ausschließlich auf ihre mentalen Modelle und ihre Erfahrung stützen („from scratch“-Vorgehen). 239 Beiden Gruppen wurde die Aufgabe gestellt, einen realen Geschäftsprozess der Telekommunikationsbranche, der ihnen in Form einer textlichen Beschreibung zur Verfügung gestellt wurde, zu analysieren und gemäß dem vorgestellten Vorgehen für den SOA-Entwurf den Prozessablauf mit Informationsobjekten zu modellieren und entsprechende Service-Operationen mit In- und Outputs abzuleiten. Jede Gruppe hatte diese Aufgabe mit dem gelernten Vorgehen zu bewerkstelligen. Der zur Aufgabe vorgelegte, reale Geschäftsprozess beinhaltete das Anlegen und Validieren von neuen Kundendaten („Create and Validate Customer“) und ist unten näher beschrieben. Dieser Prozess tritt sehr häufig in Dienstleistungsunternehmen mit einer großen Anzahl an Kunden und unterschiedlichen Vertriebskanälen auf, ist aber im Grunde in jedem Unternehmen (in einer spezifischen Form) notwendig. 5.2. Referenzmodellbasis: eTOM Prozesshierarchie und SID Informationsmodell Die experimentelle Gruppe A kann auf die im Repository abgelegten Geschäftsprozess- und Informationsmodelle des Referenzmodells enhanced Telecom Operations Map (eTOM) und des zugehörigen Shared Information/Data Model (SID), die vom TeleManagement Forum (TMF) entwickelt werde, zurückgreifen. In eTOM/SID wird das Prinzip der Serviceorientierten Architektur explizit unterstützt. Basierend auf der Prozesshierarchie von eTOM haben wir für unser Experiment einen „Create and Validate Customer“-Prozess der horizontalen funktionalen Prozessgruppierung Customer Relationship Management (CRM) zugeordnet, da diese sich u.a. mit der Erfassung und der Pflege von Kundendaten befasst. Das SID-Modell ergänzt das o.g. prozessbezogene eTOM um die Datensicht. Es stellt eine für die Telekommunikationsindustrie branchenweit gültige Sprache zur Beschreibung von Managementinformationen bereit. 5.3. Betrachtete Variablen Die unabhängige Variable in unserem Experiment hat zwei Ausprägungen, die sich auf den Wiederverwendungsaspekt im Modellierungsvorgehen beziehen: • • I1: Das Vorgehen zur Prozess- und Informationsobjektmodellierung für SOA stützt sich explizit auf ein vorhandenes Prozess- und Informationsmodell (eTOM/SID) (Treatment 1). I2: Das Vorgehen zur Prozess- und Informationsobjektmodellierung für SOA stützt sich nicht auf ein vorhandenes Prozess- und Informationsmodell, sondern die Probanden können lediglich auf ihre Erfahrungen und mentalen Modelle zurückgreifen (Treatment 2). Das Ziel der Methoden mit bzw. ohne Wiederverwendung von Designmodellen ist die Beschleunigung des Design-Prozesses und die Verbesserung der Qualität der entworfenen Artefakte. Für die Evaluierung der beiden Ansätze mit bzw. ohne Wiederverwendung von Entwurfsmodellen haben wir die folgenden abhängigen Variablen berücksichtigt, die auf dem Erfolg der Aufgabenbearbeitung basieren: • • D1: Modellierungseffizienz. Dieses Konstrukt wurde erfasst, indem die Zeit gemessen wurde, die die Gruppen benötigt haben, um den Geschäftsprozess mit den Informationsobjekten und die abgeleiteten Service-Operationen – nach eigenem Ermessen – umfassend und aufgabengerecht zu modellieren. Die hier gemessene Zeit bildet die Basis für das von uns entwickelte Kosten-Nutzen-Modell. D2: Artefaktqualität. Dieses Konstrukt wurde gemessen, indem Experten das Geschäftsprozess- und Informationsobjektmodell hinsichtlich der Qualität beurteilt haben. Für die Beurteilung der Modellqualität wurden vier Variablen angewandt: GesamtArtefaktqualität (D2), syntaktische Qualität (D21), semantische Qualität (D22) und pragmatische Qualität (D23). 240 6. Bewertung der Modellierung und der Ergebnisse Mit Beginn der Modellierung wurde die Zeit bis zur Fertigstellung aller erforderlichen Modelle gemessen. Ausschlaggebend für die Fertigstellung war der Konsens der experimentellen Gruppe darüber, dass die Prozesse, Informationen und Service-Operationen aus eigener Sicht aufgabengerecht modelliert wurden. Nach der Fertigstellung aller Modelle wurden jedem Modell drei Reviewer zugeordnet. Die Modelle wurden den Reviewern per Zufall zugeordnet und die Reviews wurden im double-blind Verfahren durchgeführt (d.h. die Reviewer wussten nicht wessen Modelle sie betrachteten und die Modellierer wussten nicht wer ihre Modelle bewertet). Bezüglich der Artefaktqualität wurden insgesamt 48 Beurteilungen vorgenommen. Alle Qualitätsbeurteilungen wurden auf einer 5-Punkt-Likert-Skala vorgenommen mit den Werten von 1 (sehr schlecht) bis 5 (exzellent). Die Experten wurden durch eine Gruppe bestehend aus den Autoren und zusätzlich jeweils einem Modellierungsexperten des Fachgebiets und der Deutsche Telekom Laboratories gestellt, d.h. insgesamt gab es sechs Reviewer. In Tabelle 1 sind die Ergebnisse für beide experimentellen Gruppen über alle abhängigen Variablen zusammengefasst. Tabelle 1. Vergleich der experimentellen Gruppen. I1 (Treatment 1) I2 (Treatment 2) D1: Modellierungszeit (in Minuten) 182 311 D2: Gesamt-Artefaktqualität 4.3 2.4 D21: Syntaktische Qualität 4.6 2.3 D22: Semantische Qualität 4.0 2.7 D23: Pragmatische Qualität 4.8 3.2 Abhängige Variable Es können fünf Vergleiche vorgenommen werden. Fünf von fünf Vergleichen haben ein signifikantes Ergebnis gezeigt. Die Gruppe, die das eTOM/SID-Modell als Ausgangspunkt für die SOA-Modellierung zur Verfügung hatte (Treatment 1), konnte über alle abhängigen Variablen signifikant besser abschneiden, als die Gruppe, die den Geschäftsprozess inklusive der Informationsobjekte für den SOA-Entwurf „from scratch“ aufbereiten musste. 7. Zusammenfassung und Ausblick In diesem Beitrag wurde die Frage untersucht, ob die Wiederverwendung von industriespezifischen (Referenz-)Modellen den SOA- Entwurfsprozess verbessert. Dabei wurden die Verkürzung der Entwicklungszeit, sowie die Verbesserung der Qualität der Artefakte angenommen. Um diese Annahmen zu überprüfen, wurde die PrOSeRO-Methode entwickelt und validiert. Sie erfüllt Anforderungen anderer SOA-Entwicklungsmodelle wie Geschäftsprozessorientierung, formelle Vorgehensweise und Rollendefinition. Zusätzlich beinhaltet die Methode eine explizite Wiederverwendung von Referenzprozessen und -daten. Alle Phasen des SOA-Entwurfsprozesses werden durch in der Methode definierte und enthaltene Werkzeuge unterstützt. Ansätze für Vorgehensmodelle, die explizit die Wiederverwendung von (Prozess-)Modellen unterstützen, werden zwar in der Literatur beschrieben, jedoch ist eine solche Methode in der Praxis noch nicht in der Breite umgesetzt worden. In diesem Beitrag wurde ein erweitertes Evaluationsmodell vorgestellt, das die Kosten und Vorteile der Wiederverwendung von Prozess- und Informationsmodellen und die semantische und syntaktische Qualität der Konstruktionsartefakte abschätzt. Das Modell wurde in einem Laborexperiment evaluiert. Die erhaltenen Ergebnisse zeigen, dass die Vorteile der Wiederverwendung von (Referenz-)Modellen bestimmt werden 241 können. Für die Zukunft eröffnet diese Arbeit neue Möglichkeiten auf unterschiedlichen Ebenen. Zunächst sollen weitere Experimente mit unterschiedlichen Prozessen (und unterschiedlichen Abständen zu Referenzmodellen) und größeren Stichproben wiederholt werden. Durch den Abgleich mit Daten aus realen Projekten sollen die erhaltenen Ergebnisse verifiziert werden. 8. Literatur [1] BECKER, J., DELFMANN, P. AND KNACKSTEDT, R. , Adaptive Reference Modeling: Integrating Configurative and Generic Adaptation Techniques for Information Models, in Reference Modeling, J. Becker, Delfmann, P. , Editor. 2007, Physica-Verlag: Heidelberg. p. 27-58. [2] BECKER, J., JANIESCH, C., PFEIFFER, D., Towards more Reuse in Conceptual Modeling – A Combined Approach using Contexts, in: J. Krogstie, Opdahl, A. L., and Sindre, G. (Hrsg.), 19th International Conference on Advanced Information Systems Engineering, Trondheim, Norway 2007. S. 81-84. [3] ERL, T., Service-Oriented Architecture - Concepts, Technology, and Design, Prentice Hall Upper Saddle River, NJ 2005. [4] FETTKE, P., LOOS, P., Multiperspective Evaluation of Reference Models - Towards a Framework, in: M.a.P. Jeusfeld, O. (Hrsg.), Conceptual Modeling for Novel Application Domains, Chicago, IL 2003. S. 80-91. [5] FRANK, U., Evaluation of Reference Models, in Reference Modeling for Business Systems Analysis, P. Fettke, Loos, P., Editor. 2007, Idea Group Publishing: London, England. p. 118-140. [6] KRAFZIG, D., BLANKE, K., AND SLAMA, D., Enterprise SOA - Service-Oriented Architecture Best Practice, Prentice Hall Upper Saddle River, NJ 2005. [7] LIM, W.C., Reuse Economics: A Comparison of Seventeen Models and Directions for Future Research, in: the Fourth International Conference on Software Reuse 1996. S. 41-50. [8] LINDLAND, I., SINDRE, G., SOLVBERG, A., Understanding quality in conceptual modeling IEEE Software Bd. 11 (1994, ). S. 42-49 [9] MARKS, E.A., BELL, M, Executive’s Guide to Service-Oriented Architecture, John Wiley & Sons, Inc., Hoboken, NJ 2006. [10] MIŠIC, V., ZHAO, J. L. , Evaluating the Quality of Reference Models, in: A. Laender, Liddle, S. W., and Storey, V.C. (Hrsg.), 19th International Conference on Conceptual Modeling, Salt Lake City, Utah 2000. S. 484-498. [11] REINHARTZ-BERGER, I., SOFFER, P., STURM, A. , A Domain Engineering Approach to Specifying and Applying Reference Models, in: J.a.F. Desel, U. (Hrsg.), Workshop on Enterprise Modelling and Information Systems Architectures, Klagenfurt, Austria 2005. S. 50-63. [12] SOFFER, P., REINHARTZ-BERGER, I., AND STURM, A., Facilitating Reuse by Specialization of Reference Models for Business Process Design, in: 19th International Conference on Advanced Information Systems Engineering (CAiSE'07), Trondheim, Norway 2007. [13] SUTCLIFFE, A., The Domain Theory, Lawrence Erlbaum Associates, London, England 2002. [14] THOMAS, O., HORIUCHI, M., TANAKA, M. , Towards a reference model management system for business engineering, in: H. Haddad (Hrsg.), 2006 ACM Symposium on Applied Computing, Dijon, France 2006. [15] VOM BROCKE, J., THOMAS, O. , Designing Infrastructures for Reusing Conceptional Models, in: 9th International Conference on Business Information Systems, Klagenfurt, Austria 2006. [16] YU, C., WU, G., YUAN, M., Business process modeling based on workflow model reuse, in: International Conference on Services Systems and Services Management (ICSSSM '05) 2005. S. 951-954. 242 PROCESS MINING ZUR STEUERUNG VON CALL CENTER-PROZESSEN Frank Bensberg1, André Coners2 Kurfassung Der vorliegende Beitrag stellt Anwendungsperspektiven des Process Minings zur Steuerung von Prozessen dar, die in Call Centern ablaufen. Mit dem Instrument des Process Minings werden anhand eines Praxisbeispiels die Call Center-Prozesse eines Finanzdienstleisters analysiert. Ziel ist die Ermittlung der Einflussfaktoren auf die Prozesseffektivität und -effizienz. Diese Einsichten über die Leistungsfähigkeit der Prozesse wiederum können für Steuerungszwecke genutzt werden. 1. Einleitung Ein Call Center wickelt Kommunikationsprozesse zwischen Menschen sowie zwischen Menschen und Maschinen mit dem Zweck ab, Services zu erbringen oder Leistungen zu vertreiben. Beispielsweise kann eine Beschwerde (sog. Prozessobjekt) kommuniziert werden, die sodann von einem Mitarbeiter des Call Centers entgegengenommen und bearbeitet wird. Oder ein Call CenterMitarbeiter kommuniziert Informationen über Produkte, um diese zu vertreiben. Nachfolgend thematisierte Analysebeispiele beziehen sich auf das fiktive unternehmensinterne Call Center einer Bank. Bislang wurde in der Literatur noch kein Konzept für die Anwendung von Verfahren des Process Minings zur Steuerung von Call Center-Prozessen vorgelegt. Vor diesem Hintergrund zielt der vorliegende Artikel darauf ab, Ansatzpunkte zur Schließung dieser Lücke aufzuzeigen. Dazu werden im zweiten Kapitel die Informationssystemarchitektur, die Prozesse und die für das Process Mining verfügbare Datenbasis eines Call Centers erläutert. Außerdem soll anhand von Beispielen aufgezeigt werden, wie Call Center traditionell gesteuert werden. Daran anknüpfend thematisiert Kapitel drei die Grundlagen des Process Minings und dessen Anwendungsperspektiven für Call Center. Der Beitrag schließt mit einer Zusammenfassung der Ergebnisse und deren kritischen Betrachtung. 2. Informationssystemarchitektur und Prozesse eines Call Centers Abbildung 1 schematisiert die Informationssystemarchitektur (kurz: IS-Architektur) und Kommunika- tionsprozesse eines Call Centers. Vereinfachend wird in der Abbildung und im Folgenden von tele1 2 ERCIS, Germany Horváth & Partners, Deutschland 243 fonbasierten Kommunikationsprozessen ausgegangen. Zu entnehmen ist, dass sich die ISArchitektur eines Call Centers aus den Grundelementen „Datenbanken“ und „Call CenterLeitstand“ zusammensetzt. Dabei umfasst die Datenbankschicht sowohl die Datenbanken der im betrachteten Unternehmen genutzten Transaktionssysteme (z. B. ERP-System) als auch Datenbanken, die als Business Intelligence-Komponenten spezifisch die Prozesse unterstützen. Innerhalb des Leitstandes werden die Kommunikationsprozesse gesteuert. Call Center-externe Kommunikationspartner InboundProzess OutboundProzess Call CenterLeitstand Interactive Voice Recognition Automatic Call Distribution IVR Dialer ACD Agentenarbeitsplätze Datenbanken Transaktionssysteme Business Intelligence Workflow Management System (WFMS) Customer Relationship Management (CRM) Enterprise Ressource Planning (ERP) Supply Chain Management (SCM) Data Warehouse (DWH) Kampagnendaten Vorhersagemodelle Gesprächshistorie Videos Trainingsdaten Abbildung 1: Schematische IS-Architektur Prozesssteuerung in Call Centern geschieht entweder durch weitgehend automatisierte ITsystembasierte Reaktionen auf Kennzahlenabweichungen oder manuelle Parametrisierungen technischer Elemente des Informationssystems sowie Anweisungen gegenüber den telefonierenden Call Center-Mitarbeitern (sog. Agenten). Mithin umfasst der Leitstand einerseits Regeln und technische Einrichtungen zum Eingriff in bereits instanziierte oder noch zu instanziierende Prozesse, die automatisiert abgearbeitet werden können, andererseits Mitarbeiter, die manuell regeln und steuern. Die IS-Architektur unterstützt zwei Typen von Call Center-Prozessen: Ein Inbound-Prozess startet durch den Anruf eines externen Kommunikationspartners. Dieser Anruf kann durch eine Interactive Voice Recognition-Anlage (IVR) entgegengenommen werden. Die Konfiguration einer IVR fällt in den Aufgabenbereich des Leitstandes, der unter anderem festzulegen hat, welche Anruftypen durch die IVR automatisiert zu bearbeiten sind. Eine IVR kann auf gesprochene Anweisungen der Kommunikationspartner reagieren, weil sie über die technische Fähigkeit zur Spracherkennung verfügt. 244 Hieraus resultiert die Möglichkeit, dass der Anrufende selbstständig bestimmte Call CenterServices nutzt. Mithin ist eine IVR als Komponente zu betrachten, die je nach Anforderung wahlweise zum Bestandteil der IS-Architektur wird, nämlich ausschließlich dann, wenn sog. Customer Self Services angeboten werden sollen. Ein Beispiel für einen Selbstservice ist die Geldüberweisung. Bei diesem weitgehend automatisierten Prozess werden die vom Kommunikationspartner gesprochenen Informationen über Bankverbindungen und Geldbetrag von der IVR-Komponente der IS-Architektur interpretiert und anschließend in den operativen Datenbanken gespeichert. Bestimmte Call Center-Dienste setzen jedoch die aktive Beteiligung von Agenten voraus, u. a. die Beantwortung von Beschwerden. In diesem Fall involviert die IVR eine automatische Anrufverteilungsanlage (Automated Call Distributor, kurz: ACD). Agenten, die zur Prozessbearbeitung grundsätzlich bereitstehen, registrieren sich in der ACD. Ferner sind in dieser Anlage die Prozessfähigkeiten (sog. „Skills“) der Agenten hinterlegt, etwa die Fähigkeit zur Bearbeitung von Beschwerden oder die Fähigkeit zur Teilnahme an Telemarketing-Kampagnen. Außerdem wird in der ACD der Agentenstatus kontinuierlich gemessen. Abhängig vom Status (z. B. „bereit zur Rufannahme“, „im Gespräch befindlich“, „ist zur Beschwerdebearbeitung befähigt“) wählt die ACD einen Agenten zur Rufbeantwortung aus. Stellt sich im Gespräch mit dem externen Kommunikationspartner heraus, dass bestimmte weitere Skills benötigt werden, über die der ausgewählte Agent nicht verfügt, so kann dieser den Anruf im Anschluss an eine zuvor in der ACD erfasste Skillverfeinerung zurückdelegieren. Darauf hin wählt die ACD einen anderen Agenten aus, der dem Skillbedarf genügt. Sofern Sollzustände – etwa bezüglich der durchschnittlich tolerierten Wartezeit – nicht erreicht werden, können die Mitarbeiter des Leitstandes eingreifen, indem diese bspw. die in der ACD hinterlegten Skills verändern. So können für Agenten, die grundsätzlich Inbound-Anrufe zu bearbeiten haben, kurzfristig in Spitzenlastzeiten Skills „freigeschaltet“ werden, um Outbound-Anrufe beantworten zu können. Der zweite grundlegende Typ eines Call Center-Prozesses ist wie erwähnt der des OutboundAnrufes. Zur Vorbereitung von Outbound-Prozessen werden ausgehend von Informationen aus den Transaktionssystemen – bspw. Informationen über das Netto-Vermögen eines Bankkunden – Telefonnummernlisten zusammengestellt. Diese können die Rufnummern derjenigen Kunden enthalten, die eine kritische Vermögensschwelle überschreiten und deshalb in den Fokus einer Kampagne zur Bewerbung eines bestimmten Vermögensanlageproduktes rücken. Solche Rufnummernlisten können im Data Warehouse (kurz: DWH) eines Call Centers abgelegt werden. Von dort werden sie an den sog. Dialer, also der Outbound-Telefonanlage, transferiert. Der Dialer verfügt zudem über Informationen über die angemeldeten Agenten, deren Skills und Stati. Aus diesen Informationen ist die zur Durchführung von Outbound-Anrufen verfügbare Agenten-Kapazität bestimmbar. Entsprechend der durchschnittlichen Gesprächszeit je Outbound-Anruf sowie der Erfolgswahrscheinlichkeit für die Herstellung einer Verbindung ermittelt der Dialer selbstständig diejenige Menge an Anrufen, die pro Zeiteinheit zu wählen sind. Wird durch den Dialer eine Verbindung erfolgreich hergestellt, dann wählt anschließend die ACD hierfür einen Agenten zur Prozessbearbeitung aus. Zur Bearbeitung des Vorgangs leistet der Agent im Regelfall Eingaben in ein Transaktionssystem (vgl. Abbildung 1). So kann dieser auf den im CRM-System hinterlegten Kalender zugreifen, um einen Beratungstermin in einer Bankfiliale zu vereinbaren. IVR und Dialer verfügen über unterschiedliche technische Fertigkeiten und unterschiedliche Geschäftsregelbestände (sog. business rules). So interpretiert die IVR im Gegensatz zum Dialer gesprochene Informationen, etwa die Höhe kommunizierter Geldbeträge. Demgegenüber erkennt der Dialer automatisch den Status des externen Kommunikationspartners. Aus diesem Grund kann der Dialer auf die „Kommunikation“ mit einem Anrufbeantworter durch Rufabbruch oder Weiterleitung an einen Agenten zum Hinterlegen einer Sprachnachricht reagieren. Falls sich eine Rufnummer als 245 nicht erreichbar erweist, kann der Dialer den betreffenden Datensatz im DWH als fehlerhaft markieren, so dass der Datenfehler durch Maßnahmen des Datenqualitätsmanagements bereinigbar wird. Im Bankensektor wird ein Dialer u. a. zur Herstellung eines Kommunikationskanals für das Telemarketing (Produktvertrieb) und das Forderungsmanagement (Beitreibung rückständiger Forderungen) eingesetzt. Um nun das für den Entwurf eines Process Mining-Ansatzes für Call Center bereitstehende Informationspotenzial beschreiben zu können, soll eine Variante des Inbound-Prozesses eingehender beleuchtet werden. Dazu liefert Abbildung 2 eine Darstellung des Prozesses in der Variante „mit Agentenbeteiligung“. Der Prozess wird auf der Ebene real ausgeführter Instanzen dargestellt, d. h. die Abbildung zeigt die Bearbeitung bzw. Nicht-Bearbeitung einzelner Anrufe – in Abbildung 2 visualisiert als Kästchen mit Identifikationsnummer: Phase 1: Anruf Call Center-Externe Phase 2: Warteschlange ACD # 501 # 499 # 502 # 500 ... ... Phase 3: Telefonat mit Agenten Service/Vertrieb # 496 Service/Vertrieb # 497 Verlorene Anrufe Service/Vertrieb # 498 # 40 # 65 Service/Vertrieb ... ... Abbildung 2: Prozessvariante „Inbound mit Agentenbeteiligung“ Abhängig von der Anzahl verwendeter Telefonleitungen kann bereits der Einstieg in die IVR mit einer Wartezeit verbunden sein. Deshalb ist in der ersten Phase eines Anrufs durch externe Kommunikationspartner ggf. ein Wartezustand zu verzeichnen. Darüber hinaus kann abhängig von der Kapazität der ACD die Übergabe des Anrufs an diese Telefonanlage Wartezeiten implizieren. Ebenso ist abhängig von der verfügbaren Agentenkapazität und dem Status der verfügbaren Agenten eine Wartezeit in der zweiten Phase möglich. Je nach Toleranz der Kommunikationspartner kann es als Konsequenz in den ersten beiden Phasen zu Abbrüchen der Kommunikationsversuche kommen. Die Daten hierüber schlagen sich in der typischen Kennzahl Anzahl verlorene Anrufe nieder. Diese Kennzahl wiederum geht zusammen mit Informationen über die Anzahl eingehender Anrufe ein in die Kennzahl Anteil verlorener Anrufe. In der dritten Phase findet Kommunikation zwischen Anrufer und einem oder mehreren Agenten statt. In den damit einhergehenden Service- und Vertriebsprozessen werden Daten über den Prozessverlauf (z. B. beteiligte Agenten, erforderliche Weiterleitungen) und das Prozessergebnis, etwa über die Höhe des erzielten Umsatzes oder das Anliegen und dem Lösungsbeitrag des Agenten generiert. Diese Daten werden Transaktionssystemen und/oder dem DWH des Call Centers bereitgestellt, um letztlich in Form von Kennzahlen zur Steuerung der Call Center-Prozesse eingesetzt werden zu können. Auf Abweichungen bezüglich Kennzahlen-Sollniveaus reagieren entweder Leitstand oder dezentrale Einheiten („Selbststeuerung“). Beispielsweise kann auf überlange Prozessbe246 arbeitungszeiten in Form einer Online-Unterweisung (sog. „Click to Coach“) oder auf ungenutzte Kapazitäten durch Aktivierung eines Web Based Trainings zur Erlangung weiterer Skills reagiert werden. Die skizzierten Datenbestände und Kennzahlen, welche in Call Centern genutzt und/oder erzeugt werden, können in ein Process Mining einbezogen werden. Hiermit wird das Ziel verfolgt, den Leitstand mit prozessbezogenen Steuerungsinformationen zu versorgen, die über das Informationspotenzial der skizzierten klassischen Call Center-Kennzahlen hinausweisen können. Aus Sicht der Steuerung sind dabei Informationen relevant, die Auskunft über die Prozesseffektivität und effizienz geben. Die Effektivität spiegelt sich im Erfüllungsgrad des sachlichen Prozesszieles (bspw. Beantwortung einer Kundenfrage innerhalb eines definierten Zeitkorridors) wider. Mit der Prozesseffizienz wird die Wirtschaftlichkeit der Prozessdurchführung adressiert. Kapitel 3 thematisiert nun vor dem Hintergrund einer Prozesssteuerung in Call Centern das Konzept des Process Minings, dessen Grundlagen zunächst zu erörtern sind. 3. Process Mining für Call Center 3.1. Grundlagen Zur Analyse großvolumiger betrieblicher Datenbestände wird seit den neunziger Jahren das Data Mining-Konzept thematisiert, das Ansätze der Statistik, der Künstlichen Intelligenz, der Datenbankforschung und der grafischen Datenverarbeitung vereinigt. Die Durchführung von Data Mining erfolgt im Rahmen eines standardisierten Prozesses, der auch analysevorbereitende Schritte wie die Selektion und Extraktion von Datenbeständen aus operativen Vorsystemen und deren Bereinigung und Transformation umfasst. [2] Sie erfolgt mit dem Ziel, in einem Datenbestand Muster zu entdecken. Ein Muster stellt eine zusammenfassende, nicht-triviale, explizite Aussage über eine Untermenge der untersuchten Datenbasis dar, die der Generierung oder Prüfung von Hypothesen dient. DT 100 100,00% Expertise Hoch Niedrig DT 56 129 39,47% ZV-Prozess effektiv 60,53% Sozialstatus Angestellte Beamte Rentner DT 176 31,58% Zeit 70 15,79% ZV-Prozess effektiv 84 13,16% ZV-Prozess effektiv Monatsanfang Monatsende 121 18,42% ZV-Prozess effektiv 253 13,16% ZV-Prozess ineffektiv Abbildung 3: Phasenstruktur des Process Minings Unter Process Mining werden in der Literatur vornehmlich solche Ansätze diskutiert, die eine Analyse von Prozessdatenbeständen mit der Zielsetzung betreiben, generalisierte Prozessmodelle zu 247 generieren. [1] Diese Ansätze fokussieren die Analyse der Protokolldateien von WorkflowManagement-Systemen (kurz: WFMS), aus denen Daten über historische Prozessinstanzen hervorgehen. Diese Protokolldateien liefern eine empirische Basis zur Erzeugung von Istprozessmodellen, aus denen durch Vergleich mit Sollprozessmodellen Anhaltspunkte für die Prozessverbesserung hervorgehen können. Auf diese Weise werden zwar Ablaufschemata für Prozesse erzeugt, allerdings steht hierbei nicht die Fragestellung nach Einflussfaktoren für die Prozesseffektivität und effizienz im Analysemittelpunkt, deren Beantwortung nahezu zwangsläufig eine Integration weiterer Datenbestände erforderlich macht. Folglich wird hier eine weite Auffassung des Process Minings zugrunde gelegt, unter der generell die Anwendung von Methoden des Data Minings auf prozessbezogene Datenbestände zu verstehen ist. Aufbauend auf dieser Begriffsbestimmung ist der Fragestellung nachzugehen, welche generellen Datenkategorien als Grundlage für das Process Mining herangezogen werden können. Notwendig ist zunächst die Identifikation von Prozessinstanzen als historische Prozessvollzüge, die bspw. durch WFMS-Protokolle dokumentiert werden können. Diese können um Merkmale des konkreten Prozessobjekts (z. B. Kunde, Produkt) angereichert werden, das den Arbeitsgegenstand bildet und auf das im Rahmen der Prozessinstanz eingewirkt wird. Die Resultate der prozessspezifischen Vollzüge führen zum Prozessergebnis, das durch Bezug zu den Prozesszielen eine Bewertung der Prozessinstanz gestattet. Als weitere Datenkategorien sind der Prozessträger, die Prozessmittel sowie der Prozesskontext zu fixieren: − Als Prozessträger sind diejenigen personellen oder maschinellen Ressourcen der betrieblichen Aufbauorganisation zu erfassen, die als aktive Elemente die Ausführung der prozessrelevanten Vorgänge leisten (z. B. Call Center-Agenten). − Prozessmittel sind diejenigen materiellen oder immateriellen Ressourcen, die von den Prozessträgern zur Prozessausführung genutzt werden (z. B. IVR und ACD). − Der Prozesskontext umfasst räumliche und zeitliche Faktoren der Prozessausführung, die gemeinsam die situativen Ausführungsbedingungen der Prozessinstanz konstituieren. Neben WFMS sind zu den potenziellen Datenlieferanten des Process Minings diejenigen Komponenten der betrieblichen Anwendungsarchitektur zu zählen, die zur Abwicklung betrieblicher Prozesse eingesetzt werden (z. B. ERP-Systeme, IVR und ACD). Weitere Datenquellen für das Process Mining sind dispositive Datenbestände, in denen prozessbezogene Daten in aufbereiteter Form vorgehalten werden. Hierzu gehören insbesondere DWH-Systeme. Eine Analyse dieser prozessbezogenen Daten setzt Aktivitäten zur Datenextraktion aus den operativen oder dispositiven Systemen sowie deren Zusammenführung in einem analysefähigen Datenbestand – z. B. in Form einer Universalrelation oder eines Sternschemas – voraus. [7] Um die Umsetzbarkeit des Process Minings in der Call Center-Praxis sicherzustellen, sind Methoden zweckmäßig, deren Ergebnisse für den Anwender leicht interpretierbar sind und daher in die Entscheidungen zur Steuerung von Prozessen einfließen können. Eine Verfahrensklasse, die diese Anforderungen erfüllt, sind Entscheidungsbaumverfahren, die als maschinelle Lernverfahren seit den achtziger Jahren im Forschungsfeld der Künstlichen Intelligenz (KI) thematisiert werden. [6] Auf Grundlage eines Bestands vorklassifizierter Objekte generieren Entscheidungsbaumverfahren Klassifikationsmodelle, die die Eigenschaften der formulierten Klassen beschreiben. Neben der Beschreibung diskriminierender Klassenmerkmale können Klassifikationsmodelle auch eingesetzt werden, um die Klassenzugehörigkeit neuer Objekte zu prognostizieren. Hierbei kann es sich um Prozessinstanzen handeln, die anhand ihrer voraussichtlichen Zielerfüllungsgrade klassifiziert wer248 den. Da sich Entscheidungsbaumverfahren durch relativ kurze Trainingszeiten und hohe Verständlichkeit der resultierenden Ergebnisse auszeichnen, genießen diese Verfahren eine hohe Akzeptanz. Sie gehören zum methodischen Arsenal zahlreicher Data Mining-Systeme. Die Anwendung von Entscheidungsbaumverfahren für die Call Center-Steuerung wird im Folgenden anhand eines Fallbeispiels konkretisiert. Dieses Fallbeispiel thematisiert den Prozess des Forderungsmanagements, der ein Primärprozess von Call Centern in Bankbetrieben ist. 3.2. Fallbeispiel: Entscheidungsbaumverfahren im Forderungsmanagement Der Kernaspekt des Forderungsmanagements von Finanzdienstleistern besteht in der Einholung und Überwachung von Zahlungsversprechen säumiger Kunden. Die Generierung von Zahlungsversprechen (kurz: ZV) erfolgt durch die Call Center-Agenten. Im Laufe dieses spezifischen OutboundProzesses (kurz: ZV-Prozess) werden säumige Kunden gezielt angesprochen und zur Abgabe eines ZV motiviert. Unter einem ZV wird dabei die einseitige Zusage zur Zahlung eines bestimmten Geldbetrags zu einem explizit definierten Zahlungstermin verstanden, sodass ZV eine monetäre und eine zeitliche Zieldimension aufweisen. Im Rahmen eines Process Mining-Projekts bei einem Finanzdienstleister wurden ZV-Prozesse im Umfeld des Privatkundenkreditgeschäfts untersucht. Motiviert wurde dieses Projekt durch den Sachverhalt, dass ZV-Prozesse einerseits erhebliche personelle Ressourcen binden und somit kostenintensiv sind, gleichzeitig detaillierte Daten über die Prozessinstanzen aufgezeichnet werden. Die ZV-Prozesse sind auf Bestandskunden gerichtet (Prozessobjekt), über die im Laufe der Kundenbeziehung zahlreiche Daten – wie z. B. Vertrags- und Kontakthistorien – gesammelt werden. Die Projektzielsetzung lag in der Aufdeckung von Faktoren zur Bestimmung der Effektivität der ZV-Prozesse. Ein ZV-Prozess ist dann als effektiv zu bezeichnen, wenn ein Zahlungsversprechen von einem Kunden eingeholt werden kann und von diesem auch tatsächlich eingehalten wird. Zur Dokumentation historischer ZV-Prozesse standen umfassende Datenbestände zur Verfügung, deren Eigenschaften zu erörtern sind. Relevante ZV-Prozessdaten werden in unterschiedlichen Frontend- und Backend-Systemen verwaltet. Die Einholung von ZV erfolgt primär auf telefonischem Wege durch das Call Center, in dem für säumige Kreditverträge entsprechende Kampagnen mehrstufig ausgeführt werden. Die Softwaresysteme des Call Centers zeichnen elementare Kommunikationsereignisse auf, sodass eine hochauflösende Beschreibung der gesamten Kommunikationshistorie auf Kundenebene möglich ist. Parallel hierzu erfolgt eine Dokumentation der eingeholten ZV in Anwendungssystemen zum Kreditmanagement, in dem auch die kundenspezifischen Zahlungseingänge aufgezeichnet werden (Prozessergebnis). Darüber hinaus konnten aus den Vertriebsdatenbanken die Vertragshistorien der Kunden sowie Kundenstammdaten extrahiert werden. Diese Datenbestände standen allerdings nur teilweise über ein zentrales DWH zur Verfügung. Also ergab sich die Notwendigkeit zur technischen und fachlichen Integration der Datenbestände. Im Rahmen der Datenvorbereitung wurden die folgenden Kategorien von Prozessattributen abgeleitet und zusammengeführt: − Daten über kommunikative Prozesse, mit denen die Outbound-Calls des Call Centers dokumentiert werden. Hierzu gehören z. B. der Startzeitpunkt, die Gesprächsdauer und das Resultat von Outbound-Calls (Statuscodes). 249 − Kundenstammdaten mit soziodemographischen Angaben, wie z. B. Geschlecht, Wohnort, Alter, Sozialstatus, Haushaltseinkommen, sowie Vertragsdaten über erworbene Finanzprodukte, aus denen auch die Vertragshistorie generiert werden kann. − Anonymisierte Daten über die involvierten Call Center-Agenten als personelle Prozessträger. Zu diesen Daten ist auch die zeitliche Zugehörigkeit zum Call Center (Tätigkeitsalter) zu zählen, die einen Indikator für die aufgabenbezogene Expertise des Agenten bildet. − Daten über den Betrag, die zeitliche Terminierung und die tatsächliche Einhaltung eines ZV. Ein ZV gilt dann als gehalten, wenn der vereinbarte Betrag innerhalb der vorgegebenen Frist tatsächlich bezahlt wird. Ein gebrochenes ZV liegt hingegen dann vor, wenn ein geringerer Betrag und/oder nicht termingetreu bezahlt wird. Auf Grundlage dieser Sachverhalte wurde die Effektivität der historischen ZV-Prozessinstanzen als binärskaliertes Merkmal abgeleitet. DT 100 100,00% Expertise Hoch Niedrig DT 56 129 39,47% ZV-Prozess effektiv 60,53% Sozialstatus Angestellte Beamte Rentner DT 176 31,58% 70 Zeit 15,79% ZV-Prozess effektiv 84 13,16% ZV-Prozess effektiv Monatsanfang Monatsende 121 18,42% ZV-Prozess effektiv Blatt 253 13,16% ZV-Prozess ineffektiv Legende relativer Anteil der Prozessinstanzen des Blatts an sämtlichen untersuchten Instanzen Klassenzugehörigkeit der Prozessinstanz Knoten relativer Anteil der Prozessinstanzen des Knotens trennendes Merkmal Merkmalsausprägungen Grau schattierte Bereiche reflektieren den relativen Anteil ineffektiver Prozessinstanzen im Blatt/Knoten. Abbildung 4: Exemplarischer Entscheidungsbaum Das Ergebnis dieser Datenintegration führte zu einem Bestand mit mehreren hundert Prozessattributen für jedes ZV, die mehrheitlich aus den Merkmalen der Kundenstammdaten resultierten. Dieser Bestand wurde zunächst mithilfe traditioneller statistischer Methoden zur Vorselektion unabhängiger Variablen untersucht. Zur Veranschaulichung der hiermit gewonnenen Ergebnisse wird in Abbildung 4 ein einfaches Beispiel dargestellt. 250 Zur Interpretation ist zunächst die generelle Struktur von Entscheidungsbäumen zu erläutern. Entscheidungsbaumverfahren legen zur Wissensrepräsentation eine Baumstruktur zugrunde, die formal aus Knoten und Kanten besteht. [5] Der Ausgangsknoten des Entscheidungsbaums ist der Wurzelknoten, während die Endknoten als Blätter bezeichnet werden. Jedes Blatt repräsentiert eine Klassifizierung für eine Teilmenge der analysierten Objekte (hier: Prozessinstanzen). Die Wurzel und die inneren Knoten des Baums repräsentieren hingegen Tests für die einzelnen Attribute der zugrunde liegenden Analyseobjekte. Der Weg von der Wurzel bis zu einem bestimmten Blatt wird als Ast bezeichnet. Beim Aufbau des Entscheidungsbaums wird anhand eines festzulegenden Auswahlmaßes schrittweise untersucht, welches Attribut den höchsten Informationsgehalt zur möglichst homogenen Aufteilung der Objektmenge hinsichtlich der Zielvariablen (Klassenzugehörigkeit) aufweist. [3] Diese Attribute werden zur Partitionierung der Objekte herangezogen und in dem Knoten des Entscheidungsbaums abgebildet. In dem beispielhaft dargestellten Entscheidungsbaum wird die Effektivität historischer ZV-Prozesse in Abhängigkeit von der Expertise – operationalisiert als Tätigkeitsalter der Agenten –, dem Sozialstatus des externen Kommunikationspartners (hier: säumiger Kreditnehmer) und der Zeit der Prozessausführung beeinflusst. Diese Prozessattribute und deren unterschiedlichen Ausprägungen werden in dem kastenförmig dargestellten Knoten des Entscheidungsbaums hinterlegt und zur Aufteilung der ZV-Prozessinstanzen herangezogen. Als Attribut mit dem höchsten diskriminatorischen Potenzial wurde vom Data Mining-Werkzeug die Expertise des Agenten erkannt, die in diesem vereinfachten Beispiel als binärskaliertes Merkmal die Ausprägungen hoch oder niedrig annehmen kann und im Wurzelknoten hinterlegt ist. Der grau schattierte Bereich des Wurzelknotens verdeutlicht den Anteil der ineffektiven ZV-Prozessinstanzen an sämtlichen untersuchten Instanzen (im Beispiel ca. 20%). Durch die Initialentscheidung erfolgt eine Partitionierung der untersuchten Prozessinstanzen anhand der Expertise des Agenten. Der linke Ast des Wurzelknotens, der mit hoher Expertise bearbeitete ZV-Prozessinstanzen repräsentiert, führt zu einem rautenförmig dargestellten Blatt (Blatt 1). In diesem Blatt beträgt der Anteil ineffektiver Prozessinstanzen nunmehr lediglich ca. 10 %. Hiermit werden bereits 39,47 % aller Prozessinstanzen klassifiziert. Aus fachlicher Perspektive kann hieraus die Schlussfolgerung gezogen werden, dass das Tätigkeitsalter des Agenten ein wesentlicher Erfolgsfaktor ist und daher bei der Prozessgestaltung berücksichtigt werden sollte. Der rechte Ast des Wurzelknotens führt hingegen zum Segment derjenigen Prozessinstanzen, die sich durch geringe Expertise der Agenten auszeichnen. Innerhalb dieses Astes erfolgt zunächst eine Partitionierung anhand des Sozialstatus des Kunden, wobei zwischen Angestellten, Beamten und Rentnern unterschieden wird. In diesem Knoten (innerer Knoten 1) ist ein deutlich erhöhter Anteil ineffektiver ZV-Prozessinstanzen in Höhe von ca. 30 % erkennbar. Das Segment derjenigen Kunden, die den Sozialstatus Angestellter aufweisen, wird auf der nächsten Ebene anhand der Variable Zeit ausdifferenziert (innerer Knoten 2). Diesem Knoten ist zu entnehmen, dass der Anteil ineffektiver Prozessinstanzen ca. 40 % beträgt, wobei nahezu ein Drittel sämtlicher Prozessinstanzen (31,58 %) von diesem Knoten beschrieben wird. Dieser Knoten verfügt über zwei Äste, von denen der rechtsseitige zu einem Blatt mit erheblichem Prozessoptimierungsbedarf führt. So ist die Mehrheit – etwa 60 % – der ZV-Prozessinstanzen aus Blatt 3 ineffektiv, wobei dieser Sachverhalt durch die Klassenzugehörigkeit des Blatts zum Ausdruck gebracht wird. Aus fachlicher Perspektive wird anhand dieser Prozessattribute eine Menge von ZV-Prozessinstanzen beschrieben, die mehrheitlich nicht zur Erreichung des prozessbezogenen Ziels führen und somit Anomalien aufweisen. Zur Verbesserung des ZV-Prozesses sind hieraus Handlungsempfehlungen ableitbar. Eine generelle Möglichkeit zur Steuerung der Prozessleistungsfähigkeit im Sinne einer Verbesserungsmaßnahme besteht in der Steigerung der Expertise von Call CenterAgenten durch Maßnahmen der Personalentwicklung. In diesem Zusammenhang können Instru251 mente des E-Learnings eingesetzt werden, mit denen Best-Practice-Beispiele aufbereitet und als Learning-on-Demand-Einheiten vermittelt werden. Auf diese Weise können Zeiträume, die sich durch geringe Kontaktaufkommen auszeichnen, zur Weiterbildung genutzt werden. Eine weitere Möglichkeit besteht in der systematischen Aufbereitung der aufgedeckten Zusammenhänge für Zwecke der zumindest teilweise automatisierten Prozesssteuerung (bspw. durch Hinterlegung als Geschäftsregel in einer ACD). Beim Prozessbeginn ist zu analysieren, ob die per Entscheidungsbaumverfahren ermittelten Bedingungen einer ineffektiven Prozessausführung erfüllt sind. Steht aufgrund der situativen Ausprägungen der Prozessattribute eine ineffektive Prozessausführung zu erwarten, sind Verfahrensweisen zur Modifikation des Prozessablaufs notwendig. Dies kann in Form eines manuellen Eingriffs durch den Call Center-Leitstand oder aber automatisiert durch Elemente der IS-Architektur erfolgen, die Prozesse auf die Einhaltung von Regeln überwachen können (z. B. ACD). Exemplarische Prozesskonfigurationshandlungen zur Vermeidung von Prozessineffektivität bestehen in der zeitlichen Verlagerung der Prozessausführung oder in der Zuweisung eines Anrufs auf erfahrene Mitarbeiter. 4. Ergebnis Mithilfe des Process Minings können Einblicke in die Effektivität und Effizienz von Call CenterProzessen gewonnen werden. Dieses kann eine Informationsgrundlage für den Call CenterLeitstand liefern, um Prozessschwachstellen systematisch abbauen und auf eine kontinuierliche Verbesserung der Prozesse hinzuwirken. Allerdings gehen mit Entscheidungsbäumen Problemfelder einher, die für die praktische Implementierung einer regelbasierten Prozesssteuerung von Bedeutung sind. So verfügen beispielsweise Entscheidungsbäume mit hoher prognostischer Validität in praxi über eine deutlich höhere Komplexität als in dem hier skizzierten Fallbeispiel. Eine umfassende Interpretation dieser Bäume zur Plausibilitätsprüfung ist zwar möglich, stellt jedoch eine anspruchsvolle Tätigkeit dar, die teils erhebliche Analysekosten zur Folge haben kann. 5. Literaturhinweise [1] ALVES DE MEDEIROS, A. K., Genetic Process Mining, Dissertation der Technischen Universiteit Eindhoven, Eindhoven, Niederlande 2006. [2] BENSBERG, F., Web Log Mining als Instrument der Marketingforschung – Ein systemgestaltender Ansatz für internetbasierte Märkte. Gabler, Wiesbaden 2001. [3] BORGELT, C., KRUSE, R., Attributauswahlmaße für die Induktion von Entscheidungsbäumen: Ein Überblick, in: Data Mining – Theoretische Aspekte und Anwendungen, Hrsg.: G. Nakhaeizadeh, Heidelberg 1998. [4] BREIMANN, L., FRIEDMAN, J., OLSHEN, R., STONE, C.: Classification and Regression Trees. Wadsworth and Brooks, Belmont (USA) 1984. [5] ESTER, M., SANDER, J., Knowledge Discovery in Databases – Techniken und Anwendungen. Springer, Berlin et al. 2000. [6] QUINLAN, J. R.: C4.5: Programs for Machine Learning, San Mateo (USA) 1993. [7] WANG, X. Z., Data Mining and Knowledge Discovery for Process Monitoring and Control, London et al. 1999. 252 WERTORIENTIERTES PROZESSMANAGEMENT: STATE-OF-THE-ART UND ZUKÜNFTIGER FORSCHUNGSBEDARF Jan vom Brocke, Christian Sonnenberg, Alexander Simons1 Kurzfassung Prozessmanagement zielt auf die Steigerung der Effektivität und Effizienz von Unternehmensprozessen. Eine explizit am Wert ausgerichtete Konzeption zum Prozessmanagement ist bis heute jedoch noch nicht entwickelt worden. Bisherige Methoden beschränken sich überwiegend auf die fachliche oder technische Gestaltung von Prozessen – Entscheidungen werden zumeist durch qualitative Kriterien oder Plausibilitätsüberlegungen begründet. Die wertmäßigen Konsequenzen der Entscheidungen werden jedoch nicht systematisch erfasst. Mit diesem Beitrag begründen wir die Notwendigkeit eines „wertorientierten Prozessmanagements“. Auf Basis der Koalitionstheorie werden spezifische Anforderungen an eine Wertorientierung im Prozessmanagement identifiziert. Sie werden verwendet, um bisherige Konzeptionen zum Prozessmanagement zu untersuchen und den Forschungsbedarf für ein wertorientiertes Prozessmanagement aufzuzeigen. 1. Einleitung Der hohe Stellenwert der „Wertorientierung“ ist heute wohl unbestritten [7, 25]. Strittig ist allerdings noch immer die Messung – sowie bereits die Bedeutung – von unternehmerischem „Wert“: Verschiedene Konzepte, wie der Shareholder- oder Stakeholder-Ansatz, und zahlreiche Messgrößen, wie der Economic Value Added (EVA), der Discounted Cash Flow (DCF) oder der Total Return to Shareholders (TRS), wurden in den vergangenen Jahren in unterschiedlichsten Disziplinen teils kontrovers diskutiert [9, 21]. Im Prozessmanagement hingegen wird der Wert von Gestaltungsalternativen bislang jedoch noch unzureichend thematisiert [28]. Dies ist erstaunlich, da der Begriff „Geschäftsprozess“ nach HAMMER/CHAMPY einerseits eine explizite Ausrichtung am Kundenwert vorsieht [18]. Andererseits stellt der Begriff „Management“ per definitionem auf den Wertbeitrag unternehmerischer Entscheidungen ab [1]. Bisherige Methoden im Prozessmanagement begründen Gestaltungsentscheidungen aber mit eher qualitativen oder rein sachlichen Erwägungen, ohne die mit einer spezifischen Gestaltungsalternative einhergehenden, wertmäßigen Konsequenzen zu explizieren [29]. Bei einer Vielzahl an Gestaltungsalternativen ist es daher kaum möglich, ihre Vorteilhaftigkeit intersubjektiv nachvollziehbar zu beurteilen [23, 27]. Ein Beispiel sind Prozessgestaltungen bei Serviceorientierten Architekturen (SOA). Technisch ist es hier möglich, je Funktion eines Prozesses alternative Services zu beziehen. Jedoch ist es fraglich, welche Konfiguration eines Serviceportfolios in einer spezifischen Anwendungssituation vorteilhaft ist 1 Martin Hilti Chair of Business Process Management, University of Liechtenstein 253 [27]. Notwendig erscheint also eine Erweiterung des Prozessmanagements um Methoden, die eine am Wert ausgerichtete Entscheidungsunterstützung ermöglichen. In Vorarbeiten sind bereits methodische Anpassungen zur monetären Bewertung vorgeschlagen worden [17]. Damit wird jedoch nur einem Teilgebiet einer umfassenderen Konzeption zu einem „wertorientierten Prozessmanagement“ Rechnung getragen. In diesem Beitrag wird eine solche Konzeption begründet. Eine Analyse des State-of-the-Art im Prozessmanagement in Bezug auf die Wertorientierung bildet die Grundlage zur Explikation des zukünftigen Forschungsbedarfs für die Konzeption eines wertorientierten Prozessmanagements. Zur systematischen Untersuchung bestehender Ansätze wird die Koalitionstheorie [11] genutzt. Arbeiten zur Koalitionstheorie zeigen, dass der einem Objekt beigemessene Wert für unterschiedliche Stakeholder durchaus variieren kann. Während Kunden beispielsweise Liefertreue und Beratungsqualität als wertstiftend empfinden, sind für Mitarbeiter eher Arbeitsbedingungen, Prestige oder Leistungsentgelte entscheidend. Die Gestaltung und Bewertung von Geschäftsprozessen hat sich also an verschiedenen Interessengruppen zu orientieren. Neben der Abstimmung unterschiedlicher Zielsysteme ist ein wertorientiertes Prozessmanagement aber auch multiperiodisch auszugestalten, um die langfristigen wertmäßigen Konsequenzen von Entscheidungen abbilden zu können. Schließlich sind eigenständige Messgrößen bereit zu stellen, die den Wertbeitrag einzelner Entscheidungen im Prozessmanagement dokumentieren. Der Beitrag ist wie folgt strukturiert: In Abschnitt 2 wird das zugrunde gelegte Forschungsdesign, das Review, skizziert. Anschließend werden wesentliche Aussagen der Koalitionstheorie zusammengefasst, um auf dieser Grundlage Anforderungen an ein wertorientiertes Prozessmanagement zu identifizieren (Abschnitt 3). Diese werden in Abschnitt 4 zur Evaluation bestehender Arbeiten zum Prozessmanagement im Hinblick auf ihre Wertorientierung verwendet. Ziel ist es, Integrations- und Erweiterungsbedarfe bestehender Prozessmanagementkonzeptionen für ein umfassendes wertorientiertes Prozessmanagement aufzuzeigen. Der hierzu erforderliche Forschungsbedarf wird in Abschnitt 5 beschrieben. Der Beitrag schließt mit einer Zusammenfassung und Diskussion der Ergebnisse (Abschnitt 6). 2. Forschungsdesign Grundlage der vorliegenden Untersuchung bilden Methoden der Reviewforschung, die zur Erstellung eines State-of-the-Art-Beitrags verwendet werden können [13]. In Anlehnung an FETTKE wird unter einem Review eine prozessorientierte Forschungsmethode verstanden, die sich in Problemformulierung, Literaturrecherche und -auswertung, Analyse und Interpretation sowie Präsentation unterteilt [8]. Zu positionieren ist ein Review hinsichtlich Ziel und Zielgruppe, Fokus, Perspektive, Struktur, Typ, Literaturauswahl und -umfang sowie dem Grad, zu dem der zukünftige Forschungsbedarf expliziert wird (vgl. Abbildung 1). Ziel (1) des vorliegenden Reviews ist einerseits die Darstellung der zentralen Inhalte bestehender Ansätze im Geschäftsprozessmanagement und andererseits ihre kritische Analyse in Bezug auf ihre Wertorientierung. Der Fokus (2) des Reviews liegt auf den in der Literatur zum Geschäftsprozessmanagement dargestellten Forschungsergebnissen. Zugrunde gelegte Forschungsmethoden oder Erfahrungen der Autoren finden dagegen keinen Eingang in die Untersuchung. Die Analyse dieser Ergebnisse erfolgt auf Grundlage der Stakeholder-Theorie, die zur Identifikation von Anforderungen an ein wertorientiertes Prozessmanagement herangezogen wird. Auf Basis der identifizierten Anforderungen wird schließlich der zukünftige Forschungsbedarf (3) expliziert. Da die zugrunde gelegten Arbeiten in Bezug auf eine bestimmte Position – die Wertorientierung – analysiert werden, ist die Perspektive (4) des Reviews nicht neutral. Die Darstellung der Untersuchungsergebnisse erfolgt thematisch (5) und natürlich-sprachlich (6). Zielgruppe (7) des Reviews sind sowohl 254 Praktiker als auch Forscher der Wirtschaftsinformatik, insbesondere des Geschäftsprozessmanagements. Kritisch ist die Explikation der berücksichtigten Literatur (8). In diesem Beitrag werden ausgewählte deutschsprachige Schlüsselarbeiten zum Geschäftsprozessmanagement dargestellt und analysiert. Abbildung 1: Klassifikation des Reviews nach Fettke [14] Mit dem Review soll untersucht werden, inwiefern bisherige Arbeiten im Prozessmanagement eine Wertorientierung vorsehen. Als Analysekriterien sollen Anforderungen an ein wertorientiertes Prozessmanagement dienen, die im Folgenden entwickelt werden. 3. Anforderungen an ein wertorientiertes Prozessmanagement Als eine Grundlage für ein wertorientiertes Prozessmanagement kann die Koalitionstheorie der Organisationsgestaltung dienen (zum Prozess der Theorieauswahl vgl. insbesondere [16]). Unter dem Begriff der Koalitionstheorie werden Arbeiten der neuen Institutionenökonomie zusammenfasst, die das Phänomen der Bildung und des Erhalts von Koalitionen als freiwillige Zusammenschlüsse von Akteuren erklären sollen. Die Arbeiten basieren auf der von BARNARD (1938) und später von SIMON (1949) geprägten Anreiz-Beitrags-Theorie [6, 26]. Eine dezidierte Koalitionstheorie wird von CYERT/MARCH (1963) beschrieben [11]. Im Folgenden werden Grundzüge dieser Theorie dargestellt, soweit sie für eine systematische Entwicklung von Anforderungen an ein wertorientiertes Prozessmanagement dienlich sind. Koalitionen kommen zustande, da Akteure mit ihrer Beteiligung einen spezifischen Anreiz verfolgen (z. B. Problemlösung, Prestige, Leistungsentgelt) und gleichzeitig bereit sind, der Koalition hierzu einen Beitrag zu leisten, der wiederum für den Erhalt der Koalition nachgefragt wird (z. B. Konstruktionsleistung, Finanzleistung). Durch die Typisierung von Anreiz-Beitrags-Relationen werden sog. Anspruchsgruppen (Stakeholder) identifiziert. Zur Menge potenzieller Stakeholder im Sinne der Koalitionstheorie gehören nur diejenigen Anspruchsgruppen, die innerhalb und außerhalb der Organisation zur Leistungserstellung beitragen [14]. Exemplarische Stakeholder im unternehmerischen Kontext sind Kapitalgeber, Eigentümer, Manager, Mitarbeiter, Kunden und Lieferanten. Unter der Annahme rationalen Verhaltens nehmen Stakeholder nur dann bzw. nur so lange an der Koalition teil, wie sie die für einen selbst gesetzten Planungshorizont erwarteten Anreize (aus der Koalition) höher einschätzen als die von ihnen geleisteten Beiträge. Die geleisteten Beiträge sämtlicher Koalitionsteilnehmer dienen der Erreichung der übergeordneten Ziele der Organisation. Für den Erhalt der Koalition ist langfristig ein sog. Anreiz-Beitrags-Gleichgewicht zu gewährleisten. 255 Dieses Gleichgewicht ist gegeben, solange die von allen Koalitionspartnern erhaltenen Beiträge ausreichen, um die notwendigen Anreize zur Bindung der Partner setzen zu können. Die Koalitionstheorie kann genutzt werden, um Anforderungen an eine wertorientierte Prozessmanagementkonzeption zu identifizieren. Ersichtlich ist zunächst, dass der einem Bewertungsobjekt beigemessene Wert für unterschiedliche Stakeholder durchaus variiert. Während etwa Kunden Liefertreue oder Produktqualität als wertsteigernd einstufen, sind für Mitarbeiter beispielsweise Arbeitsbedingungen oder eindeutige Aufgabenzuordnungen entscheidend. Aus Sicht der Kapitalgeber zählt schließlich der finanzwirtschaftliche Wert, der durch die Rentabilität des eingesetzten Kapitals ausgedrückt wird. Die erste Anforderung (A1) an ein wertorientiertes Prozessmanagement lautet also: Stakeholderorientierung. Die Koalitionstheorie bringt aber auch zum Ausdruck, dass für den Erhalt der Koalition das AnreizBeitrags-Gleichgewicht für jeden einzelnen Stakeholder zu gewährleisten ist. Nach CYERT/MARCH sind die Zielsetzungen der verschiedenen Stakeholder jedoch häufig konfliktär, so dass ein Gleichgewicht regelmäßig nicht erzielt wird [11]. Als eine zweite Anforderung (A2) an ein wertorientiertes Prozessmanagement sind somit mehrdimensionale Zielsysteme zu nennen, die untereinander auszubalancieren sind. Die Mehrdimensionalität des Zielsystems bedeutet jedoch nicht, dass sämtliche Dimensionen etwa gleichberechtigt nebeneinander stünden. Vielmehr sind sowohl UrsacheWirkungs-Beziehungen zwischen den Dimensionen als auch Gewichtungsfaktoren zu berücksichtigen (vgl. auch [23]). Die Ausgestaltung der Beziehungen (ebenso wie die Identifikation relevanter Dimensionen) ist dabei unter Berücksichtigung der unternehmensindividuellen Kontextsituation vorzunehmen. Trotz der letztendlichen Individualität relevanter Zielsysteme für eine wertorientierte Prozessgestaltung können Grundstrukturen diskutiert werden, die eine mögliche Orientierung bei der weiteren Adaption bieten. Abbildung 2 liefert ein Beispiel für ein solches Zielsystem, das einige typische Elemente enthält. Die in Arbeiten zum Prozessmanagement häufig angeführten Kriterien Kosten, Qualität und Zeit [3] können also als Zieldimensionen gelten, die in direktem Zusammenhang mit der operativen Prozessausführung stehen. Zusätzlich zu den operativen Ergebnissen sind aber auch Potenziale der zukünftigen Prozessausführung zu analysieren, z. B. aus Sicht der Kapitalgeber (Finanzen) und Mitarbeiter (Wissen, Kultur). Abbildung 2: Beispielhaftes Zielsystem Die Koalitionstheorie zeigt jedoch auch, dass der Zeit- bzw. Planungshorizont unterschiedlicher Stakeholder ebenfalls variieren kann. Eine dritte Anforderung (A3) ist daher die Mehrperiodigkeit des Bewertungssystems. Gegenüber den operativen Ergebnissen der Prozessausführung ist also eine auch zeitlich weiterreichende (bzw. totale) Betrachtung anzustellen [28]. 256 Für ein wertorientiertes Prozessmanagement ist auch die Wahl des Bewertungsobjekts entscheidend. Hier sind zunächst Geschäftsprozesse, Aktivitäten, Ressourcenbeanspruchung (Input) und Prozessleistung (Output) zu berücksichtigen (Anforderung A4). Aber auch strategische und organisatorische Maßnahmen auf Ebene des Geschäftsprozessmanagements (z. B. zum Aufbau von Sozialkapital und Know-How sowie zur Etablierung einer Prozessgovernance und -kultur) sowie Infrastrukturen (z. B. Software und Hardware) sind hier entscheidend (Anforderung A5). Zusammengefasst ergeben sich somit die folgenden Grundanforderungen: A1: Stakeholderorientierung, A2: Mehrdimensionalität des Zielsystems, A3: Mehrperiodigkeit des Bewertungssystems, A4: Prozessbezogenheit der Bewertungsobjekte und A5: Einbeziehung von Maßnahmen der Prozessgestaltung. Die beschriebenen Anforderungen stehen keinesfalls isoliert nebeneinander, sondern sind integriert zu berücksichtigen, um das Prozessmanagement um eine wertorientierte Perspektive zu ergänzen. Im folgenden Abschnitt werden bestehende Ansätze im Geschäftsprozessmanagement hinsichtlich dieser Anforderungen evaluiert. 4. Wertorientierung im Geschäftsprozessmanagement In der Literatur finden sich Arbeiten zum Management und Controlling von Prozessen, die im Hinblick auf ihren Beitrag zu einem wertorientierten Prozessmanagement zu untersuchen sind. Unter „Prozessmanagement“ wird hier ein Arbeitsgebiet verstanden, das die Planung, Durchsetzung und Kontrolle von Unternehmensprozessen zum Gegenstand hat [2, 3, 5]. Im „Prozesscontrolling“ werden Methoden zur Beurteilung der Wirtschaftlichkeit von Prozessen entwickelt [3, 20]. Der Stand auf dem Gebiet des wertorientierten Prozessmanagements soll im Folgenden anhand ausgewählter Schlüsselarbeiten veranschaulicht werden (vgl. Abbildung 3). Abbildung 3: Wertorientierung ausgewählter Konzepte im Geschäftsprozessmanagement Ein Beispiel für eine „kennzahlenbasierte Prozessanalyse“ gibt AICHELE [1]. Entwickelt wird ein Kennzahlensystem zur Geschäftsprozessoptimierung produzierender Unternehmen (A4). Auf Basis des Y-CIM-Modells werden in mehreren Modulen Kennzahlen gebildet, zu denen z. B. Finanzbuchhaltung, Personalwirtschaft, Marketing, Produktionsplanung und -steuerung, Produktentwicklung sowie Qualitätsplanung zählen (A2). Auch ein Vorgehensmodell und Beispiele zur Anwendung der Kennzahlen werden gegeben. Der Ansatz adressiert die Analyse kurzfristiger Effekte. Konzepte für eine zeitlich totale Betrachtung werden nicht vorgestellt (A3). Darüber hinaus bleibt 257 unklar, ob neben dem (operativen) Management weitere Anspruchsgruppen in der kennzahlenbasierten Prozessanalyse berücksichtigt werden (A1). ALLWEYER stellt eine „Einführung in das Prozessmanagement“ vor [2]. Die dargestellten Methoden zum Prozesscontrolling dienen der Messung von Prozesskennzahlen für die Überwachung des Prozessbetriebs (A4). Zur Unterstützung des Entwurfs werden Prozessanalysen und -simulationen thematisiert, in denen neben qualitativen Aspekten auch Durchlaufzeiten und Prozesskosten untersucht werden (A2). Strategische und organisatorische Maßnahmen zur Umsetzung des Prozessmanagements werden diskutiert – umfassende Gestaltungsempfehlungen werden jedoch nicht gegeben (A5). BECKER ET AL. liefern ein Beispiel für ein „Vorgehensmodell zum Prozessmanagement“ [3]. Ein dediziertes Prozesscontrolling ist in der Phase des kontinuierlichen Prozessmanagements vorgesehen. Hierbei werden modellbasierte Rechnungen für Zeitvorgaben sowie Ansätze der Prozesskosten- und -leistungsrechnung vorgestellt (A4). Auch werden Ansätze zum Management der Prozessperformance diskutiert. Anhaltspunkte zur Prozessgestaltung werden zur Analyse von Ist- und Sollmodellen gegeben. Neben qualitativen Ansätzen wird auch auf die Möglichkeit von Prozesssimulationen zur Analyse von Zeiten und Kapazitäten hingewiesen (A2). Die langfristigen Auswirkungen von Prozessgestaltungsmaßnahmen werden jedoch nicht hinreichend erfasst (A3). Ebenso ist keine systematische Maßnahmenbewertung der Prozessgestaltung vorgesehen. Bewertungskonzepte für strategische und organisatorische Maßnahmen werden nur knapp vorgestellt (A5). Mit einem „Controllingorientierten Beitrag zum Prozessmanagement“ stellen HORVÁTH& PARTNERS eine Vorgehensweise zur Prozessanalyse vor, bei der Kapazitäten, Kosten, Schwachstellen und Durchlaufzeiten in Kostenstellen gemessen werden [20] (A2). Ebenfalls thematisiert werden ein Regelkreis für das Prozessbenchmarking, der Aufbau und die Weiterentwicklung der Prozesskostenrechnung sowie IT-Lösungen für die Messung der Prozessperformance und die Kalkulation von Prozesskosten (A4 & A5). Methoden für mehrperiodige Wertbetrachtungen werden nicht vorgestellt (A3). Ein Beispiel für „formale Prozessanalysen“ liefern RICHTER-VON HAGEN/STUCKY [24]. Zur Prozessgestaltung werden als Designkriterien Kosten, Zeit, Flexibilität und Qualität genannt (A2). Einflussfaktoren auf die Kosten sowie Regeln ihrer entscheidungslogischen Verdichtung werden nicht dargestellt. Thematisiert wird außerdem die Prozessanalyse zur Validierung, Verifikation und Leistungsbewertung von Prozessen auf Basis von Warteschlangenmodellen und Simulationen (A4). Die Stakeholderorientierung (A1) ist gering. Mit dem „Workflow-basierten Prozesscontrolling“ entwickelt ZUR MÜHLEN einen Ansatz, in dem die von Workflowmanagementsystemen protokollierten Nutzungsdaten der Prozessausführung für das Controlling von Prozessen genutzt werden [30] (A4). Der Ansatz basiert auf einem Referenzmetamodell für die bei der Prozessausführung erzeugten und verarbeiteten Daten. Eine Bewertung der Prozessausführungen wird hierbei im Rahmen eines multidimensionalen Zielsystems vorgenommen (A2). Weitergehende ökonomische Bewertungen der betrachteten Prozesse werden jedoch nicht adressiert. Die Auswertung der Quellen zeigt, dass Arbeiten zum Prozesscontrolling überwiegend für die Steuerung von Prozessen entwickelt werden [19], während ein Prozesscontrolling zum Zeitpunkt der Prozessgestaltung in den meisten Arbeiten gänzlich unberücksichtigt bleibt. Vielmehr wird von existierenden Prozessen ausgegangen, die nach Prinzipien eines Regelkreismodells zu überwachen und zu modifizieren sind [4]. Die Anforderungen an ein wertorientiertes Prozessmanagement wer- 258 den nur teilweise und insgesamt unzureichend unterstützt. Die Beiträge erfüllen jeweils höchstens zwei der Anforderungen hinreichend. Am ausgeprägtesten erscheint die Wertorientierung im Vorgehensmodell von BECKER ET AL., in dem sämtliche Anforderungen zumindest teilweise berücksichtigt werden. Im Folgenden wird diskutiert, welche zukünftigen Herausforderungen sich stellen. 5. Explikation zukünftigen Forschungsbedarfs Der zukünftige Forschungsbedarf soll exemplarisch am Vorgehensmodell von BECKER ET AL. veranschaulicht werden [3]. Das Vorgehensmodell unterscheidet die Phasen Projektmanagement, Modellierung vorbereiten, Strategie und Ordnungsrahmen entwickeln, Ist- bzw. Sollmodellierung und -analyse, prozessorientierte Aufbauorganisation, Neuorganisation und kontinuierliches Prozessmanagement. Genauer zu untersuchen ist nun, inwieweit die einzelnen Phasen den Anforderungen (A1) bis (A5) genügen. Auf dieser Grundlage wird dann der Erweiterungs- und Forschungsbedarf für die einzelnen Phasen skizziert. Eine Übersicht gibt Abbildung 4. Abbildung 4: Explikation zukünftigen Forschungsbedarfs Bereits in der Modellierungsvorbereitung ist eine Vielzahl an Entscheidungen zu fällen, die hinsichtlich ihrer wertmäßigen Konsequenzen in einer spezifischen Unternehmenssituation abzuschätzen sind. Hierzu zählen die Definition von Modellierungsgegenstand, -perspektiven und -methoden sowie die Auswahl von Modellierungswerkzeugen. Zu planen sind auch Aufwendungen für die Durchführung von Akzeptanztests, zum Aufbau von Methodenkompetenzen, zur Definition und 259 Anpassung organisationsinterner Modellierungsstandards oder zur Auswahl, Beschaffung und Anpassung von Modellierungswerkzeugen (A5). Dabei wird bereits die Notwendigkeit zur Einbeziehung unterschiedlicher Stakeholder-Perspektiven und Zielsysteme ersichtlich (A1 & A2). Ein wesentlicher Aspekt ist auch die Bewertung des für diese Phase anzusetzenden, personellen und zeitlichen Aufwands (A2). Erfahrungen mit Modellierungsprojekten in der Praxis zeigen, dass relativ viel Zeit auf die Auswahl eines Modellierungstools verwendet wird, während der Einfluss dieser Auswahlentscheidung auf den durch Reorganisationsmaßnahmen zu erzielenden Wert kaum nachzuweisen ist. Methodisch besteht hier die Herausforderung, Entscheidungsträger zu groben Abschätzungen zu befähigen, deren Werte im weiteren Verlauf der Prozessgestaltung rollierend fortgeschrieben und detailliert werden können. In der Phase Entwicklung von Strategie und Ordnungsrahmen werden Prozessreorganisationsmaßnahmen in einen übergeordneten organisatorischen Zusammenhang gebracht. Ausgehend von strategischen Überlegungen und daraus abgeleiteten Effizienzzielen für strategische Organisationsbereiche werden in dieser Phase grobe Prozessstrukturen und -ziele definiert. Hier stehen Fragen eines sog. Alignments im Mittelpunkt, die durch eine entsprechende wertmäßige Betrachtung zu ergänzen sind. Insbesondere die Wirkung der auf einzelne Prozessbereiche fokussierten Maßnahmen auf andere Unternehmensbereiche und übergeordnete Zielwerte ist wesentlich (A5). Eine besondere Herausforderung ist die Flexibilität der zu entwickelnden Methodensysteme, da in Abhängigkeit der strategischen Vorgaben auch eine Prüfung (und ggf. Ausdifferenzierung) des Zielsystems der Bewertung vorzunehmen ist (A1 & A2). Insgesamt kann ein wertorientiertes Prozessmanagement hier wichtige Entscheidungsunterstützung bei der Auswahl der im Weiteren zu untersuchenden Prozessbereiche liefern. Diese Entscheidungen sind wesentlich, da hier Rahmenbedingungen festgelegt werden, die maßgeblich über die Wirtschaftlichkeit der späteren Phasen entscheiden. Zu entwickeln sind etwa multikriterielle Verfahren, um Prozessbereiche aus unterschiedlichen Zieldimensionen im Hinblick auf langfristige Reorganisationskonsequenzen zu bewerten (A2 & A3). Im Rahmen der Istmodellierung und -analyse werden die aktuellen Prozessstrukturen detailliert erfasst und Schwachstellen sowie Verbesserungspotenziale aufgezeigt. Der Fokus liegt auf der strukturellen Dokumentation des Istzustands. In Ergänzung zu qualitativen Beurteilungen sind Verfahren zu entwickeln, die helfen, Prozesse im Ist-Zustand im Hinblick auf unterschiedliche Anspruchsgruppen und Zielinhalte zu bewerten (A1 & A2). Ein Beispiel liefern Arbeiten zur monetären Bewertung von Prozessen [29], die nach den hier beschriebenen Anforderungen um Wertansätze in weiteren Zieldimensionen und -fristigkeiten zu ergänzen sind (A2 & A3). Das gleiche Instrumentarium ist für die Phase der Sollanalyse zu verwenden. Hier können entsprechend die Mehrwerte alternativer Sollmodelle sichtbar gemacht werden, um eine Auswahlentscheidung alternativer Reorganisationsmaßnahmen zu beurteilen. Eine wesentliche Herausforderung bei der Gestaltung dieser Methoden liegt in der Einfachheit der Bewertung. Grundsätzlich besteht ein „trade-off“ zwischen der Fundiertheit und der Einfachheit von Methoden für die Bewertung von Prozessalternativen. In gewisser Weise „mustergültige“ Lösungen erfordern in der Praxis die Planung einer Vielzahl an Daten. Hier ist berechtigterweise die Frage nach dem Kosten-Nutzen-Verhältnis der Planung selbst zu stellen. Eine bloße Vereinfachung der Methoden, etwa durch eine einperiodige und somit statische Betrachtung, läuft aber Gefahr, den Entscheidungstatbestand unzureichend zu erfassen und durchaus auch zu Fehlentscheidungen zu führen. Die Herausforderung besteht also darin, zwar Vereinfachungen vorzunehmen, dies jedoch unter Berücksichtigung der methodischen Fundiertheit. Auch in den Folgephasen der prozessorganisierten Aufbauorganisation, der Prozesseinführung (Implementierung) und dem kontinuierlichen Prozessmanagement sind eine Vielzahl an Entscheidungen zu treffen, für die ein wertorientierter Ansatz Entscheidungsunterstützung liefern kann. 260 Hier wird deutlich, dass in den einzelnen Phasen zum Teil gleiche, zum Teil aber auch spezifische Methoden benötigt werden. Eine wichtige übergeordnete Herausforderung wird daher in der Methodenintegration bestehen. 6. Zusammenfassung und Ausblick In diesem Beitrag wurde argumentiert, dass die wertmäßigen Entscheidungskonsequenzen der Prozessgestaltung mit den bisherigen Methoden im Geschäftsprozessmanagement nur unzureichend beurteilt werden können. Der Beitrag ist daher als ein Plädoyer für eine zunehmende Wertorientierung im Prozessmanagement zu verstehen. Auf Grundlage der Koalitionstheorie wurden genauere Anforderungen an ein wertorientiertes Geschäftsprozessmanagement abgeleitet. Im Rahmen einer State-of-the-Art-Analyse bestehender Arbeiten im Geschäftsprozessmanagement wurde aufgezeigt, dass diese Anforderungen nur ansatzweise und insbesondere nicht umfassend erfüllt werden. Auf dieser Grundlage konnten Anhaltspunkte zukünftiger Forschungsarbeiten auf dem Gebiet eines wertorientierten Prozessmanagements aufgezeigt werden. Dieser Beitrag soll dazu aufrufen, ein solches Forschungsgebiet zu begründen. Sicher ist, dass weitere Arbeiten notwendig sind, die auch eine Ausweitung der hier durchgeführten Literaturanalyse beinhalten. Ebenso ist zu untersuchen, welche zusätzlichen Theorien einen Erkenntnisbeitrag liefern können. Im Hinblick auf die Methodengestaltung kommt gerade der Integration von Arbeiten auf den Gebieten Wirtschaftsinformatik und Controlling eine besondere Bedeutung zu. Erkenntnisgewinne sind auch aus der praktischen Erprobung bereits vorliegender und noch zu entwickelnder Methoden zu erwarten. Literatur [1] AICHELE, C., Kennzahlenbasierte Geschäftsprozessanalyse, Berlin et al. 1997. [2] ALLWEYER, T., Geschäftsprozessmanagement. Strategie, Entwurf, Implementierung und Controlling, Bochum 2005. [3] BECKER, J.; KUGELER, M.; ROSEMANN, M. (Hrsg.), Prozessmanagement. Ein Leitfaden zur prozessorientierten Organisationsgestaltung, 5. Aufl., Berlin et al. 2005. [4] BECKER, J.; SCHÜTTE, R., Handelsinformationssysteme. Domänenorientierte Einführung in die Wirtschaftsinformatik, 2. Aufl., Frankfurt am Main 2004. [5] BECKER, R.; SCHMIDT, H., Teamorientierte Geschäftsprozessoptimierung, in: Horváth&Partners (Hrsg.), Prozessmanagement umsetzen. Durch nachhaltige Prozessperformance Umsatz steigern und Kosten senken, Stuttgart 2005, S. 107–122. [6] BERNARD, C. H., The Functions of the Executive, Cambridge 1938. [7] BIFFL, S., AURUM, A., BOEHM, B., Value-Based Software Engineering, Springer, Berlin 2005. [8] COOPER, H. M., Synthesizing Research – A Guide for Literature Reviews, 3. Aufl., Thousand Oaks et al. 1998. [9] COPELAND, T.; KOLLER, T.; MURRIN, J., Unternehmenswert. Methoden und Strategien für eine wertorientierte Unternehmensführung, Campus Verlag, Frankfurt/New York 2002. [10] CORSTEN, H. (Hrsg.), Grundlagen und Elemente des Prozessmanagement, in: Schriften zum Produktionsmanagement, Bd. 4 (Kaiserslautern 1996). [11] CYERT, M. R.; MARCH, J. G., A Behavioral Theory of the Firm, Englewood Cliffs, New Jersey et al. 1963. 261 [12] DAVENPORT, T. H., Process Innovation. Reengineering Work Through Information Technology, Boston 1993. [13] FETTKE, P., State-of-the-Art des State-of-the-Art – Eine Untersuchung der Forschungsmethode "Review" innerhalb der Wirtschaftsinformatik, in: Wirtschaftsinformatik, 48(4), 2006, S. 257–266. [14] FREEMAN, R. E., Strategic management: a stakeholder approach, Boston 1984. [15] GIAGLIS, G. M.; PAUL, R. J., It`s Time to Engineer Re-engineering. Investigating the Potential of Simulation Modelling for Business Process Redesign, in: B. Scholz-Reiter; E. Stickel (Hrsg.), Business Process Modelling, Berlin et al. 1996, S. 313–332. [16] GREGOR, S., The Nature of Theory in Information Systems, in: Management Information Systems Quarterly (MISQ), 30(3), 2006, S. 611–642. [17] GROB, H. L.; VOM BROCKE, J., Controlling des Designs von Logistikprozessen, in: H. Baumgarten; J. Becker; H. P. Wiendahl; J. Zentes (Hrsg.), Logistik Management, Springer Expertensystem, Berlin 2004, S. 1–26. [18] HAMMER, M.; CHAMPY, J., Reengineering the Cooperation. A Manifesto for Business Revolution, Harper, New York 1993. [19] HESS, T.; BRECHT, L., State of the Art des Business Process Redesign. Darstellung und Vergleich bestehender Methoden, 2. Aufl., Wiesbaden 1996. [20] HORVATH&PATNERS, Prozessmanagement umsetzen. Durch nachhaltige Prozessperformance Umsatz steigern und Kosten senken, Stuttgart 2005. [21] JOHNSON, T. H.; KAPLAN, R. S., Relevance Lost. The Rise and Fall of Management Accounting, Boston, Massachusetts 1987. [22] JONES, M. T.; ELLIOTT, R.; BALL, D. Z.; HEIN, G. F., Using Simulation as a Tool for Business Process Innovation, in: Proceedings of the Winter Simulation Conference, Piscataway, New Jersey 1993. [23] KAPLAN, R. S.; NORTON, D. P., The Balanced Scorecard. Measures that Drive Performance, in: Harvard Business Review, 70(1), 1992, S. 71–79. [24] RICHTER-VON HAGEN, C.; STUCKY, W., Business- Process und Workflow Management. Prozessverbesserung durch Prozess Management, Stuttgart et al. 2004. [25] SALFELD, R.; COENENBERG, A. G., Wertorientierte Unternehmensführung: Vom Strategieentwurf zur Implementierung, 2. Aufl., Schäffer-Poeschel, Stuttgart 2007. [26] SIMON, H. A., Administrative Behavior. A Study of Decision-Making Processes in Administrative Organizations, New York 1949. [27] VOM BROCKE, J., Service Portfolio Measurement. Evaluating Financial Performance of Service-Oriented Business Processes, in: International Journal of Web Services Research (IJWSR), 4(2), 2007, S. 1–32. [28] VOM BROCKE, J.; BUDDENDICK, C., Alignment Controlling – Der Beitrag einer wertorientierten Prozessgestaltung, in: Proceedings of the Multikonferenz Wirtschaftsinformatik (MKWI), München 2008. [29] VOM BROCKE, J., MENDLING, J., RECKER, J., Value-Oriented Process Modelling. Towards a Financial Perspective on Business Process Redesign. Paper presented at the 14th Americas Conference on Information Systems (AMCIS 2008), Toronto, CA. [30] ZUR MÜHLEN, M., Workflow-based Process Controlling. Foundation, Design, and Application of Workflow Driven Process Information Systems, Berlin 2004. 262 COLLABORATIVE SERVICES / SERVICES FÜR DIE KOOPERATION Serviceorientierung wird auch für die Unterstützung der Zusammenarbeit zwischen Menschen, Gruppen und Organisationen wichtiger. Als Service wird (gemäß ITIL V3, vereinfacht) ein Bündel aus Applikationen, Hardware, Personen, Organisationen und unterstützenden Dienstleistungen verstanden, welches Anwendern zur Verfügung gestellt wird. Wir sind interessiert an Einreichungen, die neues Wissen zu Kooperationssystemen, konkret der Entwicklung, Einführung, Nutzung und Evaluation von Services zur Unterstützung von Zusammenarbeit erarbeiten, sowie innovative Konzepte und Systeme aus diesem Bereich vorstellen. Diese betrachteten Kooperationssysteme können professionell oder von Endbenutzern entwickelt sein. Der Bezug zu Organisationen sollte deutlich sein. Leitungsgremium: Norbert Gronau, Universität Potsdam Michael Koch, Universität der Bundeswehr München Gerhard Schwabe, Universität Zürich (Federführender) Volker Wulf, Universität Siegen Programmkomitee: Andrea Back, Universität St. Gallen Jörg Beringer, SAP Steffen Budweg, Fraunhofer FIT Roman Englert, Telekom Deutschland Joerg Haake, FernUniversität Hagen Bettina Hoser, Universität Karlsruhe Remko Helms, Utrecht University Niederlande Harald Katzmair, FAS research, Austria Ralf Klamma, Rheinisch-Westfaelische Technische Hochschule Aachen Jan-Marco Leimeister, Universität Kassel Stephan Lukosch, FernUniversität Hagen Florian Matthes, Technische Universität München Jasminko Novak, Universität Zürich Volkmar Pipek, Universität Siegen Wolfgang Prinz, RWTH Aachen und Fraunhofer Kai Riemer, Universität Münster Gerold Riempp, European Business School Deutschland Johann Schlichter, Technische Universität München Stefan Uelner, T-Systems Jan vom Brocke, Hochschule Liechtenstein PRESENCE SIGNALLING IN UNIFIED COMMUNICATION SYSTEMS – A FRAMEWORK FOR CUSTOMISATION IN CONTEXT Kai Riemer, Stefan Klein1 Abstract In this paper we present Unified Communications (UC) as a new class of communication systems, marketed by vendors as a means for integrating communication media and creating presence awareness. Designed as complex infrastructures, UC systems enfold their full potential when being customised to a particular social context. In doing so, the technology allows creating contextspecific presence signalling solutions. The main contribution of this paper is a conceptualisation of the various design questions relevant in the customisation of UC presence signalling aspects. To this end, we present a seven-step process framework as guidance for implementers of UC infrastructures. 1. Introduction Unified Communications (UC), as a new and emerging class of systems, is based on the integration of communication media (e.g. Instant Messaging and Voice-over-IP (VoIP) telephony) with presence availability signalling. Being the result of a convergence of the telecommunications and the software market, a range of prominent vendors from both domains are currently entering the market with UC solutions, e.g. Alcatel, Avaya, Cisco, IBM, Nortel, Microsoft, Oracle, or Siemens. UC systems are designed as open infrastructures that allow (and require) customisation and adaptation in context. One claim of UC vendors is to take presence signalling to a new level, e.g. by applying the concept across media classes and by embedding presence signalling in the context of business processes and third party software applications. However, UC is still in its infancy with systems not yet living up to their promises; empirical examples of UC applications in organisations are rare and show that many envisioned features are yet to be implemented. Hence, research at this stage needs to be experimental or conceptual. In this paper, we explore the complexities of presence signalling in UC systems. We take the standpoint of implementers who want to adapt UC in context and create context-specific ways of presence signalling. Owing to the complexity of UC systems, many design questions can be identified that need to be taken into account. We have structured a range of complexities in a framework. Before we discuss the design and decision areas in the seven phases of our framework, we first motivate our study by briefly reviewing typical communication challenges in contemporary workplaces and by discussing the role of presence signalling in creating awareness in distributed 1 University of Münster, Department of Information Systems, Leonardo-Campus 3, D-48149 Münster 265 contexts. We then introduce UC and its main building blocks, before the main section presents our framework. 2. Presence Awareness in distributed work 2.1. Communication challenges Work practices in organisations have been undergoing significant changes over the past years, which led to new virtual forms of organising and increased distributed collaboration [6,22,25,30]. At the same time, this development is driven by the emergence of new communication technologies and devices, which on one hand drive organisational decentralization [26] and on the other hand enable people to work across a variety of boundaries [38]. At the same time, new communication channels (e.g. Voice-over-IP telephony, Instant Messaging) have mushroomed, which led to a heterogeneous accumulation of technologies that are available to the average user [21]. Many people today do not just possess one phone number or IM account, but rather they use several channels to communicate with their peers [e.g. 34]. This escalating variety of channels and devices, as well as the ever increasing messaging activity [13] increase drastically the communicative complexity for both initiator and recipient of a communication request. For initiators situations are characterised by a high uncertainty as they have to think about the recipient’s context, the appropriate channel or device, and the relevant contact details in terms of accounts and phone numbers [16]. Also, availability of others in distributed contexts is often a serious problem. For recipients the situation creates interruptions and disturbances as asymmetries of interaction become more likely in distributed contexts [15,36]. People are potentially confronted with a level of interaction that might exceed their personal preferences causing interaction overload. 2.2. Awareness of presence availability A main shortcoming in the above-described situation is a general lack of awareness of other people’s location, context, activities, and availability for communication. In traditional workplaces awareness is generally taken for granted and therefore seldom discussed at all [9,27]. Awareness is “an understanding of the activities of others, which provides a context for your own activity” [8, p. 107]. In this paper we are specifically interested in the awareness of other people’s presence, i.e. their availability for communication. Without presence awareness, availability of people cannot be easily determined and interruptions though communications requests are more likely. Through ICT people have the means to become available for others. Empirical evidence suggests that technology can be used to facilitate awareness of presence (e.g. location and context) and of presence availability (e.g. availability for communication) and thus mitigate some of the mentioned communication problems [31]. 2.3. The role of technology in awareness creation While it has been argued that awareness can never be a property of technology itself [32], because it results from a learned and skilful action and thus is the result of shared social practices [10,11,35], technologies nevertheless play an important role in enabling and supporting the creation of awareness. ICT has become an integral part of practices of people who use features designed to specifically support awareness creation or appropriate others in ways that makes them useful for doing so. One technology that is marketed with the label of presence awareness attached to it, and which is designed for addressing the above discussed communication issues, is Unified Communications (UC) technologies. UC systems can be interpreted as complex infrastructures, 266 whose features need to be adapted to and interpreted in social context for them to enfold their full potential [28]. Against this backdrop the main contribution of this paper is to provide a structured overview of design-decisions in the process of customising presence availability signalling features when applying UC in context. Before we present a framework for structuring the steps necessary in the customisation of presence availability signalling, we briefly introduce this new class of systems and give an overview of its features and characteristics. 3. Unified Communications Systems Being a result of market convergence, UC has its roots in both the telecommunications and the groupware market. Consequently, UC systems, as complex infrastructures, integrate groupware functionality with (IP-based) communications media (computer-based telephony, voice, and video services) with presence technologies and business applications [34,16,3,23]. 3.1. UC building blocks The general idea of UC systems is to help people juggle with their communication requests in the face of interaction overload [24] and to improve people’s accessibility by providing presence availability information and by integrating media and devices [13]. As such, UC is the product of the integration of various components and features. First of all, UC is based on the idea of media integration (unified communications): Devices are registered within the system and users are aided by a communication middleware in their management through a rule-based coordination and filtering system. Typically such systems provide users with a universal phone number, which finds them wherever they wish to be found [13,33]. On the technical level, this media integration is based on IP-technology [33,37]. Moreover, one of the main features of UC lies in the provision of presence information in regards to the availability of the user and his/her media and communication devices (see below). Thirdly, UC systems unfold their strengths when integrated within the context of the user, in particular with organisational processes and third party business applications (e.g. ERP systems). A core idea thus is to circumvent the need to pre-schedule communication and to solve the users’ information needs by immediately allowing them to communicate [16]. 3.2. Presence signalling in UC systems The signalling of presence availability is a defining feature of UC, which distinguishes it from traditional synchronous communication technologies. Much like the increasingly popular Instant Messaging (IM) tools, UC systems come with a presence awareness capability [4] or presence management feature [17]. The idea of this presence information is for a user to signal to the initiator of a communication act, independent of a recipient’s physical location, the availability for interaction, i.e. the “ability and willingness to communicate” [7, p. 84]. Two characteristics set apart corporate UC systems from simple IM tools: openness and complexity. UC systems are complex infrastructures that on the one hand allow adaptation and customising in context, in order for UC implementers to create context-specific UC solutions that become embedded with the workspaces of corporate users. On the other hand, UC infrastructures bring in a range of means to design complex presence availability signalling mechanisms. While UC systems are seen by many vendors as a solution to the above portrayed problems, we argue that UC, as open, flexible infrastructures, require adaptation and a certain degree of customising in context in order to live up to their promises. In the following, we present ways in which UC infrastructures can be adapted by moulding their features in the process of implementing the technology. 267 4. Framework for customising UC presence signalling The main contribution of this paper is a structured overview of design decisions likely to be encountered by those who want to customise or adapt to an organisational context the presence signalling aspects of UC infrastructures. In doing so however, we will not delve into the richness of signalling practices that are likely to emerge in context as the result of tool appropriation by users, for a related study see [29,31]. We approach our exploration of signalling design questions from the perspective of implementers and introduce a process framework, which presents design areas that, as we argue, should be considered during the process of adapting UC infrastructures to a specific organisational context (see table 1). The process begins with more technical or systems design considerations and then moves gradually to the more social/contextual design decisions. Step Description Design question 1 Generating presence availability information How are user states determined? 2 Defining the status types What are the status categories (states) available to users? 3 Presenting the signals How are signals conveyed/visualized within use context? 4 Enriching the availability status information How can the availability status be complemented? 5 Embedding in context What objects will the status signals be attached to? 6 Differentiating for different recipients Who is allowed to see what kind of status? 7 Supporting UC adoption in context How can users be supported in adopting signalling? Table 1: Process steps of our presence signalling framework 4.1. Step 1: Generating presence information In a first step, UC implementers have to decide on how the presence availability information is generated, i.e. is it automatically determined by the UC system, e.g. by using device states, or is it based on explicit user entries? In its most simple form, the presence status is derived from the user being logged on to the system [2]. As such, the status merely signals whether the user’s computer system is currently online or offline [5]. In addition, in UC systems presence information can originate from all devices a user possesses [14]. Since every communication device needs to be registered with the UC system, information of the current technical availability of all user devices exists (e.g. IM, cell phone, landline/IP phones). This information can by used as a proxy for user availability. However, the availability of devices serves only as a fairly inaccurate proxy. Consequently, one important factor in applying availability signalling is exploring and determining ways in which more accurate information can be (automatically) gathered by the system in a given context [39]. A further source is monitoring and interpreting user activities within the context of the UC system. Being based on IP-technology the system can derive the technical states of phones and hence deduce current user activity. Moreover, the system might be able to recognize from which device a user is logged on to the system thus conveying that a user is currently travelling (e.g. when being logged in from a PDA device) [20]. Also, various other sensors (e.g. Smart cards) can be used to track user activity and infer user availability (e.g. the user entering a meeting room). Finally, the availability states can be explicitly selected by the user from a set of standard states [12]. 268 4.2. Step 2: Defining presence states Having introduced several ways to determine and automatically infer user availability states, the next decision area is defining the actual range of states available for signalling. Typical IM and UC systems usually come with a range of around seven different states (see figure 1 for an example). Figure 1: Presence states in Skype™ and Microsoft Live Messenger™. While all UC systems come with a range of predefined states, most systems provide means to override the default states in order to establish a custom-made (context-specific) way of signalling. In doing so, we propose that presence states be selected according to the following quality criteria: completeness, semantic clarity, mutual exclusiveness, and simplicity. The range of available states should be complete in a sense that for every situation one state exists that signals best the user’s availability in this situation to the user’s peers. This does not mean that UC systems should provide a long list of different states for every possible situation, because this is in conflict with the requirement of simplicity. We reason that only a short and comprehensive list of signals can be grasped easily by the average user and thus be incorporated in their daily work practices. For doing so, the list of states also needs to be semantically clear; the user should be able to immediately understand what a status means and when to use it. It should also be unambiguous in a sense that consensus on when/how to use a certain state is easily (intuitively and naturally) be achieved within the relevant peer group. For example, in the Live Messenger™ example (figure 1) it is not immediately clear how the states ‘be right back’, ‘away’ and ‘out to lunch’ (Live Messenger) should be interpreted in terms of the time span the user is likely to be unavailable. Also, states such as ‘away’ and ‘out to lunch’ are not mutually exclusive – a user who is out to lunch is also ‘away’. In order to make both signalling and the interpretation of signals easier and clearer, the users should know exactly what state to choose in a given situation. And in order to achieve a main goal of UC – improving availability for communication – it is necessary for users to be able to infer from a presence status the time span for which a user is likely to be unavailable. A trade-off exists between the granularity (or specificity) of states and its average correctness in context. For example, in an extreme form the system might allow users to specify (e.g. in minutes) the exact time s/he is likely to be unavailable. The complexity and interconnectedness of a typical office or work setting however renders impossible the prediction of such exact time spans. The likely consequence is that most signals in context would be incorrect and thus perceived as unreliable, with possible negative ramifications for system adoption. Hence, we reason that the more specific the range of states is in terms of time, the more likely it is to signal incorrectly. Consequently, the actual range of states should convey a sense of time span for unavailability but in a more general sense. 269 4.3. Step 3: Presenting the signals The next step is designing the ways in which the states are conveyed to users within the workplace context. Several ways exist in which signals can be presented to the user: states can be visualized using iconographic designs and/or colour [12], sound might be used to convey certain status changes. In IM tools the colour green seems to be the dominant choice to convey availability, while red signals unavailability. This colouring obviously relates back to traffic light colours; using such a colour code for signalling has the advantage that it is inter-culturally unambiguous. Again, it would be preferable to have signals (icons/colour dots) that are easily understandable and selfexplanatory in order to reduce cognitive burden for the user and allow for a seamless adoption process. Drawing on well-established colour codes and metaphors/icons serves as a good rule of thumb in this decision area. In addition to visualizing the different states, the changes between states can also be signalled using visual or sound signals. For example, some IM tools indicate with small pop-up windows (or a sound) whenever a contact in the user’s buddy list becomes available (i.e. logs on to their computer). However, in many contexts this might cause too many unwanted interruptions for the average user; it might thus be offered as an additional feature used to be notified when one is waiting for another user to become available. 4.4. Step 4: Enriching states with context information Up to now, we have introduced design areas concerned with determining, defining and presenting user availability states in a way that is, in its most simple form, well-known from IM tools. However, the idea of providing as presence information one status for every user (e.g. ‘away’), is rather limiting in terms of estimating the time-span for the user to become available again. Hence, we can complement the availability status with other information, which can be made available within UC systems. Ageing information can be used to determine the age of a current signal. For example, when a user signals ‘be right back’, other users expect her/him to become available within a reasonably short time-span. However, they do not know how old the signal is. By adding ageing information, which reveals the time since the status was changed, users are able to better assess the actual availability. Another way to improve status interpretation is to provide access to (selected) calendar entries. When a user signals ‘away’ and her/his calendar entry for this time shows that s/he is in a meeting, others can much better anticipate future availability than without the additional calendar information. A different kind of context information is location data. Location data provides users with awareness of users’ whereabouts, which also aids in assessing user availability. Researchers have demonstrated ways to infer and convey location information in office settings [19]. In flexible office settings that allow people who are travelling frequently (e.g. sales people,) to book a desk for a day (so called non-territorial office, hotelling or desk-sharing concept) [18,1], the UC system can signal to other users the actual desk the user is working at in order to make it easier to arrange for ad-hoc meetings. A simple yet effective way to provide additional information about one’s availability is a short text message, a so-called presence messages [40]. Users can type in a short message that is then listed alongside the presence availability status explaining absence and future availability. Finally, in addition to the user presence status, which signals general availability of the user, UC infrastructures allow inferring and presenting separate availability states for the different devices or media channels available to contact a user. For example, designers might decide to provide availability data on the device level, i.e. data on whether the mobile phone is currently booked in to the system, or whether the IP phone is currently online or engaged. 270 4.5. Step 5: Embedding of signalling in context So far, we have discussed signalling on the user level (and in relation to his/her devices). In a next step, these user availability states can be embedded within the group and business process context. For example, user states can be aggregated on the group level in order to provide a sense of group availability; i.e. a maximum status shows ‘available’ when all group members are available within the sphere of the UC system, e.g. to initiate a conference call. The minimum status shows ‘available’, when at least one of the group members is available. This status can be used when the user “would like to talk with someone with similar interest or expertise but don’t care who the specific individual is” [2, 12]. Presence states can also be attached to and be aggregated on the level of almost any object available in the electronic workspace of users, i.e. wherever objects have ownership or are otherwise related to people and can thus inherit their presence states. For example, in a hospital scenario, presence information of authors of laboratory files or patients records can indicate their accessibility for urgent call-backs by the doctor on duty. Through aggregation on the file level, the doctor might be able, in case of an emergency, to get in immediate contact with specialists, who can give background information related to the particular file or to otherwise consult with these colleagues. 4.6. Step 6: Differentiate states for various recipients So far, we have mainly taken the perspective of the initiator who wants to determine people’s availability (or the time of non-availability). We have asked questions in regards to what kinds of presence information might be needed in a particular context, where to gather this information, how and where in the work context this information might be presented. Now, we will turn to the perspective of the one who is signalling availability. The first question in this area is to determine whether signals should have global validity or whether people should be able to restrict certain signalling to (sub)groups. When signalling, people sometimes need to convey certain information (e.g. with regards to location or tasks) to some people within their peer group, but not to others. Also, people, in some situations, might want to be available for some group members, while at the same time signal unavailability towards the rest. Hence, UC implementers need to explore, if such a differentiated signalling is needed in a particular context and how to implement it. A solution seems to be a concept, in which the user defines different groups for which he/she can (but needs not to) signal different states of availability. Such a group concept might be modelled as user circles with the inner circle having access both to the most accurate information and to more context information (see step 4). An outer circle then only sees a basic presence status, which, if required, can be set to signal unavailability to temporarily reduce communication load, e.g. in tight project situations. 4.7. Step 7: Support adoption of signalling in context This last step in our framework again takes the perspective of the user who actively signals availability. In many situations the user has to actively change the states in the UC system in order to truly reflect current availability. We acknowledge that signalling can be cumbersome and that users might neither be able nor willing to change significantly the way they work in order to incorporate signalling in their routines. Hence, UC implementers need to explore ways in which the user can be supported by the system and in which the changing of states can be attached to existing user routines without the user having to pay explicit attention to the changing of the status 271 (piggyback routines). In the literature authors have argued for a need to support signalling “in a way that uses human capability to peripherally process non-attended aspects.” [39, 298] One such way is using sensing devices. Siemens AG for example, as part of their research on the use of their Openscape UC system, have developed a prototype extension which allows the user status to be changed on the basis of a Bluetooth connection between user computer and the user’s cell phone. Users who carry a Bluetooth-capable mobile phone can activate the service and link it with their computer; the UC extension then monitors this connection and changes the availability status to signal ‘(temporal) unavailability’ whenever the user leaves the vicinity of the computer. Another technology again uses the cell phone; it piggybacks with the user routine of muting the ring tone whenever entering a meeting. A service can send a short message (SMS) to the UC server initiating the corresponding status change. 5. Conclusion and outlook Despite a boom of new communication services and devices individual and organisational communication problems have increased with the number of communication partners across projects and time zones and with a steep increase in computer-mediated communication encounters. The industry appears to respond to this situation with more devices, more services, and even more features (‘more of the same’). UC systems are a manifestation of this trend. However, extending communication options (i.e. by integrating media and combining it with presence signalling) in itself does not automatically solve communication problems. Rather, these infrastructure technologies need to be adapted and interpreted in a concrete social context. Our framework is meant to elaborate on design parameters likely to be encountered by UC implementers when confronted with the task of applying UC to a specific organisational setting. We have presented a structured overview of the various complexities encountered by those who customise UC presence signalling aspects in context. In doing so, we have discussed in detail seven design and decision areas, which describe the complexities of presence signalling in UC systems when implemented in a social context. While our framework can be used by UC implementers as an overview and a first guide to approaching the customisation and embedding of an UC system in context, at the same time the framework points to the need to carry out empirical studies to better understand signalling and its implications on people and their work practices, i.e. once actual UC implementations become available in organisations. The framework has been the result of mainly conceptual work, but it is grounded in a series of design and case studies as well as workshops with representatives of UC vendors and designers. Nevertheless, it represents only a first step and a starting point in exploring the richness and challenges of UC as a technology when being applied in organisations. 6. References [1] BJERRUM, E.; BODKER, S., Learning and living in the 'New Office'. Proceedings of the Eighth European Conference on Computer-Supported Cooperative Work, 14-18 September 2003, Helsinki, Finland, 199-218. [2] BOYER, D. G.; HANDEL, M. J.; HERBSLEB, J. D., Virtual Community Presence Awareness, in: SIGGROUP Bulletin. 19, 3 (1998), 11-14. [3] BURTON, J.; PARKER, M.; PLEASANT, B.; VAN DOREN, D., Will 2007 be the Year of Unified Communications, in: Business Communications Review, March (2007), 20-26. [4] CAMERON, A. F.; WEBSTER, J., Unintended consequences of emerging communication technologies: Instant Messaging in the workplace, in: Computers in Human Behavior. 21 (2005), 85-103. 272 [5] CARMONA, J., Consequences of IM on Presence Awareness and Interruptions, in Kock, N. (ed.) Encyclopedia of E-Collaboration Information Science Reference, 2008, 102-106. [6] CIBORRA, C. U.; SUETENS, N. T., Groupware for an Emerging Virtual Organization, in Ciborra, C. (ed.) Groupware & Teamwork: Invisible Aid or Technical Hindrance?, Chichester, John Wiley & Sons, 1996. [7] DE POOT, H.; MULDER, I.; KIJL, B., How do Knowledge Workers cope with their Everyday Job?, in: eJOV The Electronic Journal for Virtual Organizations and Networks. 9 (2005), 70-88. [8] DOURISH, P.; BELLOTTI, V., Awareness and Coordination in Shared Workspaces, in Proceedings of Conference on Computer-Supported Cooperative Work (CSCW'92). Toronto, 1992, 107-114. [9] GUTWIN, C.; GREENBERG, S., A Descriptive Framework of Workspace Awareness for Real-Time Groupware, in: Computer Supported Cooperative Work. 11, 4 (2002), 411-446. [10] HEATH, C.; LUFF, P., Collaboration and Control: Crisis Management and Multimedia Technology in London Underground Line Control Rooms, in: Computer Supported Cooperative Work. 1, 1 (1992), 24-48. [11] HEATH, C.; SVENSSON, M. S.; HINDMARSH, J.; LUFF, P.; VOM LEHN, D., Configuring Awareness, in: Computer Supported Cooperative Work. 11, 4 (2002), 317-347. [12] HERBSLEB, J. D.; ATKINS, D. L.; BOYER, D. G.; HANDEL, M.; FINHOLT, T. A., Introducing Instant Messaging and Chat in the Workplace, in: chi letters. 4, 1 (2002), 171-178. [13] HUTTON, J., Unified Communications - A potential cure for communications overload, in: CMA Management, October (2001), 50. [14] JENNINGS, C., Why Unified Communications need Presence Federation, in: Business Communications Review, December (2006), 18-22. [15] KAKIHARA, M.; SØRENSEN, C.; WIBERG, M., Fluid Interaction in Mobile Work Practice. Proceedings of the First Global Roundtable, Tokyo, Japan, May 29-30th 2002, 1-15. [16] LAZAR, I., Integrating Telephony, IM, Video and Mobility with Presence, in: Business Communications Review, June (2006), 28-31. [17] LI, D.; CHAU, P. Y. K.; LOU, H., Understanding Individual Adoption of Instant Messaging: An Empirical Investigation, in: Journal of the Association of Information Systems. 6, 4 (2005), 102-129. [18] LINDSTROM, J.; MOBERG, A.; RAPP, B., On the classification of telework, in: European Journal of Information Systems. 6 (1997), 243-255. [19] LJUNGSTRAND, P.; SEGERSTAD, Y. H., Awareness of Presence, Instant Messaging and WebWho, in: SIGGROUP Bulletin. 21, 3 (2000), 21-27. [20] LUO, X.; LIAO, Q., Using IM to Improve E-Collaboration in Organizations, in Kock, N. (ed.) Encyclopedia of E-Collaboration Information Science Reference, 2008, 680-685. [21] LYYTINEN, K.; YOO, Y., Research Commentary: Next Wave of Nomadic Computing, in: Information Systems Research. 13, 4 (2002), 377-388. [22] MALHOTRA, A.; MAJCHRZAK, A.; CARMAN, R.; LOTT, V., Radical Innovation Without Collocation: A Case Study at Boeing-Rocketdyne., in: MIS Quarterly. 25, 2 (2001), 229-249. [23] MOHAMED, A., Work together any place, any time, in: Computer Weekly, 3/6/2007 (2007), 38-40. [24] OLIVA, R. A., Instant Messaging comes of Age, in: Marketing Management. 12, 3 (2003), 49-52. 273 [25] ORLIKOWSKI, W. J., Knowing in practice: Enacting a collective capability in distributed organizing, in: Organization Science. 13, 3 (2002), 249-273. [26] RAHMAN, Z.; BHATTACHRYYA, S. K., Virtual Organization: A Stratagem, in: Singapore Management Review. 24, 2 (2002), 29-45. [27] RENNECKER, J., Promoting Awareness in Distributed Mobile Organizations: A cultural and technological challenge. Proceedings of the GROUP'05, Sanibel, Florida, USA, November 6-9. [28] RIEMER, K.; FRÖSSLER, F., Introducing Real-Time Collaboration Systems: Development of a Conceptual Scheme and Research Directions, in: Communcations of the Association of Information Systems (CAIS). 20 (2007), 204-225. [29] RIEMER, K.; FRÖSSLER, F.; KLEIN, S., Real Time Communication - Modes of Use in Distributed Teams. 15th European Conference on Information Systems (ECIS 2007). St.Gallen (CH): 286-297. [30] RIEMER, K.; KLEIN, S., Is the V-form the next generation organisation? An Analysis of Challenges, Pitfalls and Remedies of ICT-enabled Virtual Organisations based on Social Capital Theory, in: Journal of Information Technology (JIT). 23, 3 (2008), 147-162. [31] RIEMER, K.; KLEIN, S.; FRÖSSLER, F., Towards a Practices Understanding of the Creation of Awareness in Distributed Work. Proceedings of the Twenty Eighth International Conference on Information Systems, Montreal, Canada. [32] ROBERTSON, T., The Public Availability of Actions and Artefacts, in: Computer Supported Cooperative Work. 11, 3-4 (2002), 299-316. [33] ROSENBERG, A. M., Do you need to replace Enterprise Voice Mail?, in: Business Communications Review, October (2005), 36-41. [34] RYBCZYNSKI, T.; SHETTY, M., Unified Communications: Where the World is heading, in: Financial Executive, June (2005), 31-33. [35] SCHMIDT, K., The Problem with 'Awareness', in: Computer Supported Cooperative Work. 11, 3 (2002), 285298. [36] SØRENSEN, C.; MATHIASSEN, L.; KAKIHARA, M., Mobile Services: Functional Diversity and Overload. Proceedings of the New Perspectives On 21st-Century Communications, Budapest, Hungary, May 24-25th, 1-12. [37] STEINMANN, M. J., Unified communications with SIP, in: Queue. 5, 2 (2007), 50-55. [38] TIANFIELD, H.; UNLAND, R., IT enabling: essence of virtual organizations, in: International Journal of Information Technology & Decision Making. 1, 3 (2002), 367-370. [39] TOLLMAR, K.; SANDOR, O.; SCHÖMER, A., Supporting Social Awareness @ Work - Design and Experience. Proceedings of the CSCW'96, Proceedings of the Conference on Computer Supported Cooperative Work, Cambridge, MA, USA, 298-307. [40] TRAN, M. H.; YANG, Y.; RAIKUNDALIA, G. K., Supporting Awareness in Instant Messaging: An empirical Study and Mechanism Design. Proceedings of the OZCHI, Canberra, Australia, November 23-25. 274 SUPPORTING RESEARCH COLLABORATION – ON THE NEEDS OF VIRTUAL RESEARCH TEAMS Jens-Henrik Söldner, Jörg Haller, Angelika C. Bullinger, Kathrin M. Möslein1 Abstract Virtual teams are increasingly common in research as in corporate reality. While collaborative work in enterprises has received considerable attention, detailed understanding of collaborative work in virtual research teams is missing. To close this gap, we develop a model of the collaborative research process from idea generation to communication. We illustrate that the research phases require different support functions on the individual as well as on the team level. We explain that software tools, in particular social software, can provide support for collaborative work in virtual research teams. 1. Introduction With the first collaborative scientific paper published in the year 1665, collaboration in research can nowadays be regarded as standard procedure [1]. While previous literature on research collaboration defines generic collaboration as "a mutually beneficial relationship entered into by two or more parties to achieve common goals" [16] and Schrage [21] specified it to be a "process of shared creation", collaboration in research has some specific additional characteristics. Scientific research is a dynamic process, dealing with typically complex problems. Collaborators are by nature highly specialized in their field and act in a very dynamic context [9]. The strong increase of paper publication illustrates that fact: in the period of 1981 to 1994, the global output of scientific papers went up by 3.7 per cent each year, which signifies a doubling of the global scientific output every nineteen years [17] – already at that time! Parallel to this development, the amount of publications by multiple authors has increased, not least influenced by "publish or perish" mentality. In some disciplines, an amount and speed of publication is required which can nearly exclusively be attained by a combination of forces – intellectually as well as financially [14]. This combination often takes place in collaborative research projects between a number of institutions, diverse departments and on different academic levels. The collaborating members of a research project can hence be regarded as a virtual team. Their interaction is supported by information and communication technology (ICT) and various software applications, as the characteristic of local disparity renders face-to-face interaction rare. 1 Friedrich-Alexander-Universität Erlangen-Nürnberg, Lehrstuhl Wirtschaftsinformatik I, Germany 275 Whereas the details of computer supported collaborative work (CSCW) in a corporate context have been widely researched, there is very little literature on research collaboration and supportive applications. If research collaboration has been examined at all, focus has been nearly exclusively on natural science [4, 11]. However, social sciences like economics, less characterized by the need for expensive equipment, have not yet been addressed in detail. Accordingly, a deep understanding of the potential to support virtual research teams of all fields by the use of software applications is still lacking. To close this gap, we aim at gaining a clearer understanding of how collaborative research projects work, comparing the status quo with the requirements of the researchers. Our research consequently explores the overall research questions: "Which are the necessary support functions to virtual teams doing collaborative research? Which kind of software provides these support functions?" We address our research questions by a qualitative approach in the German research landscape. This setting is particularly suitable to gain first insights as German state agencies like the German Federal Ministry of Education and Research (BMBF) require their sponsored member organizations (e.g. Fraunhofer) to build research collaborations with other institutions and cooperate with the industry [2]. Also by their funding policy, the BMBF as well as the German Research Foundation (DFG) strongly encourage collaborative and interdisciplinary research programs [6]. In the German research landscape, so-called collaborative research centers (SFB) play an important role. As denotes their name, these collaborative research projects promote collaborative interdisciplinary research; they usually consist of different departments from up to three universities. Collaborators on different academic levels are jointly working towards a common goal (typically defined by a project definition) and share knowledge as well as resources to reach this goal [9]. In these projects, research collaboration is flanked by administrative tasks, e.g. documentation of results for dissemination, coordination of meetings, and networking with representatives of the funding institution. These elements of communication, coordination and cooperation are classified to be weaker occurrences [5] as well as prerequisites for successful collaboration [19]. Communication comprises the exchange of information while coordination regulates task assignment and further elements to reach efficient organization. Finally, cooperation means "playing in the same game with others according to a set of behavior rules" [5] and thus sets the framework for interaction. The paper proceeds as follows: the next section provides the theoretical background on the research process as well as on virtual teams. It shows first findings on potential support functions on both the individual and team level of collaborative research. We then describe the methods we used in the data collection and analysis phase, and subsequently present our findings and a model derived from theory and empirical findings. 2. Research Process & Virtual Teams – Foundations To develop the knowledge necessary to better understand the (IT supported) interaction of virtual teams in collaborative research, we started from existing knowledge on virtual teams, research collaboration, and the young strand of research on so-called web 2.0 applications. Literature characterizes virtual teams by a dispersion of the team members across geographical, temporal, and organizational boundaries, with members often coming from different backgrounds of expertise and sharing interdependent goals [10, 15, 24]. Communication between team members is usually mediated by technology that pertains to the area of computer-supported collaborative work, or more recently, social software. Research partners consequently form a virtual team if they work together with partners in other institutions and locations, striving to reach a common goal, e.g. a publication. Virtual teams have been widely researched in different contexts. Martins et al. [15] have adapted the inputs-processes-outcomes (I-P-O) model [8] popular in team research, to match the specific 276 characteristics of virtual teams. In this model, input factors like team size or technology influence the team processes (e.g. communication processes and interpersonal processes like trust). These, in turn, have an impact on team outcomes (affective outcomes like satisfaction of the team members as well as performance outcomes like the time required to fulfill the task). Hence, an optimization of team outcomes in virtual research teams is likely to be dependent on inputs and internal processes which form the behavior of the team members. Despite this broad and deep knowledge base on virtual teams, there is still the necessity to better understand both the individual research process as well as the team activities in order to identify support functions for virtual research teams. The research process of an individual researcher is conceptualized by Graziano and Raulin [7] as divided into different, mutually interdependent phases. They have proposed a comprehensive and generic model of this process (see figure 1). Due to its generic character, this model with its seven phases is supposed to be applicable for research projects of all domains. Figure 1: Research Process [7] The first phase, idea generation, deals with the identification of topics of interest; hence creativity, literature review and communication with peers are important drivers [7]. The following problem definition phase focuses these rather broad and fuzzy ideas into precise research questions [7, 28]. Procedures design encompasses all activities concerning the preparation of data collection, i.e. definition of research design and methodology. The following phase is called observation. By this rather specific denotation, the authors summarize different methods of data collection. Quantitative or qualitative analysis of collected data is the major task of the subsequent data analysis phase. During the interpretation phase, the results are related to the research question and contribution to the targeted knowledge bases is identified. In the communication phase, research results are distributed to share and transfer knowledge; communication is typically done by publications and conference attendance. Building on the model of research phases, adapted from Graziano and Raulin, Yao and Tang [23, 28] identified five support functions that can facilitate the research process, i.e. exploring support, retrieval support, reading support, analyzing support, and writing support. These support functions can be provided by software tools. While exploring support helps to identify relevant work of fellow researchers, the task of retrieval support is to find necessary literature to the topic [23]. Reading support can take place in the form of support for linking information fragments and making notes [23]. Besides the analyzing tools themselves, providing suggestions on methods and how they should be used, is one of the tasks of analyzing support. Writing support extends from automatic correction to suggestions for possible references, as well as systems that support citation. Collaborative research projects encompass parts or the entirety of the individual research process from idea generation to communication of results; in addition, activities related to the (virtual) research team are necessary, e.g. coordination of meetings and efficient as well as effective communication. Also, these team support functions can be improved by appropriate software tools, e.g. weblogs and wikis [20]. Weblogs and wikis belong to the group of webbased software applications which are denoted as social software. This term became popular with the advent of web 2.0 and is nowadays used for a multitude of applications that allow direct or indirect interaction between users and also enable representation and support of users’ relationships on the web [12]. Besides the already mentioned weblogs and wikis, social software tools include social networking services, collaborative filtering, social bookmarking, and a broad range of further tools [3]. Social software has recently received attention from the community of information systems researchers, 277 not least because social software relates to the original idea of the World Wide Web, i.e. to enable discussions within scientific communities and sharing of ideas [3]. Hence, first ideas on the potential of social software tools to support one or several phases of the research process can be found in literature. Yao [26] suggests the use of weblogs as a research diary that allows for a documentation of the research process. The commenting function of a weblog can help at the same time to further explore and develop ideas by the integration of colleagues or other experts in the individual research process [20, 26]. Beyond this use of weblogs as exploring support, they can also provide retrieval support. For example, by hyperlinks in the related posts that directly point to related websites, a network of indirectly related knowledge sources can be easily maintained and tapped [26]. Social bookmarking not only provides retrieval support, but also reading support since it establishes logical connections of different articles [26, 27]. Social software applications like Many Eyes2 are useful tools for analyzing support as they help interpret statistical data. Eventually, writing support could take place by the use of wikis that allow for collaborative editing of documents and at the same time could serve as an additional communication channel [25]. As has been shown, there are considerations in research on the necessity to particularly support virtual teams. In this context, social software has come into focus of attention. Due to its main advantages, ease of use [12] and often low cost (stemming from its open source nature), social software is suitable to realize the support functions. However, there is still need for an analysis that shows which support functions are required most in virtual research teams. We consequently aim to gain a better understanding of the characteristics of the research process in virtual research teams. Thus, we identify areas where social software can potentially provide support to the individual researcher as well as to the virtual research team. 3. Data Collection & Analysis To gain a deeper understanding about the characteristics of the research process in virtual teams and their requirements of support, we chose an explorative research approach. As empirical field, we examined seven German institution-spanning collaborative research projects. These research projects were publicly funded with project duration of three years each. Collectively, they represent a total budget of about ten million Euros, with partner institutions covering Southern, Middle and Eastern Germany. Taking into account the amount of competence and budget associated with these projects, a closer look at their inner workings and in particular their required support functions promises to provide interesting insights. We proceeded by interviewing researchers in collaborative projects who were at PhD level (ten interviewees) and postdoctoral level (four interviewees). The interview candidates were chosen due to their membership in collaborative, private public partnership research projects focusing on applied research. They hold jobs as university-employed researchers in the area of economics, business information systems and computer science. All interviewees had two to four years of experience as researchers in their field. We conducted half of the semi-structured interviews faceto-face, the others via telephone. The interviews were all recorded and transcribed. The transcripts provided the basis for our in-depth analysis. Following the content analysis procedures to code data [18], we structured our data according to the seven phases of the research process as proposed by Graziano & Raulin [7] as well as according to the five support functions identified by Yao and Tang [23, 30]. All data were coded independently by three parties and then compared, using a process of analyst triangulation [29]. 2 Further information available online at http://services.alphaworks.ibm.com/manyeyes/home (2008/11/11). 278 A cross-examination of both data sets led to a gap analysis and identification of additional areas of support. In this interpretative approach to data analysis, we used Atlas.ti, a computer assisted qualitative data analysis software package [13]. 4. Findings Our data show that during their research process, virtual research teams need support on two levels. We found evidence for the five functions of research support as identified by Yao [28] in the research process of individual researchers. In addition, we identified a crucial need for support concerning the collaborating research team – e.g. support for communication or coordination. The subsequent figure shows our framework of research support functions, combining different support functions on both individual and team level. While we separate support for the individual and team level, there are also interdependencies between these levels. For example, social bookmarking services (e.g. del.icio.us3), provide both, support for the individual researcher (collection support) as well as support for the entire team (awareness support). These interdependecies were not regarded in detail in this study. The framework of research support functions is presented below. Figure 2: Framework of Research Support Functions From several interview statements, we conclude that support for goal alignment throughout the entire research process is crucial. Contrary to expectations at the official start of the research projects, perceptions of collaborating researchers regarding the research problem heavily differ. The project was defined - which does not mean that each member knew what he had to do.4 [Interviewee D; TL1]5 Every project partner had a different conceptualization of what was to be done. [Interviewee A; TL1] What you want to do does not entirely fit with what the project partners would like to have done. [Interviewee B, TL1] 3 4 5 Further information available online at http://delicious.com (2008/11/11). All interviews were conducted in German language. Interviewees’ statements have been translated into English. For reasons of privacy, we have used an alphabetical coding scheme to identify interviewees. Team level has been abbreviated to TL, individual level to IL. The issue domain numbers (e.g., TL1) identify both the level and the issue to which a quote refers. The issue numbers for team level are 1, goal alignment; 2, communication; 3, coordination; 4, awareness. The issue numbers for individual level are 1, exploring; 2, retrieval; 3, reading; 4, collection; 5, analyzing; 6, interpretation; 7, writing; 8, dissemination. 279 From our data we conclude that continuous and iterative goal alignment is an important antecedent of successful collaborative projects. We hence introduce a team-level support function goal alignment support. Social software can provide goal alignment support by a platform that enables convergence of opinions by unhindered information flow. Technical solutions can be helpful in this context, especially wiki systems as a central information base: Our goal alignment could have been improved by using a wiki, if the partners had documented what they were thinking so that a convergence would have been possible. [Interviewee A; TL1] We see our wiki as a central repository for any information in the project. [Interviewee E; TL2] The individual research process starts with idea generation and problem definition, when individual researchers have a strong need for exploration, retrieval, and reading support. This support is necessary to facilitate gaining ideas and directions for new research based on previous research, which implies a lot of browsing, finding and reading sources. Access to relevant information is a central requirement that researchers have: Not always all necessary information had been readily available, so there were a lot of requests by phone and a loss of time. A central collaboration platform would have been very helpful. [Interviewee L; IL2] In addition, we found that social software tools can provide support, either by provisioning a repository or by communication tools that are easy to use: We set up a wiki to collect information in one place. [Interviewee E; IL2] We also worked a lot on a peer-to-peer basis, mostly using instant messaging. [Interviewee G; TL2] We have been using del.icio.us as a social bookmarking solution - we set up a joint account for the team and tagged any Internet sources that seemed relevant to provide them to the team. [Interviewee I; IL2] For the phases of procedures design and observation in which the researcher has to select specific procedures he wants to apply, as well as conducting the actual observations, Yao does not mention a dedicated support function [28]. Procedures design is of major importance to every collaborative research project. As one researcher put it: The survey design was harmonized in workshops, [for this task] it is necessary to sit next to each other [Interviewee C; TL2] Having completed the procedures design phase, the individual researchers in the team turn to observation, i.e. data collection, an activity often dependent on the industry partners' willingness to cooperate. Motivation was blemished because of one industry partner who did not deliver data / results. [Interviewee D; IL4] Our partner from the industry also had a high interest in the empirical results; therefore they were willing to provide us with the data. [Interviewee C; IL4] Support for observation is not explicitly mentioned among the five support functions identified by Yao [28]. We found that problems between partners arise very often if partners from industry do not deliver the needed empirical data. We therefore add collection support to the individual support functions. Transforming data collection in a peer-based approach, e.g. by collectively writing case studies, supports the individual researcher. Approaches to collective data collection in the natural 280 sciences have been quite successful: "Swivel"6 for example allows exploring data and statistics of other peers. The above mentioned collaboration in procedures design and observation highlights two further decisive team activities, coordination and communication. Mostly, meeting coordination was handled by communication via email and telephone, with some projects utilizing specialized software like "doodle"7. Feedback on these approaches to coordination underlines the need for coordination and communication support, for which web 2.0 tools appear suitable: Coordination was primarily performed by email, but had a lot of problems, since a lot of team members did not respond at all, so we had to call by phone in addition to that. [Interviewee G; TL3] We liked doodle for appointment coordination. It is easy and fast. [Interviewee D; TL3] The subsequent phases of data analysis can be directly linked to analyzing support. In this phase, results from the previous phases are processed using qualitative or quantitative methods. There are specialized tools that facilitate utilization these methods which usually require specific knowledge to make full use of them. Interviewees stress the proposition by Yao [28] to provide information on which tools and methods to use best as well as an explanation feature that helps in their utilization: It is a major problem to find the method you use best. I felt like guessing. [Interviewee C; IL5] A general collaboration area or a knowledge base, like a wiki, might be helpful for collaborating researchers to exchange information and question regarding usage of the tools. The subsequent phase of interpretation needs additional, dedicated support, i.e. interpretation support. In this phase, it is helpful to use technical means promoting discussions between researchers. A central storage of potential interpretations in a wiki system, for example, makes them available within the team and allows for discussion. Collaboration functioned especially well when there was a lot of interactivity between members. [Interviewee C; TL2] There was a lack of trust and awareness of what the others were doing in and with the project [Interviewee A; TL4] Occurring problems could be discussed not only with research partners within the collaborative project, but also with other experts of the domain. In chemistry, this already takes place in "usefulchem"8, an open source science project to discuss specific problems that need solutions. The final phase of communication is concerned with dissemination of the results and lends itself naturally to writing support. This comprises firstly writing and secondly the publication and dissemination. In terms of collaborative writing, use of traditional communication media leads to dissatisfaction, while the use of shared documents applications, e.g. "zoho"9 seems to be promising: Sending documents with comments by email is far from ideal – version management is hard. [Interviewee E; IL7] We used google docs - a far better experience than sending documents with changes. Also, motivation seemed to be higher – simultaneous work on a document conveys team feeling. [Interviewee M; IL7] 6 7 8 9 Further information available online at http://www.swivel.com (2008/11/11). Further information available online at http://www.doodle.ch (2008/11/11) Further information available online at http://usefulchem.wikispaces.com/ (2008/11/11). Further information available online at http://www.zoho.com (2008/11/11) 281 Beyond its usefulness to support communication, collaborative writing enhances transparency and thus awareness about the activities and state of project partners’ work. Our data shows the importance of awareness throughout the entire project: We set up a homepage to generate a form of awareness of what the others are doing. [Interviewee A; TL4] It would have eased work if progress of team members could have been made publicly visible. [Interviewee B; TL4] Awareness was seriously disturbed in our project – the fact that there was a (potentially helpful) wiki system was announced two days previous to our final meeting. [Interviewee B; TL4] We consequently introduce awareness support as an additional team-level support function. This support function has been shown to be provided for by web 2.0 tools. For example, "OpenWetWare"10 is an effort to promote sharing of information, know-how, and wisdom among researchers and groups who are working collaboratively in the field of biology. Our empirical results have revealed the need for support functions, both at the team level as well as on the level of individual support. We have shown that social software can provide these support functions by its capabilities to facilitate direct and indirect interaction between researchers as well as representation and support of their relationships [12]. We condense our insights to the proposition of a name for virtual research teams collaborating with support of social software: Open Research. We define Open Research as collaborative research by actors that are distributed among different institutions, locations and hierarchical levels. The research work is supported by tools that support information distribution, communication, coordination and collaboration across different time horizons. A central characteristic of Open Research is the opening of research work to existing and potential partners in and outside the own project, and the integration of a number of continuously developed (social software) tools to support the research. We propose a need to further study this phenomenon in detail. 5. Discussion In order to support virtual research teams in their process of Open Research we learned that a systematic approach to the collaboration process is needed. Our data suggest a bisected process with an individual and a team level (each characterized by particular characteristics) for which we have proposed an enhanced framework combining previous work and our findings. The interdependencies between the individual and the team level need a closer look in future research. We have highlighted the different support functions which are necessary to virtual research collaboration as well as indicated the potential of social software tools to facilitate these support functions. Results of our research have to be tempered with its limitations. In order to gain a first insight, we examined a limited array of projects. Further research on Open Research might focus on projects with different funding structures, including more academic levels (PhD candidates, postdoctoral researchers, and full professors), and additional types of collaborators, e.g. industry partners. We estimate that different contexts of Open Research will lead to different requirements for support functions, both on the individual and team level. 10 Further information available online at http://openwetware.org/wiki/Main_Page (2008/11/11). 282 6. Acknowledgment We want to thank Michael Koch, Florian Ott and Alexander Richter, Universitaet der Bundeswehr Muenchen, for their contribution and feedback to this work. This research has been funded by the Donors’ Association for the Promotion of Sciences and Humanities in Germany, the Federal Ministry of Education and Research (BMBF), and the European Social Fund (ESF) under HHL’s Open School Initiative and within the project “2nd Tech-Cycle” (Förderkennzeichen: 01FM07109). The authors would like to thank their interview partners for their willingness to participate in this research. We also want to thank our anonymous reviewers for their valuable comments and suggestions. 7. References [1] BEAVER, D.de B., ROSEN, R., Studies in scientific collaboration: Part I - The professional origins of scientific co-authorship, in: Scientometrics, Vol. 1, No. 1, (1978), pp 65-84. [2] BUNDESMINISTERIUM FUER FORSCHUNG (BMBF), online available at http://tinyurl.com/5nkjnx (2008/07/30) [3] BOULOS, M. N. K., WHEELERT, S., The emerging Web 2.0 social software: an enabling suite of sociable technologies in health and health care education, in: Health Information and Libraries Journal, Vol. 24, No. 1 (2007), pp 2–23. [4] CHOMPALOV, I., GENUTH, J., SHRUM, W., The organization of scientific collaborations, in: Research Policy, Vol. 31, No. 5 (2002), pp 749-767. [5] DENNING, P. J., YAHOLKOVSKI, P., Getting to “WE” – solidarity, no software, generates collaboration, in: Communications of the ACM, Vol. 51, No. 4, (2008), pp 19 – 24. [6] DEUTSCHE FORSCHUNSGEMEINSCHAFT (DFG), online available at http://tinyurl.com/5bksl5 (2008/07/30) [7] GRAZIANO, A.M., RAULIN, M.L., Research Methods: A process of inquiry, 6th edition, Allyn and Bacon, Boston 2007. [8] HACKMANN, J. R., MORRIS, C. G., Group tasks, group interaction process, and group performance effectiveness: A review and proposed integration, in: L. Berkowitz (Ed.), Advances in experimental social psychology (Vol. 8, pp 45–99), Academic Press, San Diego 1978. [9] HARA, N., SOLOMON, P. KIM, S.-L., SONNENWALD, D. H., An emerging view of scientific collaboration: Scientists’ Perspectives on Collaboration and Factors that Impact Collaboration, in: Journal ot the American Society for Information Science and Technology Vol. 54, No. 10 (2003), pp 952 – 965. [10] HERTEL, G, SCHROER, J., BATINIC, B., NAUMANN, S., Do shy people prefer to send e-mail? - Personality effects on communication media preferences in threatening and non-threatening situations, in: Social Psychology (forthcoming); available online at: http://tinyurl.com/4jw62h [11] HEINZE, T., KUHLMANN, S., Across institutional boundaries? Research collaboration German public sector nanoscience, in: Research Policy, Vol. 37, No. 5 (2008), pp 888-899. [12] KOCH, M., RICHTER, A., Enterprise 2.0 - Planung, Einführung und erfolgreicher Einsatz von Social Software in Unternehmen, Oldenbourg Verlag, München 2007. [13] LINDSAY, V.J. Computer-assisted qualitative data analysis: application in an export study. In Marschan-Piekkari, R. and Welch, C. (eds) Handbook of qualitative research methods for international business (pp 486-506), Edward Elgar, Cheltham 2004. 283 [14] LUUKONEN, T., PERSSON, O., SIVERTSEN, G., Understanding patterns of international scientific collaboration, in: Science, Technology Human Values, Vol. 17, No. 1, (1992), pp 101 – 126. [15] MARTINS, L. L., GILSON, L. L., MAYNARD, T., Virtual Teams: What do we know and where do we go from here? in: Journal of Management, Vol. 30, No. 6., (2004), pp 805 – 835. [16] MATTESICH, P., MONSEY, B., Collaboration: What makes it work? A review of the literature on factors influencing successful collaboration, Amherst H. Wilder Foundation, St. Paul, MN 1992. [17] MAY, R. M., The scientific wealth of nations, in Science, Vol. 275, No. 5301, (1997), pp 793 – 796. [18] MAYRING, P., Einführung in die qualitative Sozialforschung: Eine Anleitung zu qualitativem Denken, 5th edition, Beltz Verlag, Düsseldorf 2002. [19] RASHID, A., BEHM, A., GEISSER, M., HILDENBRAND, T., Kollaborative Softwareentwicklung – zum Kollaborationsbegriff, available online at http://tinyurl.com/69moq3 (2008/07/28) [20] SAUER, I. M., BIALEK, D., EFIMOVA, E., SCHWARTLANDER, R., PLESS, G., NEUHAUS, P., “Blogs ” and “ Wikis ” are valuable software tools for communication within research groups, in: Artificial Organs, Vol. 29, No. 1, (2005), pp 82 – 89. [21] SCHRAGE, M., No more teams: mastering the dynamics of creative collaboration, Currency and Doubleday, New York 1995. [22] SONDERFORSCHUNGSBEREICH (SFB), available online at http://tinyurl.com/35hzae (2008/07/29) [23] TANG, H., WU, Y., YAO, J. T., WANG, G., & YAO, Y. Y., CUPTRSS: A web-based research support system, Proceedings of the Workshop on Applications, Products and Services of Web-based Support Services, Hallifax, Canada, (2003), pp 21-28. [24] TOWNSEND, A. M., DEMARIE, S. M., HENDRICKSON, A. R., Virtual teams: Technology and the workplace of the future, in: Academy of Management Executive, Vol. 12, No. 3, (1998), pp 17–29. [25] WAGNER, C., Wiki: A technology for conversational knowledge management and group collaboration, Communications of the Association for Information Systems, No. 13, (2004), pp 265- 289. [26] YAO, J. T., Supporting Research with Weblogs: A study on web-based research support systems, The 3rd international workshop on web-based research support systems, HongKong, China, (2006), pp 161-164. [27] YAO, J. T., & YAO, Y. Y., Web-based Information Retrieval Support Systems: Building research tools for scientists in the new information age, Proceedings of the IEEE/WIC International Conference on Web Intelligence, Halifax, Canada, (2003), pp 570-573. [28] YAO, Y. Y., A framework for web-based research support systems, Proceedings of the 27th Annual International Computer Software and Applications Conference, Dallas, USA: IEEE Computer Society (2003), pp 601-606. [29] YIN, R. K., Case study research - design and methods, Sage Publications, Thousand Oaks 2003. 284 NON-OPTIMIZED TEMPORAL STRUCTURES AS A FAILURE FACTOR IN VIRTUAL TEAMS Felix Köbler1, Marilyn Tremaine2, Jan Marco Leimeister3, Helmut Krcmar1 Abstract Despite the expected benefits of global virtual teams, their performance has been spotty and management continues to search for reasons why these teams fail. This work addresses this issue by performing a longitudinal case study of two virtual teams in order to uncover why one was more successful than the other. The study found that a key factor for one team’s poor performance was the entrainment of the temporal norms of both the countries and the social situations of the members that reduced the available real time meeting space to zero. 1. Introduction A number of co-occurring factors have led to the development of global software teams. These include the exponential development and diffusion of communication and collaboration technology, the availability of well-educated software personnel in countries where the cost of labour is far below that of western countries, the growth of multi-national organisations with large amounts of investment capital, the flexibility of government policies that encouraged investment in offshore projects and the emergence of new global markets that led to an organisation’s desire to establish a workforce in the emerging market countries. One answer to these changes is a team-based concept the virtual team [12]. A virtual team is defined as a set of geographically dispersed knowledge workers that interact through interdependent communication and coordination processes. These processes are facilitated through information and communication technologies, to achieve a specific goal in an environment that is affected by physical (space and time) and social (organisation and culture) dimensions [7] [22]. Virtual teams are said to combine flexibility, responsiveness, lower labour costs, specific task foci and improved resource utilisation necessary to survive and gain competitive advantage in today’s turbulent, and dynamic, global business environments [15] [16] [19] [21] [22] [24] [27]. In addition to these factors, there exists the underlying belief that much technical work can be adequately pre-specified so that virtual distributed teams are a successful and cost effective strategy [3]. However, the expected benefits from global software development teams 1 Chair for Information Systems, Technische Universität München, Boltzmannstr. 3, 85748 Garching, Germany 2 CAIP - Center for Advanced Information Processing, Rutgers University, 96 Freylinghuysen Road, Piscataway, NJ 08854-8088, USA 3 Chair for Information Systems, Universität Kassel, Nora-Platiel-Str. 4, 34127 Kassel 285 have not always been achieved [4] [6]. Virtual distributed teams are found to cause significant leadership and organisational challenges, for example, a loss of trust arising from cultural misunderstandings, large communication difficulties as a result of both language differences and inexact work specifications [16] and work overloads caused by time zone differences [18]. Studies have shown that some teams work and achieve their desired goals, but that others are bogged down in problems [17]. Thus, it is important to know what causes failures in virtual teams in order to avoid such pitfalls. This work investigates possible causes for failures through a longitudinal study of two virtual teams, one which has maintained its momentum upon becoming virtual and the other which has not. The teams have many characteristics in common, in particular, the same manager and a similar membership composition. Additionally, both teams were running successfully in face-to-face mode until relocation of the team manager caused the teams to become virtual. The case study performs an ethnographic analysis of the two teams and carries out explanation building on multiple dimensions to determine what characteristics of the teams might have led to their success and failure [10] [11] [26]. The analysis is one of hypotheses building from information captured on the organisation, communication, member characteristics and management of each team. One surprisingly simple failure factor that the analysis uncovered was the failure of the unsuccessful team to find a suitable meeting time. The paper is organized as follows: First, a review of current research on temporal structures and norms and their entrainment of individuals is presented along with a small number of studies that have looked at the influence of time zone differences on virtual team environments. This is followed by a detailed description of the two teams involved in this case study. The data collection and explanation building approach is then described followed by a presentation of the study’s findings. The implication of the findings for virtual team management follows, and the paper concludes with the limitations of the research method chosen and a statement of the research’s contribution. 2. Related work Because teams are increasingly spread over different time zones, coordination and control problems arise that are related to the decreasing amount of temporal overlap between team member’s working hours [5]. This is referred to as the temporal distance between team units. The impact of temporal distance on personal life disruption has been found to be significant [9]. A second body of literature deals not with temporal distances but with the inherent temporal structures and norms that have been found to impact organizations. These structures and norms have been found to inadvertently interact with each other creating significant work interruptions and conflicts across organisational units [1] [2]. If such impacts are found in co-located units, it can be hypothesized that such temporal structures and norms are likely to differ widely between locations that are not temporally co-located and to therefore impact the temporal distance between members of a virtual team even more. Table 1 presents definitions and examples of temporal norms that are commonly found in organisations. 286 Term Definition Example Temporal Norm Culturally unstated time lags or time usage, created and accepted by a large group of members in human society The normal promotion time in Company A is three years; Meetings never last more than 1 hour in Company B. Temporal Structure Patterned organization of time, used by humans to help them manage, comprehend or coordinate their use of time. This pattern can be an individually created pattern or one agreed upon by a larger group of individuals. Status meetings take place every Monday at 5 PM Socio-temporal Norm Socially-based temporal norms, adopted by a large group of individuals, usually part of a culture or sub-culture Individuals never work on Saturday (Sabbath) in Israel Table 1: Definitions of the terms in adaptation of Wu [25] Im et al. [14] in his investigation of a global software development team, found that the team gradually evolved a set of temporal boundaries and time management practices that helped the team coordinate itself asynchronously and cope with locally entraining temporal structures. Edensor [8] demonstrates that nationalities have well defined temporalities that are found in the institutional times and everyday routines of each country. Thus, anytime a temporal distance crosses national boundaries, this crossing alone is likely to impact coordination simply because of team members’ different senses of time and time rhythms that are found in each country. In particular, if there is a need for real-time communication, the temporal overlap is likely to be even less than the temporal distance suggests. This work will focus on the impact of nationally driven and personal temporal structures becoming an important factor in the ability for the temporally distant teams studied to establish real time meetings. 3. Research Entities The research case is built on two virtually distributed teams, the Research Instrument team (RIteam) and the Software Development team (SD-team). The RI-team is defined as the successful team. The SD-team is labelled as the unsuccessful team. Both teams were academic research teams that met weekly in a university conference room. Both teams consisted of graduate students and a faculty member who guided the activities of the teams. The teams went virtual when the leader of the two teams took a sabbatical in Europe for one year. It was arranged to continue the once a week research meeting with each team via a voice over IP setup. The teams met virtually from May 2006 until May 2007. 3.1. The Research Instrument Team Historically the RI-team emerged out of a doctoral research seminar. A sub group formed in January 2006, that began having additional meetings that focused on studying global software development. This sub group consisted of four members, two faculty and two graduate students. The team leader was the advisor of both graduate students. Face-to-face meetings were held weekly for two hours in a university seminar room. Occasionally, a rotational sequence between the three universities involved in the research facilitated the participation of the team members in meetings, as team members were distributed over a 200 km2 area. The advisor met separately each week with each of the Ph.D. students. The RI-team’s gender was equally divided (one female and male Ph.D. student), one female professor (the thesis advisor) and one male professor (who served as an external member on the students’ thesis committees). The team was headed by the female professor with the support of the male professor. The team is dominated by American culture, with one exception; the female Ph.D. student is from mainland China although she had been in the U.S. for six years at the beginning of this study. 287 The key research activity of the RI-team was in conducting interviews and a survey within a Fortune 100 company. As such, this team focused much time on the development of their measurement tools, e.g., the interview guide and the survey. The original purpose of the RI-team was to generate research that formed two theses and a series of journal and conference publications. Only one of the team members is tenured so that publications in good places are very important to all team members. The team focused on one company initially but has now expanded to conduct research in multiple companies. The team continues to work together on new research questions that arose while conducting the original research. 3.2. The Software Development Team The SD-team began its existence in November 2003. The focus of the SD-team project was to develop a portable interface that read online information to blind users, that was cheap to buy and that was easy to use. This interactive system for visually impaired/blind users would allow users to listen to online newspaper articles and books through a personal data assistant and to manage their daily schedule and address book. The research also supported two Ph.D. dissertations of team members. The advisor met separately weekly with each of the Ph.D. students. Because of additional interest in the project from two Master’s students, a research team was formed to focus on developing the browsing tool in a form that was robust enough to allow a public downloadable release of the system. The team met two hours weekly in the evenings in a conference room at the university. All team members were part of the same university and lived close enough to the university to make the commute to the meeting comfortable. This team was very social and occasionally set up additional social nights in which team members were joined by their significant others for dinner. Pizza and soda were served at all meetings and individuals took on rotating responsibility for bringing the food to the meetings. From the starting point of team formation, the SD-team consisted of five members. Two of the team members were Ph.D. students (one Chinese female and one American male). Two of the team members were Master’s students (both were American males). The team leader (professor) was female. One of the Master’s students was motor-disabled and came to the meeting with a special van and a motorised wheel chair. Additional to shared tasks such as web page design and research paper writing, the team members can be divided around two centres of activities: (1) software development and (2) user interface design. The software development unit contained three individuals: a junior (male Master’s student) and senior software developer (male Ph.D. student) and a web developer who was also occasionally occupied with software development tasks (male Master’s student). The interface design unit consisted of a user interface designer who was occasionally occupied with web development tasks (female Ph.D. student) and the team leader (female professor). It should be noted that unlike the work conducted with the RI-team, the two Ph.D. students on the project were working on theses that were related to the project but neither fully needed the project for the completion of their research. The major motivation for this project was to develop a usable system for the blind. 4. Research Methodology The longitudinal case study used inductively interpretive hypothesis generation and an explanation building process following the descriptions of Glaser and Strauss [11], Yin [26] and Eisenhardt [10]. The starting point of the theory building, is as close as possible to the ideal of no theory under consideration and no hypotheses to test on the specific case [10]. For the initial semi-structured interview with the manager, an interview guideline was iteratively created. The initial interview guideline consisted of four main question types: organisational, leadership/managerial, motivational and course/process. These question types later outlined the dimensions of the analysis 288 framework, which developed a grouping of findings around the question types possible. The interview and discussions with the manager generated macro-organisational and -managerial information for both teams. The information was used to sharpen the dimensions of the analysis framework and to add or delete questions to create a new interview guideline. After the initial interview, findings were clustered around 12 dimensions: (1) team organisation, (2) sub team formation, (3) management style, (4) team processes, (5) communication technology, (6) member motivation, (7) amount/type planning, (8) member contributions, (9) inter-member trust, (10) socialization practices, (11) team culture and (12) time behaviours. Each conducted interview and its analysis served as input to sharpen the above dimensions and refine the interview guideline for subsequent interviews, which questioned prior found evidence. Interviewed team members frequently used words, phrases and stories, which played a key part in the identification of the concepts and themes that integrated the data into the framework being constructed [20]. After each interview the researcher listened to the recorded interview, created transcriptions and formed hypotheses, which linked data to the prior propositions. Generated hypotheses were grouped into the dimensions of the framework as nullifying and supporting information was collected. Each forming hypotheses was marked with the team’s and respondent’s name, to trace the information stream. Hypotheses either explained the success or the failure of both teams. Evidence hypothesising the failure of a virtual team came primarily from SD-team interview data, while success explaining evidence was derived from RI-team interview data. In some cases, the findings in the failing team amplified findings of success in the successful team, and vice versa. This process was continued until all interviews were conducted and analysed and a level of theoretical saturation was established. Before the beginning the analysis of the data, three assumptions needed to be clarified: (1) the assumption that one team was a success and the other a failure; (2) the assumption that the teams were similar in makeup; and (3) the assumption that the tasks accomplished by the teams were similar in complexity. The latter two assumptions need to be justified because it can be argued that inherent team differences in their composition or tasks could have caused one virtual team to fail rather than what is being argued in this paper, the impact of the non-optimized overlap of temporal norms. The first assumption needs to be justified because the failing team did not actively fail but lost momentum. Eventually the team was shut down by its leader because of the slow product output and the lack of attendance at the real-time meetings. Success was measured in team performance, team adherence to deadlines and team member attendance at meetings. Team performance is the ability of the team to deliver timely, high-quality products [22]. The RI-team set goals and deadlines agreed upon by all members and then worked to achieve these goals. The goals were not changed. In contrast, the SD-team set initial goals and then met and changed the goals to reduce the amount of work they needed to do to meet a deadline. After a variety of meetings in which progress was halted because key team members were not in attendance, the team leader decided in a discussion with the lead system developer to put the team meetings on hold. They have not been restarted. The two virtual teams were chosen as research units because it was believed that they had a high overlap in management and member characteristics as described in the previous section. The key differences between the teams were the following: (1) One team had two professors and the other team had two Master’s students as members. It is argued that the senior software developer replaced the role of the second professor in the SD-team because of his age and 20 year expertise associated with the task of the team. (2) The teams differed in number of members but the female Ph.D. student on the SD-team rarely attended the face-to-face meetings in the final year before the project went virtual. She never attended the virtual meetings. (3) The teams had different tasks. It is 289 argued that both tasks required significant creativity, problem solving and detailed communication exchanges so that running either meeting virtually was difficult. The teams only differentiated in their academic orientation and work assignments. In contrast to the RI-team, where the project work was centred around two dissertation projects, the individual motivation in the SD-team was based on interest in the team task and a high level of camaraderie amongst the group members. Table 2 shows collected and analyzed data sources that were used in conducting the case study. (Note: It was not possible to attend the SD-team meetings because at the time this project began, the SD-team was having trouble finding a viable meeting time for all members. Research Instrument team (internet-based group), internet-based calendar and email documents (417 emails) Archival records Interviews semi-structured interviews (6 hours 49 minutes) Software Development team (internet-based group), internet-based calendar semi-structured interviews (5 hours 2 minutes) seven months (30 hours) Table 2: Data sources underlying each research unit Participatory observation 5. Findings pre-recorded semistructured interviews (3 hours 48 minutes) - One of the key difficulties that the SD-team was found to encounter was an inability to maintain momentum because they could not find a suitable meeting time. The support for this is presented in the next set of paragraphs. Figure 1 displays the availability for virtual team meetings in the SD-team, while Figure 2 maps the individual availability/temporal structures for virtual team meetings in the RI-team. The patterns denote the type of availability of individuals. The upper time slot line shows the availability of the manager, while the line underneath displays the overall availability of the team members. Times are adjusted according to the underlying time difference of six hours between the manager and her team (GMT+5 – GMT-1). The data is derived from interviews, a shared online calendar of the team manager and meeting minutes of both teams. Non-availability (leisure) status includes commuting, leisure and sleeping/recreation times of individuals (influenced by individual temporal structures and norms). The non-availability (work) describes the state of individuals being required to perform other job related activities and not being available for virtual meetings. Restricted availability includes situations in which individuals are able to join virtual meetings by aligning or changing personal temporal structures (e.g. daily life patterns such as; waking up earlier, going home from work earlier, etc.). RI-team members were able to adjust their work availability and occasionally their personal life availability to create a window of viable real time meetings. The SD-team attempted to hold their weekly meeting on Friday at 7:00 (GMT+5) or on Wednesday at 18:00 (GMT+5). The graphical plot of individual availability on adjusted time zones shows that the 7:00 time was the only available time for virtual meetings (see Figure 1). The 18:00 time was tried, but since internet connectivity was weak at home for the team leader and since the bus and subway stopped running after midnight, the team leader refused to sleep in her office or pay for an expensive taxi in order to hold these meetings, in particular, since team members often came late to the midnight meeting because of traffic conditions they encountered. 290 Figure 1: Availability of SD-team members on weekdays During weekdays, SD-team virtual meeting times were entrained by the different restrictive schedules of each team member. Two members had just started new employment and could not meet during their workdays. A third member was constrained by the waking time of his family because his disability required family intervention. The younger team members reported that the meeting time was too early in the morning, resulting in missed meetings. In addition, the time slot was one hour, which was further shortened by connection difficulties. In comparison the RI-team meetings lasted at least two hours (see Table 3). An analysis of the team minutes of both meetings showed that the SD-Team spent much of its time in review of what had been done so that little generation of new items was done. In contrast the RI-team spent much time generating new work and task assignments to resolve problems as they came up each week. Overall, the SD-team meetings suffered from (1) a lower degree of social and personal interaction, (2) lower social facilitation, (3) decreased exercise of managerial power and (4) decreased communication among members. A 12:00 (GMT+5) meeting was tried during the lunch break of the working team members but the constraints of other meetings at their workplace made attendance unpredictable. They were also too short. Saturday meetings were proposed but family schedules of team members made these meetings untenable. Insufficient length of meetings Interview evidence in the SD-team representative example count accepted count rejected “I think (the meeting) was a little bit to short (…) we did not have much 9 1 time in the morning (…) precisely one hour” Interview evidence in the RI-team representative example count accepted count rejected “Good length (of the meetings), there is a lot to cover (…)” 0 3 Note: The count accepted column refers to the number of interview statements that supported this evidence and the count reject column is the number of interview statements that refuted it. Table 3: Evidence on insufficient length of meetings In contrast, the team member individual time schedules in the RI-team held more possibilities for holding a virtual meeting at a time acceptable to all and with a reasonable meeting length. These meetings took place on Wednesday from 9:00 – 11:00 (GMT+5) / 15:00 – 17:00 (GMT-1). In some cases, these meetings lasted three hours. 291 Figure 2: Availability of RI-team members on weekdays Overall, three major differences were found between the RI-team and the SD-team in each team’s willingness to establish a viable meeting time: (1) the temporal structures affecting their daily lives, (2) the volunteer character of the project that made members unwilling to adjust leisure schedules significantly and (3) low age awareness. It is argued that the temporal norm effects on the daily life of team members were higher in the SDteam (see Table 4). First, more members were constrained by their work schedules because they had less flexible schedules than the RI-team. Secondly, because workday time could not be used for meetings, the personal life schedules of the SD-team began to interfere. In particular, early mornings and Saturday afternoon meetings did not map the life style of the younger team members. At least two nationally determined temporal norms also interfered, that is, the scheduling of public transportation and office closures in European countries. Table 4 lists the number of times an interview respondent indicated that a meeting time affected one’s personal schedule for both the RI and SD-teams. As can be seen, the meeting time schedule was barely mentioned by the RI-team. Meeting time schedule affecting on daily life Interview evidence in the SD-team representative example count accepted count rejected “I switched my lunch hour to get to the meetings” 10 0 Interview evidence in the RI-team representative example count accepted count rejected “It is a little bit earlier for me, but it has become a habit (meeting) so it 2 1 is good for me, I got used to it” Note: The count accepted column refers to the number of interview statements that supported this evidence and the count reject column is the number of interview statements that refuted it. Table 4: Discussion on meeting time affecting on daily life The second source of meeting scheduling conflict was the nature of the temporal structure constraints on the SD-team members. All but one member worked full time jobs and thus, their focus was on serving their employer first and the team, second. Work meetings and the use of work computers entrained members to not meet during the workday (8:00 to 18:00 GMT+5). In contrast, RI-team members were academics and the project was closely aligned to the team members’ careers. Therefore, RI-team members could join virtual meetings during their official work hours without having to adapt their personal schedules for team meetings. The third assumed reason is based on the higher age distribution in the SD-team. As the schedules for team meetings were significantly dominated by the manager and senior software developer, the time patterns agreed upon did not match the temporal norms of the younger members. The mismatch of scheduled virtual meetings and individual daily life patterns resulted in a low virtual meeting attendance. Low meeting attendance was also caused by frequent changes in virtual meeting days and times in an attempt to find a suitable slot. Team members were not able to adjust personal schedules to the 292 frequently changing virtual meeting patterns. RI-team members, in contrast, were able to adjust and align individual temporal structures on the basis of a frequent and regular meeting pattern. 6. Implication for the management of virtual teams The above described findings suggest implications for the management of virtual teams. Although employees are unlikely to skip scheduled meetings, these meetings are likely to interact with existing temporal structures and norms in an employee’s life and create significant time burdens on the temporally dislocated meeting attendee. In short, an individual may be there in body, but not in mind if the temporal disruption is large enough. Therefore, managers need to gain an awareness of the temporal structures and social-temporal norms of non-collocated sites in order to guarantee acceptable meeting time overlaps. Temporally entraining structures and social-temporal norms such as public transportation schedules, personal, local and national celebrations, school schedules, traffic congestion patterns and family sleep patterns can result in severe constraints on real time meeting times. In addition, individual daily life patterns vary because of gender, age and social group also affecting meeting attentiveness. Indeed, if anyone wishes to test this latter statement, all this person has to do is ask their graduate student to meet at 7:00. Virtual meetings for which attendance is voluntary are likely to wither if no satisfactory overlaps can be found for meetings between members. One attempt to overcome the low temporal overlaps that occur because of large temporal distances is the creation of a bridge that helps to span the time zones [13] [18]. However, as indicated in this study, it is not just the workday overlap that establishes the acceptable meeting times but a large collection of temporal norms that vary nationally and can readily reduce this overlap to zero. 7. Conclusion The hypothesis that highly constrained meeting opportunities in the failing team provides one explanation why this team did not succeed. The main contribution of the underlying work displays the negative impact of non-optimized adjustments of temporal norms, structures and socio-temporal norms between virtual team members. One recommendation for managers who plan and conduct virtual meetings on a global scale is to align (meeting) time profiles of team members to support critical minimum length meetings, meeting regularity and also minimal disruption of national established norms. This study is not without its limitations. First, it is a single case study of two teams run by one manager. These teams may have been unique because of their manager or because of the individuals that formed the teams. Thus, generalisations to globally distributed teams in industry may not be applicable. Second, the teams had student members. The students on the teams were Ph.D. or Master’s students, who had worked in industry previously, but there are good arguments made that students have different goals and are thus, not representative for industry settings [23]. However we argue that because the students had full time professional jobs and because all but one of the students was over 30, that they were representative of typical industry workers. But the volunteer character of the SD-team project differentiates this team’s temporal structures and norms from that of industry-embedded teams. Industry-embedded teams are aligned to temporal structures and norms through the corporate culture, e.g. office attendance between 9:00 and 17:00, which generates a common temporal frame and decreases problems with temporal entrainments. Third, the interest in understanding why teams fail comes from the issues in running globally distributed software teams. The teams studied were predominantly North American. Even foreign student members of the team had been accustomed to North American culture and socio-temporal norms, for some time. Thus, these teams did not represent the potential cultural conflicts that are predicted to happen in temporal norms and structures in global teams. Even so, this paper is the first to show the role of non-optimized temporal structures as a failure factor in virtual teams in a detailed analysis. 293 8. References [1] ANCONA, D.G.; GODDMAN, P.S.; LAWRENCE, B.S.; TUSHMAN, M.L., Time: A New Research Lens, in: The Academy of Management Review, Vol. 26, No. 4, pp. 645-663 (2001) [2] BLUEDORN A.C.; DENHARDT, R.B., Time and Organizations, in: Journal of Management, Vol. 14, No. 2, pp. 299-320 (1988). [3] BOEHM, B.W., Software Engineering Economics, Prentice Hall PTR, Upper Saddle River, N.J. 1981. [4] CARMEL, E., Global Software Teams: Collaborating Across Borders and Time Zones, Prentice Hall PTR, Upper Saddle River, N.J. 1999. [5] CARMEL, E.; AGARWAL, R., Tactical Approaches for Alleviating Distance in Global Software development, IEEE Software, pp. 22-29 (2001). [6] CARMEL, E.; TJIA, P., Offshoring Information Technology: Sourcing and Outsourcing to a Global Workforce, Cambridge University Press, Cambridge, UK 2005. [7] CASEY, V.; RICHARDSON, I., Uncovering the reality within virtual software teams. in: International Conference on Software Engineering 2006, International workshop on Global software development for the practitioner Shanghai, China, pp. 66-72 (2006). [8] EDENSOR, T., Reconsidering National Temporalities Institutional Times, Everyday Routines, Serial Spaces and Synchronicities, in: European Journal of Social Theory, Vol. 8, No. 4, pp. 525-545 (2006). [9] EGAN, R., An Exploratory Study of Cultural Differences in Temporal Perception and Its Implications for Running Efficient Global Software Teams, Ph.D. Dissertation, New Jersey Institute of Technology, Newark, N.J. 2008. [10] EISENHARDT, K.M., Building Theories from Case Study Research, in: Academy of Management. The Academy of Management Review, Vol. 14, No. 4, pp. 532-551 (1989). [11] GLASER, B.G.; STRAUSS, A.L., Discovery of Grounded Theory: Strategies for Qualitative Research, Aldine Pub. Co., Chicago, I.L. 1967. [12] HARVEY, M.; NOVICEVIC, M.M.; GARRISON, G., Global Virtual Teams: A Human Resource Capital Architecture, in: International Journal of Human Resource Management, Vol. 16, pp. 1583–1599 (2005). [13] HOLMSTRÖM, H. P.; ÄGERFALK, P.; CONCHÚIR, E.Ó.; FITZGEREALD, B., The Irish Bridge: A Case Study of the Dual Role in Offshore Sourcing Relationships, in: Proceedings of the 27th International Conference in Information Systems Milwaukee, W.I., pp. 513-526 (2006). [14] IM, H.-G., YATES, J.; ORLIKOWSKI, W., Temporal Coordination through Communication: Using Genres in a Virtual Start-up Organization, in: Information Technology & People, Vol. 18, No. 2, pp. 89-119 (2005). [15] JARVENPAA, S.L.; IVES, B., The Global Network Organization of the Future: Information Management Opportunities and Challenges, in: Journal of Management Information Systems, Vol., 10, No. 4, pp. 25-57 (1994). [16] JARVENPAA, S.L.; LEIDNER, D.E., Communication and Trust in Global Virtual Teams, in: Organizational Science, Vol. 10, No. 6, pp. 791-815 (1999). [17] LEVINA, N., Collaborating Across Boundaries in a Global Economy: Do Organizational Boundaries and Country Contexts Matter?, in: Proceedings of the 27th International Conference on Information Systems ICIS 2006, Milwaukee, W.I., pp. 627-642 (2006). [18] MILEWSKI, A. E.; TREMAINE, M.; EGAN, R.; ZHANG, S.; KÖBLER, F.; O’SULLIVAN, P., Information ‘Bridging’ in a Global Organization, in: Proceedings of the 2007 Conference of the Center for Advanced Studies on Collaborative Research, ACM Press, New York, N.Y. 2007. [19] MOWSHOWITZ, A., Virtual organization, in: Communications of the ACM, Vol. 40, No. 9, pp. 30-37 (1997). [20] NANDHAKUMAR, J.; BASKERVILLE, R., Durability of online teamworking: patterns of trust, in: Information Technology & People, Vol. 19, No. 4, pp. 371-389 (2006). [21] NEMIRO, J.E., Connection in Creative Virtual Teams, in: Journal of Behavioral and Applied Management, Vol. 3 No. 2, pp. 92–112 (2001). [22] PICCOLI, G.; POWELL, A.; IVES, B., Virtual Teams: Team Control Structure, Work Processes, and Team Effectiveness, in: Information Technology & People, Vol. 17, No. 4, pp. 359-379 (2004). [23] REMUS, W., Using Students as Subjects in Experiments on Decision Support Systems, 22nd Hawaii International Conference on System Sciences, HICSS’22, IEEE Computer Society Press (1989). [24] SNOW, C.C.; DAVISON, S.C.; SNELL, S.A.; HAMBRICK, D.C., Use Transnational Teams to Globalize Your Company, in: Organizational Dynamics, Vol. 24, No. 4, pp. 50-67 (1996). [25] WU, D., Supporting Individual Time Management through the Capture and Display of Temporal Structures, Ph.D. Dissertation, New Jersey Institute of Technology, Newark, N.J. 2005. [26] YIN, R.K., Case Study Research: Design and Methods, Sage Publications Inc., Beverley Hills, C.A. 1984. [27] ZERBE, S., Globale Teams, ein Ansatz zur Formulierung von Gestaltungsvorschlägen für verteilte teamorientierte Organisationsformen, Ph.D. Dissertation, University Hohenheim 2000. 294 CONTENT-BASED COMMUNITY DETECTION IN SOCIAL CORPORA Annette Bobrik, Matthias Trier1 Abstract Electronic communication media are a widespread means of interaction. They effect network relationships among people. Such networks provide connectivity but are often structured in clusters. Current cluster analysis in social corpora is mainly based on structural properties. This paper extends existing approaches with content-based cluster identification and community detection in social corpora. Following a design science methodology, we demonstrate our approach using a corporate e-mail dataset. After analyzing relationships between structural and content-based groups we conclude that our method contributes to detecting online communities, especially for large structural or smaller but dispersed topical groups. 1. Introduction Electronic communication media have become the most widespread means of interacting in a company. In a recent study, 98 percent of all employees with internet access collaborate via e-mail at their workplace, most of them several times a day. Three quarters used it to improve their teamwork and to increase the number of people they actively communicate with [5]. E-Mail is thus a strong force for connecting people at the workplace. It has been shown to complement formal work networks and provide more diverse, participative and less formally aligned relations [2]. Such effects are not limited to the domain of e-mail communication: The internet sports new combined forms of interaction that blend contents and communication (e.g. comments to stories) [21]. All these interactions of people captured over time form a social network structure via communication [11]. One of the primary methods for studying the resulting electronic communities is Social Network Analysis (SNA) [24]. For this paper, the collection of all (electronic) traces of interrelated communication relationships is defined as a social corpus. Research in online communication networks is directed at understanding the structures and properties of these complex systems to identify structural patterns (e.g. [10]). One important interest is the location of groups in such networks. For this objective, SNA offers a series of clustering and grouping algorithms that find widespread application in practice. For example, Tyler et al. applied a graph-theoretic betweenness centrality algorithm to automatically identify communities in a research department of 400 employees at Hewlett-Packard [22] solely based on studying e-mail interactions. They detected 66 distinct groups reaching from 2 up to 57 members. A subsequent manual validation has shown that about 60 percent of the persons found the automatically identified 1 TU Berlin, D-10587 Berlin, Franklinstrasse 28/29 295 groups to be completely correct. This example shows that networks simultaneously allow flows of knowledge and provide connectivity but are also often structured in clusters of actors [12]. Actors tend to cluster in homogenous groups that are only loosely connected to other groups [17]. However such research and the current algorithmic implementations in common SNA tools like Pajek or UCINet only apply structural analysis of community groups. The domain of content analysis with means of information retrieval has not yet been accommodated in the methodological framework of SNA. Previous related research in content analysis and topic mining is focused on algorithms for generating keyword or topic descriptors in semi-formal text [3]. In the few studies of contents of social corpora, the focus was on expert profiling and on subsequent assessment of search strategies to search for persons with appropriate expertise in online networks [26]. The authors applied conventional text mining and indexed all the messages of a person and created a keyword vector, in which a keyword is weighted by its term frequency-inverted document frequency [26]. A precursor to the work in this paper is our content-based analysis and exploration concept called ‘Social Search’ [21]. It combines network visualization and the ability to create topic oriented sub-networks of an online discourse. Despite such initial approaches, these and similar studies mostly use content analysis to profile and search for individuals in social corpora. A comprehensive method of applying content-based analysis to study the group level of social networks is missing. Consequently there is not much known about how topical profiles are spread in social corpora, how virtual groups reflect topics, or if topical analysis would yield divergent group segmentation. With such a gap, every conventional structure-based method will not be able to convincingly detect communities in a multi-contextual network with multiple topics that are simultaneously shared among actors. Such communities are not only structural phenomenon but have been defined by seminal literature as networks about something [25]. 2. Research Objectives Based on the recognition of the above shortcomings, this paper is introducing an approach for content-based community detection in social corpora based on content clustering techniques. With this method, current structural insights about groups in social corpora can be extended with a topical perspective. Identified groups can be related to structural patterns in order to identify topic communities which are inefficiently spread across the interaction structure or which are isolated from other people. With this method, we want to contribute to research on better algorithms to identify group-level properties of electronic networks. This will enable more sophisticated automated awareness services (i.e. to answer questions like who is related to my context, or who is a relevant contact?), the support of large overlapping global teams, or other collaborative community services. Our research is driven by the following two research questions: 1. How can content-based clustering be applied for the detection of topical communities in social corpora? 2. To what extend do groups identified by existing methods of structural clustering correlate with content-based communities? We employ a design science research methodology as our focus is less on empirical insight about factor relationships but on the design and evaluation of a method (a design artifact) [23]. Consequently, the remainder of the paper is organized as follows: In Section 3 the related approaches and basic foundations for content-based clustering in social corpora are given. In Section 4, we introduce our proposed approach to find communities with similar context/collaborative content. We then demonstrate and evaluate the new approach using a 296 corporate e-mail dataset. The corresponding data source is described in Section 5. Finally, we compare our results with subgroups obtained from structural clustering to discuss the general relationship of these two perspectives in Section 6. A conclusion of our findings is presented in Section 7. 3. Methods and Foundations for Community Detection in Social Corpora In this section we briefly introduce related research and corresponding foundations for our approach of content-based community detection. They include the concepts of Social Network Intelligence, event-driven network analysis, measures of topic importance, and algorithms for structural clustering. 3.1. Event-driven Network Analysis Approach The methods presented in this paper relate to the underlying concept of Social Network Intelligence (SNI), initially introduced in [19]. This approach aims at extending conventional network analysis with a dynamic analysis on the longitudinal processes in a social network (network dynamics) and a content-based analysis of social networks. The approach allows studying the change and evolution of network structures, the impact of events, or processes of topic dissemination in networks. A comprehensive account of the resulting advantages is presented in [20]. As SNI requires extensive computational effort, the corresponding software implementation Commetrix has been introduced. Commetrix is a java-based tool constructed for event-based dynamic network analysis and attempts to address the limitations of current approaches [19]. The development of this tool yielded a comprehensive set of software-based methods for exploratory static and dynamic visualization with integrated analysis of social network measures. The methodological core of SNI and Commetrix is event-based network analysis: Relationships are not directly considered but their constituting timed events are captured. In communication network analysis such relational events are created by exchanging messages with others. From these events, relationships can be aggregated. For each event several properties are captured. For example, a time stamp or a topical descriptor of each message event can recorded as a message property. Hence, the sequence of messages and the change in relationship structure or strength is represented as a series of relational events in the data model. In addition to these important changes in capturing relationships, the actual actors are modeled together with their actor properties. 3.2. Measure of topic importance In information retrieval the term frequency-inverted document frequency (tf.idf) weighting scheme is often used together with the cosine similarity to determine the similarity between two documents [18]. The importance of a keyword tk increases proportionally to the number nk,j the keyword appears in the document dj but decreases with the number of documents of the document collection D it appears in. The keyword occurrence in one document is normalized by the total number of keywords tk in the document. As social networks can interact on different types of social content and keywords can be retrieved on different levels of abstraction as single words, or word collections, or concepts, keywords, documents and document collections can be generalized as topics, content objects and content collections. However, the tf.idf measure has some disadvantages when analyzing social content. In particular, we do not compare single content objects but content collections of varying size. Thus, we propose a variation of the tf.idf measure for comparing social content collections. Similar to the tf.idf 297 measure the importance of topic tk for actor a increases proportionally to the number of content objects cj in the content collection of the actor, Ca, containing the topic but decreases with the number of content objects of the overall content base C it appears in. The importance measure can be formalized as: 3.3. Structural Clustering A cluster analysis performed on the network structure seeks to detect densely connected subgroups. A widely used clustering algorithm for community detection is the divisive hierarchical edge betweenness algorithm by Newman and Girvan [6]. The algorithm iteratively removes edges from the network until it disaggregates into smaller subgroups. As a result a hierarchy of nested partitions is obtained ranging from all actors in one large group to each actor in a group by his own2. From this hierarchy the partition is chosen which maximizes the modularity measure [16]. The maximum of the modularity measure indicates that the actors are maximally connected with their group members and minimally connected with other groups. 4. A New Approach of Content-based Clustering In contrast to the edge betweenness algorithm which is working merely on the structure of the network we propose a content-based clustering procedure which takes the network context into account. It is basically an iterative partitioning clustering procedure which assigns objects to clusters due to the similarity of their features. While clustering social corpora the actors are the objects to be clustered and the topics in their content collections are the features the clustering is performed on. The similarities of the topics are calculated from the importance of the topics in each content collection. We assume that collaborative content approximates the context of the network activities and actors are assigned to subgroups with similar context expressed by the content objects they are related to. With the Enron dataset each message is assigned to the content collection of its sender and receiver. In a preliminary semi-automatic text mining procedure the body text and subject of each message is reduced to a set of topics weighted by their importance (see Section 3.2). Each iterative partitioning clustering procedure is characterized by the initial partition, the proximity index, the type of cluster representative, the type of pass and the statistical criterion used [8]. Topic similarities are usually calculated from the cosine similarity [18]. We use the cosine similarity with the K-means clustering method by McQueen [13]. The K-means clustering method is an inclusive, combinatorial K-means pass through the data which is iteratively optimized by the square error criterion. The square error criterion measures the dissimilarity of the members of a group to its cluster representative. The cluster representative is either an object with average feature values (centroid) or the member of the group which is on average most similar to all other members (medoid) [9]. Centroids do not necessarily have an expression in the data objects. For this reason we use medoids as cluster representatives. The results and the performance of a partitioning clustering procedure strongly depend on the chosen parameters. Especially the choice of the initial partition will influence the outcome of the analysis. There are several ways to select the initial partition [1, 2 This holds only for connected graphs. Unconnected graphs already start with their actors assigned to several unconnected subcomponents which are then further divided. 298 8]: a) randomly assign the objects to K clusters, b) select K seed points from the data, e.g. randomly or K well-separated objects, e.g. the centroid of the whole data and then selecting successive seed points which are at least a certain distance away from those already chosen, or c) use a precomputed initial partition, e.g. from a preliminary hierarchical cluster analysis. With the first two methods the optimal number of clusters in the data has to been known, or estimated, before. With the third method using a hierarchical clustering algorithm the optimal number of clusters can be derived from the clustering hierarchy applying an appropriate stopping rule (see [15]). We use an initial partition obtained from a hierarchical clustering procedure using cosine similarity, the weighted average linkage rule by McQuitty [14] and Hartigan’s stopping rule which minimizes the change of the within-cluster sum of squares to the representative of the cluster for two subsequent partitions [7]. Our content-based cluster analysis approach is not intended to compete with the structural clustering but to provide additional insights in group formation processes within collaborative networks. Each clustering procedure will identify different subgroups in a network due to the structural or content-based similarity of the actors. Depending on the network structure they belong to a set of densely connected members that are rather loosely connected to other members. Depending on the network context approximated by the content of their interactions they belong to a set of actors with similar context which are not necessarily densely connected to each other. Besides a visual comparison of the results from the two clustering procedures we evaluate some structural and content-based properties. The structural properties are the density, the average clustering coefficient, the average relationship strength, and the number of unconnected components. The density measures how many possible relationships are established whereas the clustering coefficient measures how many established relationships form relationships themselves. The average relationship strength provides information about the communicational activity within the cluster. The content dissimilarity is measured by the square error value which is the sum of the within-cluster dissimilarities of the content collections of the group members to the content collection of their medoid. To measure the stability in group memberships between the structural and the content-based clusters we use two different measures: The first stability measure is the percentage of structural group members belonging to the same content-based cluster. The second stability measure is based on a version of the Dice coefficient [4] for actor-oriented group membership stability. It measures how stable the group membership of an actor is in terms of constant group members and structural and are the sets of group members of actor in as well as content-based group size. Suppose the structural and the content-based clustering. is then the overlap between both groups. The two actor-oriented group membership stability measures can be formalized as follows: and To calculate the group membership stability of a structural cluster the average values of both actororiented group membership stability measures are used, namely AGMS#1(a) and AGMS#2(a). 5. Data Source Our analysis is based on a subsample of the publicly available corporate Enron e-mail dataset. The Enron Corporation was an American energy company which went bankrupt in late 2001. The 299 subsample sorely consists of internal messages exchanged between non-isolated Enron employees on management level from September 1th 2000 to March 31th 2001. On the one hand this was done to prevent the analysis to be overcrowded with too many peripheral actors with minimal impact on the network and to focus on the internal collaborative relationships (focus on Enron employees). On the other hand preliminary studies on the Enron dataset and its context have shown that within the selected period of time important communication threads can be found as it covers the California's electricity crisis which led to the downfall of the Enron company (focus on selected period of time). Two additional reasons for the subsample selection had to be considered. First, the selected period is more stable in the presence and activity of the network participants than earlier or later periods. Second, as the analysis of subgroups is more interested in larger collections of actors than in single individuals a window size has to be chosen where large and dense network structures can emerge. A much shorter period would yield to networks with many unconnected, stringy components where the results from the structural as well as content-based clustering procedures are obvious. Within the subsample 112 actors formed 441 relationships with average relationship strength of 17.39 messages. The density of the network is 7.09 percent. The diameter only amounts to a path length of 5 steps and the average path length between every pair of at least indirectly connected actors is 2.76 steps. However, there are two unconnected components in the network, one large component with 106 actors and one small component with 6 actors. The core group of active people, which together accumulate 80 percent of all network activity, has a share of 18.75 percent. The maximum degree is 24 contacts. The most active actor has sent 826 and received 234 messages from contacts in the sample. Interestingly, the most active actor and the most connected actor are not the same person. Moreover, the most connected actor has a much smaller network activity with 49 messages sent and 60 messages received, which is an almost perfect reciprocal relation. The clustering coefficient of the subsample, that is how many contacts of all actors are connected themselves, is 35.20 percent. 6. Results and Interpretation The structural as well as the content-based clustering procedure has been applied to the subsample of the Enron dataset described in the previous Section. Figure 1 provides the visual representation of the cluster memberships for both clustering procedures. Table 1 and Table2 contain additional information about the clusters. With the structural clustering (A) most of the clusters are well separated from the others. Only in the extremely dense center of the network the clusters seem to intermingle. In comparison, the content-based clusters (B) are more distributed over the entire network. The members of cluster C4 even belong to two unconnected components of the network. The overall content dissimilarity of each actor to its group members is expressed by the square error value: the sum of squared dissimilarities calculated from the cosine similarities of all actors’ content collections to the content collection of the medoid of their cluster. As the content-based clustering procedure identifies some smaller clusters and two large clusters with 30 (C5) and 48 (C6) members one would expect a larger square error. However, comparing the results from (A), 3.47, and (B), 2.77, the content-based clustering solution identifies more similar clusters. The content dissimilarity as well as the average relationship strength of the structural clusters does not depend on the group size. Cluster S4 has about half the number of members as cluster S7 but the same content dissimilarity. That means the members of the larger cluster S7 have more similar content collections than those in the smaller cluster S4. Clusters S4 and S5 have almost the same size but the members in cluster S5 communicate over more different topics than those in cluster S4. Interestingly, the communicational content of the smaller clusters S1, S2 and S3 is far less similar 300 than that of the larger clusters S4, S6 and S7. The clustering coefficient is high for medium sized clusters and decreases with cluster size. But even in the largest, least dense cluster, S9, almost half of all contacts are connected themselves. A B Figure 1: Structural versus content-based community detection. (A) Structural clustering: 9 clusters, square error: 3.47; (B) Content-based clustering: 12 clusters, 6 singleton clusters (light-grey), square error: 2.77. In contrast to the structural clustering obtained from the edge betweenness clustering algorithm the content-based clusters can contain more than one connected component and sometimes, as with clusters C4 and C6, also include entirely unconnected actors (singletons). As the larger contentbased clusters are spread over the entire network the group density decreases with the group size whereas the communicational activity tends to increase. As with the structural clustering the clustering coefficient is high for medium sized clusters and then decreases. But again, even in the largest cluster many contacts are also connected themselves. The content dissimilarity uniformly increases with cluster size but the relation of content dissimilarity to cluster size decreases. Thus, the group members become more similar with increasing group size. Table 1: Overview of structural clusters and structural group membership stability. Cluster Color Members Square Error Density [%] Clustering Coeff. [%] ∅ Rel. Strength AGMS#1(a) AGMS#2(a) S1 light green 2 0.23 100.0 1.00 0.00 0.00 S2 S3 S4 orange red cyan 6 0.29 33.33 0.00 10.80 0.67 0.42 8 0.24 60.71 68.18 10.00 0.57 0.17 10 0.18 55.56 66.39 71.60 1.00 0.47 S5 dark red 11 0.52 43.64 67.92 21.08 0.67 0.36 S6 dark blue 15 0.20 49.52 62.88 18.94 1.00 0.55 S7 S8 S9 magenta green yellow 18 0.18 40.52 49.04 10.94 0.53 0.35 20 0.76 30.53 44.21 9.97 0.34 0.24 22 0.87 7.83 46.34 30.30 0.25 0.28 Comparing the AGMS#1(a) values some structural group members belong almost entirely to the same content-based cluster: cluster S2 is mostly included in cluster C4, cluster S5 mostly in cluster 301 C5, clusters S3 and S7 mostly in cluster C6. Some structural groups belong entirely to the same content-based cluster, namely cluster S4 to cluster C5 and cluster S6 to cluster C6. The two largest structural clusters S8 and S9 dissolve in several content-based clusters: cluster S8 in clusters C5, C6 and some singletons, cluster S9 in clustersC2, C6, C3 and some singletons. These two clusters have also a higher content dissimilarity. Comparing the AGMS#2(a) values even if most or all members stick together they now belong to larger groups with several new members. The average group membership stability for the whole network is 0.56 for GMS#1(a) and 0.34 for GMS#2(a). That means, for each actor more than half of the structural group members are in the same content-based cluster and about one third of the structural clustering structure (group size and group membership) stays the same. Table 2: Overview of content-based clusters (non-singletons). Cluster C1 C2 C3 C4 C5 C6 Color Members Components (Singletons) Square Error Density [%] Clustering Coeff. [%] light green 2 1 0.00 100.00 2.00 dark blue 3 1 0.13 66.67 0.00 1.50 cyan 11 2 0.29 34.55 58.33 13.89 orange 12 3 (1) 0.37 24.24 71.43 8.31 red 30 1 0.86 20.69 45.89 29.77 magenta 48 2 (1) 1.12 12.50 40.93 23.69 ∅ Rel. Strength In summary, the content-based clusters of the subsample of the Enron dataset still tend to cover well connected and somewhat separated regions of the network, like cluster S6, if they are established through similar content. But at the same time the clustering procedure groups together those actors from different parts of the network, like cluster C4, that are involved into similar topics without regarding their structural relationships. B.1 B.2 Figure 2: Topic spread in content-based clustering. Node color: content-based cluster membership (light gray: filtered out), node label: database id. (B.1) Topic: ‘load curtailment’; (B.2) Topic: ‘Dynegy’. 302 Figure 2 provides a visual validation of the content-based clustering solution (B) in Figure 1 for two different topics. Network (B.1) shows all actors whose content collections contain the topic ‘load curtailment’, network (B.2) those whose content collections contain the topic ‘Dynegy’. ‘Load curtailment’ refers to reducing the energy demand peaks by load balancing, whereas ‘Dynegy’ refers to Dynegy Inc. which is a large energy company and has been a rival of Enron in the energy market. The actors not containing these topics are filtered out. For a better localization of the topic subgroups the inactive nodes and edges are presented in light gray. Both topic subgroups are spread over the entire network. Although the majority of actors involved in the topics belong to contentbased cluster C6, the first topic is better represented by the clustering solution as more actors from the second topic belong to other clusters (namely C3, C4 and C5). However, a clustering procedure establishes group memberships on properties that help to distinguish objects. Thus, if a topic is communicated by too many actors it is not meaningful enough to distinguish them and the groups are established on lesser used topics. The results from the content-based clustering can be used to classify topics and content objects in terms of relevance and distinction. Comparing the topic subgroup in (B.1) with the entire network and the structural clusters in (A) it becomes clear that a mere structural perspective on communicational activities fails to reveal the complex nature of collaborative content. 7. Conclusion This paper introduces a content-based approach to clustering social networks. Similar to most previous studies in the domain of clustering, it could be noticed, that a main challenge is the definition of the number of clusters. Using a corporate dataset of e-mail communication, we could show that the method is able to produce a series of content-related clusters and thus to support the detection of content-based online communities. A comparison of structural and content-based clusters yielded the insight that significant differences between the results of both procedures could be identified. Especially if a topic is spread throughout the structural groups resulting into similar but disconnected actors, or if a structural group is very large, content-based analysis can add value to conventional structural analysis. These results motivate further inquiries into content-based detection of contribute to better algorithms to identify group-level properties of electronic networks. However, in content-based communities, better known as communities of practice or communities of interest, actors can be a member of more than one community joining them on basis of their (temporal) interests [25]. Therefore, we intend to focus on employing clustering-algorithms (such as cliques and n-clans) that allow for multiple cluster memberships. 8. Literature [1] ALDENDERFER, M.S. and R.K. BLASHFIELD, Cluster Analysis, Sage Publications, Newbury Park 1984. [2] BIKSON, T.K. and J.D. EVELAND, The interplay of workgroup structures and computer support, in: Intellectual teamwork: Social and technological foundations of cooperative work, J. Galagher, R. Kraut and C. Egido (Eds.), p. 243290, NJ: Erlbaum, Norwood 1990. [3] CASTELLANOS, M., HotMiner: Discovering Hot Topics from Dirty Text, in: Survey of text mining: Clustering, Classification, and Retrieval, M.W. Berry (Ed.), Springer 2003. [4] DICE, L.R., Measures of the amount of ecological association between species, J. Ecology 26, p. 297-302 (1945). [5] FALLOWS, D., Email at work - few feel overwhelmed and most are pleased with the way email helps them do their jobs. PEW Internet and American Life Project, [cited 2002-2002-01-28]; Available from: http://207.21.232.103/pdfs/PIP_Work_Email_Report.pdf (2002). 303 [6] GIRVAN, M. and M.E.J. NEWMAN, Community structure in social and biological networks, Proc. Natl. Acad. Sci. USA 99, p. 7821–7826 (2002). [7] HARTIGAN, J.A., Clustering Algorithms, Wiley-Interscience, New York 1975. [8] JAIN, A.K. and R.C. DUBES, Algorithms for Clustering Data, Pretence Hall, Endelwood Cliffs, New Jersey 1988. [9] KAUFMAN, L. and P.J. ROUSSEEUW, Finding Groups in Data - An Introduction to Cluster Analysis, WileyInterscience, Hoboken, New Jersey 1990. [10] KOSSINETS, G. and D.W. WATTS, Empirical analysis of an evolving social network, Science Jan 6, p. 88-90 (2006). [11] KRACKHARDT, D., The strength of strong ties: The importance of philos in organizations, in: Organizations and networks: Theory and practice, N. Nohiram and R. Eccles (Eds.), p. 216-239, MA: Cambridge University Press, Cambridge 1991. [12] LEVINE, S.S. and R. KURZBAN, Explaining Clustering in Social Networks: Towards an Evolutionary Theory of Cascading Benefits, Managerial and Decision Economics 27(2-3), p. 173-187 (2006). [13] MCQUEEN, J.B., Some methods of classification and analysis of multivariate observations, Proceedings of the Fifth Berkeley Symposium on Mathematical Statistics and Probability, p. 281-297 (1967). [14] MCQUITTY, L.L., Similarity analysis by reciprocal pairs for discrete and continuous data, Educational and Psychological Measurement 27, p. 21-46 (1966). [15] MILLIGAN, G.W. and M.C. COOPER, An examination of procedures for determining the number of clusters in a data set, Psychometrika 50, p. 159-179 (1985). [16] NEWMAN, M.E.J. and M. GIRVAN, Finding and evaluating community structure in networks, Physical Review E 69, p. 026113 (2004). [17] RAVASZ, E. and A.-L. BARABÁSI, Hierarchical Organization in Complex Networks, Physical Review E 67 (2003). [18] SALTON, G. and M. MCGILL, Introduction to Modern Information Retrieval, McGraw-Hill, New Yoek 1984. [19] TRIER, M., IT-supported Visualization and Evaluation of Virtual Knowledge Communities, Faculty of Computing Sciences and Electrical Engineering, Technical University of Berlin: Berlin, p. 270 (2005). [20] TRIER, M., Towards Dynamic Visualization for Understanding Evolution of Digital Communication Networks, Information Systems Research 19(3) (2008). [21] TRIER, M. and A. BOBRIK, Social Search: Exploring and Searching Social Architectures in Digital Networks, Forthcoming in IEEE Internet Computing (2008). [22] TYLER, J.R., D.M. WILKINSON and B.A. HUBERMAN, Email as spectroscopy: automated discovery of community structure within organizations, in: Proceedings of Communities and Technologies, Kluwer (2003). [23] VAISHNAVI, V. and W. KUECHLER, Design Research in Information Systems, 2004-01-20, [cited 2006-0512]; Available from: http://www.isworld.org/Researchdesign/drisISworld.htm (2004). [24] WASSERMAN, S. and K. FAUST, Social Network Analysis: Methods and Applications, Cambridge University Press, Cambridge 1994. [25] WENGER, E., R. MCDERMOTT and W.M. SNYDER, Cultivating Communities of Practice, Harvard Business School Press, Boston 2002. [26] ZHANG, J. and M.S. ACKERMAN, Searching for expertise in social networks: a simulation of potential strategies, in: Proceedings of the 2005 international ACM SIGGROUP conference on Supporting group work (2005). 304 MINE, YOURS…OURS? DESIGNING FOR PRINCIPALAGENT COLLABORATION IN INTERACTIVE VALUE CREATION Jasminko Novak1 Abstract The paper introduces a theoretically-grounded conceptual framework for the design of collaborative systems which support expert-mediated interactive value creation involving end-users as active participants in the creation of products and services in principal-agent settings. We show how the problems of information asymmetry and burden of choice in interactive value creation can be addressed by integrating the principal-agent perspective with CSCW models of collaboration between heterogeneous actors. Results of a preliminary application and evaluation through the design of a concrete system for cooperative travel advisory in a real-world setting suggest its usefulness and illustrate how it can inform design practice. 1. Introduction The pervasive availability of easy-to-use Internet tools and services for information sharing, interaction and communication (wikis, blogs, instant messaging, social networks) has profoundly transformed the role of end-users from passive consumers to active co-creators of content, products and services in professional value networks. Companies are increasingly devising cooperative business models [5] in which end-users are empowered to active co-creators of value (e.g. manufacturing [25], travel [9], health [2], finance [8]). The term interactive value creation has been used to describe a range of such cooperative arrangements [5], [25]: from new forms of user participation in the consumption process, to personalized interaction [23] to active co-creation of new products and services e.g. through online feedback forums, design contests or user-innovation toolkits [35]. Common to such models are two differentiating characteristics: 1) they are based upon active, voluntary participation of individuals without formal or contractual obligation in the process [5] and 2) they derive a competitive advantage not from the control of information as a scarce resource (information asymmetry) but by actively promoting information symmetry as a mechanism of cooperative value creation [30]. Extensive research in computer-supported cooperative work (CSCW) and human-computer interaction (HCI) has addressed the cooperation mechanisms and social dynamics (e.g. user motivation, coordination) in web-based content creation and sharing platforms (Wikipedia, YouTube etc.) [13], [19] as well as the dynamics of interaction and communication in online communities and social networks (see [24], [33] for an overview). 1 University of Zurich, Dept. of Informatics, Binzmühlestr. 14, CH-8050 Zurich, Switzerland. 305 In contrast, little work has considered the nature of cooperative processes in interactive value creation. While there has been an implicit transfer of the concept of communities as the main unit of analysis for such contexts, a critical analysis of the extent to which this is applicable to interactive value creation is still missing. This concerns in particular the implications of associated issues from the agency theory and related problems of information asymmetry for the design of collaborative systems for value co-creation between users and commercial actors. Accordingly, we address the following question: How can we conceptualize and design collaborative systems which integrate users as active co-creators of value in professional value networks? In particular, we address the problems of information asymmetry and burden of choice in interactive value creation. In devising a theoretically-founded solution we critically analyze the applicability of the traditional notion of group-centric collaboration from CSCW and point to the need of considering the mecentric perspective of individual self-actualization. By relating the principal-agent theory to CSCW models of collaboration between heterogeneous actors we propose a conceptual design framework for collaborative systems enabling expert-mediated interactive value creation. We discuss the application of this model to the design of a concrete system and its preliminary validation by a case study in the travel consultancy domain in a real-world setting. In conclusion we critically discuss how the results of this preliminary evaluation provide insights into the validity of the proposed model and inform the design practice. 2. Interactive Value Creation and Cooperative Business Models The concept of interactive value creation refers to a process of voluntary and active user participation in the development of new products, processes or services targeted at a larger customer group (open innovation) or in the personalization and configuration of existing product or service offerings for a customer’s specific individual needs (mass customization) [25]. A crucial aspect of product individualization is the realization of effective access to knowledge about user needs and preferences. Users are commonly not in a position to explicitly describe their needs and desires beforehand (e.g. before actually seeing or trying out a product) and to express them in terms suitable for integration in a company’s production process. This makes the transaction costs of the elicitation and direct transfer of such “sticky” knowledge prohibitively high [35]. The approach of interactive value creation is based on the premise that by actively involving customers in solving subtasks in product design and production (e.g. feature configuration) the knowledge of user needs is directly embedded by customers themselves into their personal product configurations [25]. This carries profound consequences for companies’ business models. Empowering user participation is a two-sided coin: effective combination of local user knowledge (the problem space) and company-specific design and production knowledge (the solution space) requires revealing company knowledge. The ubiquitous Internet information access also allows users to quickly access product and provider information from a myriad of third-party sources at almost no transaction costs. This dramatically changes the traditional situation of asymmetrical information control in which companies are in the power position by having more or better information then their counterparts in the transaction. Hence, while information asymmetry is a fundamental rentseeking mechanism in traditional models, in cooperative business models providing equal access to information resources to all parties is a key mechanism of interactive value creation [30]. INTERACTIVE VALUE CREATION Variety paradox („burden of choice“) Sticky information (transfer of individual needs) Information asymmetries (uncertainities about provider) Figure 1. Main problems of interactive value creation (according to [25]). 306 However, different studies show that the provision of information to customers doesn’t necessarily lead to increased user empowerment and effective cooperation. The complexity of the solution space and the variety of available options can have an overwhelming effect, resulting in information overload [16] and the “burden of choice” problem [29], causing users to resort to standard solutions [3]. A related problem is the customers’ inability to assess the true quality of the individualized product design in advance, before its production and purchase. This uncertainty is heightened by the inability of comparison with other products (due to individualization) and by the missing recurrence of purchase as common mechanisms of uncertainty reduction for standardized products. This leads to uncertainty regarding the behavior and the performance of the producer, acting as the customer agent (principal-agent relation). Customers also frequently do not have the required knowledge nor patience for dealing with complex solution spaces and for bridging the cognitive gap between perceived personal needs and the possibilities for designing appropriate solutions [10],[22]. With increasing complexity of individualization and related information, the information gap increases instead to diminish. This reduces the effectiveness of user participation and reinforces information asymmetries and uncertainty. In order to conceptualize the design of collaborative systems supporting such value co-creation we need to understand how the above problems relate to the familiar body of knowledge on collaboration extensively researched in CSCW and related fields. 3. “We-centric” Collaboration vs. “Me-centric” Participation In collaboration research, user value co-creation has been largely conceptualized from the “weperspective” of communities and situated in the domain of information goods. Online communities are conceived as social networks connecting people with similar interests or practices who communicate regularly and exchange information and experiences through internet-based information and communication channels (e.g. discussion forums, wikis, online social networking platforms) [24]. Active participation and member contributions are motivated by intrinsic, often group-oriented or altruistic motives such as community citizenship, enjoyment of social interaction, reciprocity and reputation [33]. The defining characteristic of communities is their self-organization and autonomous constitution of social norms, acceptable behaviors and uses of community resources [24]. The collective knowledge built up through member participation is considered collective property of the community and a “public good” of its own, freely available for use and consumption (at least within community confines) [15][24][36]. Such a conceptualization applies to interactive value creation in which group interaction is necessary to accrue commercial benefits from user involvement. However, for the majority of users, the benefits of such goods reside largely in personal usefulness of contributions created by others. The greatest proportion of community users are passive participants who consume community information or services (e.g. finding answers to their needs in a discussion forum). The so-called “lurkers” typically amount to 80-90% of community members [33] and are attracted by extrinsic motivation: the prospect of easily accessible, credible information, highly relevant to their needs [18]. When integrating community-based value creation into commercial value networks, the intrinsic and altruistic “we-based” motivation of user engagement poses problems with respect to acceptable modes of use and exploitation of the community’s “public good”. Community literature makes a strong point about the challenge of establishing company-sponsored communities, initiated and actively facilitated by commercial actors with the goal of exploiting the community activity for organizational or commercial purposes[7][33]. While companies address this by offering extrinsic benefits accrued from the commercial exploitation (e.g. profit sharing, gifts, reputation [33]), empirical research in motivation theory suggests that such extrinsic incentives tend to undermine intrinsic motivation (the “crowding out” effect [6]). On the other hand, insights from motivation 307 research itself show that extrinsic incentives may also reinforce intrinsic motivation [6]. This analysis suggests that integration of user participation into commercial value networks even in intrinsically group-based collaborative value creation cannot be addressed exclusively from the “we-centric” group perspective of traditional CSCW [14]. Moreover, co-creative product individualization is already largely based on “me-centric” individual participation not requiring group collaboration. Accordingly, we argue that a shift of perspective from “we-centric” group collaboration to “me-centric” [14] participation allows us to identify theoretical models and design guidelines for collaboration systems supporting user engagement in commercial value co-creation. 4. The Principal-Agent Problem The change of focus from “we-centric” group perspective with an implied sense of togetherness and pursuit of shared purpose, to individually-motivated “me-centric” perspective requires us to consider potential cooperation problems in customer-producer relationships. This suggests the necessity to consider the principal-agent perspective which addresses transactions between selfinterested parties with differing goals in uncertainty conditions. The principal-agent perspective has been applied to transactions in socio-economic systems in general, characterized by information asymmetry and opportunistic behavior (see overview in [21]). In its application to buyer-seller relationships and electronic marketplaces [21] the buyers are model led as principals who delegate responsibility for acquiring products with desired characteristics to sellers as agents who commonly have greater information about the products and their production [31]. The uncertainty resides thereby in two main sources: the incongruence in goals and the inability of buyers to monitor the sellers’ behavior. The buyer cannot easily assess the true characteristics of the seller and the quality of his products, due to possible misrepresentation by the seller (hidden information). This results in adverse selection i.e. a buyer potentially selecting a seller with inappropriate quality. The buyer also cannot ensure the alignment of seller’s post-contractual actions with his goals and expectations and the delivery of promised product quality (moral hazard). This may result in opportunistic behavior of the seller (pursuing goals not in the interest of the buyer, such as reducing product quality to increase profit or commercially exploiting user’s personal data) [11]. The principal-agent theory frames the uncertainty problem as an information problem while the corresponding logic of signals and incentives as strategies of mitigation suggests that proper use and design of IT-artifacts can prevent and resolve problems of hidden information and hidden action [21]. We can thus apply the principal-agent theory as a conceptual framework for understanding the inherent structure of relationships between users and providers in the model of interactive value creation, an approach up-to-know only marginally addressed (e.g.[25], [34]). The value proposition of companies for enticing customer participation is the promise of obtaining highly personalized products or services tailored specifically to the customer’s needs [22]. To provide this “service”, the company claims the necessity of active user contribution in the design process. Though based on voluntary engagement and not sanctioned with contractual relationships, such participation suggests the existence of principal-agent relations typically found in more formalized arrangements. The problems of user motivation and reactions to commercial exploitation and extrinsic incentives now correspond to familiar problems of hidden information and hidden action. This points to the applicability and necessity of reviewing common solutions for such agency problems in the specific context of interactive value creation. Hidden information and hidden action are typically mitigated through signaling, screening, monitoring and self-selection [21]. In signaling, the agent explicitly communicates his characteristics to the principal in trust inducing ways (e.g. quality guarantee certificates). In screening the principal engages actively in obtaining additional information about agent characteristics, e.g. through performance tests or assessment information from third-parties (e.g. consumer associations, communities). Moral hazard associated 308 with hidden action can also be mitigated through signals as well as through incentive systems, bonding, behavior and performance monitoring. Reporting systems can reduce the information asymmetry and allow the principal to better assess agent behavior. Examples include process tracking or reputation systems where past principals evaluate the agent’s performance (e.g. eBay [12]). The next section analyzes how such techniques can be applied in the design of collaborative systems for interactive value creation. 5. Conceptual Design Framework: Expert-Mediated Interactive Value Creation through Interactive Boundary Objects Most approaches to interactive value creation focus on purely online exchange mediated through product configurators and user-innovation toolkits [25]. We propose enhancing the cooperative process with direct human-to-human interaction. A special form thereof is the design and sale of complex, highly-personalized products and services through a dialogue between the customer and an expert advisor [26]. In contrast to online sales of standardized products, targeting high-volume transactions with relatively simple needs, face-to-face consultations support the sales of complex products where customer needs are difficult to formulate and translate to a tailored configuration [26]. Designing systems for such processes differs both from requirements of web-based ecommerce (efficient interaction in simple transactions) and from classic mass customization. Figure 2. Traditional consultancy setting with a passive customer and asymmetrical information and interaction. This is especially true for “experience goods” whose quality cannot be determined before their purchase [34][17] (e.g. individualized travel, financial services). Not only is the knowledge of user needs difficult to elicit but neither the customer nor the sales agent have a clear idea of these preferences beforehand. The problem space contains highly context-dependent preferences evolving with the discovery of possible solutions. The space of solutions relevant for customer’s needs is not readily visible and is skewed by the intrinsic information asymmetry to the advantage of the agent. The agent is typically sitting behind a desk with a PC providing access to different sources of information with the customer on the other side, with no information access other than product catalogues and printouts [20]. This makes it difficult to integrate customer’s implicit knowledge of his own needs (problem space) with specialized knowledge of the solution space by the agent (Figure 2). The setting implies an inequality of roles and spurs customer’s distrust: Is the agent proposing appropriate solutions? Are there better or financially more viable options? Though the “burden of choice” problem (variety of options) should be solved by the expert mediator, the setting not only puts in question his trustworthiness but also makes it difficult for him to fulfill that task. As a theoretical foundation for tackling this problem we take the people-artifact framework of collaboration [4], since it addresses functional relationships between actors in a cooperative arrangement and tools to support it (Figure 3, left). Its special focus on information flows allows us to easily integrate it with the principal-agent framework. The coordinating role of shared artifacts is extensively documented in cooperation research [27]. Thereby, a special role is assumed by socalled boundary objects, as shared artifacts that can be interpreted and used by actors with differing 309 goals and backgrounds in their own way, appropriate for their own specific perspective [32]. This suggests that overcoming the information asymmetry in face-to-face value co-creation can be realized by providing a shared artifact which allows both parties to make visible and relate their own local worlds of knowledge (problem space of the customer vs. solution space of the agent). This relates the problem of knowledge integration between the customer and the sales agent to the theory of “perspective-making” and “perspective taking” [1]. Accordingly, to allow effective knowledge integration shared artifacts must enable the diverse actors to express one’s perspective in one’s own terms (perspective making), develop an understanding of the perspective of the other (perspective taking) and internalize these insights by expressing them anew in their own terms [1]. This requires that the product palette be visualized on a shared artifact allowing active exploration of different products and their characteristics by both parties (solution space). On the other hand, the problem space must be described in a way which expresses user needs in terms of his world of knowledge as well as in terms of provider criteria, allowing the mapping into the space of possible solutions (e.g. in a travel consultancy, displaying a world map and geographic search for the user alongside with product categories of the travel provider). Accordingly, we propose a conceptual design model for expert-mediated interactive value creation in which the configuration of the product or service is supported by interactive boundary objects mediating shared understanding and the integration of implicit user knowledge in the solution process (Figure 3, right). Figure 3. People-artifact framework [4] & conceptual model of expert-mediated interactive value creation. This model integrates the “people-artifact framework” of collaboration with requirements of cocreation through boundary objects and the principal-agent perspective, to realize a cooperative process of customer-advisor co-creation. The central principle is the creation of an open environment in which the shared artifact visualizes the different perspectives of the customer and the advisor and relates them to each other. This includes the visibility and shared manipulation of all information resources normally available only to the advisor. The transfer of sticky information about user needs into a personalized product configuration occurs through direct user involvement in expressing problem criteria in his own terms and direct exploration of possible solutions. The customer can thus identify options corresponding to his preferences without explicitly describing the criteria underlying his choices. Observing the interplay between options attracting user’s attention and his problem description, the sales advisor can develop an understanding of user needs and propose viable solutions. In this way, the burden of choice problem can be alleviated by human intervention. Displaying the space of all possible solutions to the customer and allowing him to proactively engage in its exploration, is a method for signaling the trustworthiness of the claimed product and seller characteristics, hence overcoming the problem of hidden information. Joint interaction with shared artifacts in an equitable setting can facilitate the creation of social ties and trust, creating an effect similar to bonding which alleviates hidden action. Such an arrangement is also likely to heighten overall trust in the advising process, whereas the inclusion of third-party information (e.g. communities, reputation systems) further restricts opportunistic seller behavior. 310 6. Case Study: Preliminary Application to Cooperative Travel Advisory Travel advisory is an excellent case of an interactive value creation process required for effectively conducting the sale of complex, highly-personalized products and services through a customeradvisor dialogue. Due to increasingly individual customer needs, market pressures and the stickiness of knowledge about customer needs (based on vague general feelings and desires), effective provision of highly personalized travel consultancy has become a critical concern in the travel industry [28]. Hence, the described conceptual design framework has been applied in the travel advisory setting in the following way. The shared artifact is implemented with an interactive large-display workspace allowing touch-based interaction (a Smartboard, www.smarttech.de). The workspace visualizes the problem space (product selection criteria) and the solution space (available products) in one shared surface which allows joint interaction by both parties (Figure 4). Shared visualization of the solution space: - products matching the specified selection criteria - product quality information from thirdparties (community portals) Shared visualization of the problem definition space: - selection criteria expressed in terms of travel products - user-defined search queries List-based representation of the solution space Visual history of inspected resources (graphical thumbnails) Figure 4. The interactive large-display workspace for cooperative travel advisory based on expert-mediated interactive value creation through boundary objects: reducing information asymmetry, furthering trust and promoting cooperation. The physical arrangement in which the customer and the sales agent stand in front of the display emphasizes their equality. Customer needs can be expressed both through selection criteria used by the travel system (product categories e.g. hotels, adventure trips etc.) and in the customers’ world of knowledge (e.g. free search). In a typical case, the agent asks questions about customer’s preferences and maps them to criteria of the problem definition space. The solution space visualizes matching products in a list and on a world map. The user can invoke detailed product information (including ratings from online communities), explore the map of products (zooming into a region shows all related products) or manipulate the selection and search criteria by himself. In this way, the customer can identify options which have not been explicitly expressed in terms of his preferences but s/he can use his implicit knowledge to guide his exploration and recognition of possible solutions. By selecting them he signals the previously unexpressed aspects of his interest to the advisor who can in turn adapt the selection criteria or suggest further products and options. This interplay supports the integration of implicit user needs into the solution design process required for interactive value creation. The implementation of the boundary object model in the interactive workspace provides a shared artifact allowing the participants to express their own individual perspectives, gain insight into the perspective of the other party and jointly interact with the shared material in a dialogue of constructing an appropriate solution (individualized travel offer). The reduction of the information asymmetry, increased transparency of the consultation process and empowerment of the customer to an equal and active partner address the principalagent conflict and act towards increasing the trustworthiness of the setting. The suitability of this model is suggested by the results of a preliminary evaluation of the prototype in a real-world travel agency with 12 customers and 4 sales agents. The evaluation involved solving two vacation 311 planning tasks in a within-subjects design: one accomplished in a classical travel consultancy setting (travel agent with PC, customer with print catalogue) and the other with the Smartboard workspace. User feedback was collected through a questionnaire and informal discussion. As reported in [20], [28] the system was well received by both users and travel agents: in a direct comparison 83% customers preferred the Smartboard as a better travel planning method while 3 out of 4 travel agents found the system very useful for their job. In [20], [28] we reported on general usability, interaction design aspects and user acceptance of the system not relating them to the presented theoretically grounded conceptual framework. Here we focus on overcoming the information asymmetry and furthering of trustworthiness as means of alleviating the principalagent problems. The perceived overall trustworthiness of information (Figure 5) is notably higher for the Smartboard (50% high, 42% very high trustworthiness) than in the classical setting (25% negative and only 16,7% high valuation) [28]. Figure 6. Trustworthiness of third-party information Figure 5. Overall trustworthiness of information [28] This has been attributed to the transparency of the situation (“I see what the agent sees”) and the inclusion of online community information. This is confirmed by the data on the trustworthiness of third-party information, which albeit displaying a smaller difference also shows a tendency of higher trustworthiness in the Smartboard setting (Figure 6). This discrepancy between overall information trustworthiness and the trustworthiness of third-party information in the Smartboard setting suggests that not only the information source (third-party vs. agency database) plays a role in perceived trustworthiness. Active participation of the user in the process and a better overview of available information in the Smartboard setting are likely to account for the difference (being the major distinguishing factors between the two situations). In fact, not only was the visual overview of the solution space greatly appreciated by the users [28] but the quality of the information overview is notably higher for the Smartboard setting (Figure 7) as is the valuation of available means for expressing user needs: both regarding the ease of search based on desired criteria (Figure 8) and regarding the usefulness of available criteria of product selection (Figure 9). Such results support the adequacy of the proposed model for increasing the transparency and perceived trustworthiness of the setting, thus alleviating the information asymmetry problem. Moreover, the increased ease in information access indicated by the results also suggests that the presented model provides appropriate means for alleviating the “burden of choice” problem and effectively supports the user in expressing his needs in terms appropriate to his perspective. Paired with the positive valuation of the usefulness of the system by the agents and the reported ease of use (Figure 10) this indicates the suitability of the developed boundary object model allowing both parties to work cooperatively without giving up their own local perspectives and at an appropriate level of complexity. Overall, such preliminary results of applying the presented conceptual design model in form of a prototype system in a real-world case, point to the suitability of the proposed model for supporting expert-mediated interactive value creation. They suggest that the transparency of the entire setup which exposes all information sources used by the travel agent and all of his actions to the customer, effectively acts as a signaling and monitoring method resolving the principal-agent problems of hidden information and hidden action. 312 Figure 7. Quality of the information overview Figure 8. Easy product search by desired criteria Figure 9 Usefulness of available selection criteria Figure 10. User effort assessment [20] The ability to assess product characteristics not only based on the statements of the sales agent and official information but also based on the reviews and ratings of other users from online travel communities is clearly linked to increased perception of the trustworthiness of information. Paired with the higher valuation of overall user satisfaction with the consultancy process this suggests a successful alleviation of the principal-agent conflict. The higher valuation of user interaction with the shared material and cooperation in finding together a solution through an iterative (and visible!) process of needs (re)formulation, product selection and user exploration of product options, creates a shared social situation which contributes to overcoming hidden action. 7. Conclusions Based on an extensive theoretical analysis we have developed an integrative interpretative framework informing the conceptualization and the design of collaborative systems which support interactive value creation between customers and commercial actors. We have shown how the problems of information asymmetry and burden of choice in interactive value creation can be addressed by integrating the principal-agent perspective with CSCW models of collaboration between heterogeneous actors. The proposed conceptual design framework provides theoreticallygrounded orientation for designing collaborative systems for expert-mediated interactive value creation. A first application to the design of a concrete system for cooperative advisory in the travel domain illustrates how it can inform concrete design practice. The preliminary evaluation suggests the adequacy of the model and shows how framing interactive value creation as a cooperative process in a principal-agent setting provides a useful lens for devising effective solutions to problems of information asymmetry, sticky knowledge and the burden of choice. Obviously, a more systematic validation will require more extensive application and longitudinal observation in realworld use. Furthermore, the transferability of the proposed approach to online mass customization has limits due to the cost-factor of human advisors. However, a number of markets and business services are predestined for such an approach as they significantly depend on the interaction with a human advisor, such as personalized travel, health and financial services. Incidentally, in these areas the application of interactive value creation models has yet to be fully exploited and explored. Moreover, investigating such contexts which naturally lend themselves to effective application of our model can provide insights which may allow subsequent transfer to a fully-scalable approach applicable in online context, e.g. by extending the expert-customer model to online customercustomer interaction or to mediated models aggregating individual into group interactions. 313 8. References [1] BOLAND J.R., TENKASI R.V.Perspective Making and Perspective Taking in Communities of Knowing, Organization Science, 6,4 1995 [2] DAVID, C., Marketing to the consumer: Perspectives from the pharmaceutical industry. Marketing Health Services, 21(1): p. 4, 2001 [3] DELLAERT, Benedict G.C., STREMERSCH, Stefan, Marketing mass customized products: Striking the balance between utility and complexity. Journal of Marketing Research, 43, 2 (May), 2005 [4] DIX, A. J.; FINLEY, J.,ABOWD, G. D., BEALE, R., Human-Computer Interaction. Prentice Hall, NY, 1993 [5] FREEDMAN, J. B. 2007. What Motivates Voluntary Engagement in Cooperative Information Systems. Proc. of HICSS ‘07. IEEE Computer Society, Washington, 2007 [6] FREY, B.S., JEGEN, R. Motivation Crowding Theory, Journal of Economic Surveys, 15(5), Blackwell, 2002 [7] HAGEL, J., Armstrong, A., Net Gain: Expanding Markets Through Virtual Communities, McGraw-Hill, 1997 [8] HARRISON, T., Consumer empowerment in financial services: Rhetoric or reality? Journal of Financial Services Marketing, 7(1), 2002 [9] HJALAGER, A.M. Quality in tourism through the empowerment of tourists.Managing Service Quality,11(4),2001 [10] HUFFMAN, C., Kahn, B., Variety for sale: mass customization or mass confusion. Journal of Retailing, 74, 4, 1998 [11] JENSEN, M., and Meckling, W. H. “The Theory of the Firm: Managerial Behavior, Agency Costs and Ownership Structure,” Journal of Financial Economics, (3:4), 1972, pp. 305-360 [12] KHOPKAR, T., Li, X., and Resnick, P., Self-selection, slipping, salvaging, slacking, and stoning: the impacts of negative feedback at eBay. Proc. 6th ACM Conf. on Electronic Commerce, Vancouver, ACM, New York, 2005 [13] KITTUR, A., Suh, B., Pendleton, B. A., and Chi, E. H. He says, she says: conflict and coordination in Wikipedia. In Proc. CHI’07, San Jose, 453-462, ACM Press, New York, NY, 2007 [14] KOCH, M., CSCW and Enterprise 2.0 - towards an integrated perspective, Proc. 21th Bled eConf., Bled, 2008 [15] KOLLOCK, P.,Economies of Online Cooperation: Gifts and Public Goods in Computer Communities,Routledge,98 [16] MAES, P., Agents that reduce work and information overload. Communications of the ACM, 37 7, 1994 [17] NELSON, P., Information and customer behavior. J. Political Econom. 78 311–329, 1970 [18] NONNECKE, B., Preece, J., "Why lurkers lurk," Proc. AMCIS ‘01, Boston, 2001. [19] NOV, O. What motivates Wikipedians?. Communications of the ACM 50, 11, 60-64. ACM Press, Nov 2007 [20] NOVAK, J., AGGELER, M., SCHWABE, G., Designing Large-Display Workspaces for Cooperative Travel Consultancy, Proc. of ACM CHI ’08, WIP, Extended Abstracts and Applications, Florence, ACM Press, 2008 [21] PAVLOU, P., Huigang L., Yajiong X., Understanding and Mitigating Uncertainty in Online Exchange Relationships: A Principal– Agent Perspective, MIS Quarterly Vol. 31 No. 1, /March 2007 [22] PILLER, F./REICHWALD, R./SCHALLER, CH., Building customer loyalty with collaboration nets, Quinn Mills et. al. (Hrsg.): Collaborative Customer Relationship Management, Harvard Business School, 2002. [23] PRAHALAD, C.K., RAMASWAMY, V., The New Frontier of Experience Innovation. Sloan Management Review, 2003. 44(4): p. 12-18. [24] PREECE, J. Online Communities: Designing Usability and Supporting Socialbilty. John Wiley & Sons, Inc., 2000 [25] REICHWALD, R., PILLER, F.T., Interaktive Wertschöpfung. Open Innovation, Individualisierung und neue Formen der Arbeitsteilung, Gabler Verlag, Wiesbaden, 2006 [26] RODDEN, T., Rogers, Y., Halloran, J., Taylor, I., Designing novel interactional workspaces to support face to face consultations, Proc. of CHI 2003, ACM Press, 2003 [27] SCHMIDT, K., SIMONE, C. Coordination mechanisms: towards a conceptual foundation of CSCW systems design. Journal of Computer Supported Coop. Work 5, 2-3, Dec. 1996. [28] SCHWABE, G., NOVAK, J., AGGELER, M., Designing the Tourist Agency of the Future, Proc. of 21st Bled eConference on eCollaboration: Overcoming Boundaries through Multi-Channel Interaction, Bled, June 2008 [29] SCHWARTZ, B., The Paradox of Choice: Why More Is Less, Harperperennial, 2005 [30] SHAPIRO, C., VARIAN, H.R., Information Rules: A Strategic Guide to the Network Economy, HBS Press, 1998 [31] SINGH, J., Sirdeshmukh, D. “Agency and Trust Mechanisms in Consumer Satisfaction and Loyalty Judgments,” Journal of the Academy of Marketing Science (28:1), 2000, pp. 150-167. [32] STAR, S.L.: The structure of ill-structured solutions: Boundary objects and heterogeneous distributed problem solving. In Readings in Distributed Artificial Intelligence, ed. M.Huhn, L.Gasser, Morgan Kaufman, 1989 [33] TEDJAMULIA, S. J., DEAN, D. L., OLSEN, D. R., and ALBRECHT, C. C. Motivating Content Contributions to Online Communities: Toward a More Comprehensive Theory. Proc. HICSS’05, IEEE Computer Soc., 2005 [34] TERWIESCH, C., LOCH, C., Collaborative Prototyping and the Pricing of Custom-Designed Products, Management Science,Vol. 50, No. 2, February 2004, pp. 145–158 [35] VON HIPPEL, E., KATZ, R. Shifting Innovation to Users via Toolkits. Management Science, 2002. 48(7): [36] WASKO, M.M, FARAJ, S. ‘It is what one does': Why people participate and help others in electronic communities of practice," Journal of Strategic Information Systems, vol. 9, pp. 155– 173, 2000. 314 eCOLLABORATION AND PRODUCTIVITY Katarina Stanoevska-Slabeva1 Abstract Companies are increasingly employing various forms of eCollaboration. Despite its growing importance, there is little research on the impact of eCollaboration. This paper presents the results of an empirical survey of the usage of eCollaboration tools and their impact on productivity Findings indicate that usage of eCollaboration has positive impact on productivity. No correlation was discovered however among eCollaboration and travelling. 1. Introduction and Motivation Since the beginning of the 21st century, eCollaboration has become an increasingly common phenomenon in our global economy. In general, eCollaboration refers to any kind of collaboration situation, where collaboration is partly or fully enabled or supported by specific information and communication technologies. Driven by market globalization, networked organizations, and employee mobility, eCollaboration is rapidly gaining importance in companies worldwide. A variety of different eCollaboration forms can be observed, ranging from loose collaboration initiated in an ad-hoc manner, to well structured and targeted virtual teams that collaborate on a global scale. Despite its growing importance, there is little research on the impact of eCollaboration. The research presented in this paper provides a contribution in this context by pursuing the following research question: "What is the impact of eCollaboration technology on productivity of employees involved in eCollaboration?" Quantitative research was applied to answer the research question. An online survey was applied to assess the felt productivity of participants in international research projects. 112 participants completed the questionnaire. The results revealed that usage of eCollaboration has positive impact on productivity by decreasing time to reach decisions in virtual settings, by diminishing of asymmetries among project participants, and by reducing unproductive time. No correlation was discovered among usage of eCollaboration tools and travelling. The content of the paper is structured as follows: Section 2 provides an overview of the state-of-theart; section 3 contains a description of the research approach, section 4 describes the survey results; section 5 summarizes the results from hypotheses testing, and section 6 provides a conclusion. 1 Universität St. Gallen, CH-9000 St. Gallen, Blumenbergplatz 9 315 2. Overview State-of-the-art The increased importance of eCollaboration has driven much research from a technical perspective regarding the development of various kinds of collaboration tools (see for example [20]). There is, furthermore, a considerable body of research related to the implementation of eCollaboration in organizations and the impact of eCollaboration on organizational structures [17]. In addition, the factors affecting the acceptance of eCollaboration technology have been investigated as well [20]. The usage of eCollaboration technology in organizations has a long tradition and can be considered as a mature technology that according to Gartner [9] is entering the "plateau of productivity". However, less is known about its impact. The goal of the research presented in this paper is to provide a contribution regarding the impact of eCollaboration technology by analyzing the impact of eCollaboration on productivity of virtual teams involved in international European projects. Some body of research is available on the impact of eCollaboration based on case studies. Several published case studies show that collaboration technology might have positive effects on productivity (see for example [4]), [21], [13], [14] and [3]). However, it is difficult to generalize the findings from the case studies as they were conducted independent of each other with different focus (see also [7]). Only few studies have analyzed the impact of eCollabortation based on quantitative research. For example [11], [12] have analyzed the impact of eCollaboration on productivity within supply chains. A basic finding of their research is that the level of efficiency is higher for eCollaboration tools that support operational rather than strategic activities. Lefebvre et al. [12] furthermore found out that the overall impact of eCollaboration is positive but not strongly related to cost reduction. Other research that is relevant to the research question in this paper is of more general nature and considers the impact of information and communication technology on productivity. An important aspect related to impact of ICT on productivity is the so called "IT productivity paradox". This term is attributed to the economist Robert Solow [15]. Solow observed earlier, "…that computers are everywhere except in the productivity data" [15]. During the 80s and 90s many studies showed that investments in ICT had negative or zero impact on productivity growth. An analysis of the reason for this paradox revealed three explanations [15]: 1) Some benefits of ICT in particular in the service sector have not been recorded at that time; 2) Benefits of ICT take considerable time to emerge due to long adoption cycles and need for business process redesign; 3) Many early studies were based on a relatively small sample of companies. New studies show that, the use of ICT is positively linked to performance of companies [15]. However not all companies benefit equally from investments in ICT. Powell & Dent-Micallef [18] have analyzed the reasons why ICT investments in some companies result in productivity improvement and in some they do not provide the expected results. They proved that there is significant interdependence of ICT and the existing human, business and technology resources of a company. ICT investments result in productivity increase only if they are aligned to the company strategy as well as integrated with complementary human and business resources of a company. To summarize, there is indication by previous research that usage eCollaboration has a positive effect on productivity, but it has not been assessed broadly yet [8], [19]. 316 3. Research Approach Given the goal of the research presented here, the following research approach has been applied: 1) definition of terms, 2) identification and selection of units of observation; 3) operationalization of the construct, survey design and hypothesis building; and 4) analysis of the results. In the remaining part of this section first the major phenomena under consideration are defined and operationalized for the empirical research. The results of the survey are presented in section 4. Definition of Terms: The main phenomena considered in the research presented in this paper that need to be defined are: eCollaboration, eCollaboration tools and productivity. - Definition of eCollaboration: eCollaboration is defined with different scope by different authors. While [9] for example states that "Collaboration is about people working together." [1] provides an overview of definitions that are indifferent whether the parties who work together are people, groups or organizations or even machines. In this paper the focus lies on eCollaboration among human participants. Given this eCollaboration will be defined in accordance to [10], as "…collaboration among individuals engaged in a common task using electronic technologies.". The collaborating individuals considered in this research are at different locations. - Definition of eCollaboration Tools: There are various different terms for denoting collaboration technologies in literature. For example group support systems (GSS) [6], collaborative computing [1], E-Collaboration [2]. According to [2] typical functionalities of collaboration systems are: - Communication functionalities: bulletin boards, discussion, e-mail, online paging/messaging, chat, whiteboard and audio/video conferencing. - Coordination or process structuring (see also [22]) functionalities: task lists, project management, contact management, meeting scheduling tools, meeting minutes/records, support for specific workflow and similar. - Collaboration functionalities: screen and application sharing, surveys/pooling, files and document sharing, document and knowledge management. In this study the term eCollaboration tools will be used to denote tools that support communication, coordination and collaboration of individuals in specific collaboration settings. In accordance with [2] and [16] the available tool for support of eCollaboration can be divided in three groups: 1) Communication tools that basically support the communication as part of collaboration; 2) Coordination tools that provide support mainly for coordination activities within collaboration; 3) Collaboration tools that support extensive support for complex collaboration activities. - Definition of Productivity: “Productivity” describes in general the relation between an effort (“input”) and the benefit resulting from this effort (“output”): Output Productivity = Input The output and input are task and process specific. As a consequence also the measurement of productivity is task specific and is defined by task or process specific definition of the categories "Output" and "Input". In general research questions regarding the impact of eCollaboration on productivity can be operationalized as follows: - Does eCollaboration result in increased output per involved employee? - Does eCollaboration decrease the necessary input (for example, time or other resources) to achieve a defined result? 317 - Units of Observation: In order to be able to analyze the impact of the usage of eCollaboration tools on productivity, a fairly large population of employees involved in intensive eCollaboration was necessary. Such a population was identified in the participants of international European research projects. The European commission is funding in so called "Research Frameworks" international cooperative research projects that are carried out by international consortia of cooperating companies and universities. International cooperative research projects have a minimum duration of one year and involve intensive eCollaboration among the consortium partners scattered around different locations in Europe. European cooperation projects and participants in European projects are considered suitable units of observation because of the following characteristics: - European projects are international cooperation projects. According to the rules companies from at least two European companies from different countries need to be involved in a project, in order to have a valid consortium. The resulting collaboration settings are dispersed over several locations, involve several European nationalities and disciplines and eCollaboration is an important part of projects. - The goal of the European projects is collaborative research and development. Productivity is therefore an important goal of eCollaboration as well. Given the above characteristics of European projects and their participants, they can be considered as suitable units of analysis for empirical investigation of the impact of eCollaboration tools on productivity. Such projects are listed in the online CORDIS database (www.cordis.org). 150 project teams of the projects listed there were randomly selected and invited to participate in the survey. Survey Design: In order to design the survey questionnaire the general terms defined in section 2.1 to 2.4 needed to be operationalized for the specific settings of European research projects. - Operationalisation of the Construct "Usage of eCollaboration Tools": Based on the definition for eCollaboration tools provided above, the identified eCollaboration tools have been classified in three categories: communication, coordination, collaboration. For denoting the usage intensity of collaboration tools during collaboration five different stages were chosen: 0-20%, 20-40%, 40-60%, 60-80%. 80-100%. - Operationalization of the Construct "Impact on Productivity": As mentioned above, productivity can be improved either by increasing the output per time unit or decreasing the cost for producing it. Given the fact that international European research projects have different goals, it was not possible to operationalize the impact on productivity by operationalizing the category "Output". Thus, the impact on productivity was basically measured based on the impact on the category "Input". A positive impact on productivity is present, if fewer resources need to be involved in order to achieve the same result. Based on this and in accordance of the empirical studies of [12] the following constructs were defined: - The quality of the decisions and technical discussion with your colleagues were better when supported by eCollaboration tools. - The information asymmetry (deficit of information) in the team regarding available knowledge and persons was reduced by using eCollaboration tools. - The time to reach decisions decreased in eCollaboration settings. - Less travel was required due to usage of eCollaboration technology. - eCollaboration technology providing support for document and knowledge management reduces unproductive time as for example searching for persons and information. 318 Hypotheses Building: Based on the findings of the state-of-the-art in section 2 and the specific operationalization of the constructs under consideration of the specific setting of international European projects the following general hypotheses were defined: - H1: There is positive correlation among usage of eCollaboration tools and the quality of the decisions and technical discussions. - H2: Usage of eCollaboration tools is positive correlated with productivity of eCollaboration by diminishing information asymmetries. - H3: Usage of eCollaboration tools is positive correlated with productivity of eCollaboration by decreasing time to reach decisions. - H4: Usage of eCollaboration tools is positively correlated with productivity of eCollaboration by diminishing cost for travelling. - H5: Usage of eCollaboration tools is positively correlated with the productivity of eCollaborating individuals due to reducing unproductive time. 4. Survey Results Demography of Survey Participants: The questionnaire was send to participants of 150 randomly selected projects from the online CORDIS project database. Participants from 33 projects participated in the survey. In total 227 participants accessed the online questionnaire and 112 filled in the questionnaire completely. The participants in the survey were between 23 and 63 years old. They were located in 20 different European countries. 66.1% of the participants had more than 5 years of experience in eCollaboration. Results Related to Usage of Communication Tools: The usage of various eCommunication tools for collaboration was surprisingly low. The most applied tool is e-mail. No one of the participants has declared to be a non user of e-mail. The remaining communication tools are used by a lower number of respondents: - 40.6% of users do not use instant messaging, only about 15 participants use it more than 60% - 74.7% do not use electronic whiteboard, only 6 participant use it between 40 and 60%. - 73.5% do not use electronic bulletin boards; only 3 participants use it between 40- 60%. - 42.3% do not use forums, 34% use it up to 20% of the time, while only 7 participants use it more than 60% of the time - 71.4% do not use video conferencing at all, and 3 persons use it more than 60% of the time - 14.7% do not use teleconferencing at all - 44.6% do not use Skype at all. In general it can be concluded that there is significant usage of e-mail while the usage of all other communication tools is marginal. Usage of Coordination Tools: Most of the coordination tools show a marginal usage: shared calendar, routing and workflow, user directory and workflow support are not used at all respectively by 53.47 %, 61.62% , 49.00% and 69.00% of the respondents. The only type of coordination tool that showed a higher usage is meeting coordination. There are still 29.41% of non users of coordination tools, but at the same time also 38.83% users that use it up to 40% of their collaboration time. From the different kind of coordination tools, only tools for meeting coordination show a higher usage. All other tools are only insignificantly used by participants. Usage of Collaboration Tools: From the collaboration tools listed in the online survey, the highest usage was reported for: 319 - Document management systems with 25.0% non users and 23% that use it more than 60% of their time. - Collaboration portals are used by 66.66% of participants and 12,12% use it from 80-100% of their collaboration time. - Wikis seems to be increasingly adopted by respondents, as only 36.3% do not use it at all and 19 participants use it even more than 60% of their time. - Blogs and social bookmarking are less popular for project work, as 76.5% and respectively 85.4 of the participants do not use them at all. - Co-authoring tools are used by to a certain extent by 81.8% of the participants. The above findings show that specifically dedicated collaboration tools that provide a more integrated support for collaboration show a higher usage. Emerging tools resulting from Web 2.0 developments are starting to be used. From all Web 2.0 tools, the highest value was reported for Wikis. This reflects also the better suitability of Wikis for project work. Blogs are used less, while all other Web 2.0 tools show marginal usage by a very low number of participants. Interesting is that tools supporting classification as taxonomies or social bookmarking have also marginal usage. Summary of Findings Regarding Collaboration Tools: The above results regarding usage of collaboration tools show that: With respect to communication tools the most used tool is still e-mail. Even though some respondents also use other communication tools, their usage is marginal. Coordination tools are not broadly used as well. Some usage can be observed for shared calendar as well as routing and notification support. The category of collaboration tools comprises tools that offer a more integrated support as for example document management tools, collaboration portals or Wikis. These tools are used by a higher number of users and also with higher intensity than the other tools. In general, tools that offer integrated support show higher usage and intensity of usage. The more routine activities are handled manually, the less the positive effects of collaboration tools can be experienced. The preferences to integrated tools might also result from the specific nature of European projects. These projects are set up for a certain limited period of time. This means that very soon after the start of the project a common environment has to be set up. In many cases then an environment is chosen that offers most of the needed functionalities and is available to the consortium. Tools that offer single functionality might be preferred less, as at the current stage of technology development, it is not easy possible to link them into a common environment. The results also show that none of the tools for which a certain level of usage was reported, are used 100% of the time. Most of them are used about 20% of the time. This means that participants are switching among collaboration and non-collaboration mode. The non-collaboration mode is probably used for preparing individual contributions to the team. The switch between collaboration and individual time has to be supported in a way that it allows smooth transition between eCollaboration and individual work. Summary of Findings Regarding Impact on Productivity: In general the survey respondents reported to have experienced a positive effect of eCollaboration on productivity. The following percentage of respondents either "Strongly Agree" or "Agree" that: a) eCollaboration diminishes unproductive time: 79%; b) eCollaboration has a positive effect on travelling: 76.23%; c) eCollaboration decisions with better quality are made: 64.65%; d) eCollaboration has positive impact on information asymmetry: 64.36; e) less time is needed for reaching decisions: 47%. 320 5. Results from Hypotheses Testing The process of hypothesis testing followed the following procedure: 1) First the data sets, where any kind of usage of eCollaboration tools was reported, were identified. 2) Then an overall analysis of correlations among eCollaboration tools and impact on productivity was performed. 3) The initial general hypotheses given in section 3 were adjusted for the specific tool, for which a significant correlation to impact of productivity was identified. The hypotheses were than tested. 4) Finally, a complete analysis for the category of integrated tools was performed, because these tools were reported to be used most frequently. Testing of Hypothesis 1: The initial correlation analysis revealed that there is a significant positive correlation among "Usage of shared calendar", "Usage of routing and notification function" and "Usage of workflow support" (see table 1 below). Thus, hypotheses 1 was adjusted towards more specific hypotheses as follows: Shared calendar, usage of routing and notification functionality, and workflow support have a significant positive correlation with the quality of decisions made. Table 1: Correlation among coordination tools and impact on productivity Correlations Spearman's rho v_122 Quality of decisons v_123 Information asymmetry v_124 Time v_125 Less travel v_126 Unproductive Time Correlation Coefficient Sig. (2-tailed) N Correlation Coefficient Sig. (2-tailed) N Correlation Coefficient Sig. (2-tailed) N Correlation Coefficient Sig. (2-tailed) N Correlation Coefficient Sig. (2-tailed) N v_97 Shared Calendar .473* .030 21 .264 .276 19 .250 .368 15 .175 .448 21 .205 .361 22 v_98 Meeting Coordination .024 .884 41 .001 .994 37 -.059 .746 33 .189 .231 42 -.008 .957 43 v_99 Routing and Notification .490* .033 19 .558* .020 17 .549 .052 13 .255 .264 21 .152 .501 22 v_100 User Directory .002 .991 23 .226 .311 22 .221 .377 18 -.209 .350 22 .120 .551 27 v_101 Workflow support .578* .049 12 .371 .262 11 .247 .555 8 .324 .280 13 -.050 .859 15 *. Correlation is significant at the 0.05 level (2-tailed). All thee hypotheses were supported by the data as all rs, that means the observed Spearman's rank correlation were not in the rejection reason. All three types of eCollaboration technologies actually provide support for routine activities and lessen the burden of coordination overhead in eCollaboration. As a result more time is available for discussion and decision making. Testing of Hypotheses 2: With respect to the variable "Diminishing of information asymmetry" positive correlation was observed only for tools providing routing and notification functionality (see table 4). Thus, H2 was tested in the following form: "Usage of routing and notification functionality has a significant positive correlation with the variable "Diminishing of information asymmetries". The hypotheses was supported by the data. Testing of Hypotheses 3: A significant positive correlation was observed among Wikis and "Time necessary to make decisions". The adjusted hypotheses, that "Usage of Wikis is positively correlated with time necessary to make decision" was supported by the data. This finding is in line with the core functionality of Wikis to support convergence of opinions and knowledge. 321 Testing of Hypotheses 4: Interesting is that H4 was not supported by the data for any of the tools. For all tools and for each category of tools separately there was no significant correlation among usage of eCollaboration tools and diminishing of the need and costs for travel. This finding contradicts the expectation that eCollaboration would reduce the need for travel within dispersed teams. However, it conforms the findings from qualitative research and case studies that face-toface meetings have an important role in eCollaboration [21]. Independent of the usage of eCollaboration and the ICT support for eCollaboration, face-to-face meetings are scheduled on a regular basis. Thus, the productivity gains of eCollaboration need to be achieved in other areas. Testing of Hypotheses 5: The hypothesis 5 was tested for all tools and each tool separately. Strong correlation was observed and the hypothesis was confirmed that there is positive impact of usage of document management tools and impact on diminishing unproductive time. Testing of the Impact of Document Management Tools: The eCollaboration tools for which the highest usage was reported are document management tools as document management systems, Wikis, Blogs and eCollaboration portals. The correlation to the variables related to productivity is given in table 2 below. Table 2: Correlation among document management tools and impact on productivity Correlations Spearman's rho v_108 Document Management System v_109 Wiki v_110 Blog v_123 v_126 Unproductive v_122 Quality Information v_125 Time of decisons asymmetry v_124 Time Less travel Correlation Coefficien .338** .122 .067 .176 .281** Sig. (2-tailed) .001 .229 .514 .081 .005 N 97 99 98 99 98 Correlation Coefficien .110 .069 .017 -.104 .023 Sig. (2-tailed) .278 .492 .869 .301 .823 N 99 101 100 101 100 Correlation Coefficien .077 -.127 -.003 -.035 .147 Sig. (2-tailed) .460 .214 .978 .736 .153 N 95 97 96 97 96 Correlation Coefficien .192 .007 -.038 .205* .206* Sig. (2-tailed) .061 .943 .712 .042 .043 N 96 98 97 98 97 v_115 Collaboration Portals (i.e. BSCW, Marattech, Google Groups etc ) comprising *. Correlation is significant at the 0.05 level (2-tailed). **. Correlation is significant at the 0.01 level (2-tailed). The analysis taking in consideration all tools together, was based on the following hypotheses: H6: The usage of eCollaboration tools providing support for document management (including automatic search, classification and similar) is positively correlated with the productivity on participants in eCollaboration. First a factor analysis for the most used collaboration tools providing support for document management and for the productivity variables was calculated. The subsequent correlation analysis is presented in table 3 below. 322 Table 3: Correlation matrix among factors for document management and productivity Correlations FAC1_3 Document Management Systems FAC1_3 Document Management Systems FAC1_4 Productivity Pearson Correlation Sig. (2-tailed) N Pearson Correlation Sig. (2-tailed) N FAC1_4 Productivity .319** .002 94 **. Correlation is significant at the 0.01 level (2-tailed). The critical value rP, 0,05 is 0.197 and rP, 0,01 is 0.256. The observed rP = 0.319, which means that the observed Pear's rank correlation coefficient (rp) is in the rejecting region for the null hypotheses at the significance level 0.01 ( rP ≥ rP ,0.01 → 0,319 ≥ 0, 256 ) and significance level 0.05 ( rP ≥ rP ,0.05 → 0,319 ≥ 0,197 ). The null hypothesis that there is no correlation has to be rejected on the 0.01 significance level. Hence, the data supports the hypotheses that collaboration tools providing support for document management have a positive impact on productivity. 6. Conclusion The paper presented the results of an empirical analysis of impact of the usage of eCollaboration tools on the productivity of involved employees. The unit of observation was international European cooperative research projects. The analysis revealed that the usage of document management systems as integrated solutions for collaboration support has a significant correlation with productivity. No correlation was detected in relation to diminishing of travelling time. These results confirm the findings of Lefevbre et al. [12] that no direct correlation among usage of eCollaboration tools to cost can be detected. Participants experience the main value from eCollaboration tools in the support with routine tasks that help to provide more time for the collaboration activities. As a result less time is needed to make decisions and also the quality of decisions improves. The above findings point furthermore out that the focus of the usage of eCollaboration tools has to be on support for routine activities and smooth integration with individual activities and tools. The presented research has several limitations: The evaluation was performed on project level by an anonymous online survey that was sent to project participants. The answers of the participants reflect the felt experiences of individuals with respect to eCollaboration and its impact. This means that only subjective measures are taken in consideration. 7. References [1] Alt, R. (2003). Collaborative Computing – der nächste Schritt im Business Networking, in: Beyer, L. Frick, D. Gadatsch, A., Maucher, I., and Paul, H. (Hrsg.), Vom E-Business zur E-Society. New Economy im Wandel. München: Hamp, 2003. [2] Bafoutsou, G. & Mentzas, G., Review and functional classification of collaborative systems, in: International Journal of Information Management, Bd. 22 (2002), S. 281-305. 323 [3] Cassivi, L.; Lefebvre, E.; Lefebvre, L. A.; Leger, P.M., The Impact of E-Collaboration tools on firm's performance. In: The International Journal of Logistics Management, Bd. 15 (2004), S. 91-110. [4] Collabortaion@Work 2006 - The 2006 report on new working environments and practices. European Commission. Luxembourg Office for Official Publications of the European Communities, October 2006. [5] Dasgupta, S.; Granger, M.; McGarry, N. User Acceptance of E-Collaboration Technology: An Extension of the Technology Acceptance Model. In: Group Decision and Nergotiation, Bd.11 (2002), S. 87-100. [6] Dennis, A. R., Wixom, B. H. & Vandenberg, R. J. Understanding fit and appropriation effects in group support systems via meta-analysis. In: MIS Quarterly, BD. 25 (2001), S. 167-193. [7] Eisenhard, K., Building Theories from Case Study Research, in: Academy of Management Review, Bd. 14 (1989), S. 532-550. [8] Furst, S, Blackburn, R.; Rosen, B. Virtual team effectiveness: a proposed research agenda, Information Systems, 1999, No. 9, S. 249-269. in: Journal of [9] Gartner, Hype Cycle for Collaboration and Communication. Stamford: Gartner, (2006). [10] Kock, N.; Nosek J., Expanding the Boundaries of E-Collaboration, in: IEEE Transaction on Professional Communication, Bd. 48 (2006). [11] Lefebvre, E.; Cassivi, L.; Lefebvre, L. A.; Leger, P.-M., E-Collaboration within one supply chain and its impact on firm's innovativeness and performance, in: Information Systems and e-Business Management, (2003), pp. 158-173. [12] Lefebvre, E.; Lefebvre, L. A.; Le Hen G.; Mendgen, R. (2006): Cross-Border E-Collaboration for New Product Development in the Automotive Industry. In: Proceedings of the 39th Hawaii International Conference on System Sciences. [13] Majchrzak, A., Rice, R.E., Malhotra, A. & King, N. Technology Adaptation: The case of a computer-supported inter-organizational virtual team. In: MIS Quarterly, Bd. 24 (2000), pp. 569-600. [14] May, A. & Carter, C., A case study of virtual team working in the European automotive industry, in: International Journal of Industrial Ergonomics, Bd. 27 (2001), pp. 171-186. [15] OECD, ICT and Economic Growth -Evidence From OECD Countries, Industries and Firms, 2003^. [16] O'Kelly, P. & Gotta, M., Trends in social software. Report for EDUCASE Center for Applied Research (with the Burton Group) 2006. Available online at: www.educase.edu. [17] Orlikowski, W.J., Learning from Notes: Organizational Issues in Groupware Implementation. In: Kling, R. (Hrsg.): Computerization and Controversy - Value Conflicts and Social Choices, Morgan Kaufmann, 1996, pp. 173-189. [18] Powell, Th. C. & Dent-Micaleff, A., Information Technology as Competitive Advantage: The Role of Human, Business, and Technology Resources, in: Strategic Management Journal, Bd. 18 (1997), pp. 375-405. [19] Powell, A.; Piccoli, G.; Blake, I., Virtual Teams: A Review of Current Literature and Directions for Future Research. In The Data Base for Advances in Information Systems - Bd. 35 (2004), pp. 6-36. [20] Schwabe, G.; Streiz, N.; Unland, R., CSCW-Kompendium: Lehr- und handbuch zum computerunterstuetzten kooperativen Arbeiten. Springer, Heidelberg, 2001. [21] Stanoevska-Slabeva, K.; Mirijamdotter, A.: "The Impact of eCollaboration". In: Proceedings of the eChallenges 2007 Conference, Delft, October 2007. [22] Zigurs, I.; Buckland, B.; Connolly J. R.; Wilson, V. E., A Test of Task-Technology Fit Theory for Group Support Systems. In: The DATA BASE for Advances in Information Systems, Bd. 30 (1999), pp. 34-50. 324 SERVICES FÜR RISIKO- UND COMPLIANCEMANAGEMENT Der wirtschaftliche Erfolg und die Wettbewerbsfähigkeit eines Unternehmens sind heutzutage zunehmend von der Flexibilität der Geschäftsprozesse und deren Unterstützung durch Dienste abhängig, welche von Informationssystemen bereitgestellt werden. Um diesen Anforderungen gerecht zu werden und um die Sicherheit sowie Zuverlässigkeit von Informationssystemen zu gewährleisten, wird der Beitrag von IT-Risikomanagement und IT-Governance immer wichtiger. Ein Indikator sind die Compliance-Anforderungen durch internationale Regularien, wie beispielsweise HIPAA, SOX, BASEL II und SOLVENCY II. Für den Track „Services für Risikound Compliancemanagement“ sind Beiträge relevant, die technische oder organisatorische Bereiche des IT-Risiko- und Compliance-Managements abdecken. Leitungsgremium: Günter Müller, Universität Freiburg (D) (Federführender) Stephanie Teufel, Universität Freiburg (CH) A Min Tjoa, Technische Universität Wien Programmkomitee: Hans Ulrich Buhl, Universität Augsburg Hannes Federarth, Universität Regensburg Dogan Kesdogan, Universität Siegen Hannes Lubich, British Telecom Global Services Louis Marinos, ENISA, Kreta EU Martin Reichenbach, Commerzbank Frankfurt Stefan Sackmann, Universität Freiburg Ingrid Schaumüller-Bichl, Fachhochschule Oberösterreich, Hagenberg Reinhold Thurner, Metasafe GmbH INTEGRATED INFORMATION SECURITY RISK MANAGEMENT – MERGING BUSINESS AND PROCESS FOCUSED APPROACHES Sebastian Sowa1, Lampros Tsinas2, Hanno Lenz3, Roland Gabriel4 Abstract Previous papers mostly dealt with specific views of information security management (either technical, organizational for instance). Recently, major progress has been achieved in the development of a business driven approach with BORIS (Business Oriented management of Information Security) and a process-oriented approach called ORBIT (Operational Risks in Business and IT). An integrated framework is being described in this paper that bases on the beneficial and complementary merge of both approaches. It supports management of an enterprise’s information security functions with a strong economic focus whereby it specifically links business and information security objectives. The methodology to be presented has proven to be reliable, user friendly, consistent and precise under real conditions over several years in enterprises with world wide presence. 1. Introduction 1.1. Situation Several models, methods and measures were introduced in the past each covering particular aspects of Information Security (IS) or information risk management. Most of the approaches focus primarily on technical issues but recently, also business oriented approaches for managing IS can be identified in the literacy (i.e. [1], [16]). But again, many of the approaches mainly focus on specialized fields without meeting the challenges of a holistically integrated and practicable concept. They lack in integrating the different interests of relevant actors and even more important, they lack in establishing a system that transparently links business with IS objectives and measures as well as these objectives and measures with a method for defining optimal investment policies. To handle these challenges, a framework for managing IS with a strong economic focus is presented in the following. This starts with the clarification of the appreciation of used terms and intended goals. 1 2 3 4 Ruhr-University of Bochum, Institute for E-Business Security (ISEB), GC 3/29, 44780 Bochum, Germany Munich Re, Koeniginstr. 107, 80802 Munich, Germany ERGO Insurance Group, Victoriaplatz 2, 40477 Düsseldorf, Germany Ruhr-University of Bochum, Chair of Business Informatics, GC 3/132, 44780 Bochum, Germany 327 1.2. Terms Information in this paper is defined as an explanatory, significant assertion that is part of the overall knowledge as well as it is can be seen as specific, from human beings interpreted technical or nontechnical processed data [7]. This definition is precisely in line with the ISO/IEC standards which state that information “can exist in many forms. It can be printed or written on paper, stored electronically, transmitted by post or by using electronic means, shown on films, or spoken in conversation” [9]. As consequence of the appreciation of information, IS has to cover technical as well as nontechnical topics. In this context, the ISO/IEC declares that whatever “form the information takes, or means by which it is shared or stored, it should always be appropriately protected. IS is the protection of information from a wide range of threats in order to ensure business continuity, minimize business risk, and maximize return on investments and business opportunities” [9]. 1.3. Goals The goals defined in this paper are in line with findings in several topic-near publications like [5] and [6], added with the result of several discussions to scientist, practitioners, and of reviews of content related papers [17]. R1: As IS is seen as business and strategic management topic, the Information Security Management (ISM) framework then has to enable executives to transparently link business to IS objectives. R2: The framework should support to answer questions about IS performance as well as it should support to address areas suitable or necessary to improve the performance influencing indicators. R3: The process of defining concrete and measurable indicators for the security target as well as for the current state in different levels of detail should be supported. R4: To close identified gaps, especially investment decisions have to be addressed in the context of the regarded business oriented management framework. Thereby, executives should be given support for the processes of finding and defining cost benefit balanced investment strategies. R5: When measures are running, the framework should offer a method for evaluation that can also be used for optimizing the economic and strategic performance of the overall IS infrastructure. R6: The methods defined have to be integrated into a management process that enables the continuously and especially sustainable business oriented ISM. To fulfil the requirements respectively to reach the goals, the present paper presents two already existing components, BORIS (Business Oriented management of Information Security) and ORBIT (Operational Risks in Business and IT), as well as it introduces the reader to a data model for the coexistence of the currently singularly successfully existent concepts in real environments. 2. BORIS Design 2.1. Overview To handle especially business oriented ISM issues, a framework for the Business Oriented management of Information Security (BORIS) was introduced by [17]. As seen in Figure 1, the framework consists of four layers whereby each layer covers particular aspects of strategic, tactical and operational ISM challenges. 328 1 Cost-BenefitToolbox Strategic Tactical Operational BORIS 2 3 business/information security alignment and performance management, benchmarking process and risk oriented numerical outgoings estimation cost benefit sheets or calculating the return on security investments tools for evaluation and optimization of information security infrastructures 4 integrated program management Figure 1: BORIS general topology The top level focuses on the business and ISM interaction, the second and third layers deal with linking the results of the strategic methods to specific IS objectives and with defining a balanced investment policy for implementing and managing measures targeted to close identified gaps. The fourth layer holds tools for the evaluation and optimization of IS infrastructures while an integrated program management rounds the framework of to ensure continuous effort of the tasks of interest. As the framework is presented in detail in [17], the current paragraphs have the goal of briefly recapitulating major findings and benefits. 2.2. Business Strategic Methods The top layer of BORIS deals with Business/Information Security Alignment and Performance management (BISAP). It consists of a transferring system for linking strategic as well as legal, regulatory, standard implied and contractual drivers to IS objectives and a scorecard system with which performance is measured. Here, the theoretical basis is laid by the Balanced Scorecard [10] that is widely accepted and adopted for several branches and industries as well as the general idea is used for years in the context of information management for instance (i.e. [7]). Because of the aim of connecting the BORIS system with an enterprise Balanced Scorecard, the business strategic method defined here integrates IS performance objectives and metrics in the traditional dimensions finance, customer, processes and future. An organizational dimension is added to the system to match with the requirements of several standards which accentuate the importance of organizational IS performance as well as a sixth dimension is added which covers the importance of the technological IS infrastructure. Analogue to the traditional Balanced Scorecard, also the dimensions of BISAP are connected through a knowledge-based steering methodology. The legal, regulatory, standard implied and contractual as well as strategic requirements are transferred to security objectives by the use of a systematic and formal defined process whereby relevant players such as the chief information officer, business process owners, and officers in charge of legal affairs for instance have to cooperatively agree to. Transferring tables thereby are offered to support this process: Business requirements (formulated in “business language”) here are linked to IS requirement without loosing the vital connection between them. It is only this explicitly applied connector philosophy between business and ISMS that validates the right to exist to any security control. 329 Benchmarking replenishes BISAP. As widely used and accepted method [14] it is anchored in BORIS to supports to identify the own level of maturity while the individual records of performance are set in relation to a peer group of interest. This offers to benefit from the results if data is correctly interpreted and the peers are of adequate competitive importance [13]. For BORIS, the Information Security Status Survey provided by the Information Security Forum (ISF) is currently used. To transfer benchmarking results in the next step to concrete improvement results, the strategies, objectives and identified gaps between the objectives and the current states in each of the six dimensions of the BISAP method are linked to process tactical methods. 2.3. Process Tactical Methods The Process and Risk Oriented Numerical Outgoings Estimation (PRONOE) method is introduced in detail by Tsinas [18]. It is directly linked to BISAP as it uses its output as operational guideline while the data processed in PRONOE again is delivered up to layer 1 in an aggregated format. PRONOE contains three components [17]: A risk assessment layer for determining the qualitative actual and debit, the (100- X)% rule for determining the quantitative debit and a process for the cost-benefit balancing comparison of the qualitative and quantitative actual and debit values which especially supports to address financial investment policy goals. Thereby, a management committee , consisting of the persons in charge of business management, should determine the objectives what concretely means to agree on a specific level of acceptable risk exposure and on the areas which require additional risk controls. This gives the qualitative debit. The qualitative actual then is assessed using common risk assessment methods like scorecards for instance. For BORIS, a questionnaire offered by the ISF is used to address the status of the risk areas in currently five dimensions [8]: Criticality, Level of threat, Business impact, Vulnerability – status of arrangements, and Vulnerability – special circumstances. Recently, effort is spending to transform this layer from the proprietary ISF scorecard to an ISO 27001 aligned structure. This would allow everybody to use this model, and certainly it would support the ISO dimension with eleven risk areas. The (100- X)% rule transfers the level of acceptable risk to protection areas, defined as 100 percent minus the accepted level of risk in percentage. It bases on the assumption that each assertion about acceptable risks directly implicates that any further risks are not accepted and that each assertion also defines the investment areas necessary to reduce the overlapping risk levels to acceptable ones. For cost-benefit balancing comparisons, the actual investment situation is assessed and set in relation to the debits calculated by using the (100-x)% rule. As information is generated here about whether the established security level could have been realized using defined resources or whether an objective has been left unmet because sufficient resources were not available, this element of PRONOE supports to address the appropriateness of the IS investments [12]. 2.4. Financial Tactical Methods Whenever measures have to be implemented in order to reduce defined overlapping risk levels, questions about investments on a more detailed level arise. Here, BORIS offers the calculation of the Return on Security Investment (RoSI) when accurate data is available. If accurate data is missing, is not existing or statistically significant, Cost Benefit Sheets (CoBS) as presented by Sowa et al. [17] should be used. CoBS are quite similar to the approach of Schneier [15] whereby a systematic documentation can enhance CoBS quality as well as it enabled to appropriately justify but also revise investment decision. 330 2.5. Operational Evaluation and Optimization So far, strategic, process and financial tactical methods are introduced and linked to each other what demonstrates a closed chain from business to security business management. For rounding of the quantum of methods, the operational level of BORIS holds methods for evaluating the current controls infrastructure (ECI) as well as for optimizing the necessary controls infrastructure (OCI). As a comprehensive method capable to deal with ECI/OCI is presented by Klempt [11], and Klempt et al. [14], the authors of the current paper abdicate to discuss the method further on. Instead, the method for managing Operational Risks in Business and IT (ORBIT) is introduced in the following paragraphs. 3. ORBIT Design 3.1. Overview Unlike BORIS, ORBIT is a methodology presented first-time in this paper to the scientific community. Chronologically it was designed well after BORIS was already implemented and a certain level maturity achieved. Thereby, the design of ORBIT benefits of underlying effort in the development of BORIS and completes the missing design elements systematically. ORBIT is a system aiming to control operational risks in business processes in regard to information technology consisting of elements called Knowledge Cells (KCs). KCs can be understood as data container that incorporate diverse kinds of topic related information and associations that are of specific interest for a targeted group of information consumer [2], [3]. The system bases on the assumptions that information risks are the primary ones of concern and that technology itself in the consequence has no own risks – apart from internal dependencies towards itself (recursion). Additionally, it is assumed that the requirements of the essential security objectives – availability, integrity, confidentiality and authenticity – are defined within the business processes. From background of this, the following KCs lay the foundation of the approach presented here: Business process, IT system, application system, threat, risk, and measure. In general, the model could be extended to meet the requirements of any kind of operational risks. However, this is not the subject of the paper presented. The KC business process contains the descriptions of an enterprise's core processes, especially in regard to the four typical IS objectives while the KC IT system holds information about the enterprises’ essential IT systems and networks. In addition to general information, the description here also includes the currently achieved degree of performance in regard to the IS objectives of interest, for example, the current confidentiality level or availability class. An IT system thereby may be a platform that supports 1…n business processes. It directly serves as a support for the business process and is described in its own KC. Kinds of threats are also described in a separate KC whereby a threat is defined as one possible scenario or a threatening potential that could impact IT systems [4]. Closely related with threats, the KC risk holds information derived from the quantification of possible threat impacts, whereby common methods like multiplying a probability of occurrence with possible impacts are being used. Finally, the KC measure contains possible actions to achieve IS objectives. As seen in Figure 2, the KCs are linked to each other whereby attributed associations are being used. 331 Role Business process Application Person Protection need Relevance Measure Risk IT system Threat Control Figure 2: ORBIT – Typology 3.2. Method The systemic approach for visualizing the essential IT risks in regard to the core business activities of an enterprise implies to logically link the relevant KCs. Thereby, business processes, IT systems and risks are of essential importance for what reason their relations and the main connected KCs up to measures as seen in Figure 3 are being discussed in more detail in the following. Role Business process Application Person Protection need Relevance Measure Risk IT system Threat Control Figure 3: ORBIT – Essential KCs Business process – IT system: This link enables the identification of dependencies of business processes and IT systems. Here, the targeted level, e.g. the required level of availability of an IT system for a business process, can be compared to the current condition. Thereby, a requirement is fulfilled if all systems comply with the requirements of the particular business process while a requirement is not fulfilled if one or more IT systems deviate from target conditions towards unstable 332 ones. A requirement is surpassed if all IT systems do not undercut the target condition and single ones even hold a higher security level. A comparison of target and current conditions allows a dedicated assessment of necessary measures on the basis of direct dependencies between business processes and IT systems. IT system – Threat: Standardized threat catalogs support in defining individual threat scenarios for an enterprise's IT. Thereby, a scenario can be relevant for 1...n IT systems whereby mainly threats are regarded that may lead to hostile risks when quantifying. Therefore, the reference of a risk and a business process can be created after the quantification of the threat. In the context of vulnerability assessments, threats are being analyzed that jeopardize the proper operation of IT components and can therefore lead to noncompliant security objectives. A differentiation of threats, e.g. with regard to location and type of interface, has to be carried out. Threat – Risk: Threat scenarios that affect single or accumulations of IT systems here are carried over to quantifications. A quantification is the classification of a threat in regard to its probability of occurrence and impact. The levels of probability range from almost impossible to very certain, effects are classified by using a range of insignificant up to hostile. Intrinsic connections allow risks to be allocated to business processes through the relation of threats towards the IT systems. Risk – Measure: For the purpose of risk controllability, risk measures (i.e. controls) have to be implied that observe at least one risk component (the probability of occurrence or the impact) as well as they should reduce the individual classified value. Here, a decision to take a risk and, at the same time, keep a corresponding amount of capital as a reserve, is also to be considered as a IS measure. This special measure is then employed when the investment of the IS measure is higher than the amount of loss, quantified by the department. The quantification of threats finally leads to a survey of risks that have to be controlled as shown in Figure 4. Probability of occurence almost certain very probale Q1 Q2 Focus on risk accumulation control essential Q3 Q4 Ri27 Ri23 probable rather improbale Focus on crisis management almost impossible insignificant minor essential servere hostile Impact Figure 4: ORBIT – Risk matrix The risk matrix is separated into four parts – following industry best practices. In quadrant Q1, the focus lays on the control of accumulated risks. Here, it is analyzed if the risk also occurs in other sectors of business and if there are any correlations with other risks for instance. Shifting to Q2, the 333 criticalities of risks like those of Ri23 and Ri27 are of such height that they need constant observation. Risks that are categorized in Q3 should undergo yearly evaluation. In Q4, the main focus is laid on crisis management. Enterprises should be prepared for worst-case scenarios here for instance. At the point of the risk assessment, the level of threat is defined considering all measures set up for risk control in this context. This so called net risk method is used as a hypothetical assignment of threat levels under the theoretical assumption that no minimizing measures were implemented (gross risk method) is not convenient as it doesn’t reflect the de facto situation. As far as further measures in regard to the net risks have to be planned, the corresponding risk can be evaluated at the next interval under consideration of the degree of implementation. The authors accentuate thereby that the implementation of a regular reassessment process has to be anchored in this management system – starting to run after the implementation of relevant measures at the latest. 4. Merging the Approaches: A generic Data Model for the Integrated Information Security Risk Management After introducing BORIS and ORBIT, the current chapter intends to present a generic data model that bases on the merge of BORIS and ORBIT resulting in a powerful and practicable framework for the business and process focused information security risk management. This data model relies on the fact, that no matter what the management methodology finally is, at the end of the day, the person in charge for the information security risk management functions has to deal with certain key questions like budget, staff, services, strategy, skills, and certainly controls management (e.g. selection and application of proper measurements for the minimization of the information security risks). Thus, this person needs tools capable to support him in answering these questions. Starting to compare BORIS and ORBIT, one of the first results is that both models have a common nominator: The “control management”. No matter, where the need for the selection of a control (i.e. implementation of SPAM-filter, or a security awareness programs for instance) is driven from, it is finally based on a scorecard evaluation of security respectively risk drivers as well as on an appropriate analysis of the cost-benefit situation in this context. An integrated database which contains comprehensively the results of the scorecard evaluations (either from BORIS or/and ORBIT) then is leading to a selection of a control for the driver (a policy or risk for instance) identified. Thereby, to strongly base controls management here on business and economic principles, only those controls will be implemented, which have passed the cost-benefit analysis successfully. Otherwise, because it might become traceable that some of the controls might cause higher investment than the expected benefit, they’ll be rejected. Thus, the role of ISM executives (i.e. CISO or CSO) can be supported in regard to decisions about the adequate control selection as well as it can enhance the productivity of the implemented controls while at the same time the efficiency can be increased. Nonetheless, ISM will still have to deal with decisions and management regarding the budget, skills, strategy, service and people in the IS organization which are not focused on in this paper. Realistically and based on the actual experience of the authors, the merge of BORIS and ORBIT as visualized through Figure 5 is highly enticing and promising to become a leading edge method for information security risk management. Regarding the defined goals at the beginning of this paper, the presented framework can fulfil all of them. As BORIS layer one holds a system for aligning business to security objectives supported by the linkage of the KCs business processes up to risks, R1 is fulfilled. As the scorecard system out- 334 lined in the BORIS concept enables to visualize IS performance on a high level of aggregation, R2 is reached in the consequence. Figure 5: Integrated Information Security Risk Management On the tactical layer, PRONOE is introduced to handle risk-investment oriented challenges. It holds a scorecard for assessing enterprises’ risk areas and supports in visualizing actual and debit state comparisons. Alternatively, ORBIT can be used in this context what collectively fulfils goal R3. Because both models are directly linked to the cost-benefit-toolbox of BORIS that is formed by its layers 2 and 3, offering support for dealing with concrete investment decisions, R4 is reached. Thereby, PRONOE offers the opportunity of calibrating different screws in regard to the individual denotation of a risk area, in regard to the interdependencies of risks as well as in regard to the aggregation criteria for the management summary [17]. In addition to the cost-benefit-toolbox, the ECI and OCI methods help in identifying areas of necessary action from the bottom-up perspective what enables to reach goal R5. A program management cycle that can be overlapping BORIS, including the ORBIT world, is rounding off the framwork in order to link the different tools in a planned and systematic matter, finally fulfilling R6. The structure of the framework is evaluated by interviewing several scientists and IS professionals as well as most parts of BORIS as well as ORBIT in its full structure are already implemented and running successfully in real-time environments of enterprises with world-wide presence. 5. Conclusion and Outlook The paper introduces a comprehensive model for the integrated security risk management, which is vital for any public or private organization. The higher the degree of implementation of the presented model, the higher is the expectation to see optimization of expenses on the one (i.e. minimization) and of the efficiency on the other hand (i.e. maximization of the effectiveness). The authors strongly believe that it is a matter of time where methodologies like the described ones will dominate the behaviour of IS professionals. The main reason for this assumption is, BORIS and ORBIT as well as the introduced common framework “speak” the same language at the control level. 335 Although the paper presents a systematic and holistic concept, ongoing work has to be done. For instance, BORIS and ORBIT are productively used in industrial environments solitary but their integration is just on the design stage. Here, a detailed data-model has to be developed and furthermore used for the development of the database what is one of the most challenging but beneficial tasks. Indeed, the authors predict to have the integrated method fully supported by a combined tool soon to be finalized. Tremendous effort has to be spend to have this vision realized, and the effort itself has to be a subject of decision making and furthermore to show the positive economic impact, as any other “security control”. In other respects, any further work in this direction will become obsolete – which is not going to be the case, as the author experienced so far. Nevertheless, the authors believe that the current versions of BORIS and ORBIT already enable enterprises to overcome several difficulties in the daily life of ISM. It helps to get a transparent insight into the gaps to identify not only what to do but what to do aligned to business goals and financial balance. 6. References [1] ANDERSON, R.; MOORE, T., The Economics of Information Security, in: Science, Vol. 314, No. 5799 (2006). [2] BAGNARA, S., Towards Telework in Call Centres, Euro-Telework Project Report, November 2000. [3] BARBERÁ TOMÁS, D.; DE LOS REYES LÓPEZ, E.; PAGE DEL POZO, Á; LACUESTA, J. S., ‘Contextualized knowledge’. Insights from the Organizational Memory of a Research Institute, Triple Helix 5, The Capitalization of Knowledge: cognitive, economic, social & cultural aspects, Center, Turin, Italy, 18.21.05.2005. [4] BSI, Standard 100-1, Information Security Management System (ISMS), Version 1.0, Federal Office for Information Security (BSI), Bonn 2005. [5] CAVUSOGLU, H., Economics of IT-Security Management, in: J. L. Camp; S. Lewis (Ed.), Economics of Information Security, Boston et al. 2004. [6] CAVUSOGLU, H.; CAVUSOGLU, H.; RAGHUNATHAN, S., Economics of IT Security Management: Four Improvements to current Security Practices, in: Communications of AIS, Vol. 2004, No. 14 (2004). [7] GABRIEL, R., BEIER, D., Informationsmanagement in Organisationen, Stuttgart 2003. [8] INFORMATION SECURITY FORUM, Fundamental Information Risk Management (FIRM), 2008. [9] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION, ISO/IEC 27001:2005: Information technology - Security techniques - Information security management systems – Requirements, Geneva 2005. [10] KAPLAN, R. S., NORTON, D. P., Using the Balanced Scorecard as a Strategic Management System, in: Harvard Business Review, Vol. 74, No. 1 (1996). [11] KLEMPT, P., Effiziente Reduktion von IT-Risiken im Rahmen des Risikomanagementprozesses, Bochum 2007. [12] KLEMPT, P.; SCHMIDPETER, H.; SOWA, S.; TSINAS, L., Business Oriented Information Security Management – A Layered Approach, in: R. Meersman; Z. Tari (Eds.), On the Move to Meaningful Internet Systems 2007: CoopIS, DOA, ODBASE, GADA, and IS, Berlin et al. 2007. [13] LAPIDE, L., Questions to Ask when Reviewing the Benchmarking Data, in: Journal of Business Forecasting, Vol. 25, No. 4 (2007). [14] POWELL, R., The Boom in Benchmarking Studies, in: Journal of Financial Planning, Vol. 20, No. 7 (2007). [15] SCHNEIER, B., Beyond Fear, Thinking Sensibly About Security in an Uncertain World, New York 2006. [16] SOO HOO, K. J., How Much Is Enough? A Risk Management Approach to Computer Security, Workshop on Economics and Information Security, University of California Berkeley, CA 2002. [17] SOWA, S.; TSINAS, L.; GABRIEL, R., BORIS – Business ORiented management of Information Security, Workshop on the Economics of Information Security, Dartmouth College, Hanover, NH, 25.-28.06.2008. [18] TSINAS, L., PRONOE, Process and Risk Oriented Numerical Outgoings Estimation – Vorschlag für eine Methodik zur risikoorientierten Kosten-Nutzen-Balance im Informations-Sicherheits-Management, in: KES, Zeitschrift für Informations-Sicherheit, Vol. 23, No. 4 (2007). 336 EINE RISIKOBASIERTE METHODE FÜR IMPLEMENTIERUNG UND BETRIEB VON GMP KONFORMER IT INFRASTRUKTUR AM BEISPIEL USER- UND IDENTITY MANAGEMENT Peter Brandstetter1, Barbara Ginda, Stefan Tautscher2 Kurzfassung Pharmazeutische Betriebe unterliegen besonderen rechtlichen Vorgaben für das Qualitätsmanagement. Dies gilt sowohl für die Produktion als auch für IT Systeme, die für die Produktion verwendet werden. Die Einhaltung wird von nationalen und internationalen Behörden (FDA, EMEA) überprüft. Der vorliegende Aufsatz beschäftigt sich mit diesen Vorgaben und deren Anwendung auf IT Infrastruktur, wobei ein risikobasiertes Vorgehen im Allgemeinen vorgestellt wird und spezifische Probleme bei der Umsetzung am Beispiel einer zentralen Benutzervergabe diskutiert werden. 1 Vorwort Pharmaunternehmen unterliegen in ihrer Arbeit strengen behördlichen Auflagen, die darauf abzielen, die Gefährdung der Patienten durch fehlerhafte bzw. qualitativ minderwertige Arzneimittel zu minimieren. Ziel der zuständigen Behörden wie etwa der FDA (Food and Drug Administration, Arzneimittelzulassungsbehörde der Vereinigten Staaten) oder der Europäischen Kommission ist es, durch strenge Vorschriften und regelmäßige Kontrollen, so genannten Inspektionen, sicherzustellen, dass das Pharmaunternehmen ein ausreichend gutes und ausgereiftes Qualitätsmanagementsystem nach den Vorgaben der Guten Herstellungspraxis (Good Manufacturing Practice - GMP3) besitzt und dieses bei der Herstellung seiner Produkte auch befolgt. Ein Bestandteil jedes Qualitätsmanagementsystems das sich an den Richtlinien der guten Herstellpraxis orientiert, ist das Instrumentarium der „Validierung“, also die Prüfung einer These durch Bereitstellung eines objektiven Nachweises. Vereinfacht gesagt, dient der Prozess einer Validierung dazu, sicherzustellen, dass ein Prozess oder eine Methode den vom Benutzer definierten Spezifikationen entspricht. Ebenfalls zu erwähnen ist in diesem Zusammenhang der Begriff der Qualifizierung von Geräten. Unter Qualifizierung versteht man die Beweisführung, dass Ausrüstungsgegenstände einwandfrei arbeiten und tatsächlich zu den erwarteten Ergebnissen führen. 1 CSC Intercell 3 Neben GMP gibt aus es auch noch andere Vorgaben, die im Allgemeinen unter dem Kürzel GxP zusammengefasst werden. 2 337 Die im pharmazeutischen Bereich übliche behördliche Definition der Begriffe Validierung bzw. Qualifizierung lässt sich jedoch auch auf den IT Bereich anwenden. Im Allgemeinen wird die dokumentierte Prüfung der Tauglichkeit von Computersystemen als Computervalidierung bezeichnet. Innerhalb der Computervalidierung wiederum unterscheidet man meist zwischen Softwarevalidierung und Hardwarequalifizierung. Bei Softwarevalidierungsprojekten liegt der Fokus auf der Prüfung der Tauglichkeit der Software hinsichtlich ihrer Unterstützung für den abzubildenden Geschäftsprozess. Hardwarequalifizierung dient der Tauglichkeitsprüfung der Geräteteile, die für den Einsatz einer Anwendungssoftware notwendig sind. Um also eine Software validieren zu können, muss zuvor die zugrunde liegende Hardware qualifiziert werden. In dem hier vorliegenden Aufsatz wird eine Methode für die GMP konforme Implementierung und den Betrieb von IT Infrastruktur vorgestellt. Dabei wird nicht zwischen Software und Hardware unterschieden sondern zwischen Anwendungssoftware (Software, die Geschäftsprozesse unterstützt, wie ERP System, LIMS, etc.) und der dazu notwendigen zugrundeliegenden Infrastruktur. Der Begriff IT Infrastruktur wird dabei folgendermaßen definiert: „Gesamtheit aller Computersysteme eines Betriebes bestehend aus der Hardware, Netzwerkkomponenten, Betriebssoftware (jedoch ausgenommen der Geschäftsanwendungen) sowie die zugrunde liegenden Prozesse und Prozeduren, um den Betrieb der Computer Systeme gewährleisten zu können.“ Die IT Infrastruktur Komponenten lassen sich in folgende 3 Kernbereiche unterteilen: • Server: zentralisierte Hardware, das dort installierte Betriebssystem sowie unterstützende Infrastruktur Applikationen (Virenschutz, Datensicherung, etc.). • Netzwerk: Router, Switches, Verkabelungs-Infrastruktur sowie unterstützende Infrastruktur Applikationen (Netzwerk- Verwaltungsprogramme, Firewalls, etc.) • Clients: dezentrale Anwender-Hardware, die darauf installierten Betriebssysteme sowie unterstützende Infrastruktur Applikationen (z.B.: lokale Virenschutzprogramme). Die Planung und Implementierung von IT Infrastruktur ist dem Software-Lebenszyklusmodell ähnlich im Unterschied zur Betriebsführung, wo Infrastruktur sehr häufigen Änderungen unterworfen ist. Der direkte Einfluss von Infrastruktur auf produktrelevante Daten ist jedoch vergleichsweise gering zu dem einer Anwendungssoftware. Daher ist nicht die Funktion einer einzelnen Komponente, sondern das Zusammenspiel und die richtige Konfiguration von entscheidender Bedeutung. Man spricht deshalb bei Infrastruktur nicht von „Validierung“ sondern üblicherweise von „Under Compliance“ [1] (unter Kontrolle durch Einhaltung von Verhaltensmaßregeln). „Under Compliance“ bedeutet in diesem Zusammenhang, dass die Planung, Organisation, Installation, Verwendung und Verwaltung der IT Infrastruktur kontrolliert und dokumentiert wird. 2 Methode der IT Infrastrukturqualifizierung In diesem Kapitel wird anhand eines Modells versucht eine Abgrenzung zwischen Infrastruktur und Anwendungssoftware zu schaffen, wobei die Infrastruktur in 2 Ebenen eingeteilt wird. Diese an sich künstliche Zweiteilung erfolgt, um für die unterschiedlichen Ebenen entsprechend ihrer Komplexität und daher schlussendlich ihres möglichen Fehlerrisikos andere Qualitätsstandards und –maßnahmen zu setzen. Dieses hier vorgestellte Modell und die Vorgehensweise hinsichtlich Validierung/Qualifizierung ist das Ergebnis aus verschiedenen Projekte sowohl unterschiedlicher IT Umgebungen als auch unterschiedlich großer IT Abteilungen und basiert auf Industriestandards wie dem GAMP VModell [1] und ITIL [5]. 338 Klassische Vorgehensmodelle 2.1.1 V-Modell In der Computervalidierung gilt das V-Modell wie es auch im GAMP [1] als Basismodell verwendet wird, als quasi Standard. Auf der linken Seite, die als Entwurfsphase betrachtet werden kann unterscheidet man zwischen Anforderungsdefinition (auch Lastenheft oder User Requirements Specification = URS), funktionaler Spezifikation (auch Pflichtenheft oder Functional Specification = FS) und technischem Entwurf (DS = Design Specification). Abbildung 1: V-Modell nach GAMP Jeder dieser Spezifikationsphasen steht eine Qualifizierungsphase (Testphase) gegenüber. Im Rahmen der Qualifizierung wird die korrekte Installation aller Komponenten (IQ = Installation Qualification), ein detaillierter Funktionstest (OQ = Operational Qualification) und ein Gesamttest des Produktivsystems (PQ = Performance Qualification) durchgeführt. Um den Detaillierungsgrad der Qualifizierungstests zu bestimmen, wird häufig auch eine funktionale Risikoanalyse durchgeführt (siehe auch Kapitel 2.1.3). Das V-Modell ist ein sehr allgemein gültiger Rahmen, der durchaus auch verschiedenste Softwareentwicklungsmethoden, wie z.B.: Spiralmodell, extreme Programming, etc. zulässt. 2.1.2 ITIL Abbildung 2: Management Strategien nach ITIL V2 339 Im Bereich Infrastrukturmanagement wird in der Praxis häufig ein an ITIL [5] angelehntes Modell angewendet. In Abbildung 2: Management Strategien nach ITIL V2 eine Übersichtsdarstellung der vom ITIL Modell abgedeckten Prozesse. Sowohl das V-Modell, als auch die ITIL Prozesse bilden die Basis für die hier vorgestellte Infrastrukturqualifizierung. Qualifizierung von IT Infrastruktur 2.1.3 Risikobetrachtung – Risiko Management Da die Validierung von IT einen nicht unerheblichen Aufwand bedeutet, hat sich ein risikobasiertes Verfahren etabliert, wo der Aufwand der Qualitätssicherungsmaßnahmen in Relation zu dem möglichen Einfluss einer Funktion oder einer Komponente auf die Qualität des pharmazeutischen Produktes bzw. das Leben des Patienten gestellt wird. Es gilt also, je mehr eine Funktion bzw. eine Komponente das zu produzierende Arzneimittel beeinflusst, desto besser muss auch dessen korrekte Funktionsweise abgesichert werden. Abbildung 3: Risikomanagement nach ICH Q9 Risk Management ist als ein ständig begleitender Prozess zu sehen. Sowohl in der Entwurfsphase und der Implementierung, als auch im Betrieb werden mögliche Risiken betrachtet und entsprechende Maßnahmen (z.B.: redundante Server oder detaillierte Funktionstests) zur Risikominimierung gesetzt. In Abbildung 3: Risikomanagement nach ICH Q9 [4] ist ein allgemein üblicher Riskomanagement Prozess dargestellt. 340 2.1.4 Modell einer Infrastrukturqualifizierung Abbildung 4: Infrastruktur Qualifizierungsmodell Das wesentliche Ziel der Computervalidierung ist es, zu gewährleisten, dass IT Systeme, welche die Qualität der Medikamentenproduktion und somit die Gesundheit des Patienten gefährden könnten, korrekt funktionieren. Mit Risikomanagement werden die Qualitätssicherungsmaßnahmen auf die Bereiche konzentriert, die höheren Einfluss auf die Qualität des pharmazeutischen oder medizintechnischen Produktes haben. Betrachtet man nun die unterschiedlichen Komponenten einer typischen IT Landschaft, so ist aus dem Gesichtspunkt der Computervalidierung heraus eine Aufteilung in Applikation und Infrastruktur sinnvoll (siehe Abbildung 4: Infrastruktur Qualifizierungsmodell), da auf Applikationsebene noch sehr deutlich die Kritikalität einer Applikation von einer anderen hinsichtlich der Patientensicherheit unterschieden werden kann, und natürlich auch auf funktionaler Ebene innerhalb einer bestimmten Applikation. Gerade bei Hardware und vor allem zentralen Komponenten, wie Server, virtuelle Server, Netzwerk, SAN, etc, wo eine physische Einheit unterschiedliche Applikationen bedient, ist diese Vorgehensweise nicht mehr möglich. Andererseits ist in dieser Risikobetrachtung auch der Grad an Standardisierung zu berücksichtigen und auch die Fehlertoleranz einer Komponente. Aufgrund von deutlich höherer Standardisierung, die allein durch das mögliche Zusammenspiel von Komponenten unterschiedlicher Hersteller notwendig ist und auch nachdrücklicher verfolgt wird (z.B.: Festplatten unterschiedlichster Hersteller funktionieren in einem PC), kann Hardware weniger fehleranfällig eingestuft werden, als etwa eine individuell erstellte Software. Außerdem besitzen Hardware und auch z.B.: Netzwerkprotokolle üblicherweise sehr robuste Fehlerkorrekturmechanismen, oder zumindest Fehlererkennungsfunktionen, was das mögliche Risiko eines unerkannten Fehlverhaltens noch weiter senkt. Ähnlich gelagert sind Infrastrukturdienste, die unterschiedlichen Applikationen zur Verfügung stehen, wie z.B.: Dateisystem, Druckdienste, Netzwerkprotokolle, etc. In unserem Qualifizierungsmodell verstehen wir unter dem Begriff Infrastrukturdienste jene Software, die nicht ausschließlich von einer Applikation genutzt wird, sondern vielmehr so gebaut ist, dass viele unterschiedliche Anwendungen sich ihrer Funktionen bedienen. Schon durch diesen Umstand müssen solche Dienste robuste gut definierte Schnittstellen aufweisen, die auch eine Fehlerkorrektur oder -erkennung ermöglichen. Weiters sind in unserer Betrachtung Infrastrukturdienste als Standardkomponenten anzusehen, die sich einer großen Verbreitung erfreuen. Aufgrund des hohen Verbreitungsgrades ist die Wahrscheinlichkeit, dass Fehler schnell 341 erkannt werden sehr hoch. Bei der Qualifizierung von Infrastrukturdiensten ist jedoch eine gesonderte Risikobetrachtung für jeden Dienst sinnvoll und abhängig davon die Teststrategie festzulegen. Zusätzlich wird die Funktionalität der Hardware und von Infrastrukturdiensten auch bei der Überprüfung der Applikation implizit mitgetestet. Aus diesen Umständen heraus ist ein detaillierter Funktionstest von Hardware und Infrastrukturdiensten nicht notwendig, vielmehr ist es wichtig, korrekte Installation und Konfiguration sicherzustellen und zwar nicht nur zum Zeitpunkt der Inbetriebnahme, sondern auch über den gesamten Lebenszyklus hinweg (siehe auch 0). Vor allem wenn IT als einziges Medium für die Aufzeichnung und Archivierung von produktionsrelevanten Daten verwendet wird, ist eine sichere und korrekte Langzeitspeicherung dieser elektronischen Daten zu gewährleisten. Eine gute Backup und Archivierungsstrategie ist daher unumgänglich, wie auch ein Disaster Recovery Konzept (z.B.: in Anlehnung an die ITGrundschutzkataloge des deutschen Bundesministeriums für Informationssicherheit [3]). Im Gegensatz zur Sicherung korrekter Funktionalität bei der Validierung von Software ist daher der Fokus bei Qualifizierung von Infrastruktur auf korrekte Installation und Konfiguration und sichere Betriebsführung zu legen. Um dies zu gewährleisten ist auf Basis eines verkürzten V-Modelles der folgende Prozess sinnvoll (Abbildung 5: Qualifizierungsprozess). Specification & Design Phase Planning Risk Assessment & Qualification Planning IQ and OQ Operation & Maintenance Phase Qualification End Abbildung 5: Qualifizierungsprozess 2.1.5 Specification & Design Phase Ähnlich wie bei Geschäftsanwendungen sind die Anforderungen an die Infrastruktur noch systemunabhängig zu definieren. Vor allem Sicherheitsaspekte wie Datensicherheit und Zugriffssicherheit sind dabei zu beachten, aber auch Kapazitative wie Datenmengen, Antwortzeiten, etc. Ausgehend von den Anforderungen wird dann sowohl die entsprechende Hardware ausgewählt, als auch Konfigurationsparameter für Dienste bestimmt. Dabei ist natürlich auch die vorhandene Infrastruktur mit einzubeziehen. Schon beim Design von Infrastruktur empfiehlt es sich, Risikomanagementwerkzeuge anzuwenden, um wichtige Parameter zu dokumentieren, und sicherzustellen, dass diese auch in der Designphase nicht vergessen werden. Für kritische 342 Parameter ist eine Festlegung vor der Installation notwendig, denn nur so kann erreicht werden, dass durch die Durchsicht von Dokumenten eine entsprechende fachliche Überprüfung des Designs erfolgt und auch in Form von Testprotokollen die echte Konfiguration der Infrastruktur mit den geplanten Werten übereinstimmt. Standardisierter Checklisten und Dokumentationsvorlagen für unterschiedliche Komponenten (z.B.: Vorlage für Design eines Windows Servers) erleichtern diese Phase. 2.1.6 Risk Assessment & Qualification Planning Die Überprüfung bei der Installation und Konfiguration beschränkt sich auf eben die im Design festgelegten kritischen Parameter. Ob eine Konfiguration nur durch Prüfen der Einstellung oder auch durch Testen der entsprechenden Funktion verifiziert wird, hängt von der Komplexität der Einstellungsmöglichkeit und der Kritikalität der Komponente ab und wird über eine Risikoanalyse bestimmt. Ein weiterer wesentlicher Faktor, der eine reibungslos funktionierende Infrastruktur ermöglicht, ist die richtige Qualifikation der Administratoren. Es ist daher auf entsprechende Ausbildung eigener Mitarbeiter oder Nachweise von Drittfirmen zu achten. 2.1.7 IQ & OQ Nach Abschuss der Planung der durchzuführenden Tests erfolgt nun die dokumentierte Installation (IQ = Installation Qualification) und die Funktionsüberprüfung (OQ = Operational Qualification). Es muss darauf geachtet werden, dass alle durchgeführten Schritte nachvollziehbar dokumentiert werden, da vor allem diese Dokumentation den Nachweis liefert, der im Rahmen von Behördeninspektionen geprüft wird. 2.1.8 Operation & Maintenance Nach Abschluss der Tests kann die Infrastruktur verwendet werden. Aus Qualitätssicht sind dabei vor allem Fehler- und Änderungsmanagement wichtig, die im folgenden Unterkapitel beschrieben wird. 2.1.9 Traceability Dass auch alle im Design festgelegten Vorgaben geprüft werden wird über die sogenannte Rückverfolgbarkeit (Traceability) garantiert. Diese kann entweder in einem eigenen Dokument erfolgen, oder aber auch in allen Phasendokumenten enthalten sein. Fehler- und Änderungsmanagement Neben der kontrollierten Installation/Konfiguration von Infrastruktur ist der sichere Betrieb ein wichtiges Qualitätsmerkmal. Industriestandardmodelle wie ITIL bieten sehr detaillierte Methoden für den sicheren Betrieb von Infrastruktur. Hier sollen nur die wichtigsten Aspekte der zwei wesentlichsten Prozesse (Fehler- und Änderungsmanagement) erläutert werden, um den Anforderungen einer qualifizierten Infrastruktur nach FDA und GMP zu genügen. 2.1.10 Fehlermanagement Um mögliche Fehlfunktionen erstens zu erkennen und zweitens entsprechend der Kritikalität zu beheben, sind folgende Dinge zu beachten: 1. definierter Fehlermeldungsprozess (Helpdesk) 2. Fehlerqualifizierung 3. nachvollziehbare Fehlerbehebung 343 Um langfristig die Fehlerzahl zu senken, ist präventives Fehlermanagement ein probates Mittel. Dabei werden periodisch durch Analyse der gemeldeten Fehler Präventivmaßnahmen abgeleitet und umgesetzt. 2.1.11 Änderungsmanagement Im Gegensatz zum Fehlermanagement, geht es bei Änderungsmanagement um die kontrollierte Umsetzung von Änderungen und nicht der Behebung eines Fehlverhaltens. Dabei ist zwar ein ähnlicher Prozess zu durchlaufen, jedoch ist zusätzlich noch eine Genehmigung vor der Durchführung einzuplanen und die bereits bestehende Dokumentation anzupassen. Konsequentes Änderungsmanagement ist für eine kontrollierte Infrastruktur unumgänglich. Andernfalls wird innerhalb kürzester Zeit aufgrund von nicht qualitätsgesicherten Anpassungen die gesamte Infrastruktur destabilisiert. Automatisierungswerkzeuge Durch die bereits erwähnte Häufigkeit der Änderungen bei Infrastruktur entsteht eine Flut an Daten, die sich ohne geeignete Automatisierung der Verwaltung der Daten nicht bewältigen lässt. Der Einsatz von computergestützten Systemen (Tools) zur Verwaltung der Infrastruktur darf jedoch zu keiner Verminderung hinsichtlich der Einhaltung von GxP-Richtlinien führen. Dies würde bedeuten, dass Software zur Automatisierung von Infrastruktur-Prozessen im selben Ausmaß wie Geschäftsanwendungen validiert werden müssten. GAMP 5 [1] schlägt jedoch ein anderes Vorgehen vor. Für sogenannte „Infrastruktur Software" (Netzwerküberwachungs-, Anti-Virus- und Konfigurationsverwaltung – Software, etc.) ist keine vollständige Validierung vorgeschrieben. Bei einfachen Tools, die „Out-of-the-Box“ ohne weitere aufwendige Konfiguration eingesetzt werden könnnen, genügt die kontrollierte und dokumentierte Installation (IQ) und ein einfacher Gesamttest der Funktionalität des Systems (PQ). Begründet wird diese Vorgehensweise mit der Ansicht, dass Infrastruktursoftware keinen direkten Einfluss auf die Sicherheit des Patienten hat, also ein deutlich geringeres Risiko darstellt. 3 Beispiel: Benutzerverwaltung und Authentifizierung Anhand des Beispieles Benutzerverwaltung und Authentifizierung werden wichtige Problemstellungen aus Sicht der risikobasierten IT Infrastrukturqualifizierung diskutiert, wobei der Schwerpunkt in der Darstellung der Anwendung von Risikomanagement liegt und daher detaillierte Schritte der Qualifizierung (Verification, Traceability, …) nicht explizit gezeigt werden. Das Risiko ist in diesem Fall der unbefugte Zugang zu Anwendungen den es weitestgehend zu verhindern gilt und den Anwendern dabei trotzdem höchstmöglichen Komfort zu gewähren. Userverwaltung für Qualifizierungsrelevante Infrastruktur: Designüberlegungen Im regulierten oder sicherheitskritischen Umfeld stellen sich zwei grundsätzliche Überlegungen unter der Betrachtung des oben genannten Risikos: • Will man den Anwendern ohne zusätzliche gesonderte Authentifizierung Zugriff zu GxP relevanten System geben ? • Wie kann eine, den Anforderungen hinsichtlich Flexibilität und GxP-Konformität entsprechende Userverwaltung mit einem zentralen Userverzeichnis hergestellt werden? Diese beiden Fragen zielen auf die prinzipielle Designentscheidung hin: zentrale Authentifizierungsinfrastruktur (= als Infrastrukturdienst) vs. getrennte Systeme für GxP und nichtGxP relevante Applikationen/Bereiche. 3.1.1 Zentrale Authentifizierung für GxP- und Nicht-GxP-relevante Systeme Wird ein zentraler Authentifizierungsserver verwendet, der sowohl von GxP- als auch von nichtGxP Anwendungen verwendet wird, so muss dieser zwangsläufig unter den strengeren GxP- 344 Richtlinen aufgesetzt und betrieben werden. Sämtliche Änderungen (z.B.: an den Rechten oder den Stammdaten) unterliegen dann dem Änderungsmanagement. Es muss aber auch möglich sein, dass nicht-GxP relevante Applikationen diesen Dienst verwenden können. Steht der Authentifizierungsserver etwa in einem getrennten Netzwerksegment, müssen entsprechende Anfragen zugelassen werden. In einfachen Systemen mag dies eine taugliche Möglichkeit darstellen, bei komplexeren Systemen, wenn beispielsweise auch Server aus einer DMZ Benutzer authentifizieren müssen (z.B.: Mail- oder Proxyserver) ist ein solches System aus sicherheitsrelevanten Aspekten nicht zielführend. 3.1.2 Getrennte Authentifizierungssysteme Alternativ können für die verschiedenen Sicherheitsbereiche (als solches kann eine GxP-Landschaft betrachtet werden) unterschiedliche Authentifizierungsserver implementiert werden, im vorliegenden Beispiel also ein Directory für nicht-GxP relevante Anwendungen sowie ein eigenes für alle GxP-kritischen Anwendungen. Dieses Setup hat mehrere Vorteile: • eigenes Login für den GxP-kritischen Bereich schafft Bewusstsein beim Benutzer (z.B.: Einhalten von SOPs erforderlich, …) ohne die grundsätzlichen Vorteile eines SSO (=Single Sign On Lösung) zu vernachlässigen (SSO jeweils innerhalb eines Bereiches), • höherer Sicherheitsstandard durchsetzbar, da die Anzahl und Art der Applikationen normalerweise kleiner ist, • keine Kommunikation zwischen GxP-Authentifizierungsserver und nicht-GxP Applikationen notwendig. Um den letzten Punkt sicherzustellen ist es notwendig, dass die Geschäftsanwendungen nicht am Benutzerclient installiert werden (dieser kann auch in der Regel nicht zwei unterschiedliche Benutzerkonten verwalten). Das kann relativ einfach z.B.: dadurch erreicht werden, indem alle Applikationen auf einem Terminal Server (TS) bereitgestellt werden, welcher sich im GxP-Bereich befindet. Am Client muss nun lediglich sichergestellt werden, dass die Kommunikation zwischen TS-client und dem TS verschlüsselt wird. Diese Variante hat allerdings einen Nachteil: Zwei verschiedene Server benötigen auch eine doppelte Benutzerverwaltung. Für die Benutzerkonten selbst sowie die reine Rechtevergabe (etwa Mitgliedschaft in verschiedenen Securitygruppen) mag dies kein allzu großer Nachteil sein, bei klassischen Stammdaten (etwa Telefonnummer, Emailadresse, Sozialversicherungsnummer, ...) ist die doppelte Pflege allerdings sehr mühsam und vor allem fehleranfällig. Zudem müssen oft Applikationen (z.B.: ein ERP-System) auf beide Datenbestände zugreifen (da ja nicht jeder Benutzer zwangsläufig ein login am GxP-System benötigt). Damit existiert aber nun eine Anzahl an Benutzern mit doppeltem Login, was Berichte z.B.: hinsichtlich der tatsächlichen Mitarbeiterzahl (basierend auf dem am System existierenden Accounts) erschwert. 3.1.3 Identitymanagement vs. Accountmanagement Eine Möglichkeit dem Problem der doppelten Stammdatenwartung beizukommen besteht darin, die unterschiedlichen Login- und Berechtigungsdaten (die Accounts) von den unveränderlichen Stammdaten (der Identity) zu trennen, d.h. man speichert alle personenbezogenen Daten auf einem getrennten System, dem „Identity Service“ und verknüpft lediglich mehrere System Accounts (z.B.: GxP- und nicht-GxP kritische Benutzerdaten) mit denen der physikalischen Person. Attribute, wie Telefonnummer usw., die nicht mit den Benutzerkonten zusammenhängen werden im Identitymanagement-System gespeichert. Im Directory des Authentifizierungsservers verbleiben lediglich die Login- und Berechtigungsinformationen sowie ein Link zur Person im Identity Directory. Selbst für Systeme mit einem lokalen Authentifizierungsmechanismus kann ein solches Vorgehen genutzt werden wenn die entsprechenden Schnittstellen zur Verfügung stehen. 345 Je nach Art der Daten und Verwendungszweck muss entschieden werden, ob dieses System GxPkritische Daten enthält oder nicht, im zweiten Fall kann dies auch von Personen, die nicht notwendigerweise eine Ausbildung im GxP-konformen Arbeiten besitzen (z.B.: die Personalabteilung) gewartet werden. Speziell bei Internetapplikationen gibt es derzeit schon Ansätze eines zentralen Identitymanagements, welches von verschiedenen Diensten verwendet wird (exemplarisch sei z.B.: die yahoo liveID erwähnt), im Firmenumfeld gibt es zum derzeitigen Zeitpunkt leider noch kein System (zumindest „Out-of-the-box“), welches eine Unterteilung in Account- („usercredentials“) und Identityinformationen (Stammdaten) ermöglicht. Dazu kommt, dass das zentrale Directory im Normalfall nicht alle Stammdaten einer Person erfasst (z.B.: Personaldaten), es zwar in den meisten Applikationen, die via zentralem Directory authentifizieren können, eine Verbindung zwischen Account- und Personentabelle gibt, diese im Regelfall jedoch als 1:1 Verbindung ausgeführt wird. Eine notwendige 1:n Verbindung (1 Personendatensatz für mehrere Systemaccounts) muss demnach meistens zusätzlich programmiert werden. Hinsichtlich der Validierung eines solchen Systems muss demnach mit einem größeren Aufwand gerechnet werden. Fazit Grundsätzlich können beim Design der Infrastruktur für GxP-relevante Applikationen mehrere Ansätze gewählt werden, wobei im Hinblick auf die Validierung des Gesamtsystems hierbei besonderes Augenmerk auf die Schnittstellen der Infrastruktur und der Systeme gelegt werden muss. Dies gilt im Besonderen für die Passwortauthentifizierung und Benutzerverwaltung: unterliegt die Verwaltung der Benutzerdaten keiner Kontrolle so kann das Gesamtsystem nie „Under Compliance“ sein. Weiters unterliegen GxP-relevante Systeme typischerweise höheren Sicherheitsanforderungen, weshalb auch die Schnittstellen der Authentifizierungsserver nach außen hin (in Zonen mit niedrigeren Sicherheitsansprüchen oder -möglichkeiten) möglichst gering gehalten werden müssen. Duplizierung der Authentifizierungsinfrastruktur ermöglicht es hier, die Vorteile eines zentralen Directories elegant mit den Anforderungen diverser Regularien in Einklang zu bringen. Die doppelte Wartung von Stammdaten stellt in diesem Zusammenhang ein Problem dar, einfache und standardisierte Lösungen existieren hierfür noch nicht. Will man dem Mehraufwand einer doppelten Stammdatenwartung durch Schaffung eines Identity Management Systems entgehen ist in jedem Fall Individualprogrammierung vonnöten, die aber wiederum unter dem Risikoaspekt erhöhter Fehleranfälligkeit betrachtet werden muss. 4 Literaturverzeichnis [1] International Society for Pharmaceutical Engineering (ISPE) (2008): GAMP 5. A risk-based approach to compliant GxP computerized systems [2] ISPE: GAMP Good Practice Guide: IT Infrastructure Control and Compliance. ISPE (2005) [3] Deutsches Bundesministerium für Informationssicherheit (2005): IT-Grundschutzkataloge. Standardwerk zur IT-Sicherheit. Köln: Bundesanzeiger-Verlag. BSI-Schriftenreihe. [4] Food and Drug Administratio (FDA): Guidance for Industry – Q9 – Quality Risk Management. Rockville (June 2006) [5] LATA, Arora; SHAILA Singh, POONAM Sharma: Managing Infrastructure using ITIL. Skill Soft Press (2007) 346 CONTINUOUS COMPLIANCE MONITORING IN ERP SYSTEMS - A METHOD FOR IDENTIFYING SEGREGATION OF DUTIES CONFLICTS Patrick Wolf, Nick Gehrke1 Abstract Segregation of Duties (SOD) can be seen as one major class of control activities within a company's Internal Control framework, contributing to the reliability of financial reporting. In recent years, SOD controls in terms of user access rights have experienced a surge of attention in particular, mostly due to the growing reliance of business processes on ERP systems. This paper presents a method for automatically identifying SOD conflicts in user access rights as one component of a continuous compliance monitoring framework. The paper further demonstrates the application of the proposed method in a real world project. 1. Introduction In recent years, the growing number of corporate scandals (e.g. Barings Bank, Enron, Worldcom, Siemens, Société Générale) has led to tighter regulatory and statutory requirements regarding a company's Internal Control over Financial Reporting (e.g. Sarbanes-Oxley-Act). According to the Committee of Sponsoring Organizations of the Treadway Commission (COSO), Internal Control can be defined as "a process, effected by an entity's board of directors, management and other personnel, designed to provide reasonable assurance regarding the achievement of objectives in the following categories: 1. Effectiveness and efficiency of operations. 2. Reliability of financial reporting. 3. Compliance with applicable laws and regulations" [6]. To ensure the achievement of these objectives, COSO proposes the implementation of a company-wide Internal Control framework consisting of five interrelated components: Control Environment, Risk Assessment, Control Activities, Information and Communication, and Monitoring [6]. The need for implementing a suitable and available Internal Control framework is also underlined by the aforementioned regulatory and statutory requirements [12]. Within a company's Internal Control framework, Segregation of Duties (SOD) can be classified as a major class of control activities. It contributes to the reliability of financial reporting [13] by preventing any single employee from having complete control over all phases (authorization, custody, record keeping and reconciliation) of a business transaction [15, 18], thus, avoiding a conflict of interests and preventing fraud [13, 14]. The term "fraud" is used in accordance with the 1 PricewaterhouseCoopers AG WPG, Hamburg, Germany 347 International Standard on Auditing (ISA) 240 and refers to "an intentional act by one or more individuals among management, those charged with governance, employees, or third parties, involving the use of deception to obtain an unjust or illegal advantage" [14]. If a company's Internal Control is not working effectively due to inadequate SOD, then fraudulent activities, such as misappropriation of assets and fraudulent financial reporting, may not be prevented which, in turn, could result in a material misstatement in the financial statements of the respective company [14]. According to a survey recently published by the accounting and consulting firm PricewaterhouseCoopers (PwC), the average loss from fraud over two years per company in 2007 was US$ 2,420,700 [16]. Considering the relevance of SOD for the effectiveness of a company's Internal Control over Financial Reporting, this paper proposes a method for identifying existing SOD conflicts in the user access rights of different enterprise resource planning (ERP) systems. From our practical experience, there is a strong demand for such a monitoring method, especially due to the growing reliance of business processes on ERP systems [9] and the latest corporate scandals (e.g. the Siemens AG has lately chosen Security Weaver as its global software platform for monitoring SOD conflicts2). While the continuous monitoring of SOD conflicts in ERP systems combined with the continuous monitoring of system transactions and system settings is recently marketed under the term "continuous compliance monitoring" by several consulting firms, such as PwC and KPMG, and software vendors, such as ACL CCM, Approva BizRights and Security Weaver, there seems to be a lack of scientific debate regarding continuous monitoring methods. This paper tries to fill this gap and is based on the Design Science paradigm [11]. The proposed method addresses a relevant business problem (see introduction) and constitutes a viable artefact according to Hevner et al. Research rigor is achieved by applying the established method engineering approach within the construction process. The practicability of the method is then evaluated in a real world project. The research contribution of the paper can be seen in bridging the gap between the practical and theoretical debate regarding continuous compliance monitoring. The remainder of the paper is structured as follows: In chapter 2, the method engineering approach is presented as the theoretical foundation of the method development process. Based on the understanding of the five constituent elements of a method (activities, outcomes, techniques, roles and metamodel), chapter 3 focuses on describing the most important elements of our proposed method for identifying SOD conflicts in system-based user access rights (activities, outcomes and techniques). Thus, the elements metamodel and roles will not be covered within this paper. In chapter 4, the method is evaluated by applying it in a real world project. Finally, a conclusion is given and further research needs are outlined. 2. Method Elements and Method Engineering According to Brinkkemper, the word method comes from the Greek "methodos", meaning way of investigation [4]. In the context of systems development, he defines a method as "an approach […] based on a specific way of thinking, consisting of directions and rules, structured in a systematic way in development activities with corresponding development products" [4]. Further definitions of methods have been given, for example, by [1], [2], [8] or [18]. A synopsis of these and other definitions can be found at [3] who derive four fundamental defining attributes of a method: goal oriented, systematically structured, principles-based, and intersubjectively repeatable. 2 http://www.reuters.com/article/pressRelease/idUS154425+25-Feb-2008+MW20080225 (Call-Up: 22/07/2008) 348 Method Engineering (ME) is an approach which has emerged in the IS field in the nineteen-eighties due to the "fundamental observation […] that no one method is equally suitable to all kinds of problem domains" [19]. Based on this observation, ME can be understood as an engineering discipline which focuses on the systematic design, construction and adoption of methods for various purposes (e.g. information systems development) [7]. Here, a method is not conceived "as a single intertwined and interdependent entity but as a set of disparate fragments" [10]. Gutzwiller has analyzed several ME approaches and derived the following five general elements of a method: "activity", "role", "outcome", "technique", and "metamodel" [8]. Again, an overview of alternative definitions can be found at [3]. According to Gutzwiller, an activity is a functional unit of action which aims at creating one or more defined outcomes (e.g. a functional specification). Activities may consist of sub-activities (forming a hierarchical structure) and can be ordered in a sequence (procedure model). Techniques describe in detail how a certain outcome or a group of logically interrelated outcomes is created. The metamodel is the conceptual data model of the outcomes and visualizes their overall interrelationships. Finally, roles are aggregations of certain activities required to fulfil a certain function within the company and are normally performed by employees or organizational units [8]. Based on the aforementioned understanding, the following chapter focuses on describing the activities, outcomes and techniques of our method for identifying SOD conflicts in ERP-systems as well as the interrelationships of these elements. Neither metamodels nor role aspects will be covered in this paper. The application of the method in a real world project is demonstrated in chapter 4. 3. Activities, Outcomes and Techniques of the Method The activities, outcomes and techniques of the proposed method are illustrated in Fig. 1. Fig. 1: Activities, outcomes and techniques of the SOD conflicts identification method 349 Process Scoping The process scoping activity is the starting point of the presented method and aims at identifying those processes which will later be subject to the SOD analysis. This selection should be based on a thorough assessment of each process in terms of the probability of fraud occurrence and the expected extent of such events. Typical examples of high risk processes in most companies are the purchase-to-pay process (P2P) or the order-to-cash (O2C) process. Assessment techniques, like interviews and questionnaires, should especially take into account the complexity of a certain process, such as degree of automatization and interfaces, past fraud cases, existing opportunities to commit fraud (e.g. ineffective controls), as well as employees' incentives (e.g. existing pressure, personal fraud justification) [17]. Process Analysis The aim of the process analysis activity is to gain a thorough understanding of the selected processes by decomposing each process in its flow of activities and by identifying the organizational entities and information systems (e.g. ERP systems) which are involved in performing these activities. Techniques that should be used for gathering the required information are interviews, questionnaires and observations. Process modelling tools (e.g. IDS Scheer ARIS, BOC ADONIS) might be used in order to facilitate the systematic creation of the process models. SOD Ruleset Specification The main objective of the third activity is to specify the corporate SOD ruleset which constitutes the total set of SOD conflicts considered relevant for the regarded processes. An SOD conflict is defined as a combination of exactly two process activities which hold the risk of fraud if both are performed by the same individual. SOD conflicts are relevant if both the probability of their exploitation and the expected damage resulting from such an exploitation exceed a threshold depending on a company's risk appetite [5]. This threshold ensures the manageability of the ruleset by eliminating all non-relevant conflicts. The conflicts contained in the ruleset should be formulated in a system-independent way which guarantees that the ruleset is overall applicable and not tailored to a specific system environment. This becomes especially important when dealing with more than one company (e.g. an affiliated group) and different system environments (e.g. SAP, Baan). An exemplary extract of a ruleset is given in Tab. 1. Process P2P P2P P2P SOD Conflict Create & Maintain Vendor Records vs. Process Vendor Invoices Risk A user could set up fictitious vendor accounts (or alter existing accounts inappropriately) and create fictitious invoices resulting in unauthorized payments. Process Vendor Invoices vs. A user could process payments for fictitious or Process Outgoing Payments invalid invoices. Create & Maintain Vendor A user could set up fictitious vendor accounts (or Records vs. Process Outgoing alter existing accounts inappropriately) and initiate Payments payments to these fictitious vendors. Tab. 1: Exemplary extract of a SOD ruleset for the P2P process 350 SOD Ruleset Translation The next activity of the proposed method is based on the premise that all or most of the process activities considered in the SOD ruleset (e.g. "Create & Maintain Purchase Order") are actually performed in an ERP system, thus requiring the translation of the system-independent ruleset in the specific transaction codes, function codes, authorization objects, etc. of the respective system. Again, this activity becomes particularly important when dealing with several subsidiaries of an affiliated group which all perform basically the same processes (e.g. P2P) on heterogeneous ERP systems (e.g. SAP, Oracle Financials, Baan). In such a case, the ruleset must be consistently tailored to each ERP system. A practical example is given in paragraph 4.3. Live Data Extraction and Transformation After having translated the SOD ruleset, the fifth activity aims at extracting the current user access rights from the relevant database tables of the productive ERP systems and transforming that data in a standardized format for analysis purposes. In order to automate the extraction, the implementation of customized Standard Query Language (SQL)-scripts which may be triggered periodically is recommended. The first step in creating such a script consists of identifying the relevant database tables which contain the user access rights data. In an ERP system supporting purely role based access rights, the tables illustrated in Tab. 2 should be considered at minimum. Table User Master Data Transaction Master Data Role Master Data Mapping Users To Roles Description Contains all users of the system Contains all possible business transactions supported by the system Contains all roles defined in the system Contains all relationships of users and roles. A role can be assigned to multiple users and a user can have multiple roles (m:n). Mapping Roles to Contains all relationships of roles and business transactions. A role can Transactions contain multiple business transactions and a transaction can be assigned to multiple roles (m:n). Tab. 2: Relevant user access rights tables in a role based access rights system The automated transformation of the contents of the identified tables in a standardized format by using appropriate SQL queries can then be seen as the second step. However, in the case of ERP systems whose authorization mechanisms are not purely role based, additional data transformations must be developed. Typical issues which might be encountered are: (1) access rights are directly assigned to users without using roles or in addition to existing roles; or (2) roles do not only contain business transactions (positive list), but also entries with explicit negations of transactions (negative list). In such cases, constellations must be considered where one role grants one user access to a specific transaction and another role negates this access at the same time. SOD Analysis Within this activity, the standardized data extracts from the previous step are taken and analyzed in order to determine existing SOD conflicts in the user access rights assigned for the productive ERP systems. For each user and each conflict of the translated SOD ruleset, it must be checked if the respective user disposes of sufficient access rights to perform both activities of the analyzed conflict. In such a case, the result report of the SOD analysis should show the existing conflict together with additional information (e.g. user ID, conflicting access rights) to allow the remediation of the conflicting access rights. An example of a report is given in paragraph 4.4. 351 4. Application of the Method in a Real World Project This chapter aims at demonstrating the application of the proposed method in a real world project. Firstly, a short overview is given describing the objectives and the general requirements of the project. Subsequently, the aforementioned activities, techniques and outcomes are described in the context of the project. Due to the sensitivity of the subject, all data have been made anonymous. Project Overview In the forefront of our project, the client had started to implement a continuous SOD compliance process based on the analysis tool Security Weaver (SW). Although SW is primarily focussed on SAP installations, the scope of the software was extended within the project to cover other NONSAP systems (e.g. Exact Globe, Baan, Oracle Financials) as well. At the end, more than 60 worldwide located installations of NON-SAP systems were integrated in the automated SOD compliance process. The activities performed in order to analyze the user access rights within those systems are illustrated in Fig. 2 and described below: (1) the current user access rights are extracted from each productive NON-SAP system on a regular basis; (2) the extracted data is transformed in a common standardized format; (3) the standardized data is transferred to the central SW instance (e.g. via FTP), uploaded and analyzed; (4)/(5) the results are made accessible via web interface allowing the system owners to download the reports for the purpose of remediation. 4 5 2 1 Data Extraction Decentral Decentral Decentral Non SAP Non SAP Non SAP System Systems Systems 3 File Transfer CSV-Files User Rights Central Security Weaver User WebInterface for decentralized Companies Report Download SoD Report SoD Report SoD Report Company xxx Fig. 2: Activities within an exemplary continuous SOD compliance process In the context of the overall SOD project, the main objective of our sub-project was to initially analyse the user access rights established in the productive NON-SAP systems of several selected subsidiaries with regard to existing SOD conflicts. The scope of the analysis was further limited to cover only P2P-related conflicts as well as some conflicts relating to the finance and the system administration process. SOD Ruleset Specification The SOD ruleset for the P2P process had already been defined by our client and, thus, marked the initial point of our sub-project. To obtain the ruleset, the client first identified all relevant activities performed within his P2P processes and then created an SOD matrix based on these activities to derive the potential conflicts. Tab. 3 shows an excerpt of the SOD matrix for the P2P process. The crosses indicate existing conflicts between the activities. 352 CMVR PVI POP MBA PIP X X CMVR X X PVI X X X POP X X MBA X PIP 3 Tab. 3: Exemplary SOD matrix for the P2P process SOD Ruleset Translation The system-specific translation of the P2P ruleset is demonstrated on the example of the NON-SAP system Exact Globe. Within Globe, the table "pwfunc" contains all transactions supported by the system. Tab. 4 shows an extract of this table. transactionID 650888 650892 650896 650925 652065 652066 exename Transactiontitle EBUDGETALLOCATION Budgets BALANCELIST Receivables history BALANCELIST Payables history ENTRYREPORT To be processed EFENTRY Invoices EFENTRY To create credit notes Tab. 4: Extract of transactions supported by Exact Globe To translate a specific conflict of the SOD ruleset, it is necessary to identify all transactionIDs contained in the table "pwfunc" which logically belong to one of the two activities that make up a conflict and assign those transactionIDs to the respective activity. It is immediately obvious that this activity requires a profound knowledge of the regarded ERP system and the transactions it supports. Tab. 5 illustrates the process activity "Process Vendor Invoices" tailored to Exact Globe. Process activity TransactionID GroupID Transaction Title Process Vendor Invoices G0000000018 08 Exchange rates Process Vendor Invoices G0000000054 NO Transactions Process Vendor Invoices G0000000062 NO Financial entries Process Vendor Invoices G0000000060 04 Enter Process Vendor Invoices G0000000068 NO Make recurring purchase entries Process Vendor Invoices G0000000063 NO Make recurring general journal entries Process Vendor Invoices G0000000121 07 Invoices & Bank/Cash Process Vendor Invoices G0000000102 08 Invoices & Bank/Cash Process Vendor Invoices G0000000119 04 Process Process Vendor Invoices G65047 NO Purchase Process Vendor Invoices G65076 NO General journal Process Vendor Invoices G65303 07 Exchange rates Tab. 5: Exemplary translation of the activity "Process Vendor Invoices" It should be noted that a user needs only one of the transactionIDs marked with a "NO" in the GroupID column of the table above to perform the activity "Process Vendor Invoices" within Exact Globe ("or"-conjunction). On the other hand, values other than "NO" in the GroupID column point out that a user must possess all transactionIDs belonging to the same group in order to be able to 3 Legend of abbreviations: Create & Maintain Vendor Records (CMVR), Process Vendor Invoices (PVI), Process Outgoing Payments (POP), Maintain Bank Accounts (MBA), Process Incoming Payments (PIP) 353 perform the activity "Process Vendor Invoices". In the case of group "04", only entering AND processing invoices is deemed critical. Users with access to only one of these transactions cannot perform the activity "Process Vendor Invoices" on their own. Live Data Extraction and SOD Analysis For obtaining the user access rights data from the productive NON-SAP systems, customized SQL scripts were created and implemented. The data transfer was performed using standardized csvfiles. The access rights data contained in the files was then uploaded into the central SW instance. Subsequently, the analysis of the user access rights data in terms of existing SOD conflicts was performed automatically in SW by applying the appropriate system-specific SOD ruleset to the uploaded data. A simplified exemplary result report showing one identified SOD conflict ("Maintain Vendor Records vs. Process Vendor Invoices") for the user "4711" is depicted in Tab. 6. The report also indicates the transactionIDs causing the conflict, the roles of the user containing the conflicting transactionIDs and the respective process activities to which the transactionIDs have been mapped. Based on the report, the existing conflict could be solved, for example, by revoking the user's access to transactionID 650476. Company User 100 4711 100 4711 100 4711 Conflict Process Activity Role Maintain Vendor Records vs. Process Vendor Invoices Maintain Vendor Records vs. Process Vendor Invoices Maintain Vendor Records vs. Process Vendor Invoices Maintain Vendor Master Records Maintain Vendor Master Records Process Vendor Invoices Sales invoices23456 00_PURCHASE AGENT 00_PURCHASE AGENT Transaction-ID 650124 650120 650476 Tab. 6: Simplified report of identified SOD conflicts At higher organizational levels, more aggregated reports are commonly demanded (e.g. existing SOD conflicts over all entities). Fig. 3 shows a scatter plot which we used within our project for reporting the initial status of SOD conflicts in several selected entities (C001 to C007) and the status after a first remediation (visualized via arrows) to the client's management. Fig. 3: SOD report graph showing the number of conflicts per entity (C001 to C007) 354 While the scatter plot in Fig. 3 shows only the total number of SOD conflicts for each entity, the graph in Fig. 4 gives more detailed information on the frequency of each single conflict. On the xaxis of the graph, the analyzed conflict IDs are shown (e.g. AP01 to AP15), whereas the y-axis indicates the percentage of ERP system users within the regarded entities (C001 to C007) having the respective conflict. A broken line occurs if a conflict is not applicable to the considered system. Fig. 4: SOD report graph showing the frequency of each conflict per entity 5. Conclusion This paper proposed a method for identifying existing SOD conflicts in the user access rights of different ERP systems. The method consists of six interrelated activities whose practicability was evaluated in a real world project. From this evaluation, some "lessons learned" can be derived: 1. The creation of a complete, accurate and consistent SOD ruleset without redundancies is highly important as it constitutes the basis for all subsequent activities. Thus, an independent quality assurance assessment of the ruleset should be performed prior to any implementation activities. 2. The system-specific translation of the ruleset demands highly experienced system users to ensure the accuracy and completeness of the mapping. Again, an independent quality assurance assessment has proved to be important. 3. In the case of ERP systems whose authorization mechanisms are not purely role-based, additional support tools for transforming the data into the required format had to be developed. These additional efforts should be considered when planning similar projects. 4. The redesign of user access rights in order to ensure compliance with the SOD principle may result in a substantial change of organizational work routines, e.g. if employees are not allowed to perform certain activities in the ERP systems anymore due to existing SOD violations. These required changes should be taken into account when starting an SOD project. The presented method constitutes a first step towards a comprehensive continuous compliance monitoring framework that addresses the particularities of complex ERP systems. Further research should focus on developing sound methods that can be used to automatically monitor system transactions and system settings. Due to the fact that issues with segregation of duties usually stem from a complex interaction of technical and non-technical activities that are usually not properly reflected in the master data of an ERP system alone, further research should also concentrate on the complex interplay of these types of activities and the media breaks that typically occur between them. 355 6. References [1] BALZERT, H.: Lehrbuch der Software-Technik, Spektrum Akademischer Verlag GmbH: Heidelberg/Berlin 1998. [2] BECKER, J. / KNACKSTEDT, R. / HOLTEN, R. / HANSMANN, H. / NEUMANN, S.: Konstruktion von Methodiken, in: Becker, J. / Grob, H. L. / Klein, St. / Kuchen, H. / Müller-Funk, U. / Vossen, G. (Eds.), Arbeitsbericht des Instituts für Wirtschaftsinformatik, No. 77, Universität Münster: Münster 2001. [3] BRAUN, C. / WORMANN, F. / HAFNER, M. / WINTER, R.: Method Construction A Core Approach to Organizational Engineering, in: Haddad, H. M. / Liebrock, L. M. / Omicini, A. / Wainwright, R. L. (Eds.), The 20th ACM Symposium on Applied Computing (SAC2005): Santa Fe, New Mexico USA, 2005, pp. 1295-1299. [4] BRINKKEMPER, S.: Method engineering: engineering of information systems development methods and tools, in: Information and Software Technology, No. 38, 1996, p. 275-280. [5] COMMITTEE OF THE SPONSORING ORGANIZATIONS OF THE TREADWAY COMMISSION: Enterprise Risk Management - Integrated Framework - Executive Summary, 2004. [6] COMMITTEE OF THE SPONSORING ORGANIZATIONS OF THE TREADWAY COMMISSION: Internal Control - Integrated Framework, o.J., Internet: http://www.coso.org/IC-IntegratedFramework-summary.htm (Call-Up: 22/07/2008) [7] GOEKEN, M.: Entwicklung von Data Warehouse Systemen: Anforderungsmanagement, Modellierung, Implementierung, Vieweg + Teubner: Wiesbaden 2006. [8] GUTZWILLER, T.: Das CC RIM-Referenzmodell für den Entwurf von betrieblichen, transaktionsorientierten Informationssystemen, Hochschule St. Gallen für Wirtschafts-, Rechts- und Sozialwissenschaften, Dissertation 1994. [9] HENDRAWIRAWAN, D. / TANRIVERDI, H. / ZETTERLUND, C. / HAKAM, H. / KIM, H. H. / PAIK, H.: ERP Security and Segregation of Duties Audit: A Framework for Building an Automated Solution, in: Information Systems Control Journal, Vol. 2, 2007, pp. 1-4. [10] HENDERSON-SELLERS, B. / GONZALEZ-PEREZ, C. / SEROUR, M.K. / FIRESMITH, D. G.: Method engineering and COTS evaluation, in: ACM SIGSOFT Software Engineering Notes, Vol. 30, No. 4, 2005. [11] HEVNER, A. R. / MARCH, S. T. / PARK, J. / RAM, S.: Design Science in Information Systems Research, in: MIS Quarterly, Vol. 28, No 1, 2004, pp. 75-105. [12] HÜLSBERG, F. / FELLER, S. / PARSOW, C.: Anti-Fraud-Management - Reduzierung von Haftungsrisiken und Vermögensschädigungen, in: ZRFG, Vol. 5, 2007, pp. 204-208. [13] INSTITUT DER WIRTSCHAFTSPRÜFER IN DEUTSCHLAND E.V.: IDW-Prüfungsstandard: Das interne Kontrollsystem im Rahmen der Abschlussprüfung (IDW PS 260), in: WPg, 2001, pp. 821ff. [14] INTERNATIONAL FEDERATION OF ACCOUNTANTS: International Standard on Auditing 240 (Revised) The Auditor's Responsibility to Consider Fraud in an Audit of Financial Statements, 2004. [15] LUECK, W.: Elemente eines Risiko-Managementsystems, in: Der Betrieb, Vol. 01/02, 1998, pp. 8-14. [16] PRICEWATERHOUSECOOPERS: Economic crime: people, culture and controls - The 4th biennal Global Economic Crime Survey, 2007. [17] RAMOS, M.: Auditors' Responsibility for Fraud Detection, in: Journal of Accountancy, Vol. 195, No. 1, 2003, pp. 28-36. [18] SCHEER, A.-W.: EDV-orientierte Betriebswirtschaftslehre: Grundlagen für ein effizientes Informationsmanagement, Springer, Berlin 1990. [19] TER HOFSTEDE, A.H.M. / VERHOEF, T.F.: On the feasibility of situational method engineering, in: Information Systems, Vol. 22, No. 6, 1997, pp. 401-422. 356 A RISK BASED APPROACH FOR SELECTING SERVICES IN BUSINESS PROCESS EXECUTION Stefan Sackmann, Lutz Lowis, Kai Kittel1 Abstract The vision of automated business processes within a service-oriented paradigm includes the flexible orchestration of IT services. Whenever alternative services are available for activities in an ITsupported business process, an automated decision is worth aspiring to. According to valueoriented management, this decision should be motivated economically and also requires taking account of risk. This paper presents a novel approach for assessing the risk of IT services, based on vulnerability information as can be obtained in the form of publicly available Common Vulnerability Scoring System (CVSS) data. 1. Automating IT service selection Market forces are raising companies’ ability to respond quickly and flexibly to changing demands, which is seen as one of the main competitive advantages of the future [1, 23]. To keep pace, directing business models towards automation is still regarded as an important strategic topic [25] and aligning the technological infrastructure to service oriented architecture (SOA) seems a feasible and promising way [10, 16]. Apparently, present SOA and standards such as BPEL or BPMN are still in need of improvement to satisfy business demands [29] and the present hype around service orientation is endangered by setbacks [13]. Nevertheless, prominent suppliers of hard- and software are already embodying service orientation into their products: IBM offers Websphere [19], SAP integrates Netweaver [6], and Microsoft uses services in Windows Vista [4]. Besides the technical feasibility of SOA, exploiting the full potential of services requires solutions to several business demands. In this contribution, the focus is laid on one of these issues: the automated selection between alternative IT services available for supporting the execution of business process activities. Since the ability of an IT service to meet business process-specific protection goals is crucial, a method for assessing the risk of an IT service within the context of the supported business process is developed. The method consists of two major parts: The first part proposes a new way to measure the probability of achieving protection goals within an IT service by assessing vulnerabilities. The second part extends business process models by an economic decision algorithm that also takes risk into consideration and enables an automated decision between alternative IT services in the concrete execution context. Addressing these two parts, the remainder of this contribution is structured as follows: in section 2, a layer-based model is introduced bringing University of Freiburg, Institute of Computer Science & Social Studies, Department of Telematics, Friedrichstrasse 50, 79098 Freiburg, Germany 1 357 the economic and technical view of IT risk together and serving as starting point for structuring IT services. Based upon this model, in section 3, a measure for the ability of an IT service to achieve protection goals from IT security research is presented and discussed. In section 4, this measure is integrated into an economic decision algorithm for business process activities taking the riskiness of alternative IT services into consideration. Subsequently, it is demonstrated how the algorithm works by means of an exemplified purchase process. The contribution concludes by discussing limitations of the method and by proposing possible solutions. 2. IT Risk Reference Model - Bridging the technical and economic view The challenges to a value-oriented risk management process and continuous risk assessment, resulting from a constantly changing IT support of business processes as in SOA, have been discussed in [20, 21]. Following the notion of service orientation, automating business processes means that services are not exclusively used for one specific business process but manifold. Furthermore, the orchestration of the IT services changes dynamically according to the business context and is not statically wired in advance at the time when the business process is designed. Since the economic risk depends on the business process supported, the riskiness of an IT service should be specified independently of its actual integration. Therefore, typical measures for assessing IT security that already include economic exposure, e.g. an annual loss expectancy (ALE) [3] or business adjusted risk (BAR) [12], are unsuitable. It seems more advisable to look for measures that characterize the riskiness of IT services in a form that can be integrated into the service description and thus, e.g., become part of a service or protection level agreement (SLA/PLA) [14]. The approach in hand has been developed with a focus on services provided within a trusted domain, i.e. a company’s internal services or external services of business partners under contractual relationship. Economic handling of IT risks Technological handling of IT risks Business Process IT Services / IT Infrastructure Vulnerabilities Threats Violations of protection goals disturb the business process and have (usually negative) effects on company results Attacks exploit vulnerabilities and violate protection goals Figure 1: IT Risk Reference Model [20] For measuring the riskiness of IT services, the measures used should rely on a systematic modeling of relations between causes and effects of IT risks. For this purpose, the IT Risk Reference Model has been developed [20] that is structured following a hierarchical abstraction layer model as used in computer science for reducing complexity, e.g. in network communication [28]. On the basis of four different layers (Figure 1), the economic, process-oriented view is brought together with the technical, threat-oriented view of IT risk. Beginning with the economic view, the top layer represents the “effects” and contains all activities of the business process that are regarded as assets from a risk perspective. The next layer contains all IT services and their underlying IT infrastructure representing IT resources for the superordinated process activities. Vulnerabilities constitute the “bridge” between the economic and the technical layers since they are possible points of attack for threats violating protection goals of the IT applications [24]. Thus, since a large part of attacks re358 sult from exploitation of known vulnerabilities (see e.g. [22]), the following layer represents the vulnerabilities of these applications, while the set of all known threats is part of the bottom layer representing the causes. Although the IT Risk Reference Model has been developed with a different focus on measuring changes between causes and effects of IT risk, the achievable link provides a suitable starting point for the aspired measure. Since vulnerabilities can only be identified in relation to protection goals [17], measuring the probabilities of an IT service to achieve protection goals that are relevant to superordinated business processes is seen as a promising approach. In IT security research, there are several protection goals discussed [5, 17, 30]. For the beginning, focusing on the three main protection goals, confidentiality, integrity, and availability (CIA), is proposed for mainly three reasons: firstly, since the riskiness of an IT service is highly dependent on the IT security achieved, these protection goals are relevant for business processes [18]. Secondly, there is a well established methodical understanding of these protection goals in IT security research [2]. Thirdly, focusing on high-level protection goals does not limit the applicability of the method: more context-specific protection goals can be considered. According to this view, an IT service is considered to be secure (no risk) if it has no known vulnerabilities affecting the IT service’s confidentiality, integrity, or availability of data or processes. Business Process C* = expected loss in case of violation of confidentiality I* = expected loss in case of violation of integrity A* = expected loss in case of violation of availability C*, I*, A* Decision: IT Service with minimal expected loss C 1 , I 1 , A1 C2 , I2 , A2 IT Service1 IT Service2 Cn , In , An … IT Servicen Ck = probability of service k‘s confidentiality Ik = probability of service k‘s integrity Ak = probability of service k‘s availability Figure 2: Protection goals – Linking business processes and IT service A decision-theory based selection requires two measures (Figure 2). Firstly, the damage resulting from non-achievement different protection goals has to be quantified according to the context of the business process. This could be realized either by relative evaluation (see, e.g., the POSeM model of [18]) or monetary assessment, e.g. in the form of expected loss and will be discussed in more detail in section 4. Secondly, it is necessary to determine the probability of an IT service violating the protection goals. For assessing these probabilities automatically, a new method is proposed in the following section. 3. Measuring IT Service Riskiness Following the IT Risk Reference Model, vulnerabilities are the key factor since they allow attackers to harm protection goals. It is assumed that not all known vulnerabilities can instantly be closed for economical and technical reasons (e.g., limited time and money, patches not available). Otherwise, a risk-based approach would be pointless. Prominent methods for identifying vulnerabilities are penetration tests [2] or source code analysis [7]. Furthermore, for the technical infrastructure on which the IT services run, vulnerabilities can be queried from publicly accessible vulnerability databases. This allows an initial estimation of a company’s security level by looking at the sheer 359 number of known vulnerabilities, as well as gauging the effects a given vulnerability’s exploitation would have on the individual IT security protection goals. 3.1. Vulnerability Information Sources The approach presented works with any vulnerability database that offers information on the CIA impact caused through exploiting a given vulnerability. In this contribution, the well known Common Vulnerabilities and Exposures (CVE) [8] database is used offering data according to the Common Vulnerability Scoring System (CVSS) as shown in Table 1. The Base Score Metrics not only indicate the impact of exploiting a vulnerability, but also where it can be exploited from, how complex the exploit is, and how often the attacker must authenticate to the target. The Temporal Score Metrics offer detailed information on the availability of an exploit, existing countermeasures, and the credibility of the vulnerability details. Table 1: CVE scheme and CVSS values [9] Unique CVE name: CVE-abcd-wxyz Affected Product/Service: [name and version] Original release date: mm/dd/yyyy; Last revised: mm/dd/yyyy; Source: [e.g.] US-CERT/NIST Overview [textual description] References to Advisories, Solutions, and Tools. [list of links to other databases, e.g., SecurityFocus] Vulnerable software and versions: Configuration [list of operating systems and patch levels] Technical Details Vulnerability Type: [e.g.] Input Validation (CWE-20); [links to CVE Standard Vulnerability Entries and Common Platform Enumeration] CVSS Base Score: 0 (Low) to 10 (High) (Impact Subscore 0 to 10, Exploitability Subscore 0 to 10) CVSS Temporal Score: 0 (Low) to 10 (High) CVSS v2 Vector: (AV:N/AC:L/Au:N/C:C/I:C/A:C) Published: mm/dd/yyyy CVSS metric group CVSS metric CVSS values Base Score Metrics Exploitability Metrics Access Vector local (0.395), adjacent network (0.646), network (1) Access Complexity low (0.71), medium (0.61), high (0.35) Authentication none (0.704), single (0.56), multiple (0.45) Impact Metrics Confidentiality Impact Temporal Score Metrics none (0), partial (0.275), complete (0.66) Integrity Impact none (0), partial (0.275), complete (0.66) Availability Impact none (0), partial (0.275), complete (0.66) Exploitability unproven (0.85), proof-of-concept (0.9), functional (0.95), high (1), not defined (1) Remediation Level official fix (0.87), temporary fix (0.9), workaround (0.95), unavailable (1), not defined (1) Report Confidence unconfirmed (0.9), uncorroborated (0.95), confirmed (1), not defined (1) At present, the vast majority of CVE entries relates to software applications other than web services. In future, once a critical amount of web services is in operational use, web service vulnerabilities can be expected to be listed in CVE or a similar database. Therefore, for assessing IT services, exemplary values of actual CVE entries for software applications are used in this contribution. 360 3.2. CVSS and Attack Probabilities In practice, attack probabilities often rely on subjective expert estimates given by, e.g., system administrators with a varying degree of experience, which is seen as a major drawback in the IT security field [27]. Since web services might come and go too quickly to allow expert estimates or even collecting historical data on the attack probabilities, assessing vulnerabilities might provide valuable information and extracting probabilities from CVSS data is seen as promising method: CVSS metrics reflect a strong link between threats, vulnerabilities, and the violation of protection goals. Also, a correlation between the effort in exploiting vulnerabilities and the probability of successful attacks can be assumed. Although CVSS metrics give, strictly spoken, no information about the actual probability of an attack, taking this link into consideration for a risk assessment can be expected to lead to more accurate results than existing methods for estimating attack probabilities. This issue is not yet fully analyzed and subject to further evaluation and research. However, once a suitable method for measuring attack probabilities for IT services should become evident, this could be incorporated into the proposed approach without any methodical change. 3.3. Measures for Protection Goals In its simplest form, CVSS calculates a score between 0 and 10 for any vulnerability in the database, representing the lowest threat level, 10 the highest. Following the CVSS calculation, the base score is calculated according to the following equation [9]: BaseScore = round _ to _ 1 _ decimal ((0.6 ⋅ Impact + 0.4 ⋅ Exploitability − 1.5) ⋅ f (Impact )) (1) The components Impact, Exploitability, and f (Impact) are calculated according to the following equations, whereby the absolute numbers are given by the CVSS method: Impact = 10.41 ⋅ (1 − (1 − ConfidentialityImpact ) ⋅ (1 − IntegrityImpact ) ⋅ (1 − AvailabilityImpact )) (2) Exploitability = 20 ⋅ AccessVector ⋅ AccessComplexity ⋅ Authentication (3) if Impact = 0 ⎧0 f (Impact ) = ⎨ ⎩1.176 otherwise (4) According to the temporal situation, the BaseScore can be combined with the temporal exploitability values to include information on automated exploits and fixes according to equation (5) and (6): TempBase = Exploitability ⋅ RemediationLevel ⋅ ReportConfidence (5) TemporalScore = round _ to _ 1 _ decimal (BaseScore ⋅ TempBase ) (6) However, neither the BaseScore nor the TemporalScore show which protection goal(s) the vulnerability under consideration puts at risk. Therefore, an adaptation of the calculation is proposed here for calculating the scores for each protection goal separately. This requires an adaptation of the CVSS values of the impact metrics by replacing equation (2). In order to keep the range of values between 0 and 10, the weights are adapted as follows without changing the basic method of CVSS: Table 2: Adjusted CIA impact values Metric Confidentiality Impact Integrity Impact Availability Impact Values none (0), partial (1.7), complete (10) none (0), partial (1.7), complete (10) none (0), partial (1.7), complete (10) 361 Accordingly, equation (4) is split up and adapted for each of the three protection goals: if ConfidentialityImpact = 0 ⎧0 f (CImpact ) = ⎨ ⎩1.176 otherwise (4a) if IntegrityImpact = 0 ⎧0 f (IImpact ) = ⎨ ⎩1.176 otherwise (4b) if AvailabilityImpact = 0 ⎧0 f ( AImpact ) = ⎨ ⎩1.176 otherwise (4c) Based on these adjustments, the probability that an exploit of the vulnerability under consideration will harm one of the protection goals can be calculated as follows: C = (0.6 ⋅ CImpact + 0.4 ⋅ Exploitability − 1.5) ⋅ f (CImpact ) ⋅ Temp ⋅ 0.1 with 0 ≤ C ≤ 1 (6a) I = (0.6 ⋅ IImpact + 0.4 ⋅ Exploitability − 1.5) ⋅ f (IImpact ) ⋅ Temp ⋅ 0.1 with 0 ≤ I ≤ 1 (6b) A = (0.6 ⋅ AImpact + 0.4 ⋅ Exploitability − 1.5) ⋅ f ( AImpact ) ⋅ Temp ⋅ 0.1 with 0 ≤ A ≤ 1 (6c) As single services can have several vulnerabilities, multiple CVSS scores must sometimes be combined. Following the approach of [24], the arithmetic average is used as total score. In the case where further information on dependencies between several vulnerabilities is available, e.g. that they can only be exploited in a specific order, this calculation of course can be replaced by more detailed approaches as, e.g., discussed in [26]. 3.4. Calculation Example With the adapted CVSS score at hand, every IT service can be assessed regarding its probability of achieving each of the protection goals. This is demonstrated for an exemplary service with three vulnerabilities (see Table 3) which will later be referred to when demonstrating the outstanding economic decision. Table 3: Sample vulnerability details IT Service1 CVSS metrics Access Vector Access Complexity Authentication Confidentiality Impact Integrity Impact Availability Impact Exploitability Remediation Level Report Confidence Values Vulnerability 1.1 local (0.395) high (0.35) none (0.704) partial (1.7), none (0) none (0) unproven (0.85) official fix (0.87) unconfirmed (0.9) Vulnerability 1.2 local (0.395) high (0.35) single (0.56) none (0) partial (1.7) none (0) unproven (0.85) unavailable (1) uncorroborated (0.95) Vulnerability 1.3 local (0.395) high (0.35) multiple (0.45) none (0) none (0) partial (1.7) high (1) unavailable (1) uncorroborated (0.95) The CIA-probabilities of exploitability for IT Service1 as well as the temporal scores can then be calculated according to equations (3) and (5). Inserting the results into equation (6a), (6b), or (6c), and calculating the corresponding impact with equation (4a), (4b), or (4c), the complete equation 362 for the three protection goals can be resolved. Using the exemplary values from vulnerabilities 1.1, 1.2, and 1.3 (see Table 3) leads to the following results. C = (0.6 ⋅ 1.7 + 0.4 ⋅ ( 20 ⋅ 0.395 ⋅ 0.35 ⋅ 0.704) − 1.5) ⋅ 1.176 ⋅ (0.85 ⋅ 0.87 ⋅ 0.9) ⋅ 0.1 = 0.023 I = (0.6 ⋅ 1.7 + 0.4 ⋅ ( 20 ⋅ 0.395 ⋅ 0.35 ⋅ 0.56) − 1.5) ⋅ 1.176 ⋅ (0.85 ⋅ 1 ⋅ 0.95) ⋅ 0.1 = 0.013 A = (0.6 ⋅ 1.7 + 0.4 ⋅ ( 20 ⋅ 0.395 ⋅ 0.35 ⋅ 0.45) − 1.5) ⋅ 1.176 ⋅ (1 ⋅ 1 ⋅ 0.95) ⋅ 0.1 = 0.002 In the same way, the CIA-probabilities for the other IT services can be calculated according to their vulnerabilities. Omitting the detailed values for brevity, the following vulnerabilities and probabilities are assumed. Table 4: Exemplary services and their vulnerabilities Vuln. # C I A 1.1 0.023 IT Service1 1.2 1.3 2.1 0.029 IT Service2 2.2 2.3 0.013 0.011 0.002 3.1 0.002 3.2 IT Service3 3.3 3.4 0.011 0.001 0.014 3.5 3.6 0.015 0.035 0.012 Given that vulnerabilities 1.1 to 1.3 can be found in IT Service1, IT Service2 has vulnerabilities 2.1 to 2.3, and vulnerabilities 3.1 to 3.6 are related to IT Service3, the resulting probabilities are shown in Figure 3. To combine the values of several vulnerabilities within one service, the arithmetic average is used as mentioned above. In addition, since low CVSS values stand for a low threat level, the values have to be inverted for getting the aspired probabilities: for example, vulnerability 2.1 in service 2 has a low threat level of 0.029 with regard to confidentiality, i.e. a high probability of 0.971 of achieving that protection goal. C1 = 0.977 I1 = 0.987 A1 = 0.998 C2 = 0.971 I2 = 0.989 A2 = 0.986 C3 = 0.9935 I3 = 0.992 A3 = 0.9765 IT Service1 IT Service2 IT Service3 Figure 3: Exemplary services with CIA probabilities 4. Automated Selection of IT Services The characterization of the IT services according to their capability to achieve the protection goals is only part of the information that is needed for an automated selection between alternative IT services at runtime. The missing part for an economic and value-oriented selection is an assessment of the expected loss for each protection goal in the case of its violation. These values mainly depend on the actual business process that is executed and typically varies from instance to instance. Therefore, the expected losses have to be determined context-specific for each instance. For example, one activity of a purchasing process might require sending a document to the supplier. A box of screws could be ordered with lower confidentiality than a special component that might inform competitors about a new product and thus imply a competitive disadvantage. Bringing together the CIA measures of the IT service with the CIA requirements of the business process facilitates a risk-based selection of the most suitable IT service at runtime. Thus, an orchestration of the IT services ex ante, i.e., when designing the business process, becomes obsolete and, assuming an appropriate extension of the business process model, can be delegated to the business process execution engine. 363 However, the required assessment of the expected loss in the case of a protection goal violation is a complex task and can hardly be realized by assessing each single activity of a business process that is supported by an IT service. Therefore, a hierarchical model is proposed where elements inherit their values from superordinated elements, e.g. a core processes from its superordinated business process. Such hierarchical models are very well known in business process management, e.g. within the framework of British Telecom [11] or the breakdown of business processes through to core processes and detailed processes [15]. If such a uniform “inheritance” is too broad, the values can be adapted on every level and for every instance of the modeled business process as needed. Equipping each IT service with CIA measures as described in section 3 and each IT supported activity of a business process with corresponding monetary values allows an automated decision between alternative IT services, taking not only costs but also risk into consideration. Then, the expected costs E of an IT service k can be calculated as sum of the direct costs (e.g. for using the service) and indirect costs (e.g. cost of changing between services) Costk and the expected loss in the event of a confidentiality breach LoC, loss of integrity LoI, and non-availability LoA: E k = Cost k + (1 − C k ) ⋅ LoC + (1 − I k ) ⋅ LoI + (1 − Ak ) ⋅ LoA (7) The expected costs have to be calculated for every IT service that comes into question to support the considered activity of the business process. According to a value-oriented and a risk-neutral decision strategy, the service which results in the lowest expected costs is to be chosen. For demonstration purposes, the example above is revived: a business process activity requires sending a document and there are three functionally identical IT services (e.g. e-mail, Internet form via https, and EDI) available with their CIA measures as described in section 3.4. The direct costs for sending the document amount to 0.01 € for IT Service1, 0.02 € for IT Service2, and 1.10 € for IT Service3. Indirect costs are ignored for keeping the example simple. In the first scenario, when ordering a box of screws, a violation of confidentiality would result in no loss, a violation of integrity would cost 25.00 € due to sending back the wrong box, and non-availability of the service would cost 1.70 €. Calculating the expected costs for each service shows that IT Service2 is the one to be chosen: E1 = 0.01€ + (1 − 0.977) ⋅ 0.00€ + (1 − 0.987) ⋅ 25.00€ + (1 − 0.998) ⋅ 1.70€ = 0.34€ E 2 = 0.02€ + (1 − 0.971) ⋅ 0.00€ + (1 − 0.989) ⋅ 25.00€ + (1 − 0.986) ⋅ 1.70€ = 0.32€ (8) E 3 = 1.10€ + (1 − 0.9935) ⋅ 0.00€ + (1 − 0.992) ⋅ 25.00€ + (1 − 0.9765) ⋅ 1.70€ = 1.34€ In the second scenario, when ordering a special component, where the pure fact of ordering could inform competitors about a new product, a violation of confidentiality would result in a high loss and cost 30,000.00 €, a violation of integrity would also cost 25.00 €, and again, non-availability 1.70 €. In this scenario, the calculation of the expected costs for each service would change to: E1 = 0.01€ + (1 − 0.977) ⋅ 30,000.00€ + (1 − 0.987) ⋅ 25.00€ + (1 − 0.998) ⋅ 1.70€ = 690.34€ E 2 = 0.02€ + (1 − 0.971) ⋅ 30,000.00€ + (1 − 0.989) ⋅ 25.00€ + (1 − 0.986) ⋅ 1.70€ = 870.32€ (9) E 3 = 1.10€ + (1 − 0.9935) ⋅ 30,000.00€ + (1 − 0.992) ⋅ 25.00€ + (1 − 0.9765) ⋅ 1.70€ = 196.34€ Thus, it would be advisable to send the order via IT Service3. Taking only the costs into consideration or fixing an IT service statically to an activity at the moment of business process design would inherently result in a non-optimal selection. 5. Discussion and Outlook In future SOA, where several alternative IT services are available for realizing activities of business processes, a method is required to select the most suitable one. Statically fixing a specific service to a specific business process activity at design time, or even selecting the IT service dynamically by 364 only taking costs into consideration, results in a non-optimal selection from a value-oriented view. Therefore, in this contribution, a method for taking riskiness of IT services into consideration has been developed and presented. Protection goals from IT security research, namely confidentiality, integrity and availability are proposed as “risk interface” between the IT service and the business process. A value-oriented selection of IT services requires two extensions: business process models have to be extended with economic values for not achieving protection goals and IT service descriptions have to be extended with measures for achieving these protection goals. For extending IT service descriptions, CIA measures have been introduced relying on CVSS data. One significant advantage of this approach is that the determination of CIA measures follows a methodic approach and can be automated. It allows the actual relevance of known vulnerabilities to be considered, e.g. if there is a known automated exploit of a vulnerability, this will be reflected in the respective CVSS values and, thus, immediately change the CIA measures of every corresponding IT service. However, there are also several limitations in our approach. One clear subject of further discussion is our interpretation of the CIA measures as probabilities. While a connection between CIA measures and probabilities of violations seem plausible, it remains subject to further research whether this assumption holds or not and how a company’s specific situation can be taken into consideration, e.g., through adjusted CVSS data. However, should a more precise method for calculating actual probabilities of meeting protection goals become available, it would be easy to extend our approach without having to change the whole risk-based selection of IT services. As mentioned above, additional protection goals such as authentication or accountability can easily be included whenever the required information about corresponding vulnerabilities is available. A further point of discussion is the application of the CIA measures for IT services provided by external suppliers. For IT services integrated from outside the company’s domain, it usually will not be possible to analyze vulnerabilities according to the service and the underlying IT infrastructure. However, the proposed CIA measures can also serve as external metrics that can be monitored without knowing internal metrics of the service itself and thus be integrated into SLA. For calculating the measures, the external service provider has to transform them into internal metrics and this can be achieved by applying the proposed method. In this case, the approach presented has to be extended to cope with the additional trust issues, e.g., by integrating control goals of compliance management – a challenging topic of further research. Literature [1] BHATT, G.D.; GROVER, V., Types of Information Technology Capabilities and Their Role in Competitive Advantage: An Empirical Study, in Journal of Management Information Systems. Vol. 22(2) (2005), pp. 253-277. [2] BISHOP, M., Computer Security: Art and Science, 2nd ed., Addison Wesley, Pearson Education, Boston, 2003. [3] BÖHME, R.; NOWEY, T., Economic Security Metrics, in Eusgeld, I. et al. (Eds.), Dependability Metrics, Lecture Notes in Computer Science 4909, Springer, Berlin 2008, pp. 176-187. [4] BRANDL, K., Exchange Web Services Windows Vista Gadget, 2008. http://msdn.microsoft.com/en-us/library/cc535019(EXCHG.80).aspx [2008-06-08]. [5] BURROWS, J.H., Guidelines for Security of Computer Application, Federal Information Processing Standards Publication 73, National Bureau of Standards, 1980. [6] CAMPBELL, S.; MOHUN, V., Mastering Enterprise SOA with SAP NetWeaver and mySAP ERP, John Wiley & Sons, Inc., New York, New York 2006. [7] CHESS, B.; McGRAW,G., Static Analysis for Security, in IEEE Security and Privacy. Vol. 2(6) (2004), pp. 76-79. [8] Common Vulnerabilities and Exposures (CVE), Mitre Organization, 2008. http://cve.mitre.org [2008-11-13]. 365 [9] Common Vulnerability Scoring System, FIRST - Forum of Incident Response and Security Teams, 2007. http://www.first.org/cvss [2008-04-22]. [10] CURBERA, F.; KHALAF, R.; MUKHI, N.; TAI, S.; WEERAWARANA, S., The Next Step in Web Services, in Communications of the ACM. Vol. 46(10) (2003), pp. 29-34. [11] DAVIS, R., Exploring Process Modelling: Benefits, Practices and Pitfalls, in Proceedings of the Australasian Process Days 2006, Sydney 2006. [12] GEER, D.; HOO, K.S.; JAQUITH, A., Information Security: Why the Future Belongs to the Quants, in IEEE Security and Privacy. Vol. 1(4) (2003), pp. 24-32. [13] GISOLFI, D., Web services architect, Part3: Is Web services the reincarnation of CORBA?, 2001. http://www.ibm.com/developerworks/webservices/library/ws-arc3 [2007-09-03]. [14] KARABULUT, Y.; KERSCHBAUM, F.; MASSACCI, F.; ROBINSON, P.; YAUTSIUKHIN, A., Security and Trust in IT Business Outsourcing: a Manifesto, in El. Notes in Theoretical Comp. Science. Vol.179 (2007), pp. 47-58. [15] MADISON, D., Process Mapping, Process Improvement, and Process Management: A Practical Guide to Enhancing Work and Information Flow, Paton Press, Chico, California 2005. [16] MILLS, S., The future of business – Aligning business and IT to create an enduring impact on industry, in IBM Thought Leadership Paper, 2007. ftp://ftp.software.ibm.com/software/soa/pdf/future_of_business.pdf [2007-11-30]. [17] MÜLLER, G.; PFITZMANN, A.; RANNENBERG, K., IT Security and Multilateral Security, in Müller, G. and Rannenberg, K. (Eds.) Multilateral Security in Communications, Addison-Wesley 1999, pp. 21-29. [18] RÖHRIG, S., Using Process Models to Analyse IT Security Requirements, Thesis, University of Zürich 2003. [19] SACHDEVA, N.; SCHMIDT, M.-T., Key WebSphere Service Registry and Repository scenarios in business process management, IBM White Paper, 2008. ftp://ftp.software.ibm.com/software/websphere/BPM_WSRR_WP_010308.pdf [2008-04-05]. [20] SACKMANN, S., A Reference Model for Process-oriented IT Risk Management, in W. Golden et al. (Eds.), 16th European Conference on Information Systems, Galway, Ireland 2008. [21] SACKMANN, S., Assessing the effects of IT changes on IT risk – A business process-oriented view, in M. Bichler et al. (Eds.): Multikonferenz Wirtschaftsinformatik MKWI’08, GITO, Berlin 2008, pp. 1137-1148. [22] SALVATI D.; DIERGARDT M., Towards a Scenario Based Risk Model for Information Systems, 2007. http://www.lsa.ethz.ch/people/phd/salvatid/DS-Scenario-Based-Risk-Model.pdf, [2008-01-12]. [23] SANCHEZ, R., Strategic Flexibility in Product Competition, in: Strategic Management Journal, Special Issue on Technological Transformation and the New Competitive Landscape. Vol. 16 (1995), pp. 135-159. [24] SCHNEIER, B., Attack Trees, in Dr. Dobb’s Journal. Vol. 24(12) (1999), pp. 21-29. [25] SCOTT, J.E., Mobility, Business Process Management, Software Sourcing, and Maturity Model Trends: Propositions for the IS Organization of the Future, in Information Systems Management. Vol. 24 (2007), pp. 139-145. [26] SHEYNER, O.; HAINES, J.; JHA, S.; LIPPMANN, R.; WING, J., Automated Generation and Analysis of Attack Graphs, in Proceedings of the 2002 IEEE Symposium on Security and Privacy (2002), pp. 273-284. [27] STYTZ, M., Who Are the Experts, and What Have They Done for Us Lately?, in IEEE Security and Privacy. Vol. 5(6) (2007), pp. 78-80. [28] TANENBAUM, A.S., Structured computer organization, 2nd ed., Prentice-Hall, Englewood Cliffs, New Jersey 1984. [29] WOHED, P.; VAN DER AALST, W.M.P.; DUMAS, M.; TER HOFSTEDE, A.H.M.; RUSSELL, N., On the Suitability of BPMN for Business Process Modelling, Business Process Management, in Dustdar, J.L. et al. (Eds.), BPM 2006, Lecture Notes in Computer Science 4102, Springer, Berlin (2006), pp. 161-176. [30] WOLF, G.; PFITZMANN, A., Empowering Users to Set Their Protection Goals, in Müller G.; Rannenberg, K. (Eds.) Multilateral Security in Communications. Addison-Wesley 1999, pp. 113-135. 366 INTEGRATION OF AN IT-RISK MANAGEMENT/RISK ASSESSMENT FRAMEWORK WITH OPERATIONAL PROCESSES Louis Marinos1, Lutz Kirchner2, Stefan Junginger2 Abstract This paper discusses the background and results of a research project which was conducted by ENISA (European Network and Information Security Agency) in cooperation with the BOC Information Technologies Consulting GmbH. The project was initiated with respect to the main task of ENISA: ensuring a high and effective level of network and information security within organisations in the European Union. As an important step towards this goal the research project aimed at increasing the level of integration between an enterprise-level IT Risk Management/Risk Assessment on the one hand, and selected operational business processes, on the other hand. The proposed integration is mainly established on the level of document flows between processes and activities respectively. In particular, operational processes which are closely related to IT were selected for integration. The introduced approach promises a better overall quality of IT Risk Management in an enterprise in general, as well as an improved management of risks in operational processes. 1. Motivation IT Risk Management is frequently implemented as an isolated process which shows little or no interaction with the various operational processes in an organisation (cf. [22]). This concerns valuegenerating business processes, e.g. procurement and sales, as well as support and management processes, like IT Service Management. As a consequence, risks which have to be dealt with on a daily basis during the execution of those processes are often not taken into account, neither in the course of planning nor of performing IT Risk Management. This causes a potentially negative impact on the overall quality of the operational business processes regarding aspects such as execution time, reliability and cost efficiency. At the bottom line, we assume that an isolated IT Risk Management is generally not as effective as one that is tighter integrated with operational processes and hence does not sufficiently contribute to the achievement of the organisations goals. Some approaches to IT Risk Management, like the Probabilistic Risk Analysis, address this issue by including the frequent gathering of information about operational risks from operational processes (cf. [4]). However, they primarily focus on risk assessment. Thus, their integration with 1 2 ENISA, 71001 Heraklion, Greece, http://www.enisa.europa.eu BOC Information Technologies Consulting GmbH, 10117 Berlin, Germany, http://www.boc-de.com 367 the operational processes is only limited and mostly constricted to quantitative data analysis. The most high-level approaches, i.e. especially IT Risk Management frameworks, usually do not cover the above addressed issue in sufficient depth (cf. paragraph 2.2). To overcome this desideratum, an adequate integration of IT Risk Management processes3 with the operational processes of an organisation – at least on the level of information flows - is recommended. Some of the necessary risk-related information may emerge from Risk Management activities, as they may be already implemented as an integral part of operational processes (e.g. in ITIL Service Continuity and Security Management). Additional information entities are generated “all over” the whole operational process. In consideration of the above discussed issue, the paper at hand aims at identifying interfaces between the IT Risk Management processes described in a Risk Management/Risk Assessment (RM/RA) framework (designed by ENISA, see paragraph 3.1) and selected operational process frameworks (namely ITIL, RUP, PRINCE2TM4 and CMMI, see paragraph 3.2). A pivotal design goal of the interfaces is being as concrete and detailed as it is possible when dealing with reference process frameworks rather than living processes. The focus of the integration is chiefly on the identification of corresponding information entities, the information flow between the processes, and roles. The information entities, which are to be exchanged between the IT Risk Management processes and the operational processes, are semantically mapped to each other for the specific context in which they are used. Thus, it is assured that the terminology of IT Risk Management and operational processes is compatible at any time. Main addressees of the research results are these individuals in an organisation which play a central role in the IT Risk Management implementation, integration and execution process (e.g. administrator, change manager, or CIO). Generally speaking, every person who is involved in planning and monitoring processes as well as being accountable for their outcome on any level of management may be benefiting from the outcome. The results of the research are published in the form of graphical process models created with the tool ADOit® 3.05. For easy accessibility and distribution, the ADOit®-models are being transformed in navigable HTML-models (cf. [7]). Complementing these models, a generic integration process model, which aims at supporting an organisation in the process of integrating IT Risk Management with the supported operational processes, as well as a role mapping table, is included. The paper is structured as follows: Section 2 gives a short introduction to IT Risk Management and presents a selection of IT Risk Management approaches. Section 3 describes the approach used for integration, additionally presenting the ENISA RM/RA Framework as well as two of the integrated operational process frameworks. Also the models, which document the integration results, are being presented in form of an exemplary excerpt. The paper closes with a conclusion in section 4 including a discussion of benefits a user may expect when adopting the models. 2. IT Risk Management This section gives a short overview of the terms risk and (IT) Risk Management (paragraph 2.1). It also introduces and briefly evaluates existing IT Risk Management frameworks (paragraphs 2.2 and 2.3). 3 In the context of Risk Management the associated processes, like e.g. risk assessment and risk control, are often denominated phases. 4 PRINCE2™ is a Trade Mark of the Office of Government Commerce. 5 ADOit® is a modelling tool for supporting Enterprise Architecture Management and IT Service Management. For further information see http://www.boc-group.com/ADOit. 368 2.1. Terminology A risk in general may be regarded as “the potential for realisation of unwanted, negative consequences of an event” (see [11]). Viewed from a decision oriented perspective a risk is the possibility of reaching a wrong decision and having to deal with the resulting negative consequences. Supplementing these definitions, a risk can also be interpreted as the possibility of failing to achieve a certain goal. In this context a positive derivation from a predefined goal specification may be seen as a chance (cf. [19], p. 22; [9], p. 1751). In general, Risk Management aims at making sure, that the existence of an organisation is ensured in the long run ([8], p. 12,). Risk Management is a recurrent process that deals with the analysis, planning, implementation, control and monitoring of implemented measurements. In contrast, Risk Assessment, that usually is seen as a part of Risk Management, is executed at discrete points of time (e.g. once a year, on demand) and provides a temporary view of assessed risks, while giving input to the Risk Management process (cf. [22], p. 6). IT Risk Management is a specialisation of Risk Management and focuses on the implementation of IT with respect to the overall organisational goals (cf. [3], p. 4). Risk Management principles and activities are applied to information technology specific processes. In this paper we assume that there usually exists a corporate-wide IT Risk Management in contrast to an IT Risk Management specifically applied to selected operational processes6. The possible integration of these two perspectives is also covered by this research in form of the definition of specific interfaces. 2.2. Introduction of Existing Approaches There exist numerous standards and good practices that provide guidance for IT Risk Management/Risk Assessment (cf. [22]). Standards like CobiT and ITIL chiefly aim at guiding activities in the area of IT Governance and IT Service Management, also hinting at the management of operational risks. In contrast, Risk Management frameworks focus on the definition of Risk Management processes and controls on a strategic or operational level respectively, but usually lack explicit relations to operational processes (see below). Complementing these approaches, there exists a plethora of sector- and enterprise-specific frameworks developed to fulfil special requirements of certain sectors and companies. This paper does not aim at providing a complete or ultimately well-defined categorisation and evaluation of IT Risk Management approaches. Instead, we pick out a small number of - in our opinion - representative approaches to highlight their general desiderata in terms of integration, according to the discussion in section 1. The approaches, which we briefly introduce in the subsequent paragraphs, provide some rather distinct perspectives on IT Risk Management. They were selected du to the fact, that they are well recognized, widely applied in practice, developed by representative organisations and institutes, and well documented in numerous publications or free-of-charge documentation. IT-Grundschutz of the German Bundesamtes für Sicherheit in der Informationstechnik provides a method for an organisation to establish an Information Security Management System (see [12] and [22], pp. 34 and pp. 93). It comprises both generic IT security recommendations for establishing an applicable IT security process and detailed technical recommendations to achieve the necessary IT security level for a specific domain. The key goal of IT-Grundschutz is to provide a framework for IT security management, offering information structured by typical building blocks (Bausteine), like e.g. infrastructure, IT-systems, and applications. In [13] potential synergies between a number 6 The gap between these two Risk Management approaches is also mentioned in [10], where a newly developed framework is announced for the end of the year, which claims to address this issue. 369 of ITIL processes and IT-Grundschutz are being discussed, but without offering concrete hints on how such an integration can be implemented. ISO/IEC IS 17799:2005 is an international ISO standard that provides information technology security techniques (see [17] and [22] p. 34 and pp. 86). It focuses on risk identification and risk treatment techniques, largely neglecting analysis and evaluation activities. It is mostly appropriate for initial threat identification. The documentation enlists various points that have to be taken into account to manage IT suitably. Interfaces to the organisational processes Human Resources Management, Change Management and Business Continuity Planning are also discussed. Octave v2.0 (and Octave-S v1.0 for Small and Medium Businesses) is a standard originating from Carnegie Mellon University (see [1] and [2] respectively, also [22] p. 36 and pp. 105). It provides a RM/RA method covering risk identification, analysis and evaluation, but only by provision of relevant criteria without further techniques. It includes however a complete framework to deal with the communication of risks. OCTAVE® (Operationally Critical Threat, Asset, and Vulnerability EvaluationSM) is a self-directed approach meaning that people from an organisation assume responsibility for setting the organization’s security strategy. OCTAVE-S is a variation of the approach tailored to the limited means and unique constraints typically found in small organisations (cf. [2], p. 3). 2.3. Summary The above as well as the plethora of other existing approaches all offer some mostly generic and therefore generally applicable guidance to IT Risk Management with a varying focus on specific Risk Management activities, and hence different specific strengths and weaknesses. In [21] the current situation is summarised as follows: “Each one of the standards has aspects that could benefit particular deployments; some include more detailed recommendations, while others prefer to use a more general approach”. Additionally, we may safely state, that the existing approaches do not deal with the challenge of the integration of an enterprise-wide IT Risk Management/Risk Assessment with operational processes in a satisfying manner. However, to truly leverage the synergies that may be created by combining IT Risk Management activities on different organisational levels, such an integration seems imperative. Based on this assumption, we make a proposal for an approach, which addresses this integration matter, in the subsequent paragraphs of this paper. 3. The Integration Approach The major working steps, which were executed consecutively in the course of this work, are discussed in detail in the following paragraphs. 3.1. Modelling of the ENISA RM/RA Framework The ENISA RM/RA Framework was depicted in the form of a graphical process model in ADOit®. The framework is basically a comprehensive summary of relevant concepts found in corresponding methods and literature about IT Risk Management. Due to this fact, it forms a highly adequate basis for the design and conceptualisation of an integration approach, such as it is described in this paper. In the following we give a short overview of the framework. Please refer to [22] for further details. Figure 1 shows a schematic of the framework. The covered processes (or phases) may be performed isolated or collectively. In case that all of the processes are performed, the thick arrows form a cycle which depicts a control flow through the Risk Management processes. The process 370 Definition of Scope and Framework is considered to be the starting point for this control flow. The process aims at the establishment of global parameters for the performance of Risk Management within an organisation. Subsequently, a process describing activities which deal with the identification, analysis and evaluation of risks is executed (Risk Assessment). This process is succeeded by Risk Treatment, which selects and implements measures to modify risk. Risk Acceptance aims at deciding which risks are accepted by the responsible management of the organisation. Monitor and Review describes an ongoing process for monitoring the success of the Risk Management implementation and delivering valuable input to any recursion of the (re)definition of the IT Risk Management. A supplementing Risk Communication process aims at exchanging information about risk to and from all stakeholders. In addition to the above processes, possible interfaces to operational processes are indicated, but not elaborated at this point. Complementing the framework, a set of information entities is identified by ENISA and incorporated in the model. These entities describe the exchange of information between the various Risk Management processes. Additionally, some roles are identified, which are typically involved in the execution of the Risk Management processes. These are Senior Management/Board of Directors, Risk Manager, Risk Owner, Internal Audit and Domain Expert (cf. [7]). Figure 1: The Risk Management Process in ADOit® 3.2. Modelling of the Operational Processes Due to limited resources, the number of operational process frameworks, which could be considered for integration, was restricted. Hence, the decision was made to include ITIL (see below), an application development process based on RUP (also see below), PRINCE2TM (Project Management in Controlled Environments 2, see [20]) and CMMI (Capability Maturity Model Integration, see [5]). The main reason for this choice is that these processes represent commonly used procedures and solutions for dealing with challenges in the field of IT Management, which 371 most companies have to meet, regardless of the business sector they are operating in. Moreover, they are to a certain extend accepted as de-facto standards. Furthermore, they are generally well documented and offer enough detail for integration with the ENISA RM/RA Framework, especially regarding the documentation of activities, roles and information entities. The following paragraphs give an overview of two of the operational process frameworks selected for integration. ITIL (Information Technology Infrastructure Library) was developed by the OGC (Office of Government Commerce) starting back in 1987. It aims at defining guidelines for the appropriate and efficient provision of IT services in organisations. The subsets of ITIL which are of interest for this report are Service Delivery, Service Support and Security Management (see [14], [16] and [15]). These processes are part of version 2 of ITIL and were selected for integration with Risk Management since they likely represent the most commonly used parts of ITIL at this point in time. Service Delivery mainly deals with planning and controlling aspects of IT service management. Service Support contains processes chiefly describing the support of customers in case of occurring incidents and problems. Security Management treats aspects like data security, risks and protection measures and therefore provides some parallels to Risk Management processes.7 The data that is gathered during the execution of ITIL service processes is highly valuable for assessing IT risks and helps to improve the corporate IT risk strategy. This applies especially for processes such as Incident Management and Problem Management, which deal with the consequences of IT risks. Moreover, an integration of IT Risk Management and ITIL allows for including risk treatment measures in the service process definitions – e.g. in IT Service Continuity processes - and thus improving these processes. Application Development Process: The application development process used for integration purposes is a generic heavy weight process, which is loosely based on the RUP (Rational Unified Process, see [18]). RUP is developed and published by Rational, which was acquired by IBM in 2003. The application development process should be used as a framework which can be tailored according to the requirements of the user. It comprises a number of process steps including analysis, design, implementation, testing and deployment. These most commonly used process steps are typical for almost every heavy weight software development process and hence were selected as a basis for creating the process models. The integration of an application development process with IT Risk Management ensures that on the one hand Risk Management receives valuable input from software development projects, thus contributing to the overall definition of IT Risk Management strategies. On the other hand, considering well defined risk treatment activity plans as an input to software development projects helps steering such projects and minimising the risk of failure. The selected operational processes are modelled in the same way as the RM/RA framework, thus beginning with control flows, followed by information entities, information flows and finally roles. 3.3. Modelling of the Interfaces between the Processes As a first step of integration, the activities of the operational processes, which provide interfaces to the Risk Management processes, are identified. Secondly, the information flow between the integrated activities or processes respectively is depicted. A third step is necessary when a data element is used as an incoming information flow to an activity. In this case a semantic data 7 ITIL V3 is available since early 2007 but has to ultimately supersede ITIL V2 yet, so it was not considered for inclusion. 372 mapping is conducted, which relates the incoming data element to the corresponding data elements of the receiving process. This is necessary since the data element terminology of the operational processes is not exactly matching these of the ENISA RM/RA Framework (see below). Figure 2 shows an excerpt of an IT Risk Management process with two exemplary interfaces to other processes, namely ITIL Service Support processes. The sole activity of the process, “A.14 Risk monitoring and reporting” has several roles attached, which are arranged according to their specific role relation to the activity. The role Internal Audit is responsible and accountable for the activity (hence arranged below the R- and A-symbols). The Domain Expert and Risk Owner are to be consulted (C) and the Risk Manager and Senior Management informed (I). This kind of role annotation is inspired by the RACI-role definitions, as they are for instance used in CobiT ([6]). In addition to the activities and roles the exchanged information entities (also denoted as data elements) and a data port are also included in the example. A data port contains a table which maps the incoming data elements to the data definitions of the receiving process. Figure 3 shows an exemplary data mapping. The left column displays the incoming data elements whereas the right column contains the mapping target, i.e. the data elements which are used in the receiving activity to store the incoming information. In this concrete example the incoming data elements are a subset of the documented ITIL-terminology (see [16]) and are mapped to the data elements defined for the ENISA RM/RA Framework. Note, that this is usually not a 1:1 relationship, but rather 1:n. Figure 2: The Monitor and Review Process with Interfaces to ITIL Service Support Figure 3: Mapping of Data Elements (excerpt from HTML model version) Figure 4 schematically illustrates the information flow from the ITIL process Incident Closure to the Monitor and Review process of the ENISA RM/RA Framework. From the ITIL-activity Inform User in the process Incident Closure a document Incident Status is handed over to the Risk Management activity A.14 Risk monitoring and review, where it is used to evaluate the success of the measures defined in IT Risk Management. If an increase of severe incidents in the recent past is discovered, e.g. by measuring these and other values with a set of Risk Management specific KPIs (Key Performance Indicators), Risk Management may be able to react in time and calibrate the concerned processes accordingly. To track the information flows throughout the complete set of models, model navigation is based on the easy-to-handle navigational features of ADOit® and its generated models in HTML-format. 373 ITIL Incident Management (Incident Closure) RM/RA Framework (Monitoring and Review) Figure 4: Example of Document Flow between two Processes Concluding the design step described in this paragraph, the mapping of roles was conducted for these processes which were provided with adequate role definitions. Analogous to the data definitions, the roles used in the context of Risk Management are not identical to those defined in the operational processes. Hence, they were semantically mapped to each other. Thus, in the integrated models the ITIL Change Manager e.g. is also acting as a Risk Owner and a local Risk Manager. A complete list of Risk Management roles and their mapping to roles of the covered operational processes can be found in [7]. 3.4. The Process Model for Result Application In order to successfully apply the above presented project deliverables in the course of a Risk Management integration process, a methodical approach like the one introduced in this paper is recommended. The selection of the activities, which may be executed as a part of the integration process, depends on the initial situation of an organisation prior to the implementation of the integration. Especially depending on the number of operational and Risk Management processes, which are already implemented in an organisation, some of the implementation activities may be omitted. In general, the following steps may be executed to establish an integration process: 1. 2. 3. 4. 5. Risk Management Implementation (if not already done in the past) Operational IT Process Implementation (if not already done in the past) Integration Planning and Initiation (resource assignment, process mapping etc.) Quality Assurance (e.g. review and improvement of process) Execution of Processes (support of staff, monitoring and constant improvement of process) A detailed description of the process steps and related activities can be found in [7]. 374 4. Conclusion The paper at hand illustrated the need for a thorough integration of an IT Risk Management approach and operational process, and proposed an approach for performing such an integration. The main contribution of the approach is the provision of concrete information flows between activities of IT Risk Management processes and operational process frameworks, which results in a detailed guide for establishing and harmonising both process types in an organisation. The overall expected benefit of the research results for a user, who applies the approach, can be summarised as following: • • The user receives guidelines for o Implementing Risk Management with a provided RM/RA framework o Implementing operational IT processes through provided reference models for IT service management, application development, project management and process maturity o Implementing an integration between Risk Management and common operational processes through provided interfaces, data flow definitions as well as data and role mappings o Planning and executing the whole integration process through the exemplary integration process model The resulting user benefits are o Guidance along the whole implementation and integration process o Better quality of IT Risk Management, especially with respect to the handling of operational risks o Better protection against disastrous incidents, which may cause severe damage to the organisation and result from operational risks o Improved line-up regarding compliance with frameworks which include regulations on Risk Management (e.g. SOX, Euro-SOX, Basel II, Solvency II) Potential future research could consider other possible dimensions of integration between Risk Management and operational business processes, like e.g. integration on the level of control flows, or technical interface specification for software tools. It has to be evaluated, if these kinds of integration deliver further value to the adopter. Furthermore, the success of the approach depends on the set of operational process frameworks, which are covered by documented integration scenarios. Our approach cannot be applied to an arbitrary operational process without first identifying and documenting the interfaces. To provide these interfaces to a larger number of operational process frameworks is subject to future work. 5. Literature [1] ALBERTS, C.J.; DOROFEE, A.J.: OCTAVESM Method Implementation Guide Version 2.0. Software Engineering Institute, Carnegie Mellon University, 2001 [2] ALBERTS, C.J; DOROFEE, A.J.; STEVENS, J.; WOODY, C.: OCTAVE®-S Implementation Guide. Version 1.0, Volume 1: Introduction to OCTAVE-S, Software Engineering Institute, Carnegie Mellon University, 2005 [3] BALDUIN, A. v.; JUNGINGER, M.; KRCMAR, H.: Risikomanagement von Informations- und Kommunikationstechnologien mit dem Value at Risk-Ansatz. Arbeitsbericht, Technische Universität München, 2002. [4] BEDFORD, T.; COOKE, R.: Probabilistic Risk Analysis. Cambridge University Press, Cambridge, 2001 375 [5] CMMI for Development. Version 1.2, Carnegie Mellon SEI, 2006 [6] CobiT 4.1: Framework, Control Objectives, Management Guidelines, Maturity Models. ITGI, 2007 [7] Demonstrators of RM/RA in Business Processes – Project Report. ENISA and BOC GmbH, 2007 [8] DIEDERICHS, M.: Risikomanagement und Risikocontrolling: Risikocontrolling – ein integrierter Bestandteil einer modernen Risikomanagement-Konzeption. Dissertation, Universität Dortmund, 2004. [9] FARNY, D.: Risk Management und Planung, In: Szyperski, N., Winand, U. (Hrsg.): Handwörterbuch der Planung, Stuttgart, S. 1749 – 1758, 1989 [10] FISCHER, U.: New Framework for Enterprise Risk Management in IT. In: Information Systems Control Journal, Volume 4, ISACA, 2008 [11] HEEMSTRA, F.J.; KUSTERS, R.J.: Dealing with risk: a practical approach. In: Journal of Information Technology, Volume 4, pp. 333.346, 1996 [12] IT-Grundschutz-Kataloge, 9. Ergänzungslieferung, Stand 2007. Bundesamt für Sicherheit in der Informationstechnik, 2007 [13] ITIL und Informationssicherheit: Möglichkeiten und Chancen des Zusammenwirkens von IT-Sicherheit und ITService-Management. Bundesamt für Sicherheit in der Informationstechnik, 2005 [14] ITIL Service Delivery. CD-ROM Version, Office of Government Commerce, Norwich, 2003 [15] ITIL Security Management. Office of Government Commerce, Norwich, 1999 [16] ITIL Service Support. CD-ROM Version, Office of Government Commerce, Norwich, 2003 [17] ISO/IEC 17799:2005: Information Technology - Security Techniques - Code of Practice for Information Security Management. International Standards Organisation, 2005 [18] KRUCHTEN, P.: The Rational Unified Process: An Introduction. Addison Wesley, Reading, 2000 [19] LOCHER, CH.; MEHLAU, J.I.; HACKENBERG, R.G.; WILD, O.: Risikomanagement in Finanzwirtschaft und Industrie – Eine Analyse des Management operationeller Risiken in deutschen Industrie- und Dienstleistungsunternehmen, ibi research an der Universität Regensburg gGmbH, 2004 [20] Managing successful projects with PRINCE2. TSO, London, 2005 [21] RAMIREZ, D.: Risk management standards: The bigger picture. In: Information Systems Control Journal, Volume 4, ISACA, 2008 [22] Risk Management: Implementation principles and Inventories for Risk Management/Risk Assessment methods and tools. Technical Department of ENISA, Section Risk Management, www.enisa.europa.eu/rmra, 2006 Acknowledgement The authors wish to express their gratitude to Aneta Nowobilska and David Heise who offered great support in assessing the literature and gave valuable input. 376 INTERNAL CONTROLS SCRIPTING LANGUAGE (ICSL): GRUNDZÜGE EINER INSTRUKTIONSSPRACHE FÜR INTERNE KONTROLLEN Tom Beiler1, Markus Böhm2 Kurzfassung Compliance von Unternehmen, also die Erfüllung gesetzlicher und regulatorischer Vorgaben, nimmt in ihrer Bedeutung stetig zu, und damit steigt auch die Bedeutung des Internen Kontrollsystems. Problematisch dabei ist, dass die Vorgaben für die Gestaltung des Internen Kontrollsystems Interpretationsspielräume zulassen, die zu unerwünschten Effizienzverlusten bei der Umsetzung der Vorgaben führen können. Dieser Beitrag stellt in diesem Zusammenhang die Grundzüge einer formalisierten Sprache vor, mit der sich interne Kontrollen präzise beschreiben lassen, so dass Angemessenheit und Wirksamkeit von Kontrollen bei der Gestaltung und Erweiterung des Internen Kontrollsystems besser beurteilt werden können. 1. Einführung Das Interne Kontrollsystem (IKS) ist ein zentrales Element in Unternehmen, um die Wirtschaftlichkeit und Wirksamkeit der Geschäftstätigkeit zu sichern [3]. Neben dem Schutz des Vermögens der Eigentümer oder Anteilseigner dient das IKS ebenfalls dazu, die Ordnungsmäßigkeit und Verlässlichkeit der Rechnungslegung sowie die Einhaltung von gesetzlichen und regulatorischen Vorgaben sicherzustellen. Diese Aufgabe der Einhaltung von Gesetzen und regulatorischen Vorgaben sowie der intern definierten Regelungen und Richtlinien führt in den Bereich der Compliance [9]. Compliance, also das Verhalten in Konformität mit bestimmten Regeln sowie der explizite Nachweis dieser Konformität gegenüber Dritten, hat in den letzten Jahren deutlich an Bedeutung gewonnen. Auch ist die Zahl der Vorgaben, die ein Unternehmen je nach Branche und Gesellschaftsform beachten muss, stark gestiegen, und eine Umkehrung dieser Tendenz ist nicht erkennbar. So gibt es neben dem bekannten Beispiel des Sarbanes-Oxley Act [11, 12] eine Vielzahl weiterer Vorgaben, die heutige Unternehmen gegebenenfalls erfüllen müssen. Eine recht vollständige Übersicht gibt [16], unter anderem zu: • Basel II • European 8th Directive • Gesetz zur Kontrolle und Transparenz im Unternehmensbereich (KonTraG) • Health Insurance Portability and Accountability Act (HIPAA) 1 2 Strat Hollis, Germany PricewaterhouseCoopers, Germany 377 • Payment Card Industry Data Security Standard (PCI-DSS) Weiterhin ist zu beobachten, dass zunehmend auch industriegetriebene Vorgaben für Unternehmen verbindlich werden, beispielsweise des PCI Data Security Standard [13]. Hier fordern nicht der Gesetzgeber oder eine Regulierungsbehörde, sondern namhafte Vertreter der Kreditkartenindustrie die Einhaltung, begründet über ihre Stellung im Markt. Zur Schaffung und Erhaltung der Compliance leistet das IKS eines Unternehmens einen entscheidenden Beitrag, und mit der Zunahme der Bedeutung von Compliance steigt auch die Bedeutung von interner Kontrolle, denn zusätzliche Compliance-Vorgaben stellen in der Regel auch neue und erweiterte Anforderungen an das IKS eines Unternehmens. Hierzu werden entsprechend der Zielsetzung der gegebenen Compliance-Aufgabe typischerweise bestimmte Kataloge mit Anforderungen an Unternehmensprozesse und deren Kontrolle assoziiert bzw. Ausschnitte von diesen als geeignet identifiziert. Diese Kataloge bestehen im Wesentlichen aus einer hierarchisch gegliederten Liste von Kontrollzielen (Control Objectives), zusammen mit Beschreibungen zugehöriger Kontrollmechanismen (Control Practices). Diese Mechanismen sollen, bei korrekter Umsetzung und Anwendung, sicherstellen, dass die Kontrollziele erreicht werden. Für den Bereich der Informationstechnologie eines Unternehmens sind [5, 6, 7, 8, 13, 14] solche Kataloge; in Abbildung 1 sind zur Veranschaulichung zwei Beispiele hieraus angegeben. Für Unternehmen besteht somit im Zuge der Compliance-Herstellung die Aufgabe, ihr IKS entsprechend dieser neuen Anforderungen zu erweitern. Das bedeutet, dass die Kontrollziele und Mechanismen im spezifischen Unternehmenskontext richtig interpretiert, angemessen gestaltet und damit wirksam implementiert werden müssen. In der Praxis ist diese Aufgabe allerdings keineswegs trivial. So liegen im Fall des Sarbanes-Oxley Act Untersuchungen vor, die den Schluss nahe legen, dass die Bewältigung dieser Aufgabe oftmals weder reibungslos vonstatten geht noch als effizient wahrgenommen wird. (Einige Zahlen hierzu sind in Abbildung 2 gegeben). Ein bedingender Faktor hier ist, dass die Anforderungskataloge gleichzeitig für viele Unternehmen Gültigkeit haben sollen und daher zwangsläufig eher allgemein und nur wenig spezifisch gehalten sind. Damit entstehen aber auch erhebliche Interpretationsspielräume bei der Implementierung innerhalb einer SOX Control 8: Ensure Systems Security, 8.8: Periodic Review of Access Rights. [8] Illustrative Control: A control process exists and is followed to periodically review and confirm access rights. Illustrative Test of Control: Inquire whether access controls for financial reporting systems and subsystems are reviewed by management on a periodic basis. Assess the adequacy of how exceptions are reexamined, and if the follow-up occurs in a timely manner. PCI-DSS Requirement 1: Install and Maintain a Firewall Configuration to Protect Cardholder Data. [13, 14] Requirement 1.2: Build a firewall configuration that denies all traffic from “un-trusted” networks and hosts, except for protocols necessary for the cardholder data environment. Recommended Audit Procedure: Select a sample of firewalls/routers 1) between the Internet and the DMZ and 2) between the DMZ and the internal network. The sample should include the choke router at the Internet, the DMZ router and firewall, the DMZ cardholder segment, the perimeter router, and the internal cardholder network segment. Examine firewall and router configurations to verify that inbound and outbound traffic is limited to only protocols that are necessary for the cardholder data environment. Abbildung 1: Beispiele aus zwei Anforderungskatalogen 378 konkreten Unternehmensrealität. Das wiederum birgt ein erhebliches Risiko für Defizite in interner Kontrolle von unter Umständen signifikantem Ausmaß, welche im ungünstigsten Fall erst im Rahmen einer Prüfung entdeckt werden. Die entsprechende Folge wäre dann die Feststellung der NonCompliance, also die Verfehlung des eigentlichen Ziels. Prüfungen und Kontrollen sind keineswegs eine neue Unternehmenspflicht; Unternehmen besitzen im Gegenteil bereits einen mehr oder weniger reichhaltigen Fundus an Kontrollen und Prüfprozeduren. Ebenso werden in Fällen größerer Compliance & Control Projekte externe Spezialisten und Dienstleister hinzugezogen, die ihr Know How in diesem Bereich einbringen. Dennoch, obwohl viele Unternehmen an dieser Stelle gleichartige Probleme erfahren, und das Wissen zu korrekten Implementierungen grundsätzlich vorhanden ist, hat sich bisher keine allgemein verfügbare Interpretationsmethodik über Unternehmensgrenzen hinweg etabliert. Die gemachten methodischen Erfahrungen werden nicht oder nur kaum mitgeteilt und somit auch nicht synergetisch im Sinne einer erweiterten Best Practice der Interpretation aufbereitet. Dabei hätte eine solche Methodik Vorteile: Im Zuge einer konkreten Implementierung könnten Alternativen für präzisierte Kontrollen von anerkannter Qualität verglichen und in Bausatzart ausgewählt werden oder mindestens als Startpunkt einer Anpassung dienen; eine Prüfung des Designs und eventuell auch der operationalen Effektivität würde vereinfacht. Aus Unternehmenssicht wäre es wünschenswert, wenn sich mit einem solchen Hilfsmittel die Effizienz bei Entwicklung und Betrieb des IKS verbessern ließe. Eine Voraussetzung zu einer Interpretationsmethodik ist die Möglichkeit der formalen Beschreibung von Kontrollen und Kontrollprozeduren. Von einem solchen Formalismus ist zu fordern, dass zum einen die durchzuführenden Kontrollaktivitäten möglichst genau beschrieben werden können. Dabei muss eine möglichst genaue Orientierung an den Vorgaben unterstützt werden, um das Risiko einer fehlerhaften Interpretation und Durchführung zu minimieren. Zum anderen soll ein solcher Formalismus ausreichend Flexibilität bieten, so dass Kontrollen in jedem Schritt der Präzisierung, beginnend bei allgemeinen Anforderungen und dann mit der entsprechend erforderlichen Expertise, durchführbar sind. So wird der Prozess der Interpretation der Vorgaben im Unternehmenskontext Der Sarbanes-Oxley Act ist eine Compliance-Vorgabe, die für an U.S.-Börsen gelistete Unternehmen zu erfüllen ist. Motiviert unter anderem durch den Enron und WorldCom-Skandal werden CFO und CEO verpflichtet, die Korrektheit der Finanzberichterstattung zu bestätigen, indem sie die korrekte Funktion der internen Kontrollen persönlich zertifizieren. Kann eine korrekte Funktion aufgrund signifikanter Schwachstellen in den internen Kontrollen nicht festgestellt, und somit eine Fehlerhaftigkeit der Finanzberichterstattung nicht ausgeschlossen werden, so ist diese Tatsache mit den Finanzberichten der Börsenöffentlichkeit und Investoren gegenüber zu bekunden. Die Organisation 'Financial Executives International' (FEI) hat bei einer Umfrage für das Berichtsjahr 2006 festgehalten [4], dass nur 22% von befragten Repräsentanten betroffener Unternehmen den Nutzen als die Kosten überwiegend einschätzten, während 78% befanden, die Kosten würden den Nutzen übersteigen. Andererseits jedoch zeigt ein Report von Lord & Benoit [10], dass Unternehmen, die im Hinblick auf ihre Finanzberichterstattung keine Schwachstellen des Internen Kontrollsystems offenlegen mussten, dafür auch vom Aktienmarkt „deutlich belohnt“ wurden. Diese Beobachtungen lassen zusammengenommen den Schluss zu, dass die unternehmensinterne Realität der Sarbanes-Oxley Compliance negativer wahrgenommen wird als das tatsächliche Ergebnis im Aktienwert vermuten ließe. Ein möglicher Faktor für dieses Missverhältnis zwischen Wahrnehmung und Ergebnis sind die Reibungsverluste durch die Maßnahmen zur Schaffung und Erhaltung der Compliance. Der FEI-Bericht gibt auch die Größenordnung der Aufwendungen für Sarbanes-Oxley Compliance für das Berichtsjahr 2006 an. Dem Bericht zufolge werden durchschnittlich ca. 18.000 Personenstunden angegeben, und die Kosten, für eine Stichprobe von 200 Unternehmen, belaufen sich im Durchschnitt auf 2,9 Mio. Dollar. Bei diesen Zahlen ist zu beachten, dass sie sich auf SarbanesOxley Vorgaben als ganzes beziehen. Rein auf das IKS bezogen liegen solche Untersuchungen leider nicht vor. Abbildung 2: Einige Daten zur Praxis des Sarbanes-Oxley Act 379 nicht durch unangemessen strikte Formerfordernisse behindert, sondern stattdessen sogar unterstützt. Mit der Instruktionssprache für Interne Kontrollen ICSL stellen wir in diesem Beitrag einen solchen Formalismus vor. 1.1. Diskussion verwandter Ansätze und alternativer Kandidaten Am Markt für Unternehmensdienstleistungen und -produkte werden Unternehmen mit ComplianceAufgaben durchaus unterstützt. Es gibt, nicht zuletzt motiviert durch den Sarbanes-Oxley Act, eine Reihe von Produkten, die Unternehmen bei der Bewältigung von Compliance-Aufgaben im Bereich der Dokumentation unterstützen können [2]. Diese Produkte sind oftmals jedoch nur wenig mehr als eine Adaption von Dokumenten-Management; Dokumenteninhalte mit den eigentlichen Beschreibungen von Kontrollen werden hingegen meist nicht mehr innerhalb des Produkts detailliert abgebildet. Eine Übersicht hierzu liefert [17]. Zur Lösung der eingangs geschilderten Probleme sind diese Produkte in dieser Form daher nur bedingt geeignet, und aus diesen Produkten sind bisher auch keine Ansätze vergleichbar mit ICSL hervorgegangen, oder sind zumindest unzugänglich geblieben. Eine weitere Klasse von Werkzeugen verfolgt den Zweck, mittels Programmskripten automatisch Daten aus relevanten Systemen zu extrahieren, zu konsolidieren, und zu analysieren. Ein bekannter Vertreter ist hier die 'Audit Command Language' ACL, von den Alternativen ist Picalo ein freies Werkzeug im Sinne von Open Source [1, 15]. Diese Werkzeuge werden für Kontrollen eingesetzt: routinemäßig im Rahmen von IKS sowie ad hoc, und auch zur Aufdeckung und forensischen Analyse von Betrug in Unternehmen. Des Weiteren gibt es spezialisierte Werkzeuge zur automatischen Überwachung von Hard- und Software-Komponenten, insbesondere um die Konfiguration dieser Komponenten zu erfassen, mit den Soll-Einstellungen zu vergleichen und gegebenenfalls eine Korrektur einzuleiten. Beispiele hierfür sind die Einstellungen von IT-Komponenten zur minimalen Passwortqualität, und die automatische Überprüfung von Firewall-Einstellungen. Diese Werkzeuge sind jedoch nah an IT-Komponenten orientiert, und daher kaum allgemein verwendbar. Davon abgesehen ist die Zielsetzung dieser Werkzeuge eine Automatisierung, und so können in beiden Fällen diese Sprachen nicht die oberste Ebene der persönlichen, manuellen Kontrolle durch die tatsächlich Verantwortlichen innerhalb des Unternehmens vollständig ersetzen, denn sonst würde das Verantwortlichkeitsprinzip verletzt. Auch wenn eine Automatisierung, wo sie möglich ist, grundsätzlich Vorteile und Unterstützung bietet, sollte dennoch Spielraum für fließende Übergänge von manuellen zu automatisch angereicherten Kontrollen vorhanden sein. Dies ist vor allem dort ein Vorteil, wo eine situative Reaktion auf eine variierende Kontrollumgebung und menschliches Urteilsvermögen gefragt sind. In derartigen Situationen erweisen sich automatische Lösungen als zu statisch und unflexibel. Zudem kann der Betrieb solcher Werkzeuge für Unternehmen einen hohen Kostenfaktor darstellen. Als Konsequenz sei festgehalten, dass eine Instruktionssprache ICSL mit automatischen Kontrollen sinnvoll kooperieren können muss. 2. Die Grundzüge von ICSL ICSL basiert auf der Beobachtung, dass die einschlägigen Kontrollanforderungskataloge einer Normsprache bereits recht nahe sind. Es treten häufig dieselben Handlungsanweisungen auf, angewendet auf verschiedene Objekte. Folgerichtig besteht ICSL im Kern aus einer Formalisierung der typischen, verwendeten Handlungsanweisungen wie zum Beispiel 'verify', 'identify' und 'obtain' mit einer Festlegung der zugehörigen Objekte. Eine exemplarische Auswahl von Grundinstruktionen ist in Abbildung 3 dargestellt. Hinzu kommen Elemente zur Strukturierung von Prozeduren, nament380 lich zur Gruppierung und Blockbildung, zur bedingten Ausführung, und zur Iteration. Darüber hinaus enthält ICSL die Möglichkeit, untergeordnete, externe und automatische Skripte zu initiieren und auszuwerten. Abbildung 4 zeigt die Strukturierungselemente von ICSL. Ein weiteres Element von ICSL ist die Behandlung von Instruktionsobjekten als Variablen. Im Gegensatz zu Kontrollbeschreibungen in gebrauchssprachlicher Form werden in ICSL die verwendeten Objekte, insbesondere die in die Kontrolle involvierten Rollen und Personen und die erhobenen und gesammelten Nachweise (beispielsweise Listen, Spreadsheets, Dokumente, E-Mails, digitalisierte Kopien) eineindeutig benannt und referenziert. In der ICSL-Notation werden die Schlüsselwörter einer Instruktion in Fettschrift und literale Satzteile sowie Variablen in normaler Schriftstärke geschrieben. Variablen haben zudem zur Kennzeichnung ein Dollarzeichen '$' vorangestellt, und wenn sie mit Inhalten belegt sind, werden sie, ähnlich einem Hyperlink, unterstrichen. Es gibt keinen formalen Unterschied zwischen skalaren Daten und Datenlisten. Im Zweifelsfall ist ein Skalar eine Liste mit nur einem Element. Falls zur Verdeutlichung gewünscht, können Variablen, die Listen repräsentieren, in eckige Klammern und weiterhin mit führendem Dollarzeichen zur Variablenkennzeichnung gesetzt werden. Variablennamen, die aus mehreren Wörtern bestehen, können zur Vermeidung von Missverständnissen in runde Klammern gesetzt werden. Ein ICSL-Skript muss stets mindestens eine 'Conclude'-Instruktion enthalten. Damit wird festgeschrieben, dass die Durchführung einer Kontrolle immer ein Ergebnis 'Pass' oder 'Fail' haben muss, das heißt, die Feststellung eines Sachverhaltes muss auch zu einer Bewertung führen. Eine Ausnahme ist eine alleinstehende 'Verify'-Instruktion: Dies ist der Anfang einer Refinement-Kette, und wir gehen davon aus, dass ein 'Conclude' in diesem Fall implizit enthalten ist. Verify that $Item(s) is/are $Prädikat. Verify ist eine abstrakte Instruktion die feststellt, ob Prädikat für Item bzw. für alle Items wahr ist. Ohne Refinement lässt sie es frei, wie diese Prüfung angemessen durchzuführen ist. Verify bildet sinnvoller weise den Anfang einer Refinement-Kette. Result. Optional kann mit Comparator eine Vergleichsmethode angegeben werden. Validate $Item with $Check-Liste. 'Validate' überprüft Item mithilfe der gegebenen Prüfliste Check-Liste. Das Ergebnis dieser Validierung steht im weiteren Ablauf in Check-Liste zur Verfügung. Obtain $Item from $Rolle/Person. Conclude to Pass if Bedingung, or to Fail otherwise. 'Obtain' ist eine Eingabe-Instruktion: Es soll eine Sache oder Information, beschrieben mit Item, von einer Person Person, oder von einer Person in der angegebenen Rolle Rolle erhalten werden. Falls eine Rolle spezifiziert war, steht im weiteren Verlauf der Name der tatsächlichen Person in dieser Variablen. 'Conclude' stellt das Kontrollergebnis 'Pass' oder 'Fail' fest. Hierzu werden die vorherigen Tests in Bedingung ausgewertet und mit einem Referenz- oder Schwellwert verglichen. Identify Element(e) in $Item(s) where $Prädikat to $Ergebnis. 'Identify' liefert diejenigen Elemente aus Item(s), für die das Prädikat Prädikat erfüllt ist. Das Ergebnis bzw. die Liste mit den identifizierten Elementen befindet sich anschließend in Ergebnis. Compare $Item-1 and $Item-2 [on $Komparator] to $Ergebnis. 'Compare' vergleicht zwei Dinge Item-1 und Item-2 und beschreibt als Ergebnis die festgestellten Unterschiede in Assess $Sachverhalt [with $Methode] to $Assessment. 'Assess' liefert eine Einschätzung des gegebenen Sachverhalts. Meist ist dies das Kontrollresultat, oder ein Zwischenergebnis. Das Ergebnis steht in Assessment. Optional kann mit Methode eine Methode, Vorlage oder andere Arbeitshilfe angegeben werden. Report Ergebnis with $Vorlage. 'Report' beschreibt das Kontrollergebnis, und möglicherweise weitere Details z.B. statistischer Art, in Form und mithilfe von Vorlage. Der Report ist anschließend in Vorlage enthalten. Abbildung 3: Eine Auswahl von ICSL Grundinstruktionen 381 Block / Gruppierung: {Instruktionsfolge} Folgen von Instruktionen werden in einem Block gruppiert, um sie gemeinsam als eine strukturelle Einheit handhaben zu können. Dies wird von den weiteren Strukturelementen von ICSL benötigt. Eine solche zusammengehörige Instruktionssequenz wird in geschweifte Klammern gesetzt. Es ist außerdem guter Stil, die Instruktionen einzurücken. Eine einzelne Instruktion bildet bereits eine Folge; dann können die geschweiften Klammern weggelassen werden. Bedingte Ausführung: if Bedingung then Block else Block. ICSL enthält die typische Bedingte Ausführung in der typischen Schreibweise if-then-else. Iteration: For each $Item in $Liste [do] Block. in jeder Iteration steht in Block das aktuell iterierte Listenelement Item zur Verfügung. Die Liste wird Element für Element 'ausgerollt', und der Block auf jedem Element einmal durchgeführt. Refinement: Instruktion by Block. Der Refinement Operator 'By' kann am Ende bzw. anderer geeigneter Stelle einer Grundinstruktion stehen. Der zugehörige Block beschreibt dann genauer, wie die Grundinstruktion auszuführen ist. Die häufigste Grundinstruktion, die so präzisiert wird, ist die 'Verify'-Instruktion. Aufruf Externer Skripte: Perform Skript. Mit der Instruktion 'Perform' werden andere Skripte zur Ausführung gebracht. Solche Skripte können wiederum ICSL-Skripte sein, oder auch beliebige andere Skripte, wie z.B. automatische Skripte in ACL. Mit diesem Operator wird über die Liste Liste iteriert, und Abbildung 4: Die Strukturierungselemente von ICSL Die Reihenfolge eines Skripts kann aufgebrochen werden, wenn zum Beispiel erst während der testenden Phase ein weiterer Eingabebedarf auftritt und ein weiteres bzw. wiederholtes 'Obtain' oder 'Observe' erforderlich wird. Ein solcher Fall tritt ein, wenn erst im Testverlauf auffällt, dass die Eingaben nicht vollständig waren. Ebenso die Reihenfolge betreffend ist die Verfahrensweise, wenn das Skript nicht sinnvoll weitergeführt werden kann, weil etwa auf ein 'Obtain' keine verwertbare Eingabe trotz angemessenen Aufwands erfolgt ist. Dann liegt es im Ermessen des Ausführenden, an geeigneter Stelle wieder aufzusetzen. In der Regel ist diese Stelle dann das 'Conclude' mit einem Ergebnis 'Fail' inklusive geeigneter Begründung. Weitere Konstrukte von ICSL sind das Refinement zur Unterstützung verschiedener Grade an Präzisierung sowie die Historisierung von tatsächlich durchgeführten Kontrollen. Beide Konstrukte werden im Folgenden detaillierter dargestellt. 2.1. Refinement ICSL enthält ein Konstrukt zum Refinement. Mit Refinement wird in der Spezifikationstheorie die Konkretisierung einer allgemeineren Spezifikation in eine näher am Zielsystem orientierte Spezifikation bezeichnet. Aus den Freiheitsgraden, die eine höhere Spezifikation bietet, werden konkrete Möglichkeiten im Hinblick auf das Zielsystem gewählt und festgelegt. ICSL enthält dieses Konstrukt, um den Vorgang der Interpretation von einer allgemeinen Kontrollvorgabe, bei der vergleichsweise viel Expertenwissen zur Durchführung benötigt wird, zu einer im Unternehmenskontext konkreteren Anpassung mit weniger Freiheitsgraden, und damit mit weniger Fehlermöglichkeiten zu begleiten. Wir demonstrieren den Refinement-Vorgang anhand von SOX-Cobit 8.8 aus Abbildung 1. Die gegebene Kontrolle lässt sich umschreiben in eine Verify-Instruktion: A control process exists and is followed to periodically review and confirm access rights. ▼ Transformation nach ICSL Verify that all access rights are periodically confirmed. Bei der Transformation nach ICSL ist der Term 'a control process exists and is followed' wegen Redundanz weggefallen. Des weiteren fließt bei der Transformation das Expertenwissen mit ein, 382 dass es hier insbesondere darum geht, dass für alle Benutzer relevanter Systeme die Zugriffsrechte regelmäßig bestätigt werden sollen, um Zugriffsrechte, für die keine Autorisierung (mehr) vorliegt, zu entdecken und in der Folge zu bereinigen. Es ist hier übrigens auch zu sehen, dass bereits ein verhältnismäßig einfacher und klarer Satz nicht unbedingt einfach in der Interpretation ist. Unter Berücksichtigung dieser Hinweise zur Interpretation kann jetzt ein Refinement stattfinden: Verify that all access rights are periodically confirmed. ▼ Refinement innerhalb ICSL Verify that all access rights are periodically confirmed by { Obtain $List of all users from Admin. Sample $List of all users to $[Sample]. For each $User in $[Sample] do { Obtain $Current Access Rights from Access Admin. Obtain $Last Confirmation from Access Admin. Identify any Access Right(s) in $Current Access Rights where that Access Right has: • neither been confirmed in $Last Confirmation, • nor has been granted since the last confirmation, • nor is currently in the process of being revoked, appending to $Exceptions. }. Conclude on Pass if $Exceptions is empty, and on Fail otherwise. }. Die im ‚illustrative Test of Control‘ zu SOX-Control 8.8 geforderte Einschätzung der Angemessenheit der Zeitlichkeiten des Aufräumens kann als weitere Kontrolle modelliert werden. Diese Kontrolle würde die Vorgaben für die Zeitlichkeiten erheben, und diese dann mit einer qualifizierten Einschätzung vergleichen. Ob diese zeitlichen Vorgaben auch tatsächlich eingehalten werden, ist hingegen in obiger Beispielkontrolle noch zu integrieren. Ebenso ist die Sample-Methode genauer zu spezifizieren. An dieser Stelle wurde darauf verzichtet. Auch wird implizit vorausgesetzt, dass nur die Zugriffsrechte für ein gegebenes System untersucht werden. Für mehr als ein einzelnes relevantes System wäre diese Kontrolle von einem übergeordneten Skript aus durchzuführen, dass über die Liste der Systeme iteriert, oder eine Liste der relevanten Systeme müsste direkt im Skript berücksichtigt werden. Grundsätzlich ist beim Refinement zu beachten, dass die Präzisierung entlang einer Abstraktionsachse verläuft, und nicht etwa entlang einer Vervollständigung. Der Refinement-Operator kann nur dazu dienen, vorhandene Teile einer Kontrolle genauer zu fassen, nicht aber, um nicht vorhandene Teile einzufügen. Das Einfügen neuer Teile verändert die Kontrollsemantik, und muss dann auch dementsprechend behandelt werden. 2.2. Historisierung ICSL bietet zudem eine Historisierung der Ausführung von Kontrollen. Die Historisierung von Kontrolläufen ist hilfreich zur Dokumentation und zur Erbringung des Nachweises, dass Kontrollen tatsächlich und ordnungsgemäß durchgeführt worden sind. Zur Historisierung werden die Instruktionen des Skripts im Zuge der Ausführung in eine historische Version überführt, bei der sprachlich vom Imperativ in eine Vergangenheitsform übergegangen wird, und die geforderten Variablen dann mit Inhalten belegt sind. Mit diesem Mechanismus geht aus der Kontrollausführung das Ausführungsprotokoll bzw. der Kontrollreport hervor. Abbildung 5 zeigt exemplarisch eine erfolgreiche Ausführung (Ergebnis: Pass), und einen fehlgeschlagenen Lauf (Ergebnis: Fail), der Handlungsbe383 Der erfolgreiche Fall: Die Kontrolle hat keine Abweichungen identifiziert. The following Control has been performed on Feb. 28th, 2008 with the Result Pass: It has successfully been verified that all access rights are periodically confirmed by { $List of all users has been obtained from Admin A. Smith. $List of all users has been sampled to $[Sample]. For each $User in $[Sample], the following has been performed: { $the Current Access Rights have been obtained from Access Admin B.Miller. $the Last Confirmation has been obtained from Access Admin B.Miller. Any Access Right in $the Current Access Rights have been identified where that Access Right has: — neither been confirmed in $Last Confirmation, — nor has been granted since the last confirmation, — nor is currently in the process of being revoked, appending to $Exceptions. }. It has been concluded on Pass, as no exceptions, and hence no violations of the re-confirmation process have been identified. Der fehlgeschlagene Fall: Die Kontrolle hat Abweichungen aufgedeckt. The following Control has been performed on Jan. 31th, 2008 with the Result Fail: It has not been possible to verify that all access rights are periodically confirmed, for the following reason: 2 users have been detected where the access rights have never been confirmed over the three years of the existence of the accounts. This exceeds the expected re-confirmation period of 3 months. The preliminary reason given by Admin A. Smith is that one user is a technical user, and hence is being excluded from the re-confirmation process, while the second user somehow has left the company and forgotten to be deleted from the user base. See $Exceptions for detailed information on the user ids identified. Abbildung 5: Historische Formen der Beispielkontrolle darf für zwei Benutzerkonten identifiziert hat. Im Beispiel nicht mit aufgeführt ist, dass im fehlgeschlagenen Fall der historische Kontrollauf wie im erfolgreichen Fall zu Dokumentationszwecken ebenfalls enthalten ist. 2.3. Weitere Elemente von ICSL ICSL enthält weitere Ansätze, die über die beschriebenen Grundzüge hinaus gehen: Formulare. Manuelle Kontrollen und ihre Ausführungen werden in der Praxis oftmals durch Formulare und Checklisten abgebildet, und ICSL-Skripte haben durchaus eine Äquivalenz mit Formularen, allerdings sind ICSL-Skripte in der Darstellung kompakter. Bei einer Umsetzung von ICSLSkripten mithilfe interaktiver Webseiten in einem Intranet werden die Übergänge zu WebFormularen fließend. Ebenso ist aber für ICSL ein Formulargenerator für klassische Papierformulare denkbar. Rollen und Qualifikationen. Ein ICSL-Script Instruktionen kann verschiedener Schwierigkeitsgrade enthalten. Diesem Umstand kann Rechnung getragen werden, indem die Instruktionen eines Skriptes mit Rollen annotiert werden, zum Beispiel 'Business Analyst', 'Senior Control Analyst', 'Controller', 'Compliance Manager' (Namen können je nach Umgebung variieren). Hierdurch können die zur Verfügung stehenden Kontrollakteure bezüglich der Qualifikation und Funktion effizienter eingesetzt werden, und es kann der Umstand, dass eine wenig präzise Kontrollbeschreibung eine größere Expertise in der Durchführung erfordert, deutlicher widergespiegelt werden. 384 Delegation. Die Ausführung einzelner Instruktionen in einem Skript kann delegiert werden. Dies ist sinnvoll zur Arbeitsteilung, im speziellen für Iterationen über Listen, die zum Beispiel mehrere Systeme, Ansprechpartner, Abteilungen oder Orte betreffen. Dieser Umstand ist mit der historischen Form einer Kontrolle aufzuzeichnen. Es ist jedoch immer der oder die ursprüngliche Kontrollausführende verantwortlich für die Korrektheit der Durchführung. Management-System. Mit zunehmender Größe des IKS ist es sinnvoll, die Kontrollen mit einem passenden Management-System zu verwalten. In Bezug auf ICSL sind für ein solches System folgende Möglichkeiten zur Einbettung wünschenswert: • Der Entwicklungs- und Reifungsprozess von Kontrollen sollte durch einen angemessenen Lebenszyklus und eine Versionierung unterstützt werden. • Das System sollte die zeitliche Planung der Kontrolldurchführungen und weitere inhaltliche Abhängigkeiten abbilden und umsetzen können. • Das System sollte die historischen Kontrollen zusammen mit den erbrachten Nachweisen archivieren. So kann der korrekte Betrieb des IKS schnell und übersichtlich dargestellt werden. • Das System sollte die Ergebnisse der Kontrollen konsolidieren und für ein ManagementReporting aufbereiten. • Das System sollte eine Wiederverwendung von Nachweisen und Materialien ermöglichen, wenn dies in bezug auf eine Kontrolle möglich und sinnvoll ist. Dies minimiert Störungen durch wiederholtes Beschaffen von Daten bei sonst an den Kontrollen unbeteiligten Datenlieferanten, und minimiert damit Störungen der eigentlichen Geschäftstätigkeiten und Unternehmensabläufe. 3. Abschließende Bemerkungen In diesem Beitrag wurden die Grundzüge der Skriptsprache Internal Controls Scripting Language ICSL zur Formalisierung Interner Kontrollen vorgestellt. ICSL behält dabei die gewohnten Elemente typischer Kontrollbeschreibungen bei und belegt diese mit einer definierten Semantik. ICSL bietet Variablen zur eindeutigen Bezeichnung und durchgängigen Verwendung der Instruktionsobjekte, sowie die für Skriptsprachen typischen Strukturierungselemente, inklusive des Aufrufs externer Skripte. Letztere Möglichkeit erlaubt die Integration anderer, bereits vorhandener Kontrollen. Diese können auch automatisch sein. Der Prozess der Überführung allgemeiner Kontrollanforderungen in die konkrete Realität eines gegebenen Unternehmens wird in seinen Schritten der Anpassung und Verfeinerung durch den Refinement-Operator unterstützt. Dabei erlaubt ICSL eine Balance zwischen der Genauigkeit durch eine hohe Formalisierung einerseits, und den Vorteilen menschlichen Einschätzungs- und Reaktionsvermögens in der Kontrollausführung auch in Anwesenheit von Präzisionsdefiziten in der Spezifikation sowie bei geänderter Kontrollumgebung andererseits. Durch eine Formalisierung interner Kontrollen schafft ICSL eine Voraussetzung zur genaueren Formulierung und Vergleichbarkeit von Kontrollen auch außerhalb eines einzelnen, sehr spezifischen Unternehmenskontextes. Dies kann die Basis sein für einen allgemein verfügbaren Fundus konkreter, interner Kontrollen, zusammen mit der zugehörigen Interpretationsmethodik. Dies ist eine Vorbedingungen für eine Verbesserung der Hilfsmittel zur Entwicklung und Erweiterung eines IKS im Kontext von Compliance. 385 4. Literaturangaben [1] ACL SERVICES LTD., WWW.ACL.COM. [2] AMBERG, M., MOSSANEN, K.., Vorteile und Herausforderungen IT-gestützter Compliance-Erfüllung, Gemeinschaftliche Studie der Universität Erlangen, Lehrstuhl für Wirtschaftinformatik III, und Novell, Inc., 2007. [3] COMMITTEE OF THE SPONSORING ORGANIZATIONS OF THE TREADWAY COMMISSION (COSO) (Eds.), Internal Control – Integrated Framework, 1992. [4] FINANCIAL EXECUTIVES INTERNATIONAL (FEI), FEI Survey: Management Drives Sarbanes-Oxley Compliance Costs Down by 23%, But Auditor Fees Virtually Unchanged, Florham Park, NJ, May 2007. [5] INTERNATIONAL STANDARDIZATION ORGANIZATION, ISO/IEC 27001: Information technology – Security techniques – Information security management systems – Requirements, 2005. [6] INTERNATIONAL STANDARDIZATION ORGANIZATION, ISO/IEC 27002: Information technology – Security techniques – Code of practice for information security management, 2005. [7] IT GOVERNANCE INSTITUTE, CobiT (Control Objectives for Information and Related Technology), Revision 4.1, Rolling Meadows, IL, May 2007. [8] IT GOVERNANCE INSTITUTE, IT Control Objectives for Sarbanes-Oxley: The Role of IT in the Design and Implementation of Internal Control Over Financial Reporting, 2nd Edition, Rolling Meadows, IL, September 2006. [9] KLOTZ, M., DORN, D.-W., IT-Compliance – Begriff, Umfang und relevante Regelwerke, in: Praxis der Wirtschaftsinformatik, HMD Heft 263, dpunkt.verlag, Oktober 2008. [10] LORD, R., The Lord & Benoit Report: Do the Benefits exceed the Costs?, Lord & Benoit, LLC., Worcester, MA, May 2008. [11] MARCHETTI, A.-M., Beyond Sarbanes Oxley Compliance. Effective Enterprise Risk Management, John Wiley & Sons, New Jersey, 2005. [12] MENZIES, C., REIMER, B., et al., Sarbanes-Oxley Act. Professionelles Management Interner Kontrollen, Schäffer Poeschel Verlag Stuttgart, und PriceWaterhouseCoopers, 2004. [13] PCI SECURITY STANDARDS COUNCIL, Payment Card Industry (PCI) Data Security Standard, Version 1.1, Released September 2006. [14] PCI SECURITY STANDARDS COUNCIL, Payment Card Industry (PCI) Data Security Standard: Security Audit Procedures, Version 1.1, Released September 2006. [15] PICALO.ORG, Picalo Data Analysis and Fraud Detection Toolkit: Picalo Manual, Version 3, published on www.picalo.org, 2007. [16] TARANTINO, A., Manager’s Guide to Compliance. Best Practices and Case Studies, John Wiley & Sons, New Jersey, 2006. [17] TRIPATHY, R., Sarbanes-Oxley Tools: Why Do They Fail?, Published on InsideSarbanesOxley.com, 2006. 386 WERTSCHÖPFUNGSNETZWERKE Wertschöpfungsnetzwerke sind seit längerem bekannt, verdanken ihre zunehmende Bedeutung jedoch erst dem Einsatz ausgereifter Informations- und Kommunikationstechnologien. Deren Nutzung kann Transaktionskosten senken und trägt so zu einer wirtschaftlich sinnvollen Zusammenarbeit im Netzwerk bei. Wertschöpfungsnetzwerke gehen weit über die Koordination betrieblicher Aktivitäten hinaus. Der Track widmet sich Strategien, Methoden und Konzepten, die der Gestaltung, dem Aufbau und Betrieb von Wertschöpfungsnetzwerken dienen. Hierbei ergeben sich neue Herausforderungen und Konsequenzen für die Organisation, die Steuerung und das Management der IT. Diese sollen ebenfalls behandelt werden. Neben wissenschaftlichen Beiträgen sind auch fundierte und innovative Beispiele aus der Praxis willkommen. Leitungsgremium: Helmut Krcmar, Technische Universität München Susanne Leist, Universität Regensburg (Federführende) Maria Madlberger, Wirtschaftsuniversität Wien Programmkomitee: Rainer Alt, Universität Leipzig Norbert Gronau, Universität Potsdam Werner Jammernegg, Wirtschaftsuniversität Wien Reinhard Jung, Universität Duisburg-Essen Christian Reichmayr, DAB bank AG Thomas Schnieders, Otto Versand Dorian Selz, local.ch ag Robert Winter, Universität St. Gallen Gregor Zellner, Universität Regensburg IT-GESTÜTZTE WERTSCHÖPFUNGSPARTNERSCHAFTEN ZUR INTEGRATION VON PRODUKTION UND DIENSTLEISTUNG IM MASCHINENUND ANLAGENBAU Philipp Walter1, Nadine Blinn2, Michael Schlicker3, Oliver Thomas1 Kurzfassung Im Maschinen- und Anlagenbau sind Wertschöpfungspartnerschaften ein etabliertes Mittel zur Kostenreduktion und Effizienzsteigerung, indem eine Aufgabenteilung zwischen Herstellern technischer Produkte und herstellerunabhängigen Kundendienstorganisationen stattfindet. Durch Unterbrechungen des Informationsflusses an Unternehmensgrenzen und die dadurch bewirkte Trennung von Produktion und Dienstleistung existieren in Hinblick auf die Gesamtwertschöpfung jedoch umfangreiche Steigerungspotentiale. Im vorliegenden Beitrag werden daher zunächst die Wertschöpfungsketten im Maschinen- und Anlagenbau analysiert und Verbesserungspotentiale identifiziert. Zu ihrer Realisierung wird ein strategischer Lösungsansatz entwickelt, der Produktion und Dienstleistung stärker verknüpft. Er wird in einem Fachkonzept konkretisiert, das an einem Anwendungsbeispiel aus der betrieblichen Praxis expliziert und qualitativ und empirisch evaluiert wird. 1. Einleitung Wertschöpfungspartnerschaften sind im Maschinen- und Anlagenbau ein etabliertes Werkzeug zur Kostenreduktion und Effizienzsteigerung [1, 2] – insbesondere in den Bereichen der Branche, in denen für in Serie gefertigte Produkte über einen großen geografischen Bereich hinweg Kundendienstleistungen erbracht werden. Hier findet traditionell eine Aufgabenteilung zwischen Herstellern und herstellerunabhängigen Kundendienstorganisationen statt, die auch als Wiederverkäufer und als einziger Kontakt zum Kunden agieren. Damit gehen allerdings bis heute Brüche im Informationsfluss entlang der Wertschöpfungskette einher, wodurch Produkt und produktbegleitende Dienstleistungen separiert und dadurch große Wertschöpfungspotentiale unrealisiert bleiben. Ziel dieses Beitrags ist die Konzeption eines Lösungsansatzes zur IT-gestützten Integration von Produktion und produktbegleitenden Dienstleistungen in Wertschöpfungspartnerschaften im Maschinen- und Anlagenbau. Dazu werden nach einer Zusammenfassung des Stands der Forschung 1 Institut für Wirtschaftsinformatik im DFKI, Universität des Saarlandes, Stuhlsatzenhausweg 3, 66123 Saarbrücken. Lehrstuhl für Wirtschaftsinformatik, Universität Hamburg, Von-Melle-Park 9, 20146 Hamburg. 3 INTERACTIVE Software Solutions GmbH, Hochstraße 63, 66115 Saarbrücken. 2 389 (Teil 2) zunächst der Ist-Zustand der Wertschöpfungsketten im Maschinen- und Anlagenbau erfasst, Schwachstellen bzw. Verbesserungspotentiale identifiziert, ein Soll-Zustand in Form eines strategischen Lösungsansatzes abgeleitet und ein Fachkonzept zur IT-Unterstützung dieser Lösung vorgestellt (Teil 3). An einem Anwendungsbeispiel aus der Sanitär-, Heizungs- und Klimatechnikbranche wird die Lösung konkretisiert (Teil 4) und empirisch evaluiert (Teil 5). Der Beitrag schließt mit einem Resümee und einem Ausblick (Teil 6). 2. Stand der Forschung Leistungsbündel aus Sach- und Dienstleistungen werden sowohl aus wissenschaftlicher als auch aus praktischer Sicht zunehmend integriert betrachtet. Verschiedene Wissenschaftsdisziplinen fokussieren dabei jeweils unterschiedliche Aspekte und verwenden dementsprechend eigene Terminologien. Die Wirtschaftsinformatik vereint durch ihren interdisziplinären Charakter die unterschiedlichen Sichten, so dass hier auch eine umfassende Diskussion über die Terminologie geführt wird [3, 4, 5]. Für den vorliegenden Beitrag ist ausschlaggebend, dass Leistungsbündel oftmals nicht von einzelnen Unternehmen erstellt werden, sondern arbeitsteilig von mehreren Partnern in einem Wertschöpfungsnetzwerk. Solche Wertschöpfungsnetzwerke sind bereits Gegenstand umfangreicher wissenschaftlicher Betrachtungen, insbesondere unter dem Aspekt der Koordination [6]. Um die einzelnen Sach- und Dienstleistungskomponenten der Wertschöpfungspartner zu integrieren, ist eine enge Abstimmung mit einem strukturierten Informationsfluss erforderlich. Als Wertschöpfungspartnerschaft wird eine partnerschaftliche Kooperation zwischen Unternehmen bezeichnet, die in aufeinanderfolgenden Stufen der Wertschöpfungskette tätig sind. Somit handelt sich zunächst um eine vertikale Kooperation, die im Allgemeinen für eine längerfristige Dauer angelegt ist [7]. Die Kooperationspartner sind dabei nicht institutionell verknüpft, sondern handeln selbständig und entscheiden sich eigenständig für die Partnerschaft. Die Wertschöpfungspartnerschaft geht über eine vertikale Kooperation insofern hinaus, als dass die Koordination der überbetrieblichen Leistungserstellung von allen Partnern gemeinsam geplant und organisiert wird. Auf diese Weise entsteht nach außen hin eine in sich geschlossene Wettbewerbseinheit [8]. Wertschöpfungspartnerschaften im Maschinen- und Anlagenbau wurden bisher überwiegend unter dem Aspekt des Supply Chain Managements (SCM) in ihrer Ausprägung als Lieferantenkooperation zwischen Herstellern und ihren Zulieferern untersucht [9]. Durch Strategien wie Efficient Consumer Response (ECR) und Maßnahmen wie CRP (Continuous Replenishment), JMI (Jointly Managed Inventory) oder CPFR (Collaborative Planning, Forecasting and Replenishment) sollen vor allem Kosteneinsparungen bei der Herstellung erzielt und an die Kunden weitergegeben werden, um sich so über den Preis von ihren Wettbewerbern zu differenzieren [10]. Ansätze zu Wertschöpfungspartnerschaften auf Absatzseite dagegen erheben den Kunden oft selbst zum Wertschöpfungspartner, z. B. im Rahmen der Kundenintegration und Kundenmitwirkung insbesondere bei der Dienstleistungserstellung [11, 12]. Die Fähigkeit des Kunden, die an ihn ausgelagerten Teilleistungen zu erbringen, kann im Fall technischer Kundendienstleistungen jedoch nicht vorausgesetzt werden: er benötigt eine Gesamtlösung aus technischer Sachleistung sowie produktbegleitenden Kundendienstleistungen. Die wiederverkaufende Kundendienstorganisation bestimmt dabei den Integrationsgrad dieses Leistungsbündels [13]. Vor diesem Hintergrund entstehen derzeit vielfältige neue Geschäftsmodelle, um die Integration von Produktion und Kundendienstleistungen mit Fokus auf den Endkunden voranzutreiben: während klassische Modelle beispielsweise vorsehen, dass der Endkunde Produkt und Kundendienst getrennt erwirbt, wird mit Betreibermodellen und Service Level Agreements (SLA) dem Investitionsrisiko durch ungeplante Störungen und Ausfälle begegnet [14, 15]. 390 Im Hinblick auf die Wertschöpfungskette lassen sich jedoch alle Ansätze in zwei Hauptrichtungen („Make-or-Buy“) klassifizieren: bei einem einstufigen Vertriebsweg betreiben die Hersteller selbst eigene regional begrenzte oder weltweite Servicenetze und gestalten entsprechende Serviceprodukte und -dienstleistungen selbst; bei einem mehrstufigen Vertriebsweg kooperieren Hersteller ohne bundes- oder gar weltweites Servicenetz mit produktunabhängigen Kundendiensten, die gegenüber dem Kunden gleichzeitig als Technischer Kundendienst, Berater und Wiederverkäufer agieren [16]. 3. Integrierte Wertschöpfungspartnerschaften im Maschinen- und Anlagenbau 3.1. Status Quo von Wertschöpfungspartnerschaften in mehrstufigen Vertriebswegen Zur verständlichen Darstellung komplexer Zusammenhänge, wie sie in einer Wertschöpfungspartnerschaft im mehrstufigen Vertriebsweg in Erscheinung treten, hat sich die Systemtheorie als geeignet erwiesen. Abbildung 1 zeigt daher die Wertschöpfungspartner als Systeme und ihre Organisationseinheiten als Subsysteme [17]. Die Umwelt in Form des Marktes bildet dabei den Kontext (gesättigter Markt, steigender Wettbewerbsdruck). Beziehungen zwischen den Systemen und Subsystemen werden im Folgenden auf Informations-, Finanz- und Leistungsflüsse beschränkt. Abbildung 1: Wertschöpfungspartnerschaft im mehrstufigen Vertriebsweg Am Ende der Wertschöpfungskette steht der Endkunde, der ein technisches Produkt inklusive Beratung, Installation und kontinuierlicher Instandhaltung von einer Kundendienstorganisation bezieht. Damit diese die produktbegleitenden Dienstleistungen adäquat ausführen kann, stellt ihr der Hersteller Serviceinformationen zur Verfügung, die in Papierform oder als CD vorliegen können, aber auch Informationsdienstleistungen wie eine Telefonhotline umfassen können. Die interne Wertschöpfungskette des Herstellers entspricht dem Modell von PORTER bzw. der Erweiterung nach TÖPFER [16, 18]. Abgebildet sind nur für die vorliegende Betrachtung relevanten Bestandteile: sie werden als Prozessmodule innerhalb des Systems symbolisiert, das für ihre Ausführung zuständig ist. Neben den primären Funktionen Entwicklung, Produktion und Vertrieb sind dies vor allen der Werkskundendienst und die Qualitätssicherung. Der Werkskundendienst führt Servicearbeiten beim Endkunden in der Regel nur im Gewährleistungsfall oder ausnahmsweise bei Anforderung durch den Endkunden oder einen Wertschöpfungspartner aus, da die produktunabhängigen Kundendienste im Allgemeinen durch die Abdeckung kleinerer Regionen bei größeren Stückzahlen betreuter Produkte günstiger sind. Im Unterschied zu den produktunabhängigen Kundendiensten erlaubt die institutionelle Zugehörigkeit des Werkskundendienstes zum Hersteller 391 jedoch, Beschreibungen von Störungen und Servicearbeiten direkt an die Qualitätssicherung zu übergeben. Diese Informationen aus der Nutzungsphase der Produkte sind von zentraler Bedeutung zur Verbesserung der Produkt- und Dienstleistungsqualität des Herstellers – gängige Methoden zu ihrer Verwertung sind z. B. Total Quality Management (TQM), das Konzept der European Foundation for Quality Management (EFQM), die Fehler-Möglichkeits- und Einflussanalyse (FMEA) oder das Quality Function Deployment (QFD) [19, 20]. 3.2. Herausforderung: mangelnde Integration von Produzenten und Kundendiensten In den gesättigten Märkten des Maschinen- und Anlagenbaus sind signifikante Wettbewerbsvorteile alleine über Preise nicht mehr zu realisieren [21]. Zur Differenzierung von Wettbewerbern konzentrieren sich die Unternehmen daher verstärkt auf den vom Endkunden wahrgenommenen Wert der Gesamtlösung, den sie vor allem durch produktbegleitende Kundendienstleistungen steigern wollen [22, 23]. Die Wertschöpfungspartnerschaft zwischen Herstellern einerseits und eigenständigen, produktunabhängigen Kundendiensten andererseits ermöglicht es dabei, flächendeckenden Kundendienst zu günstigen Preisen anzubieten. Der Informationsaustausch stellt dabei beide Seiten jedoch vor unterschiedliche Herausforderungen. Aus Sicht der Kundendienste ist die Versorgung mit Serviceinformationen durch die hohe Komplexität der Produkte im Maschinen- und Anlagenbau ein kritischer Erfolgsfaktor. Wird z. B. nur ein einzelner Maschinentyp, der durchschnittlich zehn Jahre genutzt wird, in 20 Konfigurationen hergestellt und alle zwei Jahre vom Hersteller überarbeitet, kann ein Kundendienst schon auf 100 unterschiedliche Varianten einer solchen Maschine treffen. Die Multiplikation mit der Gesamtzahl der Maschinentypen aller Hersteller veranschaulicht, dass aktuelle Ansätze diesem hohen Informationsbedarf nicht gerecht werden: vom Hersteller zur Verfügung gestellte Serviceinformationen sind, (unabhängig ob papierbasiert oder elektronisch) statisch und nicht-interaktiv und müssen regelmäßig mit hohem Aufwand aktualisiert werden. Die Frage nach dem richtigen Informationsmix im richtigen Verdichtungsgrad zum richtigen Zeitpunkt bleibt damit unbeantwortet. Aus Sicht der Hersteller ist der dort ebenfalls hohe Aufwand für Erstellung, Verteilung und Pflege der Serviceinformationen bei allen Partnern ebenso unbefriedigend [24]. Schwerer wiegt jedoch, dass die Hersteller ihre Endkunden fast ausschließlich über die produktunabhängigen Kundendienste erreichen, wodurch sie keinen regelmäßigen Zugriff auf Störungs-, Wartungs-, Reparatur- und Betriebsdaten ihrer Produkte haben. Zur Qualitätssicherung können sie sich daher nur auf das Feedback des eigenen Werkskundendiensts stützen (vgl. Abbildung 1), das aber deutlich weniger als 10 % der verfügbaren Informationen abdeckt (vgl. Abschnitt 5). Die beiden zentralen Informationsbestände im Hinblick auf die Integration von Produktion und Kundendienstleistung sind somit einerseits Serviceinformationen des Herstellers, die die Kundendienste benötigen, und andererseits die Informationen aus der Nutzungsphase der Produkte, die für den Hersteller wertvoll sind. Die Autonomie der Akteure behindert dabei den freien Austausch dieser Informationen: während die Informationsflüsse im Falle des einstufigen Vertriebswegs keine Unternehmensgrenzen überschreiten, müssen im Falle des mehrstufigen Vertriebswegs oder bei Mischformen beider Fälle Informationen zwischen den eigenständigen Wertschöpfungspartnern ausgetauscht werden, um die Lösungskomponenten „technisches Produkt“ und „produktbegleitender Kundendienst“ bei der gemeinsamen Leistungserstellung zu integrieren. Qualitätsfehler aufgrund von Informationsdefiziten, seien es Sach- oder Dienstleistungsmängel, schaden allen Wertschöpfungspartnern, nicht nur dem direkten Verursacher [25]. Die Herausforderung besteht somit darin, den Informationsaustausch zwischen den Wertschöpfungspartnern unter Berücksichtigung 392 der ökonomischen Rahmenbedingungen zu steigern und so die Wertschöpfungspartnerschaft durch eine intensivere interne Vernetzung zu stärken. 3.3. Strategischer Lösungsansatz Um eine Lösung der Problemstellung zu erreichen, müssen die Wertschöpfungspartner in das Netzwerk „investieren“, im vorliegenden Fall durch das Anbieten und Tauschen von Informationen mit ihren Partnern [26]. Zur effizienten Realisierung dieses Informationsaustauschs ist eine ITUnterstützung unabdingbar – sie wird im folgenden Teil 3.4 genauer dargestellt. Bezahlung Bezahlung Hersteller Entwicklung Produktion Vertrieb Produktentwicklung Produktion Absatz Dokumentation Technische Produkte Endkunden Installation / Instandhaltung Serviceinformationen Kundendienst Feedbackauswertung Kundenindividuelle Lösung Zusammenstellung Weiterverkauf Technischer Kundendienst Werkskundendienst Qualitätssicherung Produktunabhängige Kundendienste Technischer Kundendienst im Gewährleistungsfall Informationsaustausch Globale Koordination Koordination und Beratung Interne Koordination des Informationsaustauschs Informationsaufbereitung Globaler Portalbetrieb Lokaler Portalbetrieb Koordination und Beratung Feedback Bezahlung Abbildung 2: Erweiterung der Wertschöpfungspartnerschaft um einen Informationsaustausch zwischen Herstellern und den eigenständigen Kundendiensten In der Wertschöpfungskette schlägt sich der institutionalisierte, IT-gestützte Informationsaustausch in der in Abbildung 2 gezeigten Erweiterung nieder. Detaillierte Produkt- und Serviceinformationen werden von den Herstellern in der Regel als hochsensibel und geheimhaltungsbedürftig betrachtet, daher ist eine zentrale, öffentliche Datenhaltung nicht praktikabel. Stattdessen sind interne Organisationseinheiten der Hersteller für den Informationsaustausch zuständig: sie bereiten die Informationen auf, speichern sie und koordinieren ihren Austausch über ein eigenes Portal. Auf diese Weise verlassen sensible Informationen das jeweilige Unternehmen nicht unkontrolliert, sondern werden explizit für ihre automatisierte Distribution sowohl an den eigenen Werkskundendienst als auch an die produktunabhängigen Kundendienste ausgewählt und vorbereitet. Dieser Schritt umfasst ihre Aggregation und ihre Konvertierung in miteinander verknüpften Produkt- und Prozessmodelle. Diese sind sowohl geeignet, den Kundendienst mobil vor Ort beim Endkunden interaktiv und bedarfsgenau zu unterstützen, als auch die Grundlage für ein strukturiertes Feedback über Störungen und vorgenommene Kundendienstarbeiten an den Hersteller. Im Gegensatz zur Wertschöpfungskette aus Abbildung 1 können so (a) die Kundendienstmitarbeiter mobil, bedarfsgerecht, und effizient mit exakten Serviceinformationen direkt vom Hersteller versorgt werden, und (b) die bisher brachliegenden Informationen über Serviceeinsätze der produktunabhängigen Kundendienste in den Weiterentwicklungszyklus beim Hersteller einfließen. 393 Zur zentralen Koordination der verteilten Herstellerportale und des Netzwerks ist eine unabhängige Organisation vorgesehen, die auch Beratungsleistungen für die Hersteller in Zusammenhang mit Aufbau und Betrieb ihrer Portale erbringt. Ferner konsolidiert sie die verteilten Portale, indem sie als zentraler Anlaufpunkt für die produktunabhängigen Kundendienste fungiert und sie transparent zu den jeweils benötigten Informationen weiterleitet. 3.4. Architektur des Informationssystems Abbildung 3 zeigt die verteilte IT-Architektur zur Umsetzung des Lösungsansatzes. Den Kunden- diensten, d. h. sowohl den Werks- als auch den produktunabhängigen Kundendiensten, steht als Schnittstelle zum System ein mobiles, internetbasiertes Anwendungssystem zur Verfügung. Bei Bedarf nach Serviceinformationen nutzt der Kundendiensttechniker dieses System, um seine Anfrage zunächst an den globalen Portalserver zu richten, der den Techniker zum zuständigen Herstellerportal transparent weiter verbindet. Auf diese Weise haben die Kundendienste eine zentrale Anlaufstelle und müssen Änderungen am verfügbaren Informationsbestand nicht selbst mitverfolgen, so dass die Clientsoftware entsprechend schlank ausfallen kann. Der Portalserver dient dabei nicht als Broker im Sinne serviceorientierter Architekturen (SOA), sondern ermöglicht in erster Linie die nach Hersteller separierte Speicherung sensibler Produkt-, Service- und Feedbackdaten. Abbildung 3: IT-Architektur zur Unterstützung des Informationsaustauschs in der Wertschöpfungspartnerschaft Beim Hersteller wird die Anfrage in einem Dialog zwischen anfragendem Techniker und dem eigenen Portal bearbeitet, das dazu über eine zentrale Datenbank mit allen Serviceinformationen verfügt, die der Hersteller anbietet. Der Techniker wird schrittweise durch den Serviceprozess geführt und in jedem Prozessschritt mit den für ihn relevanten Herstellerinformationen versorgt. Durch die Benutzung des mobilen Systems werden Daten der bearbeiteten Anlage und die an ihr durchgeführten Maßnahmen automatisch erfasst, als strukturiertes Feedback vom Portal entgegengenommen und in einer separaten Feedback-Datenbank gespeichert. Dieser Informationsaustausch stellt die Realisierung der oben skizzierte Win-Win-Situation zwischen Herstellern und Kundendiensten dar: der Kundendienst erhält wertvolle Informationen, die seine Arbeit erleichtern, beschleunigen und 394 qualitativ verbessern, wofür er wiederum dem Hersteller wertvolle Informationen aus der Nutzungsphase seiner Produkte überlässt. Vom zufriedenen Endkunden profitieren beide Partner. Zwischen der Serviceinformations- und der Feedback-Datenbank besteht ein herstellerspezifischer Kreislauf, der exemplarisch durch die Schritte der herstellerinternen Wertschöpfungskette symbolisiert ist. So werden von der Organisationseinheit, die das Portal und den Informationsaustausch betreut, die Feedbackdaten aufbereitet und der Qualitätssicherung übergeben, die sie wiederum in die Weiterentwicklung und Dokumentation einfließen lässt. Dabei werden nicht nur die technischen Produkte, sondern auch die Serviceinformationen selbst weiterentwickelt. Aus Datensicht existieren zwei zentrale Informationstypen (vgl. 3.2). Serviceinformationen können aus Text, Bildern, Arbeitsbeschreibungen, etc. bestehen, die um Prozessmodelle von Serviceprozessen angeordnet und einzelnen Prozessschritten zugeordnet werden können. Feedbackinformationen umfassen neben Anlagendaten auch die durchgeführten Arbeitsschritte, die jeweils erzielten Zwischenergebnisse sowie ggf. Bewertungen der Qualität der Serviceinformationen selbst. 4. Anwendungsszenario Ein idealtypischer Vertreter des Maschinen- und Anlagenbaus mit mehrstufigem Vertriebsweg ist die Sanitär-, Heizungs- und Klimatechnikbranche (SHK). Die Komplexität der hier hergestellten Produkte reicht von einfachen mechanischen Geräten, z. B. Druckausgleichsbehältern, bis hin zu komplexen mechatronischen Einzelgeräten, die zu großen Wärme- und Elektrizitätserzeugungsanlagen kombiniert werden. Der Kundendienst der SHK-Branche wird überwiegend von rund 50.000 kleinen und mittelständischen Fachhandwerksbetrieben erbracht, die aus den in Serie hergestellten technischen SHK-Produkten kundenindividuelle Lösungen entwickeln, zusammenstellen, installieren und instand halten. Sie bilden so bundesweit ein dichtes SHK-Versorgungsnetz für Produkte aller Hersteller und haben 2007 einen Jahresumsatz von 24,4 Mrd. Euro erwirtschaftet [27]. Im Verbundforschungsprojekt PIPE wird das dargestellte Wertschöpfungsnetzwerk prototypisch umgesetzt [28]. Die hier entwickelten Methoden und Softwarekomponenten unterstützen die effiziente Erhebung von Serviceinformationen („Informationsaufbereitung“ in Abbildung 2), ihre Modellierung und Bereitstellung, die mobile Kundendienstunterstützung sowie das strukturierte Feedback. Ein in PIPE prototypisch abgebildeter Serviceprozess entfaltet sich um das Fehlerbild einer Fehlermeldung bei der Selbstdiagnose eines Gasheizgeräts: mit der Fehleranzeige „Fehler F.0“ weist die Software des Geräts darauf hin, dass eine Störung vorliegt, und unterbindet aus Sicherheitsgründen den weiteren Betrieb. Die zur Diagnose und Behebung dieser Störung durchzuführenden Arbeitsschritte wurden als Serviceprozess modelliert. Ein Kundendiensttechniker kann daher mithilfe des beschriebenen mobilen Anwendungssystems vor Ort am Gerät Hersteller, Typ, Seriennummer und Fehlerbild erfassen und wird direkt vom Herstellerportal mit Informationen zu dem Fehler („Unterbrechung Vorlauf-NTC-Temperaturfühler“) und den Schritten zu seiner Behebung versorgt. Bei der schrittweise ausgeführten Fehlerdiagnose stellt sich dann heraus, dass der Temperaturfühler selbst einwandfrei ist und eine Beschädigung des Verbindungskabels zwischen Leiterplatte und Fühler die Fehlermeldung auslöst. Durch die direkte Verfügbarkeit der Ersatzteildaten kann der Techniker das Kabel schnell beschaffen und ersetzen – teilt der Kunde bei Auftragserteilung den Fehlercode direkt mit, kann der Techniker das Kabel sogar vorausschauend mitführen. Die bei der schrittweisen Ausführung des Serviceprozesses gesammelten Daten (Geräteidentifikation, Typ, Baujahr, defektes Bauteil, durchgeführte Arbeitsschritte) werden anonymisiert über das Herstellerportal in die Feedbackdatenbank übernommen. Die Qualitätssicherung des Herstellers kann die Informationen nutzen, um z. B. bei Häufung einer bestimmten Störung die Gerätekonstruktion anzupassen, oder bei Verzögerungen in der Abarbeitung von Serviceprozessen deren Ab395 lauf zu straffen oder ihre Beschreibung zu verbessern. Änderungen an Produkten, deren Dokumentation oder den Serviceinformationen werden direkt von der mit der Koordination des Informationsaustauschs betrauten Organisationseinheit aufbereitet und zeitnah durch eine Aktualisierung der Serviceinformationsdatenbank den Wertschöpfungspartnern zur Verfügung gestellt. 5. Evaluation des Anwendungsszenarios Der vorgestellte Lösungsansatz wird sowohl unter dem Aspekt des Nutzenzuwachses, der von ihm generiert wird, als auch unter dem Aspekt der praktischen Relevanz evaluiert. Den Nutzen des Systems veranschaulicht Abbildung 4 anhand von vier qualitativen Merkmalen, die sich durch die Intensivierung des Informationsaustauschs in der Wertschöpfungspartnerschaft verändern. Der Grad des Informationsaustauschs (rechte Achse) zwischen den Partnern betrifft Menge und Umfang der Serviceinformationen für die Kundendienstorganisationen einerseits sowie der Informationen über durchgeführte Servicearbeiten für den Hersteller andererseits. Je umfangreicher der Austausch, umso stärker wirken sich die Informationen auf die Produkt- und Servicequalität aus (obere Achse). Die Kurve des Qualitätszuwachses flacht dabei mit steigender Informationsmenge ab, da nach und nach eine Informationssättigung eintritt. Der Aufwand, der den Wertschöpfungspartnern zur Errichtung und Aufrechterhaltung der Kooperation entsteht (untere Achse), hängt ebenfalls unterproportional vom Grad des Informationsaustauschs ab: die Schaffung der organisatorischen und informationstechnischen Voraussetzungen zum Informationsaustausch bleiben zunächst unabhängig von der Nutzungsintensität fix. Der Umfang der Nutzung dieser Infrastruktur trägt kaum zum Aufwand bei, so dass der Unterschied zwischen einer einfachen und einer intensiven Partnerschaft aufwandsseitig nur marginal ist. Abbildung 4: Implikationen der Intensivierung der Wertschöpfungspartnerschaft Auf der linken Achse wird der Nutzen der verschiedenen Wertschöpfungspartnerschaften für den Endkunden von den bisher genannten qualitativen Größen abgeleitet. Er hängt direkt von der Produkt- und Servicequalität ab, daher wird im linken oberen Quadrant eine lineare Beziehung symbolisiert. So ergibt sich im unteren linken Quadrant eine Kosten-Nutzen-Abschätzung, die verdeutlicht, dass der Kundennutzen überproportional zum Aufwand wächst, wobei zu beachten ist, dass hier (a) eine qualitative Abschätzung vorliegt, d. h. die Effekte zwar zu erwarten, aber noch nicht quantifizierbar sind, und (b) der Nutzen nicht unbegrenzt wachsen kann, da auch der Intensivierung 396 des Informationsaustauschs Grenzen gesetzt sind. Setzt man einen direkten Zusammenhang zwischen Kundennutzen, Kundenzufriedenheit und ökonomischem Erfolg der Wertschöpfungspartner voraus, leiten sich daraus zwei Schlussfolgerungen ab: 1. 2. Auch ein geringgradiger Informationsaustausch führt bereits zu einem deutlichen Nutzenzuwachs. Eine weitere Intensivierung des Austauschs stiftet überproportional viel Zusatznutzen. Im Hinblick auf den Transfer in die Praxis wurde die in PIPE entwickelte Lösung zunächst auf Kundendienstseite im Rahmen einer 2007 bundesweit durchgeführten empirischen Erhebung in der SHK-Branche unter Einbeziehung sowohl von Werks- als auch produktunabhängigen Kundendiensten evaluiert (N=129). Dazu wurden die aktuelle Situation im Technischen Kundendienst hinsichtlich verfügbarer Hilfsmittel und deren Nutzung erfasst, Anforderungen an eine mobile, interaktive Lösung wie die in PIPE konzipierte erhoben und der generelle Bedarf nach einer solchen Lösung explizit erfragt. Abbildung 5 zeigt zwei Teilergebnisse: zwar werden die schon verfügbaren Hilfsmitteln – auch IT-basierte, z. B. digitale Ersatzteilkataloge (ETK) – genutzt, das Interesse an einem mobilen Anwendungssystem wie dem hier dargestellten ist aber sehr hoch. 68% Anleitungen papierbasiert "Würden Sie das Informationswerkzeug einsetzen wollen?" Ziemlich wahrscheinlich: 42% 61% ETK auf Papier 56% ETK digital im Büro Vielleicht: 22% 53% Serviceordner 49% Hersteller-Hotline 46% Diagnose-/Fehlergeräte Wahrscheinlich nicht: 1% 44% Telefonate mit Kollegen 40% Hersteller-Website Ganz sicher: 35% 32% Anleitungen elektronisch 16% ETK digital unterwegs 0% 25% 50% 75% 100% Häufigkeit der Nutzung Abbildung 5: Nutzung von vorhandenen papier- und IT-basierten Hilfsmitteln und Wunsch nach einem prozessorientierten, mobilen Informationssystem im TKD der SHK-Branche In Experteninterviews haben sich auch auf Herstellerseite zurzeit noch ungedeckte Informationsbedarfe ergeben. So ermöglicht die Aufgabenteilung entlang der Wertschöpfungskette den SHKHerstellern zwar eine Konzentration auf ihre Kernkompetenzen, nämlich das Management ihres Zuliefernetzwerks sowie die Entwicklung und Herstellung technischer Geräte, schneidet sie aber informationstechnisch von der Nutzung der Produkte ab. Die hier anfallenden Informationen über konstruktive und servicetechnische Verbesserungspotentiale ihrer Produkte erreichen die Hersteller höchstens fragmentarisch über den Werkskundendienst bzw. über unregelmäßige und unstrukturierte Kommunikation mit den Kundendienstorganisationen, so dass auch hier die Entwicklung der dargestellten Lösung mit großem Interesse verfolgt wird. 6. Zusammenfassung und Ausblick Im vorliegenden Beitrag wurden auf Basis einer Analyse der Wertschöpfungsketten im Maschinenund Anlagenbau Verbesserungspotentiale insbesondere in Hinblick auf den unternehmensübergrei397 fenden Informationsfluss im Wertschöpfungsnetzwerk identifiziert. Daraus wurde zunächst eine Lösungsstrategie entwickelt, die in einer fachkonzeptionellen IT-Architektur konkretisiert und anhand eines Anwendungsbeispiels aus der betrieblichen Praxis veranschaulicht wurde. Zentraler Aspekt ist dabei der koordinierte, IT-gestützte Austausch von Informationen entlang der Wertschöpfungskette. Die abschließend skizzierte Evaluation des dargestellten Konzepts deutet darauf hin, dass der Lösungsansatz auf große Nachfrage stößt. Seine prototypische Umsetzung ist Gegenstand des Verbundforschungsprojekts PIPE und nähert sich derzeit der Fertigstellung. 7. Literaturangaben – Literaturhinweise [1] KLOSTERMANN, T., Optimierung kooperativer Dienstleistungen im Technischen Kundendienst des Maschinenbaus, Wiesbaden 2007. [2] TATARYNOWICZ, A., On Firms in Networks, St. Gallen 2008. [3] LEIMEISTER, J., GLAUNER, C., Hybride Produkte – Einordnung und Herausforderungen für die Wirtschaftsinformatik, in: Wirtschaftsinformatik. Bd. 50 (2008) 3, S. 248–251. [4] THOMAS, O., WALTER, P., LOOS, P., Product-Service Systems: Konstruktion und Anwendung einer Entwicklungsmethodik, in: Wirtschaftsinformatik. Bd. 50 (2008) 3, S. 208–219. [5] BÖHMANN, T. , KRCMAR, H., Hybride Produkte : Merkmale und Herausforderungen, in: M. Bruhn, B. Stauss (Hrsg.), Wertschöpfungsprozesse bei Dienstleistungen, Wiesbaden 2007. [6] BÖHMANN, T. , KRCMAR, H., Komplexitätsmanagement als Herausforderung hybrider Wertschöpfung im Netzwerk, in: F. Wojda, A. Barth (Hrsg.), Innovative Kooperationsnetzwerke, Wiesbaden 2006. [7] LAPIEDRA, R. et al., Role of Information systems on the business network formation process: an empirical analysis of the automotive sector, in: Journal of Enterprise Information Management. Bd. 17 (2004) 3, S. 219–228. [8] HÖFER, S., ZP-Stichwort: Wertschöpfungspartnerschaft, in: Zeitschrift für Planung. Bd. 7 (1996) 3, S. 303–307. [9] WERNER, H., Supply Chain Management : Grundlagen, Strategien, Instrumente und Controlling, Wiesbaden 2008. [10] HERTEL, J., ZENTES, J., SCHRAMM-KLEIN, H., Supply-Chain-Management und Warenwirtschaftssysteme im Handel, Berlin et al. 2005. [11] POZNANSKI, S., Wertschöpfung durch Kundenintegration : eine empirische Untersuchung am Beispiel von Strukturierten Finanzierungen, Wiesbaden 2007. [12] HERMES, P., Entwicklung eines Customer Self-Service-Systems im technischen Kundendienst des Maschinenbaus, Heimsheim 1999. [13] ENGELHARDT, W. H., KLEINALTENKAMP, M., RECKENFELDERBÄUMER, M., Leistungsbündel als Absatzobjekte : ein Ansatz zur Überwindung der Dichotomie von Sach- und Dienstleistungen, in: Schmalenbachs Zeitschrift für betriebswirtschaftliche Forschung. Bd. 45 (1993) 5, S. 395– 426. [14] SYSKA, A., Produktionsmanagement : Das A-Z wichtiger Methoden und Konzepte für die Produktion von heute, Wiesbaden 2006. [15] BAADER, A., MONTANUS, S., SFAT, R., After Sales Services : mit produktbegleitenden Dienstleistungen profitabel wachsen, in: K. Barkawi, A. Baader, S. Montanus (Hrsg.), Erfolgreich mit After Sales Services, Berlin 2006. [16] TÖPFER, A., Betriebswirtschaftslehre : anwendungs- und prozessorientierte Grundlagen, Berlin et al. 2007. [17] VAN BERTALANFFY, L., General System Theory : Foundations, Development, Applications, New York 2001. [18] PORTER, M.E., Wettbewerbsvorteile : Spitzenleistungen erreichen und behaupten, Frankfurt am Main 2000. [19] PAHL, G., BEITZ, W., FELDHUSEN, J., GROTE, K., Konstruktionslehre, Berlin 2007. [20] GEIGER, W., KOTTE, W., Handbuch Qualität, Wiesbaden 2008. [21] LINDEMANN, U. , BAUMBERGER, G. C., Individualisierte Produkte, in: U. Lindemann, R. Reichwald, M. F. Zäh (Hrsg.), Individualisierte Produkte : Komplexität beherrschen in Entwicklung und Produktion, Berlin 2006. [22] STILLE, F., Produktbegleitende Dienstleistungen gewinnen weiter an Bedeutung, in: Wochenberichte des DIW Berlin. Bd. 70 (2003) 21, S. 335–342. [23] TULI, K. R., KOHLI, A. K., BHARADWAJ, S. G., Rethinking Customer Solutions: From Product Bundles to Relational Processes, in: Journal of Marketing. Bd. 71 (2007) 3, S. 1–17. [24] CÄSAR, M.A., Service-Portale in Industrieunternehmen, Bamberg 2005. [25] DAUBEN, S.A., Qualitätsfehlercontrolling für Dienstleistungen im Investitionsgüterbereich : das Beispiel technischer Kundendienst, Wiesbaden 2001. [26] JARILLO, J. C., On Strategic Networks, in: Strategic Management Journal. Bd. 9 (1988) 1, S. 31– 41. [27] ZENTRALVERBAND SHK DEUTSCHLAND, Jahresbericht 2008, St. Augustin 2008. [28] PIPE, Hybride Wertschöpfung im Maschinen- und Anlagenbau, Saarbrücken 2008. PIPE wird vom Bundesministerium für Bildung und Forschung (BMBF) im Rahmen des Förderkonzepts „Innovation mit Dienstleistungen“ gefördert (Förderkennzeichen 01FD0623 und folgende). 398 VERTICAL INTEGRATION AND INFORMATION SHARING – AN EMPIRICAL INVESTIGATION IN THE GERMAN APPAREL INDUSTRY Christoph Goebel, Hanna Krasnova, Henning Syllwasschy, Oliver Günther1 Abstract Despite the astounding success of the fast fashion retailers, the management practices leading to these results have not been subject to extensive research so far. Given this background, we analyze the impact of information sharing and vertical integration on the performance of 51 German apparel companies. We find that the positive impact of vertical integration is mediated by information sharing, i.e. that the ability to improve the information flow is a key success factor of vertically integrated apparel supply chains. Thus, the success of an expansion strategy based on vertical integration critically depends on effective ways to share logistical information. 1. Introduction The astounding success of fast fashion retailers such as Zara and H&M is attracting the attention of the fashion industry worldwide. The triumph of these companies, expressed in 2-digit margins and constant growth, is tightly connected to the implementation of a supply chain strategy optimally aligned with consumer needs: quickly changing demand for fashion is translated into products at a reasonable price. Attracted by their success, many apparel companies currently try to mimic fast fashion practices. For some of them, improving supply chain performance is even a matter of survival: traditional clothing retailers, including major department store chains such as Galeria Kaufhof in Germany are suffering from steadily shrinking margins in their apparel business. The main reason for this development is the apparent inability of traditional retailers to satisfy current consumer wishes with respect to fashion and pricing. On the one hand, consumers increasingly long for choice and are becoming more fashion-savvy. A recent article of ‘The Economist’ [30] confirms the views of many fashion executives who feel a constant pressure to quickly pick up the latest trends and immediately supply clothing that adheres to them. On the other hand, consumers behave highly price sensitive when it comes to spending money on apparel. This is documented by the share of household income spent on apparel and footwear which has steadily declined in recent years [7]. The EU and U.S. consumer price indices for these product categories speak a similar language: they lag behind the average price index for consumer goods [7][31]. One of the key strategic questions in today’s apparel business is which building blocks of the fast fashion strategy should be adopted in order to improve performance. Thus, management practices 1 Humboldt-Universität zu Berlin, Germany 399 and organizational configurations that have a significant effect on firm performance have to be identified. A closer look at the management practices and organizational features of fast fashion retailers reveals at least two differences compared to traditional retailers: vertical integration and intensive information sharing between the manufacturing and retailing stage of the supply chain. In the traditional apparel supply chain, brand manufacturers are responsible for the design and manufacturing of products, whereas specialized retailers are responsible for selling the garments to the consumers. This task division has the advantage that each company can concentrate on their core competencies: while brand manufacturers apply their design and production know-how, retailers use their marketing expertise for presenting and selling different brands. In sharp contrast to this, the typical fast fashion company distributes its own brand all by itself. For this purpose it either operates its own stores or uses a distribution model based on concessions or franchising. Ferdows et al. [9] claim that the vertical integration of industry champions like Zara and H&M and the resulting control over the distribution process represents the key for their tremendous success. Vertical integration certainly plays a role in the fast fashion success formula. We hypothesize that it is rather an enabler for value generating management practices rather than a cause for superior performance by itself. In particular, companies that control the entire distribution process of their brand are able to access all relevant data related to the production and distribution of their products and thus have an informational advantage. Our interviews with industry insiders as well as earlier case study research support this hypothesis. For instance, Zara’s global store network can be conceived as a giant data collection device. The POS data is transmitted by hundreds of stores to the headquarters on a daily basis. This information enables detailed sales trend analyses as well as triggers design and production processes without any delay [13]. This of course is only possible when taking advantage of modern information technology [9][25]. In this paper, we investigate the impact of vertical integration and information sharing practices on the performance of apparel supply chains. In particular, we focus on the relationship between the degrees of control that brand manufacturers are able to exert over the distribution of their products and the intensity of information sharing between the production and distribution part of the supply chain. Our central hypothesis is that vertical integration is positively related to performance partly because it enables more intensive information sharing along the supply chain. We test our hypotheses using a data sample from the German apparel industry. In Section 2 we provide an overview of related literature. Our hypotheses and a conceptual model are presented in Section 3. In Section 4 we describe the employed methodology and the results of an empirical study in the German apparel industry. Section 5 discusses managerial implications of our work. Section 6 concludes. 2. Related Work Apparel supply chains are a popular topic in operations management research because the demand for fashionable apparel is usually highly uncertain, which calls for effective measures to cope with the resulting risk of over- and underage [22]. Fisher et al. [10] were the first to analytically show the positive effect of using the information on early sales to improve the accuracy of forecasts. A meanwhile well-known case study at Sport Obermeyer has demonstrated that the ‘accurate response’ technique truly works [11]. More recent case studies on supply chains and strategies in the apparel sector reveal the increasing influence of agile thinking in the business, mainly inspired by the success of fast fashion retailers [9][19]. 400 Vertical integration is usually equated with the concentration of ownership of facilities and assets along the supply chain in the hands of a single organization. Zara for instance can be considered as an almost fully vertically integrated apparel company since they own manufacturing and distribution facilities as well as a dedicated store network [9]. Richardson [27] analyses the advantages and disadvantages of vertical integration in the apparel sector. He sees its main drawback in the risk of exclusion from an efficient buyer market. Thus, vertical integration can impede the optimal allocation of the resources, which depends on the competition in corresponding markets (production, warehousing, transportation, retailing etc.) combined with the superior expertise of the specialized manufacturers, logistics providers and retailers. He explains the apparent success of vertically integrated fashion companies like Zara by observing that vertical integration facilitates quick response strategies. Vertical integration, he argues, enables these organizations to link design and production closely to retailing which makes them more responsive. The benefits of fast and accurate transmission of demand information along the supply chain have been shown by various authors [23][33]. We contribute to this research by considering the impact of vertical integration on this relationship. To the best of our knowledge, no study of this kind has been attempted so far. 3. Hypotheses and Conceptual Model Our conceptual model is made up of four interdependent hypotheses referring to three conceptual concepts. These concepts are Vertical Forward Integration (VFI), Intensity of Information Sharing (IIS), and Performance of Brand Owner (PBO). The exact meaning of these concepts as well as our hypotheses will be described in the following. The impact of information sharing on the business performance has been tested in various empirical studies (e.g. [23][33]), albeit not in our specific context. Based on their case study at Zara, Ferdows et al. [9] claim that intensive information sharing is particularly important in apparel supply chains since these have to cope with highly uncertain demand. We therefore hypothesize that: (H1) the intensity of the Information Sharing between the brand owner and the retailers is positively related to the Performance of the Brand Owner. Our second and third hypotheses refer to the impact of vertical integration. Richardson [27] considers a firm as vertically integrated if it owns assets, organizes activity, or controls activities in successive stages of the value chain. We focus on a special type of vertical integration, namely the Vertical Forward Integration of brand owners. Vertical Forward Integration refers to all measures taken by the brand owner to increase the control over the distribution channel including the acquisition of facilities and assets. This definition is in line with the common understanding of this term across industry (see [15]). Whereas Zara or H&M certainly mark an extreme of the vertical integration scale, most brand owners are somewhere in between, i.e. they neither own all points of sale nor do they act like the traditional clothing wholesaler who exerts no influence on sales operations at all. The positive connection between Vertical Forward Integration and Performance in the apparel sector is intensively discussed by Richardson [27], although not tested statistically. Extending his study we hypothesize that: (H2) Vertical Forward Integration is positively related to the Performance of the Brand Owners. A basic result of agency theory predicts that in situations when exchanges are characterized by uncertainty over inputs, infrequent exchange, and the need for transaction specific investments, 401 vertical integration can be efficient. This is because vertical integration reduces the incentives for information hiding and misrepresentation [14]. Here, the tradeoff is between improved information and reduced performance incentives. The assumption of uncertainty is certainly applicable to the apparel sector, where the demand is very uncertain. In line with this finding, information systems and information sharing processes can certainly be implemented more easily within one company than between several different companies. We can therefore hypothesize that: (H3) Vertical Forward Integration is positively related to the Intensity of Information Sharing between the apparel brand owner and the retailers. Figure 1. The conceptual model Hypothesis 4 summarizes the relationships described above (H1-H3) and is central for our work. It tests the assumption that vertical integration per se is an important but not a sufficient condition of the success of the brand owner. In other words, we assume that that the positive influence of vertical integration in the apparel industry is largely due to the improved information flow it enables. We therefore hypothesize that: (H4) the expected positive influence of the Vertical Forward Integration on the Performance of the Brand Owners is mediated by the Intensity of the Information Sharing between the apparel brand owner and the retailers. Figure 1 summarizes the hypotheses (H1, H2, H3) into a conceptual model (Model A). Additionally, in order to prove hypothesis H4, Model B, consisting of a simple direct link from the Vertical Forward Integration to the Performance of the Brand Owners, is tested as explained in Section 4.3. 4. Empirical Study 4.1 Survey Design and Sampling We developed a survey instrument which aimed to capture the Vertical Forward Integration, Intensity of Information Sharing, and the Performance of the Brand Owner constructs as well as some descriptive statistics. In the forefront of the survey several industry experts and representatives were interviewed, partly in person, partly over the phone. The interviews served for gaining a better understanding of the drivers of the current vertical integration trend in the apparel industry as well as to fulfil formal requirements. In particular, the survey questions were discussed one by one to ensure the content validity of the measured constructs. This procedure also ensured 402 that the terms used in the survey were clear and equally interpreted by the practitioners. As a second step, general contact details and company descriptions of 440 medium and large-sized apparel companies operating in Germany were extracted from various publicly available databases. After eliminating the companies which didn’t match the research objectives (e.g. company turnover), 350 companies were contacted by phone in order to identify a competent contact person (usually the head of logistics or marketing). Finally, 307 verified contacts were asked for participation in a standardized online questionnaire per mail and phone. The data collection effort resulted in 88 answered questionnaires out of which 51 were usable. Thus, the response rate was 16.6%. The survey was conducted in an anonymous manner to encourage participants to honestly answer the questions. Data collection took place from January until April 2008. In order to evaluate the representativeness of the sample, we analyzed its distribution with respect to four basic company profile indicators: size of revenue, number of employees, product life cycle, and price segment of goods sold as shown in Table 1. None of the four indicators exhibits any unexpected concentration. According to the opinion of interviewed fashion executives, the sample represents the brand owner side of the German apparel industry fairly well. Additional sample profiling data can be obtained from the authors upon request. Table 1. Sample characteristics Revenues in mln. Euro % of companies Employees % of companies <50 50 - 100 100 - 200 >200 18.6% 34.9% 18.6% 27.9% <200 200 -500 500 -1,000 >1,000 28.3% 41.3% 10.9% 19.6% No of assortments per year 1-2 3-4 >4 % of companies Pricing Segment % of companies 23.4% 40.4% 36.2% lower price medium price high price 14.6% 60.4% 25% 4.2 Measurement Scales The three constructs which our hypotheses are based on – Vertical Forward Integration, Intensity of Information Sharing, and the Performance of the Brand Owner – were measured using multiple indicators. These indicators formed the corresponding measurement scales. In accordance with our definition of Vertical Forward Integration, the items we used to operationalize the corresponding conceptual construct reflect the degree of control exerted by the brand owner over distribution activities of the retailers as well as the degree of vertical forward integration of the brand owner in terms of assets and facilities. The items measuring the control over the distribution process were adopted from the work of Etgar [8]. These items were complimented by the self-developed scales for asset and facility possession. The scales used to measure the Intensity of Information Sharing construct were adopted from the work of Li and Lin [23]. They cover completeness, detail, timeliness, and reliability of the information sharing activities between the retailers or POSs and the brand owner. Not surprisingly, company performance has been measured many times before; thus there exists an abundance of tested scales in the literature. The items of the Performance construct were drawn from the pool of the already available items of Bhatnagar and Sohal [3], Mattila et al. [24], and Hallén et al. [17]. All metrics were chosen keeping the targeted industry in mind but are sufficiently general to allow for comparability. 4.3 Statistical Methodology The purpose of the statistical analysis is to explain the links between exogenous and endogenous variables. In our conceptual model, these are the constructs Vertical Forward Integration, Intensity of Information Sharing and Performance of the Brand Owner. None of these so-called latent 403 variables can be observed directly but are measured by indicators (measurement scales). The relationship of the latent variables and the indicators is specified by the Measurement Model. The overall model which includes the defined relationships between the latent variables reflecting the hypotheses is called Structural Equation Model (SEM). Estimation of the SEMs can be done on the basis of two different methodologies: analysis of covariance [16] or the analysis of variance [32]. The latter is also referred to as the Partial Least Squares (PLS) approach. In this study we evaluate our model using the PLS approach for several specific reasons. First, PLS methodology is a preferred option when the theory behind the model is not strong [12]. Taking into account the novelty of our research terrain PLS was a straightforward choice. Second, as opposed to the covariance-based approach, the PLS does not place very high sample size constraints. Barclay et al. [2] mention the rule of thumb that the required sample size for using PLS has to be at least ten times the number of exogenous constructs having an impact on the most complex endogenous construct which amounts to a minimum of 20 observations in our case. With 51 observations this criterion was easily fulfilled. All calculations were carried out using SmartPLS version 2.0.M3, a statistical package developed for the estimation of SEMs using the PLS approach [28]. As proposed by Chin [6], evaluation of the structural equation model is done in two steps. First, the statistically measurable validity of the measurement model is tested. Thereafter, the structural model is evaluated. This procedure allows us to test hypotheses H1, H2 and H3. Furthermore we evaluate the mediation effect of the Intensity of Information Sharing variable (H4), i.e. whether the positive impact of vertical forward integration on performance can be explained by a higher degree of information sharing enabled by it. This mediation effect is tested based on the approach outlined by Baron and Kenny [4][18]. Thus, a simple model (Model B) with a direct causal link from the VFI construct to the PBO construct is additionally evaluated. The mediation effect exists if the significant VFI Æ PBO path in Model B becomes insignificant once the mediator variable (IIS) is integrated into the model (Model A) [4][18]. 4.4 Evaluation of the Measurement Model According to the standard validation procedure, the evaluation of the measurement model comprises the evaluation of the Convergent and Discriminant Validity. The criteria used to test the Convergent Validity are the Indicator Reliability of the chosen items, the Composite Reliability and the Average Variance Extracted (AVE) for each latent variable, and Cronbach’s Alpha. In order to test hypothesis H4, two models (Model A and Model B) are evaluated. In order to assure Indicator Reliability, each latent variable should be accountable for at least 50 percent of the variance of the corresponding indicator. Thus, the loading of a latent variable on the individual indicator should return a value larger than 0.7 [5][21]. According to Hulland [21] indicators with loadings less than 0.4 should be eliminated. 15 indicators fulfilled the former requirement exceeding the threshold of 0,7. We have left 3 other indicators with the loading values of 0.61; 0.57; 0.62 in the model to ensure the content validity of the measured constructs. Furthermore, Cronbach’s Alpha, a measure of Internal Consistency, for all constructs was assessed. As can be seen in Table 2, its values were higher than the required threshold of 0.7 for all latent constructs [26]. In order to ensure Composite Reliability, its value should exceed 0.6 for all constructs [20]. Additionally, the AVE values of all constructs should to be at least 0.5 since otherwise the variance due to the measurement error would be higher than the variance captured by the corresponding construct [12]. As can be seen in Table 2, the Composite Reliability and AVE thresholds were surpassed by all constructs. Discriminant Validity refers to the degree to which measures of distinct concepts differ [1]. According to Fornell and Larcker [12], Discriminant Validity is ensured when the AVE values for all latent variables stay greater than the squared 404 correlation between the latent variable and any of the other latent variables in the same model. This criterion was ensured for all constructs (see Table 3). The second criterion to assure Discriminant Validity requires that the factor loadings of every indicator are greater than any of the crossloadings, i.e. the loading of the indicator on another than the construct it is supposed to measure. This criterion was also met by both of the estimated models (A and B). Table 2. Quality criteria of the constructs Model A B Construct VFI IIS PBO VFI PBO Number of indicators 6 6 6 6 6 Composite Reliability 0.866 0.970 0.948 0.867 0.948 Average Variance Extracted (AVE) 0.526 0.844 0.755 0.524 0.755 Cronbach’s Alpha 0.815 0.963 0.934 0.815 0.934 Table 3. Square root of AVE (diagonal elements) and correlations between latent variables (off-diagonal elements) Construct VFI IIS PBO Model A VFI IIS 0.73 0.563 0.92 0.417 0.632 PBO Construct VFI PBO Model B VFI PBO 0.72 0.44 0.87 0.87 4.5 Evaluation of the Structural Model and the Mediation Effect As opposed to the covariance-based approach, no overall measures of goodness of fit are available when using PLS. Chin [6] argues that in Structural Equation Modeling the importance of goodness of fit measures is generally overestimated. The model validity in PLS can be evaluated by examining the resulting R2 values and the structural paths [29]. Evaluation of the significance of the path coefficients is done via a bootstrapping procedure, since there are no assumptions on how the latent variables are distributed. Evaluation results concerning the Structural Models (Models A and B) are presented in Figure 2. The results of the PLS analysis show that 40.4% of the variance in the dependent variable (Performance of the Brand Owner) is explained by the variables in the model. Recommendations for an acceptable level of R² range from 33% to 67% and above [29]. Taking into account the novelty of the research topic, such explanatory power of the model is high. At the next step the values of the path coefficients and their significance were evaluated for Models A and B. It is recommended that the values of the path coefficients exceed the 0.2 threshold [29]. We find that the path coefficient between Vertical Forward Integration and Intensity of Information Sharing (VFI Æ IIS) is high (0.563) and significant. Similarly, there exists a strong significant link(0.582) between Intensity of Information Sharing and the Performance of the Brand Owner (IIS ÆPBO). Thus, hypotheses H3 and H1 are supported. We find the link between Vertical Forward Integration and the Performance of the Brand Owner to be insignificant for model A, which rejects hypothesis 2 (H2). The evaluation of the Model B, when the IIS construct is removed, rendered a strong (0.431) and significant link between both constructs. The explained variance in the dependent variable (Performance of the Brand Owner) drops to R²=0.191. The comparison of Models A and B clearly confirms the presence of a strong mediation effect of the IIS variable. Thus, hypothesis H4 is confirmed. 405 Figure 2. Results of Structural Models’ Evaluations (PLS) 5. Discussion and Managerial Implications The statistical results show that Vertical Forward Integration alone is not a sufficient condition for the success in the fashion business: H2 was not supported by out data. However, our model shows that vertical integration does have an indirect impact on performance because it enables profitable information sharing practices (H3, H1). Indeed, we find that Intensity of Information Sharing along the supply chain mediates the relationship between Vertical Forward Integration and Performance (H4). The importance of free information flow in the apparel supply chain is an important finding of our study: a high intensity of information sharing activities between the brand owner and the retailers involved in the distribution of apparel leads to increased performance of the brand manufacturer (H1). The high and significant path coefficient is an indication of the extremely high relevance of timely demand signals in the fashion business. Our results suggest that while logistical information seems to be shared intensively within vertically integrated fashion companies, it is usually not shared in distribution systems where the brand owner exerts little control over the retailers. If their superior information flow is what distinguishes fast fashion retailers, the performance of the traditional apparel manufacturers and/or wholesalers could be improved by inter-organizational information sharing and collaboration. Information sharing across organizational borders requires both: information technology that supports the fast and reliable exchange of data (e.g. EDI, RFID) and setting the right incentives for sharing information reliably and truthfully. 6. Conclusions Motivated by the astounding achievements of the fast fashion companies, the aim of this paper was to empirically identify important drivers of success in the apparel industry. We find that solely exerting more control over subsequent supply chain stages is an important but not a sufficient condition for the success of brand owners. The increase of supply chain control, which is usually achieved by vertical forward integration, is found to be an enabler of information sharing practices along the supply chain. Intensive information sharing in turn is a crucial ingredient of a successful supply chain strategy in the apparel sector. Our results motivate further research on how to enable effective information sharing among apparel manufacturers and retailers without the need for manufacturers to open their own stores. 406 7. References [1] BAGOZZI, R. P., PHILLIPS, L. W., Representing and Testing Organizational Theories: A Holistic Construal, in: Administrative Science Quarterly, 27:3 (1982). [2] BARCLAY, D., HIGGINS, C., THOMPSON, R., The PLS Approach to Causal Modeling: Personal Computer Adoption and Use as an Illustration, in: Technology Studies, 2:2 (1995). [3] BHATNAGAR, R., SOHAL, A. S., Supply Chain Competitiveness: Measuring the Impact of Location Factors, Uncertainty and Manufacturing Practices, in: Technovation, 25:5 (2005). [4] BARON, R. M., KENNY, D. A., The Moderator-Mediator Variable Distinction in Social Psychological Research: Conceptual, Strategic and Statistical Considerations, in: Journal of Personality and Social Psychology, 51:6 (1986). [5] CARMINES, E., ZELLER, R., Reliability and Validity Assessment, Sage Publications, 1979. [6] CHIN, W., Issues and Opinion on Structural Equation Modeling, in: MIS Quarterly, 22:1 (1998). [7] CONFEDERATION OF THE GERMAN TEXTILE AND FASHION INDUSTRY, Statistics for the German Textile and Apparel Industry, 2006. [8] ETGAR, M., Channel Environment and Channel Leadership, in: Journal of Marketing Research, 14:1 (1977). [9] FERDOWS, K.; LEWIS, M. & MACHUCA, J., Rapid-Fire Fulfilment, in: Harvard Business Review, 2004. [10] FISHER, M., RAMAN, A., Reducing the Cost of Demand Uncertainty through Accurate Response to Early Sales, in: Operations Research, 44:1 (1996). [11] FISHER, M., OBERMEYER, W., RAMAN, A., Making Supply Meet Demand in an Uncertain World, in: Harvard Business Review, 1994. [12] FORNELL, C., LARCKER, D. F., Evaluating Structural Equation Models with Unobservable Variables and Measurement Error, in: Journal of Marketing Research, 18:1 (1981). [13] GHEMAWAT, P., NUENO, J. L., ZARA: Fast Fashion, Harvard Business School Case No. 703-497, Harvard Business School Press, 2003. [14] GROSSMAN, S. J., HART, O. D., The Costs and Benefits of Ownership: A Theory of Vertical and Lateral Integration, in: Journal of Political Economy, 94:4 (1986). [15] GRÜGER, M., Die Vertikalisierung der Textilwirtschaft durch Handelsmarken, Produktdesignteams, Shop-inShop- und Concession-Konzepte, Doctoral Thesis, Universität zu Köln 2007. [16] JÖRESKOG, K. G. KRISHNAIAH, P. R., Structural Equation Models in Social Sciences: Specification, Estimation and Testing, in: P. R. Krishnaiah (Ed.), Applications of Statistics, Amsterdam, 1977. [17] HALLÉN, L., JOHANSON, J., SEYED-MOHAMED, N., Interfirm Adaptation in Business Relationships, in: Journal of Marketing, 55:2 (1991). [18] HASSANEIN, K. AND HEAD, M., Manipulating Perceived Social Presence through the Web Interface and its Impact on Attitude towards Online Shopping, in: International Journal of Human-Computer Studies, 65:8 (2007). [19] HAYES, S., JONES, N., Fast Fashion: A Financial Snapshot, in: Journal of Fashion Marketing and Management, 10:3 (2006). [20] HOMBURG, C., BAUMGARTNER, H., Beurteilung von Kausalmodellen – Bestandsaufnahme und Anwendungsempfehlungen, in: Marketing ZFP 3:3 (1995) [21] HULLAND, J., Use of Partial Least Squares (PLS) in Strategic Management Research: A Review of Four Recent Studies, in: Strategic Management Journal, 20:2 (1999). 407 [22] LEE, H. L., Aligning Supply Chain Strategies with Product Uncertainties, in: California Management Review, 2002. [23] LI, S., LIN, B., Accessing Information Sharing and Information Quality in Supply Chain, in: Management Decision Support Systems, 42:3 (2006). [24] MATTILA, H., KING, R., OJALA, N., Retail Performance Measures for Seasonal Fashion, in: Journal of Fashion Marketing Management, 6:4 (2002). [25] MCAFEE, A., SJOMAN, A., DESSAIN, V., Zara: IT for Fast Fashion, Harvard Business School Case No. 604081, Harvard Business School Press, 2004. [26] NUNNALLY, J. C., Psychometric Theory, 2nd Edition, McGraw-Hill, New York, NY 1978. [27] RICHARDSON, J., Vertical Integration and Rapid Response in Fashion Apparel, in: Organization Science, 7:4 (1996). [28] RINGLE, C. M., WENDE, S., WILL A., SmartPLS 2.0, Release 2.0.M3, Hamburg, Germany, 2005. [29] RINGLE, C. M., Gütemaße für den Partial Least Squares-Ansatz zur Bestimmung von Kausalmodellen, Working paper 16, Institute of Industrial Management, University of Hamburg, 2004. [30] THE ECONOMIST, The Future of Fast Fashion: Inditex, 375:8431, 2005. [31] U.S. DEPARTMENT OF LABOR, Reflections: 100 Years of U.S. Consumer Spending, http://www.bls.gov/opub/uscs/reflections.pdf, last accessed 15/07/2008. [32] WOLD, H. Soft Modeling: The Basic Design and Some Extensions, in: K. G. Jöreskog, H. Wold (eds.), Systems under indirect observations: causality, structure, prediction, Part 2, Amsterdam 1982. [33] ZHOU, H., BENTON, W., Supply Chain Practice and Information Sharing, in: Journal of Operations Management, 25:6 (2007). 408 WEBSERVICES FÜR DIE VERRECHNUNG IN WERTSCHÖPFUNGSNETZWERKEN AUF BASIS VOLLSTÄNDIGER FINANZPLÄNE Jörg Becker, Ralf Knackstedt, Martin Matzner1 Kurzfassung Das Angebot von integrierten Bündeln aus Sach- und Dienstleistungen im Rahmen so genannter Hybrider Wertschöpfungsnetzwerke stellt neue Anforderungen an die Informationssysteme der beteiligten Partner. Daten und Prozesse sind zu integrieren, um die Lösungen effektiv anbieten zu können. Die Verrechnung ist eine Teilaufgabe der Netzwerkkoordination. Gegenstand ist die Planung, Durchführung und Kontrolle von Zahlungsströmen zwischen den Partnern und gegenüber dem Endkunden. Der Beitrag untersucht, welche Webservices im Rahmen einer Serviceorientierten Architektur bereitgestellt werden sollten, um die Verrechnung für Hybride Wertschöpfung zu unterstützen. Dazu wird analysiert, welche Daten durch die Informationssysteme der Netzwerkpartner verfügbar gemacht werden müssen. Entwicklungsmöglichkeiten für zusätzliche betriebswirtschaftliche Funktionalität zur Unterstützung des Verrechnungsprozesses werden aufgezeigt. 1. Verrechnung in Hybriden Wertschöpfungsnetzwerken Produzierende Industrieunternehmen wandeln heute vielfach ihre Geschäftsmodelle von einer ausschließlich sachgutfokussierten Fertigung hin zu um Dienstleistungen angereicherten oder gar dienstleistungsdominierten Angeboten [11]. Im Rahmen der so genannten Hybriden Wertschöpfung werden dazu physische Produkte gezielt in Kombination mit spezifischen Dienstleistungen angeboten. Der Fokus liegt dabei auf der gesamtheitlichen Nutzenerbringung beim Endkunden, dem die Leistungen als integrierte Bündel angeboten werden. Teilweise können Sach- und Dienstleistungskomponenten gegeneinander ausgetauscht werden, um den erforderlichen Lösungsbeitrag beim Kunden zu erzielen. Angeboten werden derartige Konzepte häufig in der Form verfügbarkeits- und ergebnisorientierter Geschäftsmodelle [7]. Verfügbarkeits- und ergebnisorientierte Geschäftsmodelle garantieren die Verfügbarkeit des Sachgutes vertraglich. Im Rahmen ergebnisorientierter Geschäftsmodelle betreibt der Kunde die Maschine nicht mehr selbst, sondern ruft nur vereinbarte Produktionsergebnisse ab [1]. Zur Realisierung der Geschäftsmodelle muss das herkömmliche Sachleistungsangebot um spezifische Dienstleistungen angereichert werden. Verfügt der Sachgutproduzent über die nötigen Fähigkeiten und Ressourcen, kann die Einführung der neuen 1 Universität Münster, European Research Center for Information Systems, Leonardo-Campus 3, 48149 Münster 409 Geschäftsmodelle auch unternehmensintern vorgenommen werden. Andernfalls bietet sich die Kooperation mit externen Dienstleistern an. Die Realisierung solcher Geschäftsmodelle erfordert eine Beherrschung der wechselseitigen Abhängigkeiten von Sach- und Dienstleistungskomponenten und eine Koordination und Steuerung der gemeinsam erbrachten Wertschöpfung durch produzierende und dienstleistende Einheiten. Die Komplexität der Bearbeitung von Kundenaufträgen steigt stark, wenn verschiedene Geschäftseinheiten innerhalb eines Konzerns oder gar externe Partner daran beteiligt sind [5]. Die Folgen sind lange Durchlaufzeiten und Prozessfehler und schließlich hohe Kosten. ITUnterstützung ist zur Beherrschung dieser Komplexität unabdingbar. Webservices eignen sich durch ihre Kapselung von Funktionalität hinter präzise beschriebenen Schnittstellen, die Integration der heterogenen Informationssystemlandschaften von Produktion und Dienleistung zu unterstützen. Die Kundenauftragsabwicklung umfasst sämtliche betrieblichen Aktivitäten von der Erfassung eines Auftrags über den Warentransport bis zur Abrechnung der Leistung gegenüber den Kunden und schließlich deren Bezahlung [9]. Die zuvor skizzierten Veränderungen in den Geschäftsmodellen führen zu neuen intra-organisationalen Schnittstellen [2][5]. Mit der Folge, dass Anreiz-, Motivations-, Vergütungs- und Controllingsystem für die Leistungsverrechnung in ihrer Gänze zu überprüfen sind [8]. Im Rahmen dieses Beitrages wird mit der Verrechnung ein Teilbereich dieser Koordinations- und Steuerungsfunktionen genauer untersucht. Die Verrechnung umfasst im Rahmen der Hybriden Wertschöpfung einerseits den operativen Zahlungsverkehr gegenüber dem Endkunden als Abnehmer des Leistungsbündels. Andererseits müssen zwischen den kooperierenden Einheiten jeweils eingebrachte Leistungen vergütet und zusätzlich generierte Gewinne (und Verluste) verteilt werden. Dazu soll folgende Forschungsfrage adressiert werden: Welche Webservices sollten die Verrechnung unterstützen, sodass dienstleistende und produzierende Einheiten in Hybriden Wertschöpfungsnetzwerken flexibel miteinander kooperieren können? Aufbauend auf einem Konzept zur Verrechnung in Supply-Chains wird dazu ein Modell zur Verrechnung in Hybriden Wertschöpfungsnetzwerken entworfen. Es wird dargestellt, welche Informationen Produktion und Dienstleistung zu einem gemeinsamen Verrechnungssystem beitragen müssen. Webservices, die diese Informationen verarbeiten, werden anhand ihrer Schnittstellen beschrieben und Bedarf für weitere betriebswirtschaftliche Funktionalität aufgezeigt. 2. Verrechnung mithilfe Vollständiger Finanzpläne Ein Konzept für die Verrechnung zwischen Wertschöpfungspartnern stammt von HOLTEN UND SCHULTZ [6] und wurde für die Zusammenarbeit in Supply-Chains konzipiert. Das Modell basiert auf dem Konstrukt Vollständiger Finanzpläne nach GROB. Der Vollständige Finanzplan (VOFI) ist eine Methode des Investitionscontrollings (vgl. im Folgenden [4][3]). In einem VOFI werden sämtliche einem Investitionsobjekt zurechenbaren Zahlungen (Ein- und Auszahlungen) einschließlich der monetären Konsequenzen finanzieller sowie weiterer investiver Maßnahmen (z. B. Re- und Ergänzungsinvestitionen) explizit dargestellt und zeitlich terminiert. Zu jeder Periode eines VOFI werden Zahlungen, in die Investition eingebrachtes Eigenkapital, Kredite, Anlagen sowie Ertragssteuerzahlungen erfasst und miteinander zu Bestandssalden verrechnet. Für das Modell existieren zahlreiche Erweiterungsansätze. So können etwa alternative Finanzierungs- und Anlageoptionen integriert werden, um z. B. mithilfe Linearer Optimierung im Rahmen simultaner Planung optimale Finanzierungs- und Anlagevarianten für 410 Investitionsprojekte zu ermitteln. Abbildung 1 zeigt ein entsprechendes Modell, das die Wahl zwischen sechs Investitionsprojekten (GIO1,2, X1,…,X4) betrachtet. Die K* beschreiben alternative Finanzierungsmöglichkeiten. Eine Standardanlage wurde berücksichtigt. Abbildung 1: Simultane Planung von Finanzierung und Anlageoptionen (vgl. [4]) Folgende Charakteristika machen den VOFI also zu einem für die Problemstellung besonders geeigneten Instrument: Es weist Originalgrößen in einem Totalkalkül aus und erhöht damit die Transparenz, individuelle Konditionen für Zinssätze können berücksichtigt und unterjährige Verzinsungen von Guthaben- und Kreditbeständen abgebildet werden. Das VOFI-Konzept zeichnet sich durch Einfachheit wegen seiner Transparenz und Ausbaufähigkeit (durch eine mögliche Weiterverarbeitung der Grunddaten) aus [4]. HOLTEN UND SCHULTZ fassen das Verteilungsproblem von durch Synergien erwirtschafteter Erträge zwischen Teilnehmern einer Supply-Chain als Investitionsproblem auf. Dazu bewerten die Partner zunächst ihre (privaten) Finanzpläne mithilfe des so genannten Basis-VOFIs (1) unter der Annahme der Fortsetzung der bisherigen Geschäftstätigkeit. Mithilfe des Summen-VOFIs (2) werden Materialflüsse im Rahmen einer möglichen Supply-Chain-Kooperation zu gängigen Marktpreisen bewertet. Abschließend wird ein Supply-Chain-VOFI aufgestellt, der sich vom Summen-VOFI durch die Integration von Synergieeffekten unterscheiden solle. Die Differenz der Endwerte von Supply-Chain-VOFI und Summen-VOFI sei der durch Teilhabe an der Chain generierte Mehrwert, den sich die Partner aufteilen können. Das Modell adressiert damit die Planungsphase der Verrechnung. Im Rahmen dieses Beitrags soll der Ansatz aufgegriffen und auf den Kontext der Hybriden Wertschöpfung übertragen werden. Er wird um eine operative Ausgestaltung durch die Identifizierung relevanter Informationsflüsse erweitert. Zusätzlich werden die Phasen Durchführung und Kontrolle betrachtet. 3. Webservices für die Verrechnung in Wertschöpfungsnetzwerken auf der Basis Vollständiger Finanzpläne 3.1 Überblick Ausgangspunkt für die Gestaltung einer Serviceorientierten Architektur für die Verrechnung sind die Informationen, die Produzenten und Dienstleister zu einer gemeinsamen Verrechnung beitragen müssen und die Informationen, die Ihnen durch ein gemeinsam genutztes Verrechnungssystem verfügbar gemacht werden. Der Verrechnungsprozess lässt sich in die Phasen des allgemeinen Managementprozesses mit Planung, Durchführung und Kontrolle der Verrechnung einteilen. Für jede dieser Phasen wurde ausgehend von den zuvor diskutierten Konzepten und durch die Analyse von drei explorativen Fallstudien von Produzenten-Dienstleister-Kooperationen erhoben, welche Informationen dies sind. Die Fallstudien (FS) analysierten solche Kooperationen entlang des Lebenszyklus eines physischen Produktes (FS1: kundenindividuelle Beratung und Konzeption zu 411 Industriegütern; FS2 produktbegleitende Dienstleistungen eines Produzenten während der Nutzungsphase; FS3: sog. End-of-Life-Solutions wie Recycling und Remarketing). Tabelle 1 strukturiert den Untersuchungsbereich. In den folgenden Unterkapiteln werden Webservice-Spezifikation diskutiert, die einerseits diese Informationen verfügbar machen (datenorientierte Webservices), teils zusätzliche betriebswirtschaftliche Funktionalität bereitstellen, die die Koordinationsfunktionen der Verrechnung realisieren und Konsumenten der Daten sind (funktionsorientierte Webservices). Tabelle 1: Informationsobjekte für die Verrechnung in Hybriden Wertschöpfungsnetzwerken Planung _Zahlungsfolgen für alternative Formen der Kooperation _Finanzierungsoptionen _Investitionsoptionen _Verrechnungsmodell und zugehörige Parametrisierung Durchführung _Kundenzahlungen _eingebrachte Ressourcen _unterperiodische Verrechnung _periodische Verrechnung Kontrolle _Zahlungsfolgen für alternative Formen der Kooperation _Finanzierungsoptionen _Investitionsoptionen _Verrechnungsmodell und zugehörige Parametrisierung _Kundenzahlungen _eingebrachte Ressourcen _unterperiodische Verrechnung _periodische Verrechnung _Parametrisierung für Exception-Reporting _Kontrollbericht 3.2 Planung der Verrechnung 3.2.1 VOFI-Service Zentrales Element des Konzeptes ist der VOFI-Service. Er repräsentiert das Rechenschema eines klassischen Vollständigen Finanzplanes und dient somit der Ermittlung des Endwertes der Zahlungsfolge einer Investition unter Berücksichtigung derivativer Zahlungsfolgen, die sich aus benötigten Krediten, Anlagemöglichkeiten für eingehende Zahlungen und Ertragssteuern ableiten (vgl. Kap. 2). Dazu verdichtet er eingehende Informationsobjekte, die von produzierenden und dienstleistenden Einheiten beigesteuert werden. Diese werden sukzessive integriert und schließlich zu einem einzelnen so genannten Endwert (Accumulated Value) der Kooperation zusammengefasst (vgl. Abbildung 2). Diese Informationen betreffen die vier Teilbereiche: Einzahlungen (Incoming Payments), Auszahlungen (Outgoing Payments), Informationen zu Finanzierungs- (Credit Information) und Anlageoptionen (Investment Information). Die Funktionalität des VOFIs wird in unserem Konzept in dreifacher Ausprägung in verschiedenen Phasen der Verrechnung aufgegriffen: als Basis-, Summen- und Kooperations-VOFI. Wir beziehen uns auf und erweitern hier die Arbeit von HOLTEN und SCHULTZ [6]. _Basis-VOFI: Der Basis-VOFI folgt dem originären VOFI-Ansatz. Sowohl produzierendes als auch dienstleistendes Unternehmen erfassen hier sämtliche Finanzströme, die für das Unternehmen im Rahmen der Geschäftstätigkeit anfallen, ohne an der Kooperation zur hybriden Wertschöpfung teilzunehmen. _Summen-VOFI: Alle von der möglichen Kooperation betroffenen Finanzströme werden anschließend in einem so genannten Summen-VOFI zusammengefasst. Dabei werden diejenigen 412 Zahlungsströme der betrachteten Einheiten angenommen, die bei marktlich koordinierter Zusammenarbeit anfallen würden, sollte das verfolgte Geschäftsmodell realisiert werden. Dabei werden marktübliche Verrechnungspreise für das Einbringen von Leistungen in den Anbieterverbund unterstellt. _Kooperations-VOFI: Der Kooperations-VOFI dient zunächst als Planungsinstrument zur Vertragsgestaltung (und Gewinnaufteilung) zwischen den Kooperationspartnern. Während der Durchführung wird er sukzessive mit Ist-Daten gefüllt und kann dann in der Kontrolle zum Vergleich mit den Plan-Werten herangezogen werden (Delta-Modell, [10]). Simultane Planung VOFI AccumulatedValue Basis-VOFI IncomingPayments OutgoingPayments Summen-VOFI CreditInformation Kooperations-VOFI Investment Information Plan-Daten Ist-Daten Abbildung 2: Der VOFI-Service – Varianten und Zusammensetzung Wir realisieren das VOFI-Konzept mithilfe eines gleichnamigen Webservices, der zunächst nur über die Standardfunktionen „Erzeugen“ (generiert zu einem VOFI eine ID) und „Löschen“ verfügt [3]. Auf eine detailliertere Darstellung wird hier verzichtet. Da sowohl Basis-, Summen- und Kooperations-VOFI der „klassischen“ Struktur Vollständiger Finanzpläne (vgl. Kap. 2) folgen, können alle drei Ausprägungen mithilfe eines gemeinsamen Webservices „VOFI“ repräsentiert werden. Die später gezeigten zugehörigen Funktionen können je nach Ausprägung voneinander (geringfügig) abweichen. Wir beginnen mit der Erfassung der Basis-VOFIs der Wertschöpfungspartner. Zunächst sind sämtliche für die Unternehmung anfallenden Finanzströme der Geschäftstätigkeit zu erfassen und dadurch Ein- und Auszahlungen periodenindividuell zuzuordnen. Es handelt sich, wie erläutert, um Plan-Werte der fortgeführten Geschäftstätigkeit [6], ohne dass eine Anpassung des Geschäftsmodells durch den Beitritt zur Kooperation erfolgt. Der „VOFI-Webservice“ stellt hierzu die Methode recordIncomingPaymentsPlanned() bereit (vgl. Abbildung 3). Partner- und Beleg (Receipt)-ID sind in dieser Stufe noch irrelevant. Die VOFI.ID wurde bei der Generierung des VOFI-Konstruktes erzeugt und wird nun als Referenz übergeben. Anschließend sind für eine Periode (Period) eingehende Zahlungen (IncomingPayments) zu erfassen. Die Erfassung ausgehender Zahlungen erfolgt mittels recordOutgoingPaymentsPlanned() analog. Damit kann die Zahlungsfolge des originären Cash-Flows bereits gebildet werden: buildPaymentCyclePlanned(). Die Zahlungsfolge ist nun um abgeleitete, so genannte derivative Ein- und Auszahlungen zu ergänzen. Dazu werden mittels der Services addCreditOpportunity() und addInvestmentOpportunity() Finanzierungs- und Anlagealternativen hinterlegt. Die Funktion buildFinanceInvestmentFlow() bildet daraufhin die derivativen Finanzströme unter Berücksichtigung der bei der Erstellung der VOFIs als Rahmenparameter hinterlegten Steuersätze. Der Endwert des VOFI lässt sich über buildAccumulatedValue() abfragen. 413 Abbildung 3: Funktionen zur Erfassung der Zahlungsfolge des VOFI-Services Alle von der Kooperation betroffenen Zahlungsströme der betrachteten Einheiten werden nun wie erläutert zusammengefasst und im so genannten Summen-VOFI hinterlegt. Dabei werden die Leistungen der Kooperationspartner mit Marktpreisen bewertet. Die Erfassung kann nur manuell erfolgen, weil die Zurechenbarkeit der Finanzströme zur Kooperation anders nicht sichergestellt werden kann. Die Erfassung erfolgt analog zur Vorgehensweise beim Basis-VOFI. Nun ist der Kooperations-VOFI auf Planwerten der gemeinsamen Geschäftstätigkeit zu bilden. Dazu sind zwei Teilschritte vorzunehmen: a) Basierend auf verschiedenen Varianten der Kooperationsausgestaltung sind Geschäftsmodelle auszuwählen. Begleitend ist im Rahmen der Vertragsgestaltung ein Verrechnungsmodell auszuarbeiten, das den zu erwartenden zusätzlichen Endwert aufteilt. b) Finanzierungs- und Anlageoptionen werden durch die Kooperationspartner beigesteuert. Die Schritte zur Aufstellung eines Plan-Kooperations-VOFIs werden typischerweise in einem iterativen Prozess vorgenommen, weil wechselseitige Abhängigkeiten bestehen. Es können mehrere VOFIs (alternative VOFI-IDs) zu einem Beleg (hier: Vertrag) erstellt werden. Dies ermöglicht es, alternative Varianten im Rahmen der Kooperationsbildung zu prüfen. Es bietet sich an, zunächst auf Basis der Summen-VOFIs erste Verrechnungspreise anzunehmen, die originären 414 Zahlungsfolgen aufzustellen und diese Schrittweise zu verfeinern. Für diese Zahlungsfolgen sind Finanzierungs- und Anlageoptionen zu prüfen (s. u.) und Verrechnungspreise sukzessive anzupassen. Abschließend wird für den zu erwartenden Endwert eine Verteilungsformel präzisiert, die die zuvor erfolgte Verrechnung mit Verrechnungspreisen korrigieren kann. Wir unterstellen einen Start in den Verhandlungszyklus mit initialen Verrechnungspreisen, die als eine Startlösung gewählt wurden und alternativ ausgestalteten Kooperationsmodellen, die durch verschiedene Kooperations-VOFIs repräsentiert werden. Für jede Alternative ist bereits ein Kooperations-VOFI erstellt worden für den Verrechnungspreise unter Annahme zu erwartender Kooperationssynergien als eine Startlösung gewählt wurden. 3.2.2 Finanzierungs- und Anlageoptionen Jeder Partner kann Finanzierungs- und Anlageoptionen zur Finanzierung der Geschäftstätigkeit beisteuern. Diese können aus eigenen Mitteln gewährt werden oder fremdbezogen sein. Die Funktion addCreditOpportunity() erfasst Finanzierungsoptionen (vgl. Abbildung 4). Sie sind bestimmt durch ihre Laufzeit (CreditDuration), mögliche Laufzeitbeginne ([PossStartPeriods]), Höchstvolumen (CreditCeiling), Nominalzinsfuß (CreditInterrestRate), Fälligkeit der Zinsen (InterestsInAdvance), Tilgungsmodell (CreditAmortization) und ggf. (Dis-) Agio [4]. Analog können mithilfe der Funktion addInvestmentOpportunity()Anlageoptionen hinterlegt werden. Die periodenspezifisch in Anspruch genommenen Kredit- und Anlagevarianten werden als Array durch die Funktion buildInvestmentFlows() als Ergebnis eines Simultanen Planungsmodells (vgl. Kap. 2) zurückgegeben. Abbildung 4: Finanzierungs- und Anlage-Funktionen des VOFI-Service 415 3.3.3 Vertragsgestaltung Entsprechend der in Kap. 2 genannten Anforderungen an die Verteilung geschaffener Werte ist im Zuge der Vertragsgestaltung ein System für die Gewinn- und Verlustverteilung zu erarbeiten und im System zu hinterlegen. Im Rahmen dieses Beitrags wird eine mögliche Realisierung einer solchen Verteilung vorgestellt, die ein zweistufiges Verrechnungsverfahren anwendet: 1. mittels interner Verrechnungspreise (InternalPrice) zu eingehenden Kundenzahlungen und 2. mittels eines Verrechnungsmodells (RewardFunction), das Anreizfunktionen abbilden kann und das als Planungsinstrument die Vertragsverhandlung unterstützt. Unterperiodisch werden eingehende Kundenzahlungen durch interne Verrechnungspreise (1.) zwischen den Partnern abgerechnet (vgl. Abbildung 5). Die Verrechnungspreise werden basierend auf den Planmengen und dem Endwert des Plan-Kooperations-VOFIs für einzelne Positionen der angebotenen Leistungsbündel pro Leistungseinheit ausgehandelt. Erst im Rahmen des Kontrollprozesses wird die abschließende Verrechnung (2.) vorgenommen. Dazu müssen während der Verhandlungsphase Verteilungsformeln zwischen den Partnern ausgehandelt werden, die neben anderem auch ein Kooperationsziel-konformes Verhalten der Partner sicherstellen können. Die Funktionsweise wird hier beispielhaft anhand eines so genannten Profit-Sharing-Modells illustriert. Die Darstellung lehnt sich an SCHULTZ [10] an und wurde für das Verrechnungsschema hybrider Wertschöpfung mittels VOFIs erweitert und angepasst. Das klassische Profit-Sharing-Anreizmodell folgt der Form: m ns ~ [1] Li (e1 ,..., em ) = Li + δ i ∑∑ e s , j (c s*, j ) ∀i = 1,..., m s =1 j =1 ei,j (c*i,j) repräsentieren die Ist-Ergebnisse der Investition j in den einzelnen Investmentcentern i in Abhängigkeit von den in den selbständigen Einheiten allokierten finanziellen Mitteln c*i,j. Hier wird ein funktionaler Zusammenhang unterstellt. Anhand der partnerspezifischen ~ Entlohnungskoeffizienten δi werden diese einem fixen Entlohnungsanteil L zugeschlagen. In der Produzenten-Dienstleister-Kooperation fällt eine derartige Darstellung der Ist-Ergebnisse in Abhängigkeit von eingebrachten Ressourcen schwer, weil unmittelbare Wirkungszusammenhänge nicht direkt expliziert werden können und so eine direkte Zuordnung des Kooperationserfolgs zu den Beiträgen der Partner nicht möglich ist. Daher wird das Modell dahingehend abgewandelt, dass die Verteilungsfunktion den Partnern einen durch δi angegebenen Anteil an der durch die Verrechnungspreise ermittelten Verteilung garantiert. Das ermuntert diese, möglichst stark unmittelbar zum Erfolg der Kooperation beizutragen. Der nicht ausgeschöpfte Betrag (resp. der verzeichnete Verlust) wird anschließend en Bloc auf die Partner (z. B. zu gleichen Teilen) verteilt, um opportunistisches Verhalten nicht allzu stark zu fördern. Jeder Partner „leidet“ also mit, wenn das Netzwerk als ganzes schlecht wirtschaftet. Es ergibt sich das abweichende Modell [2] Li (e1 ,..., em ) = RVi + δ i eiverr ,j mit m ∑δ i =1 ≤1 i Die eiverr , j können für eine abzurechnende Periode mithilfe der Summe der nach (1.) intern verrechneten Leistungen ermittelt werden. RVi repräsentiert dabei den verbleibenden Endwert nach Verteilung. Er ergibt sich als Differenz aus den eiverr , j für eine eingebrachte Investition j und dem Endwert des zugehörigen Ist-Kooperations-VOFI, der im Rahmen der Durchführung nun aufzustellen ist. 416 Abbildung 5: Funktionen der Vertragsgestaltung 3.2 Durchführung der Verrechnung Die Durchführung ist die operative Umsetzung des im Rahmen der Planung gestalteten Modells. Während der Auftragsabwicklung der Produzenten-Dienstleister-Kooperation können mithilfe der Funktion recordIncomingPaymentsAsIs()eingehende Kundenzahlungen erfasst werden. Zahlungen können durch alle beteiligten Partner entgegengenommen werden. Eine Zuordnung erfolgt über die PartnerID. Zahlungen werden stets für Positionen zugrundeliegender Dokumente (hier: Rechnung, ReceiptID) erfasst. Die Verrechnung an die Partner erfolgt über die hinterlegten und ausgehandelten Verrechnungspreise (‚getInternalPrice()‘). Durch die Zahlungserfassung wird zugleich eine zweite Sicht für den Kooperations-VOFI mit Ist-Daten gepflegt. Als Referenz wird dazu die VOFI-ID des Plan-Kooperations-VOFIs übergeben. Die sukzessiv fortgeschriebenen IstWerte stehen nun in der Kontrolle der Verrechnung zur Verfügung. Es resultieren Informationsobjekte, die spiegelbildlich zu den in der Planungsphase bezeichneten sind in dem Sinne, dass nun Ist-Daten anstelle von Plan-Daten abgebildet sind. Diese betreffen die realen Zahlungen, die eingebrachten Ressourcen und die Zahlungsströme der unterperiodischen und periodischen Verrechnung. 3.3 Kontrolle der Verrechnung Auf den mithilfe des Ist-Kooperations-VOFIs ermittelten Endwerts ist nun die in der Vertragsgestaltung ausgehandelte Verrechnungsfunktion zur Nachverteilung des erzielten Ergebnisses anzuwenden. Daraufhin sind entsprechende Verrechnungsbuchungssätze zwischen den Partnern zu generieren und die Zahlungen an die operativen Systeme der Partner zu übermitteln. Auf Basis der Werte können nun Plan-Ist-Vergleiche (Delta-Kooperations-VOFI) von Zahlungsfolgen und resultierenden Endwerten und zahlreiche weitere aus der Investitionsrechnung bekannte Kennzahlen abgeleitet werden. Es müssen also folglich alle in Planung und Durchführung beschriebenen Informationsobjekte im Rahmen der Kontrolle bereitgestellt werden. Neben der Verfügbarmachung dieser Daten für das Controlling, können verdichtete Kennzahlen [3] generiert werden, die in Kontrollberichten zusammengefasst und an das Controlling übermittelt werden. 4. Ausblick Der Beitrag zeigt auf, welche Informationen produzierende und dienstleistende Einheiten eines hybriden Wertschöpfungsnetzwerkes innerhalb einer Kooperation beisteuern müssen, um eine 417 gemeinsame Verrechnung zu ermöglichen und welche Webservicespezifikationen geeignet sind, diese Informationen bereitzustellen. Bestehende betriebliche Informationssysteme können anhand dieser Informationsflüsse daraufhin untersucht werden, inwiefern sie geeignet sind, die flexible Kooperation von Produzenten und Dienstleistern zu unterstützen und wo funktionale Lücken bei ERP-Systemherstellen herrschen. Entwicklungsperspektiven eröffnen sich für die Systemhersteller einerseits durch die Integration von datenbereitstellenden Services, die die Informationsflüsse zwischen den Anwendungssystemen von Produktion und Dienstleistung unterstützen. Damit verschiedene Systeme bei Produzent und Hersteller die dargestellten Informationsflüsse bedienen können, bedarf es der Etablierung von herstellerübergreifenden Standards, die derzeit noch nicht existieren. Diese Standards müssen geeignete Nachrichtenstrukturen definieren, in denen die beschrieben Informationen ausgetauscht werden. Die hier beschriebenen Informationsflüsse zur Unterstützung des Verrechnungsprozesses sollen in ein solches Standardisierungsprojekt übernommen werden. Neben dem Austausch von Daten besteht weiteres Entwicklungspotentiale durch die Implementierung zusätzlicher betriebswirtschaftlicher Funktionen und Prozesse, die die Koordination der Kooperation unterstützen. Solche Perspektiven wurden für die Finanzierungs- und Anlageoptimierung und im Rahmen der Gewinnverteilung aufgezeigt. Diese funktionalen Webservices sind derzeit Gegenstand eines prototypischen Implementierungsprojektes. Danksagung. Dieser Beitrag entstand im Rahmen des Forschungsprojektes FlexNet (Flexible Informationssystemarchitekturen für hybride Wertschöpfungsnetzwerke), das durch das BMBF unter dem Kennzeichen 01FD0629 gefördert wird. Wir danken auch dem Projektträger Deutsches Zentrum für Luft- und Raumfahrt für seine Unterstützung. http://www.flexnet.uni-muenster.de. 5. Literaturhinweise [1] BEVERUNGEN, D., KAISER, U., KNACKSTEDT, R., KRINGS, R., STEIN, A., Konfigurative Prozessmodellierung der hybriden Leistungserstellung in Unternehmensnetzwerken, in: Proceedings of the Multikonferenz Wirtschaftsinformatik, München, 2008. [2] CORSTEN, D., GABRIEL, C.: Supply Chain Management erfolgreich umsetzen: Grundlagen, Realisierung und Fallstudien. Springer, Berlin, 2004. [3] DEWANTO, B. L., Anwendungsentwicklung mit Model Driven Architecture. Logos, Berlin, 2005. [4] GROB, H. L., Einführung in die Investitionsrechnung, Vahlen, München, 2006. [5] GIZANIS, D., Kooperative Auftragsabwicklung. Dissertation. Universität St. Gallen, 2006. [6] HOLTEN, R., Schultz, M. B., Integriertes Controlling für Aufbau, Betrieb und Anpassung von Supply Chains, in: Wirtschaftsinformatik, 43( 6), 2001, S. 579-588. [7] MEIER, H., KORTMANN, D., KRUG, C., Von der Technolgoie- zur Nutzenführerschaft, in: ZWF – Zeitschrift für wirtschaftlichen Fabrikbetrieb, 7/8, 2006, S. 431-434. [8] NIPPA, M., Geschäftserfolg produktbegleitender Dienstleistungen durch ganzheitliche Gestaltung und Implementierung, in: Management produktbegleitender Dienstleistungen. Physica, Berlin, 2005, S. 1-18. [9] OTTO, A., Auftragsabwicklung, in: Klaus, P., Krieger, W. (Hrsg.), Gabler Lexikon Logistik. Gabler, Wiesbaden, 2004, S. 14-20. [10] SCHULTZ, M. B., Anreizorientiertes Investitionscontrolling mit vollst. Finanzplänen, Logos, Berlin, 2005. [11] VARGO, S. L., LUSCH, R. F., Service-Dominant Logic: Continuing the Evolution, in: Journal of the Academy of Marketing Science, 36(1), 2008, S. 1-10. 418 SCIENCE OF SERVICES / WISSENSCHAFTSTHEORIE Die Zielsetzung, neben einer artefaktzentrierten, d. h. primär gestaltungs-, technologieorientierten Forschung auch Beiträge zum theoretischen Fundament der Wirtschaftsinformatik (WI) zu liefern oder sich mit der Wissenschaftsdisziplin Wirtschaftsinformatik selbst zu befassen, ist in der WI gewissen Zyklen unterworfen. Jedoch ist seit einiger Zeit ein erfreulich positiver Trend erkennbar, dass sich diese Zyklen verkürzen. Entsprechend möchte auch die WI 2009 diesem Trend folgen. Leitungsgremium: Werner Esswein, Technische Universität Dresden (Federführender) Klaus Tochtermann, Technische Universität Graz Stephan Zelewski, Universität Duisburg-Essen Programmkomitee: Robert Braun, Daimler AG Andreas Dietzsch, PostFinance Schweiz Steffen Greiffenberg, semture GmbH Sabine Zumpe, Business School der University of Queensland (Brisbane, Australien) DOKUMENTATION UND FORTSCHRITTSBESTIMMUNG VON METHODEN ZUR GESTALTUNG SOZIOTECHNISCHER SYSTEME AM BEISPIEL EINER METHODE ZUM SERVICE ENGINEERING Stephan Aier, Christian Fischer1 Kurzfassung Methoden zur Gestaltung soziotechnischer Systeme sind zentrale Forschungsergebnisse der Wirtschaftsinformatik. Dieser Beitrag greift eine Idee von FRANK [12] auf, indem er einen Dokumentationsrahmen für Methoden aus der Wirtschaftsinformatik konstruiert und ein darauf aufbauendes Fortschrittskonzept skizziert. Der Dokumentationsrahmen orientiert sich an Anforderungen von Praktikern, indem er die Wahrnehmungsfunktion des aktuellen Wissenschaftskommunikationssystems verbessert; die auf dem Dokumentationsrahmen aufbauenden Kriterien zur Fortschrittsmessung von Methoden orientieren sich an Anforderungen von Wissenschaftlern. Eine Demonstration der Anwendbarkeit des Dokumentationsrahmens und des Fortschrittkonzepts verdeutlicht einerseits die Potenziale des Dokumentationsrahmens zur Verbesserung des aktuellen Wissenschaftskommunikationssystems, deckt aber auch weiteren Forschungsbedarf zur Bestimmung der Fortschrittlichkeit von Methoden auf. 1. Einleitung Methoden zur Gestaltung soziotechnischer Systeme sind zentrale Ergebnisse gestaltungsorientierter Forschung in der Wirtschaftsinformatik (WI) [4]. In den letzten Jahrzehnten wurde eine hohe Zahl solcher Methoden entwickelt; durch die Entwicklung verschiedener Methodenvarianten im Rahmen der situativen Methodenkonstruktion verstärkt sich dieses Problem noch einmal [10]. Diese Methoden wurden allerdings zumeist in einer Form dokumentiert, die einen direkten Vergleich der Methoden untereinander kaum ermöglicht: Häufig sind zwei Methoden, die verglichen werden sollen, nur in Textform dokumentiert und unterschiedlich strukturiert. Selbst wenn zwei Methoden in einer semiformalen Notation dokumentiert sind, unterscheiden sich beide Notationen oftmals derart stark voneinander, dass ein direkter Vergleich wiederum nur mit hohem Aufwand möglich ist. Durch die unstrukturierte Dokumentation der Methoden fällt es Praktikern schwer, eine Methode zu finden, die eine Lösung für ein konkretes Problem bereitstellt. Die mangelnde Vergleichbarkeit der Methoden erschwert es Wissenschaftlern aufzuzeigen, inwieweit eine neue Methode im Vergleich zu vorhandenen Methoden wissenschaftlichen Fortschritt darstellt. Als Lösung für diese beiden Probleme schlägt dieser Beitrag eine strukturierte Form der Methodendokumentation vor. Bereits FRANK [12] führt diese Probleme an und schlägt einen Dokumentationsrahmen für alle Forschungsergebnisse der WI und ihrer angelsächsischen Schwesterdisziplin Information Systems (IS) 1 Universität St. Gallen, Müller-Friedberg-Strasse 8, CH-9000 St. Gallen 421 vor. Durch den allumfassenden Ansatz bleibt der Dokumentationsrahmen jedoch allgemein. Der hier entwickelte Dokumentationsrahmen geht hingegen auf die Charakteristika einer Methode ein und erlaubt es daher, nicht nur Metainformationen zu der Methode, sondern auch ihren inhaltlichen Kern zu dokumentieren. Der Artikel ist wie folgt aufgebaut: Zunächst werden der Methodenbegriff, Konzepte wissenschaftlichen Fortschritts und Aspekte der Dokumentation von Forschungsergebnissen aufgearbeitet. Auf diesen Grundlagen basierend, entwickeln wir einen Dokumentationsrahmen für Methoden der WI und ein Konzept zur Bestimmung des Fortschritts solcher Methoden. Der Dokumentationsrahmen wird exemplarisch für eine Methode zur Servicespezifikation in einer Serviceorientierten Architektur (SOA) instanziiert. Außerdem wird das in dem Beitrag entwickelte Fortschrittskonzept angewendet. Der Beitrag schließt mit einer Bewertung des Dokumentationsrahmens und des Fortschrittskonzeptes und zeigt weiteren Forschungsbedarf auf. 2. Grundlagen Im Folgenden werden als Grundlage zuerst die Begriffe der Methode sowie des wissenschaftlichen Fortschritts analysiert, um anschließend den State-of-the-Art zur Dokumentation von Forschungsergebnissen nachzuvollziehen. 2.1. Methode Im Kontext der WI kann eine Methode definiert werden als die systematische Anleitung zur Durchführung von Aktivitäten, um ein Work Systems [1, 2] von einem initialen Zustand (SA) in einen definierten Zielzustand (SZ) zu transformieren [7, 9]. Weiterhin definiert eine Methode Rollen, welche die Aktivitäten ausführen und Techniken2, welche die Ergebniserstellung unterstützen [13, 18]. Abbildung 1: Metamodell situativer Methoden [9, 13] Für die effektive und effiziente Anwendung einer Methode ist es sinnvoll, den jeweiligen Projekttyp und die jeweiligen Kontextfaktoren für die Methodenausführung zu berücksichtigen und die Methode entsprechend zu adaptierten. Solche Ansätze werden unter dem Begriff des situativen Methodenengineerings diskutiert [9, 15, 20, 31]. Für die Beschreibung einer Situation unterschei2 „Techniken sind Anleitungen, wie ein Entwurfsergebnis oder eine Gruppe logisch zusammengehöriger Entwurfsergebnisse erzeugt werden. Während das Vorgehensmodell […] das Vorgehen im Grossen beschreibt, also festlegt, wann welche Entwurfsergebnisse erzeugt werden, beschreiben Techniken das Vorgehen im Kleinen, d. h. wie Ergebnisse produziert werden. Als Beispiele für Techniken können genannt werden: Konzeptionelle Datenmodellierung, Datenflussmodellierung, Entity-Life-History-Analyse, Dialogspezifikation, Stellenbildung.“ [13, S. 14] 422 den BUCHER ET AL. [9] sogenannte Projekttypen und Kontexttypen. Ein Projekttyp ist definiert als ein Tupel (SA, SZ) eines Work Systems WSS und beschreibt den Bereich des Systems, der durch die Methodenanwendung verändert wird. Beispiele für unterschiedliche Projekttypen aus dem Bereich Reorganisationsmaßnahmen sind eine Reorganisationsmaßnahme zur Einführung von Standardsoftware oder eine Reorganisationsmaßnahme zur Verbesserung der Kundenfreundlichkeit. BUCHER ET AL. weisen darauf hin, dass nicht nur Projekttypen die effektive und effiziente Anwendung einer Methode wesentlich beeinflussen, sondern auch nicht beeinflussbare Kontingenzfaktoren zu berücksichtigen sind, wie z. B. die Größe eines Unternehmens oder seine Branche. Beispiele für Methoden, welche Kontingenzfaktoren berücksichtigen, liefern YLIMÄKI/HALTTUNEN [32] sowie FITZGERALD ET AL. [11]. Das umgebende Work System WSK wird im Folgenden Kontexttyp genannt. Die spezifische Kombination von Projekttypen und Kontexttypen wird als Situation bezeichnet. Abbildung 1 visualisiert das Metamodell einer Methode. 2.2. Konzepte wissenschaftlichen Fortschritts Wissenschaftlichkeit und Fortschritt hängen eng miteinander zusammen; für KUHN [19] ist der Fortschritt sogar ein Kriterium, um Wissenschaften von anderen Gebieten abzugrenzen, z. B. von der Kunst. Daher verwundert es nicht, dass das Verständnis von Fortschritt in der Wissenschaftstheorie so breit diskutiert wird, dass es in diesem Beitrag unmöglich ist, den Diskurs auch nur ansatzweise nachzuzeichnen. Daher beschränken wir uns auf eine kurze Begriffserläuterung und legen uns dann auf ein geeignetes Fortschrittsverständnis fest. Im Unterschied zu ähnlichen Begriffen wie Entwicklung oder Veränderung ist der Fortschrittsbegriff normativ. Unstrittig ist, dass der Übergang von einem Stadium a zu einem Stadium b dann als Fortschritt bezeichnet wird, wenn b besser ist als a [23]. Gegenstand des Diskurses ist allerdings, was ein besseres Stadium in Bezug auf Theorien ist. Ein erstes Differenzierungskriterium für wissenschaftlichen Fortschritt von Theorien (T1) bezieht sich auf das, was Theorien aussagen: Für wissenschaftliche Realisten ist eine Theorie umso besser, je stärker sie sich der Wahrheit annähert, für wissenschaftliche Instrumentalisten, je besser sie Beobachtungen erklären und vorhersagen kann [24]. Ein zweites Kriterium (T2) bezieht sich auf das, worüber Theorien etwas aussagen, also ihre Anwendungsbreite. Bereits HEMPEL [16] erörtert den Begriff der Mächtigkeit einer Theorie und maß sie an dem Ausmaß der Konsequenzen für Aussagen in der Beobachtungssprache3. Ein drittes Kriterium (T3) bezieht sich auf die Bewährtheit einer Theorie. Bewährtheit von Theorien kann für wissenschaftliche Realisten ein Maß für die Wahrheitsadäquanz einer Theorie sein und würde somit unter das erste Kriterium fallen. Für wissenschaftliche Instrumentalisten hingegen gibt die Bewährtheit einer Theorie eher Auskunft über die Zuverlässigkeit eines Erklärungs- oder Vorhersageinstruments. POPPER [27] beispielsweise, Vertreter des kritischen Rationalismus, bestreitet, Bewährtheit sei ein Maß für das „Fürwahrhalten“ einer Theorie, und hält Bewährtheit für ein eigenständiges Qualitätskriterium einer Theorie. Nr. T1 T2 T3 Tabelle 1: Fortschrittskriterien für Theorien Bezeichnung Kriterien nach Zelewski [33] Wahrheitsadäquanz/Erklärungskraft Präzision (Z1a) Mächtigkeit Anwendungsbreite (Z1b) Bewährtheit empirische Bewährung (Z2) ZELEWSKI [33] entwickelt ein Fortschrittskonzept, mit dem der Fortschritt von Theorien, die nach dem Theorienkonzept des wissenschaftlichen Strukturalismus rekonstruiert wurden, formal bestimmt werden kann. Für ihn sind Merkmale für Fortschritt ein größerer empirischer Gehalt von 3 Der logische Empirismus, eine wissenschaftstheoretische Schule, zu der u. a. CARL GUSTAV HEMPEL zählt, unterscheidet zwischen Sätzen, die ausschließlich Beobachtungen beschreiben und in einer Beobachtungssprache formuliert werden, und solchen Sätzen, die von einer Theorie abhängig sind, also theoretische Entitäten oder deren Beziehungen zueinander oder zu Beobachtungen beschreiben. 423 Theorien (Z1), also eine größere Anwendungsbreite (Z1a) und eine höhere Präzision (Z1b), und eine größere empirische Bewährung (Z2). Das hier vertretene Fortschrittsverständnis ist zu dem von ZELEWSKI kompatibel; die Kriterien und ihr Zusammenhang zu den Kriterien von ZELEWSKI sind in Tabelle 1 zusammengefasst. 2.3. Kommunikation und Dokumentation von Forschungsergebnissen Gegenstand wissenschaftstheoretischer Diskussionen in WI und IS sind meist epistemologische Fragen oder Fragen zur Abgrenzung des Forschungsgegenstandes. Fragen der Präsentation und Dokumentation von Forschungsergebnissen sind in WI und IS bislang kaum im Fokus des wissenschaftlichen Diskurses gewesen, obwohl Benbasat und Zmud bereits 1999 [5] feststellten, dass Forschungsergebnisse in IS in einer Form präsentiert würden, die für Praktiker wenig ansprechend sei. Dies sei eine Ursache für die geringe Aufmerksamkeit, die IS-Forschungsergebnisse bei Praktikern genössen. Häufig wird die Präsentation und Dokumentation von Forschungsergebnissen nicht einmal als ein Bestandteil des Forschungsprozesses angesehen: PEFFERS ET AL. [26] analysieren sieben Publikationen über Forschungsmethoden im Design Research (DR), um einen DRReferenzforschungsprozess zu konstruieren. Nur zwei der untersuchten Arbeiten berücksichtigen dabei die Kommunikation des konstruierten Artefaktes [3, 17]. Ein Wissenschaftskommunikationssystem soll vier Funktionen erfüllen [22, 28, 29, 34]: Die Forschungsinhalte sollen zertifiziert sein, z. B. durch ein Peer-Review-Verfahren (Zertifizierungsfunktion); sie sollen eindeutig einem Urheber zugeordnet werde können (Registrierungsfunktion); sie sollen dauerhaft aufbewahrt werden können (Archivierungsfunktion) und die relevanten Inhalte sollen von Lesern wahrgenommen werden können (Wahrnehmungsfunktion). Der hier vorgeschlagene Dokumentationsrahmen bezieht sich hauptsächlich auf die Wahrnehmungsfunktion: Leser sollen für sie relevante und für sie irrelevante Methoden schnell voneinander unterscheiden und rasch den relevanten Inhalt einer Methode sowie relevante Metainformationen (z. B. Einsatzbereich der Methode, Ziel der Methodenanwendung, Bewährtheit der Methode, etc.) erfassen können. Die Wahrnehmungsfunktion wird umso besser erfüllt, je besser der Abgleich zwischen dem Wissensbedarf des Rezipienten und dem Wissensangebot funktioniert [14]. Um diesen Abgleich zu fördern, sind neben Basisdiensten (z. B. Erstellung von Metainformationen, Vorhandensein von digitalen Volltexten) und Push-Mechanismen (z. B. die regelmäßige Distribution von Zeitschriften, Newslettern usw.) auch Pull-Mechanismen hilfreich. Pull-Mechanismen sind beispielsweise Bibliothekskataloge oder Suchmaschinen [14]. FRANK [12] setzt zur Verbesserung des Wissenschaftskommunikationssystems bei den PullMechanismen an und schlägt einen Dokumentationsrahmen für alle Arten von Forschungsergebnissen in WI und IS vor, der in Abhängigkeit von der Forschungsmethode konfiguriert werden kann. Da Methoden der WI als ein DR-Artefakt angesehen werden können, sei hier kurz der Dokumentationsrahmen dargestellt, den FRANK für DR vorschlägt. In dem Dokumentationsrahmen berücksichtigt FRANK, dass ein DR-Artefakt eine Abstraktion von einer Absicht eines Forschers ist, dass es sich auf ein soziotechnisches System bezieht und dass es in einer bestimmten Sprache notiert ist. Jedes DR-Artefakt rechtfertigt sich von seinem Zweck her. Die Rechtfertigung eines bestimmten DR-Artefaktes weist die Adäquatheit des Artefakts in Bezug auf den Zweck nach. Es gibt verschiedene Methoden, die Adäquatheit eines Artefaktes zu bestimmen: Ein Prototyp zeigt die Umsetzbarkeit eines Artefaktes. Durch einen formalen Beweis kann die formale Korrektheit eines Artefaktes nachgewiesen werden. In Fallstudien kann belegt werden, dass das Artefakt den postulierten Zweck erfüllt. Weitere Methoden, die Adäquatheit eines Artefaktes zu rechtfertigen, unterscheidet FRANK nach dem ihnen zugrundeliegenden Wahrheitskonzept: Die Korrespondenztheorie der Wahrheit definiert eine Aussage a als wahr genau dann, wenn a. Verfahren zur Überprüfung einer Aussage nach diesem Wahrheitskonzept sind z. B. Feldstudien oder Experimente. Die Kohärenztheorie der Wahrheit nimmt an, dass eine Aussage wahr ist, wenn sie sich widerspruchsfrei in ein bestehendes Wissenskonzept einordnen lässt. Eine geeignete Überprüfungsmethode nach diesem Kriterium ist 424 die Literaturanalyse. Nach der Konsenstheorie der Wahrheit kann eine Aussage als wahr angesehen werden, wenn eine Gruppe von Experten darüber einstimmt, dass die Aussage wahr ist. Für eine Überprüfung nach diesem Kriterium schlägt FRANK in Anlehnung an HABERMAS den virtuellen Diskurs vor. 3. Dokumentation von Methoden und Messung von Fortschritt 3.1. Entwicklung eines Dokumentationsrahmens Der in dieser Arbeit vorgeschlagene Dokumentationsrahmen ist in Abbildung 2 dargestellt. In seinem Zentrum steht die Methode, die einen bestimmten Zweck erfüllt. Abbildung 2: Dokumentationsrahmen für eine soziotechnische Methode [9, 12, 13] Um einen Überblick über die Inhalte der Methode zu geben, werden die wichtigsten Elemente aus dem nicht-situativen Metamodell von GUTZWILER [13] abgebildet: eine Aktivitätenfolge und für jede Aktivität die daran beteiligten Rollen und eingesetzten Techniken. Auf eine Darstellung des Ergebnisses einer Aktivität in Form eines Informationsmodells sowie auf situationsspezifische Konfigurationsmöglichkeiten einzelner Aktivitäten soll verzichtet werden, um die Komplexität der Dokumentation zu reduzieren, So wird die Anforderung eines Praktikers erfüllt, sich rasch einen Überblick über eine Methode verschaffen zu können. Um einen Überblick über den Einsatzbereich einer Methode zu gewinnen, werden die verschiedenen Situationen einer Methode dokumentiert. Die Situation besteht dabei analog zu dem Verständnis von BUCHER ET AL. [9] aus einer Kombination aus einem Kontext- und einem Projekttypen. Durch die Dokumentation der verschiedenen Situationen wird einerseits die Anforderung von Praktikern erfüllt, rasch entscheiden zu können, ob eine spezifische Methode zur Lösung ihres konkreten Problems geeignet ist. Weiterhin erlaubt die Dokumentation der Situationen, den Fortschritt einer Methode im Vergleich zu einer anderen in Bezug auf ihren Anwendungsbereich zu überprüfen (Kriterium T2). Außerdem wird die Evaluation der Methode als Ganzes sowie die Rechtfertigung einzelner Kriterien während ihrer Konstruktion in Anlehnung an FRANK [12] dokumentiert. Eine Rechtfertigungsgrundlage rechtfertigt eine durchzuführende Aktivität. Eine Rechtfertigungsgrundlage ist aber auch Bestandteil der Evaluation einer Methode als Ganzes. Rechtfertigungsgrundlagen können andere Artefakte, Theorien oder Hypothesen sein. Für jede dieser Rechtfertigungsgrundlagen gibt es wie425 derum verschiedene Belege. Belege für Hypothesen weisen ihre Wahrheit nach, Belege für Theorien ihre Präzision, Belege für Artefakte ihre Nützlichkeit. Es lassen sich korrespondenztheoretische, konsenstheoretische und kohärenztheoretische Wahrheitsbelege voneinander unterscheiden (vgl. hierzu auch Abschnitt 2.2 in Anlehnung an FRANK [12]). 3.2. Kriterien für den Fortschritt von Methoden Der entwickelte Dokumentationsrahmen soll u. a. dazu dienen, den Fortschritt einer Methode im Vergleich zu einer anderen zu messen. Das in Abschnitt 2.2 aus der Wissenschaftstheorie vorgestellte Fortschrittskonzept bezieht sich allerdings auf Theorien, nicht auf Methoden. Methoden und Theorien unterscheiden sich jedoch fundamental voneinander: Für wissenschaftliche Realisten ist die Wahrheit von Theorien bedeutsam, insbesondere auch in Bezug auf nicht-beobachtbare Entitäten, die Bestandteil einer Theorie sind. Wissenschaftliche Instrumentalisten stellen nicht die Wahrheit von Theorien in den Vordergrund, sondern ihre Erklärungs- und Vorhersagefunktion. Methoden hingegen streben weder danach, die Realität wahrheitsadäquat zu beschreiben, noch verfolgen sie Erklärungs- oder Prognoseziele; Methoden sollen nützlich sein [21]. Daher müssen die drei Kriterien aus Tabelle 1 an die Besonderheiten von Methoden angepasst werden. Kriterium (T1) bezieht sich auf die Wahrheitsadäquanz bzw. Erklärungskraft von Theorien. Methoden hingegen verfolgen den Zweck, einen möglichst großen Nettonutzen4 zu stiften – oder anders formuliert: ein Problem effizient zu lösen. Es soll daher gelten: (M1) Ceteris paribus ist eine Methode a dann fortschrittlicher in Bezug auf eine Menge von Problemen P als eine Methode b, wenn a die Probleme aus P effizienter löst als b. Bez. Theorie Wahrheitsadäquanz/Erklärungskraft Mächtigkeit Bewährtheit Tabelle 2: Fortschrittskriterien für Methoden Bez. Methode Nr. Regel Ceteris paribus ist eine Methode a dann fortschrittlicher in Bezug auf Nützlichkeit M1 eine Menge von Problemen P als eine Methode b, wenn a die Probleme aus P effizienter löst als b. Ceteris paribus ist eine Methode a, die sich auf Projekte aus der Menge der Projekttypen PTa bezieht, dann fortschrittlicher als eine Methode b, M2a die sich auf Projekte der Projektmenge PTb bezieht, wenn PTb eine echte Teilmenge von PTa ist. Anwendungsbereich Ceteris paribus ist eine Methode a, die sich auf Kontexte der Kontextmenge Ka bezieht, dann fortschrittlicher als eine Methode b, die sich M2b auf Kontexte der Kontextmenge Kb bezieht, wenn Kb eine echte Teilmenge von Ka ist. Ceteris paribus ist eine Methode a ist dann fortschrittlicher als eine M3a Methode b, wenn a auf der Grundlage einer bewährteren Basis als b konstruiert wurde. Bewährtheit Ceteris paribus ist eine Methode a dann fortschrittlicher als eine MeM3b thode b, wenn a stärker evaluiert worden ist als b. Kriterium (T2) ist die Mächtigkeit von Theorien. Die Mächtigkeit einer Methode bezieht sich auf den Problembereich, das ist eine Menge von Situationen, in denen sie eingesetzt werden kann. Eine Situation ist definiert als eine Kombination aus einem Projekttypen und einem Kontexttypen [9]. Daher lassen sich zwei Regeln für den Methodenfortschritt definieren: (M2a) Ceteris paribus ist eine Methode a, die sich auf Projekte aus der Menge der Projekttypen PTa bezieht, dann fortschrittlicher als eine Methode b, die sich auf Projekte der Projektmenge PTb bezieht, wenn PTb eine echte Teilmenge von PTa ist. (M2b) Ceteris paribus ist eine Methode a, die sich auf Kontexte der Kontextmenge Ka bezieht, dann fortschrittlicher als eine Methode b, die sich auf Kontexte der Kontextmenge Kb bezieht, wenn Kb eine echte Teilmenge von Ka ist. 4 Der Nettonutzen einer Methodenanwendung ist die Differenz zwischen (Brutto-)Nutzen und Kosten einer Methodenanwendung. 426 Kriterium (T3) ist die Bewährtheit von Theorien. Die Bewährtheit von Methoden bezieht sich auf zwei Bereiche: erstens auf die Konstruktion der Methode, in deren Rahmen auch die Erkenntnisse der verhaltensorientierten Forschung einfließen [17], zweitens auf die Evaluation der Methode. Eine formale Fortschrittsregel für Methoden aufzustellen fällt allerdings schwer, da wegen der Vielfalt an epistemologischen Ansätzen in WI und IS eine rein quantitative Bewertung unmöglich ist [12]. Dazu müsste auch die Qualität eines epistemologischen Ansatzes berücksichtigt werden. Folgende zwei Kriterien lassen sich daher nur sehr unscharf formulieren: (M3a) Ceteris paribus ist eine Methode a dann fortschrittlicher als eine Methode b, wenn a auf der Grundlage einer bewährteren Basis als b konstruiert wurde. (M3b) Ceteris paribus ist eine Methode a dann fortschrittlicher als eine Methode b, wenn a stärker evaluiert worden ist als b. Die Fortschrittskriterien sind in Tabelle 2 zusammengefasst. 4. Exemplarische Anwendung 4.1. Instanziierung des Dokumentationsrahmens Um die Anwendbarkeit des Dokumentationsrahmens zu zeigen, wurde eine Methode von BEVERUNGEN ET AL. [6] zum Service-Design anhand dieses Dokumentationsrahmens instanziiert. Das Ergebnis findet sich in Abbildung 3. Abbildung 3: Instanziierung des Dokumentationsrahmens aus Abbildung 2 anhand einer Methode zur Servicespezifikation in einer SOA [6] Die beschriebene Methode erfüllt den Zweck, Services in einer SOA zu spezifizieren. Sie berücksichtigt das Konzept der Situativität nicht ausdrücklich. Allerdings lassen sich aus der Methodenbeschreibung zwei unterschiedliche Situationen rekonstruieren: In einem Projekttyp müssen die Geschäftsprozesse neu modelliert werden, weil sie nicht oder nicht in ausreichender Zahl vorhanden sind; in einem anderen Projekttyp sind Prozessmodelle des Unternehmens bereits vorhanden und müssen allenfalls angepasst werden. Anforderungen an den Anwendungsbereich der Methode werden nicht explizit formuliert. Daher nehmen wir an, dass sie sich in allen Unternehmen einsetzen lässt. Zur Evaluation der Methode wurde sie bei der Hellmann Process Management GmbH eingesetzt. Der Einsatz der Methode wurde in einer Fallstudie dokumentiert. Die Methode ist in drei Phasen gegliedert, die wir als Aktivitäten aufgeführt haben. Den Aktivitäten sind jeweils Techniken zugeordnet. Bei der Instanziierung des Dokumentationsrahmens ist aufgefallen, dass BEVERUNGEN ET AL. keine Rollen definieren. Daher haben wir sie nicht aufgeführt. Die einzelnen Aktivitäten und Techniken wurden ausschließlich durch Literatur belegt.5 5 In Abbildung 3 haben wir für jede Aktivität exemplarisch eine wichtige Quelle angeführt. 427 4.2. Fortschrittsbestimmung BEVERUNGEN ET AL. stellen in einer Literaturanalyse verschiedene Methoden zur Servicespezifikation vor. Exemplarisch haben wir die dort erwähnte Methode von PAPAZOGLOU/VAN DEN HEUVEL [25] ausgewählt, um anhand der Fortschrittskriterien aus Tabelle 2 zu prüfen, inwieweit die Methode von BEVERUNGEN ET AL. fortschrittlicher ist. Dazu gelte im Folgenden die Methode von BEVERUNGEN ET AL. als Methode a, die von PAPAZOGLOU/VAN DEN HEUVEL als Methode b. Kriterium (M1) bezieht sich auf den Nettonutzen der Methoden. Demnach ist eine Methode a dann fortschrittlicher in Bezug auf eine Menge von Problemen P als eine Methode b, wenn a die Probleme aus P effizienter löst als b. Die Anwendbarkeit des Fortschrittskriteriums setzt implizit voraus, dass a und b Lösungsvorschläge für zumindest teilweise dieselben Probleme anbieten. In unserem Beispiel enthält a Lösungsvorschläge für die Servicespezifikation, während b nicht nur Handlungsempfehlungen für die Servicespezifikation, sondern auch für die Serviceimplementierung gibt. Pa ist also eine echte Teilmenge von Pb, daher gilt: P = Pa. Nun wäre zu bestimmen, inwieweit a bei der Servicespezifikation einen höheren Nettonutzen stiftet als b. Allerdings machen weder BEVERUNGEN ET AL. noch PAPAZOGLOU/VAN DEN HEUVEL Angaben zu dem Nettonutzen ihrer Methode, die einen Vergleich der jeweiligen Methoden bzgl. ihres Nettonutzens erlauben würden. Daher lässt sich in dem vorliegenden Fall die Fortschrittlichkeit nach Kriterium (M1) nicht eindeutig feststellen. Kriterium (M2) ist der Anwendungsbereich der Methode. Kriterium (M2a) bezieht sich dabei auf die Projekttypen. Da die Menge der Projekttypen PTa der Methode a eine echte Teilmenge der Projekttypen PTb der Methode b ist, ist Methode b partiell fortschrittlicher als Methode a. Nach diesem Fortschrittskriterium wäre die neu entwickelte Methode von BEVERUNGEN ET AL. also ein Rückschritt im Vergleich zu der älteren von PAPAZOGLOU/VAN DEN HEUVEL. Kriterium (M2b) bezieht sich auf den Kontext. Da sich beide Methoden auf dieselben Kontexte, nämlich jeweils alle Unternehmen, beziehen, sind beide Methoden nach Kriterium (M2b) als gleich fortschrittlich einzustufen. Kriterium (M3) bezieht sich letztlich auf die empirische Bewährtheit der Methode, wobei (M3a) die Bewährtheit der einfließenden theoretischen Basis im Rahmen der Konstruktion betrifft, (M3b) die Bewährtheit der Methode durch die Evaluation. Die Bewährtheit nach (M3a) kann beurteilt werden, indem z. B. die Qualität der für jede Aktivität angegebenen Literaturquellen bewertet und miteinander verglichen wird. Dies ist allerdings mit der Schwierigkeit verbunden, geeignete Bewertungskriterien für die Qualität von Quellen aufzustellen. Daher wird an dieser Stelle auf die Anwendung von Kriterium (M3a) verzichtet. Kriterium (M3b) bezieht sich auf die Evaluation der Methoden. Beide Methoden werden in einer Fallstudie evaluiert. Ergebnis der Fallstudie ist jeweils, dass sich die Methode zur Lösung des jeweiligen Problems gut eignet. Beide Methoden können daher als ähnlich gut bewährt gelten. 5. Bewertung und Ausblick Der Beitrag schlägt ein Konzept zur Dokumentation von Methoden und zum Nachweis ihrer Fortschrittlichkeit vor. Die Instanziierung des Dokumentationsrahmens anhand des Beispiels hat gezeigt, dass der Dokumentationsrahmen dazu geeignet ist, Methoden zu beschreiben. Ein flexibler Umgang mit dem Dokumentationsrahmen kann allerdings notwendig sein: Die Methode von BEVERUNGEN ET AL. berücksichtigt bspw. keine Rollen, sodass sich die Entität „Rolle“ aus dem Dokumentationsrahmen nicht instanziieren lässt. Das Beispiel lässt erahnen, dass eine strukturierte Rekonstruktion und Dokumentation von Methoden einen Beitrag dazu leisten kann, Praktikern einen Überblick über vorhandene Methoden aus der WI zu geben und somit einen wertvollen Beitrag zur Verbesserung der Wahrnehmungsfunktion des derzeitigen Wissenschaftskommunikationssystems in WI und IS zu leisten. Um eine genauere Aussage über den Nettonutzen des vorgestellten 428 Dokumentationsrahmens machen zu können, muss allerdings eine größere Anzahl an Methoden rekonstruiert werden. Die Dokumentation muss dann durch potentielle Nutzer evaluiert werden. Weiterhin ist ein Anreizsystem zu schaffen, das Methodenkonstrukteure dazu veranlasst, ihre Methoden in dem Dokumentationsrahmen abzulegen. Ein erfolgreiches Beispiel für eine Wiki-basierte Dokumentation von bedeutenden Theorien in Information Systems ist ein von SCHNEBERGER und WADE entwickeltes Wiki [30]. Zur Verwaltung der Methodendokumentation ist eine Werkzeugunterstützung hilfreich. Ein solches Werkzeug kann eine flexible Modellierungssprache für Methoden implementieren, die auf dem Dokumentationsrahmen in Abbildung 2 basiert. Wie in Abschnitt 2.3 dargelegt wurde, können gute Suchfunktionen und die Bereitstellung eines digitalen Volltextes die Qualität eines solchen Systems steigern. Das Beispiel, anhand dessen das entwickelte Fortschrittskonzept demonstriert wurde, zeigt dreierlei: Erstens macht es plausibel, dass ein Wissenschaftskommunikationssystem nach dem hier entwickelten Dokumentationsrahmen hilfreich ist, um den Fortschritt von Methoden zu bestimmen. Zweitens kann gezeigt werden, dass sich das Konzept der Situativität auf eine Methode als Ganzes übertragen lässt, um einen partiellen Fortschritt der Methode in Bezug auf ihren Anwendungsbereich nachzuweisen (Fortschrittskriterien (M2a) und (M2b)). Drittens zeigt das Beispiel aber auch Schwächen auf: Insbesondere bzgl. der Nützlichkeit der Methode (Fortschrittskriterium (M1)) konnte keine befriedigende Aussage zum Vergleich beider Methoden gemacht werden. Ursache hierfür ist, dass der Nettonutzen der Methode in beiden Artikeln nicht quantifiziert worden ist. Dies ist aus theoretischer Perspektive insofern erstaunlich, als dass das Hauptziel einer Methode darin besteht, Nettonutzen zu stiften – und somit die Angabe von Kosten und Bruttonutzen Teil der Evaluation sein sollte. Allerdings mangelt es an Konzepten, einen quantifizierbaren Nettonutzen im Rahmen einer Fallstudie zu ermitteln. Weiterer Forschungsbedarf ergibt sich daher für die Nutzenmessung von DR-Artefakten (vgl. hierzu z. B. VOM BROCKE [8]). Alternativ kann ein Fortschrittskonzept entwickelt werden, das sich auf besser messbaren Kriterien als dem des Nettonutzens gründet. Weiterer Forschungsbedarf ergibt sich auch bei der Entwicklung von Konzepten zum Vergleich der Bewährtheit zweier Methoden. Weitere Anwendungsgebiete für eine Methodendokumentation nach dem hier vorgeschlagenen Dokumentationsrahmen sollen in künftiger Forschung evaluiert werden. 6. Literaturverzeichnis [1] ALTER, S.: 18 Reasons Why IT-reliant Work Systems Should Replace "The IT Artifact" as the Core Subject Matter of the IS Field, in: Communications of the Association for Information Systems, Vol. 12, 2003, pp. 366-395 [2] ALTER, S.: Work Systems and IT Artifacts - Does the Definition Matter?, in: Communications of the Association for Information Systems, Vol. 17, 2006, pp. 299-313 [3] ARCHER, L.B.: Systematic Method for Designers, in: Cross, N. (ed.): Developments in Design Methodology. John Wiley, London 1984 pp. 57-82 [4] BECKER, J., KNACKSTEDT, R., HOLTEN, R., HANSMANN, H., NEUMANN, S.: Konstruktion von Methodiken: Vorschläge für eine begriffliche Grundlegung und domänenspezifische Anwendungsbeispiele, in: Becker, J., Grob, H.L., Klein, S., Kuchen, H., Müller-Funk, U., Vossen, G. (eds.): Arbeitsberichte des Instituts für Wirtschaftsinformatik. Insitut für Wirtschaftsinformatik der Universität Münster, Münster 2001, [5] BENBASAT, I., ZMUD, R.W.: Empirical Research in Information Systems: The Practice of Relevance, in: MIS Quarterly, Vol. 23, 1999, pp. 3-16 [6] BEVERUNGEN, D., KNACKSTEDT, R., MÜLLER, O.: Entwicklung Serviceorientierter Architekturen zu Integration von Produktion und Dienstleistung - Eine Konzeptionsmethode und ihre Anwendung am Beispiel des Recyclings elektronischer Geräte, in: Wirtschaftsinformatik, Vol. 52, 2008, pp. 220-234 [7] BRINKKEMPER, S.: Method Engineering - Engineering of Information Systems Development Methods and Tools, in: Information and Software Technology, Vol. 38, 1996, pp. 275-280 [8] VOM BROCKE, J.: Entscheidungsorientierte Wirtschaftsinformatik – Entwicklung einer konstruktionsbegleitenden Kalkulation zur wirtschaftlichen Nutzung neuer Technologien, in: Bichler, M., Hess, T., Krcmar, H., Lechner, U., Matthes, F., Picot, A., Speitkamp, B., Wolf, P. (eds.): Multikonferenz Wirtschaftsinformatik 2008. GITO, München 2008, pp. 1551-1562 [9] BUCHER, T., KLESSE, M., KURPJUWEIT, S., WINTER, R.: Situational Method Engineering - On the Differentiation of "Context" and "Project Type", in: Ralyté, J., Brinkkemper, S., Henderson-Sellers, B. (eds.): Proceedings of 429 the IFIP WG8.1 Working Conference on Situational Method Engineering - Fundamentals and Experiences (ME07), Vol. 244. Springer, Boston 2007, pp. 33-48 [10] ESSWEIN, W., WELLER, J.: Method Modifications in a Configuration Management Environment, in: Österle, H., Schelp, J., Winter, R. (eds.): Proceedings of the 15th European Conference on Information Systems (ECIS2007), June 7-9 2007, St. Gallen, Switzerland. University of St. Gallen, St. Gallen 2007, pp. 2002-2013 [11] FITZGERALD, B., RUSSO, N.L., O'KANE, T.: Software development method tailoring at Motorola, in: Communications of the ACM, Vol. 46, 2003, pp. 64-70 [12] FRANK, U.: Towards a Pluralistic Conception of Research Methods in Information Systems Research, in: Adelsberger, H., Chamoni, P., Dorloff, F., Echtle, K., Eicker, S., Frank, U., Goedicke, M., Kollmann, T., MüllerClostermann, B., Pohl, K., Rathgeb, E.P., Unland, R., Zelewski, S. (eds.): ICB Research Report. Universität Duisburg Essen, Essen 2006, [13] GUTZWILER, T.: Das CC RIM-Referenzmodell für den Entwurf von betrieblichen, transaktionsorientierten Informationssystemen, Heidelberg 1994 [14] HAGENHOFF, S.: Zur Distribution wissenschaftlicher Inhalte, in: Schumann, M. (ed.): Arbeitsbericht. GeorgAugust-Universität Göttingen, Institut für Wirtschaftsinformatik, Göttingen 2007, [15] HARMSEN, A.F., BRINKKEMPER, S., OEI, H.: Situational Method Engineering for Information System Project Approaches, in: Verrijn-Stuart, A.A., Olle, T.W. (eds.): Proceedings of the IFIP 8.1 Working Conference on Methods and Associated Tools for the Information Systems Life Cycle. North-Holland, Amsterdam 1994, pp. 169-194 [16] HEMPEL, C.G.: Aspekte wissenschaftlicher Erklärung. de Gruyter, Berlin 1977 [17] HEVNER, A.R., MARCH, S.T., PARK, J., RAM, S.: Design Science in Information Systems Research, in: MIS Quarterly, Vol. 28, 2004, pp. 75-105 [18] HEYM, M.: Methoden-Engineering - Spezifikation und Integration von Entwicklungsmethoden für Informationssysteme. Rosch-Buch, Hallstadt 1993 [19] KUHN, T.S.: Die Struktur wissenschaftlicher Revolutionen. Suhrkamp, Frankfurt/Main 1981 [20] KUMAR, K., WELKE, R.J.: Methodology Engineering - A Proposal for Situation-specific Methodology Construction, in: Cotterman, W., Senn, J.A. (eds.): Challenges and Strategies for Research in Systems Development. John Wiley & Sons, New York 1992 pp. 257-269 [21] MARCH, S.T., SMITH, G.F.: Design and Natural Science Research on Information Technology, in: Decision Support Systems, Vol. 15, 1995, pp. 251-266 [22] MEADOWS, A.J.: Development of Science publishing in Europe, Amsterdam u. a. 1980 [23] NIINILUOTO, I.: Is There Progress in Science?, in: Stachowiak, H. (ed.): Pragmatik: Handbuch pragmatischen Denkens, Vol. 5. Meiner, Hamburg 1995 pp. 30-58 [24] NIINILUOTO, I.: Scientific Progress, in: Zalta, E.N. (ed.): The Stanford Encyclopedia of Philosophy 2007, [25] PAPAZOGLOU, M.P., VAN DEN HEUVEL, W.-J.: Service-oriented design and development methodology, in: International Journal of Web Engineering and Technology, Vol. 2, 2006, pp. 412-442 [26] PEFFERS, K., TUUNANEN, T., GENGLER, C.E., ROSSI, M., HUI, W., VIRTANEN, V., BRAGGE, J.: The Design Science Research Process: A Model for Producing and Presenting Information Systems Research, in: Chatterjee, S., Hevner, A. (eds.): Proceedings of the First International Conference on Design Science Research in Information Systems and Technology (DESRIST 2006) 2006, pp. 83-106 [27] POPPER, K.: Logik der Forschung. Mohr, Tübingen 1982 [28] RAVETZ, J.R.: Scientific Knowledge and its Social Problems, Oxford 1973 [29] ROOSENDAAL, H.E.: Developments in scientific communication: Considerations on the value chain, in: Information Services and Use, Vol. 21, 2001, pp. 13-32 [30] SCHNEBERGER, S.L., WADE, M.: Theories Used in IS Research Wiki, http://www.fsc.yorku.ca/york/istheory/wiki/, 2008, letzer Zugriff: 14.11.2008 [31] VAN SLOOTEN, K., HODES, B.: Characterizing IS Development Projects, in: Brinkkemper, S., Lytinnen, K., Welke, R.J. (eds.): Proceedings of the IFIP TC8, WG8.1/8.2 Working Conference on Method Engineering. Springer, Berlin et al. 1996, pp. 29-44 [32] YLIMÄKI, T., HALTTUNEN, V.: Method engineering in practice: A case of applying the Zachman framework in the context of small enterprise architecture oriented projects, in: Information Knowledge Systems Management, Vol. 5, 2006, pp. 189-209 [33] ZELEWSKI, S.: Relativer Fortschritt von Theorien. ein strukturalistisches Rahmenkonzept zur Beurteilung der Fortschrittlichkeit wirtschaftswissenschaftlicher Theorien., in: Zelewski, S., Naciye, A. (eds.): Fortschritt in den Wirtschaftswissenschaften. Wissenschaftstheoretische Grundlagen und exemplarische Anwendung., Wiesbaden 2006 pp. 217-336 [34] ZIMAN, J.M.: Public knowledge: an essay concerning the social dimension of science, Cambridge 1968 430 MODEN IN DER WIRTSCHAFTSINFORMATIK: WISSENSCHAFTSTHEORETISCHE UND WISSENSCHAFTSPRAKTISCHE ÜBERLEGUNGEN ZU EINER VON HYPES GEPRÄGTEN DISZIPLIN Hanno Schauer, Carola Schauer1 Kurzfassung Im vorliegenden Beitrag wird die Frage der Beeinflussung der Disziplin Wirtschaftsinformatik durch Modethemen aus wissenschaftstheoretischer Sicht näher untersucht. Auf Basis der Literatur werden Thesen bzgl. wissenschaftspraktischer Kennzeichen (Ursprung, langfristige Lerneffekte) und wissenschaftstheoretischer Fragestellungen (begriffliche Kontingenz, Originalität) aufgestellt. Die Diskussion der Thesen erfolgt anhand ausgewählter Moden der Wirtschaftsinformatik und erlaubt erste Schlussfolgerungen bzgl. der Rolle von Moden für die Disziplin. Unter Rückgriff auf Ergebnisse einer Umfrage unter CIOs im deutschsprachigen Raum werden abschließend Möglichkeiten und Grenzen der Einflussnahme der Disziplin auf Modethemen in der Praxis diskutiert. 1. Hintergrund und Motivation Die Wirtschaftsinformatik (WI) ist eine an Themen der Praxis orientierte und – zumindest nach Meinung einiger langjähriger Disziplinvertreter – eine deutlich von Moden betroffene Disziplin [10]. Verschiedene empirische Studien untermauern diesen Eindruck dahingehend, dass die wissenschaftliche Disziplin WI – auch – Themen adressiert, die als Mode eingestuft werden können ([10], [12], [13], [15]). Nicht selten wird von „Hypes“ gesprochen, denen sich offenkundig auch die wissenschaftliche Community nicht entziehen kann. Prominente Beispiele sind der „Internet-Hype“ oder – wie aktuell in der WIRTSCHAFTSINFORMATIK diskutiert – „Service Oriented Architectures (SOA)“ [8]. Explizit wurde die Rolle von Modethemen in der WI bisher in zwei schlagwortbasierten Publikationsanalysen adressiert. Mertens untersucht die Schlagworte in der Zeitschrift Computerwoche von 1975 bis 1995 und zieht hieraus Rückschlüsse auf thematische Moden in der WI, wobei er „im allgemeinen nicht zwischen Wissenschaft und Praxis differenziert“ ([12], S. 26). Er identifiziert „ausgeprägte Gipfel und Täler und wiederkehrende Modethemen“ ([12], S. 28) und diskutiert den Verlauf ausgewählter (Mode-) Themen unter zusätzlicher Bezugnahme auf den subjektiv gewonnenen Eindruck des jeweils erzielten Erkenntnisfortschritts. S. Steininger et al. analysieren jüngere Ausgaben der Computerwoche und der WIRTSCHAFTSINFORMATIK (19942005) und schlussfolgern u. a., dass sich die Disziplin WI „nach wie vor in hohem Ausmaß mit Moden [..] beschäftigt“ ([15], S. 1539). 1 Lehrstuhl für Wirtschaftsinformatik und Unternehmensmodellierung, Universität Duisburg-Essen, Universitätsstraße 9, D-45141 Essen 431 Moden implizieren für eine angewandte Disziplin – auf den ersten Blick – sowohl Chancen als auch Herausforderungen: Sie bieten einer anwendungsorientierten Disziplin – welche Legitimation nicht nur in der Wissenschaft, sondern auch in der dazugehörigen Praxis erreichen möchte – die Chance, durch die Bearbeitung aktueller Themen und Problemstellungen selbst positive Aufmerksamkeit zu erhalten. Gleichzeitig ist aus wissenschaftstheoretischer Sicht kritisch zu hinterfragen, inwiefern die Adressierung von Modethemen und die bewusste Verwendung modischer Schlagwörter aus der Praxis den Anforderungen eines grundlegenden wissenschaftlichen Ideals entsprechen und einen langfristigen Erkenntnisfortschritt der Disziplin WI befördern bzw. behindern. Dieser Beitrag ist als Diskussions- und Thesenpapier darauf gerichtet, die Chancen und Risiken des Umgangs mit Modethemen für die anwendungsorientierte wissenschaftliche Disziplin WI aus wissenschaftstheoretischer Sicht näher zu untersuchen.1 Grundlegend werden dazu nachfolgend der Begriff „Mode“ bzw. „Modethema“ diskutiert und Kriterien zur Bestimmung von Moden aufgestellt (Abschnitt 2). Die weiteren Überlegungen orientieren sich an Thesen über Charakteristika und Wirkungen von Moden. Diese Thesen werden in Abschnitt 3 eingeführt. Die Überprüfung der Thesen erfolgt anhand ausgewählter aktueller und früherer Modethemen in Abschnitt 4. Der abschließende Abschnitt formuliert Schlussfolgerungen und erörtert Handlungsoptionen für die Disziplin WI, auf Moden in der Praxis Einfluss zu nehmen (Abschnitt 5). 2. Begriffsabgrenzung Nachfolgend werden grundlegende, definitorische Eigenschaften von Moden in der WI diskutiert. Die Begriffe Mode, Modethema, Hype, Fad und Fashion werden dabei als synonym und gleichermaßen wertneutral verwendet. Die Frage der Bewertung von Moden wird im Rahmen der Thesendiskussion erst in den nachfolgenden Abschnitten thematisiert. 2.1. Kurzfristig sehr hohe Aufmerksamkeit Eine Mode kennzeichnet sich grundlegend dadurch, dass sie in der betrachteten Gemeinschaft oder Zielgruppe außerordentlich große Aufmerksamkeit erfährt. Das stark ausgeprägte Interesse an einem Modethema ist dabei typischerweise auf einen relativ kurzen Zeitraum beschränkt (wenige Monate oder Jahre); dies verdeutlichen die häufig synonym verwendeten Begriffe Modewelle oder Hype. Für Managementmoden stellt Kieser fest, dass deren Verlauf – in der Praxis – durch eine Glockenkurve beschrieben werden könne ([9], S. 22), da eine Mode recht schnell viele Anhänger findet, sich jedoch mit der Zeit „abnutzt“, da sie „ihre Wirkung als Symbol [..] des Fortschritts [verliert]“ ([9], S. 33). Mertens spricht diesbezüglich von einer Phase der Übertreibung oder Euphorie, auf die eine Phase der „Depression“ folgt ([12], S. 37). In ähnlicher Form definieren Steininger et al. Moden als „Themen, die kurzfristig aktuell sind und dann wieder abflauen“ ([15], S. 1540). Beide setzen dem aus wissenschaftstheoretischer Sicht negativ besetzten Begriff „Mode“ den Begriff „Trend“ entgegen, welcher Themen beschreibt, die in einer Community eher „langfristig“ und „stabil“ behandelt werden. Das zeitraumbezogene starke Themeninteresse lässt sich bspw. anhand von Stichwortanalysen einschlägiger Zeitschriften untersuchen (siehe bspw. [12] sowie [15] für die WI bzw. [14] für die Controllingforschung). Das Kriterium außerordentlich hoher Nennungshäufigkeit eines Schlagwortes über einen kurzen Zeitraum ist jedoch kein sicherer Indikator für hohe Aufmerksamkeit, u. a. weil Wechsel in der Begrifflichkeit in den genannten Untersuchungen nicht berücksichtigt werden. Auch ist die Anwendung teilweise Ermessensfrage: Die Intensität der Aufmerksamkeit als auch die Dauer der Aufmerksamkeit für ein bestimmtes Thema sind abhängig von der üblichen Aufmerk1 Damit soll in diesem Beitrag dediziert auf die Wissenschaft fokussiert werden. Für Einblicke in die Wirkmechanismen der Verbreitung von Moden in der betrieblichen Praxis siehe bspw. [1] oder [9]. 432 samkeit, die Themen in einer Gemeinschaft erhalten, sowie dem betrachteten Untersuchungszeitraum. 2.2. Überzeichnete und nicht rational begründbare Erwartungen an die Leistungsfähigkeit Der Modebegriff lässt sich neben diesen vornehmlich quantitativen Kriterien weitergehend inhaltlich analysieren. Denn die hohe Aufmerksamkeit, die ein Modethema erfährt, beruht auf überhöhten Erwartungen, die i.d.R. nicht vollständig rational begründet sind bzw. nicht überzeugend begründbar sind. Hier lässt sich eine Analogie zu Moden in anderen Kulturbereichen (z. B. Kleidung, Haartracht, Musik) sehen, denn auch hier ist es ganz offen „Geschmacksfrage“ und damit nicht rational über den Nutzen erklärbar, ob man einer Mode anhängt. Auch die Definition des Begriffs Mode als „sich wandelnder Geschmack“ unterstreicht diesen Aspekt. Beiträge zu Managementmoden sprechen diesbezüglich von „kühnen Versprechungen“ ([9], S. 22) und „simple formulas [..] promising a painless solution“ ([1], S. 588) die kennzeichnend für „fads“ und „fashions“ seien. Die Lösungsansätze werden dabei typischerweise der Komplexität des Gegenstandsbereichs nicht gerecht. Vor dem Hintergrund rationaler – bspw. ökonomischer Kriterien – zeigt sich daher für Moden eine Leistungsfähigkeit, die geringer ist als zunächst postuliert: Bei nüchterner Betrachtung und ggf. auch im Nachhinein zeigt sich, dass die hohen Erwartungen an die Leistungsfähigkeit auf wenig fundierten Einschätzungen derer fuß(t)en, die der Modewelle anhängen. Beispielhaft sei hier der „E-Commerce Hype“ genannt, der suggerierte, wirtschaftlicher Erfolg im Internet stelle sich bereits durch gewonnene Aufmerksamkeit („Clicks“) der Webseitenbesucher ein. Mertens ([12], S. 25) als auch Steininger et al. ([15], S. 1540) nennen – ohne weitergehende Konkretisierung – den Beitrag zum „Erkenntnisfortschritt“ oder zum „Stand der Disziplin“ als qualitatives Kriterium zur Einordnung von Themen als Moden oder Trends. Dabei scheint jedoch die angenommene Korrelation von Häufigkeit und Dauer der Verwendung von Schlagwörtern mit deren Beitrag zum langfristigen Erkenntnisfortschritt allzu gewagt (siehe [15], S. 1548). 2.3. Gegenstand der Moden in der WI Die bisherigen Ausführungen sprachen – abstrakt – von Mode-Themen. Betrachtet man genauer, welche Arten von Themen als Moden diskutiert werden, so zeigt sich, dass es häufig „Technologien“ sind, d. h. Klassen von Anwendungssystemen oder Systemkonzepte, bzw. damit verbundene betriebliche Anwendungsfelder. Beispielsweise vertritt Gartner ein eigenes „Hype Cycle“Konzept1: Demnach durchläuft jede neu eingeführte „Technologie“ – so die Annahme – einen prototypischen Lebenszyklus, der anfangs durch überhöhte Aufmerksamkeit geprägt ist, was zu einer Phase (überzogener) Ernüchterung bezüglich der Leistungsfähigkeit einer Technologie führt, auf welche dann schließlich eine reife (produktive) Technologie folgt. Die beiden in der WI durchgeführten empirischen Studien zu Moden deuten darauf hin, dass allgemeine Problemfelder oder Managementaufgaben im IT-Umfeld zwar auch, jedoch weniger häufig als Technologien oder Anwendungsklassen als Schlagwort auftauchen bzw. in der Diskussion als Mode thematisiert werden – dies gilt insbesondere für die Praktikerzeitschrift Computerwoche. Unter den von Mertens ([12], Abbildung auf S. 28) identifizierten Modethemen lassen sich elf als Technologie bzw. Systemklasse einordnen (MIS, Groupware, EDI, Datenbanken, KI, verteilte Systeme, Bürokommunikation, CIM, BTX, Multimedia, Client-Server) und sechs als allgemeine Problemstellung bzw. Managementaufgabe (Downsizing, Outsourcing, Dezentralisierung, Integration, Standardisierung, Sicherheit). In der jüngeren Untersuchung von Steininger et al. lassen sich von den Top-50 Schlagwörtern der Computerwoche (1994-2005) insg. 34 Schlagwörter dem Bereich Hardware/Technologie zu- 1 http://www.gartner.com/pages/story.php.id.8795.s.8.jsp 433 ordnen, bei der WIRTSCHAFTSINFORMATIK (1994-2005) sind unter den Top-50 dagegen nur 21 Schlagwörter zum Themenfeld Hardware/Technologie/System.1 Abschließend sei nochmals betont, dass aus unserer Sicht Themen vielfach nur in einem bestimmten Zeitraum als Mode behandelt werden, d.h. dass ihnen nur zeitlich begrenzt besonders großer Aufmerksamkeit zukommt und auch nur in diesem relativ kurzen Zeitraum die Erwartungen an deren Leistungsfähigkeit überzeichnet und nicht rational begründbar sind. 3. Thesen Die nachfolgende Diskussion orientiert sich an Thesen, die sich aus der Literatur bzw. dem Selbstverständnis der Disziplin WI ableiten lassen. Hierbei können wissenschaftspraktische Thesen, die das Phänomen Modewellen primär deskriptiv beschreiben, und wissenschaftstheoretische Thesen, welche u. a. die „Wissenschaftlichkeit“ von Moden bewerten, unterschieden werden. 3.1. Thesen bezüglich des Ursprungs und des praktischen Umgangs mit Moden Langjährige Vertreter der Disziplin WI sprechen im Rahmen einer Interviewstudie von einer „signifikanten Rolle“ von Modethemen und von „massiver“ Beeinflussung des Fachs durch Praxisentwicklungen ([10], S. 22). Wir nehmen daher an, dass typische Modethemen der Praxis entstammen, bspw. von IT-Beratungsunternehmen eingeführt werden (nicht zuletzt mit dem Ziel der Umsatzgenerierung). Die in der Praxis initiierten Modewellen schwappen dann aufgrund der vielfältigen Schnittstellen von WI-Forschern mit der Praxis (z. B. praxisfinanzierte Forschungsprojekte) auf die wissenschaftliche Disziplin WI über. These T1: „Ursprung in der Praxis“: Moden der Disziplin WI kommen aus der Praxis. Eine weitere These betrifft das Verhältnis zwischen inhaltlich verwandten Moden: Wie bei Kleidungsmoden offenkundig, so gehen wir auch bei Moden in der WI davon aus, dass es „revivals“ gibt, d. h. Modethemen, die in sehr ähnlicher Form wiederkehren. Mertens ([13], S. 1744) beklagt bspw.: „Mit den Modezyklen hängen unnötige Begriffswechsel zusammen.“ Dies erschwert bereits die Verknüpfung aktueller Forschung mit früheren Veröffentlichungen, die zwar thematisch verwandt jedoch mit anderen Begrifflichkeiten bearbeitet wurden. Auch Aussagen aus den Interviews mit langjährigen Vertretern der WI geben Hinweise darauf, dass auf Erfahrungen und Erkenntnisse, die aus früheren Modethemen gewonnen wurden, bei späteren Moden, die inhaltlich verwandt sind, kaum zurückgegriffen wird: „Die Nachteile überwiegen nicht deswegen, weil die Moden da sind, sondern, weil bei der neuen Modewelle auf die Ergebnisse der alten zu wenig zurückgegriffen wird, so dass wir keine kumulative Forschung haben.“ (P. Mertens, zitiert in [10], S. 21) Ebenso wird angemerkt, dass es erst seit kurzem längerfristige Forschungsprogramme einzelner Lehrstühle gäbe [10]. Somit unterstützt dies die These, dass (negative) Erfahrungen aus Moden allenfalls allmählich zu einem Erkenntnisfortschritt und zu einer Weiterentwicklung der Forschungslandschaft führen. Bezüglich der Organisationspraxis formuliert Kieser diesen Evolutionsgedanken wie folgt: „So tragen Moden, wenn schon nicht durch Revolutionen, so doch durch eine Akkumulation von vielen kleinen übrigbleibenden Schritten zum Wandel der Organisationen bei.“ ([9], S. 34). These T2: „Eingeschränkter Lerneffekt“: Auf (negative) Erfahrungen aus früheren – auch inhaltlich verwandten – Moden wird in späteren Moden häufig nicht zurückgegriffen. Daher tragen Modethemen i. d. R. nicht zu einem längerfristigen Erkenntnisfortschritt bei. 1 Aus Platzgründen können die detaillierten Kategorisierungen an dieser Stelle nicht veröffentlicht werden. Sie sind auf Nachfrage bei den Autoren erhältlich. 434 3.2. Wissenschaftstheoretische Thesen Die oben diskutierte definitorischen Eigenschaft, dass Mode-Begriffe während ihrer Hype-Phase besonders große Beachtung finden, wirft die Frage nach den dahinter liegenden Wirkmechanismen auf. Als ein wesentliches Merkmal der Rhetorik von in Managementbestsellern beschriebenen Managementmoden nennt Kieser ([9], S. 24) die Mehrdeutigkeit der zentralen Begriffe. Der Gegenstandsbereich der WI umfasst sowohl betriebswirtschaftliche oder Management-nahe Fragestellungen als auch solche, die als eher „technisch“ bezeichnet werden können, da sie bspw. Struktur und Aufbau von Informationssystemen betreffen. Typische Beispiele für Themen, die aus beiden Perspektiven heraus (unterschiedlich) verstanden werden können, sind IT-Sicherheit, Supply Chain Management, oder Customer Relationship Management.1 Es gibt sowohl in der Praxis als auch in der WI-Forschung Vertreter, die (aus unterschiedlichen Gründen) die eine oder andere Perspektive vornehmlich einnehmen. Ein Mechanismus, um einen Begriff oder ein Thema kurzzeitig besonders bekannt zu machen, besteht darin, diesem seine begriffliche Schärfe zu nehmen oder ihn neu in kontingenter Form einzuführen. So fällt es Vertretern aus Forschung und Praxis sowie Anhängern der unterschiedlichen Perspektiven leichter, sich selbst ein vordergründig verheißungsvolles Thema „auf die Fahnen zu schreiben“. Diese Einschätzung drängt sich bspw. auf, wenn man den Begriff der Business Services betrachtet, welcher zum Leitthema dieser Konferenz bestimmt wurde. These T3: „Verwässerungsthese“: Modewellen gehen mit einer unangemessen kontingenten Begrifflichkeit zentraler, die Modewelle prägender Konzepte einher. Eine weitere für Modewellen definitorische Eigenschaft ist, dass sie – zumindest typischerweise – nicht so leistungsfähig sind, wie es die überhöhte Aufmerksamkeit suggeriert. Es stellt sich somit die Frage nach einer möglichen Ursache für die nicht erfüllten Erwartungen. Eine Vermutung ist, dass die Originalität von Modebegriffen und den dahinter steckenden Konzepten begrenzt ist, was auch eine Erklärung dafür sein kann, warum entsprechende Moden sich nicht zum Trend weiterentwickelten. In Verallgemeinerung der These 2 „Eingeschränkter Lerneffekt“ wird vermutet, dass nicht nur die Hypes, welche vorangegangene Trends unter einem neuen Namen wieder aufgreifen, sondern alle Hypes sich dadurch auszeichnen, dass sie nicht primär inhaltlich innovieren, sondern existierende Konzepte öffentlichkeitswirksam darstellen. These T4: „Begrenzte Originalität“: Modewellen sind konzeptionell eher wenig innovativ, sondern stellen bestehende Konzepte öffentlichkeitswirksam dar und evolutionieren somit allenfalls den Stand der Kunst. 4. Überprüfung der Thesen an ausgewählten Modethemen Zur Diskussion der obigen Thesen beschränken wir uns nachfolgend auf ausgewählte Modethemen, die in der Literatur bereits als solche identifiziert und diskutiert wurden. Die Gegenstände der hier genannten Moden sind dabei sehr unterschiedlich. Es finden sich Geschäftsmodelle, Architekturbzw. Design-Prinzipien für Informationssysteme ebenso wie grundständige Annahmen über vermeintlich neue Funktionsweisen von Ökonomie. Die Begriffe „Expertensysteme“, und „E-Business“ bzw. „Internet-Hype“ wurden im Rahmen der Interviewstudie von langjährigen Vertretern der WI als Moden der WI genannt ([10], S. 2 ff.). Die zeitlich begrenzte überhöhte Aufmerksamkeit, die Expertensystemen in den 1980er Jahren zugekommen ist, und die Problematik deren praktischer Anwendung aufgrund übermäßiger Formalisierung wird bspw. von Frank [3] thematisiert. Das „E-Business“ – zumindest für den Zeitraum Ende der 1990er Jahre bis März 2000 – als Mode eingestuft werden kann, lässt sich aufgrund des Plat1 Eine detaillierte Kategorisierung einschlägiger Begriffe ist auf Nachfrage bei den Autoren erhältlich. 435 zens der Dot-Com Blase leicht nachvollziehbar begründen: Die überzogenen Erwartungen an EBusiness Geschäftsmodelle erzeugten einen Hype, der wie kaum eine andere Mode im Umfeld der WI ganze Märkte neu geschaffen und beeinflusst hat. Ebenfalls „E-Business“ sowie „Application Service Providing (ASP)“ bzw. „Application Service Provider“ heben Steininger et al. ([15], S. 1548 ff.) als Ergebnis der Stichwort-basierten Inhaltsanalyse von Zeitschriftenartikeln als Modethemen hervor. Zusätzlich wird hier „Content Management“ genannt; dieses Thema soll jedoch nicht weitergehend betrachtet werden, da hier nicht in einer für diesen Beitrag hinreichenden Weise von überhöhten Erwartungen ausgegangen werden kann. „Enterprise Application Integration“ (EAI) wird von Aier und Schelp [2] als Modethema (Hype) diskutiert, welches – ihrer Analyse nach – bisher noch keinen Beitrag zur „nachhaltigen Agilität“ des Unternehmens leistet. In thematisch engem Zusammenhang zu EAI steht der Ansatz der „Service Oriented Architectures“ (SOA), welcher von Kaczmarek und Węcel als Mode (buzzword) der WI diskutiert wird und ihrer Einschätzung nach von Softwareunternehmen übermäßig („overused“) und von Beratungsunternehmen falsch („misused“) verwendet wird [8]. Ergänzend sei, nicht zuletzt aufgrund seiner Allgegenwärtigkeit im Call For Papers zu dieser Konferenz, der Begriff „Business Service“ ebenfalls als (potentielle) Mode Gegenstand unserer Untersuchung. Dem Themenbereich „semantische Technologien / Ontologien“ widmen sich schon seit einigen Jahren sowohl in der Informatik als auch in der WI diverse Forschungsgruppen und -projekte. Bezüglich der Leistungsfähigkeit von semantischen Technologien in der betrieblichen Praxis gibt es jedoch eine Reihe kritischer Stimmen (z. B. [5], [7]), die vermuten lassen, dass dieses Themenfeld ebenfalls als Mode mit überhöhten Erwartungen gesehen werden kann. Auch aus den Reihen der WI-Forscher wird Skepsis geäußert: „the project of ontology-based conceptual modelling appears to be impossible in principle“ ([16], S. 74). Die eingeführten ausgewählten Moden der WI können – ohne Zweifel – nicht als zuverlässige empirische Basis dienen, um die aufgestellten Thesen zu stützen. Es wird sich jedoch zeigen, dass sich anhand der ausgewählten Themen bereits durchaus interessante Hinweise und Einblicke bezüglich der Rolle und des Umgangs mit Moden in der WI ableiten lassen. 4.1. These 1: „Ursprung in der Praxis“ Bereits die geringe Auswahl an Modethemen in diesem Artikel vermag diese These zu relativieren, Modewellen würden – zumindest initial – der Praxis entspringen. Zwar entstammt die Mehrzahl der hier untersuchten Hypes der Praxis (SOA, EAI, ASP). Allerdings wurden insbesondere Expertensysteme, semantische Technologien und SOA ebenfalls sehr stark durch die Wissenschaft vorangetrieben. Dies zeigt sich u. a. in einschlägigen Entwürfen von Sprachen, die eine semantisch angereicherte Kommunikation zwischen Informationssystemen erlauben – bspw. als Erweiterung gängiger Internet-Protokolle (z. B. OWL – Web Ontology Language, SOAP – Simple Object Access Protocol) – bzw. in Vorschlägen für Auszeichnungssprachen und Kalküle, die das automatisierte Schließen auf bestehenden Daten- und Regelbasen ermöglichen (Expertensysteme und semantische Technologien). Die in Teilen beeindruckende Produktivität der Forscher bei der Bearbeitung von Modethemen kann dabei durchaus als Chance angesehen werden. Dabei mögen die Motive der Wissenschaftler für die intensive Beschäftigung und Förderung von Modethemen vielfältig sein. In manchen Fällen mag es tatsächlich die Hoffnung oder der Glaube des (jungen) Wissenschaftlers an die Leistungsfähigkeit des entspr. Konzepts zur Problemlösung sein. Folgt man jedoch den Meinungen der in der Interviewstudie befragten langjährigen Vertreter der WI [10], so werden eher opportunistische Interessen verfolgt. Denn die Behandlung von Forschungsthemen, die als en vogue gelten, erhöht die Aufmerksamkeit für die eigene Forschung in Praxis und Wissenschaft und erleichtert somit die Akquisition von Drittmitteln und schafft neue Veröffentlichungsmöglichkeiten. 436 4.2. These 2: „Eingeschränkter Lerneffekt“ In den betrachteten Modewellen lassen sich Evolutionsstufen einer jeweils bestimmten prägenden Idee identifizieren, die sich in verschiedenen Moden wiederholt. Zum einen eint eine grundsätzliche Idee automatisierten Schließens auf formalsprachlich spezifizierten Wissensbasen sowohl die in den 1980ern und 1990ern a la mode gehandelten Expertensysteme als auch semantische Technologien. Expertensysteme sind an ihrem Anspruch der Formalisierung gescheitert [4]. Mittlerweile sehen erste Arbeiten zu semantischen Technologien und Ontologien auch dies als Problem an (z. B. [16]). Diese Argumentation unterstützend merkt Mertens an: „Ganz ähnliche Sachverhalte wurden im Laufe der Jahrzehnte unter Stichworten wie ‘Informationserschließung’, ‘Information Retrieval’, [..] ‘Informationsmanagement’, ‘Business Intelligence’, ‘Selective Dissemination of Information’ (SDI) oder ‘Organizational Intelligence’ untersucht. Im Kern ging es und geht es immer wieder um die Frage, wie man Informationen besorgt, filtert, in der richtigen Aufbereitung zum richtigen Zeitpunkt an die richtigen Empfänger liefert [..]. Die jeweilige Spezialistengemeinde hat sich aber kaum um die Vorgängerarbeiten gekümmert, zuweilen wusste man gar nichts von ihnen.“ ([13], S. 1742) ASP hat – nicht zuletzt, da es im Widerspruch zum Kernkompetenzansatz steht – an Bedeutung verloren, aber ist, zumindest in der Praxis, als Mietsoftware oder „Software-as-a-Service“ wieder im Gespräch. Dies lässt sich bspw. ersehen an Beiträgen bzw. Suchergebnissen auf den onlinePlattformen einschlägiger Praktikerzeitschriften, wie bspw. der Computerwoche oder ComputerZeitung. 4.3. These 3: „Verwässerungsthese“ Verwässerung ist teilweise aber nicht durchgängig Kennzeichen der untersuchten Modewellen. In der für diesen Artikel genutzten Auswahl gibt es eine auffällige (aber wahrscheinlich nicht repräsentative) Zweiteilung zwischen der Wissenschaft und der Praxis entstammender Themen: Themen, die der Praxis entsprungen sein dürften, weisen ein tendenziell hohes Maß an begrifflicher Kontingenz auf – bspw. differenziert Masak ([11], u. a. S. 11) fünf deutliche voneinander abweichende Interpretationen des Begriffes SOA, von einer Entwurfmetapher für Software bis hin zu einer Strukturidee für Services nutzende Organisationen. Auch der Integrationsbegriff (EAI) (z. B. [4]) und der ASP-Begriff (siehe [15]) werden in vielschichtiger Semantik verwendet. Interessanter Weise sind die Kernbegriffe von Themen, die vornehmlich aus den Reihen der Wissenschaft vorangetrieben werden (Expertensysteme, Ontologien – beide in Teilen dem Bereich der Künstlichen Intelligenzforschung zuzurechnen), relativ scharf konturiert. Steininger et al. kommen in ihrer Studie u. a. zu dem Ergebnis, dass in der Praktikerzeitschrift Computerwoche die Spitzen (d. h. die Moden) noch ausgeprägter und die relativen Häufigkeiten der einzelnen Schlagwörter deutlich kleiner sind als in der WIRTSCHAFTSINFORMATIK ([15], S. 1545, 1548). Die Vertreter der WI scheinen sich also zwar ebenfalls mit Modethemen zu befassen, diese aber jeweils gründlicher zu untersuchen. Folglich kann die These aufgestellt werden, dass das Befassen der WI-Forscher mit den Modethemen (der Praxis) zu einer differenzierteren Einschätzung und einem objektiveren Umgang mit den Modethemen in Praxis und Wissenschaft beiträgt. Dies bestätigt mittelbar auch eine auf Controlling-Instrumente gerichtete Literaturstudie: „Die praxisnahen Veröffentlichungen zeichnen überwiegend ein positives Bild der jeweiligen Instrumente, während die wissenschaftlichen Beiträge eher als neutral bis mäßig positiv eingestuft werden können.“ ([14], S. 256) 437 4.4. These 4: „Begrenzte Originalität“ Eine grundsätzliche Stützung der These begrenzter Originalität kann nicht getroffen werden. So ist bspw. das Konzept der Expertensysteme keine triviale Rekonstruktion des Standes der Kunst in den 1980er Jahren. Die Frage der begrenzten Originalität wird allerdings zum einen von den Moden gestützt, die Grundideen älterer Modewellen immer wieder aufleben lassen (siehe hierzu These 2 „Eingeschränkter Lerneffekt“). Zum anderen gilt diese These für die Moden in unserer Auswahl, die einer überaus großen begrifflichen Kontingenz unterliegen, da infolge der Kontingenz ein Neuigkeitsgehalt kaum auszumachen ist. Einigen Moden mangelt es aber teils nicht nur an Originalität, sondern auch an einer guten Begründung. Nicht zuletzt widerprechen die vollmundigen Verheißungen des E-Commerce-Hypes sogar gängigen Lehrmeinungen. 5. Schlussfolgerungen und Handlungsoptionen Die Hypes und Moden der WI werden bislang in wenigen Publikationen thematisiert. Dies mag der Grund dafür sein, dass es schon auf Basis der hier untersuchten (vergleichsweise kleinen) Themenauswahl gelingt, literaturgängige Meinungen zu den Moden der WI zu schärfen bzw. zu widerlegen. Mit Blick auf die hier aufgestellten Thesen können wir zusammenfassen: T 1: Die Modewellen der WI entstammen nicht allein der Praxis. Auch die Wissenschaft beteiligt sich in erkennbarem Maße an der Verstärkung von Modewellen. Einige der Modewellen wurden sogar vornehmlich aus Kreisen der Wissenschaft initiiert und vorangetrieben. T 2: Es ist ein interessantes Phänomen, dass sich inhaltlich bzw. konzeptuell stark ähnelnde Modewellen in zeitlich überschaubaren Abständen unter neuen Begrifflichkeiten ein Revival erfahren, ohne dass die Probleme und Herausforderungen vorangegangener Hypes in den nachfolgenden hinreichend adressiert würden. T 3: Ein verwässerter, kontingenter Aussagegehalt des namensgebenden Kernbegriffes eines Modethemas ist – bezogen auf unsere Auswahl – eine häufige, aber keine durchgängig Eigenschaft von Modewellen. Teilweise sind die Begriffe für eine wissenschaftliche Behandlung angemessen konkret. T 4: Die in einer Modewelle popularisierten Inhalte zeichnen sich teilweise, aber nicht durchgängig, durch eine deutlich eingeschränkte Originalität gegenüber dem jeweiligen Stand der Kunst aus. Zuweilen sind die vorgeschlagenen Konzepte sogar inhaltlich so fragwürdig, dass sie sogar gängigen Lehrmeinungen zuwiderlaufen. Gemäß einem basalen Wissenschaftsideal ist es die vornehme Aufgabe der Wissenschaft, durch wohl begründete und differenzierte Beiträge zum allgemeinen Erkenntnisfortschritt beizutragen. Das Wissenschaftsideal einer angewandten wissenschaftlichen Disziplin impliziert hierbei ein Streben nach Objektivität und Rationalität auch bezüglich (Mode-) Themen der Praxis (vgl. [9], S. 34). Was die Bewältigung realer Modewellen in der Praxis anbelangt, zeigte sich aber die wissenschaftliche WI hierbei teils wenig erfolgreich (vgl. T 2 bis T 4) und – in Teilen – auch wenig obigem basalen Wissenschaftsideal angemessen (vgl. insb. T 1). Für die Organisationsforschung bzw. Betriebswirtschaftslehre zeichnet Kieser ein – aus wissenschaftstheoretischer Sicht – recht pessimistisches Bild bzgl. der Einflussnahme der Managementmoden auf die Organisationsforschung [9]. Für die Disziplin WI kann zumindest festgestellt werden, dass sie nicht in Gänze thematisch von den Einflüssen der Modethemen der Praxis abhängig ist. Man kann durchaus von einer deutlichen thematischen Selbstständigkeit der wissenschaftlichen Community der WI sprechen. Dies zeigt sich bspw. an den von Steiniger et al. (2008, S. 1545) identifizierten Top-50 Schlagwörtern aus der Computerwoche und der WIRTSCHAFTSINFORMATIK (1994-2005): Für die Bereiche Modellierung und Prozessorientierung, die in der 438 WIRTSCHAFTSINFOMRATIK mit 3 bzw. 7 Schlagwörtern unter den Top-50 relativ stark vertreten sind, findet sich in der Top-50 Liste der Computerwoche kein passendes Schlagwort.1 Weiterhin stellt sich die Frage nach dem grundsätzlichen Nutzwert, Modethemen der Praxis in wissenschaftlichen Diskursen zu adressieren. Denn diesbezüglich wirkt die Position der Wissenschaft nicht ideal. Insbesondere sind die zeitlichen Takte, in denen die Wissenschaft arbeitet, nur eingeschränkt dafür geeignet, zeitnah auf Modewellen zu reagieren. Mertens weist bezüglich der Relation zwischen der Lebensdauer einer Modewelle und der Reaktionszeit der Wissenschaft darauf hin, „[..] dass wir [die Wissenschaft] in etwa eine Zeitstrecke von drei bis vier Jahren benötigen, damit ein junger Wissenschaftler – insbes. im Rahmen seiner Dissertation – einen Forschungsgegenstand einigermaßen abgerundet bearbeiten kann“ ([13], S. 1748). In einer vergleichenden Untersuchung von zehn Publikationsorganen der auf die Praxis gerichteten IT-Fachpresse stellen Heise et al. darüber hinaus fest, dass „Die wesentliche Stärke der analysierten Fachzeitschriften im Vergleich zu wissenschaftlichen Zeitschriften [...] ihre Aktualität“ ist, welche sich aus der niedrigen Zeitspanne zwischen Einreichung eines Manuskripts und dessen Veröffentlichung ergibt ([6], S. 21), während die wissenschaftliche Fachliteratur nur mit deutlichem Zeitverzug veröffentlichen (ebd., S. 24). Der Eindruck einer verzögerten Reaktionszeit bestätigt sich auch für die hier untersuchten Modewellen. Das Gros der von uns gefundenen kritischen Beiträge zu Modethemen wurde erst veröffentlicht, nachdem das jeweilige Modethema schon länger diskutiert wurde. Absolventen der Wirtschaftsinformatik, die in die Praxis gehen Beratung durch WI-Professoren und Forschungsgruppen Seminare für Fachleute aus der Praxis (durchgeführt von WI-Professoren und -Forschungsgruppen) Veröffentlichung von Ergebnissen in wissenschaftlichen Zeitschriften Veröffentlichung von Ergebnissen in Praktiker-Zeitschriften Präsentation und Diskussion von Ergebnissen auf Konferenzen Präsentation und Diskussion von Ergebnissen und Trends auf Fachmessen (z.B. CeBIT) Forschungsprojekte mit der Industrie 0 10 20 30 40 50 60 70 80 90 100 % (von insg. 122) nicht + kaum wichtig durchaus + sehr wichtig Abbildung 1: Einschätzung der Wichtigkeit verschiedener Wege, um Forschungsergebnisse der WI in die Praxis zu bringen Im Rahmen einer Umfrage zur Wahrnehmung der Disziplin WI durch CIOs, wurde die Frage „Wie wichtig sind Ihrer Einschätzung nach Absolventen der WI, die in die Praxis gehen, um Forschungsergebnisse in die Praxis zu bringen?“ besonders einhellig mit „durchaus wichtig“ (52,5%) bzw. „sehr wichtig“ (41,8 %) beantwortet (siehe Abbildung 1).2 Dies unterstreicht die These, dass die Verbreitung von Konzepten der Wissenschaft in die Praxis eher langfristig und vor allem über die Ausbildung von Studenten stattfindet, die in der Lehre vermittelte Konzepte der Wissenschaft in die Praxis tragen. Aus wissenschaftspraktischer Sicht haben Modethemen der Praxis auch eine positive Seite. Sie ermöglichen der Wissenschaft einen leichteren Zugang zum Diskurs mit der Praxis. Aufgabe der 1 Die detaillierten Kategorisierungen sind auf Nachfrage von den Autoren erhältlich. Die Umfrage zur Wahrnehmung der WI durch CIOs wurde im Rahmen des Projektes IFWIS durchgeführt. Nach mehreren Pre-Tests erfolgte Ende November 2007 der Versand der papierbasierten Fragebögen an die Zielgruppe. Der Zugang zur Zielgruppe wurde durch die freundliche Unterstützung von Prof. Helmut Krcmar (TU München) über die Mitgliederliste des CIO-Circle (http://www.cio-circle.org/) ermöglicht. Bis Februar 2008 wurde eine Rücklaufquote von 18,86 % (122) erzielt. Ein detaillierter Ergebnisbericht ist in Vorbereitung. 2 439 Wissenschaft sollte dann jedoch sein, eine kritisch differenzierte Sicht auf die Leistungsfähigkeit aktueller Modethemen zu vertreten. Dabei sollte sich die akademische Welt insbesondere dann zu Wort melden, wenn eine Modewelle Erkenntnissen der Wissenschaft in erkennbarer Weise widerspricht. Die Ergebnisse der Umfrage deuten darauf hin, dass es erfolgversprechend ist, die kritische Sicht der Wissenschaft auf aktuelle Moden im Rahmen von Beiträgen für Praktikerzeitschriften oder Konferenzen zu thematisieren. Auch Forschungsprojekte mit der Industrie werden von den befragten Praktikern mit deutlicher Mehrheit als wichtig eingestuft, um Erkenntnisse der Wissenschaft in die Praxis zu bringen. Vor dem Hintergrund der Zeitzyklen der Wissenschaft scheint es jedoch grundsätzlich angeraten auf längerfristige Forschungsprogramme zu fokussieren und dabei ggf. inhaltlich verwandte Modethemen zu adressieren. 6. Literatur [1] ABRAHAMSON, E.: Managerial Fads and Fashions: The Diffusion and Rejection of Innovations, in: Academy of Management Review, Bd. 16, 1991, S. 586-612. [2] AIER, S., SCHELP, J.: EAI und SOA – Was bleibt nach dem Hype?, In Bichler, M., Hess, T., Krcmar, H., Lechner, U., Matthes, F., Picot, A., Speitkamp, B., Wolf, P. (Hrsg.): Multikonferenz Wirtschaftsinformatik (MKWI08), Feb 26-28, 2008, München, GITO-Verlag, Berlin, 2008, S. 1469-1480. [3] FRANK, U: Expertensysteme: Neue Automatisierungspotentiale im Büro- und Verwaltungsbereich?, Gabler, 1988. [4] FRANK, U.: Integration – Reflections on a Pivotal Concept for Designing and Evaluating Information Systems. In: Kaschek, R.; Kop, C.; Steinberger, C.; Fliedl, G. (Hrsg.): Information Systems and e-Business Technologies. 2nd International United Information Systems Conference UNISCON 2008, Springer, Berlin, Heidelberg, 2008, S. 111-122. [5] HANIEWICZ, K.; KACZMAREK, M.; ZYSKOWSKI, D.: Semantic Web Services Applications – a Reality Check, In: WIRTSCHAFTSINFORMATIK, Bd. 50, Nr. 1, 2008, S. 39-45. [6] HEISE, D.; SCHAUER, C.; STRECKER, S.: Informationsquellen für IT-Professionals: Analyse und Bewertung der Fachpresse aus Sicht der Wirtschaftsinformatik, ICB Research Report, Institut für Informatik und Wirtschaftsinformatik (ICB), Universität Duisburg-Essen, Campus Essen, Nr. 15, April 2007 (40 S.). [7] HUBER, H.: Auf dem Weg zum wertorientierten Wissensmanagement. Keynote auf der Tagung Wissensmanagement 2007, 28. - 30. März 2007, Potsdam. (online: http://www.wm-tagung.de/) [8] KACZMAREK, T.; WECEL, K.: Hype over Service Oriented Architecture Continues. WIRTSCHAFTSINFORMATIK, Bd. 50, Nr. 1, S. 52-58. [9] KIESER, A.: Moden & Mythen des Organisierens. In: Die Betriebswirtschaft, Bd. 56., 1996, S. 21-39. [10] LANGE, C.: Entwicklung und Stand der Disziplinen Wirtschaftsinformatik und Information Systems – Interpretative Auswertung von Interviews: Teil III Ergebnisse zur Wirtschaftsinformatik, ICB – Research Report, Universität Duisburg-Essen, Nr. 4, 2006. [11] MASAK, D.: SOA? – Serviceorientierung in Business und Software, Springer Berlin Heidelberg, 2007. [12] MERTENS, P.: Wirtschaftsinformatik – Von den Moden zum Trend. in: König, W. (Hrsg.), Wirtschaftsinformatik '95, Wettbewerbsfähigkeit – Innovation – Wirtschaftlichkeit, Heidelberg 1995, S. 25-64. [13] MERTENS, P.: Gefahren für die Wirtschaftsinformatik – Risikoanalyse eines Faches. Proceedings Wirtschaftsinformatik 2005, S. 1733-1754. [14] SCHÄFFER, U.: Die Verbreitung von Wissen zu Controlling-Instrumenten – Eine Analyse der Veröffentlichungstätigkeit in deutsch- und englischsprachigen Fachzeitschriften. Gabler, 2007. [15] STEININGER, K.; RIEDL, R.; ROITHMAYR, F.: Zu den Begrifflichkeiten und Moden der Wirtschaftsinformatik: Ergebnisse einer inhaltsanalytischen Betrachtung. In: Tagungsband Multikonferenz Wirtschaftsinformatik (MKWI) 2008, München, S. 1539-1550. [16] WYSSUSEK, B.: On Ontological Foundations of Conceptual Modelling, Scandinavian Journal of Information Systems, 2006, Bd. 18, Nr. 1, S.63-80. 440 TOWARDS A RESEARCH METHOD FOR THEORYDRIVEN DESIGN RESEARCH Andreas Gehlert1, Michael Schermann2, Klaus Pohl3, Helmut Krcmar4 Abstract In this paper we outline a new methodical approach for integrating theories into the design research process. Incorporating theories in design projects allows design researchers to reason on the effects of the IT artifact prior to its realization. We argue that design decisions should be transparent claims of utility based on theory-grounded arguments. Documenting design decisions requires the design researcher to integrate appropriate theories and document the rationale behind a particular design decision. Overall, we demonstrate on the example of constructing a new modeling grammar how to integrate theories in the design research process and discuss conflicts which occur when applying these theories. 1. Introduction “But how does such work contribute to the progress of the IS discipline?” [27, p. 8] The concept of theory is a cornerstone of improving the inter-subjectivity of design artifacts [25]. The relation between theory and design is twofold [15, cf. Figure 1]: First, theories can be used to derive design artifacts such as airplanes, information systems, computers etc. (theory before design). This relation is based on the assumption that any design artifact cannot work if it does not comply with the laws embodied in a theory. In addition, the artifact may be significantly improved if the underlying theory is explicit. For instance, “… one can design an airplane wing on the basis of tested, technological (black-box) rules, but such wings can be designed much more efficiently on the basis of tested and grounded technological rules, grounded on the laws and insights of aerodynamic and mechanics.” [23, p. 228] Second, theories can be extracted from design artifacts to initiate theory building [17, theory after design]. The main reason for this activity is not only to extend the IS theory base but also to generalize design knowledge and to facilitate the comparison of design artifacts [27]. 1 Software Systems Engineering, Institute for Computer Science and Business Information Systems, Universität Duisburg-Essen, Schützenbahn 70, 45117 Essen, Germany 2 Chair for Information Systems, Technische Universität München, Boltzmannstr. 3, 85748 Garching, Germany 3 Software Systems Engineering, Institute for Computer Science and Business Information Systems, Universität Duisburg-Essen, Schützenbahn 70, 45117 Essen, Germany 4 Chair for Information Systems, Technische Universität München, Boltzmannstr. 3, 85748 Garching, Germany 441 Figure 1: Elements of theorizing in design research based on Nunamaker and Chen [15] In this paper, we focus on the contribution of theories for building design artifacts in the information systems discipline, e. g. we assume that already existing IS theories inform the design researcher when creating IT artifacts. Although many IS researchers argue that the design research process should be informed by existing theories [e. g. 8; 13; 22; 25], we argue that methodological guidance is needed to systematically integrate theories in the design research process. We base our argumentation on the notion of design rationales and show how theories can be used to support the decision making process in design research. Design rationales serve as a documentation of the design process and enable the design researcher to trace his or her design decisions [11; 16]. In current design rationale approaches, however, the decision making process is guided by the experience of the design researcher only. This experience may include best practices and/or theoretical knowledge. Since the link between a particular design decision and the theoretical knowledge leading to this decision is implicit, design decisions cannot be clearly traced back to theoretical knowledge. In this paper we show how existing design rationale approaches can be combined with theoretical knowledge to overcome this problem. The remainder of the paper is organized as follows: In section 2, we review existing design research approaches. We show that research has primarily focused on the structure of theories in design research. We describe our approach in the third section and discuss its benefits as well as its limitations. The paper closes with a summary of the results and an outlook of our further research plans. 2. Related Research on Theorizing in Design Research Many authors addressed the methodological aspect of theorizing activities in design research [8; 13; 19; 24; 25]. In their seminal paper, Hevner et al. [9] for instance propose seven guidelines to determine the contribution of design research results to the IS knowledge base. For instance, their guideline 3 requires that the “… utility, quality, and efficacy of [the] design artifact must be rigorously demonstrated.” To meet human requirements, the resulting artifact is usually complex and the result of an iterative process [22]. Consequently, Hevner et. al’s guideline 6 characterizes the design process as a search process. However, following both guidelines constitute a problem for the design researcher. They need to document and trace their decision-making process and the underlying information, e. g., requirements, design proposals, and development records. For instance, evaluating the quality of an artifact requires documenting the relationship of initial requirements, their evolution during the design process and the corresponding aspects of the artifact that addresses these requirements [24]. 442 Therefore, design researchers have focused on providing a structure for systematizing and justifying decisions during the design process. Table 1 shows that all approaches provide categories for documenting design decisions: requirements, a corresponding design proposal and means for justifying the design proposal. Furthermore, all approaches require design researcher to specify ways to evaluate the design proposal. Additionally, Gregor and Jones (2007) and Schermann et al. (2007) provide a category to reflect the iterative character of design processes and the evolution of design artifacts. Guidance on how to... Elements of design theorizing Table 1: Existing approaches to design theorizing in IS research However, Table 1 clearly shows that all approaches fail to provide methodical guidance on the actual process of theorizing in design research. No guidance is given on how to relate design decisions to suitable theoretical justification. Overall, we argue that the process of developing the artifact requires integrated theorizing activities. In the remainder of this paper we show how to document design decisions by developing theory-based design arguments. 3. Justifying Design decisions with Theories The structure of our approach, which is explained in this section, is depicted in Figure 2. To further describe this structure we use the construction of a new modeling grammar as running example. The description is split into three parts: First, the classical design research perspective is introduced. This perspective also provides the goals and requirements of the running example. Second, theories, which are relevant for our example, are elicited and the structure of theories is described. Lastly, design rationale – the integrating element between this theoretical perspective and the design research perspective is introduced. 443 Figure 2: Constructs of our approach 3.1. Design Research Perspective Each design process starts with goals [20]. Generally, goals give a coarse-grained picture of the envisioned IT artifact. The overall design goal in our example is the “construction of a conceptual modeling grammar for inexperienced modelers” [e. g. 28]. Goals are further decomposed into requirements. This decomposition process serves two purposes: First, the design process can be traced more easily by specifying what makes up this goal. Second, the decomposition of a goal into requirements allows evaluating the IT artifact. To achieve this measurability of all requirements, each requirement is attributed with indicators. The desired outcome of this measurement is described as value (cf. black elements in Figure 2). The decomposition of the goal into measurable indicators is described in the following exhibit: Exhibit 1: According to Wand and Weber [26, p. 364] a modeling grammar is a set of modeling constructs representing some proportion of the real world together with rules describing the lawful combinations of these constructs. The authors argue that such a modeling grammar should enable an efficient interpretation of its models [26, p. 366]. To interpret a model it should be easy to understand. To use a model it should aid the model interpreter when solving problems with this model. Hence, we decompose the general goal into two requirements “models should be easy to understand” (Rf-1) and “problems should be easy to solve with the models” (Rf-2; cf. Figure 3). The requirement Rf-2 should be measured by the property “problem solving accuracy” and the design researcher expects at least 75% problem solving accuracy during the evaluation of the artifact. Consequently, the design researcher assigns the value 75% to the property “problem solving accuracy”. Rf-1 is decomposed accordingly. Figure 3: Goal Decomposition 444 In the following, we assume that requirements with different operationalizations, e. g., different sets of indicators are different and requirements with equivalent sets of indicators are identical. Consistency Rule 1: Requirements with different sets of indicators are different; requirements with equivalent sets of indicators are identical. To understand consistency rule 1 we need to express what we understand by different and identical indicators. Two indicators are said to be equivalent if they describe identical real world proportions. The indicators are different if they describe different real world proportions. Furthermore, two sets of indicators A and B are equivalent if for each indicator in set A there is an equivalent indicator in set B and vice versa. If this condition does not hold both sets are different. So far we have followed traditional design science approaches. The next question is how to derive solutions, which fulfill the requirements. Since, solving problems is generally characterized as creative activities, design researchers implicitly draw upon theoretical knowledge [8; 14; 20; 22]. Achieving traceability in this creative task, the design researcher needs to link his or her existing theoretical knowledge to the specific characteristics of the IT artifact. 3.2. Theories in IS Research We need to further investigate the structure of theories to prepare their integration with a rationale management system in the next section. A theory can be described as set of hypotheses ([2]; see [7] for other definitions of theory in IS research). A hypothesis is a cause-effect relationship based on at least two constructs [5]. One construct represents the hypothesis’ cause and the other construct its proposed effect. Each construct may be represented by a set of indicators (reflexive construct) or is causing these indicators (formative construct) [6]. Overall, the indicators operationalize the construct and are, therefore, the way the construct is measured during theory testing. This notion of theory is represented by the white elements in Figure 2. Given that the construct is well described by its indicators (construct validity) we can conclude: Consistency Rule 2: Constructs with different sets of indicators are different; constructs with equivalent sets of indicators are identical. For our running example we use theoretical hypotheses from the modeling research domain, which closely fit our goals of understandable models and models, which facilitate problem solving. These hypotheses are described in the next exhibit: Exhibit 2: We apply the work of Burton Jones & Weber [4] and Bodart et al. [1] for our design work. Both papers show how to measure comprehension of models and their problem solving capability. Furthermore, they suggest hypotheses, which are relevant for our design problem. Bodart et al. [1] describe the construct surface level comprehension which is measured by the indicators “proportions of entities recalled correctly”, “proportion of relationships recalled correctly”, “proportion of attributes recalled and named correctly”, “proportion of attributes recalled and typed correctly” and “proportion of relationships recalled correctly with correct cardinalities” [1, pp. 391]. Bodart et al. failed to falsify the hypothesis that the existence of optional properties has a positive impact on surface level comprehension using a free recall experiment with 52 participants. Therefore, their hypothesis is still valid (not falsified). Burton-Jones & Weber [4] measure the “comprehension” with the indicator “recall accuracy”. The authors also failed to falsify the hypothesis that the existence of properties of relations negatively influences the comprehension of the model in a controlled experiment with 76 participants. Since the hypothesis was not falsified, it is still valid. Please note that model comprehension is measured with different indicators in the studies by Burton-Jones and Weber and Bodart et al. respectively. According to our 445 consistency rule 2 we cannot integrate the constructs but have to represent them separately (constructs C-3 and C-4 in Figure 4). Both papers measure “problem solving” by the indicator “accuracy”. Further on, both studies show that optional properties and properties of relations both have negative impacts on problem solving and provided empirical evidence for their claims by experimentation with 76 participants in the Burton-Jones and 96 participants in the Bodart et al. studies. The resulting set of the hypotheses is presented in Figure 4. Figure 4: Theory of a Conceptual Modeling Grammar Currently, we have explained the design research and the theoretical perspectives. In the next section we combine both perspectives by introducing the notion of design rationale. 3.3. Rationale Management Perspective Design Rationales (DR) are founded in argumentation theory, which states that an argument always contains four elements [21]: claims (C), grounds (D), warrants (W) and rebuttals (R). Claims are always made on the basis of the presented grounds, e. g. data or facts. The warrant links the claim with grounds. A rebuttal represents known exceptions of this argument (see Figure 5). When applying DR approaches to IT artifacts, the claim of an IT artifact is to have some utility, which is caused by its specific characteristics. While this claim is substantiated by experience in traditional design science approaches, we argue to use theoretical hypotheses. These cause-effect relationships are implemented as goal-means relations in IT artifacts and are, therefore, used as warrant for the design argument. The rebuttal in this setting is represented by hypotheses, which may contradict the warrant’s hypothesis (see Figure 5). Figure 5: Structure of design arguments [based on 3, pp. 44] Although the basic argumentation structure was implemented in many DR approaches [cf. 11 for an extensive review], these approaches extend and/or modify the Issue Based Information Systems (IBIS) approach, which we also apply here [10]. In IBIS design problems are represented by issues. As issues in IBIS represent agreed problems to be resolved they are best represented as grounds in Toulmin’s argumentation principle. Positions are assigned to issues and, thereby, claim to resolve 446 this issue (claims). In the subsequent discussion process, arguments can be brought forward to support or to rebut a position (warrant and rebuttal). According to our arguments, these positions should be linked to hypotheses to ensure their traceability to theoretical knowledge. When applying theories to design, the design researcher has to map requirements to “suitable” hypotheses. We define two consistency rules for this mapping: Consistency Rule 3: Only requirements and constructs with identical sets of indicators can be matched. Consistency Rule 4: Requirements can only be mapped to constructs which participate as effects in at least one hypothesis. Consistency rule 3 ensures that the requirement exactly matches the theoretical construct. We thereby assume that the indicators define the requirement and the theoretical constructs fully (consistency rules 1 and 2). Consequently, a requirement, which is matched to a theoretical construct with diverging sets of indicators, implies that the requirement and the theoretical constructs have different meanings. In other words, consistency rule 3 prevents that requirements are mapped to theoretical constructs with different meanings. Consistency rule 4 ensures that requirements are matched with the “correct side” of the hypothesis. This mapping is described in the following exhibit: Exhibit 3: In exhibit 1 we introduced the requirement “models should be easy to understand” (Rf-1) and “problems should be easy to solve with the models” (Rf-2). To map these requirements to the hypotheses of exhibit 2, we must find appropriate theoretical constructs, which share the same set of indicators. According to consistency rule 3, we can only map Rf-1 to the construct “surface level comprehension” and Rf-2 to the “problem solving” construct. Since both constructs are effects in at least one hypothesis, this mapping is valid (consistency rule 4). As argued above the warrant of an argument is represented by a hypothesis. More precisely the warrant is expressed by the hypothesis’ construct, which represents its cause. In addition, the warrant assigns values to all the construct’s indicators. These vales represent the design researcher’s decision on how to implement the construct in the latter IT artifact. Due to conflicting requirements, it may be possible that two different warrants exist for the same requirement. Warrants conflict with each other if and only if they assign different values to at least one indicator. This is expressed by the following consistency rule: Consistency Rule 5: A conflict is raised if and only if two warrants assign different values to at least indicator. Conflicts can be theoretically traced back to conflicting causes of different hypotheses. It means that the respective warrants cannot be implemented together in the final IT artifact. Additionally, such a conflict cannot be resolved by theory since it originates from conflicting requirements. The design researcher has to manually choose between the conflicting positions by prioritizing the requirements. The resolution of the conflict is embodied in the final IT artifact. This decision is described in the following exhibit: Exhibit 4: After the mapping of the requirements to the theoretical constructs, warrants can be formulated based on the hypotheses from exhibit 2. For instance, the research of Bodart et al. [1] indicates that avoiding optional properties in models enhances problem solving. Consequently, one way to achieve problem solving is to avoid optional properties in models. This fact is expressed by position P-1 (cf. Figure 6). Hence, the warrant assigns the value “false” to the indicator “diagrams with optional properties” to illustrate how the position will be considered in the design. However, we also want to achieve “surface level comprehension” and we know from theory that diagrams with optional properties help to attain this goal (P-3). Consequently, we assign the value 447 “true” to the indicator “diagrams with optional properties”. Now we can analyze the resulting conflict. Obviously, we cannot have diagrams with and without optional properties at the same time. So, we must decide whether to include the optional properties construct in the modeling grammar. To visualize this, we raise a conflict between the conflicting positions (I-1 in Figure 6). This conflict must be solved by the design researcher. As discussed above this decision cannot be guided by theory because it reflects contradicting requirements. According to our theory it is not possible to achieve surface level comprehension and problem solving with the means “optional properties” at the same time. In our example, the design researcher decides to avoid optional properties in the modeling grammar. This decision is documented by the IT artifact S-1. Figure 6: Rationale Management 3.4. Discussion In line with Walls et al. [25] we have argued that hypotheses should be used when designing IT artifacts. Furthermore, we have shown that the systematic usage of hypotheses implies that the hypotheses’ constructs and the requirements must have exactly the same granularity and scope. This granularity and scope is expressed via the set of indicators of theoretical constructs and requirements. A mismatch of requirements and theory can be traced back to the following four situations: 1. There is no theoretical construct that shares at least one indicator for one requirement. In this situation there is no applicable theory for the design in focus. 2. The theoretical constructs have more indicators than the respective requirement, so that the theory is more fine grained than the requirement. 3. In case the theoretical construct has fewer indicators than the requirement the theory is coarser grained than the requirement. 4. The requirement and the theoretical construct share some indicators and differ in other indicators so that the theory and the requirements are incompatible. In the situations two, three and four the design researcher has the choice to modify the requirement’s indicators to achieve the same granularity and scope than the theoretical construct. If the theoretical construct is more fine grained than the requirement, the design researcher may decide to add additional indicators to the respective requirement. In this way, theoretical knowledge informs design research and helps the design researcher to decide how to measure requirements. The value of such adapted IT artifact’s requirements has recently been demonstrated by Maiden [12]. With regard to the first situation, the design researcher may decide to proceed without a modification of the requirement’s indicators and, therefore, without theoretical support [2]. In this case the design researcher can always construct the IT artifact based on experience [18]. However, our 448 framework requires documenting implicit hypotheses used during the design process as well. In this case, hypotheses are a “side-product” of our proposed methodology. As requirements are specialized by indicators to allow for their measurement (see above) they can be directly mapped to a theoretical construct (effect, see consistency rule 3). The same can be said about the warrant, which the design researcher extracts from the IT artifact (cause). Consequently, the derived hypotheses result directly from the design work. After a successful evaluation of the IT artifact, the designer may hand the derived hypotheses over to an empirical researcher who tests these hypotheses. This two-way-exchange between theoretical and design knowledge facilitates the intertwining of design research and theoretical research. 4. Conclusion and Outlook In this paper we presented a methodical approach for substantiating and documenting design decisions with theories. The integration of references to theories in DR approaches enable the design researcher to anticipate the characteristics of the design before the artifact is instantiated. Even in the case of missing theories, our approach requires the design researcher to explicate his or her background knowledge as hypotheses. The evaluation of the results of theory-based artifacts may stimulate theory development and testing and provides a link between design research and theoretical research. Furthermore, our approach helps design researchers to trace, revise and enhance design decisions during design research processes. Our approach also clarifies the task of evaluating the design artifact by integrating theories into design and we can identify three types of evaluation [29]: 1. In output-oriented evaluation the design researcher tests whether the artifact has the required quality, i. e. whether the artifact is appropriately implemented. Thus, the objective is to determine the gap between the required and implemented characteristics of the artifact. Overall, output-oriented evaluation stimulates the improvement of the artifact itself. 2. In outcome-oriented evaluation the design researcher has to substantiate the claim of utility of the artifact, i. e. to show whether the IT artifact attains its goals. Failing to attain the goals can then be traced back to an inappropriate set of design arguments. Hence, outcome oriented evaluation shows how to improve the desired characteristics of the artifact. 3. However, if outcome-oriented evaluation shows that the chosen set of design arguments is inappropriate for attaining the goal, “… an anomaly has arisen and the [applied] theory is suspect” [27, p. 9]. Consequently, the theory used in design should be (re)evaluated to find out whether the theory is actually correct or whether the deviation from the design goal has another cause. In any case, the evaluation of theory-based artifacts creates data-sets that stimulate theory development and refinement. However, our approach also shows an important limitation of theorizing in design research: Theory-based design research requires theories with a similar granularity level to link requirements with constructs of theories. Although, we could find appropriate theories in the case of our example, suitable theories are not available for every design issue. Therefore, we enable the researcher to explicate his or her own hypotheses which may then be subject to empirical research. Furthermore, different construct definitions in different versions of theories or different replication scenarios complicate the use of such theories in design work. Here, methodological guidance is required to resolve such conflicts. However, these limitations do not corrode our approach – as they do not 449 conflict with its underlying assumptions – but provide an argument for a closer connection between the design research and the empirical research domains. 5. References [1] BODART, F. et al., Should Optional Properties Be Used in Conceptual Modelling? A Theory and Three Empirical Tests, in: Information Systems Research 12 (2001) 384-405. [2] BRIGGS, R. O., On theory-driven design and deployment of collaboration systems, in: International Journal of Human-Computer Studies 64 (2006) 573-582. [3] BROCKRIEDE, W.; EHNINGER, D., Toulmin on Argument: An Interpretation and Application, in: Quarterly Journal of Speech 46 (1960) 44-53. [4] BURTON-JONES, A.; WEBER, R., Understanding Relationships with Attributes in Entity-Relationship Diagrams, Proceedings of the 20th International Conference on Information Systems (ICIS 1999), Charlotte, NC, USA, 1999. [5] CHMIELEWICZ, K., Forschungskonzeptionen der Wirtschaftswissenschaft, C. E. Poeschel Verlag, Stuttgart, Germany, 1979. [6] FREEZE, R. D.; RASCHKE, R. L., An Assessment of Formative and Reflective Constructs in IS Research, in: Österle, H., Schelp, J.,Winter, R., (Eds.), Proceedings of the 15th European Conference on Information Systems (ECIS2007), June 7-9 2007, St. Gallen, Switzerland, University of St. Gallen, St. Gallen, 2007, pp. 1481-1492. [7] GREGOR, S., The Nature of Theory in Information Systems, in: MIS Quarterly 30 (2006) 611-642. [8] GREGOR, S.; JONES, D., The Anatomy of a Design Theory, in: Journal of the Association for Information Systems 8 (2007) 313-335. [9] HEVNER, A. R. et al., Design Science in Information Systems Research, in: MIS Quarterly 28 (2004) 75-105. [10] KUNZ, W.; RITTEL, H. W. J., Issues as Elements of Information Systems, Institute of Urban and Regional Development, University of California, Berkeley, CA, USA, 1970. [11] LOURIDAS, P.; LOUCOPOULOS, P., A Generic Model for Reflective Design, in: ACM Transactions on Software Engineering Methodology 9 (2000) 199-237. [12] MAIDEN, N., Servicing Your Requirements, in: IEEE Software 23 (2006) 14-16. [13] MARKUS, M. L.; MAJCHRZAK, A.; GASSER, L., A Design Theory for Systems that support emergent Knowledge Processes, in: MIS Quarterly 26 (2002) 179-212. [14] NEWELL, A.; SIMON, H. A., Human Problem Solving, Prentice-Hall, Englewood Cliffs, NJ, USA, 1972. [15] NUNAMAKER, J. F.; CHEN, M., Systems Development in Information Systems Research, in: Journal of Management Information Systems 7 (1991) 89-106. [16] REGLI, W. C. et al., A Survey of Design Rationale Systems: Approaches, Representation, Capture and Retrieval, in: Engineering with Computers 3/4 (2000) 209-235. [17] ROMME, A. G.; ENDENBURG, G., Construction Principles and Design Rules in the Case of Circular Design, in: Organization Science 17 (2006) 287-297. [18] SARKER, S.; LEE, A. S., Using a Positivist Case Research Methodology to Test Three Competing Theories-InUse of Business Process Reengineering, in: Journal of the Association for Information Systems 2 (2002) 1-74. [19] SCHERMANN, M.; BÖHMANN, T.; KRCMAR, H., A Pattern-based Approach for Constructing Design Theories with Conceptual Models, in: Österle, H., Schelp, J.,Winter, R., (Eds.), 15th European Conference on Information Systems (ECIS 07), University of St. Gallen, St. Gallen, Switzerland, 2007, pp. 1368-1379. [20] SIMON, H. A., The Sciences of the Artificial, The MIT Press, Cambridge, MA, USA, 1969. [21] TOULMIN, S., The Uses of Argument, Cambridge University Press, Cambridge, MA, USA, 1958. [22] VAISHNAVI, V.; KUECHLER, W., Design Research in Information Systems, 2004. [23] VAN AKEN, J. E., Management Research Based on the Paradigm of the Design Sciences: The Quest for FieldTested and Grounded Technological Rules, in: Journal of Management Studies 41 (2004) 219-246. [24] VERSCHUREN, P.; HARTOG, R., Evaluation in Design-Oriented Research, in: Quality & Quantity 6 (2005) 733-762. [25] WALLS, J. G.; WIDMEYER, G. R.; EL SAWY, O. A., Building an Information System Design Theory for Vigilant EIS, in: Information Systems Research 3 (1992) 36-59. [26] WAND, Y.; WEBER, R., Research Commentary: Information Systems and Conceptual Modeling -- A Research Agenda, in: Information Systems Research 13 (2002) 363-377. [27] WEBER, R., Toward A Theory of Artifacts: A Paradigmatic Base for Information Systems Research, in: Journal of Information Systems 1 (1987) 3-19. [28] WEBER, R., Conceptual Modelling and Ontology: Possibilities and Pitfalls, in: Journal of Database Management 14 (2003) 1-20. [29] WEISS, C. H., Evaluierungsforschung: Methoden zur Einschätzung von sozialen Reformprogrammen, Westdeutscher Verlag, Opladen, 1974. 450 BEURTEILUNGSKRITERIEN INTERNATIONALER FACHZEITSCHRIFTEN IM UMFELD DER WIRTSCHAFTSINFORMATIK Karl Kurbel, Ilja Krybus, Ivo Stankov1 Kurzfassung Veröffentlichungen in internationalen Fachzeitschriften tragen dazu bei, die Sichtbarkeit der Wirtschaftsinformatik außerhalb des deutschen Sprachraums zu verbessern. Sie erfolgen meist in Organen benachbarter Disziplinen wie „Information Systems“ und „Computer Science“. Die Diskussion in der WI-Community über die Kriterien, nach denen internationale Fachzeitschriften wissenschaftliche Beiträge beurteilen, und die Erfolgswahrscheinlichkeit bei Einreichungen gab den Anstoß zu einer empirischen Untersuchung. Gegenstand der Untersuchung sind die von 175 Zeitschriften angegebenen Beurteilungskriterien. Die über die Homepages der Zeitschriften kommunizierten Anforderungen an einzureichende Beiträge wurden inhaltsanalytisch ausgewertet. 1. Einleitung – Motivation für die Untersuchung In der Wirtschaftsinformatik wird zur Zeit verstärkt über die wissenschaftliche Orientierung, die Veröffentlichungskultur und die Positionierung des Fachs im internationalen Wissenschaftsgefüge diskutiert. Bei Veröffentlichungen werden die in Frage kommenden internationalen Publikationsorgane meist im Bereich „Information Systems“ (IS) vermutet. Information Systems versteht sich jedoch überwiegend als Disziplin, in der verhaltenswissenschaftlich geforscht und veröffentlicht wird. Das bevorzugte Forschungsinstrumentarium ist quantitativ-empirisch, mit starkem Gewicht auf Umfragen zu realen Phänomen und ihrer Erklärung mit Hilfe statistischer Methoden. Ein Großteil der Wirtschaftsinformatiker arbeitet hingegen gestaltungsorientiert und gewinnt neue Erkenntnisse häufig explorativ („construction and building approach“ im Sinne von Backlund [1]). Die Untersuchungen von Wilde und Hess [15] deuten darauf hin, dass die Mehrzahl der Forscher konstruktionsorientiert vorgeht. Dazu wird oft ein Prototyp entwickelt, mit dem die Machbarkeit der zugrunde liegenden Konzepte gezeigt wird. In der Definition des Profils der Wirtschaftsinformatik, auf die sich die Wissenschaftliche Kommission Wirtschaftsinformatik bereits 1993 verständigte [16], wird dieser Ansatz deutlich hervorgehoben: Die Wirtschaftsinformatik habe eine Gestaltungsaufgabe, und sie sei in diesem Sinne (auch) eine Ingenieurwissenschaft2. 1 2 Europa-Universität Viadrina Frankfurt (Oder) "Die Wirtschaftsinformatik ist weiterhin eine Ingenieurwissenschaft, da insbesondere die Gestaltung von IKS eine Konstruktionssystematik verlangt. ... Die Gestaltung verlangt nach der ingenieurwissenschaftlichen Erstellung von 451 Bei der Wahl eines internationalen Publikationsorgans zeigt sich nun das Dilemma, dass zwischen Wirtschaftsinformatik und Information Systems entscheidende Unterschiede bestehen – sowohl in den Forschungsgegenständen als auch insbesondere in den Forschungsmethoden [6]. Gutachter von IS-Zeitschriften und -Proceedings beurteilen Beiträge i.d.R. entsprechend dem verhaltenswissenschaftlichen Forschungsstil und messen dem methodischen Ansatz das höchste Gewicht bei – häufig auf Kosten des Innovationsgehalts, wie selbst der Herausgeber der Zeitschrift MIS Quarterly jüngst resümierte: Auch sehr gute Beiträge schaffen nicht die Gutachterhürde, wenn sie methodisch nicht den in der IS-Community hochgehaltenen puristischen Maßstäben entsprechen3 [14]. Informatiknähere internationale Zeitschriften scheinen dem konstruktivistischen Forschungsansatz, wie er in großen Teilen der Wirtschaftsinformatik verfolgt wird, näher zu kommen. In Rankings hoch bewertete Publikationsorgane sind z.B. von ACM (Association for Computing Machinery) und IEEE (Institute of Electrical and Electronics Engineers) herausgegebene Zeitschriften, in denen man häufig qualitativ hochstehende Wirtschaftsinformatik-Beiträge findet. Auf die viele Forscher interessierende Frage, nach welchen Kriterien internationale Organe Beiträge begutachten und bei welchen Zeitschriften die Forschungskultur der Wirtschaftsinformatik am ehesten Akzeptanz erwarten kann, gibt es nur meist nur vage Antworten. Um die Unsicherheit zu verringern und die weitere Diskussion in der WI-Community zu unterstützen, wurden 175 internationale Fachzeitschriften aus drei Bereichen auf ihre Begutachtungskriterien hin untersucht: (1) Information-Systems-Zeitschriften, weil sie in der Vergangenheit meist als Leitbild für die Internationalisierung der Wirtschaftsinformatik und in diesem Sinne vorrangig als für Veröffentlichungen anzustrebend angesehen wurden. (2) Computer-Science-Zeitschriften, weil die Informatik überwiegend als die Realität gestaltend eingestuft wird. In Veröffentlichungen ist es nicht unüblich, neue Methoden, Technologien und Systeme vorzustellen, auch explorativ, und innovative Entwicklungen zu beschreiben. (3) Engineering-Zeitschriften, weil im Selbstverständnis der Wirtschaftsinformatik der konstruktive Aspekt stark betont wird. Deshalb sollte zusätzlich untersucht werden, nach welchen Kriterien international anerkannte ingenieurwissenschaftliche Organe Fachartikel beurteilen. Nicht untersucht wird in diesem Beitrag, warum die Zahl der WI-Veröffentlichungen in internationalen Zeitschriften relativ niedrig ist. Eine derartige, allerdings auf IS bezogene Untersuchung haben Lyytinen et al. vorgelegt [8]. Der Beitrag ist wie folgt aufgebaut: Im nächsten Abschnitt wird das Vorgehen der Untersuchung beschrieben. Im dritten Abschnitt werden die erhobenen Beschreibungen der Akzeptanzkriterien qualitativ charakterisiert und nachfolgend vergleichend beschrieben. Der vierte Abschnitt gibt einige Schlussfolgerungen wieder. 2. Untersuchungsdesign Die Untersuchung folgt einem explorativen Ansatz – einer modifizierten Frequenzanalyse [11, 408ff]. Konzeptnennungen aus zuvor erhobenen Texten werden dabei in Kategorien binär kodiert, so dass über die Menge der Texte Nennhäufigkeiten ermittelt und Aussagen abgeleitet werden können. 3 Gestaltungshilfsmitteln (Methoden, Werkzeuge, Anwendungsprototypen) für den "Gestalter" in Wirtschaft und Verwaltung." [16] "(...) review approach #1, which I would posit is the current and dominating posture in top IS journals, stresses methodology at the expense of intellectual content." [14] 452 Für die Untersuchung wurden insgesamt 175 Eigendarstellungen von Fachzeitschriften und zugehörige Autoren-Instruktionen ausgewertet, die von den Herausgebern auf den Websites der Zeitschriften veröffentlicht wurden. Die Untersuchungsmenge setzt sich zusammen aus 50 Information Systems-Zeitschriften, 50 Computer Science-Zeitschriften sowie 75 Zeitschriften aus angrenzenden Ingenieursdisziplinen (Elektrotechnik/Elektronik, Maschinenwesen, Produktionstechnik, jeweils 25 Zeitschriften). Zu bemerken ist, dass die ingenieurwissenschaftlichen Zeitschriften, obwohl sie teilweise eng mit Wirtschaftsinformatik-Themen verknüpft sind, zumeist nicht unmittelbar als Medium für typische WI-Beiträge dienen. Um Aussagen ableiten zu können, die für international allgemein anerkannte Publikationsorgane gelten, wurden die untersuchten Zeitschriften aus der Grundgesamtheit der in internationalen Rankings aufgeführten Zeitschriften ausgewählt. Für Information Systems ist ähnlich wie für Betriebswirtschaftslehre (vgl. [4]) eine große Menge an selektiven Rankings verfügbar (vgl. [10]). Als zentrales Ranking wird häufig auf den Science Citation Index (SCI) verwiesen. Dieser steht allerdings in der Diskussion, da in der zugrunde liegenden Zitierungsanalyse Publikationen mit interdisziplinärem Charakter4 und die Relevanz der Zitierungen nur eingeschränkt berücksichtigt sind [7]. In den Bereichen Computer Science und Ingenieurwissenschaften scheinen allgemeine Journal-Rankings dagegen weniger beachtet zu werden. Hier wird stattdessen häufig der Einfluss individueller Beiträge, wie er beispielsweise durch die Zitierhäufigkeit in CiteSeer gemessen wird, zur Beurteilung einer Publikation verwendet. Dies berücksichtigend wurde als Grundlage für die Untersuchung ein Journal-Ranking eingesetzt (JournalRanking.com), das mittels Zitierungsanalyse (RPRS-Verfahren [7]) eine fachübergreifende Rangfolge von Zeitschriften anhand eines so genannten Impact Factors berechnet. • Für den Bereich Information Systems wurde abweichend vom RPRS-Ranking auf das konsolidierte Journal-Ranking von Saunders [10] zurückgegriffen. Dieses kombiniert einerseits als Meta-Ranking neun Rankings aus der IS-Disziplin. Andererseits besitzt es aufgrund der allgemeinen Zugänglichkeit auf den Webseiten der Association for Information Systems (AIS) hohe Popularität und ist für viele Autoren mitbestimmend bei der Auswahl eines Publikationsmediums. • Für Computer Science wurde das RPRS-Ranking mit Empfehlungen kombiniert, welche ausgehend von den USA und Kanada auf Webseiten verschiedener Universitäten aufgeführt sind und zunehmend als Referenz für bevorzugte Veröffentlichungsorgane dienen5. • Für die Ingenieurwissenschaften wurden die Zeitschriften in den o.g. Teildisziplinen getrennt ausgewertet und die Aussagen anschließend aggregiert. Im Rahmen der Diskussion der Ergebnisse wurden die am Aggregat getroffenen Aussagen in den Teildisziplinen separat überprüft. Für die Untersuchung wurden jeweils die top-n Zeitschriften der Disziplinen herangezogen. Für nicht mehr aktive oder nicht adäquat über Websites kommunizierte Zeitschriften (insgesamt: 6) wurden die jeweils nächstgerankten als Ersatz verwendet. Die Websites der so selektierten Zeitschriften wurden anschließend in der Reihenfolge der Nen4 5 Die Interdisziplinarität wird in der Wirtschaftsinformatik als Kernkompentenz angesehen [5]. Z.B. Illinois Institute of Technology (USA), Wayne State University (USA), University of Ottawa (Kanada), National Institute of Technology, Hamirpur (Indien), Huazhong University of Science and Technology (China), Intelligent Science Research Group, at Key Lab of IIP, ICT, CAS (China), National University of Singapore (Singapur), Nanyang Technological University (Singapur), The Chinese University of Hong Kong (Hong Kong, China). 453 nung in den Rankings mittels Suchmaschinen und Fachdatenbanken (u.a. Business Source Premier, IEEExplore) aufgesucht. Die in den Websites enthaltenen Informationen zu Zielstellung („Mission“), Publikationsprofil, Autoren-/Einreichungsrichtlinien, Herausgeberpolitik, Themen etc. wurden geordnet in Zeitschriftenprofilen als Textdateien erfasst und gespeichert. Ausgehend vom Erkenntnisziel der Untersuchung wurden themenneutrale Kategorien definiert, welche insbesondere eine Differenzierung der formulierten Anforderungen an den Forschungsansatz sowie an die Relevanz bzw. die methodische Stringenz („Relevance/Rigor“) ermöglicht. Nach einer Analyse der erfassten Zeitschriftenprofile wurden die vorab definierten Kategorien validiert. Als Kernkategorien dienten in der Untersuchung: • Die grundlegende inhaltliche Ausrichtung der Zeitschriften (Theorien/Methoden, Empirie, Praxis, Technologie, Synthesen), • Verfeinerungsstufen zu den Ausrichtungen Theorien/Methoden und Technologie, u.a. zur Ausdifferenzierung von deskriptiven, angewandten und experimentell/empirischen Schwerpunkten der Zeitschriften, • Explizite Anforderungen an die methodische Stringenz („Rigor“) sowie an die praktische (praktischer Nutzwert/Anwendbarkeit) und die akademische Relevanz (Erklärungsgehalt, Beitrag zum Verständnis bzw. zur Zusammenführung von Theorien etc.), • Anforderungen an die Aktualität und den Neuigkeitsgehalt der Beiträge. Die exakten Kategorien sind in den Abbildungen 1 bis 4 wiedergegeben. Des Weiteren wurden Daten zu den Zielgruppen, Herausgebern, Beziehungen zu spezifischen Communities und Fachgesellschaften erhoben. Die Zeitschriftenprofile wurden leitfadenbasiert durch mehrere unabhängige Auswerter separat voneinander kodiert. Eine Kategorie wurde je Beitrag als erfüllt bewertet, wenn mindestens eine zutreffende Äußerung im Zeitschriftenprofil enthalten war. Die kodierten Daten wurden anschließend zusammengeführt und inhaltliche Konflikte mit Hilfe einer bis dahin nicht einbezogenen Person in der Rolle des Mediators ausgeräumt. Der Mediationsprozess wurde mit zeitlichem Abstand zur ursprünglichen Kodierung der Daten durchgeführt. Anschließend wurden die relativen Nennhäufigkeiten ermittelt und die Daten statistisch analysiert. Ergänzend wurden stichprobenartig Beiträge der betrachteten Zeitschriften gesichtet, um getroffene Aussagen zu validieren. Nachfolgend werden zuerst qualitativ die Form und Inhalte der von den Zeitschriften kommunizierten Anforderungen bzw. Beurteilungskriterien erläutert. Im Anschluss daran werden Gemeinsamkeiten und Unterschiede zwischen ausgewählten Beurteilungskriterien identifiziert und beschrieben. Die dabei getroffenen Aussagen werden durch die erhobenen Daten quantitativ illustriert, nachdem sie auf statistische Signifikanz überprüft wurden. Dazu wurde getestet, ob die jeweils verglichenen relativen Häufigkeiten aus derselben Grundgesamtheit stammen können. Die in der Untersuchung vorliegenden Daten sind normativ ordinal skaliert (0 – "hat nicht" < 1 – "hat") und erwartungsgemäß nicht normal verteilt, wie durch den Kolmogorov-Smirnov-Test [13, S. 264] bestätigt wurde. Daher wurden anstelle des vergleichenden t-Tests für unabhängige Stichproben nicht-parametrische Kruskal-Wallis H-Tests (für den simultanen Vergleich aller drei Zeitschriftenkategorien) [2, S. 172] und Mann-Whitney U-Tests (für detaillierende paarweise Kategorienvergleiche) [12, S. 423ff] durchgeführt. Die Teststatistiken (χ² bzw. U) und statistischen Feh454 lerwahrscheinlichkeiten (p) werden im Folgenden ergänzend zu den Mittelwertschätzern (X) angegeben. Ohne gesonderte Nennung wird ein Signifikanzniveau von 0,9 (α=0,1) angelegt. 3. Ausgewählte Ergebnisse 3.1. Publizierte Beurteilungskriterien Die Darstellung der Beurteilungskriterien durch die Zeitschriften bzw. deren Herausgeber beinhaltet im Wesentlichen vier Gruppen von Informationen: (1) (2) (3) (4) Fachliche Positionierung und thematische Eingrenzung Formale Anforderungen an die Beiträge (Grobe) Erläuterung der Begutachtungsverfahren und Fachliche und formale Beurteilungskriterien i.e.S. Die thematische Eingrenzung (1) erfolgt i.d.R. durch Nennung von Fachdisziplin und einschlägigen Themen (z.B. in Form nicht abschließender Themenlisten), durch Bezugnahme auf die Interessen und Forschungsgegenstände der angesprochenen Community und selten durch Bezeichnung konkreter Abgrenzungs- bzw. Ablehnungskriterien. Die formalen Anforderungen (2) wie z.B. Anforderungen an den Umfang, die Sprache, die Gestaltung und Formatierung der Beiträge gehören zu den am stärksten ausgearbeiteten Informationen. Mit Ausnahme der Sprache und des damit verbundenen Diskursniveaus stellen sie als rein technische Anforderungen keine fachliche Hürde für die Publikation von Beiträgen dar. Die Informationsgruppen (3) und (4) überlappen zumeist inhaltlich und ergeben erst zusammengeführt ein hinreichend nachvollziehbares Bild bezüglich der angewendeten Beurteilungskriterien. In der Benennung der Beurteilungskriterien bleiben die Zeitschriften meistens vage. Es wird offenbar unterstellt, dass bereits die Themen die Natur der Beiträge bestimmen oder dass Beiträge intrinsischen, nicht gesondert geäußerten Regeln der adressierten Community oder ungeschriebenen Anforderungen der Zeitschrift folgen. Beispielhaft für diese Auslegung steht der Hinweis in Administrative Science Quarterly6, mit dem Autoren aufgefordert werden, sich einen Überblick über die veröffentlichten Beiträge der letzten zehn Jahrgänge zu verschaffen. Weiterhin sind die Beurteilungskriterien häufig stereotyp formuliert, wobei institutionelle oder organisatorische Interdependenzen für die Formulierungen offenbar eine Rolle spielen. Die wichtigsten Zeitschriften werden fast durchgängig von wenigen Verlagsgruppen (z.B. XElsevier=25%, XSpringer=11%) bzw. Fachverbänden (z.B. XIEEE=14%, XACM=9%) herausgegeben oder stehen solchen Fachverbänden zumindest sehr nahe (XVerbandsbindung=27%)7. In der Folge werden häufig gleichklingende Anforderungen an die Beiträge beschrieben, selbst wenn betont wird, dass Herausgeber oder Herausgebergremien als unabhängige Entscheider für die inhaltliche Gestaltung der Zeitschriften allein verantwortlich seien. 6 7 “Authors should look at what ASQ has published over the last 10 years, see if there are any precedents for the proposed submission, and, if there is even a glimmer of precedent, submit the work to ASQ.” (http://www.johnson. cornell.edu/publications/asq/contributors.html; letzter Abruf: 21.07.2008) Diese Schätzungen basieren auf den unmittelbar erhobenen Daten. Die Verlage und Vereinigungen wurden nicht weitergehend recherchiert. Die hier ausgewiesenen Mittelwertschätzer dürften daher die institutionellen und organisatorischen Interdependenzen eher unterschätzen. 455 3.2. Aktualität und Neuigkeitsgehalt Unabhängig von der untersuchten Zeitschriftengruppe gilt als zentrales Beurteilungskriterium, wenn ein akademisches Publikum angesprochen wird, dass reguläre Beiträge grundsätzlich originär sein sollen und einen signifikanten Erkenntnisgewinn mit sich bringen müssen (vgl. Abbildung 1). Dies gilt auch für Synthesen (Literaturzusammenfassungen, Reviews, Surveys u.a.m.), welche zumindest neue Aspekte in der betrachteten Thematik aufdecken sollen. Im Bereich Computer Science und in den Ingenieursdisziplinen ist die Originalitätsanforderung an die Beiträge höher als im Bereich Information Systems (XIS=34%, XCS=58%, XES=56%; χ²=7,43, p=0,024). Allerdings werden in den Ingenieursdisziplinen auch mehr lehrende Beiträge (z.B. Tutorials) angefragt als in Information Systems (XIS=16%, XCS=18%, XES=35%; χ²=7,23, p=0,027) und beide Beitragsarten (regulär, lehrend) stärker miteinander kombiniert. Zusammenfassende Beiträge bzw. Synthesen werden bevorzugt in den Information Systems publiziert (XIS=32%, XCS=2%, XES=16%; χ²=12,91, p=0,002). 34% Neu/originär 58% 56% 34% 34% Im Wesentlichen neu/originär Information Systems (IS) 27% Computer Science (CS) Engineering Sciences (ES) 16% 18% Andere (z.B. Tutorials) 35% 0% Abbildung 1 3.3. 10% 20% 30% 40% 50% 60% 70% Originalitätsanforderung (Aktualität und Neuigkeitsgehalt der Beiträge) Forschungsansatz und Inhalt Erwartungsgemäß ist im Bereich Information Systems das Interesse an verhaltenswissenschaftlichen Arbeiten größer als in den Ingenieursdisziplinen, in denen deutliche konstruktionswissenschaftliche Schwerpunkte gesetzt sind. Da diese Forschungsparadigmen in den von den Zeitschriften formulierten Anforderungen jedoch nicht explizit genannt werden, müssen ersatzweise Anforderungen an den theoretischen, methodischen oder empirischen Inhalt bzw. an den technologischen, lösungsbezogenen Inhalt als Indikatoren herangezogen werden (vgl. Abbildung 2 links und rechts). Bezüglich dieser Anforderungen lässt sich aus dem unmittelbaren Vergleich der Nennhäufigkeiten nicht sofort belegen, dass ein bestimmter Forschungsstil erwartet wird. Die relativen Häufigkeiten weisen keine signifikanten Unterschiede aus (Theorien/Methoden: XIS=58%, XCS=62%, XES=57%; χ²=0,29, p=n.s. (nicht signifikant); Technologien: XIS=46%, XCS=40%, XES=52%; χ²=4,12, p=n.s.). Die Verfeinerung dieser Anforderungen in Bezug auf die Form, wie Inhalte in den Beiträgen dargebracht werden sollen, gibt den paradigmatischen Unterschied jedoch wieder. So wird bei den ISZeitschriften die Ausarbeitung theoretischer Inhalte (XIS=50%, XCS=48%, XES=27%; χ²=8,94, p=0,011), die Anwendung von Theorien und Methoden (XIS=40%, XCS=20%, XES=28%; χ²=4,90, 456 p=0,086) sowie theoriebasierte empirische Arbeit (XIS=16%, XCS=6%, XES=1%; χ²=10,13, p=0,006) mehr gefragt als in den ingenieurwissenschaftlichen und Computer Science-Zeitschriften. Umgekehrt wird die Realisierung von abstrakten Konzepten (XIS=24%, XES=39%; U=1600, p=0,088), Prototypen und Demonstratoren (XIS=10%, XCS=28%, XES=16%; χ²=5,79, p=0,055) sowie der praktische Einsatz von Lösungen (XIS=18%, XCS=36%, XES=19%; χ²=6,14, p=0,046) vermehrt in den Ingenieursdisziplinen und der Computer Science gefordert (s. Abbildung 2 rechts). 58% 62% 57% Theorien/Methoden (allg.) 50% 48% Theoretische Arbeiten Theoriebasierte empirische Forschung 0% 40% 16% Abbildung 2 24% 42% 39% 10% 28% 16% 18% Praxiseinsatz von Lösungen 6% 1% Information Systems (IS) 52% Prototypen, Demos etc. 20% 28% 20% 40% Realisierungen (allg.) 27% Angewandte Theorien/Methoden 46% Technologien / Lösungen (allg.) 40% 60% Computer Science (CS) 80% 36% 19% 0% 20% 40% 60% Engineering Sciences (ES) links: Theorie-/Methodenorientierung nach Disziplin; rechts: Technologie-/Lösungsorientierung nach Disziplin In einer qualitativen stichprobenartigen Überprüfung8 fallen zusätzliche Unterschiede in den Auslegungen des Theoriebegriffs zwischen Information Systems auf der einen sowie Computer Science und Ingenieurswissenschaften auf der anderen Seite auf. Publikationsfähige Theorien und Methoden sind in Information Systems primär deskriptiv, erklärungsorientiert oder reflektierend (rückwärtsgerichtet). Es wird besonderer Wert auf die Formalisierung der Forschungsmethoden gelegt. In den beiden anderen Disziplinen richten sie sich dagegen an problemorientiertem Denken und dem Problemlösen als Kerngegenstand aus, so dass die Verwendbarkeit von Theorien und Methoden für die Konstruktion und Prognose (vorwärtsgerichtet) im Vordergrund stehen. Die Theorien und Methoden werden als Werkzeug verstanden und dementsprechend sachbezogen und kontextadaptiert statt abstrakt eingesetzt. Alle drei untersuchten Bereiche interagieren intensiv mit ihren Nachbardisziplinen. Dennoch ist die Interdisziplinarität der Beiträge als explizite Anforderung durch die Zeitschriften nicht als Selbstverständlichkeit anzusehen. Speziell die IS-Zeitschriften sind allerdings bemüht, diesem Aspekt Rechnung zu tragen, und laden vermehrt zur Einreichung fachübergreifender Beiträge ein (XIS=38%, XCS=18%, XES=19%; UIS,CS=1075, p=0,108 (n.s.); UIS,ES=1625, p=0,089). 8 Die Probe basiert auf Artikeln, die über Business Source Premier oder direkt auf den Webseiten der Zeitschriften zugänglich waren. Die erschöpfende Inhaltsanalyse der Artikel ist nicht Gegenstand dieser Untersuchung. 457 3.4. Relevance vs. Rigor Die über Information Systems [3] hereingetragene Kontroverse „Relevance vs. Rigor“ wird vorrangig dort weitergeführt, wie auch die häufige Verwendung dieser Begriffe in den Anforderungen der IS-Zeitschriften widerspiegelt (vgl. Abbildung 4). Im Vergleich der Zeitschriftengruppen dominieren Anforderungen an die Stringenz der Forschung bei Information Systems gegenüber eher relevanzorientierter Forschung in den Ingenieursdisziplinen und der Computer Science (Rigor: XIS=26%, XCS=12%, XES=5%; χ²=11,24, p=0,004), welche nach ihrem Selbstverständnis jedoch ebenfalls hohe Ansprüche an die fachliche Herleitung und Validierung der Ergebnisse stellen. Mit den relativ häufigen Nennungen von „Rigor“ in den IS-Zeitschriften wird daher der Forderung, die Forschung zu formalisieren, Nachdruck gegeben. Es ist weiterhin nennenswert, dass mehr Zeitschriften aus den Disziplinen Information Systems und Computer Science als aus dem Ingenieurswesen eine Notwendigkeit darin sehen, gesondert einzufordern, dass die in den Beiträgen beschriebenen Theorien/Methoden oder Konzepte praktisch erprobt wurden oder ihre Anwendbarkeit bzw. ihren Nutzwert anderweitig erwiesen haben (XIS=26%, XCS=28%, XES=12%; χ²=5,93, p=0,052, vgl. Abbildung 3)9. Bei den letztgenannten wird der Beweis oft direkt mit der Konstruktion erbracht, während für Theorien und Referenzmodelle aus Information Systems und Computer Sciences die Realisierung noch zusätzlich zu zeigen ist. Theorie/Methode durch Empirie erprobt 8% 14% 4% Theorie/Methode durch Lösung erprobt 14% 10% 8% Information Systems (IS) Lösung empirisch evaluiert 4% Computer Science (CS) 6% Engineering Sciences (ES) 1% Lösung theoretisch fundiert 14% 14% 3% 0% Abbildung 3 2% 4% 6% 8% 10% 12% 14% 16% Explizite Anforderungen an die Validierung/Erprobung von Theorien bzw. die Fundierung praktischer Lösungen Die Relevanzanforderungen lassen bei aggregierter Betrachtung keine adäquaten Folgerungen zu (Relevance10: XIS=38%, XCS=42%, XES=29%; χ²=2,21, p=n.s.). Bei Ausdifferenzierung des Relevanzkriteriums überwiegt jedoch die praktische Relevanz (d.h. die Anwendbarkeit auf reale Probleme, z.B. in der Wirtschaft) vor der akademischen Relevanz (Erklärungsgehalt, Potential von Theorien etc.) (UIS=1157, pIS=n.s., UCS=1025, pCS=0,039, UES=2437, pES=0,037). 9 10 Diese Statistik überprüft, ob mindestens einer der vier in Abbildung 3 dargestellten Validierungsansätze gesondert eingefordert wird. Die statistische Variable wurde durch Adjunktion der zugehörigen Werte gebildet. Die Statistik bezieht sich auf aggregierte Werte für die Relevanz. Es muss mindestens eine Nennung von akademischer oder praktischer Relevanz vorliegen. 458 Bei einer exemplarischen Überprüfung zeigt sich, dass die kommunizierten Beurteilungskriterien zudem verschiedentlich Abweichungen zu den Eigenschaften der tatsächlich veröffentlichten Beiträge aufweisen. In enger Auslegung finden sich z.B. bei den IS-Zeitschriften widersprüchliche Anforderungsformulierungen, welche für die Beiträge eine gleichermaßen hohe praktische Relevanz als auch hohe Formalisierung und Stringenz verlangen, obwohl beide zusammen kaum durch einen einzelnen Beitrag erfüllbar sind (und durch veröffentlichte Beiträge, die mit Blick auf „Rigor“ ausgearbeitet sind, i.d.R. auch nicht erfüllt werden). Beide Kriterien werden dennoch simultan genannt (46% der Rigor-Nennungen; 40% der Nennungen praktischer Relevanz). Demzufolge ist die Betonung der praktischen Relevanz selbst für solche IS-Zeitschriften typisch, die für die Publikation von stark „theorielastigen“ Beiträgen mit eher formalen statt praktisch anwendbaren Erkenntnissen bekannt sind. 26% Rigor/Stringenz 12% 5% Information Systems (IS) 22% Akademische Relevanz Computer Science (CS) 16% Engineering Sciences (ES) 12% 32% 34% Praktische Relevanz 25% 0% Abbildung 4 4. 5% 10% 15% 20% 25% 30% 35% 40% Rigor-Relevance-Anforderungen nach Disziplin Schlussfolgerungen Die Beurteilungskriterien in internationalen Fachzeitschriften fordern Originalität, fachspezifische Methodik, methodische Stringenz („Rigor“) und praktische Relevanz der Forschung. Wie hier gezeigt wurde, müssen Wirtschaftsinformatik-Beiträge diese von den Zeitschriften kommunizierten Anforderungen – je nach Zeitschrift mit unterschiedlicher Betonung – erfüllen, wenn sie im Begutachtungsverfahren bestehen wollen. Die anknüpfende Fragestellung, inwieweit diese Kriterien von den Fachgutachtern tatsächlich angewendet werden, erfordert weitere Untersuchungen. Darüber hinaus werden implizite Anforderungen unterstellt, die aus ungeschriebenen Normen der angesprochenen Community oder aus der Publikationshistorie der Zeitschrift selbst resultieren. Diese Normen zu erkennen und auf sie einzugehen, erfordert sowohl die gezielte Auseinandersetzung mit den methodischen Ansätzen und Erkenntniszielen der Community als auch eine gute Kenntnis der in diesen Zeitschriften bisher veröffentlichten Forschungsarbeiten. Darauf deutet auch durch die von [7] erkannte hohe Selbstzitierungsrate der Zeitschriften hin. Die vor der Untersuchung vermuteten Unterschiede bei der Beurteilung wissenschaftlicher Beiträge durch Information Systems- und Computer Science-Zeitschriften wurden durch die Untersuchung bestätigt. Außerdem zeigte sich, dass in den Ingenieurwissenschaften die Konstruktion von Problemlösungen relativ bevorzugt wird, worauf im Diskurs zum Gegenstand der Wirtschaftsinformatik häufig Bezug genommen wird. 459 Bei der Wahl geeigneter internationaler Publikationsorgane stehen Forscherinnen und Forscher aus der Wirtschaftsinformatik weiterhin vordergründig vor einer Entweder-Oder-Entscheidung zwischen IS- und Computer Science-Zeitschriften. Dahinter verbirgt sich allerdings die grundsätzlichere Frage, nach welchem Forschungsparadigma die eigentliche Forschungsarbeit durchgeführt wird. Je nach Art des wissenschaftlichen Ansatzes kommen dann entweder Zeitschriften aus der einen oder aus der anderen Kategorie in Betracht. Um die Annahmechancen zu verbessern, kann die eigene Forschung (vgl. [15], [9]) oder die Präsentation der Forschungsleistungen an die Methodik der durch die Zeitschriften adressierten Community angepasst werden. Ein Weg zur Verbindung der unterschiedlichen Ansätze könnte darin bestehen, die methodischen Gerüste aus Information Systems zur theoretischen Fundierung der entwickelten Lösungen heranzuziehen oder die Folgen der entwickelten Lösungen mit verhaltenswissenschaftlichen Methoden zu überprüfen. Immerhin bietet die gesonderte Aufforderung mancher IS-Zeitschriften, in einem Beitrag auch die Relevanz zu zeigen, eine weitere Chance, Forschungsergebnisse der klassischen Wirtschaftsinformatikforschung international publik zu machen. Literatur [1] Backlund, P.: On the Research Approaches Employed at Recent European Conferences on Information Systems (ECIS 2002 – ECIS 2004); in: Proceedings of 13th European Conference on Information Systems (ECIS 2005), Information Systems in a Rapidly Changing Economy, Regensburg 2005 (on CD ROM). [2] Chalmer, B.J.: Understanding Statistics; New York: Marcel Dekker; 1987. [3] Davenport, T.H.; Markus, M.L.: Rigor vs. Relevance Revisited: Response to Benbasat and Zmud; in: MIS Quarterly 23 (1999) 1, S. 19-23. [4] Harzing, A.-W.: Ranking Journals in Business Management: A Statistical Analysis of the Harzing Dataset; in: European Journal of Information Systems 16 (2008). 4, S. 303-316. [5] Heinzl, A.; König, W.; Hack, J.: Erkenntnisziele der Wirtschaftsinformatik in den nächsten drei und zehn Jahren; in: Wirtschaftsinformatik 43 (2001) 3, S. 223-233. [6] Kurbel, K.: Internationalisierung der Wirtschaftsinformatik; in: Jung, R., Myrach, T (Hrsg.), Quo Vadis Wirtschaftsinformatik?, Wiesbaden: Gabler 2008, S. 83-94. [7] Lim, A.; Ma., H.; Wen, Q.; Xu, Zh.; Cheang, B.: Distinguishing Citation Quality for Journal Impact Assessment; Version 11/2007, angenommen von Communications of ACM; http://www.journal-ranking.com/ranking/web/content/whitepapers.html; letzter Zugriff: 21.07.2008. [8] Lyytinen, K.; Baskerville, R.; Iivari, J.; Te'eni, D.: Why the old world cannot publish? Overcoming challenges in publishing high-impact IS research. In: European Journal of Information Systems, 16 (4), S. 317-326. [9] Nicolai, A.: Der „trade-off“ zwischen „rigour“ und „relevance“ und seine Konsequenzen für die Managementwissenschaften; in: Zeitschrift für Betriebswirtschaft 74 (2004) 2, S. 99-118. [10] Saunders, C.: MIS Journal Rankings (IS-World); http://www.isworld.org/csaunders/rankings.htm; letzter Zugriff: 21.07.2008. [11] Schnell, W., K. Hill, E. Esser: Methoden der empirischen Sozialforschung; 7. Aufl.; München: Oldenbourg; 2005. [12] Sheskin, D. J.: Handbook of Parametric and Nonparametric Statistical Procedures; Chapman & Hall / CRC Press, 3rd ed.; 2004. [13] Stevens, J.: Applied Multivariate Statistics for the Social Sciences; Mahwah, NJ: Lawrence Erlbaum Associates; 2002. [14] Straub, D.W.: Editor's Comments: Type II Reviewing Errors and the Search for Exciting Papers; in: MIS Quarterly 32 (2008) 2, S. v-x. [15] Wilde, T., Hess, T.: Forschungsmethoden der Wirtschaftsinformatik – Eine empirische Untersuchung; in: Wirtschaftsinformatik 49 (2007) 4, S. 280-287. [16] Wissenschaftliche Kommission Wirtschaftsinformatik (WKWI): Profil der Wirtschaftsinformatik; in: Wirtschaftsinformatik 36 (1994) 1, S. 80-81. 460 RECHTSFRAGEN, GEISTIGES EIGENTUM Zu dem Generalthema „Business Services“ ergibt sich eine große Bandbreite an rechtlichen Fragestellungen, für die hier Schwerpunkte ausgewiesen werden sollen, ohne aber andere Themenvorschläge auszuschließen. Dazu gehören Fragen des geistigen Eigentums, des Vertragsschlusses, des Verbraucherschutzes sowie der kartellrechtlichen und datenschutzrechtlichen Rahmenbedingungen, jeweils mit unterschiedlichen Schwerpunkten. Ergänzend sind auch Aspekte des öffentlichen Rechts zu beachten. Dabei geht es zum einen um die derzeit geltenden rechtlichen Rahmenbedingungen und die Identifikation eines evtl. Reformbedarfs, zum anderen aber auch um die Wechselwirkungen zwischen Recht und Technik im Sinne einer frühzeitigen Abstimmung bei der Entwicklung neuer Technologien und Geschäftsprozesse. Leitungsgremium: Walter Blocher, Universität Kassel Ulrich Hasenkamp, Philipps-Universität Marburg Andreas Wiebe, Wirtschaftsuniversität Wien (Federführender) Programmkomitee: Robert Briner, CMS von Erlach Henrici, Zürich Thomas Dreier, Universitaet Karlsruhe Wolfgang Freund, DLA Weiss-Tessbach, Wien Georgios Gounalakis, Philipps-Universität Marburg Rainer Knyrim, Preslmayr Rechtsanwaelte, Wien Ursula Widmer, Dr. Widmer & Partner, Rechtsanwälte, Bern AUSWIRKUNGEN EXTERNER KONTROLLMECHANISMEN AUF DIE GESTALTUNG UND IMPLEMENTIERUNG VON ERP-SYSTEMEN Axel Winkelmann, Malte Stockmann, Jörg Becker1 Kurzfassung Der betriebliche Einsatz von Systemen zum Enterprise Resource Planning (ERP) muss unter Beachtung externer Rahmenbedingungen erfolgen. Im vorliegenden Beitrag werden mit den Vorschriften zu den „Grundsätzen zum Datenzugriff und zur Prüfbarkeit digitaler Unterlagen“ (GDPdU) und dem „Sarbanes Oxley Act“ (SOX) zwei hierfür relevante Regelwerke vorgestellt und deren Auswirkungen auf die konkrete Ausgestaltung von ERP-Systemen untersucht, um Gestaltungsempfehlungen für ERP-Anwender zu entwickeln. Ein darauf basierender Vorschlag zur Ergänzung der Rechteverwaltung, insbesondere im Bereich der Anwendungs-zu-Anwendungs-Kommunikation SOA-basierter ERP-Systeme, schließt den Beitrag ab. 1 Einführung Bedingt durch den technologischen Fortschritt und damit einhergehende gestiegene IT-Durchdringung wird in zahlreichen Unternehmen ein großer Anteil der Geschäftsprozesse elektronisch unterstützt. Eine besondere Bedeutung kommt den Enterprise Resource Planning (ERP)-Systemen zu, die den Anspruch erheben, möglichst alle Geschäftsprozesse integriert abzubilden. Bei der Ausgestaltung solcher Systeme müssen zunehmend rechtliche Vorgaben beachtet werden [1]. Diese Compliance-Anforderungen ergeben sich zum einen aus nationalen Vorschriften wie beispielsweise den Grundsätzen zum Datenzugriff und zur Prüfbarkeit digitaler Unterlagen (GDPdU) der Bundesfinanzverwaltung, dem Gesetz zur Kontrolle und Transparenz im Unternehmensbereich (KonTraG) oder dem Corporate Governance Kodex [13]. Zum anderen lassen sich Compliance-Anforderungen auch aus Vorschriften aus dem ausländischen Rechtsraum herleiten, welche sich indirekt auf deutsche Unternehmen auswirken. In diese Kategorie kann z. B. der Sarbanes Oxley Act (SOX) eingeordnet werden [15]. Am Beispiel der GDPdU und des SOX werden im vorliegenden Beitrag die Auswirkungen von derartigen Anforderungen auf die Gestaltung von ERP-Systemen betrachtet. Die durch die Platzbeschränkung bedingte exemplarische Auswahl der GDPdU erfolgte auf Grund ihrer herausragenden Bedeutung und Relevanz für alle buchführenden deutschen Unternehmen. Der SOX wird thematisiert vor dem Hintergrund seiner Auswirkungen auf alle Unternehmen mit Zugang zu den US-Kapitalmärkten sowie seiner Signalwirkung für entsprechende europäische und 1 European Research Center for Information Systems (ERCIS) der Universität Münster. 463 damit auch direkt in Deutschland geltenden Regelungen („Euro-SOX“) [15]. Die Analyse erfolgt mit dem Ziel, eine Gestaltungsempfehlung für ERP-Systeme und moderne Architekturen u. a. im Bereich der Service-orientierten Architekturen (SOA) strukturiert zu erörtern und durch ein entsprechendes Datenmodell zu ergänzen. Diese grundlegende Betrachtung ist vor allem vor dem Hintergrund einer zunehmenden Abkehr von monolithischen Architekturen hin zu best-of-breed- oder web-service-orientierten Unternehmenssoftwareansätzen [1] von hoher Relevanz. 2 Grundlagen 2.1 ERP-System Der Begriff „Enterprise-Resource-Planning-System“ bezeichnet eine integrierte, anpassbare Anwendungssoftware zur Planung und Kontrolle von Ressourcen und Abläufen eines Unternehmens. Ihr Ziel ist eine möglichst umfassende Integration aller betrieblichen Anwendungsbereiche. Sie unterstützt die Kernprozesse der Wertschöpfung in den Bereichen Einkauf, Lagerhaltung, Produktion und Vertrieb sowie insbesondere auch die Supportprozesse im Personal- und Rechnungswesen. Charakteristisch ist die Verwendung einer gemeinsamen Datenbasis für alle o. g. Prozesse. Auf dem gemeinsamen Datenbestand operieren mehrere miteinander integrierte Teilsysteme zur Unterstützung der Prozesse in den jeweiligen unterschiedlichen Unternehmensbereichen [1]. Traditionelle ERP-Systeme weisen meist eine monolithisch geprägte Anwendungsarchitektur auf. Sie ermöglichen somit innerhalb des einsetzenden Unternehmens eine nahtlose Prozessintegration zwischen verschiedenen Unternehmensbereichen [20]. An den Schnittstellen zu Lieferanten und Kunden treten allerdings oft Medienbrüche auf. Um zwischenbetriebliche Kooperationen im Sinne des Supply Chain Management [19] besser zu unterstützen, kommt es daher unter dem Schlagwort ERP II zur Entwicklung einer neuen Generation von ERP-Anwendungen, die klassische ERPSysteme um Funktionen zur Unterstützung unternehmensübergreifender Prozesse erweitern [16] . Technische Basis für ERP II-Systeme sind serviceorientierte Architekturen (SOA) [9]. Die Gesamtfunktionalität des Systems wird in Form eines Netzwerks von lose gekoppelten Services bereitgestellt. Die Services konzentrieren sich dabei jeweils auf spezielle Teilaufgaben und sind eigenständig nutzbar. Nach außen verfügen sie über eine standardisierte Schnittstelle [2], [16]. Zur Unterstützung eines konkreten Geschäftsprozesses werden die Services flexibel kombiniert („Service-Orchestrierung“). Zur Implementierung der Services kommen v. a. Webservices zum Einsatz; zur Service-Orchestrierung werden die Geschäftsprozesse in Sprachen wie der Business Process Execution Language (BPEL) beschrieben. Dabei wird von Application-to-Application-Kommunikation Gebrauch gemacht: Die beteiligten Services tauschen ohne manuellen Eingriff die benötigten Daten aus. Services können sowohl intra- als auch interorganisational bereitgestellt werden. 2.2 Kontrollmechanismen mit Bezug zu IT-Systemen 2.2.1 Nationaler Rahmen in Deutschland am Beispiel der GDPdU Das sogenannte Steuersenkungsgesetz vom 23.10.2000 regelt die Zugriffsrechte der Finanzverwaltung auf die EDV-basierten Daten sämtlicher steuerpflichtigen deutschen Unternehmen [4]. Mit Inkrafttreten der geänderten Abgabenordnung (AO) zum 01.01.2002 wird ergänzend zu den bisherigen Vorschriften das Recht eingeräumt, im Rahmen einer Außenprüfung „die mit Hilfe eines Datenverarbeitungssystems erstellte Buchführung des Steuerpflichtigen durch Datenzugriff zu prüfen“ [13]. Die Vorschriften tragen der Tatsache Rechnung, dass immer mehr kaufmännische und steuerrelevante Dokumente originär in digitaler Form anfallen. 464 Ergänzend zu den gesetzlichen Regelungen hat das Bundesministerium der Finanzen am 16.07. 2001 die „Grundsätze zum Datenzugriff und zur Prüfbarkeit digitaler Unterlagen“ (GDPdU) veröffentlicht [12]. Hierbei handelt es sich um eine Gesetzesinterpretation, die zwar für nachgeordnete Dienststellen der Finanzverwaltung verbindlich, allerdings für Unternehmen und Finanzgerichte nicht rechtlich bindend ist [4]. Einzelne Regelungen greifen dabei die bereits 1995 veröffentlichten Grundsätze ordnungsmäßiger DV-gestützter Buchführungssysteme (GoBS) [11] auf und ergänzen diese. In der Praxis zeigte sich, dass die GDPdU große Interpretationsspielräume bieten, die für Unklarheiten bei Unternehmen und Prüfern sorgen. Das BMF hat daher mehrfach einen Frage- und Antwortkatalog zur Explizierung der Regelungen veröffentlicht, zuletzt am 23.01.2008 [6]. 2.2.2 Internationaler Rahmen am Beispiel des Sarbanes Oxley Act Als Reaktion auf die Bilanzskandale um Firmen wie Enron, Xerox und Worldcom und zur Verbesserung von Qualität und Verlässlichkeit der Rechnungslegung wurde in den USA am 30.07.2002 der Sarbanes Oxley Act of 2002 (SOX) [17] verabschiedet [15]. Das Gesetz befasst sich im Wesentlichen mit Aspekten der Unternehmensführung und Geschäftsethik. Darunter sind auch Regelungen, die sich insbesondere auf die Ausgestaltung der IT-Systeme auswirken. So verpflichtet Section 302 des SOX bestimmte Mitglieder des Vorstandes eines Unternehmens zur Abgabe von eidesstattlichen Erklärungen über die Richtigkeit der Angaben in den Berichten an die Aufsichtsbehörden und zur rechtzeitigen Offenlegung wichtiger unternehmensrelevanter Ereignisse. Section 404 sieht weiterhin die Einrichtung eines internen Kontrollsystems zur Finanzberichterstattung vor, über dessen Einsatz und Effektivität regelmäßig Rechenschaft abgelegt werden muss. Dadurch sollen Investoren vor falschen oder unzureichenden Informationen geschützt werden. Um die Publikations- und Rechenschaftsverpflichtungen adäquat erfüllen zu können, ist die Unternehmensführung auf verlässliche Daten aus den unternehmensinternen IT-Systemen, insbesondere dem ERP-System, sowie die dokumentierte anforderungsgerechte Umsetzung der internen Kontrollsysteme angewiesen. Verbindlich sind die Vorschriften des SOX für alle Unternehmen, die der Überwachung durch die US-Börsenaufsicht unterliegen [15]. Dazu zählen alle Unternehmen, deren Wertpapiere an den amerikanischen Wertpapierbörsen gehandelt oder anderweitig öffentlich angeboten werden. Auch deren Tochtergesellschaften im Ausland sind von den Regelungen betroffen. Somit hat der SOX auch direkte Auswirkungen auf zahlreiche deutsche Unternehmen. 3 Untersuchung der Auswirkungen von GDPdU auf ERP-Systeme 3.1 Relevanz der GDPdU für ERP-Systeme Die GDPdU erweitern die Prüfungsmöglichkeiten, welche den Betriebsprüfern der Finanzverwaltung im Rahmen von Außen- und Zollprüfungen zur Verfügung stehen, um digitale Auswertungsmöglichkeiten. Betroffen von der zusätzlichen Zugriffsmöglichkeit sind steuerliche relevante originär digital vorliegende Daten. Von der steuerlichen Relevanz ist immer dann auszugehen, wenn die Daten die Grundlage für eine vermögens- oder ertragswirksame Buchung in der Finanzbuchhaltung des Unternehmens bilden. Als „originär digital vorliegend“ gelten Daten und Dokumente dann, wenn sie vom zu prüfenden Unternehmen mittels der eigenen Computersysteme selbst erzeugt oder diesem in digitaler Form zugesandt wurden. Steuerrelevante Daten fallen in vielen Computersystemen an. Explizit nennen die GDPdU die Anwendungen der Finanz-, Lohn- und Anlagenbuchhaltung. Darüber hinaus können sich solche Daten auch befinden in: Fakturierung und Materialwirtschaft (Ausgangsrechnungen, Lagerprotokolle, Artikelpreise etc.), Kosten- und Leistungsrechnung (Ermittlung von Herstellkosten, Kalkulation von Verrechnungspreisen etc.) oder Personalwirtschaft (Arbeitszeiterfassung etc.). Eine Abgrenzung der 465 konkret anfallenden steuerrelevanten Daten muss jeweils im Einzelfall unternehmensspezifisch vorgenommen werden. Wie die Beispiele bereits gezeigt haben, wird ein großer Teil dieser Daten typischerweise in ERP-Systemen verwaltet, sodass sich eine GDPdU-konforme Implementierung der Geschäftsprozesse beim Einsatz eines ERP-Systems direkt auf dessen Gestaltung auswirkt. 3.2 Datenzugriff durch die Finanzverwaltung 3.2.1 Zugriffsrechte der Finanzverwaltung Die GDPdU definieren drei Arten des Datenzugriffs: Unmittelbarer Datenzugriff (Z1) Beim unmittelbaren Datenzugriff hat der Betriebsprüfer der Finanzverwaltung vor Ort direkten Zugang zu den steuerrelevanten Daten des zu prüfenden Unternehmens [11, Abschnitt 1.1.a)]. Hierfür werden ihm die vorhandene Hard- und Software zur Verfügung gestellt. Der Zugriff umfasst das Lesen, Filtern und Sortieren der Daten, ggf. unter Nutzung vorhandener Auswertungsmöglichkeiten. Eine Installation von spezieller Prüf-Software, eine Übertragung von Daten auf Medien oder Geräte des Betriebsprüfers oder ein Fernzugriff auf die relevanten Daten erfolgt ausdrücklich nicht. Mittelbarer Datenzugriff (Z2) Beim mittelbaren Datenzugriff nimmt das zu prüfende Unternehmen (ggf. ein von diesem Beauftragter Dritter) auf Veranlassung des Betriebsprüfers selbst die Auswertung vor, indem es die vorhandenen Auswertungsmöglichkeiten der eingesetzten kaufmännischen Software nutzt [11, Abschnitt 1.1 b)]. Im Rahmen der Verhältnismäßigkeit (abhängig von der Betriebsgröße) müssen zu diesem Zweck während des Zeitraums der Prüfung Mitarbeiter abgestellt werden. Datenträgerüberlassung (Z3) Bei der Datenträgerüberlassung erhält der Betriebsprüfer auf Anforderung (ggf. einen Auszug) der relevanten Daten des Prüfungszeitraums in Form eines Datenträgers [11, Abschnitt 1.1 c)]. Die Daten werden hierzu aus den entsprechenden Softwaresystemen exportiert. Zur Rekonstruktion durch den Prüfer müssen dabei neben den reinen Nutzdaten auch Informationen über die Struktur der exportierten Daten in einem möglichst maschinell auswertbaren Format bereitgestellt werden. Die überlassenen Datenträger werden vom Betriebsprüfer auf Computern der Finanzverwaltung ausgewertet. Hierbei kommen auch spezielle Datenanalyse-Werkzeuge zum Einsatz. Nach der Prüfung werden die überlassenen Datenträger gelöscht oder zurückgegeben. Umfang der Prüfung Gemäß den Vorgaben der AO müssen die steuerrelevanten Daten zehn Jahre vorgehalten werden. Prinzipiell können im Rahmen einer elektronischen Außenprüfung daher Daten aus dem Zeitraum angefordert werden. Für Daten, die vor 2002 archiviert wurden, gelten Übergangsregelungen. 3.2.2 Aktuelle Ausgestaltung des Datenzugriffs Der Prüfer kann grundsätzlich die Art des Zugriffs auf die Daten frei bestimmen und dabei auch unterschiedliche Verfahren kombinieren. Dabei ist die Verhältnismäßigkeit zu berücksichtigen. Die Analyse der durch Datenträgerübertragung erhaltenen Daten werden bundeseinheitlich mittels den Software-Tools „IDEA“ und „AIS TaxAudit“ der Firma Audicon ausgewertet. Dabei handelt es sich um eine Werkzeug-Sammlung zur statistischen Datenanalyse bzw. einer Makro-Sammlung zur Automatisierung von bestimmten Prüf-Mustern, die auf dem Gebiet der Wirtschaftsprüfung weit verbreitet sind. Die Übertragung der Daten zwischen den Quellsystemen des Unternehmens und den Computern der Prüfer erfolgt ausschließlich über Datenträger. Als Export-Format für die Quellda- 466 ten werden diverse Datenformate unterstützt (ASCII-Text-Listen, verschiedene Office-Dateiformate, auch eine Datenbankschnittstelle steht zur Verfügung). Für die Speicherung der zusätzlich geforderten Meta-Daten existiert ein Beschreibungsstandard in Form eines XML-Derivats [5]. 3.3 GDPdU-konforme Ausgestaltung von ERP-Systemen 3.3.1 Archiv-Systeme Bei der GDPdU-konformen Gestaltung eines ERP-Systems müssen alle für den elektronischen Zugriff durch die Finanzverwaltung relevanten Daten über den kompletten vorgeschriebenen Archivierungszeitraum hinweg gespeichert werden. Die Aufbewahrungsfristen werden in § 147 der AO geregelt: So sind Bücher, Aufzeichnungen, Buchungsbelege und Jahresabschlüsse zehn Jahre lang aufzubewahren, während Handels- und Geschäftsbriefe sowie sämtliche weiteren steuerrelevanten Unterlagen über einen Zeitraum von sechs Jahre vorgehalten werden müssen. Die Anforderungen des Datenzugriffs gemäß GDPdU sind erfüllt, solange alle Daten des festgesetzten Prüfungszeitraums im ERP-System recherchiert und ausgewertet sowie auf einen externen Datenträger exportiert werden können. In der Praxis fallen aber je nach Unternehmensgröße so viele steuerrelevante Daten an, dass regelmäßig Vergangenheitsdaten aus dem operativen System ausgelagert werden müssen, um dessen Leistungsfähigkeit zu erhalten. In großen Unternehmen besteht u. U. der Bedarf nach unterjähriger Auslagerung [3]. Die Auslagerung von Teilen des Datenbestandes wird besonders problematisch, wenn die ERP-Lösung eines Unternehmens in Form einer Service-orientierten Architektur konzipiert ist. Die dort ohnehin bestehende Komplexität auf Grund der verteilten Datenhaltung wird erhöht. In solchen Fällen kommt die Ergänzung des ERP-Systems um ein elektronisches Archiv in Betracht. Darunter wird hier ein Anwendungssystem verstanden, das der langfristigen und sicheren Aufbewahrung von Daten dient [14]. Es stellt dabei die Unveränderlichkeit der eingelagerten Daten (Revisionssicherheit) und deren schnelle Auffindbarkeit bei Bedarf sicher. Ein solches System besteht i. d. R. aus mehreren Komponenten [14]. Das Archivmanagement-System steuert die (automatisierbare) Ein- und Auslagerung der archivierungspflichtigen Daten und stellt Suchfunktionalitäten bereit. Dazu greift es auf einen ggf. datenbankgestützten Index zurück. Die zu archivierenden Datenbestände selbst werden im Speichersystem abgelegt. Je nach Ausgestaltung kommen dabei z. B. WORM-Medien (write-once-read-many) zum Einsatz. Die Finanzverwaltung lässt die Archivierung von Daten prinzipiell zu, fordert aber für die archivierten Daten „in quantitativer und qualitativer Hinsicht äquivalente“ Auswertungsmöglichkeiten für Produktions- und Archivsystem [6, Frage III, 11]. Die vielfältigen Auswertungsmöglichkeiten von aktuellen ERP-Systemen sind aber in Archivsystemen konzeptbedingt typischerweise nicht vorgesehen [3]. Die Archivdaten müssten also zu Auswertungszwecken in das Produktivsystem zurück übertragen werden. Dies ist jedoch in den seltensten Fällen wirtschaftlich, wenn nicht gar technisch unmöglich (auf Grund von Inkompatibilitäten wegen zwischenzeitlich geänderter Datenstrukturen im Produktivsystem, Konflikten mit geänderten Stammdaten etc.). Um den Forderungen der GDPdU zu entsprechen, müsste ein Archiv also um Auswertungsmöglichkeiten ergänzt werden. Die Notwendigkeit zur Ausstattung des Archivs mit „äquivalenten“ Auswertungsmöglichkeiten kann jedoch kritisch gesehen werden, da die technische Umsetzung der Anforderung auf Grund des damit verbundenen Aufwandes unverhältnismäßig erscheint [3], [10]. Die IT-Branchenverbände BITKOM und VOI sind der Meinung, dass die Ergänzung des Archivs um eine Exportschnittstelle für das IDEA-Datenformat (zumindest nach konkreter Prüfung im Einzelfall) geeignet ist, um den gesetzlichen Anforderungen zu entsprechen [3], [4]. Ein Betriebsprüfer hätte so in jedem Fall die Möglichkeit, die Standard-Auswertungsverfahren der Finanzverwaltung mittels der entsprechenden Software-Werkzeuge durchzuführen. In Anlehnung an [10] schlagen wir einen GDPdU-konformen Prozess zur Datenübernahme in ein digitales Archiv folgendermaßen vor: 467 1. Periodengerecht werden die steuerrelevanten Daten aus dem ERP-System extrahiert. Die Speicherung dieser Daten erfolgt im IDEA-Format. 2. Die exportierten Daten werden an das Archivsystem übergeben. 3. Das Archivsystem indiziert die Daten und nimmt ggf. eine Versionierung vor, falls die gleichen Daten gewollt oder fehlerhaft mehrfach übertragen werden. 4. Es erfolgt die Ablage der Daten im Speicher des Archivsystems. Die Korrektheit der Einlagerung wird automatisch überprüft. Eine Protokollierung der Vorgänge erfolgt parallel. Sollen archivierte Daten ausgewertet werden, wird eine Suchanfrage an das Archivsystem gestellt. Die Suchergebnisse können im IDEA-Format geladen werden, sodass ein Datenzugriff nach Art Z3 möglich ist. Steht ein universelles Auswertungsprogramm mit der Mächtigkeit der Finanzverwaltungssoftware IDEA zur Verfügung, das direkt auf das Archiv zugreifen kann, ist ein Zugriff nach Z1 – Z3 über ein einziges, integriertes System möglich. 3.3.2 Spezielle Nutzerrollen für Prüfer Beim Z1-Zugriff auf die Daten des zu prüfenden Unternehmens arbeitet der Prüfer direkt mit dem ERP-System. Er benötigt daher zwecks Authentisierung und Autorisierung einen eigenen Benutzerzugang, der über Leserechte für die relevanten Daten verfügt. Das Unternehmen hat dafür Sorge zu tragen, dass der Prüfer nur auf diejenigen Daten zugreifen kann, für die er ein Prüfmandat besitzt [11, Abschnitt I.2 a)]. Ein Verwertungsverbot für versehentlich überlassene Daten besteht nicht [6, Frage I, 14]. Daher sollte das geprüfte Unternehmen die Zugriffsberechtigungen so restriktiv wie möglich vergeben, um keinen unnötig weit reichenden Datenzugriff zu gewähren, was auch im Hinblick auf die Wahrung der Datenschutzrechte der Kunden des Unternehmens geboten erscheint. Dies trifft insbesondere auf Branchen und Unternehmen zu, für die besonders sensible (evtl. berufsständische) Vertraulichkeitsbestimmungen gelten [7]. Sinnvoll ist es weiterhin, die Aktionen, die mit einem Prüfer-Benutzerzugang durchgeführt werden, detailliert zu protokollieren [7]. Dies erleichtert es, die Recherche-Ergebnisse des Prüfers nachzuvollziehen und ermöglicht so eine bessere Vorbereitung des Abschlussgesprächs zur Betriebsprüfung. Auch können Informationen über die relevanten Prüfgebiete gewonnen werden, was die Vorbereitung auf künftige Betriebsprüfungen erleichtert. So können vorab schon Prüfungen auf Basis früherer Prüf-Profile simuliert werden, um eventuelle Probleme im Voraus zu erkennen und zu beheben. Somit kann die echte Prüfung beschleunigt werden, was die Kosten aller Beteiligten senkt. 3.3.3 Datenexport zur Vorbereitung der Datenträgerüberlassung Nur eine Teilmenge des gesamten Datenbestandes eines ERP-Systems unterliegt auf Grund des Kriteriums der steuerlichen Relevanz prinzipiell dem Zugriffsrecht der Finanzverwaltung im Rahmen der Datenträgerüberlassung [11, Abschnitt I.1]. Die zur Beantwortung einer Datenzugriffsanfrage nach Z3 konkret benötigte Datenmenge wird weiterhin durch das Prüfziel des Betriebsprüfers eingeschränkt (betroffener Zeitraum, inhaltliche Ausrichtung). Aus den in Kapitel 3.3.2 genannten Gründen ist weiterhin eine Beschränkung des Datenexportes auf das unbedingt benötigte Maß sinnvoll. Hinsichtlich der datenschutzrechtlichen Verantwortung treffen diese Überlegungen in besonderem Maße zu, da die Übertragung der Daten ausdrücklich unverschlüsselt erfolgen muss und die Datenträger somit bei Verlust ungeschützt wären [3]. Angesichts der komplexen Datenmodelle des Systems bedarf es einer Werkzeugunterstützung seitens des ERP-Systems für den Exportprozess. Nur so kann eine bedarfsgerechte und effiziente Bereitstellung der gewünschten Daten erfolgen. Zunächst sollte für jeden Bereich des Datenmodells, das dem System zu Grunde liegt, möglichst feingranular dessen steuerliche Relevanz definierbar sein. Dies trägt der Tatsache Rechnung, dass die Frage nach der Relevanz je nach Unternehmen unterschiedlich beurteilt werden kann. Auf die468 ser Basis bietet sich ein Assistenten-gestütztes Vorgehen an, um für verschiedene Prüfzwecke Sichten auf das gesamte Datenmodell zu definieren, die zur Selektion der zu Daten genutzt werden können. Mit dem Data Retention Centre [7] verfolgt z. . SAP einen ähnlichen Ansatz. Für den Datenexport nach Z3 hat die Finanzverwaltung einen Standard entwickelt („IDEAFormat“) [5]. Obwohl dessen Verwendung z. Zt. nur empfohlen und nicht vorgeschrieben wird, sollten ERP-Systeme künftig eine Exportmöglichkeit im IDEA-Format bereithalten. Neben seiner Kernaufgabe beim Datenaustausch mit der Finanzverwaltung ist er eine geeignete Basis für die Integration heterogener Teilsysteme in eine GDPdU-konforme Gesamtlösung (vgl. Abschnitt 3.2.2). 4 Untersuchung der Auswirkungen des SOX auf ERP-Systeme 4.1 Relevanz des Sarbanes Oxley Act für ERP-Systeme Im Gegensatz du den zuvor thematisierten GDPdU stellt der Sarbanes Oxley Act (SOX) keine direkten Anforderungen an die Gestaltung betrieblicher Anwendungssysteme. Diese ergeben sich erst durch die Operationalisierung der Anforderungen, die das Gesetz an die Unternehmensleitung stellt. Das Ziel hinter dem SOX ist eine Verbesserung von Qualität und Verlässlichkeit der betrieblichen Rechnungslegung. Ein zentrales Mittel zur Umsetzung dieses Ziels ist die Etablierung eines Risikomanagements und eines internen Kontrollsystems (IKS) [16, Section 404]. Bei der Ausgestaltung des IKS werden die Gefahren, die eine Erreichung des Ziels verhindern könnten, strukturiert und einzelnen Risiken gezielte Abwehrmaßnahmen zugeordnet. Hierbei ergeben sich oft konkrete Anforderungen für die IT eines Unternehmens. Der SOX sieht vor, dass das IKS nach einem allgemeinen Rahmenwerk gestaltet wird. Eines der am weitesten verbreiteten Rahmenwerke ist hierbei das Modell des Committee of Sponsoring Organizations of the Treadway Commission (COSO). COSO definiert das IKS als einen „Prozess, der von Aufsichtsgremien, Management und Mitarbeitern ausgeführt wird, um das Erreichen vorgegebener Ziele mit hinreichender Sicherheit zu gewährleisten.“ Als Ziel im Rahmen des Einsatzes von COSO zur SOX-Compliance wird die „Ordnungsmäßigkeit und Verlässlichkeit der Finanzberichterstattung“ verwendet. Alle Hindernisse zur Erreichung eines Ziels werden im Sinne von COSO als Risiken betrachtet. Um Risiken wirksam zu vermindern, sollen Kontrollen eingesetzt werden. Diese werden in die Geschäftsprozesse integriert, um ihre regelmäßige Ausführung sicherzustellen. 4.2 SOX-konforme Ausgestaltung von ERP-Systemen 4.2.1 Von der internen Kontrolle zur Aufgabe für die IT An einem Beispiel soll hier aufgezeigt werden, wie aus einer nicht-technischen Kontrolle eine Anforderung an das ERP-System abgeleitet werden kann. Es sei im Rahmen der Risikoanalyse in Anlehnung an [18] folgendes (vereinfachtes) Schema für eine interne Kontrolle erarbeitet worden:  Kontrollziel: Ordnungsmäßige Verbuchung der Umsätze für ausgehende Lieferungen.  Risiko: Betrügerische Schein-Buchungen zur Sicherung von erfolgsabhängigen Gehaltsbestandteilen der Verkäufer.  Kontrollmaßnahme: Trennung der Rollen – Vertriebsmitarbeiter dürfen keine Warenbewegungen zu eigenen Abschlüssen / Umsätzen buchen. Die vorgestellte interne Kontrolle bezieht sich zunächst nur auf organisatorische Aspekte und manuelle Vorgänge. Geht man aber davon aus, dass für die angesprochenen Buchhaltungsvorgänge auf IT-Systeme wie z. B. die Module „Finanzbuchhaltung“ und „Warenwirtschaft“ eines ERP-Systems gesetzt wird, so müssen die Kontrollmaßnahmen um Aspekte der IT erweitert werden. 469 Das organisatorische Konzept der Trennung von Rollen und Verantwortlichkeiten muss sich auch im ERP-System widerspiegeln. Um ein funktionsfähiges und vor allem gut pflegbares rollenbasiertes Sicherheitskonzept zu unterstützen, sollte ein ERP-System u. E. folgende Merkmale ausweisen:  Vor jeder Interaktion mit dem System muss sich jeder Nutzer mit einer eindeutigen, geschützten (durch ein Passwort) Kennung am System anmelden.  Den Nutzern müssen jeweils eine oder mehrere Rollen zugewiesen werden können.  Es muss in Form von Access-Control-Lists (ACL) detailliert festgelegt werden können, welche Rolle mit welchen Modulen bzw. Daten des Systems welche Aktionen durchführen darf.  Vor Ausführung jeder einzelnen Aktion muss anhand des angemeldeten Nutzers und der ACL geprüft werden, ob der gewünschte Zugriff möglich ist. 4.2.2 Besondere Auswirkungen von SOA-basierten ERP II-Systemen In einer traditionellen ERP-Architektur lässt sich das beschriebene Sicherheitskonzept recht unproblematisch umsetzen bzw. ist in vielen Systemen umgesetzt [15]. Sinnvollerweise werden alle Module des ERP-Systems auf die gemeinsame Datenbasis zurückgreifen, die dann eine zentrale Nutzerliste samt zugehöriger Rollen- und Rechte-Definitionen enthalten muss. Für die einzelnen Services einer SOA ist dies nicht in jedem Falle möglich. Bei der Einbindung von unternehmensexternen Services, die ein zentrales Motiv für eine SOA darstellt, muss davon ausgegangen werden, dass diese Services eigene Nutzerverwaltungen besitzen. Sind unternehmensexterne Services am Prozess beteiligt, benötigt der prozessausführende Nutzer bei mehreren Service-Betreibern Benutzerkonten mit entsprechend vergebenen Berechtigungen. Dies ist sehr wartungsaufwändig und potentiell fehlerträchtig. Eine Lösung wäre ein zentraler Nutzerverwaltungs-Service, der jeweils zur Berechtigungsprüfung herangezogen wird. In der Praxis dürfte sich die Frage nach dem Betrieb des Services stellen, da dieser Instanz von allen Beteiligten großes Vertrauen entgegengebracht werden muss. Eine weitere Herausforderung liegt in der Anwendungs-zu-Anwendungs-Kommunikation, die charakteristisch für eine SOA ist [18]. Die gängigen internen Kontrollen zur Sicherstellung der Rollentrennung basieren auf Nutzer-Authentifikation. In einer SOA kann sich möglicherweise eine Anwendung anstelle einer Person bei einem Webservice anmelden (z. B. ein ERP-System, dass so programmiert ist, dass es bestimmte Bestellungen automatisch per Webservice-Aufruf an die jeweiligen Lieferanten verschickt). Der konkrete Nutzer der Anwendung, die den Webservice-Aufruf samt Authentifizierungsanfrage ausgelöst hat, lässt sich nicht erkennen. Bei der Berechtigungsvergabe ist auf diese Aspekte Rücksicht zu nehmen. Insbesondere dürfen Zugriffsrestriktionen nicht unterlaufen werden können: Ein Nutzer, dem mit seinem persönlichen Benutzerkonto eine bestimmte Aktion nicht erlaubt ist, darf keinen Zugriff auf ein System haben, dass sich über ein anonymes Anwendungs-Benutzerkonto beim Webservice anmeldet und die fragliche Aktion ausführen kann [18]. Die Realisierung eines Rechtemanagements, welches den beschriebenen besonderen Anforderungen gerecht wird, kann auf der in Entity-Relationship-Modell-Form in Abbildung 1 vorgeschlagenen Erweiterung des allgemeinen Rechtemanagements aufsetzen. Grundlage des Modells ist eine Modifikation des Ansatzes der „Role-Based Access Control“ [8]. Der Ansatz sieht vor, dass ein Benutzer eine bestimmte Aktion (Lese- oder Schreibzugriff, Ausführung einer Operation etc.) auf einem geschützten Objekt nur dann durchführen darf, wenn in einer „Access Control List“ ein Eintrag existiert, der genau dies gestattet. Um die Verwaltung der Berechtigungen zu vereinfachen, erfolgt deren Vergabe nicht an einzelne Benutzerkonten („Mitarbeiter Hans-Dieter Schmidt“) sondern an Benutzerrollen („Mitarbeiter Vertriebsinnendienst“). Die Benutzerkonten unterscheiden sich in personengebundene und in (anonyme) anwendungsbezogene Konten. Bei einem geschützten Objekt kann es sich um eine im ERP-System verfügbare Information handeln oder um einen Service, der eine bestimmte Funktionalität bereitstellt, zu deren Realisierung er auf Informationen des ERP- 470 Systems zugreift bzw. diese verändert. Die vom Service benötigten Informationen können selbst geschützt sein. Der Service muss somit beim Rechteverwaltungssystem ein Benutzerkonto und die zugehörigen Authentifizierungsmerkmale angeben, um den Zugriff auf die gewünschten Informationen durchführen zu können. Bei der praktischen Implementierung einer SOA kann es vorkommen, dass hierzu nicht etwa die Login-Informationen des Nutzers, der den Service aufgerufen hat, „durchgereicht“ werden. Stattdessen verfügt der Service über ein eigenes anwendungsbezogenes Nutzerkonto, das mit entsprechenden Zugriffsrechten ausgestattet ist. Prinzipiell besteht daher an dieser Stelle die Gefahr, dass Zugriffsrechte unbeabsichtigt ausgeweitet werden, wenn ein Service, auf den ein Nutzer zugreifen darf, seinerseits Informationen nutzen bzw. verändern kann, auf die der Nutzer keinen expliziten Zugriff hat. Sind aber die Abhängigkeiten zwischen Services und den von ihnen benötigten Informationen sowie die Zugriffsrechte der einzelnen Nutzer(rollen) auf Informationen und Services vollständig im Datenmodell erfasst, können etwaige Inkonsistenzen bei der Berechtigungsdefinition automatisiert aufgedeckt werden. Hierzu muss ein Abgleich durchgeführt werden zwischen den Informationen, auf die eine Nutzerrolle expliziten Zugriff hat und den Informationen, auf welche die Services zugreifen können, die von der jeweiligen Nutzerrolle genutzt werden dürfen. Darüber hinaus kann eine Prüfung bereits in den Prozess zur Vergabe von Berechtigungen integriert werden, um auf Inkonsistenzen bereits bei ihrer Entstehung hinzuweisen. Access Control List Lesezugriff (0, n) (0, n) Aktion N,P Schreibzugriff (1, 1) Information (0, n) ACLEintrag geschütztes Objekt (0, n) D,T Service (0, n) (0, 1) anwendungsgebundenes Konto (0, n) Rolle (0, n) BenutzerRolle-ZuO (0, n) Benutzerkonto (1, 1) D,T personengebundenes Konto Abbildung 1: Ableitung eines erweiterten Entity-Relationship-Modells zum Rechtemanagement 5 Fazit Es wurde gezeigt, dass sich Compliance-Vorschriften sowohl direkt als auch indirekt auf die Gestaltung von ERP-Systemen auswirken können. In Deutschland stellen die GDPdU die Vorschriften mit der größten Reichweite dar, da sie jedes Unternehmen betreffen. Auch Vorschriften aus dem ausländischen Rechtsraum müssen u. U. beachtet werden. Ein Beispiel hierfür ist der Sarbanes Oxley Act, der Unternehmen betrifft, die sich über die amerikanischen Kapitalmärkte finanzieren. Bezüglich ihrer Auswirkung auf die ERP-Systeme können die Compliance-Regeln unterschieden werden in Vorschriften, die sich direkt auf ERP-Systeme beziehen (z. B. GDPdU) sowie Vorschriften, die sich indirekt auf ERP-Systeme auswirken, da sie Ziele verfolgen, welche sich nur mit ITUnterstützung erreichen lassen (z. B. Sarbanes Oxley Act). Letztgenannte bedürfen einer strukturierten Vorgehensweise, um die relevanten Konsequenzen für die Gestaltung von ERP-Systemen herauszuarbeiten. Hierfür existieren entsprechende weithin anerkannte Rahmenwerke wie COSO. 471 Vorschriften wie die GDPdU, die direkten IT-Bezug haben, machen einerseits detaillierte Vorgaben für die Ausgestaltung betroffener Systeme. Andererseits lassen sie aber auch immer noch viel Interpretationsspielraum. Problematisch erweist sich in diesem Zusammenhang, dass die GDPdU keinen Gesetzesrang haben, sondern lediglich eine Interpretation der Finanzverwaltung darstellen. Wichtige ERP-Hersteller haben inzwischen Werkzeuge für die effiziente Gestaltung des elektronischen Datenzugriffs nach GDPdU in ihre Produkte integriert. Auf dem Gebiet der langfristigen Vorhaltung großer Datenmengen zu Prüfzwecken gibt es hingegen noch Bedarf für Lösungen, die vollständig von den gesetzlichen Vorgaben gedeckt sind und gleichzeitig die Verhältnismäßigkeit des nötigen Umsetzungsaufwandes berücksichtigen. Der Artikel ist ein erster Grundlagenbeitrag in diesem Forschungsgebiet. Weiterführend ist der Status Quo der Abdeckung bzw. Umsetzung in ERPSystemen auf Basis der dargelegten Erkenntnisse empirisch zu analysieren sowie das vorgeschlagene ergänzende Rechtemodell in einem SOA-System zu implementieren und zu evaluieren. Literaturverzeichnis [1] Becker, J.; Vering, O.; Winkelmann, A.: Unternehmenssoftwareeinführung: Eine strategische Entscheidung. In: Softwareauswahl und -einführung in Industrie und Handel. Hrsg.: J. Becker, O. Vering, A. Winkelmann. Berlin 2007, S. 6-30. [2] Bianco, P.; Kotermanski, R.; Merson, P.: Evaluating a Service-Oriented Architecture. 2007. ftp://ftp.sei.cmu.edu/pub/documents/07.reports/07tr015.pdf. Abrufdatum 2008-06-25. [3] BITKOM: Leitfaden zum elektronischen Datenzugriff der Finanzverwaltung. Steuerrechtliche Anforderungen und Technologien zu Datenaufbewahrung. 3. Auflage. Berlin 2006. [4] Brand, T.; Groß, S.; Lindgens, B.; Zöller, B.: Leitfaden für die Durchführung eines Projektes zur Abdeckung der Anforderungen der Grundsätze zum Datenzugriff und zur Prüfbarkeit digitaler Unterlagen (GDPdU). Version 1.0 vom November 2003. Bonn 2003. [5] Bundesministerium der Finanzen (BMF): Information zum „Beschreibungsstandard für die Datenträgerüberlassung“. 2002. http://www.bundesfinanzministerium.de/nn_53848/DE/BMF__Startseite/Service/Downloads/Abt__IV/ 010,property=publicationFile.pdf. Abrufdatum 2008-06-25. [6] Bundesministerium der Finanzen (BMF): Fragen und Antworten zum Datenzugriffsrecht der Finanzverwaltung. 2008. http://www.bundesfinanzministerium.de/nn_53848/DE/BMF__Startseite/Service/Downloads/Abt__IV/ 009,property=publicationFile.pdf . Abrufdatum 2008-06-25. [7] Deutschsprachige SAP Anwendergruppe e.V.: Empfehlungen zur Anwendung der GDPdU. 2006. http://www.dsag.de/index.php?lang=de&active_main_chapter=arbeitskreise&aknr=115#103. Abrufdatum 2007-12-13. [8] Ferraiolo, D.F., Kuhn, D.R.: Role Based Access Control. In: Proceedings of the 15th National Computer Security Conference. 1992. http://csrc.nist.gov/rbac/ferraiolo-kuhn-92.pdf. Abrufdatum: 2008-06-22. [9] Fuchs, C.: Begriffserklärung ERP II. 2007. http://www.logistikinside.de/fm/2248/Durchblick%20Business%20Software.pdf. Abrufdatum 2008-06-25. [10] Groß, S.; Kampffmeyer, U.: GDPdU & Archivierung: Endlich Klarheit. 2003. http://www.contentmanager.de/ magazin/artikel_406_gdpdu_archivierung_ii.html. Abrufdatum 2008-06-25. [11] Grundsätze ordnungsmäßiger DV-gestützer Buchführungssysteme (GoBS). BMF-Schreiben vom 07.11.1995. Bundessteuerblatt 1995, BStBl. Teil I, S. 738ff [12] Grundsätze zum Datenzugriff zur Prüfbarkeit digitaler Unterlagen (GDPdU). BMF-Schreiben vom 16.07.2001. Bundessteuerblatt 2001, BStBl. Teil I, S. 415ff [13] Kampffmeyer, U.; Zöller, B.: Die GDPdU und ihre Anforderungen zur elektronischen Archivierung. Gemeinsame Stellungnahme. Hamburg und Sulzbach/Taunus 2003. [14] Kampffmeyer, U.: GDPdU & elektronische Archivierung. 2005. http://www.projectconsult.net/Files/GDPdU_Archivierung.pdf. Abrufdatum 2008-06-25. [15] Menzies, C.: Sarbanes-Oxley Act. Professionelles Management interner Kontrollen. Stuttgart, 2004. [16] Möller, C.: ERP II. A conceptual framework for next-generation enterprise systems? In: Journal of Enterprise Information Management. 18 (2005) 4, S. 483-497. [17] Sarbanes Oxley Act of 2002 (SOX 2002) vom 23.01.2002. The Library of Congress (Thomas) H.R. 3763 [18] Taylor, H.: Managing SOX in the Age of SOA. 2006. http://soagovernancearchitect.com/2006/05/26/managingsox-in-the-age-of-soa.aspx. Abrufdatum 2008-06-25. [19] Werner, H.: SCM. Grundlagen, Strategien, Instrumente und Controlling. 2. Aufl., Wiesbaden 2002. [20] Winkelmann, A.; Klose, K.: Experiences while selecting and implementing ERP systems in SMEs: a case study. In: Proceedings of the American Conference on Information Systems (AMCIS'08). Toronto, Ontario, Canada, 2008. 472 DIE AUSWIRKUNGEN VON SOZIALEN MOTIVEN AUF DIE RECHTS- UND HAFTUNGSSITUATION AM BEISPIEL OFFENER NETZE Reto Mantz1 Kurzfassung Business Services im Internet sind extrem vielfältig. Sowohl die beteiligten Personen, die ausgetauschten Leistungen, die Form des Austauschs sowie die Motive der Beteiligten sind unterschiedlich. Die folgende Arbeit soll klären, ob und inwiefern soziale oder altruistische Motive Einfluss auf die Rechtsgestaltung, also die vertragliche Auslegung und Einordnung, sowie die Haftungssituation bei typischen und untypischen IT-Verträgen haben können. Dafür sollen zunächst anhand des Beispiels offener Netze soziale Motive erarbeitet und erläutert werden. Anschließend werden die Auswirkungen dieser Motivation auf die vertragliche Auslegung durch Betrachtung zweier Situationen der Leistungserbringung (anonyme Kommunikation ohne explizite (AGB-ähnliche) Vertragsgrundlage einerseits und Verwendung eines offenen „Vertrages“ andererseits) anhand des deutschen Rechts untersucht. Nach der Gestaltung ist die Frage nach dem Einfluss der Motivation auf die Haftung der Beteiligten zu stellen. Hierfür soll die aktuelle Rechtslage im Bereich der Störerhaftung sowie des Auskunftsanspruchs beleuchtet werden. 1. Offene Netze Offene Netze (oder „freie Netze“) sind Funknetzwerke, die nicht von kommerziellen Anbietern, sondern hauptsächlich von Privatpersonen, teilweise auch von gemeinnützigen Vereinen, betrieben werden. Offene Netze bieten jedem Interessierten die Möglichkeit, zum einen das offene Netz zu nutzen und zum anderen Teil des Netzwerks zu werden und aktiv an dessen Weiterentwicklung und dessen Angebot mitzuwirken. Ein einzelner Funkknotenbetreiber stellt also Dritten – in Zusammenarbeit mit anderen Betreibern Zugang zum Netzwerk und eventuell auch zum Internet zur Verfügung. Er ist damit klar als Access Provider einzuordnen, der einen ähnlichen Dienst erbringt wie z.B. die Deutsche Telekom oder ihre Konkurrenten. Offene Netze bilden Gemeinschaften, die sich sowohl regional als auch überregional organisieren und große Funknetzwerke schaffen, die allen Beteiligten und auch interessierten Dritten Zugang zum Netzwerk selbst und zum Internet gewähren. Nur ein typisches Beispiel ist die Initiative 1 Heymann & Partner Rechtsanwälte, Frankfurt/M. 473 freifunk.net in Berlin (http://www.freifunk.net), die mit derzeit ca. 1000 aktiven Knoten das weltweit größte Netzwerk stellt. Aber auch in anderen Städten bilden sich solche Gemeinschaften und bauen offene Netze auf (für eine unvollständige Übersicht der Initiativen s. https://freifunk.net/community). Dabei versteht sich die Freifunk-Community als Teil einer globalen Bewegung für freie Infrastrukturen. Es gibt regelmäßige Kontakte und Zusammenarbeit mit anderen Initiativen auch im Ausland. Offene Netze in ihrer generellen Form zeichnen sich zusätzlich dadurch aus, dass die Teilnahme am Netzwerk gleichzeitig dem Aufbau des Netzwerks selbst dient. Durch – teilweise selbst entwickelte – Routing-Protokolle auf Basis des sog. Ad-Hoc-Modus ist jeder Funknetzknoten nicht nur Client, sondern auch Zugangs- und Vermittlungspunkt. Der „Nutzer“ eines Netzwerks ist also gleichzeitig auch dessen „Betreiber“. 2. Wirtschaftliche und gemeinnützige Motive Das Internet hat sich als wesentlicher Wirtschaftsraum etabliert. Der Waren- und Dienstleistungsumsatz über das Internet weist beständige Wachstumsraten auf. Das Internet hat außerdem neue Vertriebswege und Wirtschaftsmodelle befördert bzw. hervorgebracht. Dennoch sind die meisten rechtlichen Beziehungen im Internet als „klassische“ Verträge zu werten, bei denen die Leistungsbeziehung in Form eines Synallagmas eindeutig ist. Die Übertragung der allgemeinen rechtlichen Grundsätze auf diese Internet-Verhältnisse hat zwar zu Umbrüchen und Anpassungen im Rechtssystem geführt, ist aber weitgehend ohne grundlegende Systemveränderung durchgeführt worden. Als Beispiel unterscheidet sich der über das Internet abgeschlossene Kaufvertrag kaum vom klassischen Kaufvertrag. Lediglich beim Verbraucherschutz und im Rahmen der Durchführung des Vertrages haben sich größere Veränderungen ergeben. Auch ASPVerträge, die sich durch ihre im Internet begründete Dezentralität auszeichnen, haben als Dienstverträge (BGH CR 2007, 75) ihren Platz in der Dogmatik des BGB gefunden. Die Motivation der Beteiligten hat sich hingegen kaum geändert. Der europäische Binnenmarkt ist ein Wirtschaftsraum, in dem auch im Internet wirtschaftliche Motive vorherrschen. Veränderungen hat das Internet aber dennoch dadurch gebracht, dass die Vernetzung sowie die Etablierung neuer Kommunikationswege auch die Potenzierung von gemeinschaftlicher Arbeit auf der Basis von „Mitmachmodellen“ befördert hat. Deutliches Beispiel hierfür sind die Phänomene Open Source und Open Content - und mit Abstrichen Open Access (eingehend zur Motivation und rechtlichen Einordnung [1]). Die Motivation der Beteiligten an diesen Modellen ist eine andere – sie ist im weitesten Sinne gemeinnützig. Natürlich haben die einzelnen Beteiligten auch persönliche Interessen, die sie durch die Investition ihrer Arbeit verfolgen – beispielsweise Reputationsgewinn oder persönliche Weiterbildung - aber in der Regel herrschen eher gemeinnützige Motive vor. Auf dieser Ebene sind auch offene Netze anzusiedeln. Sie werden dabei ebenso als Etablierung einer „Netzwerk-Allmende“ begriffen, die als Parallele zu Open Source oder Open Content freien Zugriff auf Netzwerke und das Internet umfasst. Die Idee des offenen und freien Netzes ist damit Ausdruck einer fremdnützigen, altruistischen Motivation der Betreiber. Diese Idee stellt zumindest ein wesentliches Element der unterschiedlichen Motivationswege der Beteiligten dar. Die Beweggründe spiegeln sich zudem in dem Bestreben wider, den sog. „Digital Divide“ sowohl national [2] als auch international [3] zu überwinden. 474 3. Vertragliche Konstruktion? 3.1. Die Trennung zwischen Nutzer und Diensteanbieter - Auflösung eines Rollenparadigmas Betrachtet man die gesetzlichen und anderen rechtlichen Konzeptionen, die bei der Behandlung von Fragen im Zusammenhang mit technischen Netzwerken zusammenhängen, so lässt sich feststellen, dass bis auf wenige Ausnahmen eine Zweiteilung im Sinne einer klaren Rollenverteilung besteht. Netzwerk- und Internetdienste werden von einem Diensteanbieter angeboten und von einem Dienstnutzer konsumiert. Daraus lässt sich auf ein grundsätzliches Rollenparadigma schließen, das nach der eingenommenen Funktion des Teilnehmers differenziert. Die Abgrenzung nach der Funktion ist durchaus sinnvoll und erleichtert das Verständnis für die Vielzahl der im Internet eingegangenen (Rechts)Beziehungen. Zusätzlich deckt sich dieser Befund selbstverständlich mit dem synallagmatischen Verständnis von Verträgen mit Austauschbeziehung. Diese Rollenverteilung lässt sich ohne weiteres überall dort aufrecht erhalten, wo sich die persönliche Handlung ebenso klassifizieren lässt: Der Kunde des Access Providers nutzt den vom Access Provider erbrachten Dienst. In den hier betrachteten offenen Netzen, die sich einer Vernetzung mittels Funktechnologien im AdHoc-Modus bedienen, ist die Ermittlung bzw. Aufrechterhaltung dieser Rollenverteilung erheblich schwieriger. Im mobilen AdHoc-Netzwerk steht der Teilnehmer in unmittelbarem (Funk-)Kontakt zu den mit ihm über Funkwellen physikalisch verbundenen Netzwerkknoten. Über diese vermittelt kann er aber auch mit denjenigen Netzwerkknoten kommunizieren, zu denen er selbst keine unmittelbare Funkverbindung hat. Routing-Algorithmen, die auf den Netzwerkknoten arbeiten, erlauben ihm die Kommunikation mit weiter entfernt liegenden anderen Teilnehmern. Insofern kann er leicht als Nutzer identifiziert werden. Die mit ihm verbundenen Knoten hingegen, die diese Vermittlungsleistung erbringen, sind für ihn die Diensteanbieter. Diese Sichtweise ändert sich, sobald man den Netzwerkknoten aus der Sicht eines anderen Teilnehmers sieht: Für diesen erbringt er die Vermittlungsleistung. Für diesen ist er nicht Nutzer, sondern Diensteanbieter. Im selben Augenblick kann jeder Teilnehmer eines AdHoc-Netzwerks also Nutzer und Diensteanbieter sein. Es besteht demzufolge eine Identität der beiden Rollen. Eine Trennung kann nur logisch hinzugedacht werden, indem auf einzelne Kommunikationsströme abgestellt wird. Abbildung: Einfaches Beispiel eines offenen Netzes (AdHoc-Modus) 475 Über Verträge des bürgerlichen Rechts lässt sich dieses Verhältnis ohne weiteres rechtlich abbilden, indem beide Parteien Dienste als Leistung erbringen. Die Verwendung und Bereitstellung von offenen Netzen hat eine starke soziale Komponente. Die Verbreitung und Akzeptanz basiert weitgehend auf der Anzahl der beteiligten Nutzer. Zwischen den Nutzern besteht darüber hinaus häufig ein die Gruppe verbindender Gemeinschaftssinn, der sich auch auf die gemeinschaftsinterne Kommunikation auswirkt. Durch diese Gemeinschaftsbildung, aber auch durch die technische Realisierung der Netzwerke, gibt es dementsprechend keine feste Rollenverteilung in reine Nutzer und reine Betreiber. Während im kommerziellen Bereich also eine Menge von Anbietern um die Konsumenten ihrer Angebote konkurrieren, wird bei offenen Netzen die deutliche Trennung, die sich auch in TKG und TMG niederschlägt, durch das den offenen Netzen immanente Konzept fast immer aufgelöst. 3.2. Vertrag ohne Gestaltungsgrundlage – Gefälligkeitsverhältnis? Offene Netze bilden in aller Regel größere Gemeinschaften. Dennoch ist es nicht unüblich, dass sich derjenige, der den Netzknoten aktiv betreibt und derjenige, der ihn nutzt, keinen unmittelbaren Kontakt haben und/oder sich nicht kennen. Dennoch findet ein technischer Kommunikationsvorgang statt. Fraglich ist, ob in dieser Situation der faktischen Anonymität, selbst ohne Verwendung einer (AGB-ähnlichen) vertraglichen Vereinbarung wie des Pico Peering Agreement (s.u. 3.3.1) ein Vertrag geschlossen wird, der eine (rechtliche) Grundlage des Verhältnisses zwischen den Beteiligten darstellt und bei eventuellen Problemen zur Regulierung dienen kann. Als Alternative dazu könnte ein Gefälligkeitsverhältnis oder gar ein reines Gefälligkeitsverhältnis vorliegen. Nach BGHZ 21, 105 ist nach der vom BGH aufgestellten subjektiven Theorie darauf abzustellen, ob die Parteien mit Rechtsbindungswillen gehandelt haben. Es sind also die einzelnen Handlungen der Parteien im Hinblick auf Willenserklärungen zu untersuchen und zu bewerten. Als Hilfestellung hat die Rechtsprechung verschiedene objektivierte Kriterien entwickelt. Diese sind: • Gesellschaftlicher Verkehr • Unentgeltlichkeit • Grund und Zweck des Verhältnisses • Wirtschaftliche und rechtliche Bedeutung für die Beteiligten • Wirtschaftliche Risiken des Leistenden Betrachtet man diese Kriterien unter Zugrundelegung einer sozialen, gemeinnützigen Motivation dürfte es sich beim oben beschriebenen Verhältnis in offenen Netzen um ein reines Gefälligkeitsverhältnis unter Ausschluss aller Rechtspflichten handeln. Dies deckt sich auch mit den beobachteten Intentionen der Beteiligten. Allerdings stellt diese Gefälligkeitslösung keine 1:1-Abbildung der oben angesprochenen Auflösung des Rollenparadigmas - in der hier betrachteten Situation im Grunde zwei vollständig wechselseitige reine Gefälligkeitsverhältnisse („Nutzer“-„Betreiber“ und „Betreiber“-„Nutzer“) dar. Die im Rahmen der Gefälligkeit gegebene Reduktion der Pflichten bewirkt aber eine weitgehende Annäherung. 476 Die Motivation der Beteiligten wirkt sich also auf die objektivierte Bewertung der Handlungen und damit den Rechtsbindungswillen der Beteiligten aus. Sie hat folglich einen unmittelbaren Einfluss auf die vertragliche Gestaltung, der sich innerhalb der zivilrechtlichen Dogmatik abbilden lässt. 3.3. Mit vertraglicher Grundlage – Gründung einer Gesellschaft? Offene Netze sind wie oben aufgezeigt, durch die Phänomene Open Source und Open Content stark beeinflusst. Allerdings werden bei Open Source und Open Content in aller Regel spezielle vertragliche Werke verwendet, sog. offene Lizenzverträge (s. nur [4, 5]). 3.3.1. Pico Peering Agreement Offene Netze sind in dieser Hinsicht auch durch die vertragliche Konstruktion von Open Source beeinflusst worden: Vor dem Hintergrund einer zunehmenden Anzahl von öffentlich zugänglichen Netzwerkknoten sowie der Kenntnis des Konstrukts des kommerziellen Peerings (also der gegenseitigen Durchleitung von Datenverkehr durch gleichrangige Network Provider, vgl. [6, Rn. 156]) wurde im Jahr 2002 für freie Netze das „Pico Peering Agreement“ entwickelt (eingehend [7, S. 190 ff.]). Zwar existierten zu diesem Zeitpunkt bereits offen zugängliche Access Points, diese waren aber größtenteils nicht miteinander verbunden und bildeten kein größeres bzw. flächendeckendes Netzwerk. In dieser Situation entstand der Bedarf nach einem PeeringAbkommen für freie Netze (s. http://www.picopeer.net), das einerseits die Bedingungen einer Verbindung der einzelnen Netze und andererseits eine Definition offener Netze leisten sollte. Nr. 1 des Pico Peering Agreement legt die wesentlichen Pflichten des Betreibers fest: • „Der Eigentümer bestätigt, freien Transit über seine freie Netzwerkinfrastruktur anzubieten.“ • „Der Eigentümer bestätigt, die Daten, die seine freie Netzwerkinfrastruktur passieren, weder störend zu beeinträchtigen noch zu verändern.“ Das Pico Peering Agreement sollte demnach der Bildung von umfassenden und flächendeckenden offenen Netzen, aber auch der Vereinigung und Vergrößerung der Gemeinschaften rund um offene Netze dienen, indem die Betreiber Peering anbieten. Die deutliche Formulierung von Punkten, über die grundsätzlich Einigkeit bestand, sollte den bisherigen Teilnehmern die Situation erklären helfen und neuen Teilnehmern den Einstieg erleichtern. Der Begriff „pico“ soll dabei in Abgrenzung zu kommerziellen Peering Agreements den kleinen Maßstab des Peering-Aufkommens verdeutlichen. Das Pico Peering Agreement besteht aus drei Teilen: einer Präambel, der eigentlichen Vereinbarung sowie notwendigen Definitionen. Es soll laut Satz 1 der Präambel die „minimale, grundsätzliche Vorlage für ein Peering-Abkommen (Verbindungsabkommen, Bündnisabkommen) zwischen den Eigentümern individueller Netzwerkknoten“ darstellen. Satz 2 der Präambel lautet: „Das PPA ist eine formalisierte Beschreibung der Verbindung zwischen zwei Netzwerk-Instanzen (peers). Eigentümer einer Netzwerkinfrastruktur machen von ihrem Eigentumsrecht Gebrauch, indem sie ihr Einverständnis dafür geben, einen Teil ihrer Infrastruktur für den freien Datenaustausch über ihr Netzwerk bereitzustellen.“ 477 3.3.2. Interpretation und Verwendung des Pico Peering Agreement Erneut ist fraglich, ob und wie sich die soziale Motivation, die sich nicht zuletzt im Rahmen dieses „Vertragswerks“ zeigt - aber auch Grenzen definiert - auf die rechtliche Gestaltung auswirkt. Für offene Netze, insbesondere wenn sie eine starke persönliche Vernetzung zwischen den Mitgliedern aufweisen, könnte das Pico Peering Agreement als Vertrag über die Gründung einer BGB-Innengesellschaft aufgefasst werden. Es ist also zu untersuchen, ob die Regelungen der Gesellschaft bürgerlichen Rechts nach §§ 705 ff. BGB oder gar das „Wesen der Gesellschaft“ (vgl. [8, S. 3 ff.]) dieser Interpretation entgegenstehen. Denn auch hier wirken sich die sozialen Motive der Beteiligten aus. Zentraler Gesichtspunkt für die Gründung einer Gesellschaft ist der gemeinsam verfolgte Zweck. Das Pico Peering Agreement in Verbindung mit dem daraus ermittelten Willen der Beteiligten enthält einen solchen Zweck – den Aufbau und Betrieb eines offenen Netzwerks. Die Gesellschaft ist geradezu der Prototyp für die Abbildung der oben dargestellten Motive der Beteiligten. Sie erlaubt rechtlich den Zusammenschluss der Betreiber unter Festlegung einiger weniger Haupt(förderungs)pflichten, die auch gegenüber unbekannten Dritten erbracht werden können, und einem gleichzeitigen möglichst weitgehenden Haftungsausschluss. Zudem soll die Gesellschaft jederzeit Dritten offen stehen, was insbesondere im Hinblick auf gemeinschaftliche Entscheidungen der Gesellschaft problematisch sein kann. Die Aufnahme eines neuen Mitglieds, die Umdeutung der Kündigung durch Einstellung des Betriebs sowie die Mitgliedschaft in mehreren solchen Gesellschaften bedürfen der intensiven Betrachtung (dazu eingehend [9, S. 132 ff.]). Im Ergebnis kann eine Innengesellschaft unter bestimmten Voraussetzungen angenommen werden. Damit entfallen auch eventuelle Probleme hinsichtlich der Auseinandersetzung oder der Haftung der Gesellschaft – durch die Innengesellschaft ist sichergestellt, dass kein Gesellschaftsvermögen aufgebaut wird, über das eine Auseinandersetzung erforderlich wäre, die Gesellschaft tritt zudem nicht nach außen auf und haftet dementsprechend auch nicht gegenüber Dritten. Sie ist eine motivationsgesteuerte Zweckgemeinschaft, die die Parteien lediglich im Innenverhältnis bindet der sozialen Motivation entsprechend so wenig wie möglich und so viel wie nötig. Sie ermöglicht schließlich relativ unproblematisch die Einbindung wechselnder Teilnehmer sowie deren zahlenmäßiges Schwanken. Auch die oben angesprochene Auflösung des Rollenparadigmas wird durch die absolute Gleichstellung der Gesellschafter zueinander gewährleistet. Die Innengesellschaft bei offenen Netzen bildet insofern nur eine weite Interpretation des „weiten Gefäßes“ der Gesellschaft bürgerlichen Rechts. Die Konstruktion erlaubt zudem eine relativ starke Beschränkung der Haftung, genau wie sie das Pico Peering Agreement vorsieht, und wie es die Beteiligten in aller Regel auch wünschen [7, S. 190]. Als Folgefrage könnte eine Übertragung auf andere Situationen mit ähnlichen oder gar anderen Motiven interessant sein, z.B. im Rahmen von über die ganze Welt verteilten Netzwerken. Dazu ist allerdings zu beachten, dass z.B. für die Open Source-Lizenzverträge die Bildung einer Gesellschaft nach h.M. abgelehnt wird [4, S. 145; 10, S. 332; 11, S. 109]. 4. Störerhaftung Nach der Untersuchung der Auswirkungen der Motivation auf die vertragliche Konstruktion, ist der Einfluss der Motivation auf die Haftungssituation zu betrachten. 478 Derzeit in beständiger Diskussion ist die Frage nach der Störerhaftung des Internet Service Providers. Anhand offener Netze lassen sich die Grundlagen und Auswirkungen dieses Haftungsinstruments sehr gut darstellen und beleuchten. Problematisch für offene Netze ist die Störerhaftung, weil sie die typische Haftungskonstellation ist: Verletzt ein Teilnehmer an einem offenen Netz die Rechte eines Dritten, so tritt nach außen in aller Regel nicht der Verletzer selbst (mittels seiner IP-Adresse) auf, sondern eben der Betreiber des Netzwerkknotens bzw. des Gateways ins Internet. Exkulpiert sich der Betreiber unter Verweis auf seine Funktion als Access Provider, greift für Schadensersatzansprüche die Privilegierung des § 8 TMG. Dem Rechtsinhaber verbleibt nur der Rückgriff auf die Störerhaftung. Erste Frage bei der Untersuchung einer Störerhaftungskonstellation ist die Frage, ob die Handlung des potentiell Pflichtigen adäquat-kausal für die Rechtsverletzung war (BGH GRUR 2002, 618, 619 - Meißner Dekor I). Durch dieses Merkmal wird eine sehr weite Haftung eröffnet [12, § 8 Rn. 2.13; 13, Kap. 14 Rn. 10b]. Als Mittel zur Einschränkung hat der BGH das Erfordernis der Verletzung von Prüfungs- und Überwachungspflichten entwickelt (BGH GRUR 1997, 313, 315 Architektenwettbewerb; BGH GRUR 2003, 969, 970 - Ausschreibung von Vermessungsleistungen; BGH GRUR 2004, 693, 695 - Schöner Wetten; BGH GRUR 2006, 875 - RechtsanwaltsRanglisten; st. Rspr.). Er schränkt somit die Haftung nicht nur über die Adäquanz, sondern in einem zweiten Schritt weiter ein. Um festzustellen, ob eine Verletzung von Prüfungs- und Überwachungspflichten vorliegt, ist in jedem Einzelfall eine Abwägung der betroffenen Interessen nötig. Dafür hat sich in der Rechtsprechung eine Reihe von Kriterien gebildet, die mal mehr, mal weniger den Ausschlag geben können – eine einheitliche Linie hat sich bisher noch nicht gebildet. Diese sind (ohne Anspruch auf Vollständigkeit): • Kenntnis der Rechtsverletzung (str.) • Rechtsschutzinteresse des Betroffenen – Rang des Rechtsguts und Schwere der Rechtsverletzung • Wirtschaftliche Nutzenziehung des Internet Service Providers aus der Handlung des unmittelbaren Störers (z.B. relevant bei BGH – Internetversteigerung I-III) • Funktion und Aufgabenstellung des potentiellen Störers • Eigenverantwortung des Dritten • Aufwand für Prüfungs- und Überwachungspflichten • Effektivität bzw. erwarteter Erfolg der verlangten Maßnahme inkl. der Möglichkeit des unmittelbaren Störers, die Maßnahmen zu umgehen • Technische und wirtschaftliche Zumutbarkeit der verlangten Maßnahme • Datenschutz und Anonymität (str.) Betrachtet man diese Punkte, zeigt sich deutlich, dass die Untersuchung von Prüfungs- und Überwachungspflichten im Grunde eine spezialisierte Verhältnismäßigkeitsprüfung enthält. Und aus diesem Schluss ergibt sich die Folge, dass gerade die Motivation des Internet Service Providers ein wesentliches Element in der Betrachtung der Störerhaftung bildet (eingehend [9, S. 254 ff.]). Der BGH hat erkennbar und wiederholt besonders stark auf die wirtschaftliche Betätigung des Providers abgestellt (vgl. auch m.w.N. BGH GRUR 2007, 890 – Jugendgefährdende Medien bei eBay). Bereits das Fehlen von kommerziellen Beweggründen hat also deutlichen Einfluss auf die Haftung. Im konsequenten Umkehrschluss der Argumentation des BGH muss das Vorliegen von 479 sozialer und insbesondere fremdnütziger, nicht-kommerzieller Motivation zu einer weitergehenden Privilegierung des Betreibers führen. Die Störerhaftung speziell des (unbewussten) WLAN-Betreibers bildet in den letzten Jahren einen scharf umstrittenen Teilbereich der Störerhaftung. Das LG Hamburg (MMR 2006, 763) hatte als erstes Gericht einen solchen Fall zu beurteilen und hat die Störerhaftung zu Lasten des WLANBetreibers ohne nähere Begründung angenommen. Das LG Frankfurt (MMR 2007, 675) sowie das LG Düsseldorf (zuletzt mit Urt. v. 16.07.2008 – 12 O 232/08) hatten sich der restriktiven Linie des LG Hamburg angeschlossen. Mit Urteil vom 01.07.2008 hat allerdings das OLG Frankfurt nun die Gegenposition eingenommen und die Störerhaftung des WLAN-Betreibers abgelehnt (OLG Frankfurt MMR 2008, 603 m. Anm. Mantz/Gietl). Revision zum BGH ist bereits eingelegt (Az. I ZR 121/08). Die Behandlung der Störerhaftung ist damit auch für offene Netze weiterhin nicht restlos geklärt, der BGH kann aber für Rechtssicherheit sorgen. 5. Auskunftsansprüche Schlussendlich sind noch die Auswirkungen der Motivation auf Auskunftsansprüche des Rechtsinhabers gegen den Betreiber zu betrachten. Im Rahmen der Auskunftsansprüche hat sich durch die Umsetzung der Enforcement-Richtlinie (2004/48/EG) in deutsches Recht eine Änderung ergeben: § 101 UrhG (sowie die entsprechenden Parallelvorschriften in PatG, MarkenG, etc.), der zum 01.09.2008 in Kraft getreten ist, sieht einen Auskunftsanspruch des Rechtsinhabers auch gegen Dritte vor, also auch und insbesondere gegen den Internet Service Provider (eingehend [9, S. 295 ff.]). Die Umsetzung der Richtlinie insgesamt, aber auch des Auskunftsanspruchs war bis zuletzt umstritten. Zweifel an der Vereinbarkeit mit EURecht sowie nationalem Recht werden in der Literatur diskutiert (dazu [14; 9, S. 307 ff.] jeweils m.w.N.). Schon ein kurzer Blick auf den Auskunftsanspruch offenbart – im Einklang mit den bisherigen Ergebnissen – den möglichen Einfluss der Motivation der Beteiligten: § 101 Abs. 4 UrhG sieht ausdrücklich vor, dass eine Einzelfallprüfung inklusive Verhältnismäßigkeitsabwägung stattfinden muss. Zusätzlich sieht § 101 Abs. 9 UrhG noch einen Richtervorbehalt vor, falls für die Auskunft auf Verkehrsdaten zurückgegriffen werden muss, was bei offenen Netzen immer der Fall sein wird. Betrachtet man die Verhältnismäßigkeitsanforderungen, dürfte sich ein ähnliches Bild ergeben wie bei der Störerhaftung – die Kriterien im Rahmen der Untersuchung von Prüfungs- und Überwachungspflichten sind schließlich spezielle Verhältnismäßigkeitsgesichtspunkte. Dass eine Einzelfallprüfung geboten ist, zeigen nicht zuletzt Urteile, die in letzter Zeit ergangen sind, und die die Herausgabe von Daten an die Staatsanwaltschaften oder die Verwertung solcher Daten im Zivilprozess kritisch betrachten (OLG Frankfurt MMR 2008, 603; AG Offenburg MMR 2007, 809; LG Saarbrücken K&R 2008, 320; LG Frankenthal K&R 2008, 467; a.A. LG Offenburg K&R 2008, 384; dazu näher Fehler! Verweisquelle konnte nicht gefunden werden.). Schlussendlich ist noch interessant, wie sich die Umsetzung der Vorratsdatenspeicherungsrichtlinie auswirken wird – und natürlich, ob nicht auch hier Verhältnismäßigkeitserwägungen anzustellen sind, die wiederum Auswirkungen einer sozialen Motivation bedingen könnten. 480 6. Ergebnis Im Ergebnis zeigt sich, dass gerade die Motivation der Beteiligten wesentlichen Einfluss auf die hier betrachteten rechtlichen Komplexe hat. Dieser Einfluss wirkt sich zum einen stark auf die rechtliche Gestaltung im Sinne eines Rechtsverhältnisses aus. Zum anderen wirkt er bei der Begründung von Haftungsansprüchen. Literatur [1] MANTZ, RETO, Open Source, Open Content und Open Access – Gemeinsamkeiten und Unterschiede, in: Lutterbeck/Bärwolff/Gehring, Open Source Jahrbuch 2007, S. 413 [2] ERNST, SONJA, Freie Netze - Utopien aus Sauerkrautdosen, Spiegel Online v. 04.03.2005, http://www.spiegel.de/netzwelt/technologie/0, 1518, 344668, 00.html [3] FLICKENGER, ROB et al., Wireless Networking in the Developing World, 2. Aufl. 2008, http://wndw.net/pdf/wndw2-en/wndw2-ebook.pdf [4] JAEGER, TILL/METZGER, AXEL, Open Source Software, 2. Aufl. 2006 [5] JAEGER, TILL/METZGER, AXEL, Open-Content-Lizenzen nach deutschem Recht, MMR 2003, 431 [6] PETRI, AXEL/GÖCKEL, ANDREAS, in: Moritz/Dreier, Rechts-Handbuch zum E-Commerce, 2. Auflage, 2005, Kap. B [7] MEDOSCH, ARMIN, Freie Netze, 2003 [8] TEICHMANN, ARNDT, Gestaltungsfreiheit in Gesellschaftsverträgen, 1970 [9] MANTZ, RETO, Rechtsfragen offener Netze - Rechtliche Gestaltung und Haftung des Access Providers in zugangsoffenen (Funk-)Netzen, 2008 [10] HEUSSEN, BENNO, “Danaergeschenke, Dereliktion oder Haftung im Verein?” – Offene Rechtsfragen um Free Software, in: Taeger, Jürgen; Wiebe, Andreas (Hrsg.), Informatik, Wirtschaft, Recht, S. 323 [11] GRÜTZMACHER, MALTE, Copyright statt Copyleft, ITRB 2006, 108, 109 [12] HEFERMEHL, WOLFANG; KÖHLER, HELMUT; BORNKAMM, JOACHIM, UWG, 26. Aufl. 2008 [13] TEPLITZKY, OTTO, Wettbewerbsrechtliche Ansprüche und Verfahren, 9. Aufl. 2006 [14] SPINDLER, GERALD, Der Auskunftsanspruch gegen Verletzer und Dritte im Urheberrecht nach neuem Recht, ZUM 2008, 640 [15] GIETL, ANDREAS/MANTZ, RETO, Die IP-Adresse als Beweismittel im Zivilprozess - Beweiserlangung, Beweiswert und Beweisverbote, CR 2008, 810 481 GRENZEN DER DATENSCHUTZRECHTLICHEN VERANTWORTLICHKEIT IN EINER WELT DES „UBIQUITOUS COMPUTING“ Jürgen Müller1 Kurzfassung Der folgende Beitrag untersucht am Beispiel des Einsatzes von RFID-Lesegeräten, inwieweit in einer Welt des „Ubiquitous Computing“ die datenschutzrechtliche Verantwortlichkeitsregel noch tragfähig ist. Die verantwortliche Stelle ist der zentrale Anker im Datenschutzrecht, an den die meisten Schutzpflichten eines Datenumgangs angeknüpft werden. Allerdings wird deutlich, dass das Konzept der Verantwortlichkeit im geltenden Datenschutzrecht angesichts der neuen Herausforderungen eines künftig informatisierten Alltages an seine Grenzen stößt. 1. Die „verantwortliche Stelle“ im Datenschutzrecht Rechte und Pflichten im Datenschutzrecht knüpfen an den Begriff der verantwortlichen Stelle an.[4-Rn. 224] Zu solchen Pflichten der verantwortlichen Stelle gehören beispielsweise, die Verwendungszwecke der Daten bei der Erhebung gemäß § 28 Abs. 1 Satz 2 BDSG festzulegen, die Betroffenen über ihre Identität, die Verwendungszwecke oder die (Kategorien der) Empfänger gemäß § 4 Abs. 3 BDSG zu unterrichten oder im Fall einer Auftragsdatenverarbeitung, gemäß § 11 BDSG den Auftragnehmern Weisungen zu erteilen und ihre Einhaltung zu überwachen. Gemäß § 3 Abs. 7 BDSG ist eine verantwortliche Stelle, „jede Person oder Stelle, die personenbezogene Daten für sich selbst erhebt, verarbeitet oder nutzt oder dies durch andere im Auftrag vornehmen lässt“. Normadressat sind also die öffentlichen und nichtöffentlichen Stellen im Sinne des § 2 BDSG.[4-Rn. 227] Sobald diese in irgendeiner Form mit personenbezogenen Daten im Sinne des § 3 Abs. 1 BDSG umgehen, sind sie hierfür grundsätzlich im Sinne des Datenschutzrechts verantwortlich. 2. Die Bedingungen einer Welt des „Ubiquitous Computing“ In einer Welt des „Ubiquitous Computing“ finden datenerhebende, -verarbeitende und -nutzende Vorgänge durch viele Techniksysteme statt, die von ihren Funktionen ineinander greifen, verteilt und über Alltagsgegenständen in der Umwelt präsent sind.[3, 8] Der Einsatz der RFID-Technik stellt einen ersten Schritt in eine solche Welt dar. Als Komponenten des RFID-Vordergrundsystems werden, RFID-Marken, in vielen beweglichen oder unbeweglichen Gegenständen eingebettet sein 1 Wissenschaftlicher Mitarbeiter in der Projektgruppe verfassungsverträgliche Technikgestaltung (PROVET) im interdisziplinären Forschungszentrum Informationstechnikgestaltung (ITeG) an der Universität Kassel 483 [9, 10, 11] und über ein Hintergrundinformationssystem vernetzt und mit anderen Techniksystemen verbunden sein. Dabei nutzen mehrere Stellen unter Umständen die einzelnen Komponenten, wie das RFID-Lesegerät, als Infrastruktur gemeinsam. Entweder greifen sie „lediglich“ auf die Funktionen des RFID-Lesegeräts für ihre eigenen Zwecke zurück oder verwenden technisch Erhebungsergebnisse, Speicherfunktionen oder Auswertungen des Geräts in Form der Daten gemeinschaftlich. Selbst für RFID-Lesegeräte, die im „Ubiquitous Computing“ auch andere Sensoren sein können, ist denkbar, dass diese als öffentliche Infrastruktur - für jedermann nutzbar aufgestellt sind. Daher besteht, anders als bei einer Datenverarbeitung in Akten oder in herkömmlichen Datenverarbeitungsanlagen, bei Techniksystemen in einer Welt des „Ubiquitous Computing“ die Herausforderung, ob eine Verantwortlichkeit in gleicher Weise angenommen und wie diese bestimmt werden kann. 3. Objektive und subjektive Kriterien für die Verantwortlichkeit Zur Gewährleistung der informationellen Selbstbestimmung verlangt das Datenschutzrecht, wie in § 4 Abs. 1 BDSG normiert, stets eine Rechtfertigung durch einen Zulassungstatbestand in Form einer gesetzlichen Erlaubnis oder einer Einwilligung des Betroffenen. Um aber Eingriffe in dieses Grundrecht des Betroffenen gering zu halten, stellt das Datenschutzrecht verschiedene Schutzanforderungen an den Umgang mit den Betroffenendaten auf. Die datenschutzrechtlichen Regeln beziehen sich auf die Phasen des Erhebens, Speicherns, Veränderns, Übermittelns, Löschens, Sperrens oder einer anderen Form des Nutzens. Das bedeutet aber auch, dass grundsätzlich hinsichtlich der datenschutzrechtlichen Anforderungen keine Zustandsverantwortlichkeit oder Gefährdungshaftung für ein Techniksystem entsteht, dem ein entsprechendes Gefährdungspotential zu eigen ist. Vielmehr setzt die Verantwortlichkeit im Datenschutzrecht nach § 3 Abs. 7 BDSG objektiv eine Aktivität als eine zurechenbare Handlung voraus.[4-Rn. 102 f.] Gegenstand dieser Aktivität ist grundsätzlich der Umgang mit personenbezogenen Daten. Sie kann auch in einer Veranlassung der datenschutzrechtlich relevanten Vorgänge bestehen. Indiz kann hierfür eine Art Funktionsherrschaft über das Techniksystem sein, wobei sich die Kontrolle auf den Vorgang des Datenumgangs erstrecken muss. Ebenso deuten Maßnahmen, mit dem die verantwortlich zu machende Stelle die betreffenden Vorgänge initiiert und maßgeblich beeinflusst, auf einen solchen, ihr zuzurechnenden Umgang hin. Nicht die Existenz von personenbezogenen Daten, sondern der Umgang mit ihnen ist für die Interessen des Betroffenen bedeutsam. Zudem muss bei § 3 Abs. 7 BDSG ein subjektives Element hinzutreten, nämlich ein gewisses bewusstes und willentliches Handeln der Person.[4-Rn. 102 f.] Allerdings dürfen keine zu hohen Anforderungen an das Wissen und Wollen gestellt werden. In der Konsequenz heißt das, dass einer Stelle datenerhebende oder datenverwendende Vorgänge nicht zugerechnet werden können, von der sie keine Kenntnis hat. Ohne eine Veranlassung dieser Vorgänge sind sie letztlich nicht von ihrem Willen getragen. Fraglich ist, ob gleiches auch dann gilt, wenn diese Vorgänge durch Funktionen eines Techniksystems durchgeführt werden. Grundsätzlich muss auch in diesem Fall die Stelle um den Vorgang wissen, der mittels des Techniksystems in die informationelle Selbstbestimmung des Betroffenen eingreift. Dies wiederum kann aber nicht soweit gehen, dass die Stelle im Einzelnen über technische Abläufe und deren Umsetzung Bescheid weiß. Es muss genügen, wenn die Stelle die Tatsache einer Erhebung, Verarbeitung oder Nutzung von personenbezogenen Daten durch das Techniksystem für sie nachvollziehbar kennt und den jeweils konkreten Vorgang in ihren Willen einzubeziehen vermag. Dazu gehören auch tatbestandsvoraussetzende Umstände der datenschutzrechtlichen Phasen. Beispielsweise verlangt der Übermittlungstatbestand gemäß § 3 Abs. 4 Satz 2 Nr. 3 BDSG die Weitergabe der Daten an Dritte im Sinne des § 3 Abs. 8 BDSG und das Bereithalten eine Vorstellung von dem Empfänger oder dem Empfängerkreis. Daneben soll eine Erhebungs- oder Verwendungsphase 484 im Sinne des Datenschutzrechts ausscheiden, wenn bezüglich der personenbezogenen Daten kein Verwendungszweck vorgesehen ist oder für die Stelle objektiv keine Kenntnisnahmemöglichkeit besteht.[4-Rn. 107, 120] Hierdurch entfallen die tatbestandlichen Voraussetzungen eines Umgangs, der eine Verantwortlichkeit nach dem Datenschutzrecht nach sich zöge. 4. Verantwortlichkeit beim Einsatz von RFID-Lesegeräten In einem künftigen umfassenden RFID-Gesamtsystem wird eine Vielzahl von stationär aufgestellten oder mobil eingesetzten RFID-Lesegeräten genutzt werden. Wem ein RFID-Lesegerät und dessen Datenumgang zugeordnet werden kann, muss nicht immer ohne Weiteres feststehen oder bestimmbar sein. Sobald Personen beispielsweise sich der Funktionen eines Netzwerks von in der Umgebung aufgestellten RFID-Lesegeräten bedienen, führen sie jeweils die datenerhebenden- und datenverwendenden Vorgänge mittels dieser durch. Der Betreiber stellt mit einer solchen Infrastruktur lediglich die Möglichkeiten des Datenumgangs zur Verfügung. So könnte ein Inhaber einer Ladenpassage oder eines Einzelhandelsladengeschäfts seinen Kunden mobile RFID-Lesegeräte anbieten, die sie bei ihrem Besuch zur Abfrage von entsprechend mit RFID-Marken gekennzeichneten Produkten und Hinweistafeln nutzen können. In einem Einkaufszentrum, Ausstellungsgelände oder Veranstaltungshalle würde der Inhaber des Ladengeschäftes, der Schausteller oder Veranstalter den Betreiber der RFID-Infrastruktur beauftragen, für ihn je nach Geschäftszweck markierte Waren zur Abrechnung am Ein- und Ausgang, markierte Ausstellungstücke hinsichtlich Lokalisation und zur Bestandskontrolle oder die Belegung von Sitzplätzen zu registrieren. Unter einer solchen Konstellation bliebe die beauftragende Stelle für die im Rahmen des Auftragsverhältnisses stattfindenden Erhebungs- und Verwendungsmaßnahmen durch den Infrastrukturanbieter verantwortlich. 4.1 Betreiber der RFID-Lesegerätinfrastruktur Vorgeschlagen wird, die datenschutzrechtliche Verantwortlichkeit dem Betreiber des Systems aufzuerlegen, um, flankiert durch zivilrechtliche Nebenpflichten oder das Hausrecht, nahezu alle Fälle des Datenumgangs durch das von ihm betriebene Techniksystem abzudecken.[1] Ausgangspunkt dieser Ansicht ist die Überlegung, dass die meisten Komponenten eines RFID-Systems weder absichtslos noch ohne Verwendungszweck aufgestellt sind und betrieben werden. Um diese Funktion der gezielten Erfassung und Zuordnung von Objekten erfüllen zu können, arbeiteten die aufgestellten RFID-Lesegeräte in der Regel raumbezogen und eingebunden in ein Hintergrundinformationssystem. Trotz der vielfältigen Möglichkeiten, in diesen Räumen Objekte zu registrieren, ist nach dieser Ansicht stets der jeweilige Betreiber, der die technischen Einrichtungen der Datenerfassung und -verarbeitung, wie RFID-Lesegeräte oder Hintergrundinformationssysteme betreibt, für die stattfindende Erhebung und Verwendung verantwortlich. Es sei allen Anwendungen des „Ubiquitous Computing“ gemein, dass diese technischen Einrichtungen von jemandem betrieben werde, der bezüglich eines bestimmten Funktionsraumes mit der Datenerfassung ein spezifisches Betriebsinteresse verfolgt.[1] Dieser Ansicht kann nicht gefolgt werden. Sie verkennt, dass die Verantwortlichkeit gemäß § 3 Abs. 7 BDSG an den Umgang mit personenbezogenen Daten anknüpft. Der § 3 Abs. 7 BDSG weist die Verantwortlichkeit derjenigen Person oder Stelle zu, „die personenbezogene Daten ... erhebt, verarbeitet oder nutzt“. Diese Formulierung zeigt an, dass der Bezugspunkt der datenschutzrechtlich relevante Vorgang ist. Die Verantwortlichkeit entsteht an und für die einzelne, stattfindende Datenerhebung, -verarbeitung oder -nutzung. Es kommt auf die Durchführung des die informationelle Selbstbestimmung gefährdenden Vorgangs, also auf das Tätigwerden der Person oder Stelle an. Auch würde es dem Konzept des zumindest geltenden Datenschutzrechts widersprechen, da 485 Bezugspunkt für das Schutzprogramm grundsätzlich der jeweilige und konkrete Verwendungsvorgang ist. Aus § 3 Abs. 7 BDSG lässt sich keine Art Gefährdungshaftung für Techniksysteme lesen, die allein wegen ihres Betreibens den Betreiber für mit Hilfe seines Systems durchgeführte Verwendungen von personenbezogenen Daten in die Pflicht nimmt. Gleiches gilt auch für den Inhaber des Hausrechts. Selbst wenn dieser etwa aus vertraglichen, deliktischen oder anderen zivilrechtlichen Nebenpflichten Schutzmaßnahmen für Güter des Betroffenen – wie für dessen informationelle Selbstbestimmung [6- Rn. B 140,C 173; 5- Rn. 43] – zu treffen hätte, begründet dieses nicht die Pflichten einer verantwortlichen Stelle nach dem Datenschutzrecht. Der Vermieter oder Verpächter, der in seinen Räumen die Aufstellung von Lesegerät- oder Sensortechnik durch andere Nutzungsberechtigte duldet, verstößt als Inhaber des Hausrechts bzw. des Eigentums allein auf Grund seiner Vermietung oder Verpachtung nicht gegen datenschutzrechtliche Vorschriften. Einzuräumen ist freilich, dass es nahe liegt, dass der Betreiber, der in tatsächlicher und rechtlicher Hinsicht die Herrschaft über die Funktionen des Techniksystems ausübt, auch die Erhebung, Verarbeitung oder Nutzung vornimmt. Dennoch entsteht die Verantwortung einer Person oder Stelle nach dem Datenschutzrecht für den einzelnen Vorgang des Datenumgangs, den nicht zwingend der Betreiber des zu Hilfe genommenen Techniksystems durchzuführen braucht. Zwar beinhaltet die Funktionsherrschaft grundsätzlich die Möglichkeit, das Techniksystem abzuschalten, Nutzer auszuschließen oder Funktionen zu beschränken. Indem aber der Betreiber die von ihm betriebene Infrastruktur oder die Funktionen seines Techniksystems anderen Personen zur Verfügung stellt, ist er nicht notwendigerweise Nutzer und auch nicht derjenige, der den Datenumgang konkret durchführt. Abzugrenzen ist schließlich die Person, die das Techniksystem und dessen Funktionen zur Verfügung stellt, von der Person oder Stelle, die einerseits als Beauftragte oder andererseits als übermittelnde Stelle an dem Datenumgang teilnimmt. Wenn nun der Betreiber personenbezogene Daten im Rahmen eines Auftragsverhältnisses für eine andere Stelle erhebt, verarbeitet oder nutzt, treffen ihn als Beauftragter weitergehende Pflichten des Datenschutzrechts. Dagegen wäre der Betreiber selbst verantwortliche Stelle, wenn andere Stellen in einer Weise mit personenbezogenen Daten über sein Techniksystem versorgt werden, das sich sein „Betreiben“ gegenüber der anderen Stelle als ein Übermitteln im Sinne des § 3 Abs. 4 Satz 2 Nr. 3 BDSG darstellt. Das ist beispielsweise der Fall, sobald eine Person nicht die Funktionen zur Verfügung stellt, sondern mittels des RFID-Lesegerätes oder Lesegerätnetzwerkes Vorgänge initiiert, deren Gegenstand personenbezogene Daten sind und auf deren Ergebnisse eine andere Stelle für ihren Datenumgang zurückgreift. Indem die das Techniksystem betreibende Stelle mit der anderen Person die betreffenden personenbezogenen Daten austauscht, erhebt, verarbeitet oder nutzt die das System betreibende Stelle diese Daten im Sinne des § 3 Abs. 7 BDSG „für sich selbst“. Das gilt, sofern keine Beauftragung dieser Stelle vorliegt. Im Ergebnis ist nach dem geltenden Datenschutzrecht der- oder diejenige verantwortliche Stelle, der mittels eines RFID-Lesegerätes auch personenbezogene Daten erhebt, verarbeitet und nutzt. 4.2 Benutzung einer RFID-Lesegerätinfrastruktur durch mehrere Beteiligte Schwierigkeiten könnte die Bestimmung der datenschutzrechtlichen Verantwortlichkeit bereiten, wenn mehrere Stellen die selbe RFID-Infrastruktur oder das selbe RFID-Lesegerät verwenden und darüber RFID-Marken auslesen, deren Daten mit oder ohne Unterstützung des Hintergrundinformationssystem verwenden. Dies ergibt sich, wenn beispielsweise ein Auslagenregal für markiertes Informationsmaterial mehrerer Anbieter oder ein Tischbereich von mehreren Bewirtungsbetrieben gemeinsam genutzt werden. RFID-Lesegeräte am und um das Auslagenregal oder unter den Tischen würden, zugreifbar für jede Stelle, markiertes Informationsmaterial oder markiertes Geschirr 486 registrieren, um eine Prüfung des Bestandes oder eine Abrechnung differenziert für jede Stelle zu ermöglichen. Soweit diese Stellen für sich über die aufgestellte Infrastruktur personenbezogene Daten erheben oder verwenden, ist jede Stelle jeweils für ihren Datenumgang verantwortlich. Wenn jedoch diese verschiedenen Stellen die Ergebnisse der Funktionen des RFID-Lesegerätes in Form der erhobenen, verarbeiteten oder genutzten Daten zusammen, gebrauchen, lässt sich die datenschutzrechtliche Verantwortlichkeit schwieriger feststellen. Man könnte zum einen eine gemeinsame Verantwortung aller beteiligten Stellen annehmen.[1, 16] Dies ist bei Anwendungen im Feld des „Ubiquitous Computing“ durchaus ein Ansatz, um den schwierig umzusetzenden Schutzbedürfnis in komplexen und nicht stabilen Konstellationen, in denen mehrere Beteiligte die selben Techniksysteme nutzen, Rechnung zu tragen. Dennoch findet eine solche Konstruktion keine Stütze im geltenden Recht. Zum einen ist fraglich, wie bei einer gemeinsamen Verantwortlichkeit für die stattfindende Erhebung das Ziel als Steuerungsinstrument erhalten bleibt. Bei einer Erhebung, die mehrere Beteiligte für ihre jeweils eigenen Geschäftszwecke gemeinsam durchführen, lässt sich für die erhobenen Daten eine klare Zweckbindung nicht festlegen. Dadurch wird die mit der Zweckbindung intendierte Begrenzungsfunktion konterkariert. Zudem sind bei gemeinschaftlichen Erhebungs- und Verarbeitungsmaßnahmen die möglicherweise nicht kongruenten Voraussetzungen der sie rechtfertigenden Zulassungstatbestände zu beachten, auf die sich jede beteiligte Stelle jeweils stützen können muss und die den Datenumgang dieser erst rechtfertigen. Zum anderen geht der § 3 Abs. 7 BDSG bei der verantwortlichen Stelle von einer natürlichen oder juristischen Person aus. Komplexe oder undurchschaubare Konstellationen, in denen sich die genutzten Techniksysteme und beteiligten Stellen immer wieder verändern, ist dem geltenden Datenschutzrecht fremd. Mit der Annahme einer BGB-Gesellschaft als eine verantwortliche Stelle, die die beteiligten Stellen in dem gemeinsamen Erheben und Verwenden der personenbezogenen Daten bilden, ließe sich eine Konstruktion finden, mit der der Vorstellung des geltenden Datenschutzrechts entsprochen werden könnte. Eine solche Gesellschaft bürgerlichen Rechts setzt im Allgemeinen keine besonderen Formen bei Abschluss des Gesellschaftsvertrages voraus, sondern lässt sich sogar konkludent [17-Rn. 10 ff.] durch die gemeinsame Verfolgung eines Zweckes gründen. Als solcher kommt beinahe jedes wirtschaftliche Ziel in Betracht.[17-Rn. 20 ff.] Als Folge dieses Zusammenschlusses haftet diese aus Personen bestehende Gesellschaft nach neuerer Rechtsprechung analog [7-Rn. 5] zu §§ 128 ff. HGB gemeinschaftlich im Außenverhältnis. Eine solche Gesellschaft könnte beispielsweise entstehen, wenn mehrere Ladeninhaber in einer Kaufhalle eine gemeinsame RFID-Überwachungsanlage anschafften, nicht aber, wenn mehrere Ladeninhaber bei einem Inhaber einer RFID-Anlage den Gebrauch dieser mieteten. Auf Grund der Anerkennung der Teilrechtsfähigkeit einer BGB-Gesellschaft könnte der Betroffene sich zur Durchsetzung seiner Rechte, wie der aus § 34 Abs. 1 BDSG oder § 35 Abs. 1 BDSG prozessual an die Gesellschaft wenden, ohne jeder der Gesellschafter gesondert verklagen zu müssen. Allerdings bleiben auch bei der Konstruktion über eine BGB-Gesellschaft Folgefragen bestehen. Die Fragen, auf welchen Zulassungstatbestand sich diese verantwortliche Stelle stützen kann und wodurch eine Übermittlung der erhobenen und verarbeiteten Daten an die beteiligten Stellen zu rechtfertigen ist, lassen sich datenschutzrechtlich nicht zufriedenstellend beantworten. Wählte man den Weg einer Beauftragung der Gesellschaft durch die Beteiligten, bleiben Bedenken, wie die Anforderungen einer Beauftragung gewährleistet werden können. Der Gesetzgeber hat dieses Problem der vielen Beteiligten bei zumindest mehreren speicherberechtigten Stellen gesehen. § 6 Abs. 2 BDSG hilft über die Feststellungs- und Zugangsschwierigkeiten der tatsächlich verantwortlichen Stelle hinweg, aber statuiert keine gemeinschaftliche Verantwortung der Beteiligten. Für den Betroffenen sieht § 6 Abs. 2 Satz 1 BDSG bezüglich seiner Auskunfts-, Berichtigungs-, Löschungs- und Sperrungsrechte gemäß § 6 Abs. 1 BDSG im Fall, die 487 speichernde Stelle nicht feststellen zu können, eine Erleichterung vor,: er kann sich an jede dieser in Betracht kommenden Stellen wenden, wenn bei einer automatisierten Speicherung mehrere speicherungsberechtigte Stellen vorhanden sind. Diese angesprochene Stelle muss gemäß § 6 Abs. 2 Satz 2 BDSG das Vorbringen des Betroffenen an die tatsächlich speichernde Stelle weiterleiten. Deshalb erscheint es mit dem geltenden Datenschutzrecht konformer, bei einem gemeinsamen Gebrauch eines RFID-Lesegeräts oder RFID-Lesegerätenetzwerkes in dem (einen) technischen Vorgang der Erhebung, Verarbeitung oder Nutzung personenbezogener Daten, auf die die Beteiligten zurückgreifen, jeweils ein datenschutzrechtlich relevanten Datenumgang gemäß § 3 Abs. 3, Abs. 4 oder Abs. 5 BDSG durch die einzelne beteiligte Stelle zu erblicken. In dem einen technischen Vorgang einer Datenerhebung, -verarbeitung oder -nutzung würde sich ein entsprechend x-facher Erhebungs-, Verarbeitungs- oder Nutzungsvorgang im Sinne des Datenschutzrechts realisieren. Jeder beteiligten Stelle könnte somit ein Vorgang des Datenumgangs zugerechnet werden und wäre auch datenschutzrechtlich am Maßstab der für den jeweiligen Beteiligten einschlägigen Regeln datenschutzrechtlich überprüfbar. Letztlich ist die Stelle, die mittels des RFID-Lesegeräts mit personenbezogenen Daten umgeht, verantwortliche Stelle. Sie ist, wie oben angesprochen, selbst dann gemäß § 3 Abs. 7 BDSG verantwortlich, wenn sie auf Grund von Anforderungen anderer Stellen, etwa über das angeschlossene Hintergrundinformationssystem Erhebungs-, Verarbeitungs- und Nutzungsvorgänge durchführt. Dadurch erhebt und verwendet sie Daten für sich selbst. Ein Austausch dieser Daten oder Verwendungsergebnisse mit Personenbezug an die anderen Stellen könnte sich als eine Übermittlung gemäß § 3 Abs. 4 Satz 2 Nr. 3 BDSG darstellen. Beispielsweise könnte ein Spediteur über die gesamte Logistikkette Transportgut über aufgestellte RFIDLesegeräte verfolgen. Soweit hierdurch personenbezogene Daten erfasst werden, ist er für das Erheben und Verarbeiten dieser Daten verantwortlich, auch wenn diese seinen Kunden zur Verfügung stehen. In gleicher Weise erhebt bei einem unternehmensübergreifenden, elektronischen ÖPNVAbrechnungssystem die Transportgesellschaft als verantwortliche Stelle des jeweiligen Wagens oder Fahrzeuges, in dem das RFID-Lesegerät eingebaut ist, die Fahrgastdaten für sich selbst. Die Weitergabe der Daten an die gemeinsame Abrechnungsstelle erfolgte dann im Wege einer Übermittlung. 5. Grenzen des geltenden Datenschutzrechts Die Ausführungen zeigen, dass sich de lege lata für stattfindende Erhebungs-, Verarbeitungs- oder Nutzungsvorgänge grundsätzlich eine verantwortliche Stelle bestimmen lässt. Dies gilt umso mehr für Verhältnisse, die klar strukturiert und nachvollziehbar sind. Gleichwohl machen die obigen Ausführungen deutlich, dass die Regeln des geltenden Datenschutzrechts beim Einsatz der RFID-Technik und noch mehr bei künftigen Anwendungen des „Ubiquitous Computing“ an ihre Grenzen stoßen werden.[10, 12, 14] Die Herausforderungen, die sich für das Grundrecht der informationellen Selbstbestimmung ergeben können, liegen in dem Einsatz komplexer und ineinander greifender IuK-Infrastrukturen, vernetzter und leistungsfähiger Hintergrundinformationssysteme, zahllos in die Umwelt eingebrachter Sensorstationen, wie RFIDLesegeräte, und deren Vernetzung. Hinzu kommt eine Vielzahl von Beteiligten und eine gemeinsamen Nutzung der selben Techniksysteme. Verbunden könnte der Wandel durch neue Formen von Techniksystemen oder Infrastrukturen sein, die zeitweilig durch Zusammenschaltung entstehen und sich wieder auflösen. Hinzukommt, dass stattfindender Datenumgang erst durch das Zusammenwirken verschiedener Teilsysteme oder erst nach und nach datenschutzrechtlich relevant wird.[14] Dadurch wird die Bestimmung einer verantwortlichen Stelle und die wirkungsvolle Umsetzung des datenschutzrechtlichen Schutzprogramms durch sie schwieriger. Zunächst führt das dazu, dass für den Betroffenen nicht immer klar erkennbar ist, welche Stelle konkret verantwortlich zu machen ist, wenn viele Stellen beteiligt sind. Verschärft wird dieses Problem durch den Umstand, dass in 488 einem entsprechend informatisierten Alltag eine Vielzahl von datenverarbeitenden Vorgängen stattfinden und diese im Hintergrund quasi unmerklich ablaufen sollen. Aber ohne eine Kenntnis von der Identität der verantwortlichen Stelle ist der Betroffene nicht in der Lage seine datenschutzrechtlichen Betroffenenrechte, wie Auskunft, Berichtigung, Löschung oder Schadenersatz wahrzunehmen und durchzusetzen. Um viele der Funktionen im „Ubiquitous Computing“ zur Verfügung zu stellen und Anwendungen gemäß dieser Vision zu ermöglichen, sollen zudem die Techniksysteme zusammenarbeiten und regelrecht ineinandergreifen. Dabei sind oft viele Akteure beteiligt, die unter Umständen nur kurzfristig und spontan Aktionen ausführen. Je nach Funktion kann es genügen, wenn die von ihnen mitgeführten oder aufgestellten Techniksysteme, wie eine RFID-Lesegerätstation, für andere vorübergehend Teil ihrer Systeme werden, ohne ein Agieren oder Reagieren des jeweiligen Akteurs zu erfordern. Ihr möglicherweise sogar ungewolltes Zusammenwirken lässt die klare Verantwortlichkeit einer Stelle verschwimmen. Unter den Bedingungen einer allgegenwärtigen Datenverarbeitung löst sich die Verantwortlichkeit für datenverarbeitende Vorgänge auf, auch wenn § 3 Abs. 7 BDSG, wie zuvor dargestellt, grundsätzlich eine klare Zuweisung der Verantwortlichkeit verspricht. Weiter bringt eine allgegenwärtige und massenhafte Verwendung von IuK-Technik mit sich, dass sich zwischen den Akteuren immer wieder ein Rollenwechsel vollzieht. Bei den einen Anwendungen wird eine Person Betroffener, bei anderen selbst Datenverarbeiter sein. Andere Anwendungen wiederum, wie RFID-Anwendungen mit Komponenten aus RFID-Lesegeräten und RFID-Marken, erfordern durchaus, dass sie gleichzeitig Datenverarbeiter und Betroffener sind. Damit kommt der Daten erhebenden und verwendenden Stelle als verantwortliche Stelle eine ganz andere Bedeutung zu, als sie im geltenden Datenschutzrecht angelegt ist. Diesem Umstand tragen die Regeln, die von der verantwortlichen Stelle die Beachtung der entsprechenden Datenschutzmaßnahmen verlangen, nicht Rechnung. Zum einen berücksichtigen die mit der Verantwortlichkeitszuweisung verbundenen Datenschutzregeln nicht das unterschiedliche Gefährdungspotential, das den jeweiligen Stellen mit ihren Verarbeitungsmöglichkeiten zu eigen ist. Aber auch ihre unterschiedlichen Möglichkeiten, sich datenschutzgerecht zu verhalten, Vorkehrungen zu treffen und datenschutzfreundliche Lösungen anzubieten, bleiben meist außer Betracht. Zum anderen werden sie sich angesichts der vielfältigen und durchaus komplexen Anwendungen im „Ubiquitous Computing“ die hierfür erforderlichen und ablaufenden Datenverarbeitungsvorgänge nicht bewusst machen und machen können. Vielleicht kennen die verantwortlichen Stellen alle Funktionen ihrer Anwendungen, jedoch ist nicht zu erwarten, dass sie diese hinsichtlich der Erhebungs-, Verarbeitungs- und Nutzungsvorgänge verstehen. Hinzu kommt, dass ihnen oft ein legaler Zugriff auf die Geräte und Programme fehlen wird. Ohne aber ein entsprechendes Maß an Kenntnissen von Funktionsweise der Techniksysteme und an Wissen um Gestaltungsmöglichkeiten der Datenverarbeitungsabläufe werden sie kaum in der Lage sein, die Schutzanforderungen zu gewährleisten und Betroffenenrechte adäquat umzusetzen. Des Weiteren setzt die Verantwortlichkeit nach § 3 Abs. 7 BDSG voraus, dass zum einen mit den Daten umgegangen wird und zum anderen sie einen Personenbezug aufweisen. Allerdings sind Techniksysteme im Alltag präsent, die mit ihrer Sensor- und Kommunikationstechnik sowie Rechenleistung einzeln oder im Verbund die Möglichkeit eröffnen, Daten an allen Orten, zu jedem Zeitpunkt und unter nahe zu jeden Situationen zu erheben, zu verarbeiten oder zu nutzen. Dieses Potential stellt für sich eine Bedrohung für die informationelle Selbstbestimmung der möglichen Betroffenen dar, weil sie sich dieser Welt allgegenwärtiger Datenverarbeitung ausgesetzt sehen, ohne hiergegen Handlungsoptionen zu haben und ohne die Datenverarbeitungspotentiale immer in jeder Situation klar einschätzen zu können. Ebenso generieren die verschiedenen Techniksysteme Datenspuren und Datensammlungen, die für die sie gebrauchende Stelle noch keinen Personenbezug aufweisen. Gleichwohl bergen sie ein hohes Gefährdungspotential für die informationelle 489 Selbstbestimmung, da deren Qualität mit der Zeit durch ein sie personalisierendes Ereignis umschlagen kann und alle bis dahin ohne Vorgaben von dem Datenschutzrecht erfassten, gesammelten und ausgewerteten Daten auf einen Schlag doch personenbezogen werden.[12] Das bedeutet aber für beide Risikofelder, von Ausnahmen abgesehen, dass zunächst keine datenschutzrechtliche Verantwortlichkeit entsteht und damit auch das Schutzprogramm des Datenschutzrechts nicht greifen kann. Der Schutz bleibt nachsorgend. Für die datenschutzgerechte Gestaltung der Umgebung fehlt eine Verantwortlichkeitszuweisung der Akteure im Vorfeld.[12]Lediglich § 3a BDSG normiert eine Zielvorgabe an die verantwortliche Stelle, nach der Gestaltung und Auswahl von Datenverarbeitungssystemen am Maßstab der Datensparsamkeit auszurichten sind.[2 Rn 9 ff., Rn. 34 ff.] 6. Lösungsansätze 6.1 Datenschutz durch Technik Da in einer Welt der allgegenwärtigen Datenverarbeitung die verantwortlichen Stellen viele der Schutzanforderungen des Datenschutzrechts nur bedingt umsetzen können werden, reicht es nicht aus, allein diese als Adressat der datenschutzrechtlichen Reglungen anzusprechen. Vielmehr gilt es die Techniksysteme selbst datenschutzfreundlich zu entwerfen und zu konfigurieren. Daher gilt es stärker eine Verantwortung für die Techniksysteme herzustellen und Entwickler der Techniksysteme in die Pflicht zu nehmen.[12, 16] Dazu gehören ergänzend auch diejenigen, die mit Gestaltungseinfluss im Betrieb zu nehmende und genommene Techniksysteme warten und konfigurieren.[13, 15] 6.2 Datenschutz durch differenzierte Verantwortlichkeit Wenn im „Ubiquitous Computing“ die Stellen und ihre Datenverarbeitungen, die datenschutzrechtlich erfasst werden sollen, sehr unterschiedlich sind, dann bietet sich an, die Verantwortlichkeit bezüglich der datenschutzrechtlichen Anforderungen gestuft auszugestalten. Denkbar wäre zwischen einer gezielten und ungezielten Datenverarbeitung zu differenzieren.[13, 15] Bei einer ungezielten Datenverarbeitung, bei der der Personenbezug der verwendeten Daten nicht wichtig ist, könnte man die Stelle hinsichtlich der Schutzanforderungen privilegieren, wenn sie für die sofortige Löschung und Ausschluss einer Weiterverwendung der Daten Gewähr bietet. 6.3 Datenschutz durch personalisierte Verantwortung Wenn im „Ubiquitous Computing“ datenverarbeitende Anwendungen massenhaft und in vielen Lebensbereiche zur Verfügung stehen, dann sind neben Einzelpersonen vor allem auch größere Organisationen oder Unternehmen beteiligt, die das Vorhandensein und Funktionieren der Infrastruktur und der vielfältigen Dienste gewährleisten. Für den Stellenwert des Datenschutzes könnte es hilfreich sein, dessen Beachtung nicht nur den Mitarbeitern und dem betrieblichen Datenschutzbeauftragten zu überlassen, sondern die Geschäftsleitung persönlich in die Verantwortung mit hineinzunehmen.[15] 6.4 Datenschutz durch Vorsorge Um in einer Welt der allgegenwärtigen Datenverarbeitung das hohe Risiko für die informationelle Selbstbestimmung zu steuern und zu reduzieren, das in den Fällen besteht, in denen Datenschutzrecht noch nicht greift, weil keine Vorgänge stattfinden oder die Daten für die Stelle noch nicht personenbeziehbar sind, bedarf es vorsorgender Datenschutzregeln. Dazu müssen diese Stellen, die 490 entsprechend potente Techniksysteme in die Umwelt einbringen oder mit solchen Daten umgehen, im Vorfeld des geltenden Datenschutzrechts in die Verantwortlichkeit genommen werden.[12, 15] Im Ergebnis erfordern die neuen Herausforderungen durch „Ubiquitous Computing“ eine Modernisierung des Begriffs der verantwortlichen Stelle als Anknüpfungspunkt im Datenschutzrecht, die natürlich durch weitere risikoadäquate Regeln zu Verarbeitung und Gestaltung der Techniksysteme ergänzt werden muss. Literatur [1] BIZER, J. / SPIEKERMANN, S. / GÜNTHER, O. u.a.: Technikfolgenabschätzung: Ubiquitäres Computing und Informationelle Selbstbestimmung (TAUCIS), Kiel/Berlin 2006. [2] Bizer, J., § 3a, in: Simitis u.a. (Hrsg.), Kommentar zum Bundesdatenschutzgesetz, Baden-Baden 2006. [3] COROAMA, V. u.a. Szenarien des Kollegs Leben in einer smarten Umgebung – Auswirkungen des Ubiquitous Computing, Ladenburg 2003. [4] Dammann, U., § 3, in: Simitis u.a. (Hrsg.), Kommentar zum Bundesdatenschutzgesetz, Baden-Baden 2006. [5] Dix, A., § 33, in: Simitis. u.a. (Hrsg.), Kommentar zum Bundesdatenschutzgesetz, Baden-Baden 2006. [6] Hager, U., § 823 BGB, in: v. STAUGINGER, J., Kommentar zum Bürgerlichen Gesetzbuch mit Einführungsgesetz und Nebengesetzen, Berlin 1999. [7] HILLMANN, R., § 128, in: Ebenroth, C. T. / Boujong, K. / Joost, D. (Hrsg.), Handelsgesetzbuch Kommentar Band 1 §§ 1-342a, München 2001. [8] MATTERN, F., Acht Thesen zur Informatisierung des Alltags, in: ders. (Hrsg.), Die Informatisierung des Alltags – Leben in smarten Umgebungen, Berlin/Heidelberg 2007. [9] MÜLLER, J. / HANDY, M., RFID als Technik des Ubiquitous Computing – Eine Gefahr für die Privatsphäre?, in: Ferstl, O. K. / Sinz, E. J. / Eckert, S. / Isselhorst, T., (Hrsg), eEconomy, eGovernment, eSociety, Tagungsband Wirtschaftsinformatik, Heidelberg 2005, 1145 – 1164. [10] MÜLLER, J. / HANDY, M., RFID und Datenschutzrecht, Risiken, Schutzbedarf und Gestaltungsideen, Datenschutz und Datensicherheit (Zeitschrift) 2004, 655-659. [11] MÜLLER, J., Ist das Auslesen von RFID-Tags zulässig?, Datenschutz und Datensicherheit (Zeitschrift) 2004, 215-217. [12] MÜLLER, J., Datenschutzvorsorge gegenüber Risiken der RFID-Technologie, in: Mattern, F., (Hrsg.), Die Informatisierung des Alltags - Leben in smarten Umgebungen, Berlin/Heidelberg 2007. [13] ROßNAGEL, A. / PFITZMANN A. / GARSTKA H. (2001): Modernisierung des Datenschutzrechts, Bundesministeriums des Innern, Berlin 2001. [14] ROßNAGEL, A. / MÜLLER, J. :Ubiquitous Computing – neue Herausforderungen für den Datenschutz, Ein Paradigmenwechsel und die von ihm betroffenen normativen Ansätze, Computer und Recht (Zeitschrift) 2004, 625-632. [15] ROßNAGEL, A. (2007a): Informationelle Selbstbestimmung in der Welt des Ubiquitous Computing, in: Mattern, F., (Hrsg.), Die Informatisierung des Alltags - Leben in smarten Umgebungen, Berlin/Heidelberg 2007. [16] ROßNAGEL, A. (2007b): Datenschutz in einem informatisierten Alltag, Medien – und Technologiepolitik, Gutachten im Auftrage der Friedrich-Ebert-Stiftung (FES), Berlin 2007. [17] Sprau, H., § 705, in: PALANDT, O., Kommentar zum Bürgerlichen Gesetzbuch (BGB), München 2006. 491 FILESHARING UND TAUSCHBÖRSEN: DIE HAFTUNG DES ANSCHLUSSINHABERS (AUF UNTERLASSUNG) UNTER DEM GESICHTSPUNKT DER STÖRERHAFTUNG – EIN LÖSUNGSVORSCHLAG ZWISCHEN RECHTSPRECHUNG UND REALITÄT Jan Morgenstern1 Kurzfassung Die Diskussion über sog. Tauschbörsen im Internet ist in aller Munde, die Rechtsprechung zur Haftung der Anschlussinhaber für über ihren Internetanschluss begangene Urheberrechtsverletzungen ist uneinheitlich. Im Gegensatz zu Österreich steht eine höchstrichterliche Entscheidung in Deutschland noch aus. Ohne Partei für eine der betroffenen Seiten ergreifen zu wollen, möchte der Verfasser auf Basis der aktuellen Rechtsprechungsentwicklung in Deutschland und Österreich einen Beitrag und einen Vorschlag zu einer interessengerechten Lösung der Problemfelder leisten. Ein besonderer Schwerpunkt soll hierbei auf der Beurteilung der Haftung der Eltern als Anschlussinhaber unter dem Gesichtpunkt der urheberrechtlichen Störerhaftung liegen. 1. Die technische und rechtliche Ausgangsposition 1.1. Peer-to-Peer-Netzwerke als „Tauschbörsen“? Der Begriff Tauschbörse ist irreführend und gibt nicht wirklich zutreffend das System und die Funktionsweise sog. Peer-to-Peer-Netzwerke wieder. Mit Filesharing (deutsch „Dateifreigabe“ oder gemeinsamer Dateizugriff“, wörtlich „Dateien teilen“) bezeichnet man das direkte Weitergeben von Dateien zwischen Benutzern des Internets unter Verwendung eines Peer-to-Peer-Netzwerks. Dabei befinden sich die Daten auf den Computern der Teilnehmer und werden von dort aus verteilt. Normalerweise kopiert man Daten von fremden Rechnern (Download), während man gleichzeitig andere Daten versendet (Upload). Um auf solche Netzwerke zugreifen zu können, braucht man spezielle Computerprogramme. [1] 1 Rechtsanwalt, KANZLEI DR. ERBEN, D-69120 Heidelberg, Neuenheimer Landstr. 36 493 1.2. Die rechtliche Relevanz Urheberrechtlich problematisch stellt sich in der Regel weniger der Download als vielmehr der Upload der Dateien dar: Der Download wird wohl zumeist von § 53 Abs. 1 UrhG privilegiert sein. Einzelne Vervielfältigungen eines Werks durch eine natürliche Person zum privaten Gebrauch auf beliebigen Trägern sind hiernach zulässig, sofern sie weder unmittelbar noch mittelbar Erwerbszwecken dienen und soweit nicht zur Vervielfältigung eine offensichtlich rechtswidrig hergestellte Vorlage verwendet wird. Die sicherlich brisante Frage, ob die Vorlage der Kopie (des Downloads) als offensichtlich rechtwidrig einzuordnen ist, kann in der Praxis meist unbeantwortet bleiben, denn jedenfalls stellt der Upload zweifellos eine Urheberrechtsverletzung dar: Es handelt sich um ein öffentliches Zugänglichmachen im Sinne des § 19 a UrhG, eine Verwertung, die ausschließlich dem Urheber zusteht. In der Mehrheit der Fälle werden die damit klaren Verletzungen der Urheberrechte jedoch nicht von den Inhabern der Anschlüsse begangen. Zumeist sind es die im gemeinsamen Haushalt lebenden Kinder, die an den Tauschbörsen teilnehmen und so (oftmals unbewusst, zumindest ohne jegliches Unrechtsbewusstsein) bestehende Urheberrechte an Musikstücken und Computerspielen verletzen. Über die Ermittlungsbehörden erlangen die Rechteinhaber aber lediglich Auskunft seitens der Provider über den Internetanschluss, der zu dem dokumentierten Zeitpunkt der Verletzungshandlung der festgehaltenen IP-Adresse zugeordnet war. Einen rechtlichen Anknüpfungspunkt für die in der Praxis regelmäßige Inanspruchnahme der Anschlussinhaber kann alleine die Rechtsfigur der urheberrechtlichen Störerhaftung liefern. Der Ansatz dieses Rechtsinstruments und die Übertragbarkeit auf die beschriebene Sachverhaltskonstellation sollen im Folgenden dargestellt werden. 2. Die Störerhaftung Als Störer kann bei der Verletzung absoluter Rechte auf Unterlassung in Anspruch genommen werden, wer - ohne Täter oder Teilnehmer zu sein - in irgendeiner Weise willentlich und adäquat kausal zur Verletzung des absoluten Rechts beiträgt. [2] Da die Störerhaftung nicht über Gebühr auf Dritte erstreckt werden darf, die nicht selbst die rechtswidrige Beeinträchtigung vorgenommen haben, setzt die Haftung des Störers nach ständiger höchstrichterlicher Rechtsprechung allerdings die Verletzung von Prüfpflichten voraus. Deren Umfang bestimmt sich danach, ob und inwieweit dem als Störer in Anspruch Genommenen nach den Umständen eine Prüfung zuzumuten ist. [3] Dieser Ansatz wird insbesondere durch die Entscheidungen Möbelklassiker und Internetversteigerung I-III noch deutlicher unterstrichen: Nur Hinweise auf eine klare bzw. grobe und unschwer zu erkennende Rechtsverletzung führen zu einer Begründung dieser 494 Haftungsvariante, die zu Recht vom BGH eingedämmt wurde und die sich ansonsten uferlos auf jeden noch so entfernten Kausalbeitrag erstrecken würde. Zweifellos wird in der Zurverfügungstellung eines Internetanschlusses an Dritte (insbesondere Familienmitglieder) ein willentlich und adäquat kausaler Beitrag zu einer über diesen Internetanschluss begangenen Urheberrechtsverletzung zu sehen sein. Die entscheidende und vor allen Dingen sachgerechte Eingrenzung ist allerdings nach den klaren Vorgaben des BGH auf der nächsten Stufe vorzunehmen, nämlich im Zusammenhang mit der Frage, ob und wodurch nach den Umständen des Einzelfalls Prüf- und Überwachungspflichten begründet werden können. Soweit die abmahnenden Vertreter der Tonträgerindustrie formulieren: „Dieser Unterlassungsanspruch […] besteht unabhängig davon, ob Sie als Anschlussinhaber die Rechtsverletzungen möglicherweise nicht selbst begangen haben. Als Inhaber des Internetanschlusses, über den die Urheberrechtsverletzungen begangen wurden, sind Sie schließlich nach den Grundsätzen der sog. Störerhaftung für die eingetretenen Rechtsverletzungen verantwortlich, auch wenn Sie die Filesharing-Programme nicht selbst genutzt haben sollten.“ [4] ist dies rechtlich unzutreffend und geht weit über die vom BGH entwickelten Grundsätze zur Störerhaftung hinaus. Wie allerdings konkret die Grundsätze der Störerhaftung derzeit von den deutschen Gerichten auf die Filesharing-Konstellationen angewendet werden und wie dies vor dem Hintergrund der bestehenden höchstrichterlichen Vorgaben zu bewerten ist, soll nachfolgender Überblick verdeutlichen. 3. Die aktuelle Rechtsprechung in Deutschland zur Störerhaftung des Anschlussinhabers – Überblick und Bewertung 3.1. Aktueller Rechtsprechungsüberblick Die aktuelle Rechtsprechung der deutschen Land- und Oberlandesgerichte zu der Haftung des Anschlussinhabers unter dem Gesichtspunkt der Störerhaftung ist uneinheitlich. Mangels einer klärenden höchstrichterlichen Entscheidung zu der konkreten Problematik besteht erhebliche Rechtsunsicherheit. Das LG Hamburg sieht regelmäßig [5] das Überlassen eines Internetanschlusses an einen Dritten für die Begründung der Störerhaftung des Anschlussinhabers als ausreichend an. Dies birge nämlich die nicht unwahrscheinliche Möglichkeit, dass von dem Dritten Urheberrechtsverletzungen begangen werden, was Prüf- und Handlungspflichten auslöse, um der Möglichkeit solcher Rechtsverletzungen vorzubeugen. Ähnlich pauschal urteilt das LG Düsseldorf. [6] Diese Argumentation steht allerdings auf mehr als ungefestigten Beinen und wird angesichts der klaren Vorgaben des BGH sicherlich nicht dauerhaft Bestand haben können. Die Hamburger Richter verkennen, dass keinesfalls „die unwahrscheinliche Möglichkeit“, dass von einem Dritten (insbesondere der Kinder) Urheberrechtsverletzungen begangen werden, rechtlich 495 geeignet und ausreichend sein kann, vollkommen undifferenziert Prüf- und Handlungspflichten zu begründen, deren Verletzung bzw. Vernachlässigung eine Störerhaftung zu begründen vermag. Erforderlich sind vielmehr klar erkennbare und grobe bzw. offensichtliche Verstöße. Dies ergibt sich nicht nur bereits aus der oftmals vergeblich vor dem LG Hamburg zitierten MöbelklassikerEntscheidung, sondern insbesondere auch im Hinblick auf die Entscheidungen Internetversteigerung I-III. Der BGH hat hier die Anforderungen an die Störerhaftung erneut bekräftigt und konkretisiert. Bereits in der Möbelklassiker Entscheidung des BGH wurde klar herausgearbeitet, dass die urheberrechtliche – wie im Übrigen auch die wettbewerbsrechtliche – Störerhaftung nur in Fälle grober, unschwer zu erkennender Verstöße in Betracht kommen kann. [7] Sofern oftmals die Argumentation vorgetragen wird, diese Entscheidung könne nicht als (allgemeingültiger) Maßstab herangezogen werden, weil es sich hier um eine Sonderkonstellation handele, um – insbesondere mit Blick auf Art. 5 GG – den Schutz der Pressefreiheit zu gewährleisten, ist dies so nicht zutreffend. Sicherlich berücksichtigt die Entscheidung in gewisser Weise (besonders) den Schutz der Pressefreiheit. Dies führt aber nach dem Verständnis der Entscheidung lediglich dazu, dass ein mehr oder weniger pauschaler Hinweis direkt an den angeblichen Störer noch längst nicht zu einer entscheidenden Erhöhung der Prüfungspflicht führen kann. Die presserechtlichen Besonderheiten werden hier also dadurch berücksichtigt, dass die Hinweise durch den Rechtsinhaber oder Dritte konkret sein müssen. In der üblichen Filesharing-Konstellation gibt es aber in der Regel überhaupt keinen, nicht einmal einen allgemeinen, Hinweis darauf, dass über den betroffenen Internetanschluss Urheberrechtsverletzungen begangen werden. Dies berücksichtigend erkennt das LG Mannheim demgegenüber keine Haftung des Internetanschlussinhabers für urheberrechtswidrige Handlungen volljähriger Familienmitglieder. Einen Internetanschlussinhaber trifft im Rahmen zumutbarer Prüfungsund Überwachungspflichten zur Verhinderung von Urheberrechtsverletzungen durch Filesharing hinsichtlich volljähriger Familienmitglieder weder die Obliegenheit einer einweisenden Belehrung in die Internetnutzung noch einer dauerhaften Überprüfung ohne konkreten Anlass. [8] Sachgerecht und vor allen Dingen realitätsnah sind nach Ansicht des LG Mannheim Prüfungs- und Überwachungspflichten nur insoweit anzunehmen, als diese im Rahmen der Erziehung von Kindern in Abhängigkeit von deren Alter auch auf anderen Betätigungsfeldern notwendig ist. Eine dauerhafte Überprüfung des Handelns der eigenen Kinder oder des Ehepartners ist ohne konkreten Anlass nicht zumutbar. Ohne Anlass für die Annahme, dass Familienmitglieder in rechtswidriger Weise Urheberrechte im Rahmen der Nutzung des Internets verletzen, kommt eine ständige Überwachung oder gar eine Sperrung des Anschlusses für diese nicht in Betracht. Ob es allerdings bei Eröffnung des Internetverkehrs für die Kinder einer einweisenden Belehrung bedarf, ist nach dem Alter und dem Grad der Vernunft der jeweiligen Nutzer im Einzelfall zu entscheiden. [9] Vollkommen zutreffend erkennt das LG Mannheim, dass bei einem volljährigen Kind, das nach allgemeiner Lebenserfahrung im Umgang mit Computer- und Internettechnologie einen 496 Wissensvorsprung vor seinen erwachsenen Eltern hat, es sinnvollerweise keiner einweisenden Belehrung über die Nutzung des Internets bedarf. In diesem Fall muss es bei der Beurteilung bleiben, dass die Eltern ein konkretes Familienmitglied nicht ohne Anlass der Begehung unerlaubter Handlungen verdächtigen müssen und dementsprechend zur Einleitung von Überwachungsmaßnahmen verpflichtet wären. In einem weiteren Urteil hat das LG Mannheim die Frage des Umfangs der Prüfungspflichten bei minderjährigen Kindern offen lassen können, da zugleich neben den Kindern auch noch Dritte als Verletzer in Frage kamen, für die eine Störerhaftung unzweifelhaft zu bejahen sei. [10] Denn soweit der Anschlussinhaber bei seinen eigenen Kindern beurteilen kann, ob er Anlass für Belehrungen und Kontrollen im Rahmen der Eröffnung des Internetzugangs hat, kann er dass bei Dritten, wie z.B. Freunden der Kinder, nicht. Wenn der Anschlussinhaber in einem solchen Fall keinerlei Maßnahmen unternimmt, um die von seinem Internetanschluss ausgehenden Handlungen zu prüfen, verstößt er gegen die ihm obliegenden Prüfpflichten und haftet damit unter dem Gesichtspunkt der Störerhaftung. Es ist allerdings davon auszugehen, dass im Falle der Minderjährigkeit durchaus eine andere Betrachtung gerechtfertigt ist. Dogmatisch und unter Berücksichtigung der Rechtsprechungsvorgaben wird in diesem Fall die Störerhaftung aber wohl nicht auf die Verletzung von Prüfpflichten zurückzuführen zu sein, sondern auf eine nicht hinreichend beachtete Instruktionspflicht. Auf derselben Linie wie das LG Mannheim urteil das LG München I: Allein aus der Tatsache der Überlassung eines Internetanschlusses kann ohne weitere konkrete Anhaltspunkte einer drohenden Rechtsverletzung durch den unmittelbar Handelnden eine Störereigenschaft des Anschlussinhabers nicht abgeleitet werden. [11] Keine andere Deutung ist im Übrigen der jüngsten Entscheidung des LG München I [12] zu entnehmen. In dem dort zu beurteilenden Fall ging es nämlich nicht um die Störerhaftung auf Unterlassung, sondern um eine Haftung der Eltern einer Minderjährigen wegen der Verletzung von Aufsichtspflichten gestützt auf § 832 BGB. Eine Abkehr von der früheren Entscheidung des LG München I zu dieser Thematik wollten die Richter hiermit keinesfalls verbunden wissen. Im Gegenteil: Die Kammer betont nochmals die Anlehnung an das LG Mannheim und die grundsätzliche Unterscheidung hinsichtlich der Störerhaftung des Anschlussinhabers, je nachdem, ob es sich um einen volljährigen oder minderjährigen Verletzer handelt. Auch das OLG Frankfurt hat sich dieser Auffassung mittlerweile angeschlossen und spricht sich darüber hinaus für die im Hinblick auf die Entstehung von Prüf- und Überwachungspflichten gebotene Differenzierung zwischen Volljährigkeit und Minderjährigkeit des Urheberrechtsverletzers aus: Eine Pflicht, die Benutzung seines Internetanschlusses zu überwachen oder gegebenenfalls zu verhindern, besteht nunmehr auch nach Ansicht des OLG Frankfurt nur, wenn der Anschlussinhaber konkrete Anhaltspunkte dafür hat, dass der Nutzer den Anschluss zu Rechtsverletzungen missbrauchen wird. [13] 497 Solche Anhaltspunkte bestehen grundsätzlich nicht, solange dem Anschlussinhaber keine früheren Verletzungen dieser Art durch den Nutzer oder andere Hinweise auf eine Verletzungsabsicht bekannt sind oder hätten bekannt sein können. Auch wenn Urheberrechtsverletzungen im Internet häufig vorkommen und darüber in den Medien umfangreich berichtet wird, hat ein Anschlussinhaber nicht bereits deshalb einen Anlass, ihm nahe stehende Personen wie enge Familienangehörige bei der Benutzung seines Anschlusses zu überwachen. Eine Instruktionspflicht dahin, dass mit seinem Internetanschluss keine Urheberrechtsverletzungen begangen werden, trifft den Anschlussinhaber gegenüber seinen volljährigen Familienangehörigen nicht. [14] 3.2. Fazit und Bewertung Die dargestellten Entscheidungen arbeiten im Wesentlichen folgende Ansätze und Konstellationen heraus, die im Hinblick auf die Verantwortlichkeit des Anschlussinhabers unterschiedlich zu bewerten sind: 3.2.1. Unterscheidung zwischen Minderjährigkeit und Volljährigkeit Es zeichnet sich eine zunehmende Differenzierung zwischen Voll- und Minderjährigkeit bzw. eine adäquate Berücksichtigung des Alters und des Grads der Vernunft des jeweiligen Nutzers ab. Belehrungs-, Prüfungs- und Überwachungspflichten können schließlich hinsichtlich der Internetnutzung nur insoweit angenommen werden, als diese im Rahmen der Erziehung von Kindern in Abhängigkeit von deren Alter auch auf anderen Betätigungsfeldern notwendig ist. Eine Pflicht der Eltern, die Benutzung ihres Internetanschlusses zu überwachen oder gegebenenfalls zu verhindern, kann nur dann angenommen werden, wenn der Anschlussinhaber konkrete Anhaltspunkte dafür hat, dass der Nutzer den Anschluss zu Rechtsverletzungen missbrauchen wird. Dies wird wohl unabhängig von einer Voll- oder Minderjährigkeit des Internetnutzers gelten. Damit wirkt sich die Frage der Volljährigkeit oder Minderjährigkeit des Internetnutzers nicht entscheidend im Zusammenhang mit etwaigen Prüfpflichten sondern bei der Frage des Bestehens und des Umfangs etwaiger Instruktionspflichten aus. Gegenüber jüngeren (minderjährigen) Kindern wird man den Eltern wohl - auch das ist den diskutierten Entscheidungen zumindest im Ansatz zu entnehmen - eine Verpflichtung zu einer einweisenden Belehrung bzw. eine Instruktionspflicht auferlegen können, deren Vernachlässigung durchaus zur Begründung der Störerhaftung führen kann. Was den Eltern pauschal aber realistischerweise in diesem Zusammenhang abverlangt werden kann, dürfte höchst problematisch zu beurteilen sein. In diesem Zusammenhang möchte der Verfasser daher unter 5.1. einen allen Beteiligten gerecht werdenden Lösungsvorschlag anbieten. 3.2.2. Haftung für Dritte und die eigenen Kinder Soweit ein Anschlussinhaber den Anschluss Familienangehörigen und insbesondere seinen Kindern zur Verfügung stellt, beruht die Eröffnung des Zugangs zum Internet auf dem familiären Verbund. Prüfungs- und Überwachungspflichten sowie Instruktionspflichten sind nur insoweit anzunehmen, als diese im Rahmen der Erziehung von Kindern in Anhängigkeit von deren Alter auch auf anderen Betätigungsfeldern notwendig ist. [15] 498 Hiermit wird klargestellt, dass eine einweisende Belehrung, sowie eine Überwachung und Überprüfung von volljährigen Familienmitgliedern ohne konkreten Anlass nicht gerechtfertigt sein kann. Eine Unterlassung ist damit auch nicht geeignet, eine Haftung des Anschlussinhabers unter dem Gesichtspunkt der Störerhaftung zu begründen. Diese Grundsätze gelten allerdings nicht für Dritte. Denn soweit der Anschlussinhaber bei seinen eigenen Kindern beurteilen kann, ob er Anlass für Belehrungen und Kontrollen im Rahmen der Eröffnung des Internetzugangs hat, kann er dass bei Dritten, wie z.B. Freunden der Kinder, nicht. Wenn der Anschlussinhaber in einem solchen Fall keinerlei Maßnahmen unternimmt, um die von seinem Internetanschluss ausgehenden Handlungen zu prüfen, verstößt er gegen die ihm obliegenden Prüfpflichten. [16] Auch in diesem Zusammenhang wird man dogmatisch aber wohl eher auf die Instruktionspflicht abstellen müssen. 4. Die Situation in Deutschland und Österreich im Vergleich Österreich ist Deutschland einen entscheidenden Schritt voraus. Am 21.01.08 hat der Oberste Gerichtshof in Österreich eine grundlegende Entscheidung zu der Frage der Haftung des Anschlussinhabers getroffen. [17] Die hierin enthaltene Wertung könnte auch eine (früher oder später) fällige Entscheidung des deutschen Bundesgerichtshofs prägen. Die Ausgangssituation ist identisch mit den Fällen in Deutschland. Wie soll sich auch ein Unterschied ergeben? In Deutschland und Österreich sitzen die Kinder und Jugendlichen vor dem PC, „tauschen“ munter Dateien über das Internet, während die Eltern als Anschlussinhaber hiervon keine Kenntnis und Vorstellung haben. Parallel zu dem Ansatz der deutschen Störerhaftung soll der Beklagte in Österreich als Gehilfe eines Urheberrechtsverstoßes in Anspruch genommen werden. Wer - ohne Täter oder Teilnehmer zu sein - in irgendeiner Weise willentlich und adäquat kausal zur Verletzung eines geschützten Gutes beiträgt, kann nach ständiger Rechtsprechung in Deutschland als Störer für eine Urheberrechtsverletzung in Anspruch genommen werden. Demgegenüber ist nach österreichischem Recht Gehilfe eines urheberrechtlichen (wie auch wettbewerbsrechtlichen) Verstoßes derjenige, der den Täter bewusst fördert. Eine bloß adäquate Verursachung reicht nicht aus, es muss insbesondere auch ein rechtswidriges Verhalten vorliegen. In der Ausgangsposition dieser beiden rechtlichen Konstruktionen ist der Maßstab der österreichischen Teilnahme bzw. Gehilfenhaftung deutlich enger gefasst. Reicht nach deutschem Recht zur Begründung der Störerhaftung bereits ein willentlich und adäquat-kausaler Beitrag, setzt die österreichische Teilnahme eine bewusste Förderung und die Rechtswidrigkeit voraus. An dem Kriterium der Prüfpflicht überschneiden sich jedoch beide Ansätze: Damit sich die Haftung nach deutschem Recht nicht über Gebühr auf Dritte erstreckt, setzt die Störerhaftung die Verletzung von Prüfpflichten voraus. Nach dem österreichischen Ansatz muss der Gehilfe den Sachverhalt kennen, der den Vorwurf gesetzwidrigen Verhaltens begründet oder er muss zumindest eine diesbezügliche Prüfpflicht verletzen. Die Prüfpflicht ist allerdings auf grobe und auffallende Verstöße beschränkt. 499 Nach der Wertung des Obersten Gerichtshofs stellt das bloße Zurverfügungstellen des Computers mit Internetzugang zwar eine adäquate Ursache für die spätere Rechtsverletzung. Der Anschlussinhaber muss aber mangels irgendwelcher Anhaltspunkte nicht damit rechnen, dass seine Kinder bei Nutzung des Internets in Urheberrechte eingreifen würden. Ohne das Hinzutreten besonderer Umstände sind Eltern nicht verpflichtet, die Internetaktivitäten ihrer (minderjährigen) Kinder zu überwachen. Hierbei ist zu beachten, dass die Funktionsweise von Internettauschbörsen und Filesharing-Systemen bei Erwachsenen nicht als allgemein bekannt vorausgesetzt werden können. Handlungs- und Prüfpflichten können sich erst nach Kenntnis des Anschlussinhabers von einem Verstoß ergeben. Diese Argumentation lässt sich zwar nicht bis ins Detail, so doch im Grundsatz auf die Anwendung der Störerhaftung in Deutschland übertragen: Auch hier kann wohl kaum - unter Berücksichtigung der bisherigen höchstrichterlichen Rechtsprechung - ohne konkrete Anhaltspunkte für über den Internetanschluss begangene Rechtsverletzungen eine Begründung von Prüf- und Überwachungspflichten angenommen werden, jedenfalls nicht in Bezug auf volljährige Kinder. In Anlehnung an die sich abzeichnende Tendenz der Land- und Oberlandesgerichte wäre allerdings eine weitergehende Differenzierung hinsichtlich Alter und Reifegrad des Kindes wünschenswert. Bei jüngeren Internetnutzern sollten sich die Eltern - nicht nur im Hinblick auf die mit der Nutzung von Filesharing-Systemen verbundenen Risiken - ihrer Verantwortung bewusst sein. Eine entsprechende einweisende Belehrung sollte man insoweit verlangen können. Wie konkret diese jedoch ausgestaltet sein kann und soll, ist allerdings sicherlich nicht pauschal festzulegen und hängt letztlich - zumindest auch - stark von Bildungsgrad und IT-Affinität der Eltern ab. 5. Ein Lösungsvorschlag zur sinnvollen Begrenzung einer unübersehbaren Haftung 5.1. Lösungsansatz Sicherlich wird man den Eltern im Grundsatz bei minderjährigen Internetnutzern eine gewisse Verantwortung zubilligen können (müssen). Eine entsprechende Tendenz zeichnet sich (zu Recht) in der aktuellen Rechtsprechung ab. Viele Eltern werden trotzdem wohl kaum in der Lage sein, ihre Kinder über die Funktionsweise und die rechtliche Bewertung von Filesharing-Systemen aufzuklären und insoweit etwaigen Handlungspflichten Genüge tragen können, um der Gefahr einer Inanspruchnahme unter dem Gesichtspunkt der Störerhaftung zu entgehen. Ein Warnhinweis am Bildschirm bzw. im Web-Browser könnte hier Abhilfe und in gewissem Maße Sicherheit für alle Beteiligten schaffen. Es wäre durchaus möglich und denkbar, Bildschirme und Internetbrowser mit einem Haftungshinweis auszustatten, die zur Kenntnis genommen werden müssen. Auch in dieser Hinsicht bietet sich eine Vergleichbarkeit zu der oft im Zusammenhang mit der Filesharing-Problematik zitierten Kopierläden-Entscheidung des BGH [18] an. Der Entscheidung lag der Sachverhalt zugrunde, dass Kunden eines Copy-Shops Urheberrechte verletzt haben und der Betreiber unter dem Gesichtspunkt der Störerhaftung in Anspruch genommen werden sollte. 500 Der BGH gelangte zu der Auffassung, dass ein in den Allgemeinen Geschäftsbedingungen enthaltener Hinweis auf fremde Urheberrechte und die Verpflichtung zur Beachtung dieser, deutlich sichtbar im Ladenlokal angebracht, ausreiche, um die Begründung einer Störerhaftung auszuschließen. Damit habe der Betreiber alle ihm zumutbaren Maßnahmen getroffen, durch die eine Verletzung von Urheberrechten möglichst ausgeschlossen wird. Es mag zwar zunächst auf den ersten Blick etwas seltsam erscheinen, aber ein entsprechender Warnhinweis an der genutzten Hardware bzw. integriert in den verwendeten Internetbrowser sollte angesichts dieser Anforderungen ausreichen, seiner Haftung als Anschlussinhaber vorzubeugen. Sicherlich wird sich unser Auge auch noch hieran gewöhnen – es ist ja schließlich nicht der erste und sicherlich auch nicht der letzte Warnhinweis, den wir wahrzunehmen haben. Gefordert sind hier natürlich vor allem die Hard- und Softwarehersteller. Diese sollten hier eine entsprechende Vorreiterrolle spielen. Die Störerhaftung ließe sich mit guten Gründen (theoretisch, insbesondere mit der Argumentation des LG Hamburg) auch auf die Hersteller von Hard- und Software sowie auf die Provider ausdehnen, mit deren wesentlichen Beiträgen die Urheberrechtsverletzungen überhaupt erst ermöglicht werden. Im Zusammenhang mit der mittlerweile wohl fast einhellig angenommenen Haftung für unverschlüsselte WLAN-Nutzung auch in Bezug auf die Hersteller und Lieferanten der entsprechenden Router. Unproblematisch möglich wäre es sicherlich einen Hinweis wie den folgenden im Rahmen der Ersteinrichtung des verwendeten Webbrowsers bzw. bei der Erstinstallation der verwendeten Hardware, insbesondere des Bildschirms, anzubringen: BITTE BEACHTEN SIE: DIE VERBEITUNG UND ÖFFENTLICHE ZUGÄNGLICHMACHUNG VON URHEBERECHTLICH GESCHÜTZEN MATERIAL ÜBER DAS INTERNET (INSBESONDERE IM RAHMEN SOG. TAUSCHBÖRSEN) STELLT EINE VERLETZUNG HIERAN BESTEHENDER URHEBERRECHTE DAR UND KANN ZU EINER STRAFRECHTLICHEN VERFOLGUNG SOWIE ZU ZIVILRECHTLICHEN UNTERLASSUNGS- UND SCHADENSERSATZANSPRÜCHEN FÜHREN. 5.2. Rechtliche und tatsächliche Bedeutung Ausgehend von der unter 3. dargestellten Rechtsprechung entbindet ein entsprechender Hinweis die Anschlussinhaber / Eltern natürlich nicht von Prüf- und Überwachungspflichten, sofern sich tatsächlich konkrete Hinweise auf etwaige Rechtsverletzungen ergeben sollten, die über den betreffenden Internetanschluss begangen worden sind. Soweit allerdings eine einweisende Belehrung des Anschlussinhabers - wie insbesondere im Zusammenhang mit der Internetnutzung durch Minderjährige - bei Überlassung des Internetanschlusses gefordert wird, sollte der entsprechende Hinweis ausreichen, diesen Anforderungen zu genügen. 501 Ein solcher Hinweis würde die oftmals überforderten Eltern juristisch entlasten und hätte sicherlich auch mehr Nachdruck als ein entsprechend laienhafter und unverständlicher Hinweis der Eltern selbst. Sicherlich würde die Teilnahme an (rechtswidrigen) Peer-to-Peer-Netzwerken merklich zurückgehen. Insoweit wäre also vor allem auch den jeweiligen Rechteinhabern geholfen. Der Ball würde an diejenigen zurückgespielt werden, die in der Ursachenkette an erster Stelle stehen und für die ein derartiger Warnhinweis weder mit großem zusätzlichem Aufwand noch mit Kosten verbunden wäre. Auch aus Gründen der eigenen Absicherung wäre ein derartiger Hinweis für Hersteller von Hard- und Software sowie Provider ratsam. 6. Literaturhinweise [1] siehe http://de.wikipedia.org/wiki/File_Sharing [2] BGH, Urteil vom 18.10.2001 - Az. I ZR 22/99, WRP 2002, 532 - Meißner Dekor I [3] BGHZ 158, 343, 350 - Schöner Wetten; BGH, WRP 2006, 1109 = MIR 2006, Dok. 117 - RechtsanwaltsRanglisten [4] Auszug aus einem standardisierten Abmahnschreiben [5] seit Beschluss v. 21.04.06 – AZ 308 O 139/06; CR 2007, 121 [6] Beschluss vom 13.04.2007, Az. 12 O 87/07 [7] BGH GRUR 1999, 418-420 – Möbelklassiker [8] LG Mannheim, Urteil v. 30.01.07 – AZ 2 O 71/06; CR 2007, 395 [9] LG Mannheim, aaO [10] LG Mannheim - AZ 7 O 62/06 [11] LG München I, CR 2008, 49, 51 [12] LG München I, Urteil v. 19.06.08 – AZ 7 O 16402/07 [13] OLG Frankfurt, Beschluss v. 20.12.07 – AZ 11 W 58/07 [14] OLG Frankfurt, aaO [15] LG Mannheim - AZ 7 O 62/06 [16] LG Mannheim, aaO [17] OGH, Beschluss vom 22.01.2008 - Az. 4Ob194/07v [18] BGH NJW 1984, 1106-1108 – Kopierläden 502 PERFORMANCE & MONITORING, IT-CONTROLLING Das IT-Performance-Management / IT-Controlling ist in IT-Abteilungen und bei IT-Dienstleistern integraler Bestandteil aller Management- und Führungsfunktionen. Technologische Änderungen und neue Managementkonzepte müssen laufend im Controlling adaptiert und ihr Erfolg muss nachgewiesen werden. Die erfolgreiche Steuerung der IT bzw. der Informatik hängt unmittelbar damit zusammen: Wie lässt sich der Erfolg und der Wertbeitrag der IT messbar und damit steuerbar gestalten? Seit Beginn der elektronischen Datenverarbeitung wurde dazu eine Vielzahl von Controllinginstrumenten entwickelt und eingesetzt. Die Ansätze reichen hier von speziell für die IT entwickelten Kennzahlensystemen bis zur Übertragung der Balanced Scorecard oder industrieller Controllingkonzeptionen in den IT-Bereich. Die zentrale Aufgabenstellung ist dabei, die richtige IT-Controllingkonzeption und die passenden Controllinginstrumente auszuwählen. Leitungsgremium: Ulrike Baumöl, FernUniversität in Hagen Walter Brenner, Universität St. Gallen (Federführender) Günter Haring, Universität Wien Programmkomitee: Stefan Eicker, Universität Duisburg-Essen Norbert Hoffmann, Swiss Life Reinhard Jung, Universität Duisburg-Essen Michael Klaas, Universität St. Gallen Lutz Kolbe, Georg-August-Universität Göttingen Helmut Krcmar, Technische Universität München Thomas Myrach, Universität Bern Jochen Scheeg, T-Systems Enterprise Services Stefan Strecker, Universität Duisburg-Essen, Campus Essen Rüdiger Zarnekow, Technische Universität Berlin PRODUKTIONSPLANUNG UND -STEUERUNG DER IT-SERVICE-PROVISIONIERUNG Nico Ebert, Alexander Vogedes, Falk Uebernickel1 Kurzfassung Aufgrund von steigendem Kostendruck und zunehmender Kundenorientierung haben ITDienstleister ihre Dienstleistungen standardisiert. Derzeit fehlen jedoch Lösungsansätze, um komplexe Dienstleistungen, an deren Produktion viele Bereiche beteiligt sind, effizient und mit gleichbleibender Qualität bereitzustellen. Im Beitrag wird untersucht, welches die Voraussetzungen für die Verwendung von Konzepten der Produktionsplanung und -steuerung für die Provisionierung von standardisierten IT-Services sind. Ausgehend von der Ableitung der Anforderungen aus der Literatur und aus zwei Praxisprojekten bei IT-Dienstleistern erfolgt die Vorstellung eines Grobkonzepts zur Produktionsplanung und -steuerung. 1. Einleitung Die Anforderungen an unternehmensinterne und externe IT-Dienstleister unterliegen einem Wandel: steigende Kunden- und Dienstleistungsorientierung führen bei IT-Organisationen zur Professionalisierung und zur Anwendung etablierter Konzepte aus der Industrie [7]. Diese „Industrialisierung“ betrifft insbesondere die IT-Produktion, die den Betrieb, die Instandhaltung und den Support von IT-Systemen gewährleistet [12, 8]. Der Anteil der Kosten der IT-Produktion an den IT-Budgets von Unternehmen ist in der Praxis bedeutend. Er wird – zusammen mit den Kosten für die Weiterentwicklung der Produktion – auf über 80% geschätzt. Experten gehen davon aus, dass ein Großteil der damit verbundenen Kapazitäten nur unzureichend genutzt wird [35, 33]. Parallel zum Kostendruck erhöht sich die Komplexität innerhalb der Produktion, da Kunden zunehmend integrierte Leistungsbündel zur Unterstützung von Kundenprozessen anstelle systemnaher Leistungen wie Server-Betrieb oder PC-Betreuung nachfragen [1, 2]. Dies setzt die übergreifende Koordination verschiedener Bereiche wie ServerManagement, Speicher-Management oder Netz-Management voraus [14,5]. Kostendruck und veränderte Kundennachfrage haben in den vergangenen Jahren zu einem Umdenken bei IT-Dienstleistern geführt. Anstelle von kundenindividuellen Projektleistungen, werden standardisierte und kundenindividuell kombinierte Bündel aus einzelnen IT-Services zur Geschäftsprozessunterstützung, so genannte IT-Produkte, angeboten [33]. Zwar haben mittlerweile 1 Universität St. Gallen, Switzerland 505 viele IT-Dienstleister ihr Leistungsportfolio standardisiert und über Servicekataloge beschrieben [7], allerdings wurde die effiziente und effektive Provisionierung der IT-Services wenig betrachtet. Dies wird am in der Praxis weit verbreiteten Referenzmodell ITIL deutlich, das keinen Ansatz für die bereichsübergreifende Planung und Steuerung der Provisionierung beinhaltet [24]. Auch in wissenschaftlichen Ansätzen im Bereich des IT-Managements liegt der Schwerpunkt bisher primär auf der kapazitativen Dimensionierung von IT-Systemen [22,4]. Die Planung und Steuerung der Provisionierung mit betriebswirtschaftlichen Methoden wird nach Kenntnisstand der Autoren ausschließlich in einem Ansatz [34] betrachtet, der jedoch nicht die Konzeption der erforderlichen Systemunterstützung umfasst. In diesem Beitrag wird als ein möglicher Lösungsansatz für die geschilderten Herausforderungen ein Konzept zur Planung und Steuerung der IT-Service-Provisionierung vorgestellt, das sich an die industrielle Produktionsplanung und -steuerung (PPS) anlehnt. Zunächst erfolgt ein Überblick über das gewählte Forschungsvorgehen, bevor im Anschluss eine genauere Betrachtung der Merkmale der Provisionierung erfolgt. Schließlich wird ein Grobkonzept für die PPS der Provisionierung präsentiert. Abschließend erfolgen eine Zusammenfassung sowie ein Ausblick auf weitere Forschungsarbeiten. 2. Forschungsvorgehen Der vorgestellte Beitrag stützt sich auf zwei Forschungsprojekte, die zusammen mit der Deutschen Beta Services GmbH2 und der Schweizer Swisscom IT Services AG seit April 2007 durchgeführt wurden. Sie hatten die Analyse von Einsatzpotenzialen der PPS in der Provisionierung von standardisierten IT-Services und die Umsetzung eines ERP-Systems für IT-Dienstleister zum Ziel. Zwischen April 2007 und November 2007 erfolgte im ersten Projekt zunächst die Anforderungsaufnahme im PC-Dienstleistungsgeschäft (Desktop Services) bei der Swisscom IT Services AG. Parallel dazu wurde im August 2007 im zweiten Projekt mit der Anforderungsaufnahme in den Produktionsbereichen Rechnenzentrumsbetrieb, SAP-Systembetrieb, WAN-Management, LANManagement und PC-Dienstleistungen der Beta Services GmbH begonnen. Derzeit erfolgt die Umsetzung eines Detailkonzepts bei Beta Services in einem SAP R/3-Prototyp, die voraussichtlich Ende des Jahres 2008 abgeschlossen wird, und im Anschluss die Beurteilung des Prototyps durch die Produktionsbereiche. In beiden Projekten wurde die Aufnahme der Anforderungen zusammen mit Experten und unter Berücksichtigung von bestehenden Unterlagen (zum Beispiel Produktkatalog und Prozessbeschreibungen) aus den jeweiligen Bereichen durchgeführt. 3. Produktionsplanung und -steuerung der IT-Service-Provisionierung In der Realgüterproduktion hat die Produktionsplanung und -steuerung (PPS) die Aufgabe „aufgrund erwarteter und/oder vorliegender Kundenaufträge den mengenmäßigen und zeitlichen Produktionsablauf unter Beachtung der verfügbaren Ressourcen durch Planvorgaben festzulegen, diese zu veranlassen sowie zu überwachen und bei Abweichungen Maßnahmen zu ergreifen, so dass bestimmte betriebliche Ziele erreicht werden.“ [32]. Die Aufgaben der PPS stellt Abbildung 1 dar. Für die Unterstützung der PPS haben sich seit den 60er Jahren computergestützte Produktionsplanungs- und -steuerungssysteme (PPS-Systeme) etabliert [19]. Trotz der Weiterentwicklungen der PPS-Systeme zu Enterprise Resource Planning (ERP)-Systemen sind deren Kernaufgaben heute nach wie vor identisch [23]. Als zentrale Voraussetzung für die Verwendung von PPS-Systemen nicht nur im Bereich der Realgüterproduktion, sondern auch für Erstellung von Dienstleistungen, 2 Name wurde verfälscht. 506 wird die Standardisierung der Leistungen genannt [10,11, 27, 30]. Da es sich bei den hier betrachteten IT-Services nicht um kundenindividuelle sondern standardisierte Leistungen handelt, kann die Voraussetzung als erfüllt betrachtet werden. Teilbereiche der PPS Hauptaufgaben Produktionsprogrammplanung Produktionsplanung Mengenplanung Termin- und Kapazitätsplanung Produktionssteuerung Auftragsveranlassung Auftragsüberwachung Abbildung 1 – Aufgaben der PPS [15] Nachfolgend wird zunächst die IT-Service-Provisionierung aus produktionswirtschaftlicher Sicht betrachtet, bevor dann die Anforderungen an die PPS und daraus abgeleitete Erweiterungen zum ursprünglichen PPS-Ansatz vorgestellt werden. 3.1. Grundlagen der IT-Service-Provisionierung In einem Produktionssystem werden Produktionsfaktoren (Input) in einer Faktorkombination (Throughput) zu Leistungen (Output) kombiniert [32]. Analog zur Realgüterproduktion kann auch die Erstellung von Dienstleistungen als ein Produktionssystem verstanden werden [9,13,21], wobei Dienstleistung als der Output der Kombination von Produktionsfaktoren verstanden werden kann [13]. Im Unterschied zur Realgüterproduktion ist jedoch in den Erstellungsprozess der Dienstleistung ein externer Faktor integriert [13]. Bei externen Faktoren handelt es sich im Gegensatz zu internen Inputfaktoren „um Personen oder Objekte, die innerhalb der Faktorkombination in zeitlicher, artmäßiger, mengenmäßiger und örtlicher Hinsicht nicht der Dispositionsgewalt des Dienstleisters unterliegen, sondern durch den Kunde der Dienstleistung festgelegt werden.“ [21]. In der IT-Service-Provisionierung werden Produktionsfaktoren wie Server, Arbeitsplatzsysteme, Softwarelizenzen, Netze und menschliche Arbeitsleistung innerhalb von Prozessen zu IT-Systemen kombiniert, welche die Geschäftsprozesse eines Kunden unterstützen. Neben internen Produktionsfaktoren sind externe Faktoren in die Provisionierung integriert. Dies können sowohl der Kunde der Dienstleistung selbst (zum Beispiel der Benutzer), als auch IT-Systemkomponenten, Daten, Softwarelizenzen oder Gebäude des Kunden sein [3]. Da IT-Systeme in der Regel über einen längerfristigen Zeitraum betrieben werden, schließen Kunde und Dienstleister Rahmenverträge, die Leistungsbeschreibungen und Qualitätsvereinbarungen enthalten [31]. Die Erbringung von standardisierten IT-Services kann in die Phasen Entwicklung, Beauftragung, Provisionierung, Betrieb, Veränderung und Deinstallation eingeteilt werden [15]. Ausgehend davon können sowohl Provisionierungs- als auch Deinstallationsprozesse unterschieden werden: • Provisionierung: Die Provisionierungsprozesse dienen der Bereitstellung eines IT-Service für den nachfolgenden Betrieb. Die Bereitstellung umfasst zum Beispiel den Erwerb und die Bereitstellung von IT-Systemkomponenten, das Einrichten von Benutzerkonten, die Bereitstellung von Lizenzen und die Auslieferung von Systemkomponenten an den Kundenstandort (zum Beispiel PC). Die Provisionierungsprozesse können sowohl bei der initialen Be- 507 reitstellung eines IT-Service als auch bei der Veränderung eines IT-Services ausgeführt werden. • Deinstallation: Die Prozesse zur Deinstallation dienen der Außerbetriebnahme von ITServices. Die Außerbetriebnahme umfasst zum Beispiel den Abbau von ITSystemkomponenten und die Übergabe von kundeneigenen Daten an den Kunden. Deinstallierte IT-Systemkomponenten können zum Teil – analog zu Recyclinggütern – wiedereingesetzt werden. Als besondere Eigenschaft verfügt die IT-Produktion über einen IT-Systembestand, der in der Provisionierung und Deinstallation manipuliert wird. Der Systembestand beinhaltet diejenigen ITSystemkomponenten, die durch den IT-Dienstleister für seine Kunden betrieben und instandgehalten werden. Provisionierung und Deinstallation können sowohl zu einem Zugang zum als auch zu einem Abgang vom IT-Systembestand führen. In der Praxis wird der Systembestand mit Hilfe einer Configuration Management Database (CMDB) abgebildet [24]. 3.2. Anforderungen an die PPS der IT-Service-Provisionierung Zur Ableitung der Anforderungen an die PPS ist zunächst eine grobe Charakterisierung der Merkmale der IT-Service-Provisionierung erforderlich. Diejenigen Merkmale, die unspezifisch für die IT-Service-Provisionierung sind, können bestehenden Typologien der Realgüterproduktion entnommen werden. Die Typologien ermöglichen die grobe Analyse von Auftragsabwicklungsprozessen anhand von Merkmalen und erlauben die Ableitung von Anforderungen an die PPS. Eine grundlegende Arbeit dazu stellt die Typologie von Schomburg dar, zu der mittlerweile einige Erweiterungen existieren [20,25]. Im Folgenden sollen lediglich jene Merkmale von Schomburg betrachtet werden, die für die Bestimmung des Fertigungstyps erforderlich sind. Dies sind die Merkmale Erzeugnisspektrum und Auftragsauslösungsart [16]. Neben den unspezifischen Merkmalen, werden im Folgenden ebenfalls Merkmale betrachtet, die spezifisch für die Provisionierung von ITServices sind. Erzeugnisspektrum: Die Individualität der Erzeugnisse wird durch das Merkmal Erzeugnisspektrum erfasst [28]. Es reicht von Erzeugnissen nach Kundenspezifikation bis hin zu Standarderzeugnissen ohne Varianten. Da IT-Services nicht nach Kundenspezifikation erstellt werden, können sie als kundenspezifisch angepasste Leistungen (typisierte Erzeugnisse mit kundenspezifischen Varianten) und als Standardleistungen mit und ohne Varianten aufgefasst werden. Auftragsauslösungsart: Das Merkmal Auftragsauslösungsart kennzeichnet die Art der Auslösung des Primärbedarfs [28]. Es lassen sich die beiden Extremformen Produktion auf Lager und Produktion auf Bestellung mit Einzelaufträgen unterscheiden. Während bei der Produktion auf Lager Erzeugnisse für einen anonymen Markt ohne Vorliegen eines Kundenauftrags gefertigt werden, erfolgt im zweiten Fall die Produktion ausschließlich aufgrund konkreter Kundenaufträge [19]. Da grundsätzlich ein Auftrag die Erbringung der Dienstleistung auslöst, wird der Primärbedarf bei der IT-Service-Provisionierung erst durch den konkreten Kundenauftrag aufgelöst. Eine teilweise Provisionierung von Servicekomponenten ist jedoch möglich, sofern diese erwartungsorientiert disponiert werden können. Aus den beiden Merkmalsausprägungen ergeben sich Auswirkungen auf die Produktionsprogrammplanung der IT-Service-Provisionierung. Bedingt durch die Produktion auf Bestellung ist eine häufige Anpassung des Programms an den aktuellen Auftragsbestand erforderlich [16]. Mittelfristig ist in der Produktionsprogrammplanung häufig nur eine Absatzprognose bezogen auf Produktgruppen bzw. -arten möglich, da die genauen Varianten im Vorfeld nicht bekannt sind [16,19]. Ein PPS508 System muss bei Produktion auf Bestellung zu jedem Zeitpunkt genaue Informationen zu einem Kundenauftrag bzw. abgeleiteten Fertigungsaufträgen liefern können, um zum Beispiel bei Störungen die betroffenen Kundenaufträge zu identifizieren [19]. Erweiterte Abhängigkeiten zwischen IT-Servicekomponenten: IT-Services werden in der Regel als Bündel von IT-Servicekomponenten vertrieben. Neben diesen Vertriebsabhängigkeiten existieren erweiterte Abhängigkeiten zwischen Komponenten innerhalb der Provisionierungsprozesse. Zum Beispiel kann mit dem Kunden neben der einmaligen Bereitstellung eines Service zur Datenverarbeitung eine regelmäßige Sicherung der Kundendaten vereinbart werden. Bestehende Abhängigkeiten müssen einerseits innerhalb der Planung und Steuerung berücksichtigt werden. Zum anderen müssen diese Abhängigkeiten innerhalb eines PPS-Systems geeignet abgebildet werden. IT-Systembestand: In der IT-Service-Provisionierung existiert ein IT-Systembestand, der solche Produktionsfaktoren enthält, die zur Erstellung von IT-Services erforderlich sind [18]. Er umfasst zum Beispiel genutzte Softwarelizenzen, verwendete Arbeitsplatzsysteme oder bestehende Dienstleistungsverhältnisse. In der Produktionsplanung und -steuerung müssen Mengenflüsse des ITSystembestands berücksichtigt werden. Es sind nicht nur Zugänge in den IT-Systembestand möglich, sondern auch – analog zu externen Lieferungen – Abgänge aus dem IT-Systembestand in den Lagerbestand, da nicht mehr von einem IT-Service genutzte Produktionsfaktoren prinzipiell wiedereingesetzt werden können. Eine Systemunterstützung der PPS muss zunächst den ITSystembestand in geeigneten Datenstrukturen abbilden, um zum Beispiel zur Störungsbehebung Informationen über den Status der Produktionsfaktoren zu erhalten. Ferner sind Methoden und Datenstrukturen erforderlich, um die Mengenflüsse des IT-Systembestands in der Planung und Steuerung zu berücksichtigten. Integration des externen Faktors: Durch die Einbindung des Kunden in die IT-ServiceProvisionierung respektive seiner Daten, IT-Systeme etc. erhöht sich die Unsicherheit in der Planung und Steuerung für den IT-Dienstleister. Zum Beispiel können unbekannte Systeme beim Kunden oder fehlende Kundeninformationen zu Verzögerungen in der Bereitstellung eines ITService führen. Die Unsicherheit kann in der Planung und Steuerung durch Erfahrungswerte reduziert werden. Ein PPS-System sollte neben den externen Faktoren selbst auch Erfahrungswerte zu deren Disposition berücksichtigen und über geeignete Datenstrukturen verfügen. 3.3. Produktionsplanung und -steuerung Ausgehend von den Teilaufgaben der PPS und den im vorherigen Abschnitt vorgestellten Anforderungen wird in diesem Abschnitt ein Grobkonzept für die PPS der IT-Service-Provisionierung vorgestellt. Dabei liegt der Schwerpunkt auf den erforderlichen Anpassungen und Erweiterungen der Produktionsprogrammplanung und Mengenplanung sowie der dazu erforderlichen Grunddaten, da sich dort die größten Unterschiede zur industriellen PPS ergeben. 3.3.1. Erweiterung der Grunddaten Die wichtigsten Grunddaten der PPS sind Daten über Teile, Erzeugnisstrukturen, Arbeitsgänge, Arbeitspläne, Betriebsmittel-/Arbeitsplätze und Fertigungsstrukturen [19]. Da der Schwerpunkt in diesem Beitrag auf der Produktionsprogramm- und Mengenplanung liegt, werden im Folgenden nur die Teil- und Erzeugnisstrukturdaten betrachtet. Da in der IT-Service-Provisionierung zusätzlich zu Realgütern wie Server oder PCs auch immaterielle Güter wie Lizenzen oder Dienstleistungen genutzt werden können, kann der Teilestamm auch immaterielle Güter enthalten. Ist ein IT-Service relevant für den IT-Systembestand (als Zugang 509 oder Abgang) muss für ein Teil ein zusätzliches Attribute „bestandsrelevant“ gepflegt werden. Dieses erlaubt Aussagen über die Veränderung des IT-Systembestands durch die Provisionierung eines IT-Service. Aufgrund der Integration des externen Faktors in die IT-Service-Provisionierung ist es zweckmäßig neben den üblichen Teiletypen Eigenteil und Fremdteil [26] auch einen Typ Kundenteil zu definieren, der externe Faktoren spezifiziert. Ein Kundenteil besitzt die Dispositionsart „Disposition durch Kunde“, da es der Dispositionsgewalt des Kunden unterliegt. Für ein Kundenteil kann analog zu Fremdteilen das Attribut Prozesszeit definiert werden, welches erfahrungsbasierte oder mit dem Kunden vereinbarte Angaben zur Dauer von gemeinschaftlich erbrachten Prozessen enthält. Durch diese zusätzlichen Informationen wird eine Reduzierung der Unsicherheit innerhalb der Planung und Steuerung ermöglicht. Die Erzeugnisstruktur eines IT-Service kann – wie Dienstleistungen im allgemeinen – als Stückliste abgebildet werden [6], allerdings ist analog zur Realgüterproduktion die Abhängigkeit zwischen Bedarfen für Servicekomponenten erforderlich [30]. Zum Zweck des Vertriebs können die ITServices mit Hilfe von Vertriebsstücklisten abgebildet werden, die lediglich das Mengengerüst der Servicekomponenten allerdings keine Abhängigkeiten in der Provisionierung beinhalten [26]. Dies ermöglicht es, Leistungsbündel zu bilden. Innerhalb der Provisionierung sind unterschiedliche Arten von Erzeugnisstrukturen für IT-Services notwendig, um sowohl den Zugang zum IT-Systembestand als auch den Abgang vom ITSystembestand geeignet abzubilden. Während die Erzeugnisstrukturen für einen IT-Service mit Bestandszugang weitestgehend denen der Realgüterproduktion entsprechen, ist in Erzeugnisstrukturen von Services mit Bestandsabgang eine Kennzeichnung der Abgänge erforderlich. Dieser Sachverhalt kann analog zu Recyclingerzeugnissen, welche zerlegt und wiederverwendet werden, durch negative Bedarfsvorzeichen gekennzeichnet werden [29]. Zusätzlich zur Berücksichtigung der Zu- und Abgänge des Systembestands, ist eine Abbildung der erweiterten Abhängigkeiten innerhalb der Erzeugnisstrukturen notwendig. Zu diesem Zweck ist eine Erweiterung der ursprünglichen Beziehung zwischen Elementen der Erzeugnisstruktur erforderlich. Abbildung 2 zeigt drei einfache Beispiele für die unterschiedlichen Erzeugnisstrukturtypen. Negative Mengenkoeffizienten beim Bestandsabgang sind durch die umgekehrte Pfeilrichtung verdeutlicht. IT-Service mit Bestandzugang IT-Service mit Bestandsabgang IT-Service mit erweiterter Abhängigkeit E-Mail-Konto bereitstellen E-Mail-Konto entfernen E-Mail-Konto bereitstellen X Y X +1 +1 +1 a b a Mailbox Benutzerlizenz Mailbox +1 +1 +1 c b Benutzerlizenz archivierte E-Mails +1 a Mailbox b Benutzerlizenz d Datensicherung Abbildung 2 – Beispiele für unterschiedliche Erzeugnisstrukturen in der Provisionierung 3.3.2. Erweiterung der Produktionsprogrammplanung 510 In der industriellen PPS werden in der Produktionsprogrammplanung die zu produzierenden Erzeugnisse auf Basis von Absatzprognosen und Kundenaufträgen nach Art, Menge und Termin festgelegt [32]. Obwohl bei Produktion auf Bestellung individuelle Kundenaufträge die primäre Quelle für das Programm sind, ist eine auftragsanonyme Grobplanung dennoch sinnvoll, sofern sich die Erzeugnisse, zum Beispiel aufgrund der Standardisierung, auf einer höheren Betrachtungsebene etwa der Produktgruppe weniger stark unterscheiden [32]. Die Grobplanung setzt die Rahmenbedingungen für die zukünftige Produktionsdurchführung und bildet unter anderem die Grundlage für die Beschaffungsplanung, Investitionsplanung und die Fertigungsplanung von denjenigen Komponenten, die erwartungsorientiert disponiert werden können [19]. In der PPS der IT-Service-Provisionierung ist aufgrund der Standardisierung der Erzeugnisse ebenfalls die auftragsanonyme Grobplanung auf Servicegruppen oder -arten möglich. Neben Absatzprognosen können in der Grobplanung vorliegende Rahmenaufträge berücksichtigt werden. Die Ermittlung des Bedarfs an erwartungsorientiert disponierten Komponenten unterscheidet allerdings von der Brutto-/Nettorechnung des ursprünglichen PPS-Ansatzes. Im Unterschied zum ursprünglichen Vorgehen, bei dem ein einfacher Brutto-/Nettoabgleich mit dem Lagerbestand erfolgt [32], ist in der PPS der Service-Provisionierung eine zweistufige Bedarfsermittlung erforderlich, da potenzielle Zu- und Abgänge in bzw. aus dem IT-Systembestand berücksichtigt werden müssen. In einem ersten Schritt erfolgt daher eine Brutto-/Nettorechnung bezogen auf die Zu- und Abgänge des Systembestands. Das Ergebnis des Schritts bildet schließlich den Bruttobedarf für den zweiten Schritt der Bedarfsermittlung, indem der Bruttobedarf mit dem Lagerbestand abgeglichen wird. Das Ergebnis der Bedarfsermittlung ist der noch zu produzierende bzw. zu beschaffende Nettobedarf an Servicekomponenten. Der weitere Prozess der Produktionsprogrammplanung in der PPS besteht aus der Kundenanfrage, Angebotsbearbeitung sowie Auftragserteilung [19]. 3.3.3. Erweiterung der Mengenplanung Nach der Produktionsprogrammplanung liegt in der industriellen PPS ein Programm vor, welches sich aus Kundenauftragsbedarfen und Bedarfen von erwartungsorientiert disponierten Komponenten zusammensetzt. Die Aufgabe der Mengenplanung besteht in der Bestimmung der Fertigungs-/ bzw. Bestellaufträge für alle Komponenten nach Art und Zeit unter Beachtung des Programms, so dass eine wirtschaftliche Produktion ermöglicht wird [19, 32]. Bei der kundenauftragsorientierten Disposition erfolgt zunächst ein Brutto-/Nettoabgleich unter Berücksichtigung der Lagerbestände, die Losbildung und schließlich die Vorlaufverschiebung. Das Ergebnis der Mengenplanung sind die Fertigungs- bzw. Beschaffungsaufträge, die Mengen je Perioden je Komponente enthalten [32]. In der IT-Service-Provisionierung kann sowohl die erwartungs- als auch die kundenauftragsbezogene Disposition erforderlich sein (siehe Abbildung 3). Zum Beispiel erfolgt die Disposition einer kundenspezifisch konfigurierten Mailbox kundenauftragsbezogen, da erst zum Zeitpunkt des Auftragseingangs die exakte Konfiguration bekannt ist. Der dazu erforderliche Speicherplatz kann hingegen erwartungsbezogen disponiert werden, um eine kurzfristige Bereitstellung der Mailbox zu ermöglichen. Im Gegensatz zur Mengenplanung im ursprünglichen PPS-Ansatz müssen einige Besonderheiten berücksichtigt werden. Bevor die Ermittlung der Sekundärbedarfe erfolgen kann, ist innerhalb der Stücklistenauflösung auch die Auflösung der erweiterten Abhängigkeiten zwischen ITServicekomponenten erforderlich. Beispielsweise können bei der Bereitstellung eines E-MailKontos die Bedarfe für die tägliche Datensicherung ermittelt und eingeplant werden. Analog zum 511 Vorgehen in der Grobplanung ist auch in der Brutto-/Nettorechnung die Berücksichtigung von Zugängen in den Lagerbestand notwendig, die aus dem IT-Systembestand resultieren. Deshalb ist zunächst eine systembestands- und danach eine lagerbestandsbezogene Brutto-/Nettorechnung erforderlich. E-Mail-Konto bereitstellen X +1 Mailbox a +1 b OS- Lizenz auftragsbezogene Disposition +1 Speicherplatz erwartungsbezogene Disposition e Abbildung 3 – Beispiele für unterschiedliche Dispositionsarten Zusätzliche Besonderheiten ergeben sich bei der zeitlichen Sekundärbedarfsverschiebung. Aus der Integration von externen Faktoren in Form von Kundenteilen in die Prozesse resultieren Unsicherheiten für die Dauer der Prozessausführung. Zur Reduzierung der Unsicherheit kann der Rückgriff auf die Erfahrungswerte und Vereinbarungen erfolgen, die an den Teilestammdaten hinterlegt werden. Eine weitere Besonderheit ergibt für die Art der zeitlichen Verschiebung. In der industriellen PPS wird lediglich der erforderliche zeitliche Vorlauf für die Produktion oder Beschaffung von Bedarfen berücksichtigt und die Sekundärbedarfe in vorgelagerte Perioden verschoben [32]. In der IT-Service-Provisionierung müssen ebenso Dauern für Deinstallationsprozesse mit Abgängen aus dem Systembestand berücksichtigt werden, zum Beispiel für den Abbau von ITSystemkomponenten. Dies kann durch die zeitliche Verschiebung entsprechender Zugänge in nachfolgende Perioden gewährleistet werden. In Analogie zur Vorlaufverschiebung kann dieses Vorgehen als Rücklaufverschiebung bezeichnet werden. 4. Zusammenfassung und Ausblick Im vorliegenden Beitrag wurde ein erster Lösungsansatz für die Produktionsplanung und steuerung der IT-Service-Provisionierung vorgestellt. Für diesen Zweck wird die Verwendung und Erweiterung bestehender PPS-Konzepte vorgeschlagen, da die Provisionierung von standardisierten IT-Services große Ähnlichkeiten zur Realgüterproduktion aufweist. Durch die Verwendung von PPS soll eine Verbesserung der Planungs- und Dienstleistungsqualität sowie der Auslastung der Ressourcen erreicht werden. Wie der Beitrag aufgezeigt hat, sind einige spezifische Erweiterungen der Grunddaten und der Aufgaben der PPS erforderlich. Dies betrifft insbesondere die Berücksichtigung des ITSystembestands. Die Erweiterungen beschränken sich jedoch auf einen Umfang, der die Verwendung von PPS- bzw. ERP-Systemen als Ausgangspunkt für die Systemunterstützung der ITService-Provisionierung sinnvoll erscheinen lässt. Zum Zweck der Implementierung erfolgt daher eine Konkretisierung des vorgestellten Grobkonzepts vor dem Hintergrund der tatsächlichen Umsetzung in einem ERP-System. Die Umsetzung 512 und Erprobung des beschriebenen Ansatzes erfolgt derzeit im Rahmen eines Prototyp-Projekts bei der Beta Services GmbH. Aufgrund seiner weiten Verbreitung im europäischen Raum wurde SAP R/3 als Referenzsystem für die Implementierung gewählt. 5. Literaturverzeichnis [1] BERTLEFF, C., Einführung einer IT-Leistungsverrechnung zur Unterstützung des strategischen IT-Controllings, in: H. Heilmann (Hrsg.), Strategisches IT-Controlling, d.punkt verlag, Heidelberg 2001. [2] BÖHMANN, T., GOTTWALD, R., KRCMAR, H., Towards mass-customized IT services: Assessing a method for identifying reusable service modules and its implication for IT service management, in: Proceedings of the Americas Conference on Information Systems (AMCIS), Nebraska 2005. [3] BÖHMANN, T., Modularisierung von IT-Dienstleistungen, Deutscher Universitätsverlag, Wiesbaden 2004. [4] BRANDL, R., BICHLER, M., STRÖBEL, M., Cost Accounting for Shared IT Infrastructures - Estimating Resource Utilization in Distributed IT Architectures, in: Wirtschaftsinformatik. Bd. 2 (2007). [5] BRITZELMAIER, B., Eine Grundrechnung als Basis für einen Profit-Center-Ansatz in der Informationsverarbeitung, in: J. Herget (Hrsg.), Informationscontrolling, Univ. Verl. Konstanz, Konstanz 1995. [6] BULLINGER; H.-J., FÄHNRICH, K.-P., MEIREN, T., Service engineering - methodical development of new service products, in: International Journal Of Production Economics. Bd. 3 (2003). [7] CAPGEMINI, Studie IT-Trends 2007, CapGemini, Berlin 2007. [8] CAPGEMINI, Studie IT-Trends 2008, CapGemini, Berlin 2008. [9] CORSTEN, H., GÖSSINGER, R., Dienstleistungsmanagement. 5. Auflage, Oldenbourg, München 2007. [10] COX, J.F., JESSE, R.R., Application of Material Requirements Planning to Higher Education, in: Decision Sciences. Bd. 2 (1981). [11] DIETRICH, B., Resource planning for business services, in: Communications of the ACM. Bd. 7 (2006). [12] EITO, European Information Technology Observatory 2006, European Information Technology Observatory European Economic Interest Grouping, Frankfurt 2006. [13] FANDEL, G., BLAGA, S., Aktivitätsanalytische Überlegungen zu einer Theorie der Dienstleistungsproduktion, in: Zeitschrift für Betriebswirtschaft Ergänzungsheft. Bd. 1 (2004). [14] FÜRER, P.J., Prozesse und EDV-Kostenverrechnung, Paul Haupt, Bern 1994. [15] GARSCHHAMMER, M., et al., The MNM Service Model - Refined Views on Generic Service Management, in: Journal of Communications and Networks. Bd. 4 (2001). [16] GLASER, H., GEIGER, W., ROHDE, V., PPS - Produktionsplanung und -steuerung. Grundlagen - Konzept Anwendungen. 2. Auflage, Gabler, Wiesbaden 1992. [17] HACKSTEIN, R., Produktionsplanung und -steuerung (PPS). Ein Handbuch für die Betriebspraxis. 2. Auflage, VDI Verlag, Düsseldorf 1989. [18] HEINRICH, L.J., LEHNER, F., Informationsmanagement, Oldenbourg, München 2005. [19] KURBEL, K., Produktionsplanung und -steuerung im Enterprise Resource Planning und Supply Chain Management. 6. Auflage, Oldenbourg, München 2005. [20] LOOS, P., Produktionslogistik in der chemischen Industrie, Gabler, Wiesbaden 1997. 513 [21] MALERI, R., Grundlagen der Dienstleistungsproduktion. 4. Auflage, Springer, Berlin 1997. [22] MENASCE, D.A., ALMEIDA, V.A.F., DOWDY, L.W., Capacity Planning and Performance Modeling - From Mainframes to Client-Server Systems. Prentice Hall, Englewood Cliffs 1994. [23] MERTENS, P., Integrierte Informationsverarbeitung 1: Operative Systeme in der Industrie. 14. Auflage, Gabler, Wiesbaden 2004. [24] OGC, ITIL - Service Operation, TSO, London 2007. [25] SAMES, G., BÜNDENBENDER, W., Aachener PPS-Modell, Das morphologische Merkmalsschema. 6. Auflage Sonderdruck, Forschungsinstitut für Rationalisierung, Aachen 1997. [26] SCHEER, A.W., Wirtschaftsinformatik: Referenzmodelle für industrielle Geschäftsprozesse, Springer, Berlin 1997. [27] SCHLÜCHTERMANN, J., SIBBEL, R., Produktionsplanung und -steuerung (PPS) für Dienstleistungsunternehmen, in: H. Corsten und H. Schneider (Hrsg.), Wettbewerbsfaktor Dienstleistung, Vahlen, München 1999. [28] SCHOMBURG, E., Entwicklung eines betriebstypologischen Instrumentariums zur systematischen Ermittlung der Anforderungen an EDV-gestützte Produktionsplanungs- und -steuerungssysteme im Maschinenbau, RWTH Aachen, Aachen 1980. [29] SCHULTMANN, F., FROEHLING, M., RENTZ, O., Demontageplanung und -steuerung mit EnterpriseResource–und Advanced-Planning-Systemen, in: Wirtschaftsinformatik. Bd. 5 (2002). [30] SNYDER, C.A., COX, J.F., JESSE, R.R., A Dependent Demand Approach to Service Organization Planning and Control, in: Academy Of Management Review. Bd. 3 (1982). [31] SÖBBING, T., (Hrsg.), Handbuch IT- Outsourcing. Recht, Strategie, Prozesse, IT, Steuern, samt Business Process Outsourcing. 3. Auflage, C. F. Müller, Heidelberg 2006. [32] ZÄPFEL, G., Grundzüge des Produktions- und Logistikmanagement, de Gruyter, Berlin/New York 1996. [33] ZARNEKOW, R., BRENNER, W., PILGRAM, U., Integriertes Informationsmanagement, Springer, Berlin 2005. [34] ZARNEKOW, R., Produktionsmanagement von IT-Dienstleistungen. Grundlagen, Aufgaben und Prozesse, Springer, Berlin 2007. [35] ZARNEKOW, R., SCHEEG, J., BRENNER, W., Untersuchung der Lebenszykluskosten von IT-Anwendungen, in: Wirtschaftsinformatik. Bd. 3 (2004). 514 CONTROLLING IM WISSENSMANAGEMENT – KONZEPTION EINES ALLGEMEINEN ANSATZES ZUR ERFOLGSBEWERTUNG IM WISSENSMANAGEMENT Franz Lehner, Nadine Amende, Stephan Wildner, Nicolas Haas1 Kurzfassung Es ist allgemein akzeptiert, dass Wissensversorgung und interne Wissensweitergabe unverzichtbare Erfolgsfaktoren für Unternehmen im Wettbewerb sind. Offen ist allerdings wie man den diesbezüglichen Status eines Unternehmens messen oder diagnostizieren kann, um daraus konkrete und wirksame Maßnahmen für die Verbesserung des Wissensmanagements abzuleiten. Da es bisher keine methodisch zufrieden stellende Unterstützung dafür gibt, ist das Ziel des Beitrags eine Bestandsaufnahme und kritische Reflexion der bisherigen Ansätze zur Erfolgsmessung im Wissensmanagement sowie ein Beitrag für die Entwicklung einer konzeptionellen Grundlage. 1. Einführung und Motivation Wissensmanagement wird als bewusstes und systematisches Bestreben verstanden, in Organisationen ein Umfeld zu schaffen, das die Akquise, Schaffung, Aufbereitung, Verteilung, Anwendung und Bewahrung von Wissen unterstützt. Dadurch wird zum Lernen in Organisationen beigetragen, was wiederum die bestmögliche Anpassung einer Organisation an ihre Umwelt ermöglicht. Beim Versuch, einen Erfolgsnachweis von Wissensmanagementaktivitäten zu führen, stößt man aber auf erhebliche Schwierigkeiten, denn die Wirkungen des Wissensmanagements sind meist nicht explizit und nicht direkt messbar. Bei diesem Problem setzt der vorliegende Beitrag an, denn soweit es bisher überhaupt eine methodische Unterstützung gibt entspricht diese entweder nicht dem tatsächlichen Bedarf oder sie ist mit einem unangemessen hohen Aufwand verbunden. Ziel des Beitrags ist es, zunächst einen Überblick über die bisherigen Ansätze zur Erfolgsmessung im Wissensmanagement zu geben und darauf aufbauend die existierenden Instrumente zur Erfolgsmessung einer Analyse zu unterziehen. Den Abschluss bildet ein generisches Vorgehen für die Messung des Erfolgs im Wissensmanagement, sodass eine konzeptuelle Grundlage für die Erfolgsmessung geschaffen wird. 2. Grundorientierungen bei der Erfolgsmessung im Wissensmanagement Erfolg wird im traditionellen Verständnis in der Betriebswirtschaftslehre mit Unternehmenserfolg in Verbindung gebracht und als Nettogröße zwischen Ertrag und Aufwand verstanden. Positive 1 Universität Passau, Lehrstuhl für Wirtschaftsinformatik II, Innstraße 43, 94032 Passau. 515 Größen werden als Gewinn beschrieben, negative als Verlust. Dennoch unterliegt die Messung des Erfolgs eines Unternehmens unterschiedlichen Messansätzen, die hinsichtlich ihrer Eignung kontrovers diskutiert werden. Insbesondere die Auswahl der Kriterien zur Erfolgsmessung und die Beurteilungsfähigkeit dieser durch die Unternehmen ist umstritten [18]. Diese Kontroverse beruht darauf, dass Unternehmen neben der Gewinnmaximierung weitere nicht-monetäre Ziele anstreben, beispielsweise eine hohe Qualität oder eine langfristige Sicherstellung der Wettbewerbsfähigkeit. Die betriebswirtschaftliche Forschung erweiterte daher das enge Erfolgsverständnis um Ansätze, die neben ökonomischen Erfolgsgrößen auch vor- oder nicht-ökonomische Erfolggrößen berücksichtigen [18]. In Verbindung mit der zunehmenden Institutionalisierung des Wissensmanagements stellt sich zunächst die Frage, was den Erfolg von Wissensmanagement in einer Organisation tatsächlich ausmacht und wie er gemessen werden kann. Davenport und Prusak zeigen anhand praktischer Beispiele, dass tatsächlich eine Erfolgswirksamkeit durch Projekte nachweisbar ist [6], z. B. sinkt durch verbesserte Wissensnutzung in den (operativen) Prozessen die Anzahl der gemachten Fehler bzw. werden Prozesse häufiger erfolgreich zu Ende gebracht. Ebenso ergeben sich Zeitersparnisse, die wiederum mindernd auf Kosten wirken. Die projektbezogene Erfolgsmessung ist aber wegen des temporären Charakters von Projekten nur von begrenztem Nutzen, da sie keine Aussage über das Wissensmanagement insgesamt erlaubt. Für einen ernsthaften Nachweis signifikanter Beiträge zum Erfolg einer Organisation durch das Wissensmanagement finden sich nur wenige Publikationen (Beispiele sind [33, 10]). Die Literatur beruht im Übrigen auf einem meist nicht monetären Erfolgsverständnis, wobei dieser Sachverhalt allerdings nicht immer explizit dargelegt, sondern durch die Argumentation und Grundhaltung implizit deutlich wird. Ein erfolgreiches Wissensmanagement hilft demnach Organisationen, Wettbewerbsvorteile zu realisieren, die Kundenfokussierung zu verbessern, Kosten zu senken und Innovationszyklen zu beschleunigen [17, 5, 9]. Es soll somit helfen, die organisatorische Leistungsfähigkeit zu steigern und direkt zum Erfolg des Unternehmens beitragen. Die Messung des direkten Einflusses eines effizienten Wissensmanagements auf den Unternehmenserfolg ist auf Grund der großen Anzahl an Faktoren noch immer sehr schwierig und unausgereift [2]. Daher wird in der Literatur empfohlen, vorgelagerte Erfolgsgrößen zur Messung heranzuziehen. Als mögliche Erfolgsgrößen kommen z.B. die Wissensqualität, das Niveau des Wissensaustauschs oder die Nutzerzufriedenheit mit dem Wissensmanagementsystem in Frage [12, 16]. Versucht man diese Überlegungen zu systematisieren, dann kann man zwei Perspektiven bei der Erfolgsmessung unterscheiden, welche mit einem unterschiedlichen Erfolgsverständnis aber auch mit unterschiedlichen Interpretationen der Ergebnisse verbunden sind: ● ● Zum einen wird Erfolg mit der Erreichung einer Zielvorgabe (z.B. Ziele des Wissensmanagementprojektes, Wissensziele des Unternehmens) in Verbindung gebracht. Zum anderen kann der Erfolg des Wissensmanagements als Beitrag zum Unternehmenserfolg definiert werden. Man spricht in Abgrenzung zum zielbezogenen Ansatz vom systembezogenen Erfolgsansatz, weil es bei dieser Perspektive um den Beitrag des Wissensmanagements zu einem übergeordneten Gesamtsystem geht. Der systemorientierte Erfolgsbeitrag lässt sich im Allgemeinen schwer isolieren, da das Wissensmanagement meist keinen aktiven und unmittelbaren Anteil am Unternehmenserfolg bzw. der Leistungserstellung hat. Es zielt vielmehr auf Verhaltensdispositionen und die Schaffung allgemeiner Voraussetzungen, Grundlagen u.Ä. Daher steht bei der Erfolgsmessung im Wissensmanagement der Zielansatz im Vordergrund. Dieser beschreibt den Erfolg als 516 Erreichungsgrad von selbst gesetzten Zielen (z. B. Steigerung des Wissensaustausches). Ferner ist anzumerken, dass Unternehmen oder Initiativen in diesem Fall möglicherweise an der Erreichung subjektiv gesetzter Ziele gemessen werden, ohne zu hinterfragen, ob diese Ziele auch relevant sind. Weiterhin sind mögliche Inkompatibilitäten von Zielen innerhalb eines Zielbündels sowie die Möglichkeit der Zieländerung im Zeitablauf nicht unwesentlich [18]. Neben der Wahl zwischen dem zielbezogenen und dem systembezogenen Ansatz sind weitere Aspekte zu berücksichtigen, da eine allgemein gültige Vorgehensweise bei der Erfolgsmessung, losgelöst vom jeweiligen Kontext, nicht sinnvoll ist. Von besonderer Bedeutung sind die drei folgenden Aspekte: ● ● ● Dies betrifft zunächst die Ausrichtung an der Interessensgruppe, d. h. für wen bzw. für welche Anspruchsgruppe erfolgt die Bewertung (z. B. Management, Wissenschaft, Markt). Eine zentrale Rolle für die Bewertung spielt die Größe und Organisationsform der bewerteten Einheit (z. B. Abteilung, Unternehmensstandort, internationaler Konzern). Schließlich ist auch das zugrunde gelegte Bewertungsobjekt von zentraler Bedeutung, weil die Erfolgsmessung darauf abzustimmen ist und sich darin auch das spezifische Verständnis von Wissensmanagement ausdrückt. Wegen seiner grundlegenden Bedeutung soll der letzte Punkt noch weiter differenziert werden. Im Wissensmanagement können fünf Bewertungsobjekte unterschieden werden [23]: ● ● ● ● ● das Wissen (die Wissensbasis) selbst, der Mensch als Wissensarbeiter, die Aktivitäten des Wissensmanagements, Wissensmanagementprojekte und Wissensmanagementsysteme. Bei den Messungs- und Bewertungsansätzen kann dabei zwischen verschiedenen Grundhaltungen differenziert werden, die einen Einfluss auf die Vorgehensweise bei der Messung haben. Dies sind: ● ● ● ● objektive vs. subjektive Ansätze, interne oder geschlossene vs. externe oder offene Ansätze, inside vs. outside betrachtungsorientierte Ansätze und integrative bzw. umfassende Bewertungsansätze vs. Partialansätze. Bei objektiven Messungen wird davon ausgegangen, dass es normative und extern vorgegebene Werte gibt, deren Erreichung mit Erfolg gleichgesetzt werden kann. Eine Unterscheidung zwischen richtig und falsch bzw. von einer Norm abweichend ist unter diesen Voraussetzungen möglich. Bei subjektiven Bewertungen wird unterstellt, dass die Situation in jedem Unternehmen anders ist (und damit auch die Rolle des Wissensmanagements) und ein Vergleich oder eine Bewertung des Wissensmanagements auf Basis objektiver Größen wenig sinnvoll ist. Die Orientierung erfolgt daher an internen Vorgaben. Beide Ausprägungen beschreiben die Gültigkeit – das „Wofür“ – der Messung. Da bei den objektiven Ansätzen bisher keine allgemein akzeptierten Ergebnisse vorliegen, finden in der Praxis primär Methoden Anwendung, die eine subjektive Bewertung erlauben. Dazu zählen u.a. Benchmarks, Wissensbilanzen, Zeit- und Kostenanalysen, Nutzenanalyse auf Basis der Balanced Scorecard, das Knowledge Management Maturity Model u.ä. Ansätze [27]. 517 Bei der internen Bewertung wird das Wissensmanagement als geschlossenes System betrachtet. Die Erfolgsbeurteilung erfolgt unter Beschränkung auf dieses System (z.B. Einhaltung des verfügbaren Budgetrahmens, Erreichung der vorgegebenen Ziele). Bei der externen Bewertung wird das Wissensmanagement als Black-Box betrachtet, das eine Leistung nach außen bzw. für andere Unternehmensteile erbringt. Hier geht es um die Bewertung dieser Leistung, d.h. um einen nachweisbaren Beitrag zum Unternehmenserfolg, zur Kostenreduktion oder anderen Bezugsgrößen. „Was“ unter einem Erfolgsbegriff verstanden wird, definieren beide Ausprägungen unterschiedlich. Wieder anders ist die Situation bei der Inside- respektive Outside-Betrachtung. Normalerweise erfolgt die Bewertung des Wissensmanagements inside in dem Sinne, dass die Situation aus dem Unternehmen heraus beurteilt wird (entweder eingeschränkt auf das Wissensmanagement selbst oder die gesamte Organisation umfassend). Dieser Blickwinkel wird selbst dann eingenommen, wenn die Bewertung durch eine externe Organisation (z.B. ein Beratungsunternehmen) durchgeführt wird. Allerdings kommt beim Einsatz eines Beratungsunternehmens erstmals auch ein Blick von außen dazu. Das lässt sich konsequent weiter denken, indem die Bewertung generell von außen, also z.B. von den Kunden vorgenommen wird. Auf diese Weise beurteilt sich das System nicht selbst, sondern man erhält Informationen darüber, ob auch der Markt das Unternehmen für hinreichend vernetzt und informiert hält. Durch die Angabe von Adressaten beschreiben die beiden Ausprägungen das „Wer“ der Betrachtung. Bei integrativen oder umfassenden Bewertungsansätzen wird das Wissensmanagement als Ganzes mit all seinen Teilbereichen und Funktionen erfasst und einer Bewertung unterzogen. Bei Partialansätzen erfolgt die Konzentration auf Teilbereiche (z.B. Wissen bei der Bewertung des Intellectual Capitals, Wissensmanagementsysteme beim Ansatz von Maier und Hädrich [25]). Diese Grundhaltung macht erneut Aussagen zum „Was“ der Bewertung. Im Rahmen des vorliegenden Beitrags erscheint es zweckmäßig, einen interessenpluralistischen Ansatz zu verwenden, um der Sichtweise gerecht zu werden, dass das Erfolgsverständnis an den Interessen der beteiligten Interessenvertreter festzumachen ist. Dieser Ansatz berücksichtigt demnach die Interessen aller internen und externen Koalitionen. In diesem Verständnis ist ein Unternehmen umso erfolgreicher, je eher es die Ansprüche der Interessenvertreter erfüllt, von denen es Ressourcen benötigt oder erhält und daher in einer Austauschbeziehung steht [29]. Zusammenfassend wird erfolgreiches Wissensmanagement auf der Grundlage der vorausgehenden Überlegungen wie folgt definiert: Erfolg im Wissensmanagement bemisst sich über die akkumulierte persönliche und subjektiv wahrgenommene Zufriedenheit eines Organisationsmitgliedes mit der Qualität der Wissensversorgung und Wissensweitergabe im Rahmen des individuellen Aufgabenumfeldes. Dies bedeutet, dass sich der Zielerreichungsgrad für ein erfolgreiches Wissensmanagement darüber definiert, ob ein Organisationsmitglied entweder zufrieden oder unzufrieden mit der Qualität der Wissensversorgung ist und ob jedes einzelne Organisationsmitglied Möglichkeiten hat, schnell und unkompliziert auf relevantes und qualitativ hochwertiges Wissen zugreifen zu können, das in der aktuellen Arbeitssituation benötigt wird. Natürlich muss ein erfolgreiches Wissensmanagement den Organisationsmitgliedern auch Möglichkeiten, Wege und Anreize bieten, ihr individuelles Wissen einzubringen. Zusammengefasst bedeutet das, dass das Wissensmanagement dann erfolgreich ist, wenn die Gesamtheit aller Aktivitäten dazu beiträgt, das Aufffinden, Vermehren und die Nutzung des für eine Organisation relevanten Wissens für die Organisationsmitglieder wahrnehmbar zu unterstützen und zu verbessern. 518 3. Instrumente zur Erfolgsmessung im Wissensmanagement Für die Erfolgsmessung im Wissensmanagement existiert mittlerweile eine Vielzahl an Instrumenten. In diesem Zusammenhang wird auch auf weitere Literatur (insbesondere [23]) verwiesen. Wolf unterscheidet zwischen Bilanzierungsansätzen zur Ermittlung des Wertzuwachses durch Wissensmanagement über den Bilanzwert hinaus, Strategieansätzen zur Analyse der Wirkungsweise von Wissensmanagement als Mechanismus der strategischen Unternehmensausrichtung und Prozessansätzen zur Bewertung als sozialen Prozess, der die organisatorische Kompetenz verändert [36]. Auch Kasperzak et al. differenzieren verschiedene Kategorien hinsichtlich der verwendeten Verfahren u.a. Marktwert-, Investitions- oder Wiederbeschaffungswertverfahren [22]. Bei beiden Klassifizierungen wird versucht eine disjunkte Zuteilung der Ansätze zu einzelnen Kategorien vorzunehmen, was jedoch meist nicht eindeutig möglich ist. Vor dem Hintergrund der dargestellten multiperspektivischen Bewertungssituation wird eine Einteilung nach mehreren Kategorien gemäß den oben beschriebenen Grundhaltungen vorgeschlagen. Abbildung 1 listet die wichtigsten Instrumente zur Bewertung des Wissensmanagements geordnet nach diesen Grundhaltungen auf. Abbildung 1: Instrumente zur Bewertung des Wissensmanagement [24] Im Folgenden werden nun diejenigen Instrumente vorgestellt, die die Erfolgsmessung im Wissensmanagement in Bezug auf das Wissensmanagement selbst, also eine interne Bewertung, vornehmen. Die Instrumente, die das Wissensmanagement nur indirekt über die Wissensbasis bzw. das Intellectual Capital bewerten, werden hier nicht näher betrachtet, da eine Aussage über die Güte des Wissensmanagements damit nicht möglich ist. Jene Instrumente, die eine partielle Bewertung vornehmen, sind häufig an Bewertungsmethoden aus der IT angelehnt. Maier und Hädrich entwickelten, basierend auf dem Modell zur Erfolgsmessung von Informationssystemen von DeLone und McLean [8], ein Modell zur Erfolgsmessung von Wissensmanagementsystemen. Dabei erweiterten sie das ursprüngliche Modell um die Perspektiven: „Informations-, Kommunikations- und Wissensqualität“, „wissensspezifischer Service“ und „Auswirkung auf Communities“. Um die Qualität des eingesetzten 519 Systems zu messen, wurden anhand einer Literaturanalyse und einer empirischen Untersuchung insgesamt 238 Faktoren für die verschiedenen Perspektiven und Wissensmanagementsystemtypen ermittelt [25]. In ähnlicher Weise dient auch das Modell von Folkens und Spiliopoulou zur Bewertung von Wissensmanagementsystemen [13]. Eine andere Zielrichtung verfolgt das Knowledge Process Quality Model (KPQM) von Paulzen und Perc, das an SPICE angelehnt wurde. Es soll auf der Prozessebene das Wissensmanagement evaluieren [31]. Das KPQM untersucht folgende Dimensionen: Reifegrad des Wissensmanagements, Wissensaktivitäten/-prozesse, Bereiche des Wissensmanagements und die Bewertungsart. Das KPQM dient Unternehmen dazu, ihre vorhandenen Wissensmanagementprozesse zu evaluieren, um Verbesserungspotentiale zu erkennen. Das Modell untersucht jedoch lediglich die Prozesse und nicht die Wissensbasis, ebenso schlägt das Modell keine passenden Strategien für bestimmte Ergebnisse vor [30]. Das Knowledge Management Maturity Model (KMMM) von Ehms und Lang will ebenfalls den Reifegrad der Wissensmanagementprozesse in einer Organisation oder in einem Teilbereich davon messen. Der Aufbau und die Vorgehensweise sind dabei analog zum KPQM von Paulzen und Perc [11]. Weitere Bewertungsinstrumente basieren auf der Balanced Scorecard (BSC). In der Grundkonzeption der BSC werden ausgewählte Perspektiven durch strategische Zielsetzungen, konkrete Kennzahlen, vorgesehene operative Maßnahmen und einen Zeithorizont beschrieben [20]. Die ursprünglich vorgeschlagenen Perspektiven können im Bedarfsfall abgewandelt oder ergänzt werden [21]. Obwohl die BSC in ihrer Grundannahme nicht in einem der Wissensgesellschaft entsprechenden Denken verwurzelt ist, ist sie doch eine etablierte Größe [37, 3]. Das Knowledge Management Performance Framework (KMPF) von de Gooijer ist ein Ansatz, der auf der BSC und einem verhaltenswissenschaftlichen Ansatz basiert. Der erste, auf der BSC basierende Teil, soll bereichsübergreifend die Effektivität des Wissensmanagements messen. Dazu wurden die ursprünglichen Perspektiven der BSC an das Wissensmanagement angepasst. Die so genannte Knowledge Management Performance Scorecard umfasst die Perspektiven Finanzen, Geschäftsprozesse, Stakeholders und Menschen. Für jede Perspektive werden die Schlüsselfunktionen bestimmt, die das Wissensmanagement erfüllen soll. Der zweite Teil des KMPF stützt sich auf den „concerns-based-adoption-model“ (CBAM) basierten Ansatz und zeigt, wie Individuen auf Veränderungen und Innovationen reagieren. Es wird davon ausgegangen, dass Individuen in Abhängigkeit ihres Wissens, das sie bzgl. einer Innovation haben, bestimmte Verhaltensweisen zeigen. Durch diese Zweiteilung des KMPF soll es gelingen, die „harten“ Zahlen aus der BSC mit den „verschwommenen“ der Verhaltensforschung zu verbinden, um die Effektivität von Wissensmanagement zu messen [7]. Ein weiteres Instrument, welches sich der BSC bedient, ist das Modell von del-Rey-Chamorro et al. [32]. Dieses dient dazu, Indikatoren zu bestimmen, die die Leistung des Wissensmanagements in Abhängigkeit von den Geschäftsprozessen messen. Das Modell gliedert sich in drei Ebenen: Die strategische Ebene, die operative Ebene und eine Verbindungsebene, die die ersten Ebenen verbindet. Das Modell dient nicht nur dazu, den Beitrag des Wissensmanagements zu den Geschäftsprozessen zu messen, sondern auch die Effektivität des implementierten Wissensmanagementsystems. Das Process-oriented Performance Measurement (PPM) von Schauer und Pfeiffer [34] wurde entwickelt, um den ökonomischen Beitrag von Wissensmanagement zu messen, da die gängigen Instrumente des Rechnungswesens und des Performance Measurement (PM) dazu nur teilweise geeignet sind. PPM kombiniert einen spezifischen Ansatz des PM mit einer prozessorientierten 520 Systemanalyse des Wissensmanagements. Das PPM möchte den Nutzen wissensintensiver Arbeit und die Maßnahmen des Wissensmanagements modellieren. Basierend auf einer Systemanalyse werden Kennzahlen für das Wissensmanagement abgeleitet und systematisch in ein Kennzahlensystem integriert. Die Wissensbilanz A2006 möchte das im Unternehmen vorhandene Wissen systematisch aufbereiten, um die strategische Unternehmensführung zu unterstützen. Die Erstellung der Bilanz gliedert sich in sechs Schritte: (1) Aufsetzen des Projektmanagements, um die Unterstützung der Top-Managements zu sichern, einen klaren Projektplan zu erhalten und ein kompetentes Team zusammenzustellen, (2) Festlegen der Kernkompetenzen, um die strategischen Erfolgsfaktoren und die Unternehmenssituation darzustellen, (3) Assessment des Wissensmanagements, um eine differenzierte Bewertung der Erfolgsfaktoren zu erhalten und Kenntnisse über die Wechselwirkungen des Wissensmanagements zu bestimmen, (4) Erhebung und Interpretation der Indikatoren, um ein Indikatorenset zu erhalten und geeignete Maßnahmen zu treffen, (5) Festlegung der Planungs- und Steuerungsprozesses, um einen kontinuierlichen Prozess der Wissensbilanzierung zu erhalten und (6) eine interne und externe Kommunikation, um alle Interessgruppen bzw. Stakeholder umfassend zu informieren und zu motivieren [4]. Das CSF-MCA-Modell von Tambyrajah und Al-Shawabkeh basiert auf einem Ansatz, welcher das Wissensmanagement über kritische Erfolgsfaktoren (Critical Success Factors, CSF) bewertet. Auf der Grundlage einer umfangreichen Literaturanalyse wurden drei Gruppen von CSFs bestimmt: „Menschen und Kultur“, „Prozesse“ und „IT-Infrastruktur“. Das Bewertungsmodell basiert auf dem SECI-Modell von Nonaka und Takeuchi [28]. Die CSFs werden in das SECI-Modell eingefügt und hinterlegen das Modell mit Indikatoren. Dabei kann das anfänglich verwendete Set der Indikatoren aus einer Literaturanalyse gewonnen werden und anschließend mit Hilfe einer multikriteriellen Analyse diskutiert werden. Letztere bezieht sowohl Top-down- als auch Bottom-upEntscheidungen mit ein. Das Ergebnis des Modells spiegelt aber nur eine Momentaufnahme des Wissensmanagements zu einem bestimmten Zeitpunkt wider [35]. Ein weiterer Ansatz, der sich am SECI-Modell orientiert, ist die Methode von Afrazeh und Nezafati. Hierbei wird der Wissensstatus einer Organisation in Bezug auf die von Nonaka und Takeuchi definierten Wissenstypen (explizites, implizites, individuelles und kollektives Wissen) und den dazwischen ablaufenden Transformationsprozessen erhoben. Für die jeweils vier Wissenstypen und Transformationsmodi werden mehrere Indikatoren bestimmt. Die Autoren treffen jedoch keine Aussagen über die Herkunft und Validität der Indikatoren. Der Bezug zu den einzelnen Wissenstypen und Transformationen bleibt zudem unklar. Die Bewertungsergebnisse der einzelnen Indikatoren werden schließlich genutzt, um einen Leistungs- und einen Prioritätswert für jeden Indikator zu bestimmen. Diese dienen zur Berechnung jedes einzelnen Wissenstypus und Transformationsmodus sowie zur Bestimmung eines generellen Wissensstatus der Organisation. Je nach Ausprägung von Leistung und Priorität des Wissensstatus sind verschiedene Maßnahmen durchzuführen. Die Methode wurde bisher von den Autoren selbst durchgeführt. Ihre Anwendung durch die Organisation selbst wäre durchaus denkbar [1]. Abschließend ist anzumerken, dass sich einige in der Literatur angeführten Instrumente ausschließlich auf die Visualisierung des im Unternehmen vorhandenen Wissenstypus beschränken und daher keine unmittelbare Erfolgsbewertung erlauben. Anstatt einer Bewertung besteht das Ziel darin, Transparenz zu schaffen. Hierzu gehört z. B. das Knowledge-Management-Assessment-Tool (KMAT) der APQC, bei dem über einen standardisierten Fragebogen der Status von kritischen Rahmenbedingungen (z.B. Kultur, Führung, Technologie) erfasst wird [26]. Ein weiteres Instrument dieser Gruppe ist das Knowledge Framework von Jordan und Jones [19], das mittels 521 Interviews unternehmensspezifische Wissensprofile erhebt. Die Messung erstreckt sich über die Dimensionen: Wissensbeschaffung, Problemlösungsmethode, Verteilung, Besitz und Gedächtnis. Jede Dimension wird dabei durch mehrere Indikatoren charakterisiert. 4. Allgemeines Vorgehen bei der Erfolgsmessung und Zusammenfassung Obwohl die Forschung in Bezug auf die Entwicklung geeigneter Bewertungssysteme im Wissensmanagement noch am Anfang steht, lassen sich gewisse Grundtendenzen erkennen. Ein allgemein gängiger Bewertungsprozess kann in folgende Schritte gegliedert werden [15, 14]: 1. Identifizierung der Ziele: Die Ziele der Bewertung des Wissensmanagements werden in Abhängigkeit der Zielgruppe bestimmt (z. B. Wissensmanager, Manager, Kunden, etc.). 2. Auswahl des Messsystems: Das Messsystem wird in Abhängigkeit von den untersuchten Wissensmanagementinitiativen ausgewählt, damit es einfach zu handhaben und aussagekräftig ist. BSC-basierte Systeme eignen sich für eine umfassende Bewertung des Wissensmanagements, wogegen ein Matrix-System eine Übersicht über ein Portfolio von Wissensmanagementaktivitäten darstellt und zeigt, wie diese in Zusammenhang stehen. Diese Darstellung ist sinnvoll, um Prioritäten bei den Wissensmanagementaktivitäten festzulegen. 3. Festlegung der Indikatoren: Die Indikatoren werden in Abhängigkeit von Messsystem und Zielsetzung bestimmt. 4. Bestimmung der Erhebungsart: Aus den verschiedenen Erhebungsarten, wie Fragebögen, Interviews, Workshops, Untersuchung von Programmverläufen/-statistiken und Dokumenten, wird eine geeignete ausgewählt. 5. Untersuchung der Ergebnisse: Die gewonnenen Daten werden interpretiert, um Gründe für eine effektive bzw. ineffektive Nutzung des Wissensmanagements zu erhalten. Natürlich ist es möglich, die dargestellten Grundorientierungen zur Bewertung von Wissensmanagement zu kombinieren und weiter zu variieren. Unabhängig davon fehlen aber noch geeignete Indikatoren. Mögliche Indikatoren sind empirisch nicht validiert und der UrsacheWirkungs-Zusammenhang zwischen Indikatoren und Erfolg ist bisher nur exemplarisch aufgezeigt worden, denn Erfolg ist immer auch an ein Erfolgskonstrukt gebunden. Ein Defizit besteht nicht zuletzt darin, dass selbst über die Begrifflichkeiten noch Uneinigkeit herrscht. Ein noch größeres Defizit herrscht bei der Bestimmung der Faktoren. Es gibt bereits einige Studien, die sich mit Barriere- und Erfolgsfaktoren des Wissensmanagements beschäftigten, jedoch gibt es kein valides Set solcher Faktoren, welches zur Bewertung herangezogen werden kann. Der generelle Nutzen der beschriebenen Bewertungsinstrumente wird somit stark reduziert. Für eine valide Bewertung des Wissensmanagements ist es daher notwendig, allgemein gültige Barrierebzw. Erfolgsfaktoren zu bestimmen. In diesem Zusammenhang ist auch zu erwähnen, dass zwischen der wissenschaftlichen Forschung zur Erklärung des Erfolgs durch das Wissensmanagement und der Entwicklung von Messmethoden bzw. -instrumenten bisher keine hinreichende Verbindung besteht. Ein Anliegen der Autoren besteht daher darin, in weiterer Forschungsarbeit diese Lücke zu schließen [24]. Mit der vorliegenden Arbeit wurde ein Versuch unternommen, einen Beitrag auf diesem Weg zu leisten. 5. Literaturhinweise [1] AFRAZEH, A. und NEZFATI, N., A Method for Measurement of Knowledge in Organization Based on the SECI Model, in: C. Stary, F. Barachini und S. Hawamdeh (Hrsg.), Knowledge Management: Innovation, Technology and Cultures, Proceedings of the 2007 International Conference on Knowledge Management, Wien, Österreich, 27-28. August, 2007, 141-151. 522 [2] BHARADWAJ, A.S., A resource-based perspective on information technology capability and firm performance: an empirical investigation, in: MIS Quarterly, Bd. 24, Nr. 1 (2000), 169-96. [3] BODROW, W. und BERGMANN, P., Wissensbewertung in Unternehmen, Berlin 2003. [4] BRANDNER, A. (Hrsg.), Assess – Wissensbilanz A2006© – Leitfaden für Klein- und Mittelbetriebe, Wien 2006, http://assess.daa.at/download.asp?id=156, Abrufdatum: 16.11.2008. [5] CHOURIDES, P., LONGBOTTOM, D. und MURPHY, W., Excellence in knowledge management: an empirical study to identify critical factors and performance measures, in: Measuring Business Excellence, Bd. 7, Nr. 2 (2003), 29-45. [6] DAVENPORT, T.H. und PRUSAK, L., Working Knowledge, Boston 1998. [7] DE GOOIJER, J., Designing a knowledge management performance framework, in: Journal of Knowledge Management, Bd. 4, Nr. 4 (2000), 303-310. [8] DE LONE, W.H. und McLEAN, E.R., Information Systems Success: The Quest for the Depend Variable, in: Information Research, Bd. 3, Nr. 1 (1992), 259-274. [9] DETERT, J.R. und SCHROEDER, R.G., A framework for linking culture and improvement initiatives in organizations, in: Academy of Management Review, Bd. 25, Nr. 4 (2000), 850-63. [10] DOVEY, K. und WHITE, R., Learning about learning in knowledge-intense organizations, in: The Learning Organization, Bd. 12, Nr. 3 (2005), 246-260. [11] EHMS, K. und LANGEN, M., Ganzheitliche Entwicklung von Wissensmanagement mit KMMM®, in: Wissensmanagement online (2000), www.wissensmanagement.net/online/archiv/2000/08_0900/Wissensmanagement.shtml, Abrufdatum: 13.08.2007. [12] FERNANDEZ, I.B. und SABHERWAL, R., Organizational knowledge management: a contingency Perspective, in: Journal of Management Information Systems, Bd. 18, Nr. 1 (2001), 23-55. [13] FOLKENS, F. und SPILIOPOULOU, Towards an Evaluation Framework for Knowledge Management Systems, in: D. Karagiannis D. und U. Reimer (Hrsg.), Practical Aspects of Knowledge Management, Berlin 2004, 23-34. [14] HANLEY, S. und MALAFSKY, G., A Guide for Measuring the Value of KM Investments, in: C.W. Holsapple (Hrsg.), Handbook of Knowledge Management, Bd. 2 Knowledge Directions, Berlin 2003, 369-390. [15] JUNGINGER, M., HERTWECK, D., MATSCHI, M., SCHUMACHER, J., WEISS, B. und WOLTER, T., Erfolgsmessung und Gestaltung von Wissensmanagement-Projekten – Entwicklung einer Methode zur Ergebnisbestimmung und -steuerung, in: N. Gronau (Hrsg.): 4. Konferenz Professionelles Wissensmanagement – Erfahrungen und Visionen, Bd. 1, Berlin 2007, 137-144. [16] HUANG, K.T., LEE, Y.W., WANG, R.Y., Quality Information and Knowledge, Englewood Cliffs 1999. [17] JENNEX, M.E., SMOLNIK, S., CROASDELL, D., Towards defining knowledge management success, in: Proceedings of the 40th Annual Hawaii International Conference on System Sciences (HICSS'07), 2007. [18] JENNER, T., Determinanten des Unternehmenserfolges, Stuttgart 1999. [19] JORDAN, J. und JONES, P., Assessing your Company’s Knowledge Management Style, in: Long range planning, Bd. 30, Nr. 3 (1997), 392-398. [20] KAPLAN, R. und NORTON, D., The Balanced Scorecard – Measure that drive Performance, in: Harvard Business Review, Bd. 70, Nr. 1 (1992), 71-79. [21] KAPS, G., Erfolgsmessung im Wissensmanagement unter Anwendung von Balanced Scorecards, in: H. Nohr (Hrsg.), Arbeitspapiere Wissensmanagement, Nr. 2, Stuttgart 2001. 523 [22] KASPERZAK, R., KRAG, J. und WIEDENHOFER, M., Konzepte zur Erfassung und Abbildung des Intellectual Capital, in: Deutsches Steuerrecht, Bd. 39, Nr. 35, 2001, 1494-1500. [23] LEHNER, F., Wissensmanagement. Grundlagen, Methoden und technische Unterstützung. 2. Auflage, München 2008. [24] LEHNER, F., AMENDE, N., HAAS, N., WILDNER, S., Erfolgsbeurteilung des Wissensmanagements: Diagnose und Bewertung der Wissensmanagementaktivitäten auf der Grundlage der Erfolgsfaktorenanalyse, Forschungsbericht W-24-07, Lehrstuhl für Wirtschaftsinformatik II, Universität Passau 2007. [25] MAIER, R. und HÄDRICH, T., Modell für die Erfolgsmessung von Wissensmanagementsystemen, in: Wirtschaftsinformatik, Bd. 43, Nr. 5 (2001), 497-509. [26] NORTH, K., Wissensorientierte Unternehmensführung, Wiesbaden 2002. [27] NORTH, K., PROBST, G. und ROMHARDT, K., Wissen messen – Ansätze, Erfahrungen und kritische Fragen, in: Zeitschrift für Führung und Organisation, Bd. 63, Nr. 3 (1998), 158-166. [28] NONAKA I. und TAKEUCHI, H., The Knowledge Creating Company: How Japanese Companies Create the Dynamics of Innovation, New York 1995. [29] OESTERLE, M.-J., Probleme und Methoden der Joint Venture-Erfolgsbewertung, in: Zeitschrift für Betriebswirtschaft, Bd. 65, Nr. 9 (1995), 987-1004. [30] PAULZEN, O. und PERC, P., A Maturity Model for Quality Improvement in Knowledge Management, in: A. Wenn, M. McGrath und F. Burstein (Hrsg.), Enabling Organisations and Society through Information Systems, Proceedings of the 13th Australasian Conference on Informations Systemes (ACIS 2002), Melbourne 2002, 243-253. [31] PAULZEN, O., Qualität im Wissensmanagement – Modellierung und Bewertung von Wissensprozessen, Wiesbaden 2006. [32] DEL-REY-CHAMORRO, F.M., ROY, R., VAN WEGEN, B. and STEELE, S., A framework to create key performance indicators for knowledge management solutions, in: Journal of Knowledge Management, Bd. 7, Nr. 2 (2003), 46-62. [33] SALOJÄRVI, S., FURU, P. und SVEIBY, K., Knowledge management and growth in Finnish SMEs, in: Journal of Knowledge Management, Bd. 9, Nr. 2 (2005), 103-122. [34] SCHAUER, H. und PFEIFER, M., Process-oriented Performance Measurement (PPM) – Eine Modellierungsmethode für das Wissenscontrolling, in: N. Gronau (Hrsg.): 4. Konferenz Professionelles Wissensmanagement – Erfahrungen und Visionen, Bd. 1, Berlin 2007, 127-135. [35] TAMBYRAJAH, A. und AL-SHAWABKEH, A., Developing Performance Indicators for Knowledge Management, in: B. Martins, D. Remenyi (Hrsg.): Proceedings of the 8th European Conference on Knowledge Management, Consorci Escola Industrial de Barcelona, Spanien, 6-7. September, 2007, Bd. 2, 972-981. [36] WOLF, P., Erfolgsmessung der Einführung von Wissensmanagement. Eine Evaluationsstudie im Projekt „Knowledge Management“ der Mercedes-Benz PKW-Entwicklung der DaimlerChrysler AG, Münster, 2003. [37] WU, A., The integration between Balanced Scorecard and intellectual capital, in: Journal of Intellectual Capital, Bd. 6, Nr. 2 (2005), 267-284. 524 LEISTUNGSORIENTIERTE STEUERUNG DER INFORMATIONSVERSORGUNG IM RAHMEN DER QUALITÄTSSICHERUNG IN DIENSTLEISTUNGSNETZWERKEN Reinhard Jung1, Martina Meschke2 Kurzfassung Die Qualitätssicherung der Leistungserstellung in Dienstleistungsnetzwerken ist ein wichtiger Erfolgsfaktor. Die Netzwerkunternehmen müssen durch eine effektive und effiziente Informationsversorgung unterstützt werden. Eine leistungsorientierte Steuerung der integrierten Informationsversorgung sowohl auf organisatorischer als auch auf technologischer Ebene trägt den Herausforderungen Rechnung. Drei Szenarien bilden die unterschiedlichen Anforderungen in Bezug auf Flexibilität und Unabhängigkeit der Netzwerkunternehmen ab. Sie werden durch Kriterien definiert, die auf die leistungsorientierte Gestaltung der Informationsversorgung ausgerichtet sind: Ziele der Informationsversorgung, Ausgangs- und Eingangsdaten sowie Prozesse. Daraus leiten sich Architekturen sowie Rollen und Verantwortlichkeiten ab. Zur Steuerung werden drei korrespondierende Controllingansätze entwickelt, die für jede Architektur spezifische Controllingobjekte, Controllinginstrumente sowie quantitative und qualitative Kennzahlen zur Verfügung stellen. 1. Einleitung Der Dienstleistungssektor hat in den letzten Jahren immer mehr an Bedeutung gewonnen. Deutschland ist der dritt größte Dienstleistungsanbieter weltweit, und in diesem Sektor arbeiten mittlerweile dreiviertel aller in Deutschland Beschäftigten [5]. Die Leistungserbringung des Dienstleistungssektors findet zunehmend in Netzwerken statt [12, 20, 24]. Hierbei nimmt der Kunde allerdings in der Regel nur die Gesamtleistung wahr, die in entsprechender Güte integriert sein muss. Die Schnittstelle zum Kunden wird oftmals durch einen sogenannten „Service Integrator“ gebildet, der die Verantwortung für die Zusammenstellung der Endleistung hat [3, 13, 25]. Nicht nur der Service Integrator, sondern auch die übrigen Partner („Service Provider“) sind abhängig von der Leistungsqualität im gesamten Dienstleistungsnetzwerk, damit effiziente Wertschöpfung und in der Folge Gewinn erzielt werden kann. Die Sicherung der Qualität einer verteilten Leistungserstellung ist deshalb ein wichtiger Faktor für die Effektivität und Effizienz eines Dienst1 2 Universität Duisburg-Essen, Germany FernUniversität in Hagen, Germany 525 leistungsnetzwerks [1, 31]. Im Rahmen der Qualitätssicherung ergibt sich eine besondere Herausforderung an die Informationsversorgung (IV) in Dienstleistungsnetzwerken [15]. Oftmals fehlt eine angemessene IV, die im Netzwerk die qualitätsrelevanten Informationen zeitnah und adressatenorientiert am richtigen Ort zur Verfügung stellt. Daraus abgeleitet und aus den Gestaltungselementen der Phasen einer IV [11] ergeben sich die Erfolgsfaktoren Zeit (zeitnah), Kommunikationsmedium (adressatenorientiert am richtigen Ort) und Kosten (effizienzorientiert), ohne die eine schnelle, flexible und effiziente Qualitätssicherung nicht garantiert werden kann [7, 33]. Die IV in Dienstleistungsnetzwerken kann unterschiedlich gestaltet sein. Je nach Grad der Kooperationsintensität werden die Netzwerkpartner (im Folgenden kurz: Unternehmen) unterschiedliche Architekturen für die IV wählen: „Separate IV“, „Kooperative IV“ und „Integrierte IV“. Unternehmen, die eine eher kurzfristige und wirtschaftlich unabhängigere Kooperation anstreben, werden in der Regel eine „Separate IV“ wählen. Je langfristiger die Kooperation ausgelegt ist, desto eher werden die Unternehmen aus Effizienzgründen die „Kooperative IV“ oder sogar die „Integrierte IV“ anstreben. Damit ist gleichzeitig eine erhöhte Abhängigkeit zwischen den Unternehmen verbunden (vgl. Kapitel 3). Im Anschluss an die Auswahl der Architektur, die für die spezifische Situation und Zielsetzung der Unternehmen am besten geeignet zu sein scheint (Erfolgsfaktor „Zeit“ und „Kommunikationsmedium“), muss ein Mechanismus etabliert werden, um die Wirtschaftlichkeit der IV zu gewährleisten (Erfolgsfaktor „Kosten“). Die Zielsetzung dieses Beitrags ist zum Einen die Definition von drei verschiedenen IV-Architekturen, die der jeweils angestrebten Kooperationsintensität Rechnung tragen, und zum Anderen die Entwicklung eines Controllingansatzes für jede Architektur. Daraus ergeben sich zwei zentrale Forschungsfragen: Welche Kriterien sind bei der Auswahl einer IVArchitektur in Bezug auf die fachlichen und technologischen Komponenten zu beachten? Wie kann eine leistungsorientierte Steuerung der jeweiligen IV, d.h. die Entwicklung eines effektiven und effizienten Controllingansatzes pro Architektur, stattfinden? Die Entwicklung des Controllingansatzes erfolgt argumentativ-deduktiv [34], abgeleitet aus der Literatur und verfügbaren empirischen Befunden. In einem späteren Schritt, für den dieser Beitrag als Basis dient, ist dieses Modell im Rahmen einer Studie empirisch zu untersuchen. Der vorliegende Beitrag definiert in Abschnitt 2 zunächst die Grundlagen zu Dienstleistungsnetzwerken und zeigt daran die erforderliche IV auf. In Abschnitt 3 folgt dann zur Systematisierung der IV die Definition von drei Architekturen, die den unterschiedlichen Beziehungsausprägungen (Kooperationsintensität) in einem Dienstleistungsnetzwerk Rechnung tragen. Je nach Szenario muss eine spezifische Applikationsarchitektur für die IV zum Einsatz kommen. Die Entwicklung des Controllingansatzes zur Steuerung der IV pro Architektur, ist gemäß der zuvor genannten Forschungsfragen Ziel dieses Beitrags und wird in Abschnitt 4 präsentiert. 2. Informationsversorgung in Dienstleistungsnetzwerken Die Unternehmen in einem Dienstleistungsnetzwerk sind in der Regel rechtlich selbstständig und nur hinsichtlich ihres Ressourcenaustausches (z. B. Know How) wirtschaftlich voneinander abhängig [1]. Ein Dienstleistungsnetzwerk wird im vorliegenden Beitrag definiert als Kooperation zwischen einem Service Integrator, der die Schnittstelle zum Kunden „besetzt“, und mindestens zwei Service Providern. Der Service Integrator bündelt alle Leistungen zu einem Dienstleistungspaket und sollte demnach zentral für die Qualitätssicherung verantwortlich sein. 526 Die Qualität von Dienstleistungen ist schwieriger messbar als die Qualität materieller Produkte; dies ist schon allein dadurch begründet, dass materielle Produkte zu einem Zeitpunkt vor der Auslieferung vollständig vorliegen und gegen eine Spezifikation getestet werden können (z.B. Vermessung von Maschinenbauteilen), während sich Dienstleistungen erst während der Leistungserbringung beim Kunden und zudem über einen bestimmten Zeitraum manifestieren [6, 23]. Zusätzlich sind die Erwartungen und Wahrnehmungen des Dienstleistungsempfängers (Konsument) ausschlaggebend bei der Bewertung der Qualität [27]. Die Qualität im Dienstleistungsnetzwerk wird deshalb durch zwei Perspektiven definiert: die Perspektive der Konsumenten und die Perspektive der Leistungserbringer (Service Integrator und Service Provider) [1]. Die Konsumenten fordern und erwarten eine hohe Dienstleistungsqualität in Bezug auf das angebotene Leistungsbündel (z. B. Zuverlässigkeit, Freundlichkeit, Engagement und Kompetenz der Mitarbeiter, materielle Produktbeschaffenheit, seriöses und klares Auftreten (Image) des Unternehmens). Das Image hat zudem eine besonders starke Auswirkung auf die durch den Konsumenten wahrgenommene Qualität [14]. Aus diesem Grund ist der Service Integrator idealerweise das Unternehmen mit dem besten Image; er muss das Image jedoch durch eine hohe Leistungsqualität absichern. Um diese Qualität bieten zu können, fordert der Service Integrator eine hohe Qualität von den Service Providern hinsichtlich der erbrachten Einzelleistungen. Hierzu gehören Qualitätskriterien, wie z. B. die Zuverlässigkeit der Unternehmen, Flexibilität, Verbindlichkeit sowie Kosten- und Prozesseffizienz im Netzwerk [30]. Aus diesen Qualitätsanforderungen ergeben sich die spezifischen Herausforderungen für eine IV im Netzwerk, die mit einer angemessenen technologischen Infrastruktur adressiert werden müssen. Da in einem Dienstleistungsnetzwerk von heterogenen Applikationsarchitekturen bei den Unternehmen auszugehen ist [32], muss im Rahmen der Entwicklung einer effizienten IV ein optimaler, auf die Situation angepasster, Integrationsgrad erreicht werden [29]. Daraus lässt sich schließen, dass die Steuerung der Dienstleistungsqualität in Netzwerken wesentlich komplexer ist, als innerhalb eines einzelnen Dienstleistungsunternehmens [4, 23]. Die IV hat zwei Seiten, die es zu steuern gilt: Einerseits die Informationsnachfrage und andererseits das Informationsangebot [28], d.h. die Informationsbereitstellung durch die Applikationsinfrastruktur. Die Leistungssteuerung der IV zerfällt also in zwei Wirkungsbereiche: Die Steuerung der fachlichen Zielsetzungen (Informationsnachfrage und -angebot) und die Steuerung der technischen Informationsbereitstellung. In Dienstleistungsnetzwerken ergeben sich in der Regel signifikante Transaktionskosten [9, 35], wie Anbahnungs-, Vereinbarungs-, Abwicklungs-, Kontroll- oder Anpassungskosten [28, 32]. Diese fallen im Rahmen der IV in Dienstleistungsnetzwerken für die Informationsbereitstellung an, die sich aus den Kosten für die Informationsbeschaffung/Recherche und die Informationsaufbereitung zusammensetzen. Hinzu kommen die Kosten für Betrieb und Wartung der Applikationsinfrastruktur. Die Höhe der Transaktionskosten im Dienstleistungsnetzwerk wird durch folgende Kriterien beeinflusst: Die Häufigkeit der Transaktionen zwischen den Unternehmen, die Unsicherheit der Unternehmen hinsichtlich z. B. opportunistischem Verhalten, die direkten transaktionsspezifischen Investitionsausgaben (z. B. neue Informations- und Kommunikationstechnologie) [2, 19]. Aus der Höhe der Transaktionskosten ergibt sich in der Regel die Struktur der Koordination zwischen den Unternehmen [31]. Werden sehr hohe Transaktionskosten erwartet, ist die Überlegung sinnvoll, den Integrationsgrad zu steigern. Dadurch können zukünftige Transaktionskosten gesenkt werden. Zusätzlich wirken sich auf die Qualität der Kooperationsbeziehung Faktoren, wie die subjektiven Vorstellungen der Unternehmen, die Kooperationsdauer, die „innere Verpflichtung“ der Service Provider gegenüber dem Service Integrator, die ökonomische Anreiz-Beitragsstruktur sowie die Machtbeziehung zwischen dem Service Integrator und den Service Providern, aus [4]. Diese Faktoren bedingen die Wahl der Kooperationsform. Der optimale situationsspezifische Integrationsgrad 527 wird in diesem Beitrag auf einem Spektrum von drei verschiedenen Architekturen veranschaulicht, die im Rahmen der IV von den Unternehmen gewählt werden können. 3. Architekturen für die Informationsversorgung in Dienstleistungsnetzwerken Ein Controllingansatz für eine leistungsorientierte IV muss auf die Anforderungen der Kooperation zugeschnitten sein. Aus diesem Grund werden nachfolgend drei mögliche Szenarien für die IV in Dienstleistungsnetzwerken beschrieben. Sie ergeben sich aus den Ausprägungen der folgenden Kriterien: • Ziele der IV: Die Organisation der IV verfolgt je nach Kooperationsintensität bestimmte Ziele, die bekannt sein müssen, um die Struktur der Architektur ableiten zu können [4]. Aus den Zielen der IV ergeben sich die Vorgaben für die Standards der Ausgangsdaten („Berichte“). • Ausgangsdaten („Berichte“): Definition der Ausgangsdaten, die zur Steuerung der Kooperation erzeugt und in entsprechenden Berichten zusammengefasst werden. Die Standards der Ausgangsdaten („Berichte“) variieren in Abhängigkeit von der Architektur; je dezentraler die Datenhaltung organisiert ist, desto restriktiver müssen die Standards sein. Anhand der Ausgangsdaten ergibt sich, welche Eingangsdaten benötigt werden [22]. • Eingangsdaten: Die Eingangsdaten stellen den Input für die Erzeugung der Berichte dar. Die erforderliche Standardisierung der Eingangsdaten ergibt sich aus dem Zentralisierungsgrad der Berichtserstellung. Die Definition der Ausgangs- und Eingangsdaten bestimmen die erforderlichen IV-Prozesse [22]. • Prozesse: Die IV-Prozesse beziehen sich entweder auf die fachlichen (z. B. Datenbereitstellung, Informationsaufbereitung, Informationsverteilung, Kommunikation sowie Umsetzung von Qualitätssicherungsmaßnahmen) oder die technischen Aufgaben der IV (z. B. Definition der Schnittstellen, Anpassung der Applikationen und Schnittstellen an veränderte Anforderungen, Wartung der bestehenden Applikationsarchitektur) [11]. Ausgehend von den Zielen der IV, Ausgangsdaten, Eingangsdaten und Prozessen kann ein Kontinuum von drei Kooperationsszenarien aufgespannt werden: dezentralisiert, hybrid, zentralisiert. Daraus lassen sich als Ergebnis drei Architekturen mit den daraus resultierenden Rollen und Verantwortlichkeiten (fachlicher und technischer Datensteward [26]) ableiten (vgl. Tabelle 1): • Architektur 1 („Separate IV“): Szenario 1 („Dezentralisiert“) ist gekennzeichnet durch den ausschließlichen Austausch von Berichten zwischen den Unternehmen. Das bedeutet, dass zu Beginn der Kooperation der Informationsbedarf für die gemeinsame Qualitätssicherung festgelegt wird (Steuerung der Informationsnachfrage). Zudem wird ein Vorgehen zur Kommunikation und Umsetzung von Qualitätssicherungsmaßnahmen auf Basis von Berichten definiert. Die Datensammlung und -aufbereitung sowie die eingesetzte Infrastruktur liegen vollständig in der Verantwortung der kooperierenden Unternehmen. Die dezentralen Datenstewards (fachlich) übernehmen die Verantwortung für die Rahmenbedingungen der IV in den beteiligten Unternehmen, z. B. die inhaltliche Datenqualität sowie die dafür erforderlichen Maßnahmen. Die dezentralen Datenstewards (technisch) sind verantwortlich für die Wartung und Weiterentwicklung der jeweiligen Applikationen in den Unternehmen. • In Architektur 2 („Kooperative IV“) erfolgt, ausgehend von Szenario 2 („Hybrid“), eine engere Kopplung der IV der beteiligten Unternehmen, indem die Berichte aus einem gemeinsamen Data Warehouse erzeugt werden. Dieses Data Warehouse wird dediziert für die Qualitätssicherung im Netzwerk aufgesetzt und kann von den beteiligten Unternehmen für diesen Zweck beliebig genutzt werden; die Infrastruktur für Berichterstellung und Auswertungen verbleibt in den Unternehmen. Ebenso liegt die Verantwortung für die in das Data Warehouse zu ladenden Daten bei den Unternehmen. Die Kopplung der IV stellt zusätzliche Anforderungen an die Koordination des fachlichen und technischen Datenmanagements. Für das fachliche Datenmana528 gement muss die entsprechende Verantwortung für die Stammdaten im Data Warehouse festgelegt werden (fachlicher Datensteward). Das technische Datenmanagement betrifft z. B. die Definition der Schnittstellen sowie der Extraktions-, Transformations- und Ladeprozesse (dezentraler technischer Datensteward). Darüber hinaus muss die Verantwortung für die Wartung und Weiterentwicklung der gemeinsamen Infrastruktur sowie die Verteilung der anteiligen Kosten festgelegt werden (zentraler technischer Datensteward). • In Architektur 3 („Integrierte IV“) wird, ausgehend von Szenario 3 („Zentralisiert“), der engste Grad der Kopplung implementiert. Alle beteiligten Unternehmen greifen auf ein gemeinsames Qualitätsmanagement Informationssystem (Q-MIS) zu, das auf einer gemeinsamen Datenbasis aufsetzt und bis zum Berichtssystem vollständig integriert ist, also eine gemeinsame Applikationsarchitektur für die IV zur Qualitätssicherung darstellt. Damit verlagern sich die Verantwortung und die leistungsorientierte Steuerung der IV zu der zentralen Stelle, dem technischen Datensteward. Die Unternehmen sind nur noch für eine zeitgerechte Lieferung der geforderten Eingangsdaten über eine definierte Schnittstelle verantwortlich (fachlicher Datensteward). Tabelle 1: Zuordnung der Architekturen zu Szenarien Szenario 1 Dezentralisiert Kriterium Ziele Ausgangsdaten (Berichte) Eingangsdaten Prozesse Unabhängigkeit der Unternehmen mit Hohe Unabhängigkeit der Unternehmen hoher IV-Flexibilität bei den Berichten: und hohe Austauschbarkeit im Auf der verfügbaren Datenbasis können Dienstleistungsnetzwerk. beliebige Berichte definiert werden. Definition der standardisierten DatenobHochstandardisierte Daten. Berichtsjekte für die gemeinsamen Berichte und standards werden durch den Service von generellen Datenobjekten für die DeIntegrator vorgegeben. finition der individuellen Berichte. Hochstandardisierte Daten, sichergestellt *nicht relevant* durch den Einsatz von Ontologien und Metadaten [18]. Fachliche und technische Prozesse laufen in den beteiligten Unternehmen unabhängig voneinander; BerührungsFachliche Prozesse zur Bereitstellung der punkte gibt es an zwei Stellen: Daten laufen in den beteiligten Unter- - Rollen und Verantwortlichkeiten Die Applikationsarchitekturen in den Unternehmen sind vollständig unabhängig voneinander, also dezentralisiert; Maßnahmen zur Standardisierung oder Integration von weiteren/neuen Daten müssen abgestimmt werden. - - Szenario 3 Zentralisiert Enge Zusammenarbeit mit maximaler IVFlexibilität. Metadatenmanagement als Basis für die Standardisierung; darüber hinaus Standardisierung der gemeinsamen Berichtsobjekte. Einhaltung von Datenqualitätsanforderungen bei der Dateneingabe (z. Β. Datenformat, Korrektheit). Fachliche Prozesse zur Bereitstellung der Eingangsdaten verbleiben in den Unternehmen, sämtliche technischen Prozesse für die IV sind zentralisiert. Fachliche Prozesse zur Aufbereitung und Die Koordination der Informations- nehmen unabhängig voneinander; Analyse der Daten sowie zur Informatibereitstellung erfolgt durch eine ge- ebenso die technischen Prozesse, die die onsbereitstellung in Berichten sind zentmeinsame Definition von Zeit, Um- Applikationen in den Unternehmen ralisiert. betreffen. fang, Form und Adressat. Das Datenmanagement ist zentralisiert: Die Rücksteuerung bei Qualitätsab- Aufbau eines zusätzlichen Datenbestandes Metadatenmanagement, Stammdatenmafür eine zentralisierte IV. weichungen und der Umsetzung von nagement, Datenaufbereitung (z. B. Maßnahmen erfolgt ebenfalls durch Cleansing) und Datenbereitstellung. eine definierte „offline“-KommuniDie technischen Prozesse sind ebenfalls kation. zentralisiert. Architektur 1: Separate IV Ergebnis Architekturbeschreibung Szenario 2 Hybrid Datensteward (fachlich) in den Unternehmen, je nachdem, wer gerade die Anbieter-Rolle übernimmt. Verantwortung für Datenqualität und Maßnahmen in den Unternehmen, Datensteward (technisch) in jedem Unternehmen. Architektur 2: Kooperative IV Architektur 3: Integrierte IV Wie Architektur 1: Applikationsarchitekturen der beteiligten Unternehmen sind Vollständige Architektur mit integrierter Datenbasis und Analyse- sowie Berichtsunabhängig voneinander; es werden Schnittstellen zu dem gemeinsamen Data applikationen. Warehouse definiert. - Datensteward (fachlich) zur Erhebung, Aufbereitung und Datenqualitätssicherung der Eingangsdaten getrennt in den Unternehmen, Datensteward (technisch) pro Unternehmen, zentraler Datensteward (technisch) mit Verantwortung für die Daten im Data Warehouse. 529 - Datensteward (fachlich) in den Unternehmen, Zentraler Datensteward (technisch). Ausgehend von den Zielen und der Struktur der Architekturen sowie der zuvor erläuterten fachlichen Grundlagen, erfolgt im nächsten Abschnitt die Konzeptionierung von Controllingansätzen für eine leistungsorientierte Steuerung der IV. 4. Controllingansatz für die leistungsorientierte Steuerung der Informationsversorgung Zwei jüngere Ansätze aus der Literatur eignen sich als Grundlage für einen Ansatz zur Leistungssteuerung (für einen Überblick vgl. [17]). Die IS Functional Scorecard nimmt eine Leistungsbewertung der IT anhand der drei Hauptbereiche „Systemleistung“, „Informationswert“ sowie „Serviceleistung“ und entsprechender Kennzahlen für die Bereiche vor. Sie wurde von Chang und King [8] vorgeschlagen und in 149 Unternehmen auf ihre Anwendbarkeit getestet. Sie lässt sich aufgrund ihrer Bandbreite für die verschiedenen Architekturen der IV in Dienstleistungsnetzwerken einsetzen und entsprechend anpassen. Ein zweiter Ansatz, der sich zur Leistungsbewertung der IT eignet, wurde von Heo und Han [16] vorgestellt. Sie haben mit einer Umfrage bei 137 Managern untersucht, inwieweit die IT-Infrastruktur bei der Verwendung bestimmter Bewertungsparameter einen Einfluss hat. So werden, je nach Grad der Zentralisierung oder Dezentralisierung (optimaler Integrationsgrad), hauptsächlich drei Parameter eingesetzt: Die Systemqualität (z. B. Antwortzeiten), die Informationsqualität, gemessen durch Qualitätskriterien (z. B. Vollständigkeit), und schließlich die organisatorische Wirkung (z. B. Grad der Zielerreichung). Wie bereits festgestellt, sind bei der Betrachtung von Dienstleistungsnetzwerken ebenso Transaktionskosten von Bedeutung. Für den endgültigen Ansatz ist demnach die Kostenseite zu ergänzen, da sie augenscheinlich von den beiden vorgestellten Ansätzen vernachlässigt wird. Dort wird lediglich pauschal die Kosteneffizienz erwähnt. Die grundlegenden Elemente eines Controllingansatzes sind die Controllingobjekte („Was wird gesteuert?“), die Controllinginstrumente („Womit werden die Controllingobjekte gesteuert?“) und die Messgrößen bzw. Kennzahlen („Welche Werte wurden erzielt bzw. werden angestrebt?“) [21]. Der hier verwendete Controllingansatz verfolgt das Ziel, die IV für die Qualitätssicherung in Dienstleistungsnetzwerken leistungsorientiert zu steuern. Der Controllingansatz umfasst folgende, auf die IV ausgerichtete Elemente, die sich aus den definierten Kriterien der Szenarien und den Eigenschaften der Architekturen (vgl. Tabelle 1) ableiten: • Controllingobjekte: Controllingobjekte sind die Kostentreiber, die auf ihre Effizienz überprüft werden sollen. In diesem Fall sind das die Berichte, die durch die IV erzeugt werden. Die Berichte setzen sich aus sogenannten Informationsobjekten zusammen, wie z. B. Informationen zu Produkten, Märkten, Kunden. Informationsobjekte erzeugen unterschiedlichen Erhebungsaufwand; deshalb sind sie als Kostentreiber zu untersuchen. Weitere Controllingobjekte sind z. B. Datenmanagement-Prozesse oder Aktivitäten, die den Rollen zugeordnet sind, sowie Architekturkomponenten. • Controllinginstrumente (beispielhaft): Controllinginstrumente sind Methoden und Modelle, die für die leistungsorientierte Steuerung der IV eingesetzt werden können. Hierzu gehören z. B. das Prozess-Controlling, das Activity-based Costing oder das Komplexitätsmanagement der Architekturkomponenten. In Tabelle 2 werden nicht für jede Architektur konkreten Instrumente benannt. Für Architektur 1 wird lediglich eine Stellschraube erwähnt, mit deren Hilfe die relevanten Kennzahlen zu beeinflussen sind (z. B. können durch die Standardisierung der Berichte/Informationsobjekte die Informationskosten gesenkt werden). 530 • Kennzahlen (beispielhaft): Die Kennzahlen werden für die „Systemleistung“, den „Informationswert“ und die „Serviceleistung“ der eingesetzten Infrastruktur pro Architektur definiert (abgeleitet aus [8, 10, 16]). Zusätzlich werden Kostenparameter („Informationskosten“ abgeleitet aus der Transaktionskostentheorie) für die Informationsbereitstellung und die Infrastruktur pro Unternehmen sowie die gemeinsamen Architekturkomponenten erfasst. Der Controllingansatz für Architektur 1 konzentriert sich auf die gemeinsamen Informationsobjekte in den Berichten als Controllingobjekte. Das Instrumentarium zur leistungsorientierten Steuerung zielt auf den Standardisierungsgrad und den geforderten Umfang der Berichte ab. Davon ausgehend werden die IV-Prozesse und die einzusetzende Infrastruktur festgelegt. Ergänzt werden die Überlegungen durch die relevanten „Informationskosten“ für diese Architektur. Der Controllingansatz fokussiert auf die Steuerung der IV für die Koordination der Qualitätssicherung, und so wurden hauptsächlich koordinative Leistungen berücksichtigt. Im Bereich „Informationswert“ werden alle Kennzahlen aus [8] übernommen und teilweise in Tabelle 2 dargestellt. Der Bereich „Serviceleistung“ entfällt komplett, weil nur Berichte erzeugt werden, die keine weitere Serviceleistung beanspruchen. Die „Informationskosten“ bilden den IV-Prozess inklusive Infrastruktur und Koordinationskosten ab. Der Controllingansatz für Architektur 2 wird erweitert um die Steuerung des Data Warehouse und die dazugehörigen Prozesse. Die Controllingobjekte sind also die Informationsobjekte in den Berichten, die Datenmanagement-Prozesse zur Integration der Daten in das Data Warehouse (Extraktion, Transformation, Laden), die Aktivitäten des technischen Datenstewards (z. B. Vorbereitung der Struktur für die Abfragen) sowie die Elemente der Applikationsarchitektur für das Data Warehouse. Die Instrumente setzen wie in Architektur 1 an der Standardisierung der Informationsobjekte und dem Umfang der Berichte an. Darüber hinaus zielen sie auf die Effizienz der IV durch das Data Warehouse ab, z. B. um die Durchlaufzeiten bis zur Berichterstellung zu verbessern oder Antwortzeiten zu verkürzen. Im Bereich der Infrastruktur werden vor allem die Komplexität der Schnittstellen zum Data Warehouse und der zu verwaltende Datenumfang gesteuert. Der Vorschlag für die Kennzahlen baut auf den Auswahlkriterien für Architektur 1 auf und wurde ergänzt durch Kennzahlen, die sich einerseits auf die gemeinsame Nutzung der Infrastruktur beziehen (z. B. „Verbesserung des Bewusstseins für Entscheidungen“, „Zugriff auf Informationen anderer Bereiche“) und andererseits auf die Kosten für die gemeinsame Infrastruktur. Für diese Architektur wird auch der Bereich „Serviceleistung“ relevant, da der Service Integrator zu einem gewissen Grad Serviceleistungen für die gemeinsame Infrastruktur des Netzwerks erbringen muss. Der Controllingansatz für Architektur 3 bedingt die höchsten Anforderungen. Die gemeinsamen Datenmanagement-Prozesse und die gemeinsame Applikationsarchitektur zur IV müssen leistungsorientiert gesteuert werden. Gleichzeitig muss eine „faire“ Leistungsverrechnung erfolgen. Die Controllingobjekte aus Architektur 2 werden durch die Architekturelemente des Q-MIS sowie die erforderlichen Datenmanagement-Prozesse und Aktivitäten der Rollen ergänzt. Die Instrumente, die bereits in den Architekturen 1 und 2 zum Einsatz kommen, werden hier vor allem um die Steuerung der Effizienz der Applikationsarchitektur erweitert. Die Kennzahlen der Architekturen 1 und 2 werden um die Kennzahlen ergänzt, die die Leistungen und Kosten der gemeinsamen Infrastruktur messen und steuerbar machen. Tabelle 2 gibt eine Übersicht der Controllingansätze pro Architektur. 531 Tabelle 2: Controllingansatz pro Architektur Elemente Controllingobjekte Instrumente (beispielhaft) Kennzahlen (beispielhaft) Architektur 1: Separate IV Architektur 2: Kooperative IV Architektur 3: Integrierte IV wie Architektur 1, zusätzlich - Datenmanagement-Prozesse zur Integwie Architektur 2, zusätzlich ration der Daten im Data Warehouse - Architekturelemente des Q-MIS Berichte/Informationsobjekte - Aktivitäten der zentralen Rollen - Datenmanagement-Prozesse - Applikationsarchitekturelemente für das Data Warehouse wie Architektur 1, zusätzlich wie Architektur 2, zusätzlich Standardisierung der Be- Prozess-Controlling - Komplexitätsmanagement hinsichtlich richte/Informationsobjekte - Komplexitätsmanagement der Schnittder Applikationsarchitektur stellen - Systemleistung: Zuverlässigkeit der - Systemleistung: wie Architektur 1, zusätzlich Datenzugreifbarkeit, Antund Zugreifbarkeit auf Berichte - Systemleistung: wie Architektur 2 wortzeiten, Durchlaufzeiten - Informationswert: Nützlichkeit, - Informationswert: wie Architektur 2, - Informationswert: wie Architektur 1 Verfügbarkeit, Verlässlichkeit, zusätzlich Integrierbarkeit - Serviceleistung: Antwortzeiten, Flexibilität - Serviceleistung: wie Architektur 2 Serviceflexibilität, Zuverlässigkeit - Serviceleistung: *entfällt* - Informationskosten: wie Architektur 1, - Informationskosten: wie Architektur 2 - Informationskosten: Recherchezusätzlich Serviceleistungskosten, kosten, Nutzungskosten, InfraKosten für das Data Warehouse strukturkosten, Koordinationskosten 5. Fazit und Ausblick Eine effiziente IV ist ein wichtiger Erfolgsfaktor für die wirtschaftliche Gestaltung von Dienstleistungsnetzwerken. Im vorliegenden Beitrag stand die IV für eine Qualitätssicherung im Mittelpunkt der Untersuchungen. Je nach Zielsetzung und Ausgestaltung der Kooperation kann die Art und Weise sowie die technische Form der IV durch unterschiedliche Architekturen umgesetzt werden. Die Zuordnung zu einem Szenario bzw. die damit verbundene Entscheidung für eine bestimmte Architektur wird durch den geforderten Grad an Unabhängigkeit der Unternehmen und der IV-Flexibilität bestimmt. Darüber hinaus erfolgt ein Einbezug der Informationskosten in die Entscheidung für die fachliche und technische Ausgestaltung der Kooperation. Die leistungsorientierte Steuerung der IV in den Architekturen kann z. B. durch eine kostenseitige Erweiterung der IS Functional Scorecard von Chang und King [8] erfolgen. Der Vorteil liegt darin, dass qualitative und quantitative Faktoren, die die Effizienz der IV beeinflussen, erfasst werden können. Der vorgestellte Ansatz wurde zunächst argumentativ-deduktiv auf Basis bestehender Literatur entwickelt. Die Kriterien zur Beschreibung der Szenarien, die Gründe für die Auswahl einer konkreten Architektur durch die Unternehmen und die relevanten Elemente der Controllingansätze, insbesondere die verwendeten Kennzahlen, die sich bei Chang und King auf Einzelunternehmen beziehen, werden in einem nachfolgenden Schritt durch eine empirische Studie überprüft. Literatur [1] AHLERT, D./EVANSCHITZKY, H.: Dienstleistungsnetzwerke, Springer 2003. [2] BAUER, S./STICKEL, E.: Auswirkungen der Informationstechnologie auf die Entstehung kooperativer Netzwerkorganisationen, in: Wirtschaftsinformatik 40 (1998) 5, S. 434-442. [3] BAUMÖL, U./WINTER, R.: Intentions Value Networks – A Business Model of the Information Age, in: P. Miranda et al.: ICEIS 2001 - Proceedings of the 3rd ICEIS, Setubal 2001, S. 1075-1080. [4] BIRKELBACH, R.: Qualitätsmanagement in Dienstleistungscentern, Peter Lang, Frankfurt et al. 1993. [5] BMWI: Die volkswirtschaftliche Bedeutung des Dienstleistungssektors, auf: Navigation/Wirtschaft/dienstleistungswirtschaft,did=239886.html, Abruf 08-07-30. [6] BRUHN, M: Qualitätsmanagement für Dienstleistungen, Springer, Berlin 2006. 532 http://www.bmwi.de/BMWi/ [7] CHAMONI, P.: Informationsqualität in der Informationslogistik, in: is report 5 (2008) 12, S. 44-45. [8] CHANG, J. C./KING, W. R.: Measuring the Performance of Information Systems: A Functional Scorecard, in: Journal of Management Information Systems 22 (2005) 1, S. 85-115. [9] COASE, R. H.: The nature of the firm, in: Economia 4 (1937), S. 386-405. [10] DELONE, W. H./MCLEAN, E. R.. The DeLone and McLean model of information systems success: A ten-year update, in: Journal of Management Information Systems 19 (2003) 4, S. 9-30 [11] FISCHER, T. M./BECKMANN, S.: Die Informationsversorgung der Mitglieder des Aufsichtsrats – Ergebnisse einer empirischen Studie deutscher börsennotierter Aktiengesellschaften, Arbeitspapier der Universität ErlangenNürnberg, 2007. [12] FRIESE, M.: Kooperation als Wettbewerbsstrategie für Dienstleistungsunternehmen, Wiesbaden 1998. [13] GERPOTT, T. J./BÖHM, S.: Strategisches Management in virtuellen Unternehmen, in: H. Albach/D. Specht/H. Wildemann (Hrsg.), Virtuelle Unternehmen, ZfB-Ergänzungsheft (2000) 2, S. 13-43. [14] GRÖNROOS, C.: A service quality model and its marketing implications, in: European Journal of Marketing 18 (1984) 4, S. 36-44. [15] HAMANN, H.: Informationsversorgung in Transnationalen Unternehmungen, Gabler, Wiesbaden 2004. [16] HEO, J./HAN, I.: Performance measure of information systems (IS) in evolving computing environments: an empirical investigation, in: Information & Management 40 (2003) 4, S. 243-256. [17] HESS, T./KINK, N.: Bewertung von IT-Investitionen, in: Zeitschrift für Controlling und Management 51 (2007) 4, S. 272-275. [18] HÖFFERER, P.: Achieving Business Process Model Interoperability Using Metamodels and Ontologies, in: H. Österle/J. Schelp/R. Winter (Hrsg.), Proceedings of the 15th ECIS, St. Gallen 2007, S. 1620-1631. [19] JANSEN, H.: Verfügungsrechte und Transaktionskosten, in: A. Horsch/H. Meinhövel/S. Paul (Hrsg.). Institutionenökonomie und Betriebswirtschaftslehre, Vahlen, München 2005, S. 101-117. [20] JONES, C. ET AL.: Professional Service Constellations: How Strategies and Capabilities Influence Collaborative Stability and Change, in: Organization Science 9 (1998) 3, S. 396-410. [21] KÜTZ, M.: Grundelemente des IT-Controllings, in: M.Kütz/A. Meier (Hrsg.), IT-Controlling, HMD 254 (2007) 4, S. 6-15. [22] KÜTZ, M.: Kennzahlen in der IT, Dpunkt, Heidelberg 2007. [23] MELDAU, S.: Qualitätsmessung in Dienstleistungscentern, Gabler, Wiesbaden 2007. [24] MICHALSKI, T.: Strategische Entwicklungsperspektiven von innovativen wissensintensiven Dienstleistungsangeboten in Wertschöpfungsnetzwerken, in: M. Bruhn/B. Stauss (Hrsg.), Dienstleistungsnetzwerke, Gabler, Wiesbaden 2003, S. 63-85. [25] MILES, R. E./SNOW, C. C.: Organizations: New concepts for new forms, in: California Management Review 28 (1986) 3, S. 62-72. [26] OTTO, B. ET AL.: Unternehmensweites Datenqualitätsmanagement. Ordnungsrahmen und Anwendungsbeispiele, in: B. Dinter/R. Winter (Hrsg.), Integrierte Informationslogistik, Springer, Berlin 2008, S. 211-230[27] PARASURAMAN, A. ET AL.: A Conceptual Model of Service Quality and its Implications for Future Research, in: Journal of Marketing 49 (1985), S. 41-50. 533 [28] PICOT, A. ET AL.: Die grenzenlose Unternehmung. Information, Organisation und Management, 5. Aufl., Gabler, Wiesbaden 2003. [29] SCHWINN, A./WINTER, R.: Entwicklung von Zielen und Messgrößen zur Steuerung der Applikationsintegration, in: O. K. Ferstl et al (Hrsg.), Wirtschaftsinformatik 2005, Heidelberg 2005, S. 587-606. [30] SETH, N. ET AL.: SSQSC: a tool to measure supplier service quality in supply chain, in: Production Planning & Control 17 (2006) 5, S. 448-463. [31] STAUSS, B./BRUHN, M.: Dienstleistungsnetzwerke – Eine Einführung in den Sammelband, in: M. Bruhn/ B. Stauss (Hrsg.), Dienstleistungsnetzwerke, Gabler, Wiesbaden 2003, S. 3-30. [32] SYDOW, J.: Strategische Netzwerke. Evolution und Organisation, Gabler Verlag, Wiesbaden 1992. [33] VOSS, S./GUTENSCHWAGER, K.: Informationsmanagement, Springer, Berlin 2001. [34] WILDE, T./HESS, T.: Forschungsmethoden der Wirtschaftsinformatik. Eine empirische Untersuchung in: Wirtschaftsinformatik 49 (2007) 4, S. 280–287 [35] WILLIAMSON, O. E.: The Economics of Organization: The Transaction Cost Approach, in: The American Journal of Sociology 87 (1981) 3, S. 548-577. 534 VORGEHENSMODELL ZUR ENTWICKLUNG VON REIFEGRADMODELLEN Ralf Knackstedt, Jens Pöppelbuß, Jörg Becker1 Kurzfassung Reifegradmodelle stellen für das IT-Management ein wichtiges Instrument dar, weil sie die Positionierung der eigenen Organisation ermöglichen und Entwicklungsrichtungen aufzeigen. Obwohl eine Vielzahl Reifegradmodelle entwickelt wurden, ist die Dokumentation des Vorgehens zu ihrer Entwicklung verhältnismäßig lückenhaft. Der vorliegende Beitrag will helfen, diese Lücke zu schließen, indem auf der Basis wissenschaftstheoretischer Überlegungen Anforderungen an die Entwicklung von Reifegradmodellen abgeleitet, anhand dieser Kriterien einige der wenigen dokumentierten Vorgehensweisen verglichen und die Ergebnisse in einem allgemeingültigen Vorgehensmodell zusammengefasst werden. 1. Bedeutung von Reifegradmodellen für das IT-Management Für eine stetige Verbesserung des IT-Managements ist die Standortbestimmung im Hinblick auf die informationstechnischen Fähigkeiten und die Güte der eigenen Leistung grundlegend. Für jeden zu untersuchenden Aspekt der unternehmenseigenen IT ist dabei festzulegen, welche Merkmale mittels welcher Messvorschriften beurteilt werden müssen, um die Ist-Situation zu bestimmen und dieser eine definierte Güte bzw. Reife zuzuweisen. Reifegradmodelle (engl.: Maturity Models) stellen hilfreiche Instrumente zur Klärung dieser Fragen dar [5]. Ein Reifegradmodell umfasst eine Folge von Reifegraden für eine Klasse von Objekten und beschreibt dadurch einen antizipierten, gewünschten oder typischen Entwicklungspfad dieser Objekte in aufeinander folgenden diskreten Rangstufen; beginnend in einem Anfangsstadium bis hin zur vollkommenen Reife. Das Fortschreiten auf diesem Entwicklungspfad bedeutet zumeist eine stete Steigerung der Leistungsfähigkeit bzw. Güte des betrachteten Objekts, wobei das Reifegradmodell als Skala zur Beurteilung dient. Ein Reifegrad ist durch festgelegte Merkmale des zu untersuchenden Objekts und durch die jeweils zur Erreichung des Reifegrads erforderlichen Merkmalsausprägungen definiert. Die Anwendung des Reifegradmodells zur Ermittlung individueller Reifegrade von Objekten erfolgt häufig mittels vorgegebener Assessment-Methoden (z. B. Fragebögen). Zu einem gegebenen Zeitpunkt werden Beobachtungen gesammelt und validiert, um eine Zustandsaufnahme des betrachteten Objekts zu erhalten. Häufig werden Prozesse durch Reifegradmodelle 1 Westfälische Wilhelms-Universität Münster, European Research Center for Information Systems, Leonardo-Campus 3, 48149 Münster 535 beurteilt. Als Ergebnis werden dann einheitliche und überprüfbare Aussagen zu ihrem Status und zur Qualität ihrer Durchführung erwartet. Ausgehend von der ermittelten Ist-Situation lassen sich Verbesserungsvorschläge und Handlungsempfehlungen ableiten [8]. Als einer der Ersten präsentierte Nolan mit seiner Stage Theory ein mehrstufiges Reifegradmodell im Kontext von Informationssystemen [12]. Sein Modell identifiziert basierend auf empirischen Untersuchungen aufeinander folgende Entwicklungsstufen der Informationsverarbeitung. Seitdem wurden Reifegradmodelle für eine große Bandbreite unterschiedlicher Aspekte der IT von verschiedenen Gruppen, wie z. B. Wissenschaftlern, Beratern, Praktikern sowie regierungsabhängigen und -unabhängigen Organisationen entwickelt. Als das bekannteste Reifegradmodell gilt das Capability Maturity Model (CMM), das ab 1986 im Rahmen einer Initiative des USVerteidigungsministeriums am Software Engineering Institute (SEI) der Carnegie Mellon University in Pittsburgh entwickelt wurde. Es beschreibt Reifegrade von Softwareentwicklungsprozessen und diente für viele weitere Reifegradmodelle als Entwicklungsgrundlage. Recherchen zeigen, dass mehr als hundert verschiedene Reifegradmodelle vorgeschlagen werden [5]. Die Veröffentlichung immer neuer Reifegradmodelle für häufig sehr ähnliche Anwendungsbereiche erweckt aber zunehmend den Eindruck einer gewissen Beliebigkeit der vorgeschlagenen Modelle. Nur in seltenen Fällen wird überhaupt offen gelegt, wie die Entwicklung eines neuen Reifegradmodells motiviert war, in welchen Schritten es entwickelt wurde, wer an diesen Schritten beteiligt war und ob und wie evaluiert wurde, dass das neue Modell seine Funktion erfüllt. Forschungsziel des vorliegenden Beitrags ist es, ein Vorgehensmodell zur Entwicklung von Reifegradmodellen zu entwickeln, dessen Befolgung diesen verbreiteten Mängeln entgegenwirkt. Zunächst werden Kriterien identifiziert, die an den Entwicklungsprozess von Reifegradmodellen zu stellen sind (Abschnitt 2). Anhand dieser Kriterien werden Entwicklungsprozesse der wenigen hinsichtlich dieses Aspektes ausführlich dokumentierten Reifegradmodelle miteinander verglichen (Abschnitt 3). Die hieraus gewonnenen Erkenntnisse bilden die Grundlage für die Konstruktion des Vorgehensmodells zur Entwicklung von Reifegradmodellen (Abschnitt 4). Hinweise auf weiterführende Forschungsvorhaben schließen den Beitrag ab (Abschnitt 5). 2. Kriterien an die Entwicklung von Reifegradmodellen Reifegradmodelle stellen Artefakte zur Lösung des Problems der Standortbestimmung und Ableitung von Verbesserungsvorschlägen dar (vgl. Abschnitt 1). Dementsprechend wird der Ableitung von Kriterien an die Reifegradmodellentwicklung im Folgenden zu Grunde gelegt, dass die Entwicklung eines Reifegradmodells Gegenstand von Design Science Research ist. Design Science strebt eine Verbesserung der Problemlösungsfähigkeit durch die Schaffung innovativer ITArtefakte an [6]. Die im Rahmen von Design Science geschaffenen Artefakte umfassen sämtliche Elemente, die bei der Entwicklung von Informationssystemen zu berücksichtigen sind. Hierbei handelt es sich insbesondere um Sprachkonstrukte, Modelle, Methoden und Implementierungen [6]. Da Reifegradmodelle solche Artefakte darstellen, sind die an Design Science zu stellenden Anforderungen auch auf die Entwicklung von Reifegradmodellen anzuwenden. Nach [10] und [6] soll Design Science in einer mehrfachen Wiederholung zweier aufeinander folgender Phasen erfolgen. In der ersten Phase wird das Artefakt entwickelt, in der zweiten Phase wird es auf seinen Problemlösungsbeitrag hin evaluiert. Dem Bild einer Spirale folgend soll so nach Möglichkeit ein immer höheres Niveau der Problemlösungsqualität und ihres empirischen Nachweises erreicht werden. Es reicht demnach nicht, Artefakte lediglich zu schaffen, sondern diese sind 536 in Bezug auf den Nutzen, den sie für den vorliegenden Problembereich und Anwender stiften, zu evaluieren. [6] definieren sieben Richtlinien (Guidelines), die die Durchführung von Design Science leiten sollen. Basierend auf den Ausführungen von [6] und weiterer Literatur zu Design Science im Kontext der Wirtschaftsinformatik (engl.: Information Systems) präsentieren [15] ein generisches Prozessmodell zur Durchführung von Design Science, welches explizit die iterative Wiederholung von Prozessschritten sowie vier verschiedene Einstiegspunkte in die Entwicklung von Artefakten vorsieht. Diese Arbeiten bilden im Folgenden die Grundlage, um wesentliche Kriterien an den Entwicklungsprozess von Reifegradmodellen zu identifizieren. Ziel von Design Science ist die Entwicklung eines innovativen Problemlösungsartefakts (Richtlinie „Artefakte als Designergebnis“, Nr. 1), das einen Beitrag zum bisherigen Stand der Forschung liefert (Richtlinie „Forschungsbeitrag“, Nr. 4). Als Konsequenz für den Entwicklungsprozess von Reifegradmodellen ergibt sich hieraus: • K1 (Vergleich mit existierenden Reifegradmodellen): Die Notwendigkeit eines zu entwickelnden Reifegradmodells ist durch einen Vergleich mit bestehenden Reifegradmodellen zu begründen. Die Prozessbeschreibung von Design Science sieht ein iteratives Vorgehen zur Entwicklung des Problemlösungsbeitrags vor. Die Richtlinie „Design als Suchprozess“ (Nr. 6) betont ebenfalls, dass eine Lösung iterativ unter Verwendung der jeweils verfügbaren Mittel vorgeschlagen, verfeinert und evaluiert und ggf. weiterentwickelt wird. Auf die Entwicklung eines Reifegradmodells bezogen bedeutet dies: • K2 (Iteratives Vorgehen): Reifegradmodelle sind iterativ in mehreren Schritten zu entwickeln. • K3 (Evaluation): Die in die Reifegradmodellentwicklung eingehenden Grundlagen und Prämissen, sowie die Funktionserfüllung durch das Instrument selbst sind in den einzelnen Schritten zu evaluieren. Die Notwendigkeit der Evaluation wird auch von der Richtlinie „Evaluation“ (Nr. 3) betont. Dabei wird hervorgehoben, dass die Evaluation der (Zwischen-)Ergebnisse mit geeignet zu wählenden wissenschaftlichen Methoden zu erfolgen hat. Aus dem Umstand, dass für die Entwicklung des Artefakts selbst und für die Evaluation der jeweiligen Ergebnisse unterschiedliche Methoden eingesetzt werden können, folgt, dass Design Science in der Regel multimethodisch erfolgt. Dies wird von einigen Autoren auch als grundlegendes Charakteristikum von Design Science postuliert [6]. Die gewählten Methoden sind dabei stringent aufeinander abzustimmen, wie die Richtlinie „Stringenz der Forschungsmethoden“ (Nr. 5) betont. Dementsprechend ergibt sich folgendes Kriterium: • K4 (Multimethodisches Vorgehen): Die Entwicklung von Reifegradmodellen bedient sich unterschiedlicher Forschungsmethoden, deren Einsatz jeweils begründet zu wählen und aufeinander abzustimmen ist. Die Richtlinie „Problemrelevanz“ (Nr. 3) besagt, dass das Problemlösungsartefakt nicht nur innovativ, sondern dass das zu lösende Problem auch relevant für Forschung und/oder Praxis sein soll. Dies kann wiederum mit unterschiedlichen wissenschaftlichen Methoden gezeigt werden, z. B. durch eine Befragung zukünftiger potenzieller Nutzer des Reifegradmodells. Der Nachweis der Relevanz erfordert zudem eine genaue Definition des zu lösenden Problems, was für nachfolgende Evaluationen ebenfalls Voraussetzung ist. Deshalb werden die folgenden Kriterien betrachtet: • K5 (Aufzeigen der Problemrelevanz): Der Bedarf eines Problemlösungsbeitrags in Form des zu entwickelnden Reifegradmodells in Forschung und/oder Praxis ist darzulegen. 537 • K6 (Problemdefinition): Der zukünftige Anwendungsbereich des Reifegradmodells einschließlich seiner Einsatzvoraussetzungen und der mit dem Reifegradmodell angestrebte Nutzen sind vor der Entwicklung festzulegen. Von grundlegender Bedeutung für wissenschaftliches Vorgehen ist die Dokumentation des Forschungsprozesses selbst. Die Richtlinie „Kommunikation der Forschungsergebnisse“ (Nr. 7) betont, dass die Ergebnisse den verschiedenen Nutzergruppen adressatengerecht zu präsentieren sind. Neben den in [6] im Vordergrund stehenden praktisch orientierten Nutzern, stellen auch Wissenschaftler Ansprüche an die Kommunikation, die im Gegensatz zu denen der Nutzer neben der Ergebnisdarstellung auch die Darstellung des Forschungsprozesses betreffen. Dementsprechend sollen des Weiteren die folgenden beiden Kriterien berücksichtigt werden: • K7 (Adressatengerechte Ergebnisbereitstellung): Das Reifegradmodell ist den Nutzern in adressatengerechter Weise, d. h. unter Berücksichtigung ihrer Anwendungsvoraussetzungen und -interessen, zur Verfügung zu stellen. • K8 (Wissenschaftliche Dokumentation): Der Prozess der Entwicklung des Reifegradmodells ist hinsichtlich der Einzelschritte, Beteiligten, angewendeten Methoden und Ergebnisse ausführlich zu dokumentieren. 3. Vergleich der Entwicklungsprozesse einzelner Reifegradmodelle Anhand der zuvor wissenschaftstheoretisch begründeten Kriterien sollen im Folgenden bestehende Reifegradmodelle miteinander verglichen werden. Eine wesentliche Voraussetzung für die Durchführung dieses Vergleichs bildet das Kriterium K8 (Wissenschaftliche Dokumentation), da dieses eine ausführliche Dokumentation des Entwicklungsprozesses bedingt. Diesbezüglich konnten acht Reifegradmodelle als geeignet für eine eingehende Analyse ihrer Entwicklungsprozesse identifiziert werden, von denen fünf nachfolgend in einer Synopse bezüglich der hergeleiteten Kriterien gegenübergestellt (vgl. Tabelle 1) werden. Hierzu zählen zum einen das Analysis Capability Maturity Model (ACMM), welches für das USamerikanische National Reconnaissance Office (NRO) entwickelt wurde. Es dient dazu, Bewertungen der Prozesse von Organisationen vorzunehmen, die z. B. für die öffentliche Hand Analysen erstellen [3]. Reifegrade können dann bei der Vergabe von wichtigen Studien zu Rate gezogen werden. Als zweites Modell wird das Reifegradmodell zur Business Process Management Maturity (BPMM) von [17] untersucht. Die Entwicklung dieses Modells wurde durch die Feststellung motiviert, dass bisherige Reifegradmodelle sich auf einzelne Facetten des Geschäftsprozessmanagements beschränken und daher nicht zufriedenstellen. Die Entwickler betonen insbesondere, dass ihr Entwicklungsprozess wissenschaftlichen Ansprüchen genügen soll [5]. Als Drittes wird das Capability Maturity Model Integration (CMMI) in die Synopse eingeschlossen. Das CMMI integriert verschiedene Modelle, die im Umfeld des äußerst populären, ursprünglichen Capability Maturity Model (CMM) entstanden sind. Es beschränkt sich nicht mehr nur auf Softwareentwicklungsprozesse, sondern betrachtet sowohl die Produktentwicklung, den Produkteinkauf als auch die Serviceerbringung [2]. Des Weiteren findet das von der Victoria University of Wellington in Neuseeland veröffentlichte E-Learning Maturity Model (eMM) Berücksichtigung. Es soll Institutionen wie z. B. Hochschulen dazu dienen, ihre Fähigkeiten in Bezug auf die nachhaltige Entwicklung, Einführung und Nutzung von E-Learning zu messen und mit anderen Institutionen zu vergleichen [11]. Erste, auf dem eMM basierende Benchmarking-Studien wurden bereits in Neuseeland durchgeführt. Abschließend wird mit dem IS/ICT Management Capability Maturity Framework (IC/ICT CMF) ein Reifegradmodell zum IT-Management präsentiert [18]. Es ist das Ergebnis eines For- 538 schungsprojekts mit dem Ziel, ein möglichst umfassendes Modell zur Bestimmung von Reifegraden der Leistungsfähigkeit des IT-Managements zu entwickeln. Nicht dargestellt werden die folgenden ebenfalls vergleichsweise gut dokumentierten Modelle: das Business Process Maturity Model (BPMM Lee) [9], da hierzu weniger Dokumentation vorhanden ist als zum betrachteten Reifegradmodell der gleichen Domäne (BPMM Rosemann); das Capability Maturity Model (CMM) [14], da dies ein Vorgänger des betrachteten CMMI ist; und das Knowledge Management Capability Assessment (KMCA) [5], da sein Entwicklungsprozess in den Hauptphasen mit dem des BPMM von Rosemann übereinstimmt [17]. Auffällig ist, dass im Vorfeld der Entwicklung aller fünf betrachteten Modelle zunächst eine Sichtung bestehender Reifegradmodelle erfolgte. Ebenso lässt sich jeweils ein iteratives Vorgehen feststellen, bei dem insbesondere die Evaluation von Zwischenversionen in Case Studies zu anschließenden Modellveränderungen geführt hat. Umfangreiche Literaturrecherchen legten durchweg die Basis für die Kernelemente der Reifegradmodelle und wurden häufig durch Konsultation von Domänenexperten ergänzt. Die Problemrelevanz wurde in Einzelfällen durch einen konkreten Auftrag aufgezeigt, basierte jedoch häufig auf einer eher allgemeinen Herleitung. Die Problemdefinitionen stellen insbesondere Beurteilung und Vergleich von Unternehmen im Hinblick auf ihre Fähigkeiten in spezifischen Domänen in den Vordergrund. Die Art und Weise der Ergebnisbereitstellung variiert stark und reicht von einem einzelnen Konferenzbeitrag bis hin zu hundertseitigen Berichten und Vorgehensbeschreibungen. Frei verfügbare Fragebögen für ein Self-Assessment heben sich in diesem Zusammenhang positiv hervor. Tabelle 1: Synopse zu den Entwicklungsprozessen von Reifegradmodellen Kriterium Vergleich mit existierenden Reifegradmodellen (K1) Iteratives Vorgehen (K2) Analysis Capability Maturity Model (ACMM) •Vergleich mit CMMI •Orientierung an CMMI-Stufen Business Process Capability Management Maturity Model Maturity Integration (BPMM) (CMMI) •Analyse existieren- •Übertragung von Crosby’s Quality der Reifegradmodelle zum Business Maturity Grid auf die SoftwareProcess Manageentwicklung ment, die nicht zufriedenstellen •Entwicklung eines ersten Modells durch Literaturrecherche und Expertenbefragungen •Integration von Prozessbereichen des CMMI •Modellveränderungen in Folge einer Case Study •Zunächst Herleitung von vier Dimensionen •„Factor“Dimension umfasst zunächst fünf Faktoren •Einsatz von Delphi-Studien zur Ermittlung von „Factors“ und untergeordneten Fähigkeitsbereichen •Zunächst Entwicklung des Software Process Maturity Framework (SPMF) •Weiterentwicklung zum CMM •Integration mit anderen Modellen zum CMMI •Jeweils Reviews von Zwischenversionen 539 E-Learning Maturity Model (eMM) IS/ICT Capability Maturity Framework (IS/ICT CMF) •Analyse von ITManagementReifegradmodellen (Nolan’s Stage Theory, CMM, Strategic Grid) •Übernahme von Konzepten des CMM und SPICE (Software Process Improvement and Capability Determination) •Anwendung in •Identifikation Case Studies und initialer IndikatoWorkshops führten ren durch Literaturzu Änderungen des recherche Modells •Iterative Modellierung zur Eliminierung und Kombination von Indikatoren •Validierung durch Interviews •Finale Anpassungen Kriterium Evaluation (K3) Analysis Business Process Capability Management Maturity Model Maturity (ACMM) (BPMM) •Anwendung in •Anwendung in einer Case Study Case-Studies im durch unabhängige Verlauf von zwei Personen Jahren •Keine Evaluation •Explorative Studer Reifegrade vier dien und fünf •Einsatz von Delphi-Studien zur Festlegung von Modellkomponenten Multimethodisches Vorgehen (K4) •Literaturrecherche zu Phasen von Analyseprozessen •Expertenbefragung Aufzeigen der Problemrelevanz (K5) •Entwicklung im Auftrag des USamerikanischen National Reconnaissance Office (NRO) Problemdefinition (K6) Adressatengerechte Ergebnisbereitstellung (K7) •Literaturrecherche •Delphi-Methode •Expertenbefragungen Capability Maturity Model Integration (CMMI) •Vorversionen des CMM wurden zur Beurteilung zugänglich gemacht (Reviews) •Diskussion des CMM v1.0 auf einem Workshop mit ca. 200 Fachkräften •Verbreitete praktische Anwendung •Literaturrecherche zum Thema Produktqualität E-Learning Maturity Model (eMM) •Validierung der ersten Version an einer neuseeländischen Universität •Workshops in Australien und Großbritannien •Anwendung in weiteren Organisationen •Literaturrecherche zu E-LearningProzessen •Prozessmanagement ist laut Studien wichtiges Thema für Unternehmen, welche nach unterstützenden Werkzeugen für ihre Initiativen suchen •Bewertung von •Einordnung von Organisationen, die Unternehmen im Analysen erstellen Hinblick auf ihre Prozessmanagementfähigkeiten •Ursprünglich Regierungsauftrag für die Erstellung von Instrumenten zur Beurteilung von Softwareunternehmen •Wenige empirisch fundierten Erkenntnisse zum Erfolg und Misserfolg von E-LearningInitiativen •Entwicklung eines Werkzeugs zur Beurteilung von Softwareunternehmen •Unterstützung des Vergleichs von Hochschulen o. ä. •Wissenstransfer bzgl. E-Learning •Priorisierung von Investitionen in ELearning-Systeme •66-seitiger Bericht inkl. Modell- und Vorgehensbeschreibung •Wissenschaftliche Publikationen •Bisher keine vollständige Modell- und Vorgehensbeschreibung •573-seitiger Bericht •Separate 246seitige Vorgehensbeschreibung (SCAMPI) •Umfangreiche Webseite •Modell und Vorgehensbeschreibung •Excel-Fragebogen •Beispiele •[5, 17] •[2, 7, 13, 14] •[11] Wissen•[3] schaftliche Dokumentation (K8) IS/ICT Capability Maturity Framework (IS/ICT CMF) •Semi-strukturierte Interviews bzgl. Indikatoren •Ausblick: Quantitative empirische Untersuchung zur Validierung, Implementierung eines AssessmentTools, Benchmarking-Studie •Literaturrecherche •Interative Modellierung •Semi-strukturierte Interviews •Andere Autoren weisen auf den Bedarf der Zusammenführung fragmentierter Ansätze zur Verbesserung des ITManagements hin •IT-Management steht immer neuen und komplexen Herausforderungen gegenüber •Ansätze zur Unterstützung des ITManagements sind fragmentiert •Nur Konferenzbeitrag •[18] 4. Vorgehensmodell für die Entwicklung von Reifegradmodellen Im Folgenden wird ein Vorgehensmodell entwickelt, das acht Phasen der Reifegradmodellentwicklung unterscheidet (vgl. Abbildung 1). Die Vorgehensmodellelemente motivieren sich aus den identifizierten Kriterien. In der graphischen Darstellung des Vorgehensmodells ist dies durch die Annotation der Kriterien an die Vorgehensmodellelemente festgehalten. Das Kriterium K8 wird durch den Ausweis der im Rahmen der Reifegradmodellentwicklung entstehenden Dokumente berücksichtigt, worauf die Zuordnung des Kriteriums K8 zu dem Dokument-Symbol in der Legende hinweist. Außerdem generalisiert das Modell die untersuchten gut dokumentieren Entwicklungspro- 540 zesse. Die Generalisierung wird im Text durch Bezugnahme auf die vorgestellte Synopse dokumentiert. Ausgangpunkt bildet die Problemdefinition. Die initiale Definition des zu lösenden Problems wird in allen untersuchten Beispielen vorgenommen. Dabei werden der adressierte Bereich (z. B. gesamtes IT-Management (vgl. IS/ICT CMF [16]) vs. dessen Teildisziplin (vgl. CMM [14])), und die Zielgruppen (z. B. unternehmensintern vs. -extern) des Reifegradmodells festgelegt. Hierbei sollte auch die Relevanz des adressierten Problems dediziert nachgewiesen werden. Von den untersuchten Modellen wird die Bedeutung der gewählten Problemstellung aber zumeist nur über die Bedeutung des adressierten Bereichs allgemein plausibilisiert. CMMI verweist auf einen Regierungsauftrag. Abbildung 1: Vorgehensmodell für die Reifegradmodellentwicklung Ein Vergleich bestehender Reifegradmodelle findet sich bei allen untersuchten Beispielen. Allerdings variiert der Umfang des Vergleichs. Häufig werden Schwächen eines bekannten Modells zum Anlass für eine Weiterentwicklung genommen (vgl. ACMM [3], BPMM [5]). Dabei unterbleibt gelegentlich die Suche nach weiteren Modellen, die diese Schwächen ggf. bereits adressieren. Neben dieser von der Problemdefinition angestoßenen aktiven Suche nach existierenden Modellen, kann auch die Veröffentlichung eines neuen Reifegradmodells von Dritten einen Modellvergleich initiieren. Dabei ist zu prüfen, ob das neue Modell Anregungen zur Modifikation des selbst entwickelten Reifegradmodells bietet. 541 Ein umfassender Vergleich ist Voraussetzung für eine begründete Festlegung der Entwicklungsstrategie. Mit der vollständigen Neuentwicklung, der Weiterentwicklung eines einzelnen Reifegradmodells (vgl. CMM [14]), der Kombination mehrerer Modelle zu einem neuen Reifegradmodell (vgl. CMMI [2]) und der Übertragung von Strukturen (vgl. eMM [11]) oder Inhalten (vgl. ACMM [3]; IS/ICT CMF [16]) bestehender Reifegradmodelle auf neue Anwendungsbereiche lassen sich Basisstrategien unterscheiden. Die zentrale Phase des Vorgehensmodells bildet die iterative Reifegradmodellentwicklung. In einer mehrfachen Wiederholung werden die Teilschritte Gestaltungsbereich festlegen, Vorgehen wählen, Modellbereich gestalten und Ergebnis prüfen durchlaufen. Der Gestaltungsbereich der höchsten Abstraktionsstufe stellt die Architektur, d. h. die grundlegende Struktur des Reifegradmodells dar. Neben einer eindimensionalen Folge diskreter Stufen (vgl. IT BSC Maturity Model [18]) ist die multidimensionale Reifegraderhebung verbreitet (vgl. IS/ICT CMF [16]). Die verschiedenen Dimensionen können dabei hierarchisch geordnet werden (vgl. BPMM [5]). Unterhalb der Wahl dieser grundlegenden Strukturentscheidung sind die einzelnen Dimensionen und ihre einzelnen Merkmalsausprägungen zu gestalten. Für die Gestaltung der einzelnen Bereiche sind geeignete Vorgehensweisen zu wählen. Verbreitet sind Literaturanalysen (vgl. eMM [11]), die z. B. aus Erfolgsfaktoren und typischen Entwicklungsverläufen Beurteilungskriterien für das Reifegradmodell ableiten. Explorative Forschungsmethoden wie z. B. die Delphi-Methode (vgl. BPMM [4]) und Kreativitätstechniken (vgl. bspw. die iterative Konsolidierung von Indikatoren beim IS/ICT CMF [16]) können ebenfalls zum Einsatz kommen. Im Anschluss wird der zuvor gewählte Modellbereich gemäß dem gewählten Vorgehen gestaltet. Anschließend ist das Ergebnis insbesondere auf Vollständigkeit, Konsistenz und Problemadäquanz zu prüfen. Das Ergebnis dieser Prüfung entscheidet über die Fortsetzung der iterativen Reifegradentwicklung. Im Anschluss an die eigentliche Entwicklung des Reifegradmodells ist im Rahmen der Konzeption von Transfer und Evaluation über die Form des Transfers des Entwicklungsergebnisses in Theorie und Praxis zu entscheiden. Die adressatengerechte Kommunikation des Reifegradmodells kann dabei unterschiedliche Formen annehmen. Neben der verbreiteten Bereitstellung von dokumentbasierten Checklisten (vgl. eMM [11]) und Handbüchern (vgl. CMMI [2]) ist ebenfalls eine softwarewerkzeuggestützte Bereitstellung des Reifegradmodells insbesondere auch über das Internet möglich. Bereits bei der Konzeption des Transfers sind die Möglichkeiten zur Evaluation des Problemlösungsbeitrags des Reifegradmodells mit einzuplanen. Diese Forderung stellt z. B. sicher, dass bereits bei der Schaffung der Kommunikationsmittel den Anwendern die Möglichkeit zum Feedback gegeben wird (z. B. Fragebogen oder Formulare für Änderungsanforderungen in den Benutzerhandbüchern, ausführliche Datensammlung durch die Softwarewerkzeuge). Sofern die Evaluation die Unterscheidung verschiedener Gruppen beinhaltet, so ist bei der Konzeption des Transfers zu berücksichtigen, wie sich ggf. eine Experimentgruppe von einer Kontrollgruppe trennen lässt. In den untersuchten Entwicklungsprojekten wird von diesen Integrationspotenzialen relativ wenig Gebrauch gemacht. Eine quantitative Auswertung der Nutzung eines softwarebasierten Assessment-Instruments wird für das IS/ICT CMF in Aussicht gestellt. Die Implementierung der Transfermittel ist dafür zuständig, das Reifegradmodell den verschiedenen zuvor festgelegten Anwendergruppen auf die geplante Art und Weise verfügbar zu machen. Bei den untersuchten Projekten dominiert die Bereitstellung umfangreicher Berichte (vgl. ACMM [3], CMMI [2]). Fragebogen zum Self-Assessment sind teilweise verfügbar (vgl. eMM [11]), werden jedoch häufig aus kommerziellen Gründen nicht allgemein zugänglich gemacht (z. B. wenn Unternehmensberatungen Reifegradmodelle als Werkzeug für ihre eigene Geschäftstätigkeit entwickeln). 542 Im Rahmen der Durchführung der Evaluation ist festzustellen, inwieweit das Reifegradmodell seinen ursprünglich angestrebten Nutzen bewirkt und eine verbesserte Lösung zur Bestimmung der Ist-Situation, der Ableitung und Priorisierung von Verbesserungsmaßnahmen sowie der anschließenden Fortschrittskontrolle im von der Problemdefinition adressierten Bereich für die jeweilige Zielgruppe darstellt. Dabei sind die zuvor definierten Ziele mit realweltlichen Beobachtungen zu vergleichen. Die untersuchten Projekte setzen zu diesem Zweck hauptsächlich Case Studies ein, in deren Rahmen sie einem ausgewählten kleinen Kreis das Reifegradmodell zur Anwendung überlassen (vgl. BPMM [5]). Eine gegensätzliche Alternative stellt die freie Bereitstellung des Modells über das Internet dar. Dies hat den Vorteil, dass eine Vielzahl von Nutzern im Rahmen des webbasierten Self-Assessment eine große Zahl an Datensätzen generieren, die mit den Erwartungen hinsichtlich der Verteilung der Reifegrade in der Unternehmenspraxis abgeglichen werden können. Die Ergebnisse der Evaluation können eine Weiterentwicklung des Reifegradmodells bewirken. Auch die Veränderung der Konzeption von Transfer und Evaluation unter unveränderter Beibehaltung des eigentlichen Reifegradmodells ist denkbar. Negative Evaluationsergebnisse können außerdem zum Verwerfen des Reifegradmodells führen, was damit verbunden werden sollte, das Modell bewusst, ausdrücklich und nach Möglichkeit aktiv vom Markt zu nehmen. Dieser Schritt kann auch dann notwendig werden, wenn veränderte Rahmenbedingungen das Reifegradmodell ungültig werden lassen. Darüber hinaus ist es möglich, dass mehrere existierende Reifegradmodelle durch ein neues integriertes Modell abgelöst werden sollen, wie es z. B. bei der Entwicklung des CMMI der Fall war [2]. 5. Ausblick Mit der großen Zahl der in den letzten Jahren entwickelten Reifegradmodelle geht die Gefahr einer zunehmenden Beliebigkeit in ihrer Entwicklung einher. Indem die Entwicklung von Reifegradmodellen als Gegenstand von Design Science aufgefasst wurde, konnten in diesem Beitrag begründete Anforderungen an die Entwicklungsprozesse formuliert und ein geeignetes Vorgehensmodell entwickelt werden. Diese Ergebnisse bieten eine Anleitung für eine methodisch fundierte Entwicklung und Evaluation von Reifegradmodellen. Insbesondere wenn Reifegradmodelle nicht nur den Status eines Marketinginstruments von Beratungsunternehmen erlangen sollen, ist ein solches fundiertes Vorgehen unerlässlich. Das hier präsentierte Vorgehensmodell stellt eine Referenz dar, die zur Beurteilung von Reifegradmodellen, auch im Rahmen von wissenschaftlichen Reviewverfahren, eingesetzt werden kann. Weitere Forschungsarbeiten eröffnen sich in der wissenschaftlich begleiteten Anwendung des vorgestellten Vorgehensmodells. Die Entwicklung eines eigenen Reifegradmodells zum IT Performance Measurement bildet dabei den Rahmen für die Anwendung des hier hergeleiteten Vorgehens. Dabei wird das Ziel verfolgt, dem IT-Management ein Werkzeug zur strukturierten Fortentwicklung des Einsatzes von Business Intelligence (BI) an die Hand zu geben. Es soll Reifegrade in der Nutzung von BI-Systemen zur Umsetzung des IT Performance Managements beschreiben und damit eine Lücke im Spektrum bestehender Reifegradmodelle schließen, welche bisher schwerpunktmäßig entweder dem IT-Management (z. B. [16, 18]) oder dem Einsatz von BI-Systemen (z. B. [1]) gewidmet sind. Als ein weiteres Anwendungsgebiet des Vorgehensmodells soll die als hybride Wertschöpfung bezeichnete Integration von Produktion und Dienstleistung adressiert werden. Die Bewertungsdimensionen können dabei unterschiedliche Bereiche der Integration von Produzenten und Dienstleistern berücksichtigen, angefangen bei der Unternehmenskultur, über die Integration der Prozesse, bis hin 543 zu abgestimmten Controllingsystemen. Aus Sicht der Informationssysteme wäre über das Reifegradmodell z. B. zu untersuchen, in welchem Umfang die involvierten Akteure Informationen austauschen, um ihre Leistungsbeiträge aufeinander abzustimmen. 6. Danksagung Dieser Beitrag wurde durch die Förderung des BMBF Projektes „FlexNet“ (Flexible Informationssystemarchitekturen für hybride Wertschöpfungsnetzwerke; Förderkennzeichen 01FD0629) im Rahmen des Förderprogramms „Innovationen mit Dienstleistungen“ ermöglicht. Wir danken an dieser Stelle dem Projektträger Deutsches Zentrum für Luft- und Raumfahrt (DLR) für die Unterstützung. 7. Literaturhinweise [1] CHAMONI, P., GLUCHOWSKI, P., Integrationstrends bei Business-Intelligence-Systemen, in: Wirtschaftsinformatik 46 (2004), S. 119-128. [2] CMMI PRODUCT TEAM, CMMI for Development. Abgerufen am 2008-07-30 unter: http://www.sei.cmu.edu/pub/documents/06.reports/pdf/06tr008.pdf. [3] COVEY, R. W., HIXON, D. J., The Creation and Use of an Analysis Capability Maturity Model (ACMM). Abgerufen am 2008-07-30 unter: http://stinet.dtic.mil/cgibin/GetTRDoc?AD=ADA436426&Location=U2&doc=GetTRDoc.pdf. [4] DE BRUIN, T., ROSEMANN, M., Using the Delphi Technique to Identify BPM Capability Areas, in: Proceedings of the 18th Australiasian Conference on Information Systems (ACIS), 2007. [5] DE BRUIN, T., ROSEMANN, M., FREEZE, R., KULKARNI, U., Understanding the Main Phases of Developing a Maturity Assessment Model, in: Proceedings of the 16th Australasian Conference on Information Systems (ACIS), 2005. [6] HEVNER, A. R., MARCH, S. T., PARK, J., RAM, S., Design Science in Information Systems Research, in: MIS Quaterly 28 (2004), S. 75-105. [7] HUMPHREY, W. S., Managing the Software Process. Addison-Wesley, Reading 1989. [8] IT GOVERNANCE INSTITUTE, CobiT 4.1. The IT Governance Institute 2007. [9] LEE, J., LEE, D., SUNGWON, K., An Overview of the Business Process Maturity Model (BPMM), in: Proceedings of the International Workshop on Process Aware Information Systems (PAIS 2007), 2007, S. 384-395. [10] MARCH, S. T., SMITH, G., Design and natural science research on information technology, in: Decision Support Systems 15 (1995), S. 251-266. [11] MARSHALL, S., E-Learning Maturity Model. Abgerufen am 2008-07-22 unter: http://www.utdc.vuw.ac.nz/research/emm/index.shtml. [12] NOLAN, R. L., Managing the Crisis in data Processing, in: Harvard Business Review 57 (1979), S. 115-126. [13] PAULK, M., The Evolution of the SEI's Capability Maturity Model for Software, in: Software Process - Improvement and Practice (1995), S. 3-15. [14] PAULK, M., CURTIS, B., CHRISSIS, M., WEBER, C., Capability Maturity Model for Software, Version 1.1. Abgerufen am 2008-07-23 unter: http://www.sei.cmu.edu/pub/documents/93.reports/pdf/tr24.93.pdf. [15] PEFFERS, K., TUUNANEN, T., ROTHENBURGER, M. A., CHATTERJEE, S., A Design Science Research Methodology for Information Systems Research, in: Journal of Management Information Systems 24 (2007), S. 45-77. [16] RENKEN, J., Developing an IS/ICT Management Capability Maturity Framework, in: Proceedings of the Research Conference of the South African Institute for Computer Scientists and Information Technologists (SAICSIT), 2004, S. 53-62. [17] ROSEMANN, M., DE BRUIN, T., POWER, B., A Model to Measure Business Process Management Maturity and Improve Performance, in: J. Jeston and J. Nelis, (eds.), Business Process Management, Butterworth-Heinemann 2006 [18] VAN GREMBERGEN, W., SAULL, R., Aligning Business and Information Technology through the Balanced Scorecard at a Major Canadian Financial Group. Its Status Measured with an IT BSC Maturity Model, in: Proceedings of the 34th Hawaii International Conference on System Sciences (HICSS), 2001. 544 DETERMINING THE IMPACT OF BUSINESS STRATEGIES USING PRINCIPLES FROM GOAL-ORIENTED MEASUREMENT Victor Basili1,2, Jens Heidrich3, Mikael Lindvall1, Jürgen Münch3, Carolyn Seaman1,4, Myrna Regardie1, Adam Trendowicz3 Abstract In practice, the success or failure of business strategies is often determined by management as a gut feeling without taking into account quantitative information. If data is collected, it is often unclear how the data contributes to higher-level goals of the organization. GQM+Strategies® provides mechanisms for explicitly linking measurement goals to higher-level goals, and also to goals and strategies at the level of the entire business. It is based on experiences with software-related organizations, but is intended to be applicable in all kinds of businesses. This article gives an overview of the basic concepts and presents a practical case. 1. Introduction Determining the impact of business strategies is crucial for effective decision making within an organization. Different goals and corresponding strategies exist at different levels of the overall business. In practice, these goals and strategies are not aligned and their success or failure is often determined by management as a gut feeling without taking into account quantitative information. For instance, in a software organization, engineers are frequently faced with apparently unrealistic goals related to software development. If the next version of a software product needs to be released to the market in half of the originally planned time, the software development schedule is simply cut in half. There is rarely a discussion of trade-offs or other options for such decisions in order to avoid deviations of budget and schedule. Goals and strategies need to be defined explicitly and derived from high-level business goals in a systematic and transparent way. Moreover, underlying assumptions and environmental factors are often not documented, which makes it hard to determine the reasons for failed strategies. Furthermore, if measurement data is collected on the project level, it is often unclear how the activities performed there and the data collected contribute to higher-level goals of the organization. For instance, time and money are spent on software initiatives that do, in fact, not contribute to the bottom line of the business. In practice, an approach to measurement that explicitly links high-level business goals and measurement data is needed. Building an effective measurement program is a challenging task in itself. It involves observation, expe1 Fraunhofer Center for Experimental Software Engineering, Maryland College Park, Maryland 20742, USA University of Maryland, Maryland College Park, Maryland 20742, USA 3 Fraunhofer Institute for Experimental Software Engineering, Fraunhofer-Platz 1, 67663 Kaiserslautern, Germany 4 University of Maryland, Baltimore County, Maryland 21250, USA 2 545 rience facilitation, collaboration, decision making, analysis, and synthesis regarding goals, context factors, and assumptions. Furthermore, it assumes an organizational structure that sustains the process and learns. Most organizations fall short of putting together a successful program. This article presents the GQM+Strategies® approach [2] for explicitly linking measurement goals to higher-level goals for the organization, and also to goals and strategies at the level of the overall business. Even though the development of the approach was focused on software-related organizations, the basic concepts can be generalized to set up an organization-wide measurement program for controlling business strategies. GQM+Strategies® is based on the familiar Goal Question Metric paradigm [1], which is in widespread use today for creating and establishing measurement programs throughout the software industry. This extension to GQM adds the capability to create measurement programs that ensure alignment between business goals and strategies, software-specific goals, and measurement goals. Although GQM has served the software industry well for several decades, it never provided explicit support for integrating its software measurement model with elements of the larger organization, such as higher-level business goals and strategies. Section 2 gives a detailed step-by-step description of how to systematically connect goals on an organization’s different levels of abstraction using the GQM+Strategies® approach. Section 3 presents an example case of how to apply the approach, Section 4 briefly illustrates practical benefits, Section 5 addresses related work, and Section 6 presents final conclusions and future work. 2. Basics of the GQM+Strategies® Approach Based on the authors’ experience with establishing measurement programs, we see three essential factors for putting together an effective and sustainable measurement program. The first factor is to define the right goals. This includes linking goals at all logical levels of the organization (e.g., business, system, software, and project), using corporate goals to generate lower-level goals, and inheriting lower-level goals from upper-level goals. Moreover, it is important to identify the context and temporal aspects of a goal, such as what are we focusing on, or what shall be achieved and by when. The second factor is to collect the right data; that is, quantifying and interpreting the goals at all levels, justifying what data is collected at each level and why, maximizing the benefits, as well as minimizing data collection and data analysis costs. This also includes taking maximum advantage of already existing data (instead of defining everything from scratch in a pure top-down manner). The third factor is to define and sustain the measurement process. This includes creating the right organizational structure, getting feedback to projects in a timely fashion, and maintaining commitment within all organizational levels (from top-level management down to project managers). Goal+Strategies Element GQM Graph influences Goal Context/ Assumption realized by a set of Strategy > made measurable through made measurable through Metric Question GQM Goal Metric Question < measures achievement of Metric Interpretation Model influences leads to a set of is part of Goal+Strategies Element GQM Graph Figure 1: Meta-Model Elements for Constructing a GQM+Strategies® Grid 546 The Conceptual Model GQM+Strategies® [2] is an approach for clarifying and harmonizing goals and strategies across all levels of an organization, communicating business goals throughout the whole company, aligning goals with strategies, monitoring the deployment strategy, and obtaining feedback about the success or failure of strategies and business goals. One central component of the GQM+Strategies® approach is the conceptual model: The GQM+Strategies® grid specifies goals and strategies across all levels of an organization including the measurement program needed to monitor and control them. Figure 1 gives an overview of all conceptual elements for constructing a grid. The meta-model allows multiple goal levels and permits deriving multiple strategies for each of these goal levels. A goal may be realized by a set of strategies, which may in turn lead to a sequence of goals. A set of predefined goals and strategies may be defined as part of an (organization-specific) experience base. Selection and adaptation of predefined goals and strategies as well as definition of new goals and strategies is driven by context factors and assumptions. Context factors are environmental variables that represent the organizational environment and affect the kind of models and data that can be used. Assumptions are estimated unknowns that can affect the interpretation of the data. The entire model provides an organization with a mechanism not only for defining measurement consistent with larger, upper-level organizational concerns, but also for interpreting and rolling up the resulting measurement data at each level. At each goal level, measurement plans are defined in order the measure the achievement of the defined goal in combination with the chosen strategy. This includes the definition of GQM measurement goals, the derivation of questions and metrics, as well as the definition of an interpretation model that determines whether the measurement goal has been achieved. A single GQM goal (that measures a GQM+Strategies® element), corresponding questions, metrics and interpretation models are called a GQM graph in the GQM+Strategies® notation. The Grid Derivation Process The GQM+Strategies® grid derivation process [2] consists of a couple of basic tasks that may be instantiated depending on the concrete application scenario. For instance, if you want to start with a software-related goal and want to relate upper-level business goals as well as lower-level project goals to it, you need a different sequence of tasks than if you want to derive the whole grid in a topdown-oriented manner. For simplicity reasons, we present an activity diagram of the top-down process in Figure 2. There are basically two different kinds of processes, which may be performed in parallel. On the left side, there are tasks needed to define goals and related strategies. This process is iterated as long as all organizational levels (for which the measurement program has to be created) are defined. On the right side, there are tasks needed to measure already defined goals and strategies; that is, corresponding measurement goals are defined and questions, metrics, and interpretation models are specified using the GQM approach. This measurement branch can be built up in parallel to breaking down goals and strategies. The latter process consists of the following tasks: • Elicit General Context & Assumptions: Before defining business goals for an organization, the basic motivation needs to be determined and the rationales that lead to defining the goal need to be described. (1) First, context factors of the organization are defined. This includes characterizing the product or service provided, identifying existing processes, tools, etc., characterizing typical customers, characterizing income sources and business model (e.g., characterizing the factors that influence profitability, contracting vehicles, etc.), characterizing organizational interfaces (such as levels in the overall organization and levels in the contract chain), and finally, characterizing existing measurement programs and already collected data. (2) Second, underlying assumptions that lead to business goals are documented. For instance, this includes what one believes to be true but has little or no empirical evidence about, as well as assumptions about the technology, market, customers, the organization, or the workforce. 547 • Define Top-Level Goals: (1) First, an initial set of potential high-level goals has to be identified. These goals may be derived from asking some basic questions, such as: What are the organizational principles that you do not want to change, i.e., aspects of the organization you want to keep as is? What are the key elements of the environment (such as transparency, employee satisfaction, controlled risk, learning environment)? Is the organization risk-averse, risk-neutral, or risk-driven? What are your existing business goals? What do you want to happen next? Where do you envisage your organization in 5 or 10 years? How do you want to grow, e.g., new customers, new competencies? How would you define success, e.g., do you want to improve some aspect of the business? (2) Second, once a list of initial goals has been defined, the goals have to be prioritized. This also includes identifying conflicts and other relationships between the goals. (3) Third, once the most important goals have been determined, they need to be formalized using the GQM+Strategies® goal template. The template documents the basic activity that should be performed in order to accomplish the goal, the main (quality) focus of the goal, the object under consideration (e.g., a process or product), the quantification of the goal specified by a magnitude, the timeframe in which the magnitude has to be achieved, the scope, and basic constraints that may limit accomplishing the goal. Furthermore, potential relationships with other (complementary or competing) goals are listed. “Elicit General Context & Assumptions” 1. Gather the general context for your organization 2. Identify general underlying assumptions “Define Top-Level Goals” 1. Identify an initial set of potential high-level goals* 2. Prioritize goals and select most important ones* 3. Formalize selected goals using the goal template* [Top-level GQM+Strategies goal is defined] “Define Goals” 1. Elicit the implications of the chosen strategy with respect to the next level* 2. Identify potential goals (for the chosen strategy)* 3. Select the most promising goals considering feasibility, cost, and benefit* 4. Formalize selected goals using the goal template* “Define GQM Graphs” 1. Define GQM goals for each selected GQM+Strategies goal on the appropriate level* 2. Specify the GQM graph for evaluating the achievement of the goal* 3. Identify relationships between the interpretation models on this level and the ones for the level above, if existing* [Yes] “Make Strategy Decisions” 1. Brainstorm potential strategies for each selected high-level goal* 2. Decide on a strategy* Can one or more strategy be refined (by another goal level)? [No] Are there GQM+Strategies goals defined on the next lower level in the grid? [Yes] [No] * In addition document context and assumptions Figure 2: The GQM+Strategies® Grid Derivation Process • Make Strategy Decisions: (1) First, a list of potential strategies for achieving the business goal needs to be identified (e.g., building a more reliable system that will lead to less customer complaints vs. testing reliability in). (2) Second, the most promising strategy has to be selected considering its cost and benefit, and taking into account context factors and assumptions that naturally restrict the feasibility of potential strategies. • Define Goals: This task is only conducted if one or more strategies could be refined by another goal level. The stop criterion depends on the organization for which the GQM+Strategies® model is built. Usually, the process stops if a concrete set of steps has been derived that may easily be implemented in the organization (e.g., on the project level). (1) First, the implications of the chosen upper-level strategies (e.g., strategies of the business level) with respect to lower-level 548 goals (e.g., software development-specific goals) have to be elicited. For instance, if a chosen strategy is to test in reliability, the software test processes must be examined. (2) Second, potential lower-level goals need to be identified based on this analysis (e.g., decrease customer reported defects by improving system test effectiveness). (3) Third, the most promising goal with respect to feasibility, cost, and benefit is selected. Again, context factors and assumptions help to define the right selection criteria. (4) Fourth, the lower-level goal needs to be formalized using the goal template as described above (see “Define Top-Level Goals”). Creating the measurement branch of the grid for each goal and strategy level is not an isolated task; that is, the metrics derived across different levels of the GQM+Strategies® model will usually overlap. Moreover, an interpretation model for a higher-level goal may only be defined completely if the lower-level pieces have already been modeled. Define GQM Graphs: A measurement plan has to be developed for evaluating the achievement of goals and strategies. (1) First, potential measurement goals need to be identified. The GQM goal template [2] (object, purpose, quality aspect, viewpoint, and context) is used for formalizing the measurement goal. (2) Second, GQM questions and metrics as well as criteria for evaluating the achievement of the measurement goals are determined and interpretation models are defined for aggregating and interpreting the collected measurement data. With that, the GQM+Strategies® model provides guidance not just for planning, but also for analyzing and rolling up the resulting data for the decision makers and helps to make the right decisions for achieving the designated goal and evaluating the implementation strategy. (3) Third, relationships between the interpretation models on this level and the one above need to be identified. The reason for that is that using the information from the current level may help to extend and improve the upper-level interpretation models significantly. 3. Applying the GQM+Strategies® Approach The example case presented in this section is a hypothetical project, built upon real project experience gained over many years of industrial work. GQM+Strategies® was applied post mortem in order to evaluate the applicability of the conceptual model. In the following, the activities that were performed in order to systematically define the measurement program according to the GQM+Strategies® method are described. The two branches of the grid derivation process presented in the previous section are merged into a continuous series of tasks. Elicit General Context & Assumptions: A company called Company X creates web applications in the financial area. Their most famous product is called Splash and Company X is the market leader for this class of product. The basic motivation for defining a measurement program is that the market for this class of product is becoming highly competitive and there is a need to safeguard the place in the market. Table 1: Formalized Goal on the Business Level Activity Focus Object Magnitude Timeframe Scope Constraints Relations Increase Customer satisfaction Product “Splash” 10% reduction in number of customer complaints 12 weeks after release Web Products Division, Splash Project Manager Splash price and functionality Can conflict with development cost goals, schedule goals, … 549 Define Top-Level Goals: A way to safeguard the place in the market is to keep existing customers by generating customer loyalty. This can be achieved by improving customer satisfaction with the next product. Other potential high-level goals were not defined in our case. However, the organization could also think about decreasing time to market in order to speed up delivery of its product to the customer. The business goal “increase customer satisfaction for the next product” is selected as the only goal and is formalized according to the goal template. The results can be seen in Table 1. Define Top-Level GQM Graphs: The GQM goal for evaluating the defined business goal is as follows: Analyze customer complaints trend for Splash for the purpose of evaluation with respect to a 10% improvement over history from the point of view of quality management in the context of the Web Products Division of Company X. Questions and metrics are derived and an interpretation model for evaluating the achievement of the goal is defined: If the ratio between customer complaints for Splash and a historical baseline over a 12-week time period is less than or equal to 0.9, the business goal is achieved. Make Strategy Decisions (on Business Level): An analysis revealed that many customer complaints are due to product reliability problems. Brainstorming potential strategies resulted in the following alternatives: (S1) build reliability in (e.g., implement fewer defects) or (S2) test reliability in (e.g., remove more defects). Company X has only little control over the development process and only a limited budget for process improvement. Thus, they decide to “test reliability in”. Define Goals (on Software Level): First, we elicit the implications of the chosen strategy with respect to software development. In order to test reliability in, the software test processes must be examined. Potential software goals include decreasing customer-reported defects by improving (G1) system test effectiveness, (G2) unit test effectiveness, or (G3) acceptance test effectiveness. Company X has discovered a new system test process that seems appropriate for their context. They assume (based on their experience) that they can decrease the total number of customer complaints by 10% by reducing customer-reported software field defects (i.e., those that slip by system test) by 20%. So the most promising goal is to decrease customer-reported defects by improving system test effectiveness. A formalization of the goal is presented in Table 2. Table 2: Formalized Goal on the Software Level Activity Focus Object Magnitude Timeframe Scope Constraints Relations Decrease Customer-reported software defects System test process for Splash 20% 12 weeks after release (might check every week) Web Products Division, Splash Software Manager Development cost and functionality Can conflict with development cost goals, schedule goals, … Define GQM Graphs (on Software Level): The corresponding GQM goal is to analyze the trend in unique customer complaints that are due to software defects for the purpose of evaluation with respect to a 20% reduction when compared to prior projects from the point of view of quality management in the context of the Web Products Division of Company X. The goal is achieved if the number of unique customer complaints that are due to software defects of Splash compared to the average number of complaints of a set of baseline products is less than or equal to 0.8. This new information has some implications for the interpretation model of the business goal. For example, if the number of customer complaints is reduced by 10% or more, then we have achieved our business goal, else – if the number of unique customer complaints due to defects is reduced by 20% – the assumption may be wrong. It is necessary to consider that perhaps the unique customer complaints 550 due to defects are not a major problem relative to other customer complaints. It is then necessary to identify the major sources of complaints and redefine the strategy or reconsider the business goal. Make Strategy Decisions (on Software Level): Because there is a new system test process that seems appropriate for Company X, the one and only strategy is to introduce the new system test process. Table 3: Formalized Goal on the Project Level Activity Focus Object Magnitude Timeframe Scope Constraints Relations Decrease Defect slippage New system test process for Splash 20% 12 weeks after release (might check every week) Web Products Division, Splash Software Manager Development cost and functionality Can conflict with development cost goals, schedule goals, … Define Goals (on Project Level): Company X assumes that reducing slippage by 20% reduces reported defects by 20%. They already collect defect slippage data and have created a corresponding baseline based on the assumption that the projects that form the baseline are relevant to the current Splash development project. The goal is to apply the new system test method in order to see if it reduces defect slippage by at least 20% and generates the necessary improvement to customer complaints. The goal is formalized in Table 3. Business Level Goal+Strategies Elements Goal: Increase customer satisfaction by 10% Context Assumptions C1: Highly competitive market for class of products A1: Improving customer satisfaction will increase customer loyalty C2: Little control over development process C3: Limited budget Project Level Software Level Strategy: Test reliability in Goal: Improve system test effectiveness by 20% A3: Many complaints are due to product reliability A4: Reducing defects by 20% reduces complaints by 10% C4: New system test process available Strategy: Introduce new system test process Goal: Reduce defect slippage by 20% A2: Satisfaction can be measured by # of complaints A5: Reducing slippage by 20% reduces reported defects by 20% C5: Defect slippage data available on past projects A6: Baseline projects relevant Strategy: Establish baseline, evaluate new project, analyze improvement Figure 3: Summary of Context Factors and Assumptions Define GQM Graphs (on Project Level): The GQM goal for evaluating the goal on the project level is to analyze the system test process for Splash for the purpose of evaluation with respect to 20% 551 defect slippage compared to prior projects from the point of view of quality management in the context of the Web Products Division of Company X. The goal is achieved if the ratio of faults found in system test to that found after system test on the Splash project compared to the same average ratio in the set of baseline projects is greater than or equal to 1.2. If the value is between 1 and 1.2, then the new method is better than history but not good enough to achieve the goal. The relationships between this interpretation model and the one for the software goal are as follows: If the customer-reported defects are reduced by 20%, then we have achieved our software goal, else – if defect slippage from system test is reduced by at least 20% – one of the previous assumptions is wrong (either reducing slippage by 20% does not reduce reported defects by 20% or the projects that form the baseline are not relevant to the current project). There are more GQM goals (not discussed in this example) on this level that could be followed depending on whether historical data on defect slippage exists. However, because of space limitations, we skip the remaining goals. A comprehensive overview of the goals, strategies, and related context factors and assumptions that helped in going from one level to the other can be found in Figure 3. 4. Practical Benefits In practice, multiple goals on the same level of abstraction or on different levels of the GQM+Strategies® model will most likely be interrelated with each other. The most obvious relationship (documented in the conceptual model) is a hierarchical structure consisting of a top goal and sub-goals connected via strategies. For a certain goal, a set of complementary goals may exist, which provide additional support for the current goal. On the other hand, a set of competing goals may also exist that conflict with the current goal, whereas other goals may be totally unaffected by the current goal. There are several approaches available in practice and research to resolve goal conflicts (e.g., the Model-Clash Spiderweb diagrams [4]). However, sometimes it is hard to determine whether a strategy selected for one goal is in conflict with another goal. For instance, if our goal is to “increase product quality” and the derived strategy is “find more defects”, then the strategy may have various effects on a goal like “increase profits”. On the one hand, costs are increased by putting more effort into finding defects. On the other hand, costs may also be decreased, because rework effort may be reduced. GQM+Strategies® allows us to explicitly model potential conflicts and also model assumptions we made in order to overcome potential conflicts. If a goal could not be achieved, interpretation models help to determine which parts of the model need to be changed and how to measure the effect of these changes. The GQM+Strategies® approach makes high-level goals, strategies, and related measurement goals explicit across all levels of an organization. The entire model provides an organization with a mechanism not only for defining software measurement consistent with larger, upper-level organizational concerns, but also for interpreting and rolling up the resulting measurement data at each level. However, in order to implement a sustainable measurement program, further activities have to be performed (which are part of the overall approach, but beyond the scope of this paper), including (a) measurement instrumentation, (b) data collection and validation, (c) data analysis, visualization, and interpretation, and (d) the practical introduction and management of a measurement program. 5. Related Work CoBIT (Control Objectives for Information and related Technology) [6] is a framework that focuses on controlling IT. CoBIT was initially developed by the Information Systems Audit and Control Association (ISACA) and has been developed by the IT Governance Institute since 2000. CoBIT distinguishes between four different levels of goals: business goals, IT goals, process goals, and activity goals. The list of goals provided represents the consensus of experts. CoBIT provides metrics and models to measure their achievement. The CoBIT process model subdivides IT into four 552 domains and 34 processes in line with the responsibility areas of plan, build, run, and monitor IT processes. It has a clear focus on IT services, provides an easy structure for documenting relationships between and among goals and metrics, and summarizes best practices for IT governance. However, it provides only a fixed set of goals, has limited tailoring support, and makes assumptions about the process (reference model) used. Moreover, it provides no means for documenting underlying context information and assumptions that would help to tailor the model to specific organizations. Practical Software and Systems Measurement (PSM) [8] defines an information-driven measurement process that guides project managers in selecting, collecting, defining, analyzing, and reporting specific software issues. PSM represents best practices used by measurement experts. It is sponsored by the Department of Defense and the US Army. It focuses on measurement on the project level and defines seven common areas including schedule, cost, size, product quality, performance, effectiveness, and customer satisfaction. The areas may be extended with respect to specific goals related to a project. The method is tool-supported and comes with a set of predefined goals and metrics that may be tailored to specific needs. It provides support for multiple measurement areas, defines corresponding metrics on the project level, and provides best practices for implementing a measurement program on the project level. However, it does not address measurement on the business level and does not link measurement on the project level to higher-level business goals and strategies. Balanced Scorecard (BSC) [7] is an approach for measuring whether the activities of a company meet its goals with respect to vision and strategy. It was initially developed by Robert S. Kaplan and David P. Norton and is used by decision-makers for controlling organization-wide goals, making use of different dimensions that have to be determined based on the goals and characteristics of an organization. In order to derive goals and document relationships among them, a strategy map is defined, which connects all dimensions by using causal links (also known as BSC stories). Typically, four different dimensions are controlled (learning & growth, internal process, customer, and financial), each including one to two business goals. For each goal of a BSC dimension, corresponding indicators, target values, and initiatives (activities) are defined. BSC helps to make goals on the business level explicit, defines measures for controlling the goals, and sets target values. It helps to define causal chains for strategies in order to achieve business goals. However, depending on the organization, it is hard to formulate goals (no template is provided) and there is no consistent linkage between measurement on the business level and on the project level. Becker and Bostelman [3] address the misalignment between strategy at the organizational level and the project level of software organizations caused by project data that does not address organizational goals and organizational goals that fail because they are not operationalized through processes and metrics at the project level. Buglione and Abran [5] also discuss the misalignment problem, but their work is more of a comparison, rather than a merger, of BSC and GQM. The M3P – Model, Measure, Manage Paradigm [9] – is an extension of the QIP and GQM. M3P embeds GQM as a measurement definition technique within a larger framework that encompasses organizational concerns, but does not allow for explicitly linked goals at different levels of the organization. Six Sigma (6σ) [10] is a set of practices designed to improve manufacturing and business processes and seeks to identify and eliminate the causes of defects. It was first defined by Bill Smith at Motorola in 1986 and can be used for creating new or controlling existing manufacturing or business processes in order to deliver products or services that meet customer needs. Six Sigma asserts that continuous efforts to achieve stable and predictable process results (i.e., to reduce process variation) are of vital importance to business success. It adapts the Plan-Do-Check-Act paradigm for continuous improvement. It utilizes tools and techniques for fixing problems in manufacturing and business processes in a continuous and disciplined fashion and focuses on decision making based 553 on facts and data rather than on assumptions. However, it requires large amounts of reliable measurement data, which, in contrast to manufacturing, are typically not available in the software development domain. The sigma-level is assumed to be the major factor contributing to the fulfillment of customer needs. 6. Summary and Conclusions This paper presented the GQM+Strategies® approach, which provides guidance not just for planning, but also for analyzing and rolling up the resulting data for the decision-makers. The approach helps to make the right decisions for achieving the designated business goals and evaluating the implementation strategy. GQM+Strategies® inherits GQM’s benefit of assuring that the metrics set is as small as possible and that the data collected address the defined organizational objectives. It extends GQM by providing explicit support for linking software measurement goals to organizational business objectives. Considering this linkage is essential for organizational success, as it helps to translate strategic-level objectives into a set of operational software goals and corresponding quantitative project management. It helps to justify software measurement efforts and allows measurement data to contribute to higher-level decisions. GQM+Strategies® provides a systematic way to deal with relationships between different objectives at various organizational levels. Early identification of conflicting objectives may help to prevent failures very early, namely, at the time of defining the organizational strategy. Moreover, a transparent way of specifying and synchronizing objectives at various operational levels supports understanding of the overall business and improves communicating goals and strategies. The GQM+Strategies® development team is currently setting up a set of pilot projects for evaluating the approach in practice. Furthermore, tool support for specifying a GQM+Strategies® grid is under development. 7. Acknowledgements This work was supported in part by the German Federal Ministry of Education and Research (QuaMoCo Project, No. 01IS08023C) and the Stiftung Rheinland-Pfalz für Innovation (Q-VISIT Project). Furthermore, we would like to thank Sonnhild Namingha for reviewing the article. 8. References [1] BASILI, V.R., WEISS, D., A Methodology for Collecting Valid Software Engineering Data, IEEE Transactions on Software Engineering, vol.10 (3): 728-738, November 1984. [2] BASILI, V.R., et al., A., Bridging the Gap Between Business Strategy and Software Development, In: Proceedings of the International Conference on Information Systems (ICIS), December 9-12, 2007, Montréal, Canada. [3] BECKER, S.A., BOSTELMAN, M.L., Aligning Strategic and Project Measurement Systems, IEEE Software, May/June 1999, pp. 46-51. [4] BOEHM, B., PORT, D., AL-SAID, M., Avoiding the Software Model-Clash Spiderweb, Computer, vol. 33, no. 11, pp. 120-122, Nov., 2000. [5] BUGLIONE L., ABRAN A., Balanced Scorecards and GQM: What are the Differences?, In: Proceedings of FESMA-AEMES Software Measurement Conference, October 2000. [6] ISACA, Control Objectives for Information and related Technology (COBIT®), retrieved 04/12/2007, from www.isaca.org. [7] KAPLAN, R, NORTON, D., The Balanced Scorecard - Translating Strategy into Action, Boston: Harvard Business School Press, 1996; ISBN 0-87584-651-3. [8] MCGARRY, J., CARD, D., JONES, C., LAYMAN, B., CLARK, E., DEAN, J., HALL, F., Practical Software Measurement: Objective Information for Decision Makers, Addison-Wesley Professional, 2001. [9] OFFEN, R.J., JEFFEREY, R., Establishing Software Measurement Programs, IEEE Software, Mar/Apr 1997. [10] PYZDEK, T., The Six Sigma Handbook: A Complete Guide for Green Belts, Black Belts and Managers at All Levels. New York, NY: McGraw-Hill Professional, 2003. 554 BENEFITS MANAGEMENT – A LITERATURE REVIEW AND ELEMENTS OF A RESEARCH AGENDA Jessica Braun, Frederik Ahlemann, Gerold Riempp1 Abstract Benefits Management (BM) deals with the systematic planning, realization and controlling of the intended benefits of IS/IT projects, beyond the traditional success measures of staying within project time frame and budget limits. The article describes the results of a BM literature review that seeks to describe the state-of-science as well as to identify fields of promising further research. Our main findings are that, although the pioneering work of Ward et al. on BM have structured the discipline early on and have been adopted as a basis by other researchers, the research on the BM process itself is still scarce and many opportunities for future research remain open. 1. Introduction The success of IS/IT projects (ISTPs) is often measured according to time frame, budget and quality. Independently of success or failure in these three dimensions, many projects fail to deliver the desired benefits [28] and therefore organizations lose large amounts of money [11]. It is unsurprising that there are difficulties in realizing the intended benefits when one takes into account the number, investment volumes and complexity of today’s ISTPs. We argue, however, that ISTP benefits can be achieved with appropriate management [42]. This is especially important, as ISTPs are often means to implement corporate strategies and thus support organizational change and progress. Some researchers even refer to the IT department as an “agent of change in the organization” [4]. In this context, several approaches for achieving and maximizing the anticipated benefits from ISTPs have evolved under the term Benefits Management (BM). One of the first and still the most widely used and cited was the Cranfield Benefits Management Model by Ward, Taylor and Bond, who define BM as “the process of organizing and managing such that potential benefits arising from the use of IT are actually realized”. They identified the following five phases of BM: (1) Identifying and structuring benefits, (2) Planning benefits realization, (3) Executing the benefits realization plan, (4) Evaluating and reviewing results, and (5) Discovering potentials for further benefits [53]. As a first step in our BM research program, we started with an extended literature review. According to Webster and Watson [54] as well as Hart [16], a researcher can, by means of a literature review, distinguish what has already been done from what still needs to be done. Therefore, this research paper has two objectives: First, to give an overview of existing research 1 Institute of Research on Information Systems, European Business School, Rheingaustraße 1, 65375 Oestrich Winkel 555 that addresses both, BM in general and each of its five phases; and second, to develop a research agenda for future research activities in this area. The following section presents the methodology of our literature review as well as a brief descriptive overview of the results. In section 3, we discuss the relevant literature and suggest further research. We conclude with a summary, limitations and an outlook to upcoming research activities. 2. Methodology of the Literature Review and Descriptive Results A literature review [14] is a stand-alone research methodology with the objective to “critique, analyze, and extend existing literature […] in an attempt to build new groundwork” [38]. Various review methods exist, ranging from purely qualitative (e.g. narrative review) to purely quantitative (e.g. meta-analysis) [23]. The methodology for our literature review is based on the concept-centric approach by Webster and Watson [54] and can be classified as a qualitative review. Thereby, concepts instead of authors determine the organizing framework. We selected articles that either deal with BM in general [53] or with one of the above described 5 phases – from a theoretical as well as from an empirical perspective. Phase 4 and phase 5 of the BM process model are thereby considered as one concept. The identification of relevant articles followed a four-stage literature selection process: First, we selected the sources to be considered in the review (Stage 1). Secondly, the time frame of the research papers to be considered was narrowed down (Stage 2), which was followed by a manual search within such sources and such time frame (Stage 3). Finally, and in order to be complete, papers were selected, which are cited in the research papers identified in Stage 3 but are not published in the source and/or time frame selection (Stage 4) [54]. The source selection was accomplished based on three widely respected rankings that consider a broad range of different IS journals: (1) Wissenschaftliche Kommission Wirtschaftsinformatik (WKWI), (2) Association for Information Systems (AIS), (3) VHB-Jourqual. We then selected the top 15 rated journals from each of these three rankings, which led to a total of 45 journals, removed 19 duplicates and excluded 12 journals that focus mainly on technological research issues. Thirdly, one additional journal was included as a source for our review that was not ranked in the top 15 but which had recently published papers specifically dealing with BM. Additionally, we added the proceedings of 7 important IS conferences to the sources in order to allow for very recent research to be considered. The following table gives an overview of the sources which were finally chosen for the literature review. Table 1: Selected Journals and Conferences Journals Conferences CACM, Decision Sciences, EJIS, HBR, I&M, IS, ISJ, ISR, JMIS, JACM, JAIS, Management Science, MISQ, Project Management Journal, Wirtschaftsinformatik AMCIS, AuCIS, ECIS, HICSS, ICIS, PACIS, Int. Tagung Wirtschaftsinformatik We considered scientific publications from 1990 to 2007. Relevant research published before 1990 is likely cited in more recent articles and was therefore identified in Stage 4 of the literature selection process. The search for relevant papers was then performed manually by scanning the tables of content to make sure that all relevant literature was found. By contrast, a stand-alone keyword search tends to produce a lot more literature to screen, and many of these publications are not relevant for our research. Finally, in the “go backward” stage suggested by Webster and Watson [54], we browsed the bibliographies of key articles that we classified as highly relevant to spot articles that were not yet included in the selection. We then read and analyzed the selected 556 articles, the results of which shall be described in the following chapter. In total, we identified 74 articles as highly relevant – 60 journal articles and 14 conference papers. As indicated in Table 2, the proportion of articles dealing with BM is smaller than the proportion of articles dealing with the first three phases of BM. Table 2: Number of Identified Research Papers According to the Cranfield Benefits Management Model Conferences Journals TOTAL Identifying and structuring benefits Planning benefits realization Executing the benefits realization plan 4 9 13 3 26 29 0 17 17 Evaluating and reviewing results & Identifying potential for further benefits 2 4 6 Entire Benefits Management process TOTAL 5 4 9 14 60 74 Considering the time frame of the published articles, it was obvious that BM as a research discipline is increasingly attracting interest, especially in recent conferences. For instance, three papers were published at the HICSS in 2007 [37, 49, 52], and it can be predicted that more research will be forthcoming year-on-year [15]. The preferred methodology for research on the entire BM process is the survey instrument, which is used within five out of the 9 identified publications. 3. Findings on the State of the Art of Benefits Management The pioneering work of Ward et al. on BM started in the mid 1990s with an empirical study on BM industry practises in the UK [53] and in a recently published textbook, Ward and Daniels [51] give in-depth insights into the main ideas and concepts of BM that have subsequently evolved. Several other researchers have sought to expand the knowledge regarding benefits from ISTPs. In the following sections, we will give an overview of the main concepts that have emerged in academic literature regarding each of the five phases of BM as well as regarding the overall BM process. We will also suggest opportunities for further research. The main references are cited and interested readers may research the appropriate reference articles for further information. 3.1. Identifying and Structuring Benefits Overview of Existing Research: Regarding the first phase of BM, we focus on frameworks and classification schemes that have evolved over the years in an effort to structure the various benefits that IS/IT investments are credited with. Our literature review reveals that many researchers considered benefits to be components of the same underlying topic and, therefore, clusters emerged [44]. The activities of an organization, as suggested in 1965 by Anthony, are used as a basis by many authors. Anthony hereby differentiates between strategic planning, management control, operational control, information handling and financial accounting as the main segments [3]. Especially the three first mentioned segments appear in a number of frameworks classifying IS/IT benefits [19, 34, 45, 46, 55]. Some researchers have proceeded on this knowledge base and have investigated the importance of the benefits. For example, a 1995 study revealed that business redesign, improved information and strategic advantage are most important to the respective respondents. By contrast, the same study reveals benefits like reduced workforce costs, adherence to government regulations and business redesign as most prominent when measured by project budget [26]. There is also support in literature for the simple classification of benefits as tangible or intangible [18]. Tangible benefits can be measured according to an objective quantitative and thus often financial measure. By contrast, intangible benefits can only be judged on a subjective basis; therefore, qualitative measures are used [2, 12, 35]. Regarding any classification activity, very little 557 theoretical work has been done into the process of benefits identification itself compared to the amount of work on benefits classifications schemes. So far, we could only identify one study [8] that analyzes, in detail, how organizations identify the expected benefits. We assume that this process has not been well defined or even established in most organizations yet. Therefore, in the absence of empirical data it seems difficult conduct well-founded research even if the process of benefits identification might have been of interest to the research community. Future Research Opportunities: In summary, two major findings emerge from the above overview. Table 3: Key Findings - Identifying and Structuring Benefits 1. 2. IS researchers have a broad list of benefit classifications schemes to choose from. However, there is no consensus on benefit classification. The choice of a benefits classification scheme is dependent on the characteristics of the ISTP to be implemented. The in-depth exploration of activities that are most and least effective and efficient in facilitating benefits identification as well as an exploration of the skills needed for such activities could therefore form the basis of further research. Another interesting avenue for future research involves methods how to identify the “right” benefits classification from the available ones and the moderating factors. However, in summary, we conclude that the first phase of BM is a rather mature research field. 3.2. Planning Benefits Realization Overview of Existing Research: For the literature review on the second phase of BM, we focused on publications that investigate evaluation methods for IS/IT investments. Several IS/IT evaluation practices evolved over time [19]. Some authors even refer to IS evaluation as “one of the most researched and written about topics in IS research” [6]. One of the most significant distinctions is analytical evaluation versus interpretive evaluation [47]. Regardless of the existence of interpretive evaluation approaches, much of the research available focuses on testing and refining quantitative and therefore analytical methods. One reason for this is the common practice by organizations of merely quantifying the benefits most important for them [26]. However, companies are no longer able to justify IS/IT investments exclusively on the basis of analytical evaluation methods such as return of investment, which can only be considered adequate when dealing solely with cost-avoidance issues [35]. When seeking effectiveness and strategic goals, benefits are often too complex to be captured by financial measures alone [17]. As a result, interpretive methods are enjoying increased interest as they capture benefits in greater variety than the definite language of numbers. Interpretive methods include critical success factors and other subjective, multi-objective, multi-criteria methods [24] as well as balanced scorecard methods [21, 32]. Finally, interpretive approaches also support the postulation that the evaluation of information systems is highly dependent on the process of organizational change that accompanies the introduction of new IS/IT systems [48]. Future Research Opportunities: Two major findings may be drawn from the above discussion of literature regarding the second phase of BM. 558 Table 4: Key Findings - Planning Benefits Realization Evaluation approaches are polarized between analytical (low variety, high language 1. precision) and interpretive (high variety, low language precision) approaches. 2. Interpretive evaluation is enjoying increased interest among practitioners. Suggestions for further research in literature range from the development of a selection framework for evaluation approaches [50] to the identification and definition of key organizational roles needed for evaluation [43]. In order to overcome current deficiencies in this field, we suggest further research on how to combine already existing analytical and interpretive evaluation methods, depending on the characteristics of the ISTP to be implemented. Further research on industry-based and customization-oriented evaluation methods might also be promising. 3.3. Executing the Benefits Realization Plan Overview of Existing Research: Our literature review regarding the third phase of BM mainly focuses on change management issues and the ability of an organization to successfully realize the anticipated benefits. It is apparent that the successful closure of ISTPs remains an enormous challenge [22], and the quality of the implementation process itself has been identified as a critical success factor for such [30, 56]. The term “paradox of IT productivity” evolved in literature in order to describe this dilemma: Even though organizations invest in IS/IT, their inability to change the organization accordingly delays the return on these investments [7]. Organizations and their managers need to understand that even though IS/IT may have been the key enabler within successful projects, the business benefits are ultimately derived from “understanding the business and committing it to change” [13]. In this context, some researchers refer to “value conversion contingencies” [10] and “conversion effectiveness” [55], used for the organization’s ability to transform IS resources to actual benefits. Questions about change and how to manage it have occupied practitioners and researchers in many disciplines for many years: Some IS researches argue strongly to incorporate lessons learned from other fields into ISTP management practices [27], while some researchers seriously investigate the relationship between IS/IT and organizational change [31]. Given the fact that change management is becoming more important, ISTP managers will need to demonstrate and apply change management skills [4, 30, 40]. The development of IS/IT management from a “relatively unimportant service function” to an “important instrument of organizational change” was already revealed over 25 years ago [20]. Despite the growing recognition of the importance of change management, a 2004 study revealed insufficient knowledge on the part of IT professionals, especially within the following areas of change management: individual reaction and response to change, general nature of change, planning of change and the evaluation of change [40]. The reason might be the still common belief within many organizations that technology itself, and not the people, can cause change [30]. Future Research Opportunities: We conclude with two major points from the above depicted review of literature on phase 3 of the BM process. Table 5: Key Findings – Executing the Benefits Realization Plan 1. It is essential to understand and manage change processes more effectively. 2. Many IS/IT specialists and project managers lack change management skills. 559 From our point of view much work remains to uncover which change management skills and methods are most beneficial to which type of ISTP. Using as a basis the roles IS specialists adopt according to Markus and Benjamin’s change agentry model [30], further research could therefore address the suitability of these roles for particular types of ISTPs. This would improve our understanding of change management types as a critical success factor for benefits realization. 3.4. Evaluating and Reviewing Results & Discovering Potentials for Further Benefits Overview of Existing Research: The literature on reviewing and evaluating results as well as discovering potentials for further benefits comprises research on post-project evaluation and research on organizational learning. A post-project evaluation thereby determines the degree of accomplishment of an ISTP and reveals potential for further improvement that will most likely affect the planning of future IS/IT investments in terms of new project proposals or change requests. Also, post-project evaluation enables management to better understand why potential benefits may not have been realized and what actions may therefore prove useful in future projects [10]. Surprisingly, the objectives to carry out a post project review from a practitioner’s point of view seem to differ from the described academic belief: Even though 79 % of organizations surveyed in a 1990 study are performing post-implementation reviews of some kind, their objective of doing so is merely the formalization of the end of the project and not a long-term improvement based on prior experiences [25]. In academic literature, post-project evaluation has also been linked empirically to learning aspects, the second research stream prevalent during our literature review on phase 4 and phase 5 of the BM model. For instance, a 2003 study has identified the commitment to learning as well as open-mindedness as important predictors of post-project evaluations [36]. In order to establish learning based project management, organizations first need to realize that each project needs to produce two outputs: (1) The product/service itself, and (2) an assessment of what was learned during the project [9]. The latter also includes an assessment of qualitative lessons learned. The four types of knowledge important to the success of ISTPs are: (1) process, (2) domain, (3) institutional, and (4) cultural [41]. Also, frameworks exist that integrate knowledgebased risks in ISTPs [41]. Future Research Opportunities: Two major points emerge from the literature review. Table 6: Key Findings – Evaluating and Reviewing Results & Discovering Potentials for Further Benefits 1. 2. Literature on evaluating and reviewing ISTPs subsequent to project completion and on discovering potentials for further benefits is limited. Although post-project review is recognized as important in practice, it is seldom carried out or carried out properly. Therefore, we suggest for further research to shed light on the question how to establish continuous learning and overall improvement on benefits realization based on post-project reviews. Developing industry-based and customization-oriented measurement systems thereby forms a challenge. These measures should go beyond budget adherence and be consistent with the measures used for the ex-ante project evaluation. Also, research on how to establish the active use of wellknown documentation methods in such a way that is unbureaucratic yet serves as advantageous input for further ISTPs is considered promising. 3.5. Entire Benefits Management Process Overview of Existing Research: Comparably little literature exists on the overall topic of BM beyond the works of Ward, Taylor and Bond, who discovered that “very few organizations have a complete or comprehensive management process to ensure the proposed benefits from IS/IT 560 investments are actually realized” [53]. In 2007, the result of further research extending the 1996 study was presented, and although the adoption of benefits management had increased from 12% to 25% among participating organizations, most organizations still have a need for further improvement [52]. When differentiating between organizations that are more successful in terms of benefits delivery and those that are less successful, Ward, De Hertogh and Viaene identified five primary differentiating practices: (1) Transfer of lessons learned, (2) Evaluation and review of organizational change, (3) Development of benefit delivery plans, (4) Evaluation and review of benefit delivery plans, and (5) development of organizational change plans [52]. Academics have already noticed the practical problem of organizations’ inability to manage benefits; an increase in academic BM literature is proof for this [1, 33, 37, 49]. Thus far, the available BM literature has examined the following topics: critical issues in order to facilitate the adoption of BM practices in municipalities [37], the relationship between BM and strategic alignment on the success of IT outsourcing [49], the process of BM itself [5], the BM practices in the construction industry [29], and factors that will ensure the realization of benefits from IS/IT [11]. Also, additional approaches for BM were published, e.g. the active benefits realization (ABR) that complements an organization’s project management methods and focuses exclusively on benefits realization [42]. Future Research Opportunities: We summarize two key findings from the above discussion. Table 7: Key Findings – Entire Benefits Management Process 1. 2. Although academic publications on BM already emerged in the mid 1990s, the research field can still be considered rather immature. One BM model – the Cranfield process model – has found wide acceptance and forms the basis of most existing literature. In line with some authors we argue in favor of more research, for example “investigating of how the [BM] process can be extended or refined, in combination with project portfolio approaches” [52]. From our point of view, it is equally important to consider the identification of critical success factors for effective benefits management. This would include research on maturity models for BM as well as the assessment of such. Consequently, we see several different directions for further BM research: We expect that the extent of interdisciplinary research will increase as social, technological and process issues merge within the research field of BM. We also know very little about how industry characteristics, organizational characteristics, and project portfolio characteristics moderate BM’s success. We therefore suggest further exploratory research on how BM is carried out in practice, e.g. using case study methodology, which is particularly useful when a research topic is broad and complex [39] as it is the case with BM. 4. Summary, Limitations and Outlook to Forthcoming Research The purpose of this paper has been to provide an overview of existing, available literature that forms the foundational knowledge of BM. We started our paper by describing the research methodology and presented brief descriptive results. Subsequently we analyzed different streams of research dealing with BM in general or with one of its five phases according to the BM process model by Ward, Taylor and Bond [53]. The following figure gives a concluding overview of specific future research opportunities within each phase of BM and also illustrates an overall future research opportunity. Generally, we suggest a focus on research that contributes to a deeper understanding of the benefits management practices. 561 Overall Key Findings 1. The literature review revealed the complexity and multifacetedness of BM. Therefore, researchers need to balance the furtherance of BM research with considering the body of research from additional research streams. 2. There is much descriptive, explanatory and prescriptive research to be done on BM. However, we consider it most important to first develop a deeper understanding on how organizations are conducting BM in practice. Identifying and structuring of benefits Planning benefits realization Executing the benefits realization plan Evaluating and reviewing results & Discovering potentials for further benefits Specific Future Research Opportunity Specific Future Research Opportunity Specific Future Research Opportunity Specific Future Research Opportunity Choosing the right benefits categorization as a mixture of qualitative and quantitative factors Combining analytical and interpretive evaluation methods to measure each benefit as precise as possible Importance of change management skills depending on the anticipated benefits Establishment of continuous learning and improvement based on post project review results Overall Future Research Opportunity What is the state-of-the art of benefits management practices and how are these practices influenced by the IT investment characteristics, external environment and internal context? Figure 1: Overview of Future Research Opportunities regarding BM Limitations of our research are the objectivity of the selection process and completeness of the obtained articles. However, we limited such risks by following a proven course of action of how to conduct such kind of literature review [54]. Based on the findings of this literature review, the next step within our BM research program is to conduct an empirical study based on interviews with IS/IT executives and project managers. The objective thereby is to identify common as well as best practises and to improve the understanding of BM and its contextual factors. On this basis, we are then able to proceed with explanatory as well as prescriptive research on BM. 5. Bibliography [1] AL-TAMEEM, A. A. and WHEELER, F. P., A Process View of Information System Benefits Management and Evaluation, in: Proceedings of the Americas Conference on Information Systems, Long Beach, CA, USA, 2000, pp. 1089-1092. [2] AMADI, A. A. N., Process Redesign as an Intangible Benefit: Its Impact on Information Technology (IT) Investment Decisions, in: Proceedings of the Americas Conference on Information Systems, Long Beach, CA, USA, 2000, pp. 2080-2082. [3] ANTHONY, R. N., Planning and Control Systems: Harvard University Press, Boston, 1965. [4] BEATH, C. M., Supporting the Information Technology Champion, in: MIS Quarterly, 15(3), 1991, pp. 355-372. [5] BENNINGTON, P. and BACCARINI, D., Project Benefits Management in IT Projects - An Australian Perspective, in: Project Management Journal, 35(1), 2004, pp. 20-30. [6] BERNROIDER, E. W. N. and STIX, V., Profile distance method—a multi-attribute decision making approach for information system investments, in: Decision Support Systems, 42(2), 2006, pp. 988-998. [7] BRYNJOLFSSON, E. and HITT, L., M., Beyond the productivity paradox, in: Communications of the ACM, 41(8), 1998, pp. 49-55. [8] CHANGCHIT, C., JOSHI, K. D., and LEDERER, A. L., Process and reality in information systems benefit analysis, in: Information Systems Journal, 8(2), 1998, pp. 145-162. [9] COOPER, K. G., LYNEIS, J. M., and BRYANT, B. J., Learning to learn, from past to future, in: International Journal of Project Management, 20(3), 2002, pp. 213-219. [10] DAVERN, M. J. and KAUFFMAN, R. J., Discovering Potential and Realizing Value from Information Technology Investments, in: Journal of Management Information Systems, 16(4), 2000, pp. 121-143. 562 [11] DHILLON, G., Gaining benefits from IS/IT implementation: Interpretations from case studies, in: International Journal of Information Management, 25(5), 2005, pp. 502-515. [12] DUTTA, A., Putting Numbers on Intangible Benefits, in: Proceedings of the International Conference on Information Systems, Washington, DC, USA, December 12-15, 2004, 2004, pp. 387-398. [13] EARL, M. J., Putting IT in its place: a polemic for the nineties, in: Journal of Information Technology (Routledge, Ltd.), 7(2), 1992, pp. 100-108. [14] FETTKE, P., Eine Untersuchung der Forschungsmethode „Review“ innerhalb der Wirtschaftsinformatik, in: Wirtschaftsinformatik, 48(4), 2006, pp. 257-266. [15] FLAK, L. S., EIKEBROKK, T. R., and DERTZ, W., An Exploratory Approach for Benefits Management in eGovernment: Insights from 48 Norwegian Government Funded Projects, in: Proceedings of the Hawaii International Conference on System Sciences, Waikoloa, Big Island, Hawaii, 2008, pp. 1-10. [16] HART, C., Doing a Literature Review, 1 edition ed. London: Sage Publications Ltd., 1998. [17] HOCHSTRASSER, B., Quality engineering: a new framework applied to justifying and prioritising IT investments, in: European Journal of Information Systems, 2(3), 1993, pp. 211-223. [18] IRANI, Z., Information systems evaluation: navigating through the problem domain, in: Information & Management, 40(1), 2002, pp. 11-24. [19] IRANI, Z. and LOVE, P., Developing a frame of reference for ex-ante IT/IS investment evaluation, in: European Journal of Information Systems, 11(1), 2002, pp. 74-82. [20] IVES, B. and OLSON, M. H., Manager or Technician? The Nature of the Information Systems Manager's Job, in: MIS Quarterly, 5(4), 1981, pp. 49-63. [21] JONEN, A., LINGNAU, V., MÜLLER, J., and MÜLLER, P., Balanced IT-Decision-Card: Ein Instrument für das Investitionscontrolling von IT-Projekten, in: Wirtschaftsinformatik, 46(3), 2004, pp. 196-203. [22] JOSHI, K., A Model of Users' Perspective on Change: The Case of Information Systems Technology Implementation, in: MIS Quarterly, 15(2), 1991, pp. 229-242. [23] KING, W. R. and JUN, H., Understanding the role and methods of meta-analysis in IS research in: Communications of AIS, 2005(16), 2005, pp. 665-686. [24] KLECUN, E. and CORNFORD, T., A Critical Approach to Evaluation, in: European Journal of Information Systems, 14(3), 2005, pp. 229-243. [25] KUMAR, K. and SIBLEY, E. H., Post Implementation Evaluation of Computer-Based Information Systems: Current Practices, in: Communications of the ACM, 33(2), 1990, pp. 203-212. [26] LEDERER, A. L. and MIRANI, R., Anticipating the benefits of proposed information systems, in: Journal of Information Technology (Routledge, Ltd.), 10(3), 1995, pp. 159-169. [27] LEGRIS, P. and COLLERETTE, P., A Roadmap for IT Project Implementation: Integrating Stakeholders and Change Management Issues in: Project Management Journal, 37(5), 2006, pp. 64-75. [28] LIN, C., GUILFOYLE, A., and STANDING, C., The Attribution of Success and Failure by IS Project Professionals, in: Proceedings of the Australasian Conference on Information Systems, Sydney, Australia, 29 Nov – 2 Dec 2005, 2005, pp. 1-12. [29] LOVE, P. E. D. and IRANI, Z., An exploratory study of information technology evaluation and benefits management practices of SMEs in the construction industry, in: Information & Management, 42(1), 2004, pp. 227-242. [30] MARKUS, M. L. and BENJAMIN, R. I., Change Agentry - the Next IS Frontier, in: MIS Quarterly, 20(4), 1996, pp. 385-407. [31] MARKUS, M. L. and ROBEY, D., Information technology and organizational change: Causal structure in theory and research in: Management Science, 34(5), 1988, pp. 583-598. [32] MARTINSONS, M., DAVIDSON, R., and TSE, D., The balanced scorecard: A foundation for the strategic management of information systems, in: Decision Support Systems, 25(1), 1999, pp. 71-88. [33] MCKAY, J., MARSHALL, P., and SMITH, L., Steps Towards Effective IT Governance: Strategic IT Planning, Evaluation and Benefits Management, in: Proceedings of the Pacific Asia Conference on Information Systems, Adelaide, South Australia, 2003, pp. 956-970. [34] MIRANI, R. and LEDERER, A. L., An Instrument for Assessing the Organizational Benefits of IS Projects, in: Decision Sciences, 29(4), 1998, pp. 803-838. [35] MURPHY, K. E. and SIMON, S. J., Intangible benefits valuation in ERP projects, in: Information Systems Journal, 12(4), 2002, pp. 301-320. [36] NELSON, K., Post-project reviews: An examination of determinants, in: Proceedings of the Americas Conference on Information Systems, Tampa, Florida, USA, 2003, pp. 1361-1369. [37] PÄIVÄRINTA, T., DERTZ, W., and SKIFTENES FLAK, L., Issues of Adopting Benefits Management Practices of IT Investments in Municipalities: A Delphi Study in Norway, in: Proceedings of the Hawaii International Conference on System Sciences, Waikoloa, Big Island, Hawaii, 2007. [38] PALVIA, P., MIDHA, V., and PINJANI, P., Research models in information systems in: Communications of AIS, 2006(17), 2006, pp. 2-33. 563 [39] PARÉ, G., Investigating information systems with positivistic case study research in: Communications of AIS, 2004(13), 2004, pp. 233-264. [40] PARÉ, G. and JUTRAS, J.-F., How good is the IT professional's aptitude in the conceptual understanding of change management? , in: Communications of AIS, 2004(14), 2004, pp. 653-677. [41] REICH, B. H., Managing knowledge and learning in IT projects: A conceptual framework and guidelines for practice, in: Project Management Journal, 38(2), 2007, pp. 5-17. [42] REMENYI, D. and SHERWOOD-SMITH, M., Business benefits from information systems through an active benefits realisation programme, in: International Journal of Project Management, 16(2), 1998, p. 81. [43] SERAFEIMIDIS, V. and SMITHSON, S., Information systems evaluation as an organizational institution experience from a case study, in: Information Systems Journal, 13(3), 2003, pp. 251-274. [44] SETHI, V. and KING, W. R., Development of Measures to Assess the Extent to Which an information Technology Application Provides Competitive Advantage, in: Management Science, 40(12), 1994, pp. 1601-1627. [45] SHANG, S. and SEDDON, P. B., A Comprehensive Framework for Classifying the Benefits of ERP Systems, in: Proceedings of the Americas Conference on Information Systems, Long Beach, California, August 10-13th, 2000, 2000, pp. 1005-1014. [46] SILK, D. J., Managing IS benefits for the 1990s, in: Journal of Information Technology (Routledge, Ltd.), 5(4), 1990, pp. 185-193. [47] STONE, D. N., Assumptions and Values in the Practice of Information Systems Evaluation, in: Journal of Information Systems, 4(3), 1990, pp. 1-17. [48] SYMONS, V. J., A review of information systems evaluation: content, context and process, in: European Journal of Information Systems, 1(3), 1991, pp. 205-212. [49] VAN LIER, J. and DOHMEN, T., Benefits Management and Strategic Alignment in an IT Outsourcing Context, in: Proceedings of the Hawaii International Conference on System Sciences, Waikoloa, Big Island, Hawaii, 2007. [50] WALTER, S. G. and SPITTA, T., Approaches to the Ex-ante Evaluation of Investments into Information Systems, in: Wirtschaftsinformatik, 46(3), 2004, pp. 171-180. [51] WARD, J. and DANIEL, E., Benefits Management: Delivering Value from IS & IT Investments. Chichester, England: John Wiley & Sons Ltd., 2006. [52] WARD, J., DE HERTOGH, S., and VIAENE, S., Managing Benefits from IS/IT Investments: Managing Benefits from IS/IT Investments, in: Proceedings of the Hawaii International Conference on System Sciences, Waikoloa, Big Island, Hawaii, 2007. [53] WARD, J., TAYLOR, P., and BOND, P., Evaluation and realisation of IS/IT benefits: an empirical study of current practice, in: European Journal of Information Systems, 4, 1996, pp. 214-225. [54] WEBSTER, J. and WATSON, R. T., Analyzing the Past to Prepare for the Future: Writing a Literature Review in: MIS Quarterly, 26(2), 2002, pp. xiii-xxiii. [55] WEILL, P., The Relationship Between Investment in Information Technology and Firm Performance: A Study of the Valve Manufacturing Sector, in: Information Systems Research, 3(4), 1992, pp. 307-333. [56] ZMUD, R. W. and COX, J. F., The implementation process: A change approach, in: MIS Quarterly, 3(2), 1979, pp. 35-43. 564 SOFTWARE ALS SERVICE Softwarehersteller bieten im Rahmen von „Software-as-a-Service“-Lösungen die Leistung entweder kompletter eigener Softwarepakete oder integrierter Services von unterschiedlichen Herstellern über das Netz zur dezentralen Nutzung an. Das daraus entstehende „Internet der Dienste“ ermöglicht die Entwicklung innovativer Geschäftsmodelle. So können neue ServiceBroker entstehen, die ihren Kunden Implementierung und Betrieb service-basierter Lösungen auf Basis ihrer Plattformen anbieten. Zudem ergeben sich neue Herausforderungen in Bezug auf die Integration, Bepreisung und Abrechnung von „Software-on-Demand“-Applikationen, bei denen etwa Services dynamisch in Anwendungen eingebunden werden. Ziel des Tracks ist, diese Entwicklungen aus ökonomischer und technischer Sicht zu durchdringen. Leitungsgremium: Peter Buxmann, Technische Universität Darmstadt Roland Holten, Johann Wolfgang Goethe-Universität Frankfurt am Main Wolfgang König, Johann Wolfgang Goethe-Universität Frankfurt am Main (Federführender) Dirk Stelzer, Technische Universität Ilmenau Programmkomitee: Thomas Bachem, Sevenload GmbH Heiner Diefenbach, TDS Neckarsulm Alexander Dreiling, SAP Australien Torsten Eymann, Universität Bayreuth Georg Herzwurm, Universität Stuttgart Stefan Neumann, SAP AG Volker Nissen, Technische Universität Ilmenau WELCHE TREIBER LASSEN SAAS AUCH IN GROSSUNTERNEHMEN ZUM ERFOLG WERDEN? EINE EMPIRISCHE ANALYSE DER SAAS-ADOPTION AUF BASIS DER TRANSAKTIONSKOSTENTHEORIE Alexander Benlian, Thomas Hess1 Kurzfassung Vorliegende Forschungsstudie setzt sich zum Ziel, die Adoptionstreiber von Software-as-a-Service (SaaS) in Großunternehmen zu ergründen. Als on-demand Technologiehype wird SaaS sehr stark von IT-Dienstleistern für den Mittelstand beworben. Es existiert bisher jedoch keine empirische Untersuchung, die Tauglichkeit und Adoptionsfaktoren von SaaS für Großunternehmen analysiert. Basierend auf einem transaktionskostentheoretischen Forschungsmodell wurde der Zusammenhang zwischen Applikationsspezifität, Unsicherheit, Transaktionshäufigkeit sowie der Unternehmensgröße und SaaS-Outsourcing in einer großzahligen empirischen Befragung von Großunternehmen untersucht. Die auf Basis eines PLS-Strukturgleichungsmodells abgeleiteten Ergebnisse bestätigen, dass eher kleinere als größere Unternehmen SaaS aktuell und künftig einsetzen und dass Applikationsspezifität der zentrale Adoptionstreiber für SaaS bei Großunternehmen ist. 1. Einleitung Software-on-Demand-Lösungen sind bereits seit den späten 90ern des letzten Jahrhunderts bekannt und seitdem in vielen Formen und Varianten (wie z.B. als Application Service Providing (ASP) oder Business Service Providing (BSP)) immer wieder aufgetaucht. Der gemeinsame Nenner all dieser Software-Bezugsmodelle besteht darin, dass sie IT-Ressourcen und -Expertise sowie ein umfassendes Portfolio an Software-Applikationen über IP-basierte Netze quasi auf Abruf bereitstellen [11]. Während die Diskussionen in der IT Management-, aber auch wissenschaftlichen Literatur um ASP-basiertes Outsourcing wohl aufgrund des mäßigen Erfolgs in letzter Zeit stark nachgelassen haben, zieht ein weiteres Akronym, SaaS (Software-as-a-Service), verstärkt Aufmerksamkeit auf sich. Das Software-Mietmodell nimmt nicht nur auf der Agenda von CIOs und IT Managern von Anwenderfirmen einen prominenten Platz ein, ihm wird sogar vorausgesagt, dass es einen erheblichen Marktanteil als Software-Bereitstellungsoption erobern wird. In einer Befragung von 850 Anwenderunternehmen gaben 74% sogar an, sich auf die Adoption von SaaSPlattformen aktiv vorzubereiten [6]. Obwohl erhebliche Kritik geäußert wird, SaaS sei „alter Wein in neuen Schläuchen“, halten Befürworter einige Vorteile des Mietmodellansatzes dagegen. Das SaaS-Modell sei durch seine reife und flexible Technologie sowie durch die umfassenden Service-Pakete (z.B. im Bereich 1 Institut für Wirtschaftsinformatik und Neue Medien, Ludwig-Maximilans-Universität München, Ludwigstr. 28, 80539 München 567 CRM) für die Anwenderseite nicht nur attraktiver geworden, sondern klingt ebenso durch die verstärkte Service-Orientierung, die Mandantenfähigkeit und den dadurch ermöglichten höheren Auslastungsgrad von IT-Infrastruktur für Dienstleister überzeugender, da diese insbesondere in den Skaleneffekten ihr Anreizsystem sehen [10]. Traditionellerweise ist die Fokussierung auf Kernkompetenzen, attraktivere Kostenmodelle für Anwender, die größere Flexibilität hinsichtlich des Einsatzes von State-of-the-Art Technologien sowie der Mangel an notwendigen IT-Fähigkeiten und Ressourcen die Intention hinter Software-on-Demand-Modellen [12]. Der Auslagerung von IT Applikationen an Drittanbietern in Form von Internet-Services werden jedoch oftmals Risiken hinsichtlich der Zuverlässigkeit, Sicherheit und Prozessabhängigkeiten entgegengehalten, so dass Antworten aus der klassischen IT-Outsourcing-Literatur zu kurz greifen [11]. Aufgrund dieser teilweise undurchsichtigen und vor allem uneindeutigen Gemengelage an Argumenten haben sowohl Praktiker als auch Wissenschaftler bisher große Schwierigkeiten mit einer klaren Einschätzung über die Adoption des Software-Mietmodells. Insbesondere mangelt es an einer Analyse der Beweggründe für die Adoption von Software-on-Demand in Großunternehmen, die in der Bewerbung des SaaS-Modells im Gegensatz zum Mittelstand in der Vergangenheit bisher eher vernachlässigt wurden. Die vorliegende Forschungsarbeit versucht diese Forschungslücken aufzugreifen und zu adressieren. Ziel ist die theoriebasierte Analyse der Fragestellung, ob SaaS zum einen tendenziell eher von kleineren als von größeren Großunternehmen eingesetzt wird, zum anderen welche Treiber die Adoption von SaaS als Sourcing-Modell in Großunternehmen überhaupt beeinflussen können. Während in der Vergangenheit zahlreiche Theorieansätze (wie z.B. Resource-based, Resource Dependence oder die Principal-Agent Theory) bemüht wurden, um (IT-) Outsourcing-Entscheidungen zu fundieren, hat sich die Transaktionskostentheorie (TKT) als stabilster Erklärungsansatz in diesem Kontext herauskristallisiert [4]. Die konkreten Forschungsfragen dieser Arbeit sind: (1) Wie hängt SaaSbasiertes Outsourcing in Großunternehmen von transaktionsbasierten Faktoren wie Applikationsspezifität, Unsicherheit und Transaktionshäufigkeit ab? (2) Welche Rolle spielt die Unternehmensgröße für Großunternehmen bei der Adoptionsentscheidung von SaaS? Der Aufbau dieses Artikels ist wie folgt: Die nachfolgenden beiden Kapitel leiten das transaktionstheoretisch motivierte Forschungsmodell sowie darauf basierende Hypothesen anhand einer Literaturanalyse ab. Anschließend wird die Forschungsmethodik beschrieben, bevor die Ergebnisse dargestellt und diskutiert werden. Das Aufzeigen künftiger Forschungsstränge sowie praktischer Handlungsempfehlungen rundet die Arbeit schließlich ab. 2. Literaturanalyse und theoretische Fundierung Die Transaktionskostentheorie kann neben der Ressourcen-basierten Theorie als ein wesentlich etablierter Erklärungsansatz zur Analyse von IT-Sourcing angesehen werden [4]. Sie stellt einen zentralen Bestandteil der Neuen Institutionsökonomie dar, die von Ronald Coase geprägt wurde [3], der sich den grundlegenden Fragestellungen angenommen hatte, warum Firmen existieren, welche Faktoren die Konzentration innerhalb eines Marktes beeinflussen und welches Aufgabenspektrum und welche Wertschöpfungstiefe Firmen abdecken. Eine der zentralen Aussagen in Coase’ Arbeit war, dass Firmen und Märkte alternative Organisations- bzw. Koordinationsformen seien, die sich bei der Verrichtung der analysierten betriebswirtschaftlichen Aufgaben in der Höhe der Transaktionskosten unterscheiden [3]. Auf Basis dieser theoretischen Vorüberlegungen lässt sich anhand des Transaktionskostenansatzes die Existenz unterschiedlicher Organisationsformen (d.h., Märkte, Bürokratien oder auch Netzwerke) darüber erklären, wie effizient (d.h. im Sinne der Höhe der Transaktionskosten) jede einzelne Organisationsform Austauschbeziehungen zwischen unterschiedlichen Parteien koordiniert. Im Bereich der IS-Forschung wurde die Transaktionskostentheorie insbesondere im Zusammenhang mit der Fragestellung des IT-Outsourcing verwendet [4]. Aus einer kürzlich durchgeführten Inhaltsanalyse zum Stand der Forschung im Bereich des IT-Outsourcing resultierte 568 das Ergebnis, dass acht Dimensionen in diesem Kontext untersucht werden [18]: Vertragsgestaltung, Kultur, Entscheidungsverhalten, Umweltfaktoren, Organisationsformen, Unternehmenserfolg, Beziehungsverhältnis und Strategie. Bezug nehmend auf das Entscheidungsverhalten im IT-Outsourcing, das auch der vorliegende Beitrag adressieren möchte, entstanden in den letzten Jahren zahlreiche Studien, die von der Transaktionskostentheorie motiviert wurden. Aubert et al. verwendeten zum Beispiel ein Transaktionskostenmodell, in dem der Zusammenhang zwischen Kapitalspezifität, Unsicherheit und geschäftsbezogener bzw. technischer Fähigkeiten mit dem Grad des IT-Outsourcing untersucht wurde [1]. Dibbern et al. konzentrierten sich auf die Wirkungen der Spezifität des Humankapitals auf das SourcingVerhalten bezüglich Applikations-Dienstleistungen [5], während Loh ein integriertes multitheoretisches Governance-Modell des IT-Outsourcing entwickelte, das sowohl die Transaktionskosten- als auch die Agententheorie umfasste [13]. Allen drei Studien war gemein, dass sie eine konsistente empirische Unterstützung der Transaktionskostentheorie zur Erklärung der untersuchten Zusammenhänge aufwiesen. Verengt man den Blickwinkel auf on-demand basierte Auslagerungsformen, stellt man fest, dass die IT-Outsourcing Literatur nur ansatzweise Antworten bereithält. Auf der einen Seite existiert eine Anzahl an Forschungsstudien, die Definitionen oder Klassifikationen vornehmen und die spezifischen Eigenschaften von Software-on-Demand explorieren [17]. Auf der anderen Seite beschränken sich empirische Beiträge zu den Determinanten der Adoption von Software-onDemand zumeist auf einige wenige Fallstudien und vernachlässigen hierbei das wissenschaftliche Gebot der Allgemeingültigkeit [11]. Einigen wenigen Arbeiten in diesem Themenspektrum ist schließlich anzulasten, dass sie nur vereinzelte Aspekte der Adoption von Software-on-Demand in jeweils nur einem Land oder nur einer Industrie untersuchen [15]. Zusammenfassend lässt sich konstatieren, dass die aktuelle IS Literatur nur sehr spärlich großzahlig-empirische Ergebnisse zur Analyse des Entscheidungsverhaltens gegenüber on-demand basierten IT Sourcing-Modellen bereithält. Basierend auf diesem Ergebnis ist es das Ziel des vorliegenden Beitrags, diese Forschungslücke zu adressieren und die transaktionstheoretisch motivierten Faktoren auf ihren Einfluss auf SaaS zu untersuchen. 3. Forschungsmodell und Hypothesen Motiviert durch die transaktionstheoretischen Grundzusammenhänge wurde ein Forschungsmodell entwickelt, welches die drei TKT-Faktoren der (Applikations-)Spezifität, Unsicherheit und Transaktionshäufigkeit als auch die zu erklärende Variable „SaaS-basiertes Outsourcing“ umfasst (siehe Abbildung 1). TKT-basierte Konstrukte ApplikationsSpezifität Unsicherheit H1(-) H2(-) SaaSbasiertes Outsourcing H4(-) H3(-) Transaktionshäufigkeit Unternehmensgröße Abbildung 1. Transaktionskostentheoretisches Forschungsmodell zu SaaS-basiertem Outsourcing 569 Ferner wurde als Kontrollvariable die Unternehmensgröße mit in den Bezugsrahmen aufgenommen, um potentielle Größeneffekte zu untersuchen. Nachfolgend sollen die Hypothesen über den Zusammenhang der TKT-Faktoren und der Unternehmensgröße mit SaaS-basiertem Outsourcing abgeleitet werden. 3.1. Applikationsspezifität und SaaS-basiertes Outsourcing Traditionellerweise wird im Kontext der Transaktionskostenanalyse dargelegt, dass Transaktionen mit hoher Kapitalspezifität (d.h. Kapitalinvestitionen, wie z.B. Maschinen oder IT-Systeme) kostengünstiger innerhalb des Unternehmens organisiert werden, während unspezifische Transaktionen effizienter von Drittanbietern angeboten werden können [19]. Die Erklärung, die die Transaktionskostentheorie diesbezüglich bereithält, ist, dass eine hohe Spezifität von Maschinen bzw. IT-Systemen einen hohen Grad an Anpassung an die unternehmensspezifischen Verhältnisse bedeutet. Eine Übertragung hoch spezifischer Maschinen bzw. IT-Systeme auf andere Einsatzszenarien würde deshalb hohe Anpassungs- bzw. Übertragungskosten nach sich ziehen. Eine große Anzahl von Forschungsstudien im Bereich IT-Outsourcing haben die Spezifität von Anwendungssystemen als Erklärungsfaktor mit uneinheitlichen Ergebnissen einsetzen können. Während Nam et al. [14] generell keinen Zusammenhang zwischen der Applikationsspezifität und IT-Outsourcing entdecken konnten, haben Aubert et al. [1] nur inkonsistente Ergebnisse ermittelt. Am anderen Ende des Spektrums konnten Dibbern et al. aufzeigen, dass eine unternehmensinterne Bereitstellung von Softwaredienstleistungen kosteneffizienter und damit vorteilhafter ist, wenn die Spezifität des Humankapitals sehr hoch ist [4]. Im Kontext von SaaS-basiertem Outsourcing lässt sich die Applikationspezifität anhand des Grades der Anpassbarkeit (d.h. Customization), Integrierbarkeit und Modularisierbarkeit vor bzw. in einer Outsourcing-Beziehung ablesen. Basierend auf den bisherigen theoretischen Vorarbeiten lässt sich argumen-tieren, dass je höher die Spezifität eines Applikationstyps ist, desto geringer wird der Outsourcing-Grad bezüglich dieser Applikation sein, da Integrations- und Koordinationskosten in einer Outsourcing-Beziehung höher ausfallen würden als bei einer unternehmensinternen Lösung. Dies führt zu folgender Hypothese: H1: Je größer die Applikationsspezifität, desto geringer der Grad an SaaS-basiertem Outsourcing. 3.2. Unsicherheit und SaaS-basiertes Outsourcing Analog zur Applikationsspezifität übt die Unsicherheit in einer Outsourcing-Beziehung laut der Begründer der Transaktionskostentheorie einen negativen Einfluss auf den Grad des ITOutsourcing aus [19]. Zahlreiche empirische Studien konnten diesen Zusammenhang auch bestätigen. Nam et al. konnten in ihrem empirischen Beitrag feststellen, dass die Unsicherheit über künftige Entwicklungen in der Beziehung zwischen den Vertragspartnern eine signifikante Rolle bei der finalen Outsourcing-Entscheidung spielt [14]. Wie erwartet führte höhere Unsicherheit zu einem geringeren Outsourcing-Verhalten. In ähnlicher Weise fanden Aubert et al. heraus, dass die gefühlte Unsicherheit die größte Hürde für die Auslagerung von IT-Aktivitäten darstellt [1]. Dibbern leitete auf Basis der Vorarbeiten von Williamson [19] zwei Arten von Unsicherheit ab: Geschäftsbezogene und technologiebezogene Unsicherheit [4]. Während sich geschäftsbezogene Unsicherheit auf den Volatilitätsgrad von geschäftsbezogenen Entwicklungen (z.B. bezüglich Preise) vor und während eines Outsourcing-Verhältnisses bezieht, sind mit technologiebezogener Unsicherheit unvorhersehbare Entwicklungen hinsichtlich der Bereitstellung von IT-Diensten (z.B. Servicequalität) gemeint. Basierend auf diesen theoretischen Vorüberlegun-gen lässt sich die Hypothese aufstellen, dass hohe geschäfts- und technologiebezogene Unsicherheit zu einem geringeren Outsourcing-Grad führt, da die Unwägbarkeiten über künftige Entwicklungen in einer möglichen Outsourcing-Beziehung zu erheblichen Koordinationskosten führen würden, welche diejenigen einer unternehmensinternen Lösung übersteigen. 570 H2: Je größer die gefühlte Unsicherheit, desto geringer der Grad an SaaS-basiertem Outsourcing. 3.3. Transaktionshäufigkeit und SaaS-basiertes Outsourcing Die theoretische Fundierung der Transaktionshäufigkeit liegt darin begründet, dass eine höhere Anzahl an Transaktionen zwischen zwei Parteien Routineeffekte mit sich bringt, welche effizienter mit einem hierarchischen als mit dem Marktmechanismus abgebildet werden kann [19]. Dieser Zusammenhang wird durch Aussagen der klassischen Organisationstheorie gestützt, die feststellt, dass größere Interdependenzen zwischen zwei Organisationseinheiten eine verstärkte Notwendigkeit nach sich zieht, beide Einheiten zu integrieren, um Transaktionskosten zu sparen. Transaktionen mit geringerer Häufigkeit werden dagegen mit einer größeren Wahrscheinlichkeit über den Markt absolviert. Im Kontext des IT-Outsourcing konnte dieser Zusammenhang mehrfach bestätigt werden. Aubert et al. konnten in ihrer Studie feststellen, dass häufig genutztes IT-Kapital in der Software-Entwicklung eher „in-house“ organisiert, während sporadisch genutztes IT-Kapital ausgelagert wurde [1]. In ähnlicher Weise kommen Hancox et al. in ihrem Beitrag zu dem Schluss, dass Transaktionshäufigkeit negativ verbunden ist mit der Nutzung des Marktmechanismus [9]. Transaktionshäufigkeit im Zusammenhang mit SaaS-basierten Outsourcing kann in ähnlicher Weise interpretiert werden. Je mehr die Nutzung eines (bestehenden) Systems technische Schnittstellen und menschliche Ressourcen im Sinne von Abhängigkeitsbeziehungen in Anspruch nimmt, desto größer wird die Koordinationskomplexität zwischen den involvierten Parteien sein [4]. Anwendungssysteme, die eine große Transaktionshäufigkeit mit sich bringen, werden im Sinne der Transaktionkosteneffizienz demnach eher unternehmensintern als -extern organisiert. H3: Je größer die Transaktionshäufigkeit, desto geringer der SaaS-Outsourcing-Grad. 3.4. Firmengröße und SaaS-basiertes Outsourcing Die Unternehmensgröße ist eine der meist untersuchten Faktoren in der IS, Organisations- und Innovationsforschung (z.B. [8]). Es bestehen jedoch unterschiedliche Auffassungen darüber, welche Rolle die Unternehmensgröße in der Technoloie-Adoption spielt. Einerseits besitzen Großunternehmen häufig überschüssige Ressourcen (sog. ‚slack resources’ [16]), die für Technologieexperimente eingesetzt werden können. Andererseits sind Großunternehmen tendenziell weniger flexibel als kleine und mittlere Unternehmen, was die Verwendung neuer Technologien betrifft. Diese vergleichsweise größere strukturelle Trägheit kann somit auch zu höheren Kosten der Technologieadoption führen [7]. Im Bereich des IT-Outsourcing haben Kern et al. basierend auf der Transaktionskostentheorie und der ressourcenbasierten Theorie feststellen können, dass sich insbesondere kleine und mittlere Unternehmen (KMUs) für flexiblere Modelle des Software Sourcing interessieren, um auf diese Weise schnell und einfach auf innerbetrieblich fehlende Ressourcen (wie z.B. IT Expertise, State-of-the-Art Technologien etc.) zugreifen zu können [12]. In Anbetracht der empirischen Ergebnisse und der größeren strukturellen Trägheit von Großunternehmen lässt sich folgende Hypothese ableiten: H4: Je größer ein Unternehmen, desto geringer der Grad an SaaS-basiertem Outsourcing. 4. Forschungsmethodik 4.1. Datenerhebung und Stichprobenbeschreibung Um das Forschungsmodell in Abbildung 1 zu testen, wurde ein Fragebogen entwickelt und eine europaweite Befragung durchgeführt. Der Fragebogen wurde auf Basis einer umfassenden Literaturanalyse im Bereich des IT-Outsourcing entwickelt. Die aus der Literatur abgeleiteten Fragebogen-Items wurden anschließend mit jeweils einem IT-Leiter aus den unterschiedlichen Branchen der Stichprobe diskutiert und schrittweise angepasst. Nach diesem Pretest wurde der 571 Fragebogen schließlich im Zeitraum von September bis Dezember in den 5 größten europäischen Ländern (Deutschland, Frankreich, UK, Italien und Spanien) versendet. Die Befragung wurde auf der Ebene von konkreten Anwendungstypen (d.h. Kollaborationssysteme, Content Management Systeme, ERP, HR, SCM, Produktionssysteme, Engineering und CRM) durchgeführt, so dass Unternehmen die Möglichkeit hatten, unterschiedliche Anwendungstypen auf ihre SaaSTauglichkeit und auf die Adoptionstreiber hin zu bewerten. Die Fragebögen wurden insgesamt an 600 Großunternehmen mit einer Mitarbeiteranzahl größer 500 versandt, die zufallsbasiert aus einer Datenbank mit insgesamt 3.000 Großunternehmen bestehend aus Finanzdienstleistern, Maschinenbau-, Logistik-, High-Tech-Unternehmen, Energie-Anbieter und TIME-Unternehmen gezogen wurden. Diese wurden wiederum zufallsbasiert aus einer europäischen Firmendatenbank selektiert, die von einem Marktforschungsunternehmen bezogen wurde. Nach Unterstützung des Rücklaufs durch direkte Telefonkontakte konnten insgesamt 90 vollständige Antworten von 50 Unternehmen gewonnen werden. 4.2. Operationalisierung der Konstrukte Tabelle 1 zeigt die Messmodelle zu den Variablen des Forschungsmodells. Tabelle 1. Messmodelle des Fragebogens Konstrukt Indikatoren SaaS-basiertes Outsourcing Grad des SaaS-basierten IT-Outsourcing [13] Geschätzter Budgetanteil eines Anwendungstyps in Prozent, der auf das SaaSBezugsmodell in 2007 und 2010 entfällt bzw. entfallen wird [4] Grad der Verwendung unternehmensspezifischer Module [11] Grad der Anpassung an Unternehmensspezifika („Customization“) [11] Grad der Integration in bestehende Anwendungslandschaft [11] Technische Unwägbarkeiten bzgl. Bandbreite und Zuverlässigkeit [17] Ökonomische Unwägbarkeiten bzgl. Preis- und Produktänderungen [17] Prozessbedingte Unvorhersehbarkeiten bzgl. Erfüllung von Services [17] Applikationsspezifität (reflektiv) (Gefühlte) Unsicherheit (reflektiv) Quelle Transaktionshäufigkeit (reflektiv) Ausmaß an unternehmensinternen und -externen Schnittstellen der Anwendung [17] Grad an unternehmensinterner und -externer Vernetztheit der Anwendung [17] Ausmaß an Koordinationsaufwand zwischen Anwendern (d.h. Fähigkeiten und Ressourcen) bei der Nutzung der Anwendung [17] Firmengröße Anzahl Mitarbeiter [8] Bis auf eine Frage, in der bezogen auf den zu bewertenden Applikationstyp der Budgetanteil geschätzt werden sollte, der 2007 bzw. 2010 auf das SaaS-Bezugsmodell entfällt, wurden alle anderen Fragen auf einer 5er-Likert-Skala abgefragt (mit „1 = geringer Ausmaß“ bis „5 = hohes Ausmaß“). Die Messmodelle wurden alle von Vorgängerstudien abgeleitet, wie in Tabelle 1 angegeben. 4.3. Überprüfung des Messmodells Inhaltsvalidität wurde durch die Übernahme von Operationalisierungen vorhergehender Studien (siehe Tabelle 1) sowie durch Interviews mit 6 IT-Leitern aus unterschiedlichen Branchen gewährleistet. Die reflektiven Messmodelle wurden anhand der Standardkriterien der State-of-theArt-Literatur validiert [2]. Die Ergebnisse sind in Tabelle 2 aufgeführt. 572 Tabelle 2. Überprüfung der Messmodelle: Faktorladungen und Reliabilität Konstrukte SaaS-basiertes Outsourcing Applikationsspezifität Unsicherheit Transaktionshäufigkeit Firmengröße Anzahl Indikatoren Bereich standardisierter Faktorladungen* Composite Reliability (ρc) Average variance extracted (AVE) 2 0,928 – 0,957 0,941 0,888 3 0,855 – 0,927 0,928 0,812 3 3 0,921 – 0,964 0,695 – 0,900 0,964 0,849 0,900 0,656 1 1,000 1,000 1,000 * Alle Faktorladungen sind mindestens signifikant auf dem Niveau p<0,05. Alle standardisierten Faktorladungen sind statistisch signifikant mindestens auf dem p<0,05Niveau, was Konvergenzvalidität aufzeigt. Zur Untersuchung der Konstruktreliabilität wurden für jedes Konstrukt die sog. „composite reliability“ (CR) berechnet. Alle Konstrukte konnten dabei Werte für die CR aufweisen, die weit über den in der Literatur vorgeschlagenen Schwellenwert von 0,70 lagen [2]. Ferner konnten alle Konstrukte den Schwellenwert für die durchschnittliche extrahierte Varianz (AVE>0,50) überschreiten. Diskriminanzvalidität wurde durch eine Interkonstruktkorrelations-Matrix überprüft, indem nachgewiesen werden konnte, dass die Werte der Quadratwurzel der AVEs jeweils eindeutig größer waren als die Werte der Interkonstruktkorrelationen. Alles in allem konnte festgestellt werden, dass die Messmodelle der Konstrukte alle wesentlichen Validitäts- und Reliabilitätskriterien zufrieden stellend erfüllen und somit verwendet werden können, um das Forschungsmodell zu testen. 5. Analytische Auswertung des Strukturmodells Das auf dem Forschungsmodell in Abbildung 1 beruhende Strukturmodell wurde mit einem auf PLS (Partial least squares) basiertem Strukturgleichungsmodell getestet [2]. Die standardisierten βWerte der Pfadkoeffizienten und die erklärte Varianz R2 als Hauptgütemaß des Strukturmodells werden in Abbildung 2 wiedergegeben. Applikationsspezifität, die (gefühlte) Unsicherheit und Firmengröße hängen negativ signifikant (p<0,001) mit SaaS-basiertem Outsourcing zusammen. Dabei ist der Pfadkoeffizient von Applikationsspezifität fast doppelt so stark wie derjenige von Unsicherheit und fast vier mal so stark wie derjenige der Unternehmensgröße ausgeprägt, was darauf hinweist, dass Applikationsspezifität den weitaus stärksten Treiber von SaaS-Outsourcing darstellt. Der Pfad, der von Transaktionshäufigkeit zur abhängigen Variable führt, ist dagegen nicht signifikant. Insgesamt konnten 80% der Varianz in der abhängigen Variable, SaaS-basiertem Outsourcing, erklärt werden, was als überaus substanziell angesehen werden kann. Weitere Einsichten in die erklärende Kraft einzelner Faktoren können durch die Berechnung der Effektstärke gewonnen werden. Die Effektstärke f2 stellt einen Indikator dar, der angibt, wie sich die erklärte Varianz verändert, wenn ein unabhängiger Faktor aus dem Modell entfernt wird. f2Werte von z.B. 0,02, 0,15 und 0,35 weisen dabei auf Faktoren mit geringer, mittlerer und hoher Effektstärke hin [2]. 573 Großunternehmen Anzahl Mitarbeiter > 500 n=90 TKT-basierte Konstrukte ApplikationsSpezifität Unsicherheit -0.52*** -0,27** SaaSbasiertes Outsourcing R2 =0.80 -0.14*** -0.06ns Transaktionshäufigkeit Unternehmensgröße *p<0.05; **p<0.01; ***p<0.001; ns=nicht signifikant Abbildung 2. Ergebnisse aus der PLS-basierten Strukturgleichungsmodellanalyse Tabelle 3 bestätigt wiederum die Dominanz der Wirkung des zentralen Faktors der Applikationsspezifität in der Beeinflussung des SaaS-basierten Outsourcing-Verhaltens von Großunternehmen. Tabelle 3. Effektstärke der Transaktionskostenfaktoren und Firmengröße f2 (R2delta) Applikationsspezifität 0,28*** Unsicherheit 0,05* Transaktionshäufigkeit 0,01* Unternehmensgröße 0,05* *keine/geringe Effektstärke, **mittlere Effektstärke, ***hohe Effektstärke 6. Diskussion 6.1. Interpretation der Kernergebnisse für Forschung und Praxis Von den TKT-Faktoren ist die Applikationsspezifität der herausragende Treiber Kernergebnis 1: in der Beeinflussung von SaaS-Outsourcing in Großunternehmen. Wie in Abbildung 2 gezeigt, sind die beiden TKT-Faktoren Unsicherheit und insbesondere Applikationsspezifität signifikante und sehr erklärungskräftige Determinanten von SaaS-Outsourcing in Großunternehmen. Diese Ergebnisse reihen sich nahtlos in bisherige Forschungsergebnisse ein. Unsicherheit wurde bereits in Vorgängerstudien als signifikanter Einflussfaktor von ITOutsourcing-Entscheidungen identifiziert. Aubert et al. konstatieren in ihrem Beitrag, dass ein geringerer Grad an geschäftsbezogener und technischer Unsicherheit zu einer geringeren Komplexität und leichteren Messbarkeit der Leistungen des Outsourcing-Verhältnisses kommt, so dass der Wille zu aktiverem Outsourcing zunimmt [1]. Diese Tendenz kann mit vorliegender Studie bestätigt werden. Unsicherheit ist nicht nur in KMUs, sondern auch in Großunternehmen ein wichtiger Faktor bei einer Entscheidung für oder gegen SaaS. Als herausragender Treiber der SaaS-Outsourcingentscheidung in Großunternehmen konnte jedoch, genau wie in vorangegangenen Studien, die Applikationsspezifität identifiziert werden. Die starke Ausprägung dieses Indikators weist darauf hin, dass Großunternehmen insbesondere die Situation ihrer gegenwärtigen Applikationslandschaft ins Kalkül mit einbezieht, wenn es die Tauglichkeit des 574 SaaS-basierten Outsourcing-Ansatzes bewertet. Von einer Auslagerung von Applikationen, die verstärkt an Unternehmensspezifika angepasst sind und deshalb einen hohen (Des-) Integrationsaufwand benötigen, wird verstärkt abgesehen. Da Großunternehmen tendenziell auf eine längere Entwicklung ihrer IT-Anwendungslandschaft (zum Teil mit immer noch recht fragmentierten Legacy-Systemen) zurückblicken können, ist es nicht verwunderlich, dass diese Überlegungen bei der Outsourcing-Entscheidung im Vordergrund stehen. Kernergebnis 2: Unternehmensgröße ist ein hoch signifikanter, jedoch eher moderater Erklärungsfaktor von SaaS-basiertem IT-Outsourcing in Großunternehmen. Unternehmensgröße spielt nicht nur eine wichtige Rolle im Segment des Mittelstandes, sondern auch im Segment der Großunternehmen, wenn es darum geht, sich für oder gegen SaaS zu entscheiden. Das bedeutet, dass Großunternehmen mit einer geringeren Anzahl an Mitarbeitern eine vergleichsweise höhere SaaS-Adoptionsrate aufweisen können als solche mit einer größeren Anzahl. Insgesamt kann damit resümiert werden, dass das Mietmodell SaaS insbesondere im Segment kleinerer bis mittlerer Großunternehmen Anklang findet. Die Ergebnisse halten für Praktiker mehrere interessante Implikationen bereit. Zum einen können IT Manager von Großunternehmen, die die Adoption von SaaS in Erwägung ziehen, technologische und geschäftsbezogene Unsicherheiten vorab klären und sich in künftigen Vertragsverhandlungen dagegen wappnen (z.B. über konkrete Bestimmungen im Preismodell). Zum anderen sollten sich IT Manager insbesondere darauf konzentrieren zu analysieren, wie einfach oder schwer sich ondemand basierte Software Services in die eigene bestehende Prozess- und Anwendungslandschaft integrieren lassen. Eine detaillierte Untersuchung des eigenen Anwendungsportfolios auf Eigenschaften der Applikationsspezifität würde einen wichtigen Vorbereitungsschritt für mögliche Szenarien des SaaS-Outsourcing darstellen. Basierend auf den Ergebnissen, dass Unsicherheitsund Spezifitätsfaktoren eine zentrale Rolle bei SaaS-Outsourcing spielen, sollten auf SaaSAnbieterseite einerseits vertrauensbildende Mechanismen verstärkt in der Außenkommunikation gegenüber Großunternehmen etabliert werden. Andererseits sollten SaaS-Dienstleister darauf achten, dass ihre Angebote nicht bei der bloßen Bereitstellung der Services stehen bleiben, sondern ebenso umfangreiche Integrationslösungen umfassen, die es Anwenderfirmen erleichtern, den Schritt in Richtung SaaS zu wagen. 6.2. Verbesserungspotenziale und künftige Forschungsfelder Obwohl die Ergebnisse aus vorliegender Studie die Relevanz des transaktionskostentheoretischen Forschungsmodells unterstreichen, lassen sich mehrere Verbesserungspotenziale und auch künftige Forschungsfelder identifizieren. Zunächst ist vorliegender Beitrag eine Querschnittsstudie, die ausschließlich Zusammenhänge, jedoch keine Kausalitäten aufzeigen kann. Eine Längsschnittstudie würde sicherlich eine weitere nützliche Perspektive auf längerfristige Wirkungszusammenhänge bieten. Obwohl vorliegende Studie auf einem Datensatz mit sechs Ländern und Industrien beruht, konnte aufgrund der geringen Stichprobengröße keine Unterschiedshypothesen zwischen Kulturen und Industriezweigen durchgeführt werden. Künftige Forschungsbemühungen sollten sich deshalb verstärkt auf die Herausarbeitung von kulturellen und Branchen-Unterschieden bezüglich SaaSOutsourcing konzentrieren. Weitere, eher theoretisch motivierte Forschungsfelder lassen sich aus der Erweiterung des verwendeten Forschungsmodells ableiten. Zum einen ließe sich der transaktionskostentheoretische Bezugsrahmen durch weitere institutionenökonomische, strategische, aber auch verhaltenswissenschaftliche Theorieansätze erweitern, um ergänzende Erklärungsbeiträge abzuleiten. Zum anderen wäre eine stärkere konzeptionelle Durchdringung von Unsicherheit und Applikationsspezifität eine fruchtbare Anregung für künftige Forschungsarbeiten. 575 7. Literaturverzeichnis [1] AUBERT, B. A., RIVARD, S. und PATRY, M., A transaction cost model of IT outsourcing, Information and Management, 41, 7, 2004, S. 921-932. [2] CHIN, W. W., The partial least squares approach for structural equation modelling, in: G. A. Marcoulides (Hrsg.), Modern Methods for Business Research, Lawrence Erlbaum Associates, Hillsdale, NJ 1998, S. 295-336. [3] COASE, R. H., The nature of the firm, Economica, 4, 16, 1937, S. 386-405. [4] DIBBERN, J., Sourcing of application software services. Empirical evidence of cultural, industry and functional differences, Physica-Verlag, Heidelberg, New York 2004. [5] DIBBERN, J. und HEINZL, A., Outsourcing der Informationsverarbeitung im Mittelstand: Test eines multitheoretischen Kausalmodells, Wirtschaftsinformatik, 43, 4, 2001, S. 339-350. [6] DUBEY, A., MOHIUDDIN, J., BAIJAL, A. und RANGASWAMI, M., Enterprise software customer survey 2008, McKinsey & Company and SandHill Group, 2008. [7] DUNCAN, The ambidextrous organization: Designing dual structures for innovation, in: R. H. Kilmann, L. R. Rondy und D. P. Slevin (Hrsg.), The Management of organizations: Strategy and Implementation, North-Holland, New York 1976, S. 167-188. [8] GREMILLION, L. L., Organization size and information system use: An empirical study, Journal of Management Information Systems, 1, 2, 1984, S. 4-27. [9] HANCOX, M. und HACKNEY, R., IT outsourcing framework for conceptualizing practice and perception, Information Systems Journal, 10, 3, 2000, S. 217-237. [10] HESS, T. und WOLF, C. M., Software as a service 1.0 and beyond, in: T. Hess (Hrsg.), Software as a Service: Strategische Perspektiven und praktische Bedeutung, München 2008, S. 8-14. [11] KERN, T., KREIJGER, J. und WILLCOCKS, L., Exploring ASP as sourcing strategy: theoretical perspectives, propositions for practice, Journal of Strategic Information Systems, 11, 2, 2002, S. 153-177. [12] KERN, T., LACITY, M. C. und WILLCOCKS, L., Netsourcing: Renting Business Applications and Services Over a Network, Prentice-Hall, New York 2002. [13] LOH, L., An Organizational-Economic Blueprint for Information Technology Outsourcing: Concepts and Evidence, Proceedings of the 15th International Conference on Information Systems, Vancouver, Canada 1994, S. 7389. [14] NAM, K., RAJAGOPALAN, S., RAO, H. R. und CHAUDHURY, A., A two-level investigation of information systems outsourcing, Communications of the ACM, 39, 7, 1996, S. 37-44. [15] PETERSON, R. R. und FAIRCHILD, A. M., Adoption trends in application service provisioning: an exploratory field study of small and medium-sized enterprises, Proceedings of the European Conference on Information Systems, Naples, Italy 2003. [16] SCHUMPETER, J., Capitalism, Socialism and Democracy, Princeton University Press, Princeton, NJ 1950. [17] SMITH, M. A. und KUMAR, R. L., A theory of application service provider (ASP) use from a client perspective, 41, 8, 2004, S. 977-1002. [18] WIENER, M., Critical success factors of offshore software development projects - the perspective of Germanspeaking companies Gabler, Wiesbaden 2006. [19] WILLIAMSON, O. E., The economic institutions of capitalism: firms, markets, relational contracting, The Free Press, New York 1985. 576 PRÜFKRITERIEN FÜR GESCHÄFTSMODELLE IM KONTEXT VON SOFTWARE AS A SERVICE Matthias Biggeleben, Harald Kolbe, Markus Schäfermeyer, Helena Vranesic1 Kurzfassung Es gibt einen andauernden Diskussionsbedarf, wie innovative, softwarebasierte Services realisiert werden können. Im Zentrum dieser Diskussion steht das Konzept Software as a Service (SAAS), das sich von der klassischen Softwaredistribution unterscheidet und die aktuelle Weiterentwicklung des klassischen Dienstleistungsgedankens widerspiegelt. Neben der technischen Gestaltung von SAAS ist die Entwicklung von Geschäftsmodellen ein noch offenes Feld. Dieser Beitrag identifiziert die betriebswirtschaftlichen Grundprinzipien klassischer Dienstleistungen. Diese Prinzipien werden auf SAAS übertragen, um die ökonomischen Implikationen für die Geschäftsmodellentwicklung abzuleiten. Ziel dieses explorativen Beitrags ist die Entwicklung von Prüfkriterien zur Bewertung von SAAS-Geschäftsmodellen. 1. Einleitung Dienstleistungen repräsentieren im Kontext der Drei-Sektoren-Theorie den tertiären Sektor einer Volkswirtschaft. Beispiele für allgemein bekannte und täglich konsumierte Dienstleistungen des tertiären Sektors sind Handel, Logistik und Verkehr sowie das Kredit- und Versicherungswesen. Neben der Immaterialität sind „klassische“ Dienstleistungen durch eine simultane Produktion und Konsumption sowie dadurch gekennzeichnet, dass ein sogenannter externer Faktor vom Kunden in den Leistungserstellungsprozess des Dienstleisters eingebracht wird [7, 9, 11]. Obwohl die Softwareentwicklung als Dienstleistungsform ebenfalls Teil des tertiären Sektors ist, gibt es einen andauernden Diskussionsbedarf, wie innovative, softwarebasierte Services realisiert werden können. Im Zentrum dieser Diskussion steht das Konzept Software as a Service (SAAS), das sich von der klassischen Softwaredistribution unterscheidet und die aktuelle Weiterentwicklung des klassischen Dienstleistungsgedankens widerspiegelt [20, 22]. Neben der technischen Gestaltung von SAAS ist die Entwicklung von Geschäftsmodellen ein noch offenes Feld. Im Rahmen dieses Beitrags werden zunächst die betriebswirtschaftlichen Prinzipien klassischer Dienstleistungen dargestellt. Anschließend werden diese Prinzipien auf SAAS übertragen, um die betriebswirtschaftlichen Implikationen für die Geschäftsmodellentwicklung abzuleiten. Der Fokus dieser explorativen und deskriptiven Untersuchung liegt auf den folgenden Fragestellungen: Wodurch unterscheidet sich SAAS von der klassischen Dienstleistung? Welche ökonomischen Treiber 1 Universität Frankfurt, Germany 577 beeinflussen SAAS? Welchen ökonomischen Prinzipien müssen bei der Entwicklung von Geschäftmodellen berücksichtigt werden? Dieser Beitrag ist wie folgt aufgebaut. Kapitel 2 definiert den klassischen Dienstleistungsbegriff und stellt die zugrunde liegenden betriebswirtschaftlichen Grundprinzipien dar. In Kapitel 3 wird SAAS als Konzept definiert und gegenüber der klassischen Softwaredistribution abgegrenzt. Ferner wird die technische Machbarkeit zur Bewegung des externen Faktors in Anlehnung an die klassische Dienstleistung diskutiert. In Kapitel 4 werden die identifizierten ökonomischen Prinzipien auf SAAS angewendet. Es werden Prüfkriterien zur Bewertung von Geschäftmodellen entwickelt. Abschließend werden in Kapitel 5 die wichtigsten Implikationen für die Geschäftsmodellentwicklung für SAAS zusammengefasst. 2. Das Dienstleistungskonzept FANDEL und BLAGA definieren Dienstleistungen als immaterielles Ergebnis von Produktionsprozessen und differenzieren sie somit von Sachgütern, die per Definition als materielles Ergebnis von Produktionsprozessen verstanden werden [3]. Dienstleistungen sind nicht lagerbar bzw. vergänglich [9] und werden daher simultan produziert und konsumiert [7]. Ferner stellt die Integration eines externen Faktors in die Leistungserstellung ein konstituierendes Merkmal von Dienstleistungen dar [10]. Dabei liegt der externe Faktor im Gegensatz zu internen Produktionsfaktoren nicht im Einflussbereich des Dienstleisters. Er muss vom Dienstleistungsnehmer aktiv in den Leistungserstellungsprozess des Anbieters eingebracht werden, um nutzenstiftend transformiert werden zu können [2]. So wird beispielsweise in der Logistik durch den Einsatz interner Produktionsfaktoren der Ausgangszustand des Logistikobjektes als externer Faktor in den vom Kunden angestrebten Endzustand transformiert [11]. Im Rahmen der Dienstleistungsproduktion werden einerseits Rationalisierungspotenziale auf Anbieterseite erschlossen [19]. Andererseits wird für den Kunden ein Nutzen in Form von Qualitätsund Kostenvorteilen geschaffen. Dienstleistungsanbieter sind durch die Ausnutzung volumenabhängiger Kostendegressionen in der Lage, Effizienzvorteile zu erzielen. Produktionsfixe Kosten verbunden mit einer zunehmenden Ausbringungsmenge schlagen sich in fallenden Durchschnittskosten nieder. Die auf diese Weise realisierten Skaleneffekte (Economies of Scale) motivieren Dienstleistungsanbieter, hohe Kapazitätsauslastungen anzustreben. Ein bekanntes Beispiel für die Realisierung von Skaleneffekten ist die Vergrößerung der Transporteinheit in der Logistik, wodurch die durchschnittlichen Stückkosten sinken. Zusätzlich können Dienstleistungsanbieter Bündelungseffekte (Economies of Scope) erzielen, indem sie komplementäre bzw. aufeinander aufbauende Dienstleistungen anbieten oder Aufträge unterschiedlicher Kunden miteinander kombinieren. Beispielsweise nutzt der gleichzeitige Vertrieb von Mobiltelefonen und entsprechenden Nutzungsverträgen Bündelungseffekte aus, da hiermit Vertriebskosten eingespart werden können. Call-Center nutzen Bündelungseffekte aus, indem sie ihre Dienstleistung für verschiedene Unternehmen anbieten. Im Fall der externen Leistungserbringung werden Spezialisierungsvorteile (Economies of Skill) als wesentliches Argument für die Fremdvergabe von Leistungen genannt [13]. Grundlage hierfür bilden die aus Lerneffekten resultierende Prozessbeherrschung, das für die Dienstleistungserbringung notwendige Wissen sowie eine effiziente Ressourcennutzung. Fachwissen ermöglicht es, den Prozess der Leistungserbringung effizient durchzuführen [8]. Spezialisierungsvorteile treffen beispielsweise für Handwerker, Steuer-, Rechts- und Unternehmensberater zu. Folglich lassen sich auf 578 Konsumentenseite durch Inanspruchnahme einer Dienstleistung – verglichen mit dem Fall der Eigenproduktion – Qualitätsvorteile sowie Kosten- und Zeiteinsparungen realisieren. Neben den beschriebenen Rationalisierungspotenzialen auf Anbieterseite entscheidet der Zeitpunkt des Markteintritts über Erfolg oder Misserfolg einer Dienstleistung. So existieren zahlreiche Beispiele, in denen sich entweder der „First-Mover“ oder ein sogenannter „Follower“ (auch „SecondMover“ genannt) am Markt durchgesetzt hat. Als Vorteile für den First-Mover gelten nach LIEBERMAN und MONTGOMERY (1) eine überlegene Produkt- und Prozesstechnologie gegenüber potenziellen Wettbewerbern, (2) die Sicherung von Vorkaufsrechten knapper Ressourcen (z. B. die Reservierung einer Absatzregion), die den Markteintritt von Wettbewerbern erschwert sowie (3) der Aufbau von „Switching Costs“, die ein Kunde aufbringen muss, um zum Wettbewerber wechseln zu können [15, 24]. Als Nachteile des First-Movers gelten (1) die hohen Entwicklungskosten für die Innovation gegenüber niedrigeren Imitationskosten, (2) die Unsicherheit bei der Erschließung eines neuen Marktes, (3) die Dynamik der Kundenbedürfnisse und (4) der „Lock-In“ einer Strategie durch getätigte Investitionen. In Ergänzung zu den genannten Rationalisierungspotenzialen und Überlegungen zum Markteintritt, welche auch für die Sachgüterproduktion gültig sind, werden in der Literatur weitere dienstleistungsspezifische Erfolgsfaktoren diskutiert [17, 21]. Dienstleitungen benötigen ein hohes Maß an Kundenorientierung [17]. Neben einem adäquaten Auftritt des Unternehmens und des Personals, wird eine intensive Interaktion zwischen Kunde und Dienstleitungsanbieter gefordert. Ein offener Kundenkontakt sowie eine hohe kulturelle Kompetenz sollen helfen, individuelle Kundenwünsche zu identifizieren [21]. Der Erfolg einer Dienstleistung orientiert sich hauptsächlich an der Kundenzufriedenheit, die insbesondere von der Dienstleitungsqualität abhängt [17]. Daher kommt der Qualitätskontrolle von Dienstleitungen eine besondere Bedeutung zu [21]. Darüber hinaus spielt bei Dienstleistungen der Faktor Arbeit als Potenzialfaktor eine größere Rolle als im Bereich der Sachgüterproduktion [17]. Dementsprechend bedarf es einer zielgerichteten Dokumentation und Zuordnung von Kompetenzen sowie einer Abstimmung von Leistungspotenzialen durch den Dienstleistungsanbieter [17]. Es wird deutlich, dass dienstleistungsspezifische Erfolgsfaktoren den Faktor Mensch im Rahmen der Leistungserbringung fokussieren. Diese Faktoren können im Kontext von SAAS nicht berücksichtigt werden, da die Leistungserbringung vollständig softwarebasiert und damit ohne menschliche Interaktion auf Seite des Anbieters erfolgt. Infolgedessen lässt dieser Beitrag dienstleistungsspezifische Erfolgsfaktoren bewusst außer Acht und konzentriert sich auf die genannten Rationalisierungspotenziale und Überlegungen zum Markteintritt, um Prüfkriterien für Geschäftsmodelle zu entwickeln. Für den weiteren Verlauf dieses Beitrags werden Dienstleistungen wie folgt charakterisiert: (1) Es wird ein externer Faktor vom Dienstleistungsnehmer in die Leistungserstellung eingebracht, (2) die Dienstleistung stiftet einen Nutzen für den Dienstleistungsnehmer, (3) die Dienstleistung basiert auf mindestens einem der genannten Skalen-, Spezialisierungs- oder Bündelungseffekten. 3. Software as a Service 3.1. Begriffsabgrenzung Das Konzept „Software as a Service“ (SAAS) wird vom klassischen Softwarekauf abgegrenzt. Beim Kauf erwirbt der Kunde die Software selbst sowie die Lizenz zur Nutzung der Software [1]. Unabhängig davon, ob das Softwareprodukt mittels eines physischen Mediums oder via Download 579 zum Kunden gelangt, obliegt es dem Kunden, die Software auf eigener Hardware zu installieren und zu betreiben [5]. Beim Konzept von SAAS hingegen obliegen Installation und Betrieb der Software dem Serviceanbieter. Es liegt eine klare Trennung zwischen Nutzung und Betrieb vor [23]. Eng verwandt mit SAAS ist das Konzept des „Application Service Providing“ (ASP). GOLD ET AL. führen zwei Kriterien an, um den Unterschied zwischen SAAS und ASP zu kennzeichnen [4]: (1) SAAS ist wesentlich feingranularer als ASP. SAAS erlaubt auch Services, die alleinstehend keinen direkten Nutzen stiften. (2) SAAS kann auf einem Anbieternetzwerk basieren, d. h. der Serviceanbieter integriert weitere Services von Dritten. Die eindeutige Kunde-Anbieter-Beziehung wird dadurch aufgehoben. Der ASP-Ansatz hingegen basiert auf geringfügig angepasster Standardsoftware. ASP kann als Spezialfall von SAAS verstanden und letzterem untergeordnet werden. Ebenso lässt sich SAAS als nächste Generation von ASP verstehen [14, 20]. Die Vorteile von SAAS liegen in der einfachen und schnellen Orchestrierung mehrerer Services, wodurch ein hoher Grad an Wiederverwendung und Anpassbarkeit erreicht wird [18]. Die Dimensionen, anhand derer zwischen klassischer Software, ASP und SAAS unterschieden werden kann, sind in Abbildung 1 dargestellt. Abbildung 1. Unterscheidung zwischen klassischer Software, ASP und SAAS. Während SAAS und ASP der Geschäftsprozess- bzw. Produktebene zuzuordnen sind, adressieren die hiermit eng verwandten Konzepte „Service-orientierte Architektur“ (SOA) und „WebService“ architektonische bzw. technische Fragestellungen [16]. Mit Blick auf die ökonomischen Merkmale potenzieller Geschäftsmodelle ist jedoch die technische Implementierung irrelevant. Im Folgenden werden unter SAAS diejenigen Softwareprodukte verstanden, (1) die über ein Netzwerk auf der Präsentations- und/oder Applikationsebene über dokumentierte Schnittstellen angesprochen werden, (2) die standardisierte Protokolle und Datenformate zur Kommunikation anbieten und nutzen, (3) die mandantenfähig sind und (4) deren Installation und Betrieb im Verantwortungsbereich des Anbieters liegen. Dadurch fällt nicht jedes ASP-basiertes Angebot unter diese Arbeitsdefinition. Das Angebot einer nicht-mandantenfähigen Office-Umgebung, die ein Kunde mittels Terminal Services erreicht, ist eine softwareorientierte Dienstleistung, die zwar ASP, jedoch nicht SAAS zuzuordnen ist. Dagegen existieren weitbekannte web-basierte Anwendungen, wie bspw. die kundenindividuellen Marketspaces von Amazon oder EBay, die im Sinne der Arbeitsdefinition als SAAS verstanden werden können. 580 3.2. Daten als externer Faktor Problematisch wird die Umsetzung von SAAS, wenn ein Service große Datenmengen des Servicenehmers benötigt. Diese Problematik kann mit dem Einbringen des externen Faktors durch den Kunden in den Leistungserstellungsprozess des Dienstleisters in der klassischen Dienstleistung verglichen werden. Technisch ist diese Problemstellung mit der Enterprise Information Integration verwandt [6]. In diesem Kontext gibt es zwei denkbare Lösungsansätze: (1) Der Servicenehmer überträgt bei jedem Serviceaufruf alle benötigten Daten (Push-Verfahren), (2) der Serviceanbieter fordert die benötigten Daten über eine Rückrufschnittstelle (Callback) des Servicenehmers an (Pull-Verfahren). Das Pull-Verfahren kann durch einen Rückruf auf der Anwendungsebene oder einem Direktzugriff auf die Datenbank umgesetzt werden. Ferner ist ein vollständiger, inkrementeller oder bedarfsgerechter Transfer der Daten denkbar. Mögliche konzeptuelle Lösungen zur Umsetzung von SAAS sind in Tabelle 1 zusammengefasst. Diese werden im Folgenden skizziert und durch Beispiele oder Praxiserfahrungen aus Integrationsprojekten veranschaulicht. Tabelle 1: Mögliche Umsetzungsvarianten von SAAS. Push Pull Applikationsebene Datenbankebene Vollständig Umsetzbar / Fall (1) Nicht umsetzbar Inkrementell Umsetzbar / Fall (2) Nicht umsetzbar Bedarfsorientiert Umsetzbar / Fall (3) Nicht umsetzbar Vollständig Umsetzbar / Fall (4a) Umsetzbar / Fall (4b) Inkrementell Nicht umsetzbar Nicht umsetzbar Bedarfsorientiert Umsetzbar / Fall (5a) Umsetzbar / Fall (5b) Ein vollständiger oder inkrementeller Push auf der Applikationsebene ist umsetzbar (Fall 1 und 2). Der Servicenehmer überträgt sämtliche Daten vor einer Session (Fall 1). Ebenso kann dies bedarforientiert ablaufen, d. h. der Servicenehmer schickt die genau benötigten Daten bei jedem Serviceaufruf mit (Fall 3). Dies entspricht einem klassischen Funktionsaufruf mit bekannten Parametern. Zu Fall (1) konnten praktische Erfahrungen durch einen Autor gesammelt werden. Hierbei musste ein Buchungssystem für Hotels und Ferienwohnungen über Serviceschnittstellen mit einer großen, deutschen Immobilienplattform integriert werden. Die Wohnungsdaten, Belegungspläne und Preise der nächsten 24 Monate werden täglich per Push vollständig übertragen. Alle weiteren Serviceaufrufe basieren auf diesen Daten. Fall (2) wird bspw. durch Google Analytics genutzt. Jeder einzelne Webseitenaufruf sendet über einen sogenannten Tracker entsprechende Informationen an Google Analytics. Die Gesamtanalyse einer Website basiert auf den inkrementell gesammelten Daten. Ein Pull ist grundsätzlich auf Applikations- und Datenbankebene möglich. Der Umweg über die Applikationsebene kann in diesem Kontext mit einem Proxy verglichen werden [6]. Fall (1) und (4) können als gleichwertig verstanden werden; lediglich die Rolle des Auslösers wird getauscht. Der Pull auf Datenbankebene ist jedoch die einfachste Lösung (Fall 4b). Dieser Ansatz wurde ebenfalls praktisch durch einen Autor umgesetzt. Ziel war es, einen täglichen, automatisierten Datenaustausch zwischen dem ERP-System eines Großhändlers (Servicenehmer) und dessen B2B-Plattform (Serviceanbieter) zu realisieren. Als beste Lösung zeigte sich ein direkter Pull durch den Serviceanbieter auf der Datenbankebene des ERP-Systems. Ein inkrementeller Pull ist weder auf der Applikations- noch der Datenbankebene möglich, da der Serviceanbieter nicht weiß, wann neue oder geänderte Daten beim Servicenehmer vorliegen. Ein bedarfsorientierter Pull ist dagegen umsetzbar. Fall (5b) wurde ebenfalls in der zuvor genannten 581 Integration des ERP-Systems und der B2B-Plattform umgesetzt. Diese Lösung überträgt durch einen bedarfsorientierten Pull auf Datenbankebene aktuelle Lagerbestände in Echtzeit aus dem ERPSystem in die B2B-Plattform. Ein aktiver Push auf der Datenbankebene gilt in diesem Beitrag als nicht umsetzbar, da eine Datenbank als rein passives Speichermedium verstanden wird. 4. Implikationen für die Geschäftsmodellentwicklung für SAAS Im Vergleich zur klassischen Dienstleistung zeichnet sich SAAS durch folgende Besonderheiten aus: (1) SAAS ist orts- und zeitunabhängig, da der Service jederzeit über das Internet erreichbar sein muss. Dagegen kann der Markt für klassische Dienstleistungen bspw. geographisch oder auf Grund von Zeitzonen- oder Sprachbarrieren segmentiert sein. (2) SAAS kann im Vergleich zur klassischen Dienstleistung günstiger auf einen großen Kundenkreis skaliert werden. Der Aufbau neuer Kapazitäten verursacht bei SAAS lediglich geringe, sprungfixe Kosten für technische Infrastruktur. Zudem benötigen vollständig automatisierte Dienstleistungen während der Leistungserbringung keine zusätzlichen personellen Aktivitäten. Die tatsächliche Kapazitätsauslastung verursacht somit keine entscheidungsrelevanten Personalkosten. Dies stellt den wesentlichen Unterscheid von SAAS gegenüber der klassischen, personengebundenen Dienstleitung, wie bspw. Handwerk oder Beratung, dar. In Kombination mit der Orts- und Zeitunabhängigkeit führt die skizzierte Kostenstruktur zu einer globalen Wettbewerbssituation mit hohem Wettbewerbsdruck, welche nur wenige Wettbewerber pro Marktsegment erlaubt. (3) Zusätzlich steht SAAS im Wettbewerb zur „make or buy“-Entscheidung potenzieller Kunden. Diese können sich gegen die Servicenutzung entscheiden und die Eigenerstellung oder den Eigenbetrieb eines entsprechenden Softwareprodukts vorziehen. Dies führt zu einer erweiterten „make or buy or rent“-Entscheidung (vgl. Abbildung 2). Abbildung 2. Wettbewerb zwischen SAAS, klassischer Software und der Eigenentwicklung. Die genannten Besonderheiten müssen bei der Geschäftsmodellentwicklung für SAAS berücksichtigt werden. Ein Geschäftsmodell muss demnach in der Lage sein, sich sowohl gegen Wettbewerber als auch gegen die „make or buy“-Entscheidung potenzieller Kunden durchzusetzen. Notwendiges Prüfkriterium für ein Geschäftsmodell ist grundsätzlich die Stiftung von Kundennutzen. Alle weiteren, hinreichenden Prüfkriterien fokussieren die Wettbewerbssituation des Services. An dieser Stelle wird angenommen, dass für SAAS die gleichen Wettbewerbsregeln gelten wie für klassische Dienstleistungen. Die bereits skizzierten Vorteile durch Skalen-, Spezialisierungs- oder Bündelungseffekte sowie den Zeitpunkt des Markteintritts ergänzt KAY noch um eine natürliche Monopolstellung und Exklusivitätsmerkmale einer Leistung [12]. Ein SAAS-Geschäftsmodell ist somit auf die folgenden Wettbewerbsvorteile zu prüfen: (1) Zeitpunkt des Markteintritts (First-Mover), 582 Effizienzvorteile durch (2) Economies of Scale, (3) Economies of Scope und (4) Economies of Skill sowie Vorteile durch (5) Reputation oder Marktanteil und (6) Exklusivität des Services. Ein First-Mover baut durch Innovation ein Alleinstellungsmerkmal auf, d. h. er betritt ein neues Marktsegment, welches er exklusiv bedient. Dieses Geschäftsmodell ist zeitlich limitiert. Der FirstMover ist gezwungen, seine Stellung durch den Ausbau anderer Wettbewerbsvorteile zu festigen, bspw. durch die Realisierung von Economies of Scale, Skill oder Scope. Denn nicht selten wird das Alleinstellungsmerkmal des First-Movers durch einen Follower genommen. Der Follower nutzt ausgereifte Technologien der zweiten Generation, erzielt einen Trittbrettfahrereffekt bezüglich der vom First-Mover aufgebauten Kundennachfrage und lernt aus den Fehlern des First-Movers. Als Gegenbeispiele für eine Festigung der Wettbewerbsposition durch den First-Mover sind hier EBay, Google Search und Salesforce.com als erfolgreiche Follower anzuführen. Das Prinzip der Economies of Scale wird grundsätzlich anhand der Ausbringungsmengen beschrieben. Um Skaleneffekte auf SAAS übertragen zu können, muss die Abarbeitung von Requests als Ausbringungsmenge interpretiert werden. Dieser Menge müssen sprungfixe Kosten zum Aufbau von Kapazitäten gegenübergestellt werden. Sprungfixe Kosten von SAAS fallen für die Anschaffung, den Betrieb und die Wartung der technischen Infrastruktur an. Die Kosten der Softwareentwicklung sind von der Ausbringungsmenge unabhängig und somit für die Betrachtung von Skaleneffekten irrelevant. Durch Bündelung verschiedener Dienstleistungen können Economies of Scope realisiert werden. Die zentrale Eigenschaft von SAAS, verschiedene Services integrieren zu können, schafft Synergieeffekte und somit einen Mehrwert beim Kunden. Ein Beispiel hierfür ist die Kombination von Google AdWords mit Google Analytics, um Werbekampagnen durch umfassende Analysen des Benutzerverhaltens gezielt steuern zu können. Neben dieser Form der Bündelung wird auch die Konsolidierung von Kunden(-aufträgen) den Economies of Scope zugerechnet. Sofern ein Service mandantenfähig ist (Multitenancy), können ungenutzte Kapazitäten durch das Zusammenlegen mehrerer Kunden ausgeschöpft werden. Die hierdurch realisierten Fixkostendegressionseffekte stellen einen Wettbewerbsvorteil des Serviceanbieters dar. Folglich kann der Serviceanbieter bspw. einen niedrigeren Marktpreis anbieten oder durch Kosteneinsparungen Liquidität für Investition, Innovation und Produktentwicklung sichern. Realisierte Economies of Scale und insbesondere Economies of Scope sind die zentralen ökonomischen Treiber, wodurch sich SAAS außerhalb des Wettbewerbs mit anderen Serviceanbietern gegen die kundenseitige Entscheidung „make or buy“ durchsetzen kann. Economies of Skill beschreiben in erster Linie Rationalisierungspotenziale, die durch Fachwissen und einen Vorsprung auf der Lernkurve realisiert werden. In diesem Beitrag werden auch Wettbewerbsvorteile durch Qualitätsführerschaft, das umfassendere Produkt oder das höhere Service Level unter dem Begriff Economies of Skill subsumiert. Je nach Ausprägung des Wissensvorsprungs können Economies of Skill sowohl als Wettbewerbsvorteil als auch als Alleinstellungsmerkmal verstanden werden. Im letzten Fall bildet der Serviceanbieter ein eigenes Marktsegment und steht nicht in Konkurrenz zu verwandten Serviceanbietern. Beispiele für Geschäftsmodelle, die Economies of Skill ausschöpfen, sind SAPs „Business by Design“, Salesforce.com im Bereich Customer-Relationship-Management sowie Google Search im Bereich Suchmaschinen. Die genannten Beispiele grenzen sich durch individuelles Fachwissen, Produktfortschritt, Fehlerfreiheit, Stabilität sowie ein hohes Service Level von der Konkurrenz ab. Die Reputation eines Serviceanbieters kann als Wettbewerbsvorteil und somit als konstituierendes Merkmal eines Geschäftsmodells genutzt werden. Dies gilt insbesondere für SAAS, wenn kritische 583 Daten des Kunden verarbeitet werden. Bekanntheitsgrad und Reputation schaffen Vertrauen bei potenziellen Kunden. Unbekannte Wettbewerber sind dagegen nicht in der Lage, das notwendige Vertrauen für datenkritische Services aufzubauen. Ein ähnliches Merkmal für Geschäftsmodelle stellt die Ausnutzung eines hohen Marktanteils oder der Marktführerschaft dar. Für elektronische Märkte und Communities impliziert ein hoher Marktanteil hohe Besucherzahlen und das Überschreiten der kritischen Masse. Dies kann sowohl vom Markführer genutzt werden, um eigene, neue Services zu etablieren, als auch von dritten Anbietern, die eine strategische Partnerschaft mit dem Marktführer aufbauen. Als Beispiele für die Ausnutzung der Reputation und der Marktstellung dienen auch hier SAPs Business By Design und Salesforce.com. Beide Anbieter genießen das Vertrauen der Kunden und bieten grundlegende Services an. Das Gesamtangebot ergibt sich jedoch erst durch die Integration und Zertifizierung von dritten Serviceanbietern (Economies of Scope), mit denen SAP und Salesforce.com jeweils strategische Partnerschaften eingehen. Von diesem Geschäftsmodell profitieren sowohl der Integrator als auch die Zulieferer. Schließlich stellt Exklusivität ein weiteres Alleinstellungsmerkmal dar. Auf Grund von gesetzlichen Regelungen, exklusiven Vertriebs- oder Patentrechten kann der Serviceanbieter ein Geschäftsmodell außerhalb des Wettbewerbs etablieren. Ferner kann Exklusivität durch die Bildung eines natürlichen Monopols, bspw. durch Skaleneffekte, erreicht werden. Eine zusammenfassende Klassifizierung von Geschäftsmodellen für SAAS findet sich in der folgenden Abbildung 3. Neben der Nutzenstiftung ist ein Geschäftsmodell stets auf Alleinstellungsmerkmale und Wettbewerbsvorteile zu prüfen. Abbildung 3: Prüfkriterien für SAAS-Geschäftsmodelle. 584 5. Schlussfolgerung Gegenüber klassischen Dienstleistungen wurden die Orts- und Zeitunabhängigkeit, die permanente Verfügbarkeit sowie die vernachlässigbaren Personalkosten als Besonderheiten von SAAS identifiziert. Dadurch entsteht ein globaler Markt mit hohem Wettbewerbsdruck innerhalb der jeweiligen Marktsegmente. Hinsichtlich der Wettbewerbssituation gelten für SAAS die gleichen ökonomischen Regeln wie für klassische Dienstleistungen. Der durch ein Geschäftsmodell definierte Service muss grundsätzlich einen Kundennutzen stiften. Darüber hinaus muss ein Geschäftsmodell zwei Prüfkriterien genügen, um sich am Markt etablieren zu können. Entweder (1) kann der Anbieter durch den Zeitpunkt des Markteintritts, durch besonderes Expertenwissen oder durch die Schaffung eines natürlichen Monopols ein Alleinstellungsmerkmal erzielen, oder (2) der Anbieter kann sich durch die Realisierung von Effizienzvorteilen (Skalen-, Bündelungs- und Spezialisierungseffekte) oder seiner Reputation von seinen Wettbewerbern abgrenzen. Ein Anbieter von SAAS befindet sich in einer zweifachen Wettbewerbssituation. Neben der direkten Konkurrenz muss sich ein Geschäftsmodell gegen die „make or buy“-Entscheidung potenzieller Kunden durchsetzen. Aus Sicht des Kunden ergibt sich durch SAAS eine neue Form der Softwarebeschaffung. Der Kunde muss sich zwischen der Eigenproduktion („make“), dem Kauf und Eigenbetrieb einer Softwarelösung („buy“) und der Nutzung eines Serviceanbieters („rent“) entscheiden. Ein Geschäftsmodell muss folglich den Kunden überzeugen können, von einer Eigenentwicklung oder dem Kauf und Eigenbetrieb abzusehen. 6. Danksagung Die Autoren danken den konstruktiven Hinweisen der Gutachter und insbesondere dem Bundesinnenministerium für Bildung und Forschung und seinem Projektträger im Deutschen Luft- und Raumfahrtzentrum e.V., welche diese Arbeit im Rahmen des Forschungsprojektes Mind-Bau (Förderkennzeichen 01FD0611) ermöglicht haben. 7. Literaturverzeichnis [1] CHOUDHARY, V.: Software as a Service: Implications for Investment in Software Development. In: 40th Annual Hawaii International Conference on System Sciences. 2007. [2] CORSTEN, H.: Dienstleistungsbetriebe. In: Handwörterbuch der Betriebswirtschaft. Eds.: R. Köhler, H.-U. Küpper, A. Pfingsten. Edition 6, Stuttgart 2007. [3] FANDEL, G.; BLAGA, S., Aktivitätsanalytische Überlegungen zu einer Theorie der Dienstleistungsproduktion, in: Zeitschrift für Betriebswirtschaft. Bd. 1 (2004). [4] GOLD, N. et al., Understanding Service-Oriented Software, in: IEEE Software. Bd. 21 (2004). [5] GRESCHLER, D.; MANGAN, T., Networking lessons in delivering Software as a Service - Part I, in: International Journal of Network Management. Bd. 12 (2002). [6] HALEVY, A. Y. et al.: Enterprise information integration: successes, challenges and controversies. In: Proceedings of the 2005 ACM SIGMOD international conference on Management of data. Baltimore, Maryland 2005. [7] HILL, T. P., On Goods and Services, in: Review of Income and Wealth. Bd. 23 (1977). [8] HIPPEL, E. V., Cooperation between Rivals: Informal Know-How Trading, in: Research Policy Bd. 16 (1987). [9] HOWELLS, J., Innovation, Consumption and Services: Encapsulation and the Combinatorial Role of Services, in: The Service Industries Journal. Bd. 24 (2004). 585 [10] ISERMANN, H., Logistik: Gestaltung von Logistiksystemen, 1998. [11] ISERMANN, H., Produktionstheoretische Fundierung logistischer Prozesse, in: ZfB-Ergänzungsheft. Bd. 4 (1999). [12] KAY, J. A., Foundations of Corporate Success: How Business Strategies add Value, Oxford 1993. [13] KÖHLER, T. R., Die leise Revolution des Outsourcing - IT-Services aus dem Netz, Frankfurt am Main 2007. [14] LASSILA, A., Taking a Service-Oriented Perspective on Software Business: How to move from Product Business to Online Service Business, in: IADIS International Journal on WWW/Internet. Bd. 4 (2006). [15] LIEBERMAN, M. B.; MONTGOMERY, D. B., First-Mover Advantages, in: Strategic Management Journal. Bd. 9 (1988). [16] MASAK, D., SOA?: Serviceorientierung in Business und Software, Berlin 2007. [17] MEFFERT, H.; BRUHN, M., Dienstleistungsmarketing: Grundlagen – Methoden – Konzepte, Wiesbaden 2006. [18] PAPAZOGLOU, M. P.: Service-Oriented Computing: Concepts, Characteristics and Directions. In: Fourth International Conference on Web Information Systems Engineering (WISE). 2003. [19] PORTER, M. E., Competitive Strategy. Techniques for Analyzing Industries and Competitors, New York 1980. [20] SÄÄKSJÄRVI, M.; LASSILA, A.; NORDSTRÖM, H.: Evaluating the Software as a Service Business Model: From CPU Time-Sharing to Online Innovation Sharing. In: Proceedings of the IADIS International Conference eSociety. 2005. [21] SICHTMANN, C.; GRIESE, I.; KLEIN, M.: Internationalisierung von Dienstleistungen-Erfolgsfaktoren in Abhängigkeit von unterschiedlichen Dienstleistungstypen. In: Neue Herausforderungen an das Dienstleistungsmarketing. Eds.: M. Benkenstein. 2008. [22] TRIPLETREE, Software as a Service: Changing the Paradigm in the Software Industry, Washington, DC 2004. [23] TURNER, M.; BUDGEN, D.; BRERETON, P., Turning Software into a Service, in: Computer. Bd. 36 (2003). [24] WERNERFELT, B., Brand loyalty and user skills, in: Journal of Economic Behavior and Organization. Bd. 6 (1985). 586 ORGANISATIONSKONZEPTE FÜR BUSINESS SERVICES Für den Erfolg des Unternehmens wird es im Wettbewerb immer wichtiger, ein flexibles Business Service Management zu unterhalten, um sich Änderungen möglichst schnell anpassen zu können. Hierfür werden einerseits moderne Organisationskonzepte für Business Services wie etwa ein Managementkonzept der serviceorientierten Architekturen erforderlich. Andererseits werden Methoden wie etwa ITIL benötigt, welche eine möglichst optimale Unterstützung der Geschäftsprozesse mittels Business Services fördern. Gleichzeitig eröffnen serviceorientierte Architekturen neue Möglichkeiten für Organisationskonzepte in Unternehmen und Unternehmensnetzwerken. Die wissenschaftliche Auseinandersetzung mit innovativen Organisationskonzepten und Methoden für Business Services steckt noch in den Kinderschuhen. Ziel dieses Tracks ist deshalb die Auseinandersetzung mit allen Aspekten von Business Services, angefangen von Organisationskonzepten und Infrastrukturen bis hin zu Geschäftsmodellen, Anwendungen, Wirtschaftlichkeitsbetrachtungen und ggf. neuen methodischen Ansätzen zu ihrer Analyse. Leitungsgremium: Arnold Picot, Ludwig-Maximilians-Universität München Rudolf Vetschera, Universität Wien Christof Weinhardt, Universität Karlsruhe (TH) (Federführender) Programmkomitee: Lutz Heuser, SAP Gehard Satzger, Universität Karlsruhe Horst Wildemann, Technische Univeristät München DATA GOVERNANCE: ORGANISATIONSKONZEPT FÜR DAS KONZERNWEITE DATENQUALITÄTSMANAGEMENT Kristin Weber, Boris Otto, Hubert Österle1 Kurzfassung Unternehmen die Datenqualität konzernweit organisieren wollen, stehen vor der Herausforderung, eine geeignete Form zu finden. Spezielle Anforderungen sind die Berücksichtigung unterschiedlicher Interessen und die Koordination aller Anspruchsgruppen. Bisher fehlen sowohl praktische Erfahrungen als auch wissenschaftliche Auseinandersetzungen, so dass Fragen nach der aufbauorganisatorischen Einordnung, der Abstimmung mit anderen Unternehmensbereichen und die Abhängigkeit vom Unternehmenskontext unbeantwortet bleiben. Der vorliegende Beitrag zeigt Möglichkeiten für die Organisation des Datenqualitätsmanagements auf und versucht Antworten auf die Fragen zu finden. Er schlägt die Einrichtung eines Shared Service Centers vor, stellt ein DataGovernance-Modell zur Definition konzernweiter Verantwortlichkeiten für Datenqualitätsmanagement vor und zeigt einen situativen Ansatz für die Gestaltung des Data-Governance-Modells auf. 1. Einführung Unternehmen müssen ihr Geschäftsmodell heutzutage laufend anpassen und weiter entwickeln: Globale Marktpräsenz erfordert weltweit harmonisierte Geschäftsprozesse, Kunden verlangen individuell auf ihre Bedürfnisse zugeschnittene Produkte, und Dienstleistungen werden nach den Prinzipien industrieller Abläufe erbracht. Diese Anforderungen betreffen zum einen die Unternehmensstrategie und die Architektur der Geschäftsprozesse, zum anderen sind Daten von hoher Qualität eine Grundvoraussetzung, um den Anforderungen gerecht zu werden. Probleme aufgrund mangelhafter Datenqualität treten in unterschiedlichen Unternehmensbereichen auf, angefangen bei ineffizienter Beschaffung über fehlendes Verständnis von einzelnen Datenobjekte bis zu Verzögerungen bei der Einführung neuer Produkte [20]. Der Grund ist, dass einige wenige Datenobjekte, zumeist Stammdaten wie z.B. Material, Kunde und Lieferant, in den meisten Geschäftsprozessen eines Unternehmens verwendet werden. Mangelnde Koordination zwischen den „Silos“ hierarchischer Organisationsformen tragen zu schlechter Datenqualität aus Gesamtkonzernsicht bei [9]. Neben fachlichen Anforderungen ist Datenqualität aber auch eine Voraussetzung für Service-Orientierte Architekturen. Wenn Services bereichsübergreifende Geschäftsprozesse 1 Universität St. Gallen, Institut für Wirtschaftsinformatik, CH-9000 St. Gallen, Müller-Friedberg-Strasse 8. 589 abbilden, muss gewährleistet werden, dass Daten aus verschiedenen Applikationen prozessweit die gleiche Definition zu Grunde liegt [4]. Bisher ist jeder Unternehmensbereich die Qualität „seiner“ Daten verantwortlich. Im besten Fall liegt eine übergreifende Verantwortung für Datenqualitätsmanagement (DQM) beim IT Management [10]. Ähnlich wie beim Risikomanagement, für welches seit einigen Jahren ein konzernweit integrierter Ansatz unter dem Schlagwort „Enterprise Risk Management“ erforscht wird [1], muss sich – aufgrund der oben skizzierten Herausforderungen – ein konzernweiter Ansatz für DQM etablieren. Konzernweites Datenqualitätsmanagement (Corporate Data Quality Management, CDQM) bezeichnet vor diesem Hintergrund das qualitätsorientierte Management der Daten mit dem Ziel hohe Datenqualität aus Gesamtkonzernsicht dauerhaft zu gewährleisten. CDQM ist eine Unterstützungsaufgabe die verschiedene Unternehmensbereiche tangiert. Zur konzernweiten Koordination der CDQM Aufgaben müssen Verantwortlichkeiten daher bereichsübergreifend zugeordnet werden. Das dafür erforderliche Organisationskonzept wird als Data Governance bezeichnet. Aufgrund der Neuartigkeit fehlen derzeit praktische Erfahrungen und Data Governance ist bisher wenig erforscht, so dass einige Fragen zur Organisation des CDQM offen bleiben: 1. Wo kann CDQM aufbauorganisatorisch eingeordnet werden? 2. Wie muss CDQM als Unterstützungsaufgabe intern organisiert werden? 3. Wie kann die Abstimmung mit anderen Unternehmensbereichen koordiniert werden? 4. Wie sind diese Fragen in Abhängigkeit vom Unternehmenskontext zu beantworten? Dieser Beitrag zielt darauf ab, Antworten auf diese Fragen zu finden und Konzepte für die Organisation des CDQM aufzustellen. Der Rest des Beitrages ist folgendermaßen aufgebaut. Kapitel 2 beschreibt Grundlagen des konzernweiten Datenqualitätsmanagements und zeigt den Einfluss der Organisation auf Datenqualität auf. Kapitel 3 zieht Analogien für die Organisation des CDQM auf Makro- und Mikroebene aus der Organisationstheorie (Fragen 1 & 2). Kapitel 4 beschreibt das Data-Governance-Modell als Konzept für die konzernweite Koordination des CDQM (Frage 3). Anschließend definiert Kapitel 5 in einem situativen Ansatz die Abhängigkeit von Data Governance zum Unternehmenskontext (Frage 4). Kapitel 6 fasst den Beitrag zusammen. 2. Stand der Wissenschaft und Praxis 2.1. Datenqualitätsmanagement Datenqualität ist definiert durch die Abhängigkeit der wahrgenommen Qualität von den Bedürfnissen des Nutzers und die Fähigkeit, die Anforderungen der beabsichtigten Nutzung in einer bestimmten Situation zu erfüllen („fitness for use“) [18, S.19; 25, S.6]. Datenqualität wird durch eine Menge von Qualitätsattributen (auch Qualitätsdimensionen) aus Sicht des Datennutzers beschrieben. Beispiele für diese Dimensionen sind Aktualität, Vollständigkeit, Konsistenz, Relevanz und Glaubwürdigkeit [25]. CDQM bezeichnet das qualitätsorientierte Management von Daten aus Gesamtkonzernsicht und umfasst die Verarbeitung, Speicherung, Pflege und Darstellung hochqualitativer Daten. CDQM geht damit über die reaktive Verbesserung der Datenqualität hinaus, die u.a. die Identifikation und Bereinigung von Daten mangelnder Qualität umfasst. Vielmehr beinhaltet CDQM die präventive Verbesserung der Datenqualität durch die Verankerung des Qualitätsprinzips in der Unternehmenskultur und einen kontinuierlichen Kreislauf von Prozessen zur Definition, Messung, Analyse und Verbesserung der Datenqualität [9; 24]. CDQM ist also keine Ansammlung von Einzelprojekten 590 mit begrenztem Fokus (z.B. einzelne Datenbanken oder -objekte), sondern stellt eine dauerhafte Unterstützungsaufgabe für fast alle Unternehmensbereiche dar. In den letzten Jahren ist eine Reihe von CDQM Ansätzen entstanden. Total Data Quality Management (TDQM), der aus dem TDQM Programm des MIT entstand, ist der verbreitetste Ansatz [24]. Andere bekannte Ansätze sind Total Quality data Management [9] und Datenqualität für das Informationszeitalter [18]. In diesen Ansätzen steht meist die Definition der Aufgaben des CDQM und nicht dessen Organisation im Vordergrund. Zwei Ansätze [9; 18] definieren Rollen und weisen diesen Aufgaben zu. Ähnlich behandeln praktische Ressourcen die Organisation des CDQM. Sie definieren zumeist neue Stellen oder Rollen oder sie weisen bestehenden Rollen bestimmte CDQM Aufgaben zu [vgl. 28]. Zur Beantwortung der o.g. Fragen sind diese Ressourcen nur bedingt geeignet, da sie alle einen universellen Ansatz verfolgen. Eine Analyse über die Wirkungsweise des Unternehmenskontexts, wie sie für die Gestaltung der IT-Organisation vorliegt [2; 22; 27], existiert für CDQM nicht. 2.2. Einfluss von Organisation auf Datenqualität Hierarchische Organisationsformen tragen zu schlechter Datenqualität aus Gesamtkonzernsicht bei. In der Regel haben nur die obersten Hierarchieebenen einen Überblick über den Gesamtprozess, so dass sich die untergeordneten Ebenen nur auf das Erreichen der jeweiligen Bereichsziele konzentrieren. Dies führt zu einer bereichsbezogenen Optimierung, die hinsichtlich übergreifender Ziele mangelhafte Ergebnisse liefert [17, S.237/263]. Um die einzelnen Bereiche herum werden sogenannte „Silos“ aufgebaut, in welchen andere Bereiche als Feinde und nicht als Partner angesehen werden [19, S. 6f]. Für Datenqualität folgt daraus, dass jeder Bereich die Daten in der für ihn optimalen Qualität vorhält und Teilaspekte des CDQM implizit in seiner täglichen Arbeit ausführt. Da aber insbesondere Stammdaten in mehreren Prozessen, in mehreren Bereichen und Hierarchieebenen verwendet werden, ist die Datenqualität für den Gesamtkonzern nicht gewährleistet [9, S. 376ff]. Diese Organisation führt zudem zu einer Vielzahl unterschiedlicher Vorgehensweisen und fehlenden CDQM Spezialisten [13, S.66]. Weiter ist die Datenerfassung typischerweise von der Datenverwendung organisatorisch getrennt. Mitarbeiter betrachten Stammdaten oftmals als „Abfallprodukt“ eines Prozesses, und wissen nicht, dass diese in Folgeprozessen eine wichtige Funktion haben [24], wie folgendes Beispiel zeigt. Das Stammdatum „Gleis XY“ entsteht im Prozess des Neubaus einer Bahnstrecke. Die Dokumentation des Gleises mit seinen Eigenschaften hat nicht höchste Priorität beim Bauleiter, da dieser anhand anderer Ziele, wie z.B. die pünktliche Fertigstellung der Bahnstrecke gemessen wird. Die nachfolgenden Prozesse, wie z.B. Instandhaltung, Anlagenbuchhaltung und Reporting, sind aber auf diese Daten angewiesen. Die Instandhaltung benötigt zur Wartung z.B. Lage, Länge und Material des Gleises. Für die Anlagenbuchhaltung ist das genaue Fertigstellungsdatum wichtig, da dieses die Basis für den Abschreibungsbeginn ist. Alle Gleise einer Region werden in Berichten zusammengefasst, aufgrund derer Entscheidungen auf höheren Hierarchieebenen getroffen werden. Aus den Kapiteln 2.1 und 2.2 ergeben sich somit folgende Anforderungen an die Organisation des CDQM: unternehmensspezifischer Ansatz mit Bezug zum Unternehmenskontext, gleichzeitige Berücksichtigung unterschiedlicher Interessen auf allen Unternehmensebenen, Aufbau von Spezialwissen an einer Stelle und die Koordination aller Anspruchsgruppen in einem unternehmensweiten Ansatz. 591 3. Organisationskonzepte für CDQM Dieser Beitrag betrachtet die Aufbauorganisation der Unterstützungsaufgabe CDQM auf Makround Mikroebene. Die Aufbauorganisation umfasst die Gliederung eines Unternehmens in Organisationseinheiten, die Verteilung der Aufgaben auf die Organisationseinheiten sowie die Koordination zwischen ihnen [11, S. 24]. Die Makroebene legt wesentliche Merkmale der Aufbauorganisation des Unternehmens fest und gibt durch grundsätzliche Regeln den Rahmen für die Organisation auf Mikroebene vor [11, S. 96ff]. Die Mikroebene definiert die interne Organisation der in der Rahmenstruktur definierten Unternehmensbereiche, z.B. durch Gliederung in Abteilungen und Stellen, Zuweisung von Aufgaben und Festlegung von Koordinationsmechanismen [11, S. 166ff]. Unterstützungsaufgaben bieten Dienstleistungen für die Aufrechterhaltung und Bewältigung der Kernaufgaben, während Kernaufgaben wie Produktion und Vertrieb für die langfristige Sicherung des Unternehmenserfolgs von kritischer Bedeutung sind, da sie einen wahrnehmbaren Kundennutzen stiften [13, S. 41]. 3.1. Makroebene In der Organisationstheorie werden seit einigen Jahren alternative Organisationskonzepte gesucht, da klassische Organisationsprinzipien wie Hierarchie, Bürokratie und Taylorismus Dysfunktionalitäten aufweisen [vgl. 17, S. 235ff]. Speziell die Organisation von Unterstützungsaufgaben als Zentralbereiche führt zu Nachteilen wie mangelnder Kundenorientierung, Inflexibilität gegenüber Veränderungen sowie fehlender Prozesssicht [13, S.65]. Modularisierung als neue Organisationsform zeichnet sich aus durch Prozessorientierung, Kundenorientierung, Abgeschlossenheit der Aufgabe, Bildung kleiner Einheiten, dezentrale Entscheidungskompetenz und Ergebnisverantwortung und nicht-hierarchische Koordinationsformen zwischen Modulen [17, S.231ff]. Ein Beispiel für modulare Organisationseinheiten sind Shared Service Center, welche für die Organisation der Unterstützungsaufgabe CDQM geeignet zu sein scheinen, da die nachfolgenden typischen Eigenschaften von Shared Service Centern auf CDQM zutreffen. Shared Service Center stellen primär Dienstleistungen für interne Kunden zur Verfügung, umfassen grundsätzlich Ausführungsaufgaben (d.h. keine bedeutsamen Entscheidungsaufgaben), werden nur punktuell in Kernprozesse einbezogen und ihre Dienstleistung wird von mehr als einer Organisationseinheit nachgefragt [13, S. 88f]. CDQM ist ein Prozess, der durch einen wissensorientierten Dienstleistungscharakter gekennzeichnet ist – ähnlich externen Beratungsleistungen. Durch die Zusammenlegung des Dienstleistungsangebots in einem „Center of Expertise“ können Spezialisierungsvorteile realisiert werden [13, S.89]. CDQM steht somit anderem Organisationseinheiten in seinem Spezialgebiet als Ratgeber und Koordinator zur Verfügung [17, S.247]. Mögliche Vorteile eines Shared Services Ansatzes liegen in der Senkung von Kosten durch die Erzielung von Skalenerträgen und die Bündelung eingesetzter Ressourcen, in der Erhöhung der Qualität des Prozessoutputs, in einem verbesserten Wissensmanagement, in der Erhöhung der Dienstleistungsbereitschaft und in der Schaffung eines internen Kunden-Lieferanten-Verhältnisses [13, S. 73ff]. Die Dysfunktionalitäten klassischer Organisationsprinzipien, die zu schlechter Datenqualität aus Konzernsicht führen (vgl. Kapitel 2.2), werden durch die Einrichtung eines Shared Service Centers für CDQM alleine nicht behoben. CDQM kann aber dazu beitragen, das Bewusstsein für die datenbedingten Abhängigkeiten der einzelnen Bereiche untereinander zu erhöhen, beispielsweise durch die Definition von konzernweiten Datenerfassungsstandards und Datenqualitätsprinzipien und die Messung von aus Konzernsicht definierter Datenqualität. Ein weiterer wichtiger Aspekt ist daher 592 die konzernweite Festlegung von Verantwortlichkeiten für Datenqualität, die über die reine Organisation des Unterstützungsaufgabe CDQM hinaus geht. Diesen Aspekt behandelt Kapitel 4. 3.2. Mikroebene Bei der Gestaltung des CDQM auf Mikroebene sind besonders wichtig die Verteilung von Entscheidungsbefugnissen, Verteilung von Weisungsbefugnissen und die Kommunikation innerhalb des CDQM und mit anderen organisatorischen Einheiten. Die konkrete Ausgestaltung wird u.a. von den Eigenschaften der Unterstützungsaufgabe CDQM bestimmt. CDQM kann als komplex, variabel und schlecht-definiert beschrieben werden [vgl. 11, S. 184ff]. Anforderungen an die Organisation des CDQM auf Mikroebene sind daher hoher Koordinationsbedarf, anpassungsfähige Organisationsstruktur, Arbeit in Teams, Einsatz von Spezialisten und Bildung von Gremien zur Entscheidungsfindung. Zentral für den Shared Services Ansatz ist die Schaffung marktähnlicher Leistungsbeziehungen zwischen dem Shared Service Center und seinen Kunden – den dienstleistungsnachfragenden Konzerneinheiten. Der Shared Service CDQM hat in diesem Sinne zwei Kunden. Der Konzern beauftragt den Shared Service im Rahmen der konzernweiten Datenqualitätsstrategie mit dem Aufbau des CDQM und der Verbesserung der Datenqualität aus Konzernsicht. Die Konzernleitung muss dem Shared Service daher – abweichend vom reinen Shared Service Center Ansatz – mit eingeschränkter Richtlinienkompetenz gegenüber anderen Organisationseinheiten ausstatten. Leistungen des CDQM sind in diesem Sinne u.a. die Etablierung konzernweiter Vorgaben und Standards sowie die Koordination aller beteiligten Unternehmensbereiche. Die Unternehmensbereiche hingegen fragen gezielt CDQM Dienstleistungen nach, z.B. wenn sie in einem Projekt die Datenqualität einer bereichsspezifischen Applikation verbessern wollen. CDQM unterstützt diese Kunden u.a. mit methodischem Vorgehen und der Durchführung von Einzelmaßnahmen und es agiert als Helpdesk für CDQM. Das Dienstleistungsangebot für die Unternehmensbereiche kann durch Leistungsvereinbarungen (Service Level Agreements, SLAs) institutionalisiert werden. SLAs umfassen in der Regel Beschreibung der Dienstleistungen, Laufzeit, Festlegung von Verantwortlichkeiten und Vereinbarung der Leistungsverrechnung [13, S.115]. Zur besseren Abstimmung der Anforderungen von Kunden und Lieferanten (z.B. der IT) und einer reibungslosen Zusammenarbeit können Gremien und spezielle Stellen mit Koordinationsaufgaben in den liefernden und empfangenden Unternehmensbereichen eingerichtet werden [11, S.188]. Wie diese Koordination gewährleistet werden kann, behandelt das nachfolgende Kapitel. 4. Data-Governance-Modell Durch die oben beschriebenen (stamm-)datenbedingten Abhängigkeiten zwischen einzelnen Unternehmensbereichen ist die reine aufbauorganisatorische Einordnung von CDQM nicht ausreichend für konzernweit hohe Datenqualität. Vielmehr müssen bestimmte Aufgaben verteilt wahrgenommen und die Abstimmung mit allen beteiligten Unternehmensbereichen gewährleistet werden. Für die konzernweite Definition der Aufgaben und Verantwortlichkeiten wird der Begriff „Data Governance“ verwendet. Data Governance identifiziert die konzernweiten Aufgaben im CDQM und legt fest, welche Rollen mit welchen Zuständigkeiten die Aufgaben des CDQM übernehmen. Data Governance legt also die Koordination des CDQM mit den anderen Unternehmensbereichen fest. Data Governance beinhaltet somit drei wesentliche aufbauorganisatorische Gestaltungselemente. (1) Data Governance benennt die Aufgaben, die im CDQM zu erfüllen sind. Hierzu gehören z.B. die Entwicklung von Datenqualitätsstrategie und -prinzipien, die Definition von Datenpflegepro593 zessen und -standards, die Festlegung von Datenqualitätszielgrößen und deren Integration in die Anreizsysteme des Unternehmens [15]. (2) Data Governance identifiziert die an der Ausführung der Aufgaben beteiligten Rollen. Bei den Rollen lassen sich Einzelrollen und Gremien unterscheiden. Neben den Rollen, die durch das Shared Service Center CDQM übernommen werden, sind insbesondere Data Stewards von Bedeutung [7; 9, S. 403ff]. Data Stewards sind spezielle Rollen mit Koordinationsaufgaben in den liefernden und empfangenen Konzerneinheiten. Sie tragen die CDQM Kultur in ihre jeweiligen Bereiche und setzen dort Standards und Prinzipien durch. Auf der anderen Seite leiten sie die bereichsspezifischen Anforderungen an CDQM weiter. Ein Gremium (z.B. „Data Quality Board“) entscheidet in Streitfällen bereichsübergreifende Themenstellungen und überwacht CDQM konzernweit [9, S. 414f; 21, S.20]. (3) Data Governance legt die Zuständigkeiten fest, mit denen die Rollen in der Aufgabenerfüllung involviert sind. Dazu kann beispielsweise die RACI-Notation (Responsible, Accountable, Consulted, Informed) verwendet werden. Die drei wesentlichen aufbauorganisatorischen Gestaltungselemente – Rollen, Aufgaben und Zuständigkeiten – können mithilfe eines Funktionendiagramms modelliert werden. Die Zeilen des Diagramms enthalten dann die Aufgaben, die Spalten die Rollen und die Zellen markieren die Zuständigkeiten. Die Konkretisierung der Gestaltungselemente in einem Funktionendiagramm ist das Data-Governance-Modell (vgl. Abbildung 1). Data Quality Board SSC CDQM Business Data Steward Technical Data Steward Datenqualitätsstrategie A R I I Datenpflegeprozesse I R C I Datenqualitätszielgrößen C A R I R C C Helpdesk … … Legende: R – Responsible; A – Accountable; C – Consulted; I – Inf ormed; SSC = Shared Service Center Abbildung 1. Data-Governance-Modell als Funktionendiagramm (Beispiel) Data Governance ist ein Organisationskonzept und als solches immer unternehmensspezifisch. Die vom Unternehmenskontext abhängige Gestaltung des Data-Governance-Modells bestimmt die Effektivität von CDQM. Diese Grundannahme des situativen Ansatzes der Theorie der Organisationsprinzipien [z.B. 6] wurde von bisherigen Publikationen zu Data Governance weitgehend vernachlässigt. Sie gehen von einem universellen Data-Governance-Ansatz aus und definieren Rollen und Verantwortlichkeiten, die für jedes Unternehmen gleichermaßen gelten sollen [z.B. 9; 21]. Das Data-Governance-Modell bildet den Rahmen für die unternehmensspezifische Gestaltung von Data Governance in Abhängigkeit vom Unternehmenskontext. Rollen und Aufgaben können auf Basis der universellen Data-Governance-Ansätze unternehmensspezifisch gestaltet werden. Kataloge mit typischen CDQM Aufgaben entstehen derzeit [z.B. 15]. Die Spezifität des Data-Governance-Modells wird vor allem durch die Verteilung der Zuständigkeiten bestimmt. Zwei Gestaltungsparameter verdeutlichen die Beziehung zwischen der Verteilung der Zuständigkeiten und dem Unternehmenskontext. Der Parameter Platzierung von Entscheidungsbefugnissen spannt ein Kontinuum zwischen einem streng zentralen Ansatz, in welchem alle Entscheidungsbefugnisse in einer zentralen CDQM Instanz lägen, und einem streng dezentralen Ansatz, in welchem alle Entscheidungen an die ausführenden Stellen delegiert würden [vgl. 2; 3]. Der 594 Parameter Koordination von Entscheidungskompetenzen definiert das Kontinuum zwischen einem hierarchischen Ansatz, welcher sich durch eine vertikale Aufgabendelegierung, Kommunikation, Kontrolle und Überwachung auszeichnet, und einem kooperativen Ansatz, welcher formelle und informelle horizontale Koordinationsmechanismen einsetzt [vgl. 16]. Die Ausprägung dieser zwei Gestaltungsparameter beeinflusst die Zuordnung der Zuständigkeiten im Funktionendiagramm. Der folgende Abschnitt erläutert den Zusammenhang zwischen Unternehmenskontext, Gestaltungsparametern und CDQM Erfolg in einem situativen Ansatz. 5. Situativer Ansatz für Data Governance Der situative Ansatz für Data Governance beruht auf der Theorie der Organisationsprinzipien (auch Kontingenztheorie, engl. contingency theory). Die Theorie besagt, dass die Beziehung zwischen der Eigenschaft einer Organisation und der Effektivität der Organisation von Einflussfaktoren (engl. contingencies) abhängig ist [6]. Eine geeignete Organisationsstruktur (z.B. hierarchisch oder funktional), welche zu den Einflussfaktoren (z.B. Unternehmensgröße, -strategie) „passt“ (engl. fit), soll einen positiven Effekt auf die Effizient, Rentabilität oder Innovationsrate des Unternehmens haben. Im situativen Ansatz für Data Governance ist die Organisationseigenschaft die unternehmensspezifische Gestaltung des Data-Governance-Modells. Das Modell wird durch die Ausprägung der zwei Gestaltungsparameter „Platzierung von Entscheidungsbefugnissen“ und „Koordination von Entscheidungskompetenzen“ repräsentiert. Der Unternehmenskontext wird durch interne und externe Einflussfaktoren definiert. Die Einflussfaktoren beeinflussen die Beziehung zwischen dem DataGovernance-Modell und dem Erfolg von CDQM. Unternehmensspezifisches Data Governance Modell Unternehmensstrategie Wettbewerbsstrategie Diversifikationsbreite Prozessharmonisierung Organisationsstruktur Marktregulierung Art der Entscheidungsfindung Platzierung von Entscheidungsbefugnissen Erfolg des CDQM Koordination von Entscheidungskompetenzen Abbildung 2. Modell des situativen Ansatzes für Data Governance Die sieben Einflussfaktoren sind: Unternehmensstrategie, Aufbauorganisation, Wettbewerbsstrategie, Diversifikationsbreite, Prozessharmonisierung, Marktregulierung, und Art der Entscheidungsfindung. Die ersten sechs Faktoren wirken auf die Beziehung zwischen dem Gestaltungsparameter „Platzierung von Entscheidungsbefugnissen“ und dem Erfolg von CDQM; der letzte Faktor wirkt auf die Beziehung zwischen dem Gestaltungsparameter „Koordination von Entscheidungskompetenzen“ und dem Erfolg von CDQM. Die Einflussfaktoren bestimmten den “Fit” zwischen der Gestaltung des Data Governance Modells und dem Erfolg des CDQM in dem Unternehmen, d.h. die Effektivität der Organisation. Was letztendlich Erfolg in diesem Zusammenhang bedeutet, muss 595 jedes Unternehmen für sich definieren. Das gesamte Modell des situativen Ansatzes für Data Governance ist in Abbildung 2 dargestellt. Der Stand der Wissenschaft und Praxis liefert keine Aussagen, von welchen Faktoren die konkrete Ausgestaltung von Data Governance abhängt. Untersuchungen zur Wirkungsweise der Einflussfaktoren auf Governance-Modelle existieren jedoch für das IT-Management. Der hier vorgestellte situative Ansatz ist ein erster Versuch der Anwendung der Kontingenztheorie auf Data Governance und basiert auf den Erkenntnissen über die Einflussfaktoren aus der IT-Governance-Forschung und deren Wirkung auf die Ausgestaltung der IT Organisation. Die grundsätzliche Wirksamkeit dieser Einflussfaktoren auf Data Governance konnte auf Grundlage mehrerer Fallstudien und Experteninterviews bereits bestätigt werden [s. 26]. Die in Tabelle 1 dargestellten Faktoren beeinflussen die Beziehung zwischen der Platzierung von Entscheidungsbefugnissen und dem Erfolg des CDQM. Für jeden Einflussfaktor zeigt Tabelle 1 eine Definition und Referenzen der IT-GovernanceForschung. Sie stellt die jeweiligen Ausprägungen des Faktors dar, welche für einen zentralisierten, dezentralisierten und ggf. gemischten CDQM Ansatz geeignet sind. Tabelle 1. Einflussfaktoren auf die Platzierung von Entscheidungsbefugnissen Einflussfaktor Unternehmensstrategie: Vorherrschendes Kriterium der Effizienzbewertung [27] Diversifikationsbreite: Grad der Ähnlichkeit der Produkte und Märkte eines Konzerns [2; 3; 22] Organisationsstruktur: Grad der Zentralisierung von Unternehmen [8; 14; 22] Wettbewerbsstrategie: Art des Engagements in Produkt- / Marktentwicklung und Stabilitätsbedürfnis [23] Prozessharmonisierung: Grad der Harmonisierung der Geschäftsprozesse [20] Marktregulierung: Grad der Marktregulierung durch Behörden und gesetzliche Auflagen [1; 12] Zentralisiert Gewinn Große Ähnlichkeit Zentralisiert Gemischt Anlagenausnutzung - Dezentralisiert Wachstum - Geringe Ähnlichkeit Dezentralisiert Verteidiger Analytiker Pionier Global harmonisiert Stark reguliert - Lokale Prozesse - Nicht reguliert Data Governance muss auch die Art der Entscheidungsfindung und die vorherrschende Kultur des Unternehmens berücksichtigen. Tabelle 2 stellt diesen Faktor und seinen Einfluss auf die Beziehung zwischen der Koordination von Entscheidungskompetenzen und dem Erfolg des CDQM dar. Tabelle 2. Einflussfaktoren auf die Koordination von Entscheidungskompetenzen Einflussfaktor Art der Entscheidungsfindung: Informelle Regeln der Entscheidungsfindung [5] Kooperativ Konsensbildung Hierarchisch Kultur der Macht und Kontrolle 6. Diskussion und Zusammenfassung Unternehmen die Datenqualität konzernweit managen wollen, stehen vor der Herausforderung, eine geeignete Organisationsform für CDQM zu finden. Spezielle Anforderungen sind der Bezug zum Unternehmenskontext, die Berücksichtigung unterschiedlicher Interessen und die Koordination aller Anspruchsgruppen. Bisher fehlen sowohl praktische Erfahrungen als auch wissenschaftliche Auseinandersetzungen, so dass Fragen zur Organisation des CDQM unbeantwortet bleiben. Der 596 vorliegende Beitrag zeigt anhand der Organisationstheorie Möglichkeiten für die Organisation des CDQM auf und versucht Antworten auf die Fragen zu finden. Auf der Makroebene kann CDQM als Shared Service Center organisiert sein, welches Dienstleistungen für andere Konzerneinheiten erbringt. Um hohe Datenqualität aus Gesamtkonzernsicht sicherzustellen, ergibt sich auf der Mikroebene ein hoher Koordinationsbedarf mit Kunden und Lieferanten des Shared Services. Das Data-Governance-Modell definiert Verantwortlichkeiten konzernweit und gewährleistet somit Koordination und Interessensausgleich. Durch das Modell können Unternehmen Data Governance in Abhängigkeit vom Unternehmenskontext gestalten. Der hier vorgestellte situative Ansatz für Data Governance gibt Hinweise auf die Wirkungsweise des Kontexts auf das Modell. Der Beitrag stellt organisatorische Fragestellungen in den Vordergrund und zeigt deren Zusammenhang mit CDQM und Datenqualität auf. Die „richtige“ Organisation allein ist jedoch nicht ausreichend um konzernweit hohe Datenqualität zu gewährleisten. Die Wirksamkeit der Organisation hängt auch davon ab, ob es gelingt, Bewusstsein für Datenqualität in der Kultur des Unternehmens zu verankern. Organisatorische Veränderungen müssen grundsätzlich durch Change Management unterstützt werden. Literaturverzeichnis [1] ABRAMS, C., VON KÄNEL, J., MÜLLER, S., PFITZMANN, B., RUSCHKA-TAYLOR, S.: Optimized enterprise risk management, in: IBM SYSTEMS JOURNAL, Vol. 46, 2007, pp. 219-234 [2] BROWN, C.V.: Examining the Emergence of Hybrid IS Governance Solutions: Evidence from a Single Case Site, in: Information Systems Research, Vol. 8, 1997, pp. 69-94 [3] BROWN, C.V., MAGILL, S.L.: Reconceptualizing the Context-Design Issue for the Information Systems Function, in: Organization Science, Vol. 9, 1998, pp. 176-194 [4] BUTLER, D.: MDM as a Foundation for SOA, Oracle Corporation, Redwood Shores 2007 [5] DALLAS, S.: Six IT Governance Rules to Boost IT and User Credibility, Gartner Research, Stamford, CT 2002 [6] DONALDSON, L.: The Contingency Theory of Organizations. Sage Publications, Thousand Oaks, CA, USA 2001 [7] DYCHÉ, J.: A Data Governance Manifesto: Designing and Deploying Sustainable Data Governance, Baseline Consulting, Los Angeles, California 2007 [8] EIN-DOR, P., SEGEV, E.: Organizational Context and MIS Structure: Some Emprirical Evidence, in: MIS Quarterly, Vol. 6, 1982, pp. 55-68 [9] ENGLISH, L.P.: Improving Data Warehouse and Business Information Quality. John Wiley & Sons, Inc., New York, NY 1999 [10] FRIEDMAN, T.: Gartner Study on Data Quality Shows That IT Still Bears the Burden, Gartner Group, Stamford 2006 [11] GROCHLA, E.: Grundlagen der organisatorischen Gestaltung. Poeschel, Stuttgart 1982 [12] GRUNDEI, J.: Examining the Relationship Between Trust and Control in Organizational Design, in: Burton, R.M., Eriksen, B., Håkonsson, D.D., Snow, C.C. (eds.): Organization Design. Springer Science+Business Media LLC, Boston, MA 2006 pp. 43-65 597 [13] KAGELMANN, U.: Shared Services als alternative Organisationsform: Am Beispiel der Finanzfunktion im multinationalen Konzern. Gabler, Wiesbaden 2001 [14] OLSON, M.H., CHERVANY, N.L.: The Relationship Between Organizational Characteristics and the Structure of the Information Services Function, in: MIS Quarterly, Vol. 4, 1980, pp. 57-68 [15] OTTO, B., WENDE, K., SCHMIDT, A., OSL, P.: Towards a Framework for Corporate Data Quality Management, in: Toleman, M., Cater-Steel, A., Roberts, D. (eds.): 18th Australasian Conference on Information Systems. The University of Southern Queensland, Toowoomba, Australia 2007, pp. 916-926 [16] PETERSON, R.: Crafting Information Technology Governance, in: Information Systems Management, Vol. 21, 2004, pp. 7-22 [17] PICOT, A., REICHWALD, R., WIGAND, R.T.: Die grenzenlose Unternehmung: Information, Organisation und Management. Gabler, Wiesbaden 2003 [18] REDMAN, T.C.: Data Quality for the Information Age. Artech House, Boston, London 1996 [19] RUMMLER, G.A., BRACHE, A.P.: Improving Performance - How to Manage the White Space on the Organizaion Chart. Jossey-Bass, San Francisco 1995 [20] RUSSOM, P.: Master Data Management: Consensus-Driven Data Definitions for Cross-Application Consistency, The Data Warehousing Institute, Seattle 2006 [21] RUSSOM, P.: Taking Data Quality to the Enterprise through Data Governance, The Data Warehousing Institute, Seattle 2006 [22] SAMBAMURTHY, V., ZMUD, R.W.: Arrangements for Information Technology Governance: A Theory of Multiple Contingencies, in: MIS Quaterly, Vol. 23, 1999, pp. 261-290 [23] TAVAKOLIAN, H.: Linking the Information Technology Structure With Organizational Competitive Strategy: A Survey., in: MIS Quarterly, Vol. 13, 1989, pp. 308-318 [24] WANG, R.Y., LEE, Y., PIPINO, L., STRONG, D.: Manage Your Information as a Product, in: Sloan Management Review, Vol. 39, 1998, pp. 95-105 [25] WANG, R.Y., STRONG, D.: Beyond Accuracy: What Data Quality Means to Data Consumers, in: Journal of Management Information Systems, Spring 1996, Vol. 12,, 1996, pp. 5-34 [26] WEBER, K., OTTO, B., ÖSTERLE, H.: One Size Does Not Fit All – A Contingency Approach to Data Governance, in: accepted at: ACM Journal of Data and Information Quality, Vol. 2009, pp. [27] WEILL, P., ROSS, J.: A Matrixed Approach to Designing IT Governance, in: MIT Sloan Management Review, Vol. 46, 2005, pp. 25-34 [28] WENDE, K.: A Model for Data Governance – Organising Accountabilities for Data Quality Management, in: Toleman, M., Cater-Steel, A., Roberts, D. (eds.): 18th Australasian Conference on Information Systems. The University of Southern Queensland, Toowoomba, Australia 2007, pp. 417-425 598 STRATEGIC BEHAVIOR IN SERVICE NETWORKS UNDER PRICE AND SERVICE LEVEL COMPETITION Clemens van Dinther1, Benjamin Blau2, Tobias Conte1 Abstract Decentralized service providers specialize on contributing their core competency to an overall goal. This paper focuses on the strategic behavior of service providers within Service Value Networks. We present an abstract model as a formalization of a service value network. The model comprehends an auction-based mechanism design to allocate multiattribute service offers within the network and to determine prices for complex services. Furthermore we study the mechanism theoretically as well as on a simulation basis in order to analyze strategic behavior of service providers within service value networks. 1. Introduction A novel service-oriented economy following strategies such as differentiation, customer-centricity and flexible business is observed in today's service markets. Previous ideas of static value chains are giving way to highly dynamic service value networks formed by many services from different specialized service providers. Companies employ differentiation strategies by shifting resources to focus on their core business. An example is Xignite3 that specializes on providing a broad catalog of financial Web services. Other companies such as Jamcracker4 provide platforms to foster a demand and supply match between service providers and service resellers that offer value added services to customers. In theory, the complex products or services could be produced by a single vertically integrated company. But in this case the company could not focus on its core competencies, having to cover the whole spectrum of the value chain. Additionally, it would have to burden all the risks in a complex, changing and uncertain environment by itself. This is why companies tend to engage in networked value creation which allows participants to focus on their strengths. At the same time rapid innovation in the ICT sector enabled promising opportunities in B2B communication supporting this trend. However, especially in complex and highly dynamic industries, forming value networks – especially business webs with their open structure – is more than an attractive strategic alternative. Prominent advocates of this new paradigm are [19, 12, 21, 18]. Business webs bring together mutually networked, permanently changing legally independent 1 Forschungszentrum Informatik Karlsruhe (FZI), Haid-und-Neu-Str. 10-14, D-76131 Karlsruhe Institute for Information Systems and Management, Universität Karlsruhe (TH), Englerstr. 14, 76131 Karlsruhe 3 http://xignite.com 4 http://www.jamcracker.com/ The project was funded by means of the German Federal Ministry of Economy and Technology under the promotional reference “01MQ07012”. 2 599 actors in customer centric, mostly heterarchical organizational forms in order to create (joint) value for customers. Specialized firms co-opetitively contribute modules to an overall value proposition under the presence of network externalities. In our work we present an abstract model as a formalization of a Service Value Network. The model comprehends an incentive compatible auction-based mechanism design to allocate multiattribute service offers within the network and to determine prices for complex services. Incentive compatibility makes revealing the true type (service configuration and internal costs) a weakly dominant strategy for all service providers. Since incentive compatibility only holds for a one shot game, we study strategic behavior that might improve the SP payoffs. The strategic behavior is studied by means of a simulation-based analysis of two different strategies for service providers within Service Value Networks. We analyze two environmental settings, a price competitive environment as well as competition on basis of service levels. Based on our results we discuss strategic recommendations for service providers depending on how they are situated within the network. The paper is structured as follows: The next section provides a literature overview on path-based procurement auctions and mechanism design in general as well as concepts for trading different kind of services specifically. Subsequently, we proceed with the introduction of a formal model and a mechanism design for allocating and pricing of complex services. The strategic behavior regarding the two strategies deviating from the weak dominant strategy is then analyzed using a simulation approach. We conclude the paper with a summary and an outlook to ongoing research and open questions. 2. Related Work The principles of mechanism design to coordinate self-interested participants in perusing an overall goal are introduced in [16]. These mechanisms mainly apply to auctions of one or multiple units of one good. Thus, the basic auction mechanisms are not suited for auctioning heterogeneous combined services such as complex services. Heterogeneous goods and bundles are usually traded in combinatorial auctions. Nevertheless, combinatorial auctions yield major drawbacks regarding computational feasibility that result from an NP-hard complexity. Computational feasibility implies a trade-off between optimality and valuable mechanism properties such as incentive compatibility. [1, 17] propose approximate solutions for incentive compatible mechanisms to overcome issues of computational complexity. Path auctions as a subset of combinatorial auctions reduce complexity through predefining all feasible service combinations in an underlying graph topology [4]. As a subset of combinatorial auctions, path auctions are introduced in [8, 13] and [2]. In their work, path auctions are utilized for pricing and routing in networks of resources such as computation or electricity. Application-related issues of auctions to optimal routing are examined in [6, 9] and [15]. All of these approaches deal with the utility services layer according to the service classification in [3, 5] and hence do not cover the problems related to elementary services and complex services. The strategy an agent follows when placing bids in an auction is induced by the mechanism’s properties. In incentive compatible auctions agents are incentivized to choose the strategy of revealing their true type. Incentive compatible mechanisms are firstly introduced and extensively investigated by [10, 11, 20]. Most of the research has been done with respect to truth-telling of prices and valuations. In the field of designing incentive compatible mechanisms, that induce truthtelling of non-functional properties of goods or services in multiattribute auctions, a lot of investigation is still missing. Traditional approaches in the area of multiattribute combinatorial auctions are not quite suitable to enable the trade of composite services. Auctions for composite services are much more complex than simple procuring auctions, where the suppliers themselves offer a full solution to the procurer. In composite services, this is not the case, as a flawless service execution and therefore the requester's valuation highly depends on the accurate sequence of its 600 functional parts, meaning that in contrary to service bundles, composite services only generate value through a valid order of their components. 3. Abstract Model & Mechanism Design The abstract model is a formalization of a service value network containing a service requester, service providers and service offers. It captures the networks characteristics using a formal notation. The model comprehends an auction-based mechanism design to allocate service providers within the network and to determine prices for complex services. 3.1. Service Value Network A Service Value Network is represented by an k -partite, directed and acyclic graph G = (V , E ) . Each partition y1 ,K , yK of the graph represents a functionality cluster that entails services that provide the same functionality. The topology information is public knowledge. The set of N nodes V = {v1 ,K , vN } represents the set of Service Offers with v is an arbitrary service offer. Services are offered by a set of Q Service Providers S = {s1 ,K , sQ } with s is an arbitrary service provider. Figure 1 Service Value Network Model The ownership information σ : S → V that reveals which service provider owns which service within the network is public knowledge. There are two designated nodes vs and v f that stand for source and sink in the network. The set of M edges E = {e1 ,K , eM } denotes service invocations such that eij represents an invocation of service j by service i . A service configuration Aj of service j is fully characterized by a set of attributes Aj = {a1j ,K , a Lj } where a lj is an attribute value of attribute type l of service j 's configuration. Let furthermore cij ( Aj ) denote a cost function that maps service j 's configuration to corresponding costs that occur for invocation by service i such that c : A → R . Let F denote the set of all feasible paths from source to sink. Every f ∈ F represents a possible instantiation of the complex service. F−i represents the set of all feasible paths from source to sink without node i and its incoming and outgoing edges. Let Fi be the set of all feasible paths from source to sink that entail node i such that F = Fi ∩ F− i . For illustration purpose, Figure shows a formalization of a Service Value Network with service offers V = {v1 ,K , v4 } . Every feasible path from source to sink represents a possible realization of the overall complex service. 601 3.2. Mechanism Design The goal of the service requester is to maximize her utility U . Therefore she has to solve the problem of allocating a path f * within the complex service network that yields the highest overall utility. Let Uf denote the overall utility of path f . (1) o := argmax f ∈F Uf Let U* denote the utility of the winning path meaning the utility of a path f * that maximizes the requesters utility U . Let U−*s denote the utility of a path f −*s that yields a maximum utility for the service requester in the reduced graph without every service owned by service provider s and its incoming and outgoing edges. Every service provider s receives a payment or transfer t s = ∑ i∈τ ( j ), j∈σ ( s ),e ∈ f * t sj for all services she ij owns which are on the winning path. A payment t for service j corresponds to the monetary s j equivalent of the utility gap Δu j between the winning path and second best path. In other words a monetary equivalent to the utility service j contributes to the overall utility of the complex service. This monetary equivalent represents the price that service provider s could have charged without losing her participation in the winning allocation. (2) t sj := pij + ( U* − U−*s ) Consequently the payment function t s for service provider s is defined as ⎧ ∑ ∑ pij + ( U* − U−*s ), if eij ∈ o ⎪ s t := ⎨ j∈σ ( s ) i∈τ ( j ) (3) ⎪⎩0, otherwise Costs c s that service provider s has to bear for performing offered and allocated services result accordingly: ⎧ ∑ ∑ cij ( Aj ), if eij ∈ o ⎪ s (4) c := ⎨ j∈σ ( s ) i∈τ ( j ) ⎪⎩0, otherwise 3.3. Bidding Language As a formalization of information objects which are exchanged during auction conduction we introduce a bidding language for requesters and providers. Our formalization assures compliance with the WS-Agreement specification in order to enable realization in decentralized environments such as the Web. A service requester wants to purchase a complex service f which is characterized by a configuration A f . The importance of certain attributes and prices of a requested complex service is idiosyncratic and depends on the preferences of the requester. The requester's preferences are represented by a utility function U of the form: (5) Uf (α , Λ, A , P ) = α S ( A f ) − T f T f denotes the sum of all transfer payments the requester has to transact to service providers that contribute to the complex service such that T f = ∑t eij ∈ f 602 j . The configuration A f of the complex service is the aggregation of all attribute values of contributing services on the path f such that A f = (A 1f ,K , A fL ) with A fl = ⊕eij ∈ f a lj . The aggregation of attributes values depends on their type (i.e. encryption can be aggregated by an AND operator whereas response time is aggregated by a ⎛ L ⎞ sum operator). The scoring rule S ( A f ) = ⎜ ∑ λl A f l ⎟ represents the requester’s valuation for a ⎝ l =1 ⎠ configuration A f of the complex service represented by path f . The scoring rule is specified by a set of weights Λ = {λ1 ,K , λL } with ∑ L l =1 λl = 1 that defines the requester’s preferences of each attribute type. To assure comparability of attribute values from different attribute types the aggregated attribute values A f l are mapped on an interval [0;1] . T f represents the overall price of the complex service. α can be interpreted as the willingness to pay for a optimal configuration S ( A f ) = 1 based on the requester’s score. In other words α defines the substitution rate between configuration and price based on the requester’s preferences. Definition 1. MULTIATTRIBUTE SERVICE REQUEST A request for a complex service is a triple of the form R := (G, F , α , Λ, Γ) (6) with G represents a complex service network, F represents all feasible paths from source to sink that form a possible instantiation of a complex service, Λ the requester’s preferences and α the willingness to pay. Γ denotes the set of lower and upper boundaries for each attribute type. A service offer consists of an announced service configuration Aj and a corresponding price bid pij that a service provider wants to charge for service j being invoked depending on the predecessor service i such that bij (eij ) = ( Aj , pij ) is a service offer bid for invocation of service j which interoperable with a predecessor service i with b : E → A × R . A service provider s bids for all incoming edges to every service she owns. Definition 2. MULTIATTRIBUTE SERVICE OFFER A multiattribute service offer is a set of bids of the form (7) ⎧b (e ) = ( Aj , pij ), i ∈τ ( j ), j ∈ σ ( s) B s := ⎨ ij ij otherwise ⎩0, with τ (v) denotes the set of all predecessor services to service v with τ :V → V and σ ( s) the set of all services owned by service provider s . 4. Strategic Alternatives The proposed mechanism is incentive compatible for a one shot, i.e. it is a weak dominant strategy to bid the true cost. We assume that participants cannot communicate directly in a non-iterated 603 game. In contrast, the iterated game gives participants the opportunity to tacitly collude through their bidding behavior. Consider the following cases: 1. All service providers (SP) submit bids at 10% above their true cost. The allocation remains the same but the SPs receive a higher payment since the claimed costs are higher and the individual utility surplus remains equal. As such, at least the allocated SP wished that everyone submits higher bids. 2. For those SP that are not allocated it is beneficial to submit bids at their true cost in order to produce a higher utility, and as such, increase the likelihood of being allocated. 3. Let SP i being allocated at true cost and let SP i be the only SP submitting a bid above its true valuation. Due to the higher costs the utility the SP generates decreases and as such the likelihood of being allocated also decreases. If SP i is allocated anyway the payment decreases due to the smaller difference of the utility surplus. As such, it is not beneficial for SP i to submit cost above the true valuation. The situation changes if other SPs also submit cost above the true valuation since the utility difference might increase. In that case submitting higher costs can be beneficial. 4. Let SP i submit bid at true valuation and being allocated. Let SP j submit bids above the true valuation and being part of the second best allocation possibility. This bidding behavior will lead to a higher payment for SP i. As such, SP i prefers other SPs to submit bids above their true cost. We investigate this strategic decision problem by means of simple agent-based simulations. Inspired by the work of [14] we implement two simple strategies, probe-and-adjust (PA) and adjust-dependent-on-own-and-cluster-return (AOCR). Both strategies are reactive and do not implement any sophisticated learning algorithm. In so far, we follow a pure agent-based approach [7]. 4.1 Strategies Each SP has four action alternatives. She can either bid the true cost or increase the bid up to four times by discrete steps at 0.03 currency units. In total each SP has five bid alternatives, true cost or true cost + i times 0.03 and {i=1,.., 4}. 4.1.1 Probe and Adjust (PA) The first reactive strategy is called Probe-and-Adjust. Those SP which are allocated increase the bid at one discrete step as long as they drop of the best path or they reach the upper cost limit (true cost + 0.12 currency units). All SP which are not allocated decrease the bid by one discrete cost step until they are either allocated or they bid their true cost. 4.1.2 Adjust Dependent on Own and Cluster Return (AOCR) The second reactive strategy considers not only the individual return but also the market returns of the direct competitors in the same functional cluster. The aim is to maximize cluster return but not on own cost, i.e. we identify four cases, (1) actual cluster return is greater than the one the round earlier and SP i (a) is allocated and (b) SP is not allocated, as well as (2) the cluster payment is equal or lower than the one the round earlier and SP i (a) is allocated and (b) is not allocated respectively. Dependent on the described situation the SP take the following actions: (1a) SP i increases her bid by one discrete step, (1b) SP i does not change her bid, (2a) SP i does not change her bid, (2b) SP i decreases her bid by one discrete step. 604 4.2 Hypothesis development We study the results of strategic behavior under two competitive situations, price competition (PC) and quality competition (QC). In the price competition scenario all SP of one cluster offer their services at the same quality level but different price levels, i.e. the true costs of the SP differ slightly. Since competition takes place not only on prices but also on quality the offered services differ additionally in quality of one service attribute in the quality competition scenario. Let all SP in the network follow the PA strategy in the PC scenario we expect that prices will reach the true valuation equilibrium (when all SP bid their true valuation). In contrast, we expect prices to reach a level between the true valuation equilibrium and the high bid equilibrium (when all SP submit bids at the highest possible level) while all SP follow the AOCR strategy in the PC scenario. We expect a different picture for the QC scenario. Since the quality level largely impacts the service requesters’ utility we expect that SP can exploit their competitive advantage by submitting higher bids which will lead to higher payments on average. Thus, we derive the following hypothesis: • • • • • H1: In the PC scenario with only PA strategies payments will converge to the true valuation equilibrium H2: In the PC scenario with only PA strategies the deviation from the weak dominant strategy will be low, i.e. submitting the true valuation is the most frequently chosen strategy. H3: In the QC scenario the diversification on the basis of service quality decreases competition, and as such, will lead to a higher number of deviators from the weak dominant strategy (truth telling). H4: In the QC scenario the deviation from truth telling leads to higher payments for allocated SP. H5: AOCR strategy leads to higher payments of the allocated services compared to the PA strategy. 4.3 Simulation Model We apply a simulation approach to study these questions. We model the problem as a n-person game in which each node represents a service offer. We assume that SPs only own a single service. As such, we use the terms node and SP synonymously. Each SP follows one of the reactive strategies which it is assigned at the beginning of the simulation run. Thus, in each period t ∈ {1,K , T } each node i observes the own payoff r as well as the payoff r* of the best node in the cluster. The payoff r resulting from the action chosen is dependent on the topology of the network, the service requests, the offers of all nodes (including functionality and price). Regarding one topology all these factors are stochastic. As such, the node’s action decision does not solely control the payoff. Thus, the decision problem of the nodes is comparable to an n-armed bandit problem. After having decided on an action, the best path is computed as well as the payoffs for all nodes on the path. The first action is chosen arbitrarily. 4.4 Simulation Settings We conduct simulations with N = 20 nodes in 4 arbitrary chosen topologies with 5 functionality clusters and a density of 0.8 . This results in 20 simulation runs. Each simulation run has T=50 periods. The cost per link are drawn from a uniform distribution in the interval [0.5, 0.7] and assigned for each simulation run. Attribute values for response time ( ∈ [0;1] ) and encryption ( ∈ [0;1] ) are assigned at a fix value of 0.5. Link costs and attribute values stay fix over all simulation periods but SP can decide to submit bids above their true cost. The service requester’s 605 preferences are also fixed for each of the simulation periods in a way that he weights attribute values and price equally. Furthermore total path prices, and consequently, overall path utilities are normalized to the interval [0;1] . We run simulations for four different scenarios: (1) all nodes offer the same service levels and use the PA strategy (PC-PA), (2) all nodes use PA but offer different service levels for the attribute “response time” (QC-PA), (3) all nodes follow the AOCR-strategy and offer the same service levels (PC-AOCR), and (4) the nodes offer different service levels for the attribute “response time” and all follow the AOCR-strategy (QC-AOCR). 4.5 Results and Assessment First, we analyze descriptive parameters. Table 1 displays the average values of the sum of payments to the SP in the network. We compare the total-network payments for all SP submitting their true valuation and compare it to the total-network payments achieved by the SP which were also allowed to deviate from the true valuation. The received surplus (achieved payoffs – true valuation payoffs) is positive in all four scenarios which supports our assumption that collusion might be beneficial. Additionally, we observe that the total surplus is lower in the AOCR scenarios compared to PA scenarios. Besides the total networks payoffs it is also important to study the individual payments especially of those SP who would be allocated while playing the true valuation. Table 2 displays the average individual payoffs as well as the average individual payoff while playing the true valuation strategy. Table 1 Aggregated Payments of all SPs in the Network mean payments total-network (truth-telling) mean payments total-network (achieved) mean surplus total-network (achieved) surplus (%) PA-PC 2,899 2,971 0,072 2,48% PA-QC 3,166 3,309 0,142 4,49% AOCR-PC 2,899 2,943 0,043 1,49% AOCR-QC 3,166 3,203 0,037 1,16% Figure 1 Development of Aggregated SP Payments (PA-PC Setting) Table 2 Individual Payoffs of Thruth-Telling SPs mean payments per allocated SP (true valuation) mean payments allocated SP (achieved) mean surplus allocated SP (achieved) surplus (%) PA-PC 0,580 0,570 -0,009 -1,60% 606 PA-QC 0,633 0,642 0,009 1,44% AOCR-PC 0,580 0,593 0,014 2,35% AOCR-QC 0,633 0,655 0,022 3,40% The comparison of the average individual payoffs draws a different picture compared to the comparison of the aggregated payoffs. Following the PA-strategy in a price competition environment even leads to negative payoffs. Payoffs are larger for the AOCR-strategy. We also observe that the quality competition leads to higher individual payments on average compared to the price competition scenarios regardless of the strategy chosen. Unfortunately, the performed ttests do not support this observation on a significant level. Consequently, we do not find significant support for Hypothesis H5. In contrast, we find support for Hypothesis H1 since the t-test does not support significant difference of the true-valuation payments and the PA-PC payments. Regarding H4 stating that it is beneficial in the AOCR-QC scenario to deviate from truth telling for those SP that would be allocated while submitting their true cost, we perform a single sided t-test and find significant support on a level of p = 0.02 . Figure 2 shows exemplarily the course of one simulation run in the PA-PC setting. The payment sum converges already after a few repetitions close to the true-valuation-equilibrium as expected. We observe similar results in the simulation runs of the same setting with different network topologies. This additionally supports H1. Figure 2 Frequency of Successful Actions Chosen by Allocated SPs Regarding Hypothesis H2 and H3, we investigate both, the frequency of actions taken by all SP (incl. those SP that are not allocated) as well as the frequency of actions taken by the successful SPs. Figure 3 display the frequency of successful actions. Comparing the frequency of submitting true cost in the PA-PC vs. PA-QC we observe a decrease in the number of successful truth tellers. Unfortunately, we do not find significant statistical support since the t-test produces a p-value of 0.09, and thus, the null-Hypothesis cannot be rejected. 5 Conclusion In the present paper we describe that the fundamental change from a product-oriented to a serviceoriented economy fosters the formation of service value networks. Service providers offer their services within these networks. Service requesters combine different service offers to complex services best matching their preferences. The main question in service value networks is how to efficiently match service offers and complex service requests and dynamically determine prices. We propose an auction-based approach as a central allocation mechanism for multi-attribute services. Therefore, we introduce a formal model for service value networks as a k-partite, directed and acyclic graph, we specify the bidding language to define service offers and service requests, and we introduce the incentive compatible auction mechanism. In a repeated game incentive compatibility does not hold. We study two simple strategies to collude by means of an agent-based simulation approach. The simulation results show that deviating from truth telling might be 607 beneficial especially for those SP who are in the allocation. The payments of SP can increase especially if the service quality offers are diverse and as such the difference in prices does not play a such important role as in a price competition regime. We are aware that the results are based on a simple model with relatively strict assumptions. We have just studied two simple strategies, but there certainly exist a couple of more sophisticated strategic alternatives. Additionally, we did not take varying preferences of service requesters into account. As such, the results are model-specific and a generalization is to be proven with additional simulations based on real-world data. During the model development a couple of ideas for future work came up. The most interesting aspect is to introduce additional strategies and also to study mixed strategy settings. We are also interested in using a learning mechanism in order to discover additional strategies. In the present model and simulation we have studied one proposed mechanism which we want to compare to alternative mechanisms, e.g. first-price auctions in which bidding strategies play a very important role. 6 References [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20] [21] Ahuva Mu’alem and N. Nisan, Truthful Approximation Mechanisms for Restricted Combinatorial Auctions, Games and Economic Behavior (2007). A. Archer and E. Tardos, Frugal path mechanisms, ACM Trans. Algorithms, 3 (2007), pp. 3. B. Blau, C. Block and J. Stößer, How to Trade Services? - Status and Open Questions, Group Decision and Negotiation (GDN), 2008. B. Blau, D. Neumann, C. Weinhardt and W. Michalk, Provisioning of Service Mashup Topologies, Proceedings of the 16th European Conference on Information Systems, ECIS 2008, 2008. B. Blau and B. Schnizler, Description Languages and Mechanisms for Trading Service Objects in Grid Markets, Multikonferenz Wirtschaftsinformatik, MKWI 2008, München, 26.2.2008 - 28.2.2008, Proceedings, GITO-Verlag 2008 Berlin, 2008. Y. Engel, M. P. Wellman and K. M. Lochner, Bid expressiveness and clearing algorithms in multiattribute double auctions, Proceedings of the 7th ACM conference on Electronic commerce, ACM Press New York, NY, USA, 2006, pp. 110-119. C. van Dinther, Adaptive Bidding under Uncertainty - An Agent-based Approach in Market Engineering, Whitestein Series in Software Agent Technologies and Autonomic Computing, Birkhäuser, Basel, Bosten, Berlin, 2007. J. Feigenbaum, V. Ramachandran and M. Schapira, Incentive-compatible interdomain routing, EC '06: Proceedings of the 7th ACM conference on Electronic commerce, 2006, pp. 130-139. M. Feldman, J. Chuang, I. Stoica and S. Shenker, Hidden-action in multi-hop routing, EC '05: Proceedings of the 6th ACM conference on Electronic commerce (2005), pp. 117-126. J. R. Green and J.-J. Laffont, Incentives in Public Decision-Making, North-Holland Publishing Company, Boston, 1979. T. Groves, Incentives in Teams, Econometrica, 41 (1973), pp. 617-631. J. Hagel III, Spider versus Spider, The McKinsey Quarterly, (1996), pp. 71-79. J. Hershberger and S. Suri, Vickrey prices and shortest paths: what is an edge worth?, Foundations of Computer Science (2001), pp. 252-259. S. Kimbrough and F. Murphy, Learning to Collude Tacitly on Production Levels by Oligopolistic Agents, Computational Economics, Online First, Springer Netherlands, July 2008 P. Maille and B. Tuffin, Why VCG auctions can hardly be applied to the pricing of inter-domain and ad hoc networks, Next Generation Internet Networks, 3rd EuroNGI Conference on (2007), pp. 36-39. N. Nisan and A. Ronen, Algorithmic Mechanism Design, Games and Economic Behavior (2001). N. a. R. Nisan, A., Computationally Feasible VCG Mechanisms, Journal of Artificial Intelligence Research, 29 (2007), pp. 19--47. F. Steiner, Formation And Early Growth Of Business Webs, Springer, Berlin, 2005. D. Tapscott, A. Lowy and D. Ticoll, Digital Capital: Harnessing the Power of Business Webs, Harvard Business School Press, Boston, 2000. W. Vickrey, Counterspeculation, Auctions, and Competitive Sealed Tenders, The Journal of Finance, 16 (1961), pp. 8-37. A. Zerdick, A. Picot, K. Schrape, A. Artopé, K. Goldhammer, U. T. Lange, E. Vierkant, E. López-Escobar and R. Silvertone, E-economics. Strategies for the Digital Marketplace, Springer, Berlin, 2000. 608 QUALITY OF SERVICE DELIVERY: ECONOMIC EFFECTS OF MULTI-HOMING AND CONTENT DELIVERY NETWORKS Thorsten Hau1 , Jochen Wulf, Rüdiger Zarnekow2, Walter Brenner1 1 2 Abstract The structure of the Internet serves as a big "commoditizer" of all traffic. Therefore all data, be it time critical or not is transported at the same speed. However, recent trends in the internet are changing this structure. The practices of multi-homing and using content delivery networks reduce the commodity nature of data being transported and put terminating Internet service providers in a position to price discriminate against specific providers or types of traffic. We firstly formalize multi-homing and content delivery networks, we then derive end user prices for paid content and lastly show consequences of the modeled situation. We thus show how the two technologies to bypass crowded peerings change the Internet business model. Traffic which is sensitive to transport quality, such as business critical or delay sensitive traffic, will be paying higher fees to terminating ISPs. 1. INTRODUCTION It is a trivial thought that content (a service, music or text) needs to be delivered to its consumer. However, apparently this problem is by and large being ignored in the web service hype. Implicitly in all service visions it is assumed that the Internet is there and available in appropriate quality. There is for example no work that the authors are aware of, which connects web service availability with the use of the underlying network infrastructure. The available literature on web service standards does consider quality of service of web services but only as a question of setting a protocol standard to exchange quality information between two nodes in a network [7, 23]. A first tentative investigation into the matter of availability of web services is provided by [16] and [17]. Even though [16] do not attribute the differences in download speed to connection quality, such an interpretation does not seem far-fetched, especially when considering the geographical disparities in the measured data. The authors of this work believe that one key factor for the slow uptake of services (SaaS for example) by businesses is a result of the performance and reliability problems [15]; and these are in large part due to today’s Internet. This work focuses on one specific aspect of quality of service of 1 2 Institut für Wirtschaftsinformatik, Universität St. Gallen Institut für Technologie und Management, Technische Universität Berlin 609 the Internet and analyses the economic impact of two quality assurance technologies on today’s pricing regime of the Internet. Internet pricing is a vast field of research that has its roots in telecommunications. This paper departs somewhat from the “classical” literature on communications pricing by considering a special pricing problem present in today’s Internet that has not been covered by the extant literature. We focus on content oriented pricing of network services. In such a scenario Internet service providers (ISPs) with access to end users (EUs) can discriminate against content providers and charge higher prices for termination. This scenario departs from the idealized bill and keep regime that is often used as a basis for analysis of network pricing decisions. However, our scenario is quite realistic. It is commonplace that content providers (CPs) directly buy transit from terminating ISPs, thus effectively paying them for preferential access to end users. This is a viable strategy because by bypassing crowded peerings used by the CP’s original ISP, the CP gets higher quality access to EUs. This is due to the fact that peering points are a major bottleneck on the Internet. While there are usually few capacity problems present inside a single provider’s network, peerings are often at their capacity limit [19], [4]. For the purpose of this paper we call this practice multi-homing (MH). Content delivery networks (CDNs) are also a popular way to enhance the flow of information on the web. A CDN uses local caches to keep distributed images of content close to EUs thus bypassing peerings. The CDN effectively buys transit from the ISP that terminates the traffic. The paper is structured as follows: First we explain the relevant entities of the current Internet that we need for a formal model. Then we present a formalized treatment of four scenarios that show how CDN and MH affect ISPs incentives to price traffic. Lastly we discuss consequences of our model and sketch out an agenda for further research. 2. STATUS QUO: THE MARKET FOR INTERNET CONNECTIVITY 2.1. Overview Figures 1 and 2 show the structure of the Internet as commonly used to model the Internet [18], [12] and [21]. In figure 2 at the bottom, customers and content providers receive and send traffic, respectively. ISPs interconnect to exchange traffic to and from their customers (EUs or CPs). In figure 2 traffic could for example originate at the content provider and be passed on to its ISP 3. From there it is routed to ISP 1 to be terminated at end user (EU) one. The ISPs are fully meshed, each one interconnecting with all the others. It is a common approximation [12] that CPs (web sites) only send traffic and EUs only receive traffic. 2.2. Internet Service Providers ISPs provide connectivity to Internet users who are either end users or content providers. The ISPs pay the market price pw to the ISPs for termination of traffic. Typically ISPs have no lack of bandwidth on their backbones and can provide quality assurance to traffic either through excess capacity or network management techniques commonly employed only within a single provider’s network [22]. Bottlenecks (Not meant in the sense of bottleneck facility as in [1, 2] may be present in the peering points and in the access network. We ignore possible problems due to constrained access bandwidth and concentrate on the peerings. All of the following ignores dynamic considerations of integration and foreclosure through the ISP. 610 2.3. Points of Interconnection In figure 2 the circle with arrows in upper middle represents the point of interconnection where the three ISPs interconnect their networks. This is also called a “peering point”. There are two dominant modes of interconnection: Peering and transit. Peering is a settlement free agreement to exchange traffic while transit involves payment for exchanged data typically on a bit-rate per time scale. Typically peering agreements are used between ISPs of similar size while transit is paid from small ISPs to larger ISPs. Peering points are among the major bottlenecks of the Internet because it always takes both parties to agree to extend the capacity of a peering point. Since the telecommunications firms who own the Internet infrastructure tend to be not overly cooperative these peering points represent excellent opportunities for power play or generally uncooperative behavior. Peerings are frequently overloaded at peak times because one of the two parties involved has no interest in paying for extending its capacity [1] [5], [3], [8]. Ways for CPs to circumvent frequently overloaded (and therefore slow and packet dropping) peerings are multi-homing and the use of CDN services. Transit in contrast to peering involves a payment from one ISP to the other for the delivery of traffic. With such an agreement a guaranteed bandwidth is bought. Due to strategic considerations the biggest networks only peer among themselves and charge smaller networks for sending traffic to them. Since small ISPs have to pay for sending traffic to larger networks which is necessary to reach the whole Internet they optimize their out-payments for transit fees by buying the least amount of bandwidth their users will tolerate. 2.4. Content Providers Content Providers are for example websites that buy connectivity to the Internet from an ISP (possibly mediated through a hosting provider).Content providers are able to multi-home. They can buy connectivity for one fraction of their traffic from IPS1 and the rest from ISP 2. Furthermore they can host their service with any provider anywhere in the world giving them a very large set of ISPs to choose from. This creates competition amongst ISPs for CPs’ business and therefore CPs face a market price for Internet connectivity based on perfect competition. This price only includes un-prioritized traffic transportation across peering points. Canonical analysis [10-12, 14] usually assumes the following model of Internet payments: EU → ISPt ↔ a ISPo ← CP (t=terminating, o=originating), ignoring where the CP gets funding from and emphasizing the analysis of the inter ISP settlement a. Focusing on payments for content viewing, we model the payments flows according to the following scheme: ISPt ←a ISPo ← pw CP ← p EU . We ignore payments from the EU to the terminating ISP for access to the Internet. Payments from the EU to the CP might be paid through watching advertisements or direct money exchange. The arrow with the a stands for the access charge that is paid from one ISP to the other for sending traffic to the receiving ISP[13]. p is the final price paid by the EU for viewing some content. pw is the price paid from the CP to the ISP for reaching the EU. If the ISP receiving pw cannot terminate the traffic it has to pay an access charge to another ISP able to terminate the traffic. If a CDN is involved in content delivery, the CP has to pay the cost of the CDN, too. Modifying the way CPs get access to the EUs and modifying payments accordingly will be the key part of this paper. The two variations we will consider are: multi-homing and CDN delivery. With MH, the terminating ISP is directly connected with the CP, while with CDNs a neutral third party mediates between CP and ISPt. Under MH payment flows are ISPt ← pw CP ← p EU and the originating ISP is cut out of the equation. With CDN delivery, the payments are: ISPt ← pw CDN ← pw + ccdn CP ← p EU We model CDNs as fully competitive entities only passing on costs. 611 2.5. End Users Unlike CPs, EUs cannot divide their traffic amongst several ISPs and are immobile in the sense that they cannot chose their provider globally but need to chose among a small number of local ISPs. Therefore we consider a static scenario in which EUs are bound to their ISP, providing the ISP with a monopoly over terminating traffic to those EUs. Neither the competition among local ISPs for market share nor the dynamic considerations of consumers with switching costs [9] are considered here. 2.6. Multi-homing Multi-homing is the common practice that CPs interconnect with several different ISPs. There are several instances of big content providers that are present in public peering points in order to gain direct access to ISPs with many EUs. Google for example is not just with one ISP in the USA but has its own transatlantic fiber capacity and is present in DE-CIX [6]. Besides the reliability aspect this practice allows the CPs to get direct access to an ISP’s network and thus be more in control over bandwidth agreements with that ISP. 2.7. Figure 1: Simplified model of the Internet. Figure 2: A tiered view of the Internet. Figure 3: The Internet with MH. Figure 4: The Internet with CDNs. Content Delivery Networks CDNs consist of a network of servers that are distributed around the Internet within many ISPs’ infrastructures. A CDN takes content from a CP and caches it on those distributed servers, which has the effect that content is brought closer to the EU without passing through peerings. The CDN then delivers the content it is caching from the mirror site to the EU. By using the services of a CDN a CP does not need to multi-home with every possible network. We assume that CDNs do not make any profit and charge efficient prices. 612 3. MODELING THE EFFECTS OF MULTI-HOMING AND CDN A key feature of the Internet is that all traffic is being treated (more or less) equally. Methods for discriminating against specific types of traffic are expensive and are not used aggressively. While this makes the Internet very egalitarian, it is a problem for content which needs assured performance parameters. Video streaming for example can only tolerate a certain package loss and Internet gaming requires assured low delays. Since the Internet cannot assure constant quality levels, methods to bypass the main bottlenecks are used by commercial CPs: CDN and MH. Both technologies “de-commoditize” Internet traffic because the source of traffic becomes a business partner. In the following we will analyze the four combinations of market form faced by the CP and strategic behavior of the ISPs. The columns of table 1 represent the possible actions the terminating ISP can take: With MH it can perfectly discriminate against the known source of traffic and extract profits; with CDNs it can discriminate against all traffic that requires higher quality and has demonstrated this through the use of a CDN (self selection). The rows represent the market situation the CP is facing. Under competition many CPs are serving a market; with a monopoly, only one CP serves a specific market with one product. Cross product/market elasticities are assumed to be zero. The cells of the table show what the ISP will do to extract the maximum revenue from the CP. Content Competition Content Monopoly Perfect / 1st degree price discrimination (MH) 1: ISP sets access price until monopoly price for content is reached 3: ISP extracts all revenue from CP through two part tariff Class of Service / 2nd degree price discrimination (CDN) 2: ISP sets monopoly price for termination, inefficient since ISP sets avg. price 4: ISP sets monopoly access price but cannot capture all rents from CPs (dbl. marginalization) Table 1: The four possible situations with an access monopolist 3.1. Scenario 0: No Discrimination by ISP Possible The situation when the ISP has no way of differentiating different traffic, and therefore cannot set different prices for different traffic sources and different quality classes, is not shown in table 1. It corresponds to the “normal” way traffic is exchanged on the Internet. The price for terminating traffic pw is equal to the ISP’s cost c. The charge pw which is levied by the terminating ISP feeds through to the originating CP as a rise in connection costs to be included in the charge to the EU. The CP therefore can consider the market price as given. This treatment ignores the considerations put forward by [12]. 3.2. Scenario 1: Perfect Discrimination by ISP and Content Competition Here the terminating ISP can perfectly discriminate against CPs while the CPs face a competitive market. Assuming perfect competition only efficient firms are active in each differentiated market and the ISP can perfectly discriminate against each market segment (i.e. treat a whole segment like one single CP). By setting its price pw,i charged to the CPs of segment i equal to the monopoly price the ISP can extract monopoly profits while leaving no profits to the CPs. Each CP sets the competitive price pi in segment i equal to its marginal costs. For simplicity we assume that 613 marginal costs of production of the CPs are zero. Therefore pi = pw,i. The ISP with marginal costs ci per market segment determines pw,i by solving the following problem: (1) max pw ,i ⎡⎣( pw,i − ci ) Di ( pw,i ) ⎤⎦ . For example suppose that the demand function in one of the market segments i is given by Di ( pw,i ) = 1 − pw,i . Then the target function of the ISP is: max pw ,i ⎡⎣( pw,i − ci )(1 − pw,i ) ⎤⎦ . (2) Solving this gives for price and output quantity yields 1 + ci (3) pw , i = , 2 1 − ci Di ( pw,i ) = qi = and (4) 2 2 ⎛ 1 − ci ⎞ Π = pw,i qi − ci qi = ⎜ (5) ⎟ . ⎝ 2 ⎠ Interpretation: The ISP converts each competitive market-segment i into perfect monopoly and extracts the maximum profit. The output quantity is reduced and the CPs make no profits. Note that this result would not hold with users being able to switch between ISPs. Switching users without switching costs would restore competitiveness of the market. Due to long term contracts, however, the ISP has some market power. 3.3. Scenario 2: Market Segmentation by ISP and Content Competition This situation is similar to scenario one with a reduction in the ability to discriminate against CPs. With a CDN as mediator only CDN (i.e. quality sensitive) and non-CDN traffic can be distinguished. CDNs buy transit from the ISP who can thus differentiate between quality sensitive traffic from CDNs and ordinary traffic through normal peerings with other ISPs. The price taken by the competitive CPs depends on the price pw set by the ISP which acts like a monopolist. The ISP faces an aggregate demand for quality traffic. Assuming that the CDN segment is competitive, the ISP can set monopoly prices for CDN traffic which raises marginal costs of the CDN providers and thus costs for CPs. In the following treatment we assume the CDN costs to be fully absorbed into the marginal cost of the CP. For simplicity both are assumed to be constant and zero. Again the CPs are competitive in each market segment. In each of n market segment the CPs have the target function max pi [( pi − pw ) Di ( pi )] (6) where pi is the price charged to the EUs and pw is the uniform price for CDN traffic paid to the ISP. Different from scenario one, now the ISP cannot set different p w,i per market segment but just one averaged price for CDN traffic. Under perfect competition price equals marginal costs: pi = pw. (7) Interpretation: It is obvious form equation (6) that the ISP influences the pricing decisions of the CP’s through its price pw. However, since the ISP can only set a a uniform price for all CDN traffic, it can only optimize across an aggregated n demand function D = ∑ Di . Therefore prices in the EU market need not be those an integrated monopolist would have chosen. In this situation inefficiencies are present since the ISP charges an average price. Some segments profit from this by paying a price below the monopoly level, thus improving efficiency, while other segments pay more than the optimal monopoly price which might result in some markets not being served. 614 3.4. Scenario 3: Perfect Discrimination by ISP and Content Monopoly The ISP can target the CPs individually and set individually profit maximizing prices. This situation seems prone to double marginalization with two cascaded monopolies. However, the ISP can anticipate this sort of inefficiency and avoid it by setting a usage price pw and then extracting all profits of the monopoly CPs through a fixed fee A. This way of pricing is known as franchising [20]. The total price set by the ISP is T (q ) = A + pwq. (8) Assuming that the ISP sets pw = c efficiently at the marginal cost of providing the service (the variable q is the output quantity of the ISP), the CP chooses the optimal end user price p: max p [ ( p − c) D( p ) − A] . (9) This results in the monopoly EU price 1+ c p= . (10) 2 By setting the fixed fee A equal to the profit of the CP the ISP can now extract all profit without distorting the target function of the CP. The same result could have been achieved with a “tax” τ Π levied by the ISP. Interpretation: The profit based charge A does not alter the price paid by consumers but shifts profits from the CP to the ISP. This can be a problem since monopoly profits could be the reward for innovation and if those profits are taken away, innovation might not be profitable any more. This situation is good for static efficiency since the output decision of the CP is not changed by the ISP’s behavior. However, when considering the development over time, no matter how much of the CPs’ revenue is extracted by the ISP, the EU price for the content stays the same and thus there is no competitive pressure from EUs on the ISP. 3.5. Scenario 4: Market Segmentation by ISP and Content Monopoly Each of n CPs serves a monopoly market as in case three but the ISP cannot differentiate between those markets and can only optimize its revenue based on gross demand (as in case two) by all fully differentiated CPs. This corresponds to a situation know as double marginalization. Now the CPs (with constant marginal cost set to zero) set their price for content as a standard monopolist. Their target functions are: max pi [( pi − pw ) Di ( pi )] (11) where pi is the price charged to the EU and pw is the price paid to the ISP. Since the ISP can only 2nd degree price discriminate we will analyze the ISP’s problem based on average figures for price and demand from all CPs demanding quality (using CDN): 1 n p = ∑ pi , and (12) n i =1 1 n D = ∑ Di ( pi ). (13) n 1=1 Assuming for simplicity that aggregate demand is linear: D ( p ) = 1 − p , the solution to this problem is similar to the treatment in section 3.2 with the ci replaced here by pw and yields optimal prices of 1 + pw 1 − pw and an optimal output q = . Using this quantity, the optimization problem of the p= 2 2 ISP with marginal output cost c for CDN traffic is: ⎡ ⎛ 1 − pw ⎞ ⎤ (14) max pw ⎢( pw − c) ⎜ ⎟⎥ ⎝ 2 ⎠⎦ ⎣ 615 1+ c 3+ c and p = for the final consumer price. Comparing the sum of the 2 4 profits of ISP Πisp and CP Πcp we see that it is smaller than the profit Πint of an integrated monopoly provider: (1 − c) 2 (1 − c) 2 (1 − c) 2 Π isp + Π cp < Π int ⇔ + < . (15) 8 16 4 1+ c 3+ c The end user price p = in monopoly is lower than the p = above (as long as c < 1 which 2 4 makes sense because with D = 1 − p, 1 > p ≥ pw ≥ c must be true if no losses are made and there is a positive demand). Interpretation: On average across EUs’ demand for the perfectly differentiated markets this situation is suboptimal since prices could be lower and revenues could be higher. In addition to this double marginalization problem, there exists a problem due to the averaging of price and demand of the different CPs. Since the price set by the ISP is targeted at the average CP, it will typically be either too high or too low. Thus there is a second source of inefficiency. ISPs could also opt for a different pricing model and charge (as in scenario 3) a fixed fee plus an efficiently set usage fee pw. Thus inefficiencies due to the ISPs behavior would be removed. However, since the ISP can only set an average A it is impossible to extract all rents. A would even make some market segments with low profits unattractive to serve since profits are too low to cover the fixed fee. Thus one has to chose between double marginalization reducing output in some segments and franchising resulting in some markets not being served at all. resulting in pw = 3.6. Synopsis of the Four Scenarios In all four scenarios welfare is below optimal and prices are above the competitive level. It is even possible as shown in case four that welfare is lower than in monopoly. The first general result therefore is that CDNs and multi-homing reduce welfare due to reducing the efficiency of price setting for data transport. This result is true if one ignores the welfare gains of being able to deliver higher QoS by the use of those technologies. The second result which is common to all cases is that ISPs’ price setting reduces CPs’ profits. While this in itself does not need have a negative effect on welfare in a static environment it can be detrimental when considering monopoly revenues of CPs as the reward for innovation. If ISPs extract these profits, innovation might become unprofitable for CPs. Furthermore ISPs are able to exploit their access monopoly and create monopolies from otherwise competitive markets. The only precondition for this is a quality requirement of the service that does not allow the use of ordinary peerings. 4. CONCLUSIONS AND FURTHER RESEARCH This work provides a new view on access pricing and quality of service on the Internet. Assuming that CDN and multi-homing are used to improve the quality of service provided to the EU we have shown how a “de-commoditization” of traffic enables the terminating ISP to charge more for termination. Our analysis shows that there exist incentives for ISPs to further degrade peering quality to attract more traffic to the more profitable segments. On the positive side, understanding multi-homing and CDNs as quality mechanisms opens up a whole new view on the quality of service debate. Standard approaches of QoS always require global carrier collaboration. All carriers have to agree on service classes and forward each other’s traffic with the appropriate service level. With multi-homing and CDN, an edge based solution to QoS is available that can deliver QoS for many applications on the Internet. 616 The presented work leaves open and poses many further research question that need to be addressed. On the technical side, it would be interesting to know whether CDN and MH can fully replace inter carrier agreements on quality parameters of traffic. Which quality mechanisms are necessary inside one carrier’s network to complement the peering bypass capability of CDN and MH with the ability to deliver to the EUs workstation? On the service oriented side, more work needs to be done to better understand the (non-) adoption of services and its connection with (un-) reliability and issues of the Internet. In an experimental set-up with one service hosted by CDN or MH and one service hosted within another network one could empirically validate the influence of peerings on user satisfaction. There are many questions that we have not addressed. However, the text presents a new perspective on the QoS debate and on economic aspects of CDN and MH. Services hosted on the Internet are a case in point for the quality sensitivity of consumers and the lack of quality in the internet. We believe this paper will add an important building block to our understanding of QoS on the Internet and spark ideas to QoS enable the web. REFERENCES [1] ARMSTRONG, M., "Network Interconnection in Telecommunications," The Economic Journal, vol. 108, pp. 545-564, 1998. [2] 2006. ARMSTRONG, M., "Competition in two-sided markets.," RAND Journal of Economics, vol. 37, pp. 668-691, [3] BADASYAN, N.C., SUBHADIP, "A simple game-theoretic analysis of peering and transit contracting among Internet service providers," Telecommunications Policy, vol. 32, pp. 4-18, 2008. [4] CAVE, M.M., S. K. & VOGELSANG, I., Handbook of telecommunications economics: Elsevier Boston, Mass, 2002. [5] CREMER, J.R., PATRICK & TIROLE, JEAN, "Connectivity in the Commercial Internet," The Journal of Industrial Economics, vol. 48, pp. 433-472, 2000. [6] DE-CIX, "http://www.de-cix.net/content/clients.html," 2008. [7] ERRADI, A. and MAHESHWARI, P., "A broker-based approach for improving Web services reliability," presented at Web Services, 2005. ICWS 2005. Proceedings. 2005 IEEE International Conference on, 2005. [8] FOROS, O.K., HANS JARLE & SAND, JAN YNGVE, "Do internet incumbents choose low interconnection quality?," Information Economics and Policy, vol. 17, pp. 149-164, 2005. [9] KLEMPERER, P., "Competition when Consumers have Switching Costs: An Overview with Applications to Industrial Organization, Macroeconomics, and International Trade," Review of Economic Studies, vol. 62, pp. 515539, 1995. [10] LAFFONT, J.-J., REY, P., and TIROLE, J., "Network Competition: II. Price Discrimination," The RAND Journal of Economics, vol. 29, pp. 38-56, 1998. [11] LAFFONT, J.-J., REY, P., and TIROLE, J., "Network Competition: I. Overview and Nondiscriminatory Pricing," The RAND Journal of Economics, vol. 29, pp. 1-37, 1998. [12] LAFFONT, J.-J., MARCUS, S., REY, P., and TIROLE, J., "Internet Interconnection and the Off-Net-Cost Pricing Principle," The RAND Journal of Economics, vol. 34, pp. 370-390, 2003. [13] LAFFONT, J.J.M., S.; REY, P. & TIROLE, J., "Internet Peering," The American Economic Review, vol. 91, pp. 287-291, 2001. [14] LAFFONT, J.J.T., J., Competition in Telecommunications: MIT Press, 2000. 617 [15] MA, Q., PEARSON, J., and TADISINA, S., "An exploratory study into factors of service quality for application service providers," Information & Management, vol. 42, pp. 1067-1080, 2005. [16] ONIBOKUN, A. and PALANKAR, M., "Amazon S3: Black-Box Performance Evaluation."´ [17] PALANKAR, M.R., IAMNITCHI, A., RIPEANU, M., and GARFINKEL, S., "Amazon S3 for science grids: a viable solution?," in Proceedings of the 2008 international workshop on Data-aware distributed computing. Boston, MA, USA: ACM, 2008, pp. 55-64. [18] SHAKKOTTAI, S.S., R., "Economics of network pricing with multiple ISPs," IEEE/ACM Trans. Netw., vol. 14, pp. 1233-1245, 2006. [19] SHRIMALI, G.K., SUNIL, "Bill-and-Keep peering," Telecommunications Policy, vol. 32, pp. 19-32, 2008. [20] TIROLE, J., The Theory of Industrial Organization: MIT Press, 1988. [21] ULUDAG, S.L., K.S.; NAHRSTEDT, K. & BREWSTER, G., "Analysis of Topology Aggregation techniques for QoS routing," ACM Computing Surveys, vol. 39, 2007. [22] WANG, Z., Internet QoS: Architectures and Mechanisms for Quality of Service: Morgan Kaufmann, 2001. [23] ZENG, L.B., B.; NGU, A.H.H.; DUMAS, M.; KALAGNANAM, J. & CHANG, H., "QoS-aware middleware for Web services composition," IEEE Transactions on Software Engineering, vol. 30, pp. 311-327, 2004. 618 MOBILE SYSTEME Das breite Spektrum an Technologien und Anwendungen zur Unterstützung mobiler Lösungen für traditionelle und innovative Geschäftsprozesse wächst stetig und bietet ein off enes Feld für die Forschung. Zugleich sorgen die Verfügbarkeit von Standards, von Infrastrukturen für drahtlose Dienste und nicht zuletzt die hohe Verbreitung von mobilen Endgeräten weltweit für ein enormes Marktpotenzial. Ziel dieses Tracks ist die Auseinandersetzung mit allen Aspekten „Mobiler Systeme“, von den Basistechnologien und Infrastrukturen bis hin zu Geschäftsmodellen, Mehrwertdiensten, Wirtschaftlichkeitsbetrachtungen und methodischen Ansätzen einschließlich der Begleitforschung zu Akzeptanz, Nutzen und Risiken. Leitungsgremium: J. Felix Hampe, Universität Koblenz-Landau (Federführender) Gabriele Kotsis, Johannes Kepler Universität Linz Franz Lehner, Universität Passau Klaus Turowski, Universität Augsburg Programmkomitee: Michael Amberg, Universität Erlangen-Nürnberg Markus Bick, ESCP-EAP Europäische Wirtschaftshochschule Berlin Harry Bouwman, Delft University of Technology Niederlande Michael Breitner, Universität Hannover Rony G. Flatscher, Wirtschaftsuniversität Wien Bardo Fraunholz, Deakin University Melbourne George Giaglis, Athens University of Economics and Business Timber Haaker, Telematica Institut Niederlande Hagen Hoepfner, Association for Computing Machinery Thomas Kirste, Universität Rostock Birgitta König-Ries, Universität Jena Jan Marco Leimeister, Technische Universität München Gerald Madlmayr, FH Hagenberg Key Pousttchi, Universität Augsburg Kai Rannenberg, Johann Wolfgang Goethe-Universität Frankfurt am Main Thomas Ritz, FH Aachen Detlef Schoder, Universität zu Köln Gerhard Schwabe, Universität Zürich Stefan Stein, Uni Koblenz Can Türker, Eidgenössische Technische Hochschule Zürich EIN MOBILES SPIEL WIRD ZUM EVENTMARKETINGINSTRUMENT Christoph Göth, Raphael Joss, Gerhard Schwabe1 Kurzfassung Der mExplorer ist ein an der Universität Zürich entwickeltes mobiles Lernspiel, welches Erstsemestrigen den Campus einer Universität auf spielerische Art und Weise näher bringen soll. In diesem Beitrag wird gezeigt, wie das Spiel für das Eventmarketing eingesetzt werden kann und welche Wirkungen es dabei hat. Bei einem Feldtest wird gezeigt, dass ähnliche Probleme wie beim mobilen Lernen auftreten, aber auch ähnliche emotionale Wirkungen erzielt werden. Aus den unübersehbaren Ähnlichkeiten zwischen mobilem Lernen und Eventmarketing schliessen wir auf eine Konvergenz unterschiedlicher Lebensbereiche durch mobile Anwendungen. 1. Einleitung Klassische Marketingmassnahmen wie TV-Werbung, Plakate und Inserate finden in der heutigen Zeit immer weniger Resonanz. Die Konsumenten ignorieren solche Promotionen oder fühlen sich durch diese sogar gestört. Ist es dem Hersteller oder Dienstleister jedoch möglich ein Produkt oder eine Leistung mit einem Erlebnis zu verbinden, so kann sich dieses von der Masse abheben. Dies machen sich bereits seit einigen Jahren verschiedene Wirtschaftszweige zu Nutze. So kostet beispielsweise eine Tasse Kaffee am Markusplatz in Venedig 15 Franken, wohingegen er in einer normalen Universitätscafeteria 2 Franken kostet [12]. Dieser Preisunterschied lässt sich nur durch den deutlich höheren Erlebniswert am Markusplatz erklären, den der Kunde mitbezahlt. Diesen Effekt macht man sich auch im Eventmarketing zu Nutze. Ein Produkt soll mit einem Erlebnis verbunden werden, um so die Sichtbarkeit und Resonanz zu erhöhen. Eine Spielart des Eventmarketings ist das mobile Eventmarketing, wo explizit die Vorteile der Kontextualisierung genutzt werden. Ein System für Eventmarketing, der mExplorer, soll in diesem Artikel vorgestellt werden. Mit dem mExplorer soll es möglich werden ein Produkt oder eine Institution in Form eines Erlebnisses zu vermarkten. Bis anhin wurde der mExplorer dazu eingesetzt Erstsemestrigen den Campus einer Universität auf spielerische Art und Weise näher zu bringen. Die Studenten spielen dabei mit einem PDA, welcher ihnen verschiedenste Aufgaben zuteilt. Die Bearbeitung der Aufgaben führt die Studenten zu unterschiedlichen Orten und Personen auf dem Campus, dazu gehören die Mensa, das Dekanat, der Computerarbeitsraum, etc. [8]. Die zugeteilten Aufgaben können von den Studenten nur vor Ort gelöst werden. Damit sie einfacher zu den 1 Universität Zürich, Institut für Informatik 621 Aufgaben finden, verfügt der mExplorer über eine Indoor Navigation, so sehen die Spieler stets ihre aktuelle Position auf einer digitalen Karte auf dem PDA. Für das Eventmarketing ist der mExplorer schon als technische Innovation an sich ein attraktives Objekt. Wir fragten uns, ob und wie der mExplorer mittels eines geeigneten Szenarios das Promoting einer Institution oder eines Produktes ermöglichen könnte. Dabei stellten sich folgende Forschungsfragen: 1. Welche Anforderungen stellt das Eventmarketing an die mobile Unterstützung und welche Änderungen am System sind ggf. nötig? 2. Welche Wirkungen hat der Einsatz und erfüllen die Wirkungen typische Erwartungen an das Eventmarketing? 3. Was sind wesentliche Gemeinsamkeiten und Unterschiede zwischen dem Einsatz für mobiles Lernen und für das Eventmarketing? In nächsten Teil werden daher zuerst die bestehenden Marketingansätze aus dem Eventmarketing aufgearbeitet. Ein dritter Teil erklärt das System mExplorer im Detail und beschreibt das Szenario für das 175-jährige Jubiläum der Universität Zürich (Forschungsfrage 1). Bei der Durchführung des Anlasses wurden die Besucher aufgefordert einen Fragebogen auszufüllen. Im vierten Teil werden die Ergebnisse dieser Befragung präsentiert (Forschungsfrage 2). Der fünfte Teil zieht ein Fazit (Forschungsfrage 3). 2. Eventmarketing Ein wichtiges Element des Eventmarketings stellt die Erlebnisorientierung dar, ein weiteres ist die Interaktivität [2]. Mit beiden Elementen soll der Teilnehmer in das Event unter aktiver Beteiligung eintauchen. Dies grenzt das Eventmarketing auch vom verwandten Erlebnismarketing ab, bei dem der Konsument oft zum passiven Zuschauer degradiert wird. Erst durch die aktive Teilnahme, also der Interaktion mit dem Produkt, wird dieses emotionalisiert. Durch das Erlebnis und die Interaktion verankert der Konsument die Marketingbotschaft langfristig in seinem Gedächtnis, wobei das Erlebnis möglichst positiv sein sollte. Während also das Erlebnismarketing meist nur für Unterhaltung sorgt, bietet das Eventmarketing dem Konsumenten Realitätsflucht [12]. Im Eventmarketing soll ein Produkt, eine Dienstleistung oder ein Unternehmen innerhalb eines Events erlebnis- und dialogorientiert präsentiert werden. Dafür braucht es eine zielgerichtete, systematische Planung, Organisation, Inszenierung und Kontrolle. Ziel ist die Vermittlung von unternehmensgesteuerten Botschaften unterstützt durch emotionale und physische Stimulans während des Events [2]. Neben den Merkmalen Erlebnisorientierung und Interaktivität ist die Inszenierung ein drittes Merkmal des Eventmarketings [1]. Die Erlebnisorientierung fordert, dass ein Event möglichst alle Sinne der Teilnehmer beeinflusst, sie sollen sowohl visuell als auch akustisch, olfaktorisch (Gerüche), haptisch (Materialien) und gustatorisch (Geschmack) angesprochen werden. Die Interaktivität verlangt, dass der Kunde aktiv in das Event miteinbezogen wird, dies erhöht die Kommunikationswirkung. 622 Inszenierung bedeutet dem Event eine Geschichte zu verleihen, die einzelnen Elemente des Anlasses müssen zu einer natürlichen Abfolge kombiniert werden. Dabei geht es nicht unbedingt um eine besondere Dramaturgie. Das Eventmarketing verlangt nach einer systematischen Planung, jedoch ist die Organisation eines Events dabei praktisch nicht standardisierbar. 2.1. Ziele des Eventmarketings Die Ziele des Eventmarketings lassen sich in Kontaktziele und Kommunikationsziele unterteilen [4]. Zwar gibt es auch Events, die ökonomische Ziele verfolgen, diese Ziele stehen jedoch allgemein nicht im Vordergrund und sind zudem meist nur sehr schwer zurechenbar. Wichtigstes Kontaktziel ist den Konsumenten überhaupt für eine Teilnahme am Event motivieren zu können. Dies erfordert, dass die Zielgruppen für den Event im Voraus definiert sind und dass die restlichen Marketinginstrumente aktiviert werden, um das Ziel zu erreichen. Die Kontaktziele werden auch als Pre-Eventziele bezeichnet [2]. Bei den Kommunikationszielen handelt es sich um die eigentlichen strategischen Ziele eines Events. Dieses soll die Bekanntheit einer Marke vergrössern oder das Image des Unternehmens verbessern und schliesslich auch zu Kaufinteresse und Kaufbereitschaft führen. Ziel ist demnach eine Verhaltensänderung beim Konsumenten, welche durch ein positives Erlebnis erreicht werden kann [4]. Wichtig für eine erfolgreiche Zielformulierung ist eine detaillierte Zielgruppenbeschreibung. Bei den Zielgruppen handelt es sich entweder um externe Gruppen wie Kunden, Lieferanten oder auch Medien oder um interne Gruppen wie Mitarbeiter oder Eigentümer des Unternehmens. 2.2. Mobiles und ortsabhängiges Marketing Der Einbezug des Ortes führt zu kontextuellem Marketing [11], dabei soll dem Benutzer die richtige Information zur richtigen Zeit am richtigen Ort zur Verfügung stehen, unter Berücksichtigung des aktuellen Kontextes des Benutzers. Kontext meint den Ort, die Gemütslage, das aktuelle Interesse oder auch die aktuelle Aktivität des Benutzers. Ein einfacher Service wäre zum Beispiel die Angabe über nahe gelegene asiatische Restaurants. Der Benutzer fragt die Information entweder selbst ab (Pull-Prinzip) oder erhält diese basierend auf seinem Kontext automatisch (Push-Prinzip) [10]. Oft können solche Services auch durch voreingestellte Benutzerprofile beeinflusst werden. Dabei existieren auch Systeme, die das Benutzerprofil anhand der Aktivitäten des Benutzers anpassen. Werbung mit mobilen Geräten ist besonders attraktiv, weil diese über eine sehr hohe Erreichbarkeit verfügen. Die Benutzer können zu jeder Zeit und an jedem Ort angesprochen werden [3]. Zu berücksichtigen sind jedoch sowohl die Privatsphäre des Benutzers als auch der dazugehörige Datenschutz. Mobiles Eventmarketing fügt die Elemente des Eventmarketings und die Ansätze aus dem mobilen und kontextuellen Marketing zusammen. Es soll nicht nur orts- oder kontextbezogene Werbung ermöglicht werden, sondern der Benutzer soll, wie im Eventmarketing, Produkte oder Marken mit Emotionen verbinden. Er soll unterhalten werden und an der Interaktion Spass haben. Die beschriebenen Ziele aus dem Eventmarketing sollen also mit Hilfe eines mobilen Gerätes erreicht 623 werden, welches den Kontext, der in diesem Falle hauptsächlich aus dem Ort besteht, des Benutzers miteinbezieht. Eventmarketing und mobiles Marketing fliessen ineinander zusammen. 3. Der mExplorer als Eventmarketinginstrument Der mExplorer wurde ursprünglich als mobiles Lernspiel entwickelt und sollte Erstsemestrigen ihre neue Umgebung, die Universität, auf spielerische Art und Weise näher bringen [8]. In Zweierteams erhalten die Studenten einen PDA, mit dessen Hilfe sie auf dem Campus navigieren und die Aufgaben bearbeiten können. Das Spiel stellt den Studenten verschieden Fragen und Aufgaben, welche sie an die verschiedensten Orte auf dem Campus führt, die Fragen können nur vor Ort beantwortet werden. So müssen sie zum Beispiel angeben, wie viel ein Mittagessen in der Mensa kostet. Auf einer digitalen Karte sehen die Spieler ihre Position, diejenige der Aufgaben und auch die Position der restlichen Teams. Der PDA verfügt dazu über ein Positionierungssystem mittels WLAN-Positionierung. Für das Beantworten der Fragen erhalten die Teams Punkte. Ein weiteres Element ist eine Jagdfunktion. So wird jedem Team ein Jäger-Team und ein Opfer-Team zugeteilt. Kommt ein Team genügend nahe an sein Opfer-Team heran, kann es dessen Avatar auf der Karte anklicken und fängt dieses so ein. Für das Einfangen erhalten die Teams zusätzliche Punkte, das Team mit den meisten Punkten gewinnt das Spiel. Beim mExplorer handelt es sich um ein klassisches Client-Server-System, das vollständig in Java implementiert wurde. Neben dem Server kommen Windows Mobile PDAs mit einer J2ME Virtual Machine zum Einsatz. Der Server funktioniert als Koordinationspunkt, von ihm aus werden die Aufgaben an die PDAs verteilt und umgekehrt die Lösungen vom PDA an den Server gesendet. Gleichzeitig koordiniert der Server auch das Positionierungssystem und damit auch die Informationen über den Status der Jagdfunktion. Das Positionierungssystem stellt die Grundlage für die ortsabhängigen Aufgaben. Da der mExplorer hauptsächlich für die Anwendung im Innern von Gebäuden gedacht ist, fällt GPS als Positionierungsmöglichkeit weg. Deswegen wird das kommerzielle WLAN-Positionierungssystem von Ekahau eingesetzt. Abbildung 1: GUI des mExplorers Das GUI des Clients (siehe Abbildung 1) symbolisiert das eigentliche Spiel. Über dieses werden die Aufgaben gelöst und andere Teams gejagt. Den grössten Teil des GUIs nimmt die digitale Karte des 624 Gebäudes oder der Umgebung ein. Aktuell sind folgende Funktionen im mExplorer implementiert, die für das Eventmarketing relevant sind: • • • • • • Digitale Karten und Positionierung: Für Stockwerke/Gebäudeabschnitte können einzelne Karten definiert werden, dazu gehört auch eine Zoomfunktion und automatisches Scrollen / Kartenwechseln. Auf der Karte sieht der Spieler stets seine aktuelle Position und die Position der gegnerischen Teams. Points of Interest: Auf den interaktiven Karten werden Sehenswürdigkeiten als blaue Punkte markiert. Über diese POIs stehen dem Benutzer zusätzliche Informationen in Form einer HTML-Seite zur Verfügung. Aufgabenstellungen: Es lassen sich verschiedene Formen von Aufgabenstellungen definieren, sie sind entweder orts-, personen- oder anlassbezogen und können in Form von Multiple Choice, Slider, offenen Fragen oder kreativen Fragen (Zeichnung, Foto, Audio) gestellt werden. Zusätzlich können die Aufgaben miteinander verknüpft werden (Kettenaufgaben), so entsteht eine fixe Aufgabenfolge. Der Benutzer kann stets die aktuelle Rangliste abrufen. Annotationen: Der Benutzer kann zu jeder Zeit eine Position auf der Karte mit einer digitalen Notiz (Text, Audio, Foto) versehen. Diese sind auch für die restlichen Teams einsehbar. Chat: Senden von Textnachrichten an andere Teams oder den Spielleiter. Jagdfunktion: Jedem Team wird beim Spielbeginn ein Jäger- und ein Opfer-Team zugeteilt. Kommt man genügend nahe an sein Opfer-Team heran, kann man dessen Avatar auf der digitalen Karte anklicken und erhält so Punkte und ein neues Opfer-Team. 3.1. Eignung des mExplorers für das Eventmarketing Schon das ursprüngliche lernorientierte Szenario des mExplorers ist als Event ausgelegt, an dem mehrere Spielgruppen gleichzeitig die Universität erkunden. Dabei werden die positiven Eigenschaften des gemeinsamen Spielens, wie Motivation und Spass, für das Lernen genutzt [13]. Daher ist es naheliegend den mExplorer neben dem Lernszenario auch auf die Einsatzmöglichkeit für das Eventmarketing zu überprüfen. Dies soll zuerst anhand der in Abschnitt 2 vorgestellten drei Elemente des Eventmarketings geschehen. Damit wird auch die Forschungsfrage 1 (s.o.) beantwortet. Erlebnis: Der Erlebniswert des mExplorers ist hoch, was bereits in früheren Feldversuchen gezeigt wurde [13]. Durch spannende und kreative Aufgaben können die Spieler selbständig eine neue Umgebung erforschen oder in einer bekannten Umgebung Neues entdecken. Durch den Einbezug der Umgebung sind visuelle, akustische und haptische Erlebnisse möglich. Man kann also von einem multisensualen Erlebnis sprechen. Zusätzlich haben die Spieler die Möglichkeit sich gegenseitig zu fangen, was den Erlebniswert ebenfalls erhöht. Interaktivität: Der mExplorer enthält mehrere interaktivitätsfördernde Elemente. Grundsätzlich spielte der Spieler zusammen mit einem Partner selbständig das Spiel und interagiert somit aktiv mit dem Spiel, dem Partner, mit dem PDA auf dem das Spiel läuft und mit der Umgebung. Eigentlich kann man sich nur durch „Nichtspielen“ der Interaktivität des Spiels entziehen und ein Eintauchen verhindern. Durch die Verwendung von kontextspezifischen Aufgaben oder Kreativitätsaufgaben lässt sich der Effekt der Interaktivität sogar noch weiter steigern [9]. Inszenierung: Mit Hilfe des mExplorers ist es möglich der Umgebung eine „Geschichte“ zu verleihen. Dadurch, dass man die reale Umgebung zusätzlich mit virtuellen Objekten (Foto-, Audio oder Textanreicherung) ergänzen kann, ein Spielgeschehen hineinlegen kann und verschiedene 625 „geschichten“-spezifische Aufgaben stellt, kann man den Spieler mit hineinnehmen in die Dramaturgie. Dies zeigt, dass der mExplorer grundsätzlich ein sehr geeignetes Instrument für das Eventmarketing darstellt. Der praktische Test der Eignung wurde im Rahmen des 175-jährigen Jubiläums der Universität Zürich durchgeführt. Erstaunlich war die Tatsache, wie wenig man an der eigentlichen Technik für das Eventmarketing ändern musste. Die einzige technische Änderung war das Ermöglichen des Einloggens von beliebigen Spielern zu einem beliebigen Zeitpunkt. Beim Einsatz für das mobilen Lernen war dies nicht notwendig gewesen, da alle Gruppen im Vornherein feststanden und gleichzeitig das Spiel begannen. Die massgeblichen Änderungen betrafen den Einsatz der Technik. Beim mobilen Lernen wird versucht den Spielern etwas über die Umgebung beizubringen. Dazu eignen sich besonders interaktive Aufgaben mit hoher Kontextintegration [9]. Diese sind aber sehr aufwendig für den Bearbeiter. Auch sollten alle Aufgaben beim mobilen Lernen einen logischen Zusammenhang aufweisen und gemeinsam einem bestimmten, vorher formulierten Lernziel dienen. Beim Eventmarketing ist dies alles nicht notwenig. Es geht darum, dass der Spieler eine emotionale Bindung aufbaut und dies geschieht am besten über Kreativaufgaben, welche selbst nur einen losen Zusammenhang haben müssen [9]. Eine Inszenierung wie beim Eventmarketing ist damit weniger aufwendig wie ein Lernszenario beim mobilen Lernen und zielt im Kern auf emotionale Bindung. Beides lässt sich aber sehr gut durch den mExplorer unterstützen. 3.2. Das 175-jährige Jubiläum der Universität Zürich – Der mExplorer im Einsatz Für das 175-jährige Jubiläum der Universität Zürich sollte das Institut für Informatik sich der Öffentlichkeit präsentieren und dabei Werbung für die Universität und das Fach Informatik machen. Im Rahmen der Vorbereitungen wurde überlegt, ob man den mExplorer nicht als Marketinginstrument verwenden könnte. Zusätzlich wurden von anderen Bereichen des Institutes weitere spannende Forschungsprojekte ausgestellt. Jedes Projekt hatte einen Samstag lang einen Stand im Lichthof des Hauptgebäudes der Universität Zürich zur Verfügung. Um das Kontaktziel zu erreichen, also möglichst viele Leute für einen Besuch des Anlasses zu motivieren, wurden die restlichen Marketinginstrumente aktiviert: Eine spezielle Jubiläumshomepage informierte über die Aktivitäten, Plakate und Flyer in der Stadt Zürich luden die breite Öffentlichkeit zum Anlass ein. Bei dieser handelte es sich auch um die angepeilte Zielgruppe für den Event. Am Stand des mExplorers selbst wurden zwei grosse Bildschirme und Plakate zur Werbung für die Teilnahme am Szenario eingesetzt. Während des Anlasses ging es um die Erreichung der Kommunikationsziele. Zum einen sollte die Identifikation der Besucher mit der Universität gestärkt werden. Dies war das Ziel aller Anlässe zur Feier des 175-jährigen Jubiläums. An diesem speziellen Anlass ging es darüber hinaus darum das Interesse an der Informatik im Allgemeinen und das Interesse am mExplorer System und damit an der Arbeit der Arbeitsgruppe im Speziellen zu wecken. Um diese Kommunikationsziele zu erreichen erhielten die Besucher die Möglichkeit ein ca. 30minütiges mExplorer-Spiel zu spielen. Mit Hilfe des Systems ging es darum das Hauptgebäude der Universität zu erforschen und dabei die innovative Technik kennen zu lernen. Durch das Erforschen 626 der Universität sollte das allgemeine Kommunikationsziel, die Stärkung der Identifikation mit der Universität, erfüllt werden. Durch das Erleben der Technik sollte das Interesse an der Informatik und an der Arbeit der Arbeitsgruppe geweckt werden. Das genaue Vorgehen zum Einsatz des mExplorers als Eventmarketinginstrument wird im nächsten Abschnitt beschrieben. 4. Feldversuch Bei der eigentlichen Durchführung des Events am 05. April 2008 galt es zu überprüfen, ob die in Abschnitt 3.2 aufgezeigten Eigenschaften des mExplorers wirklich zutrafen und ob die Kommunikationsziele aus Abschnitt 3.3 auch erreicht wurden. Am Stand der Arbeitsgruppe Informationsmanagement sollte jeder Besucher die Möglichkeit erhalten an einem mExplorer-Spiel teilzunehmen. Unter allen Teilnehmer wurden ein iPod Touch und zwei iPod Shuffel verlost um so die Teilnahme attraktiver zu gestallten. Am Spiel nahmen im Laufe des Tages 38 Personen teil. Davon waren 13 Personen (34,2 %) weiblich. Die meisten Teilnehmer waren Schüler (36,84 %), gefolgt von Akademikern (21,05 %) und Studenten (15,79 %). Die restlichen 26,32 % verteilten sich auf verschiedene Berufe quer durch alle Gesellschaftsschichten. Die Teilnehmer waren im Durchschnitt 24,6 Jahre alt (min: 7 Jahre/ max: 60 Jahre). Auffällig ist, dass im Schnitt alle Personen überdurchschnittlich gut mit Computern vertraut waren (3,97 auf einer Lickert Skala von 1 bis 5). Dies resultiert sicherlich daraus, dass der Event explizit als Tag der Informatik angekündigt war. Es kann also von einer grundsätzlichen Technikfreundlichkeit bei den Teilnehmern ausgegangen werden. Vor dem Beginn des Spiels erhielten die Teilnehmer eine kurze Einführung in das System und ein Merkblatt, welches die Funktionen erklärte. Für das Spiel erhielten jeweils Zweiergruppen einen PDA, auf dem die digitale Karte der Universität und die Aufgaben eingezeichnet waren. Das Spiel war so aufgebaut, dass mehrere interessante Punkte wie Büsten oder Aussichtspunkte innerhalb des Gebäudes angelaufen werden konnten und dort die verschiedenen ortsspezifischen Aufgaben gelöst werden sollten. Zum Beispiel sollte der Büste „Nike von Smothrake“, welcher der Kopf fehlt, auf dem PDA ein neuer Kopf gezeichnet werden. Auf diese Weise konnte man selbständig mit Hilfe des PDA die Universität erkunden. Insgesamt gab es sechs Aufgaben und das Spiel dauerte in etwa 30 Minuten. Nach dem Spiel mussten die Teilnehmer einen kurzen Fragebogen ausfüllen, wenn sie an der Verlosung teilnehmen wollten. 5. Ergebnisse Nachfolgend die Ergebnisse zu Erlebnis, Interaktivität, Inszenierung und Kommunikationszielen. Sie zeigen die Wirkung des mExplorers beim Eventmarketing (siehe Forschungsfrage 2). Alle Fragen auf dem Fragebogen waren geschlossene Fragen, die mit Hilfe einer Lickert Skala von 1 bis 5 beantwortet werden konnten. Dabei stand 1 für gar nicht bzw. überhaupt nicht und 5 für sehr viel bzw. sehr geeignet. Als Randbedingung zu den folgenden Zahlen muss an dieser Stelle ein durch den Ort des Ereignisses gegebenes technisches Problem geschildert werden. Das Hauptgebäude der Universität hat einen überdachten Innenhof (Lichthof), in dem das Experiment stattfand. Der eingesetzte Positionierungsengine basiert auf Erfassung von WLAN Signalen, die sich an den verschiedenen Orten unterschiedlich darstellen. Dadurch, dass sich aber im Lichthof die WLAN Strahlung gleichmäßig ohne die Blockierung von Wänden ausbreiten kann, ist es sehr schwer zu erkennen, in welchem Stockwerk und wo in dem Stockwerk man sich befindet, so lange man sich innerhalb des 627 Einflussbereiches des Lichthofes aufhält. Leider lag 95 % der Spielfläche innerhalb des Lichthofes. Dadurch kam es zu erheblichen Problemen mit der Positionierung. Die Teilnehmer bewerteten daher die Behinderung durch technische Probleme mit erheblich (4,18). Trotzdem war das Feedback zum mExplorer sehr positiv. Als weitere Einschränkung ist sicherlich die kleine Datenbasis von nur 38 Personen zu nennen. Daher ist diese Untersuchung als explorative Analyse einzustufen. Für eine empirisch fundierte Aussage, müsste der Feldversuch sicherlich mit einer grösseren Personengruppe durchgeführt werden. Zudem müsste das Sample besser gewählt werden, da die befragten Personen wie oben beschreiben eher technikaffin waren. 5.1. Erlebnis Trotz der zum Teil erheblichen technischen Problemen mit der Positionierung hat den Spielern die Teilnahme an dem Spiel gut gefallen. Im Durchschnitt wurde der Spielspass mit 3,73 von möglichen 5 Punkten bewertet. Aus dem offenen Feedback im Fragebogen und den Gesprächen nach dem Spiel mit den Teilnehmern wurde deutlich, dass der Spass beträchtlich höher wäre, wenn die Positionierung zuverlässig funktioniert hätte. Zum Vergleich mit anderen Orten, bei dem diese Probleme nicht auftraten, wurde in früheren Feldversuchen im Bereich des mobilen Lernens mit dem mExplorer bereits ein Wert für den Spielspass von 4,68 [7] erreicht. Zusätzlich zum Spielspass wurden die Spieler befragt, wie schnell für sie die Zeit während des Spiel verstrichen sei. Diese Frage fungiert als Indikator dafür, wie sehr die Spieler ins Spielgeschehen eintauchten und ein Flow Erlebnis hatten. Das Ergebnis zeigt, dass die Zeit schnell vergangen ist (3,95). Sicherlich sorgte auch die gute Bedienbarkeit des Systems (3,94) für ein verbessertes Eintauchen in das Spiel. Als Fazit kann festgehalten werden, dass der mExplorer bei den Teilnehmern einen hohen Erlebniswert hinterlassen hat. 5.2. Interaktivität Wie bereits oben beschrieben, hatten die Spieler viel Spass am mExplorer. Eines der Hauptelemente des Spiels sind die interaktiven Fragen. Die Aufgaben im Spiel waren vor allen Dingen Kreativaufgaben, da diese sehr gut geeignet sind um eine emotionale Nähe zum beworbenen Objekt, in diesem Fall die Universität, herzustellen (Göth & Schwabe 2008). Die Spieler wurden danach gefragt, ob die Aufgaben zu leicht (1) oder zu schwer (5) waren. Die Spieler empfanden die Aufgaben als genau richtig (2,94). Bei den einzelnen Fragen bereiteten insbesondere diejenigen Spass, welche man mit einer Zeichnung (3,76) und mit Multiple-Choice (4,00) beantworten konnte. Der Spassfaktor bei Aufgaben mit Texteingabe (3,72) und Audioeingabe (3,2) fiel hingegeben leicht ab. Insgesamt kann man feststellen, dass die Interaktivität mit dem mExplorer und der Umgebung sehr hoch war und den Teilnehmern viel Spass gemacht hat. 5.3. Inszenierung Das Problem bei der Evaluation der Inszenierung ist, dass man nur indirekt danach fragen kann. Spass und Interaktivität sind relativ gut messbar, aber wie gut die Inszenierung an sich gefallen hat, ist schwer festzustellen. Daher wurden die Teilnehmer nach der Übertragbarkeit auf andere Felder gefragt. Dahinter steckt folgende Überlegung: Hat einem die Inszenierung gefallen, so hat man auch viel eher das Bedürfnis die Inszenierung auch in einer anderen Umgebung bzw. für ein anderes Objekt zu erleben. Insbesondere der Übertrag auf ähnliche Objekte wie z. B. Museen und Zoos (4,58) oder ganze Städte (4,50) wurde sehr gut bewertet. Die Übertragbarkeit auf allgemein andere, 628 werbewirksame Attraktionen wurde mit 3,86 etwas schlechter bewertet, wobei dies wohl eher an der unkonkreten Frage lag. Auf die Frage hin, ob man die Umgebung mit noch weiteren Informationen auf dem PDA anreichern sollte, was mit dem mExplorer möglich ist, wurde dies als wünschenswert (4,03) eingestuft. Insgesamt kann man also sagen, dass die Inszenierung mit dem mExplorer sehr erfolgreich war. 5.4. Kommunikationsziel Das Event hatte drei Kommunikationsziele. Zum einen wurde versucht mit Hilfe des mExplorers den Besuchern die Universität näher zu bringen. Dies wurde gut (3,47) erreicht. Im Vordergrund stand aber das Interesse an der Informatik und insbesondere das Interesse an der Arbeit der Arbeitsgruppe Informationsmanagement zu wecken. Hier waren die Ergebnisse noch etwas besser als beim Kennenlernen der Universität. Interesse an der Informatik wurde mit 3,74 und Interesse an der Technik und der Arbeit der Arbeitsgruppe wurde mit 3,97 geweckt. Dass die Technik die Spieler faszinierte, zeigt auch die Frage, wieviel Spass durch die Technik entstanden sei. Dies wurde mit 3,89 beantwortet. In Kombination mit dem Erlebnischarakter und der Interaktivität des Spiels kann davon ausgegangen werden, dass dieses Interesse langfristig in den Teilnehmern des Spieles verankert wurde. Man kann als Fazit festhalten, dass von einer hohen Werbewirksamkeit ausgegangen werden kann. 6. Fazit In Zeiten der Überflutung mit Werbung ist das Eventmarketing ein Instrument, welches die Akzeptanz von Anbietern und Nachfragern findet. Für die Nachfrager einer Leistung macht gut designtes Eventmarketing einfach Spass; für die Anbieter bringt es den Nutzen, dass ein Event eine bleibende Erinnerung beim Kunden hinterlassen kann. Bisher scheiterten viele Bemühungen zum Computereinsatz beim Eventmarketing an der mangelnden Portabilität der Geräte. Mobile Geräte erlauben es beim Eventmarketing die Interaktion mit der natürlichen Umgebung mit der Interaktion mit dem Gerät zu verschmelzen; dadurch wird das Einsatzspektrum von interaktiven Anwendungen deutlich erweitert. In der Aktivierung des Nutzers geht das mobile Eventmarketing deutlich über bisherige Ansätze zum mobilen Marketing (wie z.B. kontextabhängige Werbung) hinaus. Gerade bei der Aktivierung kann das Eventmarketing viel von der Mobile Learning Forschung profitieren [7], da dies ein Kernproblem beim Lernen darstellt. Es gilt den Teilnehmer durch verschiedene Stellgrössen wie Spielregeln, Technikeinsatz, Motivationsform, Aufgabenarten und Steuerungselementen in möglichst hohem Masse dazu zu bewegen sich aktiv mit einem Lern- oder Marketingobjekt auseinander zu setzen. In diesem Artikel konnten wir zeigen, wie man durch einfache Anwendung der Grundprinzipien des Eventmarketings (Erlebnisorientierung, Interaktivität und Inszenierung) zur Gestaltung eines mobilen Systems gelangt und bei dessen Einsatz Kontaktziele und Kommunikationsziele erreicht. Im vorliegenden Fall haben wir den mExplorer für die Erkundung des Events „Informatik an der Universität Zürich“ im Rahmen der 175-Jahr-Feier angepasst. Wir konnten zeigen, wie hoch das Potential eines mobilen Systems für die Förderung des Erlebniswerts ist, wenn mit Navigation, Interaktion und Kommunikation eine geeignete Funktionalität bereitgestellt wird und das Event gut inszeniert ist. Für uns Forscher war überraschend, wie sehr sich dabei die Anforderungen und die Beobachtungen von Eventmarketing und mobilem Lernen ähneln (siehe Forschungsfrage 3). In beiden Domänen tritt neben die Gestaltung von Anwendung gleichwertig eine vorbereitende Aktivität, die sich in einem Lernszenario (beim mobilen Lernen) oder einer Inszenierung (beim Event-Marketing) widerspiegelt. Bei den Tests zum mobilen Lernen überraschte uns noch die 629 grosse Bedeutung der Prozess-Steuerung sowie das grosse Potential, welches mobile Systeme hier haben [5]. Beim Einsatz zum Eventmarketing bestätigte sich dies. Gerade wenn die Teilnehmer kreativ sind, können bei der Inszenierung des Events nicht alle Eventualitäten vorausgesehen werden. Bei unvorhergesehenen Schwierigkeiten obliegt es einem Moderator mit den Teilnehmern Kontakt aufzunehmen und sie ggf. zurückzurufen. Es wiederholte sich auch die Erkenntnis aus dem mobilen Lernen mobile Medien nur zurückhaltend einzusetzen, denn der primäre Erlebnis- und Interaktionsraum ist die Realwelt (in unserem Fall: Die Informatikausstellung an der Universität Zürich). Sonst konzentrieren sich die Teilnehmer zu sehr auf das mobile Gerät und nehmen die natürliche Umgebung nicht mehr wahr (zum „Fokusproblem“ vgl. [6]). Und es zeigte sich in den Tests auch, dass selbst kommerzielle Indoor-Navigationssysteme noch nicht ausgereift sind und insbesondere in grossen offenen Hallen an ihre Grenzen stossen. Natürlich gibt es auch einzelne sachliche bzw. graduelle Unterschiede zwischen dem Eventmarketing und mobilem Lernen: So stehen beim Eventmarketing emotionale Aspekte im Vordergrund, während sie beim mobilen Lernen Mittel zum Zweck sind. Deshalb spielen Effekte eine grössere Rolle, während beim mobilen Lernen die Reflektion und die Vertiefung eine grössere Rolle spielen. Wir konnten in unseren Versuchen aber zeigen, dass dies weniger einen Einfluss auf die Technologie hat, als darauf, wie sie eingesetzt wird. Insgesamt bestätigt unsere Vermutung, dass durch den Einsatz von mobilen Medien Lernen, Arbeiten und Freizeit zunehmend miteinander verschwimmen. Konzepte wie Erlebnis, Kommunikation und Inszenierung treten als übergreifende Konzepte in den Vordergrund, wenn es das Ziel einer Aktivität ist eine „bleibende Erinnerung“ zu hinterlassen. Hier bleibt noch eine Menge interessanter Forschung zu tun. 7. Literatur [1] BECK, S., Event-Marketing in Bibliotheken: BibSpider, 2006. [2] BRUHN, M., Kommunikationspolitik. Grundlagen der Unternehmenskommunikation, Bedeutung - Strategien Instrumente: Vahlen, 1997. [3] DECKER, M., BULANDER, R., HÄGLER, T., und SCHIEFER, G., m-Advertising: Werbung mit mobilen Endgeräten - ein Überblick, in Mobile Informationssysteme - Potentiale, Hindernisse, Einsatz. Proceedings der 1. Fachtagung Mobilitaet und Mobile Informationssysteme (MMS), Passau, pp. 103-114, 2006. [4] EBER, S., Eventmarketing: Erlebnisstrategien für Marken, 3 ed.: moderne industrie, 2002. [5] FROHBERG, D. und SCHENK, B., Analyserahmen zur Lernsteuerung bei Mobile Learning, in Multikonferenz Wirtschaftsinformatik (MKWI) 2008, 2008. [6] GÖTH, C., FROHBERG, D., und SCHWABE, G., The Focus Problem in Mobile Learning, in WMUTE 2006: Proceedings of the IEEE 4th International Workshop on Wireless, Mobile and Ubiquitous Technologies in Education, Los Alamitos, CA, USA, pp. 153--160, 2006. [7] GÖTH, C., FROHBERG, D., und SCHWABE, G., Von passivem zu aktivem mobilen Lernen, in Zeitschrift für ELearning: Lernkultur und Bildungstechnologie. vol. Heft 4: Back, Andrea; Baumgartner, Peter; Reinmann, Gabi; Schulmeister, Rolf, 2007. [8] GÖTH, C., HÄSS, U.-P., und SCHWABE, G., Requirements for mobile learning games shown on a mobile game prototype, in Proceedings of the mLearn2004 conference, Rom, 2004. [9] GÖTH, C. und SCHWABE, G., Designing Tasks for Engaging Mobile Learning, in Proceedings of the mLearn 2008, 2008. [10] KÖLMEL, B., Location Based Advertising, in Mobile Business: Bernhard Kölmel, 2002. [11] LUO, X. und SEYEDIAN, M., Contextual Marketing and Customer-Orientation Strategy for E-Commerce: An Empirical Analysis, Int. J. Electron. Commerce, vol. 8, pp. 95--118, March 2004. [12] PINE, B. J. und GILMORE, J. H., Erlebniskauf: Konsum als Erlebnis, Business als Bühne, Arbeit als Theater: Econ Verlag, 2000. [13] SCHWABE, G. und GÖTH, C., Mobile Learning with a Mobile Game: Design and Motivational Effects, Journal of Computer Assisted Learning, vol. 21, pp. 204--216, 2005. 630 SERVICE-BASED INTERACTIVE WORKFLOWS FOR MOBILE ENVIRONMENTS Sonja Zaplata, Dirk Bade, Ante Vilenica1 Abstract Since the use of mobile devices spreads increasingly, mobile systems also play a major role for distributed business processes. In such scenarios, extending workflow management support to mobile systems offers potential to seamlessly integrate field staff into business processes, even if executing devices are disconnected from the company's server. However, the heterogeneity of current mobile systems still requires complex device-specific descriptions of user interfaces to integrate manual tasks. Therefore, this paper presents an abstract and modality-independent description model to support the development and execution of interactive mobile workflows and a corresponding prototype realization based on a service-oriented execution module. 1. Introduction In many companies, field staff is often already equipped with several mobile devices, such as notebooks, PDAs, or mobile phones. In order to support company-wide distributed business processes which include these employees, mobile devices shall be integrated seamlessly into such processes − despite of their specific technical differences. In such a scenario, mobile devices could be upgraded to run their own (partial) workflows, if the provided workflow management system can adapt to their specific needs. For such a purpose, specialised process description languages and workflow management systems have emerged which describe and execute the control flow of such applications. Unlike traditional workflow systems which are mostly centralized and include mobile clients as participants of single tasks only, more advanced systems focus on the distributed, selfcontained and preferably disconnected execution of business processes on mobile devices by an integrated lightweight workflow engine (e.g. [5, 7, 13]). For dealing with such mobile workflows, manual tasks containing user interactions play a key role. This is primary due to the fact that users carry mobile devices in order to interact with them at any time and place and are using mobile applications which are often related to the user’s posisition or situation. Therefore, business processes executed on mobile devices are rather characterized by context-dependent interactive applications than by automated processes running in the background. Additionally, there are situations where certain interaction modalities are prohibited or inappropriate. For instance, using speech during theater performances or in noisy environments like factory work floors is inappropriate, whereas interaction involving eyes and hands is forbidden 1 Distributed Systems and Information Systems, Computer Science Department, University of Hamburg, Vogt-Kölln-Str. 30, 22527 Hamburg, Germany 631 while driving a vehicle. Thus, a particular challenge for the development of mobile workflows is the specification of interaction tasks and the appropriate integration of manually initiated applications. Due to the heterogeneity of mobile devices, operating systems and network facilities, there is a great variety of possible user interfaces, reaching from audio and video to audio-visual interface modalities. Even within the field of the visual interface modality, screen size, resolution and underlying software systems may vary highly, so interactive applications have to be developed platform-dependent with substantial knowledge about the specific device, its software system configuration [10] and its current situation. Consequently, as a workflow participant, the executing device and its context must be known in advance and each interactive task has to be tailored to each single type of device and for more than one situation, which is in many cases very costly and inflexible. In order to cope with such challenges, an appropriate model for user interactions has to be developed which is independent of a specific platform and context - meaning any combination of mobile device, operating system, and user interface modality. However, rather than developing n user interfaces for n platforms, we suggest to develop only one abstract user interface model which is then automatically tailored to specific platforms at runtime. In addition, such a platformindependent approach has to consider the special characteristics and limitations of current distributed mobile workflow management systems, e.g. the requirement to work disconnected. In order to develop a systematic approach, the following section presents a use case to motivate and identify important requirements for such a platform-independent workflow interaction model. Subsequently, existing work in this research area is analyzed and evaluated in order to provide a basis for an enhanced approach presented in section 3. In section 4, the feasibility of modalityindependent user interactions is shown by the integration of the developed processing module into an existing workflow implementation. The paper concludes with a summary and an outlook on future work. 2. Use Case: Parallel Disconnected Mobile Workflow Processing A typical mobile workflow scenario can be found in the area of field work for marketing research where a high number of mobile users execute the same workflow in parallel. This section summarizes the experiences, observations and requirements of two German marketing research facilities being interviewed on this subject. Marketing surveys have previously been performed by paper questionnaires which had to be produced and distributed, filled out manually and finally had to be collected or sent to the research institution, where they had to be typed into the computer in order to be integrated and evaluated. As this procedure is rather inflexible, costly and time-consuming, the integration of mobile devices could eliminate several of these drawbacks. Due to the fact that marketing research is often characterized by casual employment, the assignment of few special purpose devices is not profitable, but - controlled by a central management system - the existing infrastructure of casual employees (e.g. personal mobile phones) can be utilized to transfer and present questionnaires electronically. First attempts towards the utilization of mobile phones involve the bidirectional exchange of SMS (Short Message Service) or the use of browser-based web applications which both cause unacceptable costs because of their need for frequent or permanent network connections. Another main aspect is the integration of user interactions with automated or semi-automated tasks and application calls. As many interactive applications are only valuable in a specific context, such as performing a measurement at a specific location, the utilization of simple user interfaces, devicespecific interactive applications and even fully automated services is highly interrelated. A use case 632 related example is the integration of a GPS application to attach the current position of market researchers during the interview. Therefore, the ability to integrate user interactions with arbitrary (semi-)automated activities such as software services is an important requirement to build interactive workflows for more than one specialised application or business domain. The necessary integration therefore also implicates an open architecture and an adequate data exchange mechanism, in order to allow control flow decisions based on data entered or automatically processed in previous activities. Figure 1 shows the overall infrastructure for an exemplary survey with electronic questionnaires which are distributed to mobile market researchers: Here, the participating users download the workflow description and start to execute it in parallel, e.g. at different locations. An exemplary workflow is depicted in figure 2. It contains three activities, two of them are user interactions asking the market researcher to enter information about the interview. The last activity calls an application in order to obtain position data of the current location and attaches it to the result set, which is finally returned to the server. Workflow Provision and Distribution Workflow Description Workflow Execution Personal Information Gender: Age: male 49 Local Noise Pollution Do you feel disturbed by street noise in this place? [Application Call] Include GPS data yes no Result Data Figure 1: Parallel disconnected mobile workflow processing Figure 2: Example workflow for electronic surveys However, with a growing number of field workers, the number of different executing devices increases significantly and the customization of otherwise identical user tasks to each single executing device would be very expensive and, considering the assumed cost-value ratio of such market surveys, not profitable. Therefore, a one-for-all workflow description which is also able to access device-specific applications would be advantageous. Such an approach to mobile workflow management systems leads to increased requirements resulting from the heterogeneity as well as from the limitations of mobile systems (cp. [10, 16]). The next section will therefore analyse and evaluate existing work in the area of workflow related user interface descriptions in order to develop an appropriate solution to this problem. 3. Analysis of Existing and Related Work There are two main directions for interactive workflow processes executed on mobile devices − thin client and fat client (resp. rich client) solutions. In the first case, mobile devices present information to and receive input from the user, but the business logic resides on a server in the backend. A common approach realising this is to use web applications running on a central application server, rendering information as HTML pages, which are transferred with e.g. HTTP or WAP to a (mobile) device to be displayed using an internet browser. However, this approach has several drawbacks: For example, an online connection has to be kept as long as the user interacts with the application, which is often neither possible (e.g. indoors) nor preferable (e.g. costs, energy 633 consumption). Furthermore, interaction possibilities are constrained to the elements of HTML or WML and activities which need to access resources of a mobile device (e.g. storage, camera, GPS) are not executable, because such resources cannot be accessed by an internet browser. Finally, application development is more difficult as the server is responsible for managing user sessions and dealing with unreliable network connections. An example for an interactive thin client approach is the Java Border Service Architecture [10]: It allows using a single application instance on multiple heterogeneous devices. This is accomplished by taking a snapshot of an application’s presentation layer at runtime, transforming it into an abstract intermediate representation before converting it according to the (mobile) device's capabilities. Interaction events (e.g. pressing a button) are exchanged between the application kernel and its presentation layer copy by sending messages over a network link. Other solutions rely upon Ajax (Asynchronous JavaScript and XML), which allows to asynchronously fetch data from a server in response to user interactions and to update the HTML interface correspondingly. These approaches, although dealing with some of the aforementioned problems, are not suitable for mobile environments in all cases, as e.g. a stable network link is required but not always available. On the other hand fat client solutions have been developed. In this case, the application as well as the data is stored on the device, user input is processed locally and a network connection is only used to communicate results back to or receive new tasks from servers. Java Micro Edition runtime [17], which is installed on many mobile devices and is most commonly used for developing such applications, does not only allow for arbitrary interaction methods (forms, 2D- and 3D graphics, voice, etc.) but also grants access to most of a device's local resources through standardized APIs. This way, applications may run independently of a network connection, sessions may directly be stored on the local device and once a network connection is available, results may be sent back to a server for further processing. There are several corresponding workflow engines available: The architecture presented by [13] describes a fully service-based workflow engine, running on mobile devices. Users interact with the engine by navigating and communicating through XHTML pages and forms. The results are wrapped in SOAP messages and sent to a local WS-BPEL workflow engine, managing the control flow of the process. This approach focuses on XHTML to describe interactive activities and therefore lacks several interaction possibilities as it is depending on visual modality only. As another example, the Active Forms runtime environment [14] addresses the integration of arbitrary applications, accessible through web service wrappers, into an XHTML- or mobile forms-based user interface. User tasks are described using WS-BPEL [12] and executed by a lightweight workflow engine to orchestrate user interactions spanning multiple applications. As WS-BPEL alone is not appropriate for describing user interactions, two language extensions have been defined: BPEL4People [1] and WS-HumanTask [2]. These allow to specify manual tasks within a workflow, but lack the possibility of describing a user interface in detail. Moreover, WSBPEL itself requires static endpoint references, which is a big drawback if being used in workflows spanning multiple devices in dynamic environments. Summarized, the presented workflow engines in common either require a steady network connection and/or lack the possibility of processing a rich description language for interactive workflow processes. Such a language is used to describe (interactive) activities by defining interaction components as well as flow elements specifying the temporal-logical course of actions. Existing languages can be classified by the artefacts used to define an interactive workflow and its activities. Two approaches can be distinguished: abstract and model-based descriptions. The User Interface Modelling Language (UIML) [11], for example, is a representative of the abstract description family. UIML allows defining interface elements in an abstract – device independent – way, but lacks a mapping to concrete presentation components as well as the integration of control 634 flow logic. The Extensible User Interface Language (XUL) [4] is another abstract description language, which is not – in contrast to UIML – transformed to a specific language, but interpreted at runtime. It is used, for example, by Mozilla’s Firefox applications to create the user interface and is interpreted by the Gecko Rendering Engine at runtime. But as XUL can only describe graphical user interfaces, it is bound to the visual modality. Similar drawbacks also hold for other abstract description languages, e.g. MXML [3], XAML [8] and XForms [18]. A popular representative of model-based approaches is the ConcurTaskTree (CTT) [15]. Tasks a user has to perform are decomposed into smaller subtasks leading to a task tree. The tree’s leaves represent the interaction components and are connected by binary operators to state, e.g. whether two tasks have to be executed sequentially or in parallel. Additionally, dialogs, presentations and users are part of CTT’s vocabulary and are used to group tasks to further specify the control flow and to personalize interfaces. The drawback of native CTT as a description language has its roots in the orientation of CTT towards client/server environments. This leads to an insufficient support to model data and control flow as well as non-functional requirements. Nevertheless, CTT is most suitable to form a basis of an abstract interface language for mobile workflows, not only taking into account the design of multimodal interaction methods but also the dependencies between different activities and the heterogeneity of platforms. Moreover, a graphical modelling tool called TERESA [9] supports the development of CTT-based interface descriptions. 4. Service-based User Interactions for Mobile Workflows Workflow-based applications such as presented in the use case (cp. section 2) require a platformindependent interaction model and an appropriate processing module to relieve process designers from considering the system-specific behaviour of each executing device and its potential situation. Based on the experiences of existing approaches as analyzed in section 3, this section first introduces an abstract interface model to describe user interactions in a platform-independent way. In the following, a prototypical realization of a corresponding mobile interaction service as a loosely coupled workflow management module is described and integrated into an existing workflow management system. Finally, experiences with the technical evaluation of the developed prototype are pointed out. 4.1. Abstract Interface Model The ConcurTaskTree (CTT) [15] has proved to be a suitable approach to form the basis of an abstract interface model for mobile workflows, but still lacks an appropriate description of data and control flow. The developed enhanced model is therefore made up of three main artefacts: One represents elements to define the user interface, one for the control flow and another for the data flow. Additionally, there are elements to define non-functional requirements as well as stylesheets. Due to space limitations, this section focuses on the artefact for the user interface and gives only a brief overview of the other artefacts as they correspond to traditional abstract workflow languages such as described by the Workflow Management Coalition (WfMC) (cp.[19]). From a high level point of view, user interactions can be characterized as a sequence of manual tasks of data input and output. To describe elements dealing with user interaction in a platformindependent way, the proposed model includes a preceding interface layer. Key concept within this layer is a meta-description of user interface elements. At runtime, the abstract user interface model, e.g. the elements of the interface layer, is automatically transformed into a platform-dependent description. This mapping takes care of the specific capabilities of each platform. 635 For the development of platform-independent user interface models, basic user interface elements as needed in interactive business processes have been identified. Figure 3 shows the resulting structure of the interface model, containing the most relevant elements and attributes. Centrally, there is a need for elements covering the input and output of data edited by the user. This group of elements is called Edit. Second, there is a demand for elements which deal with data that cannot be edited but selected - referred to as Selection. Third, elements are needed to trigger actions or to navigate within user interfaces which are called Control. In order to model abstract user interfaces, any of these three elements can be combined arbitrarily. Thus, an abstract user interface model, called Presentation, consists of several of those basic user interface elements. A full mobile workflow or Process, can consist of several Presentations. It is important to mention that the three basic user interface elements can be tailored towards a special usage by adding certain metadescriptions. For example, Selection can either be Single-Selection or Multiple-Selection indicating if one or more elements can be selected from a set of elements, e.g. a list. Moreover, Edit elements can predetermine a certain data type, such as String or Decimal, to facilitate further processing. 01 Process Name="Noise Pollution Survey" Process (1) 02 InteractionActivity ID="First" InteractionStartActivity="True" (Stylesheet=...) Interaction Activity (1..n) (ID=…; InteractionStartActivity=...) Presentation (1..n) (Name=….) Interactor (1..n) (ID=…; Direction=…) User Interaction Details (1) (Description=…) User Interaction Type (1) Selection (SelectionType=…; CardinalityType=…) Edit (EditType=…) Control (ControlType=…) Object (1) (Name=…; Type=…; Value=…) 03 Presentation Name="ZipCode" 04 Interactor ID="Zip" Direction="Out" 05 UserInteractionDetails Description="Enter your Zip Code:" 06 UserInteractionType EditType="String" 07 Object Name="Code" Type="String[]" Value="" 08 Presentation Name="Street/Opinion" 09 Interactor ID="Street" Direction="InOut" 10 UserInteractionDetails Description="Select your street in $Zip:" 11 UserInteractionType SelectionType="SingleSelection" CardinalityType="High" 12 Object Name="Streetlist" Type="String" Reference="Remote" Value="http://www.streetlists.org/$Zip.xml" 13 Interactor ID="Opinion" Direction="Out" 14 UserInteractionDetails Description="Noise Pollution:" Optional="True" 15 UserInteractionType SelectionType="SingleSelection" CardinalityType="Low" 16 Object Name="Choices" Type="String[]" Value="[Low|Medium|High]" Figure 3: General structure of the abstract user interface model (selected attributes only) Listing 1: Exemplary interaction activity from the market research domain There are various options to turn an abstract element into a concrete one. Listing 1 gives an example of two user interface descriptions (lines 3-7 and 8-16) using the introduced model. As mentioned previously, the platform-independent model also has artefacts to describe the control and data flow. Therefore, each basic user interface element (called Interactor) has a data output and input container to which user input is written or can be read from respectively. An example can be found in lines 9-12, where $Zip is as well input as output parameter (indicated by Direction=”InOut”) and refers to the contents of the Interactor with the respective ID in line 4. 636 Furthermore, these data containers support the use of references which allows the integration of local or remote elements within a user interface. Accordingly, in the given example contents of a selection element can be downloaded at runtime (line 12), which is advantageous if the actual execution of an activity is optional or is, e.g. to be decided in dependence of previous input data. Provided that a network connection can be established, this option allows to save memory space and to load large objects only if they are actually required. Finally, the proposed model gives the opportunity to specify non-functional requirements and stylesheets (not depicted). With these two groups of elements it is possible to bind a user interface element to a special interaction modality (for example, displaying a large image might need a certain screen size) or to specify the Look-andFeel of the application. By ignoring these additional descriptions, the respective interpreter can initialize a fallback to other (suboptimal) modalities if applicable. 4.2. Mobile Interaction Service The developed mobile interaction service is a device-specific component which can be attached to the mobile system's workflow engine or can be utilized as a lightweight stand-alone system running on a mobile device. It hides platform-specific characteristics from the process designer such that it does not matter which mobile device is used or which interaction modalities is supported. Therefore, its main tasks are to automatically transform the abstract user interface model into a platform-specific presentation and to manage the user's input. In order to achieve the mapping from abstract user interface objects to specific ones, each mobile interaction service has knowledge about the platform specific capabilities (e.g. user interface elements, supported interactions modalities) of the mobile device it is running on. To avoid developing an individual execution environment for each single device, the current prototype environment is based on the J2ME device classification [17] which is applicable to most of today's mobile systems such as notebooks, PDAs and mobile phones (cp. figure 4). Thereby, device-specific adaptations can be minimized and do mostly affect the runtime environment for certain interface modalities, such as audio and video representation. Of course, the interaction service can as well be realized in any other programming language supported by the mobile device. Parent workflow engine’s control flow Java 2 Platform, Micro Edition (J2ME) Optional Packages Java 2 Platform, Enterprise Edition (J2EE) Optional Packages Java 2 Platform, Standard Edition (J2SE) Optional Packages Personal Basis Profile Foundation Profile JVM JVM Abstract interface description Personal Profile CLDC KVM Interaction Management Instance Mapping of result data to parent workflow description Java Card Modality 1 Modality 2 User Interaction Result Writer Card VM Interaction Factory Modality n Control Flow Processor MIDP JVM Parser/ Interpreter (optional) Optional Packages CDC Interaction Service User Input Input Input Processor Result data User Figure 4: J2ME architecture and resulting device classification [17] Figure 5: Schematic diagram of the prototypical interaction service Because the concrete implementations differ slightly w.r.t. device classes and modalities, figure 5 gives a schematic overview of the overall architecture. Once an abstract description is received by the interaction service, the description is parsed and interpreted in order to create an internal model which acts as a basis for the Interaction Factory to create a modality-specific interaction dialog. This approach is flexible enough to incorporate any events that happen at runtime and hence allows adapting the interaction to the current context and system specifics by choosing an appropriate modality. The Interaction Management Instance is responsible for presenting the created dialog to 637 the user and accepting any user input. Afterwards, the user input can optionally be fed into the interaction service’s internal Control Flow Processor to realize a sequence of interactions without intervention by the workflow engine. Finally, when the user completed the interaction, his input is encoded by the Result Writer and passed back to the workflow engine to be integrated into the overall process description. 4.3. Integration Due to its service-orientation, the mobile interaction service can be plugged into existing workflow management systems or can be integrated as an invoked application, as e.g. considered by the WfMC [6]. In order to show the feasibility of the presented approach the platform-independent interaction model and its corresponding interaction service have been applied to the workflow system as presented in the use case. receive Workflow (Web Service) Development and analysis (Graphical) workflow modelling application External applications to view, export and analyse result data upload Results (Web Service) Participant Descriptor Participant Manager Communication Manager Application Descriptor Application Manager send results Interactive workflow model Result data start execution receive workflow Workflow Instance Manager return Server Workflow Execution Engine Web application store Web Service Web Service Interactive workflow instance fetch Workflow Repository Result data execute application Mobile device return Personal Information Gender: Age: Exit ... Interaction Service Camera Service Result Repository GPS Service Mobile workflow engine Interaction Service Script Repository male 49 User OK Figure 6: Global system overview of the mobile market research workflow distribution Figure 7: Schematic diagram of the mobile market research workflow engine As introduced, one of the main goals is to cover and support the entire lifecycle of electronic surveys running on different mobile phones. The corresponding lifecycle starts with modeling the survey, continues with its distribution to mobile devices, goes on with its execution, and finishes with returning the result data to the market research office (cp. figure 6). The first step includes modeling the interactions in the abstract format which is usually performed on a stationary system, such as a personal computer, and supported by modeling tools such as an XML editor or TERESA [9]. As a result, the mobile workflow is described in an XML document containing the control flow logic (here in an XPDL [19] derived language format) and the user interactions specified valid to the abstract interaction model’s XML-schema. In the second step, the workflow description is 638 stored on a web server, from where it can be distributed to mobile devices by using a web service. As the web service is accessible from mobile devices, everyone participating in the research can download the workflow description, store it in a local workflow repository and pass it to the mobile workflow execution engine once it shall be executed. Each time an interactive activity is discovered, the workflow engine calls the interaction module, which produces an appropriate interface representation, collects the user's input data and then returns the control flow back to the workflow engine. Figure 7 shows an overview of the workflow engine’s architecture and the integration of the mobile interaction service. As the workflow description specifies both control and data flow, mobile devices can execute the workflow autonomously and no connection to the server is required during runtime. When the mobile workflow has finished, its results may be stored on the mobile device until an appropriate network connection is available. As the last step of the workflow lifecycle, the mobile device returns the results to the web server, again using a web service. Finally, the results of the mobile workflow can be downloaded from the server, can be further processed, or they may trigger other applications. 4.4. Implementation Evaluation The implementation and integration of the interaction service is straight forward. Two versions have been realized: one for PDAs (using J2ME’s CDC) and another one for resource constrained mobile phones (using CLDC accordingly). The prototypes have been developed and tested using the emulators of Sun’s Wireless Toolkit as well as Nokia’s SDK, which are able to simulate a PDA and a mobile phone respectively, offer support for application profiling and configuration options to change device and infrastructure properties (e.g. processing speed or network bandwidth). As these emulators use different renderings for user interfaces, the mapping of abstract interaction objects (AIO) to concrete interaction objects (CIO) could be optimized. By finalizing certain milestones, the application was also deployed and tested on real devices. The result shows that, due to vendor-specific interpretation of concrete interaction objects, the visual user interface differs slightly from device to device and emulator to emulator. With respect to the layout of components, this is not a problem. A more aggravating factor is, however, the vendor-specific mapping of navigation keys and menu placements which, in some cases, hinder an intuitive navigation (e.g. use left and right buttons for back- and forward navigation). As some mappings of AIOs to CIOs were expected to be quite resource-intensive, the actual prototype implementation showed the opposite: Although performance issues were not explicitly considered, parsing of the abstract process description (using kXML) as well as the creation of AIOs and the mapping to corresponding CIOs are performed nearly instantly, i.e. within parts of a second. Slight performance drawbacks only appear when large binary data chunks (e.g. audio data or an image taken by a phone’s camera) shall be stored as results in the process description. In this case, binary data is Base64-encoded, which takes less than 5 seconds (for a 2 megapixel image) on the mobile phone, but approximately 30 seconds in Sun’s emulator on a PC. Apart from this, users are not aware of the on-the-fly creation and composition of user interfaces. The interaction service itself has been realized as a self-contained component which can either be attached to an existing workflow engine or used as a lightweight stand-alone system. The same service wrapping concept has also been applied for accessing the mobile phones local resources, (e.g. storage, camera, GPS) in such a way as to enable straightforward access to these services from the workflow execution engine, as depicted in figure 7. 639 5. Conclusion and Future Work This paper argues that mobile workflow management systems would benefit from a one-for-all approach to design modality-independent user interactions. Therefore, an abstract interface description model is introduced which allows the specification of user-centric workflows without knowledge of the executing device type or its environment. To interpret and to process interface descriptions resulting from this model, a corresponding service-based interaction module has been developed. To show its applicability, a prototypical realization of this module has been integrated into an existing mobile workflow management system, enabling the integration of user interactions with other interactive applications such as the internal camera of a mobile phone. Furthermore, if more than one interaction modality is available (e.g. video or audio), the most appropriate way of interaction can be chosen dynamically and in dependence of the current context situation. Future work includes solutions for the selection of appropriate participants depending on their context as well as support for automatic workflow distribution. Therefore, advanced management functionalities for mobile information retrieval are required, e.g. regarding the location or current workload of potential workflow participants. It is currently evaluated, whether mobile web service technologies can be applied to provide such informational services for each registered mobile device while respecting the privacy requirements of the mobile user. Such an approach could finally facilitate the definition of the overall business process, e.g. by involving the mobile participant selection procedure in a superordinated process description (e.g. WS-BPEL) to integrate and execute such tasks automatically. 6. References [1] Agrawal et al., BPEL4People Specification 1.0, https://www.sdn.sap.com/irj/sdn/bpel4people, 2007. [2] Agrawal et al.: WS-HumanTask Specification 1.0, http://download.boulder.ibm.com/ibmdl/pub/software/dw/ specs/ws-bpel4people/WS-HumanTask_v1.pdf, 2007. [3] Coenraets: An overview of MXML, Adobe Inc., www.adobe.com/devnet/flex/articles/paradigm.html, 2004. [4] Goodger, Hickson, Hyatt, Waterson: XML User Interface Language (XUL) 1.0, Specification, http://www.mozilla.org/projects/xul/xul.html, 2007. [5] Hackmann, Haitjema, Gill, Roman: Sliver: A BPEL Workflow Process Execution Engine for Mobile Devices, in: Proceedings of 4th International Conference on Service Oriented Computing (ICSOC), 2006. [6] Hollingsworth: The Workflow Reference Model, WFMC-TC-1003 1.1, 1995. [7] Kunze, Zaplata, Lamersdorf: Mobile Processes: Enhancing Cooperation in Distributed Mobile Environments, in: Journal of Computers, 2(1):1-11, 2007 [8] Microsoft Corp.: XAML, msdn.microsoft.com/en-us/library/ms747122.aspx [9] Mori, Paterno, Santoro: Design and Development of Multidevice User Interfaces through Multiple Logical Descriptions, in. IEEE Transaction on Software Engineering 30, Nr. 8, 2004 [10] Müller-Wilken, Wienberg, Lamersdorf: On Integrating Mobile Devices into a Workflow Management Scenario, in: Proc. 11th International Workshop on Database and Expert Systems Applications (DEXA), 2000. [11] OASIS: UIML Standard, www.oasis open.org/committees/tc_home.php?wg_abbrev=uiml, 2007. [12] OASIS: WS-BPEL Spec. 2.0, www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsbpel, 2007 [13] Pajunen, Chande: Developing Workflow Engine for Mobile Devices, in: Proceedings of the 11th Enterprise Distributed Object Computing Conference (EDOC), 2007. [14] Pajunen, Chande: ActiveForms: A Runtime for Mobile Application Forms, in: Proceedings of the International Conference on the Management of Mobile Business, 2007. [15] Paterno: Model-based Design and Evaluation of Interactive Applications, Springer 2007 [16] Satyanarayanan: Fundamental Challenges in Mobile Computing. In Proceedings of the 15th ACM Symposium on Principles of Distributed Computing , 1996. [17] Sun Microsystems, Inc.: J2ME Technologies Overview, Datasheet Overview Java 2 Platform Micro Edition, 2002. [18] W3C: The Forms Working Group, www.w3.org/MarkUp/Forms, 2008 [19] WfMC: XML Process Definition Language, Version 2.0. Specification WFMCTC-1025, 2005. 640 AN INTERACTIVE REMOTE VISUALIZATION SYSTEM FOR MOBILE APPLICATION ACCESS Marcus Hoffmann, Jörn Kohlhammer1 Abstract This paper introduces a remote visualization approach that enables the visualization of data sets on mobile devices or in web environments. With this approach the necessary computing power can be outsourced to a server environment. The developed system allows the rendering of 2D and 3D graphics on mobile phones or web browsers with high quality independent of the size of the original data set. Compared to known terminal server or other proprietary remote systems our approach offers a very simple way to integrate with a large variety of applications which makes it useful for real-life application scenarios in business processes. 1. Introduction Looking forward to the growing mobilization of the work force and data access, one focus of visualization these days is to use known visualization techniques on mobile devices. The main challenge in mobile computing is limitation of limited hardware resources. At the same time the data transfer rates have grown in the recent years. It is now possible to establish peer-to-peer data connections between mobile and portable devices and stationary hardware. Data flat rates for mobile access using e.g. WiFi or 3G wireless networks become more and more affordable. Looking further at this evolution, we expect the usage and acceptance of streaming data to mobile devices to grow in the coming years. Terminal server applications and proprietary remote visualization solutions tried to address these problems in the past. Nevertheless these technologies aim for specific solutions and have constraints regarding the flexible integration and functionality porting to the mobile device. This paper presents a system that allows the user to interactively use high quality 2D and 3D graphical content with slim clients like smartphones or PDAs. The visualization system is designed to connect to a variety of applications on the server side and transmit the pre-calculated visualization data to a mobile client where the user can interact with the server-sided application in real-time. The application can use all hardware provided by the server. The mobile client gets visualization results of highest possible quality regarding to what the server application can achieve. This objective can be fulfilled through a streaming connection between the mobile client and the application located on the visualization server. Except the addressing of limited hardware possibilities of mobile devices another benefit of a remote system that has to be taken into account 1 Fraunhofer IGD, Darmstadt, Germany 641 is a security issue. Transmitting pre-calculated and rendered data to a mobile device without sending the real application data is a big advantage looking at secure data transmission for applications handling confidential data on the server side. The data itself is safe behind firewalls and only used by the application on the server side. The only data sent to the client is the remote image data. 2. Related Work 2.1. General approaches Enabling visualization on mobile devices has been a major research topic in recent years. The main goal of the research in this area was to achieve interactivity on slim devices like Smartphones or PocketPCs with very limited hardware properties regarding complex calculations. Generally there are two ways to achieve such visualizations. The first approach aims at the development of toolkits and algorithms to provide the mobile device with highly compressed and optimized data for visualization and a framework running on the mobile device itself to render the received data sets. Here, Pulli et al. [13] or Soetebier et al. [19] have achieved very interesting results presenting a framework for mobile 3D visualization with OpenGL ES [12] and M3G [14]. With the approach in M-Loma [9] has targeted the area of geographic visualization to bring 3D city maps and landscapes to mobile phones and achieved excellent results in the field of rendering on mobile devices. The second major approach is to outsource the calculations for visualization to a server and transmit the completed results in form of images or video streams to the thin client. Engel et al. [4], B.O. Schneider and I. M. Martin [17] or SGI’s VizServer [18] have shown methods how to visualize complex 3D data on mobile devices with the focus on special applications or systems a few years ago. Other approaches described by Teler and Lischinski [22] or Soumyajit et al. [20] especially in the area of 3D remote rendering use distributed image-based transmission of parts of the 3D scene and re-arrange the images and imposters on the client-side to complete the 3D scene with pre-rendered images from the visualization server. However, these approaches target either special data structures and data sets or special applications where they integrate their remote functionality. Our approach aims for a more generalized solution in the remote visualization area to be able to use one system for a number of different applications instead of implementing specialized and proprietary solutions for each different application. Basically it does not require a specific application or server solution to work with. The application only needs the capability to capture the content that is targeted for remote visualization and an interface to listen to incoming interaction events. For some development frameworks (QT [15], MFC [10], Java [6]) this functionality is provided within a plug-in library, for others generalized methods to input the captured image data into the plug-in for further processing and transmission to the mobile client are provided. 2.2. Yet another Remote Desktop Application? A variety of virtual network computing (VNC) applications [16] [24] was developed in the recent years to gain remote workers access to workstations from everywhere. For every popular operating system different applications are available such as the Microsoft Windows remote desktop [10] or RealVNC [24] for windows and Linux operating systems. The VNC applications provide access to the complete desktop of the remote workstation. This paper describes a more sophisticated approach. Basically, our system will not give the mobile user access to the complete desktop with 642 all its functionality and access to critical system parts. Only the relevant parts of the application will be visualized for the transmission to the client-side and only these parts are available for interaction. Which parts this will be can be defined by the administrator that integrates the application with the remote system. Another issue with VNC visualization is included by the use of OpenGL or other 3D content visualization on the server environment for different reasons. Either they gain access to different users at the same time but having problems with hardware accelerated visualization technologies or they gain access to one remote user per session being able to use hardware features for the remote visualization. The reason for the problems in hardware acceleration for different users at the same time lies in the fact that such solutions make use of software emulated graphics adapters. These emulators do typically not support hardware accelerated features as needed for e.g. OpenGL. Terminal server solutions are some kind of similar to VNC solutions but terminal server solutions are optimized for special programs on the server and the client side. Furthermore real application data is transmitted between the client and server side which makes the application vulnerable for hacking or spy attacks. Since the only data this solution transmits is image data from the server to the client and proprietary interaction data from the client back to the server which only can decode the remote server we have achieved to have a very robust solution looking at security issues. 3. System Concept The basic concept of this visualization system is the outsourcing of all calculations necessary for the visualization to a server environment. Instead of transmitting the data to the mobile client and doing the visualization calculations on the mobile device the visualization application is running on the server. The thin client only has to render 2D image data and capture interaction from the client user. The interaction data is then transmitted back to the server environment for post processing and adaptation of the current visualized scenes. Figure 1 shows the basic communication pipeline between the application itself and the mobile clients on the other side using the render server in between. On the server side, at least two programs are running. The first one is the application itself which contains all the visualization functionality and technologies which has to be provided for the mobile client. Since the application is running on the server side of the overall system it can make use of all hardware advantages the server provides. Therefore very complex calculations and visualizations can be done using the latest hardware features on the server side. Figure 1: The complete communication pipeline. 3.1. Render server The render server component consists of three major parts: the network interface, the image processing engine and the application interface. Basically, the system provides a one to one connection from the mobile client to the remote application. However, more than one mobile client will be able to connect to the same remote enabled application. All clients connected to one instance of the application will see the same visualization and each mobile client will see the same interaction and remote steering from all connected devices. 643 To provide different views to different users it is possible to start multiple instances of the application on the server side and connect each different mobile participant to a different instance of the remote enabled application. Then, every mobile user will have its own visualization not shared with others and can interact with it independently. Figure 2 shows the render server’s architecture, its components and how the components communicate with each other. Figure 2: The render server system layout 3.1.1. Network Interface The network interface handles the network communication between the render server and the mobile client. At its current state it supports two options: Communication over TCP/IP for LAN, wireless LAN or 3G connections and the communication over Bluetooth for short distance connections. Both protocols are integrated into the mobile client application and the render server and can be used. The first part of the network interface is the client manager. It provides a server socket that is listening for incoming connection requests of mobile clients. It handles the connection procedure and the management of multiple clients. This management includes the correct routing of the different clients to their according application instances for remote visualization. The second part is the worker area for connections to the different clients. This part of the network interface takes care of the creation of the network stream from the compressed image data incoming from the image processor. The network connection to the client runs in its own thread which grabs the image data from a buffer provided by the image processing engine every time the client asks for a new image. Another thread is running in the network interface for incoming interaction request. Here, all commands incoming from the mobile client are decoded and sent back to the application interface. The application then grabs the commands from the interface. Every application can then interpret the commands individually. 3.1.2. Image processing engine In this engine the encoding of the captured raw image data into a stream able image or video format is done. Furthermore the capture functionality for selected application frameworks and technologies is integrated here. The image processing engines provides a number of different algorithms used to compress images like JPEG, J2K, PNG, GIF, Motion JPEG etc. Chapter 4 discusses in detail the utilization of image-based transfer in comparison to video streaming. The image processing engine can be extended by additional compression algorithms. The engine provides the current state of the visualization within a buffer. This buffer is updated for each change of the content in the application. Then, a new image will be encoded and stored into the buffer. From that buffer, the 644 network interface will grab the image and encode it into a network stream that is sent to the mobile client. 3.1.3. Application interface and integration This is the interface for the visualization application to communicate with the render server or the mobile client on the other side of the network pipeline respectively. The application has to use this interface to the render server because it provides the application with all functionality that is necessary for the remote connection. This basic interface makes it is very simple to connect new applications to the render server functionality. The render server’s application interface consists of two parts that must be connected with the application: The first part is the capturing functionality. Here, the application makes use of algorithms integrated into the render server interface to capture either the complete application window or only certain parts of the application. For a number of popular development frameworks like Java, QT, MFC or OpenGL context widgets image grabbers are integrated into the application framework of the render server to alleviate the integration of the remote system for the user. The interface is designed in a way that it can be extended with more functionality regarding the grabbing of content from an application. The application can also decide to capture the content by itself and supply only raw image data. In this case, the image processing engine will be provided with the captured raw image data for further processing. The other facility of the application interface is a command interface which is triggered every time the mobile client sends an interaction request. This request is only an undetermined command coming from the mobile client and routed through the render server to the application interface. In the current version, the application does the command message handling, interpret the command and trigger the according functionality inside. In summary, it can be stated that the effort to integrate the remote visualization functionality into existing applications is kept very low. The developer only has to decide which part needs to be exposed to remote users and let the interface capture this part. 3.2. Mobile client The mobile client was realized using the Java Micro Edition (JME) [5] to maximize the compatibility on different devices. Almost all currently available mobile devices are able to interpret JME applets. Furthermore, such applets can easily be integrated into a website. Hence, one mobile application can be used to connect to a large number of different remote applications using a large number of different mobile devices. This was one of the main goals of our work – to be able to have a generalized solution for mobile visualization without having too much effort to adapt every new application to the clients or, even worse, to the device it will be used on. Simply spoken, the mobile client does nothing else than rendering 2D images to its screen device and sending back interaction commands to the render server using the Java API. More specifically, the mobile client contains the following components: The network component, the user interface and the mobile control component. An architectural overview of the mobile client is illustrated in Figure 3. The network component contains the functionality to connect to the render server, receive the image stream and send out interaction and acknowledge commands to the render server. The send and receive functionality is running in different threads to be able to asynchronously send out commands to the visualization application on the server side. The mobile control part of the client captures all events coming from the mobile device and converts them into network commands. These commands are sent to the server asynchronously. Currently, the set of commands that can be sent from the client to the server is pre-defined. The user interface can be designed independently from the application on the server side. All the client need is an area for 2D image rendering for the 645 remote data. Additional interaction functionality can be integrated using interface elements like menus or buttons. The render server can capture the complete application on the server side and visualize it on the mobile client. In this case it is sufficient to capture mouse and key events for steering the application. Figure 3: Mobile client architecture Each time the mobile client has finished the rendering of a 2D image it sends out a flag to the render server for synchronization. This flag signals the render server to send the next image or pack of multiple images. This is necessary to keep the mobile application synchronized with the application connected with the render server. Since the render server can encode and send images very fast, the bottleneck of the whole system lies on the mobile client side. Most of the mobile clients have either very limited hardware resources or only access to bandwidth-limited networks. Taking these conditions into account the render server should never send more image data then necessary. To prevent the server from producing unnecessary network traffic it waits for the flag from the client to update the image stream. 3.3. Security issues Most of the applications to be used with the remote clients are located behind firewalls. Therefore, it is necessary to establish a communication instance in front of the firewall to be able to establish a secure connection to the render server plug-in of the application in the back of the firewall. For that reason a small Java application was developed which is running on a server in the so-called demilitarized zone (DMZ). This server is running in front of the firewall and will be able to accept most incoming connection and communication attempts, but it is not able to send data through the firewall to the secure area. In the secure area another server is running. An implicit advantage of remote visualization systems in general is the fact that only image data is transmitted. Even if an attacker would hijack the communication between the client and the render server he would only get rendered images from the application on the server side. The raw – and possibly confidential – data is located behind a firewall on a server that can not be accessed. Since the communication protocol uses proprietary commands that can be defined by the user it is very hard to tunnel the firewall using our remote protocol. 4. Discussion This chapter will discuss our approach to stream interactive visualization data from the client to the server. First of all, the remote client gets its data image by image. This means that the server grabs 646 the content and saves every image into a buffer. From the buffer a server thread creates a network command that will be transmitted to the remote client. An obvious alternative that comes to mind is to use a video stream. There are three reasons why we do not use a video stream. The first thing to take into account is the ability of the client to decode data. Decoding of video streams requires CPU power that is a scarce resource on mobile hardware. Especially taking into account that the device does not only have to listen to the video stream but furthermore has to mange interaction commands from the user makes such a solution even less useful. The second issue is the ability of the server to encode video streams in real-time. We have tested several encoders for different video streams like e.g. MJpeg or Mpeg4 [8]. These tests clearly showed that a standard computer will not be able to encode a video stream in real-time from an image chain provided frame-by-frame The best result reached frame rates of around 2 to 5 when using software encoders and the latest standard CPU hardware available. Even the use of multi-core CPUs does not give any advantages to the frame rate that can be provided by the server, because the image compression for a network stream can not be parallelized to be more efficient. The third point to take into account is mainly a synchronization issue and this is the major reason for deciding against video stream based visualization. Video streams with high compression rates typically consist of enclosed sequences of images. Within these sequences, single images are compressed using techniques that differ from format to format. But generally on the decoder side these sequence blocks must be decoded at once because the single images inside the sequence have certain dependencies on their parents. However, the current sequence has to be completely processed by the client before the client can react to the latest interaction. Therefore the user would have the experience that the remote visualization does not react immediately to its interaction requests. Especially when navigating in 3D scenes with fluent animations it makes a huge difference if a camera movement appears in realtime to the user when he started it or if the user has to wait a second until his interaction appears on the remote device. In summary, for our application scenario an on demand single image transmission is the most adequate solution. We have tested a variety of compression formats like jpeg (with different quality settings from 30% up to 100% quality), png, bmp or zip on a dual core processor machine. Here, the jpeg and png compression have proved to be the most useful for the proposed system. Most mobile devices are able to decompress jpeg or png using their hardware resources which makes the decompression procedure very fast on the client side. On the server side png requires more CPU resources than jpeg but none of these two compression methods takes the CPU to its limits when not exceeding image sizes of around 1024x768 pixels. This scalability issue is obviously a minor problem on smartphones or very slim devices with small displays but has to be considered when talking about remote solutions for web environments. Approaches to address especially the support of large solutions are described in chapter 6 in the future work part. The hardware requirements on the server side for the support of a large number of simultaneous users are the biggest scalability challenge. After all, the more independent visualizations the user of such a system wants to provide, the more instances of the application have to run on the server simultaneously and the more hardware performance is required to achieve reasonable frame rates. This is, of course, hardly a new problem, but rather a well-known issue that has been researched intensively by the network and service management community [1]. Depending on the application, the number of clients and the request rate it is possible to find the most cost-effective solutions. One major scenario for our application is to connect multiple remote clients to the same visualization. In that scenario only one application runs on the server side and multiple users are connected to that single server application. Since the render server buffers the captured images, this buffer can be used to broadcast the current image to every connected client, which causes only low additional server load. 647 5. Application Areas Due to the flexibility of the introduced system, the fields of application are numerous. The generic client implementation and the usage of the JME platform allow the client application to be ported to a variety of mobile devices as well as used in a web browser. The simplicity and flexibility of the render server interface allows the integration of the technology into a large variety of applications in the computer graphics area. Figure 4: The application FinMotion and a game client with captured graphics content on a mobile phone. The render server application interface was integrated into three completely different applications: One written in C++ using the QT platform that uses a scatter plot visualization of financial data called FinMotion [23], one gaming application using OpenGL rendering, and a Java application that visualizes cloth simulation in 3D and in real-time [7]. Especially the gaming application and the cloth simulation application make exhaustive use of hardware resources on the server side. The cloth simulation tool, which is already integrated into a CAD software for the garment industry, runs on computers with at least dual core CPUs and the latest graphics hardware. Figure 5: The applications Virtual Try On [7] and FinMotion [23] in the mobile web browser client visualized as remote applications. The cloth simulation application was slightly adapted to enhance the functionality while the scatter plot application is captured as a complete application window. 648 All three applications are connected to our remote visualization system by integrating the render server’s application interface. On the client side, the same mobile client with only small modifications is used for all applications. As the mobile client is written with JME it can be used on a mobile phone as well as in a desktop environment. For the mobile client only the graphics content of the applications was captured, for the web version either the complete application (for FinMotion) or the rendering part of the application (for the cloth simulation). All applications run on the mobile client and can be used interactively. The game client allows a landscape walkthrough and basic interactions with the character, the cloth simulation allows to chose different garment setups that are simulated in real-time on the server side and visualized on the mobile client. In FinMotion only the functionality of browsing through the financial data sets is mapped onto the mobile client for smartphones, while the complete application functionality is available in the web browser version. Again, all different applications written with different toolsets or languages are integrated into our remote visualization system with low effort all using the same render server and all using the same remote client. 5.1 Business Impact General trends in the field of mobile technologies show that bandwidth and coverage of available connection networks were continuously increasing for many years. It can also be anticipated that this trend will continue and accelerate in the coming years with technologies like WiMAX and LTE [1]. Providing a visualization technology that enables the user to remotely access data sources and applications will enable new workflow concepts independent from office locations and times. We see our technology emerging from a flat rate evolution that will provide cost-effective and high-bandwidth access to business resources. The technology itself can provide the necessary graphics functionality of a remote workplace of the future that not only depends on voice and email access but also on the remote availability of visual information. The possibility to use applications from everywhere and to remotely make informed decisions will certainly save cost and time, and will support decision making processes for a variety of businesses and work flows. 6. Conclusion and Future Work This paper introduces a system for remote visualization of graphical content. Our approach enables the integration of the technology in a variety of applications. Thus, with low additional effort application contents can be made available in mobile and web environments. This paper discusses the architecture of the system and its components, the necessary data formats and transmission techniques, and has shown several integration scenarios. Regarding future work, we plan to include a better policy management in the render server to handle interaction requests from different users for the same visualization. Currently, the most recent interaction request is executed. Furthermore, the command set used for interaction between the mobile client and the server application is pre-defined. In the future, we will develop an interaction system that allows the definition of generic commands that will be interpreted later in the application that is connected to the render server on a mobile client. Another planned enhancement is the support for DirectX applications. DirectX provides options for widget capturing that can extend the existing interface and improve the overall performance of the capturing algorithms. Furthermore, a client-side DirectX implementation could improve the performance especially for the web clients. Finally, there are ways to improve the transmission of the image data by splitting the images into parts that are frequently updated and parts that are updated very rarely. 649 Those rarely updated parts of the overall image can be transmitted on demand. Parts of the application that are continuously updated have to be transmitted permanently. Acknowledgment We thank the Heinz-Nixdorf-Stiftung in Paderborn, Germany for funding the research project TRAVO, which formed the basis of this technology. 7. References [1] 3GPP LONG TERM EVOLUTION. http://en.wikipedia.org/wiki/3GPP_Long_Term_Evolution [2] COMMUNICATIONS MAGAZINE, IEEE. Volume 45, Issue 4, April 2007 [3] J. DIEPSTRATEN, M. GORKE, T. ERTL, Remote line rendering for mobile devices, 2004, In IEEE Computer Graphics International (CGI)’04 [4] K. ENGEL, O. SOMMER, AND T. ERTL. A Framework for Interactive Hardware Accelerated Remote 3DVisualization. In Proceedings of EG/IEEE TCVG Symposium on Visualization VisSym ’00, pages 167–177,291, May 2000. [5] JAVA PLATFORM, MICRO EDITION (JAVA ME). http://java.sun.com/javame/index.jsp [6] JAVA TECHNOLOGY. http://java.sun.com/ [7] K. KHAKZAR, R. BLUM, J. KOHLHAMMER, A. FUHRMANN, AN. MAIER, AX. MAIER. Interactive Product Visualization for an In-store Sales Support System for the Clothing Retail. In: HCI International 2007. Proceedings and Posters [DVD-ROM]: With 8 further Associated Conferences. Berlin, Heidelberg, New York : Springer Verlag, 2007, LNCS 4557, pp. 307-316. [8] MOVING PICTURES EXPERTS GROUP. http://www.chiariglione.org/mpeg/ [9] M. NURMINEN. M-Loma – A Mobile 3D City Map. Proceedings of the eleventh international conference on 3D web technology, 2006 [10] MICROSOFT FOUNDATION CLASSES (MFC). http://msdn.microsoft.com/enus/library/d06h2x6e(VS.80).aspx [11] Microsoft Remote Desktop Protocol (RDP). http://www.microsoft.com/technet/prodtechnol/Win2KTS/evaluate/featfunc/rdpfperf.mspx [12] OpenGL ES. http://www.khronos.org/opengles/ [13] K. PULLI, T. AARNIO, K. ROIMELA, J. VAARALA. Designing Graphics Programming Interfaces for Mobile Devices, IEEE Computer Graphics and Applications Volume 25, Nr 6, 2005 [14] K. PULLI, T. AARNIO, T. MIETTINEN , K. ROIMELA, J. VAARALA. Mobile 3D Graphics with OpenGL ES and M3G. San Francisco : Elsevier, Morgan Kaufmann, 2008. (The Morgan Kaufmann Series in Computer Graphics). - ISBN 978-0-12-373727-4 [15] QT. http://trolltech.com/products/qt/ [16] T RICHARDSON, Q STAFFORD-FRASER, K R WOOD, A HOPPER, Virtual network computing. IEEE Internet Computing 1998 [17] B.O. SCHNEIDER, I. M. MARTIN. An Adaptive Framework for 3D Graphics over Networks, Computers & Graphics, Vol. 23, No. 6, 1999. [18] SILICON GRAPHICS, Inc. OpenGL Vizserver 3.0 – Application-Transparent Remote Interactive Visualization and Collaboration, 2003. http://www.sgi.com/. [19] SOETEBIER, H. BIRTHELMER, J. SAHM. Client-Server Infrastructure for Interactive 3-D Multi-User Environments. In: Skala, Vaclav (Ed.) ; European Association for Computer Graphics (Eurographics): Journal of WSCG Volume 12 No. 3, 2004. Proceedings. Plzen : University of West Bohemia, 2004, S. 387-394. [20] SOUMYAJIT DEB, P. J. NARAYANAN. RepVis: A Remote Visualization System for Large Environments. Proceedings of the Workshop on Computer Vision, Graphics and Image Processing (WCVGIP), Feb. 2004, Gwalior, India, pp. 54--57. [21] S. STEGMAIER, M. MAGALL ´ON, AND T. ERTL. A Generic Solution for Hardware-Accelerated Remote Visualization. In Proceedings of EG/IEEE TCVG Symposium on Visualization VisSym ’02, 2002. [22] E. TELER D. LISCHINSKI, Streaming of Complex 3D Scenes for Remote Walkthroughs, Computer Graphics Forum, 2001, pp. 17-25 [23] T. TEKUSOVÁ, J. KOHLHAMMER. Applying Animation to the Visual Analysis of Financial Time-Dependent Data. IEEE International Conference on Information Visualization (IV), 11. 2007, Zurich, Switzerland, pp. 101108 [24] VIRTUAL NETWORK COMPUTING OVERVIEW. http://en.wikipedia.org/wiki/Virtual_Network_Computing 650 KLASSIFIKATION UND IMPLEMENTIERUNG VON LOCATION BASED AIRPORT SERVICES ZUR SITUIERTEN UNTERSTÜTZUNG VON PASSAGIERPROZESSEN AN FLUGHÄFEN Stefan Hausmann1 Kurzfassung Hohe Wachstumsraten im Passagierflugverkehr trotz begrenzter Flughafenkapazitäten und ein großer Verdrängungswettbewerb setzen die Betreiber von Flughäfen unter Druck. Eine Möglichkeit zur Kapazitäts- und Effizienzsteigerung besteht im Einsatz innovativer ortsbezogener Dienste zur Unterstützung von Passagierprozessen. Der vorliegende Beitrag klassifiziert ortsbezogene Dienste im Flughafenkontext, entwirft ein Unterstützungsszenario und stellt ein integriertes Informations- und Kommunikationssystem für die Implementierung solcher Location Based Airport Services vor, das in Kooperation mit dem Siemens Airport Center entwickelt und evaluiert wurde. 1. Motivation Einige Jahre nach den Ereignissen des 11. September 2001 ist der Passagierflugverkehr inzwischen wieder ein stark expandierender Markt. Im Jahr 2007 stiegen die Passagierzahlen international um 7,2% [10, S. 10], und auch für die kommenden 20 Jahre wird ein jährlicher Anstieg um durchschnittlich 4,9% prognostiziert [1, S. 6]. Ebenso wie die Passagierzahlen steigen aber auch die Sicherheits- und Umweltauflagen, denen sich die Luftfahrtbranche stellen muss [10, S. 26ff, S. 32ff]. Während Flugzeughersteller und Fluggesellschaften mit Hilfe sparsamerer Antriebstechnologien und größerer Flugzeuge die Effizienz und Kapazität des Reisens in der Luft erhöhen [6, S. 74, S. 76], ergeben sich für die Beteiligten am Boden neue Probleme: trotz rasant gestiegenem Flug- und Passagieraufkommen stehen die Betreiber kleinerer und größerer Flughäfen untereinander in einem starken Verdrängungswettbewerb um die Gunst der Passagiere und Fluggesellschaften, der sich in einer „Konzentration auf wenige kontinentale ‚Drehkreuze‘“ [3] auswirkt. Diese können ihre Infrastruktur aufgrund politischer und gesetzlicher Rahmenbedingungen aber nicht immer in ausreichendem Maße ausbauen. So operiert z. B. der Frankfurter Flughafen mit inzwischen gut 50 Mio. Passagieren pro Jahr an seiner Kapazitätsgrenze [24, S. 4] und kann diese nur noch durch Prozessoptimierung und innovativen Technologieeinsatz erhöhen. Auch kleinere Flughäfen müssen diesen Weg wählen, um sich bei sinkenden Auslastungen [24, S. 2] gegenüber dem Wettbewerb zu differenzieren. Weil grundsätzliche Änderungen in den Flughafenprozessen erst mittel- bis langfristig erreichbar sind, setzt die Branche auf innovative mobile Dienste, um die bestehenden Prozesse zu optimieren. Einer Studie der Cambridge University zufolge könnten jährlich alleine bis zu 600 Mio. $ eingespart werden [18, S. 1 Lehrstuhl Wirtschaftsinformatik II, Universität Erlangen-Nürnberg 651 41], wenn mobile Geräte mit Ortungs- und Benachrichtigungsfunktionen Verzögerungen in den Passagierabfertigungsprozessen reduzieren würden [15, S. 5]. Der gestiegene Innovationsdruck in der Branche lässt sich bereits heute an einzelnen Lösungen erkennen: So wurde in den letzten Jahren die Selbstbedienungsfähigkeit der Buchungs- und Check-in-Prozesse wesentlich erhöht, und auf immer mehr Flugrouten setzen sich papierlose Ticketing-Verfahren durch [16]. Ein Trend ist dabei die mobile Nutzung: Bis Ende 2010 möchten 82% der Fluggesellschaften mobile Benachrichtigungsdienste einsetzen, und immerhin noch 67% planen die Unterstützung mobiler Check-in-Dienste [16]. Dabei lassen sich noch weitaus größere Nutzeneffekte realisieren, wenn der aktuelle Standort des Nutzers berücksichtigt wird. Das mobile Endgerät des Passagiers wird dann zum zentralen Bestandteil sogenannter Location Based Airport Services (LBAS), also standortbezogener Dienste an Flughäfen, die „unter Zuhilfenahme von positions-, zeit- und personenabhängigen Daten“ [23] nicht nur Kommunikationsfunktionen unterstützen, sondern die Lokalisierung des Passagiers in allen ihn betreffenden Prozessen erlauben und die dabei gewonnenen Ortungsdaten zur situierten Prozessunterstützung einsetzen. Der folgende Beitrag nennt und klassifiziert erstmalig mögliche LBAS anhand verschiedener Kriterien und erörtert anhand eines Szenarios konkrete Unterstützungsmöglichkeiten von LBAS in Bezug auf Passagierprozesse. Darüber hinaus wird ein integriertes System zur Implementierung von LBAS vorgestellt, welches in Kooperation mit dem Siemens Airport Center [14], einem Forschungs- und Demonstrationszentrum für innovative Flughafenlösungen von Siemens, entstanden ist. 2. Location Based Airport Services Im Folgenden werden prozessunterstützende LBAS benannt und klassifiziert. Der Betrachtung liegt ein in Zusammenarbeit mit dem Siemens Airport Center erstelltes Prozesshaus der im Flughafenumfeld relevanten Prozesse zugrunde (vgl. Abbildung 1). 1 – Airport Management Strategy, Leadership and Control 2 – Passenger Management Aviation Processes 2.1 Passenger Processes Non-Aviation Processes 2.2 Baggage Handling 2.3 Travelling 2.4 Hotel & Catering 2.5 Shopping & Added Services 3.1 Facility Management 3.2 Ground Handling 3.3 Airfield Management 3.4 Airline Handling 3.5 Aircraft Handling 3.6 Exception Processes Customer Customer 2.6 Exception Processes 3 – Allocation Management 4 – Cargo Management 4.1 Cargo Delivery 4.2 Cargo Handling 4.3 Cargo Collection 4.4 Exception Processes 5 – Supportprocesses 5.1 Energy 5.2 Communication / IT 5.3 Financial 5.4 Personnel 5.5 Marketing / PR 5.6 Environment 5.7 Maintenance Abbildung 1 - Flughafen-Prozesshaus (Quelle: [8, S. 15]) In diesem zeigen sich vielfältige Anknüpfungspunkte für eine Unterstützung durch LBAS. Viele Prozesse des Allocation- und des Cargo-Managements qualifizieren sich beispielsweise für das Tracking & Tracing von Waren, Personal und Arbeitsmitteln. Im vorliegenden Beitrag liegt der Fokus aber auf dem Passenger Management und dort besonders auf den Passagierprozessen, die den Passagier als externen Faktor in die Transportdienstleistung mit einbeziehen [11, S. 113]. 652 Eine Unterstützung dieser Prozesse durch LBAS erscheint aus folgenden Gründen besonders lohnenswert: - Passagierprozesse sind komplex und unterliegen ständigen Veränderungen. - Die Prozesseffizienz hängt zu einem großen Teil vom Erfahrungshorizont der Passagiere ab. - Prozessfehler haben große Auswirkungen auf nachfolgende und parallel ablaufende Prozesse (z. B. muss das bereits verladene Gepäck nicht rechtzeitig am Gate erschienener Passagiere aufwändig gesucht und wieder ausgeladen werden) LBAS unterstützen diese Passagierprozesse: Zum einen erkennen sie entstehende Informationsbedarfe der Passagiere rechtzeitig und decken sie (z. B.: „An welchen Abfertigungsschalter muss ich mich begeben?“); zum anderen ermitteln sie den Standort des Passagiers und leisten dann situierte Prozessunterstützung (z. B.: „Wo befinde ich mich und wie komme ich zu meinem Gate?“). 2.1. Klassifikation nach Anwendungsbereich Die Einordnung von LBAS in verschiedene Anwendungsbereiche ist das wichtigste Klassifizierungskriterium und fand zweistufig statt. Zunächst wurden in Anlehnung an [17] vier Servicekategorien (Content, Locating, Support und Future Services) definiert und anschließend weiter in Anwendungsbereiche verfeinert (vgl. Abbildung 2). Diesen wurden dann konkrete LBAS zugeordnet. Support Services Content Services Pull Entertainment Mobile Games Matchmaking Buddy Finder Communication Communities Instant Messaging Information Infotainment Mobile Yellow Pages Travel Planer Travel & Tourist Guides Wiki Management Customer Relationship Management Facility Management Fleet Management Marketing Security Yield Management Emergency Automotive Assistance Emergency Call Push Commerce Advertisement Couponing Offers Shopping Guides Notification Events Flight Specific Notifications General Alerts / Notifications Theft Alerts Ambient Intelligence Access Control Environmental Customization Locating Services Self Others Navigation Car Park Guidance Directions Indoor Routing Traffic Management Billing Location Sensitive Billing Route Tolling Usage Sensitive Billing Tracking People Tracking Vehicle Tracking Resource Tracking Future Services Augmented Reality Abbildung 2 – LBAS-Klassifikation nach Anwendungsbereich Schwerpunkt der Content Services ist die Übertragung von (ortsbezogenen) Inhalten an mobile Endgeräte. Benachrichtigungen oder multimediale Informationen werden entweder beim Eintreten bestimmter Ereignisse (z. B. Betreten von Zonen, Flugplanänderungen) übertragen (Push), oder der Passagier ruft selbst Inhalte (z. B. Verzeichnisse, Informationsseiten) ab (Pull). Daneben zählen auch Werbedienste, Unterhaltungs- sowie Kommunikationsanwendungen zu dieser Kategorie. Locating Services erlauben dem Nutzer, sich selbst mit Hilfe seines mobilen Endgeräts zu orten und zu bestimmten Zielpunkten zu navigieren, außerdem ermöglichen sie die Personen- und Objektortung durch Tracking der mobilen Endgeräte aus der Ferne. Support Services kombinieren Ortungsund Kommunikationsfunktionen zu Mehrwertdiensten mit Unterstützungscharakter. Unter anderem können so LBAS in den Bereichen Sicherheit, Notfalldienste, ortsbezogene Abrechnung sowie Managementfunktionen realisiert werden. Future Services repräsentieren zukünftige ortsbezogene Dienste, die sich neuartiger Benutzerschnittstellen bedienen werden. Denkbar ist hier beispielswei- 653 se eine Form von Augmented Reality [20], die reale Sinneswahrnehmungen durch ortsbezogene Zusatzinformationen überlagert. 2.2. Klassifikation nach unterstützten Prozessen In einem nächsten Schritt wurden die LBAS-Anwendungsbereiche den bereits vorgestellten Flughafenprozessen (vgl. Abbildung 1) zugeordnet. Ein Großteil der möglichen LBAS lässt sich dabei den Prozessen des Passenger Management zuordnen. Beispielsweise können die zentralen Passagierprozesse durch LBAS zur Information, Benachrichtigung und Navigation des Passagiers unterstützt werden. Wie eine Gestaltung dieser Prozesse mit LBAS-Unterstützung aussieht, wird im Abschnitt 3 konkretisiert. LBAS mit Unterhaltungs- und Werbeinhalten eignen sich hingegen eher für Non-Aviation-Prozesse. 2.3. Klassifikation nach beteiligten Akteuren Im Rahmen des Forschungsprojekts wurden die einzelnen LBAS-Anwendungsbereiche den am Flughafen aktiven Akteuren zugeordnet. Aus dem Prozesshaus in Abbildung 1 sowie der detaillierten Prozessanalyse in [8] können folgende Akteure des Flughafenbetriebs identifiziert werden: Passagiere2, Flughafenbetreiber, Fluggesellschaften, externe Dienstleister sowie der am Flughafen ansässige Einzelhandel. In Bezug auf LBAS nehmen diese Akteure eine oder mehrere der folgenden Rollen ein: - Servicebetreiber stellen die technische Infrastruktur für den Betrieb von LBAS bereit. - Serviceanbieter bieten LBAS mit eigenen Inhalten an. - Servicekonsumenten nutzen die angebotenen LBAS. Der Flughafenbetreiber verfügt flughafenweit über eine eigene IT-Infrastruktur und kann daher als einziger Akteur die für LBAS nötige Technologie betreiben. Als Serviceanbieter stellt er selbst LBAS mit flughafenspezifischen Inhalten zur Verfügung und ist als Servicekonsument daran interessiert, aggregierte Informationen (z. B. Prozessdurchlaufzeiten, Passagierlaufwege) zu erhalten, um seine Infrastruktur zu optimieren. Die Fluggesellschaften streben eine möglichst kurze Aufenthaltszeit ihrer Flugzeuge am Boden an [4, S. 5] und sind deswegen darauf angewiesen, dass Informationsbedarfe der Passagiere möglichst schnell erfüllt und somit Verzögerungen minimiert werden; hierzu bieten sie LBAS mit flugspezifischen Inhalten an. Als Servicekonsumenten erhalten sie Informationen über verspätete Passagiere und können mit diesen kommunizieren. Externe Dienstleister übernehmen an Flughäfen u. a. die logistisch aufwändige Gepäckabwicklung [12] und nutzen hierzu als Servicekonsumenten LBAS, um Gepäckstücke oder die zugehörigen Passagiere im Flughafen zu orten, falls es zu Ausnahmen in den Passagier-/Gepäckprozessen kommt. Ziel des am Flughafen ansässigen Einzelhandels ist es, den Umsatz mit Waren oder Dienstleistungen zu maximieren. Hierzu können die Geschäfte als Serviceanbieter Informationen über ihr Angebot unterbreiten sowie LBAS etwa zur Kundenbindung oder für ortsbezogene Abrechnungen einsetzen. Der Passagier als Servicekonsument schließlich erhält auf ihn zugeschnittene Informationen und durchläuft die Passagierprozesse mit Hilfe von LBAS schneller und zielgerichteter. 2.4. Klassifikation nach sonstigen Kriterien LBAS wurden im Rahmen des Forschungsprojekts nach vielen weiteren Kriterien klassifiziert, beispielsweise nach Einführungs- und Betriebskosten, Erlöspotenzialen, möglichen Abrechnungsmodellen (keine Abrechnung, Werbefinanzierung, nutzungsbasierte Abrechnung, Subventionierung), vorausgesetzten Datenquellen, Alleinstellungsmerkmalen oder ihrem Innovationsgrad. Zusammen mit den ermittelten Prozessen und Akteuren ergaben sich dabei für alle möglichen LBAS detaillier2 Auch andere Flughafenbesucher gehören zur Zielgruppe von LBAS, werden im Folgenden aber nicht mehr gesondert erwähnt 654 te Datenblätter, die als Entscheidungsgrundlage für die Implementierung bestimmter LBAS sowie des LBAS-Systems selbst dienten. 2.5. Nutzen Neben den Klassifizierungskriterien sind für die Umsetzung von LBAS in der Flughafenpraxis insbesondere die entstehenden Nutzeneffekte relevant. Neben Kosteneinsparungen und effizienterer Prozessabwicklung [15, S. 14] ergeben sich für die Beteiligten unter anderem die in Tabelle 1 genannten Vorteile. Akteur Flughafenbetreiber Fluggesellschaften Externe Dienstleister Einzelhandel Passagiere Tabelle 1 - Nutzeneffekte von LBAS Nutzen - Engere Kundenbindung - Neue Erlöspotenziale, insbesondere bei Non-Aviation-Prozessen - Differenzierung im Wettbewerb um Passagiere und Fluggesellschaften - Planungshilfe durch Analyse von historischen Ortungsdaten - Höhere Kundenzufriedenheit - Optimierung der Abfertigung, kürzere Turn-Around-Zeiten - Optimierung der Abfertigung - Verbesserung der Personal-, Gepäck- und Arbeitsmateriallogistik - Engere Kundenbindung, neue Marketingformen - Verbesserte Marktforschung - Kürzere, unkomplizierte Prozessdurchläufe - Verbesserte Orientierung sowie erhöhtes Sicherheitsgefühl 2.6. Kosten Auch die bei einer möglichen Umsetzung der LBAS in der Praxis anfallenden Kosten wurden detaillierter betrachtet. Beispielhaft zu nennen sind hier Softwarelizenzkosten, z. B. für das verwendete WLAN-Ortungssystem (vgl. Abschnitt 4.4), Entwicklungs- und Einrichtungskosten sowie Hardware- und Wartungskosten. Diese würden in der Praxis größtenteils auf die Serviceanbieter umgelegt, die daneben auch noch die Aufwendungen für die Erstellung und Pflege der LBAS-Inhalte sowie für die Implementierung von Schnittstellen zu Drittsystemen tragen müssten. Im Gegenzug können Sie mit innovativen LBAS neue Erlösquellen erschließen, beispielsweise über kostenpflichtige ortsbasierte Informations- und Unterhaltungsdienste sowie kontextabhängige Werbemöglichkeiten. Neben den Kosten können mit der Einführung von LBAS auch weitere Nachteile einhergehen, auf die im Abschnitt 5 näher eingegangen wird. 3. Szenario einer Passagierprozessunterstützung durch LBAS Abbildung 3 zeigt den typischen Passagierprozessablauf (Passenger Processes) als hauptsächlichen Bestandteil des Prozessbereichs Passenger Management [8, S. 16]. Grundlage sind die von der International Air Transport Association (IATA) definierten Prozessabläufe [9]. Eine Prozessunterstützung durch LBAS verfolgt hier das Ziel, die Prozesseinhaltung unter Berücksichtigung von Zeitrestriktionen zu gewährleisten, zum anderen soll der Passagier bei weiteren Prozessen (NonAviation Processes) [8, S. 17], also z. B. bei Unterhaltungs-, Konsum- und Gastronomieprozessen unterstützt werden. Drittens müssen LBAS auch die Behandlung von Ausnahmeprozessen (Exception Processes) [8, S.18] erleichtern. Dies betrifft beispielsweise Flugverspätungen, Gatewechsel oder Gepäckverluste. Abbildung 3 – Passagierprozesse (Quelle: [8, S. 16]) Als Anforderungskatalog für das zu entwickelnde LBAS-System wurde das folgende Szenario definiert: Beim Erreichen des Flughafengeländes (Ground Access) bekommt der Passagier die Mög- 655 lichkeit, sich mit seinem mobilen Gerät an das System anzumelden. Dies kann entweder anonym oder mit Bezug auf ein Kundenkonto geschehen. Im letzteren Fall verfügt das System dann über einen Kontext aus Benutzerdaten und –präferenzen zur Individualisierung der später angebotenen LBAS. Zum späteren Wiederauffinden speichert das System die Position des KFZ des Passagiers und gibt ihm dann eine erste Orientierung über das Flughafengelände. Am Ende jedes Teilprozesses erhält der Benutzer eine Übersicht über die möglichen Folgeschritte und ggf. über mögliche Zeitprobleme. Den Check-in kann der Nutzer direkt über sein mobiles Endgerät vornehmen. Er wird dann zum Gepäckschalter navigiert, falls er Reisegepäck aufgeben möchte. Für den Fall, dass er einen klassischen Check-in-Schalter aufsuchen möchte, weist ihm das Gerät den Weg dorthin. Nach dem Check-in verfügt das System zusätzlich über einen Kontext aus Buchungs- und aktuellen Flugdaten und kann den Passagier informieren, falls es Neuigkeiten zu seinem Flug gibt. Im Teilprozess Security-Run erhält der Nutzer aktuelle Informationen über Standort, Auslastung und optimalen Zeitpunkt der Sicherheitskontrollen. Er wird außerdem benachrichtigt, falls es Probleme mit seinem Gepäck im parallel ablaufenden Gepäckabfertigungsprozess gibt. Nach dem Security-Run betritt der Passagier den Transitbereich und wird bei optionalen Nebenprozessen durch verschiedene LBAS unterstützt. Beispielsweise ermöglicht ein elektronisches Konto, Einkaufs- und Verpflegungseinrichtungen bargeldlos zu benutzen. Außerdem kann die Nutzung spezieller Bereiche (z. B. VIP-Lounge) je nach Buchungsklasse, Nutzungsdauer und Aufenthaltsort automatisch abgerechnet werden. Mit Hilfe seines mobilen Endgeräts kann der Passagier verschiedene Informationsdienste abonnieren, indem er den 2D-Barcode [21] eines physischen Informationsträgers (Plakat, Display o.ä.) erfasst. Er bekommt ab diesem Zeitpunkt die damit verbundenen Informationen mobil und aktuell angezeigt. Während des gesamten Prozessablaufs wird der Passagier über mögliche Ausnahmeprozesse informiert. Verspätet sich sein Flug, erhält er Informationen und ggf. einen Voucher zum Bezug von Verpflegung auf sein Endgerät. Fällt ein Flug gänzlich aus, erhält er alternative Flüge und wird ggf. erneut zum Check-in navigiert. Ändert sich das Gate, wird er rechtzeitig informiert und erhält Navigationshilfe zum neuen Gate. Auch der Prozess des Boarding kann durch LBAS unterstützt werden. Zum einen können LBAS dazu beitragen, dass alle Passagiere pünktlich zum Boardingzeitpunkt am Gate sind, zum anderen können deren mobile Endgeräte automatisch vor dem Betreten des Flugzeugs deaktiviert werden. Nach dem Flug erfolgt wieder eine Anmeldung an das LBAS-System des Zielflughafens. Anschließend wird der Nutzer im Rahmen des Baggage Reclaim zum richtigen Gepäckband navigiert und erhält Informationen über den Status seines Gepäcks sowie eventuell aufgetretene Probleme. Beim Verlassen des Flughafengebäudes (Ground Departure) werden dem Passagier Weiterreisemöglichkeiten sowie Buchungsfunktionen (Taxiruf, Bezug von ÖPNV-Tickets, Hotelbuchung) angeboten. Mit Hilfe der Navigationsfunktion kann er sich auch zu seinem geparkten KFZ leiten lassen. Parallel zum Ablauf des Passagierprozess erhalten auch die anderen Akteure Unterstützung durch das System. So kann z. B. Personal zu Störungsquellen navigiert werden, der Flughafenbetreiber sowie externe Dienstleister erhalten Laufweganalysen sowie aktuelle Auslastungsübersichten, um ihre Kapazitäten anpassen zu können, und die Fluggesellschaften erhalten Ortungs- und Kommunikationsmöglichkeiten für Passagiere, die den Flugabfertigungsprozess verzögern. 4. Integriertes Ortungs- und Kommunikationssystem für LBAS 4.1. Rahmenbedingungen Um einen hohen Akzeptanz- und damit Nutzungsgrad zu erzielen, muss ein LBAS-System möglichst viele der heterogenen Passagier-Endgeräte unterstützen. Weltweit verfügen bereits über 90% aller Fluggäste über ein Mobiltelefon [15, S. 3]; nahezu jedes neu verkaufte verfügt dabei neben GSM über mindestens eine Nahfunktechnologie wie z. B. Bluetooth [2]. Im geschäftlichen Bereich dominieren bei den Passagieren daneben auch Notebooks, die üblicherweise eher mit WLAN ausgestattet sind. 656 Darüber hinaus sollte sich ein LBAS-System auch in eine ggf. bestehende WLAN-Infrastruktur des Flughafens integrieren lassen, also diese zur Kommunikation und Ortung nutzen können, um die Anfangsinvestitionen in die für LBAS erforderliche Hardware-Infrastruktur zu minimieren. 4.2. Ortungs- und Kommunikationstechnologien Für die Lokalisierung von Endgeräten bedient sich das entwickelte LBAS-System eines innovativen, hybriden Ortungskonzepts: zum einen wird eine flughafenweite, relativ präzise Ortung durch Auswertung der Signalstärken von WLAN-Accesspoints durch die mobilen Endgeräte selbst durchgeführt (Selbstortung), zum anderen kann der Aufenthaltsort von Bluetooth-fähigen Endgeräten zellbasiert über verteilt installierte Bluetooth-Accesspoints registriert werden (Fremdortung). Für die WLAN-Ortung wird auf eine Realtime-Locating-System-(RTLS)-Lösung der Firma Ekahau zurückgegriffen [7]. Diese stellte sich in einem Vergleich von fünf kommerziellen und quelloffenen Systemen zur WLAN-Ortung zwar als kostenintensive, dafür aber als beste Lösung hinsichtlich der Kriterien Ortungsgenauigkeit, Prozessor- und Netzwerkauslastung sowie Einrichtungsaufwand herausgestellt. Sie setzt das sog. Radio-Mapping-Verfahren um, bei dem in einem Kalibrierungsdurchlauf zunächst die charakteristische Signalstärkenverteilung (Fingerprint) aller empfangenen WLAN-Accesspoints an jedem Punkt des Areals erfasst wird. Im Produktivbetrieb werden dann die vom WLAN-Gerät gemessenen Signalstärken ständig mit den in einer Datenbank hinterlegten Fingerprints nach dem Weighted-k-Nearest-Neighbours-Verfahren verglichen und die zutreffendste Ortsangabe ermittelt [5]. Für die Bluetooth-Ortung wurde eine eigene Lösung entwickelt, bei der Bluetooth-Accesspoints über einen sog. Inquiry-Vorgang alle Bluetooth-Endgeräte in ihrem Empfangsbereich ermitteln. Zusätzlich werden durch einen kurzen Verbindungsaufbau mit den mobilen Endgeräten deren Signalstärken ausgewertet, was die erzielbare Genauigkeit weiter erhöht. Für die drahtlose Kommunikation mit den Endgeräten ergänzen sich beide Technologien optimal. Bluetooth ermöglicht durch vordefinierte Endgeräteprofile das Versenden von Nachrichten an Geräte ohne spezielle Client-Software, WLAN erlaubt klassische TCP/IP-Kommunikation, benötigt dafür jedoch entsprechende Clientprogramme oder Webbrowser auf den Endgeräten. Tabelle 2 vergleicht WLAN- und Bluetooth hinsichtlich ihrer Eignung für Ortung und Kommunikation. Es zeigt sich, dass beide Technologien einander komplementär ergänzen und sich somit für einen hybriden Einsatz empfehlen. Außerdem erhöht sich somit der Anteil an Endgeräten, der über mindestens eine der beiden Technologien in das LBAS-System eingebunden werden kann. Tabelle 2 – Vor- und Nachteile von WLAN und Bluetooth hinsichtlich Ortung und Kommunikation Kriterium WLAN Bluetooth Ortungsverfahren freie Ortung über Sigzellbasierte Ortung nalstärken Netzabdeckung flächendeckend einzelne Zellen Verbindungsabbruch bei AP-Wechsel nein ja Ortungsgenauigkeit 1 – 10 Meter (flächen2 – 10 Meter je nach Bluetooth-Klasse deckend) (in einer Zelle) Vorherige Kalibrierung des Areals erforderlich ja nein Clientsoftware zur Ortung des mobilen Endgeja nein räts erforderlich 4.3. Prozessunterstützung Für die Implementierung des LBAS-Unterstützungsszenarios ist zunächst die Definition logischer Zonen innerhalb des Flughafenareals (Check-in, Security-Kontrolle, VIP-Lounge, Gates usw.) erforderlich. Während diese mit den durch die Bluetooth-Accesspoints aufgespannten Empfangsbereichen identisch sind, müssen die Zonen bei der WLAN-Ortung zunächst auf der kalibrierten Signalstärkenkarte des Flughafenareals definiert werden. 657 Um die spätere Entwicklung der konkreten LBAS zu erleichtern, wurden verschiedene generische Unterstützungsmodule implementiert (vgl. Tabelle 3), die später von den einzelnen LBAS in einer bestimmten zeitlichen Reihenfolge oder in Abhängigkeit des Aufenthaltsorts des Nutzers aufgerufen werden. Der aktuelle Prozessschritt jedes Passagiers wird dabei über die Zuordnung seiner Position zu einer logischen Zone ermittelt und zur Gestaltung der Dialogführung herangezogen. Unterstützungsmodul Benutzerkonto Nachricht/Dialog Information Rechnung Navigation Tabelle 3 – Generische LBAS-Unterstützungsmodule Funktion An- und Abmelden an das System, Stammdatenverwaltung, Einstellen persönlicher Präferenzen zu Benachrichtigungen und Privatsphäre Übermittlung und Anzeigen von Benachrichtigungen, Dialogführung, Auswertung von Benutzereingaben Anzeige umfangreicher, auch grafischer Informationen (z. B. Fahrpläne, Lagepläne) benutzerspezifisches Zahlungskonto, Zahlungsmittel, Gutschriften- und Rechnungsverwaltung Kartenansicht mit aktuellem Aufenthalts- und Zielort sowie zusätzlichen Informationen (z. B. Points of Interest (POI), Standort von Mitarbeitern) 4.4. System-Architektur Abbildung 4 illustriert die Softwarearchitektur des implementierten LBAS-Systems. Als Funkschnittstelle zu den mobilen Endgeräten kommen kostengünstige Embedded-Router zum Einsatz, die Standard-WLAN-Accesspoint-Funktionalität besitzen und über Firmware- und HardwareErgänzungen um Bluetooth-Accesspoint-Funktionalität erweitert wurden. Auf diesen drahtlosen Zugangspunkten bildet die Accesspoints-Komponente den wichtigsten Bestandteil der Kommunikations- und Ortungsfunktionalität. Dabei handelt es sich um eine modifizierte Firmware auf Basis des quelloffenen Linux-Router-Betriebssystems OpenWRT [13], die drahtlose Endgeräte per WLAN authentifiziert sowie in ein TCP/IP-Netzwerk einbindet und die um zwei zusätzliche Funktionen erweitert wurde: zum einen versendet sie LBAS-Inhalte an BluetoothEndgeräte via OBEX-Protokoll [22], zum anderen scannt sie laufend die Bluetooth-Device-IDs aller in der Nähe befindlichen Bluetooth-Geräte. Diese schickt sie zusammen mit den WLANSignalstärkeinformationen, die auf den WLAN-Endgeräten über eine spezielle Client-Software ermittelt werden, an die Positioning Engine, die alle Ortungsdaten aggregiert, für die Nutzung durch die LBAS aufbereitet und mit Zeitstempeln archiviert. Die Berechnung der WLANOrtungsdaten erfolgt dabei durch Einbindung der Ekahau-RTLS-Engine per Webservice-Aufruf. Configuration Client Mobile Client Browser Application Windows Mobile Device e.g. J2ME Client Integration of different positioning systems & calculation of client locations Positioning Core (Historical database of client locations) Sockets Web-Services Positioning Engine Positioning Engine HTTP Web-Services Web Services Application Software Mapping of loc. based and user specific data / Frontend of Notification- & LBAS-System Conten Management Core (Database of user profiles & service offering) WLAN-Wrapper Ekahau Sockets Mobile Devices Radius Access Points Radius LAN-Access Authentification Bluetooth-Wrapper LAN Infrastructure Content Engine Interface LAN-Access (Intranet / Internet) Bluetooth (BT) Browser-based (e.g. J2ME) (BT) Wireless LAN (WLAN) Windows Mobile (WLAN / BT) Abbildung 4 – Softwarearchitektur des LBAS-Systems Auf einem separaten Server läuft die Content Engine. Diese führt die eigentlichen LBAS aus und stellt ihnen neben den erhaltenen Ortungsdaten auch weitere Inhalte von externen Systemen (Bu658 chungssysteme, Flight-Information-Systeme usw.) sowie eine Benutzerkontoverwaltung zur Verfügung. Die von den LBAS erstellten Inhalte werden dann entweder per WLAN oder Bluetooth an die Endgeräte distribuiert. Exemplarisch wurde für Windows-Mobile-basierte Endgeräte ein eigener Mobile Client entwickelt, der die Inhalte gerätespezifisch aufbereitet, präsentiert und gleichzeitig den Windows-MobileClient der Ekahau-Lösung anbindet. Mobile Geräte mit anderen Betriebssystemen können über einen Standard-Internetbrowser auf die LBAS-Inhalte zugreifen. Dabei wird die gesamte Dialogführung mit dem Passagier komfortabel und optisch ansprechend per AJAX [19] abgewickelt. Ein Configuration Client erlaubt die Verwaltung der Accesspoints und der angemeldeten Endgeräte sowie die Auswertung der archivierten Ortungsdaten, um den Servicekonsumenten z. B. Laufwege der Nutzer sowie Auslastungsübersichten der einzelnen Zonen zur Verfügung zu stellen. 5. Fazit und Ausblick Das LBAS-System wurde sowohl in einer Labor-Umgebung als auch beim Kooperationspartner Siemens Airport Center in einer realistisch nachgestellten Flughafenumgebung getestet. Der dabei nötige Installationsaufwand konnte durch das Verwenden einer Standard-WLAN-Infrastruktur begrenzt werden. In einem Flughafen-Praxisszenario müssen eventuell vorhandene WLANAccesspoints gegen Geräte mit Unterstützung für Firmware-Erweiterungen sowie Bluetooth ausgetauscht werden sowie ggf. zusätzliche Accesspoints installiert werden, um die für eine WLANOrtung nötige Mindestdichte an Accesspoints zu gewährleisten. Im Prototypenbetrieb konnten nach einer einmaligen Kalibrierung des Areals mit Hilfe der eingebundenen WLAN-Ortungssoftware und der Definition logischer Zonen die einzelnen LBAS für das System implementiert werden. Durch die Wiederverwendbarkeit der generischen Unterstützungsmodule beschränkte sich der Entwicklungsaufwand dabei hauptsächlich auf die Erstellung der Inhalte sowie die Gestaltung der Dialogführung und die Verknüpfung mit den logischen Zonen. Die erzielte Ortungsgenauigkeit hing bei WLAN stark von der Kalibrierungsqualität und natürlich von der verwendeten Ekahau-Software ab. Bei günstig positionierten WLAN-Accesspoints konnte jedoch eine durchschnittliche Positionierungsgenauigkeit von 2 – 5 Metern in der nachgestellten Flughafenumgebung des Siemens Airport Centers erzielt werden. Die zellenbasierte BluetoothOrtung funktionierte, sofern sich die von den Accesspoints aufgespannten BluetoothEmpfangsbereiche nicht überschnitten, einwandfrei und ermöglichte eine eindeutige Zonenzuordnung der Endgeräte. Ein Problem stellte hier allerdings die zeitliche Verzögerung dar, die durch den langsamen Inquiry-Vorgang auf den Bluetooth-Accesspoints verursacht wird. Im Mittel benötigte es gut 10 Sekunden, bis das Betreten einer Bluetooth-Zelle vom System erkannt wurde. Über die technischen Problemstellungen hinaus ergeben sich durch den Einsatz von LBASSystemen an Flughäfen neue Herausforderungen. Einerseits kann die Lokalisierbarkeit von Endgeräten bei Passagieren den Eindruck einer Überwachung auslösen. Diesem Eindruck muss mit einer transparenten Kommunikationspolitik entgegengewirkt werden, die klarmacht, welche technischen Voraussetzungen für die Ortung bestehen und wie diese durch den Passagier beeinflusst werden können. Anderseits darf die Verknüpfung von Ortungs- und Personendaten nur auf freiwilliger Basis geschehen. Widerspricht ein Passagier dieser Verknüpfung, erfährt er dann zwar noch ortsbezogene, aber eben keine personen- oder flugspezifische Prozessunterstützung mehr. Zusätzlich muss darauf geachtet werden, dass die Passagiere selbst Menge und Art der dargebotenen Informationen bestimmen können, um nicht gestört oder überfordert zu werden. Das vorliegende System implementiert selbst schon einige wichtige Prozessunterstützungsfunktionen und erlaubt die einfache Entwicklung weiterer LBAS auf einer Vielzahl von Endgeräten, die allerdings eine der Drahtlostechnologien WLAN oder Bluetooth unterstützen müssen. Es muss nun aus der Demonstrationsumgebung des Siemens Airport Centers heraus in eine echte Flughafenumgebung portiert werden, um im Rahmen eines detaillierten Business Case die genauen Kosten und Ertragsmöglichkeiten sowie die Ausgestaltung der einzelnen LBAS zu evaluieren. Nicht zuletzt hat 659 das System in der Praxis zu beweisen, dass es die erhoffte Effizienzsteigerung in den Flughafenprozessen bringt und von ausreichend vielen Passagieren akzeptiert wird. 6. Literatur [1] Airbus (2007): Global Market Forecast 2007 – 2026. http://www.airbus.com/store/mm_repository/pdf/att00011423/media_object_file_GMF_2007.pdf, Abruf am 2008-07-28 [2] Bluetooth Special Interest Group (2005): Bluetooth Shipments Climb to Five Million Per Week. http://www.bluetooth.com/Bluetooth/Press/SIG/Bluetooth_Shipments_Climb_to_Five_Million_Per_Week.htm, Abruf am 2008-0728 [3] Boston Consulting Group, The (2004): Flughäfen vor Verdrängungswettbewerb. http://www.bcg.com/publications/files/BCG_Global_Airports_21._April_2004.pdf, Abruf am 2008-07-28 [4] Bowen, Brent D.; Headley, Dean E. (2005): Airline Quality Rating 2005. Forschungsbericht, University of Nebraska, Wichita State University, Omaha [5] Deasy, T. P.; Scanlon, W. G. (2007): Simulation or Measurement: The Effect of Radio Map Creation on Indoor WLAN-Based Localisation Accuracy, in: Springer Verlag: Wireless Personal Communications Number 4, S. 563-573 [6] EADS (2004): Die A380 erwacht zum Leben, in: EADS: Steigflug - Das Unternehmen im Jahr 2004. http://www.reports.eads.net/2004/ar_2004/de/downloads/Book1/das_unternehmen_im_jahr_2004.pdf, Abruf am 2008-07-28 [7] Ekahau: Ekahau RTLS. http://www.ekahau.com/?id=4200, Abruf am 2008-07-28 [8] Ferstl, J. (2007): Integration von fluggastrelevanten Prozessen in ein zentrales Airport Operation Concept – Analyse, Bewertung und Implikationen. Diplomarbeit, Universität Erlangen-Nürnberg [9] International Air Transport Association (2005): SPT – Ideal Process Flow V1.0. 01.12.2005. http://www.iata.org/NR/rdonlyres/3A7B777C-3508-4B0E-86AB-EC39D834475D/0/IPF_V10_Nov2005.pdf, Abruf am 2008-07-28 [10] International Air Transport Association (2008): Annual Report 2008. http://www.iata.org/NR/rdonlyres/84158349-7772-489286AB-836DE73E0A52/0/IATAAnnualReport2008.pdf, Abruf am 2008-07-28 [11] Mertens, P.; Bodendorf, F. (2004): Grundzüge der Wirtschaftsinformatik. Springer Verlag, Berlin/Heidelberg/New York [12] o.V. (1996): Council Directive 96/67/EC of 15 October 1996 on access to the groundhandling market at Community airports. EU Richtlinie, Ministerrat der Europäischen Union, Brüssel [13] o.V.: OpenWrt. http://openwrt.org/, Abruf am 2008-07-28 [14] Siemens AG: Siemens Airport Center. http://www.industry.siemens.com/airports/en/SAC/en/default.htm, Abruf am 2008-0728 [15] SITA (2008): How Mobile Technology Will Enhance Passenger Travel. http://www.sita.com/NR/rdonlyres/6956EFEA-EC3E4851-B3CB-F8495C35BDD3/0/PassengerMobilityNewFrontiersPaperMay08.pdf, Abruf am 2008-07-28 [16] SITA (2008): SITA research shows mobile phones have potential to save the industry $600 M on flight delays. http://www.sita.aero/News_Centre/Press_releases/Press_releases2008/SITA_research_shows_mobile_phones_have_potential_to_save_the_industry_600_M_on_flight_delays.htm, Abruf am 200807-28 [17] Steiniger, S.; Neun, M.; Edwardes, A. (2006): Foundations of Location Based Services. http://www.geo.unizh.ch/publications/cartouche/lbs_lecturenotes_steinigeretal2006.pdf, Abruf am 2008-07-28 [18] Thorne, Alan; Prodonof, Victor; McFarlane, Duncan (2008): Aircraft Turnaround In the Auto-ID Enabled Environment. AutoID Lab, University of Cambridge, United Kingdom [19] Wikipedia: Ajax (Programmierung). http://de.wikipedia.org/wiki/Ajax_%28Programmierung%29, Abruf am 2008-07-28 [20] Wikipedia: Augmented Reality. http://en.wikipedia.org/wiki/Augmented_reality, Abruf am 2008-07-28 [21] Wikipedia: DataMatrix. http://de.wikipedia.org/wiki/DataMatrix, Abruf am 2008-07-28 [22] Wikipedia: OBEX. http://de.wikipedia.org/wiki/IrOBEX, Abruf am 2008-07-28 [23] Wikipedia: Standortbezogene Dienste. http://de.wikipedia.org/wiki/Standortbezogene_Dienste, Abruf am 2008-07-28 [24] Wilken, D.; Focke, H. (2003): Zur Nutzungsintensität der Flughafenkapazitäten in Deutschland: Weiter zunehmende Konzentration oder eher gleichmäßige Verteilung der Nachfrage nach Flughafenkapazität?, in: Universität Dresden: Mobilität und Verkehrsmanagement in einer vernetzten Welt, CR-ROM, 19. Verkehrswissenschaftliche Tage Dresden 660 SEMANTISCHE INFORMATIONSSYSTEME Semantische Modellierung und ihre automatische Verarbeitung findet verstärkt Eingang in das betriebliche Informationsmanagement. In Informationssystemen ergibt sich der Mehrwert semantischer Technologien primär aus der Integration heterogener Informationen und der Steigerung der Informationsqualität. Im Wissensmanagement und in der Gestaltung und Bearbeitung wissensintensiver Prozesse unterstützen semantische Technologien die kontextspezifische Strukturierung von Wissens- und Informationsbeständen. Abfrage- und Präsentationsmechanismen werten die Semantik von Informationen und Metadaten aus und erhöhen so den Gebrauchswert vorhandener Informationen. Von zentraler Bedeutung für diesen Track ist die wirtschaftliche Nutzung semantischer Ansätze in Geschäftsanwendungen: Von der Beurteilung, von der Analyse des Aufwands für die Entwicklung und Pflege der semantischen Modelle, über die Evaluierung, welche Unternehmens- und Wissensziele durch semantische Technologien unterstützt werden, bis zum Einsatz semantischer Technologien für geschäftliche Anwendungen. Leitungsgremium: Dieter Fensel, Universität Innsbruck Knut Hinkelmann, Fachhochschule Nordwestschweiz Rudi Studer, Universität Karlsruhe (TH) & FZI Forschungszentrum Informatik (Federführender) Programmkomitee: Andreas Abecker, FZI, Karlsruhe Jürgen Angele, Ontoprise GmbH, Karlsruhe Christian Fillies, Semtation GmbH, Deutschland Barbara Re, University of Camerino Ulrich Reimer, University of Applied Sciences St. Gallen Steffen Staab, Universität Koblenz York Sure, SAP Research Rainer Telesko, Fachhochschule Nordwestschweiz Holger Wache, Fachhochschule Nordwestschweiz Robert Woitsch, BOC, Österreich A MODEL-DRIVEN APPROACH TO ENABLE ACCESS CONTROL FOR ONTOLOGIES Willy Chen, Heiner Stuckenschmidt1 Abstract Industrial applications of semantic technologies - in particular ontologies - include the integration of heterogeneous information sources and the management of information resources and services. Currently, the adoption of these technologies in large-scaled applications within enterprises is slowed down by their failure to meet some basic requirements of commercial applications. One of those is the support of sophisticated security policies for protecting the knowledge contained in ontologies and their instances from unauthorized use. In this paper, we propose a model-driven approach to enable access control for lightweight ontologies based on a role-based security model and well-known standard technologies. 1 Motivation Ontologies and Industrial Applications Semantic technologies originally developed for knowledge representation and reasoning on the web are gaining attention from industry as an adequate means for solving complex information management tasks. A constantly growing number of companies that offer professional services or tools in this area reflect this trend [4]. Typical applications of ontologies include knowledge and skill management [20] as well as web service and business process management [8]. Studies [10] and successful projects [21] emphasize the relevance of these technologies in the area of product lifecycle management (PLM), in particular in the automotive sector. Their application in largescaled industrial use cases (e.g., [2]) quickly shows that theoretical issues like expressiveness and decidability are less a limiting factor for their uptake in industry than non-functional aspects. In commercial scenarios we are particularly faced with ever changing domains that need to be reflected within a knowledge base, restricted resources for its development and maintenance, and the uncertain perspicuity and acceptance of such an information source by the actual users [11]. The Need for Access Control Another important requirement of many industrial applications is the need to protect knowledge against unauthorized access. This need is particularly evident in many potential application areas of ontologies such as the area of data and application integration. The integrated data sources often hold confidential information that should not be accessible for everybody. In some cases, such as 1 Mannheimer Zentrum für Wirtschaftsinformatik, A5, 6 68159 Mannheim 663 the deregulation of the energy markets, there are even legal constraints on the accessibility of strategic information between different parts of the same enterprise. Tailoring the integration of data sources for different target groups is too much effort in most cases. Therefore, the only sensible solution is a complete integration of information along with the implementation of a fine-grained access control mechanism that grants access to parts of the integrated model based on a suitable set of security policies. While this problem has been investigated in details for standard technologies such as relational databases, so far there are no convincing solutions for providing fine-grained access control for ontology-based knowledge in the presence of logical inference. This hinders the uptake of semantic technologies in industrial applications dealing with sensible information. Providing a solution to this problem therefore increases the usefulness and the potential impact of semantic technologies in practice. Outline and Contributions Within this paper we present a security architecture for enabling access control of ontologies within standard semantic web infrastructures without the need to modify existing reasoners. In fact, we propose the use of a security proxy, which rewrites incoming SPARQL queries so they meet prior defined access control policies. For creating and maintaining those policies together with the corresponding ontologies in an integrated manner, we present an approach based on the Modeldriven Architecture (MDA). To this aim, the paper is organized as follows. In section 2 we briefly recall previous work on a model-driven approach for managing lightweight ontologies for industrial applications and provide an example ontology. In section 3, we extend the approach with a rolebased access control model that uses the XACML standard [17] for defining policies and show how it applies to our example. In section 4, we discuss our approach for enforcing security policies by rewriting SPARQL queries posed to the knowledge model. We conclude with a brief review of related work in section 5 and a discussion of the strength and weaknesses of our approach. 2 Indutrial-Strength Ontologies In previous work [1] we have proposed a lightweight knowledge model and an associated metamodel that meets the representation requirements of typical industrial applications while still being easy to understand and implemented using existing technology. In the following, we briefly present parts of this model for which we investigate the development of a security framework. A Metamodel for Lightweight Ontologies Gasevic et al. [9] have shown the relevance of the Model-driven Architecture (MDA) for ontology development. The Object Management Group (OMG), which provides all standards related to MDA in software engineering, has recently finalized the standardization process of the Ontology Definition Metamodel (ODM, [18]) - a metamodel for OWL ontologies based on the Meta Object Facitiliy (MOF), the standard for describing such models. The participation of big players of the branch such as IBM and AT&T and a first implementation by the Eclipse foundation, the EODM project, shows the high relevance of the ODM particularly to the industry. The coverage of OWL Full however results in a fairly complex metamodel. For OWL DL and Lite the ODM could be significantly simplified, since the use of RDF constructs are restricted in these subsets. Because OWL Full is not relevant to commercial applications due to its undecidability, we focus on more practical subsets of OWL. To enable high performance reasoning even with large A-Boxes we propose the use of a subset of OWL Lite, which falls into plain Datalog. Such a subset, namely OWL Lite-, has been defined by de Bruijn et al. [5]. The relevance of such a subset has been discussed by Volz [22] and Hitzler et al. [12]. In order to enable the direct representation of data 664 from relational databases, we added the primitive data types. The resulting subset, OWL Lite-,p, has been presented in more details in [1]. Table 1 gives an overview of the included language elements and also presents some mappings to other knowledge representation languages. Figure 1 Languages Features of OWL Lite-,p To actually utilize the metamodel for implementing an application for ontology development, we build on the Eclipse Modeling Framework (EMF), a project aiming at providing Eclipse-based tools for model-driven development. Among others, we can utilize the framework to automatically generate a Java object representation of metamodels defined in the Ecore - a meta-metamodel language, which is a real subset of MOF. Figure 2 shows the Ecore metamodel for OWL Lite-,p. Figure 2 Lightweight Ontology Metamodel 665 An Example Consider a product ontology, which integrates different information about products and their parts that may exist in different departments of a car manufacturer. Clearly, some information from e.g. sales such as the purchase price of a part should not be visible for developers. Also, external staff that works on specific parts should only see data which they require for their work. For example, somebody who is working on the braking system should only be able to see brake parts and specific electronic control units such as the Anti-Lock Braking System. The example ontology is defined using the abstract OWL syntax: Class(Manufacturer partial) Class(Supplier partial Manufacturer restriction(produces allValuesFrom Part)) Class(Product partial) Class(Car partial Product) Class(Part partial Product) Class(BodyPart partial Part) Class(PrototypeBodyPart partial BodyPart) Class(Brake partial Part) Class(ElectronicControlUnit partial Part) 3 Class(AntiLockBrakingSystem partial ElectroniControlUnit) Class(TransmissionControlUnit partial ElectronicControlUnit) Class(TCU partial ElectroniControlUnit) EquivalentClasses(TCU, TransmissionControlUnit) ObjectProperty(produces domain(Manufacturer) range(Product)) ObjectProperty(contains domain(Car) range(Part)) DatatypeProperty(hasSalesPrice domain(Product) range(float)) DatatypeProperty(hasPurchasePrice domain(Product) range(float)) The Security Framework Access Control and Policy Specification Access control systems enable the regulation of access to protected resources (i.e. objects) in distributed systems by subjects such as users or system processes (cf. [6]). They can be categorized in discretionary access control (DAC), mandatory access control (MAC), and role-based access control (RBAC) models. In DAC-based systems, the permissions to access an object are defined by its owner. In MAC models, the system determines the access to objects either by utilizing access rules or lattices for assigning permissions to subjects. It thus removes the ability of the users to control access to their resources. RBAC systems finally remove the explicit use of subjects within access rules or lattices and replace them with roles, which form a logical group of a number of subjects. In fact, permissions are assigned to roles and the subjects are assigned members of a number of roles. Thus changes of single subjects do not necessarily have consequences in the actual access control policies. The Extensible Access Control Markup Language (XACML) is an OASIS standard that describes both a policy language and an access control decision request/response language (both written in XML) [17]. The policy language consists of following basic constructs: • • • • PolicySet: A PolicySet is a container for a number of Policies or other PolicySets. Policy: A policy represents a single access control policy, expressed by a set of Rules. It applies for a defined Target. Rule: A Rule consists of a Target element and has an attribute Effect, which can be either ‘permit’ or ’deny’. Target: The Target element declares a set of Subjects, Resources, and Actions for which a Rule or Policy applies. 666 Note that the actual XACML specification defines a number of additional constructs to further refine the access control policies. Altogether XACML is an extensible standard that allows enterprises to build fine-grained access control systems. Protecting Resources in Ontologies In order to apply access control mechanisms to ontologies, we need to identify the resources, which should be protected. Since the T-Box of ontologies in generally represents a shared vocabulary of a specific domain, it is not reasonable to restrict access at this level. In fact, we aim at controlling the access to instances of specific classes and properties – i.e. the A-Box, while the T-Box remains unrestricted. We thereby assume that the access to individuals of all classes and all property values are denied by default for avoiding unintended security leaks. Because of this, access to specific classes and thus corresponding individuals as well as property values have to be explicitly granted to subjects. For this purpose, we consider following basic access rule types: (1) permit access to all individuals and values respectively of a class, a datatype property, or an object property; (2) deny access to a specific individual. To refine these policies, we further provide means to (3) deny the access to individuals and values of subclasses and subproperties of prior permitted resources. As common in modern access control systems, we envision a RBAC model for simplifying the maintenance of the access control policies. Extending the Metamodel In order to enable a uniform and interdependent maintenance of the protected ontologies together with the security policies, we extend the earlier presented metamodel of lightweight ontologies by means to model access control policies. Thus, we do not need to commit to a single representation formalism for either ontologies or security policies. We initially cover a subset of the XACML specification, which provides basic features for realizing the access control mechanism for ontologies as presented above (cf. Figure 3). We thereby leave out the PolicySet element and only consider simple restrictions on ontology resources. The use of the Target construct allows grouping the Policies by Subjects, Resources, or any combination of both. If no Action, Subject, or Resource is defined for a Target, we consider that the Policy or Rule applies for all Actions, Subjects, and Resources respectively. Figure 3 Access Control Policies Metamodel Security Architecture We can utilize existing reasoners for OWL Lite to infer implicit knowledge and query an ontology. This is typically done by sending a SPARQL select query to the appropriate endpoint of the used reasoner. In order to ensure confidentiality in such an infrastructure, we enforce the use of a security proxy, which intercepts all communication to the reasoner. Similar to web proxy systems, 667 we require a user authentication prior to its first use. The proxy acts as the Policy Enforcement Point (PEP) within the XACML architecture and constructs an authorization decision query to the Policy Decision Point (PDP). The decision of the PDP is based on the access control policies provided by the Policy Retrieval Point (PRP) and the information provided by the Policy Information Point (PIP) about for example the role of a user. The PEP finally enforces the decision of the PDP either by completely denying the query, by rewriting the query so it meets the security policies, or by directly redirecting the query to the reasoner. Details of this part of the process are discussed in section 4 below. The resulting security architecture ensures that enforcement of access control policies in a loosely coupled way by utilizing existing frameworks and tools without the need to modify existing reasoners, so they can directly support such a task. Within this work we assume that the security proxy unifies the different components (PxP) defined by the XACML architecture so there is no need to exchange messages between them. In future work, we consider splitting the single parts into separated components. Example An external developer works on the braking system of a car and thus should be able to access the required product information – i.e. information about Brakes and AntiLockBrakingSystems (ABS). Nevertheless, a specific prototype ABS-system should not be visible for him. We define following policy for a role ’ExternalBrakeDeveloper’: Policy P1 = {subject=’ExternalBrakeDeveloper’, rules={R1, R2}} Rule R1 = {‘read’, ‘permit’, {Class(Brake), Class(AntiLockBrakingSystem) }} Rule R2 = {‘read’, ‘deny’, {Individual(ABS1)}} For employees working in the sales department, we define similar rules, but explicitly permit the access to the datatype property ‘hasPurchasePrice’: Policy P2 = {subject=’Sales’, rules={R3, R4, R5}} Rule R3 = {‘read’, ‘permit’, {Class(Product)}} Rule R4 = {‘read’, ‘deny’, {Individual(ABS2)}} Rule R5 = {‘read’, ‘permit’, {DatatypeProperty(hasPurchasePrice)}} 4 Enforcing Access Policies As outlined above, security policies are enforced at a security proxy that receives queries to the ontology and rewrites them in such a way that no policies are violated considering the presence of logical inferences. In this section, we provide details about this rewriting step. The goal of the rewriting step is to create a query that returns the same results as the original query except for those answers that contain restricted information. For this purpose, the proxy first determines the access restrictions that apply for the specific query by determining the role of the issuing user and looking up the restrictions that apply to this role in the policy rules. As defined in the security framework, such rules can apply to classes, properties and instances. In this paper, we further focus on read restrictions on these elements. A proof-of-concept implementation based on the Jena framework can be downloaded at http://www.chenwilly.de/wi.html. Preliminaries Select queries in SPARQL typically contain a set of triple patterns, where subject, object and predicate may all be variables. However, for rewriting queries to meet the defined access 668 restrictions it is essential to be able to determine, if a variable will hold an individual or a data value. This can be achieved only if we assume that the predicate position within a triple is not a variable. Knowing the predicate, we can easily determine what kind of resource occurs for the subject and the object position. We refer to ?vk as variables for individuals and ?dk for data values. Temporary variables ?tk are introduced to expand the query with respect to enforce the given policies. When combining several filters we ensure that the variable names remain unique. Filtering Query Results A read restriction on individuals i1, .., in is interpreted in the way that the user is not allowed to see answers that contain this specific individual. This condition can easily be fulfilled by extending the query with the following filter condition on each of the return variables ?vk: FILTER (?vk != ex:i1 && .. && ?vk != in) This condition removes all results, where restricted individuals are bound to any of the return variables. We interpret read restriction on a class C in such a way that the user is not allowed to see answers that contain instances of the restricted class. Therefore not allowing the access to a class is equivalent to restricting the access to any individual of the class. Matters are complicated by the fact that class membership can be inferred using the ontology. Therefore, it is not possible to simply add filter restrictions for all instances that are defined to be member of restricted classes. We can however, delegate this problem to the underlying inference engine by using a filter expression on the schema level: OPTIONAL { ?vk rdf:type ?t1 . FILTER (?t1 = C) } FILTER ( ! bound (?t1 ) ) This expression checks for each return variable, whether the instance bound to the variable is of type C. If this is true, the corresponding answer is filtered out based on the criterion that variable ?t1 is bound to the restricted class. Read permission on classes can be enforced in a similar manner by adding a filter expression, which ensures that the queried instances are at least member of one of the permitted classes Ci: ?vk rdf:type ?t1. FILTER (?t1 =C1 || … || ?t1 = Cn) We further interpret restrictions on a relation R in the way that the user is not allowed to see answers in which two of the return variables are bound to instances that are in relation R to each other, because queries might be formulated in such a way, that they model the restricted relation without actually mentioning it. We again use a filter expression to filter out the corresponding answers from the result set. OPTIONAL { ?vk ?t1 ?vj . FILTER (?t1 = R) } FILTER ( ! bound (?t1 ) ) Here ?vk ≠ ?vj are return variables of the query. The expression checks whether the existence of relation R between ?vk and ?vj can be derived from the ontology. If this is the case, the corresponding answer is filtered out based on the criterion that the variable ?t1 is bound to R. This solution again delegates the problem of dealing with derivable information to the underlying inference engine which is used to check whether (?vk ?t1 ?vj) can be derived from other information 669 such as inverse relations, etc. Clearly, ?vk or ?vj may also be concrete resources. Similar to explicitly granting read access to individuals of a specific class, we can add a filter for permitting access to property values Ri: ?vk ?t1 ?vj. FILTER (?t1 = R1 || … || ?t1 = Rn) Controlling the Rewriting Process In section 4.2 we have presented the concrete filter expressions that can be used to ensure that no restricted information is returned by a query. This section now deals with linking the manipulation of the queries with the policy specifications in order to control the rewriting process. Following the assumption from 3.2, we can formulate a simple rewriting strategy that first extends the query with filters for those individuals explicitly restricted for the role under consideration and then also adds filters for concepts and relations access to which is not explicitly permitted. The corresponding simple algorithm is given below: ReWrite(Q:Query, R:Role, P:Policy) FORALL {i, read, R, deny} ∈ P DO FORALL {C, read, R, permit} ∈ P DO FORALL {C, read, R, deny} ∈ P DO FORLAL {P, read, R, permit} ∈ P DO FORALL {P, read, R, deny} ∈ P DO IF {C, read, R, permit} ∉ P DO IF {P, read, R, permit} ∉ P DO AddDenyFilter(Q,i) AddPermitFilter(Q,C) AddDenyFilter(Q,C) AddPermitFilter(Q,P) AddDenyFilter(Q,P) DenyAccess(Q) DenyAccess(Q) Verifying Anomalies in Access Policies During the creation and maintenance anomalies such as contradictory rules could occur in access policies. Since we use filters to enforce the policies, a deny rule always overrides a permit rule on the same resource. Thus, inconsistent access policies would not result in unintended information leaks. To ensure the consistency of access policies, we additionally provide an initial set of verification rules that can be applied at the metamodel level on rules that apply for the same subject: • • • • • IF EXISTS R1 = {‘read’, ‘permit’, RestrictedResource(R)}, R2 = {‘read’, ‘deny’, RestrictedResource (R)} THEN Anomaly(R1, R2) IF EXISTS R1 = {‘read’, ‘permit’, OntologyClass(C1)}, R2 = {‘read’, ‘deny’, OntologyClass(C2)} AND EquivalentClasses(C1,C2) THEN Anomaly(R1, R2) IF EXISTS R1 = {‘read’, ‘permit’, ObjectProperty(P1)}, R2 = {‘read’, ‘deny’, ObjectProperty(P2)} AND (EquivalentProperties(P1,P2) OR ObjectProperty(P1 inverseOf(P2))) THEN Anomaly(R1, R2) IF EXISTS R1 = {‘read’, ‘permit’, ObjectProperty(P1)}, R2 = {‘read’, ‘deny’, OntologyClass(C1)} AND (ObjectProperty(P1 domain(C1)) OR ObjectProperty(P1 range(C1))) THEN Anomaly(R1, R2) IF EXISTS R1 = {‘read’, ‘permit’, DatatypeProperty(P1)}, R2 = {‘read’, ‘deny’, OntologyClass(C1)} AND DatatypeProperty (P1 domain(C1)) THEN Anomaly(R1, R2) 670 5 Related Work Recently, there has been quite a bit of work on combining semantic web technologies with security issues. Most of this work, however, is about applying semantic web technologies to the problem of specifying and checking security policies and related aspects (e.g. [15]). The aspect we are interested in, the protection of knowledge encoded in an ontology has so far received less attention. Qin and Atluri [19] have presented an approach to enable access control at concept level for ontologies. Their approach is based on a propagation mechanism that derives access rights for concepts based on the semantic of the ontology and partial access rights explicitly stated. A similar approach is envisioned by Knechtel [14] who proposes to derive the access rights of derived facts from the access rights based on access restrictions imposed on stated knowledge. In contrast to this our approach relies on the re-writing on queries based on security policies. This allows us to leave the task of optimizing the execution of the query to the query engine. The inference problem, which is central to our work, has been investigated by researchers in the field of database research [7]. The problem has been investigated in the context of statistical databases, where statistical inference can be used to derive classified information from unclassified ones [16]. Special attention has been paid to the inference problem in the context of multilevel secure databases. Here it also has to be ensured that access policies are not violated between the different security layers. In our work, we have so far ignored such problems arising in multilevel security policies. Most of the work on secure databases has addressed the relational model and problems that arise from the use of database constraints. The problem of enforcing security constraints in deductive databases, a problem that is closely related to our work has so far only been addressed on a theoretical level with little concerns on implementability [3] . 6 Conclusions In this paper we have presented an approach to restrict the access to confidential knowledge that is represented using ontologies, which we consider an important feature for real world applications. We thereby fully build on existing technologies and infrastructures. The access control system relies on a security proxy, which intercepts all communication to the SPARQL endpoint of any utilized OWL reasoner. When enforcing fine-grained role-based access policies we need to take possible inferences from the ontology into account. Instead of realizing this complex issue within the security proxy, we delegate this task to the reasoner by adding SPARQL filter statements to incoming queries from users. This allows us to apply our solution with all reasoners supporting OWL Lite and SPARQL. Since the access policies and rules are highly dependent on the ontologies they have been defined for, we utilize a model-driven approach to enable their interdependent development and maintenance. Moreover, we do not need to decide for a specific representation language for either a priori, but can transform the created models to various formalisms we required. For ontologies, we can directly support OWL, F-Logic [13], and Datalog, while we may rely on the XACML specification for access policies. Future work includes the support of variables at the predicate position of triple patterns in SPARQL queries. Similarly to the rewriting of queries, we thereby aim at analyzing the query results, whether they contain confidential information. Also, we intend to support access control mechanisms for OWL DL on the one hand and OWL Lite-,p combined with rules. Clearly, hierarchical access control models will also be part of future research. 671 7 Bibliography [1] CHEN, W. and STUCKENSCHMIDT, H., Towards industrial strength knowledge bases for product lifecycle management, in: 16th European Conference on Information Systems, Galway, Ireland, 2008. [2] CHEN, W. et al., Business-oriented CAx-Integration with Semantic Technologies, in: 3rd International Applications of Semantic Technologies Workshop, Munich, Germany, 2008. [3] BONATTI, P. et al., Foundations of Secure Deductive Databases IEEE Transactions on Knowledge and Data Engineering, 1995. [4] DAVIS, M., Semantic Wave 2008 Report - Industry Roadmap to Web 3.0 & Multibillion Dollar Market Opportunities 2008 [5] DE BRUIJN, J. et al., OWL Lite-, WSML Deliverable D20 v 0.1, 2004. [6] ECKERT, C., IT-Sicherheit, Oldenburg, 2003. [7] FARKAS, C. and JAJODIA, S., The inference problem: a survey, SIGKDD Explor. Newsl., ACM, 2002. [8] FENSEL, D., Ontologies: Silver Bullet for Knowledge Management and Electronic Commerce, Springer, 2001 [9] GASEDVIC, D. et al., Model Driven Architecture and Ontology Development. Springer, 2006 [10] HAHN, A., Integration verteilter Produktmodelle durch Semantic-Web-Technologien, Wirtschaftsinformatik, 47, 278-284, 2005. [11] HEPP, M., Possible Ontologies: How Reality Constrains the Development of Relevant Ontologies, IEEE Internet Computing, 2007. [12] HITZLER, P. et al., DLP is not so bad after all, in: OWL: Experiences and Directions, 2005. [13] KIEFER, M. et al., Logical Foundations of Object-Oriented and Frame-Based Languages, Journal of the ACM, 1995. [14] KNECHTEL, M., Access rights and collaborative ontology integration for reuse across security domains, Poster, ESWC 2008 PhD Symposium, 2008. [15] KOLOVSKI, V. et al., Analyzing Web Access Control Policies, in: Proceedings of the Sixteenth International World Wide Web Conference, 2007. [16] MANDUJANO, S., Inference Attacks to Statistical Databases: Data Suppression, Concealing Controls and Other Security Trends, Aleph-Zero electronic magazine 25, 2000. [17] OASIS, A Brief Introduction to XACML, http://www.oasisopen.org/committees/download.php/2713/Brief Introduction to - XACML.html, March 2003. [18] OMG Adopted Specification, Ontology Definition Metamodel, http://www.omg.org/docs/ptc/07-09-09.pdf, 2007. [19] QIN, L. and ATLURI, V., Concept-level access control for the semantic web, in: Proceedings of the 2003 ACM workshop on XML security, 2003. [20] STAAB, S., Wissensmanagement mit Ontologien und Metadaten, Habilitation Thesis, University of Karlsruhe, 2002. [21] SYLTAKE, T. et al., How Ontologies and Rules Help to Advance Automobile Development Advances in Rule Interchange and Applications, in: Proceedings International Symposium RuleML 2007, Orlando, Florida, 2007. [22] VOLZ, R., Web Ontology Reasoning with Logic Databases, PhD thesis, Universität Fridericiana zu Karlsruhe, 2004. 672 MANAGEMENT VON MODELLBEZIEHUNGEN MIT SEMANTISCHEN WIKIS Michael Fellmann, Oliver Thomas1 Kurzfassung Der Beitrag befasst sich mit der Dokumentation von Modellen und dem Management der zwischen ihnen bestehenden Beziehungen. Zur systematischen Erfassung und Nutzung des Wissens um die Zusammenhänge und Relationen zwischen Modellen werden semantische Wikis untersucht. Hierzu wird ein Vergleichsrahmen entwickelt, der zur problemadäquaten Auswahl semantischer Wikis herangezogen wird. Zum praktischen Einsatz semantischer Wikis wird eine Metadatenstruktur entworfen und deren Verwendung anhand eines Prototyps demonstriert. 1. Einleitung Das Prozessmanagement ist gegenwärtig durch einen Sprachpluralismus gekennzeichnet. Zwar zeichnet sich mit der von der Softwareindustrie favorisierten Sprache BPMN ein De-facto-Standard ab [1], allerdings können nicht alle betriebswirtschaftlich relevanten Sachverhalte mit BPMN beschrieben werden. So lassen sich mit dieser technisch ausgerichteten Sprache bspw. organisatorische Zuständigkeiten, deren Analyse in Reorganisationsprojekten unverzichtbar ist, nicht modellieren. Die Konstruktion von Prozessmodellen und damit die zu ihrer Erstellung verwendete Sprache werden auch zukünftig von der intendierten Beschreibungsebene im Sinne einer „Nähe“ zur IT abhängen. In diesem Sinne unterscheiden sich Sprachen zur Erstellung fachlicher Prozessmodelle (z. B. EPK, UML-Aktivitätsdiagramm, IDEF3, Activity-Decision Flow Diagram) von Sprachen zur Erstellung von ausführbaren Prozessmodellen (z. B. BPMN, BPEL, XL, XPDL), bspw. im Umfang der zum Management von Fehlern und Ausnahmezuständen bereitgestellten Sprachkonstrukte. Im Ergebnis ist die Praxis der Modellierung von einer Vielzahl an Modellen geprägt, die sich hinsichtlich des Gegenstands der Modellbildung, ihrer Nähe zur IT und hinsichtlich der zu ihrer Erstellung verwendeten Modellierungssprachen und -werkzeuge unterscheiden [24, S. 9]. Die hierbei zwischen den verschiedenen Modellen bestehenden Beziehungen werden von den gegenwärtigen Modellierungswerkzeugen jedoch nur unzureichend verwaltet, obwohl dies in der Literatur bereits seit einiger Zeit gefordert wird [7; 24]. Zusätzlich verhindert oder erschwert der Einsatz mehrerer Modellierungswerkzeuge eine einheitliche Dokumentation der Modelle und Modellbeziehungen. Das Wissen um die vielfältigen, zwischen den Modellen bestehenden semantischen Beziehungen, wie bspw. in Form der Relationen „ist abgeleitet von“, „detailliert“ oder „implementiert“, ist folglich überwiegend implizit in den Köpfen einzelner Mitarbeiter einer Organisation verankert. Es liegt somit nicht explizit repräsentiert in einem zentralen Speicher vor, womit es sich einem inter1 Institut für Wirtschaftsinformatik im DFKI, Universität des Saarlandes, Stuhlsatzenhausweg 3, 66123 Saarbrücken. 673 subjektiven Verständnis entzieht und eine Wiederverwendung in mehreren Projekten nicht gegeben ist. Auch eine maschinelle Verarbeitung, z. B. zur Analyse und Suche von Abhängigkeiten zwischen Modellen, ist ohne eine explizite Dokumentation der Modellbeziehungen nicht möglich. Im vorliegenden Beitrag soll daher untersucht werden, wie das Anlegen, Speichern und Ändern von semantischen Beziehungen zwischen Modellen – kurz: das Management von semantischen Modellbeziehungen – informationstechnisch unterstützt werden kann. Bei der Gestaltung einer entsprechenden IT-Lösung muss sorgfältig zwischen formaler Präzision und pragmatischer Handhabbarkeit abgewägt werden. Bauen die semantischen Modellrelationen auf einer vorgegebenen formalen Struktur auf, so eignen sie sich zwar zur maschinellen Verarbeitung, die Interpretation realweltlicher Zusammenhänge wird jedoch ggf. erschwert. Semantische Wikis lösen diesen Konflikt auf. Sie erweitern den Wiki-Gedanken, die Zusammenarbeit zwischen verschiedenen Autoren und somit die Erstellung und Konsolidierung einer gemeinsamen Wissensbasis zu unterstützen, um semantische Technologien. Diese ermöglichen eine teilweise maschinelle Interpretation der im Wiki enthaltenen Inhalte, was durch die Annotation der Inhalte mit Elementen eines wohldefinierten Vokabulars, das bspw. als eine formale Ontologie repräsentiert werden kann, erreicht wird. Auf diesen Annotationen basierend erlauben semantische Wikis eine verbesserte Navigation, Suche und Retrieval in bestehenden Inhalten [20, S. 1]. Durch Verfahren des maschinellen Schließens können darüber hinaus auch neue Fakten aus der bestehenden Wissensbasis abgeleitet werden, wie z. B. zusätzliche Relationen zwischen Artefakten, die nicht explizit von den Autoren eines Wikis angelegt und aktualisiert werden müssen. In diesem Beitrag soll die Eignung semantischer Wikis zum Management der Dokumentation von Modellbeständen untersucht werden. Im Gegensatz zu Arbeiten, die sich domänenneutral mit der Nutzung bzw. dem funktionalen Vergleich semantischer Wikis befassen [2; 9; 27], wird hier speziell die Eignung semantischer Wikis hinsichtlich der Dokumentation von Prozessmodellen und der formalen Repräsentation der zwischen ihnen bestehenden Beziehungen untersucht. Dabei sollen sowohl generelle Merkmale semantischer Wikis herangezogen werden als auch Aspekte, die im Hinblick auf das Prozessmanagement eine besondere Rolle spielen. Der Vergleich der semantischen Wikis ist systematisch und baut auf einem einheitlichen Vergleichsrahmen auf. 2. Stand der Forschung In der Modellierung geht es häufig um die Frage, wie die Ableitung spezifischer Modelle aus einem gegebenen Modellbestand gelingen kann [12]. Die Autoren betrachten hierbei sowohl Versionsbeziehungen zwischen Modellen [14; 32] als auch Variantenbeziehungen, die in der Charakterisierung spezieller Konstruktionstechniken münden [35]. Insb. die Konfiguration spielt als spezielle Technik aufgrund ihrer Potenziale zur IT-Unterstützung eine große Rolle [10; 11; 29]. In diesen Arbeiten werden insofern zwar Relationen zwischen Modellen betrachtet, diese sind jedoch immer nur auf eine Beschreibungsebene festgelegt, d. h. liegt ein Referenzmodell auf fachkonzeptioneller Ebene oder Implementierungsebene vor, dann ist auch das aus ihm abgeleitete Modell der jeweiligen Ebene zugeordnet. Die gerade in Implementierungsprojekten notwendige Abbildung von Beziehungen zwischen fachlichen Prozessbeschreibungen und ausführbaren Prozessmodellen wird i. d. R. nicht betrachtet. Diese sollen in dieser Arbeit durch semantische Technologien gleichermaßen unterstützt werden wie die Dokumentation der Relationen auf gleicher Beschreibungsebene. Die formale Beschreibung und semantische Annotation von Modellen im Allgemeinen wird vor allem im Arbeitsgebiet des „Semantic Business Process Management“ vorangetrieben [3; 4; 33]. Die Beschreibung von Beziehungen zwischen Modellen mit Technologien des Semantic Web wird in Bezug auf Produktmodelle von Hahn [15], in Bezug auf Referenzmodelle und die daraus abgeleite674 ten Modelle von Hinkelmann, Thönssen und Probst [16] beschrieben. Die genannten Arbeiten fokussieren im Unterschied zu diesem Beitrag jedoch hauptsächlich eine Formalisierung der Semantik von Modellen auf der Ebene sprachbasierter Metamodelle oder – im Rahmen von Annotationsansätzen – der individueller Modellelemente. Eine Betrachtung der Semantik von Modellierungssprachen wird auch im Rahmen der ontologischen Analyse praktiziert [36]. Hier ist insb. das Bunge-Wand-Weber-Modell zu nennen [37]. Weitere Arbeiten zur Semantik von Modellierungssprachen sind im Umfeld der Enterprise Model Integration und von Meta-Modellierungsplattformen anzutreffen [18; 23]. Daneben existieren Werkzeuge wie METIS [17], um Beziehungen zwischen Sprachelementen und sprachbasierten Metamodellen abzubilden. Während diese Arbeiten die Semantik und das Management der Beziehungen zwischen Sprachkonstrukten von Modellierungssprachen betrachten, werden in diesem Beitrag die semantische Beschreibung und das Management der Beziehungen zwischen Modellen untersucht. Die Dokumentation von Modellen und das Management der zwischen ihnen bestehenden semantischen Beziehungen soll hier mittels semantischer Wikis unterstützt werden. Die Eignung dieser Systeme zur Unterstützung der genannten Aufgaben wird nachfolgend kriterienbasiert untersucht. 3. Vergleich semantischer Wikis 3.1. Herleitung der Vergleichskriterien Kriterien zum Vergleich semantischer Wikis in Bezug auf die Dokumentation von Modellen und das Management der zwischen ihnen bestehenden Beziehungen können in den Bereichen Modellmanagement, Modelldokumentation, Browsing und Suche sowie Kollaboration identifiziert werden. Im Bereich des Modellmanagements ist ein wesentliches Kriterium, inwiefern die Repräsentationen semiformaler Modelle in ein Wiki importiert werden können. Hierbei lassen sich grundlegend zwei Szenarien unterscheiden. Erstens kann ein Modell als Grafik, die von einem Modellierungswerkzeug erzeugt worden ist, importiert werden (indirekter Import). Zweitens kann das Modell mittels eines standardisierten Austauschformats für Modelle, wie z. B. XMI oder EPML, in das Wiki eingelesen werden (direkter Import), welches in diesem Fall die Erzeugung einer grafischen Repräsentation übernimmt. Um unterschiedliche Berechtigungen für die Nutzung des Wikis z. B. im Intranet, Extranet oder dem Internet abbilden zu können, sollte das Wiki ergänzend über eine Verwaltung von Zugriffsrechten verfügen. Eine Modelldokumentation kann bei Wikis grundlegend über die Erstellung von Wikiseiten erfolgen, die eine natürlichsprachliche Dokumentation des zu beschreibenden Modells enthalten. Um den Einarbeitungsaufwand zur Wikinutzung so gering wie möglich zu halten, ist hierbei die Unterstützung durch einen WYSIWYG-Editor wünschenswert, sodass der Nutzer keine spezielle Syntax zur Formatierung der Wikiseite erlernen muss. Semantische Wikis erlauben darüber hinaus die Zuordnung einer Wikiseite zu einem oder mehreren in einer Metadatenstruktur, wie bspw. einer Ontologie, formal definierten Konzepte. Auch die zwischen Wikiseiten bestehenden Links können semantisch genauer spezifiziert werden. Analog zur Unterstützung beim Editieren von Wikiseiten sollte das Wiki den Nutzer auch bei deren Annotation unterstützen, z. B. durch eine Auto-Vervollständigungsfunktion oder über einen WYSIWYG-Editor. Weitere Dokumentationskriterien sind, ob Metadaten und Metadatenschemata, z. B. in Form von Ontologien, importiert werden können, um somit die Inbetriebnahme eines semantischen Wikis zu erleichtern. Auch der Export ist eine relevante Funktionalität, um die Metadaten außerhalb des Wikis z. B. zur Analyse in Fremdanwendungen verwenden zu können. Zur Anpassung des Wikis an die sich ändernden Anforderungen der Modelldokumentation ist ferner relevant, ob die Metadatenstruktur innerhalb der Wikiseiten geän675 dert werden kann. Von besonderer Wichtigkeit für die Modelldokumentation ist die Versionierung sowohl der Wikiseiten als auch der zu ihnen gehörenden semantischen Metadaten, damit Änderungen an den dokumentierten Modellen bzw. der Metadaten jederzeit nachvollziehbar bleiben. Im Bereich Browsing und Suche ist, neben einer Volltextsuche zum schnellen Auffinden von Inhalten, das Vorhandensein einer Funktionalität zum facettenbasierten Browsen relevant. Somit können die zur Verfügung stehenden semantischen Metadaten zu einer effektiven und multiperspektivischen Auswahl von Modellen herangezogen werden. Als eine Facette wird hierbei ein durch die Metadatenstruktur des semantischen Wikis vorgegebenes Merkmal bezeichnet, das in Form von Relationen zwischen Modellen (z. B. „ist abgeleitet von“) oder Attributen von Modellen (z. B. „Erstelldatum“) auftreten kann. Die insgesamt im Wiki vorhandenen Werteausprägungen können im Rahmen des facettenbasierten Browsings von einem Nutzer dazu verwendet werden, schrittweise komplexe Filter zur Anzeige einer gewünschten Teilmenge des Modellbestands zu erzeugen. Zusätzlich kann das Browsing im Modellbestand durch Übersichtsseiten erleichtert werden, die Modelle nach bestimmten Kriterien auflisten. Um eine manuelle Pflege derartiger Seiten zu vermeiden, die bei einem großen Modellbestand entsprechend personalintensiv ist, sollte das Wiki über eine Möglichkeit verfügen, Wikiseiten über eingebettete Suchanfragen zu erzeugen. Diese Suchanfragen werden zur automatisierten Auswertung der über den Modellbestand gespeicherten Metadaten verwendet. Kriterien zur manuellen Suche im Modellbestand sind die Unterstützung einer Anfragesprache wie bspw. SPARQL [28] und das Vorhandensein einer Unterstützung zur Erstellung korrekter Anfragen, bspw. in Form einer Vorlage zur Anfrage oder eines Suchformulars, das die Eingabe von Anfragen erleichtert. Zur Ausschöpfung der mit der Erfassung semantischer Metadaten verbundenen Potenziale ist die Nutzung von Inferenzmaschinen ein wichtiges Kriterium, damit neue Fakten geschlossen werden können, die nicht explizit (d. h. manuell) im Wiki erfasst wurden, sondern zum Anfragezeitpunkt aus den vorhandenen Daten dynamisch abgeleitet werden. Neben den genanten Kriterien ist ergänzend zu berücksichtigen, dass Änderungskonstruktionen in Modellierungsprojekten in der Regel nicht ausschließlich am Gesamtmodell vollzogen werden. Sie werden vielmehr von Projektbeteiligten – verstärkt durch den Trend zur Arbeitsteilung in der Modellentwicklung [34] – verteilt an Detailmodellen verrichtet und anschließend zu einer verbesserten Konstruktion zusammengeführt. Kollaborationsfunktionen unterstützen hierbei die Zusammenarbeit der an der Modellerstellung und -nutzung beteiligten Akteure. Als relevante Kriterien sind insb. Funktionalitäten zum gemeinschaftlichen Indexieren (Tagging), zur Diskussion und zur Qualitätsbeurteilung (Rating) von Inhalten zu nennen. 3.2. Durchführung des Vergleichs Es existieren bereits zahlreiche Implementationen semantischer Wikis; für einen Überblick vgl. [2], zu Vergleichen siehe [9] oder [27]. Die im Rahmen dieses Beitrags betrachteten Wikis wurden anhand der Vollständigkeit der Implementierung der in diesem Beitrag genannten Kriterien, anhand des Umfangs und der Qualität ihrer Dokumentation und anhand der Häufigkeit ihrer Nennung in der Literatur ausgewählt. Da in dieser Arbeit mit dem Vorschlag von Wikis zur Dokumentation von Modellen und deren Beziehungen kollaborative Aspekte betont werden, sind Wikis, die vorwiegend das persönliche Wissensmanagement fokussieren, wie bspw. Semper [26] oder ArtificialMemory [25], nicht ausgewählt worden. Ebenso wurden Wikis nicht berücksichtigt, die ausschließlich für spezifische Inhalte entwickelt wurden, wie bspw. mathematische Formeln oder Lexika. Tabelle 1 charakterisiert die in diesem Beitrag ausgewählten semantischen Wikis. 676 Tabelle 1: Überblick über semantische Wikisysteme Name COW IkeWiki Kaukolu Makna OntoWiki Platypus Wiki Rhizome Semantic Media Wiki Sweet Wiki WikSAR Kurzprofil und Besonderheiten Quelle [13] Unterstützung der kollaborativen Konstruktion und Weiterentwicklung von Ontologien. Hierbei werden die Versionierung, Transaktionen und das Management gleichzeitiger Modifikationen unterstützt. In Wikiseiten können Ontologieinformationen zur Generierung dynamischer Inhalte und zur Fragenbeantwortung genutzt werden. [http://www.informatik.uni-freiburg.de/cgnm/software/cow/] [30] Es gestattet unterschiedliche Grade der Formalisierung von einfachen Texten bis hin zu Ontologien. Das Wiki unterstützt die W3C-Standards RDF und OWL und erlaubt automatische Schlussfolgerungen in der Wissensbasis. Zum Editieren steht ein WYSIWYG-Editor zur Verfügung. [http://ikewiki.salzburgresearch.at/] [19] Die Annotation von Wikiseiten mit semantischen Konzepten erfolgt flexibel, sodass keine strikte 1:1-Beziehung zwischen beiden bestehen muss. So ist es bspw. möglich, einzelne Textpassagen (z. B. juristischer Texte) anhand bereits existierender Ontologien zu annotieren und diese Informationen zum Retrieval zu nutzen. Es kann zwischen einer seitenorientierten Sicht und einer Sicht auf die Annotationen gewechselt werden. [http://kaukoluwiki.opendfki.de/] [21] Es können vorgefertigte Ontologien in das Wiki importiert und anschließend zur Erzeugung von Instanzdaten verwendet werden. Zum Editieren von Wikiseiten und zur Suche stehen zahlreiche interaktive Assistenten zur Verfügung. [http://www.apps.ag-nbi.de/makna/] [5] OntoWiki fokussiert agile und verteilte Wissensprozesse. Hierzu unterstützt das Wiki diverse Visualisierungen und Sichten auf die Wissensbasis, wie bspw. ein facettenbasiertes Browsing oder die Integration von geografischen Karteninformationen. Die Zusammenarbeit wird u. a. durch die Möglichkeit unterstützt, jeden Teil der Wissensbasis zu diskutieren, die Popularität von Inhalten bewerten und die Aktivitäten eines Nutzers belohnen zu können. [http://ontowiki.deri.at/] Es handelt sich um ein einfaches Wiki, das um eine Nutzerschnittstelle zur Annotation von Wikiseiten mit Metadaten erweitert – wurde. Unterstützt werden hierbei die Formate RDF, RDF-Schema und OWL. [http://platypuswiki.sourceforge.net/] [31] Es handelt sich um ein wiki-ähnliches Content-Management-System. Gesamte Seiten, d. h. deren Inhalte und Struktur, können als editierbare RDF-Daten ausgegeben werden. Rhizome unterstützt das Editieren von Seiten u. a. durch eine eigene Textformatierungssprache, mit der beliebige XML- und RDF-Daten beschrieben werden können. [http://rx4rdf.liminalzone.org/Rhizome] Als Erweiterung von MediaWiki, der Software, die u. a. von Wikipedia genutzt wird, zielt Semantic MediaWiki auf eine einfa[21] che Benutzbarkeit und Skalierbarkeit ab, um semantische Technologien für eine möglichst große Anwendergruppe zu erschließen. Ein größeres Projekt, in dem Semantic MediaWiki eingesetzt wird, ist die Schaffung der „Semantic Wikipedia“. [http://semantic-mediawiki.org/] [8] Kern dieses Wikis ist ein um semantische Technologien erweiterter Web Server. Dieser gestattet die direkte Einbettung von Schlagworten (Tags) in Wikiseiten. Die zwischen den Schlagworten bestehenden Bezüge können in Form einer Ontologie von den Administratoren festgelegt werden. Eine in den Server integrierte semantische Suchmaschine erlaubt die Suche und Navigation in den Seiten. [http://www-sop.inria.fr/teams/edelweiss/wiki/wakka.php?wiki=SweetWiki] [6] Dieses Wiki gestattet eine einfache semantische Annotation und Suche. Durch in Seiten eingebettete Anfragen können Kollektionen von Informationsobjekten dargestellt werden. Eine Visualisierung als Graph vermittelt einen Überblick über die WikiInhalte. [http://wiki.navigable.info/] Tabelle 2 zeigt die Ergebnisse des Vergleichs der zuvor ausgewählten semantischen Wikis. Sofern ein Kriterium bzw. eine Funktionalität von einem Wiki implementiert ist, wird dies durch einen ausgefüllten Kreis z angezeigt. Der umgekehrte Fall wird durch einen leeren Kreis { angezeigt. Wie aus Tabelle 2 ersichtlich ist, weisen die für den Vergleich herangezogenen Wikis bereits eine relativ hohe Implementierungsrate in Bezug auf Funktionalitäten auf, die dem Bereich der Modelldokumentation zuzuordnen sind. So unterstützen die meisten Wikis den Import von Metadatenstrukturen in Form von RDF- oder OWL-Ontologien, eine Unterstützung der Annotation wird ebenfalls von der Mehrheit der betrachteten Wikis bereitgestellt. Demgegenüber weisen die anderen in diesem Vergleich beurteilten Bereiche einen deutlich geringeren Implementierungsstand auf. Im Bereich des Modellmanagements etwa ist zu konstatieren, dass keines der verglichenen Wikis den Import von Modellen in einem Standard-Austauschformat erlaubt. Auch Funktionalitäten im Bereich der Kollaboration sind noch relativ selten anzutreffen. Als gravierend hinsichtlich der Verwendbarkeit der verglichenen semantischen Wikis sind die Mängel im Bereich des Browsings und der Suche zu bewerten. Nur wenige der verglichenen Wikis gestatten ein facettenbasiertes Browsen und in Seiten eingebettete Anfragen, die für die Navigation in großen Modellbeständen und die Generierung von Übersichtsseiten (z. B. Auflistung aller Modelle, die von einem Modell abgeleitet wurden) unabdingbar sind. Es ist jedoch zu erwarten, dass diese Probleme hinsichtlich der Nutzung der semantischen Metadaten mittelfristig durch verbesserte Implementierungen der Wikis behoben werden, womit diese dann zur Dokumentation, Suche, Bewertung, Diskussion und Analyse von Modellen und den zwischen ihnen bestehenden Beziehungen eingesetzt werden können. Eine zu diesem Einsatz erforderliche, grundlegende Anpassung der Wikisysteme betrifft die Metadatenstruktur, die zur Annotation der Modelle und der zwischen ihnen bestehenden Relationen 677 verwendet wird. Die erforderliche Metadatenstruktur kann entweder in das zu verwendende Wiki importiert werden – der Import von Metadatenstrukturen bspw. in Form von Ontologien ist bei den meisten Wikis bereits möglich (Tabelle 1, Merkmal „Import von Metadaten / Ontologien“) – oder über den im Wiki vorhandenen Editor angelegt werden. Nachfolgend wird eine solche Metadatenstruktur in Form einer Ontologie entwickelt. COW IkeWiki Kaukolu Makna OntoWiki Platypus Wiki Rhizome Semantic Media Wiki Sweet Wiki WikSAR Tabelle 2: Vergleich semantischer Wikis Import von Modellen als Grafik { z { z z { z z z z Import von Modellen über Austauschformat { { { { { { { { { { Verwaltung von Zugriffsrechten { z z z z { z z z { WYSIWYG-Editor { z { { z { { { z { Unterstützung der Annotation { z z z z z { { z { Import von Metadaten / Ontologien { z z z z z z z z { Export von Metadaten / Ontologien z z z z z z z z z z Editieren von Metadatenstrukturen / Ontologien in den Wikiseiten z z { { z { { { z z Versionierung Wikiseite z z { z z z z z z { Versionierung Metadaten { z { z z { z z z { Facettenbasiertes Browsen { { z { z { { { z { In Seiten eingebettete Abfragen z { { { { { { z { z Nutzung einer Anfragesprache z { { { { z z z { z Unterstützung der Anfrage z { { z { { { { { { Anfrage mit Inferenz { z { z z z { { z { Volltextsuche z z z z z z z z z z Bewertung und Popularität { { { { z { z { { { Diskussionsseiten, Kommentare { { z { z { z { { { Verschlagwortung { z { { { { { { z { Modellmanagement Modelldokumentation Browsing und Suche Kollaborationsfunktionen 4. Metadatenstruktur zum Management von Modellbeziehungen Als Metadaten werden allgemein Daten bezeichnet, die semantische, strukturelle, administrative und technische Daten über andere Daten bereitstellen [22, S. 85]. In diesem Sinne handelt es sich bei der Metadatenstruktur zum Management von Modellbeziehungen um eine Struktur, die vorgibt, wie semantische Daten zur Repräsentation von Modellbeziehungen zu strukturieren sind. Hierbei werden zum einen Daten betrachtet, welche die Beziehungen der Modelle untereinander repräsentieren (Modellrelationen). Zum anderen werden Daten betrachtet, die die Beziehungen von Modellen zu weiteren, sie charakterisierenden Informationsobjekten repräsentieren (Modellattribute). Abbildung 1 zeigt die Metadaten in Form einer UML-Metadatenontologie (eine OWL-Version der Ontologie kann unter http://www.semantic-business.org/ontologies/2008/08/sbpmwiki.owl abgerufen werden). Die Klassen der Ontologie sind als UML-Klassen visualisiert, Relationen als UMLAssoziationsklassen. Spezielle Eigenschaften der Relationen, wie Transitivität oder der Symmetrie, sind durch Pfeile in den Bezeichnungen der Assoziationsklassen ersichtlich. 678 Abbildung 1: Metadatenontologie Modellrelationen werden unterschieden in eine Teil-Ganzes-Beziehung partOf und eine weitere Beziehung zur Repräsentation einer inhaltlichen Nähe, Verbindung oder Verknüpfung isRelatedTo. Die partOf-Beziehung drückt aus, dass ein Modell als Teil eines anderen Modells aufgefasst werden kann. Bei einem Teilmodell kann es sich in diesem Sinne sowohl um ein in sich abgeschlossenes, eigenständiges Modell handeln, als auch um ein Modellfragment. Ein Beispiel für partOf-Beziehungen sind die von fast allen Modellierungssprachen zur Verfügung gestellten Konstrukte zur Desaggregation von Detailmodellen, die als Teil des übergeordneten Modells aufzufassen sind. Der Beziehungstyp isRelatedTo wird weiter spezialisiert in eine Implementierungsbeziehung isImplementationModelOf, eine Detaillierungsbeziehung isDetailedModelOf, eine Verknüpfungsbeziehung isConnectedTo und eine Ableitungsbeziehung isDerivedFrom. Die Implementierungsbeziehung isImple mentationModelOf drückt aus, dass ein Modell die computergestützt ausführbare Umsetzung der Strukturen eines anderen Modells ist. Hierzu können dem ausführbaren Modell weitere Strukturen bzw. Informationen hinzugefügt werden. Ein Beispiel für diese Beziehung bildet ein BPEL-Modell, das ein Implementierungsmodell des korrespondierenden BPMN-Modells ist. Bei der Detaillierungsbeziehung besitzt das referenzierende Modell ebenfalls mehr Einzelheiten als das über die Relation isDetailedModelOf referenzierte Modell. Im Unterschied zur Implementierungsbeziehung dienen diese zusätzlichen Details jedoch primär einer detaillierten Erfassung des Gegenstandsbereiches des Modells. Die Verknüpfungsbeziehung isConnectedTo gestattet die Repräsentation beliebiger Verbindungen zwischen Modellen. Ein Beispiel hierfür ist die Repräsentation der Beziehungen zwischen Modellen, die über Prozessschnittstellen miteinander verbunden sind. Mit der Ableitungsbeziehung isDerivedFrom kann der Sachverhalt repräsentiert werden, dass ein Modell durch einen Vorgang der Adaption aus einem anderen Modell hervorgegangen ist. Dieser Beziehungstyp kann weiter spezialisiert werden in die Beziehungstypen containsModel, isAnalogousTo, isConfigurationOf, isInstantiationOf und isSpecializationOf, die mit den in der Referenzmodellierung üblichen Konstruktionstechniken Aggregation, Analogiekonstruktion, Konfiguration, Instanziierung und Spezialisierung korrespondieren. Grundlegende Modellattribute sind die Beschreibungssicht (z. B. Prozesse und Daten), die Beschreibungsebene (z. B. Fachkonzept), die verwendete Sprache (z. B. EPK) und die Sichtbarkeit eines Modells innerhalb und außerhalb der Grenzen einer Organisation (z. B. öffentlich). Die genannten Attribute können über entsprechende Beziehungstypen zwischen der Klasse Modell und den Klassen DescriptionView, DescriptionLevel, Language und Visibility repräsentiert werden. Der praktische Einsatz der zuvor entwickelten Metadatenstruktur wird anhand einer Benutzeroberfläche (GUI) als Teil einer prototypischen Implementierung verdeutlicht (Abbildung 2). 679 Abbildung 2: Benutzeroberfläche zur Anwendung der Metadatenstruktur Im linken oberen Bereich der GUI kann der Benutzer alternativ zur Benutzung der Suchfunktion relevante Modelle auch durch die Auswahl von Facetten auffinden, welche die Menge der im unteren Bereich unter „Items“ angezeigten Modelle einschränken. Der Hauptbereich der GUI zeigt eine Wikiseite zur Dokumentation eines Modells, die dessen Beziehungen zu anderen Modellen mit einschließt. Nach der Beschreibung des Modells im Bereich „Description“ erfolgt unter „References“ eine Anzeige der Modellrelationen, die mit Hilfe der in Abbildung 1 gezeigten Metadatenstruktur spezifiziert wurden. Bei den Modellrelationen handelt es sich um die in der Metadatenstruktur definierten Relationstypen isReleatedTo und partOf sowie um Ableitungen dieser Relationstypen. Die Anzeige der Relationstypen erfolgt als Link; hinter jedem Link ist die Anzahl der Modelle vermerkt, die mit dem betrachteten Modell über den jeweiligen Relationstyp in Verbindung stehen. Folgt ein Benutzer einem Link, so wird eine Liste der betreffenden Modelle angezeigt, aus der ein Benutzer ein ihn interessierendes Modell selektieren kann. Somit kann ein Nutzer des Wikis in der durch die Metadatenstruktur entstehenden netzartigen Verlinkung der Modelle navigieren. Zur Verbesserung der Übersichtlichkeit ist die Anzeige der Modellrelationen weiter nach eingehenden und ausgehenden Links sortiert. Eingehende Links entsprechen Modellrelationen, die auf anderen Modellen auftreten und das betrachtete Modell als Ziel der Relation referenzieren. Ausgehende Modellrelationen entsprechen Relationen, die auf dem betrachteten Modell auftreten und als Ziel andere Modelle referenzieren. Weitere Metadaten über ein Modell werden in einer Infobox „Model Profile“ angezeigt. Die Überschriften, wie „Description Level“, entsprechen den Modellattributen, die in der Metadatenstruktur (Abbildung 1) definiert sind. Die Ausprägungen dieser Attribute werden jeweils als Links angezeigt. Folgt der Benutzer einem Link, gelangt er auf eine Wikiseite, welche die entsprechende Ausprägung erläutert. Sämtliche Informationsbereiche, wie die Beschreibung eines Modells, Modellrelationen und Modellattribute, sind direkt editierbar. Somit können alle Inhalte jederzeit von den Benutzern weiterentwickelt werden. Über den Reiter „Discussion“ im oberen Bereich der GUI kann der Austausch der Benutzer unterstützt und über den Reiter „Version/History“ können Versionen eines Modells zum Nachvollziehen von Entwicklungsprozessen eingesehen werden. 680 5. Konklusion und Ausblick Eine Modellierungsaufgabe besitzt keine einzigartige, ihr immanente Lösung. Jedes Subjekt kann zu unterschiedlichen „gültigen“ Lösungen gelangen. Das Konstruktionsergebnis ist immer ein Konsens über das von den beteiligten Subjekten unterschiedlich wahrgenommene Modellobjekt. Um die Nachvollziehbarkeit des Erstellungsprozesses zu gewährleisten, müssen die Umstände der Modellierer, ihr Vorgehen und ihre Ergebnisse dokumentiert werden. Die Dokumentation dieser Metadaten kann durch semantische Wikis unterstützt werden. Im Vergleich zu den bislang im Prozessmanagement eingesetzten Modellierungswerkzeugen einerseits und „klassischen“ Wikis andererseits bietet der in diesem Beitrag beschriebene Einsatz von semantischen Wikis die folgenden Vorteile: – – – – Partizipativer und integrativer Ansatz: Durch die Verfügbarkeit der semantischen Wikis über einen Webbrowser ohne die Installation einer weiteren Software sowie durch die leichte Editierbarkeit von Wikiseiten wird die Hemmschwelle zur Mitarbeit bedeutend gesenkt. Die Ergebnisse von Modellierungsprojekten können somit von einer großen Anzahl von Mitarbeitern im Unternehmen entdeckt, diskutiert, bewertet und wiederverwendet werden. Inkrementelle Wissenserarbeitung und -teilung: Wikiseiten können mit ersten Ideen in Textform oder unvollständigen Modellen begonnen werden, die in einem Prozess der Verfeinerung und Konsolidierung schrittweise detaillierter ausgearbeitet werden. Jeder Schritt bleibt anhand einer Versionierung und/oder mit Hilfe von Diskussionsseiten jederzeit nachvollziehbar. Organische Strukturierung: Eine Strukturierung des Modellbestandes ist an keine festen Hierarchien gebunden und kann sich daher evolutionär entwickeln. Zwischen den Modellen können beliebige Beziehungen etabliert werden, die formal über eine Ontologie definiert und kontrolliert werden können. Semantische Navigation und Suche: Durch die Verwendung formaler Ontologien im Hintergrund der Wikiseiten wird die Navigation und Suche im Modellbestand verbessert. Somit kann bspw. untersucht werden, welche Modelle von der Änderung eines anderen betroffen sind, da im Wiki eine Ableitungsrelation zwischen den Modellen gespeichert wurde. Durch die Verwendung einer Inferenzmaschine können neue Zusammenhänge automatisiert geschlossen werden, was über die Möglichkeiten zur Suche und Navigation in traditionellen Modell-Repositorien deutlich hinausgeht. Aufgrund der oben genannten Potenziale semantischer Wikis zur Verbesserung der Kommunikation der am Prozessmanagement beteiligten Akteure und zur Externalisierung von implizitem Wissen über Beziehungen zwischen Modellen erscheint eine zukünftige Integration von klassischen Modellierungswerkzeugen mit semantischen Wikis äußerst vielversprechend. Eine offene Forschungsfrage ist hierbei allerdings, ob Wiki-Funktionalitäten in klassische Modellierungswerkzeuge zu integrieren sind oder ob Wikis um Funktionalitäten zur Modellierung erweitert werden sollten. 6. Literatur [1] OMG (Hrsg.): Business Process Modeling Notation Specification : Final Adopted Specification dtc/06–02–01. Needham : OMG, 2006 [2] Völkel, M. (Hrsg.): Proc. of the 1st Workshop on Semantic Wikis – From Wiki to Semantics (SemWiki2006), held at ESWC 2006, June 11–14, Budva, Montenegro [3] Hinkelmann, K. et al. (Hrsg.): Proc. of the Workshop on Semantics for Business Process Management, held at ESCW 2006, June 11–14, Budva, Montenegro, June 2006 [4] Hepp, M. et al. (Hrsg.): Proc. of the Workshop on Semantic Business Process and Product Lifecycle Management (SBPM 2007), held at ESWC 2007, June 3–7, Innsbruck, Austria, 2007 [5] Auer, S.; Dietzold, S.; Riechert, T.: OntoWiki – A Tool for Social, Semantic Collaboration. In: Cruz, I. F. et al. (Hrsg.): Proc. of the 5th Int‘l Semantic Web Conf. (ISWC 2006), November 5–9, Athens, Georgia, USA. Berlin : Springer, 2006, S. 736–749 681 [6] Aumueller, D.: Semantic authoring and retrieval within a Wiki. Demo Session at the 2nd Europ. Semantic Web Conf. (ESWC 2005), May 29–June 1, Heraklion, Greece, 2005 [7] Boudjlida, N. et al.: A practical experiment on semantic enrichment in a homogeneous environment, Deliverable DTG4.1, INTEROP Network of Excellence (IST–508 011), 2005 [8] Buffa, M. et al.: SweetWiki: A semantic wiki. In: Web Semantics: Science, Services and Agents on the World Wide Web 6 (2008), Nr. 1, S. 84 –97 [9] Buffa, M. et al.: SweetWiki : Semantic Web Enabled Technologies in Wiki. In: Proc. of the 1st Workshop on Semantic Wikis, held at ESWC 2006, June 11–14, Budva, Montenegro, 2006, S. 74 –88 [10] Delfmann, P.: Adaptive Referenzmodellierung. Berlin : Logos, 2006 [11] Delfmann, P.; Knackstedt, R.: Towards Tool Support for Information Model Variant Management – A Design Science Approach. In: Österle, H. et al. (Hrsg.): Proc. of the 15th Europ. Conf. on Information Systems. University of St. Gallen, 2007, S. 2098–2109 [12] Fettke, P.; Loos, P.: Referenzmodellierungsforschung. In: Wirtschaftsinformatik 46 (2004), Nr. 5, S. 331–340 [13] Fischer, J. et al.: Ideas and Improvements for Semantic Wikis. In: Sure, Y.; Domingue, J. (Hrsg.): Proc. of the 3rd Europ. Semantic Web Conf. (ESWC 2006), June 11–14, Budva, Montenegro. Berlin : Springer, 2006, S. 650–663 [14] Greiffenberg, S.: Methodenentwicklung in Wirtschaft und Verwaltung. Hamburg : Kovac, 2004 [15] Hahn, A.: Integration verteilter Produktmodelle durch Semantic-Web-Technologien. In: Wirtschaftsinformatik 47 (2005), Nr. 4, S. 278–284 [16] Hinkelmann, K.; Thönssen, B.; Probst, F.: Referenzmodellierung für E-Government-Services. In: Wirtschaftsinformatik 47 (2005), Nr. 5, S. 356–366 [17] Jørgensen, H. D.; Lillehagen, F.; Karlsen, D.: Collaborative Modelling and Metamodelling with the Enterprise Knowledge Architecture. In: Enterprise Modelling and Inform. Systems Architecture 1 (2005), Nr. 1, S. 36– 45 [18] Karagiannis, D.; Kühn, H.: Metamodelling Platforms. In: Bauknecht, K. et al. (Hrsg.): E-Commerce and Web Technologies : 3rd Int‘l Conf., Aix-en-Provence, Sept. 2–6, 2002, London : Springer, 2002, S. 182–196 [19] Kiesel, M.: Kaukolu: Hub of the Semantic Corporate Intranet. In: Proc. of the 1st Workshop on Semantic Wikis – From Wiki to Semantics, held at ESWC 2006, June 11–14, Budva, Montenegro, 2006, S. 31–32 [20] Krötzsch, M.; Schaffert, S.; Vrandecic, D.: Reasoning in Semantic Wikis. In: Reasoning Web. Berlin : Springer, 2007, S. 310–329 [21] Krötzsch, M.; Vrandecic, D.; Völkel, M.: Semantic MediaWiki. In: Aberer, K. (Hrsg.): Proc. of the 5th Int‘l Semantic Web Conf. (ISWC 2006), November 5–9, Athens, USA. Berlin : Springer, 2006, S. 935–942 [22] Kuhlen, R.; Seeger, T.; Strauch, D.: Grundlagen der praktischen Information und Dokumentation. Band 2: Glossar. 5. Aufl. München : Saur, 2004 [23] Kühn, H.; Bayer, F.; Junginger, S.; Karagiannis, D.: Enterprise Model Integration. In: Bauknecht, K. et al. (Hrsg.): Proc. of the 4th Int‘l Conf. EC-Web, Prague, Czech Rep., Sept. 2003. Berlin : Springer, 2003, S. 379–392 [24] Lippe, S.; Greiner, U.; Barros, A.: A Survey on State of the Art to Facilitate Modelling of Cross-Organisational Business Processes. In: Nüttgens, M.; Mendling, J. (Hrsg.): XML4BPM 2005, 01. März 2005, S. 7–22 [25] Ludwig, L.; O‘Sullivan, D.; Zhou, X.: Artificial Memory Prototype for Personal Semantic Subdocument Knowledge Management. Demo at the 3rd Int‘l Semantic Web Conf., Nov. 7–11, Hiroshima, Japan, 2004 [26] Oren, E.: A Semantic Wiki approach for integrated data access for different workflow meta-models, DERI Technical Report 2006–02–03, 2006 [27] Panagiotou, D.; Mentzas, G.: A comparison of Semantic Wiki Engines : Slides presented at the 22nd Europ. Conf. on Operational Research, July 2007, Prague, Czech Republic, 2007 [28] Prud‘hommeaux, E.; Seaborne, A.: SPARQL Query Language for RDF : W3C Recommendation 15 January 2008. W3C, 2008 [29] Rosemann, M.; van der Aalst, W.: A configurable reference modelling language. In: Information Systems 32 (2007), Nr. 1, S. 1–23 [30] Schaffert, S.: IkeWiki: A Semantic Wiki for Collaborative Knowledge Management. In: Proc. of the 1st international workshop on Semantic Technologies in Collaborative Applications (STICA 2006) [31] Souzis, A.: Building a Semantic Wiki. In: IEEE Intelligent Systems (2005), S. 87–91 [32] Thomas, O.: Design and Implementation of a Version Management System for Reference Modeling. In: Journal of Software 3 (2008), Nr. 1, S. 49–62 [33] Thomas, O.; Fellmann, M.: Semantic Business Process Management: Ontology-Based Process Modeling Using Event-Driven Process Chains. In: IBIS Journal 2 (2007), Nr. 1, S. 29– 44 [34] vom Brocke, J.: Referenzmodellierung. Berlin : Logos, 2003 [35] vom Brocke, J.; Buddendick, C.: Reusable Conceptual Models – Requirements Based on the Design Science Research Paradigm. In: Hevner, A. R. (Hrsg.): 1st Int‘l Conf. on Design Science Research in Information Systems and Technology : February 24 –25, 2006, Claremont, CA, 2006 [36] Weber, R.: Conceptual Modeling and Ontology: Possibilities and Pitfalls. In: Journal of Database Management 14 (2003), Nr. 3, S. 1–20 [37] Weber, R.: Ontological foundations of information systems. Melbourne : Coopers & Lybrand, 1997 682 PROCESS-ORIENTED SEMANTIC BUSINESS MODELING Ivan Markovic, Florian Hasibether, Sukesh Jain1, Nenad Stojanovic2 Abstract In process-driven organizations, process models are the basis on which their supporting processaware information systems are built. Process modeling today is a highly complex, time consuming and error-prone task. In this paper, we define the abstraction levels of process modeling and extract the business knowledge required for modeling a process. Further, we present a processoriented enterprise ontology framework for capturing all relevant aspects of process models. Finally, we provide a set of application scenarios to illustrate the usage of the ontology framework. In this way, we reduce the complexity of process modeling, enable improved enterprise transparency and help ensuring the quality of designed process models. 1. Introduction In the 1990s, process orientation was introduced [4] to achieve a holistic view on an enterprise, with business processes as the main instrument for organizing the operations of an enterprise [10]. The innumerable benefits of investing in business process techniques were demonstrated in efficiency, productivity, cost reduction, quality, faster results, standardization, and, above all, in the encouragement of innovation, leading to competitive advantage and client satisfaction [3]. This followed with the introduction of process-aware information systems (PAIS) [9] as means to support the information workers in performing business processes. PAIS are driven by explicit process models, which enable a better understanding of business processes, facilitate communication between business analysts and IT experts and serve as a basis for the management and execution of business processes. However, the sources of business knowledge that describe the processes of an organization are diverse and scattered in IT-supported processes, business documents, presentations and the heads of business people. Currently, there is no agreed upon meta-model which covers the representation of all relevant aspects of process models. On the other hand, Semantic Web (SW) technologies have shown the potential in integrating the knowledge coming from various sources by means of ontologies. In addition, SW provides concepts and tools for automated inference on the represented knowledge, which enables the provision of some additional services based on existing process knowledge. 1 SAP Research, Karlsruhe, Germany 2 FZI, Karlsruhe, Germany 683 The goal of this paper is to show how semantic technologies can facilitate structuring and modeling the knowledge related to business processes and to illustrate the benefits of evaluation on different levels of process modeling. To achieve this, we contribute with i) defining the abstraction levels of process modeling and process information in models, ii) presenting a formal model for capturing all relevant aspects of process models and iii) describing a set of application scenarios. The paper is structured as follows. Section 2 gives an overview of related work and identifies some open issues. In section 3, we discuss the notion of the process in more detail and provide a layering from high-level business concepts down to process models. Section 4 presents our formal model for capturing the knowledge related to business process design. We discuss the application scenarios of our formal model in section 5. Finally, section 6 summarizes our contribution and indicates the areas for future work. 2. Related work In this section we give an overview of the related work. We start with the conventional approaches and continue with the semantic-based ones. ARIS (Architecture of Integrated Information Systems) is a method for analyzing processes and taking a holistic view of process design, management, workflow, and application processing [2]. ARIS consists of five views: organizational view, data view, control view, function view, and product/service view. However, the conceptual model of ARIS does not provide formal semantics which allows only for syntax-based analysis of models. The Object Management Group (OMG) has been developing a set of business modeling standards for enabling business flexibility. Business Process Modeling Notation (BPMN)3 specification aims to define a standard modeling notation for business process models. Business Motivation Model (BMM) [11] standard provides a schema for modeling business plans. However, these standards do not cover all the relevant aspects and do not define the formal semantics of the concepts, attributes and relations defined in the specifications. This makes it impossible to perform automated inference on models created using these specifications. One of the earliest initiatives within the enterprise ontology approaches was the TOVE project [12] that aimed at development of a set of integrated ontologies for enterprise modeling. TOVE Common Sense Model of Enterprise included three levels: reference model with typical business functions (finance, sales, distribution, and administration), generic model (with such concepts as time, causality, space, resources), and concept model (e.g. role, property, structure). However, the granularity of developed ontologies may be perceived inconsistent what hampers their potential application. Enterprise Ontology (EO) [13] is a collection of terms and definitions relevant to business enterprises. It was developed as part of the Enterprise Project, with the aim to provide a framework for enterprise modeling. EO is divided into five parts: i) terms related to processes and planning, ii) terms related to organizational structure, iii) terms related to high-level planning for an enterprise, iv) terms relating to marketing and sales of goods and services and v) terms used to define the terms of the ontology together with a few terms related to time. It was first completed in natural language format and afterwards ported to Ontolingua [13]. Finally, in [6], a set of ontologies for Semantic Business Process Management [5] is proposed. This work gives a rather high-level overview of an ontology stack covering the full BPM lifecycle, based on the ARIS [2] 3 Object Management Group. Business Process Modeling Notation – BPMN 1.0. http://www.bpmn.org/, 2006. 684 methodology. However, in order to make use of it, the stack needs to be refined and enriched and some application scenarios need to be defined. The conventional approaches do not cover all aspects of process description (e.g. business motivation) and do not define formal semantics for the models, while enterprise ontology works fail to provide a process-centric view on the organization. Enterprise ontologies are also not available in any contemporarily recognized ontology language standard for which an efficient reasoner exists. Common weakness of all the works is that they do not provide process abstraction levels to reduce modeling complexity. 3. Process hierarchy and process information in models In this section we provide two viewpoints for structuring of process knowledge with the purpose of managing process complexity. In subsection 3.1 we present a way to deal with a company’s process landscape, starting from a motivational (strategic) level, by gradually enriching the process descriptions with more details (scenario level) until the level of concrete activities have been reached (operational level). Another method to deal with the aforementioned complexity is, to have a clear understanding what sorts of information an organization deals with. We therefore present a process-centric view on the organization in subsection 3.2. 3.1. Levels of abstraction Enterprise processes are highly complicated as they span across many functional areas, involve many actors, governed by enterprise policies, government regulations, etc. To model such a process with all information is highly complex and would also defy the principle of modeling itself. Hence enterprise processes are modeled with various levels of abstraction. Each level of abstraction models a viewpoint of the enterprise process with a certain level of details for a specific purpose (artifacts associated using dotted arrows in Figure 1). The topmost level usually gives a conceptual view and one can gradually drill down from it to more concrete and detailed processes, as indicated with bold arrows in Figure 1. There is no limit on the number of levels but modeling usually stops at the smallest business relevant activity which has no further process level below. Inspired by SAP Business Maps4 we visualize the levels of abstraction with a pyramid-like structure, as shown in the Figure 1. We have found six different abstraction layers which we are describing in the following. Business Motivation forms the top most layer of the pyramid. It models the various driving forces (i.e. goals, strategies, metrics, etc.) of the enterprise and the relationships between them (cf. top left of Figure 1). The business motivation model is then structured along the industry-specific value chain. The value chain is composed of a sequence of value-creating functional areas - so called value chain elements. It starts from a supplier and ends in a consumer. The top right of Figure 1 shows the telecommunication industry value chain with its value chain elements. A Business Scenario Group is a collection of business scenarios with the same business goals. It can span across several functional areas (cf. center of Figure 1) and sometimes also integrates consumers and suppliers delimitating a value chain. A Business Scenario is a set of logically related business processes performed to achieve defined and measurable business objectives. Each Business scenario is associated with metrics (key performance indicators) as efficiency benchmarks as shown for Lead and Opportunity Management scenario in center right of Figure 1. A Business Process is a 4 SAP Business Maps comprise the content delivered with the SAP Solution Composer, which is a modeling tool freely provided by SAP for creating and browsing business-related diagrams. As a result of evolutionary adoptions and alignments of their content, the Business Maps offer a representative snapshot of the concepts and terminology perceived and applied in every-day business. http://www.sap.com/solutions/businessmaps/index.epx. 685 set of operations within a business scenario. All Business processes follow a well defined flow in order to achieve the business objectives of its scenario. A Business Process Step represents an operation of a business process that performs a defined function. The bottom right part of Figure 1 shows the process steps of the Lead Processing process. All business process steps are connected in a business logical flow in order to fulfill the purpose of the business process. Legend Belongs To Actor has a Business Motivation Refinement is driven by Telecommunications - EDITION 2008 SAP SOLUTION MAP Suppliers Design & Build & Partners Infrastructure Operate Infrastructure Develop & Promote Products & Sell & Fulfill Services Bill & Collect Assist Customers Customers & Channels Network Life-Cycle Management Goal Marketing Analytics & Product Management Strategy affects assigned to Sales & Service Fulfillment Dealer Management Metrics Industry Value Chain assigned to Influencer Billing, Invoicing & Presentment Customer Financials Management e.g. Telecommunications Customer Service Sales & Service Fulfillment Business Scenario Group e.g. Sales & Service Fulfillment BUSINESS SCENARIO GROUP Suppliers Design & Operate & Build Infrastructure Partners Infrastructure Develop & Promote Products & Services Sell & Fulfill Bill & Assist Customers & Collect Customers Channels Sales & Service Fulfillment Lead and Opportunity Management LEAD AND OPPORTUNITY MANAGEMENT SCENARIO Business Objectives: Improving Customer Service • Support multi-channel interaction Increase Speed & Efficiency • Automate - eliminate errors due to manual processes Increasing Transparency & Accountability • Increase data transparency • Provide decision support Reducing Operating Costs & Increasing Efficiency • Reduce administration, improve business processes Sales and Order Management Customer Field Service Management Business Scenario Key Performance Indicators: Logistics Management • Sales • Salesperson's Time Spent Selling (Percentage) • Sales Cycle Time (Orders) e.g. Lead & Opportunity Management Business Process Business Process Step Business Processes: This process enables manual and automatic qualification of leads. Lead Lead processing also includes the creation of a business Processing transaction, such as an opportunity, from a lead. e.g. Lead Processing e.g. Qualify Lead Lead Analysis Analyzes the success, efficiency, and processing over time of leads. Create or Generate Lead Assign products or product categories Qualify lead (manually or based on survey) Distribute lead to employee or external partner Follow up on lead and create opportunity + + + + + ~ Figure 1: Processes at different levels of abstraction Business Process Frameworks5, which are becoming popular in companies, serve the similar purpose. They provide a common language, a set of high level processes and its associated metrics which one can use as a template to quickly and easily define new processes or evaluate and improve existing ones based on the provided metrics. Some of the best known examples are Supply Chain Council’s SCOR (Supply Chain Operation Reference model), TeleManagement Forum’s eTOM framework and the Value Chain Group’s VRM (Value Reference Model). Business Process Frameworks correspond to Business Scenario Group, Business Scenario and Business Process levels within our abstraction levels. 3.2. Process information in models In this section, we give an overview on the different information artifacts depicted in Figure 2 from a process-centric perspective. The process flow could be seen as the core of a process representation and means the business logical sequence of activities and their dependencies from end to end. As processes essentially are 5 http://www.bptrends.com/publicationfiles/spotlight_052008.pdf 686 transformations that manipulate objects (e.g. create, change or delete) it is relevant for the process to capture information on these and the states they take on during the transformation. From a systems perspective objects might form the source for system data. Technology can be seen as an enabler for certain steps in the process in terms of persistency and efficiency. Also, in a tight connection to the questions on objects and data are the media used in a process. This is especially interesting since often a medium forms a process differentiating characteristic. A process could be quite different, depending on the medium used, e.g. providing the customer of a telecommunication service with either an electronic or paper bill. To the collection of objects, technology and media we refer to as resources. A similar grouping under the label of stakeholders could be done for organizational units, roles and process owners. Given the end-to-end process perspective described in the first chapter, it is important to stress that processes run across one or more organizational units within a functional or divisional hierarchy. We define a role as task and responsibility bundle which is clearly distinguished from the person that is performing the role. It can be held by different persons and one person can hold several roles. Talking about roles and processes allows to easily talk about the tasks that should belong together or should be separated from a process perspective before mapping them to the organizational structure. The process owner as an accountable manager for the process end-to-end execution can be seen as a special role in the context of processes. Resources Stakeholders Purpose & Goal Strategy Why is the process performed? What principles govern the processes execution? Objects Key Performance Indicators (KPIs) Which measures indicate process performance? Media Roles Process Technology Which objects are used, modified, and produced? By which media do processes interact? Process Owner Who is responsible for the process? Which objects are used, modified, and produced? Which roles need to contribute to process execution? Organizational Units Process Flow Business Rules Compliance Which processes precede and follow? Which rules govern the business? Which tasks are needed to ensure compliance? Which organizational units contribute to the process execution? Figure 2: Process information in models Compliance is of high importance to nowadays businesses. These regulations especially impact processes as specific tasks in processes are required in order to fulfill regulatory requirements. Thus, in process design it is important to capture and explicitly mark these tasks. The process goal is the ultimate reason for the process existence and the purpose it serves. When formulating a process goal it is useful to already think about quantifiable results. The way to do this is to define appropriate key performance indicators along e.g. the dimensions time, cost or quality that measure the process and then determine corresponding values. A goal makes explicit where to go, a strategy shapes the way reaching a goal i.e. it channels efforts towards a goal. Business policies and business rules exist to control, guide and shape strategies. They define what can be done and what must not be done. For example, a decision rule for a specific business situation states which alternative should be chosen according to predefined decision criteria. A prioritizing rule applies when reserving resources. Business Policies differ from business rules in that they are less formally-structured [11]. Business rules are in practice not necessarily stated explicitly, but likely 687 incorporated into the process design [7]. The information associated to processes described in this chapter could be thought of as the answers to the questions illustrated in Figure 2. We can think of the process-centric knowledge depicted in Figure 2 as being present on each layer of the pyramid from Figure 1 in smaller or greater detail. Some parts of this knowledge tend to grow stronger as we move down the pyramid, e.g. process flow. Of course, high level knowledge such as strategic goals and core strategy plans do not vanish as we reach a level of higher detail. They get refined and superimposed by a more concrete view. Strategic goals grow to measurable and timed operational goals, strategic directions to detailed plans, etc. Viewing the pyramid from a bird's eye view gives the full perspective of a process in all its complexity. 4. Process-oriented enterprise ontology framework In section 3 we gave two viewpoints on process-oriented enterprise knowledge. Much of this knowledge can be captured with the help of modeling approaches such as ARIS [2] using Value Chain Diagrams (VCD), Event-driven Process Chain (EPC), as well as standard office software. These methods fail however, to capture the information’s fit in the abstraction hierarchy (see Figure 1) as well as to describe their interrelation in a formal way. There is no way to retrieve any knowledge from classical enterprise modeling, which is not explicitly stated. Therefore, we propose an integrated model which allows for a machine-accessible description of enterprise knowledge using an ontology framework6 (see Figure 3). In the following we describe the main components. Motivational Ontology layer Process-oriented Organizational Ontology layer Business Motivation Ontology Business Strategy Ontology Business Goal Ontology Business Metric Ontology Influencer Ontology Business Function Ontology Organizational Structure Ontology Business Role Ontology Organizational Unit Ontology Business Process Ontology Industry specific and domain layer Business Policy & Rule Ontology Business Resource Ontology imports YATOSP Use case ontologies Use case ontologies Use case ontologies Use case ontologies Figure 3: Ontology framework Business Motivation Ontology: This acts as an umbrella ontology to capture the concepts from the uppermost level in the hierarchy given by Figure 1. There are two fundamental questions, we believe are to be captured separately from the perspectives ‘what to reach’ and ‘how to reach it’. First, what is needed to achieve what the business wants to achieve? And second, why does each element of a company’s business plan exist? [11]. Since business modeling in the end is about cognition and action in order to create value, we establish the concept of an actor at the topmost 6 The ontologies can be found at http://www.ip-super.org/ontologies 688 level of the motivation ontology. Actors are the source of all business artifacts captured in the ontologies which import the business motivation ontology. For example, the motivation for setting up a goal is not there for itself but by the cognition of an actor. The sub-ontologies are as follows: Business Goal Ontology (BGO): Goals may explain why the processes exist in the organization; examples include customer satisfaction, growth, etc. BGO models a hierarchy of business goals and provides a set of relations between them to enable goal-based reasoning [7]. We distinguish between a strategic goal, which tend to be long term and defined qualitatively rather than quantitatively, and an operational goal which is a step along the way (a milestone) towards a strategic goal. Goals can conflict with each other (if they cannot be satisfied simultaneously) and can positively or negatively influence other goals. There can be different levels of influence between goals. Business Strategy Ontology: We think of a strategy as a plan to achieve a goal. Thus, a strategy channels effort towards a goal [11]. As for the goals set up by the company for achievement the plans how to achieve goals can be refined into sub-plans. A high level strategy usually channels effort towards a high level, most likely strategic (i.e. qualitative) goal and a more detailed plan channels effort towards an operational goal. This gives a coupling between strategy and goals by a means-end relationship, although is not necessarily 1:1 nor does it always connect strategies and goals on equal levels in a decomposition tree. Influencer Ontology: Following [11], we see an influencer as something that can cause changes that affect the enterprise in the employment of its means or achievement of its ends. Influencers may be internal or external. For example, external influencers could be a customer or a competitor, internal influencers could be habits or management prerogatives. Actions by market rivals will most likely have some sort of impact on an enterprise. An influence itself nevertheless, and therefore the change caused by an influencer, is neutral. Assessment is needed to judge how an enterprise reacts to change caused by influencers. Assessment would be an application of the presented ontology stack. The bases for judgments are metrics. Business Metric Ontology: This ontology models business metrics, in particular Key Performance Indicators (KPIs) as key metrics for getting information on the performance of a company. Metrics are assigned to goals (in order to monitor the achievement of goals) and to influencers (with the purpose to evaluate their impact on the organization). Business metrics (similar to goals) can be defined on multiple levels: strategic, operational and process level. Metrics assigned to goals are modeled in a hierarchical way, coupled with the goal hierarchy. Process-oriented Organizational Ontology: It aims at describing the environment in which process is carried out from the organization’s perspective. Therefore following [6], the processoriented organizational ontology should provide a basic vocabulary and structure for describing organizations, description of artifacts, define common types of divisions, roles, business resources, business policies and business functions that are utilized or involved in the process. The organizational ontologies provide a high level view of the organization and process-related space. Since this space is quite complex the organizational ontologies layer has been further logically divided into sub-ontologies, as depicted in the Figure 3, each of them describes different part of the process space. The sub-ontologies are as follows: Organizational Structure Ontology (OSO) (cf. top right of Figure 3) describes organizational structure (hierarchy) of a company in a domain independent way by providing the main structure and relations between them. Organizational Unit Ontology (OUO) provides specification of typical 689 units that may be found in a company. Along with Business Roles and Business Resources Ontologies, it provides extensions to OSO which is shown by the imports arrow in Figure 3. Business Role Ontology (BROnt) defines common roles that are found in an organization e.g. Designer, Process Modeler, IT Expert, CEO etc. Business Resource Ontology (BRO) describes applications and resources that should be spent when carrying out certain processes or that may be results of certain task in a process. Business Function Ontology (BFO) (cf. top right of Figure 3) provides hierarchy of different functions that may be carried out within the company. It is supposed to enable vendor and domain independent classification of company processes. Business Policy and Rule Ontology (BPRO) (cf. top right of Figure 3) allows modeling constraints/guidelines that govern the behavior of the process. It is designed in a generic way to support modeling constraints from a variety of internal and external regulations. Business Process Ontology (BPO): For describing the behavioral (dynamic) perspective of a process model we use a process algebra, the π-calculus. By using the π-calculus for representing the process behavior, we are also able to integrate existing tools and techniques for verification and simulation of processes in our framework. The dynamic perspective of a process model stands for process control- and dataflow, and we model it using the ontologized π-calculus. For more details on this ontology, we refer the reader to [8]. Note that our framework maps to the process-centric knowledge depicted in Figure 2 and hence correspond to the layers in the pyramid from Figure 1, as motivated in the last section. In order to demonstrate the applicability of our process-oriented enterprise ontology framework, within the SUPER7 project, we have applied our framework in the telecommunication domain. The bottom left part of Figure 3 shows the Industry specific and domain layer which imports (is specialization of) the framework. In our case, this layer consists of the telco industry-specific YATOSP [1] ontology and a set of domain-specific use case ontologies, used in describing various telco business scenarios. YATOSP ontology is based on the aforementioned eTOM business process framework. 5. Applications of the ontology framework Formal representation of process-oriented enterprise knowledge provides many advantages. We illustrate the benefits of using our ontology framework for business modeling in the following application scenarios. 5.1. Evaluation of Motivation Models Use case 1 – Check for completeness. When checking for completeness of the motivation model we are interested in whether necessary links between the modeling elements are actually specified. For example, a strategy brings an enterprise towards a goal and a goal is set up by an actor, e.g. an organizational unit. Therefore, for example, we check if for any goal g1 an actor is given as a stakeholder and a strategy is given which supports the goal. Use case 2 – Checking for conflicts and redundancy. Goal models are an important feature of our motivation modeling. Using properties and relations of the goal ontology we can specify the priority of goals g1 and g2 as well as the degree in which goal g1 supports or hinders goal g2. We say two goals are in conflict with one another if g1 is of lower priority than g2 and g1 hinders g2. A goal g1 subsumes another goal g2, if g2 is achieved when g1 is achieved. If both g1 and g2 are subgoals of a goal g, then g2 is redundant [7]. 7 http://www.ip-super.org 690 Use case 3 – Propagation of goal contribution. When analyzing motivation models, we might be interested in how entities in the model affect each other. We illustrate this on the example of business goal modeling. Each goal has a priority attached, reflecting its importance for the business. There can be multiple levels of priorities. Goals can be decomposed into subgoals, where priority tends to decrease within the lower levels of a goal tree. Besides decomposition we can state if either a goal g1 supports or hinders a goal g2, i.e. if it has a positive or negative influence. The degree of influence is quantified in percentages. Consider that we change the degree of influence of a goal g1 to another goal or its priority level. This will not only influence its direct neighboring goals, but also other goals in the model. We would like to see how this change propagates further in the goal tree and influences goal g2. By taking into account and accumulating the influence and priority levels of the goals which connect g1 with g2 in the goal tree, we are able to recompute the influence of g1 on g2. This is very convenient for what-if scenario analysis where we can see how a change in one part of the model influences the other. 5.2. Evaluation of Business Process Models Use case 1 – Check for consistency across models. The diverse nature of process information (see Figure 2) can result in inconsistency as this information is captured across various parts of the enterprise model. The ontology framework (see Figure 3) not only links different models by providing a common, structured and formalized vocabulary but also helps to detect inconsistency arising from information resulting by incorrect model usage. For example, the definition of relations such as assigning a business function to an organizational unit, roles that an employee is allowed to play, resources required for carrying out a business activity, involves concepts defined in multiple ontologies within the framework. Consistency check ensures that a business process model is annotated consistently with respect to the constraints modeled within the ontology framework Use case 2 – Behavioral checks on process models. Behavioral checks, such as ensuring certain order of execution between activities; can also be performed on process models as BPO is based on π-calculus process algebra. For example, the activity Quality check is to be performed only after the activity Produce product and before the activity Product delivery. Use case 3 – Checks on process model based on its context. Explicit capturing of contextual information about a process (business function, goal, resources used, etc.) can be used to recommend relevant business policies to be enforced on a given process. BPRO is used to capture contextual information related to policies like policy scope, goal, its applicability criteria, etc. By matching the contextual annotations of policies to the ones of processes, we can retrieve all relevant policies for enforcement. Business policies usually contain one or more business and/or information system rules which implement them. These rules can then be checked against the matching processes in order to ensure the compliance of processes to internal and external regulations. 5.3. Navigation through the process levels By creating a common model which integrates all relevant aspects of process representation (cf. Figure 3), we are able to browse through different levels of process hierarchy. This enables the top-down linkage and bottom-up traceability between business motivation concepts on the one and detailed process models on the other side. In order to illustrate the benefits which such an integrated view provides, we list some example queries that can be answered using our ontology framework: • • Query 1: Show me all processes that support a specific goal Query 2: Show me all metrics associated to a process/goal 691 • • • • • • Query 3: Filter goals on the basis of a given deadline and/or priority Query 4: Which organizational units are involved in a specific process? Query 5: Which processes use a specific resource? Query 6: Which processes is a specific business policy enforced on? Query 7: What processes are currently performed in a specific business function? Query 8: What influencers affect the employment of a specific strategy? Ability to pose such queries creates better enterprise transparency and enables improved change management when regulations or market situation alter. 6. Conclusions & Outlook In this paper, we have presented a process-oriented approach to business modeling supported by semantic technologies. First, we reduced the complexity of process modeling by proposing process abstraction layers and identifying the relevant aspects of process description. Further, we presented a process-oriented enterprise ontology framework which we validated in the telecommunication domain. The application scenarios of the framework described in section 5 show, how introducing formal semantics enables us to perform various types of evaluation on each level of process modeling in order to detect errors/inconsistencies early in the design. In section 5, we also demonstrate how an integrated process-centric view on an organization allows us to navigate its process space, improving enterprise transparency and change management. As our next step, we plan to implement the presented application scenarios in the SAP Research Maestro process modeling tool. In the long term, we aim to evaluate the benefits of our approach within a real-world industrial setting. 7. References [1] SUPER Project, YATOSP framework (draft). Deliverable 8.2., 2007. [2] DAVIS, R. and BRABÄNDER, E., ARIS Design Platform. Springer, Heidelberg, 2007. [3] GOULD, K. and DICKEN, C., Process as an asset. BPTrends, 2008. [4] HAMMER, M. and CHAMPY, C., Reengineering the Corporation: A Manifesto for Business Revolution. Harper Business, New York, 1993. [5] HEPP, M., LEYMANN, F., DOMINGUE, J., Wahler, A. and Fensel, D., Semantic business process management: A vision towards using semantic web services for business process management. In Proceedings of the ICEBE, 2005. [6] HEPP, M. and ROMAN, D., An ontology framework for semantic business process management. In Proceedings of the 8th international Conference Wirtschaftsinformatik, 2007. [7] MARKOVIC, I. and KOWALKIEWICZ, M., Linking business goals to process models in semantic business process modeling. In Proceedings of the 12th IEEE EDOC Conference, 2008. [8] MARKOVIC, I. and COSTA PEREIRA, A., Towards a formal framework for reuse in business process modeling. In semantics4ws: Proceedings of the 2nd International Workshop on Advances in Semantics for Web services, 2007. [9] TER HOFSTEDE, A.H., DUMAS, M. and VAN DER AALST, W.M., Process-Aware Information Systems: Bridging People and Software Through Process Technology. Wiley-Interscience, 2005. [10] WESKE, M., Business Process Management: Concepts, Languages, Architectures. Springer-Verlag Berlin Heidelberg, 2007. [11] OMG. Business Motivation Model, http://www.omg.org/docs/dtc/06-08-03.pdf, 2006. [12] Fox M. The TOVE Project: A common-sense model of the enterprise. In: Proceedings of the 5th IEA/AIE Conference, LNAI 604, Springer-Verlag, Berlin, pp 25-34, 1992. [13] Uschold M, King M, Moralee S, Zorgios Y. The Enterprise Ontology. The Knowledge Engineer Review 13(1). 692 IT-INFRASTRUKTUR FÜR BUSINESS SERVICES Aus der Verknüpfung von Geschäftsprozessen und den sie unterstützenden ITServices im Rahmen des Business Service Managements entstehen neue Anforderungen an die IT-Infrastruktur. Für ihre Erfüllung können insbesondere innovative Ansätze des Infrastrukturmanagements genutzt werden. Spezielle Fragen in diesem Kontext sind u.a., wie Anforderungen an die Verfügbarkeit von Geschäftsprozessen auf die Ebene der IT-Services kaskadiert werden können, und, ob Teile einer IT-Infrastruktur branchenspezifi sch zu gestalten sind. Natürlich müssen außerdem – wie bei allen Strukturüberlegungen im IT-Bereich – die Altsysteme berücksichtigt werden. Neue Aspekte ergeben sich auch für die IT-Governance sowie für die Wirtschaftlichkeitsbewertung von ITServices und der IT-Infrastruktur. Leitungsgremium: Stefan Eicker, Universität Duisburg-Essen (Federführender) Torsten Eymann, Universität Bayreuth Stefan Koch, Wirtschaftsuniversität Wien Erich Schikuta, Universität Wien Programmkomitee: Martin Bichler, Technische Universität München Jens Borchers, SCHUFA Holding AG Alfred Geiger, T-Systems Solutions for Research GmbH, Stuttgart Wolfgang Gentzsch, Deutsche D-Grid Initiative, Berlin Reinhard Jung, Universität Duisburg-Essen Frank Leymann, Universität Stuttgart Günter Müller, Albert-Ludwigs-Universität Freiburg Heinz Stockinger, Schweizerisches Institut für Bioinformatik, Lausanne Susanne Strahringer, Technische Universität Dresden ZIELORIENTIERTE DATENMODELLIERUNG FÜR ITILBASIERTE INTER-ORGANISATIONALE CONFIGURATION MANAGEMENT DATABASES Wolfgang Hommel1, Silvia Knittl2 Kurzfassung Die essentiellste Aufgabe des IT-Service-Managements (ITSM) ist die Ausrichtung der IT an Kundenbedürfnissen. Zunehmende Dynamik, Infrastrukturkomplexität und Regularien, beispielsweise Compliance-Richtlinien, erforden eine Werkzeugunterstützung des ITSM. Hierfür hat sich das Konzept einer ITIL-basierenden Configuration Management Database (CMDB) als Informationsnexus durchgesetzt. Wir diskutieren den Einsatz einer CMDB im Zusammenspiel mit inter-organisationalen Diensten; das zugrundeliegende Werkzeug bezeichnen wir als ioCMDB. Wir analysieren Anforderungen, die sich bei organisationsübergreifenden Anwendungsfällen an das verwendete Datenmodell ergeben und stellen eine Methodik zur zielorientierten Datenmodellierung vor. Darauf aufbauend stellen wir technische Komponenten zur Realisierung der Datensynchronisation zwischen organisationsinternen CMDBs und einer ioCMDB vor und diskutieren die resultierenden Mehrwerte. 1. Einleitung Durch die kontinuierlich steigende Komplexität von Informations- und Kommunikationstechnologie in Unternehmen und die immer stärkere Abhängigkeit wichtiger Geschäftsprozesse von der IT bekommen Governance, Risk-Management und Compliance (GRC) eine immer wichtigere Bedeutung. Durch das Business Alignment der IT muss die Ausrichtung der IT-Strategie an die Geschäftsstrategie und damit auch an GRC-Anforderungen gewährleistet werden. IT-Service-Management (ITSM) Rahmenwerke, wie z.B. die IT Infrastructure Library (ITIL) [7], definieren ITSM-Prozesse, um diese Zielsetzung zu unterstützen. Ein unabhängig von der Größe des Unternehmens essentieller Managementprozess ist hierbei das sogenannte Service Asset and Configuration Management (SACM). Das primäre Ziel von SACM ist es, die Geschäfts- und Kundenanforderungen bzgl. des Controllings zu unterstützen. Indem es akkurate Konfigurationsinformationen bereitstellt, dient es weiterhin allen anderen ITSM-Prozessen, z.B. dem Incident Management und dem Change Management. Für diese Aufgaben sieht das SACM als Werkzeug ein sogenanntes Configuration Management System (CMS) vor. Dieses beinhaltet als wesentliche 1 2 Leibniz-Rechenzentrum, Garching b.München, Germany Technische Universität München, Germany 695 Komponente eine integrierte Configuration Management Database (CMDB). Mit dieser werden Konfigurationselemente (Configuration Items, (CI)) und deren gegenseitige Beziehungen (Relationen) abgebildet. CIs umfassen hierbei Servicekomponenten, Finanzgegenstände (Assets), Release-Pläne, Personen, Server, Anwendungen, Daten usw. Der Trend zu Outsourcing bzw. kooperativer Diensterbringung, z.B. im Rahmen von Grid- und Cloud-Computing, stellt auch das GRC-Management vor neue Herausforderungen. Bei der betrieblichen Umsetzung ist eine geeignete Werkzeugunterstützung der organisationsübergreifenden ITSM-Prozesse erforderlich. Diese organisationsübergreifenden Aspekte wurden jedoch bisher von ITSM-Rahmenwerken oder auch von Werkzeugherstellern nicht oder nur unzureichend berücksichtigt. Anhand eines Szenarios werden wir im Folgenden motivieren, dass sich für organisationsübergreifend erbrachte IT-Dienste eine CMDB-basierte Werkzeug- und Prozessunterstützung eignet und kostengünstig realisieren lässt. Diesen Ansatz bezeichnen wir als interorganisationale CMDB (ioCMDB). In Abschnitt 2 zeigen wir, welche Auswirkungen der Einsatz einer ioCMDB auf die Datenmodellierung und das Zusammenspiel mit bestehenden CMDBs hat. Daraus abgeleitete, zur Realisierung notwendige technische Komponenten stellen wir in Abschnitt 2.4 vor; eine Zusammenfassung der bisherigen Ergebnisse und ein Ausblick auf unser weiteres Vorgehen schließen den Artikel ab. 1.1. Kooperativ erbrachte Dienste in multi-domain Umgebungen In diesem Abschnitt stellen wir exemplarisch ein Szenario für Dienste vor, die von mehreren Organisationen kooperativ erbracht werden, das aus dem Umfeld des Grid- und Cloud-Computings motiviert wurde. Abbildung 1 zeigt ein Schichtenmodell, dessen unterste Ebene die involvierten Organisationen samt ihren Ressourcen und Subservices darstellt. Die Benutzer, die in ihrer Gesamtheit als Community bezeichnet werden, nutzen jedoch nicht die einzelnen Ressourcen, sondern höherwertige inter-organisationale Dienste, die auf Basis einer Kooperation angeboten und z.B. durch Web-Service-Orchestrierung implementiert werden. Die gestrichelten Linien stellen beispielhaft die Abhängigkeit dieser Dienste von den jeweils lokal bereit gestellten Ressourcen dar, die z.B. durch den Einsatz web-basierter Frontends oder dedizierter Middleware zwar für den Benutzer, nicht aber für das integrierte Service Management transparent sind. Abbildung 1 Zusammenhang zwischen inter- und intra-organisationalen Diensten 696 Im Folgenden setzen wir die technischen Herausforderungen bei der transparenten Nutzung von inter-organisationalen Diensten vereinfachend als gelöst voraus (vgl. [3]) und fokusieren auf das ITSM solcher Dienste. So sind etwa im operativen Betrieb im Falle von Störungen Informationen über die gegenseitigen Subservice- und Ressourcenabhängigkeiten notwendig, damit Störungsmeldungen schnellstmöglich an den richtigen Ansprechpartner beim jeweiligen Betreiber weitergeleitet werden können. Für die Planung von Dienstzuteilungen ist es ferner von entscheidendem Vorteil, wenn auf Organisationsebene autonom geplante Änderungen oder Wartungsarbeiten, welche die inter-organisationalen Dienste beeinträchtigen können, bekannt sind und kommuniziert werden können. In der Praxis gibt es allerdings bisher keine Werkzeugunterstützung für ein solches interorganisationales ITSM (ioITSM). Daraus resultieren in der Praxis oft wesentliche Nachteile, z.B.: - Das Beheben von Störungen verzögert sich, da das inter-organisationale IncidentManagement (ioIncident-Management) erst die betroffene Organisation ermitteln muss. - Das Planen von Änderungen auf inter-organisationaler Dienstebene ist komplex, da eine aufwendige manuelle Koordination aller beteiligten Diensterbringer notwendig ist. - Autonom auf Organisationsebene durchgeführte Änderungen können bei mangelnder Berücksichtigung von Abhängigkeiten inter-organisationale Dienste massiv beeinträchtigen. Im folgenden Abschnitt stellen wir als Lösung dieser Herausforderungen das Konzept einer ioCMDB vor, deren Datenmodellierung den Schwerpunkt dieses Artikels bildet. 1.2. Inter-organisationale CMDB Abbildung 2 zeigt die Zusammenhänge des Managements von intra- und inter-organisationalen Diensten bzw. Ressourcen. Jede Organisation verwaltet ihre eigenen IT-Ressourcen autonom, wofür in den Organisationen i.A. schon ITSM-Werkzeuge im Einsatz sind. Die Organisationen verwalten auch ihre IT-Services autonom, wofür CMDBs eingesetzt werden können. Zur Unterstützung des ioITSM wird eine ioCMDB eingesetzt, in die, wie im nachfolgenden Abschnitt erläutert wird, auch relevante Informationen aus den jeweiligen CMDBs der Organisationen eingespeist werden. Abbildung 2 Zusammenspiel von intra- und inter-organisationalem IT Service Management 697 2. Datenmodellierung und Zusammenspiel mit lokalen CMDBs Bereits bei organisationsinternen CMDB-Implementierungen ist die konkrete Modellierung der CIs und ihrer typisierten Beziehungen keine triviale Aufgabe. Meist wird ein objektorientierter Modellierungsansatz gewählt, der Klassen abzubildender realer Objekte und deren beschreibende Eigenschaften festlegt (vgl. [1], [8]). Dieser wird vorrangig aus Performanzgründen oft auf ein relationales Datenbankschema abgebildet. In der Praxis ist dabei die Entwicklung zu beobachten, dass ebenfalls aus Gründen der Geschwindigkeit analog zu Data Warehousing Verfahren zunehmend denormalisierte Schemata eingesetzt werden [9]. Für die Entwicklung einer ioCMDB ist jedoch insbesondere zu berücksichtigen, dass die bereits vorhandenen CMDBs zwar über standardisierte Schnittstellen zum Zugriff auf die Daten verfügen mögen, es aber kein einheitliches, standardisiertes Datenmodell gibt. Selbst falls entsprechende Standards verabschiedet werden und sich in der Praxis langfristig durchsetzen sollten, müsste jede organisationsübergreifende Lösung flexibel genug sein, um mit bereits vorhandenen, proprietären lokalen Datenmodellen umgehen zu können, um eine Integration zu ermöglichen. In diesem Abschnitt betrachten wir vier zusammenhängende Aspekte: Zunächst erläutern wir szenarienunabhängig, welche Daten lokaler CMDBs für den Aufbau und Betrieb einer ioCMDB relevant sind. Dann diskutieren wir eine Herangehensweise für das Schema-Design, also die für jedes Szenario spezifische Modellierung der ioCMDB-Daten. Darauf aufbauend zeigen wir den Zusammenhang zwischen lokalen CMDB- und ioCMDB-Daten und schlagen entsprechende Synchronisationsprozesse vor, für die wir eine Komponentenarchitektur zur technischen Umsetzung vorstellen. 2.1. Übernahme relevanter CMDB-Einträge Prinzipiell könnte der Datenbestand einer ioCMDB zur Unterstützung organisationsübergreifender ITSM-Prozesse mit genau allen dafür nötigen Informationen von Grund auf neu aufgebaut werden. Diese Methodik würde zwar selbst dann noch die Kompatibilität sicherstellen, wenn mindestens eine der beteiligten Organisationen keine lokale CMDB betreibt. Allerdings wäre es in der Praxis jedoch aus offensichtlichen Gründen ineffizient, bereits vorhandene, direkt zugängliche Informationen nicht zu nutzen und dafür in einem separaten System redundant zu akquirieren und zu pflegen. Zunächst ohne Berücksichtigung der technischen Realisierung und der vom Datenmodell her möglichen syntaktischen Inkompatibilitäten muss deshalb analysiert werden, welche in einer lokalen CMDB vorhandenen Daten in eine ioCMDB übernommen werden sollen. Ausschlaggebend sind hierfür einerseits die Relevanz der Daten für die ioITSM-Prozesse und andererseits aus dem GRCManagement resultierende Sicherheitsaspekte, z.B. der Schutz vor unbefugten Zugriffen durch die anderen Organisationen. Einen Lösungsansatz für den zweiten Aspekt haben wir bereits in einer früheren Arbeit vorgestellt und betrachten den Zugriffsschutz in diesem Artikel als gelöst [5]. Aufgrund der Beschränkung auf relevante Daten und wegen möglicherweise aus Sicherheitsgründen nicht zugänglichen Informationen ist jedoch auf das Problem von Dateninkonsistenzen durch die nur partielle Datenübernahme zu achten, d.h. dass einzelne Attribute von Objekten oder ganze Objekte, auf die sich Relationen zwischen CIs beziehen, fehlen können. Die Vollständigkeit der in einer ioCMDB-Instanz vorliegenden Daten bezüglich der durch ioITSM-Prozesse vorgegebenen Use Cases muss deshalb unbedingt durch einen geeigneten Qualitätsmanagementprozess nachhaltig sichergestellt werden und kann durch Automatismen nur partiell IT-unterstützt werden. 698 Die Bestimmung der von einer CMDB in eine ioCMDB zu übernehmenden Daten ist szenarienspezifisch, da die CIs und deren Attribute sowie die verwendeten Relationen zwangsweise dienst-, organisations- und kooperationsspezifisch sind. Wir erläutern deshalb im Folgenden anhand einiger ausgewählter Beispiele und bewusst unvollständig, welche häufig gepflegten CIs, Attribute und Relationen zur Kandidatenmenge für die Aufnahme ins ioCMDB-Datenmodell gehören: - Relevante CIs: o Incident Records ausgewählter Zeiträume, wie etwa den „letzten X Wochen“. Diese Daten werden vom ioIncident-Management zur Bearbeitung von Anfragen zu aktuellen und jüngst zurückliegenden Vorfällen benötigt, sollen in der ioCMDB jedoch u.a. zur Minimierung von Betriebskosten nicht dauerhaft archiviert werden. o Ausgewählte Benutzerobjekte, insbesondere zur organisationsübergreifenden Bereitstellung von Kontaktdaten von Personen, die mit den ioITSM-Prozessen betraut sind oder als lokale ITSM- oder Serviceansprechpartner fungieren. o Change Records, speziell auch aus dem lokalen Forward Schedule of Changes (FSC nach ITIL), sofern die Veränderungen organisationsübergreifend relevante Dienste betreffen und beispielsweise zur Planung von Wartungszeiträumen relevant sind. o Alle Dienst-/Service- und Hardware-/Server-CIs, die organisationsübergreifend relevante Dienste und Subservices betreffen; hierbei sind neben statischen insbesondere auch dynamische Attribute relevant, die z.B. von Monitoring-Werkzeugen aktualisiert werden und z.B. über Verfügbarkeit und Auslastung informieren. o Dienstleistungsvereinbarungen (Service Level Agreements (SLAs)), soweit diese organisationsübergreifend relevante Dienste betreffen und z.B. zur Priorisierung von Incidents im Rahmen des ioIncident-Managements ausgewertet werden müssen. - Relevante Attribute: o Lokale Ansprechpartner bei Service- und Hardware-CIs, sofern diese auch im Rahmen der ioITSM-Prozesse kontaktiert werden sollen. o Objekt-Identifikatoren zur eindeutigen Zuordung von korrespondierenden Objekten in der lokalen CMDB und der ioCMDB (sog. Object Association). o Zeitstempel der letzten Änderung zur technischen Unterstützung des unten erläuterten technischen Synchronisationsprozesses. o Änderungshistorie, die analog zu den o.g. Incident Records auf einen Erfassungszeitraum, der nur die jüngere Vergangenheit betrifft, beschränkt sein sollte. - Relevante Beziehungen zwischen CIs: o Angaben zur Diensthierarchie (Services und deren Subservices bzw. Ressourcen) sowie ggf. weitere relevante Abhängigkeiten zwischen Diensten, um kausale Zusammenhänge z.B. bei Dienstausfällen identifizieren und kommunizieren zu können. o Angaben zur Dienstlokalisierung, z.B. „Dienst A läuft aktuell auf Maschine X“, die insbesondere zur Fehlerdiagnose beim Einsatz virtueller Maschinen, die dynamisch zwischen verschiedenen Hosts migriert werden können, relevant sind. Wie bei lokalen CMDBs gilt bei der Umsetzung die Daumenregel, dass eine kleine Menge an gut gepflegten Daten einer möglichst umfassenden Aggregation der vorhandenen Daten im Hinblick auf Nachhaltigkeit und Effizienz der Lösung als auch auf die Betriebskosten vorzuziehen ist. 2.2. Modellierung der ioCMDB CIs und Relationen Durch die fehlende Datenmodell-Standardisierung bei den organisationsintern eingesetzten CMDBs kommt es bei einer organisationsübergreifenden Betrachtung in der Praxis zu unterschiedlichen CMDB-Schemata, die bezüglich der ausgewählten CIs, Attribute und Relationen zu einem 699 gemeinsamen ioCMDB-Schema konsolidiert werden müssen. Die dabei als Basis notwendigen Vereinheitlichungen, z.B. bei der Wahl von Attributnamen, die Synonyme und Homonyme eliminieren müssen, sowie die syntaktische Umformung, z.B. von Datumsformaten oder Telefonnummern, werden von einer Vielzahl etablierter Methoden der Datenbankintegration unterstützt und deshalb hier nicht näher betrachtet. Wir fokussieren vielmehr auf die zur Sicherstellung der Interoperabilität notwendigen Schritte und insbesondere zusätzlichen Datenfelder, die sich nur in der ioCMDB, nicht jedoch in den lokalen CMDBs finden. Das Zusammenlegen der Daten aus einer potentiell beliebig großen Menge an Quellen muss durch eine Anreicherung des Datenmodells unterstützt werden, z.B.: - Zur Vermeidung von Kollisionen im Objektnamensraum (engl.: namespace clashes) muss die Organisationszugehörigkeit, beispielsweise durch ein eindeutiges Präfix pro beteiligter Einrichtung, explizit erfasst werden. Dies betrifft sowohl systeminterne Identifikatoren, z.B. bei zwei CMDBs, die zwei verschiedene Entitäten über denselben Attributwert „id=12345“ identifizieren, als auch Attributwerte, z.B. bei Ortsangaben wie „Gebäude B, Raum 12“. Zur Umsetzung haben sich URN-basierte Ansätze als geeignet erwiesen, z.B. „id=urn:iocmdb:orgA.example.com:12345“. - Maßeinheiten sollten explizit angegeben werden, beispielsweise falls Strafzahlungen für SLA-Verletzungen in einer CMDB in Dollar und in einer anderen in Euro angegeben werden. Dadurch können Ungenauigkeiten, die sich durch ein wiederholtes Umwandeln in bzw. von einer einheitlichen Maßeinheit ergeben können, vermieden werden; diese sollten bei Bedarf von einer graphischen Managementoberfläche durchgeführt werden. Darüber hinaus müssen die ioITSM-Prozesse gezielt mit Informationen unterstützt werden, die erst mit der Teilnahme an organisationsübergreifenden Szenarien bedeutsam werden und deshalb u.U. auch nicht implizit aus den Daten der lokalen CMDBs abgeleitet werden können: - Für die ioITSM-spezifische Kommunikation und Datenweitergabe sind Ansprechpartner zu benennen, die ggf. von den für die organisationsinternen ITSM-Prozesse definierten Personen abweichen. - Die von ioITSM-spezifischen Rollen wie dem inter-organisationalen Service Desk erfassten Daten müssen geeignet auf ioCMDB-CIs abgebildet werden können, z.B. auf ioIncident Records und ioChange Requests. Die Modellierung der Attribute dieser CIs orientiert sich an ihren organisationsinternen Entsprechungen. - Alle in der ioCMDB gespeicherten Objekte benötigen Metadaten, die von denen ihrer Ursprungsobjekte separiert sind, beispielsweise den Identifikator des letzten Bearbeiters und den Zeitstempel der letzten Änderung. - Relationen zwischen den CIs der ioCMDB können organisationsübergreifend sein, d.h. Beziehungen über die Grenzen einer Einrichtung hinaus können in der ioCMDB hinterlegt werden, wohingegen das notwendige Zielobjekt in einer lokalen CMDB fehlen würde. Bereits hieraus ist ersichtlich, dass die Inbetriebnahme und Pflege einer ioCMDB nicht nur aus dem Zusammenschalten existierender Datenbanken besteht, sondern auch einen initialen und dauerhaften Verwaltungsaufwand für die Pflege dieser zusätzlichen Informationen bedeutet. 2.3. Prozesse zur Datensynchronisation zwischen ioCMDB und lokalen CMDBs Die Daten in der ioCMDB müssen immer möglichst aktuell gehalten werden, um beispielsweise Fehldiagnosen im ioIncident-Management zu vermeiden, die durch veraltete Daten entstehen würden. Klassische Bulk-Import-Verfahren, die u.a. im Umfeld des Data Warehousing und z.T. im 700 Rahmen von Business Integration Prozessen eingesetzt werden und dort beispielsweise einmal pro Nacht den gesamten Datenbestand aus dem Quellsystem übernehmen, notwendige Transformationen vornehmen und ins Zielsystem einspeisen, reichen deshalb nicht aus. Nachfolgend skizzieren wir einerseits ein effizienteres Verfahren zum Datenabgleich und diskutieren andererseits die Frage, ob der Datenabgleich zwischen den CMDBs und der ioCMDB im jeweiligen Szenario unidirektional oder bidirektional gestaltet werden sollte; dies beeinflusst insbesondere die Implementierungskosten, wirkt sich im Betrieb aber z.B. auf die notwendigen Maßnahmen zur Sicherstellung einer hohen Datenqualität aus. Der klassische ETL-Ansatz (Extract, Transform, Load, siehe [6]) steht vor der Schwierigkeit, dass immer der gesamte Datenbestand des Quellsystems nach relevanten Datensätzen, beispielsweise Änderungen seit dem letzten Synchronisationslauf, durchsucht werden muss; durch eine starke Erhöhung der Datenabgleichsfrequenz, beispielsweise alle fünf Minuten, wird zwar die Aktualität der Daten im Zielsystem verbessert, aber das Quellsystem einer unnötig hohen Last ausgesetzt. Insbesondere ist das Zeitintervall, in dem Datenabgleiche erfolgen, fixiert und passt sich nicht dem charakteristischen Nutzungsverhalten (z.B. tagsüber viele Änderungen, nachts nur wenige) an. Auch bei internen Abrechnungsmodellen, in deren Accountingfunktionen die Anzahl ausgeführter Datenbankanfragen eingeht, würden sich die Kosten mit der Datenaktualität vervielfachen. Aus diesem Grund schlagen wir einen ereignisgesteuerten Synchronisationsmechnismus vor, der durch das Einfügen, Modifizieren bzw. Löschen ganzer Datensätze oder einzelner Attribute ausgelöst wird und die Änderung, sofern sie für das Zielsystem relevant ist, zeitnah an dieses weitergibt. Die technische Umsetzung kann z.B. mit Hilfe von sog. Triggern und Stored Procedures in relationalen und objektorientierten Datenbankmanagementsystemen erfolgen, deren Implementierungskosten sich im Allgemeinen nicht von externen, z.B. JDBC-basierten ETL-Lösungen unterscheiden und durch die unmittelbare Integration in das Datenbanksystem typischerweise eine höhere Performanz aufweisen. Die technische Schnittstelle zwischen der lokalen CMDB und der ioCMDB besteht somit zunächst aus einem Mechanismus, der die entsprechenden Ereignisse zur Verfügung stellt; darauf baut ein parametrisierbares Filtersystem auf, das für das Zielsystem irrelevante Ereignisse verwirft. Anschließend müssen die Daten bei den Ereignisarten Einfügen und Modifizieren in das vom Zielsystem benötigte Format gewandelt werden und der Datenbestand im Zielsystem entsprechend aktualisiert werden. Dabei können Ausnahmebehandlungen notwendig werden, beispielsweise falls ein zu modifizierendes Objekt im Zielsystem noch nicht exisiert und somit neu angelegt statt nur verändert werden muss. Bei der Implementierung sind weitere Fehlersituationen, z.B. die temporäre Nichtverfügbarkeit des Zielsystems, zu berücksichtigen. Die oben diskutierte Bereitstellung von Daten aus den lokalen CMDBs zur Nutzung durch ioCMDB-unterstützte Prozesse impliziert, dass der Abgleich zwischen CMDB und ioCMDB auf jeden Fall in dieser Datenflussrichtung realisiert werden sollte. Die Implementierung eines Datenrückflusses von der ioCMDB in die jeweilige lokale CMDB kann je nach Szenario durchaus mit Synergieeffekten verknüpft sein, die den entstehenden Zusatzaufwand rechtfertigen; im Folgenden werden einige Mehrwerte dieses Use Cases skizziert. Bei den Datenrückflüssen ist prinzipiell zwischen den Nutzdaten, z.B. modifizierten Attributen von ioCMDB-CIs, und den Metadaten zu unterscheiden; zum Umfang der Metadaten zählen wir hier über den Dublin Core Standard [4], der z.B. Zeitstempel und Identifikator des letzten Bearbeiters umfasst, hinausgehend insbesondere auch Protokolldaten. Informationen bezüglich Benutzeraktivi701 täten anderer Einrichtungen auf ioCMDB-Daten aus lokalen CMDBs können zur Optimierung des ioCMDB-Datenbestands ausgewertet werden. Solche Aktivitäten sind z.B. Schreifzugriffe, Einzel-, Such- oder Batchoperationen und deren Kontext, z.B. im Rahmen einer ioIncident-Bearbeitung,. Außerdem bildet diese Informationen auch die Grundlage für die Integration in Auditierungs- und Risk-Management-Prozesse, die die ioCMDB nicht nur als isoliertes System betrachten. Bei der Übernahme von Nutzdaten aus der ioCMDB in eine CMDB sind einerseits aktualisierte Attribute von denjenigen CIs zu berücksichtigen, die ursprünglich aus dieser CMDB übernommen wurden. Zum anderen können auch in der ioCMDB neu angelegte CIs relevant sein, beispielsweise ioIncident-Records, deren Impact-Analyse Auswirkungen auf CIs ermittelt hat, die genau einer der beteiligten Organisationen zugeordnet werden können. Die Übernahme dieser Daten hängt jedoch auch davon ab, ob und wie stark die bereits organisationsintern vorhandenen ITSM-Prozesse so angepasst werden können, dass sie auch vom ioCMDB-Datenbestand Gebrauch machen. Sofern die verwendeten ITSM-Werkzeuge direkt an diese zusätzliche Datenquelle angebunden werden können, sollte der Mehraufwand für eine redundante Datenspeicherung vermieden werden. In diesem Fall ist jedoch mindestens auf organisatorischer Ebene zu klären, wie die ggf. notwendige (Langzeit-) Archivierung des ioCMDB-Datenbestands gehandhabt wird, um den jeweils aktuellen ioCMDB-Datenbestand möglichst schlank halten zu können. 2.4. Technische Komponenten zur Implementierung der Datensynchronisation Abbildung 3 zeigt ein einfaches Beispiel der für die Umsetzung des oben beschriebenen Synchronisationsprozesses benötigten Systemkomponenten. Jede Organisation hat eine lokale CMDB. Diese kann gegebenenfalls aus mehreren einzelnen Datenbanken oder den Repositories der vorhandenen Managementwerkzeuge bestehen, die intern zu einer sog. CMDB-Federation (CMDBf), wie sie vom CMDBf-Komitee spezifiziert wurde, zusammengeführt werden [2]. Die Kommunikation zwischen ITSM-Werkzeugen und der CMDB erfolgt typischerweise über JDBC oder Web Services und ist verallgemeinernd als Enterprise Service Bus (ESB) dargestellt. Nachrichten über Änderungen am CMDB-Datenbestand werden ebenfalls über den ESB an die neue, nachfolgend spezifizierte Komponente, die wir als ioCMDB-Konnektor bezeichnen, übermittelt. Falls die CMDB keine geeigneten Triggermechanismen unterstützt, um jeweils nur die Änderungen am Datenbestand zu melden, muss dem ioCMDB-Konnektor ein Wrapper vorgeschaltet werden, der Änderungen am CMDB-Datenbestand regelmäßig z.B. anhand von Objektzeitstempeln ermittelt und als Events an den ioCMDB-Konnektor weitergibt; wie oben erläutert wurde, sollte dies jedoch aus Lastgründen nur eine Fallback-Lösung darstellen. Die Verarbeitung der Daten im ioCMDB-Konnektor findet in mehreren Stufen statt. Zunächst werden Änderungen mittels eines Filters auf ihre Relevanz überprüft. Der Filter arbeitet regelbasiert, wobei umfangreichere Regelsätze zu sog. Policies zusammengefasst werden, die wie Policies für andere Dienste in einem Enterprise Policy Repository hinterlegt sind; jede Filterregel entscheidet anhand der Metadaten (z.B. CI eines bestimmten Typs) und der Attributwerte (z.B. Serverhardware, die einem organisationsübergreifend relevanten Dienst zugeordnet ist), ob die Änderung ans Zielsystem propagiert werden soll. Sofern mehrere Regeln für dasselbe Quellobjekt zutreffen, muss das Verhalten im Konfliktfall, d.h. bei einander widersprechenden Regeln, definiert werden. Für die Abbildung der Regeln auf ein maschinenlesbares Format stehen diverse, meist XML-basierte Policysprachen zur Auswahl, die hier nicht näher diskutiert werden. Im zweiten Schritt muss bestimmt werden, welches Objekt im Zielsystem von der aktuellen Operation betroffen ist. Dies umfasst einerseits die Transformation des lokalen Objektidentifikators 702 in denjenigen des Zielsystems, wofür wie oben erläutert z.B. Präfixe zum Einsatz kommen können; andererseits muss das Verhalten definiert werden, falls beispielsweise ein zu modifizierendes oder zu löschendes Objekt im Zielsystem nicht vorhanden ist. Auch bei diesen Konfigurationsparametern handelt es sich um Regelwerke, die im Policy Repository hinterlegt werden können. Daran anschließend sind in einem dritten Schritt sowohl Attributnamen als auch -werte in das Format des Zielsystems umzuwandeln. Wir schlagen hierfür den Einsatz eines XSLT-Prozessors vor. XSLT ist einerseits ein Standard zur Transformation von XML-basierten Daten, so dass die Implementierungskosten sowohl für den Datenkonverter als auch die szenarien-spezifischen Transformationsregeln gering sind, da z.B. Open Source Komponenten wie Xalan [10] eingesetzt werden können; andererseits ermöglicht eine XML-basierte Ausgabe die dynamische Ergänzung zusätzlicher Attribute im Zielsystem, beispielsweise wie oben diskutiert zur expliziten Angabe von Maß- und Kosteneinheiten. Dadurch können aufwendige Schema-Erweiterungen der lokalen CMDBs einfach vermieden werden. Schließlich werden die konvertierten Daten ins Zielsystem geschrieben bzw. ggf. die Löschoperation ausgeführt. Die Kommunikation erfolgt in unserem ioCMDB-Modell über Web Services; dabei muss konnektoren-seitig ein Puffer implementiert werden, der Änderungen bei temporärer Nichterreichbarkeit des Zielsystems zwischenspeichert. Exakt dieselben Schritte sind – mit entsprechend angepassten Parametern – auch bei Datenrückflüssen aus der ioCMDB in eine lokale CMDB zu durchlaufen. Ein Initialabgleich zwischen CMDB und ioCMDB kann angestoßen werden, indem für jedes Objekt im Quellsystem entweder ein Änderungsevent erzeugt oder eine triviale Änderung, z.B. ein Eintrag ins Historienattribut, durchgeführt wird. Die web-servicebasierte Kommunikation mit der ioCMDB sollte prinzipiell verschlüsselt erfolgen, da sensible Daten i.d.R. via Internet übertragen werden, und kann durch zusätzliche SecurityStandardmechanismen wie Firewalls dem Bedarf entsprechend abgesichert werden. Abbildung 3 Einsatz der ioCMDB-Konnektoren in einem einfachen Szenario 3. Zusammenfassung und Ausblick Dienste, die auf dem Zusammenwirken mehrerer Organisationen basieren, benötigen zur Umsetzung der komplexen Anforderungen des GRC-Managements eine gezielte Werkzeugunterstützung. In Anlehnung an die ITIL-basierte CMDB setzen wir hierzu eine inter-organisationale 703 CMDB (ioCMDB) ein. Wir haben ferner gezeigt, dass beim Deployment einer ioCMDB besonderes Augenmerk auf die Datenmodellierung zu richten ist, um für jedes Szenario eine kostengünstige und nachhaltige Lösung umzusetzen. Dabei ist explizit vorgesehen, dass die ioCMDB auch zusätzliche CIs aufnehmen kann, die in den lokalen CMDBs nicht vorhanden sind. Diesem Aspekt muss beim Schema-Design Rechnung getragen werden, wofür wir eine grundlegende Herangehensweise vorgestellt haben. Für den Austausch von Informationen zwischen CMDBs und ioCMDBs haben wir einen Prozess der Datensynchronisation vorgeschlagen, der Event-orientiert auf Basis von Web Services umgesetzt werden kann. Schließlich haben wir die notwendigen technischen Komponenten erläutert und dabei insbesondere den ioCMDB-Konnektor und seinen internen Workflow zur XSLT-basierten Verarbeitung der CI-Daten vertieft. Im Rahmen einer formalen Kooperation mit einer der Organisationen, die führend am CMDBfKomitee [2] beteiligt ist, streben wir an, unsere Konzepte zum organisationsübergreifenden CMDB-Einsatz in die aktuellen Standardisierungsbemühungen einfließen zu lassen. Parallel dazu wird an einer prototypischen Implementierung gearbeitet, mit der sich eine bestehende CMDB für den Einsatz als ioCMDB aufrüsten lässt. Danksagung: Die Autoren danken der IntegraTUM-Projektgruppe und dem Munich Network Management (MNM) Team für fruchtbare Diskussionen und Anregungen zu diesem Beitrag. IntegraTUM ist das Projekt der TUM zur Schaffung einer nahtlosen und benutzerfreundlichen IuKInfrastruktur, das von der DFG unter Vertragsnummer WGI 554 975 gefördert und vom Vizepräsidenten und CIO der TUM, Prof. Dr. Arndt Bode, geleitet wird. Das MNM-Team ist eine Forschungsgruppe mit Mitgliedern an der LMU, der TUM, der Universität der Bundeswehr München und dem LeibnizRechenzentrum der Bayerischen Akademie der Wissenschaften unter Leitung von Prof. Dr. HeinzGerd Hegering. 4. Literaturangaben [1] BMC Software, Best Practices for Modeling Business Entities in the BMC Atrium CMDB, Verfügbar online unter: www.bmc.com/products/documents/20/52/62052/62052.pdf, 2008. [2] CARLISLE, F. et. al. CMDB Federation (CMDBf) - Committee Draft. Technical report, BMC Software, CA, Fujitsu, Hewlett-Packard, IBM, Microsoft, Januar 2008. http://cmdbf.org/. [3] FOSTER, I., et. al. The Open Grid Services Architecture, Version 1.5. Informational Document, Global Grid Forum (GGF), July 24, 2006. [4] HILLMANN, D. Using Dublin Core. Verfügbar online unter http://dublincore.org/documents/usageguide/ . 2005 [5] HOMMEL, W. und KNITTL, S., An Inter–Organizational Configuration Management Database as Key Enabler for Future IT Service Management Processes , In eChallenges 2008, 2008, Stockholm, Schweden, Oktober, 2008 [6] KIMBALL, R. CAERTA, J. The Data Warehouse ETL Toolkit. Indianapolis, IN: Wiley. 2004 [7] MACFARLANE, Shirley. Service Transition, Itil, Version 3. Edinburgh: Stationery Office, 2007. [8] N(i)2. N(i)2 - MULTI-DOMAIN CMDB SYSTEM – White Paper, Verfügbar online unter http://ni2.com/, 2008. [9] SHIN, S. K. und SANDERS, G. L. 2006. Denormalization strategies for data retrieval from data warehouses. Decis. Support Syst. 42, 1 (Oct. 2006), 267-282. [10] The Apache Xalan Project. Verfügbar online unter http://xalan.apache.org/. Zugriff am 20.07.2008. 704 KONZEPTIONELLE METAMODELLE VON IT-GOVERNANCE-REFERENZMODELLEN ALS BASIS DER KOMBINATION UND INTEGRATION IN EINER MULTI-MODELL-UMGEBUNG Stefanie Alter, Matthias Goeken1 Kurzfassung In jüngster Zeit steht zur methodischen Unterstützung der Aufgaben der Unternehmens-IT eine stetig wachsende Anzahl von Referenzmodellen zur Verfügung. Aus verschiedenen Gründen können diese Referenzmodelle immer seltener isoliert voneinander betrachtet und eingesetzt werden. Vielmehr wird es für die IT-Abteilungen zu einer Herausforderung, das Zusammenspiel in einer „Multi-Modell-Umgebung“ [29] aktiv zu gestalten, um mit dieser Heterogenität umzugehen, bspw. weil die Modelle in Teilen redundante Anwendungsbereiche haben, Unterschiede hinsichtlich der zugrundeliegenden Sprachwelten aufweisen und auf verschiedenen Prinzipien beruhen. In der Praxis sind Vorschläge entwickelt worden, Modelle direkt ineinander abzubilden („Mapping“). Dieser Ansatz weist jedoch verschiedene Probleme auf. Als eine weitergehende und methodisch fundierte Art, mit den genannten Herausforderungen umzugehen, wird die Metamodellierung angesehen, durch die die genannten Modelle auch auf Ebene ihrer Komponenten und Strukturen analysiert, verglichen und integriert werden können. 1. Einführung Für Betrieb und Entwicklung von Anwendungssystemen bzw. IT-Infrastruktur sowie die damit zusammenhängenden Steuerungs- und Kontrollaufgaben sind gegenwärtig mannigfaltige Referenzmodelle, Best-Practice-Modelle und Standards verfügbar (im Folgenden einheitlich „Referenzmodell“2): Für die IT-Infrastruktur sind insbesondere die IT Infrastructure Library (ITIL) bzw. ISO 20000 für das Servicemanagement, die Control Objectives for Information and related Technology (COBIT) für IT-Governance (i. e. S.) und Audits sowie die verschiedenen Sicherheitsstandards (ISO 17799 bzw. 2700x sowie BSIGrundschutz) maßgeblich. Hinzu kommen u. a. Modelle für Entwicklung (CMMI) und Projektmanagement (PRINCE 2 und PMBOK) [15]. 1 Frankfurt School of Finance & Management. Für diesen Beitrag sind auch solche Referenzmodelle von Bedeutung, die nicht der IT-Governance i. e. S. zugeordnet werden. In Anlehnung an [15, S. 21 ff. sowie die dort angegebene Literatur] werden jedoch auch solche Modelle als „IT-Governance-Referenzmodelle“ bezeichnet, die außer Strukturen auch Prozesse und Techniken zur methodischen Unterstützung der genannten Aufgaben der Unternehmens-IT beschreiben. 2 705 In der Regel kommen in Unternehmen mehrere Referenzmodelle zum Teil oder vollständig nebeneinander zum Einsatz, um für die verschiedenen Anwendungsbereiche jeweils spezifische methodische Unterstützung zu erhalten. Da die Modelle jedoch zunehmend thematisch-inhaltliche Überlappungen aufweisen, wird die parallele, aber kontrolliertkombinierte Anwendung dieser Referenzmodelle zunehmend wichtiger, damit sie eine gemeinsame Steuerungswirkung entfalten können und sich nicht unterschiedliche, nicht kompatible Sprachwelten entwickeln. Daher wird die Integration oder Kombination der Modelle zu ganzheitlichen Referenzmodellen vermehrt gefordert [13,18]. In Literatur und Praxis gibt es eine Reihe von Ansätzen und Initiativen, mit dieser Modellvielfalt umzugehen [vgl. 15, S. 205 ff. und die dort angegebenen Quellen], was die hohe praktische Relevanz offenbart. Die Ansätze und Initiativen reichen von merkmalsbasierten Vergleichen, die den Gegenstandsbereich der Referenzmodelle charakterisieren und abgrenzen, bis hin zu umfangreichen „Mappings“, in denen jeweils angegeben ist, welche Bestandteile und Komponenten verschiedener Referenzmodelle miteinander korrespondieren bzw. sich ergänzen [11] Insbesondere in den „Mappings“ werden jeweils nur Teile und ausgewählte Komponenten der Modelle in die Betrachtung einbezogen. Gleichzeitig ergibt sich dabei eine enorme Detailtiefe, da die Betrachtung auf Ebene der Modelle selbst erfolgt. Ein Vergleich der den Modellen zugrundeliegenden Strukturen findet in der Regel nicht statt. Nach Ansicht der Verfasser fehlt eine methodische Fundierung für einen systematischen und abstrakten Vergleich sowie die Integration und Kombination der unterschiedlichen Modelle. Aus diesem Grund wird hier versucht, einen weitergehenden und ergänzenden Beitrag für den Umgang mit der Modellvielfalt zu leisten. Dieser stützt sich auf Metamodelle, die sich in anderen Bereichen der Wirtschaftsinformatik als hilfreich erwiesen haben, um die höhere Abstraktionsebene für einen Vergleich oder für die Integration zu nutzen [6, 32]. Sie erlauben aufgrund des abstrakteren Herangehens die Vernachlässigung von Details bei gleichzeitig ganzheitlicherer Sicht auf mehr oder alle relevanten Modellkomponenten. In Abschnitt 3 wird daher die Entwicklung eines Metamodells eines Best-Practice-Referenzmodells beschrieben. In Anlehnung an Ansätze aus dem Bereich der Schemaintegration von Datenbanken können - in einem weiteren Schritt - Korrespondenzen zwischen Metamodellkomponenten festgestellt werden, womit sich die Integration der konzeptionellen Metamodelle weitergehend unterstützen lässt. Zuvor erfolgt eine Beschreibung der „Multi-Modell-Umgebung“ in der ITGovernance (Abschnitt 2). Schlussfolgerungen sowie ein Ausblick auf weitere Forschungsarbeiten in Abschnitt 5 schließen diese Arbeit ab. 2. IT Governance: Eine Multi-Modell-Umgebung Die verfügbaren Referenzmodelle entsprechen unterschiedlichen Perspektiven auf die Unternehmens-IT. So wird beispielsweise COBIT [10] von Wirtschaftsprüfern und Auditoren bevorzugt, während im Bereich Systementwicklung CMMI [26] Verwendung findet. Der ITBetrieb wiederum hat seine Prozesse vielfach an ITIL [24] oder ISO 20000 ausgerichtet [19]. Die verschiedenen verwendeten Referenzmodelle stellen somit eine sogenannte „MultiModell-Umgebung“ dar [29]. Die Gründe für die Entwicklung dieser Multi-ModellUmgebung, die daraus resultierenden Herausforderungen sowie mögliche Lösungsansätze werden in diesem Abschnitt vorgestellt. Es ist vermehrt zu beobachten, dass der Gegenstandsbereich der Referenzmodelle wächst [13, 19], da die jeweils neuen Versionen der Referenzmodelle im Vergleich zu ihren Vorgängern 706 zumeist größere fachliche Bereiche abdecken. Beispielhaft sei hier die Veränderung von ITIL V2 zu ITIL V3 genannt: Während ITIL V2 sich primär auf Prozesse fokussierte, beschäftigt sich ITIL V3 zusätzlich mit Strategie (Service Strategy) und Optimierung (Continual Service Improvement). V3 nimmt darüber hinaus stärker als V2 die Integration der IT in das Business in den Fokus (Alignment) [23, 24]. Ähnliche Entwicklungen lassen sich bei CMMI und COBIT beobachten. Durch die Ausdehnung der Modelle ergeben sich so vermehrt Schnittmengen und Redundanzen bei Anwendung von vormals tendenziell spezialisierten und überschneidungsfreien Modellen. Ein weiterer Grund ist die Integration von Funktionsbereichen. Unternehmensbereiche wie beispielsweise die Entwicklung sind angehalten, mit anderen Unternehmensbereichen zusammenzuarbeiten. Durch abteilungsübergreifende Projekte müssen sich Mitarbeiter mit unterschiedlichen Referenzmodellen auseinandersetzen, den verschiedenen Modellen jeweils die relevanten Teile entnehmen und diese ad hoc kombinieren. Abbildung 1 zeigt die Multi-Modell-Umgebung aus dem Blickwinkel eines Prozessverbesserungsprojektes im IT-Bereich. Zur Realisation des Projektes werden Kenntnisse sowohl in domänen-spezifischen als auch in domänen-neutralen Modellen benötigt. Diese Modelle lassen sich zusätzlich in die Bereiche Governance und Organisationale Infrastruktur bzw. Bereitschaft einteilen. Solche übergreifenden Projekte sind ein weiterer Grund für das Entstehen einer Multi-Modell-Umgebung. Domänen neutral Organisationale Infrastruktur und Bereitschaft (einschließlich Geschäftspraktiken, Entwicklungsmethoden sowie Veränderungs- und Verbesserungsmethoden) EFQM Lean Six Sigma COBIT SOX ISO 9000 CMMI PRINCE 2 P-CMM ISO 12207 IT-Grundschutz SCOR ITIL SWEBOK Steigende Entscheidungsautorität der Verwendergruppe Governance (einschließlich externer Bestimmungen und Regulationen sowie intern beschlossener Governance) Domänen spezifisch Steigende Entscheidungsautorität der Verwendergruppe Abbildung 1 Multi Model Umgebung (In enger Anlehnung an [29]) Weiterhin können verschiedene Stakeholder des Unternehmens Promotoren oder Gegner einzelner Referenzmodelle sein, sodass deren Auswahl nicht immer streng ökonomisch und sachlich begründet verlaufen muss. Hiermit verwandt sind regulatorische Anforderungen (Compliance), welche Empfehlungen oder Verpflichtungen aussprechen, durch die die Verwendung von bestimmten, unterschiedlichen Modellen obligatorisch werden kann. Aus den genannten Gründen resultiert, dass sich die methodische Unterstützung durch Referenzmodelle als eine „Multi-Modell-Umgebung“ darstellt, woraus sich Unternehmen vor diverse Herausforderungen gestellt sehen. Bspw. führt die Verwendung von unterschiedlichen Referenzmodellen dazu, dass getrennte Sprachwelten entstehen.3 Außerdem können die 3 Besonders deutlich wird dies im Umfeld von COBIT [10, 11, 12] und CMMI [18, 26]. Ein Prozess und seine Ziele werden etwa im COBIT-Referenzmodell mit den Begriffen Process und Control Objective bezeichnet, während CMMI sie als Process Area und Specific Goal bzw. Specific Practice benennt. Ein COBIT Control 707 Anforderungen der verschiedenen Referenzmodelle an denselben Prozess kollidieren, indem unterschiedliche Schwerpunkte gesetzt oder Philosophien vertreten werden. Auch die Vorschläge zur Prozessausgestaltung können sich hinsichtlich der verantwortlichen Rollen und deren Aufgaben bzw. Rechte und Pflichten unterscheiden. Nennenswert sind außerdem die Anforderungen hinsichtlich der Compliance bei länderübergreifend agierenden Unternehmen. Diese und weitere Herausforderungen führen in den Unternehmen etwa zu Doppelarbeit, Mehrfachdokumentation oder auch redundanter Prozessmodellierung. Im Ergebnis erhöht der parallele Einsatz verschiedener Referenzmodelle so die Komplexität, und sie können keine gemeinsame Steuerungswirkung entfalten. Die Kombination oder Integration von Modellen kann eine Möglichkeit sein, den Herausforderungen der Multi-Modell-Umgebung zu begegnen. Praxisgeleitet gibt es – wie erwähnt – gegenwärtig mehrere Initiativen mit dem Ziel, die Referenzmodelle auf Ebene der Modelle aufeinander zu „mappen“, d. h. am Beispiel COBIT etwa auf Ebene der konkreten Control Objectives [siehe 15, S. 205 ff]. Ergebnis einer bereits abgeschlossenen MappingInitiative ist das ITIL-COBIT-Mapping des itSMF und der ISACA [14], welches Gemeinsamkeiten und Unterschiede verschiedener Modellkomponenten herausarbeitet. Aus der hierbei vorzufindenden Detailtiefe resultiert ein zum Teil schwer handhabbarer Umfang, bei [14] bspw. rd. 400 Seiten Mappingtabellen. Für die wissenschaftlich fundierte und stabile Integration ist es jedoch nach Auffassung der Autoren ratsam, die Referenzmodelle auch auf einer höheren Abstraktionsebene – der Metamodellebene – zu vergleichen, um so mögliche Ansatzpunkte für eine stabilere und handhabbarere Integration und Kombination herauszuarbeiten. 3. Konzeptionelle Metamodelle von IT-Governance-Referenzmodellen Der folgende Abschnitt beschäftigt sich mit konzeptionellen Metamodellen von ITGovernance-Referenzmodellen. In der Wirtschaftsinformatik werden Modelle genutzt, um von der Realität zu abstrahieren. Sind nun wiederum Modelle und nicht die reale Welt Gegenstand der Modellbildung, so werden Modelle von Modellen erstellt, welche als Metamodelle bezeichnet werden [32]. Da Metamodelle Modelle von Modellen sind, können zur Unterstützung Erkenntnisse aus der konzeptionellen Modellierung herangezogen werden. In Anlehnung an die Arbeiten von Becker, Schütte et al. [3, 27, 28] wird im folgenden Abschnitt der Erstellungsprozess von Metamodellen betrachtet. Abbildung 2 zeigt ein Metamodell des COBIT-Referenzmodells, anhand dessen die Entwicklung beispielhaft erläutert wird. Dieses Modell wird in Abschnitt 4 zur Illustration des Kombinations- und Integrationsprozesses verwendet (Zu einer genaueren Herleitung vergleiche [7, 8, 9]). In der Wirtschaftsinformatik ist die Tendenz zu erkennen, die Modellierungssprache zu fokussieren und deren Entwicklung zu forcieren [20, 21, 22, 32], während die Fragen des Vorgehens während des Modellierens weitgehend vernachlässigt werden. [33] bringen dies zum Ausdruck indem sie kritisieren, dass zwar der “way of modelling” bearbeitet wird, der “way of working” jedoch weitaus geringere Beachtung seitens der Wissenschaft erfährt. [21] bemerkt: „Recently, several software researchers and research groups have been proposing meta conceptual models. Although important results have been achieved, not much attention has been directed to the problem of filling the models, that is, instantiating the model with knowledge. Very little work has attacked the problem of bridging the gap from the real world Objective findet im CMMI keine exakte Entsprechung, kann aber im Umfeld der Begriffe Specific Goal und Specific Practice eingeordnet werden (siehe auch Abschnitt 4). 708 to the conceptual model.” Die erste grundlegende Frage ist daher: Wie kommt der Modellierer zum (Meta-) Modell? Oder anders: Wie kann das Wissen über das zu modellierende Objekt erlangt werden, das in das (Meta-)Modell eingehen soll? Role (1,*) is assigned to (1,*) Control Objective Activity (1,*) (1,1) (1,*) Control Practice (1,*) (0,*) Input is contained in uses / needs (1,1) IT-Resource Output is contained in is contained in isa (1,*) (1,4) Domain belongs to is used by (1,1) (1,1) (0,*) (0,*) (1,*) (1,1) Result (1,*) Process (0,*) supports has (1,1) Maturity Level (1,*) (1,5) (1,*) isa IT Governance Focus Area Goal (1,*) Activity Goal Information Criteria supports IT Goal Process Goal (1,7) (1,*) (1,*) is created by adresses is measured by is determined by (1,1) (1,*) Metric Maturity Model Abbildung 2 Ontologisches Metamodell von COBIT Der Modellierer kann als Brücke und Interpreter zwischen Realität und Modell bzw. zwischen Modell und Metamodell betrachtet werden. [5, S. 74] beschreibt die Modellierungssituation folgendermaßen: „Setzt man Modellierung mit Abbildung der Realität gleich, so würde nicht nur der Modellerstellungsvorgang trivialisiert - man bräuchte nur noch ein geschultes Auge und eine gewisse Auffassungsgabe für die Realität - , sondern man ginge von der impliziten Annahme aus, daß die Realität objektiv erkennbare Strukturen aufweisen würde.“ Vor diesem Hintergrund stellt sich die Frage, wie der Metamodellierungsprozess methodisch fundiert ablaufen kann. Hier ist kritisch zu analysieren, wie ein mehrere hundert Seiten umfassendes Referenzmodell durch eine strukturierte Vorgehensweise in ein Metamodell abgebildet werden kann. COBIT bspw. erleichtert den Metamodellierungsprozess durch die ihm innewohnende Struktur. Vereinfacht gesagt hat COBIT – im Sinne von [5] – eine „objektiv erkennbare Struktur“, die die Darstellung der Komponenten in einem Metamodell erleichtert. Allerdings stellt sich die Frage, ob die „objektiv erkennbaren Strukturen“ jeweils auch die semantisch gehaltvollsten sind. Soll jedoch für ein im Vergleich unstrukturierteres Modell wie ITIL ein Metamodell erstellt werden, ist die methodische Fundierung des Metaisierungsprozesses eine weitaus größere Herausforderung. Um von der Instanzebene über die Modellebene zur Ebene der Metamodelle zu kommen, werden Mechanismen für die Abstraktion benötigt. Im Rahmen der Metamodellierung abstrahiert der Modellierer ausgehend vom ursprünglichen Modell auf eine höhere ModellEbene, die Metamodellebene. Diesen Abstraktionsmechanismus nennt Strahringer [32] 709 Metaisierungsprinzip. Ein in der Wirtschaftsinformatik stark verbreiteter Mechanismus ist die linguistische Abstraktion. Dieses Metaisierungsprinzip wird beispielsweise verwendet, um eine Sprache abzubilden. Neben der sprachlichen Abstraktion gibt es weitere Möglichkeiten des Metaisierens. So betonen [17] und [1] die Möglichkeiten des ontologischen Metaisierens, das im Gegensatz zum sprachlichen Metaisieren eine Abbildung der Modellkomponenten aufgrund ihrer ontologischen Zusammenhänge darstellt. Für das COBIT-Metamodell wurde die ontologische Abstraktionsform verwendet, um die relevanten Komponenten der Referenzmodelle der IT-Governance zu beschreiben. Für den Benutzer des Metamodells kann es von Bedeutung sein, das Metaisierungsprinzip zu kennen, da insbesondere beim ontologischen Metaisierungsprinzip der Modellierer diverse subjektive Modellierungsentscheidungen treffen muss [16]. Hier ist es jedoch ausreichend, kurz auf das verwendete Metaisierungsprinzip hinzuweisen, etwa durch den Titel des Metamodells. Bereits eine Deklaration in der Bildunterschrift erleichtert dem Benutzer das Modellverständnis. Um Modelle bzw. Metamodelle für die weitere Forschung nutzbar zu machen, sollte nach Meinung der Verfasser die Qualität des Metamodells Beachtung finden. Die Bestimmung der Qualität von Modellen ist jedoch problematisch, wie das folgende Zitat von [3, S. 2] verdeutlicht: „Ein wichtiger Punkt ist … die Tatsache, dass die Richtigkeit von Modellen nicht letztendlich nachweisbar ist, sondern sich aus dem Diskurs der Sachkundigen und Gutwilligen ergibt, die ein Modell als zutreffend erachten“. Darüber hinausgehend wird vermehrt ein höheres Maß an Transparenz und Nachvollziehbarkeit beim Modellierungsprozess und bei der Evaluation von Modellierungsergebnissen gefordert. Insbesondere für letzteres können Erkenntnisse der Evaluation von konzeptionellen Modellen herangezogen und auf die Metamodellierung angepasst werden. Eine Möglichkeit zur Evaluation könnte beispielsweise die der pragmatischen Modellqualität sein. [22] evaluieren die pragmatische Qualität von Modellen mithilfe von Benutzerbefragungen und schließen von der Benutzerzufriedenheit auf die Qualität des Modells. Um diese Form der Evaluation jedoch für Metamodelle von Referenzmodellen der IT-Governance nutzen zu können, sind verschiedene Fragen zu analysieren. Beispielsweise die Frage, welche Art von Benutzer für eine Evaluation geeignet ist. Unabhängig von der Art der Evaluation kann jedoch festgehalten werden, dass erst Metamodelle von ausreichender Qualität zur Integration eingesetzt werden können. Zusammenfassend kann festgehalten werden, dass der Erstellungsprozess von Metamodellen methodisch fundiert erfolgen sollte, dass das Metaisierungsprinzip eines Modells ersichtlich sein muss und die Modelle evaluiert werden sollten. In dieser Form erstellte konzeptionelle Metamodelle von Referenzmodellen können - wie im folgenden Abschnitt beschrieben - zur Kombination und Integration eingesetzt werden. 4. Kombination und Integration von IT-Governance-Referenzmodellen mithilfe von Metamodellen Im Folgenden wird die Eignung von Metamodellen zur Kombination und Integration von Referenzmodellen erörtert. Die Möglichkeiten und Grenzen eines Metamodells als Hilfsmittel zur Kombination und Integration werden am Beispiel der Referenzmodelle COBIT 4.1 und CMMI dargestellt. Hierbei wird auf Verfahren der Schemaintegration von Datenbanken zurückgegriffen, deren Anwendung für den hier verfolgten Zweck zielführend erscheint. Das Ziel der Schemaintegration ist es, mehrere konzeptionelle Schemata in einem integrierten Schema zusammenzuführen. [2] definieren Schemaintegration als „… the process of merging 710 several conceptual schemas into a global conceptual schema… .“ Sie betonen weiter, dass das alleinige Auffinden gleicher Konstrukte und Konzepte nicht ausreicht. Vielmehr müssen Ähnlichkeiten und Unterschiede zwischen den Input-Schemata festgestellt werden. Da die Konstruktion eines globalen Modells auch der Zweck der Integration verschiedener (spezialisierter) Modelle sein kann, liegt eine ähnliche Zielsetzung vor. Darüber hinaus verweisen [2] darauf, dass Ähnlichkeiten und Unterschiede – auch Korrespondenzen genannt – in den zu integrierenden Modellen festgestellt werden müssen, um angemessen entscheiden zu können, ob entsprechende Modellkomponenten bspw. modifiziert in ein globales Schema eingehen können. Für das Zusammenführen von Modellfragmenten sind von [30, 31, 25] vier Aktivitäten vorgesehen, die im Folgenden am Beispiel eines Ausschnitts des vorgestellten COBITMetamodells und CMMI exemplarisch durchgeführt und diskutiert werden: (1) Vorintegration, (2) Vergleich und Konfliktidentifikation, (3) Anpassung und Überlagerung und (4) Restrukturierung- und Optimierungsphase. Ad (1) Vorintegration Im Rahmen der Vorintegration wird festgelegt, welche Modellkomponenten in welcher Reihenfolge konsolidiert werden sollen. Hierbei werden verschiedene Integrationsstrategien unterschieden, bei denen die zu integrierenden Modelle mit unterschiedlichem Gewicht eingehen. Wird die Erstellung eines globalen Modells angestrebt, so ist es Ziel, dass die unterschiedlichen Modelle gleichgewichtig eingehen. Anders wäre es, wenn ein Modell als Bezugspunkt genommen wird. Übertragen auf den hier vorliegenden Anwendungsfall bedeutet dies die Identifikation der zu integrierenden Modelle, des Ausmaßes der Integration und der Reihenfolge. In unserem Beispiel sollen COBIT 4.1 und CMMI gleichgewichtig integriert werden. Ausgangspunkt ist das COBIT-Modell ohne jegliche Erweiterungen [10 bzw. 8]. CMMI wird ebenfalls in seiner elementaren Form verwendet [27]. Ad (2) Vergleich und Konfliktidentifikation In der nächsten Phase erfolgt der Schemavergleich, bei dem Beziehungen zwischen den Elementen der Referenzmodelle identifiziert, analysiert und dokumentiert werden. Insbesondere sollen Konflikte und Inkonsistenzen aufgedeckt werden. Unterschieden werden in Anlehnung an [4] vier semantische Beziehungen: • Äquivalenz: Zwei Konstrukte zweier Modelle sind als äquivalent zu bezeichnen. • Überlappung: Zwei Konstrukte zweier Modelle bilden eine nichtleere Schnittmenge. • Einschluss/Teilmenge: Ein Konstrukt von einem Modell schließt ein Konstrukt eines anderen Modells vollständig ein. • Disjunktheit: Zwei Konstrukte zweier Modelle bilden eine leere Menge, stehen jedoch in einer für die Konsolidierung relevanten Beziehung. Welche der genannten Beziehungen vorliegt, muss einerseits über die Benennung der Modellelemente entschieden werden, wobei es gilt, mögliche semantische Defekte zu identifizieren (Synonyme, Homonyme). Eine tiefer gehende Integration und Analyse würde auch die Instanzen der jeweiligen (Meta-)Modellelemente einbeziehen. 711 Specific Practice und Sub Practice (Überlappung) Specific Practice und Sub Practice (Überlappung) Activity Control Objective is contained in Specific Practice und Sub Practice (Überlappung) is contained in Control Practice belongs to Domain Category (Extensionale Äquivalenz) is used by Result Work Products (Extensionale Äquivalenz) Process is created by Process Area (Extensionale Äquivalenz) is measured by has Maturity Level Capability (Extensionale Äquivalenz) Metric ohne Entsprechung (Disjunktheit) Abbildung 3 Vergleich von COBIT und CMMI Abbildung 3 zeigt einen Ausschnitt des COBIT-Metamodells aus Abbildung 2. Die einzelnen Konstrukte werden jeweils mit dem CMMI-Referenzmodell verglichen und gemäß den genannten semantischen Beziehungen gekennzeichnet. Beispielsweise kann die COBITKomponente Process als äquivalent zur CMMI-Komponente Process Area betrachtet werden. Demgegenüber gibt es in CMMI keine Entsprechung für die COBIT-Komponente Metric. Beispiele für Überlappungen sind CMMI Specific Practices, die Überschneidungen zu den COBIT Control Objectives aufweisen. Ad (3) Anpassung und Überlagerung Ziel dieser Aktivität ist es, die Modelle durch Mischen bzw. Überlagern in ein gemeinsames konzeptionelles Modell zu überführen. Hierbei kommen Integrationsregeln zum Einsatz, die festlegen, wie Modellelemente, zwischen denen eine Beziehung besteht, in dem globalen Modell abgebildet werden [4, 30, 31]. Für die verschiedenen vorliegenden semantischen Beziehungen können Integrationsregeln für die Bildung eines globalen Modells definiert werden. Bspw. kann bei Äquivalenz ein gemeinsames Modellelement in das globale Modell aufgenommen werden; bei Überlappung bietet sich die Bildung eines integrierenden, gemeinsamen Modellelements (ggf. mit neuem Bezeichner) an, welches beide Modellelemente semantisch voll umfasst; bei Disjunktheit kann entschieden werden, ob das Modellelement in dem konkreten Anwendungsfall Bedeutung hat oder ob es vernachlässigt werden kann. Letzteres kann bspw. mit Blick auf das Element Metric (Abbildung 2) erwogen werden. Process (bzw. Process Area) und Result (Work Product) können - nach entsprechender Entscheidung für die Benennung - unverändert in das globale Modell eingehen. Bei Activity und Control Objective ist ein differenzierteres Vorgehen möglich und die Aufteilung in mehrere Modellelemente erforderlich. Ad (4) Restrukturierung- und Optimierungsphase Schließlich können an dem Endergebnis oder den Zwischenergebnissen Restrukturierungen und/oder Optimierungen vorgenommen werden. Sind im Anschluss weitere Referenzmodelle zu integrieren, wird mit der Aktivität 2 fortgefahren. 712 Im Ergebnis sind so Korrespondenzen auf Ebene der Metamodellkomponenten identifiziert, wodurch sich zum einen ein höheres Maß an Transparenz und Vereinheitlichung der unterschiedlichen Sprachwelten ergibt. Zum anderen lässt sich auf Grundlage einer solchen Analyse ein kontrolliert-kombinierter und ggf. ein integrierter Einsatz verschiedener Referenzmodelle der IT-Governance fundierter gestalten. 5. Fazit und Ausblick Die Metamodellierung von Referenzmodellen stellt nach Meinung der Verfasser eine Möglichkeit dar, den beschriebenen Herausforderungen sinnvoll zu begegnen. Bevor jedoch Metamodelle zur Integration genutzt werden können, muss sicher gestellt sein, dass die Qualität der Modelle ausreichend ist, d.h. die Modelle müssen zunächst in einem methodisch gestützten Verfahren erstellt werden. Hinsichtlich der anschließenden Evaluation ergeben sich neben den bekannten Problemen der Evaluation von konzeptionellen Modellen spezielle Herausforderungen, die auf die Metaebene zurückzuführen sind. Ein weiterer notwendiger Schritt ist die Integration von mehreren heterogenen Referenzmodellen. Die Integration zweier Referenzmodelle, wie hier für COBIT und CMMI illustriert, ist lediglich der erste Schritt, um den Herausforderungen einer Multi-Modell-Umgebung zu begegnen. Ein generisches Metamodell, - das vergleichbar zu einer EAI-Applikation - die vorhandenen Modelle integriert und je nach Standpunkt auch als Metametamodell [32] bezeichnet werden kann, wird Gegenstand weiterer Forschungsbemühungen sein. Kritisch zu betrachten ist die Frage nach der Integration der Modelle auf der Ebene der Anwendung von Referenzmodellen (Ebene der Prozessbeschreibungen etc.). Die Integration von Modellen auf Metaebene ist nicht ohne weiteres auch auf der Modellebene anzuwenden. Die Veröffentlichungen der adressierten Referenzmodelle umfassen zum Teil mehrere hundert Seiten und beinhalten Prozess- und Rollenbeschreibungen, Hinweise und vieles weitere. Die Verfasser sind sich bewusst, dass die Metamodellierung hierfür lediglich einen Startpunkt darstellt. Die Integration auf der Ebene von Aktivitäten oder gar Teilaktivitäten kann durch Metamodelle nicht geleistet werden. Jedoch ist die Identifikation von Konflikten auf der Ebene der konzeptionellen Elemente eines Referenzmodells ein erster und entscheidender Schritt für eine Integration auf den nachgelagerten Ebenen. Auf Metaebene können so potentielle Kombinationspunkte ausfindig gemacht werden, welche eine spätere Kombination auf Modellebene erst ermöglichen. Weitere Forschungsbemühungen adressieren daher die gemeinsame toolgestützte Abbildung von Metamodellen und Modellen in einem semantischen Netz. Literaturverzeichnis [1] ATKINSON, C., KÜHNE, T., Model-Driven Development: A Metamodeling Foundation, IEEE Software, vol. 20, no. 5, pp. 36–41, 2003. [2] BATINI, C., LENZERINI, M.; NAVATHE, S.B., A Comparative analysis of methodologies for database schema integration. In: ACM Computing Surveys 18 (1986) 4, S. 323-364, 1986. [3] BECKER, J., ALGERMISSEN, L., Grundsätze ordnungsmäßiger Modellierung - Über Konstruktivisten, Handels-H's und Referenzmodelle, Arbeitsberichte des Instituts für Wirtschaftsinformatik,Westfälische Wilhelms-Universität Münster , 1994. [4] CONRAD, S., Schemaintegration. Integrationskonflikte, Lösungsansätze, aktuelle Herausforderungen, in: Informatik – Forschung und Entwicklung 17 (2002), pp. 101-111, 2002. [5] DRESBACH, S.: Epistemologische Überlegungen zu Modellen in der Wirtschaftsinformatik. In Becker, J., Schütte, R., Wendt, O., Zelewski, S. (Eds.): Wirtschaftsinformatik und Wissenschaftstheorie. Bestandsaufnahmen und Perspektiven. Wiesbaden, p. 71-94, 1999. [6] ESSER, M.; Komplexitätsbeherrschung in dynamischen Diskurswelten, Josef Eul Verlag, Köln 1999. [7] GOEKEN, M.; ALTER, S. Towards Conceptual Metamodeling of IT Governance Frameworks – Approach – Use- Benefits. Erscheint in: Proceedings of the Hawaii International Conference on System Sciences (HICSS’42), Waikoloa, Big Island, Hawaii 2009. 713 [8] GOEKEN, M.; ALTER, S., Representing IT Governance Frameworks as Metamodels, in: Proceedings of the 2008 International Conference on e-Learning, e-Business, Enterprise Information Systems, and eGovernment (EEE’08), World Congress in Computer Science (Worldcomp’08), July 14-17, Las Vegas Nevada 2008. [9] GOEKEN, M.; ALTER, S., IT Governance Frameworks as Methods, in: Proceedings of the 10th International Conference on Enterprise Information Systems (ICEIS 2008), June 12-16, Barcelona, Spain 2008. [10] IT GOVERNANCE INSTITUTE, COBIT 4.1, o.O. 2007. [11] IT GOVERNANCE INSTITUTE, COBIT Mapping, Overview of International IT Guidance, 2006. Unter: www.isaca.org, Abruf am 10.3.2007. [12] IT GOVERNANCE INSTITUTE, COBIT 4.0, o.O. 2006. [13] IT GOVERNANCE INSTITUTE, IT Governance Global Status Report, 2006. Verfügbar unter www.isaca.org, at; Abruf: 03.04.2007. [14] ITSMF und ISACA, ITIL-COBIT-Mapping, Gemeinsamkeiten und Unterschiede der IT-Standards, Symposion, Düsseldorf 2008. [15] JOHANNSEN, W.; GOEKEN, M., Referenzmodelle für IT-Governance, Heidelberg 2007. [16] KARAGIANNIS, D., KÜHN, H., Metamodeling Platforms, in: A. Min Tjoa, & G. Quirchmayer (Eds.), Lecture Notes in Computer Science: Vol. 2455. Proceedings of the Third International Conference EC-Web (pp. 451–464). Springer, 2002. [17] KARAGIANNIS, D., HÖFFERER, P., Metamodels in action: An overview. ICSOFT (1), 2006. [18] KNEUPER, R., CMMI, dpunktVerlag, Heidelberg 2007. [19] KPMG, Summary of KPMG IS Governance Survey. KPMG LLP, London, September 2004. [20] KURPJUWEIT, S.; WINTER, R., Viewpoint based Meta Model Engineering. EMISA 2007, pp 143-161, in: Manfred Reichert, Stefan Strecker, Klaus Turowski (Eds.): Enterprise Modelling and Information Systems Architectures - Concepts and Applications , Proceedings of the 2nd International Workshop on Enterprise Modelling and Information Systems Architectures (EMISA'07), October 8-9, 2007. LNI P-119 GI 2007. [21] LEITE, J.C.S.P.; FRANCO A.P.M., A strategy for conceptual model acquisition. In IEEE International Symposium on Requirements Engineering. IEEE Computer Society Press, Los Alamitos, CA, pp 243-246, 1993. [22] MAES, A., POELS, G., Evaluating quality of conceptual modelling scripts based on user perceptions, in: Data and Knowledge Engineering 63 (2007), p. 701-724. [23] OFFICE OF GOVERNMENT COMMERCE, ITIL V2, London 2000. [24] OFFICE OF GOVERNMENT COMMERCE, ITIL V3, London 2007. [25] RIZOPOULOS, N., McBRIEN, P., MAGNANI, M., MONTESI, D.: Schema Integration based on Uncertain Semantic Mappings, Conference or Workshop Paper, 24th International Conference on Conceptual Modeling (ER’05), Klagenfurt, Austria Lecture Notes in Computer Science,Volume 3716, pp.31–46, October 2005. [26] SOFTWARE ENGINEERING INSTITUTE, CMMI, 2007. [27] SCHÜTTE, R., Die neuen Grundsätze ordnungsmäßiger Modellierung, Paper zum Forschungsforum '97, 16.09.-20.09.1997 Leipzig 1997. [28] SCHÜTTE, R., ROTTHOWE, T., The Guidelines of Modeling- an approach to enhance the quality in information models. In Ling, Ram, Lee (Eds.) Conceptual Modeling – ER 98. Singapore, 16.-19.11.98, pp240-254, 1998. [29] SIVIY, J., KIRWAN, P., MARINO, L., MORLEY, J. Fünfteilige White Paper Serie zum Thema MultiModell-Umwelt, Unter: www.sei.cmu.edu/publications/pubweb.html, Abruf 10.07.2008. [30] SPACCAPIETRA, S., PARENT, C.; DUPONT, Y., Model Independent Assertions for Integration of Heterogeneous Schemas. VLDB Journal 1, 1, S. 81–126, 1992. [31] SPACCAPIETRA, S., PARENT, C., View Integration: A Step Forward in Solving Structural Conflicts. In: IEEE Transactions on Knowledge and Data Engineering 2, 6, S. 258-274, 1994. [32] STRAHRINGER; S., Metamodellierung als Instrument des Methodenvergleichs, Shaker Verlag, Aachen 1996. [33] VERHOEF, T.F., HOFSTEDE, A.H.M.T.; WIJERS; G.M., Structuring Modelling Knowledge for CASE Shells. In Andersen, R. et al. (Eds.): Proceedings of the third International Conference CAiSE’91 on Advanced Information Systems Engineering, pp. 502-524. 1991. 714 SOFTWAREENTWICKLUNGSMETHODEN Die Softwareentwicklung befindet sich im Umbruch. Neue Methoden und Technologien wie modellgetriebene Entwicklung, Extreme Programming, Web Services, Web 2.0, Open Source Ansätze und Wiederverwendung im Kleinen (Patterns) und im Grossen (Frameworks) verlangen von den SoftwareentwicklerInnen immer umfassendere Kompetenzen. Dabei spielt insbesondere die Kombination der verschiedenen Methoden eine bedeutende Rolle, um eine effektive und nachhaltige Verbesserung der Softwareentwicklung hinsichtlich Qualität und Zuverlässigkeit zu erzielen. Besonderes Augenmerk wird dabei auch auf entsprechende Ausbildungs- und Weiterbildungskonzepte gelegt, ohne die die korrespondierende organisatorische Umsetzung nicht möglich wäre. Leitungsgremium: Georg Herzwurm, Universität Stuttgart Matthias Jarke, Rheinisch-Westfälische Technische Hochschule Aachen Gertrude Kappel, Technische Universität Wien (Federführende) Frank Leymann, Universität Stuttgart Programmkomitee: Ruth Breu, Universität Innsbruck Peter Buxmann, Technische Universität Darmstadt Stefan Eicker, Universität Duisburg-Essen (Campus Essen) Gregor Engels, Universität Paderborn Michael Heiss, Siemens AG Österreich Jochen Küster, IBM Zürich Research Laboratory Barbara Paech, Universität Heidelberg Gustav Pomberger, Johannes Kepler Universität Linz ADJUSTMENT STRATEGIES FOR MANAGING UNANTICIPATED CHANGES IN SOFTWARE DEVELOPMENT PROCESSES Katja Andresen1, Norbert Gronau2 Abstract Software engineers face multiple challenges of managing unanticipated changes, dependencies, uncertainty, emerging demand patterns. In this contribution we focus on the process of software development and its design to especially cover unforeseen changes. The article presents a structural view on the (distributed) software engineering process introducing three domains that trigger adjustment opportunities of the engineering process. Hereafter the solution approach imposing the process model PEPMAD is outlined. 1 Introduction The software industry is acknowledged worldwide as a key driver of social and economic growth [28]. Software Engineering has been a research field since the late 60’s. The international conference on Software Engineering has been held regularly since 1975. Various meetings, events, journals and magazines are devoted to the topic of software engineering [28]. Nonetheless most modern approaches suffer from constraints that can be considered principles of the software engineering (as programming, testing, integrating). Of course, entire approaches emerged for which the motivation is to alleviate aspects. Nowadays advances address the building of selfadapting/managing/healing software systems [14]. Attempts are called automatic programming, constraint-based languages or aspect orientation to name a few Fehler! Verweisquelle konnte nicht gefunden werden.[19]. Hence new technologies are available to support the development of systems that respond more quickly and efficiently to a changing environment. However, most technology used to develop, maintain, and evolve software systems do not adequately cope with complexity, distribution and change [8], [16]. On the other hand, the capability to cope with changes is very often a unique selling proposition for software developing companies and essential for successful business. In this article the focus was laid on the engineering process that is being affected when changes need to be managed. The results stem from the research project “IOSEW”3 dedicated to explore the 1 University of Applied Science Berlin University of Potsdam 3 The research project IOSEW is funded by the Federal Ministry of Education and Research, Germany (IOSEW:01/SF 03). 2 717 link between flexibility strategies and (distributed) software product development. Four industrial partners that are small and medium sized contributed with specific software engineering processes and problems that provided the foundation for results. All of our industrial research partners develop and sell enterprise systems software. This contribution is organised as follows: first a short overview of the principles in software engineering process are given. The process is divided into time depended phases introducing change qualities. Afterwards a structural process view is presented dividing the process into sub-views that contribute to run-time adjustment. Then requirements and challenges in terms of optimization are discussed before the solution approach is presented. The section on recent developments points at influential research work. Finally, the results are summarized. 2 Characteristics of the Software Development Process The modern software paradigm requires basic activities. Although depths vary common initial planning activities comprise the definition of “ingredients” as engineering techniques such as specification, design, implementation et cetera. The selection of programming languages and basic project management methods are integral to modern software engineering. Along with that roles are assigned and a schedule is outlined in the initial planning process. During the course changes occur that may or may not have been foreseen, e.g. additional customer requirements, resource fluctuation and more [7]. If all options are known in advance only anticipated changes are to be planned for. However, common software engineering activities show a different picture. Table 1 provides typical adjustment challenges based on the research in IOSEW. Table 1: Typical requirements to design for adjustments Element A: Software development model B: Software development model / Actor C: Software development model D: Resource actor E: Environmental turbulence F: Environmental turbulence Challenges based on Case-Studies Unforeseen additional test phase Iteration of requirements analysis Combination of models, e.g. with development partners Key-Developer leaves company Top-Down Management Decision to cancel cooperation with external division Management decision about cooperation with new partner Design and Run-time considerations The examples undermine; in the design phase of the software engineering process the need for adjustment can not be fully foreseen or anticipated. Thus, the planning process takes all known and foreseen constraints into consideration. However, the goal is to design for unanticipated changes that may occur within the dynamic context of the process. The process should be enabled to adapt to changes during run-time. The differentiation between design-time and run-time is common in various approaches dealing with flexibility issues in systems and software techniques. Especially software systems are oftentimes characterized in this form [1], [6]. In software systems design issues as bandwidth, sensors, represent parameter that can individually adapt to environmental influences embedded in control loop constructions for instance [4]. The view helps to link qualities as flexibility, fault-tolerance, tempo of adjustment with initial (planned 718 for) behaviour and dynamic real-time performance of the software system. On one hand we use this perspective to differentiate between initial software process design and on the other to evaluate dynamic process behaviour; here unanticipated adaptation comes into play as unforeseen process variations are of importance. We consider the following research questions that are further discussed in this paper: 1. How can the complex task of designing an adjustable software engineering process be divided into subtasks that are more easily to manage? 2. How can the system be enabled to adapt for best output during run-time when unanticipated changes need to be addressed (goal-function). 3. Along with that how can the responsiveness be evaluated. Is there an easy way to integrate concepts into daily business? In the following section the software process is viewed thru the lens of increasing capability to adjust to changes. 3 Areas for Design and Run-Time Process Adjustment Generally, the systems approach is taken characterizing an information system. Figure 1 provides an unstructured overview of elements as the software development process, actors, organisational development and implementation techniques, relations between the arrangement of phases and the framework. The software (development) process itself is a structure typically comprised of the following steps: product and resource specification, development, implementation and release. For that a set of software development models exist describing approaches to activities that take place during the process. Actors as developers, members of the organisational and managing company structure as well as customers taking part in this process are involved. Phase 1 Phase 2 Phase 3 Phase.. Specif icat ion Developing Im plement at ion Release SE M odel SE Process Adapt ion request Act ors (dist rubut es) unit s decisions Figure 1: Elements of the Software Process To classify software processes the following system description follows a three layer approach that structures domains to analyse and influence adaptive behaviour: 1) elements 2) structural topology, and 3) decision area. 1) Elements of the systems describe all entities that are part of the software-engineering process. Each entity can be seen as parameter that is somehow adaptable to changing conditions. The degree of adaptable behaviour may be given by nature, e.g. the capabilities of actors to cope with changes. Others are determined by rules like building blocks and coverage of the chosen software development models. 719 A few scenarios (Table 1) can be realized if elements as correcting variable are considered. The test team in ‘A’ could respond to lacking software quality by integrating additional steps. Mastering the loss of a key-developer in D, integrating an additional phase into the waterfall model leads to limitations of adjustments purely based on adjustment of elements. The latter examples require structural changes. 2) The structural topology addresses the links between elements. The links can be dynamically established, changed or simply dropped during run-time of the software development process. Links represent communication flows between actors; the interconnection of phases (first x then y), tasks and sub-tasks. Process adjustments using structural topology require degrees of standardisation (as communication rules) to establish and deploy links. Also, modularity is a key to exchange and integrate elements. Roles therefore require clearly assigned profiles. Deploying modularity the process is structured into different stages to define variation points. Structural topology adjustment allows to completely revising the organisational set-up of the development process. However, elements (a phase, an actor) can be replaced without necessarily changing the structural topology. 3) The decision area refers to the (physical) distribution of elements. It relates to the area decisions to adapt are made. Distribution of elements raises the question of distributed (adaptable) process management. One of the features that are currently assigned to selforganizing systems is their decentralization [4]. Distributed adjustment involves further activities as distributed decision management and achievement strategies for desired global behaviour results. Decentralization of engineering processes may take different forms. Outsourcing, near- or off shoring are categories representing organizational aspects. Mapping two or more sites requires interoperable processes and process models. To add or diminish locations scalable structures are needed. Table 2: adjustment strategies (referring to scenarios in table 1) Domain A: additional testing Elements - possible but requires scalability of se model, actor B: Failure in functionality - possible but restricted to actor C: model combination in distributed environment D: key developer leaves - requires structural change E: management decision – cancel cooperation F: management decision cooperation 4 - Requires structural change; sd.-model might support profiles - requires structural change - work load increase possible (scalability) - requires structural change - work load decrease possible (scalability) Structural topology - adjustment of se4 model - model exchange - allocating additional work-load - methods - implementation of additional requirement analysis - defining synchronization points - se model adjustment or exchange - exchange of element - se model adjustment or - se model exchange - exchange or adjustment of elements Decision area - delegation of (modular) tasks, processes, phases - new partnering models - se model combination - expansion of decision area possilbe se model = software engineering process model (Waterfall, V Model, XP, RUP, …) 720 - (external) delegation - partnering as option - global (interoperable) process model - distributed software process management - delegation of activities - reduction of decision area In the view of the abovementioned elements contain the properties to adjust to changes; each representing “parameters” similar to correcting variables in software technique and other disciplines. This form of adaptation does not change the structure but the value or status of the element (e.g. work-load). As opposed to adjustment purely related to elements structural links allow a more dynamic behaviour towards unanticipated changes during run-time of the project. Common turbulences as loss and exchange of elements etc. require adjustments that address the structure or configuration of the se-process. Communication rules and behaviour are linked to this domain; likewise a revision of the (pre-planned) process model; the integration of redundant (work-load) absorbing structures. The third domain covers partnering strategies (outsourcing of activities). Collaboration to mutually address the product development is linked with a shift from local or personal level to global level. Obviously, organisational changes as distributing product development, integrating new partner during the project stands for a high degree of flexibility during the project. However scenarios as merging locally distributed teams and process models involves building responsiveness, agility and adaptability into process architectures, project management methods, and organizations. Adjustment Strategies and Requirements Many sources of change are relatively unpredictable such as changes in leadership personnel (E, F in table 2), not specifiable (emerging) functions or events (B). Frequently, when product development goals are at risk engineers interact ad-hoc to then known facts [7]. In such cases the engineering model may not be suitable anymore. If documentation is suddenly crucial the waterfall model will be an option perhaps in exchange of less documentation focussed models. Hence expensive rework and uncertainty need to be accepted. The best way to narrow the problem space is to identify candidates reducing the consequences of unanticipated changes. At this point the domains of adjustment support deriving necessary properties: Obviously, elements, links and decision space need to be scalable to handle quantitative aspects as work-load. Links between elements should be allowed to be established when needed. A scalable decision space adds and diminishes partners/sites that share the engineering problem. Modular process structures defining sub-tasks and goals allow efficient modification of structures and decision space. Modular structures of engineering models ensure the definition of development phases and sub-tasks therefore exchange, distribution is an option if needed. Interoperable structures ensure compatibility and standards [18]. At the level of elements role models (project manager, developer, tester etc.); communication rules; exchange formats, protocols and further aspects of standardization contribute to topology adjustment. The input and output services between (distributed) sites are also a matter of well defined standards and rules allowing efficient partnering. Software engineering processes are considered knowledge-intensive processes. The skills of actors contribute in as much the engineering model may manage knowledge, e.g. contain best-practises (RUP model) or knowledge and skill profiles of actors. Requirements that can be derived in order to respond and adapt to run-time dynamics relate to the context of elements, structural flexibility approaches but also se-process model adjustments. A selection has been illustrated. Understanding the factors that impact how process models are 721 chosen, how they are developed, how they evolve and how they can be adapted are therefore critical topics for managerial attention. Designing Distributed SE-Processes – Local versus Global Optimization A key challenge for distributed SE-processes referring to the decision area is to balance local and global optimization (E, F Table 2). In biologically inspired systems decentralization does not involve global coordination but local autonomy is postulated [12], [20]. Likewise actors as engineers, customers would act locally and the view is restricted to their immediate region. In terms of optimization this imposes a constraint upon the system (Figure 1). The question to ask is how a global process configuration can be achieved over n sites or engineering partners when commercial software is developed. Theoretically, each partner acts goal-oriented and is responsible for its own internal state and behaviour meaning by authority or contracting self-management is enforced. Practically, organisational and geographical aspects stand for both complexity and variety in process and product design in proprietary models employed by commercial firms. The process optimization does strongly depend on how well actors are able to understand each other and find ways to mutually satisfactory results. So tensions and mistrust will cut off many options for joint benefit [7], [3]. Therefore, we suggest coming to an achievable solution that can be locally accepted. Scenario E and F is an example for different levels of achievability. An expected top-down management decision to perhaps finish with a partner that serves as an equal engineering partner represents a very turbulent and unsecure environment for the (internal) team. Central coordination, redundant structures rather than local autonomy appear more fruitful in the light of loosing product and engineering knowledge. From a local focus redundancy in structures is an option to adapt as the process benefits in future (e.g. test-algorithms, de-bugging, documenting etc.). Hereby distributed autonomy is reduced; central control structures are established; thus the focus is to reach a local optimum for the team afraid to lose a partner. Based on the link between structure of product and organisations that participate in the development structural analogies represent the similarity between product and process design [11]. In other words decentralized processes require likewise product and process management structures for better adjustment (global optimization). Structural analogies are identified as key enabler for adaptability in related research [1], [7]. However, stability valuing trust and mutual benefit appear a basic must when designing distributed adaptable engineering processes that show overallefficiency. 4 Solution Approach – PEPMAD So far we have shown the enduring principles in software engineering; provided sub-views on three domains that trigger adjustment. We also showed our concept of achievability in terms of optimization. In this section managerial functions to support adaptive behaviour during run-time are outlined. Adaptation during run-time responds to environmental context of the software engineering process, e.g. new customer demand patterns. Hence changes need to be registered. Afterwards a decision needs to be taken what way to go. Hence alternatives need to be found and evaluated, e.g. additional testing, partnering with X or Z etc. Third, to put the decision into action requires reconfiguring the 722 process. Therefore, to enable the software process to be more adaptable three basic functions are required: (1) context management; (2) option management and (3) configuration management. The context management gathers information about decision area, structural topology and elements. It corresponds to process monitoring (Figure 2). If changes are significantly unanticipated the adaptation management is engaged. The evaluation of alternatives is criteria based. The suitable alternatives are subject for reconfiguration activities. The criteria that serve for evaluation of alternatives are based on relevant properties (as scalability, modularity, interoperability, redundancy…) that need to be enhanced in order to adapt the domains of adjustment to design the process more adaptable. The PEPMAD – Process Model PEPMAD – the Potsdam Evolutionary Process Model for Adaptable Design is a process model (Figure 2). In general, a process model is a central outline for a systematic development of a system being an organisational framework. It specifies the order and the kind of actions between system elements in focus [13]. The goal of PEPMAD is to define features that are essential for a given software engineering process to be more adaptable during run-time. The loop construction allows continuous course of activities and adaptation to new circumstances [27]. The evolutionary aspect is given by the integrated loop which implies self-optimization and continuous improvement [24]. The term applied to a software development system is a vision lent from biological context to underline the fact that the system itself has to recognize its needs and accordingly adapt its functions, retaining the useful and abolishing the disturbing elements [25]. Also, process adjustment is a continuous organizational task that should be integrated as soon as possible as software changes occur on the first day of development resulting in engineering process changes [8]. Input Output 1 process monitoring process reconfiguration 3 2 Criteria recommended actions Figure 2: PEPMAD – Potsdam Evolutionary Process Model for Adaptable Design PEPMAD @work Applying PEPMAD there are two choices to make: the process or scenario to analyze and the depth of analysis. With regard to the first the differentiation between single site locations versus distributed (open) environment is of interest. Distributed processes need to be modular and interoperable to facilitate the work, to attract partners that understand the task and to contribute to it. By contrast, in single locations problems are more often solved by face-to-face communication. A 723 special stage represents the start-up engineering organisation that has just entered the market with a software product. At this point the benefits of modularity may not (yet) be of interest but the capturing of process and product knowledge to (iteratively) optimize project performance. Based on the initial condition of the engineering process the evaluation of the decision area is linked with a weighting of important process qualities; for instance modularity and interoperability in distributed and others as self-optimization, knowledge management for start-up’s. A catalogue of about 50 aspects captures the current situation. The model provides conclusions on this to support adjustment strategies. The situation-based weighting of the criteria does influence the importance and order of recommendations that are directly linked with questions. An optional but recommended step especially in distributed environments is the communication analysis deploying KMDL® (Knowledge Modelling Description Language) to identify strategic positions in the communication network [15]. In addition to the questionnaire lived communication can be visualized that show established communication ways also bottle-necks. The following picture illustrates the PEPMAD contents (Figure 3). Situation-based questionnaire elements links Distribution of elements distributed single Weighting of criteria Modularity Scalability Answer 1 When? Comments Question 2 Answer 2 How? Comments procedures communication analysis ... gate-keeper bridge ... Structural topology Decision-area Question 1 recommondations actions Star Bridge Liason ... Gatekeeper ... Question n Answer n Who? Comments Isolation Context Management software procedure models Option Management Monitoring / Loop structure Reconfiguration Management Figure 3: PEPMAD in detail As said, the recommendations show options for better process adjustments. Options are directly linked with process models if they do contain the recommended activity. For instance, for a start up documentation may be recommended to ensure stability against loss of expertise; models supporting documentation as waterfall model would be listed. The idea is to additionally provide a choice of deployment packages that consist of established process models. Fifteen well-known process models have been pre-evaluated in terms of adaptation features. The best (most adaptable) results can be attained if the models can be integrated or combined to complete the recommendations. 5 Recent Developments PEPMAD is being established within a research project “IOSEW”. Software engineering processes of four software companies ranging from very small to medium sized companies provided the foundation for the process model. PEPMAD is tool-based covering the “simple run”. For a first- 724 time deployment three hours joining key personnel and consultant to ask and explain questions are necessary. Afterwards the simple cycle can easily be integrated into the business. The extended cycle deploying link analysis using KMDL® does require experts for data gathering and visualization; approximately 3 – 4 days are needed for a geographically distributed process between 2 to 3 partners. The rest of the section points at a selection of related recent research that either influences or contributes to the results. Autonomic computing (AC) presents autonomic elements that follow the well-known MAPE cycle: to monitor, analyze, plan and execute [22]. AC introduces a computer system. PEPMAD as said is a process model; nonetheless basic activities of the MAPE cycle are shared. PEPMAD in our opinion appears to be a special variation though the MAPE model is less specific. A range of work has aimed to examine the link between a product’s architecture and the characteristics of the organization that develops this product. The link in between is the process of production. The roots of this approach lie in the field of organization theory, where it has long been recognized that organizations must be designed to reflect the nature of the tasks that they must perform [23], [9]. In addition, discussions on flexibility concepts and methodologies, popular in the IT engineering world, termed agility, adaptation, changeability served as impulse though typically not agreed upon as they often reflect a specific level of consensus [1],[10]. 6 Conclusions Developers design software systems based on needs and constraints imposed by external factors. These constraints require organisations not only to adjust to them but also and especially to respond to them in shortest time. We have investigated the approach to build a self-adapting software engineering process to manage turbulences during process run-time. The concepts fill the gap between structure and function of the engineering process. PEPMAD postulates a couple of main principles: - Three domains of adjustments support overall process adjustment; namely elements, structural links and decision area. - Based on well defined domains of adjustment the goal is to use them all during run-time by planning well in advance. - To gather or buy information is one principle to diminish uncertainty. Given these characteristics, PEPMAD would also benefit from research in several related areas. For example dynamic software product lines and product reuse [17], [25] , automatic versus distributed human decision making, and further structural analogy research [29]. Nonetheless to cope with dynamics each planning phase should be supported by process models that support change during project run-time taking possible adjustment strategies into consideration. PEPMAD is a blueprint to better adapt to the additional emergence of unanticipated change. The feasibility has been proven for small to medium software developing companies. To ensure broad utilization and adoption the process model would benefit from more case studies, which probably would contribute to refinements. Of interest the generalization of results for open-source software engineering processes remains uncertain. Additionally, new developments in process models, standards that influence the enduring principle of software engineering appear challenging. 725 7 References [1] ANDRESEN, K.: Design and Use Patterns of Adaptability in Enterprise Systems, Gito, Berlin, 2006. [2] ANDRESEN, K., GRONAU, N., Managing change – Determining the Adaptabiltiy of Information Systems, European Conference on Information Systems (EMCIS) 2006 [3] BALASUBRAMANIAM, R., LAN, C., ANNAN, M., PENG, X., Can distributed Software be Agile?, Communications of the ACM, 49, 41 – 46, 2006. [4] BICOCCHI, N., MAMEI, M., ZAMBONELLI, F., Towards Self-organizing Virtual Macro Sensors, IEEE Computer Society, First International Conference on Self-adaptive and Self-organizing Systems (SASO), 2007. [5] BLAIR G., S., COULSON, G., BLAIR L., DURAN-LIMON, H., GRACE, P., MOREIRA, R., PARLAVANTZAS, N., Reflection, self-awareness and self-healing systems, ACM Press, 9 – 14, 2002. [6] BISHOP, J., HOORSPOL; N., Cross-Plattform Development: Software that Lasts, IEEE Computer, 39, 26 – 35, 2006. [7] BOEHM, B.: Making a difference in the Software Century, IEEE Computer 41, 32 – 38, 2008 [8] BOHNER, S., An Era of Change-tolerant systems, IEEE Computer 40, 100 – 102, 2007. [9] BURNS, T., STALKER, G., M., The Management of Innovation, Tavistock Publications, London, 1961. [10] COALLIER, F., Standards, Agility, and Engineering, IEEE Computer 40, 100 – 102, 2007. [11] CONWAY, M.E., How do Committee's Invent, Datamation, 14, 28-31, 1968 [12] CARILLO, L., MARZO, J.,L., VILA, P., MANTILLA, C., A., Ant Colonies for Adaptive Routing in PacketSwitched Communications Networks. In Eiben et. al. (editors) Parallel Problem Solving from Nature, 673 – 682, 1999. [13] FITZGERALD, B., Formalised systems development methodologies: a critical perspective, Information Systems Journal, 6, 3 – 23, 1996. [14] GHEIS; K., ULLAH KAHN, M., REICHLE, R., SOLBERG, A., Modeling of Component-Based Self-Adapting Context-Aware Applications for Mobile Devices, IFIP Working Conference on Software Engineering Techniques, 718- 722, 2006. [15] GRONAU, N. FRÖMING, J., Eine semiformale Beschreibungssprache zur Modellierung von Wissenskonversionen. In: Wirtschaftsinformatik, 48, 349-360. 2006 (in German). [16] GWANHOO, L., DELONE, W., ALBERTO-ESPINOSA, J., A., Ambidextrous Coping Strategies in Globally Distributed Software Development Projects, Communications of the ACM, 49, 35 – 40, 2006. [17] HALLSTEINSEN, S., HINCHEY, M., SOOYOUNG, P.; SCHMID, K., Dynamic Software Procuct Lines, , IEEE Computer 40, 93 – 95, 2007. [18] HANISCH, F., STRASSER, W.: Adaptability and interoperability in the field of highly interactive web-based courseware. In: Computers & Graphics, 27, 2003; 647-655 [19] HAREL, D., Can Programming Be Liberated, Period? IEEE Computer 41, 28 – 37, 2008. [20] HERRMANN; K., WERNER, M., MÜHL, G., A Methodology for Classifying Self - Organizing Software Systems. International Transactions on Systems Science and Applications, 2 (1); 41 – 50, 2006. [21] HIGHSMITH, J., COCKBURN, A., Agile Softwaer Development: the business of innovation, IEEE Computer, 34, 120 – 127. [22] KEPHART, J. O., The Vision of Autonomic Computing, IEEE Computer 36, 41 – 52, 2003. [23] LAWRENCE, P., R., LORSCH, J.W., Organization and Environment, Haward Business School Press, Boston, MA, 1967. [24] LEHMANN, M., M., Feedback in the software development process, Information and Software Technology, 38, 681 – 686, 1996. [25] MADAM HOMEPAGE, Mobility and ADaptation enAbling Middleware, http://www.intermedia.uio.no/confluence/display/madam/home (28.07.2008) [26] MADHAVJI, N., H., The Process Cycle [Software Engineering], Software Engineering Journal, 6, 234 – 242, 1991. [27] NUSEIBEH, B, Weaving together Requirements and Architectures, IEEE Computer, 34, 115 – 119, 2001. [28] OSTERWEIL, L., J.; GHEZZI, C.; KRAMER, J.; WOLF, A.,L.: Determining the Impact of Software Engineering Research on Practice, Computer, IEEE Computer 41, 2008. [29] V. HIPPEL, E., Task Partitioning: An Innovation Process Variable, Research Policy 19, 407 – 418, 1990. 726 REQUIREMENTS ENGINEERING FOR HYBRID PRODUCTS AS BUNDLES OF HARDWARE, SOFTWARE AND SERVICE ELEMENTS – A LITERATURE REVIEW Marina Berkovich, Sebastian Esch1, Jan Marco Leimeister2, Helmut Krcmar1 Abstract In this paper we compare different approaches and show the need for systematic requirements engineering for hybrid products beyond disciplinary boundaries. Hybrid products consist of combinations of hardware, software and service elements. The purpose of this paper is to report on a literature review on requirements engineering for hybrid products. Each academic discipline involved (software engineering, product engineering and service engineering) has a different view on requirements engineering. The goal of the literature review is to discover how the approaches of each discipline are able to cope with requirements engineering for hybrid products. 1. Introduction Increasing competition and increasing technological development result in high time-, cost- and development pressure. These trends induce the need for differentiation for most companies [32, 34]. Thus companies are compelled to individualize their products and services regarding to customer needs. The companies’ goals are to improve the innovation processes continuously and to increase their ability to determine, to track and to cover customer-needs better than competing companies. The improvement of the ability to innovate is an essential factor for the prosperity and growth of companies [10]. Hauschildt [14] defines innovations as qualitative new products or methods, which noticeably differ – however this is measured – from the prior state. The novelty has to be realized. The sole generation of a new idea is not sufficient; sale or utilization distinguishes between innovation and invention. Therefore companies develop more and more complex solutions. These complex solutions consist of combinations of product-, software and service elements. The distinction between product and service becomes blurred and a so called hybrid product emerges [23]. A hybrid product is a 1 Technische Universität München, D-85748 Garching b. München, Boltzmannstr. 3 2 Universität Kassel, D-34127 Kassel, Nora-Platiel-Str. 4 727 complex solution consisting of several parts, usually hardware, software and service elements, which are not easily, recognized as single parts, but different characteristics of these three parts define the hybrid product [23]. Especially the development of hybrid products is different because of the high number of sub-elements, the high level of technological integration and the degree of customer-integration [23, 37]. But in the literature the development of products and services are elaborated separately. Hybrid products have some differences compared with other areas. Hybrid products are more complex as products consisting of one part as hardware, software or service element [23]. The trend to customer individuality is also one of the important aspects characterizing these products. The lifecycle of hybrid products is considered differently as traditional products. The company that builds hybrid products does also offer services in combination with the product, what means in practice that the later operation of the product is also important. The operator model changes from “build and forget” to “build, operate & advance”. Ultimately also the business model of the company changes to a “pay per use” philosophy. The individual components of these hybrid products have different development and manufacturing periods and are developed by different functional areas within a company. These aspects cause various challenges for companies. 2. Requirements Engineering Requirements engineering (RE) is a crucial aspect for a successful development of products and software [5, 24]. A dominant understanding of RE in software engineering defines requirements engineering as consisting of requirements analysis, prioritization and negotiation of requirements, the activities to control and to administer requirements of a system under development. The change- and realization-management and the validation of requirements are also parts of RE. Strong evidence that RE is especially important gives [33] which states that “surveys which have been carried out so far suggest that, for large hardware/software systems, about 15% of the total budget is taken up by requirements engineering activities.” All changes of requirements cause modifications of parts of the solution and increase development costs. Requirements engineering has to capture and to map the origin and the context of changes. Furthermore the impact of changes should be made assessable. Another important mission of tracking changes is to anticipate future changes of requirements. The development of hybrid products is influenced by the disciplines product-, software- and service-engineering. Thus, the development of hybrid products needs a special designed process of requirements engineering. In order to develop the requirements engineering for hybrid products we analyze whether the RE in each of the discipline is appropriate for hybrid products. 3. The State of the Art of RE in the Literature Most development process models in product engineering, software engineering and service engineering consider requirements engineering only during the first phases of the overall development process. The goal of the requirements engineering’s activities is to elicit and specify the requirements. The fact that missing or incorrect requirements have negative effects on the success of the product is widely recognized [5, 24]. 728 The development process of hybrid products involves different stakeholders and components. In the following sections we describe and compare different approaches in product engineering, software engineering and service engineering, each of them specialized in developing mainly one component: (physical) products, software or services. 3.1. Analyzed aspects In software engineering requirements engineering has already been accepted as an independent discipline and is done systematically. Many concepts and methods for handling of requirements have already been elaborated there. The development of process models has been elaborated there, which is especially important for hybrid products [23]. From the requirements engineering in software engineering we derived the aspects based on the phases of the requirements engineering process and proper questions listed below: • Requirements elicitation: How are the requirements elicited? What methodical support is available? • Requirements analysis: How are the requirements analyzed? How are the requirements translated to the language of the developer? What methodical support is available? • Requirements negotiation: How are conflicts between requirements resolved? Are priorities assigned to requirements? What methodical support is available? • Documentation: How are the requirements documented? Which information is documented? • Validation: How are the requirements validated for completeness, correctness and consistency? • Change management: How are changes of requirements managed? Especially the next aspects are important for the literature review: • Systematic requirements engineering: whether the requirements engineering is evaluated in all phases of the development process. • Methods for formal specification of requirements: are there methods for a formal specification of requirements? • Methods for requirements elicitation are described: are the methods of requirements elicitation described? • Tool-support: are there tools supporting the process of requirements engineering • Documentation and management of changes of requirements: are changes of requirements documented and is the change management process defined? • Whether all phases of the innovation process are covered: are all phases of the innovation process considered in requirements engineering? • Whether hybrid products are captured: does the process of requirements engineering consider hybrid products? 3.2. Sources of RE-approaches: Product Engineering Jung [20] defines a requirement as a request that a product fulfills certain properties or functions. A requirement can be posed consciously or unconsciously by any person that has an interest in justifying the requirement. A requirement consists of a describing attribute and a defining value (quantification). 729 Most development approaches in product engineering take requirements engineering into consideration [1, 3, 7, 9, 11, 16, 21, 24, 27, 35]. Some examples illustrate the common views of these approaches. Cross [7] suggests a goal tree, which is used to vaguely collect the initial requirements. During the development process the requirements are refined as the problemunderstanding of the customer and engineers increases. Ehrlenspiel [11] defines an iterative process for eliciting the requirements. He suggests using checklists to support the customer interviews and to overcome misunderstandings between the customer and the engineer. Lindemann [24] has developed a set of methods for requirements elicitation. These methods are not used in a predefined order and can be applied repeatedly. Examples for methods involving the customer are: checklists, mind maps and questionnaires. A sequential process model is suggested by Pahl [27]. He states that the engineer has to extract the requirements from the customer’s wishes. He also recognizes that the customer is often not able to express his requirements appropriately, but he does not suggest methods for eliciting the requirements. Ulrich [35] collects the requirements in hierarchical weighted lists. The author states that it is important to reveal implicit customer-needs and that a common product-understanding between customer and engineer is absolutely necessary. Most authors demand that changes of requirements are documented in form of requirement-lists. The origin and cause of changes is hardly documented. Interdependencies between requirements are captured by creating links between requirements, but an anticipatory handling of requirements is missing. The analysis of the mentioned literature revealed that RE in product engineering is mostly restricted to the early phases of the development process. During the late phases RE does not seem to play a substantial role. Most of these approaches state that the customer plays a central role during the entire development process, but type and degree of customer integration into the development process varies. The integration of the customer into the process of requirements elicitation is emphasized, but not in later phases [20]. The methods of product engineering deal only with requirements for products. They do not mention that a product can consist of hardware and software or even of a bundle including services. The inclusion of services into the development process is not mentioned. 3.3. Sources of RE-approaches: Software Engineering The term “requirement” is defined by IEEE-Standard IEEE 610.12-1990 [17] as follows: “A requirement is a (1) condition or capability needed by a user to solve a problem or achieve an objective; (2) condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed documents; (3) documented representation of a condition or capability as in (1) or (2)”. In contrast to the definition of product engineering, this definition considers the role of the user. A functionality does not exist on its own, but the user needs it, to fulfill his tasks. Additionally, this definition states the origin of the requirements. Because the user will use the finished software, he is the main source of requirements. Therefore the integration of users into the requirements elicitation is a decisive factor for the success of software-projects [22]. Boehm [4] defines requirements engineering as follows: „Software requirements engineering is the discipline for developing a complete, consistent unambiguous specification – which can serve as a 730 basis for common agreement among all parties concerned – describing what the software product will do (but not how it will do it, this is to be done in the design specification)“. Figure 1: RE process (according to [33]) In Figure 1 the RE process is depicted according to Sommerville and Kotonya [33]. The authors give the following definition of the process of requirements engineering: “A requirements engineering process is a structured set of activities which are followed to derive, validate and maintain a systems requirement document. Process activities include requirements elicitation, requirements analysis and negotiation and requirements validation.” As the arrows in Figure 1 indicate requirements engineering is not a linear process but an iterative process. The outcome of the RE process is the requirements document and the system specification respectively. The main processes are described below: • Requirements elicitation: The task of requirements elicitation is the identification of requirements’ sources and the elicitation of requirements according to the identified stakeholders and other requirements’ sources [28]. The methods applied for elicitation of requirements are interview, workshop, observation and perspective-based reading, also brainstorming, prototyping, Mind Maps and checklists [28]. Also [33] suggest interview and observation as methods for eliciting the requirements. Sources of requirements among others can be users, domain knowledge, existing systems and regulations. • Requirements analysis and negotiation: The goal of requirements analysis and negotiation is to solve conflicts that exist between requirements and eventually get a consistent set of requirements [28]. Conflicts exist because different stakeholders have different interests in the system and different views on the system. Mostly the win-win-approach is applied to solve the conflicts [28]. • Requirements documentation: Pohl [28] suggests natural language based and model based forms of specifications. Model based documentation is based on modeling languages such as UML. To express the importance of each requirement, priorities are assigned to requirements. There exist many methods for prioritizing requirements. • Requirements validation: The goal of requirements validation is to check if the requirements specify the system as the customer wants and needs it. The methods for validation presented by Sommerville and Kotonya [33] are reviews, prototyping and testing. Pohl [28] suggests inspection, reviews, walkthroughs, perspective-based reading and prototypes. 731 Aurum and Wohlin [2] give a comprehensive compilation of practices used in RE in software engineering. In this paragraph we give a short overview of these practices. The methods requirements elicitation, specification and modelling mean “understanding the needs of stakeholders, eliciting requirements, modelling and collecting them in a repository” [2]. Here we see that software engineering is aware that there are several stakeholders with different interests in the product. To resolve these conflicts the activities of negotiation and prioritization are introduced [28]. Prioritizing requirements “assists project managers with resolving conflicts […], plan for staged deliveries, and make necessary trade-off decision” [2]. Relationships between requirements determine factors for choosing the way of software development work [8]. In order to obtain a connection between requirements engineering, design, implementation and test, requirements traceability is introduced. Requirements traceability is defined as “the ability to describe and follow the life of a requirement, in both a forwards and backwards direction” [13]. Basing on the traceability the impact analysis tries to identify the parts of a system to be changed, if a requirement is changed and to identify the consequences on the system if the change is done [19]. We conclude that RE in software engineering is highly elaborated and many methods and process models are known. Software engineering sees RE as a continuous activity which is performed throughout the entire development process, while product engineering considers RE as a phase at the beginning of the development. 3.4. Sources of RE-approaches: Service Engineering The term service engineering is defined by Gill [12] as “the systematic development of predominantly technical services by deploying engineering methods, practices and by using tools of the engineering design field”. According to Schmitz [30] service engineering in large part is handled by marketing divisions. Schmitz [30] sees requirements engineering as a task carried out by qualitative marketing research. To elicit the requirements the customer should imagine the service and should then express a hypothetical evaluation. Ramaswamy [29] understands services as transaction processes. He suggests separating the quality of services into quality of service design and quality of service delivery. For the process of developing services, the requirements to the services are crucial. The process model of Ramaswamy consists of various steps. In the step “Defining Design Attributes” the key-customers and their expectations and requirements are elicited and prioritized. So we can see that the elicitation of requirements is intended, but no precise methods are provided. The management of requirements is not mentioned. The process model of Schneider et al. [31] envisions the elicitation of customer requirements during the concept phase. Methods and tools for RE are not provided. We conclude that there are process models for service engineering. These models describe the process on a very high level; hence tangible methods are not given. We can also show that most approaches mention the customer as a source of requirements. According to Zahn [36] the integration of the customer is an important factor for the development of services. But precise 732 methods and applicable tools can hardly be identified and therefore the role of RE in Service Engineering is very vague. 4. Conclusion The importance of RE to successfully conduct development processes has been recognized by all three disciplines of product-, software- and service-engineering. In software engineering RE is applied throughout the development process and there are a large number of methods for eliciting and managing requirements. In product engineering RE is also widely accepted. The handling of requirements is integrated in the engineering-process. Most approaches consider RE only during the first phases of the innovation process. Origin, context and period of validity of requirements are not captured. Service engineering is still a young discipline and lacks support for systematic approaches [6, 15]. There exist some general process models, which mention RE, but offer no tangible methods. The abstraction level of these models is very high, so they are not relevant for practical use. Methods for elicitation and handling of requirements are treated only rudimentarily. In Figure 2 some aspects of RE are set in connection to the RE process of the three disciplines. The criterions are derived from the aspects covered in the paper. We can see that the RE in software engineering is most elaborated and RE in service engineering has the biggest gaps. product engineering software engineering [2, 18, 25] systematic requirements engineering methods for formal specification of requirements methods for requirements elicitation are described tool-support is existing changes of requirements are documented and managed all phases of the innovation process are covered hybrid products are captured partially covered not covered Figure 2: aspects of requirements in the three disciplines 733 service engineering [6, 29, 31] In Figure 2 we can see that especially the aspects that are most relevant for hybrid product are not covered by the existing approaches of RE. Also tool-support and methods for formal specification of requirements should be improved. Hybrid products need customer orientation [23, 37]; to guarantee that the customer-need is satisfied, the customer has to be integrated into the whole development process, but none of the approaches covers all phases of the innovation process. Services are a part of the hybrid product [23, 37], but the RE in product development and software engineering does neither mention the integration of services nor the parallel development of them. Additionally the RE approaches of product engineering do not cover software parts of products. In the RE of software engineering hardware is considered as already existing and is taken into account as an unchangeable “system context”. Because of this lacks in the approaches all the four circles for “hybrid products are captured” in Figure 2 are selected as “not covered”. 5. Limitations and Outlook for Future Work This literature review covered only the most dominant literature found in these domains. It could only present the most significant differences and deficiencies of RE for the development of hybrid products – more detailed and thorough analyses are required. Future work should develop models, modelling methods and supporting tools to cover the RE for hybrid products. It is particularly important to support all phases of the innovation process. Therefore models have to capture changes of requirements and interdependences between requirements and the methods have to deal with them accordingly. To meet the challenges of RE for hybrid products, models are needed, that are capable of treating the requirements and the product as a whole. The models must also be able to capture service packages and its interplay of hardware-, software- and service components along the entire development process appropriately. By comparing the existing approaches and industrial practices it should be possible to develop a transdisciplinary understanding of requirements and its handling. Future research has to answer - amongst others - the following questions: Which methods and models are used by the RE in practice? Which methods and models presented in the literature are used in practice? Which are success and failure factors of RE in practice? Which activities must be supported by a process model for RE in the field of hybrid products? Is an integrated RE supporting all phases of the innovation process possible, reasonable and applicable? 6. References [1] AHRENS, G. Das Erfassen und Handhaben von Produktanforderungen, Dissertation der TU Berlin, Berlin, 2000. [2] AURUM, A. WOHLIN, C. Requirements Engineering: Setting the Context, in: Engineering and Managing Software Requirements, Springer, Heidelberg, 2005. [3] BREIING, A., FLEMMING, M. Theorie und Methoden des Konstruierens, Springer, Berlin, Heidelberg, 1993. [4] BOEHM, B.W. Guidelines for verifying and validating software requirements and design specifications, EURO IFIP 79, North Holland 1979, S. 711-719 [5] BROOKS, F. P., JR. “No Silver Bullet: Essence and Accidents of Software Engineering, in: Computer, Vol. 20, No. 4, April 1987, pp. 10-19. 734 [6] BULLINGER, H.-J., SCHEER, A.-W. Service Engineering – Entwicklung und Gestaltung innovativer Dienstleistungen, 2nd Edition, Springer, Berlin, 2005. [7] CROSS, N. Engineering Design Methods, Wiley, Chicester, 1996. [8] DAHLSTEDT, A. G., PERSSON, A. Requirements Interdependencies: State of the Art and Future challenges, in: Engineering and Managing Software Requirements, Hrsg.: Aurum, A., Wohlin, C., 1st Edition, Springer, Berlin, 2005. [9] DANNER, S. Ganzheitliches Anforderungsmanagement, Shaker, Aachen, 1996; Diss. der TU München, 1996. [10] EDGETT, S. J., COOPER, R. G. New Product Development, Ancaster, Product Development Institute, Ontario 2005. [11] EHRLENSPIEL, K. Integrierte Produktentwicklung, Hanser, München, 2003. [12] GILL, C. Architektur für das Service Engineering zur Entwicklung von technischen Dienstleistungen, 1. Auflage, Shaker, 2004. [13] GOTEL, O.C.Z., FINKELSTEIN, C.W. An analysis of the requirements traceability problem, in: Proceedings of the First International Conference on Requirements Engineering, Colorado Springs, CO., 1994. [14] HAUSCHILDT, J., SALOMO, S. Innovationsmanagement, 4td Edition, Franz Vahlen GmbH, München, 2007. [15] HERRMANN, T., KLEINBECK, U., KRCMAR H. Konzepte für das Service Engineering: Modularisierung, Prozessgestaltung und Produktivitätsmanagement, 1st Edition, Physica, Heidelberg, 2005. [16] HUMPERT, A. Methodische Anforderungsverarbeitung auf Basis eines objektorientierten Anforderungsmodells, HNI-Verlagsschriftenreihe, Paderborn, 1995. [17] IEEE Standard Glossary of Software Engineering Terminology, The Institute of Electrical and Electronics Engineers, New York, 1990, IEEE Std. 610.12-1990. [18] JACOBSON, I., BOOCH, G., RUMBAUGH, J. Unified Software Development Process: The complete guide to the Unified Process from the original designers, Addison-Wesley Longman, Amsterdam 1999. [19] JÖNNSON, P., LINDVALL, M. Impact Analysis, in: Engineering and Managing Software Requirements, Hrsg.: Aurum, A., Wohlin, C., Springer, Berlin, 2005. [20] JUNG, C. Anforderungsklärung in interdisziplinärer Entwicklungsumgebung, Dr. Hut, Aufl. 2006. [21] KRUSE, P.J. Anforderungen in der Systementwicklung, VDI-Verlag, Düsseldorf, 1996. [22] KUJALA, S. M., KAUPPINEN, L., LEHTOLA, KOJO, T. The role of user involvement in requirements quality and project success, in: 13th IEEE International Conference on Requirements Engineering, Paris, 2005, pp. 75 – 84 [23] LEIMEISTER, J. M.; GLAUNER, C. Hybride Produkte – Einordnung und Herausforderungen für die Wirtschaftsinformatik, in: Wirtschaftsinformatik, Vol. 50, No. 3, 2008 . [24] LINDEMANN, U. Methodische Entwicklung technischer Produkte, Springer, Berlin, Heidelberg, New York, 2005. [25] MARSCHALL, F., SCHOENMARKERS, M. Towards model-based Requirements Engineering for web-enabled B2B Applications, in: Proceedings of the 10th Annual IEEE International Conference and Workshop on the Engineering of Computer Based Systems (ECBS), 2003, S. 312 – 320 [26] MEIREN, T. Service Engineering – Systematische Entwicklung von kunden- und mitarbeiterorientierten Dienstleistungsprodukten, in: Technologiemanagement in der Praxis: Forschen und Anwenden, Hrsg.: Spath, D., Fraunhofer IRB , Stuttgart, 2006. 735 [27] PAHL, G., BEITZ, W., FELDHUSEN, J., GROTE, K.H. Konstruktionslehre, Springer, Berlin, Heidelberg, New York, 2003. [28] POHL, K. Requirements Engineering. Grundlagen, Prinzipien, Techniken, 1. Auflage, Dpunkt Verlag, 2007. [29] RAMASWAMY, R. Design and Management of Service Processes, Addison- Wesley, Massachusetts, 1996. [30] SCHMITZ, G. Die Ermittlung der Kundenanforderungen an industrielle Dienstleistungen, in: Zeitschrift für Planung, 2000, Nr. 2, pp. 195-215 [31] SCHNEIDER, K., DAUN, C., BEHRENS, H., WAGNER, D. Vorgehensmodelle und Standards zur systematischen Entwicklung von Dienstleistungen, in: Service Engineering: Entwicklung und Gestaltung innovativer Dienstleistungen, 2. Auflage, H.-J. Bullinger, A.- W. Scheer, Springer, Berlin, 2006, pp. 113-138. [32] SIMONIS, G. Die Zukunftsfähigkeit von Innovationen: das Z-Paradox., in: D. Sauer; Ch. Lang. Paradoxien der Innovation, Campus, Frankfurt/New York, 1999, pp. 266 [33] SOMERVILLE, I.; KOTONYA, G., Requirements Engineering: Processes and Techniques Wiley & Sons, 1998. [34] SPATH, D., DILL, C., SCHARER, M. Vom Markt zum Markt, LOG_X, Stuttgart, 2001. [35] ULRICH, K. T., EPPINGER, S. D. Product Design and Development, McGaw-Hill, New York, 2003. [36] ZAHN, E., SPATH, D., SCHEER, A.-W. Vom Kunden zur Dienstleistung - Methoden, Instrumente und Strategien zum Customer related Service Engineering, Frauenhofer IRB Verlag, Stuttgart, 2004. [37] ZELLNER, G. Gestaltung hybrider Wertschöpfung mittels Architekturen – Analyse am Beispiel des Business Engineering. in: Wirtschaftsinformatik, Vol. 50, No. 3, 2008. 736 REENGINEERING DEPRECATED COMPONENT FRAMEWORKS: A CASE STUDY OF THE MICROSOFT FOUNDATION CLASSES Robert Neumann, Sebastian Günther, Niko Zenker1 Abstract In today’s application engineering, the implementation of frameworks and related technology boosts development quality and reduces related effort. Framework functionality embodies expert knowledge and is driven towards reuse. While stable from a conceptual point of view, technological changes require constant adaptation and reengineering. This article presents overall framework engineering principles and practices (FEPP) and shows their concrete application using the example of the Microsoft Foundation Classes. Abstracting from the case study, the focus of this work is upon introducing particular methods for how to cut down on the complexity of maintenance projects by considering the FEPP during framework development. 1. Motivation As offsprings of the object-oriented programming paradigm, component frameworks in the past were subject to intensive research that reached its peak in the 1990s. Economies of frameworks were derived from framework engineering principles which have established a collection of concepts and best practices describing how to efficiently develop software frameworks. Even though framework development, maintenance, and discontinuance are well analyzed phases in the framework lifecycle, the reactivation of an already discontinued framework seems to be a rather unexplored discipline. A very successful and well known example in the domain of Windows application development is the Microsoft Foundation Classes (MFC). However, as with the introduction of the .Net framework in 2002 Microsoft changed its focus away from native towards managed development, the MFC were decided to be not longer maintained. Contrarily, the number of Independent Software Vendors (ISVs) outside the managed world was still significant, whereby some of them had established gigantic code bases in native C/C++ code with the MFC interfacing between their application and the Windows operating system. Those ISVs were dependent on the MFC being updated to expose new Windows features as they wanted to support their products even on modern Windows versions. Visual Studio 2008 (released in October 2007) for the first time after more than ten years contained a major set of updates for the MFC demonstrating an attempt to bring the MFC back to the market. 1 Otto-von-Guericke-Universität Magdeburg, Universitätsplatz 2, 39106 Magdeburg 737 The resurrection of the MFC moved the question of how to assess the maintainability of a “reactivated” framework into the focus of our investigations. Using the MFC, we investigated places in a framework that are sensitive to future refinement projects. We analyzed how well the architecture of the framework supports maintenance and what can be done to reduce the intensity in effort those projects require. A resulting catalog of refinement points compares the architecture of a framework to framework engineering principles and practices (FEPP) and discusses how deviations from the FEPP might impact the complexity at which future maintenance projects are possibly driven. The catalog depends on a study that was conducted in cooperation with the Microsoft Visual C++ team in 2008. The paper is organized as follows: The second section gives an overview of the basics of software frameworks, clarifies terminology, and discusses the significance of frameworks. It follows a listing of framework key characteristics which represent the starting point for our further explanations. Based on this, the third section introduces an approach for how to improve the maintainability of a framework using the FEPP. Thereby, the focus is upon demonstrating that perspicacious development embodies the foundation for easy-to-accomplish future maintenance. 2. Backgrounds of Framework Engineering The term ”software framework” generally refers to a high-level design that is abstract enough to be applicable to various problems of an application field. It can be used to bootstrap concrete implementations which are based on a common architecture [10]. Referring to Taligent Inc., frameworks are defined as “a set of prefabricated software building blocks which programmers can use or customize for specific computing solutions” [15]. Thereby, Taligent emphasizes that a framework captures the problem-solving expertise necessary to solve a particular class of problems. Companies can use frameworks to obtain such problem-solving expertise without having to fully develop it. Furthermore, frameworks provide a well-designed infrastructure, so that when new pieces are created, they can be added easily or substitute old pieces with minimal impact [14]. All of the above definitions share the idea of two basic aspects: Firstly, a framework provides the users with a certain set of functionality and secondly, frameworks allow the users to customize or modify this functionality. Framework reengineering is becoming evidently a vital activity in the software industry [4]. Its goal is to understand, analyze, and improve frameworks to form new framework versions. Reengineering includes tasks, such as refactoring (changes to the appearance of code), redesign (changes to the architecture), and refinement (new functionality, bug-fixing, or performance improvements). Since the reengineering process can be triggered as part of the software lifecycle -especially the maintenance phase-, we will in the remainder of this work also refer to it as “framework maintenance”. In the following, we will further discuss the significance of frameworks and show their different key characteristics. 2.1. Significance of Frameworks Frameworks support the application development process by providing prefabricated solutions to reoccurring problems. They capture and leverage the expertise of domain experts in a software component that can be included by other application programs. The use of frameworks can result in a dramatically shortened development time with fewer lines of code. This is because several common aspects of the applications are already captured by the framework. The effort required for maintaining applications can also be significantly reduced when multiple applications are built on 738 top of one framework [8]. In case of modifications or fixes being made to the framework, applications implicitly benefit from the changes, since those are automatically propagated through the framework. The applications that are built from the framework follow the same design and share the same code base; thus frameworks provide consistency and therefore a better integration across platforms. Above all, using frameworks is related to two major aspects: Reuse and Quality. Thereby, not only the implementation of a system, but also the design of the system is reused. Since the design of successful frameworks has already proven to be efficient and has run through an in-depth testing and refinement process, it forms a quality base for developing new applications. Once a framework has been developed, the problem domain has already been analyzed and a working design and implementation have been produced [1]. 2.2. Framework Key Characteristics With the term “Framework Key Characteristics” (FKC) we refer to properties that are commonly embodied by successful frameworks to a relatively high extent. The FEPP relate to particular FKC by describing ways of how to implement them. Both FEPP and FKC will again be mentioned together, when addressing how they can help reducing maintenance. The design and the functionality of a framework incorporate the following FKC: Reusability means that software and ideas are developed once and then used to solve multiple problems. This leads to an enhanced productivity, since applications can now be built on top of already existing solutions for generic problems [11]. Ease-of-Use encompasses the application developer’s ability to use the framework [8]. The framework should be easy to understand and facilitate the development of applications. Ease-of-use is also established by providing a detailed documentation including descriptions of the framework’s functionality as well as sample applications demonstrating how to solve easy problems using the framework. Extensibility means that new components or properties can be added easily to the framework. Extension typically is achieved by deriving from existing classes (inheritance) or adding customized components to the framework (composition). So called hook methods provide a way to extend stable interfaces with new functionality. This is important to “ensure timely customization of new application services and features” [6]. Flexibility describes a framework’s ability to be used in more than one context. The more problems the framework can be applied to, the higher the problem domain coverage. Very flexible frameworks are reused more often than frameworks with a lower degree of flexibility [11]. Completeness refers to a framework’s ability to cover all possible variations of a problem. Since even the best frameworks can never provide solutions to all possible problems with an arbitrary level of detail, it makes it consequentially impossible for frameworks to be complete. However, a certain degree of completeness can be achieved and is referred to as “relative completeness” [8]. Relative completeness encompasses default implementations for the abstractions within a framework, so that these abstractions do not necessarily have to be implemented by the user. Consistency is a characteristic which reflects that the rules and conventions which determine the framework are followed throughout the whole framework without exception. Consistency in 739 frameworks speeds up the developers’ understanding of the framework and helps to reduce errors in its use [11]. Consistent frameworks always follow the same interface conventions and class structures as well as the same notations for naming variables, functions, and classes. During our investigations, we found out that the MFC incorporate those characteristics to a very high extent. Even though the MFC core was designed more than 17 years ago, it considers the FKC in an exemplary fashion. Ease-of-use, for example, is achieved by providing an elaborated interface, a very comprehensive and always up-to-date documentation, and a complex, but easy-touse development environment. On the other hand, due to their age, the MFC do not consider certain aspects of the object-oriented programming paradigm, such as Polymorphism. An example of why this can be disadvantageous will be given in section three. In conjunction with the problem of maintenance, it will be discussed pros and cons of the way MFC incorporates the FKC. 3. Addressing Framework Maintenance A study conducted by the National Bureau of Standards estimated that 60% - 85% of the total software development cost is due to maintenance [5]. These numbers are determined mostly by errors that were not found during operational testing and thus needed to be fixed at the customer’s side, generally an expensive undertaking. Therefore, it seems reasonable to attempt a reduction of potential future maintenance efforts from the very beginning. Certainly intensive and exhaustive testing prior to the release plays a major role, but maybe as important as that is to initially design the framework in a fashion that makes future engagements easier to accomplish. The incorporation of best practices, such as design patterns or object-oriented methods in general, standards, guidelines, and substantiated documentation can significantly support the creation of better preconditions for future maintenance and extension development. The catalog we have derived from the MFC case study distinguishes the reduction of framework maintenance into two core activities: preventing and enabling maintenance. Preventing maintenance refers to an attempt to reduce the likelihood of future maintenance while enabling maintenance encompasses a concept that makes the framework accessible for future maintenance. 3.1. Preventing Maintenance Preventing maintenance represents a concept to increase the overall quality of a framework while reducing the likelihood of future maintenance. The quality of a framework is determined by the degree to which it incorporates previously mentioned FKC on the one hand and by the amount of errors it contains on the other hand. Even though the number of bugs can be reduced by instantiating methods of testing, the integration of FKC can further reduce the likelihood of erroneous behavior. The following four FEPP describe how to achieve a relatively high saturation of the FKC in a framework that help cutting down on the likelihood of maintenance. 3.1.1. Documentation The documentation of a framework represents a driver that can make a critical contribution to the overall success of the framework. Ease-of-use and reusability can be established by providing a detailed documentation including descriptions of functionality as well as sample applications demonstrating how to solve easy problems with the framework. Without documentation, the only way for application developers to understand how the framework is used would lie in trying to comprehend the way the framework is used from the source code. However, if there was not even the source code available, the value of the framework to the framework applicants would be very 740 low. With the Microsoft Developer Network (MSDN)2, Microsoft provides a comprehensive and highly up-to-date documentation for the MFC that is always accessible over the internet. 3.1.2. Contracts One of the key problems when working with frameworks, such as MFC, is that, provided the inputs to a function or component, the framework users do often not receive the output they expected. In other words: the perceived behavior of a function might sometimes differ in some way from the behavior that the users anticipated. Due to this misunderstanding, users often open bug fixing enquiries on the vendors’ side, whereby the vendors have two possibilities of dealing with them: Either they modify the way in which the respective functionality is exposed by the framework or they refine the documentation and clarify how to correctly use this part of the framework. To avoid this misunderstanding between component designers and component users from the very beginning, contracts provide a way of determining beforehand, whether a class or a component used within a certain context generates a correct result [2]. They “specify preconditions on participants to establish the contract and the methods required for the instantiation of the contract“ [12]. While adding a clear communication between the framework users and the framework designers, contracts can help reducing the frequency at which users open bug fixing enquiries that aim at clarifying the way hooks3 are used. Contracts can help to enhance the ease-of-use and thus the reusability FKC of a framework and allow a slimmer documentation. Furthermore, they can improve the flexibility of the framework architecture making maintenance projects easier to conduct. Regarding MFC, we could identify only a weak contractual behavior. Behavioral contracts, for example, are incorporated by the macros VERIFY, ENSURE, and ASSERT. In case of an error, the MFC application terminates with a runtime exception, whereby a dialog states the problem that caused the shutdown. Even though this kind of contractual behavior seems to comply with the idea of behavioral contracts, it is only very inchoate and can be easily circumvented. MFC’s exception handling mechanisms can trivially be bypassed by just overriding and reimplementing the function that wraps a macro accordingly. To split the contract of the base class, it is enough to just not implement previously mentioned macros in the overridden function. 3.1.3. Standard Conformity Standard conformity incorporates the flexibility and reusability characteristics of frameworks. Furthermore, standards can help improving the consistency of the overall framework architecture and code. Incorporating standards not only improves the product quality (standards are geared to principles and best practices), but also can help improving the flexibility of the framework. Due to specific aspects of the Windows operating system, Microsoft had to rely on an extended C/C++ standard in its compiler. Standards allow code to become independent from its base technology. Standardized code should run on every platform that complies with the standard and enables software developers to use their products with a variety of base technology distributions of multiple vendors. Since the MFC exclusively targets the Microsoft Windows platform, it stands to reason that MFC does not support the development of platform-independent code. Other compilers on the Windows 2 3 http://www.msdn.microsoft.com Hooks are understood here as the means to perform customization to a framework. 741 platform do not explicitly support the MFC; a fact that binds the MFC developer community to the Microsoft compiler. In case of a specific compiler becoming superior to the Microsoft compiler by, for example generating particularly high-performing executables, MFC applications could not benefit from this. Furthermore, bugs within the Microsoft compiler could not be by-passed by simply switching to another compiler that does not show these bugs. An alternative solution to circumvent this problem could encompass concentrating all MFC-related client code in one module. This module can then be compiled with the Microsoft compiler while the MFC-independent rest of the code is passed to a compiler that can achieve better performance. However, from the application developers’ perspective, an MFC that works without any Microsoft- specific extensions would certainly be favored as it would increase their flexibility. 3.1.4. Default Behavior One important question concerning the completeness of a framework is how default behavior is incorporated and exposed. If the users, for example, do not need or want to customize certain abstractions within a framework, a default implementation that fits their particular requirements might save them time and effort. On the other hand, if a default implementation of an abstraction should not be sufficient, they could simply override it and provide their own customized functionality. Even though providing default behavior on the first glance increases the size of the framework code base, this does not automatically result in a potentially increased maintenance complexity. Since an enhanced completeness is connected to an enhanced ease-of-use, the framework users will potentially open less support enquiries that aim at refining hot spots4 in the framework. In many cases, the aggregated effort for maintaining the code that adds the default behavior might be less than the effort that evolves from refining badly designed hot spots. Regarding the MFC framework, default behavior is incorporated in classes that are intended to be used as base classes (e.g. CObject) as well as in the hook methods that represent the set of Windows message handlers. Instead of leaving the implementation of the message handlers to the developers of the application extensions, the MFC provides a default implementation for every method. 3.1.5. Summary As can be seen in the following table 1, each individual FEPP incorporates different FKC. Table1: Framework Key Characteristics (FKC) vs. Framework Engineering Principles and Practices (FEPP) 4 Hot Spots are places within the framework that require customization from the user. 742 3.2. Enabling Maintenance Even though the previously discussed methods help reducing the likeliness of future maintenance, this does not mean that the product does not need to be maintained at all. Changes in the domain of the framework, extensions requested by the user, or even bugs represent reasons to make modifications to the framework. Thus, it seems even more important to establish the framework on an architecture that is open and flexible enough to efficiently support future maintenance, use appropriate design patterns, and establish and follow conventions. 3.2.1. Architecture Inside the architecture, we want to point at two concepts that effectively enable the user to customize the framework’s behavior: Message Mapping5 vs. the use of Polymorphism. Message Mapping describes the way MFC binds Windows messages (integer IDs) to Windows message handlers (typically classes), whereby the event handlers announce which events they are able to process. The basic idea of Message Mapping is that the users of MFC in their client applications are able to customize the message handling to hook in their own responses on events. As MFC evolved as a child of the established programming standard C++, it could benefit from object-oriented language concepts. One powerful feature of C++, however, was not utilized: Polymorphism. The concept of Polymorphism captures the potential to more intuitively perform what was implemented with Message Mapping in MFC. Modifying the MFC to make use of Polymorphism could encompass to automatically attach a certain virtual message handler function to a specific Windows message in the MFC message pump (figure 1). Changing the message handler of a Windows message could now be achieved by deriving a new class from the MFC’s Windows message processing class (CWinApp) and overriding the virtual message handlers in the new class respectively. Figure 1: A polymorphism-based alternative to Message Mapping. Following conclusions are drawn: While Message Mapping is connected to manually editing the Windows message/Windows message handler entries in the map and then defining the message handler in a class accordingly, the Polymorphism-based alternative makes the first step unnecessary and merely requires overriding the appropriate virtual functions. Internally, however, the Polymorphism-based alternative does something similar to the Message Mapping mechanism, but is rather exposed as an object-oriented feature of the C++ programming language itself. 5 For more detail on Message Mapping, please refer to the MSDN (http://www.msdn.microsoft.com). 743 Since there are no message map entries to be taken care of, the Polymorphism-based approach would not only improve the ease-of-use FKC of the MFC, but also make the code of the application less susceptible to errors. The less code needs to be written by a developer, the fewer the number of errors he can potentially commit to the application. With respect to the effort that is related to maintaining and extending the MFC, the last statement also indicates that the Polymorphism-based approach could result in a decrease of resources necessary for maintenance (as there is less code affected). Hooking a new Windows message handler into an application could be achieved by simply overriding a virtual function from the MFC’s message dispatcher class CWinApp rather than fist declaring and defining a new entry in the message map and secondly creating the message handler class. 3.2.2. Design Patterns Design Patterns provide solutions to reoccurring software design problems that have proven to work in practice [9]. With respect to frameworks, Design Patterns are particularly useful for designing Hot Spots, the parts of the framework that determine its flexibility. Design Patterns can support the development of software frameworks by improving the flexibility and enhancability of a framework’s Hot Spots and thus ultimately paves the way for less complicated modifications due to maintenance. During our investigations, we identified three design pattern in the MFC: The Singleton Pattern (by accessing the main application object CWinApp), the Bridge Pattern (in serialization), and the Observer Pattern (as the basis of the Document/View architecture). For the ongoing explanations, we will concentrate on MFC’s implementation of the Observer Pattern only. The Observer Design Pattern refers to a pattern that is used to observe the state of an object in a program and is mainly used for realizing distributed event handling mechanisms [9]. The essence of this pattern is that one or more objects (observers) are registered to observe an event that may be raised by the observed subject. The subject provides an interface for attaching and detaching observers as well as notifying all observers that were attached about a new event. The observers contrarily define a notification function that is called by the subject as soon as a new event occurs. MFC embodies the Observer Pattern in its Document/View architecture. Documents in MFC are usually used to store the application’s data and thus act as subjects. Views on the other hand are attached to windows and display the data within documents on the screen while acting as observers. Since a document can have many views to display its data in different ways, a document updates all attached views when its content was changed by calling the function UpdateAllViews. The Observer Pattern in MFC’s Document/View architecture (see figure 2) ensures that the modification of a document’s data is propagated to all views that were attached to this document. 3.2.3. Conventions Conventions can help developers to better understand code that was written by other persons and thus try to address problems that evolve from the nature of very large projects. In order to be able to handle even big software development projects, they are broken down into smaller ones and assigned to teams. Code that is written in a more natural way with a structure that easier maps to a human’s native language can consequentially be easier to comprehend and understand [3]. To enable developers to use the associations and experiences they have gained from past projects, it is essential that all code produced within a software project (or even in general) follows a similar 744 design. This design aims at providing a coding foundation for all developers and thus tries to converge their work-related way of thinking expressed in so called coding conventions. Thereby, coding conventions not only suggest writing short and easy-to-understand statements, but also advices to use expressive variable and function names [13]. Figure 2: The Observer Pattern in MFC’s Document/View architecture. Across the Windows API, the foundation for the MFC, we identified the use of the Hungarian notation. In the Hungarian notation the first character or first several characters of a variable or parameter name identify the type of this variable or parameter. In addition, the MFC also defines its own set of naming conventions (e.g. “m_” for member variables or “On” for event handlers). With respect to maintenance and extension development of MFC, the used naming conventions certainly help developers to quickly acquaint themselves with existing code. They thus address the reusability and flexibility FKC, but from a developer’s point of view. 4. Conclusion This work aimed at presenting an approach that describes what to consider when reengineering frameworks with respect to their maintainability. As shown in the example of the MFC, frameworks might be subject to reactivation, even though their deprecation was already decided earlier. Thereby, the decision about reactivating a framework might be the result of an abruptly changing market or an organization’s strategy. The approach we presented identifies two main aspects that should be taken into account, when analyzing a framework’s internal condition after a reactivation: Preventing maintenance and enabling maintenance. We have shown that preventing maintenance can be achieved through a detailed documentation, the incorporation of contracts and default behavior as well as the consideration of standards. Enabling maintenance on the other hand helps reducing the complexity of future maintenance by designing the framework architecture in a way that it is easy to access by incorporating design patterns at places where it makes sense. Furthermore, conventions can support maintenance by allowing associations that were made earlier in the development phase. During our investigations, we identified several areas within the MFC that urgently require action to match this framework with the state-of-the-art in framework engineering. Refining the MFC’s internals at discussed places might help cutting down on the complexity of future maintenance projects. However, a careful investigation on the diversity of the MFC applicants would most likely 745 reveal that additional constraints exist which would increase the complicacy of conducting those changes. Further research could concentrate on the engineering of an approach that describes how to perform fixes to reactivated frameworks considering the situation of the framework community. Another open point might be the use of tools, such as Jfreedom [7], to support the framework reengineering process. 5. Bibliography [1] ARRANGO, G., PIETRO-DIAZ, G. and PIETRO-DIAZ, R., Domain Analysis Concepts and Research Directions, IEEE Computer Society 1991 [2] BEUGNARD, A, JÉZÉQUEL, J. M., PLOUZEN, N. and WATKINS, D., Making Components Contract Aware, IEEE Computer Society 1999 [3] CWALINA, K., ABRAMS, B. and RAGSDALE, S., Framework Design Guidelines: Conventions, Idioms and Patterns for Reusable .NET Libraries, Amsterdam, Addison-Wesley Longman 2005 [4] DEMEYER, S., MENS, K., WUYTS, R., GUEHENEUC, Y. G., ZAIDMAN, A., WALKINSHAW, N., AGUIAR, A. and DUCASSE, S, Workshop on Object-Oriented Reengineering, 19th European Conference on Object-Oriented Programming (ECOOP) 2005 [5] EAGLE, D., Evaluating Larch/C++ as a Specification Language: A Case Study Using the Microsoft Foundation Class Library, Iowa Sate University, Department of Computer Science, Iowa, USA 1995 [6] FAYAD, M. E. and SCHMIDT, D. C., Application Frameworks, Communications of the ACM, vol. 40, no. 10, pp. 32-38 1997 [7] FLORES, N. and AGUIAR, A., Jfreedom: a reverse engineering tool to recover framework design, Proceedings of the 6th European Conference on Object-Oriented Programming (ECOOP), Workshop on Object-Oriented Reengineering 2005 [8] FROEHLICH, G., HOOVER, H., LIU, L. and SORENSON, P., Designing Object-Oriented Frameworks, in: CRC Handbook of Object Technology, CRC Press, pp. 25-1 - 25-22 1998 [9] GAMMA, E., HELM, R., JOHNSON, R. and VLISSIDES, J., Design Patterns: Elements of Reusable ObjectOriented Software, Addison-Wesley Longman, Amsterdam 1995 [10] GREENFIELD, J. and SHORT, K., Software factories: assembling applications with patterns, models, frameworks and tools, Wiley Publishing, Inc., Indianapolis, USA 2004 [11] KOSKIMIES, K. and MOSSENBACK, H., Designing a Framework by Stepwise Generalization. Proceedings of the 5th European Software Engineering Conference 1995 [12] LAJOIE, R. and KELLER, R. K., Design and Reuse in Object-Oriented Frameworks: Patterns, Contracts, and Motifs in Concert, Proceedings of the 62nd Congress of the Association Canadienne Francaise pour l'Avancement des Sciences (ACFAS), Colloquium on Object Orientation in Databases and Software Engineering, Montreal, Canada, pp. 94-105 1994 [13] MOSER, H., Auswirkungen von Code Conventions auf Software Wartung und Evolution 2003 [14] NELSON, C., A Forum for Fitting the Task, IEEE Computer 27, pp. 104-109 1994 [15] TALIGENT, The Power of Frameworks, Addison Wesley 1995 746 AGENTEN-, MULTIAGENTENTECHNOLOGIEN Der Track „Agenten- und Multiagententechnologien“ befasst sich mit dem Entwurf, der Einführung und dem Einsatz von Agenten-/Multiagentensystemen in betrieblichen und gesellschaftlichen Anwendungsfeldern. Beiträge sollen entweder eine funktionale Perspektive oder eine Anwendungsperspektive einnehmen. Funktional orientierte Beiträge adressieren technologische Herausforderungen und stellen Lösungen und Systeme vor, die es erlauben, Agenten- und Multiagententechnologien erfolgreich in Unternehmensprozessen einzusetzen. Anwendungsorientierte Beiträge präsentieren innovative Softwarelösungen, die auf Basis der Agenten-/Multiagententechnologie für den konkreten Einsatz entwickelt wurden. Experimente, Fallstudien und Erfahrungsberichte, welche in überzeugender Weise die Notwendigkeit und die Vor- sowie Nachteile der Nutzung der Agenten-/Multiagententechnologie herausarbeiten, sind hier besonders willkommen. Leitungsgremium: Stefan Kirn, Universität Hohenheim (Federführender) Winfried Lamersdorf, Universität Hamburg Jörg Müller, Technische Universität Clausthal Programmkomitee: Michael Berger, Siemens AG, München Ralph Bergmann, Universität Trier Birgit Burmeister, Daimler AG, Böblingen Theodor Fischer, ipoint Systems (angefragt) Bogdan Franczyk, Universität Leipzig Otthein Herzog, TZI Bremen Kurt Kammerer, vi Franziska Klügl, Universität Würzburg Matthias Klusch, DFKI Saarbrücken Paolo Petta, Austrian Research Institute for Artificial Intelligence, Wien Vijay Sugumaran, University of Oakland / MI., USA Gerhard Weiß, Software Competence Center Hagenberg GmbH, Hagenberg COOPERATION MECHANISMS FOR MONITORING AGENTS IN SERVICE-ORIENTED ARCHITECTURES André Miede, Jean-Baptiste Behuet, Nicolas Repp, Julian Eckert, Ralf Steinmetz1 Abstract The Service-Oriented Architecture paradigm (SOA), e.g., realized with Web Services technology, enables enterprises to establish cross-organizational, service-based workflows. An important issue is the monitoring of the fulfillment of Service Level Agreements (SLAs) which define the responsibilities between the participants. Recent research has shown that agent technology is a useful approach in this context. Thus, we present ways for agent cooperation on different levels of abstraction. This cooperation aims at monitoring workflows and especially to react to deviations in different scenarios of SLA violations. 1. Introduction In an international and highly competitive economy, modern enterprises face many challenging requirements. To address these challenges, both the technology side and the business side have to cooperate seamlessly, while maintaining a mutual understanding of the challenges and their possible solutions on both sides. Among the different requirements which affect existing and future enterprise Information Technology (IT) architectures, the two following have a strong impact on both applications and research [8, 9, 11]: • Achieving a high flexibility of business processes and their underlying IT. • The integration of heterogeneous systems. The Service-Oriented Architecture (SOA) paradigm is an option to support an enterprise infrastructure which facilitates the addressed requirements. At the core of SOA is the “service” concept, which has to be understood as the technological representation of business functionality [8]. By using services as flexible components, business processes can be composed from them, abstracting processes from the underlying, mostly monolithic applications and allowing for compositions even across organizational boundaries. Such common and relevant scenarios remain an important focus of application scenarios and research in this field: cross-organizational, servicebased workflows. Establishing cross-organizational workflows is based on a trustworthy and dependable service exchange between the participating parties. Service Level Agreements (SLAs) are used to define 1 Multimedia Kommunikation (KOM), TU Darmstadt 749 both the responsibilities and requirements of the participants. However, the actually fulfillment or non-fulfillment of the SLAs has to be monitored. Ideally, this is done live at runtime to allow for reactions to detected deviations from the negotiated quality. In order to reduce further complexity and new, costly layers of manual administration, concepts from the field of self-organization (sometimes also known under the name of “Autonomic Computing”) can be utilized [10]. This paper presents cooperation mechanisms for agents to monitor service-based workflows in SOAs. These mechanisms are inspired by natural concepts from the field of self-organizing systems and extend an existing decentralized monitoring architecture. The rest of the paper is structured as follows: Section 2 gives an overview of a common application scenario for monitoring workflows, briefly discusses related work, and introduces the monitoring architecture the concept will be built on. Section 3 lays the foundation for the presented concept by discussing the key elements of the cooperation mechanism. Sections 4 and 5 show the core of the cooperation concept, namely intraand inter-cluster cooperation, which is used to react to deviations from SLAs in different scenarios. Section 6 presents important details about the implementation of the cooperation concept. Section 7 closes the paper with a summary of the key points and an outlook on future work. 2. Scenario and Related Work 2.1. Monitoring and Deviation Handling Scenario Cross-organizational service-based workflows are commonly described with the following scenario: to orchestrate higher level services and business processes, a service requester – i.e., an enterprise – integrates third-party services offered by various service providers, e.g., business partners. Service Level Agreements are contracted between the two parties, specifying in particular the service availability and the service performance by metrics like response time and throughput [6]. Figure 1 gives a schematic impression of this setup. Enterprise Boundary Business Process Layer Service Consumer Layer Service Provider Layer Application/ Legacy Layer Figure 1: Cross-Organizational, Service-Based Workflows Just as for any contract between clients and providers, the specification of the SLAs alone is no guarantee by itself. Thus, the monitoring of their fulfillment during runtime is needed as well and the actual service performance and availability have to be compared with the contracted ones, because services may, temporarily or permanently, not be able to fulfill the contracted requirements. Reasons for these failures are diverse as they can be caused by changes in the implementation of the services, overloads due to poor resource planning, crashes and outages of the service providers, or improperly negotiated SLAs that cannot be fulfilled by the services [3]. 750 On the other hand, the monitoring infrastructure itself may also experience problems. In this case, what at first sight was detected as an SLA violation, is none and thus should not be treated as one. More detailed information has to be gathered to support decisions for differentiated reactions. Based on the gathered monitoring information, deviations from the SLAs or infrastructure problems have to be handled accordingly, so that the workflows meet the requirements again. Reactions from such violations may include the renegotiation of the SLAs, the invocation of alternative services, the creation of new monitoring units, etc. However, in this scenario it is important to identify the cause of the problem as specific as possible to react the right way and closest to the failure. 2.2. Related Work Approaches for monitoring and alignment of service-based workflows can be classified into centralized and decentralized ones, and into functional and non-functional monitoring. Centralized monitoring and alignment means centralized gathering of monitoring data and centralized decision making, while the collection of monitoring data itself may be realized in a distributed manner by monitoring probes. Baresi and Guinea proposed such an approach, based on a central Monitoring Manager [1]. Although the possibility of recovery actions is mentioned, the authors did not provide any solution for deviation handling. To cope with scalability and performance problems in large-scale SOAs, centralized approaches are limited. Solutions have been proposed for distributed monitoring based on mobile agent technology. Most of the proposals for distributed monitoring are intended for network management, like [4]. But the agent technology has also been proved to be suitable for automated and decentralized monitoring of services. The AMAS.KOM architecture has been developed for this purpose [12, 13]. In the AMAS.KOM architecture (cf. Figure 2), service calls are redirected by proxies to agents which act as monitoring units. Agents are then used as proxies for services, monitoring them, checking the fulfillment of SLAs, and being able to take countermeasures in an autonomic fashion. Client Monitoring Factory Proxy Agent Agent Agent Web Service Web Service Figure 2: Simplified Overview of the AMAS.KOM Architecture The generation of Monitoring and Alignment Agents (MAA) is automatically done based on the workflow description and the corresponding business requirements. This generation is realized through a transformation of the workflow description and the business requirements into monitored instances of the workflow. The transformation process contains four steps: 751 1. Annotation 2. Modification and Splitting 3. Generation 4. Distribution Figure 3: Workflow Transformation Steps In the Annotation step, the business requirements are described for the complete workflow in a single policy document in machine-readable format. In the Modification and Splitting step, requirements for each service of the workflow are derived from the global policy document. The MAAs are created during the Generation step based on these derived requirements. As this step is especially relevant for the understanding of the architecture and the presented concept, more details are necessary: An MAA associated with an SLA for a given Web Service is generated and started by the central Monitoring Factory for the first call to this Web Service with the given SLA. The required configuration parameters are passed during the agent construction, i.e., which Web Service to monitor, the used SLA, specifications for handling deviations, etc. The content of the request to the Web Service itself is then sent to the Monitoring Agent subsequently. For further calls to the same Web Service with the same SLA, the reference to the responsible agent will be retrieved and then the request will be sent to the agent. Finally, the agents are distributed in the infrastructure during the Distribution step. The AMAS.KOM architecture has been designed to support automated monitoring and alignment of service-based workflows. Currently, monitoring capabilities have been integrated into the agents, which now work individually, forwarding service calls, and checking the fulfillment of the contracted SLAs. In order to increase the architecture’s abilities to react autonomously to different types of deviations, cooperation mechanisms among the agents can be considered the next necessary step. The current AMAS.KOM architecture is enhanced by integrating these cooperation mechanisms into the monitoring agents. Details of this concept are described in the following. 3. Cooperation Concept Overview 3.1. Hybrid Architecture – Agent Clusters A Web Service may be monitored by several agents at the same time, each monitoring the fulfillment of a contracted SLA. It seems therefore natural to group all the agents monitoring a given Web Service into an Agent Cluster. An overview of the overall cluster concept is provided in Figure 4. An Agent Cluster consists of the agents monitoring a specific Web Service and therefore corresponds to this Web Service. While each individual agent of the cluster is in charge of monitoring the fulfillment of a given SLA by the Web Service, a cluster of agents cooperating together by exchanging monitoring information has a better and more detailed view of the monitored Web Service. Therefore, such a cluster of cooperating agents has special diagnosis capabilities and can distinguish a Web Service crash from a simple inability to fulfill the contracted SLA, or from problems actually occurring inside the agent infrastructure. Consequently, it can determine suitable reactions to overcome the current problems and execute them in an autonomic way, e.g. invocation of alternative Web Services, SLA renegotiation, delegation of the monitoring to other agents, or other reactions. 752 Client Monitoring Factory Proxy Leader Agent Intra-Cluster Cooperation Cluster Agent Agent Agent Agent Inter-Cluster Cooperation Web Service Web Service Figure 4: Overview of the Cooperation Concept As a result, the Agent Cluster associated with a given Web Service is responsible for the monitoring of this Web Service and for the handling of many different types of deviations. 3.2. Distributed Approach Inside the Agent Cluster Based on Monitoring Agents The agents forming an Agent Cluster are basically all Monitoring Agents. A Monitoring Agent is in charge of monitoring the fulfillment of a given SLA by the Web Service. Web Service calls associated with a given SLA are redirected by proxies to the corresponding agent. This Monitoring Agent acts as a proxy for the Web Service, forwarding the requests to the Web Service, while monitoring it and checking the fulfillment of the associated SLA. Monitoring Agents are also capable of cooperation (cf. Section 4) and of taking countermeasures in an autonomic fashion. For tasks other than monitoring, such as the diagnosis of SLA violations based on the monitoring information from the different agents, the execution of countermeasures, or cluster management, it was first considered to add task-specialized agents into the Agent Clusters. For example, adding one “Diagnosis Agent” aggregating the monitoring information from the monitoring agents of the cluster and which is therefore capable of diagnosis. However, such an approach would require the presence of a multitude of task-specialized agents per cluster, and thus per Web Service, imposing a lot of overhead on the architecture. Moreover, such specialized agents with central functions would constitute critical points-of-failure inside the cluster. Since the number of Monitoring Agents per cluster (equal to the number of agreements contracted by the associated Web Service) is limited, there is no need for specialized agents, e.g., aggregating the monitoring information. An “n to n” communication pattern inside the Agent Cluster is fully scalable, and much more robust. Our proposal is therefore a distributed approach inside the Agent Cluster, based solely on Monitoring Agents and on their cooperation, as described in Section 4. 3.3. Elected Cluster Leader For some tasks in the cluster, which cannot be decentralized, an agent is elected among the Monitoring Agents: the Cluster Leader. Once elected, the Cluster Leader still performs its regular duties just as any Monitoring Agent, but it also takes extra responsibilities in addition. The Cluster Leader is especially the interface of the Agent Cluster for the agents of other clusters. It is in charge of the incoming communication from other Agent Clusters. If another Web Service 753 crashes, an agent monitoring this service will try to delegate its requests to an alternative Web Service. For this purpose, the latter agent may contact the corresponding Cluster Leader and ask for treating its requests. The Cluster Leader is responsible for receiving these requests and to forward them. It has to decide whether to accept such requests or not, according to the performance and other monitoring criteria of the Web Service it monitors. The Cluster Leader treats those external requests by delegating them to the Monitoring Agents of its cluster. Electing an agent among the Monitoring Agents of the cluster for taking extra responsibilities is a robust way of dealing with central non-critical functionalities like treating requests from other Agent Clusters. Details on how the Cluster Leader is elected and how it can be replaced in case of a failure are described in Section 4. 4. Intra-Cluster Cooperation 4.1. Exchange of Monitoring Information The communication pattern for the exchange of monitoring information between the agents inside a cluster is inspired by the self-organization mechanism Stigmergy, a communication style observed in nature, especially in ant colonies [2, 10]. Stigmergy is a form of indirect communication between agents by modifying their environment. It is a self-organization mechanism enabling very simple agents to create complex structures, like ants creating foraging networks or building nests only by releasing pheromones. Likewise, Monitoring Agents exchange their information in a distributed way by releasing positive and negative feedback in the Agent Cluster. After a Web Service call, a Monitoring Agent releases negative feedback if it detects an SLA violation or experiences a failure, and releases a positive feedback otherwise. Feedback consists typically of simple messages and may contain some information like the response time of the last service call, possibly the content of the service request, and in the case of a negative feedback whether it refers to a SLA violation or a failure. The other agents of the cluster modify their behaviors according to received negative feedback. In turn they check the Web Service if they have not done so lately and release feedback. While sending and receiving feedback, agents update their perception of the monitored Web Service (the Web Service’s “reputation”). In order to avoid a chain reaction of feedback releases, agents do not react to further negative feedback after a certain time. A Monitoring Agent reacts to negative feedback from other agents in the cluster with top priority since such feedback may suggest forthcoming problems for the agent itself. 4.2. Handling of SLA Violations After Monitoring Agent detects a deviation from the requirements, it releases negative feedback in its cluster. After that, it correlates the monitoring results from the other agents that it has received as feedback, updates its perceived reputation of the service, performs a simple diagnosis and determines whether the detected SLA violation actually comes from an inability for the Web Service to fulfill these requirements, a service crash, a problem in the agent infrastructure, or an isolated accident. Based on this simplistic diagnosis, the agent decides to delegate the monitoring of its SLA to another agent in the cluster, or to an alternative Web Service. Delegation to an alternative Web Service is performed when the agent perceives that the original service is unable to fulfill the contracted SLA, the mechanism is explained in Section 5. 754 In the case when its latest service call has failed, the Monitoring Agent first needs to get the result of that request as soon as possible. It requests this result from another agent in the cluster or an alternative Web Service. The choice of the agent in the cluster or the alternative Web Service to delegate to is based on the current perception of these (see agent reputation in Section 4.3 and service reputation in Section 5). In the cases of both a simple SLA violation and failure, Monitoring Agents may need to delegate to other agents or alternative Web Services for treating their further requests and fulfilling the SLAs. Such delegations must not be requested as in the case of a failure. Instead, the Monitoring Agents send calls for proposals to other agents in the cluster or to Cluster Leaders of alternative Web Services, which in turn reply with refusals or proposals, specifying their ability to fulfill the given SLA. Based on the received proposals and the current perception of the other agents or Web Services, the requesting agents decide on which services they delegate to. If no proposal is satisfying, i.e. better than the current Web Services, they decide to go on with the current configurations, and possibly ask for the renegotiation of the SLAs. 4.3. Management of the Agent Cluster The delegation model inside the Agent Cluster, in particular the choice of the Monitoring Agent to delegate to (see Section 4.2), is based on the “reputation” of the agents. The reputation of an agent describes its reliability and its eagerness to cooperate, for example by accepting requests or calls for proposals from other agents and by always releasing feedback. The reputation model we propose for agent reputation is the Certified Reputation model, developed by Huynh et al. [5]. This is a promising distributed model which therefore does not need any central agent for managing the reputations. Besides the choices of the delegating agents, agent reputation is used for the election of the Cluster Leader: the agent in the cluster with the best reputation is elected – if several agents have the same reputation, it is chosen randomly among the best, e.g., taking the one with the smallest id number. Since agents are fundamentally selfish, taking care of their own interests first, their wish for becoming the Cluster Leader and their fear of being excluded from the cluster are good incentives to make them cooperate and to build a good reputation. The self-management of the Agent Cluster is realized by a heart-beat mechanism centralized at the Cluster Leader. The latter sends heart-beats periodically to the agents in the cluster, in order to notify them of its presence. After receiving heart-beats from the leader, the other agents reply by sending heart-beats back. If an agent fails to receive a heart-beat from the leader, it launches an election. In this way, although there is initially no foreseen leader in the cluster, an election is immediately launched. By receiving heart-beats from the other agents, the Cluster Leader is aware of the presence of all the other agents in the cluster, and is able to detect if an agent does not respond anymore. In this case, the leader tries to delegate the tasks of the faulty agent to another agent in the cluster, or in case of necessity asks for the generation of a new agent in the cluster which will overtake the tasks of the faulty one. 5. Inter-Cluster Cooperation When a Monitoring Agent diagnoses that the Web Service it monitors has crashed or is unable to fulfill the contracted SLA, it may decide to delegate its service requests to an alternative Web Service. An alternative Web Service is a service that implements equivalent functionalities to the original one, but with better Quality of Service characteristics. A list of these alternatives has to be previously defined manually by the client during the SLA negotiation so that it is then given to the 755 agent in its policy file. In the future, these equivalent Web Services could be discovered and retrieved automatically using semantics. Monitoring Agents delegate requests to alternative Web Services by contacting their associated Cluster Leaders. In the case when service requests have failed in their own clusters, the Monitoring Agents still need to obtain the results for the current requests as soon as possible. For this purpose, they request the Cluster Leaders of the alternative Web Services for the results to these current requests. The Cluster Leaders treat these requests by delegating them inside their own clusters. Afterwards, as well as in the case of simple SLA violations without failure, Monitoring Agents may need to delegate to alternative Web Services for treating their further requests while respecting the SLAs. Such delegations must not be requested as in the previous case. Instead, the Monitoring Agents send calls for proposals to the Cluster Leaders of the alternative Web Services, which in turn reply with refusals or proposals, specifying the overall “reputations” (see 4.1) of their Web Services. Based on the received proposals, the requesting agents decide on which services they delegate to. If no proposal is satisfying, i.e. better than the current Web Services, they decide to go on with the current configurations, and possibly ask for the renegotiation of the SLAs. The inter-cluster cooperation is now limited to sending requests or calls for proposals to Cluster Leaders by Monitoring Agents of other clusters. Other cooperation mechanisms, such as communication between the leaders of the different clusters, are currently under investigation. Detection of SLA Violation by Single Agent WS = Web Service Result Obtaining WS Result No Yes WS Problem WS Problem Yes WS Problem: Inter-Cluster Request for Result No Agent Problem: Intra-Cluster Request for Result No Yes Adaptation for Future Agent Problem: Intra-Cluster Call for Proposals WS Problem: Inter-Cluster Call for Proposals Decision Options: • Delegate to Existing Agent in Cluster • Creation of New Agent in Cluster (+Delegation) • Continue with Current Configuration Decision Options: • Delegation to Altenative WS • SLA Renegotiation • Continue with Current Configuration Figure 5: Schematic Overview of the Different Deviation Handling Scenarios and their Interrelations To sum up the essence of Section 4 and 5, Figure 5 gives a schematic overview of what deviation handling scenarios can be handled by the proposed collaboration mechanisms. 756 6. Implementation The AMAS.KOM architecture and the extensions presented in this paper are implemented using the JADE framework, an Open Source Java framework for agent development, which is compliant with the FIPA specification (Foundation for Intelligent Physical Agents) [7]. For Web Service deployment Apache AXIS is used, thus the architecture supports the following common Web Service standards: WS-BPEL 2.0 for workflow description, WSDL 1.1 (Web Service Description Language) for the description of Web Service interfaces, SOAP 1.2 as protocol for the exchange of XML messages, REST as architectural style for service communication, and WS-Policy and WSSecurityPolicy as policy formats. The discussed enhancements of the AMAS.KOM architecture consist of adding cooperation capabilities to the monitoring agents. The implementation of these mechanisms is mainly realized by adding new behaviors to the existing agents, using the class Behaviour of the JADE framework. The JADE framework provides the necessary tools for agent development in Java. However, it has to be emphasized that agent development is not identical to object development. One special feature of agent computing is the autonomy of the agents. Autonomic agents cannot be accessed like objects, but they can only be accessed by sending messages to them in the FIPA ACL format (Agent Communication Language). For example, the Monitoring Factory consequently has to forward the content of the Web Service requests to the agents as ACL messages, and receives the responses in return as ACL messages as well. Such a communication between objects and agents is provided by the JADE framework, using a GatewayAgent. During the implementation, special attention is paid to the proper definition of new behaviors in JADE in order to allow their future enhancements. 7. Conclusions and Future Work In this paper, cooperation mechanisms for monitoring and deviation handling agents were presented. Cooperation is built around the idea of special domains, called Agent Clusters, where a set of autonomous agents is monitoring a service for different aspects and reacts to detected problems. Coordination is achieved by the election of a Cluster Leader, which has responsibilities both within the cluster (intra-cluster cooperation) and between clusters (inter-cluster cooperation). This setup makes it possible for the agents to detect deviations and to react to them in a timely manner and according to pre-defined specifications. The concept is an extension of the existing AMAS.KOM architecture, building on its code base using agent technology from the JADE framework. Future work aims at refining the concept further, especially detailing inter-cluster cooperation to allow for more functionality here and to approach a wider range of deviation scenarios. Furthermore, the WS-Re2Policy language has to be integrated to have a more flexible and dynamic means to specify what is to be monitored and how should be reacted to deviations [14]. Concerning the implementation, special care has be taken to ensure the maintainability and extensibility of the architecture, e.g., to extend the criteria to be monitored or to extend the available reaction possibilities. Another very important aspect is the evaluation of the concept and its implementation. Here, issues such as the imposed communication overhead have to be analyzed and weighed against the benefits 757 of automated monitoring and deviation handling. Due to page restrictions, results for these issues will be presented and discussed in our next publications. 8. Acknowledgments This work is supported in part by E-Finance Lab e.V., Frankfurt am Main, Germany and BearingPoint Management and Technology Consultants. 9. References [1] BARESI, L.; GUINEA, S., Towards Dynamic Monitoring of WS-BPEL Processes, in: Proceedings of the 3rd International Conference on Service oriented computing, 2005, pp. 269-282 [2] CAMAZINE, S.; DENEUBOURG, J.; FRANKS, N. R.; SNEYD, J.; THERAULAZ, G.; BONABEAU, E., SelfOrganization in Biological Systems, Princeton Studies in Complexity, Princeton University Press, 2003. [3] ECKERT, J.; SCHULTE, S.; NIEMANN, M.; REPP, N.; STEINMETZ, R., Worst-Case Workflow Performance Optimization, in: 3rd International Conference on Internet and Web Applications and Services (ICIW'08), Athens, Greece, June 2008. [4] GAVALAS, D.; GREENWOOD, D.; GHANBARI, M.; O'MAHONY, M., Using Mobile Agents for Distributed Network Performance Management, in: Proceedings of the Third International Workshop on Intelligent Agents for Telecommunication (IATA99), pp. 96-112, 1999. [5] HUYNH, T.D.; JENNINGS, N.R.; SHADBOLT, N.R., Certified Reputation - How an Agent Can Trust a Stranger, in: The Fifth International Joint Conference on Autonomous Agents and Multiagent Systems, 2006, May 8-12, Hakodate, Japan, 2006. [6] IBM CORPORATION, Web Service Level Agreement (WSLA) Language Specification, Version 1.0, January 2003. [7] JADE, Java Agent DEvelopment Framework, http.//jade.tilab.com/, 2008. [8] JOSUTTIS, N. M., SOA in Practice: The Art of Distributed System Design (Theory in Practice), O'Reilly Media, Inc., 2007. [9] KRAFZIG, D.; BANKE, K.; SLAMA, D., Enterprise SOA: Service-Oriented Architecture Best Practices (The Coad Series), Prentice Hall PTR, 2004. [10] MIEDE, A.; REPP, N.; ECKERT, J.; STEINMETZ, R., Self-Organization Mechanisms for Information Systems -A Survey, Proceedings of the Fourteenth Americas Conference on Information Systems (AMCIS 2008), 2008. [11] Newcomer, E.; Lomow, G., Understanding SOA with Web Services (Independent Technology Guides), AddisonWesley Professional, 2004. [12] REPP, N., Monitoring of Services in Distributed Workflows, in: 3rd International Conference on Software and Data Technologies (ICSOFT 2008), July 2008. [13] REPP, N.; ECKERT, J.; SCHULTE, S.; NIEMANN, M.; BERBNER, R.; STEINMETZ, R., Towards Automated Monitoring and Alignment of Service-based Workflows, in: IEEE International Conference on Digital Ecosystems and Technologies 2008 (IEEE DEST 2008), February 2008. [14] REPP, N.; MIEDE, A.; NIEMANN, M.; STEINMETZ, R., WS-Re2Policy: A Policy Language for Distributed SLA Monitoring and Enforcement, in: Proceedings of the Third International Conference on Systems and Networks Communications (ICSNC), 2008. 758 GEOREFERENZIERUNG IN DER LOGISTIK Michael Schuele, Paul Karaenke, Achim Klein1 Kurzfassung Georeferenzierung und Geographische Informationssysteme (GIS) finden in vielen Disziplinen außerhalb der Geographie weite Einsatzmöglichkeiten. So werden bereits heute viele ITAnwendungen durch Georeferenzierung unterstützt. In diesem Beitrag wird der Einsatz von Geoinformationen zur Individualisierung von Logistikleistungen untersucht. Geoinformationen stehen in direkter Beziehung zur räumlichen Adaptivität von Wertschöpfungssystemen. Als Anwendungsszenario werden logistische Leistungen des Passagiertransports an Flughäfen betrachtet. Es wird eine das Lieferkettenmodell unterstützende Softwarearchitektur vorgeschlagen und im Rahmen einer Simulationsstudie evaluiert. 1. Einführung Unter einem Lieferkettenmodell ist die Abbildung einer realen oder geplanten Lieferkette als ein System von Entitäten, die an der Herstellung, Transformation und Verteilung von Sach- und Dienstleistungen von den Lieferanten zu den Kunden beteiligt sind, zu verstehen [16]. Durch die Ausrichtung der angebotenen Leistungen auf die individuellen Besonderheiten und Wünsche des Käufers kann sich der Anbieter einen Wettbewerbsvorteil verschaffen. Diese strategische Vorgehensweise kann als Individualisierung bezeichnet werden. Im Rahmen der Individualisierung einer Leistung werden die Eigenschaften des Produkts so angepasst, dass sie der Präferenzstruktur des Kunden entsprechen [10]. Logistikleistungen können ebenfalls Gegenstand von Individualisierungsstrategien sein. Gegenstand dieses Beitrags ist ein Lieferkettenmodell der Passagiertransportsysteme zur Abfertigung der Flugzeuge an einem Flughafen. Die angebotenen Leistungen sind ausschließlich Dienstleistungen. Aus den sich stetig wechselnden Anforderungen an die Transportsysteme zur Abfertigung der Flugzeuge ergibt sich ein Individualisierungsproblem, welches eine räumliche Adaptivität des Lieferkettenmodells verlangt. Das bedeutet, es gilt Adaptionspotentiale des Lieferkettenmodells bzgl. der Dimension Raum zu finden. Als Lösungsperspektive wird die Perspektive der Software-Architektur-Modellierung anhand des Design Science Paradigmas eingenommen [5]. Die Methoden für den Lösungsansatz dieser Arbeit zur Lösung des Individualisierungsproblems sind im Bereich der Softwaretechnologie zu suchen. Das Lieferkettenmodell wird in einer Softwarearchitektur abgebildet. Die räumliche Perspektive wird in diesem Softwaresystem durch den Einsatz von Geoinformationssystemen umgesetzt. Die Eigenschaft der Adaptivität wird durch den Einsatz von Multiagententechnologie erreicht, da dabei das individuelle Verhalten autonomer Akteure abgebildet werden kann. 1 Lehrstuhl Wirtschaftsinformatik 2, Universität Hohenheim, D-70599 Stuttgart, Schwerzstr. 35. 759 Kapitel 2 beschreibt den Stand der Forschung in diesem Bereich. Kapitel 3 beschreibt die Problemstellung, formalisiert den Gegenstand des Lieferkettenmodells und diskutiert die Erwartungen an die Anpassung bezüglich der Dimension Raum in diesem Lieferkettenmodell. Kapitel 4 schlägt eine Softwarearchitektur für diese Fragestellung vor. In Kapitel 5 wird diese anhand einer Simulationsstudie evaluiert. Kapitel 6 schließt ein Resümee und gibt einen Ausblick auf weitere Arbeiten. 2. Verwandte Arbeiten Beim Blick in die Literatur stellt man fest, dass die Frage der Individualisierung von Gütern und Dienstleistungen bisher vor allem entweder unter einer Marketingperspektive sowie in einer einzelbetrieblichen Produktionsperspektive betrachtet worden sind. Letztere adressiert die Individualisierung durch eine im Einzelfall (bspw. Autoindustrie) sehr weitgehend aufgefächerte Variantenstrategie. Dieser Ansatz kann um exklusive Individualisierungsmöglichkeiten ergänzt werden, bspw., wenn auf individuelle Wünsche des einzelnen Kunden direkt eingegangen und die Lösung ggf. sogar unter Mitarbeit des Kunden entwickelt und realisiert wird [7]. Erprobte Forschungsansätze für das hier skizzierte Individualisierungsproblem sind in der Literatur nicht vorhanden, sieht man einmal von den Ergebnissen aus dem Gebiet der kundenindividuellen (Massen-)Produktion ab. Nach [3] kann der Ansatzpunkt der Individualisierung sowohl das Produkt als auch der Herstellungsprozess sein. Die Individualisierung findet in einer auf mehreren Phasen des Produktlebenszyklusses statt (von der Planung bis hin zur Nutzung). Die zentrale Forschungsfrage lautet deshalb: Wie können grundsätzlich diese Lösungspotentiale des Wertschöpfungssystems erschlossen werden und anhand welcher Kriterien kann die theoretische und praktische Relevanz dieser Fragestellung bemessen werden? Verwandte Konzepte sind Anpassung (engl. customization) [3], Kundenindividuelle Massenfertigung (engl. mass customization) [3][11][10], Personalisierung (engl. personalization) [10] und Prosumer (engl. Kunstwort aus Producer und Consumer) [17][3]. Unternehmen können Individualisierungsstrategien dadurch entwickeln, dass sie einer Differenzierungsstrategie folgend ihr Leistungsportfolio um kundenindividuelle Leistungen erweitern. Bereits Gegenstand aktueller Forschungen sind die dazu erforderlichen Anpassungen in Marketing, Produktion und Distribution (z.B. [8], [6], [15]). Bisher nur wenig betrachtet wurde allerdings die Rolle der jeweiligen Wertschöpfungssysteme, die als Verbund der wertschöpfenden Aktivitäten aller beteiligten Akteure die Gesamtleistung für den Endkunden erzeugen. Kirn et. al. nehmen als zentrale Forschungshypothese an, dass die Individualisierung von Sachgütern und Dienstleistungen eine eigenständige Leistung ist, die vom jeweiligen Wertschöpfungssystem erbracht wird. Unterschiedliche Wertschöpfungssysteme innerhalb ein- und derselben, aber auch von verschiedenen Branchen unterscheiden sich unter anderem auch danach, welche Individualisierungspotentiale sie jeweils eröffnen, und nutzen. Um diese Potentiale zu fördern, sind Änderungen im Wertschöpfungssystem notwendig. Änderung von Wertschöpfungssystemen, die zielgerichtet, d.h. explizit vor dem Hintergrund einer individuellen Anforderungserfüllung erfolgen, werden als Adaption des Systems bezeichnet. Die Adaption kann bezüglich verschiedenster Dimension erfolgen, die Aufmerksamkeit widmet sich hauptsächlich den Dimensionen der räumlichen, zeitlichen und ökonomischen Adaptivität [7]. Dieser Beitrag widmet sich hauptsächlich der räumlichen Dimension, welche aus einer Perspektive der Software-Architektur-Modellierung betrachtet wird, so dass die Individualisierungsleistungen im Wertschöpfungssystem und die damit verbundene Anpassung von Wertschöpfungssystemen 760 spezifische Anforderungen an Softwaresysteme stellen. Bei [3] wurde eine Anwendungsarchitektur für Mass Customization Informationssysteme entwickelt, welche die spezifischen Anforderungen der Wettbewerbsstrategie Mass Customization erfüllen. In den Arbeiten [18][1][2][12] werden jeweils Konzepte vorgestellt, die dem allgemeinen Kapazitätsproblem an Flughäfen entgegenwirken. Hierzu werden Lösungen gezeigt, die die Verkehrsplanung auf dem Vorfeld durchführen. Die Anforderungen mit räumlichen Daten zu arbeiten werden teilweise diskutiert [18][2][12]. In [18] wird als Grundlage für die räumliche Abbildung der Verkehrswege ein diskretes Modell erstellt. In dem Beitrag von [2] werden die Ergebnisse durch den Einsatz eines Simulationswerkzeuges erzielt. Die Adaptivität bezüglich der Dimension Raum wird durch die Abbildung des Vorfeldes in einem Graphen erreicht. Aus dem Bereich der in diesem Beitrag eingesetzten Technologien zeigen die Arbeiten in [9] einige Anwendungsbeispiele für raumbezogene Informationssysteme. Aus den eigenen Forschungsarbeiten [13][14] lassen sich ebenso Erkenntnis über die Integration von Geoinformationssystemen und Multiagentensystemen ableiten. In diesem Beitrag ist die Motivation für die Planung der Logistikdienstleistung am Vorfeld des Flughafens nicht ein Kapazitätsproblem, sondern ein Individualisierungsproblem. Die Verkehrsplanung auf Basis von räumlichen Daten wird eher als Werkzeug zur Lösung des Problems herangezogen, als als zentrale Problemstellung angesehen. Gegenstand dieser Arbeit ist das gesamte Lieferkettenmodell und nicht nur die direkt den Passagiertransport durchführenden Akteure. Zudem wird die Anwendung von Technologien aus der Geodatenverarbeitung zur Beschreibung der Adaptivität bezüglich der Dimension Raum explizit diskutiert. Auf diese Weise wird der Begriff der Individualisierung im Bereich des räumlichen Kontexts fassbarer. 3. Problembeschreibung 3.1. Lieferkettenmodell Der Gegenstand des Lieferkettenmodells der Passagiertransportsysteme als ein Teil der Bodenabfertigung am Flughafen kann in einer graphenbasierten Abbildung dargestellt werden. Hierbei werden die teilnehmenden Akteure als Knoten (Kreis) dargestellt und die Interaktionsbeziehungen zwischen diesen Akteuren als ungerichtete Kanten. Abb. 1 zeigt das betrachtete mehrstufige Lieferkettenmodell. Ein vergleichbares Modell kann beispielsweise [4] entnommen werden. 1st tier Supplier OEM Passagiertransportservice Busfahrer Customer Distributor Passagiertransportservice Ground Handling Service Manager Flug Abfertigung des Fluges Airline Service Provider Airline Passagier Abbildung 1. Lieferkettenmodell für Passagiertransporte am Flughafen Die einzelnen Akteure werden nachfolgend näher erläutert. • Busfahrer: Der Busfahrer hat die Funktion die Dienstleistung des Passagiertransports vom Terminal zum Flugzeug bzw. vom Flugzeug zum Terminal zu erbringen. 761 • • • • Ground Handling Service Manager: Der Ground Handling Service Manager fungiert als Schnittstelle zwischen dem Busfahrer und dem Airline Service Provider und übernimmt die Gesamtkoordination des Passagiertransportservice, indem die einzelnen Aufträge den Busfahrern zugeordnet werden. Airline Service Provider: Der Airline Service Provider fungiert als Organisation, die als Anbieter des Passagiertransportservice, einer Teildienstleistung zur Abfertigung des Fluges, mit dem Kunden (Airline) in direktem Kontakt steht und über die Serviceleistung verhandelt. Die abzufertigenden Aufträge sind an den Ground Handling Service Manager weiterzugeben. Airline: Die Airline fungiert mit ihren abzufertigenden Flugzeugen als der Kunde der angebotenen Dienstleistungen der Airline Service Provider. In diesem Beitrag wird die Airline als Endkunde im Lieferkettenmodell angesehen. Passagier: Der Passagier ist der finale Kunde des Lieferkettenmodells, der die Leistung des Fluges im eigentlichen Sinn abnimmt. Der Passagier tritt auch als die zu transportierende Entität in Erscheinung. In der weiteren Betrachtung wird der Akteur Passagier im Lieferkettenmodell keine Relevanz haben. Aufgabe des dargestellten Lieferkettenmodells ist es, den Passagiertransportservice für ankommende und abgehende Flugzeuge durchzuführen. Das heißt, die Airline beauftragt einen Airline Service Provider, Passagiertransportservice durchzuführen. Der Ground Handling Service Manager sammelt die Aufträge und teilt diese zum Durchführungszeitpunkt den einzelnen Busfahrern zu. Ständig wechselnde, individuelle Anforderungen wie z. B. Ankunftszeiten, Abflugszeiten, Parkpositionen der Flugzeuge und Terminalposition der Passagiere, meistens verursacht durch Verspätungen, ergeben ein unübersichtliches Szenario. Die Busfahrer selbst fahren die Passagiere von einer bestimmten Parkposition des Flugzeuges zu einem bestimmten Terminal und andersrum. In solch einem Lieferkettenmodell gilt es, die eingesetzten Ressourcen möglichst effizient zu nutzen. Um dennoch auf die beschriebenen, individuellen Anforderungen eingehen zu können, muss dem Lieferkettenmodell die Eigenschaft der Adaptivität zur Verfügung stehen. In diesem Beitrag wird die Adaptivität im Bezug auf die Dimension Raum untersucht. Dies bietet sich bei der großen Flächenausdehnung des Flughafengeländes, in dem die räumliche Lage der einzelnen Akteure eine Rolle spielt an. Dies fordert den Einsatz von Technologien aus der Geodatenverarbeitung, was sich in unterschiedlichen Facetten auf die einzelnen Akteure des Lieferkettenmodells auswirkt. 3.2. Individualisierungsproblem Die Merkmale des Individualisierungsproblems werden im Folgenden beschrieben und in Tab. 1 zusammengefasst. Diese Merkmale dienen gleichzeitig als Anforderungskatalog für die in Kapitel 4 zu entwickelnde Softwarearchitektur. Das zu individualisierende Produkt ist die Dienstleistung des Passagiertransportservice. Der Anforderungsspezifikator ist die Airline, welche spezifische Anforderungen an den Passagiertransportservice stellt. Inhaltlich bedeutet das, dass die Dienstleistung sich auf die nicht planbaren Parameter Parkposition der Flugzeuge und Terminalposition der Passagiere anpasst. Die Individualisierung bezieht sich auf den Prozess der Koordination und den Passagiertransport selbst. Die Individualisierung kann erst stattfinden, wenn die Parkposition und die Terminalposition der Passagiere feststehen. Beteiligt an der Individualisierung sind die Airline als Anforderungsspezifikator, der Airline Service Provider, der ein ökonomisches Interesse an die Auswirkungen der Individualisierung hat, der Ground Handling Service Manager, der die Anforderungen mit Hilfe von Technologien der Geodatenverarbeitung in der Auftragskoordination umsetzt, und der Busfahrer, der den Ground Handling Service Manager mit geografischen Informationen versorgt und den Passagiertransport selbst durchführt. In diesem 762 Beitrag findet die Individualisierung im Bezug auf die Dimension Raum bei den Akteuren Busfahrer und Ground Handling Service Manager statt. Der Busfahrer erhält eine Technologie zur eigenen geographischen Positionsbestimmung, die an den Ground Handling Service Manager mitgeteilt wird. Der Ground Handling Service Manager kennt die Position der abzufertigenden Flugzeuge und die der Busse und ordnet aufgrund dieser Information den Busfahrern Aufträge zu. Dies kann mit Hilfe eines Softwaresystems gelöst werden, welches räumliche Daten verarbeiten kann. Darüber hinaus kann das Szenario über eine graphische Schnittstelle visualisiert werden. Für die Koordination der einzelnen Akteure untereinander und deren Anpassung muss eine Technologie gewählt werden, die die Eigenschaft der Adaptivität in einem verteilten System unterstützt. Die Individualisierung durch die Adaptivität bezüglich der Dimension Raum soll eine positive ökonomische Auswirkung auf das gesamte Lieferkettenmodell haben. Merkmale des Individualisierungsproblems Produkt Anforderungsspezifikator Prozess Individualisierungsakteure Individualisierungsdimension Unterstützung der Dimension Raum im Softwaresystem Adaptivität im Softwaresystem Zielsetzung der Produktion Ausprägungen im betrachteten Lieferkettenmodell Dienstleistung des Passagiertransportservice Airline stellt die spezifischen Anforderungen Koordination der Passgiertransporte Airline Service Provider, Ground Handling Service Manager, Busfahrer Raum geographisches Positionierungssystem, Softwaresystem mit der Funktionalität geographische Daten zu verarbeiten, Visualisierung Technologie mit der Fähigkeit die Eigenschaft der Adaptivität in einem verteilten System zu unterstützen allgemein: Kostenminimierung unter Nebenbedingungen; hier: Reduzierung einzusetzender Transportkapazitäten (variable Kosten) durch Weg- und damit Zeitminimierung Tabelle 1. Merkmale des Individualisierungsproblem 4. Softwarearchitektur In diesem Abschnitt werden die Funktionalitäten des Lieferkettenmodells in einer Softwarearchitektur abgebildet. Die Architektur beschreibt die akteurspezifischen Informationssysteme und ihre Kommunikationsbeziehungen. Zur Repräsentation autonomer Akteure und Lösung zwischen den Akteuren bestehender Koordinationsaufgaben bietet sich der Einsatz der Multiagententechnologie an. Die Multiagententechnologie liefert einen reichhaltigen Vorrat an Konzepten, Modellen und Methoden, um gerade solche Koordinationsaufgaben unter Berücksichtigung der Ziele einzelner Akteure und ihren Zielbeziehungen zu lösen. Entsprechende Softwarearchitekturen für Multiagentensysteme erlauben die effiziente Implementierung von bottom-up-Koordinationsverfahren und basieren damit nicht auf konventionellen, hierarchischen Ansätzen der Planung und Steuerung. In Multiagentensystemen wird das individuelle Verhalten von Akteuren durch Softwareagenten repräsentiert. MAS bieten somit Ansätze, Probleme in einer verteilten Umgebung adaptiv und flexibel zu lösen. Die Basis für die jeweiligen Informationssysteme bildet ein Softwareagent. Der Zusammenschluss, dieser auf mehrere Informationssysteme verteilte Softwareagenten, bildet ein Multiagentensystem. Für die Interaktionen innerhalb des verteilten Systems wird die Standardkommunikationsschnittstelle der Softwareagenten verwendet. Abb. 2 zeigt die Softwarearchitektur der einzelnen 763 Informationssysteme und ihrer Schnittstellen in einem UML-Komponentendiagramm. Die Gesamtarchitektur besteht aus einem Informationssystem für die Akteure vom Typ Busfahrer, dem BusDriver Information System, einem Informationssystem für die Akteure vom Typ Ground Handling Service Manager, dem Ground Handling Service Manager Information System, einem Informationssystem für die Akteure vom Typ Airline Service Provider, dem Airline Service Provider Information System und einem Informationssystem für die Akteure vom Typ Airline, dem Airline Information System. Jeder Akteur kann im Lieferkettenmodell mehrfach vorhanden sein. Das BusDriver Informationssystem ist das einem Busfahrer zu Verfügung stehende Informationssystem. Es besteht aus den Subkomponenten BusDriver Agent und einem geographischen Positionierungssystem. Das Positionierungssystem ermittelt die aktuelle geographische Position und stellt diese dem BusDriver Agent zur Verfügung. Der BusDriver Agent liefert dem Ground Handling Service Manager Information System Informationen über die aktuelle Verfügbarkeit und geographische Position des Busses. Der Busfahrer wird vom Ground Handling Service Manager Information System über den nächsten durchzuführenden Passagiertransport informiert. Für einen Bus kann ein GPS-Empfänger zur Ermittlung der augenblicklichen geographischen Position verwendet werden. Global Positioning System (GPS) ist eine satellitengestützte Navigations- und Positionierungstechnik. GPS-Empfänger bestimmen aus den Signalen, die aus den Satelliten ausgesandt werden, den genauen Standort auf der Erde. GPS entspricht den Anforderungen der Positionsbestimmung auf dem Flughafenvorfeld im Freien und der erforderlichen Genauigkeit. Abbildung 2. UML-Komponentendiagramm der Softwarearchitektur Das Ground Handling Service Manager Information System ist eine Koordinationskomponente. Es besteht aus den Subkomponenten Ground Handling Service Manager Agent, GIS und GIS GUI. Der Ground Handling Service Manager Agent erhält vom Airline Service Provider Information System Informationen über die durchzuführenden Aufträge mit den zugehörigen Terminal- und Parkpositionen. Zusammen mit den durch das BusDriver Information System gelieferten Daten über die aktuelle Verfügbarkeit und geographische Position der Busse wird mit Hilfe der GIS Subkomponente die Zuordnung der durchzuführenden Aufträge zu den Bussen vorgenommen. Durch eine Routenrechnerfunktion in der GIS Subkomponente wird der verfügbare Bus mit der geringsten Anfahrtsdistanz gewählt. Die GIS GUI Subkomponente bildet das aktuelle Geschehen 764 am Vorfeld des Flughafen graphisch auf einer Karte virtuell ab. Die Zeitdauer, die für die einzelnen Passagiertransporte benötigt wurde, wird vom Ground Handling Service Manager Agent an das Airline Service Provider Information System übermittelt. Die gesammelten Anforderungen lassen auf den Einsatz der Technologie der Geoinformationssysteme (GIS) schließen. Ein Geoinformationssystem dient der Erfassung, Speicherung, Analyse und Darstellung aller Daten, die einen Teil der Erdoberfläche und die darauf befindlichen technischen und administrativen Einrichtungen sowie geowissenschaftliche, ökonomische und ökologische Gegebenheiten beschreiben. Das Airline Service Provider Information System hat eine Vermittlerrolle. Es besteht aus der Subkomponente Airline Service Provider Agent. Der Airline Service Provider Agent verhandelt mit dem Airline Informationssystem über die zu erbringende Servicedienstleistung und vermittelt die notwendigen Informationen bezüglich Terminal- und Parkposition der einzelnen Flugzeuge vom Airline Information System zum Ground Handling Service Manager Information System. Eine Analyse der vom Ground Handling Service Manager Information System übermittelten Information über die benötigte Zeitdauer zeigt hier die Effizienz des Lieferkettenmodells auf. Das Airline Information System ist die Schnittstelle des Kunden, der Airline, zum Softwaresystem. Es besteht aus der Subkomponente Airline Agent. Der Airline Agent verhandelt mit dem Airline Service Provider Information System über die zu erbringende Dienstleistung und liefert dem Airline Service Provider Information System die Informationen über die abzufertigenden Flugzeuge. 5. Evaluation 5.1. Simulationsmodell In diesem Abschnitt wird die in Kapitel 4 vorgestellte Softwarelösung evaluiert. Da der Einsatz der Informationssysteme im Realsystem nicht evaluiert werden kann, wählt man hier als Evaluierungsmethode die Simulation des Lieferkettenmodells. Hier wird der Spezialfall der Multiagentensimulation (MASim) verwendet. Für die Simulation des Lieferkettenmodells kann folgendes Simulationsmodell erstellt werden. Es werden die vier Agenten der in Kapitel 4 vorgeschlagenen Softwarearchitektur als Agentenklassen mit ihrem dort definierten Verhalten definiert. Zusätzlich gibt es einen World Agent. Das Szenario wird abgeleitet aus dem EU-FP6-IST Projekt BREIN, in dem der Flughafen Stuttgart als Anwendungsszenario zur Verfügung steht. • • • • World Agent: Der World Agent repräsentiert die Umwelt, in der die Agenten leben. In diesem Fall werden die geographischen Daten des Vorfelds des Flughafens geordnet nach thematischen Schichten wie z. B. Fahrwege und Parkpositionen aus Datenfiles in die Simulation geladen. Alle anderen Agenten können sich dieser geographischen Information bedienen. BusDriver Agent: Der BusDriver Agent repräsentiert einen Bus. Die Aufträge mit den Auftragsinformationen werden bei Verfügbarkeit an diesen erteilt. Der Bus Driver Agent sendet stetig seine aktuellen Status und seien geographische Position an den Ground Handling Service Manager Agent. Der kürzeste Fahrtweg kann mit Hilfe der geographischen Informationen des World Agenten ermittelt werden. Die Geschwindigkeit der Busse ist konstant. Ground Handling Service Manager Agent: Der Ground Handling Service Manager Agent koordiniert die durchzuführenden Aufträge an die verfügbaren Busse. Eine Visualisierung des Geschehens am Vorfeld wie im Ground Handling Service Manager Informationssystem in Kapitel 4 vorgesehen kann durch die Simulationsplattform geleistet werden. Airline Service Provider Agent: Der Airline Service Provider Agent informiert den Ground Handling Service Manager über die durchzuführenden Passagiertransporte und wertet die 765 • benötigten Zeiten für die einzelnen Busfahrten aus. Die Verhandlungen über die Dienstleistung mit der Airline werden in der Simulation nicht abgebildet. Airline Agent: Der Airline Agent repräsentiert ein abzufertigendes Flugzeug. Bei Ankunft eines Flugzeuges wird der Airline Service Provider Agent über den Auftrag und die zugehörige Auftragsinformation in Kenntnis gesetzt. 5.2. Simulationswerkzeug Für die Simulation des hier beschriebenen Lieferkettenmodells wird eine Simulationsplattform mit der Fähigkeit geographische Daten verarbeiten zu können benötigt. Frühere Arbeiten skizzieren Kopplungenarchitekturen von GIS und MASim und deren Implementierung, die diese Fähigkeit mit sich bringen [13][14]. Das vorgestellte System aus dem Beitrag [13] wird als Simulationsplattform für die Evaluierung verwendet. Diese Kopplung von GIS und MASim basiert auf einem eigenen in JAVA implementierten GIS und einer auf dem JADE (Java Agent DEvelopment Framework) aufbauenden MASim. Die Kontrolle des Gesamtsystems liegt hier bei der GIS Komponente. Das MAS ist wie eine Analysefunktion direkt in das System eingebunden. 5.3. Experiment Zu beweisen gilt es, dass durch die Adaptivität des Lieferkettenmodells bezüglich der Dimension Raum, also durch den Einsatz der Technologien aus der Geodatenverarbeitung, die benötigte durchschnittliche Dauer für eine Busfahrt effizienter ist als ohne die Eigenschaft der Adaptivität. Es werden zwei Versuchszenarien simuliert. Im ersten Versuchszenario nutzt der Ground Handling Service Manager Agent die Information über die geographische Lage der einzelnen BusDriver Agents um mit Hilfe einer Routenberechnungsfunktion (Dijekstra) des GIS dem verfügbaren BusDriver Agent mit dem kürzesten Anfahrtsweg den Auftrag zuzuordnen. Im zweiten Versuchszenario werden die Aufträge dem ersten verfügbaren Bus Driver Agent zugeordnet. Auf diese Weise entsteht eine Vergleichbarkeit der durchschnittlichen Dauer für eine Busfahrt. Unterschiedliche Verhaltensfunktionen sind zu diesem Zweck im Simulationsmodell für den Ground Handling Service Manager Agent zu implementieren. Im Simulationsmodell werden 200 aus dem Realszenario abzufertigende Flugzeuge betrachtet. Der Simulationszeitraum ist ein Tag, ein Simulationsschritt ist 10 Sekunden. Die Geschwindigkeit der Busse wird im gesamten Simulationsmodell als konstant angenommen, so dass ein kürzerer Weg eine Zeitersparnis bedeutet. Für die Durchführung die Passagiertransporte stehen zehn Busse zur Verfügung. Im Szenario existiert ein Ground Handling Service Manager Agent und ein Airline Service Provider Agent. Den Busfahrern wird in beiden Versuchen unterstellt auf den Verkehrwegen des Vorfelds den kürzesten Weg zwischen zwei Positionen am Vorfeld finden zu können. Für das Aufnehmen und Aussteigen der Passagiere wird eine konstante Zeitdauer angenommen. Die Zeit für einen Passagiertransport wird als Zeitraum zwischen dem Zeitpunkt der Auftragszuweisung und dem Zeitpunkt der Statusmeldung über die Verfügbarkeit definiert. 5.4. Simulationsergebnis Die Simulation selbst wird auf der Oberfläche des Simulationswerkzeugs visualisiert. Während der Durchführung werden die Zeiten für die einzelnen Passagiertransporte durch den Airline Service Provider Agent in ein Logfile geschrieben. In Abb. 3 ist die Auswertung der Zeitreihen in einem Diagramm zu sehen. Auf der x-Achse ist die Uhrzeit des Anfangszeitpunktes des Auftrages angetragen, auf der y-Achse wird die Dauer des Passagiertransportes in Minuten dargeboten. Für beide Versuchsszenarien gibt es eine Zeitreihe im Diagramm. Die mit Kreisen markierten Stellen 766 weisen darauf hin, dass der Versuch, in dem keine räumliche Adaptivität durch den Einsatz von GIS-Funktionalitäten vorhanden ist, die Zeitdauer für die Durchführung eines Auftrags tendenziell größer ist. Dieses Ergebnis bestätigt auch den Wert der durchschnittlichen Zeitdauer. Die einzelnen Ausreißer, die in der Zeitreihe ohne Adaptivität eine bessere Zeit liefern als in der Zeitreihe mit Adaptivität, lassen vermuten, dass der Grund in der nicht vorausschauenden Koordination zu suchen ist. Es wird immer der BusDriver Agent mit der geringsten Anfahrtsstrecke gewählt. Ein besseres Ergebnis wäre z. B. zu erzielen, wenn für die nächsten beiden Aufträge die Summe der Anfahrtsstrecken möglichst gering sein soll. Die zufällige Auswahl der freien BusDriver Agents im Versuch ohne Adaptivität zeigt diese Fälle auf. Abbildung 3. Auswertung der Simulation 6. Zusammenfassung und Ausblick Diese Arbeit zeigt einen Ansatz für eine Softwarearchitektur, die die Problemstellung der Individualisierung in einem Lieferkettenmodell für Passagiertransporte am Flughafen aufgreift. Focus liegt hier auf der Eigenschaft der Adaptivität im Bezug auf die Dimension Raum. Der Beitrag definiert die Ausprägungen des Individualisierungsproblems und transformiert diese in die vorgestellte Softwarearchitektur. Die Anforderungen des Individualisierungsproblems konnten erfolgreich umgesetzt werden. Als weiterführende Arbeit steht die Untersuchung weiterer Versuchszenarien im Lieferkettenmodell für Passagiertransportsysteme am Flughafen an. Das Verschieben der konstanten Parameter wie z. B. der Anzahl der zur Verfügung stehenden Busse oder der Anzahl der durchzuführenden Fahrten wird mit Sicherheit zu interessanten Ergebnissen führen. Von einer geographischen Perspektive betrachtet kann das Lieferkettenmodell auf einen weiteren in der Fläche arbeitenden und zur Flugzeugabfertigung notwendigen Service dem Gepäcktransportservice ausgedehnt werden. Interessant ist die Tatsache, dass ein Gepäcktransporter das Gepäck mehrerer Flugzeuge auf einmal befördern kann. Ein weiteres Ziel kann die Beschreibung und Entwicklung weiterer Anknüpfungspunkte für die Eigenschaft der Adaptivität bezüglich der Dimension Raum sein. Wissenswert ist ebenso die Untersuchung der Auswirkungen dieser Adaptivitätspotentiale auf alle beteiligten Akteure im Lieferkettenmodell. Der in diesem Beitrag beschriebene Ansatz könnte zugleich in anderen Anwendungsgebieten eine Rolle spielen. Sowohl die Beschreibung eines generischen Ansatzes der Adaptivität bezüglich der Dimension Raum, als auch die Entwicklung eines generellen Ansatzes für eine Softwarearchitektur kann für die Forschung im Bereich der Individualisierung einen erheblichen Beitrag leisten. 7. Acknowledgement This work has been supported by the BREIN project (http://www.gridsforbusiness.eu) and has been partly funded by the European Commission’s IST activity of the 6th Framework Programme under contract number 034556. This paper expresses the opinions of the authors and not necessarily those 767 of the European Commission. The European Commission is not liable for any use that may be made of the information contained in this paper. 8. Literaturverzeichnis [1] Cheng V., Surface Operation Automation Research For Airport Tower And Flight Deck Automation, in: Proceedings of the 7th International IEEE Conference on International Transportation Systems, Washington, 2004, S. 607-612. [2] Confessore, G.; Liotta, G.; Grieco, R., A simulation-based architecture for supporting strategic and tactical decisions in the apron of Rome-Fiumicino Airport, in: Proceedings of the 37th Conference on Winter Simulation, Orlando, Florida, 04.-07. Dezember 2005, S. 1596-1605. [3] Dietrich, A. J., Mass Customization Informationssysteme – Anforderungsanalyse und Architekturentwurf, Dissertation, Universität Hohenheim, 2007. [4] Heiserich, O., Logistik: eine praxisorientierte Einführung, Wiesbaden 2002. [5] Hevner, A. R.; March, S. T.; Park, J.; Ram, S., Design Science in Information Systems Research, in: MIS Quarterly 28 (2004) 1, 2004, S. 75-105. [6] Kleinaltenkamp, M.; Burghard, W.: Standardisierung und Individualisierung – Bestimmung der Schnittstelle zum Kunden. In: Kleinaltenkamp, M.; Fließ, S.; Jacob, F. (Hrsg.): Customer Integration – Von der Kundenorientierung zur Kundenintegration. Wiesbaden 1996, S. 163-176. [7] Kirn, St.: Individualization Engineering - Gestaltung adaptiver Wertschöpfungssysteme für individualisierte Sachgüter und Dienstleistungen, Cuvillier Verlag, Göttingen 2008. [8] Lampel, J.; Mintzberg, H.: Customizing Customization. In: Sloan Management Review 38. 1993, S. 21-30. [9] Moll, P. (Hrsg.), Raumbezogene Informationssysteme in der Anwendung, Verlag Irene Kuron, Bonn 1995. [10] Piller, F. T., Mass Customization. Ein wettbewerbsstrategisches Konzept im Informationszeitalter, DeutscherUniversitäts-Verlag, Wiesbaden 2003. [11] Pine II, B. J.: Maßgeschneiderte Massenfertigung. Wien 1994. [12] Pestana, G; Silva, M.; Casaca, A.; Nunes J., An airport decision support system for mobiles surveillance & alerting. In: Proceedings of the 4th ACM international Workshop on Data Engineering For Wireless and Mobile Access, Baltimore, MD, USA, 12. Juni 2005, S. 33-40. [13] Schüle, M.; Bieser, T.; Karaenke P.; Kirn, S., Integration einer Multiagentensimulation in ein Geoinformationssystem., in: Bichler, M.; Hess, T.; Krcmar, H.; Lechner, U.; Matthes, F.; Picot, A.; Speitkamp, B.; Wolf, P. (Hrsg.): Multikonferenz Wirtschaftsinformatik, MKWI 2008, München, 26.2.2008 - 28.2.2008, Proceedings, GITO-Verlag, Berlin 2008. [14] Schüle, M.; Herrler, R.; Klügl, F., Coupling GIS and Multi-Agent Simulation – Towards Infrastructure for Realistic Simulation, in: Lindemann, G.; Denzinger, J.; Timm, I.; Unland, J. (Hrsg.): Multiagent System Technologies, Proceedings of the 2nd MATES 2004, Springer, Berlin 2004, S. 228-242. [15] Spring, M.; Dalrymple, J.F.: Product customization and manufacturing strategy. In: International Journal of Operations & Production Management 20. 2000, S. 441-467. [16] Supply-Chain Council: SCOR Model, Version 7.0. 2007. [17] Toffler, A.: Future Shock. New York 1970. [18] Visser H. G.; . Roling, P: Optimal Airport Surface Traffic Planning Using Mixed Integer Linear Programming, in: Proceedings of the AIAA's 3rd Annual Aviation Technology, Integration, and Operations (ATIO) Technical Forum, Denver 2003. 768 FROM A RESEARCH TO AN INDUSTRY-STRENGTH AGENT PLATFORM: JADEX V2 Alexander Pokahr, Lars Braubach1 Abstract Since the beginning of the nineties multi-agent systems have been seen as a promising new software paradigm that is capable to overcome conceptual weaknesses of mainstream object-oriented software solutions. Despite these theoretical advantages, in practice agent software is rarely used and as software paradigm has been widely superseded by the service-oriented architecture. One key reason for the slow adoption of agent-based ideas is that existing agent software in most cases does not provide business-relevant features such as persistency or scalability. Hence, in this paper it is analyzed which essential business requirements exist and a solution agent platform architecture is presented. This architecture has been implemented within the Jadex V2 agent platform, which is a complete overhaul of the V1 architecture. 1. Introduction In literature agent orientation is often promoted as new software paradigm with which shortcomings of object-oriented solutions can be solved. Nonetheless, in practice only few agent-based systems have been successfully deployed and the paradigm is not well recognized by industry practitioners. One question that will be tackled in this paper is, why this is the case and how this can be changed. In general, agent orientation brings a new perspective into software engineering and considers an application of being composed by a multitude of individual agents working together to provide the required functionalities. The agent paradigm assumes that an agent is an autonomous entity that acts on its own behalf and communicates with other agents via asynchronous messages. Hence, agent orientation is a paradigm that naturally fits for the development of loosely-coupled distributed and concurrent systems. On the one hand, distribution is supported by the fact that agents make no assumptions where other agents are located meaning that the location of an agent is transparent for its communication partners. This allows a software developer to distribute agents across system borders as needed without having to change the application logic. On the other hand, concurrency is supported by the agent’s autonomy, i.e. each agent can work independently from others and thus the agents of a multi-agent system can in principle be executed in parallel. Therefore, multi-agent systems provide a clear metaphor for building potentially massively parallel applications. With respect to current and emerging trends the importance of distribution and concurrency is further illustrated. In the following three of the most prevailing trends (cf. e.g. [10]) are sketched: • Ubiquitous computing is the vision of Weiser [15] and means that computing devices become smaller and smaller and finally vanish into the environment. In a ubiquitous environment a lot 1 Distributed Systems and Information Systems Group, University of Hamburg, Vogt-Kölln-Str. 30, 22527 Germany. 769 • • of independent small devices exist and they often need to build up a heterogeneous service network in order to fulfill user requirements. Hence, ubiquitous computing needs a programming paradigm that takes into account distribution as a core concept. Autonomic computing [7] puts the administration effort of systems in the focus of attention. The basic idea here is to build self-* (-heal, -optimize, -configure, -protect) systems, which can manage themselves by monitoring and adjusting their individual components. Such behavior can only be achieved when components can act independently from each other and take over different responsibilities. Typically, in an autonomous system for each business component a dedicated management component is responsible for controlling the behavior of the first. Hence, autonomous computing architectures are conceptually agent-based and per-se concurrent. Multicore processors [2] have reached the consumer market since 2006 and improve processing power by providing more than one processing unit on board of a single chip. Nowadays dual or quadcore processors are common and it seems reasonable that in the near future multicore processors will be available with a huge number of cores. In order to exploit that processing power the software has to be programmed in a way that supports multiple processes or threads. This is feasible using state of the art programming languages. Nevertheless the available concepts for controlling concurrency such as semaphores and monitors are very low-level and lead to error prone code that additionally is hard to program. Therefore, a programming paradigm providing higher-level concurrency concepts is needed. If agent technology provides solutions for these and other challenges the question arises, why agent orientation has not yet made it to mainstream software engineering projects and so few systems have been deployed. In the following some key reasons are presented: • Heterogeneity of the research field leads to the severe problem that there are no agreed-upon conceptual frameworks. Therefore it exists a multitude of programming languages, methodologies and agent platforms making the choice of the right artifacts a hard one. • The lack of interest of industry players causes too few respectively too expensive industry-grade agent tools being available. One reason for the low number of companies selling agent-oriented solutions is the high research and development effort required before agent products can be sold. Many companies tried to use agent technology in the nineties during the agent hype phase and failed due to the immatureness of the field. As no immediate return on invest was producible the paradigm has been abandoned and the current service-oriented architecture hype lets many companies concentrate on the service wave. • The lack of integration with existing mainstream technology and tools makes agent technology risky to use for companies, because they have to decide whether they want to rely on proven technologies or utilize agent approaches – mostly they cannot have both. But, as agent orientation has orthogonal advantages with respect to existing paradigms, the choice in such a setting is always to use the proven technology. In the following it will be investigated how these challenges can be addressed under a technical viewpoint, i.e. with respect to adequate infrastructure support. For this purpose in Section 2 the requirements for industry-grade agent software are examined. In Section 3 existing agent solutions are evaluated from the perspective of a business user. Thereafter, in Section 4 the Jadex V2 architecture is presented and it is detailed how the architecture helps to address the issues mentioned. In Section 5 the content is summarized and an outlook to planned future work is given 2. Requirements Much has been said (cf. [8, 10]) about the advantages of agent technology for building applications in the context of the current and emerging trends as outlined in the introduction. Many of these advantages are closely related to functional requirements, such as the ability to adequately react to 770 changes in a dynamic environment [9] or the necessity of high-level abstractions to support decomposition and organization of large application structures [8]. For a widespread industrial adoption, a technology not only has to provide the functional capacities to solve the specific problems at hand, but also has to answer the question how well it embeds into some given business context. In [3], a criteria catalog was developed that includes, besides functional aspects, especially also non-functional requirements that allow assessing how well an artifact under investigation fits to the peculiarities of an application context. These non-functional requirements (also called software quality attributes) are the key-factor when moving from research prototypes to industrial quality software. In the following, the most important criteria are quickly sketched. • • • Usability refers to the features of an artifact from the viewpoint of a single user or usage context. Relevant criteria in this category are individualization and extensibility, which state how easily an artifact can be adapted to a concrete usage context. From a developer perspective, simplicity/intuitivity and learnability/familiarity are important factors that indicate how fast and efficient an artifact can be put into practice. Operating ability criteria are performance, robustness, stability and scalability, which describe how well the artifact behaves when considering varying system loads (performance), presence of failures (robustness), long term behavior (stability) and varying problem sizes (scalability). Pragmatic aspects are not related to using or operating an artifact, but mostly to the incurred efforts, costs and risks. Concretely, the maturity of an artifact has a direct effect on the risk of a software project. Costs are usually comprised of initial (purchase) costs and follow-up costs, e.g. for operation/maintenance or for training of personnel. Finally, additional efforts typically arise due to technical boundary conditions of an artifact, such as incompatibilities to other existing, required or preferable technology. It should be noted that a simple “the more the better” rating (e.g., of performance) is not suitable for any concrete software project, because these criteria are highly interrelated. Depending on the business context, suitable trade-offs have to be found, e.g. between simplicity, performance and costs. As a consequence, generic software infrastructures, e.g. for agent based systems, need to be adaptable to business needs. 3. Related Work As outlined in the last section, industrial uptake of agent technology does not directly follow from the inherent conceptual advantages compared to more conventional software paradigms like objects, components or services. In addition to those conceptual advantages, agent infrastructures need to exhibit quality attributes similar to the conventional implementations, such as Java EE application servers. These two aspects can be paraphrased as “having something to add” and “having nothing to remove”. Agents have something to add to existing solutions, because they, e.g., facilitate more flexibility and quick adaptation to changes and can introduce a higher conceptual level when considering goals (“what should be done?”) instead of only actions (“how is something done?”). But agent infrastructures should also have nothing to remove. Especially features, which are well supported by conventional paradigms, like the support for modular software development, integration with existing technologies such as databases or user interface frameworks and high operating ability (scalability, robustness, etc.), could be knock-out criteria, when being absent from agent-based solutions. Infrastructures for agent development therefore need to balance the two above mentioned aspects. Existing agent infrastructures can be broadly categorized into two different approaches. The first approach focuses on the first aspect (“having something to add”), i.e. this approach aims at building specialized agent-oriented solutions. The second approach tries to “having nothing to remove” by 771 reusing existing conventional tools and techniques as much as possible and adding agent-oriented concepts and technology only in a selective way. The primary advantage of building specialized agent-oriented solutions (first approach) is that agent-specific characteristics can be taken fully into account. Therefore, the expressive power of the agent paradigm can be used for building various aspects of an application. The major drawback of this approach is that these specialized solutions usually do not fit well into existing traditional infrastructures. This means that existing features of e.g., applications servers, such as persistence, can not easily be reused in the agent context. As a result, proprietary solutions are implemented to support these features in a more agent-suitable way. An example of this approach is the widely used JADE agent platform (see e.g.[1]), which aims at providing agent-oriented middleware services according to the FIPA specifications [13]. For supporting non-functional requirements, additional components have been developed that e.g. support agent persistence or reliable messaging. Among the advantages of JADE is the simplicity, such that JADE can also be used for rapid proto-typing of agent applications, and the large user base, which results in numerous add-ons of varying quality being available. JADE has limitations with regard to the seamless integration with mainstream technology and poor scalability due to the use of a thread-based concurrency model. Further examples of the first approach are other agent platforms such as 3APL and Jason [1]. The main motivation behind the second approach (reusing existing conventional tools and techniques) is minimizing the gap between agent technology and the software engineering mainstream. In this approach, the seamless deployment of agents or agent-like features into existing objectoriented/component infrastructures is seen as the appropriate way to overcome the barriers that currently hinder the adoption of agent technology in the industry. Besides encouraging industry adoption, a major benefit of this approach is the reduced implementation effort and increase in maturity due to relying on proven industry grade products. Moreover, due to adherence to industry standard APIs, developers can choose from the large body of commercial or open source implementations (e.g. of Java EE application servers), which in turn might offer certain advantages or disadvantages depending on the application context. The drawback of this approach is that the usage of standard technologies imposes certain constraints on which and how agent concepts can be implemented. Depending on the used basis, therefore usually only a subset of existing agent features can be realized without compromising the mainstream integration and as a result, only advantages specific to those agent features can be obtained. Examples of this approach are agent platforms such as Whitesteins LS/TS [14] and the Agentis AdaptivEnterprise Suite. Both focus on integration with a Java EE technology base, but whereas the main aim of the Agentis suite is integrating BDI-style goal orientation, LS/TS puts more weight on agent concurrency and message passing. Among the advantages of LS/TS is the ability to run the same application on different execution environments (Java SE/Java EE) targeted to development vs. production settings and also the availability of different reasoning engines ranging from simple task-based to more high-level goal-oriented agents. Main criticism with regard to LS/TS is the high complexity, which makes it unsuitable for rapid prototyping of agent applications and the fact that the platform is closed and therefore no user community is available. Besides platforms, there are also programming languages like the JACK agent language [1], extending languages like Java to include agent-oriented constructs. Both approaches have their merits. The first approach is suitable for contexts in which agent advantages have a big payoff (e.g. logistics domains, [12]) and therefore the easy integration with mainstream technologies is not so important. On the other hand, the second approach allows integrating agent-oriented ideas into an existing business IT landscape and is therefore seen as the more promising approach for achieving mainstream industrial uptake of agent technology. 772 4. Jadex V2 Architecture The Jadex agent framework (see e.g. [1]) mainly consists of the agent infrastructure, and tools for the development of agent systems. The concrete requirements for Jadex V2 have been revealed by an evaluation of V1 against the criteria catalogue from Section 2. In the following a short review of the evaluation with respect to the non-functional criteria is given. • Usability The usability of Jadex V1 has been evaluated to high due to several reasons. First, Jadex does not introduce a new programming language, but relies completely on a hybrid language approach. This approach distinguishes between structural and behavioral aspects, which are specified in the suitable mainstream languages XML and Java respectively. Second, the BDI concepts are interpreted in an intuitive way, which is near to their folk-psychological meaning and includes an explicit representation of goals. This also allows a natural transition from modeling to implementation via existing goal-oriented methodologies like Tropos or Prometheus. Third, Jadex also fulfills software technical reusability requirements by providing a BDI-based modularization concept called capabilities. • Operating ability The operating ability has been identified as one crucial aspect for industrial exploitation of agent platforms and is hence very well-supported by commercial platforms like JACK or LS/TS. In V1 operating ability has been evaluated to only fair. In order to assess the quality of agent platforms in this respect, several small benchmarks have been conducted on a standard desktop PC as explained in the following. The performance has been tested via agent creation resp. termination time. In this respect the creation/termination of agents was at a rate of circa 50 resp. 250 agents/sec. The scalability has been measured by the number of agents that can be started on a standard Java VM with normal 64MB heap space. The number of agents was limited to about 200, which is mainly caused by the high 200kb memory footprint of agents. The robustness and stability are mainly features of the agent platform. Robustness is to some degree ensured by the isolation of agent execution, which prohibits the propagation of errors to the platform layer, i.e. a faulty agent cannot easily cause the platform to fail. The stability has been tested via long-running test-cases, which demonstrate that at the platform as well as the architecture layer no memory-leaks are existent. • Pragmatic aspects This category led to a good evaluation for Jadex V1. The acquisition and installation of Jadex is unproblematic, because it can be directly downloaded from internet and also contains extensive documentation material. Furthermore, the technical boundaries are kept low. This is achieved by a clean separation between the platform and architecture layer and extension points at both layers. In general, the evaluation showed that the non-functional aspects usability and pragmatics are already covered to a sufficient degree in V1. Hence, in Jadex V2 the objectives are keeping the levels of usability and improvements should especially be targeted to the operating ability area. The resulting Jadex V2 agent infrastructure is composed of the agent platform and the agent kernel(s) (cf. Figure 1). The responsibility of the agent platform is to ensure the continuous execution of the agents inhabiting the platform. On the contrary, the agent kernel determines the agent architecture used, i.e. it defines which concepts can be used for programming agent behavior. The infrastructure has been designed in such a way that it allows kernels as well as platforms being used interchangeably. On the one hand this means that in combination with a platform different kernel implementations can be used (e.g. BDI and/or rule-based). On the other hand, it is also possible to use a kernel on different kinds of platforms (e.g. Standalone or JADE). The details of the platform and kernel architectures will be explained in the following sections. In this respect it will be especially highlighted how platform and kernel address the requirements from Section 2. 773 4.1. Platform Architecture The Jadex platform architecture exhibits two main characteristics: 1. It can execute agents regardless of their internal architecture. 2. It can exploit an arbitrary middleware for reusing available services. The first aspect is important, because applications differ in the complexity of agents that is required. If e.g. ant algorithms shall be built it is sufficient to use simple reactive agent architectures, while problem solving tasks might require cognitive capabilities and therefore deliberative agent architectures are a better fit. One could even argue that it can have advantages to build parts of the application using different agent architectures according to the complexity of the agents at hand. Rule-based BDI … Standalone Platform Middleware Adapter … J2EE Platform Agent Platform … Bridge … Platform Platform Service Service FIPA (AMS, DF,…) Clock … Platform Platform Execution Execution Middleware Middleware Middleware Infrastructure Protocols Jadex Agent Infrastructure Kernel Kernel FIPA Application Application Application Library Library Custom Custom Code Code Figure 1: Jadex V2 architecture In order to execute different agent architectures within a single platform it is necessary to define the responsibilities of the kernel and the platform. A platform has the minimal duties of executing an agent, delivering messages to the agent, notifying the agent at certain time points and indicating that an agent should kill itself. Agent kernels must therefore exhibit the following methods for an agent: public boolean executeAction(); public void messageArrived(IMessageAdapter message); public void notifyDue(); public void killAgent(); The executeAction() method has the purpose to execute an agent for a single step, i.e. the agent should perform an action and return the control to the platform in a short period of (CPU) time. If the agent execution exceeds some platform-defined limit, the platform might decide to abort agent execution. The boolean return value indicates if the agent wants to be executed again. If this is not the case it can be reactivated by messages or a timing info. The messageArrived() method delivers a message to an agent for processing. It is noteworthy here, that the supplied message has to be an IMessageAdapter, which is an interface that hides platform-specific transport details and allows an agent to retrieve all information about the message in a generic way. This means that Jadex does not assume a fixed message structure such as FIPA ACL [13]. Instead, the message adapter provides access to name-value pairs of the underlying message and additionally to the message type. The message type contains meta information about the message and can be used to extract the relevant information from the message. In this way besides FIPA ACL also alternative formats such as Email can be supported. The notifyDue() method is necessary for allowing an agent to be reawakened at an agent-defined point in time. For this purpose the agent uses the clock service for registering the desired time point. The service then guarantees to call the notifyDue() method on the agent at this time point. Different clock service implementations allow for running the same application in simulation as well as real-time execution mode [12]. Finally, the killAgent() method requests the agent to kill itself and starts its takedown process. For an agent it is necessary to rely on services of the platform adapter. These basic services are especially needed for sending messages and, waking resp. cleaning up the agent, and fetching the platform. A cutout of the adapter interface is shown below: 774 public void sendMessage(IMessageAdapter message); public void wakeup(); public void cleanupAgent(); public IPlatform getPlatform(); Using the sendMessage() method an agent can send a message via the platform. The platform is then responsible for all aspects of the transport, which can be either locally or remotely depending on the addresses of the target agents. The wakeup() method is needed to ensure that an agent’s processing can be activated. It is e.g. called when a message is placed in the agent’s inbox or other (kernel-specific) events happen and requests the platform scheduler to call executeAction() on the corresponding agent. CleanupAgent() is the platform equivalent to killAgent() on the agent side and initiates the removal of the agent. An agent can call this method if it wants to be disposed. The platform always has to know when an agent is going to be killed, because it handles the agent’s resources and has to release them afterwards. Finally, the getPlatform() method gives an agent access to the platform itself and its platform services (cf. Fig. 1). Platform services are a mechanism for building up the platform’s functionality in an extensible manner. If the platform should e.g. support the FIPA standards, services for AMS and DF can be added. Agent platforms in most cases are devised for a specific application scenario, e.g. a lightweight platform for a mobile device versus a heavyweight platform for back office functionalities. The second criterion of being able to reuse existing middleware allows developing different kinds of platforms for Jadex agents and facilitates the integration with proven solutions. Picking up the example it makes sense to build a platform for mobile devices with a low resource footprint restricting its functionalities to a minimum, whereas a platform for back office tasks needs features like high dependability and hence could be build upon a Java EE server. Regarding the requirements discussed in Section 2 the platform architecture directly contributes to the usability and pragmatics and indirectly also to the operating ability criteria. With respect to the usability it supports individualization and extensibility to a high degree. On the one hand kernels and platforms are rather independent of each other and on the other hand the flexible service-based platform infrastructure supports the adaptation of platforms according the application context. Considering the pragmatic dimension the proposed architecture mainly contributes to the technical boundary conditions, because it facilitates the integration with existing middleware infrastructures. Finally, operating ability is indirectly supported by the customizable service approach of the platform, which allows services being tailored to the concrete demands. E.g. if stability and robustness are crucial, persistent AMS und DF services could be developed. 4.2. Rule Kernel Architecture To simplify the development of different kernels as part of the Jadex agent infrastructure, a basic rule kernel has been devised. The goal of this kernel is to form a basis for different concrete reasoning kernels that already provides or simplifies the provision of quality attributes. The rule kernel ensures that concrete kernels can be built rather independently from (non-functional) quality attributes thereby focusing on functionality (i.e. describing the behavior of agents). It is realized as a generic rule engine and concrete kernels are specified in terms of a state structure and transition rules that operate on the state (see Figure 2). The declarative specification of the concrete reasoning engine leaves much more room for optimizing the execution in different directions than what would be possible with a procedural implementation. Basis of the rule kernel is the interpreter, which connects the kernel to the underlying platform by implementing the required Java interface (cf. Section 4.1). The interpreter itself represents a typical rule engine [5] consisting of an agenda, a pattern matcher and a state or working memory. Rules are specified in a CLIPS-based [5] condition language, whereby the action part is assumed to be pure Java. The pattern matcher determines based on the state and a given set of rules at any time the 775 possible variable assignments to fire some of the rules. The matching rules with corresponding variable assignments are stored as so called activations in the agenda. In each agent execution step, the interpreter fires one activation from the agenda, and informs the pattern matcher about the incurred state changes. The pattern matcher then updates the agenda to reflect newly matched or no longer matched activations. In addition to activations from the agenda, the interpreter has to execute so called external entries, which represent asynchronous occurrences happening parallel to the agent execution, such as messages received from other agents. During each execution step, these entries are copied to the state, leaving details of, e.g., message processing to the concrete kernel rules. Flyweights Parsers … Runtime Model Metamodel … Kernel Kernel Rules Rules Feature 1 Feature 2 … OAV OAV State State Java Impl. J2EE Impl. … Pattern Pattern Matcher Matcher Rete Impl. Treat Impl. … Agenda Ext. Entries … Interpreter Interpreter (Rule (Rule Engine) Engine) Rule Kernel OAV OAV Type Type Model Model Concrete Kernel (e.g. BDI) Programmer‘s Programmer‘s Interface Interface (optional) (optional) Figure 2: Jadex V2 Rule Kernel Architecture (concretizes kernel layer of Figure 1) The state uses an OAV (object-attribute-value) triplet representation of data, because this representation can be easily mapped to different implementations (e.g. Java objects, database tables, RDF, etc.) that support different quality attributes. The type model describes the structure of data items that can be stored in the state and is used for data access as well as (optional) runtime consistency checking in the rule kernel. Usually a separation in metamodel and runtime elements is useful, to distinguish between data shared among all agent instances of the same type and runtime data that is private to each agent instance. The kernel rules describe all possible forms of state transition and thereby determine the behavior according to a specific agent architecture. Different implementations of the pattern matcher exhibit different performance characteristics. E.g. the Rete algorithmbased [4] implementation has a higher memory footprint due to caching partial matches, but has superior execution speed compared to less memory consuming implementations, such as TREAT [11]. The manipulation of data based on an OAV model and the specification of behavior in form of rules represent very low-level ways of interfacing with the system. Therefore, concrete kernels will usually offer a higher level programming interface, which hides low-level details. For example, flyweights [6] can provide a Java object like access to the data in the state and parsers can hide rule details behind Java-like expressions. The rule kernel architecture contributes to achieving desired quality criteria (cf. Section 2) by providing an efficient base layer for concrete kernels. Operating ability criteria such as scalability and performance are achieved using proven rule-based technology such as the Rete algorithm. Individualization is supported by providing different implementations of the components. Therefore, different state representations allow adequate fulfillment of conflicting requirements depending on the situation (e.g. efficiency using in-memory objects, vs. robustness using database storage) and different pattern matcher implementations allow to choose between fast execution and low memory footprint. Also, in the pragmatics area, for technical boundary conditions different implementations can be developed for concrete execution environments, such as a state representation based on EJB technology for Java EE execution requirements. 4.3. BDI Architecture The Jadex BDI architecture has been described extensively in the literature (e.g. in [1]) and it has been one major objective of Jadex V2 to keep the BDI functionality and the offered programming 776 interface as similar as possible. Hence, here the Jadex BDI model will only be outlined briefly. In general, BDI agents are programmed with beliefs (subjective knowledge), goals (desired outcomes) and plans (procedural code for achieving goals). Jadex distinguishes the procedural knowledge in plans from the descriptive knowledge and the former is specified in Java classes while the latter is defined in an XML-based ADF (agent definition file). From within Java plans the developer can access agent functionality via API calls, which e.g. allow accessing beliefs or dispatching goals. In order to keep this programming model the same as in V1 a special layer has to be placed on top of the rule kernel. This layer internally uses the functionalities offered by the rule kernel and adds Java-based access facilities in the style of the flyweight pattern [6]. This means whenever the user calls an BDI-based method (such as getBelief()) the new layer will create a flyweight (here BeliefFlyweight), which exposes the same functionality as in V1 (here e.g. getFact()) and internally translates calls to OAV state operations. Internally, the BDI state representation as well as the BDI functionality has been specified in terms of a rule engine implementation. As already denoted the BDI state representation consists of two OAV type models: a metamodel and a runtime model. The metamodel contains elements that can be used for defining Jadex agent types and therefore allow specifying application-specific agent types and their beliefs, plans and goals. In addition, a parser has been implemented that reads/writes XML agent definitions to/from an OAV state. In contrast, the runtime model contains information about agent instances, such as the agent’s current belief, goal and plan instances. In addition to the state representation the BDI functionalities have been rebuilt using production rules. For this purpose the BDI functionalities have been categorized into different groups such as belief handling, event processing, goal processing, goal deliberation, and many more and for each group several rules have been devised. An example rule is illustrated in CLIPS-like notation below: ?plan <- (plan (processingstate “ready”) (lifecyclestate “body”)) ?agent <- (agent (plans contains ?plan)) => // Java code for plan execution The execute plan body rule states that whenever an agent has a plan that is in processing state “ready” and in lifecycle state “body” an activation will be created. The action side of this rule contains the concrete Java code for plan execution and in this case just resolves the value of the bound ?plan variable, fetches its plan body and invokes it. In V2, the existing set of V1 BDI functionalities has been completely rebuilt using the rule-based approach. Because rules have been grouped according to their functionality, it is now possible, to use streamlined BDI rule sets, e.g. when some advanced features, such as goal deliberation are not required. Additionally, new functionalities (e.g. emotions) can much more easily be added to the existing BDI functionality. Besides the BDI kernel it is planned to also develop a reactive kernel and a task-model based kernel. While the reactive kernel will consist of a simple API directly on top of the basic rule kernel (e.g. for ant-like agents), the task-model kernel will not use the rule base functionality but instead provide a simple object-oriented agent programming model (cf. JADE). 4.4. Evaluation The new Jadex V2 architecture has been devised in a way that makes the underlying rule kernel transparent to a high degree for the agent programmer. Hence, the evaluations for usability and pragmatics are not affected by the changed architecture, whereas the operating ability has been assessed again. In general the V2 operating ability has been evaluated to good, because the performance and scalability could be improved. Regarding the performance benchmark creation and deletion of agents could be improved by an order of magnitude to 500 resp. 2000 agents/s. Also the scalability could be improved. The number of agents that can be started on a standard Java VM with normal 64MB has enhanced to over 2000, each with a footprint of circa 25kb. This shows that the 777 proposed architecture is able to preserve the advantages of Jadex V1 while the operating ability is now comparable to commercial solutions available. 5. Conclusions and Future Work In this paper it has been argued that current trends such as ubiquitous computing and multicore processors require advanced distribution and concurrency concepts that are covered insufficiently by established software paradigms like object-orientation. Agent orientation offers solutions for these problems but is not extensively used in practice. One important reason for this is that the lack of integration with existing technology and tools. In this respect, only if agent systems “have something to add” and “have nothing to remove” they will be considered to be used in commercial settings. Nothing to remove means here that functional and in particular non-functional properties of existing solutions should be kept by agent-based offerings. To achieve this, the new Jadex V2 framework architecture has been presented. One main characteristic of this architecture is the strict separation between platform (execution environment) and kernel (agent architecture), which allows both being exchanged independently. In this way, on the one hand different agent architectures can be used on the same platform (e.g. BDI versus rule-based) and vice versa one kernel can be used in multiple execution environments (e.g. a mobile- vs. serverbased implementation). The platform architecture itself is characterized by a flexible approach using pluggable services, facilitating extensibility and adaptability to the application context. For kernel implementations a rule kernel base has been proposed, which offers a rule mechanism and an OAV state representation. On this (optional) rule kernel concrete kernel implementations such as BDI can be built. Using the rule kernel has advantages especially concerning non-functional aspects, because its usage is independent of its implementation and components can be adapted according to the concrete demands (e.g. for a fast execution the Rete rule matcher can be used). To further improve robustness and stability, future work will focus on the platform level. A Java EE platform adapter will allow executing agents in the context of application servers, which offer major advantages in the area of non-functional requirements by features such as built-in transactional execution, load management and replication. Furthermore, the standardized deployment procedures of application servers will lower the barrier for adoption and installation of agent-based solutions. 6. References [1] Bordini, R., Dastani, M., Dix, J., El Fallah Seghrouchni, A., Multi Agent Programming, Springer, 2005. [2] Borkar, S., Thousand core chips: a technology perspective. In Proc. of (DAC '07), ACM, 2007. [3] Braubach, L., Pokahr, A., Lamersdorf, W., A Universal Criteria Catalog for Evaluation of Heterogeneous Agent Development Artifacts, in: From Agent Theory to Agent Implementation (AT2AI-6), 2008. [4] Forgy, C., Rete: A Fast Algorithm for the Many Patterns/Many Objects Match Problem. Artif. Intell. 19(1), 1982. [5] Friedman-Hill, E., Jess in Action - Rule-based Systems in Java, Manning, 2003. [6] Gamma, E., Helm, R., Johnson, R., Vlissides, J., Design Patterns, Addison-Wesley, 1995. [7] IBM, Autonomic Computing: IBM’s Perspective on the State of Information Technology, IBM, 2001. [8] Jennings, N., An agent-based approach for building complex software systems. Commun. ACM 44, 4, Apr. 2001. [9] Kirn, S., Herzog, O., Lockemann, P., Spaniol, O. (Eds.), Multiagent Engineering, Springer 2006. [10] Luck, M., McBurney,P., Shehory, O., Willmott,S., Agent Technology: Computing as Interaction, AgentLink, 2005. [11] Miranker, D., TREAT: A Better Match Algorithm for AI Production System Matching, Proc. Of. AAAI’87, 1987. [12] Pokahr, A., Braubach, L., Sudeikat, J., Renz, W., Lamersdorf, W., Simulation and Implementation of Logistics Systems based on Agent Technology, in: Hamburg International Conference of Logistics (HICL’08), 2008. [13] Poslad, S., Charlton, P., Standardizing agent interoperability: the FIPA approach. In Multi-Agents Systems and Applications, Springer, 2001. [14] Rimassa, G., Greenwood, D., Kernland, M., The Living Systems Technology Suite. In Proc. ICAS’06, 2006. [15] Weiser, M., The Computer for the Twenty-First Century, Scientific American, September 1991. 778 RFID UND UBIQUITOUS SERVICES RFID (Radio Frequency Identifi cation), Sensorik und andere Technologien des Ubiquitous Computing erweitern die Möglichkeiten der betrieblichen Informationsverarbeitung um eine automatisierte Verknüpfung von Systemen mit physischen Objekten und bilden die Grundlage zum „Internet der Dinge“. In der Folge können einerseits etwa Prozesse in Logistik, Produktion, Verkauf und Aftersales deutlich feingranularer kontrolliert und gesteuert werden, z.B. in der Kühlkette eines Handelsunternehmens. Andererseits ermöglicht das Wissen über Abläufe in der physischen Welt auch erstmals die Umsetzung völlig neuartiger Geschäftsmodelle, z.B. KfzVersicherungen nach dem Prinzip „Pay-as-you drive“. Der erfolgreiche Einsatz in der Praxis erfordert jedoch ein tiefgreifendes Verständnis der notwendigen Basistechnologien und Standards sowie der Gestaltungsprinzipien für neue sensorgestützte Geschäftsprozesse bis hin zur Veränderung der Erfolgslogik einer Branche. Darüber hinaus ergeben sich auf der Kundenseite mögliche Akzeptanzprobleme in Bezug auf eine scheinbar omnipräsente Überwachung durch „Spy Chips“ und Anwendungen, die „nachhause telefonieren“. Leitungsgremium: Alois Ferscha, Johannes Kepler Universität Linz Elgar Fleisch, Eidgenössische Technische Hochschule Zürich & Universität St. Gallen (Federführender) Kai Rannenberg, Johann Wolfgang Goethe-Universität Frankfurt Programmkomitee: Oliver Christ, Leiter SAP Research Schweiz Martin Meints, ULD Kiel Florian Michahelles, Post Doc ETH Zürich, Associate Director Auto-ID Labs Hartmut Pohl, Fachhochschule Bonn-Rhein-Sieg Frederic Thiesse, Post Doc Universität St. Gallen, Leiter M-Lab & Retail Research Initiative RFID IN REVERSE LOGISTICS RESEARCH FRAMEWORK AND ROADMAP Lars Thoroe, Adam Melski, Matthias Schumann1 Abstract Reverse logistics is constantly gaining in importance for both research and practice. Research on RFID has so far concentrated on the use of RFID in order to support forward logistics processes, but is beginning to realize the specific potentials and benefits of RFID systems in this evolving research area. IS research has so far addressed individual and rather isolated aspects of this topic. In order to promote this evolving field of RFID research, we present a structuring framework and propose a roadmap for future research. 1. Introduction The integration of the real and the virtual world by the use of Ubiquitous Computing technologies promises new possibilities regarding the control of operational processes. In the context of logistics and supply chain management this integration corresponds to the linkage of flows of material and flows of information. The focus of both research and practice has so far been the use of RFID in order to support the classical logistics processes along the supply chain from suppliers to producers, retailers and customers. Flows of material which run in the opposite direction of the classical supply chain have in recent years increasingly been the subject of logistics research and practice. Collecting and processing goods and material outside of the classical processes of source, make, deliver are gaining importance due to changing socio-economic and legal conditions. These changes pose new challenges to logistics which are addressed by a relatively new area of logistics research denoted as reverse logistics. So far, IS research has only addressed isolated cases and aspects of the use of RFID in reverse logistics. In order to promote this emerging research area we provide a framework, which organizes the field in definable layers and interconnections. Based on this framework, we propose a roadmap for future research. The paper is organized as follows. In Section 2 we briefly present the concept of reverse logistics and review existing research on RFID in reverse logistics. In Section 3 we introduce our framework, based on which we propose a roadmap for future research in Section 4. The paper ends with the conclusion in Section 5. 1 Georg-August-Universität Göttingen, Institut für Wirtschaftsinformatik, Professur für Anwendungssysteme und EBusiness; Platz der Göttinger Sieben 5, D-37073 Göttingen 781 2. RFID in reverse logistics – state of the art 2.1. Concept of reverse logistics A consensus regarding the definition of the relatively new concept of reverse logistics has not yet been reached in the scientific literature. The first proposals for a definition are from the early 90s and are limited to aspects like waste management and recycling [5; 8]. Nowadays, the term reverse logistics is mostly conceived in a more general sense, as is the case in the following definition, which was developed by the European Working Group on Reverse Logistics: “The process of planning, implementing and controlling flows of raw materials, in process inventory, and finished goods, from a manufacturing, distribution or use point, to a point of recovery or point of proper disposal” [5]. This definition encompasses flows of material originating from the end customer as well as those having its source further up the supply chain. 2.2. Literature review One of the characteristic attributes, which distinguishes reverse logistics flows from those in forward logistics, is the increased uncertainty [4; 36]. This uncertainty pertains to time, amount and source of future flows, as well as identity and condition of the logistical objects which form the flow. The potential use of RFID in order to remedy the uncertainty in reverse logistics flows is mentioned by many authors [3; 11; 29; 38]. However, there is no profound analysis of potential applications of RFID in the reverse logistics literature. Previous research in the area of Ubiquitous Computing has addressed the use of RFID in some areas of reverse logistics: Parlikad et al. (2003) analysed requirements for object-related information in the context of reuse and recycling of end-of-life products [31]. Kulkarni et al. (2005) discuss the same topic in more detail. In their article, the authors present two case studies dealing with electronics product recovery and point out the benefits of object-related information provided by RFID-based information systems [25]. Dörsche et al. (2005) [7] and Khan et al. (2006) [20] propose a system for the support of product recovery decisions of vehicle components based on embedded sensorequipped RFID tags. Kulkarni et al. (2007) [26] and Parlikad et al. (2007) [32] present quantitative models analyzing the value of RFID in remanufacturing. Another subject of research has been the use of RFID in managing the collection of product returns. Koh et al. (2003) have illustrated how RFID-enabled unique identification can support the collection of returns emanating from the customer (push-returns) [21]. These benefits have been corroborated in some practical applications, e.g. in speeding up return processes of printers at Hewlett-Packard Brazil [14]. The use of RFID systems in order to limit the negative impacts of product recalls (pull-returns) has been the subject of various publications dealing with models and methods for enhanced product tracing using RFID [e.g. 1; 6; 12; 19]. Karaer and Lee (2007) analyze benefits of RFID-based inventory information in handling returns at a distribution centre [18]. Benefits of RFID systems to support the management of returnable containers are relatively well documented in the relevant literature. The RFID-enabled increased visibility of containers such as bins, kegs and boxes has shown to decrease losses due to shrinkage and undocumented damages in sectors ranging from automotive to beverages industry and postal services [13; 30]. Potential negative impacts of Ubiquitous Computing in general and widespread use of RFID in particular have been the subject of research in recent years. In one of the earlier works, Hilty et al. (2003) address environmental risks connected with the vision of Ubiquitous Computing [17]. Koehler and Som (2005) analyze effects of this vision on sustainable development, pointing out – among other effects such as health-related aspects and social implications – the environmental impacts of integrating devices into everyday objects [22]. They identify increased resource consumption as well as the entry of electronics waste into other waste streams as the main threats. 782 Recently, the focus has shifted from Ubiquitous Computing in general towards RFID in particular. Kräuchi et al. (2005) assess the threats of widespread item-level tagging to waste management processes. For several scenarios concerning the diffusion of RFID, they analyze the quantities of different materials contained in transponders and try to identify potential consequences for waste management processes in Switzerland [23]. Based on this analysis, Wäger et al. (2005) call for a number of precautionary measures in order to reduce negative environmental impacts [37]. Gliesche and Helmigh (2007) conducted a more detailed analysis of the negative effects on processes in the recycling of plastic, paper, glass and aluminum [15]. Although all these works address some important aspects of RFID in reverse logistics, they are still piecemeal and do not cover the research area as a whole. We therefore present a structuring framework in order to promote this emerging field for research. 3. Framework Our framework consists of five layers, which we have identified as important sub-areas when assessing the role of RFID in reverse logistics. An overview of the framework is given in Figure 1, followed by a more detailed description of its layers. Figure 1: Research framework for RFID in reverse logistics 783 3.1. Influencing factors and drivers The top layer of the framework describes the factors which cause the increase in importance of reverse logistics in recent years. These drivers pose new demands for reverse logistics processes, which in turn give rise to new requirements on additional object-related information. In the relevant literature, these driving forces are usually divided into legal, economic and social factors [5; 10; 29]. The first main area, in which legislation acts as a driving force on the importance of reverse logistics, is waste management and recycling. The growing social consciousness of ecological matters is, especially in Europe, reflected in recent legislation. Several laws have been passed promoting reuse and recycling of end-of-life products as well as intensified use of returnable packaging [27]. Table 1 shows an overview of the most important EU legislation on waste management: Table 1: EU legislature on waste management Directive Scope Contents 75/442/EC Waste management in general Umbrella Framework specifying general goals of waste management: avoidance of generation, promotion of recovery 94/62/EC Packaging waste Specific goals for reuse and recycling of packaging 2000/53/EC End-of-life vehicles Producer responsibility for recycling; quotas for recycling and reuse of vehicles and components 2002/96/EC Waste electrical and electronic equipment Producer responsibility for recycling; quotas for recycling and reuse of WEEE The second area of legislation posing new challenges for reverse logistics is traceability and recall management. In recent years, several recalls due to safety concerns of food and other safety critical consumer goods have created numerous scandals and shattered consumer trust. Legislation responded with new laws on recall management tightening accountability and requirements on traceability for all supply chain partners. Two prominent examples are the TREAD (Transportation Recall Enhancement, Accountability and Documentation) Act which targets carmakers in the USA and the EU regulation 178/2002 which concerns the food industry [35]. Changing economic conditions also add to the continuous increase in importance of reverse logistics [5; 33]. Average usage periods of goods are decreasing. Therefore products which are disposed of by the end customer often still contain considerable value, which may be recovered profitably. An example is the remanufacturing of mobile phones which is done successfully since the mid-1990s [16]. Prices for almost all categories of raw material are constantly increasing since 2000 due mostly to increased demand induced by the economic growth of newly industrialised and emerging countries. For this reason, the use of secondary raw materials obtained from waste of industry and private households is increasingly economically advantageous [2]. Another economic driver is seen in booming e-commerce. With e-tailers traditionally suffering from a relatively high ratio of returned products, this results in increased effort in handling returns. The growing social environmental consciousness not only influences legal conditions of business, it is a driving factor of reverse logistics in its own right. As more and more consumers and investors include ecological considerations in their decisions, they are targeted by so-called green marketing, in which companies try to communicate ecological corporate and product images [9]. 3.2. Material flows Material flows as the central matter of reverse logistics practice and research is the second layer of our framework. Based on the definition in Section 2.1., the following categories of reverse logistics flows can be distinguished [5; 10] 784 - End-of-use returns: This category encompasses goods that are disposed of when their time of use has expired. Commercial returns: These flows are unused products returned in order to undo a preceding business transaction. The bulk of this category consists of returns from consumers to retailers, however these flows can occur between any two parties in a supply chain. Warranty returns: Defective or damaged products that are either returned by the recipient or recalled by the vendor fall into this category. Packaging: This category encompasses nonreturnable and returnable packaging, e.g. boxes, pallets, barrels, product packaging etc. Production scrap and by-products: We do not consider this fifth category in our framework as it is of relatively low relevance within our scope. Apart from basic logistics processes as transport, storage and cross-loading, reverse flows consist of the following specific processes: The collection of logistical objects constitutes the start of reverse material logistics flows. Two kinds of collection processes need to be distinguished. Pull collections, which are triggered by the receiving party (e.g. producer recalling defective products) and push collections, which are prompted by the source of the flow (e.g. customer after concluding usage of a product). As reverse flows are – in comparison to forward flows – relatively heterogeneous [35], some kind of sorting is often required. Sorting splits heterogeneous material flows in separate fractions for further processing. Similarly, disassembly processes may be needed in order to separate components for separate processing. At the end of the reverse logistics process chain, objects are processed and subjected to a variety of recovery and disposal alternatives. According to the relevant EU legislature, these alternatives form a hierarchy with priority given to reuse, and disposal in landfill as the least desirable option. The role of RFID in these processes is twofold: Firstly, RFID tags as part of these material flows are themselves objects, which pass through the reverse logistics process chain towards recovery or disposal. Secondly, the tags may provide object-related information and thus act as instruments for these processes. 3.3. Requirements on information flows The influencing factors depicted in the top layer pose challenges for reverse logistics processes, some of which entail new requirements for object-related information. Reverse logistics processes have – in comparison to forward logistics – specific requirements for object identification and information, because these processes are relatively poorly controlled and monitored [35]: In forward logistics, object identities are seldom completely unknown at process transitions, as they are often announced by preceding information flows. As forward logistics systems are usually well monitored, the object state is relatively stable. By contrast, reverse logistics processes are far less planned and so far hardly controlled by information systems. Furthermore, reverse logistics objects are far more heterogeneous. Formerly homogenous objects are subject to generation of variants once they leave the controlled systems of forward logistics, which calls for a finer granularity of object-related information. These characteristic requirements on object identification and information are summarized in Table 2. Table 2: Identification and information requirements in forward and reverse logistics Characteristic Forward logistics Reverse logistics Identification purpose Confirm relatively certain identity Establish completely unknown identity Object configuration Static bill of materials, documented at class-level Dynamic bill of materials, to be documented at item-level Object state Rather known and static due to Rather unknown, sensor-equipped RFID tags document 785 controlled processes, sensor-equipped RFID tags serve quality checks unknown effects in usage life Sufficient tagging level for product identification Product packaging Packaging, product (and components) Prevalence of barcode Very high Rather low, as barcodes labels are often no longer usable (end-of-life products) The general requirements described above have to be refined when considering specific reverse flows: Object identification as the basis of linking flows of material and information can be done either at class-level or on item-level. In some cases, reverse logistics processes do not require itemlevel identification. For the sorting of end-of-life products or packaging, which are recovered as secondary material or disposed of, class-level information is usually sufficient. So far, these sorting processes are not based on identification, as barcode labels are no longer usable. In the absence of readable data carriers, sorting processes either rely on manual inspection or on technologies which automatically detect relatively broad physical characteristics such as size, weight and magnetism of objects. Other reverse logistics processes can however benefit from item-level data: In addition to specific collection processes (e.g. targeted recalls), sorting and recovery of high-value objects may benefit from item-level information regarding the state of the object. These processes rely on object-related data like bill of materials. However, the usefulness of object-related data based on the state of the object at the time of its assembly can be quite limited at the time of its recovery. Meaningful and reliable data regarding the current state of the object has to be gathered dynamically during its lifecycle and needs to be documented and accessed at item-level [25, 31]. 3.4. Opportunities and threats of RFID tagging Both potential positive and negative impacts on reverse logistics processes can be expected from item-level RFID tagging. In order to meet the demands on object-related information discussed on Section 3.3, RFID systems have been proposed for various scenarios: Collection processes may benefit from automatic identification, from collections of commercial returns and recalls [21], to enabling deposit systems [35] and enhanced compliance with laws regarding extended producer responsibility [24]. Sorting processes are among the most costly processes in reverse logistics (e.g. sorting of packaging waste in Germany accounts for approx. 40% of the total disposal cost [34]) and may be considerably enhanced, if they are based on object identity instead of broad detectable characteristics [35]. Finally, RFID-enabled documentation of an objects’ individual history may provide valuable information during end-of-life decision making and recovery processes [26; 31; 32]. The use of RFID systems in order to fulfil the specific information requirements is advantageous because of two characteristics of the technology: Firstly, RFID-enabled unique identification is especially beneficial in reverse logistics processes, due to the increased heterogeneity of pertaining objects. Secondly, it is the persistency of RFID tags compared to barcode labels which may enable – and not just, as is the case in forward logistics, enhance – widespread automatic identification in reverse logistics systems. Threats on reverse logistics processes may arise from tags as electronic components entering waste streams. Assuming that all units of packaging waste in Germany were tagged with light smart labels weighing only 0.1 g, this would lead to 20000 t of electronics waste annually entering the processes of packaging waste management [35]. End-of-life electronics equipment is usually processed separately, as it contains hazardous and valuable materials which have to be treated separately [37]. With the spread of item-level RFID a separate collection of transponder and object 786 will in most cases no longer be feasible, which on the one hand hinders a proper disposal of the tags as electronics equipment and on the other hand makes recovery of the objects they are attached to difficult. Tags in specific sorting and recovery processes may interfere with existing technologies (e.g. smelting processes in glass recovery) and secondly contaminate (and thus depreciate) recovered secondary material [15; 23]. The potential opportunities and threats for reverse logistics which may arise from RFID tagging are summarized in Table 3: Table 3: Potential impacts of RFID tagging on reverse logistics processes Process Opportunities Threats Collection - Enabling registration and documentation of collections e.g. for Extended producer responsibility Deposit systems Tracing data enables targeted recalls, verification of warranty claims No separate collection of tags as electronics components Reverse flows heterogeneous Æ increased need for sorting Waste flows: Sorting based on identity instead of broad physical characteristics Æ potential for better separation of waste fractions - Increased value of recovered material - Efficient sorting out of hazardous materials Tags as contaminants of material fractions difficult to separate Sorting - Recovery Item-level product history can improve recovery decisions and processes Tags as contaminants may reduce value of recovered material 3.5. Technological progress and diffusion of RFID Only in few cases, RFID systems will be implemented solely for the purpose of supporting reverse logistics processes. In most cases, RFID will first and foremost be implemented for the support of forward logistics processes – with possible secondary benefits and challenges in reverse logistics. Therefore the role of RFID in reverse logistics will considerably depend on the diffusion of RFID in forward logistics. Thus the barriers of item-level RFID in forward logistics processes are of importance when analyzing its role in reverse logistics. This diffusion depends in large parts on technological progress which may help overcome existing technical barriers. Tag prices are usually seen as an important challenge for widespread item-level RFID, with progress in the area of polymer electronics as a possible long-term solution. Substituting several (semi-)metals in transponders with polymer semiconductors may (by enabling low-cost printing production) dramatically lower the costs for simple, short-range transponders and therefore increase diffusion of RFID at item-level. Apart from its impact on diffusion, technological progress is an important aspect of research on reverse logistics in its own right, as the use of different materials may pose different challenges on recovery processes and the value of recovered materials. 4. Roadmap: Issues for future research The five layers presented in the framework are delineable sub-areas of research on the role of RFID in reverse logistics which are useful for structuring the field. However, in order to comprehensively explore the area, research questions spanning these layers are necessary. We categorize these issues according to scope into economic, ecological and technical issues. 787 4.1 Economic issues The use of RFID promises significant potential to close the gap between forward and reverse logistics information flows. However, except for successful applications in closed loop logistics of returnable containers, there is hardly practical evidence for these potential benefits. Future research should provide methods and models in order to quantify benefits enabled by RFID systems spanning forward and reverse logistics. This should also include aspects of the distribution of costs and benefits of RFID systems in logistics. In the context of consumer goods it is often assumed that large retailers are using their market power to force the introduction of RFID at the expense of manufacturers who have to bear the costs of tagging although it is the retailers who benefit most from it. Incorporating potentials regarding the support of extended producer responsibility may give new impetus to this debate. Additional problems arise from aspects concerning the diffusion of RFID technology in reverse logistics application scenarios. On the one hand, RFID systems can in most cases not be implemented at once, as untagged products will remain in use for years. Reverse logistics processes therefore cannot be changed to operate on tagged objects exclusively, as untagged objects will have to be handled for years to come. On the other hand, unlocking benefits of item-level RFID adds further complexity as more parties (e.g. maintenance, repair and disposal companies), become actively involved in the use of the system and may need to be offered incentives, in order to, for example, participate in documenting object history. 4.2 Ecological issues Research on the overall ecological impacts of item-level RFID is still in its infancy. The articles mentioned in Section 2.2 either focus on negative (usually in worst case scenarios) or positive impacts of RFID (in isolated application scenarios); profound research assessing the ecobalance of item-level RFID is lacking. Research should provide life cycle analysis of different tagging scenarios, incorporating potential ecological opportunities and threats. This may help policymakers to assess its impact before the reality of item-level RFID catches up with the relevant legislation (see Section 3.1.). New legislation may for instance be needed in order to prevent negative impacts of widespread item-level tagging or in order to make use of the possibilities of RFID which could make legal instruments such as obligatory deposit systems or extended producer responsibility feasible. 4.3 Technical issues Integrating the different technical requirements on RFID systems in forward and reverse logistics is a critical issue. Privacy concerns and customer acceptance are in both forward and reverse logistics a major challenge for item-level tagging of consumer products [28]. In forward logistics these concerns can be met with deactivating tags after purchase by default, e.g. by using the killcommand which is implemented in the most important tag standard EPC class 1 Gen 2. This measure is both effective and feasible; however deactivating tags permanently prevents all uses in reverse logistics beyond the point of sale. The development of effective low-cost security measures which increase customer acceptance and allow for the use of RFID throughout the supply loop remains an important subject for future research. This is just one example where technical requirements on RFID differ significantly for forward and reverse logistics. Analysing and reconciling these different requirements regarding tag and reader architecture as well as data management aspects needs to be the subject of future research. In an integrated view on positive and negative impacts of RFID in reverse logistics, the separation of tag and object is an important aspect, which should be considered in the development of methods of binding tag and object. In order to maximize potential benefits (both economic and ecological) 788 and minimize negative impacts, we deduce the question of the optimum decoupling point of tag and object as an essential issue. An exemplary decision problem is shown in Figure 2: Figure 2: Exemplary decision problem of optimum decoupling point 5. Conclusion Reverse logistics is constantly gaining in importance due to changing legal and socio-economic conditions. The expected diffusion of RFID towards the item-level entails both opportunities and challenges for reverse logistics processes, which constitute an important field for future research. Only isolated aspects of this complex research area have so far been addressed, focusing either on negative impacts of item-level tagging or on potential RFID applications in specific areas of reverse logistics. In order to promote a comprehensive approach, which covers the wide area of RFID in reverse logistics and incorporates both positive and negative impacts, we developed a framework structuring the field. We then deduced issues, which future research should address. If the specific challenges can be overcome and positive practical experiences of the use of RFID in the management of closed loop container systems can be transferred to other areas of reverse logistics, RFID systems promise to reduce the inherent object-related uncertainties and thus contribute significantly to the closing of the supply loop. 6. References [1] AGRAWAL, R., CHEUNG, A., KAILING, K. AND SCHONAUER, S. Towards Traceability across Sovereign, Distributed RFID Databases, Proceedings of the 10th International Database Engineering and Applications Symposium, Deli 2006, pp. 174-184. [2] BARDT, H. Die gesamtwirtschaftliche Bedeutung von Sekundärrohstoffen, IW-Trends, Vol. 33 (2006), No. 3. [3] BREEN, L. Give me back my empties, or else! A preliminary analysis of customer compliance in reverse logistics practices (UK), Management Research News, Vol. 29 (2006), No. 9, pp. 532-551 [4] CHOINARD, M., D’AMOURS, S. AND AIT-KADI, D. Integration of reverse logistics activities within a supply chain information system, Computers in Industry, Vol. 56 (2005), No. 1, pp. 105-124. [5] DE BRITO, M. AND DEKKER, R., A Framework for Reverse Logistics, in Dekker, R., Fleischmann, M., Inderfurth, K., Van Wassenhove, L. N. (Eds.): Reverse Logistics, Springer, Berlin Heidelberg 2004, pp. 3-27. [6] DE, P., BASU, K. AND DAS, S. K., An RFID based technique for handling object distribution and recalls in pervasive transaction environments, Proceedings of the 2004 IEEE Conference on Mobile Ad-hoc and Sensor Systems, Fort Lauderdale 2004, pp. 349-358. [7] DÖRSCH, C., FIKOURAS, I., BURKERT, R. AND MÜLLER, D. H., Eco-conscious Design Based on Single Component Polymers for Sustainable Supply Management in Automotive Production, Proceedings of the International Conference on Engineering Design, ICED 2005, Melbourne. [8] DOWLATSHAHI, S., Developing a Theory of Reverse Logistics, Interfaces, Vol. 30 (2000), No. 3, pp. 143-155. [9] D'SOUZA, C., TAGHIAN, M. AND KHOSLA, R., Examination of environmental beliefs and its impact on the influence of price, quality and demographic characteristics with respect to green purchase intention, Journal of targeting measurement and analysis for marketing, Vol. 15 (2007), No. 2, pp. 69-78. [10] FLEISCHMANN, M., Quantitative models for reverse logistics, Springer, Berlin Heidelberg 2001. [11] FLEISCHMANN, M., VAN NUNEN, J., GRÄVE, B. AND GAPP, R., Reverse Logistics – Capturing Value in the Extended Supply Chain, in An, C. and Fromm, H. (Eds): Supply Chain Management on Demand. Springer, Berlin Heidelberg New York 2005, pp. 167-186. 789 [12] FOLINAS, D., MANIKAS, I. AND MANOS, B., Traceability data management for food chains, British Food Journal, Vol. 108 (2006), No. 8, pp. 622-633. [13] FOSTER, P., SINDHU, A. AND BLUNDELL, D., A Case Study to Track High Value Stillages using RFID for an Automobile OEM and its Supply Chain in the Manufacturing Industry, Proceedings of the 2006 IEEE Conference on Industrial Informatics, Singapore 2006, pp. 56-60. [14] GAMBON, J., Best RFID Implementation: Keeping Tabs on Printers, http://www.oatsystems.com/media/Best_RFID_Implem_article2.pdf, retrieved 2008-07-14. [15] GLIESCHE, M., AND HELMIGH, M., Auswirkung eines RFID-Masseneinsatzes auf Entsorgungs- und Logistiksysteme, Dortmund 2007. [16] GUIDE, V. D. R., NEERAJ, K., NEWMAN, C. AND VAN WASSENHOVE, L. N., Cellular telephone reuse: the ReCellular Inc. case, in: Flapper, S. D. P., Van Nunen, J. and Van Wassenhove, L. (eds.): Managing closed-loop supply chains, Springer, Berlin Heidelberg New York 2005, pp. 151-156. [17] HILTY, L., BEHRENDT, S., BINSWANGER, M., BRUININK, A., ERDMANN, L., FRÖHLICH, J., KÖHLER, A., KUSTER, N., SOM, C., AND WÜRTENBERGER, F., Das Vorsorgeprinzip in der Informationsgesellschaft: Auswirkungen des Pervasive Computing auf Gesundheit und Umwelt, Bern 2003. [18] KARAER, Ö. AND LEE, H. L., Managing the Reverse Channel with RFID-Enabled Negative Demand Information, Production and Operations Management, Vol. 16 (2007), No. 5, pp. 625-645. [19] KELEPOURIS, T., PRAMATARI, K. AND DOUKIDIS, G., RFID-enabled traceability in the food supply chain, Industrial Management & Data Systems, Vol. 107 (2007), No. 2, pp. 183-200. [20] KHAN, O., SCOTTI, A., LEVERANO, A., BONINO, F., RUGGIERO, G. AND DÖRSCH, C., RFID in Automotive: a Closed-Loop Approach, 12th International Conference on Concurrent Enterprising, Milano, 2006. [21] KOH, R., SCHUSTER, E. W. AND LAM, N., Prediction, Detection, and Proof: An Integrated Auto-ID Solution to Retail Theft, Cambridge 2003. [22] KOEHLER, A., AND SOM, C., Effects of Pervasive Computing on Sustainable Development, IEEE Technology and Society Magazine, Vol. 24 (2005), No. 1, pp. 15-23. [23] KRÄUCHI, P., WÄGER, P. A., EUGSTER, M., GROSSMANN, G., AND HILTY, L., End-of-Life Impacts of Pervasive Computing – Are RFID tags a threat to waste management processes?, IEEE Technology and Society Magazine, Vol. 24 (2005), No. 1, pp. 45-53. [24] KUHNHENN, K. AND URBAN, A. I., ELEKTROG-Produktverantwortung - Individuelle Produktverantwortung für Elektroaltgeräte – Durch RFID zum Ziel?, Müll und Abfall, Vol. 38 (2006), No. 12, pp. 638-644. [25] KULKARNI, A. G., PARLIKAD, A. K., MCFARLANE, D. AND HARRISON, M., Networked RFID Systems in Product Recovery Management, Proceedings of the 2005 IEEE International Symposium on Electronics and the Environment, New Orleans 2005, pp. 66-71. [26] KULKARNI, A. G., RALPH, D., AND MCFARLANE, D., Value of RFID in remanufacturing, International Journal of Services Operations and Informatics, Vol. 22 (2007), No. 3, pp. 225-252. [27] KUMAR, F. AND FULLENKAMP, J., Analysis of European Union environmental directives and producer responsibility requirements, International Journal of Services and Standards, Vol. 1 (2005), No. 3, pp. 379-398. [28] LANGHEINRICH, M.: RFID and Privacy, in: Petkovic, M., Jonker, W. (eds.): Security, Privacy, and Trust in Modern Data Management, Berlin Heidelberg New York 2007, pp. 433-450. [29] MEADE, L., SARKIS, J. AND PRESLEY, A., The theory and practice of Reverse Logistics, J. Logistics Systems and Management, Vol. 3 (2007), No. 1, pp. 56-84. [30] PARK, J. AND LEE, B., RFID Application Model and Performance for Postal Logistics, Lecture notes in computer science, Vol. 4537, (2007), pp. 479-484. [31] PARLIKAD, A. K., MCFARLANE, D., FLEISCH, E. AND GROSS, S., The Role of Product Identity in End-ofLife Decision Making, Auto-ID Centre White Paper, Cambridge 2003. [32] PARLIKAD, A. K., MCFARLANE, D., RFID-based product information in end-of-life decision making, Control Engineering Practice Vol. 15 (2007), pp. 1348-1363. [33] STEVEN, M., Networks in Reverse Logistics, in Dyckhoff, H., Lackes, R. and Reese, J. (eds.): Supply Chain Management and Reverse Logistics, Springer, Berlin Heidelberg 2004, pp. 163-180. [34] STEVEN, M. AND LAARMANN, A., Lerneffekte in der Entsorgungslogistik, ZfB Zeitschrift für Betriebswirtschaft, Special Issue: Reverse Logistics 1, 2005, pp. 95-114. [35] THOROE, L. AND SCHUMANN, M., Objektinformationsbedarfe und RFID-Nutzenpotenziale in Reverse Logistics, in: Breitner, M.; Breunig, M.; Fleisch, E.; Pousttchi, K.; Turowski, K. (eds.): Proceedings zur 3. Konferenz Mobile und Ubiquitäre Informationssysteme, Bonn 2008. [36] TIBBEN-LEMBKE, R. S. AND ROGERS, D. S., Differences between forward and reverse logistics in a retail environment, Supply Chain Management: An International Journal, Vol. 7 (2002), No 5, pp. 271-282. [37] WÄGER, P. A., EUGSTER, M., AND HILTY, L., Smart labels in municipal waste – a case fort he Precautionary Principle, Environmental Impact Assessment Review, Vol. 25 (2005), No. 5, pp. 567-586. [38] ZHENG, J., ZHENG, W. AND LIU, P., Research on information integration management of reverse logistics, Proceedings of the 7th international conference on Electronic commerce, ACM Press, New York 2005, pp. 851-855. 790 SICHERHEIT Die Frage nach der Sicherheit und Verlässlichkeit der Business Services ist ein Schlüsselfaktor für ihren möglichen Einsatz. Dabei sind mindestens zwei Aspekte von wesentlicher Bedeutung: Zum einen ist Sicherheit eine notwendige Grundvoraussetzung. Die hohe Komplexität der Systeme und die durch sie getriebenen Veränderungen führen die Gesellschaft in zunehmende Abhängigkeit vom einwandfreien Funktionieren der servicebasierten Systeme und der in ihnen eingesetzten Sicherheitsmechanismen. Zum anderen ist zu erwarten, dass sichere Infrastrukturen Innovationen beschleunigen und neue Geschäftsfelder erst ermöglichen und damit die Basis für neue und bisher nicht bekannte Business Services darstellen. Dieser Track widmet sich beiden Aspekten auf den verschiedenen technologischen Abstraktionsebenen und in allen betroffenen Anwendungsgebieten. Leitungsgremium: Claudia Eckert, Technische Universität Darmstadt Günther Pernul, Universität Regensburg (Federführender) Gerald Quirchmayr, Universität Wien Programmkomitee: Hannes Federrath, Universität Regensburg Rüdiger Grimm, Universität Koblenz-Landau Rolf Oppliger, eSECURITY Technologies Hartmut Pohl, Fachhochschule Bonn-Rhein-Sieg Kai Rannenberg, Johann Wolfgang Goethe-Universität Frankfurt am Main Ingrid Schaumüller-Bichl, Fachhochschule Oberösterreich, Hagenberg Gerhard Weck, INFODAS GmbH Köln COLLABORATIVE PENETRATION TESTING Severin Winkler1, Christian Proschinger2 Kurzfassung Penetrationstests stellen im IT-Sicherheitsmanagement großer Unternehmen einen Fixpunkt bei technischen Audits dar. Die Durchführung eines solchen Audits mit den Mitteln eines realen Angreifers stellt einen besonderen Mehrwert dar, da es eine realistische Einschätzung der aktuellen Sicherheitssituation zulässt. Collaborative Penetration Testing beschreibt die Möglichkeit der effektiveren Durchführung solcher Audits, um mit der Professionalisierung im Cybercrime Bereich Schritt zu halten. Durch Spezialisierung und daraus resultierende Arbeitsteilung wird ein effizienterer Einsatz des vorhandenen Testbudgets erreicht. Vorhandene Vorgehensmodelle können so in ihrer Produktivität gesteigert werden. Unseren Ansatz stellen wir anhand eines Prototyps vor. 1. Einführung Ein kollaborativer Penetrationstest (Collaborative Penetration Test) ist ein von mehreren, in der Regel zeitlich und physisch getrennt arbeitenden Menschen durchgeführter Test. Dadurch ergeben sich einerseits neue Möglichkeiten, andererseits werden Fragen und Probleme zur Arbeitsweise der Gruppe und dem allgemeinen Ablauf aufgeworfen. Es handelt sich dabei um eine Kombination aus den Forschungsgebieten des Penetration Testings[3] sowie der Computer Supported Collaborative Work (CSCW) [1] [18]. Der Vorteil eines kollaborativen Penetrationstests gegenüber einem nicht kollaborativ durchgeführten Audit liegt im Nutzengewinn, erreicht durch Spezialisierung und gezielte Werkzeugnutzung. Ziel des vorliegenden Beitrages ist es, die Voraussetzungen für kollaboratives Penetration Testing aufzuzeigen und ein anhand dieser Anforderungen entwickeltes Tool vorzustellen. Als Penetrationstest wird im Allgemeinen ein Sicherheitstest eines IT Systems bezeichnet, bei dem die Tester Mittel und Methoden nutzen, die auch von realen Angreifern verwendet werden [2]. Im Gegensatz zu einem automatisierten Schwachstellenscan werden gefundene Sicherheitslücken in Absprache mit dem Auftraggeber auch tatsächlich ausgenutzt. Auf diese Weise kann Schritt für Schritt immer tiefer in ein System eingedrungen werden, wodurch falsch-positive Ergebnisse ausgeschlossen bzw. weitere Schwachstellen aufgedeckt werden können. 1 Secure Business Austria, A-1040 Wien, Favoritenstraße 16. 2 Raiffeisen Informatik GmbH, A-1020 Wien, Lilienbrunngasse 7-9. 793 Des Weiteren wird diese Art eines technischen Sicherheitsaudits durch folgende Punkte charakterisiert: • Ort, Zeitpunkt und mögliche Zielsysteme sind mit dem Auftraggeber (z.B. einem Systembetreiber oder Systemeigentümer) abgestimmt. • Der Angriff kann bei Beeinträchtigungen der getesteten Umgebung jederzeit abgebrochen werden. • Ein festgelegtes Budget begrenzt den Zeitrahmen. • Die gefundenen Schwachstellen werden bewertet und in einem Bericht präsentiert. • Eine manuelle Prüfung von automatisiert generierten Scanergebnissen wird durchgeführt. Aufgrund der zahlreichen Angriffsvektoren auf ein System, dem daraus resultierenden Umfang des erforderlichen Wissens und der somit notwendigen Spezialisierung der ausführenden Personen werden Penetrationstests meist im Team durchgeführt [10]. Hier findet manchmal auch der Begriff „Tiger Teams“ Verwendung; bei den Mitgliedern dieser Teams handelt es sich um sogenannte „White-Hats“, d.h. Sicherheitsexperten, die ihr Wissen weder zum eigenen Vorteil noch zum Schaden anderer nutzen. Neben der Festlegung des anvisierten Zielsystems kann auch eine Kategorisierung des Tests vorgenommen werden. Grundsätzlich wird zwischen Black-Box- und White-Box-Ansatz unterschieden. Beim White-Box Ansatz sind dem Auftragnehmer detaillierte Informationen über das System zugänglich. Dies sind zum Beispiel Netzwerkpläne oder der Source Code einer zu testenden Applikation. Hingegen stellt der Black-Box Ansatz die Situation eines Außenstehenden nach [3]. In der Praxis hat sich als Mischform der sogenannte Grey-Box Ansatz sehr bewährt, da die Tester durch einige zusätzliche Informationen den Angriff präziser planen können und den Betrieb des Systems weniger gefährden. Um die Testergebnisse vergleichbar und nachvollziehbar zu machen, wird beim Penetration Testing nach festgelegten Methoden, sogenannten „Vorgehensmodellen“, gearbeitet, die unter dem Punkt „Related Work“ näher beschrieben werden. Sämtliche Modelle durchlaufen folgende Phasen: • • • • Aufklärung Scanning Zugang erlangen Dokumentation Die empirische Analyse mehrerer Penetrationstests ergab, dass es sich entgegen der relativ starr wirkenden Vorgaben tatsächlich um sehr dynamische Workflows handelt. Da jeder Test individuell ist, lassen sich Phasen und Prozesse schwer im Vorhinein planen. Unsere Arbeit behandelt daher folgende Punkte: • Wir untersuchen und beschreiben die Vor- und Nachteile von kollaborativen Penetrationstests. Dabei legen wir besonderes Augenmerk auf die wachsende Professionalität in der „Cyberkriminalität“ und wie Sicherheitsexperten damit Schritt halten können. 794 • Wir analysieren die Anforderungen an ein Tool zur Unterstützung von kollaborativen Penetrationstests. • Wir beschreiben unseren Prototypen, bei dem wir Teilaspekte bereits umgesetzt haben. 2. Problemstellung Die Anzahl der gefundenen Schwachstellen eines Penetrationstests verhält sich in der Regel proportional zum Arbeitsaufwand, d.h. Qualifikation des Personals, Qualität der eingesetzten Tools und verfügbare Zeit. Durch Arbeitsteilung und Spezialisierung können die vorhandenen Ressourcen effektiv genutzt werden. In der Vergangenheit hat sich gezeigt, dass die Angriffe auf Unternehmen an Professionalität gewinnen und sich diesbezüglich ein richtiger Markt entwickelt. Seinen Anfang hat dies bei „Vulnerability Research“ und der Entwicklung von Exploits. Die entdeckten Schwachstellen werden oftmals weiterverkauft bzw. versteigert wie zum Beispiel auf der WabiSabiLabi Plattform3. Eine weitere Sparte hat sich auf die Herstellung von Schadsoftware spezialisiert. Hierzu gehört die Entwicklung von Rootkit-Technologien zum Verstecken von Schadsoftware bzw. um Daten unbemerkt aus einem Unternehmensnetzwerk zu transportieren, so z.B. trojanische Pferde. Diese für kriminelle Zwecke entwickelte Software wird ständig weiterentwickelt. Mittlerweile ist Software-as-a-Service[6] in der Malware-Szene bereits umgesetzt. Auf der nächsten Stufe steht der „Betreiber“, der diese Technologien einsetzt und so an für ihn interessante Daten (etwa Geschäftszahlen) gelangt oder die infizierten Rechner für Botnetze nutzt. Gestohlene Informationen können ebenso wie Ressourcen (siehe Botnetze) gesammelt und weiterverkauft werden [4]. 2.1. Arten der Zusammenarbeit und Aufgabenverteilung Die Komplexität heutiger Systeme und Netzwerke führt zu mannigfaltigen Angriffsvektoren, daher wird der Penetration-Test meist von mehreren Akteuren durchgeführt. Die Verteilung der Aufgabengebiete orientiert sich an folgenden Kriterien: - funktional infrastrukturell prozessbezogen Die funktionale Trennung erfolgt auf Basis der zu testenden Applikationen bzw. Systeme. Das verwendete Betriebssystem, Datenbanksoftware oder die eingesetzte Programmiersprache stellen hier die wesentlichen Parameter dar. Bei Tests, deren Schwerpunkt im Applikationsbereichs liegt, etwa Webapplikationen, ist die verwendete Programmiersprache der wichtigste Aspekt. Die Praxis zeigt, dass sich Security-Analysten, die Penetrationstests durchführen, zumeist auf fachliche Bereiche fokussieren. Die Schwerpunkte liegen hier meist auf Betriebssystem-, Applikations- oder Netzwerkebene. Eine funktionale Trennung bringt den Vorteil mit sich, dass für kritische Systeme hochspezialisierte Experten hinzugezogen werden können. So wäre ein denkbares Szenario: Im Laufe des Tests stellt sich heraus, dass es sich bei einem eingesetzten Mailsystem um Lotus Notes handelt. Ist nun ein Experte für Lotus Notes greifbar, kann dieser die Informationen rascher auswerten und die Penetration zielsicherer durchführen. Dies wiederum bedeutet eine Qualitätssteigerung der Ergebnisse und ein geringeres Ausfallsrisiko während der Durchführung des Tests. 3 WabiSabiLabi Auktionsplattform: https://wslabi.com (Stand Juli 2008) 795 Eine infrastrukturelle Aufteilung erfolgt normalerweise anhand der IP-Adressen. Diese Trennung ermöglicht ein paralleles Arbeiten in jeder Phase des Tests. Besonders bei der Überprüfung von großen Netzwerken, bzw. ganzheitlichen Unternehmenspenetrationstests bedeutet diese Art der Arbeitsteilung einen Effizienzgewinn. Eine zusätzliche Segmentierung kann anhand einer Priorisierung der Kritikalität für das Unternehmen getroffen werden. Hochkrititsche Systeme sollten einerseits detailliert geprüft werden, andererseits muss dies oftmals auch in speziellen Zeitfenstern erfolgen. Die prozessbezogene Betrachtung geht davon aus, dass gewisse Aktivitäten abgeschlossen sein müssen, damit mit weiteren Arbeitsschritten fortgefahren werden kann; ebenso gibt es Verzweigungen oder Entscheidungen, die auf den Ablaufpfad des Tests einwirken. Bei der Umsetzung von Vorgehensmodellen muss daher die Abhängigkeit der einzelnen Module analysiert werden, um dementsprechend die Ressourcen zu verteilen. Die Zuweisung der Tätigkeiten erfolgt für die Software-basierte Umsetzung idealerweise als Rollenkonzept, da sich dies gegenüber der benutzerorientierten Sicht als effizienter erwiesen hat. Als vereinfachtes Beispiel für Abhängigkeiten von Aktivitäten sei der von außen durchgeführte Test eines internen Netzwerksegments genannt. Hierbei muss zuerst ein Scan des IP Bereichs durchgeführt werden, um herauszufinden, hinter welchen Adressen sich tatsächlich Systeme verbergen. In der Folge muss ein Gerät gefunden werden, das zumindest eine Schwachstelle aufweist, die ausgenutzt werden kann. Dieses muss in beiden Netzsegmente verbunden sein. Durch das Ausnützen der Schwachstelle kann logischer Zugriff auf das Gerät erlangt werden. Danach kann erst der interne Netzwerkbereich untersucht werden. 3. Related Work Seit den ersten Penetrationstests durch Tiger Teams wurde kontinuierlich daran gearbeitet, die Reproduzierbarkeit des Vorgehens zu erhöhen und die Ergebnisse vergleichbar zu machen. Ebenso wurde versucht, Angriffsmöglichkeiten abzubilden. Attack Trees [16] stellen hierbei eine der bekanntesten Möglichkeiten dar. Daraus resultierend gibt es die Überlegung Attacken als Petri Netze darzustellen [11]. Bestehende Vorgehensmodelle dienen als Grundstein für unsere Überlegungen, da sie einerseits stets den Rahmenprozess mit den vergleichbaren Kernelementen wiedergeben, andererseits ebenso die verschiedenen Detailausprägungen dokumentieren. Das NIST (National Institute of Standards and Technology) hat im Jahr 2003 „Guideline on Network Security Testing“ verfasst. Bei dieser Methode wird davon ausgegangen, dass die Informationsbeschaffung und der Angriff auf ein System oder Netzwerk iterative Prozesse darstellen, d.h. dass sich das Team während des Tests immer weiter vorarbeitet [13]. ISECOM (Institute for Security and Open Methodology) hat das OSSTMM (Open Source Security Testing Methodology Manual), aktuell in Version 2.2 frei verfügbar, veröffentlicht. Durch die ganzheitliche Betrachtung der IT-Sicherheit und Gliederung in einzelne Teilaspekte wird hier ein Rahmen für die funktionale Trennung vorgegeben [10]. Die OISSG (Open Information Systems Security Group) hat das ISSAF (Information Systems Security Assessment Framework) publiziert. Dieses Vorgehensmodell gliedert sich in 3 Phasen, wobei das tatsächliche Assessment in Phase 2 in detaillierte Arbeitspakete unterteilt wird. Die Dokumentation schließt auch die verwendeten Überprüfungstools mit ein [14]. 796 Das BSI (Bundesamt für Informationstechnik) stellt mit dem „Durchführungskonzept für Penetrationstests“ eine Methode zur Abwicklung von Penetrationstests zur Verfügung. Das BSI misst der Informationsbewertung einen besonderen Stellenwert zu. In dieser Methode wird auch klar zwischen Modulen zur Informationsbeschaffung und jenen zum Eindringen unterschieden [3]. Die Fachgruppe Security der Schweizerischen Informatikgesellschaft (SI) hat im Jahr 1999 „Sicherheitsüberprüfungen von IT-Systemen mit Hilfe von ‚Tiger-Teams‘“ beleuchtet. Ein Tigerteam ist eine Gruppe von White - Hats Es handelt sich zwar um kein explizites Vorgehensmodell, allerdings werden zwei für unsere Arbeit relevante Punkte beleuchtet: die Durchführung im Team sowie die Unterteilung in Arbeitspakete [15]. 4. Lösungsansatz Das Ziel unserer Überlegungen und der Umsetzung durch unser Tool ist, durch Arbeitsteilung und damit einhergehende Spezialisierung eine Effizienzsteigerung und Qualitätsverbesserung zu erreichen. Um die Vorteile eines Collaborative Penetration Tests auch tatsächlich nützen zu können, minimieren wir die Reibungsverluste, die durch erhöhten Kommunikationsaufwand entstehen. Unser Prototyp kann als leichtgewichtiges, auf Penetration Tests spezialisiertes Groupware System beschrieben werden. Leichtgewichtig, da es ohne Installation sowie plattformunabhängig unter Windows, Linux und Unix Betriebssystemen betrieben werden kann. Es ist ausschließlich für Penetrationstests geeignet, da es aus Modulen besteht, welche genau auf diese Tätigkeit abgestimmt sind. 4.1. Vorgehensmodell und Prozess-Sicht Die Verbindung zwischen Vorgehensmodell und Prozesssicht wird anhand eines Beispiels dargestellt. Abbildung 1 stellt einen Teilausschnitt, nämlich die Aufklärungsphase und partiell die Scanningphase eines vereinfachten Penetrationstests dar. Die einzelnen Subprozesse sind hierarchisch nummeriert. Im Subprozess 1.1.3 erfährt das Testteam, dass der Ansprechpartner für ein bestimmtes System das Unternehmen verlassen hat. Dies deutet auf einen möglichen SocialEngineering-Angriff hin. Es sollen so zusätzliche Informationen zur Kompromittierung des Systems erlangt werden. Der Subprozess 1.1.4 namens „Social Engineering“ wird initiiert. Hierfür sollte ein Spezialist für Social Engineering im Team eingesetzt und ihm diese Tätigkeit zugewiesen werden. Dies muss dem Team kommuniziert werden, anschließend sind diesem die Ergebnisse des Subprozesses zur Verfügung zu stellen. Abbildung 1: Beispielhafter Ablauf eines Penetrations-Tests (vgl. Winkler, 2008) 797 Die prozesstechnische Betrachtung von kollaborativen Penetrationstests hat folgende Aspekte aufgezeigt: - Es existieren in der Regel sehr viele, kleine Prozessschritte; statisches Verhalten der Arbeitspakete auf Makroebene; sehr dynamisches Verhalten der Arbeitspakete auf Mikroebene; Kommunikation und Dokumentation sind Schlüsselpunkte. Durch die feine Granularität der Prozessschritte ist es notwendig, diese in Arbeitspaketen zu aggregieren. Erst dadurch wird die zielführende Aufteilung auf die den Test durchführenden Security-Analysten ermöglicht. Betrachtet man die Makroebene eines Penetrationstests, so gliedert sich dieser in Phasen, die je nach gewähltem Vorgehensmodell iterativ sein können. Diese Phasen stellen gebündelte Arbeitspakete dar. Da auch ein kollaborativer Penetrationstest an dieser Methode keine nennenswerten Änderungen verursacht, können diese in klassischen Prozessbeschreibungssprachen dokumentiert werden. Auf Mikroebene erhöht sich bei der Bearbeitung durch mehrere Personen die Dynamik der Prozessaktivitäten wesentlich. Daraus resultieren Modifikationen, oftmals während der Durchführung. Es handelt sich dabei um sogenannte „ad hoc-Workflows“, die aus dem CSCW bekannt sind[1]. Diese weisen keine fixe Struktur auf, sondern können während der Durchführung von den handelnden Personen adaptiert werden [17]. Kommunikation ist bei einem kollaborativen Penetrationstest die wichtigste Komponente der Ressourcenallokation, da eine Detailplanung aufgrund der dynamischen Mikroebene nicht möglich ist. Da die Ressourcen bei diesen Tests durch das zur Verfügung stehenden Personal und den Zeitrahmen begrenzt sind, ist eine effiziente Nutzung zu gewährleisten. Dokumentation ist die Basis für die Ergebnisaufbereitung. Sie muss transparent und vollständig sein. Da bei einem kollaborativen Penetrationstest mehrere Personen verteilt und teilweise parallel agieren, bestehen hier besonderen Herausforderungen[1]. Mit unserem Collaborative Penetration Testing Tool versuchen wir, dieses Problem zu lösen. 4.1.1. Kommunikationsunterstützung Die Umsetzung von Erkenntnissen aus dem CSCW-Bereich ermöglicht es, die Reibungsverluste, die zuvor aufgezeigt wurden, zu kompensieren. Für die Realisierung unseres Konzepts ist sowohl eine synchrone als auch eine asynchrone Kommunikationsschiene notwendig. [7] Mittels schriftlicher (synchroner) Mitteilungen können sämtliche Teammitglieder miteinander kommunizieren. In Kombination mit der notwendigen Dokumentation ergibt sich durch diese gleichzeitige Protokollierung des Informationsaustausches ein Nutzengewinn in Netzwerken verteilt arbeitender Personen[8]. Die während des Tests entstehenden Artefakte müssen auch (asynchron) zwischen den durchführenden Personen ausgetauscht werden können. Die Ergebnisse eines oder mehrerer Arbeitspakete stellen oftmals den Input für einen nächsten Arbeitsschritt dar, der unter Umständen von einer anderen Person ausgeführt wird. So kann etwa ein großflächiger Portscan den Input für gezieltes Fingerprinting darstellen. Bezüglich Datenaustausch entschieden wir uns für den Einsatz von Peer-to-Peer-Technik (P2P). Diese bietet gegenüber einer klassischen Server-Client-Architektur mehrere Vorteile. Sämtliche im Test eingebundenen Hosts sollen äquivalente Partner sein. Durch den Einsatz von P2P erwarten wir 798 uns eine bessere Lastverteilung im Netzwerk. Während eines Tests befinden sich Hosts oftmals nicht im selben Netz, d.h. eine direkte Kommunikation ist nicht möglich. P2P ermöglicht es, andere Hosts als Brücken zu verwenden. 4.1.2. Koordinationsunterstützung Ad hoc-Workflows erlauben die Definition und Adaption von Prozessen vor und während der Durchführung. Daher müssen folgende Funktionen unterstützt werden: - Bearbeitung des Ablaufs vor und während des Tests Hinzufügen, Bearbeitung und Löschen von Arbeitsschritten vor und während des Tests Hinzufügen, Bearbeitung und Löschen von Arbeitspaketen vor und während des Tests Hierfür werden Prozessvorlagen unterstützt, die über die P2P-Kommunikation zwischen den Teilnehmern ausgetauscht bzw. von diesen adaptiert werden können. Prozessvorlagen sind z.B. in XML verfasste Prozessbeschreibungen, die direkt in die Anwendung eingelesen und abgebildet werden können. 4.1.3. Compliance zu Penetration Testing Standards Die Vorlagen, die für den Test erstellt werden, basieren auf den bekannten Vorgehensmodellen für Penetrationstests. Hier muss je nach Auftraggeber bzw. Testszenario das passende Modell ausgewählt werden. 4.1.4. Reporting Das Reporting-Modul bereitet die Ergebnisse des Penetrationstests automatisiert auf. Wir haben uns für die Implementierung von zwei Arten von Bericht entschieden. In einem Management-Bericht werden die Daten aggregiert und aufbereitet. Die Darstellung erfolgt hier mittels Grafiken, um Entscheidungsträgern einen raschen Überblick zu vermitteln. Der Detailreport dient als technischer Report für das Fachpersonal, damit dieses die Schwachstellen im Detail nachvollziehen und entsprechend gegensteuern kann. 4.1.5. Daten- und Kommunikationssicherheit Bei der ausgetauschten Information bzw. den übermittelten Daten handelt es sich meist um streng vertrauliche Informationen. Da oftmals externe Tests stattfinden und die Kommunikation somit z.B. über das Internet abgewickelt wird, ist der Einsatz kryptographischer Methoden unbedingt notwendig. 4.1.6. Usability Das Tool muss intuitiv bedienbar sein, um den Lernaufwand möglichst gering zu halten. Dies erhöht gleichzeitig die Benutzerakzeptanz. 799 4.1.7. Systemeinschränkungen Unser Tool ist keine P2P-Tauschbörse. Es handelt sich um ein temporäres, d.h., während der Überprüfung existierendes Netz, das nur einem eingeschränkten Benutzerkreis, den Testern, zur Verfügung steht. Die Applikation unterstützt nur einen kleinen Teil des Funktionsumfanges einer üblichen Workflow-Engine, außerdem ist kein aufwendiger Workflow-Editor implementiert. Im Vergleich zu einer Groupware-Plattform unterscheidet sich unser Tool durch die ausgedehnte Prozessunterstützung. 5. Design und Implementierung Bei der Implementierung wurde durch ein modulbasiertes Design auf einfache Erweiterbarkeit geachtet. Wir ermöglichen somit auch die Einbindung von Fremdkomponenten, um besser auf sich ändernde Anforderungen eingehen zu können. Um die als Rich-Client-Applikation umgesetzte Lösung plattformunabhängig zu gestalten, wählten wir Python4 als Programmiersprache. Sämtliche Parameter werden in Konfigurationsdateien ausgelagert, um die Wartbarkeit zu erleichtern. 5.1. Modulkonzept Bei Penetrationstests wird oftmals eine beachtliche Anzahl von Tools eingesetzt, daher war es uns ein Anliegen, die Möglichkeit der Integration aufzuzeigen. Die Fremdkomponenten, wie zum Beispiel der Netzwerkscanner Nessus5 oder der Portscann Nmap6, wurden, durch das Einbinden in die Benutzeroberfläche durchgängig in den Workflow integriert. Die Module können dadurch Informationen wie z.B. Scan Ergebnisse oder Parameter austauschen, um den Ablauf des Prozesses zu verbessern. 5.2. Reporting Das Reporting-Modul erzeugt auf Basis der Endberichte der einzelnen Module Berichte für verschiedene Zielgruppen. Das Ausgabeformat der Module ist unterschiedlich. Im Idealfall handelt es sich dabei um XML Dateien, die relativ einfach weiterverarbeitet werden können. Das ReportModul parst die Ergebnisse und speichert diese akkumuliert und mit Metabeschreibungen in einer Datei ab. Aus dieser Metadatei wird je nach Berichtstemplate der spezifische Bericht für die jeweilige Zielgruppe erzeugt. Derzeit sind zwei Berichtsarten implementiert, eine Mangement Summary sowie ein technischer Report. In der Management-Summary werden die aggregierten Daten für eine rasche Übersicht aufbereitet. Abbildung 2 zeigt eine sogenannte Vulnerability-Matrix. Hierbei werden mögliche Falsch-Positive aufgezeigt. Diese Auswertung basiert auf einem Vergleich der Ergebnisse zwischen VulnerabilityScanner und Netzwerkscanner. Wir unterscheiden folgende zwei Fehlerarten: • Typ 1 Fehler: Der Vulnerability-Scanner hat einen Host gefunden, der Netzwerkscanner jedoch nicht • Typ 2 Fehler: Der Netzwerkscanner hat einen Host gefunden, der Vulnerability-Scanner jedoch nicht. 4 Multiplattform Programmiersprache, die objekt-, aspektorientierte und funktionale Programmierung unterstützt. Nessus Vulnerability Scanner: http://www.nessus.org/nessus/ (Stand: Nov. 2008) 6 Nmap Port Scanner: http://nmap.org/ (Stand: Nov. 2008) 5 800 Die Risiken der einzelnen Schwachstellen werden in einer dreistufigen Skala bewertet. Abbildung 2: Management-Summary: Vulnerability Matrix und Schwachstellendiagramm Die obige Abbildung zeigt die Anzahl der gefundenen Schwachstellen in Abhängigkeit des verwendeten Betriebssystems. Dies lässt z.B. Rückschlüsse auf den Reifegrad des Patchmanagements in den einzelnen Bereichen zu. 6. Zusammenfassung und Ausblick In diesem Paper wurde Collaborative Penetration Testing, eine Weiterentwicklung der klassischen Penetrationstests nach Vorgehensmodellen, vorgestellt. Durch Arbeitsteilung und Spezialisierung wird die Effektivität und Effizienz erhöht, da die Ressourcen eines Penetrationstests durch das vorgegebenes Budget und die zur Verfügung stehende Arbeitszeit beschränkt sind. Dies stellt eine Möglichkeit dar, die wachsende Komplexität der zu testenden Infrastrukturen und der zunehmenden Professionalisierung im Cybercrime Bereich [5] [12] zu bewältigen. Hierfür analysierten wir die grundlegende Problemstellung der Durchführung eines Penetrationstests aus prozesstechnischer Sicht. Durch die von uns angestrebte Arbeitsteilung ergibt sich Potential zur Minimierung kommunikationstechnischer Reibungsverluste. Mit unserem Prototyp stellen wir die praktische Umsetzung der Erkenntnisse dieses Bereichs im Kontext unserer Idee unter Beweis. Der Hauptvorteil ist ein qualitativ verbessertes Testergebnis. Zur einfacheren und effizienteren Modellierung von Workflows ist der Einsatz der Business Process Execution Language (BPEL) 7 anzudenken. Dies würde die Definition der Vorgehensmodelle mittels einer standardisierten Beschreibungssprache ermöglichen. Durch die Erstellung von Process Templates für mehrere Standards wäre es möglich, den Produktivitätsgewinn in Feldstudien empirisch zu belegen. Ebenso erwarten wir uns Rückschlüsse auf die anzustrebende Granularität im Prozessdesign, die wiederum relevante Aspekte für das zukünftige Design von Vorgehensmodelle für Penetrationstests liefern. 7 BPEL 2.0 Spezifikation: http://docs.oasis-open.org/wsbpel/2.0/OS/wsbpel-v2.0-OS.html (Stand Juli 2008) 801 Weiters wird auch angedacht, die Art der Zusammenarbeit genauer zu analysieren[9], um die Unterstützung der Kommunikation weiter zu verbessern. 7. Literaturverzeichnis [1] AVRAM, G., Of Deadlocks and Peopleware – Collaborative Work Practices in Global Software Development, International Conference on Global Software Engineering 2007 [2] BISHOP, M., FRINCKE, D., About Penetration Testing, IEEE Security & Privacy (Nov/Dec 07), 2007 [3] BSI, Durchführungskonzept für Penetrationstests, Bonn, 2003 [4] BSI, Lagebericht zur IT Sicherheit, http://www.bsi.de/literat/lagebericht/lagebericht2007.pdf (Stand Juli 2008), 2007 [5] DN1NJ4, RBN „Rizing“, http://www.shadowserver.org/wiki/uploads/Information/RBN_Rizing.pdf (Stand Juli 08), Shadowserver Foundation, 2008 [6] GRESCHLER, D., MANGAN T., Networking lessons in delivering “Software as a Service” Part 1, International Journal of Network Management Volume 12 Issue 5, 2002 [7] GROSS, T., KOCH, M., Computer-Supported Cooperative Work – Interaktive Medien zur Unterstützung von Teams und Communities, Oldenbourg Verlag, 2007 [8] HAYTHORNTHWAITE, C., Collaborative Work Networks among Distributed Learners, Proceedings of the 32nd Hawaii International Conference on System Sciences, 1999 [9]HORROCKS; S., RAHMATI N., The Development and Use of A Framework for Categorising Acts of Collaborative Work, Proceedings of the 32nd Hawaii International Conference on System Sciences, 1999 [10] HERZOG, P., Open-Source Security Testing Methodology Manual 2.2, ISECOM, http://www.isecom.info/mirror/osstmm.en.2.2.pdf (Stand Juli 2008), 2006 [11] MCDERMOTT, J.P., Attack Net Penetration Testing, Proceedings of the 2000 workshop on new security paradigms, Ballycotton, 2000 [12] MELANI, Lage in der Schweiz und international – Halbjahresbericht 2008/I , 2008 [13] NIST, Guideline on Network Security Testing, Washington, 2003 [14] OISSG, Information Systems Security Assessment Framework, 2004 [15] SCHWEIZER INFORMATIKGESELLSCHAFT, Sicherheitsprüfungen von IT-Systemen mit Hilfe von TigerTeams, 1999 [16] SCHNEIER, B., Attack Trees, Dr. Dobb’s Journal, 1999 [17] VAN DER AALST; W.; VOORHOEVE, M., Ad-Hoc Workflows: Problems and Solutions, Proceedings of the 8th International Workshop on Database and Expert Systems Applications, 1997 [18] WINKLER, S., Collaborative Penetration Testing, Universitätsbibliothek Universität Wien, Wien, 2008 802 AUTOMATING PERIODIC ROLE-CHECKS A TOOL-BASED APPROACH Ludwig Fuchs, Christian Müller1 Abstract The use of roles in Identity Management has proven to be a solution for reorganising and securing the access structures of organisations. One critical challenge companies face after they implemented roles is the maintenance of the role system itself. This includes sophisticated duties like periodically verifying the valid roles. We argue that due to the high complexity, periodic rolechecks need to be automated. However, as a result of lacking theoretical foundation, no approaches to leverage the level automation have been published so far. In this work we develop a catalogue of use cases that affect the role definitions within an organisation. We propose checkROLE, a tool for automated role-checking on basis of the defined use case catalogue. 1. Motivation In today’s business environment companies provide access to resources to a greater number of users, and more types of users, than ever before. Major IT security problems arise because of employees gaining unauthorised access to resources as a result of manually handling user accounts ([4], [12]). This situation results in the so called identity chaos. National and international regulations like Basel II [1], the Sarbanes-Oxley Act [19], and the EU Directive 95/46 [5] force businesses to audit the actions within their systems. In-house Identity Management (IdM) is a means to solve the aforementioned identity chaos. It deals with the storage, administration, and usage of digital identities during their lifecycle [8]. Role-based IdM in particular is seen as a means to get compliant in general and to easily manage identities and their access to resources ([6], [10]). However, the central challenge after the implementation of roles is the management and maintenance of the role system itself in order to assure its timeliness. This includes the operative administration of the user-role assignments as well as strategic tasks including, e.g., the administration of role-permission assignments. Several developments within an organisation might affect the role definitions and require the role catalogue to be adapted. With thousands of users and millions of authorisations in big companies this task can’t efficiently be carried out manually. Besides the lacking theoretical foundation, no approaches to leverage the level of automation during the process of role-checking have been published so far. In this work we develop a catalogue of use cases that affect the role catalogue within an organisation. In order to show the applicability and advantages of our approach we furthermore propose checkROLE, a tool for the automatic 1 Universität Regensburg, D- 93053 Regensburg, Universitätsstr.31 803 detection of the defined use cases. Using checkROLE organisations can automatically identify changes in their role definitions and keep their role catalogue up-to-date. This paper is structured as follows. After an introduction to Role System Management and periodic role-checks in the related work section, we introduce a catalogue of use cases as the theoretical foundation for automating role-checks in section 3. After a detailed description we analyse selected use cases showing their influence on role definitions. In section 4 we then consecutively propose checkROLE. Section 5 gives conclusions and points out future work. 2. Related Work 2.1. Role System Management Operative and strategic management of roles and the role system in general are essential tasks to keep the implemented role definitions usable. In order to avoid misunderstandings we define the terms used in the following: Role System Management is the umbrella term for operative Role Management and strategic Role Management (Role Maintenance). Operative Role Management includes routine administration duties like user-role-assignment or role-permission-assignment according to the given administration model. Various authors investigated this area proposing several role administration publications like [2], [14], [15], [16], [17], [18], and [21] as well as role system lifecycles ([9], [11], [20]). However, operative Role Management can only be carried out effectively on basis of correct role definitions. Besides the maintenance of the underlying role concept and -model, the most important Role Maintenance duty is the up-to-date keeping of the role catalogue on basis of strategic Role Management processes. In contrast to its operative counterpart, this task heavily depends on organisational and operational structures (OOS) within a company. With dozens of business processes, thousands of users and millions of authorisations in big organisations, strategic Role Management is a seemingly difficult task. Only a few authors theoretically touched this issue on the brink ([11], [20]) while hardly any of them consider automation of Role Maintenance processes. The goal is to face Role Maintenance challenges by analysing existing role- and permission structures in order to provide suggestions for necessary changes in the role definitions, role-permission-, and user-role assignments. This way inconsistent permission assignments endangering compliance with security principles can be cleansed. 2.2. Periodic Role-Checks The importance of periodic role-checks as central part of the Role Maintenance duties has recently been pointed out by [9]. The goal of periodic role-checks is to evaluate the elements of a role system at a certain point of time in order to identify changes within a company that affect the role definitions. Values of role model elements of the last valid state are compared with their actual values in the productive systems. Periodic role-checks have to rely on existing user and access information as well as role definitions stored in the Identity Management Infrastructure or other user repositories. Together with organisational structures and the basic employee information coming from various directories this is a reliable and permanently available source for adequate user information. After the input information has been gathered the comparison of the output OP(t) of the productive user management environment at time t against the last valid role catalogue state OR(t-1) on basis of predefined use cases indicates events that affect the role definitions (see Figure 1). A consecutive impact analysis provides further assistance for resolving the discrepancies. Modifications in the organisational structure and user population are highlighted, for example when employees move to another department or a large number of new employees are hired. On basis of 804 this assistance a decision for resolving the open issues has to be made manually in an analytical way together with business- and IT representatives. In general, one can say that this duty is an iterative process, reducing inconsistencies all along the overall role-check process loop. As seen in Figure 1, periodic role-checks need to be carried out on basis of a well-defined use case catalogue. To the best of our knowledge no such basis has been proposed yet and no insight about underlying use cases as well as practical implementation issues is given in literature. In the following we close this gap by developing a use case catalogue that can be used as theoretical basis for role-checks. . Figure 1: Role-checking on basis of a given use case catalogue 3. Automatic Role-Checking 3.1. Input Elements Before designing a comprehensive use case catalogue we identified the various elements within organisations affecting role-checks and the defined role catalogue using busiROLE [7] as underlying role model. BusiROLE supports the usage of various types of roles, namely Basic Roles, Organisational Roles, and Functional Roles and is applicable in complex role environments. Basic Roles bundle common access rights, Organisational Roles represent employees' positions, and Functional Roles correspond to the task bundles of employees. Basic Roles can be regarded as special Organisational Roles. Our research was carried out on basis of practical experience with various partners from industry on the one hand and scientific publications in the business administration- and role-based user management area ([3], [11], [13], and [20]) on the other hand. The initial analysis revealed a number of components influencing the valid set of roles (see tables 1-6): Employees, Organisational Hierarchies, Positions, Task Bundles, and Permission (Bundles). Employees e.g. could leave the company or be assigned to a different hierarchical element. A hierarchical element is defined as a unit in the organisational structure of an enterprise, for example a business unit, a department, or a unit within a department. In other cases employees might be promoted and assigned to a new Position and new Task Bundles. Examples for change of Organisational Hierarchies include mergers or major restructuring efforts within a business area. Additionally, Permission Bundles of users might change over time. New IT systems might be implemented and the respective rights assigned to the employees while old system might no longer be used. Various constraints, e.g. security policies restricting the user-role- and user-permissionassignments can also affect Role Maintenance. However those constraints are usually not stored in a way that they could automatically be integrated into the role-checking process. Hence we focus on the previously introduced elements because information about those elements is likely to be available in an appropriate format. A definition of every element is given in the following to found the basis of standardised use case catalogue description in section 3.2. 805 Tables 1-6: Definition of input elements for role-checks Employees EMPS EMPa∈ EMPS A set of all employees A human being working for a certain enterprise Organisational Hierarchies OH OHtypea OHEtypea OHEa∈ OHEtypea A set of all Organisational Hierarchies within an enterprise with OH = {OHtypea, OHtypeb, …, OHtypen} One specific organisational hierarchy type within an enterprise, e.g. the line organisation A set of all hierarchical elements within OHtypea An element of a certain organisational hierarchy type OHypea Positions POSITIONS POSa∈ POSITIONS Task Bundles TB TBa∈ TB The set of Positions within OH A Position within an OHEa ∈ OHEtypea Set of all Task Bundles A bundle of tasks serving to fulfil a certain business goal Permission Bundles PB PBa∈ PB Set of all Permission Bundles A specific Permission Bundle serving to fulfil a certain business goal Organisational and Functional Roles ORG_Roles FUN_Roles ORG_Rolea ∈ ORG_Roles FUN_Rolea ∈ FUN_Roles Set of Organisational Roles Set of Functional Roles An Organisational Role defined to represent one Position A Functional Role defined to represent one Task Bundle 3.2. Use Case Catalogue Definition After the theoretical definition of input elements for role-checks we derived a comprehensive set of input element-specific use cases that influence the existing role definitions (see Figure 2). The elements are classified according to their respective layer of origin: Permissions and Permission Bundles are representing the existing access rights and hence are directory-specific while the other elements are related to operational and organisational structures within a company (OOS-specific). For each element various operations are possible, representing one single use case. Regarding Organisational Hierarchies, e.g., “new”, “delete”, “split”, and “merge” are possible operations. Hierarchical elements can be created or deleted as a result of restructuring efforts within a company. The splitting and merging operations can be seen as a combination of the previously mentioned ones. In terms of Positions companies might e.g. define new or delete old ones. Splitting an existing Position into two separate units can again be modelled as definition of two new Positions, re-assigning the old Task Bundles appropriately, and the consecutive deletion of the old Position. The same holds for the “merge” or “relocate” operation. Organisations might carry out new Task Bundles, delete old ones, or relocate existing Task Bundles to a new Position. The “split” and “merge” operations can again be seen as a special combination of the basic operations. Taking a user-centric view one can easily recognise the various changes an Employee can go through when working for a company. He can either change his Position or the assigned Task Bundles, or be 806 relocated to other hierarchical elements. Directory-specific use cases, finally, are dealing with Permission (Bundle) changes. Companies might install new resources, abandon old IT systems, or update existing software. The various examples regarding the “merge”, “split”, and “relocate” operations already have shown the interdependencies between single events. In practical settings it is likely that they do not occur isolated but combined. We are thus now going to identify complex use cases consisting of a number of the various events shown in Figure 2. Figure 2: Theoretical use case catalogue 3.3. In-Depth Analysis of Selected Use Cases In order to foster a clear differentiation and standardised usage we designed a three-layer scheme describing every use case in terms of its structure, its impact on the role system, and possible detection mechanisms. An analysis together with user partners from industry has shown the applicability of this schema as a means of easing communication. We are thus using it during the in-depth analysis of selected use cases in the following. 3.3.1. Selected Use Case 1: Employee Changes Hierarchical Element Structure (Figure 3): An employee EMPc is assigned to a new hierarchical element OHEi and Position POSi2 in the organisation. Due to this fact his work pattern changes and consists of new Task Bundles TBc and TBd. Previously he has been working in hierarchical element OHEj incorporating position POSj1 and related Task Bundles TBe, TBf, and TBg. Impact: To enable correct execution of TBc and TBd according permissions are granted to EMPc. This means that he needs to be assigned to a certain number of roles corresponding to POSi2, TBc, and TBd. However, access right allocation is mostly done manually by IT administrators and only rarely on basis of automated processes that ensure that the permissions requested are granted compliant with current role system policies. Imagine the promotion of an employee that rapidly needs access rights 807 for his new daily work and thus requests them calling several IT administrators. This usually results in a direct assignment of requested rights, probably on basis of the privileges of EMPb. Taking a closer look at necessary de-provisioning tasks unused Organisational- and Functional Roles corresponding to the old Position POSj1 and Task Bundles TBe, TBf, and TBg have to be revoked. Usually no automatic de-provisioning processes are in place so that this duty is not carried out at all or at most manually. Hence the employee is likely to accumulate a number of excessive rights within the organisations’ IT systems, violating the principle of the least privilege [6]. Figure 3: Employee changing organisational hierarchy element Detection and Actions: The first step in this scenario is to detect all employees EMPi∈ EMPS which have been assigned to a new hierarchical element. This can be done by analysing the according user attributes e.g. in the global user directory. In a second step, Role Maintenance must on the one hand examine if these employees have been assigned to the correct permissions and roles according to their new OHEi assignment. In case of any incorrect assignments this situation has to be resolved together with responsible executives. Role Maintenance has to check if old and thus unused access rights and role memberships have been correctly revoked. Statistical analysis and the integration of policies that e.g. define that a user is not allowed to be member of more than one Position in a certain organisation hierarchy type OHtypea can be facilitated to address this problem. 3.3.2. Selected Use Case 2: New Hierarchical Element is Created Structure (Figure 3): A new hierarchical element OHEk is created within a company due to certain organisational changes. It e.g. emerges from splitting an existing OHEl into two separate hierarchical elements. Scientific publications in the business administration area and in the area of organisational behaviour contain additional insight into reasons for change of hierarchical structures within an organisation ([3], [13]). In this scenario the creation of a hierarchical element results in the definition of a new position POSk1 and assignment of Task Bundles TBd, TBe ∈ TB. Employees are newly hired (EMPnew) or move from existing hierarchical elements to the newly created one (EMPa). Impact: After the creation of a new hierarchical element appropriate Organisational- and Functional Roles have to be defined. Role development has to be carried out for the new hierarchical element. However, in real-life settings employees quickly need permissions in order to fulfil their workload. 808 Imagine the newly created department OHEk in a large company. Two employees EMPa and EMPnew assigned to the defined Position POSk1 need to work on a highly critical project as soon as possible. In such a scenario administrators would likely assign permissions manually. This situation is subverting the goals of the existing role system. A further disadvantage is that employees who later on join this specific department, will also not be provided with the correct roles but rather gain their permissions manually. Similar to the previous use case the employees that already worked within the company in a different department still might have a large number of their old permissions due to the lack of correct de-provisioning processes. Figure 4: Creation of new hierarchical element Detection and Actions: To detect this use case and react appropriately any newly created or deleted hierarchical elements have to be detected at first. This can be done by an analysis of available organisational charts, a list of valid hierarchical elements, or user attributes regarding the assignment of employees to hierarchical structures. Consecutively the permissions of employees working in the newly created hierarchical elements have to be examined. Respective Functional- and Organisational Roles must be implemented and the role catalogue extended accordingly if they are not in place yet. After the creation of the various roles within the new hierarchical elements the permissions of employees have to be correctly provisioned. Directly assigned permissions have to be revoked and membership has to be granted using roles. Unused roles might have to be deleted. 4. checkROLE – A Tool for Automated Role Checking As tool support for the automatic detection of the various use cases is mandatory we developed checkROLE an open-source application that is able to detect events affecting the role definitions. On this basis it provides responsible managers assistance in their decision process from Figure 1. Input information from various user repositories at a certain point of time t is copied to the Role Maintenance environment using a LDAP connector or a .csv-file import. Additionally, an image of the currently valid role catalogue is extracted from the Role Management System. CheckROLE provides interfaces to an Active Directory storing the role catalogue, synchronised identity information, as well as access rights. Moreover a connector to other external Role Mining tools gives us the ability to execute non-statistical analysis of user data. 809 4.1. Detecting Use Cases in CheckROLE Figure 5 presents the main interface of checkROLE. Besides the detection scenarios (Role Maintenance) the Import to LDAP tab provides the ability to set up the data basis contained in the underlying repository. To support additional Role Mining tasks, an Export to DB tab was implemented providing export functionality of user and permission data. For real-life applicability we narrowed down the theoretically defined use cases according to their outcome to nine so called detection scenarios that checkROLE is able to identify. These detection scenarios occur in various combinations, dependent on the underlying use cases from section 3: • • • • • • • {EMPa, EMPb, …, EMPn} have directly assigned Permission Bundles PBa ∈ PB {EMPa, EMPb, …, EMPn} have a set of wrong or unused Organisational Roles {ORa, ORb, …, ORn} ∈ ORG_Roles inconsistent assignment of Permission Bundle PBa ∈ PB to FUN_Rolea ∈ FUN_Roles inconsistent assignment of Functional Role FUN_Rolea ∈ FUN_Roles to Organisational Role ORG_Rolea ∈ ORG_Roles detection of new Permission Bundle PBnew ∈ PB detection of changes in Position definitions detection of changes in Organisational Hierarchies Figure 5: CheckROLE interface 4.2. Test Scenario In order to demonstrate the application of checkROLE, we are going to present a short test scenario in a small industrial company with about 10 departments, 45 employees and 15 different business roles granting membership to about 50 different Active Directory groups (permissions). The company has implemented busiROLE as role model. For the role-checks user information and the existing role catalogue have been imported to the Role Maintenance environment using a LDAP connection to the global Active Directory within the company. Applying the Check user moves and the Check users OR functionality of checkROLE generates the output windows shown in Figure . 810 Figure 6: CheckROLE test scenario output The window on the left lists the employees that have changed their hierarchical element(s) and/or Position since the last role-checking loop. Positions of employees are stored in the title attribute within the Active Directory of the company. One can see that three users previously working in the Development department have joined the MigrationTeam. Their title attribute has changed, e.g. from Developer to ProjectLeader in case of employee PetBrau. Security policies prevent users to have more than one Position and Organisational Role at a certain point of time. CheckROLE identified that PetBrau is still connected to his old Organisational Role (OR_Developer) and that his title attribute has a different entry not corresponding to the Organisational Role assigned. Investigating the valid roles in the department MigrationTeam OR_ProjectLeader is suggested as the correct role. This needs to be done on basis of cluster analysis of existing rights within the respective department, closely interwoven with Role Development issues. The output window on the right side of Figure reveals directly assigned permissions. Even though all the permissions imported to the Role Maintenance environment have to be granted on basis of role membership, checkROLE identified several direct user-permission assignments. Employee PetBrau is e.g. on the one hand still able to access the various resources connected to his old Organisational Role. To fulfil the tasks related to his new Position ProjectLeader he was on the other hand assigned to the necessary permissions SW-Remedy-G, Project_Schedule, SW-RaD_Tools-G, and NET_Framework directly. With this output responsible role managers now are able to take adequate measures to resolve the found issues. This short scenario has shown that checkROLE is able to support strategic Role Management and provide information that might not even have been identified at all. 5. Conclusions and Future Work In this paper we have seen that companies require support in ensuring the timeliness of the implemented roles in their IT infrastructure. Several changes within an organisation might affect the role definitions and require the role catalogue to be updated. This requires an automated overview over possible changes to be integrated in a Role Maintenance solution. Up to now, to the best of our knowledge, no assistance is provided by researchers in this area. Consequently we defined a use case catalogue that acts as theoretical basis for role-checks. An in-depth analysis of single use cases has revealed their structure, impact on the role definitions, and possible detection mechanisms. We furthermore presented checkROLE a tool for automatic detection of various use cases. It facilitates statistical analysis and data mining algorithms to compare a valid role catalogue with the present situation within a company in order to identify discrepancies. A short test scenario 811 has shown the applicability of checkROLE within a small company. For future work we are going to add new functionalities for detecting combined use cases and migrate towards a process-oriented role checking workflow. Up to now checkROLE only provides a simple text-based presentation of results. For a seamless integration into future Role Maintenance and Role Development solutions it needs to be extended in order to allow for an automatic correction of detected anomalies. Moreover the text-based visualisation is very limited in terms of readability in more complex test scenarios. We hence are implementing an adequate solution that presents the found results in a more structured way allowing for interaction with the checkROLE users, i.e. the Role Maintenance team. References [1] BANK FOR INTERNATIONAL SETTLEMENTS, BIS: International Convergence of Capital Measurement and Capital Standards: A Revised Framework - Comprehensive Version, http://www.bis.org/publ/bcbs128.pdf, 2006. [2] CRAMPTON, J., LOIZOU, G., Administrative scope: A foundation for role-based administrative models, ACM Transactions on Information and System Security (TISSEC) 6, pp. 201–231, 2003. [3] DAFT, R., Organization Theory and Design. 2nd ed. West, St. Paul, Minn. 1986. [4] DHILLON, G.: Violation of Safeguards by Trusted Personnel and Understanding Related Information Security Concerns. Computers & Security 20 (2), pp. 165-172, 2001. [5] EUROPEAN UNION: Directive 95/46/EC of the European Parliament and of the Council. Official Journal of the European Communities L (28-31), http://ec.europa.eu/justice_home/fsj/privacy/docs/95-46-ce/dir199546_part1_en.pdf, 1995. [6] FERRAIOLO, D. F., KUHN, R. D., CHANDRAMOULI, R., Role-Based Access Control. Artech House, Boston, Mass./London 2007. [7] FUCHS, L., PREIS, A., BusiROLE: A Model for Integrating Business Roles into Identity Management, Proc of the 5th Int. Conference on Trust, Privacy, and Security in Digital Business (TrustBus), Torino, Italy 2008. [8] FUCHS, L., PERNUL, G., Supporting Compliant and Secure User Handling – a Structured Approach for In-house Identity Management, Proc. of the 2nd Int. Conference on Availability, Reliability and Security (ARES '07), pp. 374-384. IEEE Computer Society, Vienna, Austria 2007. [9] FUCHS, L., PERNUL, G., proROLE: A Process-oriented Lifecycle Model for Role Systems, Proc. of the 16th European Conference on Information Systems (ECIS), Galway, Ireland 2008. [10] GALLAHER, M. P., O’CONNOR, A. C., KROPP, B.: The economic impact of role-based access control. Planning report 02-1, National Institute of Standards and Technology, http://www.nist.gov/director/progofc/report02-1.pdf, Gaithersburg, MD 2002. [11] KERN, A., KUHLMANN, M., SCHAAD, A., MOFFETT, J., Observations on the role life-cycle in the context of enterprise security management, Proc. of the 7th ACM Symp. on Access Control Models and Technologies (SACMAT '02), pp. 43-51, ACM, New York 2002. [12] LARSSON, E. A.: A case study: Implementing Novell Identity Management at Drew University. Proc. of the 33rd ACM SIGUCCS conference on User services (SIGUCCS’05), pp. 165-170, ACM, New York 2005. [13] MINTZBERG, H., Structuring of Organizations. Prentice Hall, Englewood Cliffs, N.J. 1979. [14] NYANCHAMA, M., OSBORN, S., The role graph model and conflict of interest, ACM Transactions on Information and System Security (TISSEC) 2, pp. 3–33, 1999. [15] OH, S., SANDHU, R., A model for role administration using organization structure, Proc. of the 7th ACM Symp. on Access Control Models and Technologies (SACMAT '02), pp. 155–162, ACM, New York 2002. [16] OH, S., SANDHU, R., Zhang, X., An effective role administration model using organization structure, ACM Transactions on Information and System Security (TISSEC) 9, pp. 113–137, 2006. [17] SANDHU, R., BHAMIDIPATI, V., MUNAVER, Q., The ARBAC97model for role-based administration of roles, ACM Transactions on Information and System Security (TISSEC) 2, pp. 105–135, 1999. [18] SANDHU, R., MUNAVER, Q., The ARBAC99 Model for Administration of Roles, Proc. of the 15th Annual Computer Security Applications Conference, pp. 229–238, Phoenix, USA 1999. [19] SARBANES, P. S., OXLEY, M.: Sarbanes-Oxley Act of 2002, also known as the “Public Company Accounting Reform and Investor Protection Act of 2002”, http://frwebgate.access.gpo.gov/cgibin/getdoc.cgi?dbname=107_cong_bills&docid=f:h3763enr.tst.pdf, 2002. [20] SCHIMPF, G., Role-Engineering Critical Success Factors for Enterprise Security Administration, Position Paper for the 16th Annual Computer Security Application Conference, New Orleans, USA 2000. [21] ZHANG, Y., JOSHI, J. B., ARBAC07: A Role-based Administration Model for RBAC with Hybrid Hierarchy, Proc. of the IEEE Int. Conference on Information Reuse and Integration, pp. 196–202, Las Vegas, USA 2007. 812 INNOVATIONSMANAGEMENT UND PRODUKTENTWICKLUNG Der Bereich Innovationsmanagement und Produktentwicklung hat vielfältige Schnittstellen und Berührungspunkte zu Software- und IT-Systemen. Zum einen müssen natürlich solche Produkte selbst entwickelt werden, wozu es dedizierte Entwicklungsprozesse gibt. Für diesen Track von zentralerer Bedeutung ist aber die Rolle, die Software- und IT-Systeme für die Innovationsentwicklung generell haben, und wie sie die Effizienz und Effektivität der Entwicklung von Produkten und Services treiben. Neue Möglichkeiten der Kommunikation und Vernetzung, der Simulation und des Prototyping, der Kundenintegration oder Produktionsplanung usw. haben die Potenziale des Managements von Innovation und Produktentwicklung in den letzten Jahren deutlich verändert. Sie schaffen Raum für verbesserte Innovationsprozesse und teilweise völlig neuartige Geschäftsmodelle. Leitungsgremium: Nikolaus Franke, Wirtschaftsuniversität Wien (Federführender) Oliver Günther, Humboldt-Universität zu Berlin Kathrin Möslein, Universität Erlangen-Nürnberg Frank Piller, Rheinisch-Westfälische Technische Hochschule Aachen Programmkomitee: Andrea Back, Universität St. Gallen Francis Bidault, European School of Management and Technology Berlin Lutz Ellermann, Vaillant GmbH Ellen Enkel, Zeppelin University Deutschland Joachim Henkel, TU München Matthias Freund, Bundeskartellamt Deutschland Jürgen Karla, RWTH Aachen Detlef Schoder, Universität zu Köln Gerrit Tamm, SRH Hochschule Berlin Jürgen Wenger, BMW AG FACHLICHES INNOVATIONSMANAGEMENT ALS STRATEGISCHER ERFOLGSFAKTOR IN DER IT-BERATUNG UND SYSTEMINTEGRATION Sean Eikenberg1,2, Stephan Melzer2, Ulrike Lechner1 Kurzfassung Nachhaltig erfolgreiche IT-Beratungs- und Systemintegrations-Unternehmen setzen sich mit den Problemen ihrer Kunden auseinander. Ein offenes und auf Kunden ausgerichtetes Innovationsmanagement findet IT-gestützte Prozessinnovationen für fachliche Kundenprobleme. Wir haben mit unserer Aktionsforschung bei der sd&m AG vier Instrumente für ein solches fachliches Innovationsmanagement entwickelt und erprobt. Mit dieser Arbeit präsentieren wir diese Instrumente, leiten daraus für die weitere Forschung Thesen ab und reflektieren die noch offenen Fragestellungen. 1. Einleitung Aus betriebswirtschaftlicher Sicht ist die Liquidität die unmittelbare Steuerungsgröße der Unternehmensführung. Ihr Wirkungsgrad ist jedoch nur kurzfristiger Natur. Für einen nachhaltigen Unternehmenserfolg sieht Gälweiler [1] die Notwendigkeit weiterer Steuerungsgrößen. Für ihn steuert sich Liquidität über Erfolg, Erfolg wiederum durch bereits vorhandene Erfolgspotenziale und diese letztendlich durch zukünftige Erfolgspotenziale. Gälweiler sieht in die Auseinandersetzung mit den fachlichen Kundenproblemen die Grundlage zukünftiger Erfolgschancen. Bei IT-Beratungs- und Systemintergrations-Unternehmen nehmen wir aktuell zwei Instrumente zur Sicherung zukünftiger Erfolgspotenziale wahr: • Fachliche Kundenprobleme werden über Analogie antizipiert. Eine bei einem Kunden bereits erfolgreiche Lösung wird generalisiert und bei einem anderen Kunden eingesetzt. • Neue IT-Technologien am Markt werden durch ein Innovationsmanagement beobachtet. Sobald die Vermarktbarkeit gegeben ist, werden sie Kunden in Pilotprojekten angeboten. In Märkten mit wenigen Marktteilnehmern besteht beim ersten Instrument die Gefahr eines endlichen und damit beschränkten Vertriebspotenzials. Das zweite Instrument ist rein technologiegetrieben, abstrahiert von den konkreten Kundenproblemen und ist damit durch andere Unternehmen substituierbar. Wir konnten in früheren Forschungsarbeiten [2, 3] feststellen, dass diese Form des Innovationsmanagements nur unzureichend auf die Rolle des Kunden eingeht. So fehlt dem technisch orientierten Innovationsmanager häufig der direkte Zugang zu den Kunden. Beide Instrumen1 2 Universität der Bundeswehr, München, Deutschland sd&m AG, München, Deutschland 815 te für sich genommen sind aus unserer Sicht bei einem IT-Beratungs- und SystemintergrationsUnternehmen nicht ausreichend, um zukünftige Erfolgspotenziale hinreichend abzusichern. Aktuelle Forschungspublikationen [4-6] stützen die These, dass Lösungen zu fachlichen Kundenproblemen im Zuge eines offenen und auf Kunden ausgerichteten Innovationsmanagements gefunden werden können. Mit unserer deskriptiven Forschungsarbeit hinterfragen wir diese These mittels Aktionsforschung im IT-Beratungs- und Systemintegrationshaus sd&m. Dazu stellen wir in Kapitel 2 sd&m sowie den Aufbau unserer Aktionsforschung vor. Den Schwerpunkt bildet Kapitel 3 mit unseren Erkenntnissen zu den Inhalten, Werkzeugen, organisatorischen Themen und Kundenfunktionen eines möglichen fachlichen Innovationsmanagements. Im vierten Kapitel fassen wir unsere Erkenntnisse für nachfolgende Forschungsarbeiten zu Thesen zusammen und reflektieren die noch offenen Fragestellungen. Trotz kritischer Bewertung der Erfolgsfaktorforschung innerhalb der Managementwissenschaften [7, 8] sehen wir für unserer Forschungsarbeit eine hohe Praxisrelevanz. 2. Aktionsforschung 2.1. Das IT-Beratungs- und Systemintegrationshaus sd&m Die sd&m AG gehört zur weltweiten Capgemini-Gruppe und repräsentiert deren Geschäftssparte Technology Services in Deutschland und der Schweiz. Das Leistungsangebot von sd&m umfasst die Entwicklung von Individualsoftware, die Systemintegration und die IT-Beratung. Im Jahr 2007 hat sd&m 198 Mio. € Umsatz erzielt und beschäftigt aktuell über 1.840 Mitarbeiter an 8 Standorten in Deutschland und in der Schweiz sowie einem Nearshore-Center in Wroclaw, Polen. sd&m ist projektzentriert und hat eine hybride Linienorganisation, die für die zwei umsatzstärksten Kundengruppen (Automotive, Banken und Versicherungen) branchenorientiert und für alle weiteren Kunden regional aufgestellt ist. Mit sd&m Research (sR) verfügt sd&m über eine Forschungsabteilung, die unter anderem für das technologiegetriebene Innovationsmanagement verantwortlich ist. Ziel des sR Innovationsmanagements ist die Stärkung von sd&m als Diskussions- und Dienstleistungspartner für neue IT-Technologien [9]. Es greift diese Technologien aktiv auf, gestaltet vertrieblich nutzbare Leistungsbausteine und vermittelt dem sd&m-Team Anwendungswissen. Der im Fokus dieser Arbeit stehende sd&m-Vorstandsbereich Automotive (VB Automotive) gliedert sich in drei Kundenbereiche und d

Log In

Measuring Client-Vendor Distance in Global Outsourceing Relationships: A Conceptual Model

Related papers

Related papers

Related topics