“Smart Connected Systems” really means the future of information, and thus, the future of civilization. It will require a remarkably agile global network that could comfortably scale to trillions of nodes—some of them hardware, some software, some purely data, many of them coming into and out of existence or changing location constantly. Obviously, such a network system cannot be “designed” in any ordinary sense, and it certainly cannot be designed “top-down”. However, despite this inherent issue, the Internet of Things must be designed in some sense.
Today the relationship between the evolving technologies driving the Internet of Things and the business models that these systems could inform is “disconnected” and problematic at best. The Internet of Interactions — between and among “Things” and “People” — requires much more than simple incremental improvements in today’s technologies to be fully realized. The challenge is much more than a simple patch, Band-Aid, or new flavor of what we already do.
Such a network will easily be the biggest technical achievement in the history of humanity. Its closest predecessor is probably the global financial economy—with which, in fact, it will share vital characteristics. Some basic principles must be put in place to guide the growth of a vast, distributed technological organism that must remain organized as it evolves according to a logic all its own. It demands that we design not only devices and networks but also information and the underlying tools in new ways not currently addressed.
What’s required is a true shift in thinking about how devices, people and physical systems will be integrated and how they will interact. We need an approach that is about looking forward to a single, unified architecture for the nearly infinite, and unforeseen, interactions to which any PERSON or any THING can contribute.
Designing For The Internet Of Things
1) Communications protocol
For the IoT to reach its potential, it needs to be founded on a set of complimentary communications protocols that do not restrict or place structural limitations on the design of the IoT. It may seem self-evident that the IoT must use Internet Protocol but at this point, this is far from certain. Many parochial, self-interested groups and standards bodies are lobbying for alternative protocols, despite that none have ever been tested at scale and all are incompatible with the current Internet.
All the issues surrounding “bridging” or “gatewaying” other protocols to IP create island structures and block the cross-device systems intelligence we all seek. These gateways are also burdensome and costly. These additional protocols only serve to slow the IoTs development as it confuses and distracts end-users and OEMs alike.
As it currently stands, IP is the only protocol that has been used at scale, battle-tested and debugged over years of real use. It’s not perfect but so far we have seen no alternative that addresses the fundamental control, file transfer and streaming needs of IoT devices.
2) IoT Language
You may ask, “If we have a protocol, why do we need a language?”. If so, it’s helpful to use a metaphor: Think about the protocol as like deciding on the medium of transmittal (e.g. books). It only describes how to get the information from one place to another it doesn’t ensure that the receiver can understand the message. A protocol without a common language is like sending a French novella to a German without a dictionary. When we think about it this way and consider how IoT devices handle units of measurement (e.g. time, distance), often without human interaction, language becomes even more critical. In fact, it’s similar to inventing a whole new human language and getting everyone to agree to it.
For the web, Sir Tim Bearners-Lee created a new markup language for displaying web pages and other information that can be displayed on web browsers – Hyper Text Markup Language (HTML). Before this common language was introduced, the Internet was largely just an academic network where private arrangements of language could be agreed between parties. The introduction and proliferation of HTML helped “automate” these arrangements and helped to fuel the explosive growth of the Internet and the Web in the 90′s.
Despite its pivotal role in personal computing era, HTML is not the long-term solution for the Internet of Things as it was designed for pages of text. Another web language – Extensible Markup Language (XML) – has been successfully applied within the IoT however, it still doesn’t deal with the language of the variables and content it may contain. What’s needed is a new IoT language akin to HTML. The stark reality is that this new language will most likely need to be given away license free, or a very long and costly “war” will be waged between software companies vying to control the vast revenues that will flow from the IoT.
3) Information Architecture
Information architecture is arguably one of the least understood but pivotally important things yet to be determined for the IoT. Current information structures are built on the very old 1970′s ideas about structuring and indexing data into rigid tables – the relational database. These require pre-emptive design of the information and data structures. So for a relational database to be a viable option, you will have to pre-design the future of all human knowledge, everywhere. It’s simply impossible because we simply cannot comprehend the extent of all knowledge and data. Even defining simple IoT devices or objects and their data structures or language is fraught with problems as the things we all know and love today will surely be different tomorrow and we have no idea what those differences will be so how can we design a rigid structure to contain what we don’t know.
We need a fully flexible and extensible structure that can build indexes and relations naturally, not unlike nature does with DNA. The design firm, MAYA Design Inc, has developed an interesting approach to this problem. By “containerizing” the information in a universal file, which has a unique identity, the information is divorced from the system that may contain it (i.e. it has no address or location but does have unique ID). The uForms, as MAYA Design has called them, can be simple XML files that contain Value / Attribute pairs called duples which can refer to other uForms by using their unique ID in the Value field of an Attribute. This very simple extensible design allows relations to be built at a very fundamental level without predesigning the structure of data. Not only can new duples be added as new capabilities are created but they can refer to whole chains of other uForms to deal with references to common definitions for units of measure, color or just to create an efficiency in file transport not unlike that achieved in HTML when it refers to a font or a color.
MAYA’s uForm methodology and their uForm browser technology may not be the only method but it’s one of only a few that we’ve seen that allows for highly distributed databases that are “browsable” at the “edge” in their native location without having to move all the data to centralized server repositories or cloud storage facilities.
4) Network Architecture
Current network architectures are built on hierarchical concepts that sprung from the mainframe era of the 60′s an 70′s. Commonly called client-server architectures, these networks have been recently reinvented and are now called “Cloud Computing”. Regardless of the terminology, these architectures are fundamentally similar in that they both require large movements of data or traffic on the network as nodes must store their data on large, centralized servers. For obvious reasons (data center size and network bandwidth), any centralized solution is unlikely to scale to trillions of devices – consider how large a Google data center is today and that only deals with the data stored on a few billion devices never mind several trillion.
Computer scientists believe that only peer-to-peer architectures are capable of such scale, ironically the Internet’s early architects even predicted this and built this capability in from the beginning. This architecture fundamentally “flattens” the network and takes out hierarchy. In fact, Skype and some music sharing sites have already brought peer-to-peer architectures to the mainstream although most of us are unaware of its invisible benefits. This architecture provides a ripe opportunity for new types of devices and the next generation application platform that will manage device nodes, regardless of their location. It’s possible that one node could provide services to many information aggregators and their attendant applications, which would create a network architecture that is fundamentally much more complex than current client-server thinking would allow for.
How Do We Get There
It’s important to note that, taking these initiatives seriously and integrating them into our design principles does not mean junking all current IT practice in one fell swoop. The pillars of present-day information technology will not crumble overnight, nor has the great existing investment in them suddenly lost all value. There are reasonable, fiscally sane paths for migrating to the future. But migrate we must. The assumptions and practices of the mainframe and PC eras are now decades old and not suitable for the pervasive computing era that informs the Internet of Things and people. The nature and behavior of a truly distributed global information system are concerns that have yet to really take center stage—not only in business communities, but in most technology communities, too.
A New Manifesto
In our years of work on the Internet of Things phenomenon and its real-world effects on business, we have not encountered very many compelling visions about the complete integration of things, people, systems and real-time real-world inputs. The world today, for the most part, lacks a group of coordinated innovators that understand that the tools we are working with to make products “smart” on networks were not designed to handle the scope and diversity of interactions they are being enabled to accomplish.
This perspective does not just come from our own thinking. It is from the diverse group of people who are thinking about the scope and on the scale that Smart Systems deserves. It is because this community of technologists and business developers is so diffuse that we believe a new approach is required. This is why we believe a new “manifesto” is required.
A new manifesto is required that addresses both the required technology architecture and the corresponding and radically new business models these technologies will inform.
Most importantly, we plan to demonstrate that for the first time in the evolution of networked businesses, these two “architectures” must be viewed in close proximity. The two thrusts need to be mutually supportive without inhibiting one or the other. However, trying to coordinate and leverage the respective roles of technology architecture and business architecture often creates contention. Many of the participants in this emerging arena we speak with are coming to see the continuously evolving relationship between these two dimensions as fertile ground for innovation. They need to be interwoven and mutually supportive. In fact, from our own direct consulting experiences, we believe success in either goes to the company that effectively utilizes the combined potential of both.