1 Introduction

In the last decade, the conjunction of Business Process Management (BPM)  [1,2,3] and Systems (BPMS) [4], with Service Oriented Computing (SOC) [5] and Architecture (SOA) [6, 7] proposals, has gained many adepts both in industry and academy, as an straightforward way to connect Business Processes (BPs) with the services implementing them. Nowadays collaborative and virtual organizations need increasingly support to enact their collaborative BPs, fulfilling both centralized and decentralized scenarios, which depend on the organizations involved and/or the restrictions of their collaborative BPs and technologies.

The SOC paradigm helps in solving this problem by designing specific software pieces i.e. services, providing desired qualities such as lose coupling, high cohesion, easing interoperability, normalizing data exchanges (i.e. types and format), explicitly defining interfaces for interactions between systems, among others. Also, collaborative BPs can be modeled and executed in a notation such as Business Process Model and Notation (BPMN 2.0) [8], or as services composition  [6, 7] with the Web Services Business Process Execution Language (WS-BPEL) [9] if the execution is fully automatic (i.e. no user interactions).

Collaborative organizations sharing common goals  [10] are focused on integrating their software systems in order to exchange data and execute business functions setting up their business processes (BPs)  [1,2,3]. This collaboration can be of two main types: (i) organizations are part of a collaborative environment in which the interactions between BPs and services are explicitly defined and agreed; or (ii) organizations offer capabilities for integration, not explicitly agreeing on their BPs but mainly on the contract of the services they expose or require to be able to participate in the collaborative environment.

A BPMS provides a complete platform to execute BPs by means of human tasks interacting with users and automatic tasks invoking services when needed, allowing the interaction between different participants. Integration platforms are specialized middleware-based infrastructures, notably Enterprise Service Bus (ESB) to support the implementation of a SOA [11], providing an intermediate processing layer between applications and services with the goal of facilitating integration issues. This middleware can be integrated with BPMS platforms helping supporting both types of collaborative scenarios as defined in (i) and (ii).

Also, in order to support the realization of human tasks within the BPMS, it would be useful to include mainstream social platforms such as Facebook, Twitter, LinkedIn and Google+, for employees involved in the BPs and for external users interacting with the platform. These capabilities would help, for example, to notify users when some activities need to be performed by employees or when user’s participation is required to complete a process activity, among others.

In this paper we present a proposal for setting up a collaborative environment, both methodological and technological, in which organizations (e.g. in e-government) can interact based on their BPs and services implementing them. At the center of the proposal we defined: (i) a reference architecture for a process-aware inter-organizational service integration platform (PA-IOSIP) which is mainly based on the conjunction of a BPMS platform with an integration middleware infrastructure (e.g. ESB)  [12], and (ii) a maturity model which provides a roadmap to guide the efforts towards setting up such a collaborative environment between willing organizations, taking into account several dimensions such as the different type of participating organizations, their infrastructure, collaborative processes, among others.

The rest of the article is organized as follows: In Sect. 2 we present related work. In Sect. 3 we analyzed several collaborative scenarios to be supported by our PA-IOSIP. In Sect. 4 we describe our proposal including the definition of the maturity model, the dimensions and elements we have defined within them. In Sect. 5 we present a case study based on the implementation of a collaborative BP carried out within the Uruguayan e-government, as a proof of concept. Finally in Sect. 6 we present some conclusions and future work.

2 Related Work

In [13] we presented a systematic literature review of existing approaches to support services and BPs lifecycle, with focus on modeling, design and execution, but few of them succeeded in linking services to the BPs lifecycle [14] in an integrated manner. From the technological point of view, some proposals support the execution of collaborative BPs and services, but mainly with their own implementations of BPs engines and platforms.

Several well-known maturity models were defined for software process improvement such as Business Process Maturity Model [15], Capability Maturity Model (CMM)  [16] and the Capability Maturity Model Integration (CMMI) [17]. These are reference models for evaluating the maturity and capacity of an organization, with regards to key elements as defined in each case. We also analyzed several proposals for collaborative and integration frameworks and platforms, including specific proposals for e-government which constitutes our real context for prototyping the proposal [18,19,20,21,22].

In [19] an e-Government Maturity Model which integrates the assessment of technological, organizational, operational and human capital capabilities is proposed. The model is structured around four domains: “e-Government strategy”, “IT governance”, “process management” and “organization and people”. The “process management” domain comprises the following key domain areas: business process management, performance management, services to citizen and business, interoperability, compliance, and quality and security assurance.

In [20] a BPM maturity and adoption model is proposed to guide organizations to process maturity, identifying six-phases for BPM maturity and adoption: acknowledge operational inefficiencies, become process-aware, establish intraprocess automation and control, establish interprocess automation and control, establish enterprise valuation control and create an agile business structure.

Compared to our proposal, these models are broader so they are not as specific as ours in issues related to BPMS adoption and services interaction. Also, the application of these models is intended to be performed individually for each organization. In contrast, our proposal is intended to be applied to the whole collaborative environment, considering each participating organization.

3 Collaborative Environment Scenarios Analysis

The context of analysis is a group of organizations that collaborate through a Process-aware Inter-organizational Service Integration Platform (PA-IOSIP) as described in [12]. We analyzed several collaborative scenarios (which we defined based on our knowledge of the real context for e-government) with different combinations of BPs maturity and infrastructure, and social media capabilities and challenges in the complexity of the context.

The integration platform defines three main layers [12]. The top layer corresponds to the User applications layer which provides users with several applications to interact with the BPs executing in the integration platform, and also with other components such as documents and business rules. The middle layer corresponds to the BPMS layer which provides components to support the BPs lifecycle including modeling, implementing, executing, evaluating and improving processes. Finally, the bottom layer corresponds to the Integration layer which includes components to facilitate different aspects (e.g. security, connectivity, metadata) for achieving an interoperable cross-organizational collaboration.

3.1 Scenarios for the Collaborative Environment

The analysis of scenarios for the collaborative environment was based on defining different combinations of the participant organizations capabilities and their interaction with the central integration platform. In Fig. 1 we show two of the scenarios analyzed: an initial scenario (with few capabilities) and a high level scenario (with more complex capabilities). The analysis starts with the initial scenario going up through the high level scenario by adding complexity and capabilities in the participant organizations, the integration platform and the infrastructure involved.

Fig. 1.
figure 1

Example of scenarios analyzed for the collaborative environment

Full size image

As shown in Fig. 1(a), the first step to set up this collaborative environment is to provide an integration platform that allows participant organizations to interact within each other through it. This integration platform provides several components (e.g. security, connectivity, metadata) for achieving an interoperable cross-organizational collaboration, mainly based on services integration with no BPMS platform. There are some organizations that has integration capacities and therefore can be partially integrated in the collaborative BPs, and there are other organizations that does not present these capacities.

The most advanced organizations will present not only integration capacities but also provide BPMS support for collaborative BPs, interacting with other organizations by means of the integration platform. A web portal for interacting with clients/partners is mandatory even at this early stage, providing at least initiate and query capacities for their processes. Social media integration with users is desirable at least for external users from the web portal.

At the high level scenario shown in Fig. 1(b), the BPMS support for collaborative BPs will be spread within the complete collaborative environment (as a signal of BPM maturity), also adding a central BPMS at the integration platform. All participating organizations will present integration capacities, and BPMS support, although BPMS providers could not be the same for all participants. In  [23] we propose a methodology that helps organizations in choosing the most adequate BPMS for their needs, based on their infrastructure and specific requirements (functional and non functional).

Processes execution will be hosted and carried out within the BPMS of the process owner in each case, interacting in a (mostly) asynchronous way with the rest of the BPMS via the central integration platform. The web portal for external users should allow specific queries regarding process execution, even if the execution is at that moment within another organization’s control. For this, identifying the best way to chain the invocations through participants of the collaborative BP by means of the integration platform is a key element. Social media will be in place not only for external users, but also for organization’s employees to execute tasks within the BPMS platform.

Between the initial scenario and the high level scenario several other intermediate scenarios take place, as the participant organizations continue growing their capacities to interact within the integration platform, to specify, model, implement and execute their own internal BPs in a BPMS platform and also taking part in the collaborative BPs defined at the integration level, including social media interaction with employees and external users, among other elements.

3.2 Scenarios for Social Media Interactions

As pointed out in [24] it is reasonable to combine BPM with social software as a way of improving users interactions. However, there are still few studies on how BPM benefit from social software in practice. As an example, in [25] the authors propose a BPMN extension for expressing social interactions like direct messaging, broadcasting and voting, but they did not take these ideas into action. In an collaborative environment, it is necessary to think about how external users (e.g. citizens in an e-government case) can interact with the execution of a BP from their social networks of daily use. In this context, we explored interaction mechanisms from three of the main social networks (Facebook, Twitter and Google+) within the execution phase of a BP. In Table 1 we identify common interactions between users and the execution of a BP through web media.

Table 1. Common interactions through web access media
Full size table

In the e-government context for example, it could be useful for a citizen to enter the web portal and view available processes, to query processes by name and category with respect to its specific needs, and also view process information. From this list of processes, a citizen can create a process instance providing the information to initiate it, or use a specific social network for starting it, e.g. by sending a tweet or filling a Facebook or Google+ form. The citizen could also want to check the status of its request, thus it is important to list created instances for an user and provide a way to view historical data from an instance. These functionalities can be provided in a classical way from the E-Government portal, or for example from an embedded Facebook application which requires the user to use its network-specific credentials for login.

There are many kinds of notifications within processes. In this social environment, the user can follow the public profile of an organization to access news, or the process can send direct messages, e.g. a tweet to the user, or a Facebook message of a private publication in the wall. An interesting interaction arises when an organization needs to arrange a meeting with the user. In this case the user can receive an invitation to a private Google Calendar event, and also receive an automatic reminder when the meeting date is near. Alternative, a public calendar can be used.

Process information can take the form of documents which can both assessed when the user queries the information of a specific instance and from central repositories like Google Drive. In some cases, the user needs to send a confirmation with respect to some activity in which he/she is involved. This can be done by notifying the user by publishing a private message in its Facebook wall and then using the Like button. In the case of meetings, it is also possible to use Google Calendar confirmations. Finally, a social intensive functionality is voting in which users can take collaborative decisions or respond to surveys. The three social networks provide fully customizable forms for polling and processing their results.

4 Setting up a Collaborative Environment

Based on the analysis of collaborative environment scenarios we discussed in Sect. 3, and on the analysis of existing proposals, standards and approaches for the definition of integration platforms and collaborative environments, we have defined the following research question: How can a collaborative environment between interacting organizations be set up considering both methodological and technological requirements by defining key elements that when achieved, guarantee an integration compliance level between participants?

We have also defined sub-questions to guide our research work, mainly focused on the reference architecture for an integration platform, the maturity model and the case study for validation. We applied research methods suitable for each phase, starting with an extensive analysis of existing proposals (systematic literature review, existing standards and approaches for integration platforms, maturity models). For the definition our proposal, we followed design science principles [26], creating artifacts: (a) reference architecture for an integration platform, (b) maturity model to guide the efforts in setting up a collaborative environment within (a), and (c) case study within the uruguayan e-government as a proof of concept for (a) and (b).

4.1 Reference Architecture for an Integration Platform

The reference architecture defines a Process-aware Inter-organizational Service Integration Platform (PA-IOSIP) [12], as introduced in Sect. 3. In particular, the platform provides support for collaborative BPs and services execution within a controlled distributed environment (e.g. e-government, e-health) where organizations communicate through a private network and there are formal agreements between participants. It can also be an open one (e.g. e-commerce, e-science) where participants collaborate via Internet without explicit agreements. The reference architecture for the integration platform details can be seen in [12].

4.2 Maturity Model for Collaboration

The maturity model we have defined is based on key definitions of the maturity models BPMM, which in turn is based on the CMM and CMMI, taking into account the analysis of scenarios in Sect. 3. The main objective of the maturity model is to guide the efforts to set up a collaborative environment within the reference architecture for the integration platform, by evaluating the maturity of the whole set from the point of view of the integration platform. For this, we considered meaningful dimensions that we have identified from the scenarios analysis. The maturity model defines five levels of maturity, following the definitions of the maturity models of reference. In Table 2 we present the general definition of the maturity model.

Table 2. Levels defined in the maturity model for a collaborative environment
Full size table

We identified five dimensions of interest for the analysis: (i) Maturity of each participant organization, (ii) Level of integration and interoperability within the platform, (iii) Support for BPMS and collaborative BPs, (iv) Central portal for external users interaction and (v) Support for social media integration. The summary of the maturity model is presented in Fig. 2 showing the levels and dimensions.

Fig. 2.
figure 2

Maturity model with dimensions and definitions for each level

Full size image

Maturity of Each Participant Organization. It defines the capacity that each organization has to interact with the integration platform and collaborate with other participants. The maturity of a participant organization is based on BPMM definitions and the extensions we made: (i) infrastructure support for the integration and interoperability within the platform, and (ii) support for collaborative BPs execution in a BPMS platform. The compliance for each level is measured by the percentage of the organization BPs that are supported.

Level of Integration and Interoperability Within the Platform. This dimension looks at the collaborative environment from the integration platform point of view. Bearing in mind the reference architecture we have defined for such platform, including BPMS and middleware, we define it at each maturity level considering the number or participant organizations that are integrated and effectively collaborating through the integration platform.

Support for BPMS and Collaborative Process. This dimension also takes the integration platform point of view. We evaluate the support for collaborative BPs provided by the general collaboration by means of BPMS support for BPs execution within all organizations and the integration platform. The final target is to provide a central BPMS within the integration platform to host general collaborative BPs, and also BPMS support in each participant organization, decentralizing all processes.

Central Portal for External Users Interaction. This dimension takes into consideration the support provided by the collaborative environment to external users (e.g. citizens) to interact with it. A central portal allows to initiate BP cases, query existing cases to retrieve the current state, the current executing task, among others. To do so, a key element is to define a traceability mechanism for collaborative BPs execution, for example, where each BP registers key data when it gives control to another participant.

Support for Social Media Integration. This dimension takes into account the support the integration platform provides for interaction via social media mainly for external users and organization’s employees. The BPMS platform must be able to include for example notifications via twitter and messages and publications via facebook, providing users with a friendly way to track and be informed about the execution of their BPs, also interacting via the web portal with these platforms.

5 Proof of Concept

We have implemented a prototype of a real collaborative BP within the Uruguayan e-government [27], the “Born Alive” process, to develop a proof of concept of the reference architecture applying the maturity model we have defined. For doing so, we have integrated different technologies simulating the context of the integration platform and participant organizations. The collaborative BP involves several government agencies such as: Health Ministry (owner), Social Security Institute, Social Services Ministry, National Registry. We have already analyzed this collaborative BP but from another point of view in [28].

We will focus here in the description of the infrastructure distribution, integration and capabilities provided by the participant organizations and the central integration platform, by means of implementing the reference architecture at the maturity model level Three. Further validation of the maturity model will include the definition and analysis of measures to be able to navigate to levels Four and Five for continuous improvement of collaborative BPs, infrastructure and services. We implemented the reference Architecture with two open source BPMS: Activiti BPMSFootnote 1 for the Health Ministry, and Bonita BPMFootnote 2 for the central integration platform, and as middleware platform the Red Hat Jboss FuseFootnote 3. We selected Activiti and Bonita since they provide similar functionalities with a very different approach (Activiti with focus on java developers and Bonita with focus on automating the development), to evaluate their integration in a real collaborative environment. In Fig. 3 we present the general definition for the prototype implementation.

Fig. 3.
figure 3

Architecture and technologies used for the prototype implementation

Full size image

Both Bonita and Activiti BPMS provide a REST API which allows interaction with the process engine from the middleware platform and the web portal. The integration platform exposes services as SOAP Web Services (mainly for security reasons) and invokes the REST API from the central BPMS (Bonita) or the MSP one (Activiti) when needed. All interactions between participants (with each other or the integration platform) goes through the middleware platform (as defined in the e-government infrastructure). Invocations and answers to/from other participants are simulated to execute the process completely. The middleware platform has definitions for routing the messages received within the SOAP WS, to the corresponding message queue and/or to invoke the REST API of the corresponding BPMS (e.g. to send a message).

We have also prototyped the social interactions described before with respect to the BP executed in Activiti BPMS. Social networks interact with the process engine through the REST API provided by Activiti, and every interaction from the process is encapsulated in Java classes in such a way that internal users of the e-gov platform are unaware that they are interacting with social networks. We have created specific social network accounts representing governmental dependencies and we configured them so they can use external applications that we provided for some specific interactions. In reply, the social networks provided us with authentication tokens that Activiti needs to interact through the WS they provide for interaction.

The proof of concept allowed us to put in place the needed infrastructure to set up a collaborative environment of maturity level three, following the definitions and guides defined in the maturity model. The middleware platform was integrated seamlessly with Bonita as the central integration platform, and Activiti was deployed as part of one organization, interacting with the integration platform, via SOAP/REST WS and messages. We tested integration with social networks for both external users and employees. We conclude that the definitions in the maturity model help defining what is needed to set up a collaborative environment.

6 Conclusions

This paper presented a proposal for setting up a collaborative environment to support the interaction of organizations within an integration platform. We defined a reference architecture for such an integration platform, and a Maturity Model which provides a roadmap for implementing collaborations within it. The maturity model provides key guide for the progressive implementation of the reference architecture in a collaborative environment, and how to evolve it to improve both infrastructure and collaborative BPs support.

Several scenarios were analyzed to help identifying the main elements to be considered by the model. The proposal was applied for the implementation of a collaborative BP within the Uruguayan e-government, which served as a proof of concept for the proposal, including social media integration. We believe that the proposal constitutes a step forward in providing guidelines to set up a collaborative environment. Future work will be extending the case study to higher maturity levels, and to carry out more case studies in other real environments, to continue evaluating the usefulness of the proposal.