Openness in technology is an element of interactions. It’s about allowing access to whatever information is needed to take appropriate action, without tying that access to a single technology or vendor so you can always pick the right solution for each problem.
Of course, open has become a heavily loaded term. A few years ago I did a talk on the overloaded nature of the word open, and I suspect you could add additional examples to the list therein. But in nearly every case, openness in communications benefits everyone.
The ability to move and share information is the lifeblood of many corporations – and some would say all of them these days thanks to the advent of analytics, IoT and the cloud. As technology evolves, that movement of information will increase in both ubiquity and value.
And that is why open data movement is important. Open data movement is designed to get data moving on your terms. In particular, it is focused on using open standard protocols together with open source APIs.
So let’s look into these.
Standards and Specifications
A standard is traditionally a consensus driven specification that defines the way folks want things to work, and are willing to enforce. This enforcement can take several forms, but for simplicity let’s call them “legal enforcement” and “will of the community”.
With a few exceptions, standards development is a long, evolved process. They need to be driven to the minimum set to derive goodness and not lock out anyone. That’s why anything submitted as an industry specification should be able to point to independent implementations outside of the control of whatever company or entity is driving the development of the standard.
With the use of standard protocols (like MQTT or AMQP), data can flow between endpoints that use those standards. Don’t like your current message broker implementation? Plug in another one. Need a different capability to solve your problem? There’s a standard that does that. And that’s why open data movement isn’t about a single standard, but many. In a world where your data environments can run from access layer (as in IoT) to edge layer to core enterprise, you’ll frequently find multiple protocols in use even within a single use case.
Application Programming Interfaces
You can think of APIs as the user interface for programs. They allow programs to easily pass information needed to achieve a result. And like standards, API’s come in proprietary and open forms.
Working with open source APIs provides a level of protection from vendor lock-in, and from the downside of vendor-induced mismatches. In the image, you can see that standard protocols (MQTT and AMQP) are paired to popular and active open source APIs (Paho and Qpid, respectivel).
What About Open Source Code?
Obviously the most open way of communicating is to determine both the content and the intent of any message. By allowing view (and modification) of source, open source delivers a level of openness found in no other layer.
However, standardization in open source is only driven by the will of the community, which can be a risky element. What happens if the will of the community decides to change the underlying protocol? Will that jeopardize working solutions? What if the the protocol fails to adapt to emerging needs and the implementation becomes increasingly complex and fragile?
In technology, openness helps delineate how things connect. While it may extend into visibility into the implementation, the ability to view and modify source does not inherently add value or openness to communications. With exceptions, most of us don’t know or care how electricity is generated or transmitted – we’re just glad we can turn the lights on and charge our phones. Neither do most of us care about the choice of programming language, programming style, or reuse of code.
The choice of standards and open APIs helps protect you from lock in, making it easier to migrate applications, microservices and workloads from datacenter to clouds or vice versa at will. And open data movement, by supporting multiple protocols, allows systems to seamlessly share information across and between those environments, creating a true hybrid cloud environment that’s “open for business.”