This chapter provides guidelines for defining and establishing interoperability requirements.

29.1 Overview

A definition of interoperability is "the ability to share information and services". Defining the degree to which the information and services are to be shared is a very useful architectural requirement, especially in a complex organization and/or extended enterprise.

The determination of interoperability is present throughout the Architecture Development Method (ADM) as follows:

• In the Architecture Vision (Phase A), the nature and security considerations of the information and service exchanges are first revealed within the business scenarios.
• In the Business Architecture (Phase B), the information and service exchanges are further defined in business terms.
• In the Data Architecture (Phase C), the content of the information exchanges are detailed using the corporate data and/or information exchange model.
• In the Application Architecture (Phase C), the way that the various applications are to share the information and services is specified.
• In the Technology Architecture (Phase D), the appropriate technical mechanisms to permit the information and service exchanges are specified.
• In Opportunities & Solutions (Phase E), the actual solutions (e.g., Commercial Off-The-Shelf (COTS) packages) are selected.
• In Migration Planning (Phase F), the interoperability is logically implemented.

29.2 Defining Interoperability

There are many ways to define interoperability and the aim is to define one that is consistently applied within the enterprise and extended enterprise. It is best that both the enterprise and the extended enterprise use the same definitions.

Many organizations find it useful to categorize interoperability as follows:

• Operational or Business Interoperability defines how business processes are to be shared.
• Information Interoperability defines how information is to be shared.
• Technical Interoperability defines how technical services are to be shared or at least connect to one another.

From an IT perspective, it is also useful to consider interoperability in a similar vein to Enterprise Application Integration (EAI); specifically:

• Presentation Integration/Interoperability is where a common look-and-feel approach through a common portal-like solution guides the user to the underlying functionality of the set of systems.
• Information Integration/Interoperability is where the corporate information is seamlessly shared between the various corporate applications to achieve, for example, a common set of client information. Normally this is based upon a commonly accepted corporate ontology and shared services for the structure, quality, access, and security/privacy for the information.
• Application Integration/Interoperability is where the corporate functionality is integrated and shareable so that the applications are not duplicated (e.g., one change of address service/component; not one for every application) and are seamlessly linked together through functionality such as workflow. This impacts the business and infrastructure applications and is very closely linked to corporate business process unification/interoperability.
• Technical Integration/Interoperability includes common methods and shared services for the communication, storage, processing, and access to data primarily in the application platform and communications infrastructure domains. This interoperability is premised upon the degree of rationalization of the corporate IT infrastructure, based upon standards and/or common IT platforms. For example, multiple applications sharing one infrastructure or 10,000 corporate web sites using one centralized content management/web server (rather than thousands of servers and webmasters spread throughout the country/globe).

Many organizations create their own interoperability models, such as illustrated in the example below from the Canadian Government. They have a high-level definition of the three classes of interoperability and identify the nature of the information and services that they wish to share. Interoperability is coined in terms of e-enablers for e-Government. Their interoperability breakdown is as follows:

• Information Interoperability:
  • Knowledge management
  • Business intelligence
  • Information management
  • Trusted identity
• Business Interoperability:
  • Delivery networks
  • e-Democracy
  • e-Business
  • Enterprise resource management
  • Relationship and case management
• Technical Interoperability:
  • IT infrastructure

In certain architectural approaches, such as system of systems or a federated model, interoperability is a strongly recommended best practice that will determine how the systems interact with each other. A key consideration will be the enterprise's business operating model.

29.3 Enterprise Operating Model

Key to establishing interoperability is the determination of the corporate operating model, where the operating model is "the necessary level of business process integration and standardization for delivering goods and services to customers. An operating model describes how a company wants to thrive and grow. By providing a more stable and actionable view of the company than strategy, the operating model drives the design of the foundation for execution."¹

For example, if lines of business or business units only need to share documents, then the Architecture and Solution Building Blocks (ABBs and SBBs) may be simpler than if there is a need to share structured transaction data. Similarly, if the Architecture Vision includes a shared services environment, then it is useful to define the level the services are to be shared.

The corporate operating model will normally indicate what type of interoperability approach will be appropriate. This model should be determined in Phase A (Architecture Vision) if not in Phase B (Business Architecture), and definitely by Phase E (Opportunities & Solutions).

Complex enterprises and/or extended enterprises (e.g., supply chain) may have more than one type of operating model. For example, it is common for the internal operating model (and supporting interoperability model) to differ from the one used for the extended enterprise.

29.4 Refining Interoperability

Implementing interoperability requires the creation, management, acceptance, and enforcement of realistic standards that are SMART (Specific, Measurable, Actionable, Realistic, and Time-bound). Clear measures of interoperability are key to success.

Architecture is the key for identifying standards and facilitated sessions (brainstorming) will examine potential pragmatic ways (that fit within the current or emerging business culture) to achieve the requisite degree of interoperability.

Interoperability should be refined so that it meets the needs of the enterprise and/or extended enterprise in an unambiguous way. The refined interoperability measures (degrees, types, and high-level targets) should be part of or referred to the enterprise architecture strategic direction.

These measures are instantiated within a transformation strategy that should be embedded within the Target Architecture definition and pragmatically implemented in the Transition Architectures. Upon completion, also update the consolidated gap analysis results and dependencies to ensure that all of the brainstorming nuggets are captured.

An example of specifying interoperability is the Degrees of Interoperability (used within the Canadian Department of National Defense and NATO). These organizations were focused on the sharing of information and came up with four degrees of interoperability as follows:

• Degree 1: Unstructured Data Exchange involves the exchange of human-interpretable unstructured data, such as the free text found in operational estimates, analysis, and papers.
• Degree 2: Structured Data Exchange involves the exchange of human-interpretable structured data intended for manual and/or automated handling, but requires manual compilation, receipt, and/or message dispatch.
• Degree 3: Seamless Sharing of Data involves the automated sharing of data amongst systems based on a common exchange model.
• Degree 4: Seamless Sharing of Information is an extension of Degree 3 to the universal interpretation of information through data processing based on co-operating applications.

These degrees should be further refined and made technically meaningful for each of the degrees. An example refinement of degree 3 with four subclassifications follows:

• 3A: Formal Message Exchange
• 3B: Common Data Exchange
• 3C: Complete Data Exchange
• 3D: Real-time Data Exchange

The intent is to specify the detailed degrees of interoperability to the requisite level of detail so that they are technically meaningful.

These degrees are very useful for specifying the way that information has to be exchanged between the various systems and provide critical direction to the projects implementing the systems.

Similar measures should be established to determine service/business and technical interoperability.

29.5 Determining Interoperability Requirements

Co-existence between emerging and existing systems, especially during transformation, will be a major challenge and brainstorming should attempt to figure out what has to be done to reduce the pain. It is imperative to involve the operations management staff and architects in this step as they will be responsible for operating the portfolio deliverables.

For example, there might be a need for a "wrapper" application (an application that acts as the interface [a.k.a. interpreter] between the legacy application and the emerging infrastructure). Indeed, pragmatically, in the "if it works do not fix it" world, the "wrapper" might become a permanent solution.

Regardless, using the gap analysis results and business scenarios as a foundation, brainstorm the IT issues and work them through to ensure that all of the gaps are clearly identified and addressed and verify that the organization-specific requirements will be met.

It is important to note that the ensuing development process must include recognition of dependencies and boundaries for functions and should take account of what products are available in the marketplace. An example of how this might be expressed can be seen in the building blocks example (see Part III, 37. Building Blocks).

If a mechanism such as the Degrees of Interoperability is used, then a matrix showing the interoperability requirements is a useful tool, as illustrated in Business Information Interoperability Matrix and Information Systems Interoperability Matrix , noting that the degree of information sharing is not necessarily symmetrical or bi-directional between systems and/or stakeholders.

The matrix below can be used within the enterprise and/or within the extended enterprise as a way of detailing that information and/or services can be shared. The matrix should start in the Business Architecture (Phase B) to capture the nature of the sharing of information between stakeholders, and evolve to determine the what systems share what information in Phase C.

Business Information Interoperability Matrix shows that Stakeholder A requires unstructured data exchange (degree 2) with Stakeholders/Systems B and D, and seamless sharing of data (degree 3) with Stakeholders/Systems C, E, F, and G.

The business information interoperability matrix should be refined within the Information Systems Architecture using refined measures and specifying the actual systems used by the stakeholders. A sample is shown in Information Systems Interoperability Matrix .

In Information Systems Interoperability Matrix , both the nature of the exchange is more detailed (e.g., Degree 3A versus only Degree 3) and the sharing is between specific systems rather than stakeholders. For example, System A shares information with the other systems in accordance with enterprise technical standards.

In many organizations the Business Architectures describe the nature of the information shared between stakeholders and/or organizations (e.g., in defense the term is "operational node"), and the Data Architecture specifies the information shared between systems.

Update the defined target data and Application Architecture (Version 1.0) with the interoperability issues that were raised.

29.6 Reconciling Interoperability Requirements with Potential Solutions

The enterprise architect will have to ensure that there are no interoperability conflicts, especially if there is an intention to re-use existing SBBs and/or COTS.

The most significant issue to be addressed is in fact business interoperability. Most SBBs or COTS will have their own business processes and most likely information architecture embedded. Changes to the information architecture will be technically challenging, but achievable; however, changing the embedded business processes will often require so much work, that the advantages of re-using solutions will be lost. There are numerous examples of this in the past.

Furthermore, there is the workflow aspect between the various systems that has to be taken into account. The enterprise architect will have to ensure that any change to the business interoperability requirements is signed off by the business architects and architecture sponsors in a revised Statement of Architecture Work.

Assess the Architecture Vision and Target Architectures as well as Implementation Factor Assessment and Deduction matrix and Consolidated Gaps, Solutions, and Dependencies matrix to look for any constraints on interoperability required by the potential set of solutions.

29.7 Summary

Defining interoperability in a clear unambiguous manner at several levels (business/service, information, and technical) is a useful architecture planning tool. The notions of interoperability will become ever more important in the Service Oriented Architecture (SOA) environment where services will be shared internally and externally in ever more inter-dependent extended enterprises.

Footnotes

1. Enterprise Architecture as Strategy provides potential models.

return to top of page