# Negotiations Framework for Monitoring the Sustainability of Interoperability Solutions

Carlos Coutinho, Adina Cretan, Ricardo Jardim-Gonçalves

► To cite this version:

Carlos Coutinho, Adina Cretan, Ricardo Jardim-Gonçalves. Negotiations Framework for Monitoring the Sustainability of Interoperability Solutions. 4th International Working Conference on Enterprise Interoperability (IWEI), Sep 2012, Harbin, China. pp.172-184, 10.1007/978-3-642-33068-1_16 . hal-01515746

HAL Id: hal-01515746

https://inria.hal.science/hal-01515746

Submitted on 28 Apr 2017

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
# Negotiations Framework for Monitoring the Sustainability of Interoperability Solutions

Carlos Coutinho¹, Adina Cretan², Ricardo Jardim-Gonçalves¹

¹ CTS, Departamento de Engenharia Electrotecnica, Faculdade de Ciencias e Tecnologia, Universidade Nova de Lisboa, Portugal
c.coutinho@campus.fct.unl.pt, rg@uninova.pt

² Computer Science Department, “Nicolae Titulescu” University of Bucharest, Romania
badina20@yahoo.com

**Abstract.** The competition inherent to globalisation has led enterprises to gather in nests of specialised business providers with the purpose of building better applications and provide more complete solutions. This, added to the improvements on the Information and Communications Technologies (ICT), led to a paradigm shift from product-centrism to service-centrism and to the need to communicate and interoperate. Traditional segments like banking, insurance and aerospace subcontract a large number of Small and Medium Enterprises (SMEs) that are undergoing this change, and must ensure the criticality and accuracy of their business is not affected or impacted in any way. This paper proposes a methodology and a framework that provide critical businesses a control mechanism over the interoperability solutions in place on their subcontracted enterprises, imposing negotiations which formalise the solutions applied. It then focuses on its application on the business case of the Concurrent Design Facility of the European Space Agency (ESA-CDF).

**Keywords:** Sustainable Enterprise Interoperability, Negotiations, Control, Aerospace.

## 1 Introduction

The service globalisation perpetrated by the Internet has led to a need for change in the traditional businesses. Market terms and conditions dictate a constant need to change and adapt to new environment conditions, new paradigms and solutions, platforms and technology solutions, trends and fashions. Thus, being the best-of-breed no longer means being the most efficient or having the highest performance, it means keeping up with the look & feel trends, being available in many platforms and heterogeneous environments, i.e. implicates a continuous change. Many manufacturing enterprises currently have a very clear update and delivery schedule plan, e.g. when deploying a new car model, it is possible to know what the next version(s) of that car will look like and what it shall feature.

This heterogeneity, constant change and subsequent need for interoperability are worrying traditional business areas like finances (banking, insurance), aeronautics and aerospace, which usually tend to be very conservative towards change on account to
accuracy and stability. As an example, the aerospace industry is served by a small set of large enterprises that implement projects and missions, and which then subcontract several Small and Medium Enterprises (SMEs) for supporting their development, thus creating a network of dependencies. The need for interoperability with the other players in these networks is as crucial for staying in business, as the ability to do so while maintaining the proprietary business assets protected from the competition.

The evolution of ICT permitted faster, more secure and robust data exchanges, promoting the development of solutions as result of the contributions of the several enterprises working in a network, thus allowing the gathering of multiple competences and expertise into higher-valued products and solutions. Emerging paradigms like the Internet of Things [1] (IoT, which is reshaping the world in the form of categorized discoverable items) and the Internet of Services [2], [3] (IoS), together with the evolving cloud computing's concepts [4] of Infrastructure as a Service (IaaS), Platform as a Service (PaaS) and Software as a Service (SaaS) are gradually transforming the existing reality into a set of available commoditised virtual objects, services, enterprises and networks.

This increase of availability and demand of combined solutions removed all traditional boundaries and allowed the specialisation of enterprises (particularly SMEs) and the building of complex and heterogeneous provider networks. This move from product-concentric to service-dispersed strategies is leading to concerns about reaching and maintaining the interoperability.

To large contractors or even final customers like banks and space agencies, which depend on the performance of this network of SMEs to conduct their business, the improvement coming from the specialisation needs to be balanced with the increase on control of the outcomes that result of multiple sources. The misunderstanding of a concept, a change in a data unit, a mistaken method on a single enterprise in the network can lead to chained mistakes on its counterparts and consequently to errors in the final result that are very difficult to detect and even more difficult to trace and resolve.

It is then essential that more than describing data and interface contracts, the interacting enterprises publish their models, ontologies and methods so that their partners can understand and cooperate with them easier. Moreover, it is important that a controlling entity (e.g. the prime contractor or the customer) is able to control if these models and concepts are aligned with the desired outcome.

Section 2 proposes research questions and hypotheses. Section 3 presents a proposed solution. Section 4 describes the application of this solution to the actual business case of the ESA-CDF. Section 5 presents final statements and future work.

## 2 Research questions and Hypotheses

As result of the needs focused on section 1, some research questions are proposed:

* How can businesses monitor and control the interoperability stability and solutions provided by their subcontracted enterprises?

* How can SMEs provide extended information about their operations without periling proprietary knowledge to their competition?
The research conducted proposes the following hypotheses:

* If the interoperability solutions required between the partners in the network are formalised then it will be easier for a contracting enterprise to monitor it and ensure it is aligned with the required purposes;

* To allow the proper control from the contracting enterprise, as well as to allow settling of divergences towards a faster achievement of interoperability with a smaller effort, this formalisation should be shaped in the form of negotiations between the interested parties and also with the influence of the controlling party;

* If the formalisation of the negotiations towards interoperability solutions includes proper encapsulation and access restrictions, then besides handing the important information to the right partners, it will prevent unsolicited data from being exposed.

## 3 Proposed solution

Each enterprise works on its own premises, developing its own business concepts, trades, skills, functionalities and methods. Although the establishment and embracement of standards is becoming more frequent, most of the business knowledge is based on past experiences, other partners' knowledge and new ideas. When two or more enterprises settle in the establishment of a partnership, several of these ideas may collide, which means they need time to harmonise. The relation between the complexities in the interoperation between them and the time and effort that is necessary to solve them is not linear, which means they need to develop a way to optimise this time and effort, thus reducing the time where there is no operation.

The proposed solution combines a methodology and framework that have at its core the need for negotiations in the development of interoperability solutions. These negotiations can have multiple participants (e.g. the partners and the supervision of their prime contractor or customer).

Enterprise Interoperability (EI) concerns the seamless exchange of information that allows an enterprise to perform globally, independently if the exchange of information is internal (between the various departments and parties that compose the enterprise), external (between the enterprise or part of it and an external party), or both [5]. Additionally, EI denotes that the exchanged information is understood in the same way by all of them. While the large prime contractors can determine the interoperability rules towards its network of dependencies, by setting the market standards and compelling the surrounding environment to comply with these standards, SMEs are much more sensible to the variations on their environment.

Achieving a sustainable EI is then [6] an integrated and interactive process of adaptation in a constant and iterative effort to recheck the existing interoperable status, while maintaining the existing interoperability towards the surrounding environment. Knowledge, adaptation and flexibility are therefore the pillars for undertaking a Sustainable EI (SEI).
## 3.1 Framework Methodology

One of the first problems that face interoperability is the detection of the problem itself. For that purpose, the first step of this methodology is to gather knowledge from the interacting parties. To do so, the proposed framework provides a set of questionnaires and interviews with appropriate stakeholders to allow the capturing of the enterprise information. Traditionally, this capture focused only the technological issues regarding interfaces and data formats, tools and ontologies. The authors propose that besides the technology capture, and based on the work of the MSEE project [7], that it is as well important to capture the intangible business needs, the human interactions and behaviours, and the operational use of the technology ("business and people").

The result of the knowledge capture phase is then applied to reference models [8], formalising it into Model-Driven Architectures (MDA [9]) and Model-Driven Interoperability (MDI [10], [11]). Actually, to set the difference to the current MDA and MDI, which the SSME research [12] considers as being essentially focused on the technological assets, the authors propose complementing the MDA and MDI (for the technological items) with a "Business" B-MDA and a "Business" B-MDI to deal with the "business and people" aspects, as can be seen on Fig. 1.

<figure><img src="image_2.png" /><figcaption>Fig. 1. MDA, B-MDA, MDI and B-MDI negotiating the interoperability solutions.</figcaption></figure>

The captured knowledge is then shaped in the form of a Computation-Independent Model (CIM) that describes the foundations for the design and interoperability, e.g. methodologies, functionalities, high-level objectives and visions. A complementing Business-CIM (B-CIM) shall describe e.g. strategies, organisation responsibilities, balance scorecards, HR hierarchies and roles, authorisations, objectives, behaviours and targets for each role. These models are independent of any algorithm or code. They are developed in UML, UEML and OCL to describe the foundations for the design and for the interoperability [13].
The CIM layer can be split into two layers [14]:

* Top CIM (and B-CIM) layers handle the strategic business functionalities, that are stable and conformant to requirements and needs (“as-is”), which include the interoperability needs towards other existing partners;

* Bottom CIM (and B-CIM) layers handle the operational transients and the proposed changes towards new partners, additional self-improvements (due to e.g. adoption of new technologies, supported platforms, lessons learned and best practices) and new interoperability challenges [15].

Then, the CIM is transformed into a Platform-Independent Model (PIM) which handles e.g. terminologies, ontologies, and algorithms, while still independently of any code or underlying platform, and the B-CIM is transformed into a Business-PIM (B-PIM), which handles e.g. operational workflows, management plans, and how each HR role shall fit and contribute in the system. These models shall be specified in the shape of ontologies, knowledge bases and rules.

Finally, the PIM is transformed into a Platform-Specific Model (PSM), producing pseudo-code and code that implements the rules and algorithms, and the B-PIM is transformed into a Business-PSM (B-PSM), resulting in e.g. rule and workflow engines, operational and deployment manuals, work permits, training and schedules.

The framework implements the PSM and B-PSM models in the shape of a set of services [16], as services (and web-services in particular) are considered very flexible, adaptable, reusable [17] and hence, suitable for the purpose of enhancing EI. Services can be developed by several parties, reshaped, versioned, composed and orchestrated, and governed by a Service Oriented Architecture (SOA) [18].

Still facing the flexibility target, the authors propose that the resulting SOA is deployed in a cloud-based infrastructure (IaaS and SaaS) [19]. The decision to develop the infrastructure and services over clouds is to grant the solution with the benefits associated to the cloud business model, which is to have cheap, fast, and on-demand scalable infrastructure and services.

The challenge to achieve a Sustainable EI (SEI) is therefore to build, on top of the currently established services, other services concerning technology, business and people, which provide the ability to rapidly adapt to innovation and imminent changes in the surrounding environment and yet maintain the seamless interoperability towards its ad-hoc network of partners, providers, subcontractors and customers. This pushes EI a step ahead towards its complete life cycle.

Each of the MDI/B-MDI layers presented on Fig. 1 is defined and shaped accounting negotiations. Negotiations in the CIM/B-CIM layer shall comprise business alignment, understanding of roles and strategies. In the PIM/B-PIM layer, negotiations shall deal with understanding the workflows, work packages, harmonising ontologies into a reference ontology [20] and specifying black-box tests. Finally, negotiations in the PSM/B-PSM layer mean dealing with middleware and platform issues, implementing specific policies and rules, interfaces, operational manuals, communication channels, deployment procedures and so on.

On each negotiation, in any of these layers, the problems are exposed and formalised, the benefits are presented and the interoperability solution alternatives are enumerated. The negotiations can then reach several conclusions:

* One of the partners agrees in changing to the other's definition;

* Both partners agree in a compromise solution;
* The partners agree in a solution imposed by the supervisor;

* The partners agree that interoperability can only be achieved via the use of translators and mediators;

* The partners agree that interoperability can only be achieved partially and thus need to redefine the scope;

* The partners agree that interoperability is not possible, not desired or not worth the changes/effort/time needed to achieve it.

This means that interoperability negotiations may start from the very enterprises' foundations, where it is easier to discuss business-related concepts and ideas, and then the progressive steps of transformation into lower-level models may also be synchronised to refine this interoperability, so that the overhead of transforming the concepts into code is performed by automation tools.

## 3.2 Framework Architecture

<figure><img src="image_3.png" /><figcaption>Fig. 2. Architecture of the framework for Sustainable Enterprise Interoperability (SEI).</figcaption></figure>

The resulting framework (Fig. 2) is then composed by a multi-levelled set of services defined over a Cloud SaaS platform adopting the MDA, MDI, B-MDA and B-MDI paradigms, and split into three negotiation levels:
Negotiation level 1 (Bottom – Middleware Services): Technical level, deals with middleware provision, supporting the aspects related with the basic infrastructures, handling the heterogeneity related with multiple negotiation players, which shall interact using an Enterprise Service Bus (ESB) for dealing with technical interoperability issues. It includes services that handle heterogeneity issues on the basic interoperability level (e.g. authentication, permissions, communications, syntax, session, and data), infrastructure and ICT.

Negotiation level 2 (Intermediate – Coordination Services): Intermediate conceptual level with the purpose to assist the negotiations at a global level (negotiations with different participants on different jobs) and at a specific level (negotiation on the same job with different participants). It handles the issues regarding communication at this level (synchronisation between the CSs of the several parties that are taking place in the negotiation), and manages the on-going transactions and negotiation data persistence, controlling the semantic discrepancies between the negotiating parties. It includes services that perform management of data transactions, semantic interpretation, dynamic discovery of services, and implementation of the business model rules, persisting its data (e.g. business-specific data, semantic ontologies, rules) on a IaaS infrastructure modelled using standard reference models and data access [21];

Negotiation level 3 (Top – Negotiation Manager): Strategic level, enables high-level operations close to the enterprises’ business decision centres, implementing the business decisions that need to be taken for the negotiation, e.g. Starting a new negotiation, submission of a proposal, acceptation/rejection of a proposal, inviting a new party to participate in the negotiation. It also manages the negotiation parameters, and communicates with the lower levels using web-services.

The proposed framework includes mechanisms (autonomous agents [22]) to identify the aspects related to the interoperability problems that are sensible to changes in the networked environment, including services to support the negotiating of solutions that act on these changes, enabling the sustainability of the enterprise-networked interoperable environment along its life cycle with less transient downtime, reducing the effort and cost to (re)achieve interoperability.

## 3.2 Negotiation model and negotiation mechanism

Negotiations are sets of complex actions, some of which may occur in parallel, where multiple participants exchange and take decisions in multiple phases over a set of multiple attributes [23]. The participants to a negotiation may propose offers and each participant may decide in an autonomous manner to stop a negotiation either by accepting or by rejecting the offer received. Also, depending on its role in a negotiation, a participant may invite new participants to the negotiation. The negotiation services shall make use of negotiation techniques and negotiation model to determine the best alternatives for the negotiation.

The Negotiation Model is defined as a quintuplet $M = \langle T, P, N, R, O \rangle$ where:

* $T$ denotes the time of the system, assumed to be discrete, linear, and uniform;
* *P* denotes the set of participants in the negotiation framework. The participants may be involved in one or many negotiations;

* *N* denotes the set of negotiations that take place within the negotiation framework;

* *R* denotes the set of coordination rules among negotiations that take place within the negotiation framework;

* *O* denotes the common ontology that consists of the set of definitions of the attributes that are used in a negotiation.

A negotiation is thus described at a time instance through a set of negotiation sequences:

Let $\mathcal{Sq} = \{si | i \in \mathbb{N}\}$ denote the set of negotiation sequences, such that
$\forall si, sj \in \mathcal{Sq}, i \neq j$ implies $si \neq sj$.

A negotiation sequence $si \in \mathcal{Sq}$ such that $si \in \mathbb{N}(t)$ is a succession of negotiation graphs that describe the negotiation $\mathbb{N}$ from the moment of its initiation and up to the time instance $t$. The negotiation graph created at a given time instance is an oriented graph in which the nodes describe the negotiation phases that are present at that time instance (i.e., the negotiation proposals sent up to that moment in terms of status and of attributes negotiated) and the edges express the precedence relationship between the negotiation phases.

According to the defined approach regarding the negotiation, the participants to a negotiation may propose offers and each participant may decide in an autonomous manner to stop a negotiation either by accepting or by rejecting the offer received. Also, depending on its role in a negotiation, a participant may invite new participants to the negotiation.

The metaphor Interaction Abstract Machines (IAMs) will be used to facilitate modelling of the evolution of a multi-attribute, multi-participant, multi-phase negotiation. In IAMs, a system consists of different entities and each entity is characterized by a state that is represented as a set of resources.

The evolution of all negotiation phases takes place in parallel. By modelling this parallel evolution in a dynamic environment, the proposed model allows us to describe and manage negotiations on multi-attribute negotiation objects and involving multiple participants. It also allows us to model different negotiation scenarios from single linear negotiation to concurrent and dependent multi-proposal negotiations.

The negotiation mechanism (Negotiation Services) that was built to implement this negotiation model shall comprise a set of rules defined in the Java Expert System Shell (JESS [24]), using the Web Ontology Language (OWL [25], [26]) and the Semantic Web Rule Language (SWRL [27], [28]) and inferred by the framework's Inference Engine.

# 4 Application to a real business case in the aerospace field

The European Space Agency – Concurrent Design Facility (ESA-CDF) performs design studies to determine the viability of space missions. Each study encompasses a set of design sessions carefully planned and scheduled, as each session comprises the gathering of several of their highest-skilled engineers, hence convey an expensive
effort. This expertise is required as the study outcomes are providing decision support evidences for large-scale investments.

The complex process associated with each study involves multiple domains (e.g. Mission analysis, Thermal, Propulsion), which match the different views and interests of the mission. Each of these domains is a complex field where state-of-the-art design techniques combine with the expertise of the field engineers towards developing a model, responsible for providing a set of parameters that support mission decisions.

The difficulty about this process, besides the inherent complexity of the referred subjects, is the adoption of the concept of Concurrent Engineering methods [29], which fast-track the design into a scenario where multi-disciplinary teams perform their activities in parallel.

Despite each domain design team models its own view of the mission, the teams need to define and exchange a large set of mission parameters, required to satisfy the mission and to ensure that all views are fully integrated and fit perfectly.

With the heterogeneity related to the various systems and applications used by each design team and mission, problems of misunderstandings regarding the exchanged data and its dependences are frequent, leading to additional rework.

Each domain engineering team performs its design using different tools (e.g. CATIA, STK, Matlab) and is provided and supported by a network of partners and suppliers (its collaborative environment).

Interoperability in this case is defined in two levels:

* The one between each domain and its tools, partners and suppliers in the supply chain, towards the target of defining the domain design or vision of the mission;

* The one between the various domains of a mission-related study, where all the domains present their view and compete for their interests into setting the values for mission-related parameters (e.g. Spacecraft dry mass, Electrical power, Launch mass).

The main issues detected in this scenario are precisely when dealing with the execution of the study, where all different visions, concepts, definitions, methods and relationships need to be harmonised and coordinated towards the evolution of the parameters that define the mission.

These mission parameters are inter-related (e.g. changes in the structure or in the number of instruments naturally affect the total dry mass) and their values are kept under control by the mission requirements. The interactions between design domains are performed in a set of closed-room sessions [30] where all involved domains and stakeholders are represented in a single room (the CDF room, with its special configuration [31]) and each domain presents its design solutions and the corresponding impact on the mission design.

The design of each study domain is executed and reported in a domain specific spreadsheet, where the exchanged data is carefully specified in specific rows and cells, and the data exchange between the domains is accomplished by linking all the domain spreadsheets in a moderated environment. Data dissemination and decisions are taken via the sharing of presentations planned, controlled, moderated and performed orderly by each domain.

This interoperable environment is very unstable, as it depends on the synchronisation of the different methodologies used by each domain to perform the
design, as well as the perfect synchronisation of the data in the linked spreadsheets. A
simple mistake in an inserted value, a misunderstanding about a parameter's unit, a
network communication failure, an error in a design macro or a spreadsheet cell name
with a typo is enough to break the interoperability [32].

Interoperability in this unstable scenario is the responsibility of the study Team Leader which moderates the discussions, and of the Systems Engineer and related Assistants which provide local support to the domain engineers. The seniority of the domain experts, which are especially recruited to participate in the study, is actually a crucial factor to improve interoperability.

The application of the proposed framework to the ESA-CDF environment was
performed, firstly by submitting questionnaires that qualify the space environment in
terms of requirements, needs and achievements, and major interoperability problems
found. The consequent knowledge was then shaped into MDA and MDI.

The ESA-CDF design process is clearly human-oriented; hence, it was very
important to split the modelling into MDA and B-MDA, MDI and B-MDI. This top-
down analysis performed to model the CDF operation, started by defining the CIM
and B-CIM layers. These include the modelling of the CDF study definitions,
objectives, each domain, hierarchies and roles associated with a study, the concepts
and stakeholders of CDF study, the expected behaviour of the system as a whole, the
organisation hierarchy, and major functionalities. These models also captured
methodologies, best-practices and operational knowledge, along with the needed
functionality and dependencies.

These models were then transformed to PIM and B-PIM layers that allowed the
CDF processes, structures and operations to be defined independently of the
technology that will support them (e.g. the split of the mission into domains, what
each will do, when will each interact towards the others, the definition of lessons-
learned and capture of domain knowledge and practices, the relationship towards
external parties, the configuration items). This also included the setting of a space-
related ontology that describes, relates, and models the common space mission
definitions, i.e. ESA-SERDL (Space Engineering Reference Data Library [33]) and
the creation of the central data model defined by the standard ISO10303 STEP and
EXPRESS statements, i.e. ESA-SEIM (Space Engineering Information Model [34]),
as well as study workflows (e.g. the flow in which each domain presents their
outcomes, policies about exchanging the data parameters).

Finally the models were transformed to PSM and B-PSM layers, which defined a
set of web-services interconnecting the various domains, all connected via a central
Enterprise Service Bus, and human and operational policies including rules, manuals
and wizards.

On each of the MDA/B-MDA layers defined for the CDF environment and for its
network of dependences (prime contractors and subcontracted SMEs), negotiations
were modelled to handle the harmonisation of CIM/B-CIM objectives and
understandings, the harmonisation of the PIM/B-PIM ontologies and flow outcomes,
and the PSM/B-PSM middleware heterogeneities, formats, units and operations.

Whenever a new partner enters or shows changes in the interoperable space, the
negotiation services, powered by the JESS negotiation rules, will be used to inquire
the parties for the motivations, strengths, benefits, threats, prejudices, opportunities
and impacts (e.g. time, effort, cost, dependences) due to the changes. Then, the
negotiations take place in order to reach the most suitable solution in terms of impact and stability of the networking peers, along its life cycle. These negotiations are performed by the interested parties (e.g. SMEs) and the prime contractors and ESA-CDF domain supervisors can also participate for controlling the decisions that are taken and making sure they are aligned with the domain specifications. Regardless of the outcome of the negotiation, knowledgeable and mature decisions can be taken centred on accurate information about the other parties, based on facts and with decision support, able to be tracked and documented, hence providing lessons-learned and knowledge for future negotiations.

**5 Final Considerations and Future Work**

This paper described common problems found in the EI domain, particularly on the proposed business case of feasibility studies for aerospace missions, and proposed a collaborative framework to enhance business knowledge, to allow the adaptation of enterprises, and to allow the negotiation of solutions for the detected interoperability changes.

Driven by the formulated research question, the authors foresee that by adopting the proposed framework, major contractors and final customers have a mechanism that allows them to follow and influence (monitor and control) the interoperability solutions that are taken in subcontracted enterprises, aligning them with their objectives.

The formalisation of the negotiations into the defined negotiation model allows SMEs to perform the negotiation keeping their knowledge assets encapsulated in the negotiation model's entities, thus allowing them to negotiate without exposing them to the competition. Through the negotiation mechanism, the sustainability of the interoperable environment will be robust and easy to maintain.

This paper concludes that interoperability typically breaks because it is often developed over a poorly described (and rarely modelled) tacit knowledge. The integration of formal procedures for modelling, storing and documenting the business activities into MDA, MDI, B-MDA and B-MDI models allows a comprehensive analysis of the processes and of the possible alternatives. Adding the ability to negotiate the interoperability solutions leads to maximised results, stronger capabilities and relationships, thus contributing to reduce the risk of losing interoperability. The use of an adaptive framework that allows flexibility in terms of rearrangement, composition, reuse and scalability will result in a seamless, sustainable interoperability which favours its maintenance across time. The ability to reach and interoperate with more enterprises stimulates more business opportunities and stronger and healthier interactions.

Future research shall include the improvement of the framework's supporting tools: ontologies, questionnaires, tools, guidelines and processes (e.g. contract management, negotiation and renegotiation, development methodologies).

**Acknowledgments.** The authors wish to acknowledge the support of the European Commission through the funding of the UNITE, MSEE and ENSEMBLE FP7
projects, and the European Space Agency - Concurrent Design Facility (ESA-CDF) for their support, interaction and contribution in the development of the business case that is presented on this paper.

## References

[1] “Internet of Things - An action plan for Europe,” CORDIS, p. 13, 2009.

[2] J. Cardoso, K. Voigt, and M. Winkler, “Service Engineering for the Internet of Services,” in *10th International Conference on Enterprise Information Systems ICEIS 2008*, 2009, pp. 15-27.

[3] “Internet of Services,” 2012. [Online]. Available: http://www.internet-of-services.com.

[4] K. Jeffery and B. Neidecker-Lutz, “The Future of Cloud Computing: Opportunities for European Cloud Computing Beyond 2010,” *Analysis*. p. 71, 2010.

[5] M.-S. Li, R. Cabral, G. Doumeingts, and K. Popplewell, “Enterprise Interoperability Research Roadmap,” no. July. European Commission - CORDIS, p. 45, 2006.

[6] R. Jardim-Goncalves, C. Agostinho, and A. Steiger-Garcao, “Sustainable Systems’ Interoperability: A reference model for seamless networked business,” in *2010 IEEE International Conference on Systems, Man, and Cybernetics (SMC 2010)*, 2010, pp. 1785-1792.

[7] “MSEE Project,” 2012. [Online]. Available: http://www.msee-ip.eu/project-overview. [Accessed: 10-Apr-2012].

[8] G. Doumeingts, B. Vallespir, and D. Chen, “GRAI GridDecisional Modelling,” in *Handbook on Architectures of Information Systems*, Springer, 2006, pp. 321-346.

[9] OMG, “Model Driven Architecture,” 2011. [Online]. Available: http://www.omg.org/mda. [Accessed: 20-Dec-2011].

[10] Y. Lemrabet, M. Bigand, D. Clin, N. Benkeltoum, and J.-P. Bourey, “Model Driven Interoperability in practice: preliminary evidences and issues from an industrial project,” in *First International Workshop on Model-Driven Interoperability (MDI’10)*, 2010, pp. 3-9.

[11] Athena Consortium, “Athena Interoperability Framework,” 2011. [Online]. Available: http://www.modelbased.net/aif. [Accessed: 20-Dec-2011].

[12] G. Xiong, Z. Liu, X.-W. Liu, F. Zhu, and D. Shen, *Service Science, Management, and Engineering: Theory and Applications*. Academic Press, 2012.

[13] J. Ullberg, R. Lagerstrom, M. van Sinderen, and P. Johnson, “Architecture Modeling for Interoperability Analysis on the Future Internet,” in *6th International Conference on Interoperability for Enterprise Systems and Applications (I-ESA2012)*, 2012.

[14] Y. Lemrabet, H. Liu, J.-P. Bourey, and M. Bigand, “Proposition of Business Process Modelling in Model Driven Interoperability Approach at CIM and PIM Levels,” in *Enterprise Interoperability V*, Springer, 2012, pp. 203-215.

[15] L. Nie, X. Xu, D. Chen, G. Zacharewicz, and D. Zhan, “GRAI-ICE Model Driven Interoperability Architecture for Developing Interoperable ESA,” in *Enterprise Interoperability IV*, Springer, 2010, pp. 111-121.

[16] U. Zdun and S. Dustdar, “Model-driven and pattern-based integration of process-driven SOA models,” *International Journal of Business Process Integration and Management*, vol. 2, no. 2, pp. 109-119, 2007.

[17] M. P. Papazoglou, P. Traverso, S. Dustdar, and F. Leymann, “Service-Oriented Computing: a Research Roadmap,” *International Journal of Cooperative Information Systems*, vol. 17, no. 02, p. 223, 2008.
[18] R. Jardim-Goncalves and A. Grilo, “SOA4BIM: Putting the building and construction industry in the Single European Information Space,” *Automation in Construction*, vol. 19, no. 4, pp. 388-397, Jul. 2010.

[19] R. Sharma and M. Sood, “Cloud SaaS and Model Driven Architecture,” in *International Conference on Advanced Computing and Communication Technologies (ACCT11)*, 2011, no. Acct, pp. 978-981.

[20] J. Sarraipa, R. Jardim-Goncalves, and A. Steiger-Garcao, “MENTOR: an enabler for interoperable intelligent systems,” *International Journal of General Systems*, vol. 39, no. 5, pp. 557-573, Jul. 2010.

[21] R. Jardim-Goncalves, C. Agostinho, P. Malo, and A. Steiger-garcao, “Harmonising technologies in conceptual models representation,” *International Journal Of Product Lifecycle Management*, vol. 2, no. 2, pp. 187–205, 2007.

[22] C. Coutinho, A. Cretan, and R. Jardim-Goncalves, “Sustainable Interoperability Framework for supporting Negotiation Processes,” in *6th International Conference on Interoperability for Enterprise Systems and Applications (I-ESA 2012)*, 2011.

[23] R. Jardim-Goncalves, J. Sarraipa, C. Agostinho, and H. Panetto, “Knowledge Framework for Intelligent Manufacturing Systems,” *Journal of Intelligent Manufacturing*, vol. 22, no. 5, pp. 725-735, Oct. 2009.

[24] “JESS Rule Engine,” 2012. [Online]. Available: http://www.jessrules.com/jess/index.shtml. [Accessed: 15-Feb-2011].

[25] “OWL - Web Ontology Language,” 2012. [Online]. Available: http://www.w3.org/2004/OWL. [Accessed: 14-Nov-2011].

[26] “Protégé-OWL editor,” 2012. [Online]. Available: http://protege.stanford.edu/overview/protege-owl.html. [Accessed: 14-Mar-2012].

[27] M. O'Connor et al., “Supporting Rule System Interoperability on the Semantic Web with SWRL,” in *4th International Semantic Web Conference (ISWC2005)*, 2005.

[28] “SWRLJessTab,” 2012. [Online]. Available: http://protege.cim3.net/cgi-bin/wiki.pl?SWRLJessTab. [Accessed: 20-Mar-2012].

[29] M. Bandecchi, “The ESA Concurrent Design Facility (CDF): concurrent engineering applied to space mission assessments,” in *2nd Nordic Systems Engineering Boat Seminar (FinSE2001)*, 2001, pp. 1-36.

[30] G. Kolfschoten, A. Matthyssen, and M. Fijneman, “Theoretical foundations for Concurrent Design,” in *4th International Workshop on System & Concurrent Engineering for Space Applications (SECESA 2010)*, 2010, no. 1.

[31] ESA-CDF, “ESA-CDF,” 2012. [Online]. Available: http://www.esa.int/esaMI/CDF/. [Accessed: 10-Jan-2012].

[32] H. P. D. Koning, H. Eisenmann, and M. Bandecchi, “Evolving Standardization Supporting Model Based Systems Engineering,” in *4th International Workshop on System & Concurrent Engineering for Space Applications (SECESA 2010)*, 2010, no. 1.

[33] “ESA-SERDL,” 2012. [Online]. Available: http://atlas.estec.esa.int/ucielas/SERDL. [Accessed: 10-Jan-2012].

[34] “ESA-SEIM,” 2012. [Online]. Available: http://atlas.estec.esa.int/ucielas/SEIM. [Accessed: 10-Jan-2012].