Web service technology enables organizations to open up their business processes and engage in tightly coupled business networks to jointly offer goods and services. This paper systematically investigates all decisions that have to be made in the design of such networks and the processes carried out by its participants. Three areas of different kinds of design decisions are identified: the value modeling area, which addresses economic viability of the network, the collaboration modeling area, which addresses how business partners interact to produce the goods or services identified in the value modeling area, and the workflow modeling area, which addresses the design of internal processes needed for the interactions identified in the collaboration modeling area. We show, by reporting on a real-world case study, that there are significant differences between these areas: design decisions are unique for each area, IT support for collaboration processes is orthogonal to IT support for workflows, and the role of web choreography standards such as BPEL4WS differs for both of them.
Recently, a number of standards have been proposed for machine-readable specification of inter-organizational business processes, such as ebXML BPSS, BPEL, and WSCI. Although these formalisms differ in many respects, they are all based on the same idea: they provide (and only provide) XML-based syntactic constructs to specify valid sequences of web service invocations of some business partners. Thus, these business partners are assumed to work together by invoking each other’s web services. Although a considerable amount of research has been published on these standards, for instance on their fundamental and relative expressiveness, not much is currently known about guidelines for actually designing cross-organizational processes. In this paper, we show that three groups of design decisions must be made before the designer even considers using web services (instead of something else, such as EDI) and before the designer considers using one of the available web service choreography standards. Briefly, these This work is part of the Freeband A-MUSE and FRUX projects. Freeband (http://www. freeband.nl) is sponsored by the Dutch government under contract BSIK 03025. decisions concern the commercial viability of the business activities being coordinated, the coordination mechanisms required to realize these commercial activities, and the workflows for each participating organization to support this coordination. We will argue that a workflow internal to a business, which is private but yet must support an interorganizational coordination process, involves decisions that are absent from purely business-internal workflow design. 2
Before committing considerable resources to creating a collaboration with another organization, an organization usually seeks answers to the following two questions: is the collaboration economically viable (e.g., generating a positive cash flow), and is the collaboration feasible (e.g., does it not overextend organizational and IT support change capabilities). We approach these questions by dividing them in three areas of concern: value modeling (economic viability), coordination modeling (feasibility/impact with respect to relations of organizations with each other), and workflow modeling (feasibility/impact with respect to internal structure and processes). For each area of concern, we identify a number of design decisions, which are presented in Table 1. In the next sections, for each area of concern we discuss these issues and illustrate them using a case study. 3
In the value modeling area, we address the enterprises and final customers that
participate in a collaboration. As such, the value model presents who is offering what of
economic value to whom and expects what in return. The latter refers to the notion of
economic reciprocity; an important notion in commercial trade. In addition, the value
model shows whether valuable objects are offered as a bundle (potentially by different
suppliers) or not. Bundling [
The value modeling design decisions can be represented by an e3-value value model
[
enterprise/end-customers? – What bundles of value objects exist? – What partnerships do exist? Coordination modeling Coordination process design decisions: Workflow modeling – Which information is exchanged between business partners, and in
which order? – What are the trust relations between the actors? – Are additional actors needed to resolve trust issues (e.g., trusted
third parties?) – Who is responsible for the coordination activities at each business
partner? IT support design decisions: – What technology to use (e.g., HTML forms, web services)? – Synchronous or asynchronous information exchange? – What is the format of the message data exchanged? Workflow design decisions are mainly concerned with issues in operations management and organization theory. As an example, we mention the choice between make-to-client-order (goods are manufactured after a client order has been received) or make-to-stock (goods are manufactured in advance, orders are satisfied from stock) processes that always have to be made in the manufacturing industry.
IT support design decisions: – What information systems are needed? – What functions do these information systems need to offer? – Distribution decisions, e.g. central IT facilities or facilities per location interface may cause exchanges via another interface of such an actor (e.g. to buy raw materials to produce the object requested).
We illustrate the cross-organizational design decisions using a case study on portals
for music fans, based on earlier work of one of the authors [
Coordination is the interaction between a number of actors, in this case business partners, needed to produce a result. Coordination is needed because of dependence between the activities of the actors. Therefore, the actors exchange information to keep each other informed on the current state of affairs in their joint effort to produce a result.
We distinguish between on the one hand, coordination process by which business coordinate their behavior in a collaboration (coordination modeling area), and on the other hand, internal processes of each of the businesses participating in a collaboration (workflow modeling area). A coordination process consists only of interactions between two or more parties in the collaboration. These interactions involve externally visible behavior of each of the coordinating businesses. The set of all interactions of one business is called its abstract business process. In general, there will be one or more internal business processes that jointly realize the abstract process of a business. Most of these internal processes will be confidential, as it contains confidential business rules and uses confidential data.
In the value model (Fig. 1), a dependency path shows which value exchanges are needed to satisfy a customer need. A dependency path is not itself a coordination process or workflow. Instead, one or more coordination processes have to be designed to coordinate all activities and information exchange needed to realize the value exchanges connected by a dependency path.
IT support for coordination processes involves supporting information exchange as specified in the coordination processes. This information exchange can take many forms, e.g. web services but also conventional forms of information exchange.
In our case study, information exchange between fanclub members and the portal provider is based on HTML forms, as fanclub members (who are human end consumers) want to interact with the portal directly. The portal software designers have complete freedom in designing these forms. They may also choose to not design these forms themselves, but use a ready-made shopfront offered by a third party. As this is usually not a free service, in this case the value model (Section 3) needs to be adapted and the business case reconsidered. Information exchange with the settlement service is most probably governed by the standard procedures published by the settlement service provider.
While some parts of a coordination process may be supported by technology other other than web services, for other parts web services may be chosen. For these parts, web service choreography specification formalisms such as BPEL4WS can be used to describe them. In fact, a coordination process such as the one depicted in Fig. 2 actually requires two BPEL4WS specifications, one for each business partner. (It is not possible to specify sequences of both partners in one BPEL4WS specification as in BPEL4WS, only a choreography of one partner can be described.) Thus, a complex business collaboration as described by the dependency path that we have focused on in our case results in a number of relatively small web service choreography specifications. 5
Workflows are internal business processes that realize the atomic activities that are
visible in coordination processes. For a large part, design choices in workflow design fall
outside Computer Science as they are in the domains of Organization Theory [
In this paper, we have systematically identified all design decisions that need to be made when designing multi-party collaborations. This revealed a clear distinction between value modeling, coordination modeling and modeling internal workflows. IT support is different for each of the latter two, as is the role of web service technology and choreography standards. For each type of modeling, we have shown examples (using our case study) of modeling techniques such as e3-value and BPMN. These modeling techniques are relatively lightweight while still providing enough insight to support design decisions. Moreover, these techniques are simple enough to be understood by non-technical stakeholders, which is important as design decisions made by software engineers influence design decisions that have to be made by business stakeholders and the other way around.