Intel and Samsung recently unveiled the Open Interconnect Consortium, and the AllSeen Alliance was established in December with Qualcomm’s backing. The companies behind these groups have clearly noticed that there are barriers between where we are and where we need to be for true connectivity.

In order to enable the IoT, businesses have to address issues that span not just the technical interconnectivity landscape, but business common sense, as well.

It is very hard to make a true internet of things. The IoT term bandied about with aspirational abandon implies a lot without going into too much detail: connected devices talking to each other, devices communicating with humans in a range of ways and all with predictive outcomes resulting from this interconnection.

Pulling all of that off in a relevant manner that satisfies the requirements of security, reliability and relevance is no small task. We have just started down this road, and with the current state of affairs, we have no Internet of Things, we have Just a Bunch of Things (JBOT).

>See also: Next big thing: Preparing for the Internet of Things in the enterprise

JBOT is the rudimentary “simple” connectivity that we currently see in most types of device connectivity today. Whether talking about fitness wearables, smart thermostats or connected cars, there isn’t yet a lot of intelligence happening in how the devices communicate with people, with each other or with third parties.

Nest is a wonderful first step, and a great product, but it and its brethren across the smart device landscape are not yet capable of delivering a 10x disruptive wallop to an existing paradigm because the JBOT world lacks both the infrastructure and the readiness to support such a transformation.

The key to evolving from JBOT to IoT requires not just developing technical standards that entrepreneurial teams can work with, it also means starting from use cases where the problem can be solved with an intelligent network of devices.

To see an example where existing technology met a powerful use case and led to a purpose-built “internet of things”, look no further than Uber.

Uber is a wonderful proto-vision of where the world will be heading. It is a global network of thousands of real-time monitored nodes (cars) deployed in both public and private networks for the sole reason of solving a specific transportation problem. Uber does not leverage any truly breakthrough technologies, but they did assemble available mobile technologies, machine learning and logistics managed in a remarkable way to transform an industry (land travel) through a kind of miniature IoT.

It does not take much imagination to see how a larger IoT can get mind bogglingly complex, very quickly. Sticking with automobiles, imagine a near future scenario where you are driving your car in an urban area and the car monitor knows that you are getting to the fuel level where you typically want to stop and fill up.

Those car sensors could communicate with nearby gas stations and attempt to secure for you the best possible price per gallon, based on a wide range of aggregated variables.

Those variables may include your make and model of car, type of gas you purchase,, known corporate loyalties, average time at pump, average fuel consumption per week, how busy the gas stations are at the moment, or how many gas stations are reachable on the fuel you have left in the tank.

Your car would then come back to you with a dynamically derived price per gallon, and make the recommendation to you on which gas station to pull into just up the road. All of this is incredibly complex. It’s many years away. To be sure, it will happen, but the road from here to there is hard work.

 So, what kind of work are we talking about? How do we get to that wider, open world where myriad of devices are able to make predictive outcomes for us? Aside from great hardware and software engineering, there must be an increasingly standardised awareness of how an ideal IoT is to be architected.

What is the grammar of this architecture? We don’t have it yet, but folks like Linux Foundation’s AllSeen Alliance are taking a step in the right direction. We need to have the discussions to resolve technical taxonomy issues before it can happen.

I would argue that even more important than technical taxonomies and standards is having good reasons to go build out these IoTs. What are the problems to be solved that require truly intelligent connectivity?

Clear, industry-specific thinking will be required. For example, a construction maintenance company that wants to monitor structural integrity through an array of deployed sensors will have a totally different set of deployment and operational criteria versus a smart network of lawn sprinklers in your neighbourhood that learn to how to collaborate to optimise water supplies from your municipality.

We cannot begin to know those specific requirements for all of these networks, but we do know they will have to be both tailored and adhere to a common set of standards, for they, like the original internet from which they spawn, are open-ended.

This is all about collecting data that can be used to create new services and offerings to improve every aspect of our lives. The currency for IoT is the data collected by the things.

>See also: 4 things that will happen in the Internet of Things space in 2014

This creates friction to realizing the wider dream of IoT where devices communicate with each other to make informed decisions because the companies that create these devices also want to own the data.

The real IoT is not possible until we have some open standards (with adoption) around how things will communicate data between different “mini-IoTs” so that my car can talk to different gas stations to find me the best gas price.

We need to begin having a deeper conversation about these grammars, and whether Google and Samsung’s efforts to create a forum for these discussions pay off remains to be seen.

We need to celebrate fantastic entrepreneurial achievement in this first generation of connected devices, hopefully now we’ll be able to start discussing their shortcomings, those that keep us anchored in a JBOT world.

Sourced from Ross Mason, founder and VP of product strategy, MuleSoft