Real-World Open Networking. Part 2 - Interoperability: The Holy Grail

In our last post we described the attributes of an Open Network Solution. In this post we unpack what surely is the “Holy Grail” of Open Networks: Interoperability. Interoperability is defined as:

Interoperability is a characteristic of a product or system, whose interfaces are completely understood, to work with other products or systems, at present or in the future, in either implementation or access, without any restrictions

-- Wikipedia
https://en.wikipedia.org/wiki/Interoperability

Bottom line, interoperability means that I can freely substitute components, i.e. If I have Component X in my Open Networking solution, then in the future I can freely replace it with Component Y.

Today, components vary widely in that ability, across any of the component “form factors” we described in this post. But it’s not just technology components that play into our concept of interoperability.

INTEROPERABILITY ASPECTS OF OPEN SYSTEMS

By definition, to be highly-interoperable, we need to be able to freely substitute the components along each of the dimensions of openness that we described in the here.

• Open Standards
• Open API’s
• Open Partners
• Open Source
• Open Operations

Let’s look briefly at each of these in turn.

OPEN STANDARDS

Probably the most obvious and most-used strategy for driving interoperability has been the definition and/or adoption of standards. This covers both those standards formally established by standards bodies (“de jure” standards) and those established informally by market dominance or pervasive use (“de facto” standards).

The idea of Open Standards does not really mean substituting different Standards for each other (although solution designers should probably consider Standard-switching costs in their design phase). Using Open Standards means selecting one standard for a particular functional area of the solution and driving the level of compliance to a this standard to allow the free switching of components within that functional area of the solution.

This is a complex subject which we are going to review in the next post.

OPEN API’S

From a software integration perspective, Application Programming Interfaces (API’s) are a fundamental way in which interoperability can be achieved. There are a number of perspectives to the “Openness” of an API:

• Ease of accessibility to the specification
• Access to a test environment or reference implementation
• Use of common and open interface protocols e.g. REST

API’s and the issues of interoperability is also quite a complex topic, and we’ll explore this in more detail in the next post plus one.

OPEN PARTNERS

Being able to switch partners freely is key to open systems, but there are several factors to consider:

• Contractual relationships: It makes sense to set up a firm relationship as a baseline but also to be able to modify or terminate the contract if circumstances require. Also relevant is the ability to partner in novel and creative ways, for example joint ventures and reseller arrangements.
• Technology transparency: A vendor does not use or rely on proprietary components that cannot be transferred to other partners or used in-house by the solution owner.
• Win-Win relationships: Open Partners depends on establishing and promoting a win-win relationship between suppler and customer, rather than one benefiting at the expense of the other.

Unfortunately, there have been many instances of vendors attempting (and succeeding) in locking themselves into customers long-term. This form of “rent seeking” generates ill-will and gives rise to many protective measures, some of them extreme and working against the idea of “Win-Win”.

OPEN SOURCE

We discussed Open Source in previously, but we didn’t examine this from an interoperability perspective. Open source addresses the technology transparency requirement of Open Partners- it is accessible to all and is therefore transparent. Although effort may be required to ramp up knowledge of a new vendor, Open Source components often have multiple sources of support, knowledge and resources that can assist in this process.

OPEN OPERATIONS

As mentioned in the last post, Open Operations means that operational processes are flexible and open to change, open to engagement, and transparent. In short, this summarises DevOps.

We reviewed the DevOps paradigm in an earlier article. Practices are open when new vendors can slot in without friction or significant overhead. There is a clean flow-through from business to development to operations that enables new vendors to rapidly pick up the pace of value-add. The use of common concepts, tools, and practice enables new vendors to understand where they fit in very quickly.

CONCLUSION

We can see from the above that all the attributes of Open solutions drive Interoperability. Most business cases and project plans contain risk assessments and sometimes financial provisions for dealing with the costs of change that may occur during a project: a failure of a partner, or a piece of technology or some other aspect of the solution will incur costs and delays as the new components are selected, validated and integrated into the solution.

The only real test of interoperability is that these risk events, if they occur, are orders of magnitude less difficult and costly, such that the risk provisions can be reduced or eliminated. We know what to aim for, but alas we are far from that stage. In this post we have covered some of the issues that cause this failed assumption. We’ll cover more in our next post.

Stay tuned.