GAINING INSIGHT INTO BUSINESS
NETWORKS
A simulation based support environment to improve process
orchestration
GAINING INSIGHT INTO BUSINESS
NETWORKS
A simulation based support environment to improve process
orchestration
PROEFSCHRIFT
ter verkrijging van de graad van doctor aan de Technische Universiteit Delft,
op gezag van de Rector Magnificus prof. dr. ir. J.T. Fokkema, voorzitter van het College voor Promoties,
in het openbaar te verdedigen op donderdag 15 december 2005 om 10.30 uur door Tamrat Woldu TEWOLDEBERHAN
bestuurskundig ingenieur geboren te Asmara, Eritrea
Prof. Dr. H.G. Sol Prof. Dr. Ir. A. Verbraeck
Samenstelling Promotiecommissie:
Rector Magnificus, voorzitter
Prof. Dr. H.G. Sol, Technische Universiteit Delft, promotor
Prof. Dr. Ir. A. Verbraeck, University of Maryland, USA, promotor Prof. Dr. Ir. E. van Heck, Erasmus Universiteit Rotterdam
Prof. Dr. H. Koppelaar, Technische Universiteit Delft
Prof. Dr. Ir. R. Maes, Universiteit van Amsterdam
Prof. Dr. W. Vree, Technische Universiteit Delft
To my dad, Woldu, to my mom, Tsehaitu, and to my dear wife Ruth.
Colophon
Published and distributed by: Tamrat Woldu Tewoldeberhan
Zairestraat 85 Delft University of Technology
2622 ET Delft Faculty of Technology, Policy and Management
The Netherlands Jaffalaan 5
Phone: +31 (0) 15 262 7665 2628 BX Delft, The Netherlands
Phone: +31 (0) 15 278 8380
Fax: +31 (0) 15 278 3429
English editor: Miranda Aldham Breary
Printing: Febodruk BV – www.febodruk.nl, Enschede/Utrecht Cover picture: Roy T.H. Chin
Tamrat Woldu Tewoldeberhan
Gaining insight into business networks: A simulation based support environment to improve process orchestration
Doctoral Dissertation, Delft University of Technology, The Netherlands ISBN: 90-5638-140-7
Keywords: business process orchestration, decision support, simulation & modeling, service orientation, business networks
Copyright © 2005 by Tamrat Woldu Tewoldeberhan
All rights reserved. No parts of this publication may be reproduced, stored in a retrieval system, or transmitted in any form by any means, electronic, mechanical, photocopying, recording, or otherwise, without the written permission of the author.
PREFACE AND ACKNOWLEDGEMENTS
“No one who achieves success does so without acknowledging the help of others. The wise and confident acknowledge this help with gratitude." Alfred North Whitehead
In today’s world, organizations are becoming increasingly interested in using business networks as a means to adapt to the ever-changing environment. An important challenge organizations need to meet is efficient and effective business process orchestration with their partners in business networks. In the research presented in this thesis, we examined process orchestration issues in current business networks, and developed a simulation based support environment that consists of a methodology and software tool, that can be used to assist organizations to design an efficient and reliable process orchestration.
I am indebted to many people for their help in the last four years in completing my PhD research journey. First and foremost, I would like to thank my first supervisor, Henk Sol, for providing me with the opportunity and freedom to conduct this research. His care and valuable comments not only helped me to guide my dissertation research, but also to set my priorities and to put family first.
I would like to thank my second supervisor, Alexander Verbraeck, for his resourcefulness, profound support, and fruitful lengthy discussions. The countless discussions I had with him in the afternoons helped me to shape my dissertation research. Thank you!
During the four years research period, I was lucky to meet wonderful research colleagues in the Faculty of Technology, Policy and Management. Many thanks to Edwin Valentin, Zoran Stojanovic, Marijn Janssen, Peter Jacobs, Jeffrey Gortmaker, Semir Daskapan, and Amr Ali-Eldin for constructing feedbacks and for being always interested to improve my thesis. I would like to thank Simon Msanjila for conducting his MSc thesis within this research and for assisting me during the testing phase of the research.
Many thanks to Sabrina Rodrigues for her valuable administrative support and for sharing numerous comedy clips that made my long research journey smooth and fun. I am indebted to Miranda Aldham-Breary for her practical support in many ways and for improving the English quality of the dissertation.
During the last and challenging stage of the research, many people helped me finish up in time. I would like to thank Cornie Versteegt, Job Honing, and Elisangela Kalancilo for proof reading my dissertation manuscript; Wieke Bockstael-blok for translating my summary and propositions to Dutch, and for identifying weak points in the thesis manuscript; and, Roy Chin for designing a beautiful picture of the research for the dissertation cover page.
I had the pleasure to work with wonderful colleagues in the Systems Engineering section. I would like to thank Jurgen van Grinsven, Wander van den Berg, Sam Muniafu, Jessica Nong,
Pieter van Houten for the relaxing talks during lunch times and coffee breaks. I want to thank the members of my ‘peer group’ Piet van der Zanden, Evren Akar, and Andrew Barendse, and coaches, for the constructive and interesting research related debates that we had.
During the long struggle to finish my PhD in The Netherlands, several wonderful friends made my stay pleasurable. Many thanks to Eyassu Tesfamariam, Samson Tesfazgi, Daniel Beyene, Yi Zhao, Hashim Mohammed, Hidat Berhe, Eden Melles, Naoual Babaghayou, Biniam Ghebremichael, Milen Goitom, Abraham Mehari, Yohannes Asgede, and Alganesh Mengesha. Last, but certainly not least, I would like to thank my parents, Woldu Tewoldeberhan and Tsehaitu Petros, and my dear wife, Ruth Demoz. My parents for raising me to be a better person and Ruth for her love and support.
Tamrat Woldu Tewoldeberhan Delft, December 2005
1. PROCESS ORCHESTRATION IN BUSINESS NETWORKS ... 1
1.1 INTRODUCTION... 1
1.2 PROCESS ORCHESTRATION IN BUSINESS NETWORKS... 4
1.3 PROCESS ORCHESTRATION CHALLENGES IN BUSINESS NETWORKS... 5
1.4 PROCESS ORCHESTRATION ENABLING TECHNOLOGIES... 7
1.4.1 Electronic Data Interchange (EDI)... 8
1.4.2 Workflow ... 8
1.4.4 XML-based frameworks and technologies ... 8
1.5 SIMULATION BASED INQUIRY SYSTEMS... 10
1.6 RESEARCH OBJECTIVE AND QUESTIONS... 12
1.7 RESEARCH METHODOLOGY... 14
1.7.1 Research philosophy ... 15
1.7.2 Research strategy ... 16
1.7.3 Research instruments ... 18
1.8 RESEARCH OUTLINE... 21
2. PROCESS ORCHESTRATION IN PRACTICE... 23
2.1 THE US DOD LOGISTICS NETWORK... 24
2.1.1 Introduction... 24
2.1.2 Process orchestration in the US DOD logistics network ... 26
2.1.3 An E-portal solution to improve process orchestration ... 28
2.1.4 Lessons learned... 35
2.2 IMPROVING PROCESS ORCHESTRATION THROUGH SIMULATION... 37
2.2.1 Simulation and visualization ... 37
2.2.2 The User Interface... 38
2.2.3 Lessons learned... 39
2.3 REFLECTIONS... 41
3. PRINCIPLES OF BUSINESS PROCESS ORCHESTRATION... 43
3.1 INTRODUCTION... 43
3.2 SERVICE ORIENTATION AND SERVICE-ORIENTED ARCHITECTURE... 45
3.2.1 Evolution of service-oriented architecture... 46
3.2.2 Principles of service-oriented architecture... 47
3.2.3 Basics of service-oriented architecture... 50
3.2.4 Extended service-oriented architecture... 51
3.2.5 Service-oriented architecture for process orchestration... 53
3.3 BUSINESS SERVICES... 53
3.4 BUSINESS PROCESS ORCHESTRATION... 55
3.5 BUSINESS PROCESS ORCHESTRATION LANGUAGES... 58
3.5.1 Fundamental concepts... 59
3.5.2 Advanced features ... 61
3.5.3 Predefined signals... 62
3.5.4 Workflow ... 62
4.1 REQUIREMENTS FOR THE SUPPORT ENVIRONMENT... 63
4.2 A FRAMEWORK FOR THE SUPPORT ENVIRONMENT... 65
4.3 WAY OF THINKING... 66
4.3.1 View on the problem domain... 66
4.3.2 Methodological principles... 68
4.4 WAY OF WORKING... 72
4.5 WAY OF MODELING... 74
4.5.1 The Conceptual Model ... 75
4.5.2 The Empirical Model... 81
4.6 WAY OF CONTROLLING... 97
4.7 REFLECTIONS... 98
5. TESTING THE SUPPORT ENVIRONMENT... 101
5.1 FAPLIN SUPPLY CHAIN CASE... 102
5.2 CONCEPTUALIZATION... 104
5.2.1 Conceptualization of the processes ... 104
5.2.2 Conceptualization of the Web services... 107
5.2.3 Conceptualization of the process orchestrations... 112
5.3 SPECIFICATION... 115
5.3.1 Simulation in DSOL ... 116
5.3.2 Simulating Purchase Goods and Source Goods processes orchestration in DSOL... 117
5.3.3 Modeling hidden decision points... 121
5.4 VERIFICATION, VALIDATION, AND EXPERIMENTATION... 126
5.4.1 Verification and validation... 126
5.4.2 Experimentation with the neural network model... 126
5.4.3 Experimentation with the simulation model ... 129
5.5 IMPLEMENTATION OF RESULTS IN A GAMING ENVIRONMENT... 133
5.6 REFLECTIONS... 137
6. EVALUATING THE SUPPORT ENVIRONMENT ... 139
6.1 STRUCTURE OF THE EXPERT INTERVIEW APPROACH... 140
6.2 EXPERTS’ EVALUATION OF THE SUPPORT ENVIRONMENT... 141
6.2.1 View on process orchestration ... 141
6.2.2 View on the support environment... 142
6.3 REFLECTIONS... 145
7. EPILOGUE ... 147
7.1 RESEARCH FINDINGS... 147
7.1.1 Research question one... 147
7.1.2 Research question two... 148
7.1.3 Research question three ... 150
7.2 RESEARCH APPROACH... 155
APPENDIX A. DSOL IMPLEMENTATION OF BPEL4WS <RECEIVE>
ELEMENT ... 170
APPENDIX B. EXPERT INTERVIEWS PARTICIPANTS... 174
SUMMARY... 175
SAMENVATTING ... 181
FIGURE 1-1: EVOLVING FORMS OF BUSINESS... 3
FIGURE 1-2: RESEARCH OUTLINE... 22
FIGURE 2-1: US DOD LOGISTICS NETWORK... 25
FIGURE 2-2: US DOD ORDER REQUISITION PROCESS... 27
FIGURE 2-3: F-101 SUPPLY CHAIN ARCHITECTURE... 29
FIGURE 2-4: REQUISITION PROCESS ORCHESTRATION THROUGH E-PORTAL... 31
FIGURE 2-5: SUBMISSION OF MECHANIC ORDER... 32
FIGURE 2-6: REQUISITION GENERATION... 33
FIGURE 2-7: TRANSFERRING ORDER... 34
FIGURE 2-8: PURCHASE ORDER... 34
FIGURE 2-9: SIMULATION AND VISUALIZATION ARCHITECTURE... 37
FIGURE 2-10: REQUISITION BUSINESS PROCESS... 38
FIGURE 2-11: VISUALIZATION INTERFACE... 39
FIGURE 3-1: EVOLUTION OF ARCHITECTURES... 47
FIGURE 3-2: APPLICATION IMPLEMENTATION LAYERS: SERVICES, COMPONENTS, OBJECTS. 49 FIGURE 3-3: SERVICE-ORIENTED ARCHITECTURE... 51
FIGURE 3-4: EXTENDED SERVICE-ORIENTED ARCHITECTURE... 52
FIGURE 3-5: CURRENT MESSAGING-CENTRIC APPROACHES VERSUS BPO APPROACH... 56
FIGURE 3-6: ORCHESTRATION DEVELOPMENT LIFECYCLE... 58
FIGURE 3-7: ROLES IN BPO... 60
FIGURE 3-8: ROLE DECLARATION IN XML SCHEMA... 60
FIGURE 4-1: ANALYTICAL FRAMEWORK FOR DESIGN METHODOLOGIES... 65
FIGURE 4-2: COMBINED BLACK BOX AND WHITE BOX SIMULATION MODEL... 72
FIGURE 4-3: PROBLEM-SOLVING CYCLE... 73
FIGURE 4-4: UML SEQUENCE DIAGRAM OF PURCHASE ORDER PROCESS... 77
FIGURE 4-5: BPEL4WS PROCESS IN ORACLE BPEL PROCESS DESIGNER... 80
FIGURE 4-6: BPEL4WS BASED SIMULATION BUILDING BLOCK DEVELOPMENT PROCESS.... 83
FIGURE 4-7: BASIC EVENT GRAPH CONSTRUCT... 85
FIGURE 4-8: EVENT GRAPH FOR BPEL4WS ELEMENT <RECEIVE>... 86
FIGURE 4-9: EVENT GRAPH FOR BPEL4WS ELEMENT <FLOW> ... 87
FIGURE 4-10: UML CLASS DIAGRAM OF BPEL4WS BASED SIMULATION BUILDING BLOCKS ... 89
FIGURE 4-11: UML CLASS DIAGRAM OF SOME WSDL BASED SIMULATION BUILDING BLOCKS ... 90
FIGURE 4-12: UML CLASS DIAGRAM OF BPEL4WS ELEMENT 'RECEIVE' SIMULATION BUILDING BLOCK... 91
FIGURE 4-13: MULTILAYERED FEEDFORWARD NEURAL NETWORK... 94
FIGURE 5-1: ARCHITECTURE OF THE ORCHESTRATION... 104
FIGURE 5-2: UML SEQUENCE DIAGRAM OF PURCHASE GOODS PROCESS... 105
FIGURE 5-3: UML SEQUENCE DIAGRAM OF SOURCE GOODS PROCESS... 106
FIGURE 5-4: UML SEQUENCE DIAGRAM OF REPLENISH STOCK PROCESS... 106
FIGURE 5-5: UML SEQUENCE DIAGRAM OF SUPPLY FINISHED GOODS AND MANUFACTURER FINISHED GOODS PROCESSES... 107
FIGURE 5-7: WSDL REPRESENTATION OF SHIPGOODSREQUEST MESSAGE... 113
FIGURE 5-11: MULTILAYERED PERCEPTRON (MLP) ... 125
FIGURE 5-12: TRAINING MLP USING LOAN SERVICE SAMPLE... 127
FIGURE 5-13: BEST FIT OF MEAN SQUARE ERROR (MSE) ... 128
FIGURE 5-14: AVERAGE FIT OF MEAN SQUARE ERROR (MSE)... 128
FIGURE 5-15: OUTPUT OF SIMULATION RUN... 131
FIGURE 5-16: NUMBER OF SUCCESSFUL ORCHESTRATION FOR 'SEQUENTIAL REQUEST TO WAREHOUSES' ORCHESTRATION DESIGN... 132
FIGURE 5-17: GAMING ON SUPPLY CHAIN PROCESS ORCHESTRATION... 134
FIGURE 5-18: PURCHASE ORDER THROUGH FAPLIN WEB PORTAL... 135
FIGURE 5-19: PROCESS ORCHESTRATION WAITING HUMAN DECISION-MAKING... 135
“To raise new questions, new possibilities, to regard old problems from a new angle, requires creative imagination and marks real advance in science.” Albert Einstein
1. Process Orchestration in Business Networks
1.1 Introduction
According to the evolution theory of Charles Darwin, human beings and other living organisms need to adapt to cope with the ever-changing environment; otherwise their survival becomes questionable (Darwin, 1859; Darwin & Huxley, 2003). Following Darwin, living creatures have been adapting to changes in the environment for millions of years. Those that could not adapt to new situations perished, while those that could have survived, all the time undergoing continuous change in response to the need to adapt to their changing environment.
This principle of survival of the fittest can be used to explain some of the phenomena in today's business world (Dekkers, 2004; Kurzban, 1982; Mackey, 2003; Ptak, 2002; Rice, 2001; Singh, 2001). This is because it is not the biggest, not the strongest, nor the most aggressively competitive company (organization) that necessarily grows and evolves. Just as in evolution theory, where the fittest organisms are those that are the most adaptable, organizations that are capable of adapting quickly to a rapidly changing environment are the most likely to survive and thrive. Organizations must continuously change in response to ongoing changes in the business environment (Donaldson, 1996; Greiner, 1972; Quinn, 1978; Quinn & Cameron, 1983; Tapscott, 1999), and, to cope with change in the business environment, organizations have used different strategies and means over time. In their book, Bowersox et al. (1996) illustrate the issues and consequences of adaptability to the environment using Ford’s car manufacturing “self-sufficiency” philosophy as an example (see Table 1-1).
In the current era, organizations use inter-organizational relationships as a way to adapt and increase their performance level (Binney & Ishak, 2002; Hengst & Sol, 2002; Tapscott, 1999). The focus of efforts to improve the performance of organizations has shifted from the organizational level to the inter-organizational level (Malone & Crowston, 1994; McGrath & Hollingshead, 1994). The current era is characterized by high competition, high information flow, a high demand for timeliness and accurateness of information and changes in business needs and customer needs. According to Hengst and Sol (2002), there are numerous business trends that indicate a growing interest in inter-organizational relationships. Some of these trends are: deregulation of markets, increased use of information and communication technology (ICT), outsourcing, and globalization. The use of ICT provides an increasing number of new, easy and cheap ways to exchange information with other organizations (Hengst & Sol, 2002).
Table 1-1: Ford’s unsuccessful ‘self-sufficiency’ philosophy
“Ford’s desire for control went beyond material and components. To transport materials to River Rouge and finished products to dealers he invested in railroads, trucks, and both Great Lakes and ocean vessels. The idea was to control all aspect of inventory moving from a network of over forty manufacturing, service, and assembly plants throughout the United States, Canada, Australia, New Zealand, and United Kingdom, and South Africa to dealers throughout the globe.
This was clearly one of the most ambitious vertical integration schemes, and Ford found he needed help. At the peak of Ford’s vertical extension the firm faced economic, regulatory, and labor union barriers that eventually required products and services to be provided by a network of independent suppliers. The key to effective marketing was finally found by developing a strong network of independent dealers. As time passed, Ford discovered that specialized firms could perform most essential work as well as or better than his own bureaucracy. In fact, these specialists often outperformed Ford’s own units with respect to quality and cost. Entrepreneurial firms soon became contributors to Ford’s network. Over time, the Ford strategy shifted from ownership-based control to one of orchestrating channel relationships. The financial resources at Ford were shifted to developing and maintaining core manufacturing competencies. Ford found out that in the final analysis, no firm can be self sufficient.” Source: (Bowersox & Closs, 1996)
Developments in ICT such as the WWW, EDI, email can be seen as enablers that allow organizations to cross organizational boundaries more easily when dealing with information intensive processes (Hengst & Sol, 2002). Outsourcing of secondary activities is another business trend that thrives on inter-organizational relationships. Organizations outsource their secondary activities and focus on their core competencies to reduce costs (Siems & Ratner, 2003). Globalization is another business trend that has increased inter-organizational relationships (Elg & Johansson, 2001). Trade agreements have resulted in a worldwide market in which organizations must compete. Hence, organizations form relationships with other organizations to bring together their core competencies to create the “best of all” products or services. Coordinating and creating relationships is important for any organization that wants to gain a competitive advantage (Cummings, 1980).
In response to global competition, deregulated markets, increased customer selectivity on price, quality and service, environment protection issues and rapid technological development, many companies are restructuring their organizations to become more flexible and dynamic (Hammer & Champy, 1993). This has resulted in inter-organizational coordination and collaboration, which in turn has led to an increased interest in networks (Nohria & Eccles, 1992; Wilkes, 2002). Nohria and Eccles (1992) explain it as follows:
“If the old model of organization was the large hierarchical firm, the model of organization that is considered characteristic of the New Competition is a network of lateral and horizontal interlinkages within and among firms.”
Vertical functional stovepipes 1980's and earlier Horizontal process tunnels 1980's-90's Businessnetworks
Figure 1-1: Evolving forms of business (Wilkes, 2002)
In the past, organizational performance was focussed on the independent vertical departmental functional tasks, and later, the focus shifted to processes across departments and functions (Hammer, 1990). Today’s organizations, however, focus on their primary competencies and outsource secondary activities to focused providers in the quest for higher performance (Tapscott, 1999). The virtues of business networks are clear: innovation and efficiency. Baker (1990) defines business networks as organizations integrated across formal groups, created by vertical, horizontal, and spatial differentiation for any type of relation (see Figure 1-1).
Recent technological developments, specifically the integration of information and telecommunication technologies, have enabled an entirely new set of more disaggregated, distributed, and flexible production arrangements, as well as new ways for organizations to organize their internal operations and their transactional ties to other organizations in the network. Information technology seems to strengthen the ongoing development of business networks by providing the necessary technological infrastructure to build networks and by reducing coordination costs (Akselsen, Evjemo, Kassah, Nordhus, & Ytterstad, 1997; Liere, Hagdorn, Hoogeweegen, & Vervest, 2004). Supported by information and communication technologies, organizations can now coordinate and maintain more links with more partners, with much lower costs, than was possible before the advent of ICT (Brown, Durchslag, & Hagel, 2002; Butler et al., 1997).
According to Akselsen et al. (1997) organizations that work in business network face a number of challenges within the areas of coordination and orchestration, control and collaboration, customer satisfaction, quality of service and product, relationships to partners and thrust. These challenges arise in particular for business networks because of the many, and shifting, actors involved which may be geographically and organizationally dispersed (Akselsen et al., 1997).
In this research, we focus on the process orchestration challenges that business networks currently face. We define business process orchestration as a process-driven method used to coordinate and manage internal and external business services (Theilken, 2002). Orchestration
is a coordination mechanism in the context of services and service orientation (see chapter 3 for details). In the next sections, process orchestration and their challenges in business networks are described from an information systems perspective, using real-life examples.
1.2 Process orchestration in business networks
In the network economy, organizations focus on their core competences and outsource the rest to facilitate innovation and efficiency (Brown et al., 2002; Siems & Ratner, 2003). The way to outsource for most organizations seem to be through tightly managing, across corporate boundaries, the process of producing and delivering products or services (Hacki & Lighton, 2001). Most organizations hold fast to a strong managerial preference for controlling their activities tightly. However, results show that such a tightly managed processes has trade-offs (Brown et al., 2002). Brown et al. (2002) state that tightly coupled processes are often inflexible and can have huge negative impacts. For instance, problems with key suppliers, say a fire at a supplier’s plant that forces unanticipated delays in the shipping of products, can be damaging. Such a tightly coupled processes cannot cope with the agility of the current business and customer requirements (Brown et al., 2002). Changing tightly coupled processes to adapt to new requirements is challenging. Changing processes that stretch across many organizations can be difficult and entail a considerable amount of time and cost. In 2001, Hacki et al. argued in The McKinsey Quarterly that loosely coupled processes are the building blocks of networked organizations (Hacki & Lighton, 2001). Managing loosely coupled processes in business network permits organizations to gain flexibility, including the ability to make operational changes quickly and to shape customer offerings. The business network of Li & Fung is an example of such a network with loosely coupled process orchestration (see Table 1-2).
Table 1-2: Li & Fung business network
Li & Fung is a Hong Kong based company that is involved in a supply chain network consisting of 6,000 specialized companies, in 39 countries. It orchestrates the production of goods by others, drawing on a vast global network of highly focused providers to arrange for private-label manufacturing, primarily on behalf of European and US clothiers. For a specific product or client, Li & Fung assembles a customized set of specialized providers to handle everything from product development to the sourcing of raw materials, production planning and management, and, eventually, shipping. If glitches pop up at any stage of the intricate process along the network, the company quickly shifts an activity from one provider to another. To produce a line of garments for a customer, Li & Fung might purchase South Korean yarn that would be woven and dyed in Taiwan, the fabric might be sent to be cut in Bangladesh, and the cut pieces shipped for final assembly to Thailand, where the garments might be matched with Japanese zippers, and, finally, the finished garments will be delivered to geographically dispersed retailers in quantities and time frames specified well in advance. Having a wide network, and thus more options, provides considerable flexibility. To meet the specific needs of a customer or even a product, Li & Fung can configure activities like modules in a process. The South Korean yarn provider may be appropriate for one product line, but an Indonesian supplier that uses different raw materials or a different production technology may be the better choice for another. A product may require three additional steps in the supply chain or two fewer steps. Li & Fung assembles the right modules for each job and coordinate with the partners. Source: (Brown et al., 2002)
This type of flexibility promotes high-output performance. Instead of tightly coupling its inter-organizational process with its many partners, Li& Fung gained efficiency through loosely coupled process orchestration among its specialized suppliers. According to Brown et al. (2002), Li & Fung’s return on equity has exceeded 30 percent a year since the mid-1990’s: 2001 revenues amounted to just over $1 million per employee.
1.3 Process orchestration challenges in business networks
The Li & Fung network example discussed in the previous section shows how a process orchestration, which is based on service-oriented paradigm, can help to facilitate agile processes and reduce IT costs. However, as we will show below, designing and maintain processes orchestration in the current and emerging forms of networked organizations is challenging. Partly the challenge is due to B2B e-commerce issues such as scalability, volatility (dynamism), autonomy, heterogeneity of applications (Medjahed, Benatallah, Bouguettaya, Ngu, & Elmagarmid, 2003). In this section, we discuss the major information system challenges that exist when orchestrating operations and processes among numerous organizations in the network.
We illustrate the challenges by using a Cisco business network real life example. The example was chosen because the business network is integrated across formal groups, created by vertical, horizontal, and spatial differentiation for any type of relations (Shah, 2002). The Cisco business network consists of many partners with complex process orchestrations. The situation is described below, in the text box.
Table 1-3: Cisco business network
Cisco conducts business with a huge network of partners for the many products and services it offers to its clients. To satisfy customer orders, Cisco executes 15 million inter-enterprise process instances per month (Chehadi, 2004). According to Yashpaul Dorga, Cisco’s program manager for global manufacturing b2b services, the biggest issue for Cisco stemmed from integrating information and business processes across multiple partners, a trouble spot for many high-tech companies developing next-generation e-commerce and supply chain practices (Shah, 2002). On the data side, a lack of consistent part numbers posed a problem for Cisco's eHub, which relies on a steady stream of accurate data for decision-making capabilities, according to Dogra. The same idea applies to the process side, he said, citing the many different ways companies generate purchase orders or handle invoicing. "If the information is not accurate or updated, it's not going to work in a hub," said Al Delattre, a partner at Accenture Ltd., a consulting firm based in El Segundo, Calif. "Before you can conduct a symphony orchestra, you have to give everyone the sheet music."
The key issues observed in the Cisco business network were the following: information delays and distortion between levels in the supply chain; planning activities not synchronized and closed looped; high levels of forecast variability; lack of visibility to exception conditions; and no inter-enterprise process optimization (Chehadi, 2004). The impact of these events led to shortage of parts, long lead times, a lower than acceptable percentage of on-time shipments and frequent expediting (Shah, 2002).
The example given above reveals typical process orchestration issues in business networks. It shows why process orchestration in business networks is difficult. The reason for increased difficulty in orchestrating processes efficiently and effectively can be attributed to the following constraints.
• The numerous business networks that currently exist have inherent dynamic and complex characteristics. They are dynamic because the number and type of partners involved change to adapt to the changing customer and business needs. The orchestration among the partners can become complex depending on the type and duration of the interaction.
• The inter-organizational processes involved in the orchestration generally are large in number and are related in a complex manner. This creates difficulties for improving and optimizing inter-organizational process orchestration.
• Organizations involved in business networks are autonomous and are reluctant to be fully transparent to their partners as this may reveal confidential resources and knowledge. There is no total visibility of processes in networks. Unless there are special circumstances, e.g. long-term contracts, organizations are not willing to share core processes. Improving overall process orchestration can be difficult if there is not enough transparency.
• Processes in organization have to be flexible enough to adapt to environmental changes, i.e. changes due to new product developments, the introduction of a new strategy or a new tactic. Again, inter-organizational process orchestration can be challenging as the processes in each organization in the network keep on changing to adapt to new requirements. Because of the issues mentioned above, it is challenging to define and manage internal and external business processes, to increase operational efficiency, to improve responsiveness to customers and to enable adaptability to change.
Organizations have to understand and improve their process orchestration continuously to adapt to the changing business and customer requirements. However, improving and changing process orchestration to meet new requirements becomes hard given the constraints mentioned above: complex process orchestration, dynamic process orchestration, actors’ reluctance in sharing information, limited visibility of process orchestration in the network, and difference in interests and goals among the actors. These constraints increase the challenge and make it difficult to orchestrate inter-organizational processes efficiently and effectively. Ineffective and inefficient process orchestrations in the network leads to inordinate waiting times for multi-step processes, a lack of synchronization in material movements, limited coordination and cooperation and an excessive control. In addition, as shown in the example, there are information delays and distortion, a high level of forecast variability, and a lack of visibility with respect to exception conditions. In supply chains, for instance, such inefficiencies and ineffectiveness lead to shortages of parts, high inventories and production costs, and long lead times.
1.4 Process orchestration enabling technologies
Technologies to enable business-to-business (B2B) interactions in business networks were available for a considerable time before the advent of the Internet. The most widely used and earliest of these technologies is Electronic Data Interchange (EDI) that commonly runs on a dedicated computer network. Later, developments in the software industry have given rise to new technologies for B2B process interaction: component middleware and workflow. Currently there is a new trend to use XML-based technologies and frameworks to orchestrate processes at organizational and inter-organizational level.
Medjahed et al. (2003) distinguish the interaction of applications in B2B into three layers:
communication, content and business process layers. Interaction at the communication level deals
with protocols for exchanging messages among applications. Java RMI, MQSeries, HTTP, and SOAP are some of the typical protocols. Languages and models used to describe and organize information are dealt with at the content layer. The semantic issues of the document, and the type of business documents used for exchange, i.e. during the orchestration, are looked at in this layer. Partners in business network need to “understand” the content of messages exchanged with others. Some frameworks used for the content layer are the xCBL, cXML, UBL, RDF, and EDIFACT’s standards. Finally the business process layer is concerned with the conversational interactions i.e., joint business process agreements, e.g. delivery mode, contracts, among services. What actions are allowed and what responses are expected are the kind of questions that are raised at this level of interaction (Medjahed et al., 2003). Medjahed further identifies seven major requirements for interaction of applications in business networks.
1: coupling among partners: different degree of tightness of integration and duration in networks depending on relationship type.
2: heterogeneity: differences in hardware, software, structure, at business process layer, and data with the business network.
3: autonomy: degree of compliance of a partner to the global control rules.
4: external manageability: refers to the degree of external visibility and manageability of partners’ processes.
5: adaptability: the degree to which processes are able to be adapted to meet changes in an environment with dynamic orchestration.
6: security: the degree to which transactions can be executed securely.
7: scalability: the ability of the interaction infrastructure to be extended due to growth in volume of data, transaction or products.
There are many different type of interaction technologies and frameworks available ranging from interaction at the communication level to interaction at the process level. However, not all of them are considered to be orchestration technologies and frameworks; only those that address all three levels i.e. communication, content, and process, are considered to be orchestration technologies and/or frameworks. Below we discuss some of the main orchestration technologies and frameworks that are available.
1.4.1 Electronic Data Interchange (EDI)
EDI is commonly defined as inter-organizational application-to-application transfer of business documents, e.g. a purchase order, between computers in a compact form (UnitedNations, 2003). Hansen and Hill (1989) explain EDI as “the movement of business documents electronically between or within organizations in a structured, machine-retrievable, data format that permits data to be transferred, without rekeying, from a business application in one location to a business application in another location”. EDI focuses mostly on the communication and content layers. It uses a VAN for routing messages and it provides a homogeneous solution for content interoperability (Medjahed et al., 2003). EDI documents are structured according to a standard, e.g. ANSI X12 and UN/EDIFACT (UnitedNations, 2003). EDI has little flexibility to expand the set of supported document types and the cost of implementing it is high. However, it is one of the most secure technologies in use today for B2B interaction. Over time, new Internet based EDI initiatives have been developed that address some of the earlier EDI shortcomings. For instance, EDI standards have been mapped to XML documents (XML/EDI) and are routed by Internet thereby reducing the need for investment in communication software. EDIINT (Electronic Data Interchange – Internet Integration) uses the Internet as a communication medium instead of VANs.
1.4.2 Workflow
Workflow technology, e.g. Staffware, COSA, SAP/R3, deals with production workflows by automating orchestration mainly at an intra-organizational level (Georgakopoulos, Hornick, & Sheth, 1995). It circulates tasks among workers, or, more specifically, worker roles such as a clerk or a manager. A worker does the designated share of the work and forwards the task, through the workflow management system, to the next worker or a group of workers to be processed further. A workflow is thus a collection of interrelated tasks (Georgakopoulos et al., 1995). Workflow products enable us to define a workflow as a type and to instantiate it for each concrete work case, they provide the support for task routing and monitoring: beginning and ending conditions for tasks, deadlines for task finishing, giving an alarm signal if a task is not finished in time, exception handling and so on.
Current efforts, e.g. the Business Process Management Initiative BPMI.org, promise to deliver the next generation workflow systems, inter-enterprise workflow systems (IEWSs) that have the ability to thread together cross-organizational business process, supporting the integration of diverse users, applications and systems (Yang & Papazoglou, 2000). IEWS focus mainly on orchestration at the business process layer (Medjahed et al., 2003).
1.4.4 XML-based frameworks and technologies
A large number of contemporary process orchestration frameworks and standards for business networks are based on XML, an emerging standard for data representation and exchange on the Internet (Medjahed et al., 2003). They are aimed at overcoming some of the limitations of EDI standards, e.g. the high cost of setting up a VAN infrastructure. The vision behind this various XML frameworks is to allow the use of services on the Internet without the need for dedicated transformation and mediation facilities or custom integration of partner’s systems.
The following are some XML-based frameworks and technology initiatives that exist for process orchestration:
• eCO framework: provides means for businesses to discovery and access services regardless of the e-commerce standards and protocols each potential partner adopts. At the content level, eCO introduces xCBL, XML Common Business Library, to define business documents (‘content’) and the interfaces of processes. xCBL is a set of XML building blocks and a document framework that allows the creation of robust, reusable, XML documents for e-commerce. At the business process level, eCO uses BID (Business Interface Definition) to describe XML business services in terms of the documents exchanged. BID does not mandate a global business process definition (Medjahed et al., 2003).
• BizTalk: approaches the orchestration issue by leveraging standards and technologies like SOAP (Simple Object Access Protocol), XML, and MIME (Multipurpose Internet Mail Extensions). It relies on a centralized schema repository to publish and validate XML-based schemas. The architecture of the biztalk consists of three layers: application, BizTalk Framework Compliant (BFC) server, and transport. Applications communicate by sending business documents through BFC servers (one per end). BFC servers send BizTalk messages to each other via multiple communication protocols (HTTP, SMTP, MSMQ).
• cXML: is an XML-based schema language and protocol for consistent communication of business documents between procurement applications, e-commerce hubs and suppliers. At the communication layer, it supports request-response and one-way message exchange. At the content layer, it defines XML DTDs to describe procurement documents the same way as xCBL.
• RosettaNet: aims at standardizing product descriptions and business processes in information technology supply chain applications. It consist of the RosettaNet Business Dictionary (RBD), RosettaNet Technical Dictionary (RTD), RosettaNet Implementation Framework (RIF), and RosettaNet Partner Interface Protocol (PIP). Common Internet transport protocols are supported at the communication layer. RosettaNet uses an XML-based schema as document content model at the content layer. At the business process layer, RosettaNet focuses on providing a common basis for business network interaction via PIPs.
• ebXML: aims at defining a set of specifications for enabling B2B interactions among companies of any size. The basic part of the ebXML infrastructure is the repository. At the communication layer, businesses exchange messages through the messaging service which does not rely on a specific protocol. At the content layer, interaction is done through business documents, i.e. core, domain, and business information components. At the business process layer, ebXML defines business process specification schema in UML and XML.
• Web service: allows applications to communicate in a platform- and programming language-independent manner using standardized XML messages. At the communication layer, it is based on document based (SOAP) communication instead of object based. At the content layer, a Web service uses an XML-based description language called WSDL (Web Service Description Language) to define the interface of
a Web service. At the business process layer, many proposed standards are used: BPEL4WS, BPML, XLANG, WSCI, WSCL, WSFL and DAML-S.
We have discussed a number of technologies and frameworks that enable inter-organizational information exchange or process orchestration. In this dissertation, we focus on Web service technology for process orchestration as a state-of-art technology that can be used to support service- oriented architecture.
1.5 Simulation based inquiry systems
In the previous sections we discussed several issues and challenges for orchestrating processes in business networks. In this section, we discuss a simulation based inquiry system that can be used to solve the inefficiency and ineffectiveness problems of process orchestration in business networks. Emphasis is given to a discrete-event simulation through out the rest of the dissertation.
Discrete-event simulation models are contrasted with other types of models, such as mathematical models, descriptive models, statistical models, and input-output models (Banks, 1998). Banks (1998) state that a discrete-event simulation model attempts to represent the components of a system and their interaction to such an extent that the objectives of the study are met. Most mathematical, statistical, and input-output models represent a system’s inputs and outputs explicitly but represent the internals of the model with mathematical or statistical relationships. In addition, discrete-event simulation models include a detailed representation of the actual internals (Banks, 1998).
Discrete-event simulation models are dynamic and the passage of time plays a crucial role. Most mathematical and statistical models are static in that they represent a system at a fixed point in time (Banks, 1998).
In addition, mathematical and statistical models adopt optimization of one or more variables as the main goal (Boyson, Harrington, & Corsi, 2004). The validity of such theoretical models may be questionable, as process orchestrations in business networks almost never behave as assumed in the ideal model cases.
The input data for the parameters in the model may also vary in time, i.e. it may be stochastic by nature. Many orchestration variables and parameters in real life vary from time to time, and such stochastic information is difficult to incorporate in optimization models. The difficulty increases with the complexity of the models and the presence of uncertain or missing information (Boyson et al., 2004). The more uncertain or stochastic variables there are, the more difficult it is to come up with an optimized configuration or solution.
Simulation models, i.e. discrete-event simulation models, can provide organizations with dynamic insights into a complex orchestration, and it is a powerful methodology for business process modeling (BPM) (Bhaskar et al., 1994; Swami, 1995; Tumay, 1995). Greasley (2003) shows that simulating process orchestration can capture the dynamic behavior of processes in two aspects: variability, and interdependence. In contrast to optimization models or systems
differential equations, simulation is well suited to handle the stochastic and time-varying nature of processes and the non-linear interaction between process elements (Bhaskar et al., 1994). Simulation also allows for a quick implementation of adjustments in the modeled system, making it possible to analyze different alternative solutions in a relatively short time.
Shannon (1975) defines simulation as the process of designing a model of a concrete system and conducting experiments with this model to understand the behavior of a concrete system and/or to evaluate various strategies for the operation of the system. According to Sol (1982), simulation is an effective method of inquiry for organizational decision-making. Sol states a simulation based inquiry system is able to address the following organizational decision-making requirements:
• the possibility to emphasize the activity of conceptualization by presenting freedom for the construction of a base model
• the possibility to construct a model system in view of the availability and attainability of data, and to place it in an experimental frame
• the possibility to generate alternative solutions and analyze these in comparison with the initial specification
Sol (1982) argues that a simulation based inquiry system guided by the paradigm of bounded rationality, presents instruments for:
• the creation of evidence in a data-void environment, by generating data not previously available, or by generating data that reflect different alternatives to reach a decision
• the generation of action alternatives in relation to the existing situation as a frame of reference
Several researchers in the simulation field proposed a set of general guidelines and high-level steps to guide a simulation modeler and builder (Banks, 1998; Banks, Carson, & Nelson, 1996; Law & Kelton, 1991; Pegden, Shannon, & Sadowski, 1995). Even though different steps are proposed, they are all similar and all authors propose the following common steps: conceptualization, specification, verification & validation, experimentation and solution finding. Conceptualization is the first step in the simulation and modeling process, after setting out a clear problem formulation and objectives. This step results in a conceptual model that describes the problem and relevant variables. Specification is the next step in the simulation and modeling processes, and it results in a working simulation model. The relevant objects, processes, and variables identified in the conceptualization phase are now detailed and implemented in a simulation language. Analysis of the relevant data is also done in this step. After achieving a working simulation model, the next step is to make sure that it is coded correctly and represents the problem considered. This step is called verification and validation. The final step in the simulation study is experimentation and solution finding. In this step, appropriate scenarios are designed and experiments are carried out to identify problems and solutions to the problems. These processes define the steps that are needed to conduct a thorough and sound simulation study (Banks, 1998).
1.6 Research objective and questions
In section 1.3 we discussed that many business networks we see today have the following inherent characteristics: dynamic and complex process orchestration, autonomous partners that are reluctant to share internal process information, limited visibility of end-to-end process orchestration across the network, and partners with different interest. These characteristics give rise to challenges with respect to understanding, improving, and adapting process orchestration. Inefficiencies and ineffectiveness in the process orchestration can lead to high costs and long lead-time. In section 1.4 we discussed enabling technologies for B2B interaction, and highlighted frameworks and technologies for process orchestration. However, the complexity of the situation remains the same. Integration and process orchestration technologies will not help when analyzing processes, i.e. finding bottlenecks in the inter-organizational processes and finding solutions to the bottlenecks.
In section 1.5 we stated that simulation is an effective inquiry system that can be used to find bottlenecks in inter-organizational processes and to experiment with different alternatives to find the right solution (Sol, 1982). Numerous research projects have indicated that simulation can be used to analyze the dynamic behavior of systems and to come up with alternative solutions to the problems identified (Babeliowsky, 1997; Banks, 1998; Bhaskar et al., 1994; Dur, 1992; Eijck, 1996; Giaglis, Paul, & Doukidis, 1996; Greasley, 2003; Hengst & Vreede, 2004; Hlupic & Robinson, 1998; Janssen, 2001; Jones, Elliott, Ball, & Hein, 1993; van Meel, 1994; Melao & Pidd, 2003; Pidd, 1992; Sol, 1992; Valentin & Verbraeck, 2002; Vreede, 1995; Wierda, 1991).
We focus our research in using simulation based inquiry systems to support the process of improving inter-organizational process orchestration in business networks. In section 1.3 we discussed the idea that improving the efficiency and effectiveness of inter-organizational process orchestration can help address issues such as long lead times, high inventories and production costs in business networks. It is our aim to support the process of improving efficiency and reliability aspects of process orchestration by developing a simulation based support environment. The efficiency and reliability of process orchestration can be measured and improved in many ways, and there is a need to focus on operational metrics. Based on the challenges we discussed in section 1.3, we focus on two specific operationalized metrics, i.e. efficiency in terms of time, and reliability, both being necessary to improve inter-organizational process orchestration. Efficiency, which is defined as ‘the resources expended in relation to the accuracy and completeness with which users achieve goals’ (ISO 9241-11), is measured in terms of time. Order cycle time, service time, and queue time as some examples. Reliability, which is defined as ‘the ability of a system or component to perform its required functions under stated conditions for a specified period of time’ (IEEE, 1990), is measured in terms of the number of completed process orchestration instances in a specified period of time. Reliability takes into account at the effect of a resource, e.g. a service, failure on the overall inter-organizational process orchestration.
Therefore, we formulate our central research objective as:
“Develop a simulation based support environment that can be used to support the process of improving the
efficiency and reliability of process orchestration in business networks”
The output of the research is a simulation based support environment that consists of a methodology or ‘recipe’ and a supporting software library. The societal relevance of the research becomes clear when looking at the role of efficient and reliable inter-organizational process orchestration in providing opportunities to decrease costs and increase overall service quality, and thereby create a potential source of competitive advantage (Theilken, 2002). The support environment is intended to help decision makers understand the dynamic behavior of their inter-organizational process orchestration, estimate the effects and consequences of their decision to change or modify the way processes are orchestrated, and to evaluate the efficiency and reliability of newly designed orchestration scenario to ensure desired level of service quality.
To demonstrate the visible social relevance of the research clearly, we focus on the context in which process orchestration is carried out to support service-oriented architecture. In section 1.2 we stated that Li & Fung was able continually to relocate work among its service providers based on recent performance trends using the opportunities created by a service-oriented architecture and loosely coupled business processes (Hagel, 2002). One of the ways to achieve such flexibility and efficiency using loosely coupled processes is to adopt a service-oriented architecture for orchestrating processes (Hagel, 2002). Hagel (2002) states that loosely coupled processes provide much more flexibility than traditional, enterprise-centric business processes, allowing organizations to benefit from the flexibility offered by a service-oriented architecture and Web service technology. Loosely coupled processes, through Web service technology, are more suitable for coordinating activity across enterprises, enabling each enterprise to leverage more effectively the resources of other enterprises (Hagel, 2002). The service-oriented paradigm and service-oriented architecture (SOA) enable managing and orchestrating loosely coupled processes located across the network (see Chapter 4 for details on service orientation). Service-oriented architecture and service orientation are geared to address cost and adaptability issues by providing architectural solutions for enterprises and their IT support (Steen, Lankhorst, ter Doest, & Iacob, 2004). Papazoglou and Georgakopoulos (2003) define service orientation as a computing paradigm that utilizes services as fundamental elements for developing applications. At its most abstract, a service orientation views everything, from the mainframe application to the printer to the shipping dock clerk to the overnight delivery company, as a service provider (Microsoft, 2004). Service providers expose capabilities through interfaces. A service-oriented architecture is used to map these capabilities and interfaces so that they can be orchestrated into processes (Microsoft, 2004). The separation between the interface and the implementation is fundamental to the service model (Papazoglou & Georgakopoulos, 2003). Web service, a technology that implement service-oriented architecture, provides a fast and cheap means to integrate and orchestrate processes. Because of the fact that service-oriented architecture satisfy the apparent inter-organizational process orchestration need we identified, and because it is also the state-of-the-art architecture to use, we make a choice to focus on service-oriented architecture as the basis for inter-organizational
process orchestration in this research. In addition, we focus on orchestration of business processes that are routinized, automated, and well known. The Cisco business network, described in section 1.3, is a good example where inefficiencies and ineffectiveness of the routinized and well-known processes significantly affect the overall performance of the orchestration.
The scientific contribution comes from the results of our research project, which should result in a simulation based methodology that can be used to support the process of improving efficiency and reliability of inter-organizational process orchestration in business networks. The methodology should take into account the following situations: organizations in business network are reluctant to share information, there is limited visibility for end-to-end process orchestration, complex and dynamic process orchestration, and there are differences in interests and goals among the organizations.
To help us develop such an environment, we formulated several key research questions. The first research question was intended to help us obtain a detailed understanding of the problems, issues, and challenges of process orchestration in business networks. An answer to this question will provide us with deep insight into the problem domain.
“What are the current and emerging issues in orchestrating processes in business networks?”
This first research question is answered partially in the first chapter and is further elaborated in chapter two. The second research question was aimed at gaining insight into relevant mechanisms that can be used for the purpose of process orchestration in business networks.
“What orchestration mechanisms can be used to orchestrate processes in current business networks?”
We discuss a number of mechanisms in chapter three, and focus service orientation and service-oriented architecture as the way forward for process orchestration in current business networks. After gaining an understanding the challenges and the mechanisms used for process orchestration in business networks, the third issue addressed in the research was ways to improve process orchestration using a simulation method of inquiry. Therefore, the third and main research question that was considered in the research was
“How can we support the process of improving process orchestration in business networks using a simulation based inquiry system?”
This research question directed the researcher towards developing a new simulation and modeling support environment. The support environment, which consists of a methodology and its supporting software library, is described in detail in chapters four and five.
1.7 Research methodology
We present the research methodology used to address the research questions in three dimensions: research philosophy, research strategy and research instruments. A research methodology should describe a certain research strategy, in which a set of research instruments are
employed to collect and analyze data on the phenomenon studied, guided by a certain research
philosophy. We describe below the research philosophy, strategy, and instruments used in the
research presented in this thesis.
1.7.1 Research philosophy
A research philosophy consists of the ontological, epistemological, and axiological assumptions made by a researcher pursuing an intellectual endeavor (Gregg, Kulkarni, & Vinze, 2001). Ontology describes the nature of reality, e.g. what is real and what is not (Vaishnavi & Kuechler, 2004/5). Epistemology explores the nature of knowledge to determine what kind of knowledge can be obtained and what are the limits to that knowledge. Axiology deals with values (Vaishnavi & Kuechler, 2004/5).
Two major research perspectives are used to study organizational phenomena: positivism and interpretivism (Galliers, 1992). Positivists claim that reality can be observed and described objectively without interfering with the phenomenon being studied. They pursue scientific progress through the repeatability of a phenomenon observed. A positivist adopts a realism ontology i.e. they postulate that the universe comprises objectively given, immutable objects and structures existing as empirical entities, on their own, independent of the observer’s appreciation of them (Hirschheim, 1992). Interpretivists claim that reality can only be understood by subjectively interpreting observations of reality. Multiple interpretations of reality are possible. Interpretivists adopt a relativism ontology that states that reality is a subjective construction of the mind; socially transmitted concepts and names direct how reality is perceived and structured (Gregg et al., 2001). Reality therefore varies with different observers, languages and cultures.
Design science is yet another “lens” or perspective that can be used to perform research into information systems and organizational phenomena (Glass, 1999; March & Smith, 1995; Winograd, 1996): it complements the positivist and interpretive perspective. Vaishnavi and Kuechler (2004/5) define design science as a research perspective that involves the analysis of the use and performance of designed artifacts to understand, explain and, very frequently, to improve on the behavior of aspects of information systems. Similar to the posivitist and interpretivist research perspectives, the design science research perspective has been shown to produce scientific knowledge (March & Smith, 1995; Simon, 1996; Vaishnavi & Kuechler, 2004/5). All or part of a phenomenon may be created as opposed to naturally occurring. Simon (1996) calls it science of the artificial, i.e. a body of knowledge about artificial (man made) objects and phenomena designed to meet certain desired goals.
An ontological, design science perspective by definition changes the state-of-the-world through the introduction of novel artifacts (Vaishnavi & Kuechler, 2004/5). In contrast to positivistism, even the problem statement is subject to revision as a design science research effort proceeds (March & Smith, 1995). Epistemologically, design science strives to create innovative and valuable artifacts. Whereas a positivist tries to understand reality, a researcher using design science attempts to create things that serve human purpose (March & Smith, 1995). Axiologically, design science is value-oriented. Design researchers believe that the proverbial ‘truth’ is not ‘out there’: instead they facilitate its enactment by creating artifacts
(Orlikowski & Iacono, 2000; Purao, 2002). Its outputs are assessed against criteria of value or utility (March & Smith, 1995). The basic tenets of positivist, interpretivist and design science research perspectives are summarized in Table 1-4.
Table 1-4: Research perspective (Gregg et al., 2001; Vaishnavi & Kuechler, 2004/5)
Basic Belief Positivist Interpretive Design science
Ontology A single reality. Knowable, probabilistic
Multiple realities, socially constructed
Multiple, contextually situated alternative world-states. Socio-technologically enabled Epistemology Objective; dispassionate. Detached observer of truth Subjective, i.e. values and knowledge emerge from the researcher-participant
interaction
Knowledge through making: objectively constrained construction within a context. Iterative circumscription reveals meaning. Methodology Observation; quantitative, statistical Participation; qualitative. Hermeneutical, dialectical. Developmental. Measure artifactual impacts on the composite system Axiology: what
is of value
Truth: universal and beautiful; prediction Understanding: situated and description Control; creation; progress (improvement); understanding
The choice of a research perspective should be based on the research objective rather than the research topic (March & Smith, 1995). In section 1.6 we stated that the objective of the research was to develop a simulation based support environment that could be used to improve the process of improving process orchestration in business networks. Ontologically, the problems and challenges that we identified related to process orchestration in business networks will be subject to revision as the research proceeds and more knowledge is obtained. We will address our objective (epistemology) by constructing a support environment, i.e. artifact. We can obtain more knowledge about process orchestration by studying the behavior of the support environment in the context of process orchestration. Thus, knowledge is obtained through making artifacts, a process that is iterative in nature. Moreover, the goal of the research is to improve the efficiency and reliability of process orchestration in business networks. The keyword is “improve” which is value-oriented (March & Smith, 1995). Thus the choice was made to use the design science philosophical perspective for the research presented in this thesis.
1.7.2 Research strategy
A research strategy outlines the steps to be taken in a scientific inquiry to reach the research objective. In a recent MIS Quarterly journal, Hevner et al. (2004) discuss the design science research strategy in relation to positivist behavioral science research strategy. Hevner et al. (2004) argue that the two paradigms are complementary in nature. With the behavioral science
paradigm, which has its roots in natural science, its users seek to develop and verify theories, i.e. principles and laws, that explain or predict human or organizational behavior surrounding the analysis, design, implementation, management, and use of information systems (Hevner et al., 2004; March & Smith, 1995). The design science paradigm has its roots in engineering and the sciences of the artificial (Simon, 1996). It is fundamentally a problem-solving paradigm where its users seek to create innovations that define the ideas, practices, technical capabilities, and products through which the analysis, design, implementation, management, and use of information systems can be effectively and efficiently accomplished (Denning, 1997; Hevner et al., 2004). The aim of using the design science paradigm is to extend the boundaries of human and organizational capabilities by creating new and innovative artifacts such as constructs, i.e. vocabulary and symbols, models, i.e. abstraction and representation, methods, i.e. algorithms and practices, and instantiation, i.e. implemented and prototype systems (March & Smith, 1995). Hevner et al. (2004) argue the complementary nature of the two paradigms by stating the development of such artifacts relies on existing knowledge bases and theories that are applied, tested, modified, and extended through the experience, creativity, intuition, and problem solving capabilities of the researcher (Marakas & Elam, 1998). The two paradigms are inseparable and are two sides of the same coin. While the goal of behavioral science is truth, the goal of design science is utility (Hevner et al., 2004).
In this research, we advocate using the design science paradigm to create and evaluate simulation-based support environment (artifact) to solve the process orchestration issues in business networks that we identified and discussed in chapters one and three. The artifacts that are created include a method, and an instantiation that prototypes a type of system solution. However, we followed the behavioral science paradigm at the initial phase to develop a descriptive model and the requirements of the problem situation.
Hevner et al. (2004) argue that the design science research paradigm is used in the information systems discipline to address what are considered to be ill-structured or wicked problems. According to March and Smith (1995) design science research excels at solving ill-structured problems where conflicting theoretical bases exists. Sol (1982) states that ill-structured problems are vague and do not fulfill the following requirements.
• the set of alternative courses of actions or solutions is finite and limited
• the solutions are consistently derived from a model of the problem situation that shows a good correspondence with reality
• the effectiveness or the efficiency of the courses of action can be numerically evaluated
The problem we consider in this research exhibits the characteristics of an ill-structured problem because the alternative courses of actions for providing a solution are unlimited. A great number of alternative solutions can be thought upto improve process orchestration in business networks. In addition, considering the complexity and dynamics of process orchestration in business networks, there is probably no model available with sufficient correspondence from which solutions can be derived in an exact way.
We follow Hevner et al. (2004) guidelines when developing a support environment for improving process orchestration:
• design as an artifact: design science must produce a viable artifact in the form of a construct, a model, a method, or an instantiation
• problem relevance: the solution developed must be for an important and relevant business problems
• design evaluation: the utility, quality, and efficacy of a design artifact must be demonstrated using evaluation methods
• research contributions: the contribution must be verifiable in the areas of design foundations, and /or design methodologies
• research rigor: the research must rely upon the application of rigorous methods in both the construction and evaluation of the design artifact
• design as a search: the search for an effective artifact requires utilizing available means to reach desired ends while satisfying laws in the problem environment
•
communication of research: the contribution must be presented effectively both to technology-oriented and management-oriented audiences1.7.3 Research instruments
Research instruments are used to describe the way the data is collected and analyzed, i.e. the way the research steps are carried out. A number of research instruments are used in the field of information systems: case study, field experiment, laboratory experiment, survey, simulation, action research, and a few others (Galliers, 1992). The selection of research instruments, e.g. a case study or a laboratory experiment, depends on the amount of existing theory available, on the nature of the research, i.e. the problem type, on the aspects of the research objectives, and on the type of research question (March & Smith, 1995; Vaishnavi & Kuechler, 2004/5). In addition, the research strategy used to approach the problem also influences the type of research instruments used (Hevner et al., 2004).
At the initial stage of the research, we used an exploratory case study to understand the business needs, and to identify requirements for the support environment in which we are going to develop in the research. A case study helps us to describe the relationships which exists in reality, usually within an organization or between organizations (Galliers, 1992; Yin, 2003). Designing a support environment that helps the process of improving process orchestration in business networks is complex due to the need for a deep understanding of process orchestration issues. Therefore, we decided to conduct an exploratory case study to identify emerging ideas and gain deep understanding of current issues of process orchestration in business networks. The choice for a case study is often based on opportunism, rather than on rational grounds (Yin, 1989). However, it should be a conscious and formalized step in the design of a research study. The following criteria were used to select the exploratory case study:
• the case should involve a business network consisting of numerous organizations orchestrating processes
• the case study should involve dynamic and complex process orchestration where there is limited visibility of end-to-end processes
