Interoperability is a characteristic of a product or system to work with other products or systems. While the term was initially defined for information technology or systems engineering services to allow for information exchange,Institute of Electrical and Electronics Engineers. IEEE Standard Computer Dictionary: A Compilation of IEEE Standard Computer Glossaries. New York, NY: 1990. a broader definition takes into account social, political, and organizational factors that impact system-to-system performance.
Types of interoperability include syntactic interoperability, where two systems can communicate with each other, and cross-domain interoperability, where multiple organizations work together and exchange information.
Types
If two or more systems use common data formats and communication protocols, then they are capable of communicating with each other, and they exhibit syntactic interoperability. XML and SQL are examples of common data formats and protocols. Low-level data formats also contribute to syntactic interoperability, ensuring that alphabetical characters are stored in the same ASCII or a Unicode format in all the communicating systems.
Beyond the ability of two or more computer systems to exchange information, semantic interoperability is the ability to automatically interpret the information exchanged meaningfully and accurately in order to produce useful results as defined by the end users of both systems. To achieve semantic interoperability, both sides must refer to a common information exchange reference model. The content of the information exchange requests are unambiguously defined: what is sent is the same as what is understood.
Cross-domain interoperability involves multiple social, organizational, political, legal entities working together for a common interest or information exchange.Slater, T. , , 2013
Essential properties of an interoperability standard An interoperability standard must observe these properties:Oasis Open, Interoperability Guidelines, https://www.oasis-open.org/policies-guidelines/interoperability-guidelines; ETSI, Solve the Challenge of Interoperability! Interoperability Best Practices, https://www.etsi.org/images/files/Events/interoperability_best_practices_handbook.pdf Closed feature set (no extensions or subsetting): The specification must be normative and bounded. The standard must state that a compliant implementation supports the entirety of the base standard and nothing else. The standard must not allow vendor-specific extensions. The standard may define allowable subsets, but must exclude vendor-specific or vendor-defined subsetting. Later versions of a standard need not be 100% backward compatible, but deviations are precisely specified. Deterministic Output: The standard must define explicit and invariant requirements around input-to-output mappings. The standard must permit no “implementation defined” behaviors. The standard may permit implementations to set limits on maximum size, capacity, etc., but must require uniform, conforming behaviors within those limits. The standard document uses the word "shall" essentially exclusively, and "may" or "should" in only rare cases (for example, error handling that must be delegated to an external system). For standards governing real-time processes, Exhaustive Error Handling: Rather than leaving errors to "implementation-defined" logic, the standard must mandate exact error codes, state transitions, and fallback behaviors to maintain system stability. Platform & Vendor Neutrality: The definitions must remain divorced from specific internal system architectures, programming languages, or operating environments. Reference implementation: while it is not essential to specify a reference implementation, that is common. The standard may provide for resolution of ambiguities or omissions to ensure uniform implementation. The standard may include a test suite for conformance testing.
Interoperability and open standards Interoperability implies exchanges between a range of products, or similar products from several different vendors, or even between past and future revisions of the same product. Interoperability may be developed post-facto, as a special measure between two products, while excluding the rest, by using open standards. When a vendor is forced to adapt its system to a dominant system that is not based on open standards, it is compatibility, not interoperability.
Open standards
Open standards rely on a broadly consultative and inclusive group, including representatives from vendors, academics and others holding a stake in the development, that discusses and debates the technical and economic merits, demerits and feasibility of a proposed common protocol. After the doubts and reservations of all members are addressed, the resulting common document is endorsed as a common standard. This document may be subsequently released to the public, and henceforth becomes an open standard. It is usually published and is available freely or at a nominal cost to any and all comers, with no further encumbrances. Various vendors and individuals (even those who were not part of the original group) can use the standards document to make products that implement the common protocol defined in the standard and are thus interoperable by design, with no specific liability or advantage for customers for choosing one product over another on the basis of standardized features. The vendors' products compete on the quality of their implementation, user interface, ease of use, performance, price, and a host of other factors, while keeping the customer's data intact and transferable even if they choose to switch to another competing product for business reasons.
However, while "open" is a necessary condition for an interoperabilty standard, it is not a sufficient condition. For example, the standard-setting processes for the Fortran, C, and C++ languages are open, with a broadly-inclusive consultative group. But the resulting standards are not interoperability standards.
Post facto interoperability
Post facto interoperability may be the result of the absolute market dominance of a particular product in contravention of any applicable standards, or if any effective standards were not present at the time of that product's introduction. The vendor behind that product can then choose to ignore any forthcoming standards and not cooperate in any standardization process at all, using its near-monopoly to insist that its product sets the de facto standard by its very market dominance. This is not a problem if the product's implementation is open and minimally encumbered, but it may well be both closed and heavily encumbered (e.g., by patent claims). Because of the network effect, achieving interoperability with such a product is both critical for any other vendor if it wishes to remain relevant in the market, and difficult to accomplish because of lack of cooperation on equal terms with the original vendor, who may well see the new vendor as a potential competitor and threat. The newer implementations often rely on clean-room reverse engineering in the absence of technical data to achieve interoperability. The original vendors may provide such technical data to others, often in the name of encouraging competition, but such data is invariably encumbered and may be of limited use. Availability of such data is not equivalent to an open standard, because: The data is provided by the original vendor on a discretionary basis, and the vendor has every interest in blocking the effective implementation of competing solutions, and may subtly alter or change its product, often in newer revisions, so that competitors' implementations are almost, but not quite completely interoperable, leading customers to consider them unreliable or of lower quality. These changes may not be passed on to other vendors at all, or passed on after a strategic delay, maintaining the market dominance of the original vendor. The data itself may be encumbered, e.g., by patents or pricing, leading to a dependence of all competing solutions on the original vendor, and possibly leading to a revenue stream from the competitors' customers back to the original vendor. This revenue stream is the result of the original product's market dominance and not a result of any innate superiority. Even when the original vendor is genuinely interested in promoting healthy competition (so that he may also benefit from the resulting innovative market), post-facto interoperability may often be undesirable as many defects or quirks can be directly traced back to the original implementation's technical limitations. Although in an open process, anyone may identify and correct such limitations, and the resulting cleaner specification may be used by all vendors, this is more difficult post-facto, as customers already have valuable information and processes encoded in the faulty but dominant product, and other vendors are forced to replicate those faults and quirks for the sake of preserving interoperability even if they could design better solutions. Alternatively, it can be argued that even open processes are subject to the weight of past implementations and imperfect past designs and that the power of the dominant vendor to unilaterally correct or improve the system and impose the changes to all users facilitates innovation. Lack of an open standard can also become problematic for the customers, as in the case of the original vendor's inability to fix a certain problem that is an artifact of technical limitations in the original product. The customer wants that fault fixed, but the vendor has to maintain that faulty state, even across newer revisions of the same product, because that behavior is a de facto standard and many more customers would have to pay the price of any interoperability issues caused by fixing the original problem and introducing new behavior.
Government
eGovernment Speaking from an e-government perspective, interoperability refers to the collaboration ability of cross-border services for citizens, businesses and public administrations. Exchanging data can be a challenge due to language barriers, different specifications of formats, varieties of categorizations and other hindrances.
If data is interpreted differently, collaboration is limited, takes longer and is inefficient. For instance, if a citizen of country A wants to purchase land in country B, the person will be asked to submit the proper address data. Address data in both countries includes full name details, street name and number, as well as a postal code. The order of the address details might vary. In the same language, it is not an obstacle to order the provided address data, but across language barriers, it becomes difficult. If the language uses a different writing system it is almost impossible if no translation tools are available.
Flood risk management Interoperability is used by researchers in the context of urban flood risk management. Cities and urban areas worldwide are expanding, which creates complex spaces with many interactions between the environment, infrastructure and people. To address this complexity and manage water in urban areas appropriately, a system of systems approach to water and flood control is necessary. In this context, interoperability is important to facilitate system-of-systems thinking, and is defined as: "the ability of any water management system to redirect water and make use of other system(s) to maintain or enhance its performance function during water exceedance events." By assessing the complex properties of urban infrastructure systems, particularly the interoperability between the drainage systems and other urban systems (e.g. infrastructure such as transport), it could be possible to expand the capacity of the overall system to manage flood water towards achieving improved urban flood resilience.