COLUMN – “Open Cloud” allows us to mix and match web services
April 3, 2014 - Keep the Cloud Open is a first attempt at describing what redefining “Open” in the Cloud might mean.
April 3, 2014 By Ken Sinclair
If we are not clear on Keeping the Cloud Open there is a dark side, a concern of an evolving trend towards Proprietary Cloud. I grew up in the industry during the DDC revolution and saw the floundering of the early proprietary DDC systems that evolved quickly with amazing capabilities, but rapidly became obsolete and impossible to maintain. Several early DDC system companies failed and those that succeeded were liberated with the development of open protocols with total project integration and interaction with several vendors.
Large automation companies resisted “Open” until forced to open their proprietary ways by their clients. Open meant losing control for these companies which is of course what the client needed and wanted. A new paradigm is in the definition of large companies, in the past large companies were limited to large building automation but in the cloud the likes of Amazon, Google, plus several others dwarf these companies and raise new questions as to data ownership and interaction.
I fear a repeat of history for some upstarts that are ignoring known open standards and protocols while attempting to claim ownership of your data. Their fate is known but it may be painful to you if they are your present cloud service provider.
I am concerned about companies providing Proprietary Cloud to gain control. The term “Proprietary Cloud” is not normally used because of the negative connotation but words like ‘closed vendor’ cloud or ‘managed cloud’ are used to politely describe my concern.
Cloud Standards or flavours are not well understood, or specified or requested, and this allows large companies to build fences around your data and who can control your web services. The very thing pitched to set you free may trap you. Understand and take ownership of your data and insure “cloud openness” which is yet to be clearly defined. We have provided an review of Open Cloud Definitions as a first step to start our journey to understanding the true implications of keeping our cloud open.
From my Classification or what ‘things’ are called, I write:
Conclusion: If we are to keep the cloud open and as useful as possible you cannot allow unstructured naming of anything, you must take ownership of your classification or what ‘things’ are called.
The dangerous potential trend to a proprietary cloud is fuelled by overall security concerns and the instant value of included web services in the proposed Proprietary Cloud.
How do we avoid Proprietary Cloud while still involving our clients and the many vendors and our new and existing web services?
How do we build “Open Cloud” that allows us to mix and match web services to our Corporate enterprise goals?
Our past open progress could be lost in a cloud, if we do not heed our past experience of 30 years we may be giving up control rather than gaining it while we move past the IOT to the WOT.
In this column, Getting Over the Internet of Things – Toby Considine of TC9, writes:
Ken Sinclair has been doing a great job stirring the pot on open systems and open standards, and open interfaces revolution in buildings and “things”. It is only as the buildings industry matures in how it uses these specifications that it will move past the unproductive arguments over the best protocol to something more useful. While we argue about the Iot, the WoT is coming.
The IoT is nearly 40 years old, now. I am arbitrarily taking the development of X10 in 1975 as its beginning. The IoT is a nest or proprietary things serving single applications or single vendors. The IoT is the family of single-scope products that the cable company and the home security company is using to expand their offerings. It is a dead end.
Throughout this year, I have been writing about some of the ways to get past the IoT. OBIX has always been about reaching to people and the enterprise. Therese Sullivan has introduced a new acronym (MQTT) to AutomatedBuildings this month that speaks of another route in her article IoT Opens to Mobile Messaging Standards. Enterprise computing, and personal computing, is all about combining protocols, using what William Cox calls the Architects Palette. The enterprise architect selects standards and blends them. This blending is a critical step on the road to the Web of Things.
Some writers and researchers are using the Web of Things (WoT) to name a semantically aligned IoT. The Web of Things moves beyond the parochial standards that we keep inventing in buildings (and elsewhere) and moves to higher level i.e., more abstract semantics. Like the Internet of Things, everything in the WoT has an URI (which is different than everything has an IP address…). In simplest illustration, in the Web of Things, there is no BACnet Light, no ZigBee IP Light, and no KNX light, not even an X10 light, there is only a light. That light is slowly being placed into a context using standard ontological methods, but that is taking two steps ahead.
This does not mean the end of the domain protocols. Far from it. Building protocols are the best for using internally to building applications. Buildings have seen over-extensions of domain protocols from the other side in recent years, as the smart grid folks tried to get buildings to abandon their domain specific languages to use those of the utilities. If you are inside a BACnet (for example) application, of course you should use the BACnet light. Just don’t expect anyone from outside your niche to adapt their language to yours.
OBIX has always been first and last about common low-level semantics. In the current drafts, wherein we broke out encodings and bindings, we were reaching to enterprise-style composition, to expanding the palette. MQTT is another expansion of the palette.
Understand and take ownership of your data and insure “cloud openness” which is yet to be clearly defined.
Ken Sinclair is the publisher of AutomatedBuildings.com and can be reached at firstname.lastname@example.org.
Print this page