Platform Rants

In my previous post, I laid out what mobility as a service (MaaS) is, what it relies on to succeed, its meteoric pace of growth, and some of its effects on community transit. Having that foundation can help transit agencies be more informed, but it doesn’t answer the question of how to respond in terms of making concrete choices around technology investments. What are the strategic choices an agency can make now that will have meaningful impact on its ability to participate in or even set the course of MaaS systems in its community? What does it look like to embrace the principles of MaaS in the day-to-day?

To answer these questions, first some terminology: key to this topic is the technology platform, which is simply something that allows other things to be built upon it by other independent actors. For example, Facebook has a platform that allows the multiplayer game Farmville, which is developed by another company, to run on top its social network platform. If a platform is sufficiently scalable in its design and popular enough among users, then you have a technology ecosystem: a platform plus a collection of third party technology systems built on that platform, which play nicely with one another, and which together accrue value greater than the sum of their parts. Think of the role that the Apple app store has played in elevating the iPhone from a mere phone to a wildly transformative mobile device.

The Rant

While the concepts of the platform and the ecosystem are hardly new, they had not captured the popular imagination until relatively recently. A few years back, Steve Yegge, a programmer working at Google and former Amazon employee, wrote an extended rant in blog post form about Google’s systematic inability to grasp the key elements of creating technology platforms. Intended for fellow Googlers only, he inadvertently made his post public and in so doing made a splash in the programming world for reasons beyond an entertaining writing style and a penchant for poking fun at Amazon CEO Jeff Bezos. He was among the first to capture essential points about what makes up platform-friendly software designs, and he described the specifics how one business — Amazon¹ — managed to reorient itself internally to support those designs.

Should you have the time, I encourage you jump over to read the rant through to the end before continuing on. It’s a fun read, and the occasional dives into obscure Amazon and Google technologies don’t last long.

Design Implications of Platforms

Yegge says that Amazon’s transition started with an edict Jeff Bezos issued sometime around 2002. Its key elements:

• All systems had to be designed using service-oriented architecture principles, a design approach that allows a software system to be readily used by another independent system, resulting in the first system being a “service” for the second.
• The systems’ services must be made available through well documented application programming interfaces (APIs) using internet-based networking. No “back doors”, such as exchanging information through a shared database, were allowed. To use the functionality or data of a system, it had to be through the documented “front door” APIs.
• The APIs needed to be designed to be accessible not just within Amazon, but from the public internet. Any arbitrary system should be able to use a system as a building block for its own purposes.
• To eliminate any doubt about the seriousness of the matter, anyone at Amazon who didn’t design their systems in accordance with the mandate would be fired.

The effect was a dramatic shift toward creating systems that took maximum advantage of the internet in order to bring a new level of accessibility to Amazon’s technology infrastructure.² Yegge goes on at length about platform accessibility, calling it “The. Most. Important. Thing.” in software. To go beyond interfaces designed for people (e.g., web pages, desktop software, mobile apps) and create public, documented system-to-system APIs has the effect of increasing the potential uses of software by orders of magnitude. It says to the rest of the tech world, “I’m available to be part of the solution to your problem.” A highly accessible system can be plugged in and become a component in a larger mesh of systems, where each part extends and amplifies the power of the others.

Contrast Amazon’s now fully developed platform mindset with the isolated systems that still today characterize most community transit software. Their low platform accessibility means that they can’t readily take advantage of other systems, and they can’t be used as components in external systems, such as MaaS platforms. They sit alone, along with the agencies that use them, isolating their customers as well.

Business Model Implications

Yegge’s rant was written in 2011, and the lessons it sought to teach have been well learned across the technology sector. Platform- and ecosystem-focused business models have spread through substantial portions of the world economy like a brush fire. They now dominate the world of startups, to the point where it’s a near requirement for venture capital funding. Platform thinking is now part of the DNA of every single new mobility startup, and legacy players like Ford are racing to adopt them as well. The industry consensus has fallen in line with Yegge’s opinion that “a platform-less product will always be replaced by an equivalent platform-ized product.”³

A Model Response From Transit

Some of the larger and more forward thinking transit providers have recognized the sea change and taken action. One prime example is Portland Oregon’s TriMet. While most of their platform accessibility is behind the scenes, you can get a hint at the results they’ve achieved by seeing the site they dedicate to providing software developers with everything they need to build applications upon TriMet’s APIs. The APIs provide instant access to such things as bus and light rail schedules, real-time vehicle locations, and service alerts. For the general public there’s a gallery of the dozens of applications using TriMet’s open data.

Recently TriMet worked with a team of vendors to develop its next generation electronic fare payment system, Hop. Hop was designed with open APIs throughout, allowing for such innovations as smartphone-based virtual cards. The system has the core functionality required to serve as the mobility wallet for a MaaS platform⁴, meaning that it could take the place of a credit card and serve as the unifying payment method for TNCs, e-scooters, and their ilk in the region. This could offer the end user more streamlined management of the proliferating modes and put TriMet in the position of being key technology infrastructure for the very disruption swirling around it. Other agencies, such as LA Metro with their upgrade to their TAP system, are following suit.⁵

Directions for Community Transit

As Yegge defines platforms, much of the community transit sector still falls squarely in the platform-less product category. We can’t be hard on ourselves for not matching Amazon, Uber or any of other behemoths at the platform game. After all, the rant was directed at Google of all places for its inability to grasp what it needed to do to keep pace. Google has upped its game since 2011, but the point is that institutional change is hard, even when many in the industry recognize the trends and see the need for innovation. Business models and organizational cultures don’t change overnight.

In order to maintain its relevance over the long haul, community transit will need to move aggressively to adapt in several key areas. A key measure of success will be the implementation of scalable and replicable technology that matches Jeff Bezos’s edict, but more important for the present is identifying the steps that will allow for such an outcome to be within reach of a broad swath of the sector. Here are three areas of focus:

At Agencies

For transportation agencies, there should be in-house understanding about technology platforms and the value they have for transit. A measure of success could be that at least one person in the organization be comfortable in their understanding of what an API is, the role of data standards to making transit’s services visible to the mobile device-carrying public, and generally how platform accessibility and service-oriented software architectures are transforming our economy. This sort of knowledge may be considered an integral part of mobility management⁶, so if an agency has staff with the title of mobility manager, this work can fall to them, so long as their expertise filters up to leadership and can be reflected in the agency’s strategic plans. The objective here isn’t necessarily to have all the resources to execute on a major technology upgrade, but rather to be platform-literate and ready to respond when a viable opportunity arises.

At the State and Regional Levels

For state, provincial, and regional oversight bodies⁷, the demands are greater. In the past, when transit operations were more freestanding, straightforward, and predictable, it was workable for such bodies to primarily perform funding and auditing roles. Now, in the face of the platform-ization of everything, more is needed to keep community transit viable in the long term. Most community transit agencies simply do not have the resources to successfully procure and implement the new wave of technology needed to keep pace. To be successful they will need the active support of larger entities that are positioned to address common needs and find opportunities for economies of scale. While the transit agencies will certainly need to be literate and prepared as described above, umbrella entities will need to supply more specialized technical expertise. Areas of action may include general education on technology, needs assessments, and support throughout the procurement and implementation life cycles. In addition, they should maintain a sufficiently detailed understanding of all the agencies they support so they can identify opportunities for shared solutions, coordination, and, where appropriate, direct project management of their implementation.⁸

Building out the capacity to support community transit in this manner will be a new direction for many oversight bodies, one that may fall outside their traditional core competencies. This does not change their fiduciary duty to support the success of transit under their responsibility. Outside expertise can help where capacities need to be built out.

Technology Vendors

Finally, rapid evolution is needed within the technology marketplace serving community transit, where the insular software designs and business models of the late 20th century continue to dominate. Before the rise of the smartphone, one vendor could feasibly provide nearly every aspect of an agency’s operations with limited need to interoperate with any other vendor’s system. It was arguably preferable, in fact, as there were fewer compelling reasons to integrate systems and fewer technical tools to make such integrations successful. Now however, a vendor that fails to support the advancement of its customers’ platform accessibility is a clear detriment to the long term relevance of the agencies that rely on it.

The last few years have given rise to a new generation of technology vendors within the transit sector that not only build API-centric software as described above but also have business models and collaboration skills to open their applications for integration with other vendors, even direct competitors. At this point there may even be enough to form a nascent open transit platform software association.⁹ Interestingly, some of these companies are using their fluency in building platforms to explore building their own direct service networks in ways that are reminiscent of TNCs but limited to a particular niche, such as medical transportation or volunteer driver programs. At this early stage it’s hard to say how these emerging, privately operated micro-platforms will affect the sector.

Conclusion

With no Jeff Bezos to issue edicts, let alone fire those who fail to follow them, community transit will not be responding to these historic shifts with a top-down solution. A well crafted rant might make a dent, but the paradigm for adapting to change will be the main one it has used since its inception: a small army of highly dedicated private citizens, professionals, and policymakers who take leadership and action to serve the needs of their communities. The success of that response will largely depend on the perceived urgency of the problem.

Waiting for things to blow over or settle down is unlikely to be in community transit’s best interest. While the business models of the large players driving MaaS are not yet sustainable, they have enough traction and funding to continue transforming the industry for years to come. These are the years where MaaS concepts will continue to be cemented in the public consciousness, and new, more viable business models will evolve on the foundations being built today. The impact of delayed response will mean on an ever-widening breach between private mobility’s penetration into the sector and community transit’s ability to maintain its value.

1. When referring to Amazon, it’s mostly the Amazon Web Services (AWS) division that Yegge is talking about. AWS is what provides cloud hosting services to an astonishing share of the rest of the internet. Initially a way for Amazon to earn some money from its spare server resources outside of black Friday, it has grown by leaps and bounds. AWS is far and away the largest cloud hosting provider and the reason Amazon as a whole is profitable. ↩

2. We in transit have our own meanings for accessibility, so hereafter I’ll clarify it as platform accessibility. ↩

3. See The Efficiency Paradox: What Big Data Can’t Do by Edward Tenner for a thoughtful critique and analysis of the limits of platform-ization. ↩

4. Interview with Tim McHugh and Rhyan Schaub — Lessons from TriMet’s Hop Fastpass ↩

5. For LA transit, one payment system to rule them all ↩

6. See a dated but still relevant treatment of mobility management from the AARP Public Policy Institute here. ↩

7. In the United States, this would include state departments of transportation, metropolitan planning organizations, and regional councils of government. ↩

8. Given the long history of failed efforts to consolidate public service functions, it’s important to understand that this is not a proposal for greater centralization of operational control into the hands of an umbrella entity. Rather, the objective is to strategically situate technical resources where they will be most efficient and effective in their ability to support agencies in the advancement of their missions in their respective communities. Broadly speaking, since community transit is all about successfully serving the niches, consolidation of functions should only be undertaken after thorough assessment and engagement with agencies and those they serve. ↩

9. Just a crazy idea. But in case any vendors reading this are interested, I’d be happy to help connect folks up. ↩