It’s been about 10 years. Apple went from creating one of the most interesting and successful media playing devices, the iPod, to generating the flagship mobile experience for consumers. Of course, I’m talking about the iPhone. The iPhone is simple, elegant, user friendly, and it just works, but the trick in the iPhone and the broader Apple marketplace is that they’ve been able to crack the code on how to create a platform.
The iPhone is a platform. What I mean by that? That means that this device, as a piece of hardware, not only comes preloaded with a dozen beautiful applications. It has enabled hundreds of thousands if not millions of applications built outside of Apple’s Palo Alto headquarters. Thousands of developers have built and continue to build many diverse and amazing tools.
That’s what we mean about a software company working as a platform. As Tim O’Reilly likes to put it, it’s the art of creating, of architecting technology where users can add even more value than what they take. The App Store may be the best current living example of this notion that is growing and thriving.
Then, since then this notion has been further extended towards areas that aren’t necessarily technological. Most relevant to this conversation is a term popularized by civic-minded Web 2.0 advocates, a notion called government as a platform. Now, this phrase, government as a platform can take on a lot of different meanings. Sometimes that can mean enabling citizens to do the work of government with government. Say, picking up the trash themselves and helping out their local recycling firm, or more famously adopting hydrant, so they can dig them out when it snows, or something just as simple as providing input. It’s not just the city making decisions on its own.
These however are more about the metaphor of government as a platform, less the technology of a platform itself. Even when technology was used, it was an enabler, not the focus point. The iPhone, however, is different. At the base level though, it was really hard and software. The App Store, no matter how you extend its metaphor, no matter how you apply its meaning to other areas, it really is a technology platform for creating new software. It’s been remarkably successful at doing that.
If we were to take this metaphor, this idea of an Apple App Store and apply it to government? What would that mean, not just from a metaphorical perspective, but from a technological one?
If we were to take this metaphor, this idea of an Apple App Store and apply it to government? What would that mean, not just from a metaphorical perspective, but from a technological one.
This question couldn’t be more relevant than it is right now. That’s because just this week, the United States Federal Government announced the launch of the United States Digital Service. This is a technology group centralized within the vast bureaucracy of the federal government, focused on supporting the creation of world class digitals interfaces for citizens.
It shares its motivation and much of its strategy and plan to its predecessor in the United Kingdom, the Government Digital Service or GDS by short. What GDS aimed to do was to create a rock star group within the government of technologists that can not only build direct government interfaces that were simple, beautiful, and easy to use. Most famouslyGov.uk, but also then serve as a kind of consulting support and strategy group for the other agencies within the federal government.
A possibly apocryphal story I heard was that a consultant came in for a big technology project projected at millions of dollars. GDS was invited by the lead agency to help provide a point of view. Now, instead of a typical vendor conversation, instead of just sitting down at the table, looking at their proposal, possibly past works, and maybe even the roadmap, the GDS staff walked into the room with a prototype. They came into the meeting with a functioning prototype of the software the agency was trying to use. They could say, “These guys are asking for tens and millions of dollars and look my team built this basically functioning equivalent in a fraction of the cost and time.” That changes things: the conversation, the process, and the power between the vendor and the government.
That changes things: the conversation, the process, and the power between the vendor and the government.
This is the background upon which USDS is being launched. GDS has already been credited with saving their government millions upon millions of dollars. Interestingly enough, it sprung out of its own healthcare debacle. They tried to roll out a healthcare system for their National Health Institute was calamitous outcomes. There is a phrasing that, “Never let a good crisis go to waste,” and our friends across the pond did not. Now, it seems that our officials in DC are not either. Now, pointing Mikey Dickerson, former Google engineer and leader of the the healthcare.gov redesign, the administration is launching an American Government Digital Service, known as the US Digital Service (or USDS). While their mandate is large, I suspect at its core, there’s this basic goal: “We will not let another healthcare.gov happen again.”
Yet, although GDS and USDS have similar motivations, similar histories in their own ways, they don’t share fully the same approach. USDS will serve as more a management consultancy for tech projects, while 18F, a technology team about 6 months older, will be more on the implementation side. Both, however, will share responsibilities and resources, it seems, with the technology groups within the agencies already. Now, the UK did that, but they did it with a broad mandate, and the staff (500+ now) to really overhaul the system.
Because responsibility is shared between USDS and the other agencies, I think the question around a functioning Apple store is salient. Apple, much like USDS had to share—or even give up —responsibility. They couldn’t build every application in the App Store, nor did they want to. Their strategy was the ecosystem.
With limited resources, complicated management structures, and share responsibilities, USDS may need to follow suit. Instead of centralizing technology expertise and a big bench, they want consider the platform play: commit to pushing innovation, tech-savvy, and modern software techniques down into the organization. This way the agencies themselves don’t have to rely on USDS or 18F for every single thing they do. That’s just not sustainable.
A close study of the Apple model, though, may point the way. For their platform, Apple focused on standard (both technical and design), distribution, and developer engagement & incentives.
Design
Anybody who has used an Apple device of any kind, iPhone, Android, iPhone, iPad, or Mac even, can’t help but notice the elegance and simplicity of the software. It just works and works beautifully.
They did that by having, of course, amazing designers on staff at Apple who could create a calendar application prettier than one that you’ve seen before; who could create an operating system that felt human; and who could continually push the envelope rising the tides of the broader design community. These became their de facto design standards, reference prototypes which anyone seeking to sit their app next to Apple’s on the home screen would do well to match.
Side note: something similar I’ve been personally noticing is with the web publishing platform, Medium, which you’re reading this article on. Flickr shared a similar origin story. The quality of the content you see on other pages by other authors, their insight, rhetoric, and meaningfulness forces you to think long and hard about what you write and how because you want to stack up. Talent attracts talent. Just the same way, developers adding apps to the App Store wanted to stack up.
The quality of the content you see on other pages by other authors, their insight, rhetoric, and meaningfulness forces you to think long and hard about what you write and how because you want to stack up. Talent attracts talent.
Of course, Apple’s strict submission and review process ensured that those apps would; not just anybody could throw an app into the App Store. No, instead you’d have to meet key standards and be approved by Apple personnel. Of course, I’ve heard this as a headache for some, but for users, they can likely see that there is a common interface language as it were to iOS applications. The gesturing is common, as are, say, the location of common buttons just settings and sharing. The user interfaces are always clean and simple. And every day, the expectations grow higher and higher for designers to create delightful experiences for their users.
This is a, ‘less is more’ approach. Instead of doing more — say building *every* application with such rigorous standards, they did less, building a number of flagship applications along with design standards to cultive high quality external contribution. That’s part of how the App Store went from just a dozen or two apps on the fresh loaded system to hundreds of thousands in the App Store.
What does this tell us for government? First and foremost, a base-level set of principles would needed, and the US’s port of the UK’s equivalent is a great start: pithy, practical, and user-centric. Supplementing these with more day-to-day design standards (e.g. a style guide, etc) may be helpful overtime. Beyond that, since USDS is meant to serve as a management consultant role, they could either invest directly or help agencies in the usability standards and interoperability systems that ensure the applications built by any agency meet industry standards for what’s great. Beyond that, they could invest in the integration services that make going from app to app to app seamless.
Those services can include identity. If you’ll notice there are many apps, for instance—those in the game center, the number of facebook apps now, etc — all those present next to seamless experiences. Switching the app to app, doesn’t require you to login again and again. Data is synced across devices too, in the same way you’d hope agencies coordinated and shared data. Finally, you’re less concerned about viruses or similar malfeasance because of Apple’s strict review and approval process; something you’d certainly want from say the IRS or HHS.
In the government setting, it’s often commented that half of your time is spent filling out paperwork, and nearly all of that is filling out paperwork with the same information over and over again. As if every form wants you to fill them out its name, your name, your address, etc. each time. So an shared federal identity service could means that citizens wouldn’t have to go through that laborious and frustrating process. That instead, they could create one account that spans multiple apps. That means that you go from many small pieces or large, not joined at all save a link from app to app, to one where those pieces are joined, arguably loosely, but loose enough that the citizen doesn’t have to each time log in or register and acclimate to that new environment. (Note: I know this has been tried before in the US was mixed results; the UK, however, relies on bank/credit card identify information, and it seems to show promise.)
The same goes, I would argue, for the design and user experience components of the App Store as we think of the government as a platform. Could we create design prototypes that are valuable from agency to agency. Probably the best example of this is Twitter’s Bootstrap design framework built by the Twitter team for them to make it easier to build Twitter and then any supporting pages for that company.
Cleverly, that team open sourced it and it quickly became the most popular open source project on GitHub. Pull up almost any page on the internet from a startup, you’ll likely see a common set of buttons or toolbars, particularly at startups, early-stage companies without the time or resources to invest in design. If you look closely, you’d notice that it’s probably Bootstrap or another common CSS framework that’s making it happen.
What about government Bootstrap? Could we create design frameworks and standards working hand in hand with USDS and the agencies that not only create common experiences app to app, but also dramatically lower the barrier for agencies to create new tools? Particularly when those agencies have a limited bandwidth and limited technical resources.
These design resources make the time to go from idea to delivery from say, 4 months or 6 months to 4 days or 6 hours. I can speak from personal experience. I can take a simple Ruby general app, throw in a Bootstrap design, customize it a bit, and take it live within a day.
Given USDS’s role as more management consultant than operational arm, it may be hard for the group to directly build either of these pieces of infrastructure. Yet, building them in a vacuum isn’t good either. Instead, maybe USDS could work with 18F and a sponsoring agency to build these services while developing new technology. For instance, develop a scalable identy system while developing a service that needs one; or generalize out a design patter after launching a beautiful app. In this way, these services — or others like them— would not only have a test case, but USDS would not need to creep beyond their mandate.
These two ideas coming together, an identity layer that makes it easier for users to switch from app to app and a design framework that provides common user experiences offer a powerful combination for a central digital strategy unit. This could dramatically change the way agencies approach technology. First and foremost, it means they no longer have to look at 18F or GDS or USDS every time they want to build a tool. Instead, those tools are now at their ready. Second, it recognizes the fact that American federal governments are vast, and will often require more than one application. HHS is going to need its own handful of apps; Energy another set, and so forth. That’s the unavoidable reality of decentralized bureaucracy, with specialized services for its specialized constituencies. That’s not a problem, that’s a reality and possibly even a good thing. These integration layers or infrastructure pieces, however, let even a thousand apps bloom, all the while keeping them in a walled garden where citizens can find what they are looking for and know that it’s likely beautiful.
These two ideas coming together, an identity layer that makes it easier for users to switch from app to app and a design framework that provides common user experiences offer a powerful combination for a central digital strategy unit.
Distribution.
The App Store model’s been something tried by other companies, both private or public. In the civic technology space, you’re seeing a number of companies invest in a platform strategy. Most, hover, focus on easier access to government clients. For instance, if your civic startup has anything to do with business permitting, you might partner with Accela, and then when a city is working with Accela, and they can more readily deploy your tool on top. For a startup, as anybody who’s worked in one can know, anything that brings down the acquisition cost is a boon.
Now, I would argue that the harder question for civic technology companies doesn’t come in the form of procurement or access to government. No, now I think that there’s energy and cities in particular across the country for new tools and a new way of doing things. There’s an itch they want to scratch. The startups and new service providers are the solution.
Instead, I think the bigger problem is actually user adoption. Getting these tools that are built, that nearly all, some are, but nearly if not most are citizen facing, and would be better with massive user numbers. Not just 100 or 50 users here or there, but thousands or tens of thousands, particularly if it’s a broad-purposed app.
It’s fair to note that some of the apps are more niche and don’t require that kind of visibility or user acquisition, and that’s fair. For the ones that do, and those in particular are the ones that are generating more significant revenue, raising funding, and have applicability or jurisdiction.
These platforms need a way to get to users, and that’s hard. As has been written in the past, people don’t wake up in the morning wanting to be civic. While you or I may wake up and pull up our email or Facebook because that’s how we been trained, that our professional and personal lives are front and center, and that’s what we want to see right away. Do we wake up in the morning and want to report a pothole? Do take a quick break from work to share an idea to improve the city? Maybe some of us do. (I’m sufficiently nerdy that that’s something that’s top of mine, but I suspect I’m in the minority there.) We want people to be civic, but we can’t assume they already are.
We want people to be civic, but we can’t assume they already are.
That means that in the civic space it’s particularly hard to gain users. That said, it was the traditional consumer space—where user acquisition is still a challenge —that the App Store model paved the way for a new breed of popular apps, because soon after launch, the iPhone was more the exception than the rule in the smartphone market.
As these devices, these little remarkable handhelds, become ever present, you were promised entry into a massive user base, all eager for new toys to trick out their pocket-sized supercomputer. The specter of your app becoming one of those shiny button user’s home screen, because feverish incentive for developers looking to build things that people used.
Put another way, the App Store paves out a pathway for use or distribution for a company that typically would have to invest dramatic resources into marketing, ranging from print to online ads, outreach and PR, and ongoing community management, user engagement.
Applying that lesson to the government space, however, is more difficult. Unlike Apple, Google, or other consumer platforms, the government doesn’t have a flagship piece of hardware. There isn’t a device everyone crave, which we drive app downloads and usage. (The closest thing would be a driver’s license I suppose, which isn’t exactly magical, not could it run anything ranging from Angry Birds to Wikipedia.)
Thus, how do we re-create that kind of, every man, every place, every usage platform that we can put in the palms of citizens hands? I’m not quite sure. You may be able to re-create the efficacy of the App Store sans the hardware.
Could you make the value of building an app that gets approved for the App Store something that governments can do? The value, not necessarily the process. Could you add other benefits, such as a business model or connections to other applications that would incentivize developers to build with those common pieces of infrastructure, design, identity, etc.?
You could imagine a high-profile government App Store focused specifically on citizens, curated very, very well, and then complemented with nontraditional delivery mechanisms. The government sends us mail, the government controls street signs, the government controls so much of what we interact with on a day-to-day basis.
We might be able to leverage those physical assets and existing processes to create the same kind of transparent marketplace that Apple was able to do. Add to that then, the prestige of, say a centralized government body housed within the offices of the executive branch. Then, you might be able to even take advantage of the clout of, say, the Oval Office. Maybe high-value applications be part of a weekly communication from the White House, that these are the apps that fit our standards that we care about and you should be using? Could you push users from one interface to another, what’s been called the civic upsell, only for applications that meet that standard?
There are probably many ways to push this kind of thinking. This piece of a government as a platform hasn’t been fully addressed yet. The central strategy would be to consider where the government had leverage — in the same way Apple did with devices and the app store — and then to put it to work on incentivizing users and encouraging developers.
The broader point, however, is simple: when you build something, people do not necessarily just come. Instead, you have to architect scaffolding for the tool makers, ways their apps can get into the hands of a sizable user base eager to engage. This strikes me as a massive opportunity for centralized technology groups such as USDS.
Business model.
Finally, the App Store was able to draw in so many developers in a serious fashion because there was money on the table. Developers could charge for their applications, ranging from $0.99 to $10 to even more than that. That meant that there was real financial incentives for developers to build apps for this government as a platform.
Of course, Apple took a chunk of that deal, and until recently, things like in-app purchases were difficult to do, so the revenue potential for many applications was a bit limited, but still there was potential. You could make money off apps in the App Store.
Now, some interesting studies have come out now that most don’t make money, that in fact, most put the developers in a lot of jeopardy around sustainability of their lifestyle and career if building iOS apps is all they do. That said, at least at the start, and there’s much commentary about this in the news, the prospect of a revenue share model did two important things.
First, it told developers and the world that their contributions in this ecosystem matter. That they are worth paying for, that you should have skin in the game just as they do because these tools matter. Second, it was a signal to developers and the community writ large that this notion of a platform wasn’t just a ‘nice to have’, but it was a ‘need to have’.
Apple invested serious resources to build that up. From a technology perspective, and from a business operations perspective, they equally staffed up a the tools and resources developers would need to go to work and a team to go through the approval process for new applications. These two together become a fairly articulate and compelling case for developers or others thinking about building on that platform, that this just isn’t a passing fancy. That the iPhone as a platform was for real.
Such a revenue share opportunity holds less relevance for the USDS and 18F examples; in those cases, the expectation is that some of the work will be done in-house, and even contracted work likely wouldn’t function on the kind of $.99 app store model. You could, however, open up the doors to the design standards and the distribution channels to outside developers, in the same way Apple did. Further, you could augment the now commonplace app contests and hackathons with prizes in the form of contracts with the agencies or USDS that offer that same kind of business incentive for developers. Sustainability, profitability, and just keeping the lights on are increasingly common and hard questions for civic technology; if any of these tactics borrowed from Apple move the needle, it should pay dividends for the ecosystem.
These three different tactics, design, and distribution, and business model, are some, but not all of the tactics that Apple used to create its platform. To make this work, we need to move beyond government as a platform as just a metaphor or idea, but into a real technological reality. Begging, borrowing or stealing innovation, whenever possible, from what worked at Apple, Google, and others, and remembering that it’s not just about the technology, but it’s also not just about the metaphor. It’s both.
It’s about the means studying closely the mechanisms through which those consumer platforms were really able to become platforms. Their businesses shifted from one exclusively about internal creativity to external participation and co-creation. That is, they swapped from a top-down model to a networked one. For the US Digital Service, it seems already slated to play this kind of network role. They can’t mandate that each agency builds everything, nor can they build everything themselves. Instead, it’s my belief that they should learn from the successes, from the consumer industry.
Learn from the iPhone, learn from the Android ecosystem, and see how those platforms, in a very real and technical sense, became effective ecosystems for innovation. See if those lessons can be applied in the public sector. Could USDS actually make government a platform a reality? A technological reality that makes every government agency more tech-savvy and excited about building great software. A reality where citizens can have world-class digital interfaces, no matter the creator, no matter the agency.
That should be our goal for government in the 21st century. One that works sure, but also one that gets smarter, more creative, and more open overtime. That’s exactly what we’ve seen from successful platforms across the board. I suspect that too is what we’ll see as we venture ahead in re-architecting our governments as a platform.
Leave a Reply
You must be logged in to post a comment.