Challenges of the Centralized Smart Cities Approach

Architects planners, regulators, politicians, and technologists alike are diving into “smart cities” at an unparalleled pace. These developments are following the pervasive developments in connectivity, from broadband internet to the wide range of sensors that firms like Intel and Cisco are pushing onto the market and into the streets. This approach is largely the natural next step for existing cities and isn’t that different when brought into the mix for brand new masterplanned developments such and Songdo in South Korea.

What is this approach? Start with the concept of the connected or sensor networks that essentially overlay a digital infrastructure on top of the built landscape. The first step is to gather data. From traffic counts to energy usage, the data points are as varied as your imagination allows when looking at solutions to common problems that plague the city. This is the start of where the issues lie.

Smart cities discourse often includes elements of infrastructure that is connected to these data points. Start with the infrastructure itself as resource distribution grids for water, electricity, and data to grids, on which resources are distributed as optimized commodities to a ubiquitous network of “things” or devices such as resource collectors (solar panels, street lights, and future pavers), city interface points (street lights, autonomous vehicles, and phones), and passive/autonomous systems (delivery, maintenance, and civic services). This all comes from a long series of playbooks based on solving city issues. The approach to solving these issues, especially at the city level, are most easily understood from a masterplanned approach. The idea that a single entity or team being charged with solving the issues of the city or optimizing the services it provides makes for a traditional step forward. This is where we get things wrong. The city itself and those who occupy and live in it are very much a complex and adaptive entity as opposed to a linear system we wish to be easily understood.

The most successful attempts at building smart cities rely on the combination of a cohesive vision matched with the right tools, systems and services to be integrated and laid down as a solid and cohesive infrastructure. Cities in the past have been evolutionary though, no city was built in a day and the demands have not only been satisfied by the opportunists but the other way around as well. An example of this lies in the development of infrastructure in Istanbul as the result of the geche kondu rules of the Middle Ages. People building on open land gained them ownership of property and created opportunity for those willing to provide infrastructure to those new to the urban fabric. As the city grew with informal settlements developing into more concrete developments, utilities were called for. Supply following demand. As areas of the city had infrastructure develop faster than other areas, those areas tended to grow faster. This play is evident in new cities as much as in old ones. Transitioning and evolving existing infrastructure to serve new technological advancements. As technological advancements are better understood and projected in modern times, we are starting to see infrastructure predate development and failing endure. This is where we run into problems designing from scratch. We are solving problems that are unrelated to the context and culture of the sites we are designing for.

Cities are best being served when the bottom up approach is taken, and for smart cities, that comes in the form of resource liberation. Cities are using technology to optimize and reduce cost of services they provide, from utilities mitigating last mile losses to transportation networks serving more people efficiently with existing resources, the devices and sensors are coming in regardless of the master plans. This data becomes the key though, the path for letting the city solve its own problems as they come up. By making that data open, people and groups are free to make use of it. We see this in simple forms like Boston’s adopt-a-hydrant program where people are taking on a small civic duty to keep their city safe to companies like uber making safe, cheap, efficient public transportation available to city occupants at minimal cost to the city itself.

Sidewalk labs is walking a fine line between the two approaches right now with its progress in Toronto. From the intent to open up new channels of data for the exploration and use as part of a truly connected district of an evolving technological hub, it’s still being pushed forward as an ideal for the waterfront district. Pushback from residents and watchdogs has been substantial when news broke that Sidewalk Labs was the innovation partner in the development and the backing of technology giant Google. This is the first true large scale example of the challenges of technology’s fast paced attitude is applied to the slow development process of the built environment. The city faces tough questions particularly related to data and privacy. How is it collected, where will it be stored, and who will have access and opportunities to use it. All valid concerns that are overshadowing the traditional set of deliverables developers use to push projects through a permitting and urban review process that is being called into question.