Systems Interoperability Types: The Results of Our Tertiary Study and What It All Means

This paper is available on arxiv under CC 4.0 license. Authors: (1) RITA S. P. MACIEL, Federal University of Bahia, Brazil; (2) PEDRO H. VALLE, Federal University of Juiz de Fora, Brazil; (3) KÉCIA S. SANTOS, Federal University of Bahia, Brazil; (4) ELISA Y. NAKAGAWA, University of São Paulo, Brazil. Table of Links Introduction Related Work Research Method Results Discussions Conclusions & References 4 RESULTS This section presents an overview of studies and answer the three RQs. 4.1 Overview of Studies Table 1 summarizes some information of the 37 secondary studies. This table shows the study ID (used along with this work), review type (i.e., SLR (systematic literature review), qSLR (quasi-systematic literature review), SMS (systematic mapping of studies), LR (Literature Review), and MLR (Multivocal Literature Review)), study title, publication year, the number of primary studies analyzed by each secondary study, quality assessment, and references. Regarding the publication venue, we observed that 27 studies were published in journals and 10 in events. Hence, most studies have high quality and are detailed enough to be published in journals; therefore, we believe they are suitable to answer our RQ. In turn, we indirectly analyzed more than 1,480 primary studies (summing only the number of studies declared in the secondary studies). The last column of Table 1 lists the calculation of the quality assessment[10] . Most studies with lower scores (0.5 to 1.5) refer to LR, which usually does not adopt a systematic and rigorous way to be conducted; on the other hand, most studies with higher scores (2.0 to 4.0) are SMS or SLR that require systematic review processes. We consciously decided to keep all 37 studies for further analysis, i.e., we did not use the quality assessment to exclude studies. This is because the primary purpose of our study was to provide a comprehensive overview of all review studies on interoperability types published in the field. Second, using DARE allowed us a holistic view of the quality of the studies. Hence, by making the scores available, readers can have a notion of their quality. Following, Sections 4.2, 4.3, and 4.4 answer RQ1, RQ2, and RQ3, respectively. 4.2 Types of Interoperability Regarding RQ1 (Which interoperability types have been addressed?), we examined each study to identify the interoperability types explicitly reported in each one and found 36 different types, as listed in Table 2. We can observe that some types have caught more attention than others; for instance, semantic interoperability appeared in 30 studies (including seven studies that specifically addressed it), while network occurred in just one (S28). We also extracted the definitions (or understandings) of each type that the studies provided. Four secondary studies (S8, S16, S19, and S24) did not offer the definitions or generically present them; hence, we turned to the primary studies considered in these secondary studies. It is worth highlighting the types (in Table 2) are according to those presented by the studies; hence, ones apparently similar (e.g., business, process, and business process) were considered distinct due to their slight different definitions. We concerned to keep the original information from the studies, considering it could be important for further analyses by other interested. We also observed that interoperability types are sometimes referred to as levels, stages, layers, phases, or dimensions and are usually organized through a hierarchical relationship (further detailed in Section 4.3). In the end, we collected a total of 117 definitions[11] distributed to 36 types. Deeply analyzing each type’s definition(s), we gathered similarities, overlaps, and even divergences. Due to this scenario, we believe that a grouping and positioning of the interoperability types may favour understanding them better, so we prepared Figure 2. We grouped the types into technological, social-technical, and crosscutting. For this work, we defined that technological group refers to those types that deal with the interaction among SIS elements, such as hardware, networks, software platforms, and different systems. In turn, this group was split into low level and high level. While types in the low level group are necessary to overcome heterogeneity in software infrastructures (e.g., technical, objects, and device), types in high level meet the demands to support the collaboration among different software elements to achieve SIS goals (e.g., semantic, syntactic, and pragmatic). Social-technical group contains types that address the capability of elements (outside the software itself), people, and organizations to collaborate and overcome their differences. This group was split into individual and organization groups. While the individual group focuses on addressing issues related to people, the organization group focuses on addressing issues related to organizations. Cultural is an example of a type of social-technical individual interoperability, and enterprise is a social-technical organization type. Finally, the crosscutting group impacts both technological and social-technical aspects of SIS interactions; legal was then placed in this group. Another analysis was regarding the stability of the definitions, i.e., how much the definitions of a given interoperability type have somehow been kept the same in different studies. For this, we carefully analyzed all definitions found for each type, making it possible to group it into four groups — stable, ongoing, initial understanding, and misunderstanding — colored in green, blue, orange, and red, respectively, in Figure 2. The more aligned the definitions of the given type, the more stable that type is. In the context of this work, stable understanding refers to types with minimal disagreement in their definitions and present in several studies over the years. For instance, semantic interoperability is addressed in 30 studies published from 2012 to 2023 (all period considered in our study). Ongoing understanding encompasses types that are not well-defined regarding both the type name and its definition. This group have more overlapping than discrepancies. Coincidentally, all five types associated with business process alignment (in blue in Figure 2) are in this group, possibly because they deal with interoperability in different domains, such as industry (S19), health (S27), and enterprise (S2 and S4). Initial understanding refers to those types addressed in few studies (one or two studies), and no relevant disagreement in their definitions was observed. The type in misunderstanding presented discrepant definitions, such as data with six non-aligned definitions coming from seven different studies, and functional and programmatic with two distinct definitions each from two studies. In summary, few types (i.e., eight types) have a stable definition. The majority (21 types) have an initial understanding, followed by ongoing understanding (five types), and two was classified as misunderstanding. Hence, while considerable attention has been given to several different types, the concern has not been unifying the definitions/understandings. Following, we provide a discussion of each group of interoperability types, highlighting the most relevant issues observed in each group and type. Concerning the technological and low level group, nine types are in these group, as shown in Figure 2. All these types address software communication across heterogeneity of hardware devices, network, and systems infrastructures. In particular, technical interoperability is a concern in most studies (20 of 37) and enables the communication among software systems despite the heterogeneity of underlying communication infrastructures. Its definitions often comprise various solutions, such as standardization of hardware and software interfaces (as in S5, S21, and S25). While technical interoperability is domain-independent, other types, such as device, hardware, network, objects, and platform, appear more in specific technological domain, e.g., IoT-based devices and solutions (as in S23 and S24). Additionally, while network and hardware keep similarities with technical interoperability (i.e., communication between hardware and software infrastructure), platform has similarities to syntactic interoperability (i.e., to overcome the heterogeneity of communication protocols). Cloud interoperability treats heterogeneity among cloud providers and cloud layers (as in S4 and S6). Blockchain interoperability appeared in six recent studies (from 2021) and surprisingly already presents a common definition considering these studies. This type refers to the ability of distinct and heterogeneous blockchain systems to work together seamlessly, enabling information exchange/sharing and access across different blockchain networks without a centralized authority, each representing a distributed data ledger (S30, S32, S33, S34, S36, and S37). S30 still points out that blockchain interoperability refersto technical and semantic interoperability. Data interoperability is the one that presents significant divergent definitions found in seven studies (S2, S4, S6, S14, S16, S19, and S28). When defined for IoT context, it refers to the ability to deal with heterogeneity in the acquisition and use of data across different platforms and software systems; in other words, it seems similar to technical interoperability. S28 defines data interoperability as one composed of device, network, platform, and semantic interoperability. When considering specific domains, such as cyber-physical systems (in S14) and constructive industry (in S19), the purpose is to make data accessible despite different representation strategies, such as languages, syntax, and data models, i.e., it is similar to syntactic interoperability. Considering technological and high level group, semantic, syntactic and pragmatic have stability in their definitions, other 11 types have initial understanding, and one presents misunderstanding definition. Semantic interoperability appears in most studies (30 of 37) and provides communication without information ambiguity and in an accurate way without human intervention, so software systems need to agree with a common information representation. Although semantic is usually treated as domain-independent interoperability, it has drawn attention from specific domains, e.g., Industry 4.0 (S16, S18, and S28), health (S3, S7, S26, S27, S29, S31, S32, and S35), and IoT (S22, S23, and S24). In particular, IoT-focused studies (S22 and S23) present slightly different definitions, in which the heterogeneity of data sources (image, text, and video) captured by sensors and delivered to applications may be solved through ontologies; hence, it is related to a problem of semantic interoperability. Besides, there is a trend that the heterogeneity and specificity in these domains should be addressed differently, i.e., through low-level interoperability types; so device (as in S24 and S28), network (S28), and platform (S23, S24, and S28) are mentioned. Similarly to semantic interoperability, another type with long-term investigation is syntactic found in 12 studies. In general, it refers to structural and behavioral aspects of message exchange to enable communication among distinct software systems. Another stable type is pragmatic that aims the communication by sharing context, intention, and effect of message exchanges (S10, S21, and S35). Regarding software-to-software communication, we gathered eight types. In short, ecosystems refers to the ability of different ecosystems collaborate among them and with independent entities (S4 and S6). Conceptual (S8, S17, and S35) refers to the highest interoperability level in SIS, when several aspects to achieve interoperability are aligned (e.g., process, information, restrictions, and contexts). Service highlights that interaction among software services should be dynamically performed (S2, S4, S6, and S19). Information (S14 and S16), software systems (S4 and S6), and system (S8, S14, and S16) address systems interaction and effective use of information, while constructive (S14 and S21) and dynamic (S35) occur when SIS are aware about state changes in the assumptions and limitations they are making over time. The remaining three types with initial understanding of the technological and high level group deal with specific interoperability issues: (i) electronic identity refers to systems from different domains that collaborate considering automatic authentication and authorization concerns(S4 and S6); (ii) programmatic was proposed to attend peculiarities (e.g., activities workflow) of specific domains (S14); and structural refer to when multimedia, hypermedia, object-oriented data, and other forms of information are recorded. Finally, functional presents a misunderstanding; while S14 defines it as an ability to exchange information reliably, S35 refers to this type as functional requirements delivered by the systems in a consistent and established manner. The social-technical group deals with social-technical aspects related to organizations and people’s needs and contains 11 types, as shown previously in Figure 2. The social-technical and individual group comprises four types with initial understanding and addressed in S4 and S6 only. These types are newer (compared to others) and cope with interoperability beyond the software boundaries: (i) cultural (to be used by transnational organizations to deal with different languages, traditions, religions, and ethics while collaborating in the same domain); (ii) knowledge (to promote sharing of intellectual assets and repositories); (iii) rules (to align and match business and legal rules on organizations’ automated transactions); and (iv) social networks (to promote the ability of enterprises to use and interconnect with social networks for collaboration purposes). Social-technical and organization group comprises seven types. The organizational type, a stable type, aims to align business processes to carry out cross-organizational interactions and is a concern of 15 studies (S1, S3, S4, S5, S6, S8, S13, S15, S17, S19, S20, S25, S27, S30, and S32). All five interoperability types with ongoing understanding follow business guidelines to promote interaction among organizations and process alignment (as addressed by nine studies: S2, S4, S6, S8, S14, S16, S19, S21, and S27). In general, these types seem to be the same but with some differences in their definitions and were proposed mainly by domain-specific studies. For instance, business is addressed in enterprise domain (S2 and S4), process in cyber-physical systems (S8 and S14), business process in health (S27), and enterprise in Industry 4.0 (S16). Furthermore, operational (S8, S14, and S21) is a specific type focused on project’s cost and time, and process failures as well. From a broader view, these five types with ongoing understanding and domain-specific could be considered sub-types of organizational (which is a domain-independent type). With respect to crosscutting group, it contains only one type (legal) found in four studies (S5, S15, S21, and S30). Legal interoperability may impact both technological and social-technical aspects of SIS; hence, we considered it as having a crosscutting nature. We also considered legal has a stable understanding and concerns the legal aspect of business processes and software functionalities, such as government laws and enterprise policies. In particular, S5 and S15 addressed e-government, evidencing legal interoperability can be relevant for this domain. In summary, the eight stable types (technical, blockchain, cloud, pragmatic, semantic, syntactic, legal, and organizational) seem to have already a consensus regarding their definition in the literature. Otherwise, most types (21) still have an initial understanding, with few studies addressing them. Moreover, five types (business, business process, enterprise, operational, and process), all of them directly related to organizational interoperability, have ongoing understanding, and data and functional present misunderstanding, despite the number of studies that mention it. After deeply analyzing each interoperability type, its definitions, and possible categorization (as previously shown in Figure 2), we considered the publication year of the secondary studies and drew Figure 3. For instance, seven studies were published in 2019 and mentioned semantic. The intention of this figure was to provide an overall view of the stability of types and quantity of secondary studies addressing them and, therefore, the interests in those types over the years. The year 2019 had the most studies published (eight studies), as previously listed in Table 1, so this year concentrates many types. At the same time, the three studies published in 2014 also concentrate many types. Additionally, semantic was the most recurrent one (in 30 studies) followed by technical (20), organizational (15), and syntactic (12); in particular, they are addressed in most interoperability models and frameworks (e.g., LCIM encompasses technical,syntactic,semantic, and pragmatic, while EIF addresses organizational) (Section 4.3 further discusses models or frameworks). Besides, semantic seems to keep the interest over the years. We also observe that due to the increasing interest in IoT, cloud computing, Industry 4.0, and other domains that require smart systems, technical has also drawn attention due to the high heterogeneity of hardware and software infrastructure and the lack of standards for that. As a highlight, organizational (with a stable understanding) is the most recurrent among the social-technical ones. In turn, this type has been a concern since enterprises started demanding interoperability among their systems, as found in S1, which addressed interoperability in enterprise information systems. Additionally, the most recurrent types in the secondary studies also present stable understanding (i.e., organizational, semantic, syntactic, and technical). Finally, blockchain seems to be a new trend having six studies associated since 2021. In summary, the diversity of interoperability types from various studies reveals the interest and concern of the community in the field of systems interoperability. Many definitions or understandings of interoperability types exist with their specificities, similarities, some overlapping, and even divergences. Moreover, the continuous emergence of new types over the years to solve interoperability issues coming from new technologies (e.g., cloud-based or blockchain) or new domains (e.g., Industry 4.0) indicates that several open issues still need to be solved. 4.3 Interoperability Models and Frameworks Concerning RQ2 (Which are the existing interoperability models and frameworks?), we looked for existing models and frameworks (which usually include interoperability models) addressed in the secondary studies. Table 3 shows the 13 different interoperability models (six conceptual models and seven IAM) and six different frameworks found in 12 (of 37) studies. We believe these models and frameworks are the most relevant because the secondary studies contemplated them. Still, we also believe there are others out of the scope of these studies. Interoperability models organize interoperability types and can be a conceptual model or an IAM. A conceptual model presents types and relationships among them that are usually hierarchical. An IAM encompasses interoperability types, barriers, achievement levels (stages, phases, or dimensions that are commonly associated with one interoperability type or with desired attributes), and means to measure and evolve interoperability [76]. An interoperability framework not only organizes the types but also addresses different aspects, including assumptions, concepts, values, practices, software solutions, interoperability achievement guidelines, reference architectures, and others. Hence, frameworks refer to a more complete way (compared to interoperability models) to deal with interoperability issues and achieve different purposes. We observed there are still misunderstandings concerning the models and frameworks. For example, a study classified LCIM as an IAM, but it is a conceptual model [87]. i-Score was also classified as IAM, while it is indeed a method for interoperability assessment [37] and, therefore, we did not consider it in our study. Another example is e-GIF (found in S20), which refers to any frameworks for e-government domain, then removed from our analysis. Other studies presented misunderstandings regarding the interoperability types contained in models and frameworks. Hence, we assumed that the secondary studies served us to identify relevant models and frameworks. To complement our analysis, we examined primary studies and other external materials, such as technical reports, websites, books, and others. Figure 4 presents a panorama of the interoperability models (conceptual models and IAM) and frameworks distributed over the years when they were first delivered. Appendix A of this work summarizes the interoperability types or levels of each model and framework. Some models and frameworks were updated: LCIM (in 2005), NMI (NATO C3 Technical Architecture Reference Model for Interoperability) (2007), and EIF (2017), and some served as a basis to derive others. We also observed that some models or frameworks were initiatives of standardization organizations (e.g., IEEE (Institute of Electrical and Electronics Engineers), DTMF (Distributed Management Task Force), and ISO (International Organization for Standardization)) and research institutions like SEI (Software Engineering Institute). Others are from research projects or international calls such as H2020[12] or even government interests. In particular, US military forces have been continually interested in interoperability issues and introduced the three first interoperability models: SoIM (Spectrum of Interoperability Model) in 1980 [51], MCISI (Military Communications and Information Systems Interoperability) in 1996 [3], and LISI in 1998 [21]. Moreover, NATO (North Atlantic Treaty Organization) introduced NMI in 2003 with an interest in promoting interoperability among systems from different nations [66]. Backing to the beginning of the 1980s, distinct interoperability issues began to be organized. In the case of SoIM and MCISI, technical and syntactic aspects of interoperability were taken into account for the military domain. At the end of the 1990s, LISI introduced a new proposal based on levels to organize interoperability issues. Moreover, LISI can be considered the first IAM and the first that contemplated enterprise issues as interoperability concerns; hence, it has contributed as a reference to derive or influence other models (e.g., LCI, LCIM, and OIM (Organizational Interoperability Maturity Model)). We can also observe that both MCISI and LISI focused on information systems, probably due to the need to interoperate this class of systems at that time. In more detail, LISI focuses on assessing the interoperability maturity in information systems. It defined five interoperability levels [21]: (i) level 0 (isolated - interoperability in a manual environment); (ii) level 1 (connected - interoperability in a peer-to-peer environment); (iii) level 2 (functional - interoperability in a distributed environment); (iv) level 3 (domain - interoperability in an integrated environment including domain data models and procedures); and (v) level 4 (enterprise - interoperability in a universal environment including enterprise data models and procedures). These levels are not explicitly related to interoperability types, but LISI named these levels and defined the desired characteristics for each level. LISI also defines four attributes within each level (summarized by the acronym PAID (Procedures, Applications, Infrastructure, and Data)) to encompass the range of interoperability considerations. In summary, LISI offers a matrix with the five levels in the rows and the four attributes in the columns. Each matrix’ cell describes the abilities or capabilities needed to achieve a specified level of interoperability for a specific attribute. Still, at the end of the 1990s and derived from LISI, OIM emerged as another IAM as an initiative of DST[13] (Australian Defense Science and Technology Organization) and aimed to assess the ability of organizations to interoperate among them considering human-activity aspects [26]. In more detail, OIM presents five levels [26]: (i) independent (no interaction); (ii) ad-hoc (ad-hoc arrangements); (iii) collaborative (shared goals, roles and responsibilities); (iv) integrated (common understanding and preparedness); and (v) unified (shared knowledge base across the systems). OIM also presents four attributes to assess interoperability among organizations [26]: preparedness, understanding, command style, and ethos. Based on OIM, OIAM (Organizational Interoperability Agility Model) appeared to address agility attributes (e.g., open and dynamic) as assessment items [48]. It is worth highlighting that OIM, OIAM, EIMM [9], and MMEI (Maturity Model for Enterprise Interoperability) [35] are domain-independent models, while the other two — ULSSIMM (Ultra Large Scale Systems Interoperability Maturity Model) [74] and DIAM (Disaster Interoperability Assessment Model) for disaster response management systems [54] — are domain-specific ones. We can observe that besides offering interoperability categorization, these IAM present attributes to interoperability measurement in general. Indeed, such an assessment can determine the strengths and weaknesses of an entity (or system) in terms of interoperability. These models usually offer means (e.g., methodologies or guidelines) to identify the current interoperability level (in which an entity is placed) and achieve the desired level. Hence, IAM show that interoperability, more than a non-functional requirement to be implemented in software systems, is a continuous issue that organizations should pursue. Backing to the beginning of the 2000s and derived from LISI and/or OIM, three interoperability models emerged: LCI, LCIM, and NMI. LCI went beyond by dealing with interoperability issues not explicitly addressed in LISI; LCI introduced the concept of coalition interoperability that aims the collaboration of several organizations [84]. LCI presented two layers (technical and organizational), also referred to as layers of coalition interoperability. The technical layer comprises four levels (physical, protocol, data/object model, and information), and the organizational layer contains four levels (aligned procedures, aligned operations, harmonized strategies/doctrines, and political objectives). Between both layers, the knowledge/awareness level appears as intermediate level. Hence, LCI is relevant by first coping with social-technical interoperability issues, particularly through the organizational layer. Another relevant model is LCIM, the most recurrent one in the secondary studies. This model classifies the interoperability issues into seven conceptual levels (no interoperability, technical, syntactic, semantic, pragmatic, dynamic, and conceptual). It is worth highlighting that its updated version [89] mapped each level explicitly to an interoperability type. LCIM has influenced many interoperability solutions and other models and frameworks despite its simplicity. For instance, some have adopted the strategy to associate a level to an interoperability type (e.g., EIF, GridWise, INTEROP, AIF, and ULSSIMM), and others have adopted semantic interoperability concerns(e.g., EIF, e-GiF, and ULSSIMM). The LCIM highest levels (i.e., pragmatic, dynamic, and conceptual) focus on diverse core requirements to assure systems collaborations. Otherwise, NMI focused specifically on technical interoperability and defined four degrees considering manual and automated activities to achieve interoperability among systems: (i) unstructured data exchange (human-readable text); (ii) structured data exchange (human and manual interpretable data); (iii) seamless sharing of data (common and automated data model); and (iv) seamless sharing of information (universal and automated data processing). In its updated version in 2007, NMI kept the degrees but aligned to the LISI levels. Another model introduced at that time was SoSI, proposed by SEI. This model is the first that explicitly addresses the interoperability in SoS (Systems-of-Systems), a class of systems with unique characteristics mainly regarding the managerial and operational independence of constituent systems [28]. SoSI considers four interoperability types (technical, programmatic, constructive, and operational), each one associated with a given level. Interoperability frameworks go beyond conceptual models and IAM as they combine several elements to overcome interoperability challenges. Initiatives worldwide exist, such as EIF in Europe and Gridwise in the US. These initiatives are destined for different domains, including enterprises (AIF, INTEROP, and IDEAS), public services (EIF), and electric power (GridWise), and have covered different interoperability types. In particular, EIF can be considered one of the most complete and well-known frameworks. EIF was proposed in the context of an H2020 project and provided several strategies and guidance for developing and updating the nations’ interoperability frameworks and policies. EIF contributes to establishing a single digital market by fostering cross-border and cross-sectoral interoperability to deliver European public services. This framework addresses interoperability relationships among public services, between public services and non-public enterprises, and between public services and ordinary citizens. EIF comprises [30]: (i) a set of 12 principles to establish general behaviors on interoperability; (ii) a conceptual model for designing and operating interoperable public services; and (iii) a layered interoperability model that organizes different interoperability aspects. This model is considered a primary element in establishing an interoperability-by-design paradigm to the other EIF elements and has four interoperability layers (legal, organizational, semantic, and technical), integrated public governance as a crosscutting layer, and interoperability governance as a background layer. EIRA[14] (European Interoperability Reference Architecture) is another initiative of the same consortium that, aligned with the EIF, specifies four building blocks for developing interoperable public services. Each block corresponds to one of four interoperability types of EIF layers. As we can see, EIF is a comprehensive framework that, in addition to establishing conceptual aspects, provides guides for interoperability implementation, aiming to facilitate its adoption. As EIF targets the European community, legal interoperability is an essential aspect of being considered. Another well-known framework is AIF (ATHENA Interoperability Framework), a result of ATHENA project[15] that provided solutions to meaningful interoperation among enterprises. AIF contains guidelines to address business needs and technical requirements for interoperability based on a multidisciplinary and model-driven solution approaches in solving interoperability problems. AIF encompasses four types of interoperability achievement (from the lowest to the highest): information/data, services, process, and enterprise/business. Semantic aspects are considered a crosscutting barrier that should be overcome at all levels. This framework is structured into three parts: (i) conceptual integration (which focuses on concepts, meta models, languages, and model relationships and provides a modeling foundation for systematizing several aspects of interoperability); (ii) applicative integration (which focuses on methodologies, standards, and domain models and provides guidelines, principles, and patterns that can be used to solve interoperability issues); and (iii) technical integration (which focuses on developing ICT environments). AIF also provides tools and platform specifications for developing and running enterprise applications and software systems. Among other artifacts, AIF comprises: (i) EIMM (Enterprise Interoperability Maturity model, which defines concerns and maturity levels to determine the current ability of an enterprise to collaborate with external entities and specify the path to improve this ability); and (ii) IIAM (Interoperability Impact Analysis Method, which focuses on the return of investment (ROI) and the impact of the interoperability measures). Similarly to AIF, another enterprise-oriented framework is INTEROP[16] , proposed by the INTEROP Network of Excellence [24]. INTEROP presents four concerns (business, data, process, and service), three barriers (conceptual, technological, and organizational), and three approaches (federated, unified, and integrated) aiming to identify the barriers in the early phases before implementing the interoperability solutions. IDEAS is another framework with an important contribution by highlighting that interoperability among enterprises could be achieved considering different types (application, business, communication, data, and knowledge) [102]. Finally, the U.S. Department of Energy proposed GridWise in 2007 to enable interoperability among various entities that interact with the electric power system [97]. A very recent framework is BIF (Blockchain Interoperability Framework), published in 2021 [12], that classifies solutions that connect different blockchain systems, enabling a more comprehensive interoperability analysis. BIF classifies interoperability solutions into public connectors, hybrid connectors, and blockchain of blockchains. As a highlight, all other studies we found and deal with blockchain interoperability are aligned to this framework [32, 41, 92]. Hence, for a while, BIF can be considered a reference for the blockchain context. We observed that frameworks found in our work consider mainly those interoperability types that are part of technological group and with stable understanding (as previously shown in Figure 2), such as technical, syntactic, and semantic. These three types seem to form a basic stack for becoming a software system interoperable. Moreover, models and frameworks often address interoperability types in social-technical group, particularly related to organizations, such as organizational, business, and enterprise. Finally, there are many interoperability models and frameworks, but few are widely adopted in the industry, as already stated previously in [36]; at the same time, a model with good impact is LCIM, well-known frameworks are EIF and AIF, and a framework with potential wide adoption is BIF, considering the popularity that blockchain has gained. 4.4 Domains and Interoperability Solutions Concerning RQ3 (Which are the domains and their related solutions for interoperability?), we found 12 different domains addressed in 33 (of 37) studies, listed in Table 4. It is worth highlighting these domains refer to those as referenced by the studies. We only joined those that can be clearly considered synonymous, like Industry 4.0 and IIoT (Industrial Internet of Things). While some domains represent a segment of the reality for which software systems are developed, such as health and Industry 4.0, others refer to hardware and software infrastructure for supporting the development and execution of systems (e.g., cloud computing and blockchain). We also collected the interoperability solutions (and their categories) for those domains[17] from the secondary studies. Table 4 lists the category of these solutions (i.e., conceptual model, domain-specific model, framework, ontology, meta-model, platform, and standard) and those interoperability types explicitly addressed by these solutions; therefore, these types are a subset of those presented previously in Table 2. The health domain has drawn attention and appeared in nine studies(S3, S7, S26, S27, S29, S31, S32, S35, and S36). In particular, S26 also addressed IoT and both S32 and S36 coped with blockchain. The ability of health information systems to communicate and work together is crucial for efficient management of health services, public health initiatives, high-quality care for patients, and clinical research. When interoperability is lacking, medical information becomes disorganized, repetitive, and difficult to access, leading to lower quality care and a waste of financial resources [88]. In the health domain, semantic interoperability seems to be a major concern, in particular, for EHR (Electronic Health Record) based systems that have used ontologies and web standards (e.g., OWL (Ontology Web Language)). However, no consensus about standards for EHR still exists. Syntactic and technical interoperability have been treated through the adoption of several standards, for instance, HL7 v3 messaging, FHIR (Fast Healthcare Interoperability Resources), openHR, ISO 13606, and DICOM (Digital Imaging and Communications in Medicine). We also observed that health equipment manufacturers usually adopt one of the proposed standards and implement a mapping to other solutions to achieve interoperability. HIMSS[18] (Healthcare Information Management Systems Society), a global advisor for the transformation of the health ecosystem, continuously works on technical, syntactic, and semantic interoperability. Another interesting initiative is THR (Transnational Health Record) system framework [53], which considers technical, syntactic, semantic, and business process interoperability levels to promote health globally, aiming to achieve digital healthcare without borders. Furthermore, the business interoperability deals with workflows to several processes, such as user data registration and accesses. The health domain has also worked to achieve interoperability as a non-functional requirement; particularly, the next challenges is the organizational type (S3, S27 and S32). Due to the use of IoT in the medical ecosystems and the heterogeneity in health systems, technical and syntactic interoperability are still issues to be solved (S26). Using blockchain in the health industry can address the challenges faced in cross-domain EHR solutions, ensuring privacy and scalability (S32 and S36). Over the years, interoperability in the health domain has been a constant concern, given that there are studies published from 2015 (S3) to 2023 (S36); in particular, S35 details and classifies several interoperability solutions for health systems. In summary, the health domain has recognized the significance of interoperability as a cross-cutting factor in healthcare systems (S35). In addition, this domain has considered the impact of various technologies, such as IoT (S26) and blockchain (S32, S35, and S36), on different aspects of its systems. Interoperability is also a primary non-functional requirement for enterprise and e-government domains (as found in S1, S2, S5, S15, and S20). According to three studies (S2, S5 and S15), the Internet and its communication protocol have supported the interoperability in these domains, leading to the emergence of e-business and e-government concepts. Companies need to align their business rules, policies, and constraints to cooperate among them, and then interoperability must go beyond communication platforms that host software systems. These domains have then invested in frameworks, such as EIF and AIF, as S20 mentioned. Regarding the interoperability types, technical, syntactic, and semantic are also a concern in these domains. Those types (i.e., business, enterprise, and process) associated with organizational interoperability also appeared. Additionally, legal seems relevant when dealing with government systems, but this type is still little studied. addresses the challenges of enabling end-to-end communication among all production-relevant assets on the shop floor and information technologies [14]. The complexity of this domain requires solutions for different interoperability types. S28 details an extensive list of solutions (e.g., protocols, API, gateways, and middleware), butstill no de facto solution. In particular, ontologies appeared to solve semantic interoperability in S16 and S18; however, just considering this type seems insufficient due to the need to integrate several IoT application layers separately from data acquisition and hardware/software platforms. Industry 4.0 Hence, three new types have been considered [70]: (i) device (to provide information exchange between physical and software components); (ii) network (to deal with seamless communication of devices over different networks); and (iii) platform (to offer a collaboration of the diverse platforms used in IoT due to diverse operating systems, programming languages, and access mechanisms for data and things). Additionally, data interoperability refers to a larger type that encompasses these three types to treat heterogeneity jointly. According to S18, interoperability standards must be sought to obtain the most cost-effective solutions in this scenario. Other more comprehensive and integrative solutions are Industry 4.0 reference architectures [65], including IIRA (Industrial Internet Reference Architecture) [44] and RAMI 4.0 (Reference Architecture Model for Industry 4.0) [45], the most relevant ones in the Industry 4.0 community. As a closer domain of Industry 4.0, manufacturing also comprises software systems that concern industrial product development and management life cycle. Companies use different strategies and technological sources across PDP (product development process), embodying different characteristics and perspectives to meet the customers’ needs. Similar to Industry 4.0 domain, semantic interoperability is considered to solve the hardware and software heterogeneity (as pointed out in S13 and S25). Additionally, industry players apply meta-models, domain-specific models, and frameworks to cope with distinct perspectives (e.g., mechanical engineering, electrical engineering, and computer science) of information sharing across different phases of product development. have also brought challenges due to the need to integrate a heterogeneity of elements, including physical and software components, while they sometimes operate in critical application domains. Hence, beyond technical, syntactic, and semantic interoperability, other types appeared (data, constructive, information, operational, programmatic, and systems) to deal with specific aspects of these systems, such as equipment maintenance, acquisition of management information, and reliable information exchange (S8 and S14). Cyber-physical systems In the same direction, the domain of constructive systems (i.e., those that manage the planning, design, construction, operation, and maintenance of buildings) also has its specificities and the need to interoperate different kinds of systems (such as for digital representations of physical and functional characteristics of places), leading the need of business, data, process, and service interoperability. Domain-specific models are solutions for those interoperability types (S19). use context information to characterize a given situation, person, object, or place. S17 presented frameworks to deal with organizational interoperability and overcome distinct context data representation. Surprisingly, pragmatic interoperability, an LCIM interoperability level that considers context information, does not appear in the study. Context-awareness software systems Otherwise, focuses on pragmatic interoperability to achieve the desired interoperation since the context is taken into account in the message exchange. To cope with this interoperability type, meta-model, ontologies, and platforms have been used to manage the context, intention, and effect of messages exchange (S10). collaborative systems A couple of studies addressed cloud computing, IoT, and blockchain. In particular, cloud computing is a paradigm managing a pool of virtualized resources at infrastructure, platform, and software levels to deliver them as services over the Internet, storing and managing large amounts of heterogeneous data [80]. Cloud providers are categorized into proprietary and open-source platforms, and most of them have their API, protocol, and data format [58]. Due to the lack of adoption of standards in such a heterogeneous environment, when users want to shift to another provider or use additional services from different providers, they face the lock-in situation (S9 and S11). As the most obvious solution for cloud interoperability seems to be standards, several organizations are working on proposals, such as ISO/IEC 17788:2014, DCRM (Distributed Computing Reference Model), OCCI (Open Cloud Computing Interface) specifications, CIMI (Cloud Infrastructure Management Interface), and CDMI (Cloud Data Management Interface). Like Industry 4.0 and cyber-physical systems, cloud computing also investigates semantic interoperability solutions, such as OWL, SPARQL Protocol, and RDF Query Language. Open libraries, model-based, and open-service solutions are under investigation to manage inter-cloud interoperability issues. creates an ecosystem in which people and things interconnect among them through the Internet. The information exchange occurs anytime and anywhere, with devices and sensors monitoring people and the environment and generating a large volume of data that different applications can consume. The heterogeneity of IoT (e.g., hardware, network, software infrastructure, applications, and data acquisition protocols) often hampers the interoperability of IoT-based systems. IoT Hence, these systems often operate in vertical silos and adopt semantic interoperability approaches, such as Semantic Web technologies (e.g., OWL and RDF) and SSN (Semantic Sensor Network) ontology (S22 and S23). At the same time, the adoption of common semantics (for instance, through ontology or shared schema) cannot be viable in some cases, leading to the need for new types of low-level interoperability, such as device and platform (S24). Additionally, cloud and edge platforms (used to store data) and Software Defined Network (SDN) (a network-level integration approach) are used (S28). is a distributed ledger system that allows reliable transactions among untrusted network participants. As S30 pointed out, various use cases have diverse requirements, requiring the adoption of blockchains with different capabilities. Blockchain As a result, like in the IoT domain, blockchain systems exist and operate in silos, and people cannot reap the full benefits of blockchain technology (S34 and S35). Blockchain interoperability enables smart contract invocations, asset exchanges, and data verification, increasing flexibility, application migration, and scalability. However, achieving interoperability poses several challenges, including security and privacy (S35). According to S30, blockchain interoperability deals with three significant aspects: (i) interoperability between different blockchains; (ii) interoperability between decentralized applications (dApps) using the same blockchains; and (iii) interoperability between blockchain and other technologies such as enterprise systems. In this context, interoperability makes possible that different transaction between different chains can be: (i) Cross-Chain Transaction (CC-Tx), which belongsto the same blockchain system (homogeneous blockchain); and (ii) Cross-Blockchain Transaction (CB-Tx) between different blockchains (heterogeneous blockchain). Moreover, the solution is often classified into blockchain of blockchains (BoB), public and hybrid connectors. BoB is usually referred as a platform for developers to construct Cross-Chain dApps (CC-dApps) spread across multiple blockchains (e.g., Polkadot, Cosmos, and Ethereum). Connectors-based solutions coordinate the token-transferring process on distinct ledgers and serve as a translator between different ledger protocols (e.g., HTLC (public) and ILP (hybrid)) (S30). An alternative way to classify solutions is presented in S37: (i) chain, target to public blockchains (e.g., Loom, Rootstock, and Herdius); (ii) bridge, that is a connectors component across blockchains (e.g., BTC Relay and Peace Relay); and (iii) dApp-based interoperability solutions, target provide interoperability among applications and blockchains (e.g., Overledger and Plebeus). In summary, we can say that most domains concern with semantic interoperability, which has ontologies and conceptual models as the most recurrent solutions (found in S3, S9, S13, S16, S18, S22, S23, S24, S25, S28, and S31). Additionally, we observe technical and syntactic interoperability have been sometimes solved in different domains with the adoption of standards. Although standards facilitate the development of computational solutions, particularly in IoT and cloud computing, industry stakeholders have not widely adopted them, often leading to lock-in problems. Similar to IoT and cloud computing, the blockchain domain has faced heterogeneity issues but the studies deal with a specific type — the blockchain interoperability type — to address their solutions. Other common solutions in diverse domains are platforms, API, reference architectures, and gateways that have also provided technical, syntactic and semantic interoperability solutions (as in S24 and S26). Furthermore, the primary solutions to manage organizational interoperability (including business, enterprise, and process) are frameworks and conceptual models (S2, S3, S14, S15, and S27). Our intention with this RQ is not to be exhaustive but to bring a broader view of what the secondary studies discussed. The domains mentioned above may have many other interoperability solutions and types; besides, practically all other existing domains present interoperability issues requiring specific investigation. [10] The detailed calculation is available in https://bit.ly/3Zb87v9 . [11] All definitions of each interoperability type and the raw data extracted from studies and used to answer RQ1 are available at https://bit.ly/3Zb87v9. [12] http://www.ec.europa.eu/horizon2020 [13] https://www.dst.defence.gov.au [14] https://joinup.ec.europa.eu/collection/european-interoperability-reference-architecture-eira [15] https://cordis.europa.eu/project/id/507849 [16] Originally named EIF (Enterprise Interoperability Framework), but referred to as INTEROP in this work to avoid misunderstanding with EIF (European Interoperability Framework). [17] The complete list of interoperability solutions is available at https://bit.ly/3Zb87v9. [18] https://www.himss.org/ This paper is available on under CC 4.0 license. arxiv