Systems Interoperability Types: A Tertiary Study: Discussing the Results and What Comes Next

Table of Links

Introduction

Related Work

Research Method

Results

Discussions

Conclusions & References

5 DISCUSSIONS

Interoperability refers to a non-functional or quality requirement required in almost all existing SIS. In this scenario, this work offers a comprehensive view of various interoperability types, models, and frameworks, as well as how different domains and associated solutions have addressed interoperability. Interoperability has been investigated since software systems became distributed some decades ago and has attracted considerable attention from industry, academia, and standardization organizations.

Several significant initiatives aim to provide interoperability in various domains. These initiatives involve multiple stakeholders from different countries and sectors to achieve effective collaboration among SIS. For instance, EIF for enterprise, Open Connectivity Foundation (OCF)[19] , which focuses on providing a common framework for IoT devices, European Blockchain Services Infrastructure (EBSI)[20] is another initiative that aims to promote the interoperability of blockchain-based services across Europe, FHIR standard, EU’s eHealth Digital Service Infrastructure (eHDSI)[21] , Interoperability Standards Advisor (ISA)[22] for health different systems and countries, to cite a few.

Comparing our work with the closest work [33], we identified 36 interoperability types, while that work presented 64. Analyzing the reasons, we observed that most types from [33] deal with low-level technical aspects (e.g., communications, electronics, telecommunications, and plug-and-play), which were replaced by technical and syntactic interoperability.

Other types are very generic (e.g., high-layer, lower-layer, higher-layer, and specification-level) or solution-oriented (e.g., object-oriented, procedure-oriented, and product-to-product), so they were short-lived. We also observe that both works ([33] and ours) identified three interoperability types as those most recurrent: organizational, semantic, and technical; besides, some social-technical types also appeared in both studies, e.g., cultural, organizational, enterprise, and process.

In some way, both works can reveal the evolution of interoperability conceptualization and stabilization ofsome interoperability types. While [33] identified interoperability types through a survey on interoperability measurement, our study is more extensive by considering interoperability types, conceptual models, frameworks, and some domains that addressed interoperability solutions. Moreover, this related work was published 15 years ago, and the technologies have suffered considerable advances; therefore, we believe an updated view ofsystemsinteroperability typesis valuable.

As we can see, interoperability types often guide research and development. However, there is still much work to be done, with several open issues remaining. The following sections present our main findings and related open issues, urgent actions to be performed, potential research opportunities, and the threats to the validity of our work.

5.1 Findings and Open Issues

Following, we discuss the main findings of our work and identify open issues associated with each finding, making it possible for researchers and practitioners further inspiration, reflection, and investigation.

• Interoperability is a field in continuous evolution: Interoperability has been an important topic of interest for at least four decades. Since the first works on interoperability at the beginning of the 1980s when technical and syntactic interoperability started to be treated [51], going to the 1990s when middleware for interoperability drew attention [13] and to 2000s when the military domain highlighted the need of non-technical interoperability [82], the concept of interoperability has smoothly evolved over the years to keep up with the continuous evolution of hardware and software technologies. It has also evolved, encompassing not only technical interoperability but also social-technical ones.

Hence, while technical interoperability overcomes barriers regarding heterogeneity (e.g., software and hardware infrastructure), social-technical ones cope with differences (e.g., cultural, ethical, languages, doctrines, and legal aspects).

At the same time, this evolution has signaled that popular interoperability types (i.e., technical, syntactic, and semantic) have no longer fulfilled the current systems interoperability needs [42]. For example, blockchain, IoT, and cloud computing have required new and disruptive means to achieve interoperability.

Open issues: With the inevitable emergence of new software and hardware technologies and even disruptive SIS, the field of systems interoperability will need to evolve continually. New possibilities of interactions in SIS and suitable interoperability types should be characterized, while existing types should be revisited considering the new scenarios.

• Interoperability has gone beyond the software system’s boundary: The emergence of new application domains (e.g., smart-* systems, Health 4.0, and Industry 4.0) has brought several interoperability concerns and challenges. Software systems have mediated interactions among people, organizations, and things (e.g., equipment, devices, and cars), often replacing activities previously performed by human beings. Hence, interoperability is today not only a software need but also a concern outside the software systems’ boundary [56].

Consequently, providing interoperability in systems also involves solving real-world interoperability, e.g., when systems from two countries with their specific legislation need to interoperate, legal interoperability should be treated (as in the case of EIF as a proposal for EU).

Therefore, the interoperability field has included interoperability types out of the boundary of software systems themselves (e.g., cultural, legal, and knowledge) as a natural way to connect organizations, different cultures, countries, and regions that software systems have made possible.

Open issues: A critical challenge is to perceive the limits of computational support for solving some social-technical interoperability types (e.g., legal, cultural, and political). As these types are related to issues beyond software boundaries, finding suitable interoperability solutions should involve different stakeholders besides those from the computing area.

• Interoperability must be considered from different perspectives: Nowadays, software systems are responsible for different interactions (involving people, organizations and their processes, and things). Interoperability has increasingly dealt with heterogeneity in software systems regarding different elements (e.g., platforms, languages, communication protocols, and so on) and also differences that systems must address (e.g., cultures from different regions and legal issues from different countries).

Besides those interoperability types found in our work, others have recently appeared in the literature, such as human [39], social [18], political [67], full [57], and trustworthy [2]. Additionally, similar to other quality requirements, interoperability must be treated along with all systems life cycle — from requirements engineering to system modeling, architectural design, implementation, and maintenance — which must involve teams from computing and also from other areas.

In this scenario, it is undeniable that different perspectives must be considered for achieving suitable interoperation in software systems.

Open issues: Interoperability should become a multidisciplinary research field, encompassing other knowledge areas, like social sciences, economy, and politics.

• Interoperability refers to a consensus, but the panorama does not reflect that yet: The research works indicate that interoperability has drawn considerable attention, aligned with the industry interest in solving systems interoperability. Basically, the interoperability principle is to establish a consensus to achieve effective collaboration among systems; however, studies show that finding a consensus even within specific application domains like health is not trivial [25].

New interoperability types have also continuously emerged with little or no investigation yet. We also observe it lacks a consensus in the research community and industry on those basic types, those specific for specific application domains or classes of systems (e.g., SoS), or those for a given technology like IoT or cloud computing [59, 70]. In turn, research initiatives seem not to talk to each other.

Open issues: A consensual understanding of the existing interoperability types is not still established. It is also required interoperability solutions, strategies to solve misunderstandings, consolidation of many interoperability types, and avoidance of new types without considering how existing ones should be a goal to pursue. Indeed, the interoperability concept still needs to be better and widely comprehended, including types considered as socialtechnical interoperability.

• Interoperability models and frameworks are good solutions, but their hierarchical levels need to be rethought: Interoperability models (i.e., conceptual models and IAM) and frameworks play an important role in organizing and sharing interoperability knowledge in a systematized way. Several areas recognize the value of interoperability models for systems interoperability, so these models have been used as a reference guide for industry solutions and research works. Several areas also recognize that frameworks like EIF and Athena can be very promising in specific domains. Neverthless, sometimes these models and frameworks do not present a widespread adoption [23].

Furthermore, they do not consider new interoperability types that seem to be essential in systems that they support the development. For instance, INTEROP (a framework for enterprise systems) could address legal interoperability as nowadays enterprise systems have crossed the countries’ borders. Most models and frameworks provide a hierarchical organization of the interoperability types, in which technical, syntactic, and semantic comprise a base stack for systems interoperation.

At the same time, new types emerged to deal with the interactions among elements in a given system or interactions among various systems and may require different types that seem not suitable to be organized hierarchically. Some examples of these types are legal, cultural, and political.

Open Issues: As interoperability models and frameworks can no longer reflect the current interoperability scenarios, they need to be updated with the new interoperability types and new kinds of relationships than hierarchical one. Specifically regarding IAM, certifications of interoperability levels for systems could be considered.

• Domains with success interoperability should be an example to be followed: Internet/Web domains successfully adopt several standards [93] to solve technical and syntactic interoperability. Hence, web-based systems have adopted them and have solved other types (in particular, semantic and organizational). Furthermore, health stands out as one of the domains found in our study that has mostly investigated interoperability.

The work of Mello et al. [60] better summarizes the main works and solutions for interoperability in health systems. This domain has already examined the impact of cloud computing and IoT heterogeneity on the interoperability of its systems. For a while, the blockchain domain seems to be a prime and recent example of efforts to address interoperability by presenting initiatives that facilitate the development of interoperability solutions, ultimately making blockchain technology more accessible and valuable to a broader range of industries. Solutions to decrease lock-in situations also exist and should be followed.

Open Issues: As the interoperability solutions, mainly in highly heterogeneous scenarios, are costly and time consuming to develop, success domains and their solutions (e.g., Internet/Web and health) should serve as an example for others and for new domains like Industry 4.0.

• Several interoperability solutions exist but still without a broader adoption: Several interoperability solutions, including standards, ontologies, frameworks, conceptual models, platforms, reference architectures, API, services, and gateways, have supported the achievement of systems interoperability over the years. In general, domains that present heterogeneity in their components (which need to interoperate) are the ones with a variety of solutions [42]. In particular, standards are a cost-effective solution but challenging to be adopted by stakeholders and players that already use their particular solutions.

For instance, although several works exists in IoT domain, applications usually run in vertical silos [70]. In general, the same happens with other solutions that are usually isolated contributions without a wide dissemination even in their domains.

Open issue: To make possible wide adoption of interoperability solutions, consortia encompassing companies, research institutions, standardization organizations, and even governments should be formed. For instance, Autosar[23] is a large consortium leveraging the adoption of a reference architecture. Moreover, interoperability solutions for systems involving newer technologies, such as edge, fog, blockchain, and artificial intelligence, are also required and could reuse success experiences from previous solutions, but disruptive ones will be possibly necessary.

• A complete body of knowledge on systems interoperability is missing: Our study presents an initial body of knowledge of systems interoperability; however, it also reveals that this knowledge is still somehow fragmented, even within specific application domains or technologies such as IoT.

Moreover, several studies reported a lack of comprehensive information about interoperability types [8, 33, 36] or seek definitions of interoperability [63, 85]. Regarding interoperability models (including conceptual models and IAM) and frameworks, it lacks a consensus on what precisely they should comprise to be useful [75]. In this scenario, our work provides a step towards a holistic view of systems interoperability.

Open Issue: The knowledge about systems interoperability could be stated through a document similar to SEBOK (Systems Engineering Body of Knowledge) [27] or SWEBOK (Software Engineering Body of Knowledge) [15]. This document could specify the accepted definitions of interoperability types, their relationships, and what interoperability models and frameworks are exactly.

5.2 Future Actions and Potential Research Opportunities

The interoperability types have been the driving force of much of the research work in the field. In this work, the analysis of various interoperability types and associated topics, such as models and frameworks, revealed several open issues, as discussed previously. In response, we present some of the most urgent and future actions and potential research opportunities that could contribute to advancing the state of the art in the field.

• Interoperability discussion forums: Interoperability has been discussed in several forums (like conferences and workshops), but as a subtopic associated with others such as in the architectural design of cyber-physical systems or health systems. We highlight the need of creating dedicated forums for specifically discussing interoperability challenges and solutions, bringing together researchers and practitioners from various fields, including computer science, engineering, politics, and social sciences.

Such forums could bring a much-needed common understanding on systems interoperability and how to achieve and ensure it, as well as serve as a venue for sharing ideas, best practices, and case studies and address both theoretical and practical interoperability aspects. These forums could also focus on specific topics, such as data interoperability, social interoperability, full interoperability, technical standards, and multidisciplinary aspects such as the implications of legal interoperability.

• Interoperability task forces and standardization organization: Following successful examples, such as the OMG (Object Management Group), W3C (World Wide Web Consortium), IEEE (Institute of Electrical and Electronics Engineers), and HIMSS (Healthcare Information Management Systems Society), we suggest to create task forces and an organization specifically focused on systems interoperability. These task forces could be organized around interoperability challenges like in cloud computing, IoT, blockchain, smart cities, or financial systems.

Moreover, such organization could address: (i) the development of interoperability patterns (or interoperability standards as those existing in some domains), guidelines, and solutions that can be shared and reused across different domains; and (ii) the establishment of interoperability certification programs that could promote best practices. Finally, this organization could be a vehicle to become transparent what has been done in different domains, promoting the sharing of their achievements.

• SIS Interoperability Body of Knowledge (SISBOK): We foresee the need of a comprehensive and evolving body of knowledge of SIS Interoperability (SISBOK). SISBOK would be a repository of knowledge related to interoperability, including types, models, frameworks, and related solutions, serving as a basis for continuous evolution of these concepts and their definitions, as a reference for researchers and practitioners, and as a learning object for students.

The development of SISBOK will require involvement of multiple stakeholders, including researchers, practitioners, and standardization organizations. Knowledge from previous experience, e.g., from existing interoperability models, should be also considered and incorporated in SISBOK when pertinent, although most models require updated.

• Detailed definition of the existing interoperability types: A deeper understanding of the interoperability types can drive the progress in the field. A detailed, clear, and common definition of each interoperability type considering heterogeneity and differences among them, as well as requirements, constraints, and attributes, can enhance stakeholders’ communication. Interoperability frameworks and patterns could also adopt unified definitions for their types. Additionally, meta-frameworks could provide a high-level understanding of the relationships among different types.

• Investigation of social-technical interoperability: Several social and organizational factors, such as people’s culture, ethics, politics, and culture and structures of organizations, directly impact the achievement or not of different levels of SIS interoperability. These factors have not been sufficiently investigated, so requiring a deeper examination of the various scenarios in which social-technical interoperability should be treated, the differences influencing these factors, and strategies to overcome such differences. In addition, investigating the relations between technological and social-technical interoperability types in different contexts (including new types and context where they will likely emerge) could leverage the SIS interoperability.

• New interoperability types: Identifying and defining new interoperability types are essential to the development and evolution of SIS, especially considering large and complex SIS that depend on diverse new technologies like blockchain. For instance, new scenarios where SIS will operate have given increasing importance to ethical issues and data protection and privacy, leading to the need for new interoperability types, which should also be consistent with types already in use.

• Remodeling the relationships among interoperability types: Understanding the relationships among types is also crucial to achieve SIS interoperability. Considering our investigation presented in this work, we observe that it is necessary to remodel the relationships among those types, going beyond the well-known hierarchical relationships.

For instance, legal interoperability has a cross-cutting nature, affecting both technological and social-technical perspectives of an SIS. By understanding how different types relate each other, stakeholders can make more informed decisions of the required types for a given SIS. Additionally, interoperability models, frameworks, patterns, and solutions should be updated accordingly.

• Assessment models for interoperability solutions: Existing IAM provide a valuable support for evaluating and selecting interoperability solutions, but they are somehow outdated considering the very new interoperability solutions emerging continuously. Moreover, currently, it is unclear which interoperability types each solution offer. Hence, new criteria and methods to evaluate these solutions and even new assessment models are required. Additionally, IAM could designate “stamps” indicating the interoperability types covered by the solutions, so helping stakeholders in selecting more adequate solutions.

• Maturity model for SIS interoperability: Maturity models to assess SIS regarding their interoperability levels could be another potential future research. These models should consider different types, systems requirements, and possibly particularities of specific domains. In addition, they should outline the steps needed for a given SIS to reach each maturity level and progress to higher levels.

5.3 Threats to Validity

We identified a set of threats to the validity for our tertiary study and the countermeasures to mitigate them, according to the work of Ampatzoglou et al. [5]:

• Study Selection Validity: The first threat was relevant studies that might have been missed; hence, we adopted several countermeasures to deal with this threat. In particular, the search string might have imposed threats during the studies search. To mitigate it, we followed the process presented in [50] to test, calibrate, and define our string carefully. Another countermeasure was the search for studies in three publication databases, namely Scopus, IEEE Xplore, and ACM DL, since they are considered the most relevant sources of studies in software engineering [29, 50].

During the search, we also considered various types of scientific publications, including conference papers, journal articles, technical reports, books, and book chapters, as a countermeasure to enlarge the scope of our selection. Additionally, to ensure an unbiased selection of studies, we defined three RQ and eight selection criteria (two inclusion criteria and six exclusion criteria) in advance. We believe the RQ (and associated rationale) and the criteria were detailed enough to provide confidence in how we obtained the final set of studies.

Moreover, aiming to increase the reliability of selection, at least two authors checked and read each study as a way to mitigate the threat. When conflicts in the selection criteria application occurred, the third and fourth authors reviewed the study to make the final decision. Another countermeasure was that all authors (including two with extensive experience conducting secondary studies) reviewed the tertiary study protocol; additionally, we systematically and rigorously followed the protocol to avoid bias and ensure the inclusion of all relevant studies.

However, some studies could have been excluded due to the lack of information in the title, abstract, keywords, introduction, and conclusion sections; furthermore, studies could have been missed despite all our effort to include all relevant studies. After applying these countermeasures, we believe the final set of 37 studies reflects the state of the art in SIS interoperability.

• Data validity: Another threat was that we might have missed relevant data from the secondary studies. Hence, a countermeasure was using a data extraction form that was carefully prepared and checked to make it possible to collect all data from the studies and answer our RQ correctly. We also performed a pilot test with the data extraction form to observe its suitability and efficiency in gathering data.

Additionally, as some data from secondary studies was not apparent to be easily extracted, we had to interpret it. As a countermeasure, we had a specialist (one of the authors) who doubled checked each data extracted and the interpretations done. This specialist identified some inconsistencies and incompatibilities that we discussed until reaching a consensus. We also used the extracted data to trigger several discussion sessions to understand the data better and identify data correlation.

Research validity: It refers to the possibility that our opinion or knowledge might have influenced the synthesis of the results. As a countermeasure, all authors of this study contributed to discussing and synthesizing the results. In turn, the authors have researched systems interoperability and software architecture for years; hence, we believe our previous knowledge could have contributed to a better synthesis of results.

We also previously defined and systematically followed a detailed protocol (as summarized in Section 3.1), which was based on well-established guidelines for tertiary studies [50]. In addition to the information presented in this work, we offer external material with all raw and extracted data on which we based our findings, as well as information to make possible the reproducibility and auditability of this tertiary study.

[19] https://openconnectivity.org/

[20] https://digital-strategy.ec.europa.eu/en/policies/european-blockchain-services-infrastructure

[21]https://digitalhealtheurope.eu/glossary/ehdsi/

[22] https://www.healthit.gov/isa/

[23] https://www.autosar.org/

This paper is available on arxiv under CC 4.0 license.