Image this: it’s 4:57pm, you’re sitting at work counting down the remaining minutes, and you get a text message from a State Street merchant. They’re offering you a great discount, and to sweeten the deal, they’re offering to pay your bus fare if you come down to their store. You decide it’s a good deal, head to your bus where you swipe your phone. Later, at the checkout, the store automatically credits your Metro account.
Or, try this: Your company is in a building next to a parking ramp that’s nearly always full. A big event for another tenant is going to need extra parking, so the night before they put the word out to compnaies in the building, and offer to pick up the bus fares and throw in some extra tickets to a movie for people who don’t drive the next day. You click ‘Yes’ in the email from your company to volunteer. Your company, which knows your account information, automatically transfers the fare credit and tickets to you from the other company, which doesn’t know (and doesn’t need to know) anything about you.
I could go on with many other ideas involving bus fare payments – creative pricing during snow emergencies, work bus passes that pay for rides right before and after working hours but not on weekends, or that are limited to specific trips, et cetra. If we had a very flexible bus fare payment system, the list of scenarios the community wants to enable could be very, very long.
The technology involved here is not especially complicated. The challenge is not even coming up with the list of scenarios. The challenge is how do we make the system that was designed to enable the 100 scenarios we imagined before we bought the system enable the 101st scenario we came up with after we signed the contract and installed the system?
One of the keys to building a such a system is to ensure that it has a strong commitment to open access and a solid “Application Programming Interface” that 3rd parties can access. As an example, the City of Boston provides access to its real-time bus location data, and here’s a long list of applications that make use of that data. Boston didn’t have to pay to develop those – entrepreneurs detected a need and went to work. Boston focused on the part that only it could do – tracking the buses and providing the data. More locally, Madison bus data is available through an API, and now you can get real-time access to your bus through the Mobile UW App on the iPhone, the UW Homepage on nearly any mobile device, through SMS, or as a real-time display in that can be deployed by any business that has an old computer. None of that was something Metro thought to develop or had the staff time to develop.
That sort of approach is thinking of the system as more of a platform with which anyone can build on, rather than a single solution that does everything. A good way to wind up with a platform as the end result is to treat the acquisition not as a single system, but as parts that are composed into a single system, with potentially different vendors providing different parts. Karl Fogel, of Civic Commons, writes in his post ‘New York City Bus Tracking: Procuring for an Open Architecture‘:
What’s particularly interesting about this project is how 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. That might sound obvious, but it’s actually not how a lot of civic procurement happens. More 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….By separating the software side from the hardware side, and by making a few other key decisions, such as that the server software would be 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
Unfortunately, buying a system as separate components is not the option that cities often reach for first. Again, returning to Fogel:
It’s easy to understand the attraction of this [whole-solution] method for both sides: the city gets to externalize all the details and just write a check.
More to the point, the city can write a Request-For-Proposals that focus only on the end goals, and not necessarily have to know the details of how the different components will interface. It’s a much simpler RFP to write. And in the greater scheme of things, the city staff writing the RFP can’t only worry about hypothetical scenarios of pay-by-smartphone to make a State Street business happy. Above all, they 13 million riders that need to get on the bus quickly and efficiently.
I’m not a fan of single-vendor implementations of big systems. For one, and returning to Fogel one last time:
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. Great deal for the vendor; not such a great deal for the taxpayer.
Once the city has sunk significant funds into the all-in-one solution, it puts the city in a negotiating disadvantage for future upgrades. That 101st scenario we want to enable? Sure, it can be done, for a huge price of whatever the vendor wants to charge. The city is also at risk: Washington, DC has to replace its SmarTrip farecard system because the company that makes the cards went out of business and they can’t get new cards. Once their stockpile runs out, they’re in trouble, so like it or not, they’re upgrading.
Finally, the big single solutions just don’t tend to be very good, especially in government IT. What was the last government website you interacted with? Was it a pleasant experience? Probably not. Clay Johnson has savaged the Federal Government on this point. Johnson, who believes in Government and was behind the first Obama website, claims that procurement is broken and it’s killing America. He hammers home on the extraordinarily high sums the government spends on some of its website, and his diagnosis is that the regulatory and procedural complexity of procurement means that the best technology and price don’t win, but the companies that have the lawyers and accountants to file the paperwork and slog through the process win, and the government is stuck with substandard technology. Clay acknowledges that procurement reform isn’t likely to win elections, but that it’s an important problem and wonders if we might not be better off reducing the complexity and attempts at avoiding fraud (which don’t really work anyway) to simplify the process and make it more fair.
Clay goes on: in another piece, he cites the growing contracting cartel as doing more than just costing government more money – it’s making it harder to trust government:
This isn’t right, it’s not fair, and more than that: it’s breaking us. It’s widening the gap between the technology that government has to operate, and what people expect. Given time it will cause people’s faith in government to collapse more than it already has. Today that gap represents itself with the eyes rolling when people have to deal with government data or government websites. But as that gap grows, without technology that the people outside the government take for granted, government itself will become the equivalent of an infant in a world of mature adults. It will be the governmental consequence of Moore’s Law — that gap is growing exponentially while Government’s access to it and to the people that understand it is often shrinking. The status quo isn’t just making things difficult, it’s asphyxiating government’s ability to serve.
All of this serves to underscore that there is intense complexity in procurement in the first place, especially in a city as fond of its processes as Madison is known to be.
Complexity be damned though. Madison is a city where citizens can and are expected to get involved, and I want to see us find a path forward that ensures that our ideas for civic improvement aren’t limited because we bought the wrong software for our farebox and can’t afford to replace it. I’m extremely fortunate: Alder Satya Rhodes-Conway has arranged for me to sit down with herself, the Chuck Kamp, the director of Metro, and Anne Monks from the Mayor’s office. I’ve got the ears of the people who can make a difference.
The only problem is I have no idea what to tell them. Grad school has cut down on the number of things I’d call myself an expert on, and bus fare systems wouldn’t have been on the list in the first place. I was further humbled when I found an analysis done by another blogger of the DC Metro’s fare replacement system. Even as a computer science grad student, I had to admit that was a lot of three letter acronyms.
So here’s my plan: I’m going to lay out the lessons of open data and platform access. They’re mostly already on-board because of the tracking experience, but I’m going to do what I can to be sure that they see the possibilities for payments, too. If you’re reading this and you have other suggestions for scenarios we should support, please add them in the comments.
Then, I’m going to do what I can to help connect Madison with other cities that have recently gone through the procurement process looking for new fareboxes. This will be the first ForwardLookout post I’ve ever done where much of my intended audience does not live in Madison. Farebox RFPs are not likely to be a core competency of any city, and I imagine every city that goes through them spends a fair amount of time researching, learning, and documenting best practices. Madison needs to connect with those cities, learn from them, and then share what it learns. If you’re reading this and your city has a a success story, please, let us know!
I have no doubt the RFP we want to write has already largely been written. We just need to find it, and we need to do what we can to help Metro find it. We are in this together.
