Smart Cities, IoT and Interoperability

In search of smart interoperability…cities, sensors, traffic, people.

When asked how interoperable IoT systems should be, analysts and planners—especially of the technical kind—answer as interoperable as possible.  That said, not all define interoperability the same way—is it user interop (making all the data available via smartphone apps, for example), vendor interop (allowing substitutions of multi-sourced equipment or software) or system interop (allowing common controls or communications)?

Reality, meanwhile, rarely mirrors any form of interoperability.  The process by which smart cities are rolling out IoT apps is often hodgepodge.  For example, a medium-sized city we know has more than 30 IoT projects in various stages of deployment, mostly in the pilot stage.  These projects fall within the functional jurisdictions of six or seven city departments.  Yet little coordination exists even among the projects that fall within a single department.  

Other “smart cities” are highly planned or espouse comprehensive visions combining technical, environmental and community involvement layers.  In some cases they are outsourced to an outside developer, such as Alphabet (Google’s parent) in the case of Toronto’s Sidewalk Labs.  What Apple is to the smartphone, Alphabet wants to be to the smart city, claiming it will provide Toronto with “the most innovative district in the entire world.”  Yet some community voices are resisting the offer.  Are there in fact different kinds of innovative cities and possibly different kinds of interoperability, some that come from above or the sidelines and others that bubble up from below?

Jane Jacobs described something closer to hodgepodge as the source of innovation in her classic The Death and Life of Great American Cities.  Vibrancy and reflection of a community’s diverse preferences may foster “greatness” more than technical interoperability does.  On the other hand Hausmann’s highly-coordinated 19^th century design for Paris or Buckminster Fuller’s plan for Minnesota Experimental City offered efficiencies that Jacobs’ vision may not.  Are these two forms of smart cities incompatible?  (MXC, as Fuller’s plan was called, was never built due to the protests of about 70 rural residents who lived where MXC’s geodesic dome and 250,000 population were to be placed.)

Of course the smart cities being developed today can count on a level of technical control and pizzazz unimaginable even by Fuller…IoT for sensing how much energy is being used in buildings, IoT for calibrating traffic signals and bus routes, IoT for alerting us of a drop in the town’s drinking water or of an imminent crime.  IoT is becoming the traffic or nervous system of the smart city.  So how interoperable should this traffic be?  Should Amsterdam's mix of streets and canals be the model perhaps?

In the end a city's use of IoT may call for its own grid—an interoperable one.  Yet how to achieve the interoperability is an open question—with a common monitoring, data analytics and control platform, a common sensing and communications network, or common access procedures at the user end?  And which users should be the focus of all the new IoT-based apps—city managers, the private sector, or the city’s residents?  Finally, there is the timing issue.  Too much interoperability too soon and the trial and error spirit underlying smart cities could be jeopardized; too late and the integration process becomes very costly and take years to implement.

Interoperability is a good idea.  So is instilling an entrepreneurial spirit into the city politic to offset its tendency towards bureaucratic resistance.  Over-integrate and creative innovation may be lost.  Under-integrate and duplication results.  In short, a healthy balance is called for.  The resulting interoperability should blend user and community inputs along with technical and legal ones (on security and privacy, for example) while not stifling new processes or ideas.

The result may even be…smart interoperability.