The Open Group Standard
This document is The Open Group Standard for Open Interoperability Framework. It has been developed and approved by The Open Group. A forcing function for this standard is the EU Digital Markets Act (DMA).
The purpose of this standard is to assist organizations that have a requirement to interoperate their business systems with other business systems either within their organization or with other organizations.
The EU Digital Markets Act legislation drives the need for open interfaces to enable interoperability and thus there is a need for an Open Interoperability Framework Standard. This standard will also help an organization achieve Boundaryless Information Flow.
TOGAF defines interoperability as: The ability to share information and services.
Interoperability is defined by ISO Technical Committee 184, Subcommittee 5 (ISO/TC 184/SC 5), “Architecture, Communications and Integration Frameworks” as follows:
Interoperability - Two or more entities (devices, equipment, machines, people, processes, applications, software units, systems, enterprises) can exchange items (information, material, energy, control, assets, ideas) in order to perform their respective tasks. Items exchanged according to a set of rules and mechanisms implemented by an interface in each entity. Inter-operating entities have a common understanding of the properties of the items exchanged.
Ensures that the precise meaning of exchanged data and information is preserved and understood throughout exchanges between parties, in other words ‘what is sent is what is understood’.
The Open Interoperability Framework (OIF) provides a structured approach to address the various challenges that must be overcome to enable interoperability. The OIF is visualized by a cube (see Figure 1). This cube must be applied for each interoperability interface independently. The cube consists of three slices:
The Systems Interoperability slice describes aspects of the information systems that are involved in these interoperability challenges. The elaboration of Systems Interoperability is entirely governed and architected in the ICT context.
The Organizational Interoperability slice describes generic aspects of the relation between interoperating organizations, the elaboration of which assumes governance and architecture of the business or administrative context.
The Legal Interoperability slice describes the aspects of policies and interoperability governance. Ultimately, this slice is responsible for security of the interoperability solution and mitigating the risks of interoperability.
Within Systems Interoperability and Legal Interoperability, a layered model is used because each interoperability use case is dependent on an implementation of all the layers and each layer cannot be implemented without the pre-requisite layer having been implemented.
Within Organizational Interoperability, the slice is organized in pillars because in each interoperability use case, only one pillar is used.
Subsections address each slice of the cube separately.
Figure 1 Open Interoperability Framework Cube
Systems interoperability is a layered approach to enable automated information systems to engage in a mutually cooperative process to achieve a common or compatible business goal. Systems Interoperability describes the mechanisms and protocols needed to allow systems controlled by different enterprises to collaborate in a meaningful way. It is defined in four layers. Each layer depends on a fully implemented interoperability solution for the next lower layer. The layers are (bottom to top):
• Network & Media Interoperability
• Technical Interoperability
• Semantic Interoperability
• Procedural Interoperability
Network & Media Interoperability is having the capability to exchange data, either by a common means of networking or by a common means of exchanging a physical medium that can be read and written. Within the network and media interoperability layer of systems interoperability challenges are rare but may impose limitations if the standards used by two (or more) parties exchanging are different such as deletion of data due to size limitations across different protocols or complete unreadability due to completely different media formats.
Today, with the internet the network interoperability for traditional and contemporary IT systems sharing data / information is not an issue as almost all organizations are connected to the internet where bandwidth, security and scalability standards are defined such as TCP/IP, HTTP/S, (S)FTP, SMTP, etc. Nevertheless, the following should be published while defining network topology for seamless interoperability:
Type(s) of communicating infrastructure.
The internet DNS naming convention – both external and internal.
IoT requirements
Security requirements – Firewalls, Routers, DMZ, login parameters, certificates, MFA, NAT IPs, etc.
Certain technologies do not fit neatly into a single layer. For example, with the proliferation of IoT (Internet of Things) wherein physical devices embedded with sensors, actuators and wire-less connectivity are also part of the network, sharing information with or among them is a challenge as the current IoT devices and systems are fragmented with respect to the network protocols that they support. IoT is being used in critical areas and contexts such as healthcare, security & surveillance, manufacturing industries, smart homes, smart city, etc. and though the industry is trying to come up with standards like LWM2M (Light Weight Machine-to-Machine), Bluetooth, Bluetooth Low Energy (BLE), MQTT, Open Group Standards (O-MI and O-DF), etc. convergence on a specific standard for specific application is still a challenge. As IoT devices are constrained in terms of size and can typically support little power, the choice of the network topology and protocols to be supported by the devices while designing IoT network in a given context should consider the following:
Simultaneous communication across devices in the network
Security within the network
Scalability in the technical capacity of the network
Range to be supported.
Data rate requirements
Power requirements
The use of physical media in organizations today is limited with the proliferation of cloud technology, which allows data to be backed up on cloud, which was one of the major component of media use in organizations. However, in alternate scenarios, the following should be agreed upon and published to allow interoperability of media:
Type of media and logistic requirements thereof
Naming conventions for physical media and data therein is addressed in the Semantic Interoperability layer.
Technical Interoperability is having the capability to resolve all kinds of technical differences between systems that need to interoperate and are therefore exchanging data but has no specific relation to the nature of the data at hand. These differences include, but are not limited to, syntactical differences, conversion between metric and non-metric units, between currencies, between time zones, between data formats, etc.
These differences can be addressed by agreeing to common standards for the exchange of data or by means of conversion, using a common technical gateway that helps converting data for the target systems for the following common generic data:
Different encodings of symbols and characters. Although increasingly encoding of symbols is based on the UTF-8 standard, many other code tables continue to be in use, for which the technical gateway can be used
Different standards for unit of measure. E.g. metric vs. anglo-saxon units, etc.
Different time zones. If systems operate in different time zones and are not using the standard UTC (Coordinated Universal Time) time then conversion of this type of data element can be done by the technical gateway
Different currencies. Conversion of currencies by the target system for book-keeping or maintaining log of transactions in local currency would require this conversion and can be done through the technical gateway.
Different languages. Translation across languages can be achieved by adopting UTF-8 encoding standards OR a technical gateway can be used for the purpose but for contextual translation semantic interventions are required.
Chopping and concatenation. The technical gateway can truncate and reassemble a message from a source system into a target system in case the target system doesn’t support a large message and it can do the opposite as well.
Checksum. To protect integrity of messages being exchanged as part of the interoperability requirements, checksums is a standard technique for validating message veracity. The technical gateway can both generate and verify all kind of checksums and replace these integrity verification attributes in case the interoperating systems use different techniques.
Transposition of tables. Series of data that represent table entries can be reordered in order to simulate row-column interchange. Generally all vector, matrix and tensor operations that only involve the execution of a mathematical process can be accommodated.
Reformat, compression or transcoding. Structured data can be transformed into different structures, essentially without changing anything to its content. This type of operation includes conversion between various file formats (e.g between Word 2003 document format and Open Document Format, or between AVI and MPG movie format). Compression of data (e.g. ZIP or RAR) and decompression also is covered by this capability.
Syntax. Any set of rules that define format of the payload but are independent of the meaning of the underlying data itself can be interpreted by the technical gateway in order to transform the data into a different format. Schemas, stylesheets, and DTDs are examples of this type of conversion.
Malignant data filtering. To prevent data that can have harmful effects in destination systems from reaching these systems, data containing binary logic that matches certain patterns can be detected, quarantained or destroyed.
Network & Media Layer. Both sides of a gateway (domains) independently operate and therefore could have mutually independent network and media interoperability in their respective domains. A gateway can define a standard for network and media interoperability on both sides, and therefore relaxes the requirement that the interoperating domains need to apply the same standards on both sides. It is sufficient that both sides each have a standard for network and media interoperability in common which can be interpreted by the Technical Gateway.
The technical gateway enables proper mapping of all data relevant for exchange as part of interoperability objectives to be mapped properly on messages formatted to a common standard endorsed by the interoperating systems / enterprises. The technical gateway assumes and is transparent for common semantics and compatible business processes. Special consideration must be given to the security attributes of the data to be exchanged. In particular, when data is to be exchanged in encrypted form, the technical gateway must be able to decrypt data in order to perform its conversions. This requires the technical gateway to be trusted by both interoperating enterprises. The above discussion assumes a 2-sided gateway that is able to cater to 2 enterprises exchanging data and can be deployed by either of the enterprise, however a multi-sided gateway, and/or a gateway deployed by an independent 3rd party may as well fulfil all requirements.
Semantic Interoperability is having the capability to achieve a common understanding of the meaning of any data that is to be handled as part of the business, whether the source of the data is internal or external to the business, either by agreeing on a common data model for the information to be exchanged or by means of semantic transposition, using a common semantic gateway. The semantic interoperability layer handles all context-specific transpositions that are necessary to properly understand the information that is meant with any data exchange between interoperating systems.
Figure TBD provides an overview of the subjects that must be understood and addressed to achieve semantic interoperability. The Open Group’s Open Data Element Framework (O-DEF) Standard provides a good starting point for several of the subjects identified in the Semantic Crop Circle. Each subject is further described in the following subsections.
Figure 2 Semantic Interoperability
As one begins the effort to achieve interoperability, it is helpful to identify relevant standardized vocabularies that are suitable for the domains that need to interoperate. If the O-DEF is adopted, then suitable plug-in standards can be utilized.
A property is a characteristic applicable to all members of an object class (see ISO/IEC 11179).
Note: A property is similar to an attribute used by the data modeling community. An example property is date of birth.
An object class is set of ideas, abstractions, or things in the real world that are identified with explicit boundaries and meaning, and whose properties and behavior follow the same rules (see ISO/IEC 11179).
Note: An object class or subclass is similar to an entity used by the data modeling community. An example object class is a person and an example subclass is a male person. Any property applicable to an object class is a valid property for all instances of this object class. Need to differentiate subclass from roles.
For any given object class and property pair, the value constraints (rules) for the property must be explicitly defined, when applicable. A few examples include minimum and maximum values, months in a year, country names, marital state, IP addresses, etc.
Any given object class and property pair may have read and/or write access restrictions. The restrictions must be explicitly defined and enforced.
Any given object class and property pair may have regional based classification differences with other regions. An example is the differences between vehicle license plate classifications between different European countries. Another example is the differences between minor and adult classifications of persons from different regions based on the person’s age.
Any given object class or object subclassmay have a relationship or role with another object class or object subclass within a specific domain. An example is a person object class performing the role of manager within the enterprise object class. Need another example. Look at current O-DEF and identify subclass that has a role that cannot be inherited from parent.
Any given object class and property pair shall have representation (format) requirements. These requirements must be explicitly defined. An example is an optional numerical format for date such as mm/dd/yyyy.
Procedural Interoperability is having the capability to achieve mutual benefit by using compatible business processes that originate the exchange of information. This includes, but is not limited to - deadlock prevention, resolving or avoiding resource conflicts, priority handling, time-out management, error handling, etc. Include discussion of O-MI and how the standard can be applied to procedural interoperability. Need input from Kary.
The procedural interoperability layer handles all process adaptations that are necessary to be able to process messages in a collaborative context. This ensures that all business state changes, necessary as a result of co-operation between systems in different enterprises are coordinated across systems of different enterprises. In order to be able to handle the collaboration process, specifications must be defined for:
The states of all systems involved with the achievement of compatible objectives across enterprises,
The information that must be available in each system and must be synchronized in order to achieve a compatible objective,
Required or expected quality of the information exchanged between the interoperating systems. For example, the required frequency of updating exchanged information.
The governance principles by which information relevant to collaboration is managed, in particular the Master / slave relation of each information element involved in collaboration. Many organizations implement a Master Data Management strategy as part of their overall information governance.
The interoperating systems must allocate enough (system) resources to enable interoperability with adequate performance. Performance is assumed to be adequate when interoperability rarely fails due to time-out processing.
Procedural Interoperability can be achieved either by creating compatible business processes, supplemented by business rules that resolve conflicting information or by use of a common procedural gateway. Successful Semantic Interoperability is a prerequisite for Procedural Interoperability.
Organizational Interoperability is a generic set of arrangements between organizations (private or public): businesses, institutions, or administrations, that need to interoperate in order to achieve a common or compatible objective. Each generic type of objective is represented as a column. Currently three generic types of objectives have been identified, but additional generic objectives could be added without compromising the Open Interoperability Framework.
Commerce interoperability is the collection of objectives where enterprises interoperate because one of them intends to provide a service or deliver a product that the other enterprise intends to consume or purchase. Both organizations may either be commercial organizations or public services. Commerce interoperability generally implies that the requirements include transaction integrity and non-repudiation across the interoperability boundary. This implies that the interoperability architecture needs to include security. Two Phase Commit is a frequently applied interaction protocol recommended for this type of interoperability. In the case of loosely coupled systems, a reversing transaction type frequently is recommended to support state integrity across governance domains.
Federated Service Interoperability, also referred to as (International) Public Service Interoperability, refers to the case that the delivery of a (public or commercial) service crosses borders of jurisdiction, language, governance, or technical domain. The organizations involved both are qualified and responsible to perform their part of the service, demanded by a third party, or on behalf of a third party and cannot or are not allowed to exercise any form of control or direction over or towards the other. The scenario may also be applicable to cross border or cross domain B2C interaction. For federated services interoperability the first requirement is to define a precise demarcation of responsibility. The objective is to make certain that no issues remain for which neither interoperating organization feels responsible, that where responsibilities overlap, agreement is obtained what functionality will be performed on either side of the demarcation line. In most cases confidentiality is required, either by applicable legislation or by objective of the service itself. The interoperability architecture therefore must address security and compliance.
Add paragraph that refers to the EIF.
Simulation interoperability refers to any cooperation between organizations that is intended to not leave any changes in the domain of interoperability. The nature of the objective implies that all state changes in the interoperating system must be reversible.
This context justifies special consideration, since in different governance domains, different policies and/or implementations may exist with respect to the life cycle of any information systems implementation. As a point of reference, the following system environments are considered:
Development system environment: this kind of system cannot originate any data that have binding consequences for users of another governance domain. Its flexibility and adaptability to specific interoperability requirements is usually greater than for any other type of environment. In most cases the reproducibility of any results obtained with this type of system cannot be guaranteed. Generally, development systems are not considered for training and simulation interoperability, except for the development of interoperability scenarios.
Test system environment: this kind of system cannot originate any data that have binding consequences for users of another governance domain but may supposed to be representative for a related production system. Results obtained with such a system are usually reproducible. Generally, test systems are not considered for training and simulation interoperability, except for the development of interoperability scenarios.
Shadow system environment: this kind of system is supposed to be an exact copy of the production environment, working with a copy of real data. As it is supposed to operate in the shadow of production systems, it must include full undo capabilities to avoid duplication of results of production systems. Shadow system environments are a candidate for training and simulation interoperability.
Production system environment: this kind of system is responsible for any operational task. It is working with real life data, and it is only supposed to use any undo capability if this reflects a real-life fact. Production systems are designed to have sufficient capacity to accommodate the scale of the business it is supposed to support. In some cases, production systems can be candidates for training and simulation interoperability.
Education system environment: this kind of system is only responsible for the training of end users in some relevant environment. Depending on the educational objectives it may or may not be representative of the production environment. Only in rare cases it may be a candidate for training and simulation interoperability. The choice of environment for a training and simulation interoperability case can be made independent of the choice of training, which is being made in another governance domain, or can be coordinated with that governance domain.
The Open Interoperability Framework currently defines three alternative modes of operation for organizational interoperability (see paragraphs above) but is not limited to these three. Tailoring the framework with additional organizational interoperability modes of operation is possible and allowed, without impacting the validity of the framework.
Legal interoperability collects and considers all concerns of legal nature to be considered when designing applicable architectural building blocks for interoperability. Three levels of legal requirements must be considered:
• Constitutional Interoperability defines generic principles that must be adhered to by any system and any business solution.
• Legislative Interoperability defines restrictions that prevent sometimes obvious solutions to be legal. To achieve interoperability legal circumventions or legal changes are required.
• Jurisdictional Interoperability defines specific issues to be considered because a court or management decision has mandated or forbidden an activity that could be required by an interoperability scenario. Jurisdiction also includes the imposition of security policies.
Legal interoperability requires full concern of the legal requirements and liabilities pertinent to the intended interoperability, and involves the adherence to regulations to all the following, whenever applicable:
• Data Protection laws that define or restrict the ability to use or exchange certain data for interoperability purposes
• Base registry legislation that prescribe the use of certain data for specific (classes of) purposes
• Privacy laws that generally defines or restricts the handling of data that can be related to a single living person)
• Contract legislation that enhances or restricts the meaning of data exchanged between organizations
• Digital Signature legislation, that defines, enhances, or restricts the validity and usability of digital signatures or digitally signed documents
• Digital Identity related legislation, that defines, enhances, or restricts the ability to use assets or persons identified by another organization in a business process
• Notary related legislation, that defines when deeds are needed to give a specific interoperability a legal basis
• Treaties, e.g., tax treaties, that define specific requirements for any collaboration between specific countries, in addition to, or in deviation of general international law.
• Legislation specific to the domain of interest. In many countries’ legislation and regulation, specific to the business domain of the enterprise exists, that provides contextual information for the architecture. Enterprises cannot be assumed to be aware of this contextual information when they operate in different business domains or in different countries. An example of this is the exchange of trip data of international transport between road traffic authorities.
Constitutional interoperability requires the comparison of the respective constitutions of interoperating domains A and B and categorizes all potential interoperability cases into four classes:
1. Permissible both under the constitution applicable in domains A and B. Legislative interoperability can be implemented, without restrictions applying to this interoperability objective.
2. Permissible under the constitution of Domain A, but not permissible under the constitution of Domain B. An alternative for domain B must be found in order to achieve the interoperability objective, or domain B should consider a revisit of its legislation, before legislative interoperability can be implemented.
3. Not permissible under the constitution of Domain A, but permissible under the constitution of Domain B. A (set of) business rule(s) must be defined to make the shared objective permissible in Domain A, before legislative interoperability can be implemented.
4. Not permissible under the constitutions of both domains A and B. Interoperability cannot and shall not be implemented in this case.
When interoperability between two domains is permissible, it does not automatically imply it is permitted. Legislative and Jurisdictional interoperability define and restrict when and on what conditions it is permitted.
Legislative interoperability requires defining a set of rules that will need to be executed each time a new objective for interoperability is transformed into a specific relation with another governance domain. It represents the constitutional requirements that must be enforced for each unique combination of an interoperability objective and a governance domain with which collaboration is considered. When a governance domain interoperates with multiple other governance domains, multiple sets of enforceable rules can be defined. When a governance domain pursues multiple objectives that require interoperability with another governance domain, a separate set of enforceable rules can be defined for each objective. Although multiple sets of rules can be created by objective and by governance domain, it is anticipated that several rules are common to all rule sets.
Jurisdictional interoperability requires executing the legislative rules by defining a set of rules that need to be executed for each collaborative activity that is executed in support of a compatible business goal. It represents the dynamic rules that will be implemented for each interaction of a system within the scope of the architecture with a system outside the architecture governance domain. The ruleset specifically involves all security controls that must be implemented at the external boundary of the governance domain and includes the mapping between business objectives, business rules and policies that are needed to make sure that illegal activities cannot cross the border between two collaborating governance domains.
< >