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:
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.
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.
Let’s look briefly at each of these in turn.
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.
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:
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.
Being able to switch partners freely is key to open systems, but there are several factors to consider:
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”.
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.
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.
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.