15. Top Lessons for Public Sector?
1. Think big, start small
2. Prioritise openness and interoperability
from procurement through to architecture
design
3. Promote your administration as an
innovation platform
4. Connect the innovation dots
Marked by Conformity, Tradition, Need for SecurityTraditionally, top down, slow to innovate, resistant to changeCulture embeds a host of organisational, managerial and even legal barriers to innovation
Music industry and newspapers: Both slow to adapt. Both paying the price.Music: Forced by Apple and independent online releasesNewspapers: One daily closing per day. Even now many not adapting to mobile
Often the best source of new products and ideas but don’t always understand the public sector –not just how it works but what it needsHard to access and work with government At the same time face growth barriers such as finding right skills and ability to innovate –that government can help resolve
Darwinian – weak dieNo company so large it can stifle the market through dominanceEfficiently responds to changing desires of consumers – real time responses
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.
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.
