16. Top Lessons for Cities?
1. Think big, start small
2. Prioritise openness and interoperability
from procurement through to architecture
design
3. Promote your city as an innovation
platform
4. Connect the innovation dots
Cities must deliver more for less ie better infrastructures and more efficient and responsive servicesClean energyHealth and AgeingSafer water suppliesWaste management
Internet of ThingsOpen DataOpen Innovation
One criticism of the smart city concept is that it is driven by a vision of grand projects suited to large property developers and global ICT companies. The early focus on smart cities was certainly more top-down as a result of the attention paid to ambitious new developments like Masdar and Songdo and also to the strong support offered by the likes of IBM and Cisco.
The rapid adoption of the Smart Phone as an intelligent end-user device and the growing importance of the Apple and Android apps markets has encouraged a resurgence of a more bottom-up view of the potential of urban computing platformsThe big win in civic technology is to build systems that become platforms upon which anyone can build new services, whether volunteer, commercial, or cross-governmental. The technical architectures and commercial models behind these approaches differ considerably, but they all aim to provide a development platform on which city agencies, suppliers and third-parties can build new applications and services for city management and citizen engagement.
Pike Research has coined a new term - the Smart City Operating System (SCOS) - which is not a single technical solution but a conception of the city as a “platform of platforms,” acting as a distributed middleware for linking different application areas It is a conception of the Smart City that what engineering consultancy Arup calls an “urban information architecture.”It is a practical, relatively easy to implement approach to Smart City that draws together diverse and ubiquitous systems, rather than requiring a city to start over.
For those starting on the journey is an example from New York as it was structured as an open platform from the very beginning — starting with the procurement of the various components. The MTA separated the project into a software side and a hardware side which is not what usually happens in civic procurement
Typically, a city requests to buy a whole solution in one piece, and each interested vendor submits a bid encompassing every aspect of the project: the server software, the on-bus hardware that reports the bus’s position, the mobile phone applications and web applications to query the server, public display units… everything, the whole enchilada.It’s easy to understand the attraction of this method for both sides: the city gets to externalize all the details and just write a check, and the vendor gets a big contract. But the disadvantages (for the city) are equally obvious: The vendor becomes the only competence center, the only place with enough expertise to service and maintain the system over the long haul. There’s another disadvantage to monolithic procurement, too, less often remarked on: from a technology standpoint, big turnkey systems generally don’t have good entry points for requesting data and services in a programmable way. In tech-speak, they tend not to have good APIs (“application programming interfaces” — for example,the standardized set of request and response formats your phone uses to get map information from a mobile service provider is an API).
By separating the software side from the hardware side, and by making the server software open source, the MTA has essentially forced their bus-tracking system to have good APIs — because the on-bus hardware uses published APIs to talk to the server software, and because the server software is now an independent piece whose value derives from being able to communicate with anyone’s client applications as easily as possible. Requiring that the server software be open source, as the MTA did, cements this last advantage: the best survival strategy for a piece of open source software in that position is to have as rich an API set as it can.Structuring the project this way doesn’t necessarily increase costs — in this case, there’s no evidence that it did, and it’s even likely to reduce costs over the long run, because it improves the competitive bidding situation: the MTA can use different software or hardware vendors for future phases, or even use multiple different vendors simultaneously, thus diluting the project’s overall risk. They can do this because the server software is open source (based on the OneBusAway software originally developed for use in Seattle) and thus any interested vendor can acquire expertise in it. And the MTA can use different hardware vendors because the API-oriented nature of the system means that there is no “secret sauce” whereby the hardware and software communicate using a proprietary protocol known only to the original vendor.
And that brings us to why this system isn’t just for people who happen to have smart phones: anyone can use those APIs,Thecorner store (where you’re thinking of buying that newspaper) can set up a display showing where the next bus is along its route; the MTA even lent out a couple of displays to demonstrate this. Or maybe someone will set up a display in their living room window near the bus stop, subsidized with ads (not everyone finds that an attractive future, but if it gets eyeballs that means people find it useful.) Or maybe someone will set up a text-response service for people whose phones can do text messages but not apps.All this happens outside the MTA’s budget: the MTA does not have to spend more money for these things to appear. All it has to do is structure the bus-tracking system in such a way as to enable spontaneous application development by third parties.
Since anyone can query and record bus positions over time (along the B63 route right now, and across all of New York City in the future), the MTA is enabling third parties to use that information to make predictions about bus arrival time, to analyze traffic patterns, to note and publicize service disruptions, In general to things that formerly only a transit agency could do. That doesn’t mean the MTA itself won’t do these things — they’ve already released one month’s worth of data for the B63 route in Brooklyn, just as a sampleItmeans that the MTA has bravely opened itself up to competition from the private sector: if some app developer thinks she can use the data to do something better than the MTA does it, then she’s free to try. That’s what platforms are all about.
