We hereby embark on a reverie that commenced before and continued during the writing of this article. And I’m not quite sure if it’s done yet. The evolution of thought practically happened in real time as I tried to explain… stuff. And to draw said stuff. In the end, perhaps this is an etude in defining the Internet of Things (IoT). As usual, it may raise more questions than it answers.

I can’t believe it’s been almost two years since I made a feeble attempt to put some structure behind this nebulous concept of the IoT. Much of my thinking (not to mention the industry) has progressed since then, but I had a discussion recently that forced me to go back to an image I had put together illustrating how I saw the various pieces of the IoT coming together. To a first order, it still feels more or less relevant (although clearer than ever that it wasn’t put together by a true graphic artist).

I reprise the figure below as a starting point, but I’ve de-highlighted the bits I don’t really want to pay attention to in this discussion. I’ve even removed the “hub” (or “gateway”) – not because it’s not relevant, but because it’s a complicating factor that doesn’t really matter. Let’s pretend we don’t need it, shall we?

What we’re left with is a configuration consisting of Things talking to the Cloud. And, critically, Phones that also talk to the Cloud. So data can travel from the Thing to the Cloud; the Cloud can work its deep learning and analytical magic and then present the results to the Phone for us to gaze at admiringly. (Assuming we’re under 40 years old and can read the text.)

But, after talking to Golgi,* I was left with the feeling that maybe it’s not quite so simple. Although, as I write, I must admit I’m still wrapping my head around what follows. Because, in my original thinking, the Cloud-to-Phone communication is bidirectional. Yes, data goes from the Cloud to the Phone, but then, presumably, instructions will go from the Phone back to the Cloud and thence back to the Thing. It’s all one big integrated-but-distributed beast.

Where does Golgi fit then? Golgi enables Phones to talk to Things. They do that by having the Thing talk to Golgi’s Cloud infrastructure, which then talks to the Phone. And vice versa. But they go to pains to clarify that they’re not a Cloud platform.

What that means is that Golgi isn’t implementing the Cloud portion of this figure. Because the goings-on in my conception of the Cloud are defined by the system developer. All of the analytics and algorithms are application-specific. With a convenient platform, it’s easy to configure and build all of this custom functionality, but, regardless of how much work was required, it’s still custom.

How does this compare to Golgi’s Cloud component? The difference is that you can’t control any of what goes on in the Golgi Cloud bits – they’re fixed, and they implement only what’s required to ensure that blobs of data travel reliably back and forth between the Thing and the Phone.

I got to see a demo of Golgi technology in action at the IoT DevCon recently; sure enough, given a collection of Things using a variety of communication modes – even texting (under the hood, using SMS as a channel) – they were able to control the Things from the Phone. In that case, it might seem odd to send the messages way off to the Cloud somewhere, only to have them come back two feet away, but it makes much more sense when the Things are at home and you’re on the train.

Still and all, having seen that, I was scratching my head (while nodding sagely so that no one could see that I was perhaps a step behind). If IoT apps talked to Phones from Cloud platforms (and Golgi wasn’t a Cloud platform), then why was a separate Golgi pathway needed?

Listening to the discussion, my initial takeaway was that this phone communication stuff is actually difficult, and that most of the other systems couldn’t make it work. So Golgi would let you establish a Phone connection alongside your other Cloud implementation. This would look something like the next figure.

This still isn’t particularly satisfying. Even with this parallel path, you still need to be able to view Cloud data on the Phone. So it feels like this parallel path is only for controlling the Thing. Which is consistent with the fact that the communication model with Golgi is remote procedure call (RPC), not publish/subscribe. In other words, it’s command-centric, not message- or data-centric.

Still, communication really happens both ways with Golgi, so this just seems a bit clumsy.

It then occurred to me – literally while writing – that my confusion may all come down to how one defines the IoT. The original figure comes from my conceptualization of the different components of the IoT, and the presence of the Cloud with application-dependent functionality is, to me, a critical element in that definition. Otherwise you’ve simply got a collection of networked equipment.

But what if I backed off on that? What if some guy is making equipment and wants only to be able to control it from a phone from anywhere? No fancy-schmancy algorithms, no wading up to your armpits in pools of big data; just make the dang Phone talk to the dang Thing. Is that too much to ask?

Well, in that case, the whole Cloud platform part of the picture disappears, and you’re left with Golgi as a communication channel. And there’s no ambiguity. The two Cloud entities (custom and Golgi) don’t coexist; they’re alternatives. The following image, to me, makes far more sense.

The question that then comes to mind is, does such a Golgi implementation really represent an IoT instance? I think that this is what’s gotten me swimming a bit – the fact that this is supposed to be an IoT Thing without a real Cloud intelligence component. If my conclusion is correct (and a quick check-in with Golgi seemed to confirm it), then it feels to me like this is simply implementing a Phone as a (very) remote control for a Thing.

That’s not meant as a put-down; I’m sure there’s a ton of hard work that has gone not only into making the communication work via the many ways devices can talk, but also into defining the mechanism that lets developers build the apps that implement that communication. Using dev kits for the selected platforms, developers write programs using Golgi’s APIs and four basic data types, and then Golgi creates the drivers and files required to make this work on the targeted systems. Pretty slick.

But I just can’t visualize the IoT without the Cloud. Why? Because the Cloud is where all this abundance of data is supposed to be transformed into wisdom and peace and love and rock and roll. (Sex and drugs optional.) All that data fusion is what makes the IoT more than the sum of all the Things.

But I could be wrong. If you define the IoT as any distributed system with an internet component – which a Golgi-powered system would definitely be – then you don’t need a “smart” Cloud function. Feel free to opine in the comments below.

AFTERWORD: Between writing and submitting this piece, I happened to attend the Sensors Expo conference. One conversation with Anaren had a similar flavor: accelerating the ability to connect a phone to a device. Again, like a remote control. This reinforces a view of the IoT as being “connected devices” that may or may not have intelligent Cloud capabilities. I got the sense from some of the people that I talked to both at Sensors Expo and at DAC that the whole Cloud intelligence thing is still more concept than reality. (I’m sure some Cloud companies would disagree.)

*For those of you with medical skills, this will be obvious. For the rest of us, well, it’s not clear if this word has Greek, Latin, Germanic, or other roots. My pronunciation guess was a Hellenic “goal-ghee.” That’s not correct: it’s “Gaul-jee.”

More info:

Golgi