Business Object Component Workshop

Cross-Organizational Workflow Integration using Contracts

Willem-Jan van den Heuvel and Hans Weigand

INFOLAB, Tilburg University,

PO Box 90153, Tilburg,

5000 LE, The Netherlands

E-Mail: wjheuvel@kub.nl, weigand@kub.nl

ABSTRACT: Enterprises are lining up into virtual enterprises to meet the ever-increasing customer's demands in a more flexible and effective way than ever before. Hence, the business processes as well as supporting workflow systems need to be tightly integrated into streamlined, virtual value chains to shorten delivery-times, minimize coordination costs and improve overall quality.

It is generally recognized that the combination of workflow with business-object component technology provides the required solution. However, today’s widespread business workflow modeling techniques suffer from an object bias, ignoring the most essential coordination vehicle in the enterprise: communication, and the resulting commitments. In this paper, we present contracts that encapsulate (formal) commitments laid down as a set of obligations to coordinate and control the interaction between business workflows. Therefor, we introduce a business contract specification language (XLBC) to formally link the (CDL) specification of business object based workflows systems.

KEYWORDS: workflow integration, contracts, XLBC

1. Introduction

Today's increasingly competitive, expanding global marketplace requires that companies line up into virtual alliances to address rapidly changing market conditions in a more flexible and effective way than ever before. Companies are required to transparently integrate and streamline their business activities to increase their service and shorten delivery times. Value chain integration means more than just doing business over the web: the business processes of several different enterprises need to be seamlessly integrated into more effective and efficient holistic re-engineered business processes.

Emerging technologies, such as business objects, components and XML are generally being perceived as core technologies to successfully deal with these challenges. However, there are several important issues that need to be addressed before these promises become reality:

1. Enterprise (Workflow) Models

Most enterprise and workflow models lack the semantics to concisely represent specific activities, tasks, roles, business processes, business goals, recourses and organization structures of a business. Traditionally, business models are represented by means of data-oriented techniques (e.g., ER-diagrams), and process models (e.g., Petri-nets).

Only recently, industry has recognized the advantages of modeling (virtual) business workflows as collections of self-sustaining business objects that wrap both business processes and business data [ortner99]. Business objects represent a special category of objects with business semantics such as customer, bill and procurement.

However, even modern business-object oriented enterprise modeling techniques are not equipped with constructs to specify virtual enterprises as networks of mutual commitments. They lack mechanisms to adequately represent the (in)formal communicational structures that are utilized to coordinate business workflows [1].

2. Commitments and Contracts

An essential aspect that needs to be taken into account for inter-organizational transactions are mutual commitments that parties are accepting to integrate their business processes. According to our view, contracts are the most natural vehicles to prescribe the coordination between two or more business workflows. Contracts are used to make explicit the (legally binding) commitments that the partners make, and in which future commitments to performs actions are laid down [winograd86].

Business commitments comprise the “glue” that integrates (autonomous) enterprises into virtual alliances. Business commitments are materialized via contracts and mandate the shared goals (intentions) and policies of the virtual enterprise.

Cross-organizational workflow integration on the basis of contracts exemplifies a complex problem for which current workflow management products offer few solutions. Some research has been conducted on workflow integration, e.g., CrossFlow [koetsier99] and [ludwig99], but what is to be included and excluded in these contracts has not yet been extensively investigated.

2. Running Case: Integration of a semiconductor supplier and a PC-assembler

The computer hardware (sub) component industry is under continuous pressure to deliver qualitatively superior products for low prices and short delivery times. To cope with these demanding requirements, many component manufacturers have decided to outsource their construction activities and limit themselves to the composition of computer configurations into various designs tailored towards the demand of individual customers. These requirements do not only require smooth internal business processes, but also demand close partnerships with all suppliers of semiconductors throughout the supply chain.

In this case that is based on a model company described in [keller98], we focus at the business process integration of a PC-manufacturer and a Semi-conductor (“component”) manufacturer.

The procurement logistics of the PC-manufacturer should be tightly coupled to the sales & distribution processes of the (various) subsystem manufacturer(s) to garantuee a non-hampering production and timely delivered products. Procurement logistics is occupied with delivering the required (often planned) materials, e.g., raw materials and semi-finished products as well as services to the production processes in the enterprise. Sales processing is concerned with the other end of the production process, and deals with sales order processing and delivery processing.

In this situation, a customer order from the PC-Manufacturer directly determines the release order date and quantity for the subsystem supplier (e.g., chips, transistor or motherboard).

Figure 1 Semi-Conductor Industry Value Chain Integration

The yearly “umbrella” contract between the supplier and the PC-assembler specifies the planned volumes of sales, the quality of products (waste) and the price (range). E.g., chip AB234 will be procured every two months, at any time with a delivery time of 1 day to the assembler for price $10 (see Figure 1). The contract governs both the procurement process of the Semi-conductor manufacturer[2] and the invoice/payment processes of the PC-Manufacturer.

In addition to the automated order processing, the computer manufacturer is able to check the part stocks at the supplier site. On the other hand, the semi-conductor manufacturer is allowed to look into the material master record of all available configurations the computer manufacturer produces.

Likewise, other manufacturers, such as (mobile) telephone producers and other consumer electronics companies, can define this type of contracts (outline contracts) with semi-conductor (subsystem) manufacturers (see Figure 1).

3. The Integrated Enterprise Architecture

Virtual enterprises constitutes a (temporary) cooperation between two or more companies and is aimed at a certain goal (mostly to deliver more timely and qualitative products and services). Virtual enterprises need to be designed on a architecture to deal with ever-increasingly complex business processes, and cope with change in a more flexible way than before. Moreover, the concept of architecture is an essential feature to accomodate future reuse.

Figure 2 illustrates an integrated value chain enterprise framework for a virtual enterprise that conceptually links two business workflows (see the left and right "towers"). Both workflows and comprising business tasks/objects are formally connected with a contract specification. The integrated enterprise framework provides a basis for the effective encapsulation of business practices, policies, and tactics in modular high-level components.

Figure 2 The Integrated Enterprise Architecture

The specification of the integrated enterprise architecture basically comprises two main steps:

1. Specification of the enterprise model

During this step the enterprise model of a company is represented with a component definition language (CDL) and organized along the layers of the enterprise architecture (see 3.1-3.4).

2. Link business workflows with a contract definition

During the second step, business workflows of individual organizations are conceptually integrated with contract. The contract therefore connects the relevant CDL definitions that have been defined in step 1, and defines mutual obligations and authorizations to coordinate the interaction. We have designed a XML-based contract specification language for this purpose, called XLBC, that will be sketched in section 4.

3.1 Business Objects

Business objects provide a natural way for describing application-independent concepts such as product, release order, supplier, stock and the like (see Figure 3). The business objects play a central role in capturing the semantics of actual business entities and processes, in a way that is understandable by the business [manola98].

Business (entity) objects that reside in this layer essentially contain business data which can be manipulated by their business methods (/services). Business objects can be subdivided in various categories. Common Business Objects (CBOs) are business objects that can be shared across multiple domains, e.g.., a currency business object. They can be specialized to deal with domain-dependent semantics. Furthermore, we discern business objects with common semantics within a vertical domain, also named domain frameworks. The OMG is currently putting much standardization efforts in both categories of objects.

Before we give a CDL example of a business (entity) object Supplier, we present a simplified version of the enterprise model of a IC Manufacturer company (see Figure 3). This lot manufacturer produces standardized ICs that are used in the PC-manufacturer’s products. This enterprise model is structured along the axis of the integrated enterprise modeling architecture and represents a componentShipment workflow that is concerned with delivering lots of ICs according to a predefined contract (the Release_Order_doc contract).

The interface (services) of business objects, as well as the task and workflow objects are textually represented with the Component Definition Language (CDL). CDL is a declarative language to specify the services of collections of business objects, their relations, dynamics, business constraints and attributes.

Figure 3: Enterprise Model of Component Manufacturer (Motherboard) Shipment

Business objects are not written in CDL, but in programming models for which language mappings are available, e.g., Enterprise Java Beans. CDL is a superset of the Interface Definition Language (IDL), the ODMG Object Definition Language (ODL) and the ODMG Object Query Language (OQL). This specification language extends IDL by adding several “high-level” constructs to capture more business semantics. IDL indeed merely defines object methods to implement language-independent distributed objects, which can be plugged in to a broker (ORB) that provides additional services such as security, concurrency and transaction services. The goal of CDL transcends this rather low-level, inter-object communication purpose of IDL, and is oriented towards delivering distributed (business) objects based on the Business Object Facility (BOF), specifying Common Business Objects and delivering marketable business objects by software vendors [bodtf97].

The following CDL excerpt illustrates the supplier business object, associated with the Release_Order_doc business object.

3.2. Business Tasks

A business task is the definition of a set of interrelated activities that collectively accomplish a specific business objective, possibly, according to a set of pre-specified policies. A business task is associated with a role performed by (automated) actors in the domain; actors can execute multiple roles. Business tasks are initiated by events that trigger activities in the organization. They can be internal (e.g., rules) or external (e.g., customer requests). The business process tasks are initiated on the basis of an incoming event (e.g., a customer request), and result in an outgoing event (e.g., the notification that a product is ordered). Business tasks rely on (a collection of) business objects to perform their operations, i.e., they change their states.

Business tasks provide a set of basic building blocks for an application in a specific business domain, e.g., procurement management, general ledger, etc. These building blocks can be specialized and extended to capture domain or application specific processes that are realized at the workflow layer, e.g., on the basis of inheritance or composition.

The following excerpt shows an example of a CDL definition of the business task process_release_order (performed by the SalesEmployee actor) during which the requested quantities of a customer (Manufacturer) are recorded in the Release_Order_doc business objects. This task is performed after the request to release an order from the Manufacturer has been received by the SalesEmployee. Release orders contribute to the agreed upon quantities in the outline agreement: this task “releases” the schedule lines with delivery information in the contract (outline agreement).

3.3 Business Workflows

The workflow layer assigns business tasks to actors according to the state of each process in progress, and, moves the process forward from one role (that performs a business task) to the next. Workflow objects coordinate and control the overall process logic of business tasks. The control of the workflow objects is stored as a set of state transition rules (STRs) that specify the conditions under which the workflow can proceed from one task to the next.

Workflow objects are based on an extensive foundation of reusable components, viz. the core business processes that form the basis for building new applications. Workflow-enabled business processes can track transactions across department and even enterprise boundaries. This type of distributed workflow layer provides the sequence of business activities, arrangement for the delivery of work to the appropriate inter-organizational resources, tracking of the status of business activities and coordination of the flow of information of (inter and intra-) organizational activities.

Workflow activities may invoke components from existing applications, for instance legacy objects, and combine them with newly developed applications. Several of the workflow activities have a transactional nature which requires long running interactions. The requirements of transactional workflows have been described in [schmidt98].

The CDL excerpt show in the above, specifies the componentShipment workflow that handles the delivery process of the IC manufacturer to the PC Manufacturer. The workflow is initiated by an external event init_component_shipment; this event will be linked to the contract (see below).

As explained in the above, the state transition rules lot_shipment and credit_limit specify how the workflow proceeds from one business task, e.g., process_release_order, to the next check_credit_limit.

4. Contracts: The glue to link inter-organizational workflows

Virtual enterprises float upon a network of mutual commitments that have been formally represented in business contracts. Contracts are statements of shared purpose [marshall00] which comprise the mutual obligations and authorizations that reflect the (legally binding) agreements between two, or more, trading partners. These agreements are generally used to specify delivery times, the quality of products, the terms of delivery, the price of the requested items, the business procedures, shared terminology, etc.

In this way, business contracts (and their objectified counterparts) can be applied to couple inter- or intra-organizational business workflows which are defined in term of cooperating business activities and objects in a comprehensive manner.

4.1 The Contract Specification Language: the Formal Language for Business Communication

In this section, we will explain a slightly adapted version of the Formal Language for Business Communication (FLBC) [kimbrough97] to specify business contract(s) between enterprises. FLBC was introduced to provide a representation that offers more expressiveness and flexibility than the conventional EDI standards, such as EDIFACT and ANSI. Our XML-version of this language (XLBC) represents messages as sequences of speech acts that are organized in a layered architecture, see Figure 4, ranging from low-level, communicational building blocks (speech acts) to workflow loops. Each layer is built on top of the lower one.

We assert that the speech act is the most elementary unit within a business transaction. Speech acts define what people do (actions) while communicating ([searle69], [austin62]). They represent a performative act, like a request or a promise, that in itself constitutes an action.

Speech acts usually only have a meaning when they come in pairs; for instance a request that is followed by a commit. We call these pairs of speech acts a transaction. A transaction can be defined more formally as the smallest sequence of speech acts that has an effect in the social world of the participants. These effects can be defined in terms of obligations, authorizations and accomplishments.

As can be seen in this example, the combination of the request of the customer to deliver a product, and the promise of the supplier to actually deliver it, constitutes a deontic effect: the obligation for the supplier to deliver the product, and an obligation of the customer to pay the agreed price.

At yet a higher level, we have defined a workflow loop that bundles various transactions. For instance a typical workflow loop can be built up from an actagenic and factagenic transaction, or conversation. During the actagenic conversation an actor requests something from another actor, which this actor can reject or accept. This leads to a commitment or obligation to keep the promise. The factagenic conversation starts after the executor has performed the transaction, and (s)he has declared that (s)he has created the desired state-of-affairs. The factagenic conversation results in an obligation for the customer to accept the state-of-affairs, if it is conform the conditions of satisfaction. The ActionWorkflow-loop [medina92] is an example of such a workflow loop; and the DEMO approach [dietz96] provides similar loops.

Figure 4: The multi-leveled communication patterns

The workflow loop gives a rather biased perspective of a transaction; the analyst takes the viewpoint of either the buyer or the seller. Since business transactions are in fact exchange processes, we have defined contracts to represent this reciprocity. The contracts can be represented as two interleaving workflow loops: e.g. a customer who requests a product (e.g., a computer manufacturer that orders a batch of ICs), and a supplier who requests money for it in return (e.g., an IC Manufacturer). Depending on the trust between parties engaged in an electronic commerce relationship, they make use of various (implicit) contracts during a business transaction.

Even at a higher level, contracts can be organized in scenarios that are comparable to use cases as they denote a sequence of transactions across different contractual relationships, for example, in a supply- chain.

For a detailed description of this layered formal business communication language we refer to [weigand99].

4.2 Workflow Control and Execution

Cross-organizational workflows should basically comprise the following two essential elements (see Figure 5): an execution workflow and a control workflow.

The execution workflows (also called business workflows) sequence and synchronize the internal business tasks in an organization, or organizational unit. Their interface masks off the internal business processes from the controlling workflow. This is a realistic assumption as partners mostly do not want to loose autonomy in a trading relationship.

Cross-organizational workflows are managed by patterns of deontic control messages as specified in the contract. The workflow control basically comprises two parts: the actagenic phase and the factagenic control phase, that basically encapsulates the “wrapped” execution workflow.

The actagenic control phase initiates an internal workflow execution based on his promise to deliver a service. Then the internal workflow takes over the worfklow control, allocates the resources to the scheduled tasks, and tracks the operations. The internal state of the workflow is monitored by the contract object, e.g., to check if the deadlines are being met. After the internal workflow has been executed, control is given back to the contract object and the transaction will be finalized by the assertion of the customer that the service has been delivered according to the former promise (see Figure 5).

Figure 5: Cross-Organizational Workflow Definition

Security aspects for Contract Objects

In principle, all internal tasks of the enterprise architecture that are required for workflow execution are masked off from the outside world. We call workflows, tasks and objects private (or protected) entities. However, in some cases exceptions need to be specified, e.g., if a customer wants to track the completion of his order in the producer’s system. This category entails public workflows, tasks and objects. Therefore, the contract includes a special section to specify authorizations or even obligations to execute a task in the connected workflow system.

Figure 6: Contracts Specify Object Visibility

Figure 6 aims to express how the Release_Order contract, that we are about to define more formally, prescribes the visibility of the workflow objects and it’s components (task and business objects). The left hand side represents the enterprise model of the integrated circuit board manufacturer; the right hand side the PC manufacturer. The “white” entities represent public entities, whereas the gray entities denote private, or protected components. The advantage of this approach is that the security can be defined for various (categories of) trading partners. Storing visibility information inside the CDL definitions would therefor not make sense.

Although the figure suggests that the contract links two workflows symmetrically, it must be noted that there is a very important asymmetry. The activity actually performed is the componentShipment. The execution of this workflow takes place at the left hand side. The control of this workflow takes place at the right hand side. The control is split up in two parts: the actagenic part (Init_Release_Order) and the factagenic part (Eval_Release_Order). Remember that the objects in the right hand side of the picture only store and manipulate the state of the workflow control: the actual coordination is supervised by the contract. The right hand side control part can be a sub-workflow of a more complex workflow (let’s say inventory management), but this is not relevant for the interaction and therefore needs not be taken into account. We claim that the asymmetry is fundamental: the naive idea that there are two independent workflows that just need to be synchronized symmetrically should be abandoned. It is always one of the two sides that controls the other.

As we said, contracts are reciprocal arrangements, so the contract also defines a compensating workflow (typically the payment). It may also be the case that on the scenario level, different contractual arrangements are synchronized in a symmetric way. But on the workflow level, there is fundamental asymmetry.

4.3 The CDL/XLBC Metamodel

CDL defines three categories of business types: business objects, business tasks and business workflows. Workflows are executed by an authorized (automated) actor and result in an obligation or an accomplishment (see the homonymous association classes). Business types have static and dynamic features. Static features include attributes and relationships to other types. We discern three behavioral features: an operation, an appliance and a state.

Figure 7: An excerpt of the CDL/XLBC Metamodel

XLBC contracts are represented at the middle of the metamodel. As can be seen in Figure-7, XLBC-contracts are composed out of one or more workflow loops, which in turn contain several transactions, composed out of XLBC messages. XLBC transactions manipulate the deontic state of the system: a transaction results in a new obligation, authorisation or accomplishment. The deontic state comprises the actual state of the set of mutual obligations and authorisations at a certain point in time.

An execution workflow is initiated by a startWorkflowExecution event. This category of events is (lexically) linked to an obligation that is laid down in the contract. This means that if one completes an actagenic XLBC transaction, e.g., init_release_order, which according to the contract definition results in the obligation of the seller to ship components, the workflow componentShipment is started. Execution workflows terminate with a terminateWorkflowExecution event. They trigger the control flow which check if the executor’s obligation is fulfilled. The factagenic transaction is triggered by the terminateWorkflowExecution event. This transaction itself triggers an accomplishment, if it succeeds, that is, if the other party accepts the result of the workflow execution.

4.3.1 The Contract Specification

The following excerpt shows an example of an XLBC specification of a contract, called Release_Order_Contract, between a computer manufacturer (e.g., IBM) and one of its part suppliers (Philips-Conductors). This contract is a special category of a sales document that states fixed delivery conditions, e.g.. the number of parts procured in a period (e.g., a month).

More in particular, this contract describes the obligation of a seller (Philips-Conductors) to deliver the product (an IC) to the PC Manufacturer (IBM) (workflow w003), as well as the obligation of the semi-conductor manufacturer to pay for this delivery (workflow w004). The transaction has an identifier (CONTRACT-ID) and a name (CONTRACT-TYPE) by means of which it can be stored in the XLBC component library.

The roles INITIATOR and EXECUTOR define the agents that play a role in the transaction. These roles are identified by the homonymous tags. There is a limited but extensible number of role names stored in the thesaurus: for the time being, we consider only the roles INITIATOR and EXECUTOR. The roles that are specified in the contract, e.g., buyer and product, refer to business objects that must be defined in CDL.

The contract does not specify the private details of the workflow execution as explained in section 4.2. The PRED componentShipment in the workflow definition transfers control to the componentShipment execution workflow.

In the example, the ACCOUNT-PAYMENT workflow is only named. This could be sufficient if this workflow is a standard component defined elsewhere. The RELEASE_ORDER workflow is defined in some more detail (but we have abbreviated it for reasons of space). Of the various states, only one is worked out: the state characterized by the obligation of the seller to deliver the product within one day. We have abbreviated the time reference in the deadline which normally is spelled out completely in XML.

The security section of the contract specifies “visible” (public) business (task) objects and workflows. This does not mean automatically that the other party has all access rights to these objects, as it might be constrained by local restrictions in the CDL definitions.

The transactions that are defined in the contract are transaction types which assumingly are stored in the XLBC component library. Therefore the structure of these transaction is not further defined in the contract. The parameters of the contract (agent, theme and date) are linked to the transaction roles.

Not shown in the example is that the starting state of the workflow is typically characterized by means of authorizations. In our example, the authorizations would specify which products can be ordered and what are the limits on quantity and price. The INIT_RELEASE_ORDER transaction only succeeds, and brings the state to s1 (the obligation to deliver), if the request is in accordance with the authorizations.

The obligation has a deadline (within one day). Passing the deadline without having delivered implies that the workflow moves to a new state, one of violation. This transition must be performed by a Contract Manager, which resides at the organizations involved or is a separate control object.

5. Discussion

In this paper, we propose contract-based support to establish virtual enterprises with tightly intertwined business workflows. Contracts encapsulate the control of the workflows in terms of deontic statements that are organized in various layers (see Figure-8). Moreover, contracts determine the visibility of internal objects in the enterprise systems. The deontic statements are linked to business objects, tasks and workflow by means of the CDL/XLBC Metamodel.

Lately, several similar initiatives have been launched to introduce contracts as a means to script workflows into an integrated value chain. A recent example is the CrossFlow project. The CrossFlow project aims at developing a framework to support contract based service trading [koetsier,99]. However, this particular contract specification language is equipped with less business semantics, and not linked to a business object framework.

In [marshall00] an architecture is sketched to support contracts and business processes. This architecture comprises a contract manager, process manager and a message manager and could likewise be applied to support the CDL/XLBC language. Verharen [verharen98] points out in his thesis a similar architecture to support intelligent agents.

The OMG has proposed the jointFlow standard that is focused at the enactment of workflow process components. It defines interfaces that support control of process execution, supports interoperation between process components, and offers some services for monitoring [schmid98], [omg98]. We claim that this standard should be extended with the notion of contracts to seamlessly integrate the workflow process components into cross-organizational workflows.

.

Figure 8: The integration of the contract specification language (XLBC) with the integrated enterprise architecture (CDL)

Although the CDL/XLBC metamodel certainly needs to be improved in the near future, we think that the initial contract definition we presented in this paper adds a valueable perspective to the “traditional” pure object-, and not subject-, oriented way of workflow system modeling and design: the communication and the resulting mutual commitments.

Though it would certainly be desirable to define formal semantics for this combined language, we kept it outside the scope of our current research. We refer to [verharen98] for formal semantics of an ACL and contract language (CoLa) that should be integrated with CDL semantics.

Our current results are exploratory in nature: aspects of the language in this paper are being validated in several projects. A library of XLBC contracts is currently being developed in the MEdiating and MOnitoring for electronic commerce (MEMO) ESPRIT project. Potential trading partners can choose the most appropriate patterns from this library and configure them to suit their specific requirements.

Linking separated enterprise workflows into conceptual virtual organizations provides only a part of the required solution. These conceptual business models need to be linked to existing legacy systems. We research this mapping in the Process-Integration for Electronic Comnmerce project [heuvel01] .

Acknowledgement

The MeMo ESPRIT project is a consortium consisting of ABN-AMRO, Tilburg University, RWTH Aachen, Origin Spain, EKD, IMK Checkmark and IHK. The PIEC project is a joint project with the Dutch Telematics Institute.

References

[austin62] Austin, J., ”How to do things with words”, Clarendon Press, 1962

[bodtf97] Data Access Technologies, “Business Object Architecture ({BOA})

Proposal”, OMG –Document BOM/97-11-09, OMG Business Object Domain Task Force, 1997.

[dietz96] Dietz, J.L.G., “Introductie tot DEMO: Van Informatietechnologie naar organisatietechnologie”, Samson Bedrijfsinformatie, Alphen aan den Rijn/Zaventem, 1996

[heuvel01] Willem-Jan van den Heuvel, “Binding business Applications to LEgacy Systems: The BALES Methodology”, Thesis, Tilburg University, forthcoming

[keller98] Gerhard Keller, Thomas Teufel , “SAP R/3 Process Oriented Implementation: Iterative Process Prototyping”, Addison-Wesley, 1998

[kimbrough97] Kimbrough, S. and Moore, S.A., ”On automated message processing in electronic commerce and work support systems: Speech Act”, ACM Transactions on Information Systems (TOIS), 1997

[koetsier99] M. Koetsier, P. Grefen and J. Vonk, “Contracts for Cross-Organizational Workflow Management", CrossFlow Consortium / University of Twente, TR-CTIT-18, 1999

[leymann2000] F. Leymann and D. Roller, Production Workflow: Concepts and Techniques, Prentice Hall, New Jersey, 2000.

[ludwig99] Heiko Ludwig and Keith Whittingham, Virtual enterprise co-ordinator--agreement-driven gateways for cross-organisational workflow management, Proceedings of the international joint conference on Work activities coordination and collaboration , 1999, Pages 29 - 38

[manola98] F. Manola {et al.}, “Supporting Cooperation in Enterprise Scale Distributed Object Systems'', in M.P. Papazoglou and G.~Schlageter, editors, Cooperative Information Systems: Trends and Directions, Academic Press, London, 1998.

[marshall00] C. Marshall, “Enterprise Modeling with UML: Designing Succesful Software through Business Analysis”, Addison&Wesley, Reading, Massachusetts, 2000

[medina92] R. Medina-Mora and T. Winograd and R. Flores and F. Flores, “The Action-Workflow Approach to Workflow Management Technology”, in: Proc. Of 4th Conf. On Computer Supported Cooperative Work (CSCW '92), ACM Press, New York, 1992.

[omg98] Object Management Group, Workflow Management Facility, OMG Document bom/98-06-07, 1998.

[ortner99] W. Ortner and C. Stary , “Virtualization of Organizations: Consequences for Workflow Modeling”, Proceedings of: HICSS-32 Conference, IEEE, 1999

[papazoglou99] M.P. Papazoglou and W.J. van den Heuvel, “Leveraging Legacy Assets”, to appear in M. Papazoglou, S. Spaccapietra, Z. Tari, editors, Advances in Object-Oriented Modeling, MIT-Press, 2000.

[papazoglou00] Michael Papazoglou and Willem-Jan van den Heuvel, Configurable Business Objects for Building Evolving Enterprise Models and Applications, W. van der Aalst, J. Desel and A. Oberweis (eds), Springer, 2000

[sanfran98] S. Abinavam and {et al.}, San Francisco Concepts & Facilities, International Technical Support Organization, IBM, February 1998, SG24-2157-00.

[scheer,99] A.-W. Scheer, ARIS-Business Process Modeling, Springer, Berlin, 1999

[schmidt98] M.T. Schmidt, “Building Workflow Business Objects, Object-Oriented Programming Systems Languages Applications'', OOPSLA'98 Business Object Workshop, London, Springer, 1998

[searle69] Searle, J., ”An essay in the philosophy of language”, Cambridg University Press, 1969

[vdheuvel99] W.J. van den Heuvel, M.P. Papazoglou, and M.A. Jeusfeld, “Configuring Business Objects from Legacy Systems'', Procs. CAISE'99 Conf., Heidelberg, Germany, Springer-Verlag, June 1999.

[verharen98] Egon Verharen, “A Language/Action Perspective on the Design of Cooperation Information Agents”, Thesis, Tilburg University, 1998

[weigand99] H.Weigand and W.J. van den Heuvel, “Meta-Patterns for Electronic Commerce Transactions Based on the Formal Language for Business Communication (FLBC)”, in: International Journal of Electronic Commerce, (3)2: 45-66, 1999

[winograd86] Winograd, T., ”A language/action perspective on the design of cooperative work”, In: Greif, I., editor, Computer Supported Cooperative Work: A Book of Readings, Morgan Kaufmann, 1986

---

[1] Another term for a business workflow is a production workflow. Production workflows constitute a special category of workflows with a high business value and a high repetition factor.

[2] In the remainder of this paper, we will use the following synonyms for “Semi-conductor manufacturer”: “IC Manufacturer”, “Sub-component Manufacturer” and “Lot Manufacturer”.