From inter-organizational business process models to service-oriented architecture models

Abstract

Today’s business processes become increasingly complex and often cross the boundaries of the organizations. On the one hand, to support their business processes, modern organizations use enterprise information systems that need to be aware of the organizations’ processes and contexts. Such systems are called Process-Aware Information System (PAIS). On the other hand, the service-oriented architecture (SOA) is a fast emerging architectural style that has been widely adopted by modern organizations to design and implement PAIS that support their business processes. This paper aims to bridge the gap between inter-organizational business processes and SOA-based PAISs that support them. It proposes a novel model-driven design method that generates SOA models expressed in SoaML taking the specification of collaborative business processes expressed in BPMN as input. We present the principles underlying the approach, the state of an ongoing implementation, and the results of two studies conducted to empirically validate the method in the context of ERP key processes.

1 Introduction

In the last two decades, the process-aware corporation paradigm has emerged as a replacement of the traditional functional organization [1]. To support their business processes, modern organizations use enterprise information systems that need to be aware of the organizations’ processes and contexts [2]. Such systems are called Process-Aware Information System (PAIS) [2]. Business Process Management Systems and Workflow Management Systems are examples of PAISs.

Today’s business processes become increasingly complex and often cross the boundaries of the organizations [3]. These cross-organizational business processes (COBPs) often require the coordination of several organizations and must take into account collaborative scenarios involving distributed and autonomous partners. For example, a typical ‘Sales & Distribution’ business process requires the coordination of several business partners including a buyer, a supplier, a shipment company, and other partners such as financial institutions. In such a process, the organization will, for example, make use of bank services to be able to offer a payment service.

Designing a PAIS that supports COBP is complex, time-consuming, and requires a designer with extensive experience [3]. One emerging approach to design PAISs is the use of service-oriented architecture (SOA) (e.g., [4,5,6]). SOA is an architectural style that provides a way of describing and understanding organizations, communities, processes, and systems to maximize agility and interoperability [7]. Since its introduction, SOA has been advocated as an evolutionary step in software architecture to help organizations overcome the challenge of building effective PAISs that support their business processes [6]. For Van Der Aalst [2], it is very natural to design PAISs that support COBPs using SOA because business processes can be seen as the ‘glue’ connecting SOA services. SOA helps organizations to deliver dynamic solutions and reach their strategic goals by targeting efficiency, agility, and productivity [8]. Unfortunately, designing SOA-based PAISs is not a trivial task considering the large gap between business and IT layers [6, 9, 10]. A number of papers have reported various approaches to bridge the gap between these two layers. Some of these research efforts, including [5, 9, 11], used business models as a starting point. Authors in [5, 9, 11] claim that using business models allow designing services that are aligned with the business objectives since business models describe the rationale of why organizations create and deliver value. On the other hand, some other research efforts, including [4, 12,13,14,15,16], used the specification of business process models to design PAIS models. Unfortunately, to date and to the best of our knowledge, there is no end-to-end method guiding organizations to design and specify PAISs models from either business models or business process models.

This paper aims to bridge the gap between COBPs and PAISs that support them using a model-driven design method that generates SOA services from COBP models. The main contributions of this paper are: (i) an end-to-end method that identifies and specifies SOA services from the specification of process models, (ii) a method that applies to processes from different business domains, and (iii) a method that is tailored for business analysts who do not need to become software architects or Business Process Management (BPM) experts. Our ultimate goal is to help business analysts produce precise SOA design-level models of the PAIS that automate the organizations’ processes using their knowledge of the business domain. COBP models are expressed in Business Process Model and Notation (BPMN) [17], while generated SOA models are specified using the Service-Oriented architecture Modeling Language (SoaML) [7].

This paper extends the work presented in [6], by (1) improving the process of SOA services identification and (2) reporting the results of two empirical studies conducted as initial steps toward the empirical validation of the method in the context of key ERP processes.

The remainder of the paper is organized as follows. Section 2 surveys related work in the area. Section 3 describes our approach to design SOA-based PAIS from COBP models. Section 4 presents the design and implementation of our method. Section 5 illustrates the proposed approach in the context of a generic B2B purchasing process. Section 6 presents the results of empirical studies conducted to empirically validate our approach. Section 7 draws our conclusions and summarizes our envisioned further work in the area.

2 Related work

Several research efforts have proposed approaches to build software models by either using business models or business process models.

2.1 From business process models to software models

In [12], Carlson proposed a technique he called Business Information Analysis and Integration Technique (BIAT) to design the high-level architecture of an information system based on the specification of the underlying business process. To Carlson [12], any organization offers a product to a client (i.e., the concept of generic order). Hence, BIAT technique used seven questions based on the concept of generic order to identify the components of the information system. In [13], Coad et al. proposed a question-based development method to build software models from generic enterprise-component models (ECM). ECM define a fundamental model shape for supporting some aspects of business processes. While the approach is interesting, it focuses only on model fragments instead of entire process models.

In [4], the authors presented a model-driven development approach that uses transformation rules to generate services from the specification of business processes expressed in BPMN. Generated services are specified using the SoaML language. The transformations are based on a set of one-to-one mapping between BPMN and SoaML. Similar to [4], authors in [14] proposed a semiautomated approach based on model-to-model transformations from BPMN models (Computation Independent Model, CIM) to SoaML-based models (Platform Independent Model, PIM). BPMN models are analyzed through a set of mapping rules to obtain service models representing constructs and architectures for PIM-level models which will be used as a basis for the further transformation to Platform-Specific Models. Nevertheless, these approaches generate service models that are lacking business semantics.¹ In [15], Bianchiniet al. proposed a semiautomatic top-down method to support designers in the process of analyzing collaborative business process models in order to identify functionalities that can be exported as services. This approach starts with value and task dependencies analysis of the business process to identify candidate services. Candidate services are refined afterward before being conciliated. However, the method proposed by Bianchiniet al. [15] is limited to service identification. It does not specify the services.

In [16], Cruz et al. proposed an approach to identify system functional requirements by extracting use case models from business process models. This approach was extended in [19] to build aggregated use case models from a set of business process models. Later in [20], Cruz et al. proposed a new approach to generate an aggregated data model based on a set of interrelated business process models expressed in BPMN. In [21], Gonzalez-Huerta et al. presented a three-step transformational approach to derive software models from BPMN models. This approach is interesting because it proposes to (i) refine the input BPMN model and (ii) applies process re-engineering patterns to generate the to-be model before generating software models. However, the authors did not elaborate on the derivation of software models.

2.2 From business models to software models

In [5], the authors proposed a model-driven approach to extract services from business models expressed with e3-value business ontology. Identified services are specified using UML. The proposed method focuses on applying model transformation rules to build high-level service models that are still missing a link to related business requirements. In [9, 11], the authors argued that business models are more appropriate to communicate the business perspectives of the process during service identification. In [9], Andersson et al. presented an approach for service design using a goal model and e3-value business models. In [11], Weigand et al. proposed a three-step method for service identification that starts from a value-based business model. Later in [22], authors introduced a new business service and resource modeling language based on the Resource Event Agent (REA) business ontology (see [23]) and a transformation approach to map business models to service models.

In [24], the authors proposed a model-driven development method to elicit services based on REA business models. This approach is interesting; however, like [5, 9, 14, 22], the service models are not elaborated with enough details to allow their implementation. Our work proposes a novel approach to (i) identify SOA services from COBP models, (ii) associate them with business patterns to allow their specification, and (iii) specify each service with SoaML.

3 From collaborative process models to SOA models

This paper focuses on the derivation of SOA models from COBP models. COBP models are expressed in BPMN [17]. BPMN is a recognized standard for business process modeling. Generated SOA services are specified using SoaML [7], a language that extends UML metamodel to support explicitly service modeling and requirements for SOA.

Fig. 1

REA metamodel

Fig. 2

Overall process for SOA services identification and specification from BPMN models

3.1 Toward a generic approach

To elaborate a generic approach that applies to COBPs from different domains, we first need to conceptualize each COBP using business terms such as economic resources, economic agents, and value-adding activities [25]. One solution consists of using a business ontology such as REA [23, 26], e3-value [27], or BMO (Business Model Ontology) [28]. Indeed, a business ontology focuses on key business abstractions such as resource exchanges that span process domains. By using a business ontology, the business modeler can elicit the actors involved in a business scenario, and explain their relationships in terms of economic resources exchanged between actors [1]. In this work, we chose the REA business ontology [23] that is getting wider attention from the community [29, 30].

REA was introduced by McCarthy as an accounting framework to record economic phenomena in a shared data environment [23]. Then it has evolved to become a business ontology [26]. In REA, an organization can increase or decrease the value of its resources through either exchanges or conversions [29]. In an exchange process, the organization receives resources and provides other resources in return. In a conversion process, an organization uses or consumes resources in order to produce new or modified resources. Figure 1 illustrates the REA metamodel. Economic resources are scarce objects that have utility for the organization [23]. An economic agent is an individual or an organization capable of controlling economic resources [29]. An economic event is a phenomenon that reflects changes in economic resources. It can increment or decrement the value of economic resources. The duality association links increment events to decrement events. The work presented in this paper deals with exchange-type processes.

3.2 Overall approach

Figure 2 shows our four-step approach to generate SOA services from BPMN models. We would like to provide organizations with a generic method and tools to help them design SOA-based PAISs from COBPs models. The first step builds the Process Value Chain (PVC) model by decomposing the input COBP into elementary (sub)processes. This step is important because we need to generate services of each (sub)process that composes the input COBP. The second step identifies, for each (sub)process, high-level services we call Exchange services. The third step identifies, for each (sub)process, low-level services we call business information services. The last step specifies identified services using SoaML.

3.2.1 Extraction of process value chain

A COBP can be composed of several (sub)processes. For example, a Sales & Distribution (S&D) process is composed at least of two (sub)processes: ‘Sales’ and ‘Distribution.’ Sales is an exchange process. It exchanges the resource product for cash. Distribution is a conversion process that changes the location feature of the product. To generate services for S&D process, we need then to identify services for each (sub)process.

To infer (sub)processes that compose a given COBP, we build its PVC model. The PVC model is obtained using the pattern-based approach elaborated in [1, 31]. This approach comprises three steps. The first step consists of annotating the COBP model to distinguish economic resources. In this step, we ask business analysts to simply annotate the economic resources (i.e., scarce objects that have utility for the organization) in the BPMN model. The second step starts by inferring the remaining REA concepts (i.e., economic agents and economic events). REA economic agents are identified from the BPMN participants (i.e., pools and swim lanes). Economic events (i.e., activities that change the value of economic resources) are filtered from BPMN activities using previously annotated economic resources. Once REA concepts have been identified in the BPMN model, we identify the (sub)processes based on REA business patterns detection such as conversion and exchange patterns [29]. The last step connects the identified (sub)processes by following the economic resources flow in order to build the PVC model. Figure 3 shows the PVC of a generic S&D process. This process is composed of two (sub)processes: ‘Sales’ and ‘Distribution.’ The output of the Distribution process is the resource Product; this process changes its location. The input of the Sales process is the Product which is exchanged for Cash.

Fig. 3

PVC for the S&D process

Fig. 4

Exchange pattern

3.2.2 Identification of exchange services

Exchange services are special services that automate economic events which are activities that change the value of exchanged economic resources. Since this work deals only with exchange processes, conversion processes of the PVC are out of the scope of the paper and thus will not be considered. We need then to identify Exchange services for each exchange process in the PVC model. Therefore, we propose the following two-step process:

Build the REA exchange model During this sub-step, we build an REA exchange model for each exchange process in the PVC. This model shows: (i) the partners in the process, (ii) the economic events (i.e., activities that change the value of economic resources), and (iii) the exchanged economic resources. In order to obtain this model, we simply instantiate the exchange business pattern of Fig. 4 in the context of the (sub)process. Each exchange consists of at least one increment event that increases the value of a resource and at least one decrement event that decreases the value of a resource. Each event is related to two agents: the provider who loses rights to the resource, and the recipient who receives the rights.

Fig. 5

Open-EDI collaboration phases

Fig. 6

Overall process for the identification of Open-EDI phases

Extract exchange services Exchange services are identified by analyzing economic resources transfers using the REA model obtained previously in the first step. Thus, each resource transfer (i.e., a combination of provide and receive) will yield an SOA Exchange service that handles the resource exchange. For example, when applied to the Sales (sub)process (see Fig. 3), we can extract two Exchange services. The first service will support activities that provide and receive the resource Product. The second service will support activities that provide and receive the resource Cash. Note that exchange pattern of Fig. 4 will be used later to specify identified services with SoaML.

3.2.3 Identification of business information services

Exchange services identified in the previous step will support activities that change the value of economic resources. However, a COBP can be more complex and involves other activities that do not change the value of economic resources. These activities are called business events [32]. They are automated by what we call business information services. Note that exchange services represent a special type of business information services. However, they should continue being designated as ‘exchange services’ since this term is more precise.

To identify business information services, we need to analyze exchanged messages from the BPMN model. Then, we have to match the services with business patterns to facilitate their specification with SoaML. However, message analysis will not allow us to match identified services with business patterns. To match a business information service with a business pattern accordingly, our approach uses the ISO Open-EDI model [33]. According to this model, a COBP moves through five phases, namely planning, identification, negotiation, actualization, and post-actualization (see Fig. 5). Using the ISO Open-EDI model is motivated by two main arguments. First, this model uses REA as its ontological framework for specifying the concepts and relationships involved in a COBP. Second, each collaboration phase consists of one or more exchanged messages that can be associated with business patterns (see [6, 26, 29]), allowing the specification of services. Furthermore, Open-EDI collaboration phases are adapted to REA ontology and are structured in three phases: (1) planning/identification, (2) negotiation; and (3) actualization/post-actualization (see [34]). Planning/identification phase involves process activities where potential partners plan the upcoming resource exchanges and identify each other by matching their proposed resources. The planning/identification phase is completed when a one-to-one link is established between partners. The purpose of the negotiation phase is to achieve an explicit, mutually understood, and agreed upon goal for the business transaction. The negotiation phase is completed when commitments and a contract are effective. Actualization/post-actualization phase starts once economic resource transfers are started [35]. Our approach for business information services identification is based on a two-step process:

Delimit Open-EDI phases boundaries for each process in the PVC Figure 6 shows the process used to delimit Open-EDI collaboration phases of a collaboration business process. At first, we use the first economic event (i.e., the activity that changes the value of an economic resource) to pinpoint thebeginning of the actualization/post-actualizationphase. In fact, actualization/post-actualization phase starts with activities involved in the exchange of the economic resources. Those activities were already identified using the exchange model of Sect. 3.2.2. Actualization/post-actualization phase ends with the last activity of the process. Once the actualization/post-actualization phase is identified, three scenarios are possible: either the process has (i) only an actualization/post-actualization phase. (ii) a negotiation phase before the actualization/post-actualization phase, or (iii) all three phases. If there are no activities before actualization/post-actualization phase boundaries, no further action is required. If any process activities are performed before actualization/post-actualization, we need to demarcate the boundaries of the planning/identification and negotiation phases. For that, we adopted a question-based approach, similar to the one used in [25]. At first, we ask the business analyst to specify whether an agreement exists between the partners. If there is an agreement that governs the process between the partners, it implies that planning/identification activities are unnecessary and that all activities before actualization/post-actualization phase are negotiation phase activities. For example, if the ‘Sales’ (sub)process (Fig. 3) is managed by an agreement, activities that handle ‘Request for Quotations’ (RFQ) and ‘Quotations’ will be unnecessary because the partner is known. Therefore, all activities before the actualization/post-actualization phase are negotiation activities. In the other case (i.e., there is no agreement), and since the purpose of planning/identification phase is to establish a one-to-one link between partners, we ask the business analyst to identify the last activity that establishes this one-to-one relationship. This activity will be elected as a boundary between the planning/identification and the negotiation phases.

Extract business information services for each process in the PVC by analyzing process messages Once Open-EDI collaboration phases boundaries are identified, we had two options: First, extract a business information service per message (collaboration between partners). Such a solution will identify too many services with granular responsibilities (nanoservices). This type of service design is an anti-pattern called Fine Grained Service (see [36]). Second, extract one business information service per collaboration phase. This option will yield services that may contain a large number of very low cohesive operations in their interfaces. Such services are called God Object Services (see [36]). Instead, our option to identify services with adequate coverage within the boundaries of each phase is to ask the business analyst to annotate exchanged messages as either ‘one way’ or ‘request–response.’ ‘Request–response’ messages will be grouped and handled by a single business information service.

3.2.4 Specification of services

Generated services are specified with SoaML, an OMG specification to architect SOA solutions. SoaML provides a metamodel and a UML profile with service modeling capabilities to support SOA design methods [7]. SoaML extends UML in six areas [37]:

• 1) Participants are either physical or moral entities and could be a software component that provides or consumes services. Participants have ports and can provide or consume any number of services. When a participant uses a service it is considered a ‘service consumer’ and uses a port with a ‘Request’ stereotype. When a Participant offers a service, it is considered a ‘service provider’ and will have a port with ‘Service’ stereotype [7].

• 2) Service Interfaces define how a participant interacts to provide or consume services. It describes the interface and the participants’ responsibilities using a ‘Service’ or ‘Request’ port [7].

• 3) Service Contracts are used to specify the agreement between service providers and consumers. It shares information between the participants regarding products, value, obligations, etc., without describing the details of how and why they will fulfill their obligations. Thus, it enforces loose coupling of the SOA paradigm [7].

• 4) Service Data describes the type and the content of messages [7].

• 5) Services Architectures describe how service consumers and providers collaborate. It expresses the dependencies between Service Contracts and the roles of the Participants [7].

• 6) Capabilities are used to model the ability to act and produce an outcome. Capabilities specify a set of functions or resources that a service might offer [7].

To specify generated services, we propose a pattern-based transformation approach. More precisely, our method transforms extracted services using business patterns from [26, 29]. To specify a service with SoaML, we created transformation rules that model Service Interfaces and Participants. The other SoaML models are not yet supported by our method. Transformations are based on structural and behavioral patterns from [26, 29]. More precisely, transformations use the exchange pattern (see Fig. 4) to specify exchange services and patterns corresponding to the Open-EDI collaboration phases for business information services. For example, our approach uses commitment and contract patterns (see [29]) to specify negotiation phase services and Claim materialization, account and posting patterns (see [29]) to specify services of the actualization/post-actualization phase. Sections 4 and 5 describe service specification with SoaML.

4 Design and implementation

In this section, we discuss the design and implementation of a proof-of-concept prototype that supports the proposed approach. Section 4.1 presents the prototype architecture. Section 4.2 describes the implementation of the transformation rules for specifying identified services.

Fig. 7

Prototype architecture

4.1 Prototype architecture

We implemented a proof-of-concept prototype with the Eclipse Modeling Framework™ (EMF, version 2.12.0). EMF™ is a Java-based modeling framework that implements EMOF (Essential Meta-Object Facility). As shown in Fig. 7, the prototype is based on three Eclipse plugins. The first plugin is bpm.modeling. It represents the REA-based business process metamodel used to model COBPs. It is based on EMF Ecore which represents the core of the EMF framework. To support COBP orchestration and choreography, we extended the REA metamodel with the behavioral model of the Business Process Definition Metamodel (BPDM) [38]. The second plugin is bpmnToValueChain. It is responsible for extracting PVC models from COBPs models using the pattern-based approach described in [1]. The third plugin is pvcToSoaML. It represents the core of the proof-of-concept prototype. It is responsible for generating SOA services. This plugin is based on two components: ServiceExtractor and ServiceSpecifier. ServiceExtractor provides functions to identify services according to the process explained in Sect. 3.2. ServiceSpecifier specifies identified services by applying transformation rules to build SoaML models.

4.2 Transformations rules

We designed a prototype as a rule-based application. Transformations are implemented using when-then rules that manipulate BPMN and SoaML objects. The when part matches model elements (e.g., pattern instance). The then part builds SoaML models by transforming COBPs and services objects using Red Hat Drools, an open-source business rule management system (BRMS). We used EMF and Drools BRMS mainly because this work is part of a more complete EMF-based and Drools-based framework that supports methods described in (i) [25] which specializes generic BPMN models to obtain organization-specific BPMN models and (ii) [1] which derives business models from process models expressed in BPMN.

The transformation process starts by initializing the Drools facts base by a representation of an annotated BPMN model (see [1]). To build the PVC model from the input BPMN model, we implemented a set of transformation rules based on structural and behavioral patterns (see [1]). To extract SOA services for each (sub)process in the PVC, we used the approach presented in Sect. 3. Then, to identify exchange services, we wrote a single rule to create a service for each resource transfer. Thus, we extract at least two exchange services by (sub)process. Indeed, according to the exchange pattern, every increment economic event must be related by exchange duality to at least a decrement economic event, and vice versa. To extract business information services, we wrote a single rule for each collaboration message within an Open-EDI phase.

Fig. 8

Contract pattern

Fig. 9

Transformation rule to specify the service that manages the exchange contract

Fig. 10

Generic procurement process

To specify identified services, we wrote a single Drools transformation rule per business pattern. Each rule specifies SoaML Service Interfaces (provided interfaces, required interfaces, roles, and behavior) and participants using its corresponding pattern. For example, the transformation that needs to be applied to specify the business information service that supports collaboration activities to manage a Purchase Order in a S&D or procurement COBP during the negotiation phase is based on the contract pattern of Fig. 8. This transformation is represented by the rule shown in pseudo-code format in Fig. 9. The when part looks, in the Drools working memory, for the extracted contract service and binds it to the variable $s. The then part contains the actions to perform. Each action corresponds to EMF calls. The first action (line 1) creates the SoaML Service Interfaces. Line 2 and 3 add provided and required interfaces to the Service Interfaces of $s according to the contract pattern (i.e., contract, commitment, and terms), respectively. Line 4 adds SoaML roles to the Service Interfaces and links them to provided and required interfaces. Line 5 adds SoaML behavior model. Line 6 creates SoaML participants representing parties in the contract.

5 A running example

This section illustrates the approach with a B2B Procurement process (see Fig. 10). A procurement process starts by filling out a requisition. Then the company (buyer) sends a request for quotation (RFQ) to potential suppliers. Suppliers prepare quotations and submit them back to the buyer. After receiving quotations, the buyer selects a supplier, creates a purchase order (PO) and sends it back to that supplier. Then, the supplier fulfills the order and delivers the product to the buyer. Once the product is received, a bill is issued by the supplier, and the company (buyer) sends the payment.

5.1 Step 1: Extraction of the PVC

To identify elementary (sub)processes that compose the procurement process, we use the pattern-based approach elaborated in [1, 31] (see Sect. 3.2.1). First, we ask the business analyst to annotate all the economic resources in the BPMN model. Two economic resources (Product and Cash) were annotated for the Procurement process. Next step is to infer the remaining REA concepts in order to identify the (sub)processes. Economic agents correspond to BPMN pools of the BPMN model. In this case, economic agents are ‘Company’ and ‘Supplier.’ Economic events are activities that change the value of the economic resources ‘Product’ and ‘Cash.’ Activities with a gray background in Fig. 10 represent economic events. In fact, the Procurement process is an exchange process (Cash for Product), whose PVC is then composed of a single exchange process. The input of the Procurement process is the economic resource ‘Cash.’ The output is the economic resource ‘Product.’ The PVC model of the Procurement process is shown in Fig. 11.

Fig. 11

PVC for the procurement process

Fig. 12

REA procurement model

5.2 Step 2: Identification of Exchange Services

To identify exchange services, we use the process described in Sect. 3.2.2. First, we build the REA model by instancing the exchange pattern of Fig. 4 in the context of the procurement process from the company point of view. The entities ‘Company’ and ‘Supplier’ represent economic agents. The entities ‘Product’ and ‘Cash’ represent the economic resources. Finally, entities ‘Receive Product’ and ‘Process Payment’ represent the increment economic event and the decrement economic event, respectively. The REA model of the procurement process is shown in Fig. 12. The next step identifies exchange services that handle the resource exchange for each resource transfer (i.e., a combination of provide and receive). Thus, the method extracts two exchange services using the model shown in Fig. 13: The first service supports activities for managing the resource ‘Product.’ The second service supports activities for managing the resource ‘Cash.’

Fig. 13

Exchange services of the procurement process

Fig. 14

Open-EDI phases of the procurement process

5.3 Step 3: Identification of Business Information Services

To identify business information services, we use the process described in Sect. 3.2.3. The first step identifies Open-EDI phases (i.e., planning/identification, actualization/post-actualization and negotiation). To identify the actualization/post-actualization phase, we use the first activities that involve exchanged economic resources (i.e., activities marked with a gray background in Fig. 10). These activities delimit the boundary of the actualization/post-actualization phase. Thus, to identify the remaining Open-EDI phases, we ask the business analyst to answer two questions. The first question is to define whether an agreement governs the exchange process. For this example, the company sends RFQs and then selects its partners (i.e., suppliers) based on received quotations. Therefore, this process is not governed by an agreement. The next question is to find the limit between the remaining Open-EDI phases. We ask the business analyst to identify the activity that establishes a one-to-one relationship between the partners. The business analyst identifies ‘Select Supplier’ as the activity that establishes the one-to-one relationship between the ‘Company’ and the ‘Supplier.’ Thus, ‘Select Supplier’ activity is marked as the boundary between the negotiation and the planning/identification phases. Identified Open-EDI phases are shown in Fig. 14.

The next step identifies Business Information Services . Thus, we ask the business analyst to annotate each message exchanged in each Open-EDI phase as either ‘one-way’ or ‘request–response’ type. RFQ and Quotation messages are annotated as ‘request–response’ message type. Therefore, a single service is identified to manage the identification of the partner through the exchange of RFQ and Quotation resources during the planning/identification phase. PO (purchase order) message is annotated as a ‘one-way’ message type. Therefore, a second service is identified to issue and handle the PO during the negotiation phase. The Invoice message is annotated as a ‘one-way’ message type. Therefore, a third service is identified to manage the invoicing during actualization/post-actualization phase. Identified services need to be matched with their corresponding business patterns to allow their specification in the final step (i.e., Step 4). Thus, we use the Open-EDI phases business patterns proposed by Hruby [29]. For example, the Quotation service that manages the RFQ and Quotation resources will be matched with the Contract pattern. For [29], RFQs and Quotations have the same structure as contracts and contains terms and commitments that have not yet been accepted by all parties in the contract. The partners (economic agents) negotiate the content of the terms and commitments, and when they agree upon them, the RFQ or Quotation becomes a contract that binds the agents (parties in the contract). The service that manages the PO is also matched to the pattern Contract. Indeed, a purchase order represents the contract that binds the agents (i.e., Company and Supplier). Finally, the service that manages the invoice resource will be matched with the Claim pattern ([29]). This matching process is not automated yet and is part of our future work (see Sect. 7). Table 1 illustrates extracted services for the B2B procurement process of Fig. 10.

Table 1 Procurement services

5.4 Step 4: Specification of Services

To specify identified services with SoaML, we implemented transformation rules that build service interfaces model and participants model. Service interfaces allow provider and consumer to invoke and respond to operations, send and receive messages or events. Service participants represent certain parties or components that provide and/or consume services. To illustrate our approach, we illustrate how to specify the Contract Service that is responsible for managing the PO contract during the negotiation phase.

Fig. 15

Service interfaces diagram of the Contract Service

The service interface is defined from the perspective of the service provider using: (i) the provided and required interfaces which are UML interfaces that are realized or used by the service interfaces; (ii) roles that will be played by the connected participants involved with the service; and (iii) the behavior which specifies the valid interactions between the provider and consumer using UML interaction and/or activity diagrams. Figure 15 shows the service interface diagram of the Contract Service. This specification is based on the contract pattern of Fig. 8. The contract has two participants, company and supplier. The service interface provides PO Taker interface (role of the provider in the service) and requires PO Placer interface (role of the consumer in the service). PO Placer has commitments (Commitment pattern) that define values (e.g., quantity) and dates for economic resources (e.g., product) and terms that define potential commitments that are instantiated if certain conditions are met (see Fig. 8). The service interface behavior is illustrated in Fig. 16.

Fig. 16

Service interfaces behavior of the Contract Service

SoaML Participants define types of organizations, roles, or components that provide and/or consume services. Service participants diagram of the Contract Service is shown in Fig. 17.

Fig. 17

Service participants diagram of the Contract Service

6 Evaluation

In this section, we report two empirical studies conducted to evaluate the applicability and the correctness of the proposed method. The first study aims at verifying whether the questions used by our approach to identify SOA services are applicable to many process areas, relevant, and easy to answer (i.e., do not require technical skills of software architecture or business process automation). Indeed, a key aspect of our approach is our claim that it can be (i) performed by users (e.g., business analysts) without having to become BPM experts or SOA software architects, and (ii) applicable to COBPs from different business domains. The second study aims at evaluating whether the generated services obtained after applying the method (i) are relevant, (ii) have a correct business semantic, and (iii) can automate the COBPs. These aspects can only be validated by experts who have the appropriate expertise that enables them to walk through the proposed method and evaluate the process, the questions used and the generated services. The rest of the section is organized as follows: Sect. 6.1 presents the set of selected business processes used as experimental objects in both studies; the evaluation of the questions used in the approach is discussed in Sect. 6.2; finally, the evaluation of the identified services is presented in Sect. 6.3.

6.1 Experimental business processes

To carry out the two empirical studies, we selected five collaborative business processes from ERP process catalogs [39, 40] and the MIT process handbook [41]. These processes were modeled using BPMN language. Table 2 lists the selected business processes.

Table 2 Selected business processes

Table 3 Questions asked by the method

6.2 Evaluation of questions

One of our goals when defining the approach is to design a semiautomatic method that does not require particular technical skills. Our question-based approach has been defined to require minimal user interaction before the identification and the specification of SOA services. The objective of this first empirical study is to evaluate whether the questions used as the basis for the identification of SOA services are (i) applicable and relevant in the context of COBPs from different business domains; and (ii) easy to answer by business analysts.

6.2.1 Experimental design

To design the first empirical study, we encoded the questions used by the method from Q1 to Q4. Table 3 shows the questions codification.

The goal of this first experiment is to evaluate, the applicability, the relevance, and the simplicity of the questions used by the method to identify SOA services from the point of view of the participant experts. For each objective (i.e., applicability, relevance, and simplicity), we defined a research question (RQ). Therefore, we had three research questions RQ1, RQ2, and RQ3. The context of this study is determined by: (i) the five selected business processes presented in Table 2, (ii) the questions used by our method, and (iii) the participants (i.e., the experts who evaluate the questions being applied).

Questions applicability The first objective is to evaluate, from the expert’s perspective, the questions applicability (Table 3) in the context of selected COBPs. The research question to be answered in this study is:

RQ1: Are the questions asked by our method applicable?

For this evaluation, we presented to the experts the four questions we have encoded Q1 to Q4 and the five selected business processes expressed in BPMN (see Table 2). Then, we asked them whether each of the questions used by the method (see Table 3) is applicable when it is instantiated in the context of a given business process. This allows us to gain empirical evidence on whether the questions can be applied to business processes from different domains. It helps in the meantime to collect participants comments in order to understand why a particular question is not applicable to a particular business process.

For each question Q1 to Q4, we had a bi-valuated variable (i.e., with two possible values 0 and 1) but also open questions to the participants to explain their perception of questions applicability. The bi-valuated variables can have two possible values: 0, which means that the expert has found the question not applicable and should not be instantiated in the context of a specific business process and 1, which means that the expert has found the question applicable when instantiated in the context of a particular business process. Plus, when the answer is 0, we asked the participants to add comments explaining why they think that the question is not applicable and therefore collect accurate information about their perception.²

Questions simplicity The second objective is to evaluate, from the expert’s perspective, the simplicity of the questions (Table 3) in the context of selected COBPs. We define the simplicity of the questions by the ability of a business analyst to answer the questions asked by our method without having to become an expert in SOA or COBP modeling. The research question to be answered in this study is:

RQ2: Are the questions asked by our method easy to answer?

For this evaluation, we presented to the experts the four questions encoded Q1 to Q4 and the five selected business processes expressed in BPMN (see Table 2). Then, we asked them whether each of the questions used by the method (see Table 3) is easy to answer when instantiated for a given business process

For each question Q1 to Q4, we had a bi-valuated variable (i.e., with two possible values 0 and 1) but also open questions to the participants in order to give feedback with regard to their perception of questions easiness. The bi-valuated variables can have two possible values: 0 which means that the expert has found the question difficult to answer in the context of a specific business process; and 1 which means that the expert has found the question easy to answer in the context of a particular business process. In addition, when the answer is 0, we ask the participants to add comments, by answering open questions, to explain why they found the method question difficult to answer.

Questions relevance The third objective is to evaluate, from the expert’s perspective, questions relevance (Table 3) in the context of selected COBPs. The research question to be answered in this study is:

RQ3: Are the questions asked by our method relevant?

For this evaluation, we presented to the experts the four questions encoded from Q1 to Q4 and the five selected business processes expressed in BPMN. We asked them whether each question is relevant in the context of a given business process. This allows us to gain empirical evidence on whether the questions are relevant to business processes from different business domains.

For each question Q1 to Q4, we had a bi-valuated variable (i.e., with two possible values 0 and 1) but also open questions to the participants to explain their perception of questions relevance. The bi-valuated variables can have two possible values: 0 which means that the expert has found the question irrelevant to the process and should not be instantiated in the context of the business process; and 1 which means that the expert has found the question relevant when instantiated in the context of a particular business process. Plus, when the answer is 0, we ask the participants to add comments, by answering open questions, to explain why they found the question irrelevant.

6.2.2 Participants selection

To evaluate the questions used by our method, we invited five senior business analysts from various business sectors by convenience. The participants have several years of experience in information systems analysis, business process modeling, and a solid BPM expertise. Table 4 summarizes the participants’ profile in the first study.

Table 4 Profile of the participants in the questions evaluation study

6.2.3 Experiment execution and results

Several documents and instruments were designed to introduce the participants in the context of our research project. The material³ included: (1) BPMN models of the selected COBPs, (2) training slides with an overview of the method, (3) questions used to identify services, and (4) a questionnaire for gathering the data. The participants performed the evaluation separately and submitted the data collection forms once they finished. The questionnaire was designed to be completed in a single session of up to 60 min. It was structured to allow experts to answer binary questions (i.e., Yes/No). Additional space was available for the experts to add comments explaining their answers.

Questions applicability evaluation Table 5 shows experts’ assessment of the bi-valuated variables regarding questions applicability in the context of the selected business processes of Table 2. These results show that in general, the experts agreed that the questions used by our method were applicable. More precisely, in the context of this experiment, experts confirmed that the questions were applicable in 94% of the 100 collected answers (5 experts $\times$ 5 exchange processes $\times$ 4 questions) (see Fig. 18). Indeed, participants agreed that in most cases questions were considered applicable except for Q2. Detailed analysis of experts’ answers and comments to the open questions, allowed us to gain more evidence about the questions applicability. Essentially, expert 1, 2 and 5 found that question Q2 is not applicable in the case of ‘Distribution’ and ‘Maintenance’ (sub)processes. They suggest modifying the question in order to fit those (sub)processes. In fact, we intentionally ignored this conversion-type (sub)processes from the process value chain as our method deals only with exchange-type processes. The Distribution and Maintenance (sub)processes are conversion processes because Distribution (sub)process changes the ‘location’ attribute of economic resources, while Maintenance (sub)process changes their ‘state’ attribute [29].

Fig. 18

Questions evaluation results

Table 5 Questions applicability evaluation

Table 6 Questions simplicity evaluation

Questions simplicity evaluation Table 6 presents the results of the bi-valuated variables regarding questions simplicity in the context of selected processes (Table 2). These results show that in general, the experts agreed that the questions used by our method were easy to answer. More precisely, in the context of this experiment, experts confirmed that the questions were easy to answer in 92% of the 100 collected answers (see Fig. 18). Indeed, participants agreed that in most cases questions were easy to answer except for Q3. A closer look into experts’ answers and comments to the open questions allowed us to understand experts’ perception of the questions easiness. In fact, they agreed that question Q3 was difficult to answer in the case of Online Sales & Distribution.’ Detailed analysis of the results from questions simplicity evaluation reveals that experts consider question Q3 not easy to answer in the context of the ‘Online Sales & Distribution’ process. Indeed, identifying the last activity that establishes a one-to-one link between partners can represent a challenge especially when (i) the process is composed of several (sub)processes that involve different partners or (ii) simply when the BPMN model is missing details about this activity. However, experts confirmed that this question does not require technical skills to answer.

Table 7 Questions relevance evaluation

Questions relevance evaluation Table 7 presents the results of the bi-valuated variables regarding questions relevance in the context of the selected business processes (Table 2). In fact, obtained results are similar to questions applicability evaluation where experts agreed that in most cases questions were relevant except for Q2. More precisely, in the context of this experiment, experts confirmed that the questions were relevant in 94% of the 100 collected answers (see Fig. 18). Deeper analysis of experts’ answers and comments reveals that expert 1, 2 and 5 consider question Q2 irrelevant in the case of ‘Distribution’ and ‘Maintenance’ (sub)processes. They based their answers on the same explanation as for the questions applicability evaluation. Thus, like previously explained it in the case of questions applicability, we explicitly ignored those processes since they are conversion-type (sub)processes [29].

6.3 Evaluation of services

The objective of this second experiment is to evaluate: (i) the relevance of the identified services, (ii) the semantic correctness of the services from a business perspective, and (iii) the ability to automate the COBPs using the identified services. The context of this empirical study is determined by the selected business processes, the identified SOA services, and the experts.

6.3.1 Experimental design

The goal of this experiment is to evaluate: (i) the relevance (ii) the correctness of the business semantics associated with the identified services, and (iii) whether the identified services can automate the business process collaborations, from the point of view of the experts. For each objective, we defined a research question. Therefore, we had three research questions RQ4, RQ5, and RQ6. To carry out this study, we used the same processes as for the first experiment (see Table 2).

Evaluation of services relevance The first objective is to evaluate, according to the experts, the relevance of the identified services in the context of each COBP. We define service relevance by the fact that the service can support one or more activities of the business process. The research question to be answered in this study is:

RQ4: Are identified services relevant in the context of selected business processes?

During this evaluation, we presented to the experts the list of identified services encoded from S1 to S36. Then, we asked them to determine whether a particular service is relevant in the context of the process that was used to generate it.

Therefore, for each service from S1 to S36, we had a bi-valuated variable (i.e., with two possible values 0 and 1) to indicate whether a particular service is relevant in the context of a process and also added open questions to the participants to explain their perceptions about the service relevance. The bi-valuated variables can have two possible values: 0 which means that the expert has found the service irrelevant in the context of the business process; and 1 which means that the expert has found the service relevant in the context of the business process. Besides, when the answer is 0, we ask the expert to add comments explaining their perception, by answering the open questions.

Evaluation of services business semantics The second objective is to evaluate the business semantic correctness of the identified services. Through this evaluation, we want to verify that the business patterns associated with the services are correct. This is a key aspect of our method because the business pattern will allow us to specify the service with SoaML in the PAIS design phase. The research question to be answered in this study is:

RQ5: Is the business semantic associated with the services correct in the context of selected business processes?

To assess the business semantic correctness of the services, we presented the experts with the list of identified services, encoded from S1 to S36, where each service is associated with an REA business pattern. Each service has the same business semantics of its associated business pattern. For example, if a service is based on the REA ‘Contract pattern,’ it will have the business semantics of this business pattern. Then, we asked the experts to determine whether the business semantic of identified services is correct.

Therefore, for each service from S1 to S36, we had a bi-valuated variable (i.e., with two possible values 0 and 1) to indicate whether the service’s business semantic is correct in the context of a particular process and also added open questions to participants to explain their perceptions about the service’s business semantic correctness. The bi-valuated variables can have two possible values: 0 which means that the expert has found the service’s business semantic not correct in the context of the business process; and 1 which means that the expert has found service’s business semantic correct in the context of the business process. As for the other research questions, when the answer is 0, we ask the expert to add comments explaining their perception, by answering the open questions.

Evaluation of the services capability to automate business processes The objective of this study is to assess, from the experts prescriptive, whether identified services can be used to automate the business process collaboration. The research question to be answered in this study is:

RQ6: Can we automate the COBP using identified services?

For this evaluation, we used the list of encoded services from S1 to S36 that are explicitly linked to the appropriate business processes encoded from P1 to P5. Then we asked the experts to evaluate whether the identified services can automate collaboration activities of the COBPs. If the answer is negative, the expert will then annotate the activities that are not automated.

Therefore, for each process from P1 to P5, we used a bi-valuated variable (i.e., with two possible values 0 and 1) to indicate whether the expert believes that the collaboration activities of the COBP can be automated using the identified services. The bi-valuated variables can have two possible values: 0 which means that the expert considers that collaboration business process cannot be automated using identified services; and 1 means that the expert has found identified services can automate the COBP.

Besides, when the answer is 0, we asked the expert to annotate missing activities to enable the COBP automation. Then, we added an open question to ask the participants to explain their assessment of identified services capability to automate COBPs.

6.3.2 Participants selection

To evaluate generated SOA services, we approached five experts with a solid SOA architecture background and many years in software design. Three out of five accepted our invitation and the other two declined their participation due to lack of time. All experts are senior solutions architects with a heavy background in different business sectors. Expert 1 and Expert 2 are senior solution architects with more than 15 years of experience in software design and implementation. Expert 3 is an ERP architect with a solid knowledge of SOA and business modeling. He has been involved in major projects, especially implementing new procurement, finance, and asset management processes for more than 20 years.

6.3.3 Experiment execution and results

As for the first experiment, we designed several documents and instruments to put the participants in the context of the research project and the proposed approach. The materials included: (1) BPMN models of the selected business processes, (2) training slides with an overview of the method, and (3) a questionnaire for gathering the data. The questionnaire is designed to be completed in a single session of up to 120 min. The questionnaire is structured to allow experts to answer binary questions and ask them to add comments explaining their answers. In the end, we used the unit-test-based prototype to generate 36 SOA services codified from S1 to S36 (see Table 8). These services were then given to the experts to assess their relevance, business semantics correctness, and their ability to automate COBPs activities. Before the experiment took place, we answered all questions raised by the experts who performed the evaluation and submitted the data collection forms once they have finished.

Table 8 Identified SOA services

Table 9 Services relevance evaluation

Results of services relevance evaluation Each expert evaluated the relevance of the 36 generated services for a total of 108 evaluations (36 services $\times$ 3 experts). Table 9 presents the results of the bi-valuated variables regarding services relevance in the context of the five selected business processes.

Based on obtained results in the context of this experiment, we observe that in most cases experts agreed that identified services were relevant in the context of the selected business processes. In fact, out of 108 answers, experts confirmed that 92.59% of identified services were relevant. Detailed analysis of experts answers to the open questions reveals that experts agreed that identified services were relevant except for services S4, S9, S14, S18, S22, S25, S26, and S27 (see Table 8). More precisely, experts 1 and 2 found that the method generates more services than they expected. For example, our method identified one service (S3) to support activities that manage ‘Request for Quotations’ (RFQ) and ‘Quotation’ and another service (S4) to support activities that handle the ‘Purchase Order’ (PO). Expert 2 proposes to combine both services into a single SOA service for automating the activities that manage RFQ , ‘Quotation’ and PO . Expert 2 proposes also to replace the services S25, S26, and S27 in process P3 with a single banking management service. In addition, expert 1 explains that S14, S18, and S22 that support activities that handle ‘Goods receipt,’ ‘billing,’ and ‘tracking’ are irrelevant. In his perspective, those services are considered too granular and the service already identified can be extended to support these activities.

Table 10 Evaluation of services semantics correctness

Results of services business semantic evaluation Each expert evaluated the services business semantics correctness of the 36 generated services for a total of 108 evaluations (36 services $\times$ 3 experts). Table 10 presents the results of the bi-valuated variables regarding the services business semantics correctness in the context of the five selected business processes.

The obtained results in the context of this experiment, show that in most cases experts agreed that business semantic of identified services were correct. In fact, out of 108 answers, experts found that 93.52% of associated business semantic with identified services were correct. Detailed analysis of experts answers to the open questions reveals that experts agreed that associated business semantic with identified services were correct except for services S3, S8, S11, S14, S20, S22, and S34 (see Table 8). More precisely, expert 2 doesn’t find correct to associate services that manage RFQ and Quotations (i.e., S3, S8, and S34 in Table 8), with a business semantic based on the Contract pattern. This pattern implies explicitly confirmed commitments of both parties when at this stage of the process, commitments are not firm yet. We agree with the expert about the state of the commitments. Note that we linked the service that manages RFQ and Quotations to the contract pattern as RFQ, quotes, and contracts share the same structure and business semantics (see [29]). After discussion with the experts, we plan to specialize the contract pattern in order to take into consideration the state of the commitments according to the Open-EDI phase. In the next case, expert 1 argues that identified SOA service S11 and S20 that support the shipping process purchase in P2 and P3 match an outsourcing pattern rather than an exchange pattern since the partners (i.e., third-party companies) handle the shipping (sub)process for the organization. We agree with the expert 1 point of view. Our method assigned an exchange pattern to the shipping service as from an REA perspective, only economic resources can be exchanged but not processes [29]. In this case, the company exchanged the Shipping Service (which is an economic resource provided by the third-party) for Cash.

Expert 1 explains also that Claim⁴ pattern associated with SOA services that support activities for managing goods receipt (S14 and S22 in Table 8) is not correct. We understand the expert point of view. Our method linked the services S14 and S22 to the Claim pattern as ‘good receipt’ contains information about the unbalanced value and relevant information about dual economic events (see [29]).

Table 11 Results of the evaluation of the ability to automate COBPs with services

Results of service level of automation evaluation Each expert evaluated the ability to automate the five selected COBPs using identified services for a total of 15 evaluations (5 processes $\times$ 3 experts). Table 11 presents the results of the bi-valuated variables regarding the ability to automate the business process collaboration activities by identified services in the context of the experimental business processes presented in Table 2.

The obtained results in the context of this experiment show that in most cases experts agreed that collaboration activities of selected COBPs could be automated using identified SOA services. In fact, experts agreed that most of COBPs could be automated using identified services especially processes P1, P4, and P5. More precisely, based on the experts’ annotated activities (i.e., activities that the experts found they cannot be automated by identified services), we found that a ratio 90% of collaboration activities can be automated using identified services. Detailed analysis of the remaining 10 % reveals that they meet one of these two criteria:

• 1) They are part of a conversion (sub) processes in the PVC (e.g., the distribution and the maintenance processes). Those activities were intentionally ignored since our method does not deal with conversion processes.

• 2) They are not shown in the BPMN model. For example, some activities are part of a bundled sub-process or an external partner private process.

6.4 Threats to the validity

In this subsection, we discuss issues that might have affected the validity of the experiments. For this study, we consider threats to internal, external, and construct validity as discussed in [42].

6.4.1 Internal validity

The threats to internal validity compromise the confidence to confirm a relationship between the independent and dependent variables. This is relevant when the study’s goal is to establish a causal relationship between those variables. Threats to internal validity in this study are mainly related to the participants’ experience and the information exchange among them.

Threats related to experts’ profiles might impact questions and services evaluations. To mitigate this threat, we defined a minimum skill set to be met by participants. Experts’ selection was based on strong professional experience and knowledge background especially in business analysis and COBP modeling for the first study (i.e., questions evaluations) and in the SOA style for the second study (i.e., services evaluations). To mitigate the impact of information exchange, the experiment took place in a controlled environment in which the participants were monitored.

6.4.2 External validity

Threats to external validity might compromise the confidence to determine that study’s results can be generalized. The primary external threat arises from the possibility that selected COBP could be non-representative of other business processes. To address this issue, we analyzed 20 COBPs from different domains. Then we selected the 5 most common COBPs that represent different levels of complexity in different business domains and are the most used in enterprise resource planning systems (see [39]). However, the results might be valid only for the analyzed processes, and further replications are needed to improve the generalizability of the results.

6.4.3 Construct validity

The construct validity of the two studies might have been influenced by the selection of variables we used as a proxy of the different hypotheses. The main threat the construct validity is the selection of the variable to validate whether the method does not require specific technical skills. We used as a proxy for this construct a question asking the experts whether they perceive the question was easy to answer. An affirmative answer to this question does not necessarily mean that the approach does not require SOA technical skills, and we cannot assure that the participants had no previous SOA expertise. Therefore, further replications of this study with more in-deep questions are needed to be able to validate this point. Moreover, the use of bi-valuated variables might impose a dichotomy on the answers, in further evaluations or replications we will use 5 or even 7-point Likert scales to gather more fruitful information.

7 Conclusion and future work

Today’s business processes become increasingly complex and often cross the boundaries of the organizations. These processes (COBPs) often require the coordination of several organizations and must take into account collaborative scenarios. To support COBPs, modern organizations develop what we call PAISs. One emerging approach to design PAISs is the use of SOA. However, designing such SOA-based PAISs is not trivial considering the large gap between COBPs and PAISs.

In this paper, we proposed a semiautomatic approach that bridges the gap between COBPs and SOA-based PAISs that support them. The proposed approach uses a model-driven development method to identify and design services using SoaML language from COBP models expressed in BPMN.

We showed the feasibility of our approach by developing a proof-of-concept that relies on open-source software. We also conducted empirical studies with business analysts and SOA architects as a first step toward the empirical validation of the approach. The first study confirmed that we had achieved our first goal of designing an approach that is easy to use without having to become SOA architect or BPM experts. The results of the second study confirmed that (i) the services identified by our method are relevant, (ii) the associated patterns are correct and can specify services, and (iii) the identified services automate selected COBPs.

While this paper establishes guidelines to advance our long-term research program that consists of providing organizations with a method, tools, and techniques that characterizes the transformations from COBP models to SOA-based models, much work remains to be done. Our next challenges are: (i) elaborate the approach to map business information services to business patterns automatically, (ii) fully support of the SoaML profile, (iii) develop a tool that supports the approach, and (iv) validate the approach in the context of a larger catalog of COBP models.