1 Introduction

Since the 70’s, Collaborative Networks of Organizations (CNO) have evolved from single workshops collaborative situations to inter-organizational collaborations [1]. This evolution could be easily explained by the development of new technology. Indeed, a set of heterogeneous organizations, geographically distributed, could instantaneously exchange information in order to achieve common or compatible goals thanks to computer networks. Nevertheless, organizations are still heterogeneous by nature (mission, equipment, culture, vocabulary, etc.). To be efficient, they have to collaborate, or at least coordinate their actions, in order to build a coherent way to reach the shared goal of the CNO.

Although the new technologies have pushed the boundaries of CNO, in terms of variety of forms, geographical distribution, variety of data to manage, the CNO life cycle is always composed of five main stages [2]:

  1. 1.

    Creation: can be divided into two parts, namely (i) initiation and recruiting, dealing with the strategic planning and (ii) foundation, dealing with the constitution and start up

  2. 2.

    Operation: the “normal” stage of the CNO existence.

  3. 3.

    Evolution: when small changes in membership, roles, or daily operating principles happen.

  4. 4.

    Dissolution: when the CNO ceases to exist.

  5. 5.

    Metamorphosis: when major change in objectives, principles, and membership take place, leading to a new form of organization.

The need for information management all along the CNO lifecycle is obvious as underlined in [3]. Even if it is exposed with a manufacturing point of view in [3], the Challenge 3 could be defined in any domain: “Challenge 3: ‘‘Instantaneously” transform information gathered from a vast array of diverse sources into useful knowledge for making effective decisions”.

This challenge is crucial to ensure the success of CNO especially due to the fast development of new technology that produces amounts of data. Indeed, amounts and variety of data arose from the development of domain ontologies and the development of Internet of Event (IoE). According to [4, 5], IoE could be divided in four sources:

  1. 1.

    Internet of Things: all physical objects connected to the network. This includes all things that have a unique id and a presence in an Internet-like structure. Things may have an Internet connection or tagged using Radio-Frequency Identification (RFID), Near Field Communication (NFC), etc.

  2. 2.

    Internet of Location refers to all data that have a spatial dimension. With the uptake of mobile devices (e.g. smartphones) more and more events have geospatial attributes.

  3. 3.

    Internet of People: all data related to social interaction. This includes e-mails, Facebook, Twitter, forums, LinkedIn, etc.

  4. 4.

    Internet of Content: all information created by humans to increase knowledge on particular subjects. This includes traditional web pages, articles, encyclopedia like Wikipedia, YouTube, etc.

According to [6], the information management all along the CNO lifecycle could refer to a big data challenges. Indeed, “Big data is a set of techniques and technologies that require new forms of integration to uncover large hidden values from large datasets that are diverse, complex, and of a massive scale”[6] and Big Data is characterized by 4V: volume, variety, velocity and value. Value refers to the process of discovering huge hidden values from large datasets with various types and rapid generation of more valuable information that is similar to the challenge 3.

Talia [7] pointed out that obtaining useful information from large amounts of data requires scalable analysis algorithms to produce timely results. As researchers continue to probe the issues of big data in cloud computing, new problems in big data processing arise from the transitional data analysis techniques. The speed of stream data arriving from different data sources must be processed and compared with historical information within a certain period of time. Such data sources may contain different formats, which makes the integration of multiple sources for analysis a complex task [8].

Moreover, due to the heterogeneity of organizations and the CNO lifecycle, the information management has to be defined without requesting a change for the organization. Therefore a middleware is needed [9] and, as explain in [10], target architecture for this middleware is Service Oriented Architecture (SOA). SOA is composed of several components and the SOA governance is in charge to manage the lifecycle of the middleware.

Even if there is lots of work on the SOA governance [11–13], the alignment between organization (business aspect) and SOA (technical aspect) starts from processes and there is a lack concerning the information management, especially how to generate valuable information from incoming data, and process adequacy with the objectives of cross-organization.

A framework is proposed in this paper in order to fill the previous lack. This framework is a novel approach to reach the goal to manage data and information in order to help CNO to make effective decisions all along their lifecycle. This approach aims to define a business governance as an extension of the SOA governance in a Service Oriented Architecture.

The remainder of this paper is divided into two sections. Section 2 identifies the objectives of the framework in order to list the required functionalities and before concluding, Sect. 3 presents the architecture of the framework.

2 Objectives of the Framework

In order to reach the Challenge 3 and thus to help CNO to make effective decisions, the aim of the framework is to build snapshots of the reality. The idea of snapshots is to have pictures of the world state that is composed of all information related to a specific CNO context. There are at least three kind of snapshots:

  • Situational snapshot is a picture of the world state and it is independent from CNO activities.

  • Expected snapshot is a picture of what the CNO expect to obtain after executing activities.

  • Forecast snapshot: what the situational snapshot or expected snapshot looks like in future.

By comparing information embedded into each snapshot, the CNO could make effective decision. Figure 1 represents an overview of the comparison principles over the time.

Fig. 1.
figure 1

Overview of the use of snapshots in order to help CNO to make effective decisions.

Full size image

To illustrate the benefits of the comparison, it is possible to take a common example as in criminal stories. A murderer exists; his picture is the situational snapshot. Policemen don’t know exactly how the murderer looks like but based on gathered information, they build a facial composite, which is the expected snapshot. If the facial composite is closed to the picture, the policemen have a chance to capture the murderer. Another example is when you are looking for someone for a long time; it is possible to generate a new picture, the forecast snapshot, thanks to accelerated ageing models based on a picture or a facial composite.

Another example in CNO context could be the following: several organizations want to produce together a product and so they define a production process. Based on this process, the supplier has to finish a part of the product two weeks after the beginning of the process but it has a technical malfunction. Therefore thanks to a comparison of forecast snapshots, it is possible to find the impact at the end of the process and thanks to comparison between situational and expected snapshots, it is possible to detect the problem as soon as possible.

Nevertheless, each snapshot depends on time. Therefore, snapshots have to be either changed directly by user or indirectly by the use of IoE, results of CNO activities.

Therefore, the framework has to propose the following functionalities:

  • Compare snapshots.

  • Propose forecast snapshot (based on simulation).

  • Transform data into information (in order to update snapshot).

These functionalities have to be built in compliance with the problematic of heterogeneity of data and the evolving aspects of CNO. Therefore it is necessary to generate and manage snapshots by transforming and combining amounts of data without manual effort.

3 CNO Governance Principles

3.1 Snapshot and Models

This section describes the architecture of the proposed framework in order to fit with the functionalities identified in the previous section. The main purpose of the framework is to manage snapshots in order to update and compare them. Therefore, each snapshot needs to be understandable to the same (or at least similar) structure. For this reason, a model will represent each snapshot because a model “represents reality for the given purpose; the model is an abstraction of reality in the sense that it cannot represent all aspects of reality. This allows us to deal with the world in a simplified manner, avoiding the complexity, danger and irreversibility of reality” according Rothenberg [14]. However to be comparable, a model has to be written according to a specific language, shared by several users, called metamodel [15].

Accordingly, each snapshot is a model and each model is conform to a metamodel. Nevertheless it is obvious that defining one metamodel able to cover all CNO contexts is a pipe dream. But for one given CNO context, it is possible to have one metamodel describing all information. For this purpose, the framework is based on the core-metamodel presented in [16], which is an extendable metamodel from generic concepts of collaboration to a definition of specific context (such as road management in winter period).

Finally, the objectives of the CNO governance are (i) to update models based on information provided by users, IoE or CNO activities, (ii) to compare models, (iii) to simulate in order to build forecast models and (iv) to design collaborative behaviour in order to merge, when it is needed, the expected and situational models.

The last point is in conformity with the lifecycle of CNO, especially the creation, evolution and metamorphosis stages. The chosen model to represent the collaborative behaviour is the process model in BMPN. Indeed, process model aims to capture the different ways in which a case can be handled. Process model is composed of ordering activities and could be described with temporal properties, creation and use of data and resources [17]. Hence, the simulation could be based on process model in order to build forecast models. Moreover, on-going research works [18] and [19] propose a methodology to build collaborative processes based on collaborative aims.

3.2 Framework of CNO Governance

Figure 2 represents the proposed framework. It is divided into three main layers in order to support all the previous identified functionalities and thus reach the aim of “Instantaneously” transform information gathered from a vast array of diverse sources into useful knowledge for making effective decisions”.

Fig. 2.
figure 2

Overview of the CNO governance framework.

Full size image

Agility layer:

Numerous authors largely discussed the notion of agility. The Collins dictionary defines agility as the power of moving quickly and easily. For Badot [20], agility is a reconfiguration of the system to satisfy a need of adaptation. For other authors, such as Kidd [21], Lindberg [22] and Sharifi [23] agility is a need of flexibility, responsiveness or adaptability. In logistics, flexibility is seen as “the ability to meet short-term changes” [24] and is differentiated to the over time adaptation in response to a change [25]. Therefore, the agility layer of the framework is in charge to ensure (i) the assessment of the need for CNO to evolve or to metamorphose, (ii) the help to adapt the CNO.

Hence the agility layer is divided into three components:

  • Model comparison: this component evaluates at any time the divergence between the expected model and the situational model. If the value of the divergence is higher than a threshold value, an alert is sent to the detection component.

  • Detection: this component is in charge of analysing the divergence and thus defining the new objectives of the CNO. This analysis is possible because the situational model and the expected model are defined based on the same metamodel. The result of this analysis is sent to the collaborative process design component.

  • Collaborative process design is the component in charge of adapting or defining new collaborative process. This deduction is based on the result of the detection component. The result of this component is composed of two models, which are (i) the collaborative process and (ii) a mapping between CNO activities and objectives. This second model will be reuse in the Updating layer (see below) in order to update the expected model.

This layer was defined in previous research works. The mechanisms of the model comparison and detection components were described in [26], and [18, 19] present a solution for the collaborative process design component.

Simulation layer:

This layer aims to produce a forecast model of the situational model and of the expected model, in order to apply the agility layer to the two forecast models. Hence it is possible to anticipate, instead of react, an evolution.

The two forecast models are obtained thanks to manipulation of existing information, e.g. existing model, or by the result of a simulation. The idea of this layer is inspired from the results of the European funded CRISMA project [27].

Updating layer:

This layer has a simple but difficult objective to achieve: build both situational and expected model from data. The difficulties arise in the variety and the amount of data sources. Three main kinds of data sources could be identified (i) IoE, (ii) data from users or their ontologies and (iii) the achievement of CNO activities, e.g. the progress of the collaborative behaviour. This variety of data sources implies issues concerning (i) Trust management, especially regarding IoE (especially Internet of person), (ii) comparison of data due to the heterogeneity of semantics and levels of description, e.g. granularity issue.

In order to achieve this simple objective, the Updating layer is divided into seven components:

  • Trust Management: this component aims to filter no-trustable data. For instance, if a sensor always sends the same expected value during one second, thus we have a Dirac delta function. This value may be wrong and the governance does not have to take it into account. Trust management is more complex than just this example as explains in [28].

  • Information function: this component is the key point of the governance. It aims at transforming data to information. This component is compliant with Big Data challenges [6] to automatically define the transformation from data to knowledge. However, it is possible to manually define information function that transforms data into information. For example, if sensors could send the heart rate and another could send the body temperature of a human being, it is possible to deduce if the human being is ill or not. Indeed, if his/her body temperature is above 39 °C (fever) and his/her heart rate is above 120, so he/she is ill.

  • Model Adaptation: this component is used to update the situational model. Based on information generated by Information function component, the situational model is updated thanks to principles defined in [26].

  • Compare to process deduction: this component is used to update the expected model. As described in [26], this update is possible thanks to information generated by Information function component and the model defining mapping between CNO activities and objectives.

  • Process state: this component is used to also update the expected model based on the progress of collaborative process. This is allowed thanks to the model defining mapping between CNO activities and objectives.

  • Information added by user: this component allows user to directly add, remove or modify information from the situational or expected models.

  • Semantics reconciliation is needed because we cannot assume that each user and/or each information function will generate information based on a coherent glossary or taxonomy. A semantics reconciliation component is used with the aim to unify semantic as well as the level of description, e.g. the granularity level, of information. This component is based on work described in [29].

4 Conclusion and Next Challenges

This paper presents a framework for CNO governance that aims to support CNO all along their lifecycle. Especially, the objective of the governance is to “Instantaneously” transform information gathered from a vast array of diverse sources into useful knowledge for making effective decisions. In order to achieve this objective, the idea is based on snapshots of the reality that allow CNO to make a comparison between the situational state and the expected state from the CNO point of view. This comparison is possible if data provided by various heterogeneity sources could be filtered (using trust principles), aggregated, and transformed into information.

In order to achieve the objectives of the governance, a three-layers architecture is proposed. The agility layer aims at detecting divergence between CNO behaviour and reality and then deducing a new version of the CNO behaviour. The simulation layer aims to make forecast in order to anticipate evolution. The updating layer is the key point of the governance. It aims to manage a huge number of data from various sources in order to produce information usable by other layers.

This framework is based on the result of three PhD works, two on the agility layer and one on the updating layer. Each PhD provides theoretical solution and a demonstrator. Our future work consists in merging the demonstrator and developing the simulation layer.